ERP

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, mida 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, paindlikkus, 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 kindlaid ärilisi eesmärke, 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 suure osa tööajast on meeskonnal võimalik projektiga tegeleda). 

Kasutegur: ERP juurutamist saab läbi viia vaid koostöös tellijaga ja laias laastus kulub tellija spetsialistidel projekti jooksul sama palju ajalist ressurssi kui juurutamise partneril. Kui tellijal – sisemisel projektijuhil, peakasutajatel, tavakasutajatel – pole projekti jaoks piisavalt ajaressurssi, jäävad olulised küsimused vastusteta ja projekt hakkab venima, läheb üle eelarve või 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 täpsusta IT-alased nõuded 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 erinevat ettevõtet 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 ERP lahenduse juurutamiseks; 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 ERP tarkvara juurutamiseks, mis võimaldab planeerida ja kontrollida juurutamise tegevusi. 
Kogemus – edukate juurutamiste portfell: millistest ettevõtetes on sarnast lahendust edukalt juurutatud ning millised on olnud tulemused; võimalusel edukate ERP lahenduse juurutamise näidetega ettevõtete külastamine. 
Dokumentatsioon – millist dokumentatsiooni teenuse pakkuja pakub/tarnib ERP tarkvara juurutamise käigus ning selle lõpus.