Definiran poslovni proces ne znači da je definiran i budući softver. U toj fazi nastaje tek prvi model poslovanja na kojem će se temeljiti razvoj sustava. Tek kada ljudi počnu koristiti softver u svakodnevnom radu postaje jasno koliko se stvarni način rada razlikuje od onoga što je bilo zapisano u dokumentaciji.
Dokumentacija gotovo uvijek prikazuje idealan tijek poslovanja. U stvarnom radu zaposlenici kombiniraju korake, preskaču pojedine aktivnosti, odgađaju unos podataka ili hitne situacije rješavaju izvan sustava jer posao ne može čekati. Softver pritom nije pogrešno razvijen. Jednostavno se prvi put susreće sa stvarnim operativnim uvjetima koji tijekom planiranja nisu bili potpuno vidljivi.
Upravo zato operativni timovi trebaju biti uključeni tijekom cijelog procesa razvoja, a ne samo prilikom prikupljanja početnih zahtjeva. Njihovo iskustvo otkriva poslovne situacije koje dokumentacija sama gotovo nikada ne može dovoljno precizno opisati.
Razvoj poslovnog softvera počinje razvojem dokumentacije. Operativni tokovi upisuju se u korake koji definiraju očekivane ishode. Na papiru sve to izgleda uredno i jasno.
Development tim dobiva sliku rada. Već u ovome koraku najčešće je učinjena nepopravljiva šteta po projektu. Dostavljena dokumentacija je filtrirana. Opisani procesi predstavljaju idealnu verziju operative. Redoslijed koraka je linearan, a granični slučajevi koji se pojavljuju u radu su reducirani.
U stvarnom radu taj isti proces rijetko ostaje linearan. Administratori rade s podacima koji dolaze iz više izvora, s vremenskim razmacima. Interni koordinatori spajaju informacije između timova koji ne rade u istom ritmu. Menadžeri operative donose odluke u uvjetima gdje se prioriteti mijenjaju tijekom dana.
U dokumentaciji postoji jedan standardizirani tok rada, dok u stvarnosti istodobno postoji više paralelnih načina izvršavanja istog procesa. Razlika između njih ne nastaje zato što zaposlenici ne žele slijediti pravila, nego zato što svakodnevni rad zahtijeva prilagodbu situaciji, prioritetima i vremenskom pritisku.
Tijekom vremena upravo ti prilagođeni načini rada postaju stvarni poslovni proces, iako nikada nisu formalno definirani. Sustav nastavlja prikazivati idealni model poslovanja, dok se svakodnevni rad sve više oslanja na iskustvo zaposlenika, međusobnu komunikaciju i lokalne odluke koje dokumentacija nikada nije predvidjela.
U jednom internom sustavu svi zahtjevi između timova trebali su ići kroz isti obrazac. Unese se zahtjev, ide odobrenje, pa dalje u izvršenje.
Tako je barem bilo zamišljeno. U praksi, kad bi se dan zakomplicirao, taj se tok počeo preskakati.
Koordinatori su počeli dobivati pozive direktno: “Možeš li ovo odmah riješiti, hitno je.” U tim situacijama nije se čekao sustav. Neke stvari su se riješile odmah, a unos u sustav bi došao kasnije, ako bi došao uopće.
Sustav je i dalje izgledao uredno, jer je proces postojao samo formalno. Stvarni posao se počeo događati drugdje; na telefonu, u kratkim dogovorima između ljudi… S vremenom je softversko rješenje postalo mjesto gdje se stvari bilježe, a ne gdje se odluke stvarno donose.
U skladištu posao teče stabilno dok su uvjeti blizu prosječnih. Narudžbe idu svojim redoslijedom, skeniranje i pakiranje prate definiran tok koji se može preslikati u sustav.
Ta stabilnost vrijedi samo dok se ne počne gomilati posao.
Kada volumen posla poraste, situacija se mijenja. Odluke su donesene u hodu i izvan su sustava. Operateri mijenjaju redoslijed čekanja jer on blokira cijeli poslovni tok. Artikal se uzima s druge lokacije jer s primarne trenutno nije moguće. Narudžbe se preskaču i dodaju kasnije.
Sustav i dalje prikazuje uredan i predvidiv tok, dok se u stvarnosti izvršenje odvija drugačije. Razlika se ne vidi odmah, vidljiva je tek kada iznimke postanu češće od pravila. Tada prestaje biti jasno što je zapravo pravilo, a što improvizacija.
U terenskom radu procesi sustava izgledaju stabilno dok se promatraju iz faze planiranja. Planirani tok rada pretpostavlja da neće doći do komplikacija i da su resursi potrebni za rad dostupni u svakom trenutku.
U stvarnosti se rad odvija u promjenjivim uvjetima. Uvjeti na terenu, dostupnost opreme, pa i sami prekidi u komunikaciji utječu na izvedbu posla. Redoslijed aktivnosti se prilagođava situaciji i trenutku.
Dio informacija u trenutku nastanka nalazi se izvan sustava. Unos podataka često se odgađa, jer prioritet je odraditi posao. Sustav zato često nije ažuriran tijekom rada.
On i dalje prikazuje planirani tijek rada, samo što se stvarna izvedba odvija u drugačijim uvjetima. Sve je bilo zamišljeno drugačije u fazi planiranja softvera. Razlika izlazi na površinu kroz odgode u ažuriranju sustava tijekom izvršenja rada.
U terenskom radu komunikacija nije uvijek stalna. Postoje situacije u kojima se kontakt sa centralnim timom prekida zbog uvjeta na lokaciji rada ili prirode obavljanja posla.
U tim trenucima odluke se donose bez potpune podrške sustava. Informacije se unose naknadno ili u skraćenom obliku. Sustav više ne prikazuje kontinuitet izvršenja u stvarnom vremenu, nego naknadno rekonstruira tok aktivnosti.
Softver u takvim uvjetima i dalje funkcionira kao sustav, ali prestaje biti vjeran prikaz stvarnog načina rada na terenu. Zato se uvode odgode u sinkronizaciji, dopuštaju se offline unosi u softver i kasnija validacija podataka. Dio logike premješta s “real-time” izvršenja na naknadnu obradu kako bi sustav mogao pratiti fragmentirani tijek rada na terenu.
Tijekom razvoja platforme EUDoctor složenost sustava nije postala vidljiva tijekom same faze razvoja. Pojavila se tek kada su liječnici i pacijenti počeli svakodnevno koristiti platformu u stvarnim konzultacijama. Radni tokovi koji su tijekom dizajna izgledali potpuno linearno počeli su se prilagođavati vrsti pregleda, hitnosti slučaja, regulatornim zahtjevima pojedinih država i načinu rada različitih ambulanti.
Koraci koji su u početku bili definirani kao zasebne aktivnosti u praksi su se često spajali, preskakali ili izvodili drugim redoslijedom. Ne zato što su korisnici pogrešno koristili sustav, nego zato što je stvarni način rada zahtijevao drugačiji slijed aktivnosti od onoga koji je bio predviđen tijekom planiranja.
Većina promjena uvedenih nakon puštanja sustava u produkciju nije bila posljedica tehničkih problema. Nastale su promatranjem načina na koji zdravstveni djelatnici stvarno rade. Upravo je operativno iskustvo korisnika pokazalo koje dijelove sustava treba dodatno prilagoditi kako bi softver podržavao stvarni rad, a ne samo njegov idealizirani model.
Problemi u sustavu najčešće se prvi put pojave kroz korisničke prijave tijekom stvarne upotrebe sustava.
Korisnik prijavi da određeni korak traje duže nego što je očekivano. Drugi ne može završiti isti postupak koji je ranije prolazio bez problema. Treći traži pomoć jer se isti tok više ne može ponoviti. Svaki slučaj izgleda kao zaseban incident.
U korisničkoj podršci ti se slučajevi počinju skupljati, isti tip pitanja pojavljuje se kroz različite kontekste. Ticketi se počinju ponavljati kao isti obrazac.
U tom trenutku podrška postaje prvi sloj u kojem se vidi razlika između dokumentiranog procesa i stvarnog načina korištenja sustava. Broj ponavljanja se povećava, i postaje jasno da problem nije u pojedinačnim korisnicima. Dio procesa nije dovoljno precizno ugrađen u sustavu.
Tek tada se slučajevi grupiraju u razvojni zahtjev. Za development tim to je znak da model procesa ne odgovara stvarnoj upotrebi. Specifikacija se korigira na temelju ponašanja sustava u praksi.
Prodajni proces najčešće je definiran kao niz jasno odvojenih koraka. Potencijalni klijent ulazi u sustav i kroz vrijeme se razvija u klijenta ili se izgubi u procesu.
U stvarnom radu taj tok rijetko izgleda tako. Prodajni razgovor se često vraća unatrag. Informacije se nadopunjuju nakon prvog kontakta, a klijent donosi odluke prije nego što su svi podaci uneseni u sustav. Dio komunikacije odvija se izvan CRM-a zato što se situacija mijenja tijekom samog procesa.
CRM u tom trenutku ne prati stvarni tijek razgovora, nego njegovu naknadnu verziju. Prodajni predstavnik rekonstruira što se dogodilo kako bi se sustav ostao ažuriran. Realni proces i zapis u sustavu počinju se razilaziti.
Zbog takvih slučajeva, teže je iz CRM-a dobiti stvarnu sliku o tome u kojoj fazi prodajnog procesa se potencijalni klijenti u stvarnosti nalaze.
To znači da je CRM evidencijski sloj koji opisuje što se dogodilo u stvarnom radu s klijentom.
Poslovni softver ne postaje stabilan onoga trenutka kada je dokumentacija dovršena ili kada je sustav pušten u produkciju. Stabilnost dolazi tek kada se softver prilagodi stvarnom načinu rada ljudi koji ga svakodnevno koriste. Operativni timovi tijekom vremena otkrivaju situacije koje nije bilo moguće predvidjeti u fazi planiranja, a upravo one postaju temelj za daljnji razvoj sustava. Što softver vjernije odražava stvarni način rada organizacije, to zaposlenici imaju manju potrebu za zaobilaznim procesima, dodatnim alatima i improvizacijom. Tek tada sustav postaje prirodan dio svakodnevnog poslovanja, umjesto još jednog ograničenja kojem se poslovanje mora prilagođavati.
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.
