Metoodiline lähenemine on võitjate valik
Allikas: Äri-IT Kevad 2022
Autorid: Kristina Ilves, BCS Itera kvaliteedi- ja metodoloogiajuht ning Külli Rebane, BCS Itera ärijuht
Õige metoodika valik tarkvara juurutamiseks on sama tähtis kui tarkvara enda valimine. Olgu tegemist traditsioonilise või agiilse metoodikaga, toob teatud etappidest või tegevustest loobumine kaasa väga ohtliku olukorra, mis reeglina läheb sõna otseses mõttes kalliks maksma.
Üks asi on leida ettevõtte igapäevatöö planeerimiseks ja korraldamiseks sobivaim majandustarkvara (ERP), teine asi on see aga ka tegelikult käima panna. Viia uude lahendusse vajalikud andmed ning seadistada-kohandada tarkvara nõnda, et see toetaks äriprotsesse maksimaalselt ja muudaks need efektiivsemaks. Ühtlasi koolitada välja inimesed, et nad oskaksid uut lahendust kasutada.
Metoodika valimine
See, KUIDAS majandustarkvara juurutada, on vähemalt sama oluline kui õige tarkvara valimine.
On üsna tavapärane, et ettevõte teeb põhjaliku eeltöö, valib pikalt nii tarkvara kui ka juurutuspartnerit. Aga kui otsus on olemas, soovib lahenduse kasutusele võtta piltlikult öeldes homme. Sellise kiirustamisega tehakse aga kahetusväärseid otsuseid, mis võivad oodatud võidu asemel kaasa tuua hulga lisatööd ja -kulusid, rääkimata pettunud kasutajatest, kelle töövahendid on muutunud hoopis kohmakamaks. Soovitud efektiivsuse kasv jääb tulemata.
Musta stsenaariumi ärahoidmisel mängib olulist rolli konteksti sobiva metoodika valimine ja aja varumine selle rakendamiseks.
Tähtis on mõista, mille alusel ja mille vahel valida, ning mis võib juhtuda, kui mõnest rollist loobutakse või mõni tegevus kõrvale jäetakse. Valik sõltub peamiselt tellija äri keerukusest, vajadustest ning valmisolekust panustada. Ja muidugi juurutuspartneri võimekusest eri metoodikaid rakendada. Parima lahenduse võib saada ka mitme meetodi asjakohasel kombineerimisel.
Tarkvaraarenduses pikka aega rakendust leidnud waterfall’i metoodika järgi on terviklahenduse juurutamisel selged etapid. Enne iga järgmise etapi kallale asumist koostatakse põhjalik dokumentatsioon ning tehakse täpsustused (joonis 1).
Joonis 1. Klassikaline waterfall’i metoodika
Tänapäeval löövad aga laineid mitmed agiilsed metoodikad. ERP juurutuse agiilset lähenemist ilmestab joonis 2:
Joonis 2. Agiilne tarkvara juurutamine
Ettevaatust agiilse juurutuse puhul!
Agiilne juurutus on paljude soov. Kuid ettevaatust! Nii tarkvara kasutuselevõtja kui ka juurutuspartneri jaoks pole sugugi alati selge, kuidas agiilset juurutust läbi viia, püsides eelarves ja ajakavas. Agiilsus ei tähenda ega tohigi tähendada juhtimata projekti.
Agiilne lähenemine ERP juurutamisel on hea, kui eesmärk on kaasata kasutajad võimalikult varakult ning teha tänu sellele lahendusse täiendusi juba teadlikuma tellijaga. Kui aga eesmärk on kärpida eelarvet ja ajakava, on agiilsust valesti mõistetud.
Puhastverd agiilse lähenemise rakendamine kompleksse majandustarkvara juurutamiseks võib osutuda ebaotstarbekaks ühel konkreetsel põhjusel. Erinevalt mõnest muust tarkvarast ei pruugi vajaduste loendist tarkvara kriitiliste osade jaoks ärivajaduste eraldamine iteratsioonideks otstarbekaks osutuda, kuna äriprotsessid on omavahel väga põimunud.
Olgu lähenemine klassikaline või agiilne, on igal etapil, tegevusel ja rollil mis tahes metoodikas täita oma osa ning eesmärk. Ehkki esmapilgul tundub, et millestki loobumine annab võidu, on sellel tagasilöögid. Siin on nimekiri loobumistest ja tagajärgedest:
Analüüsist loobumine
Kõige tavapärasem on kliendi soov jätta ära analüüs. Põhjenduseks tuuakse soovimatus rääkida juurutuspartnerile oma senisest äriprotsessist, kuna soovitakse uue lahendusega protsesse muuta. Oodatakse, et muudatusettepanekud teeb partner, lähtudes oma kogemusest ja tarkvara võimalustest. Teatud mõttes on see õige. Uue tarkvara juurutamise üks eesmärkidest on muu hulgas ka protsesside parendamine, kuid analüüsi vahelejätmise korral on sel juhul eelarve ja ajakava muutus juba ette sisse kirjutatud.
Juurutuspartnerina peame kogu aeg arvestama, et klient ei oota meilt tingimata vastust küsimusele, vaid pigem lahendust probleemile. Lahenduse otsimine algab aga äraspidisel moel hoopis õige probleemi tuvastamisest. Analüüs aitabki leida n-ö õiged probleemid, millele asutakse järgmistes etappides lahendusi otsima. Lisaks tuleb arvestada, et ükski juurutuspartner ei loo nagunii suurt punast nuppu, mis loeb ja võtab arvesse kõigi kasutajate mõtted.
Dokumentatsiooni koostamisest loobumine
Jutt käib siis ärivajadusi ja lahendusi kirjeldavast dokumentatsioonist. Mis saab, kui otsustatakse jätta tervik läbi rääkimata ja kirja panemata ning alustatakse lahenduse ülesehitamist ühest äriprotsessist? On selge, et teatud hetkel peab siis esimese äriprotsessi juurde tagasi pöörduma, selle jaoks tehtud kohandusi muutma või isegi täiesti ümber tegema.
Koolitustest loobumine
Juurutuspartneri soovitus võtta kasutajate koolitamiseks aega ei ole kindlasti ajendatud soovist projekti mahtu suurendada või ajakavasse koolituse näol mitme kuu jagu puhvrit lisada. See tuleneb hoopis elukogemusest. Võib julgelt väita, et projektid, kus nii võtme- kui ka peakasutajatele antakse aega ja võimalus lahendusega sõbraks saada, täidavad oma eesmärki paremini. Sel juhul esineb vähem vigu, lahendused on üles ehitatud läbimõeldult ning kasutajad on rohkem motiveeritud.
Suuremates projektides, kus mõned kasutajad osalevad kogu juurutusprotsessis, on võimalik delegeerida lõppkasutajate koolitamine neile. Kuid lühema projekti korral ei pruugi nad selleks valmis olla, nende käe all ei omanda lõppkasutajad vajalikul määral teadmisi-oskusi ning lõpuks tuleb koolitused enne või pärast lahenduse kasutusele võtmist ikkagi juurutuspartnerilt tellida.
Kokkuvõttes kehtib ERP juurutamisel tihti elutarkus: meil ei ole nii palju aega, et kiirustada.