Tarkvaralahenduse juurutuse seitse võtmeküsimust

Ühtset ja kindlat tõde erinevate projektijuhtimis metoodikate puhul pole. Kõik metoodikad on välja töötatud eesmärgiga viia projekt võimalikult edukalt läbi ajalistes, rahalistes ja soovitud tulemuse kvaliteedi etteantud raamides, võttes arvesse kõiki võimalikke riske ja püüdes neid ennetada.

Vaadakem korraks teguritele, mis on tarkvara juurutamist erinevates ettevõtetes raskendanud.

Igal tarkvaraprojektil on kindel eesmärk. See on selge ja kõigile projekti osalistele ühtselt mõistetav kirjeldus sellest, mida ja miks hakatakse tegema, millised on kitsaskohad, mis lahendatakse ja millise tulemuseni tahetakse projekti lõpuks jõuda.

Et seda eesmärki oleks kergem paika panna, tuleb kirja panna kõik äriprotsessi efektiivset funktsioneerimist takistavad tegurid, millise prioriteetsusega on need segavad faktorid ning milline on lahendus, mis rahuldab ettevõtte vajadusi.

Vältima peaks olukorda, kus tekib teadmine, et midagi oleks vaja muuta ning siis keskendutakse mõttele, et võlusõnad nagu ERP, CRM, MRP (vastavalt kliendihaldus, ressursside ja materjalivajaduse planeerimine) lahendavad olukorra. Paljud on neist kuulnud, paljud võtvad neid kui asja, mille omandamisel keegi tuleb ja lahendab kõik probleemid. Siiski on need kolmetähelised võlusõnad vaid tööriistad lahenduse väljatöötamiseks, mis iseenesest midagi ei lahenda.

Selleks, et neid enda kasuks tööle panna, on täpselt vaja teada, mida tahetakse ettevõttes paremini teha, millised on need otsused, mille tegemiseks täna info puudub või mille kättesaamine on liiga vaevaline.

Nähes uue tarkvara võimalusi, on selge, et tekivad mõtted, kuidas uut funktsionaalsust paremini ära kasutada. Ja nagu öeldakse, süües kasvab isu… Siinkohal peab aga eriti tähelepanelik olema, kuna iga lisa, muudatus või erisoov nõuab realiseerimiseks lisaaega, töötajate ja juurutajate ressurssi ning rahalisi vahendeid.

Planeeritud projekti õigeaegse lõpetamise huvides oleks mõistlik kõik juurutuse käigus tekkivad soovid üles kirjutada ja siis juba koos juurutajaga otsustada, kas need realiseerida juurutusprojekti raames ja olemasoleva eelarve piires või jätta need eraldi töödena ootenimekirja.

Eraldi nimekirjas olevatele töödele tehakse hiljem hinnapakkumine. Sellest lähtuvalt saab otsustada, kas soovitud funktsionaalsus on lisainvesteeringu vääriline. Selliselt on võimalik ära hoida nn lumepalliefekti, millel võivad olla planeerimatud tagajärjed.

Kõik me ootame juurutajalt teadmisi juurutatava tarkvara osas, kogemusi erinevatele ettevõtetele lahenduste juurutamisel, oskusi lahendada ärispetsiifilisi nõudmisi tarkvaras ja võimet efektiivselt töötada ning maksimaalselt kokku hoida nii enda kui ka tellija aega.

Ükski firma ei taha olla see esimene klient verinoorele konsultandile, kellele peab hakkama selgitama, kuidas tegelikult erinevad protsessid äriettevõttes käivad. On olnud juhtumeid, kus juurutust ostes põrkab ettevõte kokku sellise pealesunnitud olukorraga. See tekitab kliendil põhjendatud küsimuse, kas nii ongi kõigis tarkvara juurutust pakkuvates ettevõtetes.

Tegelikult on selline olukord pigem erand kui reegel. Selleks, et teada saada juba enne lepingu sõlmimist, mis inimestega hakatakse koostööd tegema, on mõistlik küsida teistelt klientidelt juurutaja kommentaare kohta, vaadata kriitilise pilguga üle tarkvara juurutusmeeskonna CVd ja vajadusel paluda kohtumist teie ettevõttes juurutust läbi viima hakkava meeskonnaga.

Enne uue tarkvaralahenduse väljatöötamise kallale asumist tasub mõelda, kas teil on selleks piisav inimressurss. Saamaks teada oma ettevõtte inimeste juurutuse läbiviimiseks vajaminevat aega, on mõistlik võtta laias laastus aluseks juurutaja poolt esitatud projektile kuluv tunnimaht ja arvestada, et oma inimeste töömaht on sama suur. Iga konkreetse projekti põhiselt võib see ka natukene erineda.

Täpse nägemuse kliendipoolsete töötajate ressursi osas oskab oma kogemustele toetudes öelda ka juurutaja. Tähtis on, et projekti planeerides võetakse arvesse töötajate puhkusi, võimalikke (pikalt ette teada olevaid) komandeeringuid, koolitusi jms.

Kuna juurutusprojekt on kahe meeskonna vaheline tihe koostöö, kus mõlemal on võrdse tähtsusega roll projekti edukal läbiviimisel, siis ühe võtmeisiku puudumine projekti mõnes etapis võib mõjutada kogu projekti kulgu.

Iga projekti edukal läbiviimisel on kaks osapoolt - tellija ning juurutaja. Hetkel valitseb vähemalt majandustarkvara turul olukord, kus uue tarkvaralahenduse tellijaid või olemasolevale tarkvarale täienduste soovijaid on nii palju, et juurutajad ei jõua kõiki klientide soovitud lahendusi koheselt ellu viima hakata.

Eestis pole erandlik, et juurutaja pakub tähtajaks, millal ta saab töödega alustada, kuupäeva alles kolme või nelja kuu pärast.

Samas on viimasel ajal olnud ka palju juhtumeid, kus juba olemasolevad juurutusprojektid kipuvad venima juurutaja ressursipuuduse tõttu. Selline olukord tekitab klientide seas loomulikult meelepaha.

Juurutajapoolset ressursipuudust on tarkvaralahendust hankima hakkaval ettevõttel raske hinnata. Lähtuda saab ainult infost ja lubadustest, mis saadakse juurutajalt ning lisateabest, mis koguneb juurutaja teiste klientide võtmeisikutega suheldes.

Alati tasub küsida juurutajalt nimeliselt projektile kinnitatud meeskonda ja nende üheaegsete projektide arvu. Ära ei tohi unustada, et lepingusse oleksid vastava riski maandamiseks ka adekvaatsed sanktsioonid sisse kirjutatud.

Tarkvara juurutusprojekte planeerides tuleb kindlasti üle vaadata tellijapoolsete projekti võtmeisikute ajaressurss. Vaevalt on ettevõttes inimesi, kes on koormatud 50%. Tarkvaraprojekti läbiviimine on kõigile töötajaile lisatöö.

Oma projektide läbiviimisel oleme näinud erinevaid inimressursi ja motivatsiooni süsteeme. Mõnes on mängitud ümber ajutiselt mõne võtmeisiku töökohustused, teises on välja töötatud konkreetne motivatsioonisüsteem projekti etappide ja/või kogu projekti õigeaegse läbiviimise osas.

Paljud ettevõtted on kõigele sellele mõelnud ja olenemata oma suurenenud töömahust tunnevad selliste firmade töötajad, et on motiveeritud ning osalised mingis uues ja tähtsas ettevõtmises.

Kuid on ka selliseid ettevõtteid, kus mainitud teemale tähelepanu ei pöörata. Viimasel juhul on aga väga raske head tulemust oodata. Ei tasu unustada, et projekt on edukas ainult siis, kui kõik osapooled on rahul.

Enne uue tarkvaralahenduse juurutama hakkamist peaksid ettevõtte siseprotseduurid olema paigas. Disainietapi - ettevõtte protsesside ja tegevuste kirjeldamine vastavalt tulevasele tarkvarale - käigus võivad praegused protsessid uut tarkvara ja selle võimalusi nähes muutuda.

Vähim, mis peab enne juurutamist olema tehtud, on kogu ettevõtte tarbeks kokku lepitud, kuidas uues situatsioonis (uue tarkvaralise lahenduse olemasolul) käituda ja seda ka töötajatele selgitatud.

Pole võimalik alustada juurutamisega ja samal ajal hakata kõiki ettevõttes toimuvaid protsesse ümber kujundama. Projektist võib saada kaos, kui nädal tagasi kokku lepitud protsessid enam ei kehti ja kogu töö tuleb ümber teha.

Selline tegevus võib muuta suuresti juurutustööde mahtu, tekitades töötajates segadust ning edasi lükata projekti valmimise lõpptähtaega.

Autor: Piret Kuhlbars