eBizMags

Svaka implementacija SW rješenja pretpostavlja i donošenje niza strateških odluka kompanije ili institucije koja takvim projektom želi ispuniti zadane ciljeve. Sam cilj projekta i način ostvarenja cilja morali bi biti u potpunosti i jasno definirani. Podrška upravljačke strukture ne bi trebala biti upitna, a odabir SW i implementatora trebali bi biti garancija uspjeha. Pitanje je da li je to baš uvijek tako? Deklarativno – da, tako je uvijek, no u praksi baš i ne mora tako biti.

Na početku, još u predprojektnoj fazi kompanija / institucija iskaže potrebu za novim SW rješenjem i prva dilema s kojom se susreće je definicija cilja takvog pothvata. Moramo reći da se taj korak danas sve lakše rješava i to ili uz pomoć vlastitih stručnjaka ili uz pomoć specijaliziranih konzultanata koji na lijep i stručan način definiraju sve što željeni projekt treba donijeti. U takvom elaboratu definiraju se ciljevi i zadaci, tehnička i poslovna specifikacija zahtjeva, te čitav niz drugih parametara koji bi trebali pomoći implementatoru da napravi ponudu, a kasnije ako bude izabran, i u samoj realizaciji implementacije.

Takav dokument bi u pravilu trebao dati odgovor na prvu stratešku odluku, a to je da li se želi razviti rješenje ili se želi implementirati standardno rješenje. I tu se krije prva ‘zamka’ za implementatora, a to je da se traži standardno rješenje, a poslovna specifikacija zahtjeva je tako definirana da vrlo lako, tijekom projekta, može prerasti u razvoj rješenja. Razloge tome možemo tražiti u činjenici da zahtjeve specificiraju ljudi koji znaju poslovanje, odnosno ljudi koji određene poslove već rade koristeći ili su koristili neka druga SW rješenja, te se vrlo često radi o parcijalnim programskim rješenjima koja su nastala kao rezultat vlastitog ili eksternog razvoja.

S aspekta implementatora on nije u mogućnosti utjecati na ovaj segment i vrlo često ulazi u posao ne opterećujući se ili ne sagledavajući ovu komponentu problema. Konačno, na strani implementatora posao zaključuje komercijala, a ako je voditelj projekta od strane implementator i uključen, on nije zadužen za analiziranje poslovnog segmenta potencijalnog projekta.
Ako se rizik implementacije i procjenjuje, to se radi zbog komercijalnih razloga, a ne razmatrajući kako i da li će se moći izvesti traženo poslovno rješenje kvalitetom, obimom i načinom prihvatljivim za korisnika, odnosno kupca. U pravilu poslovna specifikacija se piše na način da zadovolji korisnike, ne sagledavajući potrebu da bi se i oni morali prilagođavati novom SW rješenju, te se vrlo često ni ne sagledava praktičnost i provedljivost zahtjeva, a o vremenskoj dimenziji da i ne govorimo.

-

Od strane implementatora prodaja pod svaku cijenu želi dobiti posao, te vrlo često i procjenu rizika podređuje tom cilju, ne razmišljajući da će možda ugovoreno otežati, a možda i onemogućiti realizaciju projekta.

Potpisom ugovora, sve ugovorene negativnosti prebacuju se na voditelja projekta i samu operativu projekta. Sam voditelj o samom projektu ne razmišlja poslovno, već administrativno – jedino ga brinu rokovi, osigurani resursi i da ono što se napravi korisnik potpisom prihvati. Poslovni aspekt se tako prebaci na operativnog implementatora, a to je konzultant – specijalista za pojedini segment poslovanja. On bi trebao prepoznati što je napisano u specifikaciji koja je dio ugovora, prepoznati što operativni korisnik želi, a vrlo često to ne mora biti u skladu sa očekivanjem. Pitanje je koliko sam konzultant ima poslovnog znanja i iskustva da se može ravnopravno nositi sa korisnikom.