Izvediv ERP roadmap počinje jasnom mapom stvarnog rada, ne popisom željenih funkcionalnosti. Tim najprije treba utvrditi tok procesa, podatke, iznimke, odgovornosti i integracije. Zatim nalaze prevodi u ciljno stanje procesa, ovisnosti i faze provedbe. Dobar plan ERP modernizacije odvaja korekcije s neposrednim učinkom od promjena koje traže novi model podataka, integraciju ili promjenu odgovornosti.
ERP roadmap služi donošenju odluka o redoslijedu provedbe. Treba odgovoriti na nekoliko praktičnih pitanja:
Bez tih odgovora roadmap često postaje niz tehničkih aktivnosti: migracija, konfiguracija, razvoj, testiranje. Takav plan može biti detaljan, a ipak ne rješavati uzrok problema. Ako primjerice prodaja unosi podatke pod različitim pravilima, brži prijenos narudžbi u proizvodnju samo ubrzava prijenos nedosljednih podataka.
Svrha mape sadašnjeg i ciljnog stanja nije dokazati kako ljudi rade pogrešno. Svrha je opisati stvarni rad, uključujući prečace koji održavaju poslovanje, te odlučiti koje od njih treba zadržati, standardizirati ili ukloniti.
Početna mapa treba pratiti radni tok od okidača do završetka, a ne organizacijski dijagram. Za proces nabave to može početi potrebom za materijalom, nastaviti se zahtjevom, odobrenjem, narudžbenicom, primitkom, računom i evidentiranjem obveze. Za proizvodnju tok može obuhvatiti planiranje, izdavanje materijala, prijavu rada, kontrolu kvalitete, skladišno kretanje i obračun.
Za svaki korak zabilježite:
Važno je razlikovati propisani proces od stvarnog procesa. Uputa može navoditi unos narudžbe u ERP, dok komercijalist prije toga vodi dogovor u e-pošti, tablici ili drugom sustavu. Uputa može propisati odobrenje, dok se stvarna odluka donosi telefonom, a odobrenje se unosi naknadno. Roadmap mora polaziti od stvarne slike jer upravo ona otkriva operativne ovisnosti.
Problemi u ERP projektima često izgledaju kao tehnički problemi, iako počinju nejasnim vlasništvom nad podacima. Ako nitko nije odgovoran za šifarnik artikala, kupaca, dobavljača, sastavnica ili radnih centara, sustav će s vremenom sadržavati duplikate, zastarjele vrijednosti i lokalne iznimke.
Za ključne podatke zato odredite:
Ova odluka izravno određuje redoslijed projekta. Integraciju nije razumno širiti prije odluke o sustavu koji vodi ključni podatak. Novi izvještaj nije stabilan dok definicije mjera i izvori podataka nisu usklađeni.
Integraciju nemojte opisivati samo nazivom sustava i tehničkim sučeljem. Zabilježite koji poslovni događaj prenosi podatak, koje se polje prenosi, kada prijenos nastupa, što se događa pri pogrešci i tko rješava odstupanje.
Primjerice, prijenos narudžbe iz prodajnog sustava u ERP može otvoriti pitanja cijene, porezne oznake, roka isporuke, statusa kupca i promjene nakon potvrde. Ako se dio tih podataka mijenja u oba sustava, problem nije samo integracija. Problem je neodređen izvor istine i nejasna odgovornost za promjenu.
Ciljno stanje procesa ne mora biti savršena slika budućnosti. Treba biti dovoljno precizno za odlučivanje o promjenama. Opisuje budući tok rada, pravila, odgovornosti, podatke i potrebne kontrole.
Za svaku uočenu razliku između sadašnjeg i ciljnog stanja formulirajte promjenu kao poslovnu odluku. Umjesto opće stavke poput "digitalizirati odobravanje", korisnije je zapisati: zahtjev za nabavu dobiva vlasnika, iznos određuje razinu odobrenja, odobrenje ostavlja evidentiran trag, a narudžbenica nastaje tek nakon odgovarajućeg statusa.
Takav opis pomaže razlikovati četiri vrste promjena:
Jedan nalaz može tražiti više vrsta promjene. Ručni unos sastavnice, primjerice, može zahtijevati uređeni šifarnik artikala, jasnog vlasnika sastavnice, pravilo izmjene i ERP funkcionalnost za upravljanje verzijama. Roadmap treba prikazati tu povezanost, a ne voditi svaku stavku kao nepovezani zahtjev.
Praktičan ERP roadmap često ima tri razine rada.
Brze korekcije rješavaju jasan problem uz ograničenu promjenu sustava i bez stvaranja budućeg duga. To mogu biti uklanjanje dvostrukog unosa, standardizacija obaveznog podatka, jasna odgovornost za odobrenje ili jednostavniji izvještaj iz već pouzdanog izvora.
Brza korekcija nije svaka mala izmjena. Ako privremeno pravilo povećava broj lokalnih iznimki ili stvara novu paralelnu evidenciju, može otežati kasniju modernizaciju. U roadmap je korisno upisati i uvjet povlačenja takvog privremenog rješenja.
Ova faza stvara uvjete za veće promjene. U njoj se obično uređuju šifarnici, definicije podataka, poslovna pravila, odgovornosti i kriteriji prihvaćanja. Uključuje i odluke o tome koji sustav vodi koji podatak.
Temeljne pripreme često djeluju manje vidljivo od nove funkcionalnosti, ali određuju pouzdanost kasnijeg rada. Preskakanje ove faze obično premješta problem u migraciju, testiranje ili svakodnevni rad korisnika.
Strukturne promjene obuhvaćaju veći redizajn procesa, uvođenje ili modernizaciju ERP funkcionalnosti, migracije i integracije. Za njih treba pripremiti opseg, poslovnog vlasnika, testne scenarije, odluke o prijelazu i plan rada nakon puštanja u rad.
Kod složenijih procesa korisno je fazu podijeliti prema poslovnoj cjelini, primjerice od narudžbe do naplate, od nabave do plaćanja ili od plana proizvodnje do obračuna. Podjela ima smisla samo ako svaka cjelina može raditi stabilno nakon prijelaza i ako su ovisnosti otvoreno navedene.
Za svaku promjenu procijenite pet pitanja:
Posljednje pitanje je posebno važno. Prihvaćanje ne treba svesti na tehničko testiranje. Za proces izdavanja materijala prihvaćanje može uključiti točno stanje zalihe, evidentiranog korisnika, mogućnost obrade iznimke i usklađen trag za računovodstvo. Time se zahtjev povezuje s poslovnim rezultatom, bez oslanjanja na općenite formulacije.
Pretpostavimo da tim želi povezati prodajnu narudžbu, planiranje proizvodnje, skladište i fakturiranje. Primamljivo je prvo razviti prijenos narudžbe. Razumniji redoslijed može početi provjerom šifarnika artikala, jedinica mjere, pravila cijena i vlasnika podataka. Nakon toga slijedi dogovor o statusima narudžbe i trenutku kada narudžba postaje obvezujuća za planiranje.
Tek tada ima smisla definirati prijenos podataka, obradu promjene narudžbe, ponašanje pri pogrešci i kontrolu uspješnog prijenosa. Sljedeća faza može povezati materijalne potrebe i skladišno izdavanje, a zatim fakturiranje i računovodstveni trag. Ovakav slijed možda ne pruža najbrže vidljivu integraciju, ali smanjuje rizik prijenosa neprovjerenih ili proturječnih podataka kroz više procesa.
Roadmap nije čvrsto obećanje svih datuma. Ovisnosti se mogu promijeniti nakon detaljnije analize podataka, otkrivanja iznimki ili odluke vanjskog partnera. Zato svaka faza treba imati pretpostavke, otvorene odluke i kriterij spremnosti za sljedeći korak.
Također, nije svaku lokalnu iznimku korisno odmah standardizirati. Neke iznimke štite odnos s kupcem, posebnu proizvodnu praksu ili zakonski zahtjev. Prije uklanjanja potrebno je utvrditi svrhu, učestalost, vlasnika i rizik. Standardizacija bez tog provjeravanja može prebaciti posao iz sustava natrag u tablice i neformalne kanale.
Najveći kompromis obično nastaje između brzine i pripreme. Preduga analiza odgađa korist, ali prerana provedba bez odluka o podacima i odgovornostima povećava dorade. Dobar plan ERP modernizacije zato nije maksimalno detaljan dokument. On je radni instrument koji jasno pokazuje što se radi sada, što čeka preduvjete i tko uklanja blokade.
Prije odabira rješenja ili zaključavanja opsega, okupite vlasnike procesa, podatkovne vlasnike i osobe koje rade operativne korake. Za jedan prioritetni tok procesa izradite sadašnje stanje, ciljno stanje i popis razlika s ovisnostima. Zatim svaku stavku svrstajte u brzu korekciju, temeljnu pripremu ili strukturnu promjenu.
Ako tim još nema pouzdanu sliku procesa i prioriteta, ERP i procesni screening može pružiti strukturiranu početnu točku. Za procese koji prelaze prodaju, proizvodnju, skladište i računovodstvo, korisno je promatrati ih kao povezano poslovanje , a ne kao odvojene zahtjeve pojedinih odjela.