Milline on parim meetod ERP juurutamiseks?
Autor: Maarika Helstin, BCS Itera kvaliteedi- ja metodoloogiajuht
PROJEKTI TELLIJA HUVI ON UUS ERP LAHENDUS TÖÖLE SAADA VÕIMALIKULT KIIRESTI JA ODAVALT. LISAKS PEAB LAHENDUS TOETAMA MAKSIMAALSELT ETTEVÕTTE STRATEEGILISTE EESMÄRKIDE ELLUVIIMIST.
Edukaks juurutuseks tuleb keskenduda õigete tegevuste planeerimisele, nende elluviimisele ja kontrollile. Tarkvara juurutamise meetodid on tegevuste poolest üsna sarnased – planeeri, disaini, arenda, testi ja juuruta. Erinevus tuleneb eelkõige järgmistest punktidest:
- tegevuste järjekorrast;
- kommunikatsiooni viisist;
- dokumenteerimise nõuetest;
- prioriteetide ümberhindamise paindlikkusest.
Kõige levinumad ERP tarkvara juurutamise meetodid on agile ja waterfall. Waterfall on lineaarne meetod, mille kohaselt kõik etapid ja nende tegevused läbitakse järkjärgult. Näiteks, arendustegevustega võib alustada alles siis, kui kogu disain on kinnitatud. Vastanduseks agiilse meetodi puhul saab klient lahenduse kätte osade kaupa ehk iteratsioonidena.
Mõlemal meetodil on oma plussid ja miinused, millega tuleb arvestada. Kõige olulisemateks teguriteks on juurutusmeetodi valiku puhul aeg ja raha. ERP juurutusprojekti panustab projekti tellija vähemalt sama palju aega kui teostaja.
| Eelised | Piirangud | ||
| Agiilne |
· Sobivaima funktsionaalsusega lahendus – klient saab vajadusel lahenduse suunda muuta. · Paindlik prioriteetide ümberhindamine – ärivajaduste prioriteete saab muuta. · Kiire – ajakava on lühem ja töö intensiivsem. |
· Eelarve ei ole teada, kuna juurutustööde maht selgub töö käigus. · Põhjaliku dokumentatsiooni puudumine. · Tellija projekti liikmetel ei ole igapäeva töö kõrvalt piisavalt aega projektiga tegeleda. |
|
| Lineaarne |
· Eelarve on fikseeritud ja ette teada. · Põhjalikult ette planeeritud tegevuskava. · Tellija töömaht projektiga tegelemiseks on hajutatud pikema aja peale. · Põhjalik dokumentatsioon. |
· Juurutus kestab kauem. · Lahenduse disaini ei saa arendustööde käigus muuta. · Lahenduse lõpliku disaini väljatöötamine on keeruline. · Tellija võib saada ülevaate lõplikust lahendusest alles projekti lõpus. |
|
ERP projekti kestvus ja maht sõltub ettevõtte suurusest ja äriprotsesside keerukusest. Majandustarkvara juurutamiseks tuleb valida meetod, mille ROI on kõige kõrgem. Kui juurutamise aeg läheb liiga pikaks, siis ei pruugi oodatavat tuluefekti saavutada.
Tellija panus projekti
Uue ERP tarkvara juurutamisel tuleb korrastada olemasolevaid äriprotsesse, andmeid ette valmistada, testida ja muudatused ellu viia. Need on vaid mõned tegevused, millesse tellijad oma aega investeerivad. Enne projekti algust on vaja välja arvestada, millises ulatuses ollakse valmis oma igapäevasest tööajast panustama juurutusprojekti. Kas see on 75% või 25% – sellest sõltub projekti kestvus. Agiilse meetodi puhul on töö intensiivsus suurem ja tulemus saavutatakse kiiremini. Lineaarse meetodi puhul saab töid hajutada pikema aja peale.
Muutuvad vajadused
Kiiresti areneva ja muutuva äri puhul sobib paremini agiilne meetod, kuna prioriteete on võimalik paindlikult muuta. Arendusvajaduste nimekirja vaadatakse regulaarselt üle ja muudetakse hetkevajadustest lähtuvalt. Samuti, kui ei ole täpselt teada, milline tulevane lahendus peaks olema, siis ei ole võimalik lõpplikku disaini enne arendustööde algust kokku saada.
Projekti eelarve
Suurimaks mõjutajaks juurutusmeetodi valiku puhul on BCS Itera praktikast tulenevalt projekti eelarve st tulenevad piirangud. Agiilse projekti puhul toimub tööde arveldamine time and material põhimõtte järgi, kus kogu investeeringu summa selgub projekti lõppedes. Kuid ettevõtted planeerivad IT investeeringuid pikaajaliselt ette ja piirid tulenevad fikseeritud eelarvest. Lineaarse meetodi puhul saab teha valiku, millised arendused teostatakse ja millised ärivajadused lahendatakse toote standardvõimalusi kasutades. Valiku tegemiseks tuleb disain ja lõplik arenduste nimekiri kokku saada enne arenduste teostamist ja valik tehakse ette antud projekti eelarvest lähtuvalt.
Dokumentatsioon
Põhjaliku dokumentatsiooni puudumine seab projektile suure riski. Näiteks, kui keegi projekti meeskonna liikmetest peaks vahetuma, siis uuel inimesel ei ole võimalik saada detailset ülevaadet sellest, mis projektis on eelnevalt tehtud või kokku lepitud. Lineaarse meetodi puhul on dokumentatsioonile pandud suurem rõhk ning hästi dokumenteeritud lahendus on suureks kokkuhoiu kohaks tulevaste jätkuprojektide elluviimisel. BCS Itera kasutab oma projektides Microsofti poolt väljatöötatud Dynamics tootepere juurutamise metodoloogiat nimega Sure Step, mis annab võimaluse valida erinevate meetodite vahel.
| Protsess | Sobi kui: | |
| Agiilne (Agile) |
· Analüüs · Mitmed tsüklid – disain, arendus ja testimine. · Käivitamine
|
Ø Eelarve ei ole fikseeritud. Ø Äriprotsessid on kiiresti muutuvad. Ø Projekti meeskonna liikmed saavad piisavalt panustada oma aega. Ø Oodatakse kiiret tulemust. Ø Lahenduse ärivajadusi ei ole projekti alguses võimalik kindlaks määrata. Ø Protsess on keeruline ja arenduste maht suur. Ø Projektis osaleb rohkem kui kaks osapoolt (näiteks liidestamine kolmanda osapoole lahendustega). Ø Põhjalikku dokumentatsiooni ei ole vaja. |
| Lineaarne (Waterfall) |
· Analüüs · Disain · Arendus ja testimine · Käivitamine
|
Ø Eelarve on fikseeritud. Ø Arenduste maht on keskmine või suur. Ø Ärivajadused on keerulised, kuid ette teada. Ø Kliendipoolsed projekti liikmed ei saa igapäeva töö kõrvalt korraga panustada palju aega. |
| Kiire (Rapid) |
· Analüüs · Disain · Seadistuste lõpetamine · Käivitamine
|
Ø Kasutajate arv on 1-25. Ø Äriprotsess on lihtne ja neid ei kaardistata. Ø Arendusvajadus on minimaalne. Ø Andmemaht on väike. Ø Tegemist on alustava või alles alustanud ettevõttega (alla 2 aasta). |
Meetodite kombineerimine
Kuna tegelik elu ei ole alati nii must-valge, siis on võimalik omavahel erinevaid meetodeid kombineerida. Näiteks, kasutada juurutamise põhiosas lineaarset juurutamise meetodit ja keerulisem osa protsessist, teha agiilset meetodit kasutades. Lisaks tuleb ette seda, et programmi standardis vajalik lahendus üldse puudub ja on vaja arendada täiesti uus funktsionaalsus, siis on kõige mõistlikum alustada lahenduse väljatöötamist nn prototüübi abil.
Alati alustada analüüsist
Olenemata juurutuse meetodist, tuleb igal juhul alustada põhjalikust analüüsist, mille käigus selgitatakse välja hetkeolukord ja tuleviku ootused. Selle info põhjal saab otsustada, millised peaksid olema järgmised sammud.
Skoop elik projekti ulatus
Olenemata meetodist tuleb alati jälgida, et projekt püsiks kokku lepitud skoobis. See tähendab, et tegeletakse ainult kokku lepitud lahenduse piirides. Kui skoopi ei järgita, siis tulemuseks on see, et projekt lõpptähtaeg lükkub edasi või eelarve mahtudest minnakse üle.
Kokkuvõttes, milline on parim meetod?
Pole ühest vastust, milline meetod on õige või vale. Igal protsessil on omad probleemid ja otsus tuleb teha lähtuvalt olukorrast ning võimalustest. Lõplik valik tehakse meeskonna koostööna. Projekti tellija vaatab üle oma võimalused ja teostaja saab vastavalt sellele anda oma soovitused ning selgitada valikuga kaasnevaid riske. Oluline on see, et ERP-i juurutamisel kasutatakse kindlat ja kokku lepitud metodoloogiat ning parimat praktikat, millega teostaja on eelnevates projektides kokku puutunud. Halb on see, kui projektis puuduvad eesmärgid ja tegevusplaan nende saavutamiseks.