IIB: Ono „ali“ što sreću kvari

Sproveli smo sve metodološke korake, najpre prilikom donošenja odluke o izboru puta i načina rešavanja informacionih ili poslovnih potreba, a zatim to ponovili i u procesu implementacije. „Ali“ rezultat nije ono što smo očekivali…

Rezultat lošeg uvođenja projekta razvoja dela ili celog poslovnog informacionog sistema se može oslikati kroz nekoliko varijeteta koji se događaju u praksi:

• Projekat ne zaživi uopšte, čak se neretko može desiti i da su obe strane uradile sve po planu, ali se u toku uhodavanja konstatuje da nam ipak „to“ toliko i ne treba;
• Projekat zaživi, ali sa značajno umanjenim funkcionalnostima od željenih;
• Projekat zaživi sa većinom funkcionalnosti, ali radi bočno od glavnih procesa, pritom se ne koristi ni za operativno donošenje odluka o vođenju posla za koji je pretežno kupljen, a kamoli za nešto više;
• Projekat formalno živi, u internom marketingu između službi i menadžmenta, a u praksi nije poznato ni ko ga koristi ali se, gle vraga, uskoro opet kupuje novo, još bolje softversko rešenje koje se interno od istih službi opet reklamira kao spas u pravi čas;
• Novi sistem zaživi, ali radi kao Frankenštajn, sporo daje rezultate koji često nisu vremenski usaglašeni, pa su samim tim i neupotrebljivi.

Interesantno je i u praksi potvrđeno da, što je preduzeće sa većom organizacionom hijerarhijom, to je lakše bez velike odgovornosti interno zakamuflirati bilo koji od navedenih varijeteta a, paradoksalno zvuči, i dobiti budžet za neki novi projekat za koji opet nije bitno da li će i koliko biti uspešan.

Kako smo došli do ovoga?

Rast i razvoj poslovnih sistema uvek prate izazovi i rizici, bez obzira da li je reč o tome da li: širiti ponudu ili povećavati obim, nabavljati nove mašine ili optimizovati rad postojećih, uzeti kredit ili koristiti sop­stvena sredstva, smanjiti broj zaposlenih na račun automatizacije procesa, dovesti nove zaposlene ili obučavati postojeće…

Sve ove promene u stopu prati razvoj poslovnih informacionih sistema, koji su infrastrukturna podrška poslovnim sistemima, pa se posledično u informacionim sistemima uglavnom suočavamo sa izmenom evidencije i tokova podataka u smislu automatizacije, povećanja detaljnosti, sintetisanja kvalitetnijih rezultata… Ovo se postiže unapređenjem ili zamenom postojećih aplikativnih rešenja, ali i dodavanjem novih.

Zanemarimo unapređenje postojećih aplikativnih rešenja i posmatrajmo dalje korake tako da je doneta odluka da se uvede novo softversko rešenje (bilo da se dodaje ili da se menja postojeće). Ako želimo da doneta odluka bude objektivna, treba ispuniti nekoliko pretpostavki:

Jasan zahtev

Potpuno nam je poznato koji prob­lem treba da rešimo ili koju potrebu da ispunimo, tj. postoji jasan poslovni zahtev ka budućem softverskom rešenju, koji recimo glasi: „Imamo potrebu da u rešenju koje nam nudite postoji mogućnost da formiramo cenu ka kupcu koji je naručio novi proizvod po posebnoj specifikaciji, tako što ćete nam omogućiti predkalkulaciju cene koštanja, zatim želimo da vidimo šta nam je potrebno i šta nam nedostaje za realizaciju te porudžbine, u smislu materijala, ali i ostalih resursa. Dalje, ono što nedos­taje treba poručimo i ispratimo do koje faze nam je stigla nabavka. Kada proizvodnja započne želimo da pratimo napredak i eventualna kašnjenja, a na kraju da uradimo kalkulaciju stvarne cene koštanja i vidimo kako smo prošli na datom poslu.“

U prvoj fazi uvođenja, snimanja stanja i uzimanja zahteva, sve teče kao po loju, obe strane imaju elana i lako se razumeju.

Mogućnost izbora

Postoji dovoljno dostupnog softvera, koji se relativno lako identifikuje i izbor sužava na nekoliko alternativa. Zbog lake dostupnosti moćnih pretraživača, uspešnog marketinga ili na osnovu preporuke, vrlo lako je identifikovati mnoštvo globalnih, regionalnih i lokalnih softverskih rešenja koja imaju moćne skraćenice (MES, DMS, EAM, CMS, ERP, MRP, APS, CRM, SFA…) a njima treba dodati i, u poslednje vreme ponovo aktuelizovanu, izradu softvera od nule po zahtevu korisnika.

Sve izabrane alternative „kuvaju, peglaju i čuvaju malu decu“, odnosno, funkcionalne su i efikasne. Prethodno izabrane aplikacije, čitajući brošure i specifikaciju, gotovo da zvuči kao da ih je moguće, bez ulaganja bilo kakvih resursa, brzo pokrenuti. Ovakav prizvuk, pogotovu uz moćnog prezentera, imaju one koje se rade od nule tj. po meri korisnika. Konstatujemo i da sve aplikacije i dobavljači sa sužene liste imaju dobru referentnu listu.

Kvalitetan kadar

Sužavanjem izbora dobavljača usluga i aplikacija potvrdili smo da postoje i odlični timovi koji nude, prezentuju, uvode i daju podršku za izabrane aplikacije. Dobavljač koga ćemo izabrati odgovorio je na sva pitanja, a čak je ponudio dodatne mogućnosti, više od zahtevanih. U razgovorima je potvrđeno i kako će se raditi uvođenje, kasnije i podrška, i uvereni smo kako je to dobro uhodan proces.

Ugovor je potpisan i uvođenje počinje

Proces uvođenja počinjemo uspos­tavljanjem timova, a dalje se radi po manje-više standardnim koracima većine metodologija, gde se glavne faze uglavnom svode na: prvo, neka vrsta snimka stanja i uzimanja zahteva, srpski rečeno pravljenje „blu printa“, potom podešavanje sistema, obuka korisnika i na kraju puštanje u rad.

U prvoj fazi uvođenja, snimanja stanja i uzimanja zahteva, sve ide kao po loju, obe strane imaju elana i lako se razumeju.

U drugoj fazi, podešavanje sistema, strana izvođača je i dalje samouverena i demonstrira sistem, korisnik uglavnom biva zasut gomilom novih informacija i prihvata podešeno rešenje zdravo za gotovo ne udubljujući se u prikazano i dalje verujući uvođačima.

Na obuci, zbog želje da se što pre pokrene sistem ili umanje troškovi, često se preskoči ili zbrza detaljna obuka ključnih korisnika i pristupa se obuci krajnjih korisnika, koja, uz neke trzavice na pojedinim tačkama, uspešno prolazi.

Uzroci propusta su retko u metodološkom sprovođenju projekta, pa tada mora da se gleda dublje, u suštinu. Detaljnom analizom se dolazi do stvarnih uzroka uočenih propusta

Na kraju, pred start rada uživo, pošto su sve faze uvođenja sprovedene i potpisane, pristupa se pripremnim aktivnostima i novo čedo konačno „počinje da hoda“.

Procedura sprovedena, sistem počinje da živi, „ALI“ …

Iako u navedenim koracima i pos­tupku izbora aplikacije kao i načinu implementacije nema velikih propusta, rezultat vrlo lako počinje da odmiče sve dalje od željenog. Ukoliko se „proklizavanje“ uoči ranije, u ranim fazama implementacije, stvari su nešto lakše. Ipak, često se dogodi da se proklizavanje uoči tek posle starta sistema.

Uočavanjem proklizavanja rezultata, odmah počinje analiza i neka vrsta eskalacije procesa uvođenja. Uzroci tih propusta su retko u metodološkom sprovođenju projekta, pa tada mora da se gleda dublje, u suštinu. Detaljnom analizom se relativno lako dolazi do stvarnih uzroka uočenih propusta, a njih delimo u dve grupe:

Prva grupa uzroka nezadovoljstva konačnim rezultatom potiče od samog korisnika:

• Najčešće ne postoji jasan projektni zadatak, zato što su zahtevi izneti više deklarativno, a uočava se i da nije jasno definisano koji resursi i preduslovi su potrebni, procesi nisu opisani do nivoa detaljnosti potrebnog za dobru implementaciju. Interesantno je i da se događa da se ovo identifikuje na vreme, ali biva s namerom ostavljeno da se rešava u hodu;
• Moguće je da je odluka o izboru softvera i formulacija zahteva potekla od sektora iz uskog posmatranja sopstvenih potreba, a bez povezivanja sa celinom poslovnog informacionog sistema;
• Nekada je softver izabrala jedna ekipa sa jednom namerom i viđenjem, da bi posle uvođenje bilo potpuno prepušteno drugoj koja ili nema dovoljno znanja ili im se prosto viđenja i ciljevi ne poklapaju sa početnim;
• Kada otkrijemo da nivo postojeće evidencije podataka ne može da podrži zahtevane funkcionalnosti, a detaljniji nivo evidencije nije iz nekog razloga moguće sprovesti (nemogućnost softvera, neznanje korisnika ili uvođača), problem je ozbiljan, a dodatno raste što se kasnije otkrije. Ovo često može biti i zajednička odgovornost obe strane i eliminatorni uslov za nastavak projekta;
• Šanse za neuspeh rastu i ako zaposleni koji su zaduženi ne umeju da formulišu precizno zahteve, ali i da koordiniraju rad svih potrebnih službi da bi se dobio željeni rezultat ili kada se, kasnije u procesu upotrebe rešenja, desi da tim koji je izneo projekat biva sklonjen, a iza ne ostane niko ko bi znao da upravlja obimom i rezultatima;
• Fluktuacija zaposlenih preko određene mere itekako utiče na ukupno nezadovoljstvo rezultatom, a ponekad se dešava i „sabotaža“ drugih interesnih grupa;
• Na kraju, kada se ne vidi brzo željeni rezultat, ponestaje i volja za dalje ulaganje novca i ljudskih resursa zbog percepcije da sve nekako sporo ili loše ide.

Druga grupa uzroka na strani pružaoca usluge / implementatora su često samo druga strana istih onih koji se događaju na strani korisnika:

• Prva i slična greška kao kod korisnika, samo posmatrana iz druge perspektive: Napravljen je snimak stanja, dat predlog rešenja, sve je dokumentovano, ali je većina bitnih elemenata o tome kako nešto treba da radi ostala na deklarativnom nivou (kao da su posao radili prodavci). Iako je manjak detalja identifikovan na vreme, razrada se ostavlja za kasnije;
• Softver ipak ne rešava sve zahteve zbog kojih je odabran, a nije ga moguće doraditi da ispuni potrebne zahteve, iako je na prodajnim prezentacijama rečeno drugačije. Nažalost ovo se nekada svesno prikriva i odlaže za kasnije faze, kada će korisniku biti teško da izađe iz projekta;
• Iako po listi referenci liči da je firma iskusna u oblasti, konsultanti/programeri koji rade na projektu ipak ne znaju dovoljno i nemaju iskustva iz delatnosti ili ne
• poznaju softversko rešenje i
• njegove mogućnosti;
• Može da se dogodi i da je izabrani softver teško integrisati sa nekim od već postojećih softvera jer se logički ne podudara struktura podataka ili je teško podeliti nadležnosti – preklapaju se;
• Fluktuacija kadra je moguća i na strani uvođača. U nekom momentu, na primer, zbog dobijanja „boljeg“ posla, neki konsultanti budu pomereni na drugi projekat, a započeti se ostavi nedovoljno iskusnima;
• Poslednji uzrok koji izdvajamo je i da trošenjem predviđenog budžeta, nebitno čijom krivicom, u momentu kada je ispunjenje zahteva još daleko, počinje težnja ka neformalnom uprošćavanju zahteva. Ovim se dešava spuštanje ugovorenog nivoa implementacije u stilu: dogovoren je konj, a isporučen vrhunski magarac.

Da li je moguće bez velikog „ALI“?

Formalno ispunjenje određenih standarizovanih koraka, tj. vođenje projekta obično niti šta garantuje, niti dovodi do uspešnog unapređenja informacionog ili poslovnog sistema.

Iskustvom kadrova obe strane može se prepoznati suština projekta i omogućiti upravljanje svim bitnim detaljima, pritom ne obrađujući detalje koji stvarno nisu ključni za ishod čitavog projekta

Udubivši se malo više u fazu izbora kojim rešenjem ispuniti potrebu, vidi se da je poslovni zahtev sa početka dovoljan samo za prezentaciju i načelan izbor rešenja, ali ne i za konačnu implementaciju. Time je, ako u procesu davanja predloga rešenja ovo nije detaljno razrađeno, a dokument jeste usvojen, jasno da obe strane ne razumeju materiju, a toga nažalost neće biti svesne sve dok ozbiljno ne zagaze u kasnije faze uvođenja. Ovo znači i da bez pravovremenog i preciznog određivanja preduslova, logičkih veza procesa na poslovnom i tehničkom nivou, te resursa potrebnih za sprovođenje nekog posla i to već u prvoj fazi uvođenja, projekat neće odmaći dalje od odlične zamisli ili će značajno podbaciti u očekivanom rezultatu. Iskustvom kadrova obe strane može se prepoznati suština projekta i omogućiti upravljanje svim bitnim detaljima, pritom ne obrađujući detalje koji stvarno nisu bitni.

U datom primeru, kod izbora rešenja smo olako postupili i u analizi referentnih implementacija. Ovo se može podvesti pod rubriku „verovali ili ne“, jer sve češće ovaj korak biva ignorisan prilikom izbora, time propuštajući da lako proverimo odnos sa korisnikom, moguću detaljnost implementacije, kao i umeće konsultanata i sposobnost softvera da odgovori na konkretne zahteve.

Bez obzira da li je odluka sa početka teksta bila uvođenje dodatnog, zamena ili unapređenje postojećeg softvera, ako obratite pažnju na propuste koji mogu da nastanu, već u prvoj fazi izbora biće moguće odabrati rešenje ili izvođača koji nudi veću verovatnoću uspeha, a potom i, takođe u prvoj fazi uvođenja, uočiti kritična mesta implementacije, te omogućiti vraćanje projekta na pravi put ili se već tada odlučiti za prekid projekta jer svaka kasnija reakcija može samo više da boli.

Na osnovu 35 godina iskustva, kao i danas, obostrana iskrenost u namerama i saznanjima, u svim fazama projekta od prodaje pa do puštanja u rad, omogućava da projekat plovi u „mirnim vodama“.

iib.rs