Organisatsiooni arendamine digipöörete õnnestumiseks – vajalike võimekuste perspektiiv

Hiljuti istusin ühe avaliku sektori projekti lõpus kliendiga koos ja arutasime plaanitud tegevusi. Selle käigus ta küsis: „Kuidas mina poliitikakujundajana peaksin suutma IT projekti juhtida ja selle vajadusi suunata? Ma tunnen oma valdkonda väga hästi, kuid IT arendustest tean palju vähem.“ Probleem, kus ärivaldkonnalt oodatakse ka samal tasemel IT projekti juhtimise oskusi võib tabada mitmeid äripoole spetsialiste. Ärilt oodatakse üha enam IT võimekusi seoses äri digitaliseerimisega ning järgnevalt vaatame, kuidas sellega toime tulla.

Vastus selle mure lahendamisele võib peituda sobiva toimemudeli valikutes, selmet kohe projekti arenduspartnerit valima tõtata. IKT toimemudel on lühidalt kokku võttes lähenemine teenuse juhtimisele, et seeläbi väärtust luua. Terviklik lähenemine sisaldab endas kategooriaid: a) organisatsioonid ja inimesed, b) informatsioon ja tehnoloogia, c) partnerid ja tarnijad, d) väärtusvood ja protsessid.

Üks keskne ja oluline aspekt, millele järgnevas artiklis rohkem tähelepanu pöörame, on rollide ja vastutuste maatriks, mis defineerib ära juhtimisobjektid ja nende juhtimiseks vajalikud võimekused. Aastal 2022-23 teostas meie pikaaegne koostööpartner Mihkel Lauk analüüsi, mis keskendus IKT arenduste toimemudelile. Projekti fookus oli seatud eelkõige avalikule sektorile, kuid tulemused on laiendatavad ka erasektorile. 

IKT arenduste toimemudel 

Toimemudeli paremaks mõistmiseks alustame sellest, miks Mihkli tehtud analüüs ellu kutsuti, ehk siis mis probleemide lahendamiseks seda uuringut alustati. Projekti meeskonda kuulusid veel Ragner Paevere, Madis Tapupere ja Janar Linros. Probleemid jagunevad sisuliselt kaheks:  

1. Tunnetuslikult rikkis asjaolud ehk siis nö sümptomid: arendus on jäik ja prioriteete ei saa muuta, projektid lähevad üle aja, prioriteetide muudatused on aeglased ja nendega kaasneb suur ressursikulu, puudub majasisene arendusvõimekus ja tehnoloogia juhtimine on väliste partnerite käes, lisaks ka projektipõhine lähenemine ja sõltuvus struktuurfondidest, dubleerivad IKT teenused ministeeriumi ja asutuste sees, suur süsteemide ja tehnoloogiate mitmekesisus koos suure ressursikuluga.
    
2. Objektiivsed asjaolud: Tulenevad eelkõige sellest, kuidas IKT-d on Eestis arendatud. Äripool on seni eelkõige kirjeldanud ärivajadusi ja teinud hanke. Seejärel on tulnud IT (nt partneri näol), kes on võtnud selle ärivajaduse ja asunud seda süstematiseerima ning korrastama. See on viinud äri olukorda, kus nad on mugavusstsoonis ja ei pea tehnoloogiast liigselt palju teadma. Nii pandeemia kui ka muude muudatustega läks nõudlus IT spetsialistide järele kõrgemaks kui pakkumine ja seega ei olnud äril enam piisavat IT poolset tuge ja ta jäi IT probleemidega üksi. Üheks aspektiks on ka see, et kui äri sõltus IT-st ja ei osanud kaasa rääkida, siis valmiv IT lahendus peegeldas pabermaailma protsesse ilma, et oleks toimunud digitaliseerimisega seotud kvaliteedihüpe. Seda siis juhul, kui IT ei saanud ärist aru või äri ei rääkinud kaasa. 

Toimemudelid ise võivad varieeruda, kuid selle aluseks töötati välja referentsmudel. Toimemudeli referentsmudel lähtub seisukohast, et kohustuslik juhtimisobjekt on äriarhitektuur ja selle komponendid. IT ei eksisteeri eraldiseisvalt ja IT arhitektuur on äriarhitektuuri tulem ning sellele allutatud. Äriarhitektuuri prioriteetsus omab olulist mõju ka vastutustele, nimelt IT ei vastuta asjade eest iseseisvalt, vaid IT küsimustes on lõplikuks vastutajaks samuti äri.

Näiteks infoturbe probleemide korral ei ole mitte probleem IT-l vaid see on lõppkokkuvõttes äri probleem, kes peab otsustama mil määral ta seda talub või eraldab vahendid probleemi lahendamiseks. Äriarhitektuur moodustub kokku erinevatest arhitektuuri vaadetest, mis omakorda seostuvad juhtimisobjektidega ning toetavate metoodikatega. 

Pilt

Äri vastutab äri toimimiseks vajaliku IKT eest.  

Äripoolelt ei suuda siiski üks inimene kõike seda kanda, selleks on vaja ikkagi ülesanded jaotada erinevate rollide vahel ära. Alloleval joonisel on kujutatud nö hädavajalik rollide ja vastutuste MVP (minimaalne töötav toode ehk inglise keeles minimum viable product). 

Pilt

Riigi mõistes lisab täiendavat komplekssust erinevate juhtimistasandite olemasolu - arendusprojekt, asutus ja ministeeriumi valitsemisala. Pannes selle joonise päris organisatsiooni või siis antud juhul ministeeriumi valitsemisala konteksti, võime näha vägagi erinevaid olukordi, kuid üldjoontes taanduvad need nelja mudeli peale. 

• Hajus mudel - Kogu IKT valitsemine ja juhtimine toimub asutuse sees. Asutus omab kõiki vajalikke võimekusi, sh äriarhitektuuri ja tehnoloogilise arhitektuuri juhtimine, samuti kriitiliste ärisüsteemide haldus ja ülalhoid. Ettevõtte puhul oleks siis tegu olukorraga, kus näiteks üks mingile kindlale tootele spetsialiseerunud osakond toimetab sellega täiesti iseseisvalt. 
   
• Jagatud mudel - Jagatud teenuste stsenaariumi korral toimub strateegiline ja eelarve planeerimine ministeeriumi valitsemisala juhtimistasandil. Jagatud on taristu alusteenused ja arvuti töökohateenused, samuti muud standardiseeritavad tugiteenused, nt hankimine. Ettevõtte kontekstis on tegu olukorraga, kus osakonnal on küllaltki suur iseseisvus, kuid teatud teenused on keskselt tagatud.  
   
• Kompetentsikeskuse mudel - Kompetentsikeskuse mudel on äriarhitektuuri juhtimise küpsust toetav mudel ja sobib seetõttu olukorras, kus äriarhitektuuri juhtimise küpsustase on madal. IT pool võtab enda kanda suure osa äripoole kohustustest, võimaldades piirangute raames tehnoloogias kaasamisest saadavat kasu maksimeerida. Ettevõtte kontekstis on tegu olukorraga, kus osakond tunneb oma äri hästi, kuid IT projektide jaoks on loodud eraldi IT osakond, kes neid projekte läbi viib ja toetab, pakkudes selleks oma teenuseid. Äri on selles kontekstis tellijaks IT-le.  
   
• Tsentraliseeritud mudel – Eesti riigi kontekstis on see kõige ebatõenäolisemaks stsenaariumiks, kuna see eeldab riigiülese avalike teenuste portfelli ja IKT eelarve keskset integreeritud juhtimist. Ettevõtte kontekstis võib seda siiski ette kujutada olukorras, kus ehitatakse mingit kindlat toodet ja kogu ettevõte on sellele allutatud. Pea kõik toodet puudutavad juhtimisotsused käivad põhimõtteliselt juhtkonnast läbi.
   

Võttes arvesse riigi kontekstis mitut juhtimistasandit ja võimalikke juhtimismudeleid, kus IKT võib olla osa ärist või eraldi üksus, on vaja kaaluda, kus peaksid paiknema vastutused spetsiifiliste tegevuste eest. Selles osas kehtib üldine reegel, et vastutus peaks paiknema seal, kus tehakse enamus selle vastutusega seotud tööst. Äriarhitektuur on keskne juhtimisvahend ja üks selle alamaosa on IT arhitektuur. Kui IT arhitektuuriga seotud tegevusi tehakse peamiselt IT osakonnas/asutuses, siis peaks ka vastutus selle alamteema eest lasuma seal. Läbi äriarhitektuuri jääb siiski äri vastutama terviku eest. 

Edukate IKT arenduste eeldused 

Projekti üks fookusi oli ka edu eelduste tuvastamine, analüüsi käigus uuriti 16 silmatorkavat projekti. Selle käigus uuriti, miks projekt õnnestus, selmet keskenduda ebaõnnestumistele. Õnnestumisi uurides joonistusid välja selgelt eduka lõpptulemuseni viivad aspektid. Sisuliselt kõigis uuritud projektides esinesid alljärgnevalt kirjeldatud edu eeldused.  

Pilt

• Väärtuse koosloome - Tänapäevased IT eesmärgid on samad, mis äripoolel. Enam ei räägita äriteenustest ja IT teenustest, vaid ainult äriteenustest ja äriarendusest, mida mõnedel juhtudel tehakse tehnoloogia kaasamise abil. 
• Teenuse juhtimise terviklikkus – teenuseid juhitakse lähtudes äriarhitektuurist, kasutades selleks ITIL-i (Information Technology Infrastructure Library) puhult kirjeldatud dimensiooni: 1) Organisatsioonid ja inimesed; 2) Informatsioon ja tehnoloogia; 3) Partnerid ja tarnijad; 4) Väärtusvood ja protsessid. 
• Juhtimissüsteemi, rollide ja vastutuse selgus - iga väärtusvoos osaleja mõistab enda rolliga kaasnevat vastutust ja ajakohastab vastavalt oma oskusi ning pädevusi – seda läbi kõikide juhtimistasandite. 
• Strateegiline fookus - kõige olulisemad eesmärgid IKT arendustes on arenduste kiirus, kvaliteet ja turvalisus. Kriitilised kontrollkohad on läbipaistvus raha- ja ajakasutuses. 
• Tippjuhi panus - Tippjuhi panus suurendab ka teiste pühendumust. Tippjuhtide kaasatus, osalus ja eestvedamine on oluline, kuna see toetab töö sisulist ja mõtteviiside muutust. 
• Äripoole vastutus - IKT arendustes on vajalik asjatundlik äripoole esindaja - tooteomanik, kes julgeb võtta vastutust ja teha kiireid (vahel ka riskantseid) ning konkreetseid otsuseid. Erandeid jõuab vajadusel lahendada ka hiljem. 
• Agiilne ja iteratiivne arendus - On oluline, et arenduste tulemused loodaks nii kiiresti kui võimalik, et kõik osapooled saaksid neid kiiresti kasutusele võtta, kogemusi omandada ning sellest tulenevalt järgmiste iteratsioonide osas paremaid otsuseid teha.  
• Head partnersuhted - Partnersuhete kaalutlemise põhimõte tähendab, et tulenevalt välistest faktoritest ja ärivajadustest (kiirus, tähtaeg, turvalisus), on kasulik partnersuhete osakaalu maksimeerida, tasakaalustades seda infoarhitektuurist tulenevate nõuetega. Juhtimist ei tohi käest anda partnerile. Partner ei ole käsutäitja vaid abiline probleemi lahendamisel, oluline on koostöö ning ühise ärilise eesmärgi nimel pingutamine. 
• Lõimitud tiimid – Tiimi liikmed ei takerdu formaalsetesse organisatsiooni piiridesse. Lõimitud tiimi põhimõte tähendab muu hulgas, et vajalikud kompetentsid kaasatakse eesmärgipõhiselt vastavalt vajadusele ja paindlikult, kasutades selleks nii sisemisi kui väliseid ressursse. 
• Paindlik eelarve – Eelarve juhtimine peab olema äriliselt autonoomne, pidev ja paindlik. Paindlikkuse tagab see, kui äripool saab ise seada arendusvajadustele prioriteedid tervikliku teenuse eelarve raamides, millest eelnevalt on eraldatud tehnoloogia ülalhoiu ja elutsükli juhtimise kulud. 
   

Eelduste täitmine ei garanteeri projekti õnnestumist, kuid see muudab õnnestumise tõenäosuse oluliselt suuremaks. Teisalt nende täitmata jätmine muudab ebaõnnestumise tõenäosuse selgelt suuremaks.  

Ebaõnnestumised ja partneri vaade 

Me alustasime sellest, et lõplik vastutus on äril, seejärel täpsustasime, et vastutuse realiseerimiseks on tal kasutada organisatsiooni erinevad ressursid, kellele ülesandeid delegeerida ning lõpuks kirjeldasime nö edu eeldusi, mis organisatsiooni korralduses peaks toetama projekti õnnestumist. 

Asetades end välise partneri konteksti ja nähes, et Tellijal ehk siis äril on edu eeldused täitmata, tekib küsimus, mida sellises olukorras teha. Üldiselt võib sellises olukorras kaaluda mitut varianti:  

1. Juhtida äri tähelepanu edu eeldustele ja toetada nende täitumist nii, kuidas see on võimalik. Iga IKT arendusprojekti raames toimuva koostöö eesmärk on projekti õnnestumine ja mõlemapoolne rahulolu. Olukorras, kus äri mõistab oma vastutust ja täidab edu eeldusi, läheb koostöö sujuvamaks ja mõlemale poolele kasulikumaks. Projekt on selgelt fokuseeritud ja otsuseid tehakse eesmärgist lähtuvalt. Partnerina on võimatu nn jõuga asju ümber korraldada, kuid õigel hetkel saab õigete inimeste tähelepanu juhtida puuduvatele asjaoludele ja eelduslikult toimuvad selle tulemusena soovitud muutused. 
    
2. Riigimehelikult projektist väljuda. Kui probleemidele ja puudujääkidele on tähelepanu juhitud, kuid asjad oluliselt paremaks ei lähe. Partner näeb, et toodetakse mingit jama ja raisatakse Eesti elanike raha, siis selmet selles kaasa lüüa ja oma nime määrida, võib projektist väljuda. Partneri perspektiivist ei tule selline otsus kergelt, sest töö saamiseks on tehtud investeering ja projekti käigus on juba sellesse investeeritud, seega on soov investeering tasa teenida. Lisaks võivad sellist väljumist takistada ka lepingutes olevad trahvid. Teisalt on ebaõnnestumisele määratud projekti kallal töötamine ka partneri töötajatele demoraliseeriv ja lõppkokkuvõttes võib olla otstarbekam projektist ikkagi loobuda, kui seda taluda.  
    
3. Taluda ja võtta nii palju tulu kui võimalik. Kui olukorda paremaks muuta ei ole võimalik ja väljumine ei ole võimalik, siis jääb üle ainult kannatada ebaõnnestumisele määratud projekti. Võib kõlada küll küüniliselt, kuid sellises kontekstis jääbki partneril üle ainult puhvri loomine, et võimalike negatiivsete tagajärgedega toime tulla.  

Kokkuvõte 

Artiklis vaatasime organisatoorset töökorraldust IKT arendusprojektide toetamiseks. Kirjeldatud õppekohad on relevantsed nii avalikule kui ka erasektorile. Peamised tähelepanekud on järgmised:
 

• Äri on vastutav teenuste eest ja kui selle teenuse osutamiseks on vaja IKT komponenti, siis on ka äri selle eest vastutav. Äril on juhtimiseks kasutada äriarhitektuur, mis konsolideerib endasse mitmeid teisi distsipliine.  
• Äri ei ole siiski vastutustega üksi, vaid tal peavad olema kasutada erinevad võimekused teiste spetsialistide näol. 
• Toimemudel defineerib ära minimaalse komplekti rolle ja vastutusi, mis on IKT arendusprojekti jaoks vajalikud ja sellega nii otsesemalt kui kaudsemalt seotud. 
• IKT arendusteks võib kasutada erinevaid organisatoorseid mudeleid, need peaksid lähtuma organisatsiooni ülesehitusest. Ideaalis võiks äri ja IT olla integreeritud.  
• Projekti õnnestumiseks eksisteerivad edukriteeriumid, nende täitmine tõstab oluliselt projekti õnnestumise tõenäosust. Suurem osa edukriteeriume puudutab IKT arendusprojekti juhtimise erinevaid tasandeid.  
• Partnerina projektis, kus edukriteeriumid ei ole täidetud, on tunnetatud ebaõnnestumise risk suurem. Soovides siiski projekti edukalt lõpetada, on praktiliselt kohustus suunata äri tähelepanu juhtimise puudujääkidele ja määramata vastutustele.  
• Kui soovid projekti kohta põhjalikumalt teada, siis soovitame tutvuda lõpparuandega Rahandusministeeriumi veebilehel ja link aruandele on siin.  

Agiilse arenduse kohta saad lähemalt lugeda siin blogis.
Suurte tarkvaraprojektide ehk vesiagiilsuse kohta saad lugeda siin.

Otsid tarkvaraarenduse partnerit? Võta meiega ühendust.