Millised on levinumad ERP süsteemid ja kuidas valida nende seast just teie ärile sobiv? Kuidas aru saada, kes oleks hea juurutuspartner? Ja kuidas ületada vastuseisu, mida suured muudatused organisatsioonis sageli esile kutsuvad?

Neid ja teisi küsimusi lahkavad järgnevas loos Fujitsu Estonia digitransformatsiooni valdkonna juht Ingrid Joost ja Thermory IT-juht Julia Ležeiko.

Julia

ERP ehk Enterprise Resource Planning tarkvara koondab endasse ettevõtte paljude äriprotsesside haldamise nii, et see kõik on seotud finantsiga. See on ühtlasi ka ettevõtte finantstarkvara.

Iga äritarkvara ei ole ERP – on olemas kindla protsessi või ärivaldkonna jaoks mõeldud lahendused, mis tegelevad detailselt just selle konkreetse valdkonna vajadustega.

Kui tuua näiteid Fujitsu portfooliost, siis Persona on just personalitööks mõeldud tarkvara ning keskendub personaliga seotud protsessidele.

Microsofti D365 Business Central on samas ERP lahendus, mis tegeleb nii ostu, müügi, lao kui logistikaga ja sealjuures ka finantsiga.

Ingrid

Kõige vanem ERP maailmas on SAP, mis loodi juba 1972. aastal. See on praeguseni maailmas kõige võimsam ERP süsteem.

Selle kõrval teine suur ja võimas on Oracle Netsuite.

Kaks Microsofti tarkvara on veidi väiksemad. Endise Axapta (AX) nüüdne nimetus on Dynamics365 Finance & Operations. Endise Navisioni (NAVi) nimi on nüüd Dynamics 365 Business Central.

Eesti turul esindaud ka Epicor ja Monitor.

Uue põlvkonna tarkvarad on juba avatud lähtekoodiga, üks selline näiteks on Odoo.

Nende kõigi jaoks on Eestis tugi olemas, maailmas on aga variante veel väga palju rohkem.

Eestis on arendatud ka oma ERP tarkvara, MRP-Easy, mis on standardtoode väikestele ettevõtetele.

Ingrid:

Viimase kümnekonna aasta jooksul on see seis väga palju paremaks muutunud. Enamusel suurtest kindlasti on, keskmise suurusega ettevõtetest kasutavad ERPi umbes 2/3.

Väikeste puhul ei ole see nii levinud ja üks põhjus on, et nd ei leia sobivat lahendust – olemasolevad on neile liiga kallid või võimsad. Kasutatakse küll Eestis arendatud veebipõhist  MRP-Easy´t, mille miinuseks on, et sinna ei saa teha lisaarendusi. Aga tean mitmeid tublisid väikesi ettevõtted, kes on selle suurepäraselt kasutusele võtnud.

Ingrid

See on alati keeruline küsimus.

Mistahes tarkvara juurutamisel on esimene asi vaadata üle oma äriprotsessid ja mõista, millised on selle ärivaldkonna parimad võimalikud protsessid. Neid konkreetse ERP tarkvara standardprotsessidega kõrvutades selgub, kui palju teie parim võimalik äriprotsess erineb ERP tarkvara standardprotsessist.

Kui need on enam-vähem ligilähedased või vaid väikeste nüanssidega, siis kindlasti on mõistlik võtta see ERP koos nende kohendustega. ERPi arendamine teie protsesside järgi on tavaliselt samuti võimalik, kui see on äriliselt põhjendatud nõudmine.

Oma protsessidele vastavate eraldi tarkvarade otsimine ja nende liidestamine toob kaasa riskid, millele peab mõtlema. Mida rohkem on integratsioone, seda suuremad on ettevõtte ärisüsteemi riskid. Iga liides võib mingil hetkel katkeda, näiteks süsteemide uuenduse käigus või mis tahes põhjustel.

Ettevõtte siseselt peab eraldama ressursi tarkvara haldamiseks. Kaaluge, kas see võimekus on teil olemas.

Julia

Mitme erineva tarkvara liidestamisel tuleb juba juurutuse ajal mõelda ka kasutaja vaatepunktile. Ühe kasutaja jaoks on mitmes süsteemis töötamine ebamugav. Korduv sisselogimine, ühest süsteemist teise hüppamine ja katkendlik töövoog tekitab palju probleeme.  Lõpuks ei pruugi see lähenemine igale ettevõttele sobilik olla.

Julia

On kaks erinevat strateegiat ettevõtte ärilahenduste ökosüsteemi ehitamiseks.

Ühe suure ERPi lähenemist nimetatakse Single ERP Strategy – strateegia, kus kõik protsessid paigutatakse ühe lahenduse sisse. Seda teed lähevad ettevõtted, kelle protsessid on suhteliselt standardsed ja kes ei soovi mitmeid erinevaid tarkvarasid omavahel integreerida. Sageli ei ole neil ettevõtetel ka tehnilist võimekust keeruliste ärilahenduste ökosüsteemi haldamiseks.

Teine variant on kombineerida mitut lahendust, mis on valdkonnale spetsiifilised ehk best-of-breed (oma valdkonna parim) ning mõeldud konkreetse protsessi jaoks. Neid tasub rakendada valdkondades, mis on äri seisukohast kõige olulisemad ja loovad konkurentsieelist. Need tuleb siis liidestada keskse finantstarkvaraga ja vajadusel ka omavahel.

Best-of-breed lähenemine on tööjõumahukam, ühtse ERPi puhul on vähem tehnilist tööd integratsioonidega. Ühtse ERPi valikuprotsess on palju keerulisem, kuigi haldamine on lihtsam. Best-of-breed variandi puhul on samas rohkem aega mõelda, sest esmalt lahendad ühe protsessi ja siis võtad ette järgmise.

Eelistus ühe või teise lähenemise kasuks peab olema väga hoolega läbi mõeldud.

Julia

Siin on üldiselt kolm varianti lähenemiseks.

Võib appi kutsuda ERPi juurutajad ja paluda neilt konsultatsiooni uute protsesside disainimisel. Selle käigus saavad nad juba natuke mõelda konkreetse ERPi võimalustele. Siin on aga üks oht:  isegi kui antud ERP ei sobi sellele ettevõttele, valmib analüüs ja protsessi disain siiski veidi kallutatuna selle konkreetse ERPi loogika ja terminoloogia poole.

Sel põhjusel eelistaks ma teist varinati ehk sõltumatut ärikonsultanti, kes ei lähtu üldse kindla tarkvara taksonoomiast ja ülesehitusest. Ta teeb  ettepanekuid protsesside optimeerimiseks vastavalt just ettevõtte tulevikuplaanidele. Soovitan sellise planeerimise ja disainimise juures alati mõelda, milline on teie ideaalne tulevane protsess, mitte tänane kitsaskoht. Ehk siis mida me soovime näha kahe aasta pärast.

Kolmas variant on teha seda majasiseselt. Kui organisatsioon on piisavalt suur ja majas on kompetentsi, siis targad pead istuvad koos ja panevad uue protsessi disaini kirja. Leitakse optimeerimiskohad ja digitaliseerimise võimalused ja selle teekaardi järgi hakataksegi ERPi valima.

Ingrid

Kui me räägime sellisest lahendusest, mis hõlmab ettevõtte kõiki peamisi protsesse – müük, ost, finants, personal, palk, ladu, tootmine, siis peab arvestama vähemalt 1 aastaga. Keerulised ja mahukad juurutused kestavad ka 1,5-2 aastat. Üle kahe aasta läheb projekt juba liiga pikaks ja hakkab venima.

Aeg sõltub ka sellest, kuivõrd ettevõtte põhiprotsessid vastavad tarkvara standardfunktsionaalsusele. Kui need on enam-vähem vastavuses, siis tuleb teha vähem arendusi ning saab kiiremini juurutada.

Veel sõltub juurutuse pikkus sellest, kui palju soovitakse liidestusi teiste tarkvaradega. Iga liides on eraldi arendus, mis võtab aega.

Minu praktikas kõige lühem juurutus toimus kolme kuuga. See oli SAP juurutus, kus kasutusel olid kõik moodulid. Sai tehtud, aga see oli hullumeelne ja väga stressirohke. Veel olen poole aastaga teinud Microsofti Axapta juurutuse ja see oli samuti väga raske protsess. Midagi sellist ma kellelegi ei soovita.

Julia

Ärge piirduge valikut tehes vaid müügikonsultandiga suhtlemisega, isegi kui teile selles faasis tundub, et tarkvara on igati sobiv. Alati on mõistlik rääkida otse ka nende inimestega, kes tegelikult hakkaksid teie juures juurutust läbi viima. Kui siis tekib hea ja soe kõhutunne – nad räägivad teie keelt ja tunnevad hästi teie ärivaldkonda – siis ma julgeksin selle partneriga jätkata.

See võib kõlada kummaliselt, aga tõesti on kõhutunne oluline ka sellise ratsionaalse tegevuse juures nagu äritarkvara valik. Minu jaoks on see otsustamisel kolmas komponent tarkvara enese sobivuse ja pakkumise suuruse ehk rahakotile vastavuse kõrval.

Ingrid:

Väikesel Eesti turul on võimalik riske vähendada, küsides referentse. Saad neile helistada või kohtuda ja uurida, kuidas selle pakkujaga koostöö kulges. Olen ise valija rollis seda teinud.

Aitab suhtlemine nende ettevõtetega, kus sarnaseid lahendusi on tehtud ja kus äriprotsessid on teie omadega sarnased. Nii leiad kokkupuutepunkte või häid näiteid.

Ingrid

Kindlasti on see probleem. Harjumuste muutmine ongi kõige raskem. Et inimesed võtaksid mis tahes muutusi paremini vastu, on oluline nendest rääkida juba planeerimise faasis. Siis nad teavad, mis on tulemas. Kui inimestel on aega mõttega harjuda ja pikemalt valmistuda, võtavad nad selle lihtsamini omaks.

Julia

Kasutan vastuseisu ületamiseks ratsionaalset lähenemist. Projekti ettevalmistamise käigus pannakse paika standard, kuidas me täpselt hindame uut funktsionaalsust. Näiteks on kolm kriteeriumi: kas see on keerukam kui vana? kas nõuab work-around´e? kas on ebamugav?

Kõik need kriteeriumid peavad olema defineeritud täpselt. Kui keegi ütleb, et talle ei meeldi, siis saab konkreetselt hinnata, milles on probleem. Võib-olla on see tegelikult väga põhjendatud ja seda tulebki käsitleda lisaarendusena. Samuti võib olla, et see koht nõuab protsessi muutmist.

Nii saab vältida liigseid emotsioone ja luua konstruktiivsust ERPi juurutuse projekti meeskonna töös.

Ingrid

Sellised projektid peavad olema realistlikult kavandatud ja planeeritud, arvestades inimeste olemasolevaid tegevusi – kui palju on igapäevaseid tööülesandeid ja kui palju selle kõrvalt on aega tegeleda uue tarkvara õppimise ja juurutmisega.

Ajalise plaani koostamine ja inimeste koormuse planeerimine on hästi oluline. Kui need projektid viiakse läbi väga lühikeses ajaaknas, ilma inimeste ajaressursi planeerimiseta, siis võib see tähendada rohkem stressi ja suuremat vastuseisu.

Kui aga ettevõtte siiski otsustab kiire juurutuse ära teha hoolimata kõigist asjaoludest, siis võib juhtuda, et tarkvara on testimata ja süsteemid ei tööta. Kui näiteks räägime tootmisettevõtetest, siis kaubad võivad jääd välja saatmata, arved tegema. Kaubanduse puhul maksed ei toimi ja nii edasi. Jõuga kiirustamine võib tekitada väga palju kitsaskohti.

Julia

ERPi juurutusel peab väga realistlikult aru andma, et see on näiteks üks aasta, mille jooksul tuleb tegevusi hoolega prioritiseerida. Inimesed ei jõua samal ajal ette võtta muid uusi algatusi nagu tootmise auditit, LEAN-projekt vms. Sel ajal tulebki igale töötajale jätta vaid tema esmane peamine ülesanne.

Siis leiavad inimesed ka aja, et osaleda ERPi töötubades ja rahulikult rääkida sellest, kuidas nad tahavad uues tarkvara lahenduses tööd teha. Siis tekib võimalus lahendusi testida ja on aega koolitusele tulla.

Seega peab ka tarkvara tellija tegema korraliku projektiplaani, mitte ainult juurutuspartner.

Ingrid

Kõige olulisem on, et ettevõtte kõik töötajad, kes tarkvara kasutama hakkavad, saavad aru selle loogikast. Kuidas põhifunktsionaalsused töötavad ja kuidas nad omavahel seotud on? See on vältimatu baas.

Näiteks kui keegi jätab oma lõigus midagi tegemata, siis kuidas mõjutab see teisi? Võibolla järgmine inimene ei saa seetõttu oma tööd teha.

Tihti on nii, et ettevõtted kasutavad suurte ERPide funktsionaalsusest vaid väikest osa. See sõltub ettevõtte tegelikest vajadustest ja ka sellest, kui hästi juurutuspartner on neist vajadustest aru saanud ning osanud neid tarkvaras rakendada.

Näen Eesti turul, et ERPi pakkujatena pöörame siiski väga vähe tähelepanu koolituste tegemisele ja toe pakkumisele. Seda saaks minu arvates paremini teha.

Julia

Kasutajate seas on nii kiiremaid kui aeglasemaid õppijaid. Kui keegi vajab rohkem aega, siis ei saa kuidagi tagant sundida, vaid tulebki toetada. Siin aitab “train-the-trainer” metoodika, kus valdkonniti koolitatakse välja peakasutajad. Need inimesed on edaspidi teistele toeks ja õpetavad omakorda kolleege.

Tavaliselt ei koolita juurutuspartner ise kõiki lõppkasutajaid. Küll aga õpetatakse kasutama nii tarkvara looja kui juurutuspartneri poolt koostatud juhendmaterjale.

Lugu on koostatud Äripäeva raadio saates “Digipööre kaubanduses ja tööstuses” eetris olnud intervjuu põhjal.
45-minutilist saadet saad kuulata Äripäeva Raadio veebikanalil. 

Uued postitused meie blogis