Često nas potencijalni klijenti pitaju koja je najbolja strategija za neki specifičan segment poslovnih procesa i potreba u ERP sistemu Microsoft Dynamics 365 Business Central. Ovaj renomirani ERP sistem nudi dosta standardnih mogućnosti. Ipak, iako je dizajniran za (gotovo) bilo koju industriju i veličinu kompanije, kao i svaki softver, ni ovaj softver ne može out-of-the-box ponuditi funkcionalnosti za podršku baš svakoj poslovnoj industriji ili svakom segmentu poslovanje bilo koje firme. U takvim situacijama, neophodna je strategija implementacije i budućeg održavanja ERP sistema.
Sa jedne strane, kako je u pitanju globalno rasprostranjen softver sa partnerima širom sveta, klijenti mogu pronaći neki sertifikovani vertikalni dodatak (modul) koji nude kompanije bilo gde u svetu, sa opisom koji odgovara industriji ili vertikali u kojoj klijent posluje. Sa druge strane, opcija je da se za ove specifične funkcionalnosti uradi razvoj na projektu, prema specifikaciji korisnika.
U ovom tekstu pokušaćemo da istaknemo prednosti i nedostatke obe opcije i posebno skrenemo pažnju o čemu treba voditi računa prilikom izbora ovih opcija.
Potencijalne strategije
Prva strategija koja klijentima stoji na raspolaganju je razvoj na projektu. Ova opcija podrazumeva da se klijent odluči za nekog lokalnog partnera i na projektu implementacije uvede standardne Microsoft ERP opcije, uz razvoj za sve segmente koji nisu standardno podržani.
Prednosti ove opcije su prilagođavanje rešenje konkretnim potrebama i detaljima klijenta, izrada rešenja po konkretnim i potpuno specifičnim zahtevima u svakom segmentu. Na ovaj način može se dobiti prilagođeno rešenje, koje će imati sve one opcije koje su korisnicima potrebne i čime će krajnji korisnici biti najzadovoljniji (zbog prilagođavanja svake opcije) Takođe, u slučaju da se tokom vremena jave novi, promenjeni ili prošireni zahtevi, dodatni razvoj će uvek pokriti i ove potrebe.
Glavni razlog zbog koga klijenti zaziru od ove opcije leži u činjenici da klijent smatra da specifičan segment njegovog poslovanja zahteva duboku industrijsku ekspertizu, da je veoma kompleksan i da zahteva mnogo vremena i posla u izradi svih opcija. Svaki klijent svestan je neophodnosti određenog obima razvoja na projektima implementacije ERP sistema, ali ukoliko se radi o osnovnim segmentima poslovnog procesa kompanije ili kompleksnoj vertikali, procena je da bi adekvatno rešenje iziskivalo enorman razvoj. Veliki razvoj na projektu uvek povlači i pitanja preciznosti postavljenih uslova i zahteva, kvaliteta dokumentacije, održavanja rešenje u budućnosti i velike zavisnosti od partnera koji tako veliki i važan segment napravi po specifikaciji.
Ovo su legitimni razlozi zašto klijenti često razmatraju da li je razvoj opcija ili je bolje izabrati drugu strategiju.
Sa druge strane, klijentima je često primamljiva strategija kupovine gotovog modula, najčešće nekog inostranog partnera. Ova opcija znači da će klijent na tržištu pronaći modul baš za njemu interesantan poslovni segment, te u sistem staviti vertikalni dodatak partnera, kojim će podržati potrebne procese.
Kao i kod prve strategije, intuitivno su jasne neke od prednosti i nedostataka. Prednost korišćenja standardnog modula svetskog partnera znači usvajanje najbolje prakse koju je partner stekao na više projekata, te uvođenje modula koji se već koristi u praksi. Nedostaci su uglavnom cena i zabrinutost za lokalnu podršku (na teritoriji drugog govornog područja).
Naše mišljenje je da izbor strategije nije jednoznačno određen i univerzalno isti, već zavisi od mnogo faktora. Ne želeći da umanjimo varijantu izbora gotovog modula svetskog partnera, u nastavku ćemo pokušati da istaknemo još neke skrivene nedostatke opcije izbora gotovog modula, koji se u praksi sreću.
Manje evidentni nedostaci
Prva stvar koja se često previdi pri izboru opcije kupovine gotovog modula slična je previdu koji se napravi pri izboru ERP softvera: potencijalni klijenti se fokusiraju na kratke opise funkcionalnosti i grube crte procesa. Iz kratkog predstavljanja ili prezentacije stiču utisak bogatstva opcija, iskustva partnera i velike širine funkcionalnosti sadržanih u modulu, pa im često deluje da modul podržava sve što im je potrebno. Praksa, međutim, pokazuje da treba biti obazriv. Često se dešava da, iako grube crte procesa odgovaraju potrebama korisnika, detaljna razrada pokazuje da je modul malo drugačije zamišljen i napravljen od organizacije koju korisnici žele. Čak i male razlike, u nekim detaljima, mogu dovesti do toga da modul ne zadovoljava baš potrebe i očekivanja korisnika, što će se manifestovati tokom upotrebe modula.
Druga stvar o kojoj treba voditi računa je širina modula. Moduli svetski zastupljenih partnera često podržavaju širok spektar opcija, što na prvu deluje kao dodatni razlog za izbor baš ove opcije. Ipak, neretko se u praksi dešava da klijentu nije potrebna ni polovina dostupnih opcija. Cena modula definisana je za kompletan skup funkcionalnosti, što znači da klijent plaća puno (njemu) nepotrebnih opcija. Ako se ova dva razloga uzmu zajedno, klijent može dobiti modul koji podržava mnoge nepotrebne opcije, ali ne podržava neke koje su, u nekim detaljima, njima veoma važne.
Na kraju, treba istaći i održavanje i mogućnosti izmena modula. Mnogi svetski partneri ne žele da menjaju svoje module prema zahtevima klijenata, već žele da isti modul implementiraju svuda (zbog lakše podrške i migracija na nove verzije) – ukoliko imaju modul koji se razlikuje kod svakog klijenta, onda to nije standardizovani modul i upravo se odstupilo od izabrane strategije. Stoga, opcije izmena i modifikacija, koliko god nužne ili male delovale korisniku, mogu biti nepoželjne od strane partnera. Ne treba zapostaviti ni mogućnost da partner cenom želi da obeshrabri klijenta da traži dorade i izmene, pa nije nerealno očekivati da čak i sitne modifikacije modula mogu zahtevati veće investicije.
U sklopu trećeg skrivenog ograničenja koje smo naveli treba sagledati i potencijalne izmene u poslovnim procesima. Naime, implementacija ERP sistema obavlja se sa idejom da sistem podržava procese kompanije najmanje 5, ali neretko i 10 godina. U tom svetlu treba razmatrati i implementaciju standardizovanog modula. U slučaju da se kroz godine kompanija menja ili raste, verovatno će nužne biti i potrebe za izmenama u ERP sistemu, a kako se standardizovani moduli najčešće razmatraju za najvažnije procese i vertikale, neophodne će biti izmene i u tim segmentima.
Savet
Naš savet je, kao i uvek, pozabaviti se detaljima prilikom izbora strategije. Kratak opis modula svetskog partnera nikako ne sme biti dovoljan. Treba razraditi što više procesa i koraka, kako bi se identifikovao stepen poklapanja zahteva. Ukoliko taj stepen nije 90%, treba dobro razmisliti o upotrebljivosti takvog modula i ukupnom trošku za implementaciju i kasnijeg održavanja.
Dodatno, kako smo pisali u drugim tekstovima, klijenti često istovremeno definišu dva cilja projekta: automatizacija (što manje posla krajnjih korisnika) i standardizacija (usvajanje najbolje prakse). Ova dva zahteva su u velikoj meri kontradiktorna, a praksa pokazuje da se klijenti, nakon implementacije, uglavnom više fokusiraju na automatizaciju i zahteve krajnjih korisnika (za što manje akcija i što prilagođenijem rešenju). Ako postoji opcija da će Vaš projekat ovako izgledati, proverite još jednom opciju standardnog modula, jer taj modul sigurno zahteva prilagođavanja korisnika i navika.
Nikako ne želimo reći da je izbor gotovog modula univerzalno lošiji izbor. Ukoliko je modul dizajniran tako da podržava procesne korake tačno onako kako su potrebni korisniku, ova strategija je sigurno najbolji izbor. Samo treba biti siguran oko odnosa onoga što modul nudi i onoga što korisnicima treba.
Drugi savet koji možemo dati u sklopu ovog pitanja je napraviti procenu izmene procesa u budućnosti. Koliko ste sigurni da postavljeni procesi, zahtevi i funkcionalnosti na projektu implementacije neće zahtevati nikakve (a posebno ne veće) izmene nakon 4-5 godina? Ukoliko imate rezervu po pitanju ovoga, svakako treba još jednom razmisliti da li je vertikalni modul prava opcija.
Na kraju ćemo istaći savet i u slučaju izbora opcije razvoja, a to je insistiranje na detaljnoj dokumentaciji. Izrada velike količine razvoja na projektu, bez detaljne dokumentacije koja to prati, svakako je jako loše dugoročno rešenje.
