Uspješne poduzeća često dođu do točke poslovanja u kojoj moraju digitalizirati svoje poslovne procese. U tome trenutku, razvoj softvera koji neće samo odraditi posao već i pobrinuti se za ukupno poslovanje i planove u budućnosti kompleksan je i zahtjevan zadatak.
poduzeća koje uvide od samih početaka da prilikom digitalizacije ne prelaze u digitalno rješenje, već dobivaju novog poslovnog partnera, efikasnije prolaze kroz čitav proces transformacije.
Ne radi se samo o prikupljanju informacija od ključnih ljudi i pretvaranju workflowa u sustav. Taj potrebni proces često se odvija kroz više slojeva interpretacije: management tada definira što “treba vidjeti”, operativni timovi opisuju kako bi stvari trebale funkcionirati, dok development dobiva objedinjenu verziju. Ona izgleda uredno, ali dio stvarne kompleksnosti je izgubljen.
Tu nastaje osnovni problem. Sustav koji je dizajniran da donese predvidivost sudara se s operativnim okruženjem koje je fragmentirano i puno iznimki. Kako standardizirati takve procese? Dok pritisak implementacije raste, povećava se i razlika između onoga što je modelirano i onoga što se stvarno događa u radu.
Za to učiniti potrebno je odabrati poslovnog partnera za izradu softvera koji razumije poslovne procese i sposoban je tehnološki ih standardizirati. Ovaj članak prikazuje najčešće točke gdje dolazi do tog razilaženja; kroz vendor odluke, rokove isporuke, vlasništvo nad sustavom, komunikacijske slojeve i post-launch fazu u kojoj se stvarni operativni problemi tek dolaze do izražaja.
Prilikom odabira softver partnera, cijena često postaje primarni filter kroz koji se evaluira cijeli projekt. Na razini odluke to izgleda racionalno, uspoređuju se ponude i rokovi isporuke u filtriranju najboljeg kandidata. U pozadini, već tada se definira koliko će se duboko radni procesi uopće razumjeti, prije nego što razvoj krene.
Kod odabira vendora prema cijeni, discovery faza gotovo se uvijek skraćuje. Ne zato što netko svjesno odluči “preskočiti analizu”. Svaka dodatna iteracija razumijevanja procesa promatra se tada kroz prizmu troška sredstava i vremena. Stvara se business conflict između kontrole budžeta i kvalitete razumijevanja sustava. Rezultati konflikta posljedično će definirati primjerenost samog softver rješenja. Primjerice, skladište, financije i korisnička podrška često isti poslovni proces provode na različite načine. U dokumentaciju najčešće uđe samo standardni tijek rada, dok svakodnevne iznimke ostaju izvan specifikacije. Softver se tada gradi prema idealiziranom modelu poslovanja, a operativni timovi nastavljaju koristiti neformalne načine rada kako bi riješili situacije koje sustav ne prepoznaje.
Implementacija u takvom kontekstu počinje ranije nego što su sve varijacije poslovnog workflowa stvarno mapirane. Sustav se počinje graditi na osnovnom, “čistom” procesu, dok se stvarni operativni scenariji nalaze izvan formalne definicije. Implementacija tada pobjeđuje razumijevanje procesa zbog pojednostavljene analize.
Kako razvoj napreduje, postupno se otkriva da dio zahtjeva nikada nije bio jasno definiran. Pretpostavljeni su kroz razgovore između managementa, operative i development tima. U praksi to znači da rubni slučajevi nikada nisu završili u dokumentaciji. Zaposlenici ih znaju rješavati jer se s njima susreću godinama, ali development tim za njih nikada nije saznao. Nakon implementacije upravo takve situacije postaju support zahtjevi, zaobilazni procesi ili dodatni razvoj koji se mogao izbjeći tijekom kvalitetnijeg discovery procesa.
Posljedica toga je niz malih korekcija u okviru plana izgradnje sustava. Funkcionalnosti se prilagođavaju. Redefiniraju se kako bi sustav uopće mogao biti dovršen u okviru zadanog budžeta i roka. Razilaženje između cijene i razumijevanja procesa ovime je dodatno produbljuno.
Prava korekcija u ovakvim situacijama događa se ranije, u discovery fazi. Tada je potrebno eksplicitno uključiti granične i stvarne operativne tokove. Sustav se ne smije graditi na idealiziranom prikazu koji izgleda uredno, ali ne odražava stvarno stanje organizacije.
U ranim fazama softver projekta, rok isporuke često postane dominantna poslovna varijabla koja oblikuje način na koji se cijeli sustav definira. Kada se postavi agresivno, mijenja se kompletna dinamika isporuke, i sam način na koji se pristupa razumijevanju radnih procesa.
Pod takvim pritiskom discovery faza prestaje biti prostor za dubinsko mapiranje stvarnih operativnih tokova. Ona postaje ograničeni korak koji se mora nekako ugurati u okvir planiranog razvoja. Nastaje business conflict između brzine isporuke i točnosti razumijevanja sustava. Sve nauštrb primjerenosti budućeg finalnoga softver rješenja. Također, pojavljuje se i operational conflict između stvarnog ponašanja u operativi i pojednostavljenog modela. On naprosto mora biti “dovoljno dobar”, a ne realan, da bi ušao u development.
Posljedica ovakvog pristupa postaje vidljiva tek kada sustav uđe u svakodnevni rad. Tijekom testiranja sve može izgledati ispravno jer je implementiran glavni poslovni proces. Tek nakon implementacije pojavljuju se situacije koje tijekom discovery faze nisu bile prepoznate, poput dodatnih razina odobravanja ili iznimki od standardnih poslovnih pravila. Ono što je izgledalo kao mali rubni slučaj vrlo brzo postaje ograničenje same arhitekture sustava.
Implementacija u takvom kontekstu počinje oblikovati ponašanje organizacije prije nego što je proces u potpunosti razumljen. Umjesto da sustav reflektira način rada firme, firma počinje prilagođavati svoj način rada sustavu koji je izgrađen na djelomičnim informacijama. To dodatno učvršćuje sistemsku logiku u odnosu na stvarne poslovne procese, a razlika između dizajna i stvarnog izvršenja ne vidi se odmah, nego se akumulira kroz korištenje.
Posljedica ovakvog pristupa je tehnička nepreciznost koja generira strukturalni dodatni posao koji će se pojaviti kasnije. Tada će se stvarni operativni slučajevi sudarati s pretpostavkama ugrađenima u sustav. Funkcionalnosti koje su izgledale stabilno u fazi razvoja pokazivati će ograničenja tek kada se suoče s punim rasponom iznimki u radu.
Ovakve se situacije sprečavaju prije početka izgradnje, kroz validaciju kritičnih točaka u poslovanju i uključivanje rubnih operativnih situacija. Time se smanjuje razlika između pretpostavljenog i stvarnog ponašanja sustava prije nego što se započne proces implementacije.
Kod totalnog outsourcing modela, sustav vrlo brzo počinje oblikovati način na koji poduzeće donosi operativne odluke. U početnim fazama to često izgleda kao efikasno rješenje jer interni tim ne mora graditi vlastitu tehničku strukturu. Razvoj kreće brže, a vendor preuzima odgovornost za arhitekturu i izvedbu sustava.
Početak implementacije je brži, ali istovremeno smanjuje se razinu interne kontrole nad načinom na koji je sustav definiran. Dokumentacija, arhitekturna logika i poslovna pravila postupno se koncentriraju unutar vendora, dok poduzeće zadržava samo funkcionalni pogled na softver koji koristi. Stvara se business conflict između brzine pokretanja projekta i dugoročne kontrole nad sustavom. Istovremeno, razvija se i operational conflict između načina na koji vendor interpretira procese i načina na koji se oni stvarno izvršavaju unutar organizacije.
Naizgled jednostavna promjena, poput dodavanja nove razine odobravanja ili izmjene pravila numeriranja dokumenata, odjednom zahtijeva dodatnu analizu vendora jer unutar poduzeća više nitko ne razumije na koji su način poslovna pravila implementirana. Čak i manje operativne promjene postupno postaju ovisne o vendoru, što smanjuje fleksibilnost organizacije i usporava njezinu prilagodbu novim poslovnim potrebama.
Problem nije vidljiv odmah nakon launch-a softvera. Sustav može djelovati stabilno i funkcionalno, sve dok poslovni model ostaje relativno nepromijenjen. Međutim, kako operativa evoluira, pojavljuju se nove iznimke i dodatni procesi, nove prilagodbe sustava. Svaka sljedeća promjena počinje ovisiti o vanjskom tumačenju arhitekture, što postupno povećava ovisnost o vendoru unutar samog poslovanja.
Većina softver projekata počinje s pretpostavkom da različiti dijelovi organizacije ne razumiju podjednako način na koji posao stvarno funkcionira. Upravo se u toj pretpostavci najčešće pojavljuju prvi komunikacijski gapovi u softver projektima. Operativna realnost filtrira se kroz management prije nego što dođe do development tima.
U takvom modelu zahtjevi ne dolaze direktno iz operative. Informacije prolaze kroz sastanke kako bi sustav ostao pregledan i “izvediv” unutar planiranog opsega projekta. Time se stvara trade-off između jasnoće komunikacije i stvarne kompleksnosti procesa. Krivo interpretirani operativni poslovni tokovi postupno se ubacuju u samu strukturu specifikacija.
Na početku implementacije taj problem često nije vidljiv. Međutim, kako operativni timovi počinju koristiti sustav u stvarnim uvjetima rada, pojavljuju se situacije koje nisu bile dovoljno precizno modelirane kroz formalne zahtjeve procesa.
Tada nastaje razlika između planiranog načina rada i stvarnog poslovanja. Prodajni timovi počinju rješavati iznimke kroz Slack poruke jer ih CRM ne podržava. Financije svakog petka izvoze podatke u Excel kako bi ručno uskladile račune. Operativa uvodi dodatne procese koji nikada nisu bili dio originalnog dizajna sustava. Nakon nekoliko mjeseci softver više nije jedino mjesto na kojem se odvija poslovanje. Sve su to posljedice malih pojednostavljivanja koja su tijekom razvoja napravljena kako bi projekt ostao unutar planiranog budžeta i rokova.
Problem pritom ne nastaje zbog jedne velike greške u razvoju, nego zbog mnoštva sitnih pojednostavljivanja procesa. Umanjuje se operativna kompleksnost kako bi projekt ostao vremenski izvediv. Management vidi standardiziran proces unutar sustava iako operativni timovi održavaju paralelne razine rada koje nikada nisu formalno ušle u specifikaciju.
Slična dinamika često se pojavljuje i kod projekata koji postupno izlaze iz planiranih rokova, kao što je objašnjeno u članku Why software projects run late.
Da bi se izbjegle ovakve situacije, ne radi se dodatni posao nakon launch-a, nego se uključuju operativni timovi u definiranje kritičnih točaka poslovanja prije nego što njihovi zahtjevi uopće postanu formalna specifikacija sustava.
Prvi znak problema u mnogim softver projektima pojavljuje se nekoliko mjeseci nakon launch-a, kada započnu stvarni poslovni pritisci koje sustav nije predvidio. U toj fazi sustav često formalno izgleda završen, a stvarni se problemi tek počinju razvijati kroz svakodnevno korištenje.
Fokus organizacije prirodno se prebacuje na stabilizaciju poslovanja, i održavanje redovnih operativnih prioriteta. Tehnička podrška prelazi iz aktivnog razvoja u reaktivno održavanje. Intervencije se događaju kada problem postane već dovoljno vidljiv da utječe na izvršenje rada. Time se događa trade-off između smanjenja troška podrške i dugoročne stabilnosti sustava.
U prvim mjesecima korištenja problemi rijetko izgledaju kritično. Pojavljuju se sitna odstupanja između načina na koji je rad zamišljen i načina na koji se posao stvarno provodi. Dio procesa počinje se zaobilaziti, određene odluke donose se izvan sustava. Operativni timovi postupno razvijaju dodatne rutine kako bi održali tempo s postavljenim rokovima.
Kako se takvi zaobilazni modeli akumuliraju kroz vrijeme, operativno odstupanje u softverskom sustavu postaje sve izraženije. Sistemska logika ostaje formalno nepromijenjena, ali stvarni radni procesi počinju se udaljavati od načina na koji je sustav prvotno dizajniran. U operativi počinju vagati između standardiziranih tokova rada i stvarnih prioriteta operative.
Tek nakon dužeg razdoblja postaje jasno da sustav više ne odražava stvarni način poslovanja. Zaposlenici točno znaju koje korake moraju odraditi izvan aplikacije prije nego što se vrate u službeni proces. Excel tablice, chat poruke i ručna odobravanja postupno postaju jednako važni kao i sam softver. Organizacija se sve više prilagođava ograničenjima sustava, umjesto da se sustav prilagođava organizaciji. Management i dalje vidi stabilan sustav, dok operativni timovi svakodnevno koriste improvizirane procese kako bi posao mogao funkcionirati.
Kako bi se izbjegle ovakve situacije, potreban je model kontinuiranog usklađivanja. Sustav se kontinuirano uspoređuje sa stvarnim ponašanjem operativnog dijela, kako bi se odstupanja prepoznala prije nego što postanu dio svakodnevnog rada organizacije.
Većina problema u softverskim projektima ne postaje vidljiva u fazi odabira vendora, niti u fazi dizajna sustava. Pojavljuju se tek kada se sustav počne koristiti u stvarnim operativnim uvjetima. Odluke se tada ne donose linearno, a rad se odvija pod pritiskom rokova, unutar iznimki i paralelnih prioriteta.
Tada postaje jasno da razlika između uspješnog i problematičnog projekta ovisi o tome koliko je precizno modeliran stvarni način rada organizacije. Kada se ta razina razumijevanja preskoči, sustav i dalje može izgledati tehnički ispravno, ali operativni timovi postupno razvijaju paralelne načine rada kako bi obavili svakodnevne zadatke.
Razlika između dizajniranog i stvarnog načina rada rijetko je vidljiva odmah nakon implementacije. Ona se postupno povećava kako se poslovanje mijenja, a zaposlenici uvode male zaobilazne procese kako bi održali svakodnevni rad. Šest mjeseci kasnije management i dalje vidi izvještaje koji pokazuju da se procesi provode prema planu, dok operativni timovi koriste Excel tablice, e-mail komunikaciju i chat poruke kako bi obavili posao koji sustav više ne podržava. Softver nije tehnički zakazao, ali više ne odražava stvarni način na koji poduzeće posluje.
Ako se ova tema odnosi na projekt koji planirate, možete nam se javiti izravno ili proći kroz project estimation flow za strukturiranu prvu procjenu.
