Kaj določa ceno in čas prehoda z NAV na Business Central?

Pri dolgoletnih uporabnikih NAV-a se pogosto pojavi povsem logično vprašanje: če partner naš sistem že pozna, zakaj je pred prehodom potrebna dodatna analiza? Poznavanje tehnične rešitve, zgodovine podpore in obstoječih prilagoditev je vsekakor pomembna prednost, vendar samo po sebi še ne pove dovolj o tem, kako podjetje danes dejansko posluje in kaj bo potrebovalo v prihodnjem sistemu.

Procesi se skozi leta spreminjajo, nekatere nekoč pomembne funkcionalnosti se danes morda sploh ne uporabljajo več, meja med standardno funkcionalnostjo in razvojem po meri pa se za uporabnike pogosto zabriše. Kar nekdo uporablja vsak dan, dojema kot del NAV-a, čeprav je bila rešitev v resnici pred leti razvita posebej za podjetje. Zato je pred prehodom treba ponovno pogledati tako sistem kot poslovne procese in ugotoviti, kaj je še relevantno, kaj je mogoče poenostaviti in kaj Business Central danes že pokriva drugače.

Prav zato se realna ocena projekta ne začne pri številki, ampak pri razumevanju obsega.

Preden ocenimo projekt, moramo vedeti, kaj sploh ocenjujemo

Dve podjetji lahko danes uporabljata NAV, pa je lahko njun prehod na Business Central povsem različen. Eno ima eno družbo, nekaj integracij in relativno standardne procese, drugo pa več podjetij, lokacij, veliko prilagoditev in povezave z različnimi zunanjimi sistemi.

Zato je treba na začetku določiti osnovni obseg projekta. Katere družbe bodo vključene? Koliko uporabnikov bo uporabljalo rešitev? Koliko lokacij je treba upoštevati? Katere integracije morajo ostati in katere je treba na novo vzpostaviti? Katere procese bo pokrival standard in kje je dodatna funkcionalnost dejansko potrebna?

Nato sledi diagnostika obstoječega okolja, procesov in podatkov. Na tej podlagi je mogoče narediti fit/gap analizo, oceniti, kaj lahko pokrije standard Business Centrala, kje je smiselno prilagoditi način dela in kje obstaja dovolj dober poslovni razlog za razvoj po meri. Hkrati se identificirajo ključna tveganja in odvisnosti, ki lahko pozneje vplivajo na strošek ali časovnico.

Dobra ocena tako ni samo številka na ponudbi. Pove tudi, kaj je v to številko vključeno, na katerih predpostavkah temelji in kje so področja, ki lahko med projektom zahtevajo dodatne odločitve.

Če obseg še ni dovolj jasen, je lahko tudi zelo natančna številka samo navidezno natančna.

V ceno prehoda ne vpliva samo tehnologija

Pomemben del obsega so prilagoditve. Podjetje je lahko določen razvoj v NAV-u že plačalo, vendar to še ne pomeni, da se ga lahko brez dodatnega dela samo prenese v Business Central. Gre za drugo okolje, zato je treba posamezne rešitve ponovno oceniti in ugotoviti, ali jih je sploh smiselno graditi znova.

Enako velja za podatke. Čeprav je njihov prenos iz NAV-a v Business Central praviloma lažji kot migracija iz popolnoma nepovezanega sistema, je še vedno treba določiti obseg, kakovost podatkov in način prenosa. Prehod je tudi priložnost, da se podatke očisti in v novo okolje prenese samo tisto, kar bo podjetje dejansko potrebovalo za nadaljnje poslovanje.

Tudi način uvedbe vpliva na projekt. Nekje je smiseln enkraten prehod, drugje fazna uvedba po družbah, državah ali poslovnih področjih. Vsaka možnost prinese drugačen način priprave, testiranja, migracije in vključevanja uporabnikov.

Zato cene prehoda ne določa samo velikost tehničnega okolja. Določa jo kombinacija poslovnih procesov, količine in kakovosti podatkov, števila integracij, obsega potrebnih prilagoditev in načina, kako želi podjetje izvesti spremembo.

Časovnica projekta nastane iz obsega, ne obratno

Ko je dovolj jasno, kaj bo projekt vseboval, se lahko začne realno načrtovati izvedba. Predstavljena metodologija projekt razdeli na več faz: najprej analizo in zasnovo rešitve, nato implementacijo v več ciklih, pripravo na produkcijo in nazadnje zagon z obdobjem intenzivnejše podpore.

Pomembno je, da implementacija ne poteka več mesecev v ozadju, nato pa se rešitev tik pred zagonom prvič pokaže uporabnikom. V prvem ciklu se pripravi standardna rešitev in predstavi ključnim uporabnikom, ki jo preverijo in testirajo. V naslednjih korakih se dodajo upravičene prilagoditve in integracije, uporabniki pa skozi projekt sproti spoznavajo nov način dela.

Pred go-live sledijo izobraževanja, končno testiranje in priprava organizacije, ob samem zagonu pa končna migracija podatkov. Po prehodu je predvideno še obdobje hypercare, ko je implementacijska ekipa intenzivneje vključena v podporo uporabnikom in odpravljanje težav.

Na dogodku je bila za srednje veliko podjetje predstavljena okvirna časovnica, po kateri bi začetna faza trajala približno en do dva meseca, implementacija štiri do šest mesecev, priprava na produkcijo približno dva meseca in začetno obdobje po zagonu okoli enega meseca. Toda že v predstavitvi je bilo jasno poudarjeno, da gre samo za orientacijo, saj dejansko trajanje določajo velikost podjetja, kompleksnost procesov, število integracij in obseg rešitve.

Zato je bolj smiselno najprej razumeti projekt in šele nato postaviti datum, kot pa izbrati datum go-live in poskušati ves obseg prilagoditi njemu.

Zgodnje vključevanje uporabnikov zmanjša tveganje pozneje

ERP projekt ni uspešen samo zato, ker nova rešitev tehnično deluje. Delovati mora tudi v praksi, kar pomeni, da morajo procesi ustrezati načinu dela, uporabniki pa morajo sistem razumeti in znati uporabljati.

Prav zato so ključni uporabniki vključeni že med implementacijo. Standardno rešitev preverjajo na delavnicah, sodelujejo pri testiranju in sproti ugotavljajo, ali zasnova ustreza dejanskemu poslovanju. Tako se morebitne napačne predpostavke odkrijejo precej prej, kot če bi uporabniki novo okolje prvič videli nekaj tednov pred produkcijskim zagonom.

To je pomembno tudi za samo oceno projekta. Več neznank kot podjetje razjasni pred začetkom in več pričakovanj kot uskladi dovolj zgodaj, manjša je možnost, da bodo med implementacijo nastajale večje spremembe obsega.

Dobra analiza zato ne obstaja zato, da bi projekt postal bolj zapleten. Njen namen je ravno obraten: čim več kompleksnosti odkriti takrat, ko jo je še mogoče obvladati brez dragih sprememb sredi projekta.

Realna cena in časovnica prideta šele za realnim obsegom

Podjetje pred prehodom seveda potrebuje oceno investicije in okvirno časovnico. Brez tega težko pripravi proračun, določi prioritete in načrtuje svoje ljudi.

Toda pri prehodu z NAV na Business Central je veliko bolj koristno dobiti realno oceno nekoliko pozneje kot hitro številko, ki temelji na preveč predpostavkah.

Prvi korak je zato pregled trenutnega okolja in procesov. Na tej osnovi je mogoče določiti obseg, razumeti podatke in integracije, preveriti prilagoditve, oceniti tveganja in šele nato sestaviti časovni in finančni okvir, ki je dovolj dober za poslovno odločitev. Prav takšen pristop je bil v predavanju predstavljen tudi kot smiseln naslednji korak pred začetkom projekta.

Cena in čas prehoda z NAV na Business Central zato nista določena samo z velikostjo sistema, ampak predvsem s tem, koliko kompleksnosti ima podjetje danes in koliko je želi odnesti v novo okolje.