U jednom od prethodnih tekstova pisali smo o razlikama između ERP sistema koji su dostupni na tržištu, uz posebno isticanje razloga zašto su svetski poznata rešenja (SAP, Oracle EBS i Microsoft Dynamics) toliko zastupljena. Dotakli smo se teme razlike u vezivanju kompanije za softver (kod svetskih rešenja) ili za drugu kompaniju (kod lokalnih rešenja, koje je lokalna firma sama razvila). U vezi sa tim, otvorili smo pitanje zastupljenog mišljenja kako je jednostavno zameniti partnera za implementaciju ili podršku/održavanje, pošto je u pitanju renomirano svetsko ERP rešenje.
Kada je u pitanju sistem Microsoft Dynamics 365 Business Central (bivši NAV odnosno Navision), u nastavku ćemo pojasniti zašto nije baš tako i koje zamke treba izbeći u ovom procesu.
Proces zamene Microsoft Dynamics partnera nije jednostavan i treba od početka razumeti da proces košta i traje. Zato i na početku teksta još jednom apelujemo da pažljivo birate partnera za saradnju, te pokušate da produžite saradnju sa tim partnerom. Nešto povoljnija situacija je u slučaju da se razmatra prelazak na novu verziju odnosno novi projekat implementacije (jer je to praktično početak nove saradnje). Promena u toku održavanja postojeće verzije je veoma kompleksna i puna izazova.
Promenu Dynamics partnera klijenti u preko 90% situacija razmatraju u toku podrške, odnosno nakon što je projekat implementacije završen. Nekada se radi i o dužem periodu nakon projekta, koji se meri godinama. Jako su retke situacije želje za promenom u toku same implementacije.
U posebnom tekstu pisali smo o važnosti podrške, gde smo pomenuli koliko je teže držati visok nivo zadovoljstva u odnosu na implementaciju, kao i čime su klijenti najnezadovoljniji u podršci. Ovde ćemo istaći izazove koji otežavaju zamenu partnera i kojih treba biti svestan od trenutka izbora sistema Microsoft Dynamics 365 Business Central.
Poznavanje procesa, specifičnosti, terminologija
Prvi razlog zašto nije jednostavno zameniti Microsoft Dynamics partnera intuitivno je jasan. U toku projekta implementacije, partner je upoznao specifičnosti klijenta. Projekat implementacije traje od par meseci do dve godine (u većim sistemima) i članovi projektnih timova zajedno prolaze kroz nekoliko faza. Od organizacije procesa, dogovora oko načina rada, razrade potreba i koraka u novom sistemu, do terminologije koja se koristi u organizaciji, partner je u velikoj meri upoznao klijenta. Promena, u bilo kom trenutku u budućnosti, znači da novom partneru treba određeno vreme da upozna procese i specifičnosti.
Lokalizacija
U zemljama za koje Microsoft isporučuje lokalizaciju kao deo standardnog rešenja, promena partnera je jednostavnija. Međutim, na tržištima gde partneri razvijaju svoje lokalizacije (kao što su zemlje ex-Ju regiona) ovako nešto je prilična komplikacija.
Partnerova lokalizacija znači da klijent u svom sistemu ima relativno širok skup lokalnih i vrlo važnih funkcionalnosti, dizajniranih, napravljenih i podešenih od strane tog partnera. Iako sve lokalizacije na nekoj teritoriji funkcionalno izgledaju vrlo slično (jer moraju podržati iste lokalne propise i zakone), tehnička rešenja se mogu mnogo razlikovati.
Situacija da novi partner preuzima održavanje projekta sa tuđom lokalizacijom znači da novi partner treba da pruža podršku za lokalizaciju koju je dizajnirao i napravio neko drugi. Lokalni propisi mogu zahtevati hitne intervencije, a zakonske izmene dodatno opterećuju ovaj proces.
Vrlo često novi partner postavlja uslov postavke svoje lokalizacije umesto lokalizacije prethodnog partnera, što nas vraća na temu cene i vremena promene partnera, koje smo istakli u uvodu.
Specifični moduli i dorade
Slično kao i sa lokalizacijom, tokom implementacije prethodni partner može postaviti brojne module i specifične dorade. Novi partner ne može znati logiku dorada i modula koje je neko drugi pravio, čak i ako projekat sadrži detaljnu dokumentaciju (a često nije tako). Stoga, novi partner dolazi u situaciju da treba da održava, drži funkcionalnim, pomaže pri korišćenju i unapređuje celine sa kojima nije upoznat ni funkcionalno, ni tehnički. Takvu situaciju mnogi partneri neće prihvatiti.
Jedno rešenje je da novi partner postavi svoje module i iznova napravi dorade, ali se ponovo vraćamo na pitanje cene i vremena.
Opseg objekata
Za razliku od prethodnih razloga koji su intuitivno jasni i verujemo očekivani, postoji i jedan manje očigledan razlog, uslovljen specifičnostima Microsoft Dynamics on-prem implementacija. Na žalost, ovaj aspekt često nije ni komuniciran sa korisnikom tokom pregovora i projekta, pa korisnici postaju svesni ove teme tek kada razmatraju promenu.
Naime, kod on-prem implementacija, (implementacija ERP sistema sa opcijom kupovine licenci, na sopstvenom ili zakupljenom serveru), korisnik ostvaruje pravo na sve funkcionalnosti i elemente baze podataka koje je Microsoft uključio u licencu (sve što je podržano licencom koja je kupljena). Ukoliko je potrebno napraviti neke izmene (dorade), neophodno je iste smestiti u objekte baze podataka (tabele, stranice, izveštaje i jedinice kôda).
Microsoft podržava dve opcije za realizaciju i postavku specifičnosti u sistemu:
- Korišćenje opsega objekata partnera. Ova opcija znači da će partner module, dorade i izmene staviti na svoj opseg (ID) objekata u bazi podataka (tabele, stranica, izveštaje i jedinice koda). Partnerski opseg objekata rezervisan je samo za konkretnog partnera i niko drugi ne može imati pristup, niti mogućnost izmena objekata na tuđem opsegu.
- Kupovina objekata. Ova opcija znači da klijent, pored licence, kupuje određeni opseg (ID) objekata, na kojima se mogu stavljati izmene i dorade. Ova varijanta znači da se sve ili deo izmena stavlja na javni opseg, koji je dostupan i drugim partnerima.
Prva opcija je jeftinija, jer ne generiše trošak objekata korisniku i to je razlog zašto se često uzima ova opcija bilo od strane klijenta, bilo od strane partnera. Opsegu registrovanom za jednog partnera nijedan drugi partner na svetu ne može pristupiti. Na ovaj način se malom uštedom stvara enormna zavisnost. Dakle, ne samo da će novi partner morati da se upozna sa specifičnostima klijenta i svim stvarima koje smo naveli prethodno u tekstu, već će morati da ponovo napravi sve izmene i dorade (svaku sitnicu) na nekom drugom opsegu, gde će imati pristup. Jasno je kolika je ovo dodatna komplikacija prilikom potencijalne promene.
Druga opcija, i pored toga što je nešto skuplja zbog dodatnog troška kupovine objekata, daje mnogo veću slobodu korisniku.
Smatramo veoma važnim sagledati ovo pitanje i odličiti se za pristup pre projekta. Takođe, smatramo veoma važnim da se ova tema komunicira od početka.
Zaključak
Naša sugestija svim klijentima je da ne uzimaju zdravo za gotovo floskulu da je jednostavno zameniti partnera na projektu bilo implementacije, bili podrške/održavanja. Promena partnera je proces koji zahteva vreme i koji generiše trošak. Iz ovog razloga, smatramo da firme trebaju biti fokusirane na saradnju sa postojećim partnerima, ali i da na početku procesa dobro sagledaju potencijalnu saradnju. Uvek sugerišemo klijentima da razlikuju verifikovane reference, odnosno reference za koje partneri dostavljaju kontakt podatke. Reference bez kontakt podataka ne treba ni uzimati u obzir, a svakako sugerišemo i kontaktiranje nekoliko klijenata svakog partnera pre odluke o saradnji.
