Majandustarkvara juurutus: kui palju peaks panustama tellija?

Allikas: Äri-IT Sügis 2021

Autor: Leho Hermann, BCS Itera müügijuht

Nagu tangot tantsitakse kahekesi, on ka majandustarkvara (ERP) juurutamisel selgelt kaks osapoolt ja nende olulist panust vajav projekt. Just olulist panust, kuna tihtilugu klient alahindab oma osa.

Kuna ERP projekte ei tehta iga aasta, siis on arusaadav, et puudub kogemus ja tööjõudu ei osata planeerida. Probleemide vältimiseks on soovitatav partneriga see teema juba müügifaasis põhjalikult läbi rääkida, et mõista, millise pädevusega inimesi mingil ajahetkel on vaja.

Rusikareegel ütleb, et kliendi pool peab panustama vähemalt sama palju töötunde nagu partner. Kui näiteks projekti mahuks on planeeritud 1000 tundi, siis sama mahtu oodatakse kliendi meeskonnalt.

Vaatame põhjalikumalt ERP-projekti tavapäraseid etappe (olenevalt partnerist võivad metoodika ja etapid mõneti erineda).

Analüüsietapp

Ükskõik millise projekti tähtis eeltöö on probleemide ja tulevikuliste vajaduste kaardistamine. Seda on võimalik teha nii oma ressurssidega kui ka koos partneriga. Mõlemal juhul tuleb kaasata võtmekasutajad, kuulata ära nende mured ja visioonid, need korrastada ja dokumenteerida.

Kui projektiplaanis on näiteks ostuprotsessi töötoaks planeeritud 4 tundi, siis see on ainult osa vajaminevast panusest. Selleks et töötuba oleks efektiivne, on vaja selleks valmistuda (mitte üksi, vaid kaasates olulisi protsessis osalejaid), siis see läbi viia ning pärast veel selle memo läbi töötada ja vajadusel kommenteerida. Näiteks võiks ühe teema (ost) panuse tundides kokku võtta järgmiselt:

Partneri projektiplaanis või pakkumises välja toodud 4–8 tundi ühe teema jaoks võib tähendada kliendi meeskonnale 3–4 korda mahukamat ajalist panust. Kui seda enda jaoks ei teadvustata ja see teadmine tuleb projekti alguses tellija töötajaile üllatusena, on juba oht, et projekt ei kulge edukalt.

Andmeülekanded

ERP-projekti tulemusel toodetakse andmeid, mille põhjal tehakse eri tasanditel juhtimisotsuseid. Seetõttu on ülimalt oluline, et algandmed, millega uut ERP-d kasutama hakatakse, oleksid kohe kvaliteetsed ja õiged. Muidu hakkab üks viga tootma järgmisi ja nende leidmine ning parandamine nõuab juba kordades rohkem aega ja raha.

Nii nagu analüüsietapi kestvus on partneri pakkumises hinnatud ühe numbriga, kuid tegelikult kulub sinna aega kordades rohkem, tähendab ka kvaliteetsete andmete tekitamine kliendi meeskonna jaoks tegelikkuses palju suuremat panust. Juurutuspartneri ajahinnang peegeldab põhimõtteliselt kliendi ettevalmistatud andmete importimist uude lahendusse eeldusel, et andmed on õiged. Selle nimel ongi vaja kliendil teha palju eeltööd, sest ainult andmete igapäevased kasutajad oskavad öelda, millised andmed on õiged. Partneri osaks jääb tehniline importimise töö.

Andmete ettevalmistamine tähendab nende kättesaamist vanast süsteemist, liigsete või vanade andmete eemaldamist, lisaväljade täitmist uue lahenduse jaoks jms. Juhul, kui enne on kasutusel olnud mitu programmi ja hulgaliselt Exceleid, muutub see töö veelgi ajamahukamaks.

Kõiki protsesse hõlmava ERP-projekti puhul võib olenevalt (vanadest) süsteemidest andmete ettevalmistamine nõuda kümneid ja kümneid tunde ja see on töö, mida ei saa teha partner.

Seadistamiste ja kohanduste etapp

See on üks aktiivsemaid etappe, kus toimub palju ühiseid töötubasid, mille käigus omandatakse põhiteadmised uuest lahendusest ja tulevaste protsesside olemusest ning tehakse analüüsietapis kokkulepitud seadistused.

Taas ei piirdu kliendi panus pelgalt töötubades osalemisega, vaid oluline on pärast igat töötuba räägitu ka iseseisvalt või koos kolleegidega üle korrata või lahenduses ära testida. See kinnistab info ja annab hea ettevalmistuse järgmisteks töötubadeks.

Joonis 1.

Tihti tekib diskussioon selle üle, kes võiks koostada kasutusjuhendid. Praktika näitab, et head kasutusjuhendid on loonud kliendi võtmekasutajad, kuna nemad tunnevad kõige paremini oma protsesse ja nüansse, mida peab juhendites kajastama. Ka selle ajaga on vaja arvestada.

Käivitamise etapp

Kui kõik eelmised etapid on edukalt läbitud, tuleb väga oluline osa – lahenduse testimine, mida teevad nii partner kui ka kliendi töötajad. See annab kindluse, et kõik eelnev on toimunud korrektselt ja vastavalt kokkulepitule.

Selles etapis lisanduvad ka ülejäänud tulevased kasutajad, kellele tehakse koolitused ja antakse teadmised uuest lahendusest.

Aja poole pealt kehtib nii testimise kui ka koolituse kohta ütlus, et testimist ja koolitust pole kunagi palju, mis tähendab seda, et selleks tuleks planeerida pigem rohkem aega kui vähem. Soovitame kliendil kõik oma protsessid ja erinüansid läbi testida, et veenduda nende toimimises.

Positiivne näide on tuua pan-Balti jaemüügiketi projektist, kus klient otsustas eraldada lisaaja iseseisva testimise jaoks (protsesside mitmekordne läbitegemine uues tarkvaras; proovipäevad poodides, kus tehinguid tehti nii vanas kui ka uues tarkvaras). Tulemus oli see, et go-live-päeval tuli kasutajatelt ainult paar küsimust ja kogu projekt läks töösse täiesti valutult.

Soovitame teha kasutajatele mitu koolitust, et teadmised kinnistuksid, kusjuures parimad koolitajad võivad olla hoopis oma maja inimesed, kes tunnevad igapäevast äri ning oskavad just neile viidata.

Joonis 2.

Kokkuvõtteks

• Kogu projekt on tähtis ehk kõik etapid vajavad palju panustamist, et üleminek uuele lahendusele oleks maksimaalselt sujuv ja probleemivaba.
• Tuleb arvestada, et ERP-projekt on kliendi, mitte partneri projekt ehk tuleb arvestada olulise kliendipoolse panustamisvajadusega. Näiteks Premia Grupi juurutusjärgne kokkuvõte oli, et ERP-projekti panus jaguneb kliendi ja partneri vahel 2/3 ja 1/3.
• ERP-projekti ette valmistades tuleb kindlasti planeerida osalejad ja nende panus, et see vajadus ei tuleks üllatusena. Selleks tuleb teha projektiplaani koostamisel aktiivset koostööd oma partneriga.