Digitugi

Määra ERP juurutamise ulatus/skoop – milliseid protsesse ja/või funktsioone (näiteks, müük, ost, planeerimine, ladu, tootmine, finants, personalijuhtimine, hooldus jne.) soovitakse ERP tarkvara abil digitaliseerida ja/või automatiseerida. 

Kasutegur: Ilma selleta puudub võimalus hinnata projekti maksumust, mis on oluline nüanss projekti juures. Kui ulatus on puudu, on ebaselge ja on mitmeti tõlgendatav, saadakse hinnapakkumised, mis on raske üksteisega võrrelda ja see võib viia vale otsuseni. 

Nimeta ERP juurutamise mõõdetavad ärilised eesmärgid – millised on konkurentsivõime näitajad (toodete/teenuste kvaliteet, tarnekiirus, tarnekindlus, paindlikus, omahind) peavad muutuma paremaks ning kuidas seda mõõdetakse. 

Kasutegur: mis tahes investeering peab ennast mõistliku aja jooksul ära tasuma. ERP tarkvara investeerigu tasuvust on keeruline mõõta, samas seades kindlad ärilised eesmärgid on see siiski võimalik ja väärib läbi mõtlemist.  

Loo ERP juurutamise projekti struktuur – juhtivkomitee (STECO), projektijuht, projektimeeskond ja võtmekasutajad ehk valdkonna juhid. 

Kasutegur: ERP juurutus on pigem äriprojekt kui IT projekt, mille käigus sageli muutuvad ka ettevõtte äriprotsessid. Selliste muudatuste läbiviimiseks peab olema tellijal hästi toimiv ja piisavate volitustega motiveeritud projekti organisatsioon.  

Planeeri ERP juurutamise projekti ressursid – milline on projekti eelarve, ajaline horisont (millal peab olema ERP juurutatud) ning millised ajalised ressursid on olemas projekti meeskonnal (kui suur osa tööajast meeskonnal on võimalik tegeleda projektiga). 

Kasutegur: ERP juurutust saab läbi viia vaid koostöös tellijaga ja laias laastus kulub tellija spetsialistidel projekti jooksul sama palju ajalist ressurssi, kui juurutus partneril. Kui tellijal – sisemisel projekti juhil, peakasutajatel, tavakasutajatel – on puudu projekti jaoks piisavalt ajaressurssi, jäävad olulised küsimused vastusteta ja projekt hakkab venima, läheb üle eelarve ja sageli katkeb sootuks. 

Loo ERP juurutamise projektiplaan ning esmane ajakava – millised on peamised projekti teostamise sammud ning milline on ajakava. 

Kasutegur: projekti alguses on vaja kokku leppida konkreetsed sammud ja “verstapostid”, mille abil saab kontrollida projekti edenemist. Need “verstapostid” peavad olema tellijale üle antavad tulemid, mille kvaliteeti saab tellija kontrollida – näiteks tootmisprotsessi toimiv ja dokumenteeritud prototüüp. 

Kirjelda hetkeolukorra protsesse (AS-IS protsessid) – kuidas ettevõtte toimib praegu. Protsesside kirjeldamise metoodika (tekst, visuaalsed voodiagrammid või nende kombinatsioon), ulatus ja sügavus sõltuvad ERP juurutamise ulatusest. 

Analüüsi tulevasi protsesse ning määra ERP tarvara funktsionaalsed nõuded – mida ja kuidas ERP süsteem peab tegema ettevõtte protsessides. Tulemusena valmib FRD (Functional Requirements Document). 

Määra mitte-funktsionaalsete (tehniliste) ERP tarkvara nõuded – milline ERP süsteem peab olema ehk tuleb täpsustada IT-alaseid nõudeid tarkvara projekteerimiseks. 

Võrdle omavahel erinevaid lahendusi:

Tehnoloogia – milline on ERP lahenduse baastehnoloogia, millal on seda muudetud/uuendatud ning millised on tehnoloogia arendamise plaanid. 
Funktsionaalsus – millist funktsionaalsust erinevad ERP lahendused pakkuvad ning kuidas see sobib ettevõtte funktsionaalsete nõuetega. 
Integratsioon – millised võimalused on integreerimiseks teiste tarkvaraliste lahendustega. 
Maksumus – ERP lahenduse soetamise ja juurutamise maksumus. 
Ülalpidamise kulud – ERP lahenduse versioonide uuendamise ja/või muutmise kulud; hilisemate lisaarenduste maksumused ja lihtsus. 
Riskianalüüs – millised riskid (sh. turvariskid) võivad mõjutada tarkvara kasutamist ja millised on nende riskide võimalikud tagajärjed. 
Sama lahenduse partnerite arv – kui mitu erinevad ettevõtete pakuvad sama lahendust kohalikul turul. Ainult ühe partneri olemasolu tekitab niinimetatud “tarnija lõksu”, kus soovi või vajaduse korral puudub võimalust minna teise partneri juurde, kes pakub sama lahendust. 

Erinevate ERP lahenduste pakkujaid saab võrrelda järgmiste kriteeriumide alusel: 

Ettevõtte – kui pikalt on lahenduse pakkuja tegutsenud ning millised on edasised äriplaanid 
Meeskond – pakkuja ressursi piisavus viia läbi ERP lahenduse juurutamine; meeskonna asukoht ning võime suhelda eesti keeles; hilisema kasutajatoe meeskond ning võime suhelda eesti keeles. 
Metodoloogia – kas on olemas ning millist metodoloogiat kasutatakse ERP lahenduse juurutamisel. Teiste sõnadega, kas teenuse pakkujal on olemas standardne teekond ER tarkvara juurutamiseks, mis võimaldab planeerida ja kontrollida juurutamise tegevusi. 
Kogemus – edukate juurutamise portfell: millistest ettevõtetes on sarnast lahendust edukalt juurutatud ning millised on olnud tulemused; võimalusel, edukate ERP lahenduse juurutamise näidete külastamine. 
Dokumentatsioon – millist dokumentatsiooni teenuse pakkuja pakub/tarnib ERP tarkvara juurutamise käigus ning selle lõpus.