Majandustarkvara juurutamine: hasartmäng või kirurgiline protseduur?
Autor: Marek Maido; BCS Itera turundusjuht
Kas usaldame südamekirurgi, kes ütleb, et uuringuid pole vaja, visake aga lauale pikali! Aga sama mõtteviisiga tarkvarafirmat?
Miks ma selle teema siin tõstatan? Sest olukordi, kus tellija ei saa aru protsessi metoodikast või õigemini selle vajalikkusest, on päris palju. Tavaliselt toongi talle näite keerukast südameoperatsioonist – me ei võtaks ju väga tõsiselt arsti, kes ütleb, et uuringuid pole vaja, lõikame lahti ja siis vaatame, mis saab.
Nagu iga terviserike või näiteks majaehitus, eeldab ka vähegi suurema ettevõtte juhtimis- ja majandustarkvara juurutamine korralikku eeltööd. Esmalt ootame arstilt, ehitajalt ja IT-konsultandilt ikka kogemust, oskusi ja põhjalikkust.
Tihti küsivad kliendid, kes majandustarkvara (Enterprise Resource Planning) juurutavad, et kui valusaks kogu see projekt võib kujuneda. Lihtne vastus: mida põhjalikum on ettevalmistus, seda valutumalt läheb. Oluline on ka mõista, et mida rohkem muudatusi soovitakse ja mida suuremat efekti oodatakse, seda keerulisem ja mitmekesisem on projekt.
Planeerimise osa ERP juurutamisel on võimatu ülehinnata. See protsess mõjutab kõiki osakondi alates sekretärist kuni ostu ja laoni, nii et sellise mastaabi puhul peab sul olema kindel plaan. Kui planeerimine lonkab, siis läheb pahatihti juurutusprotsessis siht kaduma, tekivad viivitused ning lõpuks jookseb kogu projekt rööbastelt maha. Nii et planeeri, planeeri ja siis planeeri veel!
ERP juurutamises on mõnekümne aastaga välja töötatud mitu metoodikat. Vahet pole, kas agiilne metoodika või WaterFall – üks sobib ühes situatsioonis ja teine teises. Olulisem on, et osapooled mõistaksid metoodikat ühtmoodi ning valdaksid ja järgiksid seda detailselt.
BCS Itera on juurutanud peaaegu 25 aasta jooksul 500 keskmise ja suure ettevõtte majandustarkvara. Ma võin täie veendumusega öelda, et ilma põhjaliku eeltööta ja juurutusmetoodika järgimiseta mängitakse laua taga ühiselt loteriid. Kui päris halvasti ei lähe, siis palju jamasid tuleb kindlasti.
Toon siin lihtsustatud kujul välja põhilised etapid…
Diagnostika
Ehituses võiks seda võrrelda eskiisprojektiga, kus on visandatud projekti visioon ehk kliendi ootused ja arhitekti arusaam. Tähtis on, et kõik saavad üheselt aru projekti ulatusest ja keerukusest. Tulemiks on ühine arusaam tulevasest lahendusest, projekti maksumuse suurusjärk ning eeldatav ajavahemik. See ei ole veel täpne hinna-pakkumine. Tavaliselt võtab kogu etapp aega nädal.
Analüüs
Siin on tegemist juba nõuete kirjeldusega, kus tellija annab detailselt edasi oma ootused, kuidas lahendus peab katma kõik väiksemadki protsessid. Tulemuseks on dokument, kus on kirjas nõuded, millele lahendus peab vastama – selle põhjal hakatakse ühiselt uut lahendust ehitama-paigaldama. Sõltuvalt lahenduse ulatusest ja suurusest läheb selle peale aega 2-4 kuud.
Vahemärkus: need kaks etappi tuleb kindlasti läbida, muidu pole mingit selgust, mida, kuidas ja mis ajaraamistikus tegema hakatakse. Suure projekti puhul tasub tervik etappideks jagada (kuigi alati pole see võimalik, sest piltlikult sõltub vundamendi või esimese korruse ehitus järgmistest), aga selle vajalik-kust oskab kindlasti hinnata juba pädev partner.
Disain
Põhimõtteliselt on tegemist tehniliste jooniste ja kirjeldustega. ERP projekti puhul on eelkõige disainitud kõik tellija erivajadused ja lahendused. Tellija ja partner peavad üheselt aru saama, mis on vajadus ja pakutav lahendus. Tihti tehakse kliendile ka nn toimiv prototüüp, millele lisatakse järg-mises etapis kliendipõhised erilahendused. Sõltuvalt lahenduse ulatusest ja suurusest võtab see etapp aega 2-4 kuud.
Arendus-paigaldus-tugi
Panin need kolm etappi siin kokku – see on ehituse ja kolimise protsess, mille lõpus on tellija uue lahenduse kasutusele võtnud.
Õige algus tagab edu
Kui taas meditsiinivaldkonna juurde tulla, siis on üllatavalt tihti patsiente, kes ei taha eriti panustada uuringutesse ehk diagnostikasse, mõistmata, et see on kogu protsessi edu ja südamerahu alus. Ka meie valdkonnas tuleb seda ette. Võin aga öelda, et kui keegi pakub teile kui kliendile ilma eeltööta midagi, siis maksate kas raskelt üle või saate ebasobiva asja.
Sageli on tellijale endalegi üllatuseks, et ta ei ole endale päris selgeks teinud, mida ja kuidas ta soovib, ning juhtkonnas on asi läbi vaidlemata. Mida siis partner peaks ehitama? Nende sisemiste vaidluste ja diagnostika etapi vahele jätmine ongi põhjus, miks partneri ja tellija suusad tihti risti lähevad.
Seega tasub partneri kogemust usaldada, kui tehakse ettepanek kohtuda ja läbi viia ettevalmistavad töötoad. Jah, reeglina on see professionaalse töö puhul tasuline, täpselt samamoodi, nagu arhitekt küsib eskiisprojekti eest tasu.
Kas projekt vajab juhti?
On tellijaid, kes ei saa aru, milleks projekti-juhti on vaja. Äkki saab ikka kuidagi ilma läbi?
Kuid oleks lihtsameelne arvata, et kõik liigub sujuvalt ja koordineeritult, kui panna n-ö ühte aegruumi 10-20 inimest eri ettevõtetest. Ütlematagi on selge, et siin on vaja projektijuhti – kedagi, kes juhiks metoodiliselt, jagaks laiali kohustused, planeeriks ressursi, lepiks kokku kohtumised, jälgiks tähtaegu ja hoiaks eesmärkide saavutamisel silma peal, kontrolliks kvaliteeti ning tagaks operatiivse kommunikatsiooni. Teatava liialdusega võib öelda, et 60% projekti edust sõltub projektijuhist.
Kokkuvõte
Ärme tee ERP projektist kasiinokülastust, vaid alustame sellega professionaalselt, läbides põhjaliku ettevalmistuse. See on näiline, et ilma selleta hoitakse aega kokku, vastupidi. Kokkuhoitud investeeringu võib julgelt mitmekordistada, sest see kulub hiljem parandustele, ümbertegemisele, muudatustele, vaidlemisele ja kadunud närvirakkude taastamisele. Sisekaitseakadeemia endise rektori Lauri Taburi kirjutises jäi mõni aeg tagasi silma Dwight Eisenhoweri tsitaat, et plaan ei tähenda midagi, oluline on selle koostamise protsess.