Kako pravilno planirati ERP projekt

Po definiciji svaki je projekt jedinstven, a to znači – različit. Projekti se dijele po veličini, cijeni koštanja, trajanju, rizicima i slično, no najvažnije je – po kompleksnosti. Uvođenje ERP-a u neku firmu je vrlo kompleksan projekt, te je njegov uspjeh ovisan o pravilnom planiranju. Prva faza planiranja je – snimka postojećeg stanja. Ovdje ne mislim na postojeće procese u pojedinim poslovnim granama (nabava, prodaja, financije i računovodstvo), nego postojeće stanje ERP-a.

U današnje vrijeme implementator softvera će vrlo rijetko imati sreću da kupac nema nikakav softver koji on zove ERP. Bilo da ima prastari sustav pisan u DOS-u, neki lokalni softver ili da se vodi poslovanje u excelu, naručitelj je navikao na rad s tim sustavom, baš na takav način. Ovdje implementator mora provesti s svaki odjelom neko vrijeme da vidi kakav je to softver, što on može, te da skupi sve informacije od naručitelja na način da se detaljno popiše s čim je naručitelj zadovoljan (kojim funkcionalnostima), s čime nije zadovoljan (postojeće funkcionalnosti koje ne rade kako naručitelj želi) i što naručitelju nedostaje (koje funkcionalnosti bi želio, a ne postoje) i to je tzv. GAP analiza. Evo jedan primjer. Naručitelj ERP-a izdaje račune kupcu na način da na njih stavlja i robu i usluge. Sadašnji softver mu ne daje direktan uvid u skladište (tj. zalihu robe), već se to radi indirektno, da mora stalno gledati u neki drugi ekran (ako i to). Naručitelj to želi promijeniti. Tu je potrebno jasno definirati što bi točno želio vidjeti na pojedinom artiklu. Da li samo stanje skladišta? Ili možda i nabavne cijene? A što ako želi vidjeti i trenutnu maržu koju ostvaruje na tom specifičnom artiklu, baš na tom računu?

Kada je ova faza planiranja gotova, slijedi faza planiranja implementacije. Naravno, da ovo izgleda čudno, i da se sada, dok ovo čitate, pitate: „Pa kako faza implementacije, a tek smo napravili GAP analizu?“. Ovdje se ne misli na fazu implementacije gotovog ERP-a nego na planiranje implementacije modula po prioritetima. Nikad, ali nikad ne planirajte tzv. „big bang“, odnosno ne planirajte isporuku ERP-a odjednom. Vrlo često sam vidio da ERP projekti nisu uspjeli samo zato jer su u istom periodu implementatori pokušali postaviti i nabavu i prodaju i proizvodnju i financije i plaće i …. To se tako ne radi! Potrebno je s naručiteljem dogovoriti što se radi prvo, što drugo, a što ima najmanji prioritet. Kada je ova faza gotova kreće faza koja uzima najviše vremena i truda, a koja je krucijalna za uspjeh projekta. To je snimka pojedinog modula (npr. nabave ili prodaje) i svih funkcionalnosti. Tu je potrebno za svaki modul dobiti detaljan opis svake funkcionalnosti unutar modula i, što se vrlo često zaboravlja, povezanosti s drugim modulima u budućnosti. Vrlo često se implementator fokusira samo na modul koji će se isporučiti ne gledajući s čim on mora biti povezan u budućnosti, pa kod povezivanja dvaju ili više modula ima velike probleme, što uzrokuje povećanim vremenom na projektu, a time i troškovima, koje je vrlo često nemoguće naplatiti, a uvijek rezultira nezadovoljstvom naručitelja.

Ovdje je potrebno također napraviti još jednu GAP analizu. Koji god ERP implementirali uvijek postoje dorade. U tom smislu, prilikom snimke funkcionalnosti pojedinog modula morate ustanoviti: ima li to novi ERP baš tako kako naručitelj traži, ima li to novi ERP ali napravljeno na drugačiji način ili ta funkcionalnost u novom ERP-u uopće ne postoji. Da bi ovo razjasnili, ako smatrate / znate da funkcionalnost postoji, ili postoji ali na drugačiji način nego naručitelj traži, obavezno pokažite to naručitelju i to prilikom snimanja stanja. Vrlo sam često u svojoj praksi doživio da implementator kaže naručitelj: „to postoji!“ i uvjeren je da je time završio. No prilikom implementacije, naručitelj kaže: „Hmm da, ali mi nismo mislili tako!“. Evo i primjera iz realnog života. Kolegica je radila na snimki stanja kod naručitelja i napisala je: „Naručitelj radi reverse. Budući da naš ERP to pokriva, nisu potrebne dorade.“. Da, u našem ERP-u postoji funkcionalnost reversa. Pitao sam kolegicu: „Jesi li ih pitala na koji način rade revers, tj. je li mu naš način prihvatljiv?“. Odgovor je bio: „Nisam, ali puno sam puta radila reverse i to je sigurno ono što i oni trebaju!“. Kada bi sada morao opisati što je taj naručitelj smatrao reversom ne bi bilo mjesta za niti jedan drugi članak u ovom izdanju magazina. Ukratko, reverse smo morali napisati ispočetka jer bez njih je cijeli ERP (dakle ne samo određeni modul u kojem su reversi) bio – neprihvatljiv.

Kada ste skupili sve zahtjeve tj. funkcionalnosti za pojedini modul, napravite dokument. Da li se on zove „Specifikacija funkcionalnosti“, „Popis zahtjeva za nabavu“ ili nekako drugačije, nije važno. Ovdje pazite da ne upadnete u zamku, na način da taj dokument sadrži samo riječi. Mora sadržavati i slike ekrana koje će naručitelj dobiti i koristiti. Jedno je napisati: „Na svakoj stavci nabavnog nalog unosit će se rabat“, a drugo je kada i prikažete ekran, jer tada naručitelj ima priliku vidjeti ne samo da će to moći, nego i kako će to moći! I sad je trenutak da se postojeće funkcionalnosti prezentiraju svima. I da se jasno i glasno pokaže kako će se raditi u budućnosti. Upamtite da u ovom slučaju implementator mora biti nepopustljiv prema naručitelju. Iako to izgleda neprofesionalno, upravo je suprotno. Naručitelj je tražio određene funkcionalnosti, te jednostavnost upotrebe (što gotovo svi ERP-ovi imaju). No, vrlo često, želi da to radi na isti način kao stari ERP (na primjer, želim za ovo koristiti tipku F3, a ne kombinaciju ALT+F5).

S naručiteljem na početku planiranja treba jasno komunicirati dvije stvari: prvo, da je novi ERP bolji (zato ga i naručuje) i drugo, da je novi ERP – drugačiji (pa će trebati određeno vrijeme prilagodbe). To, drugim riječima znači: „Novi ERP nije i ne smije biti prepisani stari“. Sada je potrebno jasno definirati hoće li se, kako, u kojem formatu i koji podaci prenositi iz starog ERP-a u novi. I tu treba biti jasan: niti će se moći prenijeti svi podaci, niti će prijenos onih koje je moguće prenijeti biti jednostavan. A kako doći do tih podataka. Ako stari ERP omogućuje prijenos na neki prihvatljiv način, onda je to moguće, a ako ne onda postoje dvije solucije: stari implementator mora napraviti neki prihvatljiv format i eksportirati podatke u njega (ako želi) ili će se sve morati ručno unijeti. Naručitelj mora biti svjestan da je on i isključivo i samo on odgovoran za ažurnost i točnost podataka koje se prenose, a implementator je odgovoran za prilagodbu i import tih podataka u novi sustav. Naravno, ako su za novi sustav potrebni neki dodatni podaci ili u drukčijem formatu (a gotovo uvijek jesu), onda implementator mora omogućiti unos tih podataka u template za import.

Sada je vrijeme za definiranje vremenskog slijeda, odnosno kada će se što raditi. Naravno, za to je uvije potrebno ostaviti rezervu (tzv. contigency reserves) za rizike. Nikad nemojte zaboraviti u vremenski plan ubaciti i demonstracije napravljenog dijela ERP-a. I to po principu – što češće to bolje. Naime, fatalna je pogreška napraviti vremenski plan gdje će naručitelj vidjeti modul na kraju. Tada je vrlo kasno, skupo i vremenski zahtjevno skupiti sve primjedbe. Da bi se to umanjilo (govorim o primjedbama i promjenama već dogovorenog), potrebno je čim je implementator neki dio napravio, ma kako mali bi, dati ga naručitelju da ga vidi i da ga proba koristiti. Time implementatore dobiva dvije velike prednosti. Prva je, da vrlo rano vidi da li su zahtjevi koji su bili definirani stvarno i ono što naručitelj treba, a ne što je on mislio da mu treba. Druga je ta da će se naručitelj rano naučiti radu sa softverom i prilagoditi mu se, tako da će kod konačne implementacije već biti familijariziran s njime i lakše će ga koristiti, a samim time i brže biti produktivan.

Vremenski slijed mora sadržavati i planirano vrijeme testiranja cjelokupnog modula prije puštanja u produkciju. Stoga je potrebno imati i testnu okolinu u kojoj se naručitelj može „igrati“, odnosno drugim riječima, isprobavati što sve može ERP i modul koji ste mu stavili na test. Na kraju je potrebno napraviti i plan puštanja u produkciju (nakon finalnog testa slijedi prijenos gore spomenutih podataka). Plan puštanja u produkciju mora obavezno sadržavati i plan obuke (finalni), jer ma koliko naručitelj radio u testnom sustavu, radi svakodnevnih aktivnosti na svom radnom mjestu, potrebno je još jednom napraviti obuku. I, na kraju, potrebno implementator mora planirati resurse tj. konzultante koji će biti kod naručitelja (ne telefonski dostupan, nego na lokaciji), u prvim danim a produkcije kako bi mu olakšao prilagodbu i smanjio pritisak.

Naravno, sve gore napisano nije recept za siguran uspjeh, već samo mali dio onoga što sam u praksi vidio da funkcionira. Ali, i dalje očekujte probleme. A kakav bi projekt bio bez njih?

=====

by Nenad Trajkovski

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s