Kako ugovoriti održavanje ERP-a

Velik broj članaka i rasprava je posvećen uvođenju ERP-a u neku firmu. Projekt je kompleksan, zahtjevi su nejasni, rokovi prekratki, cijena prevelika i tako u nedogled. No, kada tad, projekt se završi i korisnik radi s rezultatima tog projekta; ima sopstveni ERP. Mnogi laici bi pomislili da je time najveći dio posla završeni i da je gotovo s „mukama“. E, pa nije. ERP rešenje, budimo iskreni, nije jeftin proizvod i uvodi se u neko poduzeće s namjerom da se koristi godinama. Kompanije koje odlučuju koji ERP će implementirati i koja firma će to napraviti vrlo često (i to je jedini ispravan put), odabiru i po kriteriju – održavanja, tj. kakvo održavanje im firma implementator pruža u budućnosti. U nastavku teksta ćemo objasniti kakve vrste održavanja postoje i na što treba paziti prilikom ugovaranja.

Uopšteno, održava se hardver i softver. Dublja podjela bi bila: računala, mrežna oprema, periferije, sistemski softver i aplikativni softver. Iako je ovaj tekst namijenjen isključivo održavanju aplikativnog softvera, točnije, ERP-a, ne smiju se zaboraviti ni ostale komponente. Održavanje se generalno dijeli na interno, eksterno i kombinirano. Interno održavanje je kada u vlastitoj firmi postoje timovi koji mogu sve gore navedeno održavati, bez ičije vanjske pomoći. Eksterno održavanje je kada kompanija ne posjeduje timove za bilo kakvo održavanje, a kombinirano je kada firma neki dio održava vlastitim timovima, a neke druge mora ugovoriti. Osim ako imate isključivo interno održavanje (a to je vrlo rijetko kada se radi o ERP rešenjiima), postoje veliki rizici kod detektiranja problema i preuzimanja odgovornosti. Na primjer, kada vam računala, periferiju i sistemski softver održava jedna, a ERP druga firma, kada naiđete na problem koji nije očit (a vrlo često nije), postoji velika opasnost da kada nazovete jednu firmu, odgovor bude: „Naš dio je u redu, problem je kod onog drugog!“. Najbolji način da se to spriječi, iako se vrlo rijetko radi, je da se održi sastanak između svih kompanija koje vrše održavanje i dogovore pravila rješavanja problema. Na primjer, kada korisnik nazove firmu koja održava ERP, a nije greška u tom segmentu puno je bolje, da onaj tko održava ERP kontaktira drugu kompaniju koja, na primjer, održava hardver i pokuša s njom direktno riješiti korisnikov problem, nego da se s korisnikom igra „ping pong“. Naravno to vrijedi u slučajevima gdje problem nije očit, na primjer kada korisnik ne može upaliti računalo. Naravno, najbolje bi bilo da jedna firma održava sve. Tada, kada korisnik naiđe na problem, firma koja održava interno mora odrediti gdje je problem i kako ga riještiti.

Postoje dva tipa održavanja: u garantnom roku, te nakon što taj rok istekne. U garantnom roku kompanija je, u pravilu, dužna otkloniti sve bugove do tada pronađene, a vrlo često se garancijom pokriva i određeni broj sati konzultacija, tj. pomoći korisniku pri radu jer, ne zaboravimo, korisnik neće znati u potpunosti koristiti ERP i baš sve njegove mogućnosti odmah nakon završetka implementacije (nekad će mu trebati mjeseci da svlada sve što ERP „može“ i što korisniku treba). Izvan garantni rok pokriva sve što ne spada u garanciju i ono što garancijom nije pokriveno (na primjer, pomoć korisniku može biti u garanciji u trajanju od 6 sati mjesečno, a sve izvan toga se naplaćuje), te sve što je što je pokriveno garancijom nakon njenog isteka. Održavanje izvan garantnog roka se može ugovoriti ili se ono (ukoliko nije ugovoreno), radi „po pozivu“. Gdje je razlika? Osim što je razlika u cijeni (po pozivu je gotovo uvijek skuplji), najveća je razlika u vremenu odziva. Vremena odziva bit će objašnjena u ovom članku, a ovdje je bitno napomenuti da ukoliko korisnik nema ugovoreno održavanje, pomoć će dobiti kada izvođač bude imao vremena. Zašto? Zato jer on ni sa čime nije obavezan pristupiti problemu odmah, ili što prije, jer ga na to ne obvezuje ugovor. Zato je izuzetno važno da se održavanje van garantnog roka – ugovori!

Kada korisnik dođe do problema oni se dijele na: bug (korisnik nešto ne može raditi ili ne može raditi na način kako bi to trebalo), ispravak postojeće funkcionalnosti (korisnik može raditi s određenom funkcionalnošću, ali nju treba doraditi jer se, na primjer, pojavila nova poslovna potreba) ili korisnik treba novu funkcionalnosti, te zakonske promjene. Tu postoji veliki rizik. Tko određuje u koju kategoriju problem spada? Korisnik će vam vrlo često reći kada je potrebno proširiti neku funkcionalnost, da bez nje ne može obavljati svoje dnevne aktivnosti i da je to za njega – bug. Da bi bilo jasno o čemu se radi, važna je specifikacija funkcionalnosti u fazi implementacije, odnosno bilo koji dokument koji precizno opisuje postojeću funkcionalnost i kako bi ona trebala raditi. Ako je ona tako napisana i opisana, onda se puno lakše može zaključiti da li se traži dodatak na nju ili ne. Ako je pak ona neprecizno napisana, onda ćete ući u beskonačno natezanje oko dogovora da li se to što se traži trebalo ili nije nalaziti u funkcionalnosti. Generalno, ugovor o održavanju pokriva otklanjanje grešaka (bugova) i određen broj sati za konzultacije, tzv pomoć korisnicima. Što se tiče zakonskih promjena one se mogu, a i ne moraju ugovoriti. Ako se ugovore rizik snose obje strane i naručitelji i isporučitelj. Ako, na primjer u jednoj godini nema niti jedne zakonske promjene, isporučitelj je dobio novac kojim se one pokrivaju, ali kako ih nije bilo, to je njegova čista zarada. Ako pak u jednoj godini ima nekoliko zakonskih promjena tada isporučitelj može utrošiti puno više vremena kako bi te promjene napravio nego je pokriveno s ugovorenom cifrom i ne može dodatno naplatiti. Naravno, ako se ne ugovori zakonska promjena opet se dolazi do istog problema kako je prije bilo navedeno, a to je da isporučitelj nije dužan istu i napraviti na vrijeme (što se rijetko događa, ako isporučitelj želi opstati na tržištu), a cijena takve promjene je redom veća od one koju pokriva ugovor, jer je isporučitelj u situaciji da odredi bilo koju cijenu, jer korisnik (budući da ne može birati želi li tu promjenu ili ne), mora to i prihvatiti. Korisniku ERPa će vrlo često trebati pomoć u njegovom korištenju (na primjer vrlo često korisnik krajem godine zove i puta kako se radi inventura ili kako se zatvara godina). Ako imate takav ugovor tada je to njime pokriveno (naravno do određenog, ugovorenog, broja sati), a ako nemate tada se plaća po regularnoj cijene konzultacija isporučitelja. Nove funkcionalnosti se redovito naplaćuju i posebno ugovaraju.

Kod prijave kvara, ugovaraju se najčešće tri stupnja: Kritično (sistem ne radi ili ne rade neke njegove funkcionalnosti neophodne za nesmetan rad), Hitno (korisnik može raditi sa sustavom ali jako otežano) i Regularno (korisnik ima smetnje, ali ima i zaobilazni put, tzv. „workaround“). Treba jasno ugovoriti tko određuje stupanj hitnosti. Korisniku je sve kritično i odmah će tražiti rješenje. Na implementatoru je da korisniku pokaže kako može riješiti svoj problem bez hitne tj. trenutne intervencije i tako „smiri“ korisnika. Ako to ne može ili nije izvedivo, onda je korisnik u pravu. Vrlo jednostavno!

Ovisno o stupnju hitnosti dogovara se i vrijeme odziva. Pod time ne mislim na vrijeme na koje će se netko iz help deska javiti na telefon, već na vrijeme za koje će početi s otklanjanjem kvara. To se zove i „response time“. Na primjer, za kritične kvarove, to vrijeme može biti 15 minuta, dok za one regularne kvarove može biti i 5 radnih dana. S druge strane postoji tzv. vrijeme rješavanja ili „repair time“. To je vrijeme u kojem se implementator obvezuje otkloniti kvar. Ako implementator ugovori takvo vrijeme, snosi sav rizik. Naime to je vrijeme u kojem implementator GARANTIRA da će problem riješiti. A svi implementatori znaju da postoje tzv. skriveni bugovi, koje je teško otkriti, pa samim time je teško i reći, a kamoli unaprijed se obavezati ugovorom, kada će biti riješeni. Stoga to ne treba ugovarati, ako je ikako moguće.

Radno je vrijeme ovisno o potrebama korisnika. Ako imate npr. maloprodaju koja radi od 0-24 onda je logično da za takve lokacije ugovorite i adekvatno vrijeme u kojem help desk radi (ali imajte na umu da to onda i više košta, jer implementator mora imati ekipe koje rade noću). Isto vrijedi i za dane vikenda ili praznika. No, kod ERP rešenja je najčešće održavanje ugovoreno od npr, 08:00 do 18:00 radnim danima. Naravno radni dani ovise o tome da li radite u više država ili samo jednoj. Ako npr. radite u regiji, a imate jednog te istog implementatora, tada je vrlo često praznik u jednoj državi radni dan u drugoj i implementator mora biti dostupan (što opet povećava cijenu održavanja)

Na kraju moram napomenuti da sve prijave kvarova morate adekvatno i pratiti. Za to koristite neki alat. BILO KOJI alat je dobar ako su se o njemu i implementatori i korisnik dogovorili, jer obje strane moraju u njega imati uvid. Osim standardnog opisa problema, mora se pratiti vrijeme prijave, vrijeme pristupanja rješavanju, vrijeme stvarnog rješenja, tko je problem riješio i, ne manje važno, osoba sa strane korisnika koje je rješenje provjerila i potvrdila ili odbacila da je ono ispravno. Taj alat služi ne samo za praćenje statusa grešaka i napretka pojedinog rješavanja, nego kao i podloga za realan izvještaj, kao i podlog za račun koji će implementator ispostaviti. Jer, ako se implementator ne drži ugovora, ovaj će izvještaj to jasno pokazati i služi kao osnova za obračun kamata, koja se isto tako ugovara.

Da bi implementator zadržao svoj status kod korisnika, te da bi s njima radio godinama važno je da korisnik bude zadovoljan. A to znači da se mora sklopiti dobar ugovor, kako bi obje strane bile zaštićene, a korisnik imao stalan osjećaj da ima pomoć ako mu nešto ne radi ili pođe po zlu. To mogu usporediti sa servisom automobila. Koliko god automobil bio kvalitetan, ukoliko je servis koji taj auto održava i popravlja kvarove – loš, kupac će taj auto zamijeniti nekom drugom markom i nekim drugim serviserom. Isto je i s ERP-om. Imajte to na umu bilo da ste implementator ili korisnik!

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