Како планирати развој са малим ризиком

Porudžbine iz internet prodavnice stižu, ali neko mora svako jutro da ih ručno unosi u poslovni sistem. Skladište vidi drugačije podatke o zalihama nego prodaja, a petkom tri osobe prikupljaju brojke za izveštaj menadžmenta. U takvoj situaciji, pitanje kako planirati razvoj sa niskim rizikom nije prvenstveno tehnološki zadatak. Prvo treba razumeti kako je svakodnevno poslovanje postalo toliko zavisno od ručnih prenosa, tabela i znanja pojedinih kolega.

Smanjenje rizika ne znači da kompanija ne treba da se menja. To znači da promena ima jasan poslovni razlog, dobro definisane granice i proverljive posledice. Čak i tokom dobro planiranog manjeg razvoja, kompanija ostaje funkcionalna: računi se izrađuju, porudžbine se ispunjavaju, proizvodnja ne staje, a uključeni zaposleni znaju šta se dešava.

Rizik razvoja često je već prisutan u procesu

Mnoge organizacije greše kada odmah traže sistem ili automatizaciju za iritantan simptom. Ako fakturisanje kasni, traže novi modul za fakturisanje. Ako nema dobrog izveštaja, traže novu kontrolnu tablu. Ako ima previše e-mailova, uvode novi alat za upravljanje radnim procesima.

Ova rešenja mogu biti opravdana, ali ne uvek. Moguće je, na primer, da fakturisanje kasni jer se podaci o porudžbinama nalaze na tri različita mesta i nije jasno koji je izvor tačan. Kontrolna tabla bi samo brže pokazala iste pogrešne ili kasno unete podatke.

Najveći operativni rizik često nije sam stari sistem. Već proces u kojem ljudi služe kao veza između sistema, odeljenja i izvora informacija. Ako zaposleni ode na odmor, proces se usporava. Ako pogrešno unese broj artikla, greška se prenosi u skladište, fakturisanje ili komunikaciju sa klijentima. Ako vlasnik tabele nije dostupan, niko nije siguran koju verziju treba koristiti.

Zato razvoj sa niskim rizikom treba započeti ne ekranom ili tehnologijom, već konkretnim poslovnim procesom.

Kako planirati razvoj sa niskim rizikom u praksi?

Dobra polazna tačka je proces koji je dovoljno bolan da vredi poboljšati, ali dovoljno dobro definisan da ne otvara celokupno poslovanje kompanije odjednom. To može biti prenos porudžbina iz internet prodavnice u skladište, obrada dokumenata dobavljača, evidencija servisnih zahteva ili redovno ručno sastavljeni izveštaj menadžmenta.

Kod odabranog procesa vredi pratiti šta se zaista dešava. Ne ono što procedura kaže, već ono što kolege rade svakodnevno. Odakle dolaze informacije? Ko ih proverava? Koliko puta se isti podaci unose? Gde zadatak čeka na odobrenje? U kom koraku se telefonira ili piše e-mail jer sistem ne pokazuje nešto?

Mapiranje procesa često brzo otkriva da korak više nema stvarnu svrhu. Možda je tabela uvedena pre mnogo godina jer tadašnji sistem nije mogao da obradi neki podatak. U međuvremenu se sistem promenio, ali tabela je ostala i danas samo stvara dodatne provere, kopiranja i nesigurnost.

Cilj razvoja treba da bude formulisan na poslovnom jeziku. Cilj nije „integrisati sisteme“, već na primer da podaci o porudžbinama iz internet prodavnice stignu do tima zaduženog za ispunjenje bez ručnog unosa i proverljivo. Nije cilj „napraviti AI rešenje“, već da kolege brže pronađu podatke potrebne za donošenje odluka iz dolaznih dokumenata.

Manji obim, stvarni rezultat

Preveliki prvi korak čini projekat nepredvidivim. Ako razvoj istovremeno obuhvata prodaju, skladište, nabavku, fakturisanje i finansije, broj odluka brzo raste. Svaka iznimka, stara pravila i različiti načini rada zahtevaju dodatne konsultacije. Dok se rešenje ne završi, sama poslovna potreba može se promeniti.

Bolje je razviti prvu fazu koja sama po sebi donosi vrednost. Na primer, ne menjajte ceo lanac upravljanja porudžbinama odjednom. Prvo osigurajte da porudžbine iz internet prodavnice automatski i ujednačeno budu prikazane u internom operativnom sistemu. U sledećoj fazi može se rešavati rezervacija zaliha, zatim predaja transporteru ili obaveštavanje klijenata.

Ovo nije sporiji pristup. Često donosi brže opipljive rezultate, dok smanjuje šanse da ceo projekat krene u pogrešnom smeru zbog pretpostavke. Tokom prve faze korišćenja, otkriva se da li je originalna zamisao bila ispravna i sa kojim iznimkama se zapravo treba računati.

Smanjenje obima ne znači da treba zanemariti kasnije proširenje. Rešenje treba da se uklopi u sistemsko okruženje tako da kasnije ne mora biti odbačeno. Zato treba od početka razjasniti vlasnike podataka, sistemske veze, ovlašćenja i šta se smatra zvaničnim poslovnim podacima.

Rizik se može kontrolisati mernim tačkama

Razvoj je upravljiv kada menadžment ne vidi samo da se „radi“, već i da li poboljšava poslovanje. Za to nije potreban složen sistem pokazatelja. U procesu porudžbine može se meriti vreme utrošeno na ručni unos podataka, broj pogrešnih porudžbina, vreme obrade i koliko izuzetaka mora da rešava čovek.

Merenje treba početi pre promene. Ako nema početne vrednosti, kasnije se može raspravljati samo na osnovu utisaka da li je razvoj bio vredan. Može se desiti da novi proces u početku izgleda sporije jer čini vidljivim provere koje su ranije obavljane neformalno ili nedosledno. To nije nužno neuspeh. Treba razumeti da je usporavanje privremeni efekat učenja, potrebna kontrola ili stvarni problem u dizajnu.

Uslove za uspeh treba unapred definisati. Na primer: 95 procenata dnevnih porudžbina može se obraditi bez ručnog unosa; skladište vidi isto stanje kao i korisnička podrška; izrada finansijskog izveštaja smanjuje se sa tri sata na trideset minuta. Konkretan cilj pomaže da se odluči kada se može preći na sledeći korak i kada još treba poboljšati.

Uvođenje: sve se ne odlučuje na dan instalacije

Tehnički završeno rešenje nije nužno funkcionalno poslovno rešenje. Tokom uvođenja se otkriva da li se izuzetni slučajevi, odgovornosti i dnevni radni ritam zaista mogu rešiti. Zato je preporučljivo prvo koristiti novi proces u ograničenom obimu: za jednu grupu proizvoda, na jednoj lokaciji, za jedan tip klijenata ili za jedan određeni tim.

Paralelno funkcionisanje je u nekim slučajevima opravdano, ali ne treba ga održavati neograničeno. Ako stari i novi proces predugo koegzistiraju, zaposleni rade duplo, podaci se mogu razlikovati, i niko ne zna kojem sistemu da veruje. Bolje je unapred odrediti koliko traje kontrolisani probni period, ko odobrava njegov rezultat i pod kojim uslovima novi proces postaje primarni.

Plan povratka je takođe deo upravljanja rizikom. Ne zato što se očekuje da razvoj ne uspe, već zato što treba zaštititi poslovanje. Ako integracija pošalje pogrešne podatke, treba znati kako je zaustaviti, kako identifikovati pogođene transakcije i ko odlučuje o korekciji. Dobro dokumentovana mogućnost povratka čini uvođenje sigurnijim.

Znanje ljudi ne treba da ostane skrivena komponenta sistema

U rastućim kompanijama je često da ključna osoba pamti izuzetke: kojem klijentu treba poslati dokument u kojem formatu, koje podatke dobavljača treba posebno proveriti, ili zašto se određena porudžbina ne sme automatski preneti. To je dragoceno iskustvo, ali poslovni rizik ako postoji samo kod jedne osobe.

Cilj razvoja sa niskim rizikom nije da zameni ovog kolegu. Umesto toga, da njegovo znanje bude predstavljeno u proverljivim pravilima, vidljivim statusima i zajednički korišćenim radnim procesima. Tako on provodi manje vremena na ponavljajuću administraciju, a više na onome gde je zaista potrebno razmatranje, poznavanje klijenata ili stručna odluka.

Dokumentacija treba da bude kratka, ali korisna. Kod novog procesa, tim treba da zna šta se promenilo, šta treba da uradi u slučaju greške, kome se može obratiti i koje podatke ne sme slobodno menjati. Razjašnjenje odgovornosti za rad je jednako važno kao i sama lista zadataka za razvoj.

Najbolji prvi razvoj nije nužno najspektakularniji. Često je najvredniji onaj koji eliminiše svakodnevno polusatno kopiranje, čini vidljivim zaglavljenu porudžbinu ili oslobađa proces od jedne tabele. Ovi koraci ne samo da štede vreme: oni dokazuju da se poslovanje kompanije može razvijati kontrolisano, bez rizika sledećeg velikog skoka.