Zahtjev poput "treba nam ekran za odobravanje" rijetko je dovoljan za dobar razvoj poslovnog softvera. Prije sučelja treba razumjeti što se odobrava, prema kojem pravilu, tko odlučuje, što slijedi nakon odbijanja i kako se ispravlja pogreška. Održivi proizvod nastaje kada tim prvo modelira stvarni rad i odluke, a zatim izgradi jedan cjelovit, provjerljiv tok.
Takav redoslijed ne usporava razvoj softvera. Smanjuje vjerojatnost da se brzo isporuči funkcija koja radi samo u idealnom slučaju, dok korisnici i dalje vode iznimke u tablicama, e-mailovima ili usmenim dogovorima.
Radionica i procesni dijagram korisni su početak, ali najčešće opisuju kako bi posao trebao izgledati. Stvarni zadatak pokazuje kako ljudi doista dolaze do odluke: gdje traže podatke, koga pitaju za potvrdu, koje iznimke provjeravaju i što zapisuju izvan sustava.
Zato otkrivanje procesa ne treba svesti na popis željenih ekrana. Kombinirajte:
Važna je razlika između poslovnog pravila i navike nastale zbog starog alata. Ako referent ručno kopira podatak iz jednog sustava u drugi, to ne znači nužno da kopiranje treba automatizirati. Možda podatak treba postati dostupan na pravom mjestu, možda se izvor mora povezati integracijom, a možda se pravilo koje traži kopiranje više ne može jasno objasniti.
Ova provjera sprečava da poslovni softver pretvori ograničenje starog procesa u trajnu funkciju. Ujedno daje timu konkretnu osnovu za odluku: koji je zadatak važan, koji podatak nedostaje i koja osoba nosi odgovornost u pojedinoj točki toka.
Poslovni objekt ima životni ciklus. Ponuda može biti nacrt, poslana, prihvaćena, odbijena ili istekla. Radni nalog može čekati materijal, biti u radu, zaustavljen ili završen. Te oznake nisu samo prikaz na ekranu. One određuju što je dopušteno, što se mora evidentirati i kakva je posljedica sljedeće radnje.
Za svako stanje korisno je definirati:
Ovaj model iznosi logiku iz sučelja na vidljivo mjesto. Bez njega pravila lako završe skrivena u gumbima, porukama ili nepisanim uputama korisnicima. Posljedica se često pokaže tek pri promjeni procesa: nije jasno zašto se određena radnja ne može izvršiti, tko može riješiti zastoj ili koji podatak druga integracija smije preuzeti.
Jasna stanja i prijelazi olakšavaju i povezivanje s drugim dijelovima poslovanja. Primjerice, nalog koji čeka materijal može imati drukčiji učinak na planiranje, nabavu i izvještavanje od naloga koji je stvarno zaustavljen. Kada su definicije jasne, povezano poslovanje ne ovisi o različitim tumačenjima istog statusa.
Prva verzija ne mora imati sve ekrane. Treba omogućiti jedan cijeli tok kroz sučelje, poslovna pravila, podatke i izvještaj ili drugi provjerljiv izlaz. Takav vertikalni rez korisniku omogućuje obavljanje stvarnog zadatka, a timu otkriva nedorečenosti u modelu procesa.
U primjeru odobravanja, minimalni cjeloviti tok može izgledati ovako:
Ovo nije samo manja verzija konačnog rješenja. To je provjera važnih pretpostavki. Tim rano saznaje nedostaje li ovlast, je li neki pojam različito shvaćen, može li se pogreška ispraviti bez zaobilaženja sustava i daje li izvještaj odgovor koji poslovni vlasnik zaista treba.
Deset djelomično izgrađenih ekrana može ostaviti dojam napretka, ali ne pokazuje prolazi li posao kroz sustav. Vertikalni rez izlaže cijeli lanac stvarnim pitanjima prije nego što se opseg i trošak prošire.
Stavka backloga poput "dodati novi filter" unaprijed zaključava rješenje, a ne objašnjava potrebu. Ne govori tko ima problem, u kojem zadatku, zbog čega sadašnji tok ne radi i kako će tim provjeriti da je promjena pomogla.
Bolja stavka može opisati sljedeće:
Primjer: referent prodaje pri pripremi poziva ne može brzo pronaći kupce s dospjelim ponudama, pa ručno izvozi podatke. Očekivanje je da pregled otvorenih ponuda po datumu ukloni izvoz i skrati pripremu. Tim tada može predložiti filter, spremljeni pogled, izvještaj ili drukčiji tok. Rješenje nije zaključano prije razumijevanja problema.
Takav pristup product developmentu ostavlja prostor za tehničku procjenu i poslovnu odluku. Također olakšava naknadnu provjeru: koristi li se promjena, je li ručni izvoz zaista nestao i pojavljuje li se nova prepreka na drugom dijelu procesa.
Funkcija nije dovršena zato što radi s potpunim i ispravnim podacima. Poslovni procesi uključuju nepotpune unose, pogrešne odluke, promjene ovlasti i podatke koji dolaze iz drugih sustava. Zato održivi poslovni softver treba predvidjeti barem:
Svaka posebna iznimka povećava površinu za testiranje, dokumentaciju i buduću promjenu. Iznimke ipak ne treba uvijek odbiti. Neke su nužne zbog stvarne poslovne obveze ili važnog rizika. Međutim, prije gradnje vrijedi postaviti pitanje: je li poslovna vrijednost jasna i može li se proces prvo pojednostaviti?
Odluka što se neće graditi dio je odgovornog razvoja softvera. Privremena kompatibilnost sa starim tokom također treba imati vlasnika i rok. Ako novi tok dokaže da radi, stari tok treba ugasiti. Inače oba toka nastavljaju stvarati kod, podršku i nejasnoće.
Broj isporučenih funkcija malo govori o tome pomaže li proizvod radu. Korisnije je pratiti pitanje može li korisnik završiti stvaran zadatak bez nepotrebnog zaobilaženja sustava.
Ovisno o procesu, tim može promatrati:
Ovi signali nisu zamjena za poslovnu prosudbu. Oni pomažu da se rasprava ne vodi samo po dojmu ili broju zahtjeva. Funkcija koju nitko ne koristi nije neutralna: povećava kod, testove, dokumentaciju i broj budućih odluka.
Razvojni tim treba vidjeti posljedicu koda u svakodnevnom radu. Poslovni vlasnik treba razumjeti tehnički trošak posebnog pravila, integracije ili paralelnog toka. Kada se te perspektive redovito susreću, proizvod se razvija kao cjelina, a ne kao niz nepovezanih narudžbi.
Za početak odaberite jedan čest, važan i dovoljno ograničen zadatak. Prikupite stvarne primjere, definirajte stanja, prijelaze i odgovornosti te dogovorite što će dokazati da je novi tok koristan. Zatim planirajte vertikalni rez koji uključuje pravilo, podatak, korisničku radnju i provjerljiv ishod.
Kada proces uključuje ERP, proizvodnju, računovodstvo ili više povezanih modula, ERP i procesni screening može pomoći razdvojiti stvarna poslovna pravila od ograničenja postojećeg alata prije nego što razvojni opseg postane obveza. ORKA taj slijed povezuje kroz mapiranje procesa, dizajn toka, razvoj i provjeru stvarnog rada.