Vlasnik poslovnog procesa odgovara za svrhu, pravila, rezultat i promjene procesa. Izvršitelj obavlja korake procesa. Odobravatelj donosi odluku unutar zadanog praga. Tehnički vlasnik sustava održava sustav koji proces podržava, ali ne preuzima poslovnu odluku. Kada se pojavi iznimka, unaprijed određeni prag eskalacije mora usmjeriti slučaj osobi s ovlasti za odluku.
Upravljanje poslovnim procesima često zapinje zato što su te četiri uloge spojene u jednu nejasnu formulaciju: "netko iz prodaje", "financije", "IT" ili "voditelj". Takav opis ne govori tko može promijeniti pravilo, tko smije odobriti odstupanje ni tko snosi odgovornost za posljedicu odluke.
Naziv funkcije nije vlasništvo procesa. Direktor prodaje može biti vlasnik procesa od ponude do narudžbe, ali pojedine odluke unutar procesa može delegirati voditelju prodaje, kreditnom kontroloru ili voditelju skladišta. Slično tome, voditelj IT-a može biti tehnički vlasnik ERP konfiguracije, bez ovlasti za promjenu pravila odobravanja popusta.
Vlasnik poslovnog procesa ima poslovni mandat. On ili ona mora moći odgovoriti na četiri pitanja:
Ako odgovor glasi "dogovorit ćemo se", odgovornosti u procesu još nisu dovoljno definirane. Dogovor može biti koristan, ali ne može zamijeniti odluku, ovlast i zapis pravila.
Vlasnik definira cilj procesa, prihvatljiv rezultat, pravila i mjere za praćenje. Odlučuje o promjeni poslovnog toka kada promjena utječe na više timova, kupce, dobavljače, trošak, rizik ili rok usluge. Također određuje tko može odobravati pojedina odstupanja.
Ta osoba ne mora izvršavati svaki korak. Njezina odgovornost nije unos podataka, nego funkcioniranje toka od početka do kraja. Primjerice, u procesu nabave vlasnik može biti poslovna osoba odgovorna za nabavnu politiku, a ne administrator sustava koji održava obrazac zahtjeva za nabavu.
Izvršitelj provodi zadatak prema važećem pravilu. On prikuplja podatke, provjerava uvjete, evidentira događaj, šalje zahtjev na odobrenje ili zatvara korak. Izvršitelj ne bi trebao samostalno tumačiti nejasno pravilo niti trajno mijenjati tok rada zato što je pojedini slučaj nezgodan.
Dobra uputa izvršitelju navodi:
Odobravatelj odlučuje o konkretnom slučaju unutar ovlasti. Ovlast mora imati granicu: iznos, vrstu odstupanja, razinu rizika, utjecaj na rok ili kombinaciju tih elemenata. Bez granice odobravanje lako prerasta u opću konzultaciju, a odgovornost se vraća izvršitelju.
Odobrenje nije isto što i vlasništvo procesa. Odobravatelj može prihvatiti jednokratni izuzetak, ali ne bi trebao sam mijenjati trajno poslovno pravilo ako za to nema mandat vlasnika procesa.
Tehnički vlasnik sustava odgovara za konfiguraciju, integracije, pristupe, podatkovne kontrole i pouzdan rad sustava u okviru svoje uloge. On procjenjuje može li se poslovno pravilo provesti u ERP-u ili povezanom rješenju te upozorava na tehničke posljedice.
Tehnička izvedivost ipak nije poslovna odluka. Rečenica "sustav to ne dopušta" treba otvoriti provjeru konfiguracije, podataka, integracije i željenog pravila. Ne smije automatski postati razlog za napuštanje poslovne potrebe.
Proces je stabilniji kada svaki prijelaz između uloga ima jasan okidač, vlasnika i očekivani izlaz. Koristan je kratak opis za svaki korak, bez složenog dijagrama kao preduvjeta.
Za svaki prijelaz zapišite:
Ovaj okvir posebno je važan na granicama odjela. Prodaja može smatrati narudžbu spremnom za isporuku, dok financije čekaju kreditnu provjeru, a skladište čeka potvrđen termin. Bez zajedničkog statusa i pravila predaje, svaki tim vidi samo svoj dio posla.
Vodič za operativno upravljanje može pomoći pri razradi dnevnih upravljačkih ritmova oko takvih prijelaza.
Iznimka nije svaka neugodnost. Iznimka nastaje kada slučaj ne ispunjava uvjet redovnog toka ili kada redovni postupak proizvodi neprihvatljiv poslovni rizik. Prag eskalacije treba biti razumljiv izvršitelju i dovoljno precizan za dosljednu primjenu.
Prag može biti vezan uz:
Uz prag odredite i vrijeme reakcije. Ne mora svaka iznimka imati isti prioritet. Međutim, proces treba razlikovati slučaj koji može čekati dnevnu odluku od slučaja koji blokira isporuku ili zatvaranje razdoblja.
Eskalacija treba sadržavati činjenice, a ne samo zahtjev za pomoć: broj predmeta, odstupanje, posljedicu bez odluke, predložene opcije i rok u kojem odluka još ima smisla. Vlasnik procesa zatim može procijeniti je li riječ o pojedinačnom odobrenju, pogrešci podataka, tehničkom kvaru ili signalu za promjenu pravila.
Zamislite poslovni tok od zaprimanja kupčeve narudžbe do naloga za isporuku. Primjer ostaje na razini procesa, bez pretpostavke o određenom ERP rješenju.
Prodajni izvršitelj unosi narudžbu i provjerava kupca, artikle, cijenu, rok i obvezne podatke. Ako su svi uvjeti unutar dogovorenih pravila, narudžba prelazi u sljedeći korak prema planiranju ili isporuci.
Ako cijena odstupa od odobrenog cjenika unutar unaprijed postavljenog praga, narudžba ide odobravatelju s ovlasti za komercijalno odstupanje. Odobravatelj može prihvatiti ili odbiti pojedinačnu narudžbu te obrazložiti odluku u zapisu predmeta.
Ako odstupanje prelazi prag, utječe na ugovorni uvjet ili se ponavlja kod više narudžbi, slučaj ide vlasniku poslovnog procesa. Vlasnik ne mora ručno odobriti svaku narudžbu. Njegov posao je odlučiti treba li zadržati pravilo, promijeniti prag, otvoriti novi komercijalni model ili pokrenuti analizu uzroka.
Ako sustav ne može provesti odabrano pravilo, tehnički vlasnik procjenjuje promjenu konfiguracije, integracije, podataka ili kontrole pristupa. Poslovni vlasnik odobrava poslovnu namjeru promjene, a tehnički vlasnik vodi izvedbu unutar tehničkog opsega. Nakon promjene treba provjeriti radi li tok prema dogovorenom pravilu i ostaje li trag odluka dostupan korisnicima procesa.
Ponavljana iznimka često otkriva slabost procesa, ali nije svaka ponovljena iznimka dokaz da pravilo treba ukinuti. Prije promjene korisno je razlikovati četiri uzroka:
Vlasnik procesa treba odlučiti o promjeni na temelju zabilježenih slučajeva i poslovne posljedice. Izvršitelj može predložiti poboljšanje. Odobravatelj može ukazati na učestalost odstupanja. Tehnički vlasnik može objasniti ograničenja i opcije provedbe. Nijedna od tih uloga sama ne zamjenjuje odluku o novom procesu.
Promjena bi trebala imati jasan opseg: koje pravilo se mijenja, od kada vrijedi, na koje slučajeve se odnosi, tko je obaviješten i kako će se pratiti učinak. Time se izbjegava stvaranje paralelnih uputa u e-pošti, usmenih dogovora i lokalnih radnih zaobilaznica.
Previše razina odobravanja može smanjiti rizik pojedinačne odluke, ali često usporava tok i skriva odgovornost. Premalo kontrola ubrzava izvršenje, ali povećava vjerojatnost nedosljednih odluka. Pravi raspored ovlasti ovisi o vrijednosti, riziku, učestalosti i posljedicama procesa.
Također, jedna osoba ponekad nosi više uloga, osobito u manjim organizacijama. To samo po sebi nije problem ako su ovlasti izričito zapisane. Problem nastaje kada ista osoba čas djeluje kao izvršitelj, čas kao odobravatelj, a poslije nitko ne može utvrditi na temelju kojeg pravila je odluka donesena.
Procesna dokumentacija ne mora biti opsežna. Za početak je često dovoljno imenovati vlasnika procesa, opisati ključne prijelaze, postaviti pragove eskalacije i evidentirati najčešće iznimke. Tek tada automatizacija u ERP-u ili kroz integracije dobiva stabilna poslovna pravila.
Odaberite proces u kojem odluke često čekaju: od narudžbe do isporuke, od zahtjeva do nabave ili od rada do knjiženja. Za posljednjih nekoliko iznimaka utvrdite tko je izvršavao korak, tko je imao ovlast odobrenja, tko je trebao odlučiti o promjeni i gdje je odluka zapisana.
Ako te odgovore nije moguće dati brzo i jednako za svaki slučaj, proces treba razjasniti prije veće sistemske promjene. ORKA pristup u ERP i procesnom screeningu može poslužiti kao strukturiran početak za mapiranje odgovornosti, prijelaza i iznimki prije odabira ili prilagodbe rješenja.