Što je zapravo posao sudskih vještaka iz područja informatike i telekomunikacija?

Što je zapravo posao sudskih vještaka iz područja informatike i telekomunikacija?

Često pitanje koje je upućeno sudskim vještacima iz područja informatike i telekomunikacije je što je zapravo njihov posao, odnosno u koju točno vrstu predmeta su uključeni. Budući da vještak ne smije iznositi konkretne činjenice koje je saznao obavljajući svoj posao, jedini način da se odgovori na to pitanje je nabrajanje različitih područja koja se tiču (izvorno previše općenitih i širokih) područja informatike i telekomunikacije a u kojima se može pojaviti neki problem, pitanje ili situacija u parničnom ili izvanparničnom postupku, odnosno u nekoj od faza poslovnog odlučivanja, a za koje se traži mišljenje ili analiza neovisnog eksperta. Pritom vrijedi obrat kako je zapravo daleko lakše nabrojiti slučajeve korporativne prakse u kojima nije moguće tražiti mišljenje ili nalaz vještaka informatike i telekomunikacija.

Jedno od najzanimljivijih i najkompleksnijih takvih područja je ono koje se tiče implementacije različitih vrsta poslovnih informacijskih sustava u poduzećima ili organizacijama. Iako pažnju javnosti zaokupljaju različiti online i e-kriminalci i njihova nerijetko medijski eksponirana kaznena djela, rad sudskih vještaka u takvim predmetima je najčešće više tehničkog ili rutinskog karaktera. Nepobitna je činjenica kako je vrlo zahvalno „riješiti“ neki problem, pojasniti strankama određeni tehnički kontekst na laicima shvatljiv način ili odgovoriti na zadatak vještačenja zadan od strane suda - npr. tko je, kada, na koji način i korištenjem kojih alata i metoda vezanih uz informatičke i telekomunikacijske tehnologije nešto učinio. Međutim, najkompliciraniji predmeti i slučajevi vezani su upravo uz probleme pa i neuspjehe kod uvođenja kompleksnih poslovnih informacijskih sustava, a najčešće u srednja i velika poduzeća i organizacije koji nisu toliko „glamurozni“, ali su sa stručne strane vrlo interesantni i kompleksni za shvaćanje,  analizu te posljedično izradu nalaza i mišljenja.

Već (nepopularnim!) pozivom na opće poznato moguće je početi dokazivati kako su takvi projekti i u svjetskoj praksi povezani s vrlo visokim postotkom neuspjeha u smislu probijanja zadanog proračuna, ugovorenog vremenskog roka ili opsega, cijene i kvalitete, a svi iskusni IT menadžeri svjesni su činjenice kako su šanse za neuspjeh i napuštanje uvođenja novog poslovnog informacijskog sustava na razini 35 do 40 % dok s druge strane spektra najmanju šansu za neuspjeh imaju projekti infrastrukturnih i tehničkih migracija. Kako se u poslovnoj informatici koriste svjetske tehnologije, tako niti situacija u Hrvatskoj, barem iskustveno promatrano, nije puno drugačija. U sudskoj praksi - ali i onoj izvan suda, u slučaju kada se sudski vještaci angažiraju kao stručnjaci ili savjetnici kod pokušaja povrata „propalih“ projekata - moguće je identificirati sličan uobičajeni slijed fatalnih koraka koji vode do velikih poteškoća ili potpune propasti projekata uvođenja informacijskih sustava u kompleksnije organizacije.

Neovisno o tome radi li se o integriranim ili onim „običnim“ poslovnim informacijskim sustavima, odnosno njihovim slijednim ili pobočnim inačicama (IBIS, CRM, ERP, x2y gdje „x“ i „y“ mogu biti business, government ili customer), povijest bolesti je slična, uz neke uzroke koji su nešto više specifični za one organizacije koje su obveznici javne nabave. Ovom prigodom neće se detaljnije ulaziti te specifičnosti jer one same zaslužuju zasebnu kolumnu a jednim dijelom su povezane i uz nažalost uvriježene obrasce poslovanja u našoj državi.

Ponuditelji poslovnih informacijskih sustava obično nude neki sustav koji je već prethodno uspješno implementiran i s određenim predefiniranim i standardiziranim funkcionalnostima, dok naručitelji procjenjuju ponude prema nekom internom skupu kriterija koji u praksi mogu biti raznoliki, a najlošije je ako su isključivo cjenovno ili novo-tehnološki orijentirani, bez procjene vezanih i skrivenih troškova. U idealnom slučaju, odluka o uvođenju je nepristrana i lišena „vanjskih“ utjecaj, a izrazito cjenovno orijentirana. Međutim, kompleksnost odvijanja poslovnih procesa već u organizacijama srednje veličine takva je da je bez analize poslovanja poduzeća gotovo nemoguće očekivati da će ugovorena implementacija proći bez problema i u ugovorenom opsegu.

Navedeno je došlo pod lupu znanstvenika još za vrijeme istraživanja mogućnosti optimizacije procesa ljudskog rada početkom prošlog stoljeća, a većina metoda vezanih uz organizaciju poslovanja koje se i danas široko koriste razvijene su tijekom i nakon Drugog svjetskog rata, i to prvo u industriji vezanoj uz naoružanje, a zatim i u civilnoj industriji. Raznolikost korištenih sustava modeliranja poslovnih procesa dovela je do izgradnje nekoliko notacija, odnosno sustava zapisa metodologije odvijanja poslovnih procesa od kojih je jedan od popularnijih onaj koji koristi svjetski poznati SAP. Neovisno o tome koji sustav analize, odnosno modeliranja poslovnih procesa se koristi, važno je napomenuti da bi baš svaku ključnu strukturnu promjenu u organizaciji poslovanja - teško je zamisliti neku koja bi bila kompleksnija od uvođenja novog poslovnog informacijskog sustava - trebalo pratiti prethodno obavljeno modeliranje poslovnih procesa, kako bi se znalo sadašnje stanje, novo stanje kojemu se teži (s implementiranim funkcionalnostima unutar novog sustava), te koje su racionalizacije postignute u tranziciji iz starog u novo stanje. Pritom treba napomenuti kako potonje nije predmetom modeliranja poslovnih procesa već se može kvantificirati isključivo upotrebom simulacijskih alata.

Uz puno razumijevanje činjenice kako je ova analiza subjektivna i pristrana, jer je utemeljena na vlastitom iskustvu, a autora ove kolumne u pravilu zovu kada je „već kasno“, da obavi post mortem analizu i ustanovi što je i kada krenulo po krivu te ukaže na to čiji bi to mogao biti propust, isti još mora susresti propalu migraciju ili implementaciju poslovnog informacijskog sustava prije čijeg uvođenja je napravljena analiza poslovnih procesa i za koje postoje notirani modeli. Nažalost, u našoj je stvarnosti modeliranje u informatici dobrim dijelom prisutno isključivo u nastavnim programima na fakultetima i smatra se suhoparnim, nepotrebnim i dosadnim sadržajem kojemu nema previše mjesta u praksi, iako je prava istina zapravo zrcalna slika navedenog.

Uvođenje ovakvih novih poslovnih informacijskih sustava obično počinje uz puno optimizma sa strane izvoditelja koji je osigurao ugovor, ali i sa strane naručitelja koji očekuje mjerljive koristi i optimizaciju poslovanja (iako zapravo ne zna što konkretno očekuje jer to nigdje nije definirano - no čim je nešto tako novo, napredno i dosta košta, mora biti i bolje od starog), te redovito s nešto manje entuzijazma od strane korisnika koji su u pravilu najrigidniji dio sustava i grčevito se drže onoga što poznaju makar bilo neoptimalno i repetitivno u korištenju, te teško usvajaju nova znanja, postupke i procese, čak i kada donose očite dobrobiti. Traženi hardver i licence za baze podataka se obično isporučuju i instaliraju bez većih poteškoća a prvi problemi se vide kod migracije temeljnih funkcionalnosti (to npr. mogu biti blagajna, materijalno knjigovodstvo ili računovodstvo troškova) koje bi trebale među prvima biti korištene u novom sustavu građenom po metodi „od dna prema vrhu“ jer korisnici uočavaju da sustav u detaljima nije prilagođen potrebama naručitelja. Naravno, izvoditelj ovo očekuje i kreće s rješavanjem problema u radu, programiranjem novih funkcionalnosti, migracijama i otklanjanjem starih i novonastalih grešaka u radu, no kako projekt odmiče i uvode se nove funkcionalnosti i moduli a problemi rješavaju u hodu, gubi se jasna distinkcija između onoga što je prilagodba postojećeg sustava potrebama naručitelja, što je greška u programskoj logici a što je korisnička pogreška (i takvih slučajeva ima) pri korištenju novog sustava. Ovo se reflektira i u subjektivnoj percepiji izvođača što je on ugovorio i što u okviru toga treba isporučiti, a koja se značajno razlikuje od viđenja naručitelja koji smatra da sustav mora biti 100 % funkcionalan prema njegovim zahtjevima koji često i nisu eksplicitno definirani već se mijenjaju i prijavljuju u hodu, čime konstantno uzrokuju kreetanje izvođača koje se prilagođava novonastaloj situaciji „pomične mete“ i novih projektnim zahtjevima, umanjujući vjerojatnost da će metu u svom stalnom slučajnom kretanju ikada zapravo dostići.

Većina naručitelja i izvoditelja organizira timove koji nadziru odvijanje implementacije a u kojima nevoljko surađuje naručitelj ili čak u tim nominira nekoga tko nema niti internu motivaciju niti moć odlučivanja, već u radu tima sudjeluje iz formalnih razloga. Iz prakse je znan primjer implementacije jednog poslovnog informacijskog sustava vrijednosti veće od 10 milijuna kuna gdje je glavna osoba u timu za implementaciju bio zaposlenik odjela za održavanje bez ikakvog interesa ili poznavanja problematike, a koji se na sastanku pojavio svega prvih par puta. S druge strane, izvoditelj često nadzire više paralelnih implementacija i preopterećen je radnim zadacima sa strane svog poslodavca.

Takvi timovi u samom početku redovito se sastaju i produciraju zapisnike u kojima se uglavnom navode mnogobrojni uspjesi u početnim fazama implementacije, dok se s progresijom projekta sve se veći naglasak daje na probleme koji se od sastanka do sastanka iz različitih razloga neuspješno pokušavaju riješiti a njihov pojavni oblik i uzroci mogu biti različiti: od npr. činjenice kako je jezgra sustava zapravo posve neprilagođena novoj implementaciji (npr. poslovni informacijski sustav izvorno razvijen za turističko hotelsko poduzeće nudi se za izvozno industrijsko-proizvodno), preko toga da izvoditelj zapravo nema dovoljno zaposlenika za potporu projektu ugovorene veličine do unutrašnje motiviranog otpora na strani naručitelja, opterećenja zaposlenika koji moraju koristiti paralelno stari i učiti raditi na novom sustavu ili internog informatičkog osoblja koje je zapravo najviše stavljeno po strani kod ovakvih implementacija - i ne opiru se tome previše jer iz iskustva znaju kako stvari u konačnici često završavaju.

Prijelomna točka je često ona u kojoj je potrebno producirati izvješća tražena zakonom korištenjem novog sustava, bilo u okviru redovitog financijskog izvještavanja FINE ili burze, bilo vezano uz fiskalnu odgovornost kod organizacija povezanih uz državu ili kod kreiranja izvješća za interne potrebe rukovodstva. Tada se ustanovljava da korištenjem novog sustava to nije moguće obaviti te se ili pokušava situacija brzinski „pokrpati“ ili se vraća natrag korištenju staogi sustava i transakcije unesene u novi se ručno ili automatski prenose u stari da bi se mogla kreirati izvješća i zadovoljiti tražena forma. Tada i naručitelj i izvoditelj shvaćaju da je projekt u velikim problemima i počinju se formirati izvanredni timovi za povrat projekta iz zatečenog stanja koji su češće neuspješni nego uspješni jer su međusobni odnosi ugovornih strana toliko poremećeni da je neuspjeh projekta neminovan.

U praksi, ovakva situacija koja svoj korijen problema duguje neprovođenju modeliranja poslovnih procesa unutar poduzeća i nekorištenju čak niti najjednostavnijih strukovnih metoda i modela projektnog upravljanja završava na različite načine koji su svi redom loši po obje strane. Ponekad se za neke manje kompleksne module zadržava novi sustav  a za ostale se i dalje koriste moduli starog sustava koji funkcioniraju na više zadovoljavajući način. Ovime se u slučaju integriranih sustava zapravo i odustaje od principa „integriranosti“. Ponekad se nova implementacija napušta u potpunosti jer se u roku godinu i pol do dvije koliko se čini da je obično potrebno da svi shvate kako od nove implementacije neće biti ništa u ugovorenom opsegu pojavilo i novo rješenje na tržištu za koje se čini da je podesnije potrebama naručitelja. U drugim slučajevima, povlači se pitanje koje nije informatičke već poslovne prirode a to je pitanje plaćanja koje je obično ugovarano po licencama i modulima, uz ugovaranje održavanja i dodatnog razvoja, pa se izvan ili unutar sudskog ili čak ovršnog postupka pokušava kvantificirati koliko je „postotaka“ nekog sustava uvedeno, što je i u kojem opsegu isporučeno, a temeljem čega sud mora donijeti odluku, ako se stranke već ne mogu između sebe dogovoriti, koliko je naručitelj još dužan platiti ili koliku štetu je izvoditelj dužan nadoknaditi. U novije vrijeme često se ugovaraju penali ili traže garancije za implementacije poslovnih informacijskih sustava, no još do prije nekoliko godina većina ovakvih ugovora nije bilo puno kompleksnija od onih za kupoprodaju osobnog vozila pa je i posao sudova i odvjetnika bio daleko kompleksniji. Naravno, na vještaku je da uđe u cjelokupnost natječajne i ugovorne dokumentacije, sve zapisnike o implementaciji, korespodenciju o implementacijama i rješavanju problema, otvorene i zatvorene tickete korisničke podrške, radne naloge, te da nakon razgovora sa ključnim kontakt osobama obje strane i uvida u stvarno stanje poslovnog informacijskog sustava razvije metodologiju koja se može kasnije reproducirati a koja će biti korištena kako bi uspio odgovoriti na zadani zadatak vještačenja dostignutog stanja implementiranosti predmetnog poslovnog informacijskog sustava.

Posljedica djelomičnih i neuspjelih implementacija poslovnih informacijskih sustava je daleko veća od one koju je moguće financijski izmjeriti. Svim takvim neuspjelim projektima zajedničko je to da menadžment ne dobiva informacije o poslovanju niti može planirati budućnost - onaj tradicionalno „posljednji“ modul potpore menadžerskom odlučivanju, ma kako se on formalno zvao (dashboarding, poslovna inteligencija, poslovno odlučivanje) u svim ovim slučajevima nije uveden jer zahtijeva sve prethodne module i konzistentno skladište podataka za ispravno funkcioniranje, te do izražaja dolazi princip „garbage in - garbage out“. Većina menadžera opće prakse niti ne shvaća u potpunosti moć informatike u sustavima kojima upravljaju te je i dan dana usprkos svim kolokvijalnim pričama, konferencijama, člancima i neizmjernim frustracijama profesionalnih informatičara ta poslovna funkcija više u statusu „stola i stolice“ nego potpore strateškom funkcioniranju i razvoju organizacije. Opisani propali projekti samo još više učvršćuju animozitet i poimanje poslovne informatike kao „problematične“ poslovne funkcije sa zamućenim ciljevima i nerazumljivim i neizvjesnim povratom na investiciju. Kod korisnika to stvara otpor jer poslovni informacijski sustav ne vide kao potporu operativnim aktivnostima već ulaganje dodatnog mentalnog napora za implementaciju i savladavanje funkcionalnosti sustava koji u konačnici nije zaživio. S praktične strane, štete su ogromne, kako one direktne prema ugovorenome (direktna plaćanja na strani naručitelja ili nenaplaćeni a obavljeni rad i gubitak reputacije na strani izvoditelja), tako i indirektne, pri čemu je ona temeljna trošak „potonulog“ rada zaposlenika naručitelja i izvoditelja. Samo direktna šteta uzrokovana investicijama u naplaćene a nefunkcionalne module koja postaje predmetom sudskih sporova lako se može locirati u raspon od više stotina tisuća do više milijuna kuna za srednja poduzeća te u rasponu od 5 do 10 milijuna kuna za velika poduzeća (organizacije), ne uzimajući u obzir vezane troškova opreme i upravljanja njome, vezanih licenci, električne energije, klimatizacije i godišnjeg održavanja sustava.

Cilj ovog teksta nije nikako taksativno nabrojati sve probleme na koje se može naići pri implementaciji poslovnih informacijskih sustava, jer su neki specifični za privatni a drugi za javni sektor; neki ovise o vrsti poslovne djelatnosti,  internoj organizaciji,  razini dostignute kompleksnosti poduzeća i spremnosti za adaptiranje novih tehnologija, već samo skrenuti pažnju na u praksi dosta uobičajeni kolosijek koji vodi u propast kompleksnih informatičkih projekata koji je nažalost moguće sustavno dokumentirati u Hrvatskoj, ali i svjetskoj praksi razvoja poslovnih informacijskih sustava. On je uzrokovan nekorištenjem strukovnih metoda (najčešće kako bi se inicijalno uštedilo a već na početku srednjeg roka značajno izgubilo), a koji bi bilo moguće izbjeći već kada bi rukovoditelji naručitelja ili izvoditelja takvih projekata poznavali nešto više metodologije projektnog menadžmenta, operativnog procesa uvođenja poslovnih informacijskih sustava i nužnosti ugovaranja modeliranja, optimizacije i simuliranja postojećih poslovnih procesa u odnosu na nove, a sve prije nego se krene u provedbenu fazu operacionalizacije izgradnje novog sustava.

(Autor članka je dr. sc. Saša Aksentijević, rukovoditelj informacijskih sustava, integralne i informacijske sigurnosti u međunarodnom poduzeću energetskog sektora, vlasnik poduzeća Aksentijević vještačenje i savjetovanje, d.o.o., stalni sudski vještak za informatiku i telekomunikacije i asistent iz predmeta „Poslovni informacijski sustavi“ na Pomorskom fakultetu u Rijeci)