Kriteriji prihvata poslovne aplikacije trebaju odgovoriti na jedno pitanje prije početka izvedbe: može li ovlaštena osoba, na temelju dogovorenih ulaza i dokaza, potvrditi ispravan završetak poslovnog toka ili evidentirati odstupanje? Dobar kriterij nije opis ekrana ni općenita želja. To je provjerljiv scenarij s vlasnikom ulaza, poslovnom odlukom, očekivanim ishodom, iznimkom i mjerom prihvata.
Poslovni zahtjev često započinje kratkom rečenicom: "automatizirati odobravanje", "povezati skladište i prodaju" ili "uvesti AI pomoć u obradu dokumenata". Takva rečenica opisuje smjer, ali ne određuje što isporuka mora učiniti u stvarnom radu.
Bez kriterija prihvata različiti sudionici mogu pod istim zahtjevom razumjeti različite stvari. Korisnik može očekivati završenu narudžbu, računovodstvo ispravno knjiženje, a tehnički tim uspješan prijenos podatka. Sve tri provjere mogu biti važne, ali nisu ista poslovna odluka.
Kriteriji prihvata poslovne aplikacije služe za razdvajanje tih pitanja prije izrade. Oni pomažu utvrditi:
U ORKA pristupu polazište je poslovni proces i odgovornost, a ne samo funkcionalnost pojedinog sučelja. Screening poslovnog procesa može pomoći razdvojiti procesne odluke, podatke i prijelazne točke prije definiranja opsega izvedbe.
Najkorisniji oblik kriterija prihvata opisuje jedan konkretan poslovni tok. Za svaki tok zabilježite šest elemenata.
Navedite događaj koji pokreće radnju i točku na kojoj proces završava. Izbjegnite neodređene početke poput "kad stigne podatak". Precizniji početak može biti: zaprimljena je prodajna narudžba s identifikatorom kupca i stavkama.
Granica procesa također mora biti jasna. Završetak nije nužno prikaz poruke na ekranu. Može biti evidentirana narudžba, odobrenje odgovorne osobe, otvoren zadatak za obradu iznimke ili zapis u službenoj ERP transakciji.
Za svaki nužan ulaz navedite vlasnika. Vlasnik nije nužno osoba koja podatak tehnički prenosi. To je uloga odgovorna za točnost, potpunost ili poslovnu valjanost podatka.
Primjeri ulaza koje vrijedi razdvojiti:
Ako vlasnik nije određen, tehnička izvedba može prenijeti podatak, ali ne može riješiti poslovni spor o njegovoj valjanosti.
Kriterij treba imenovati odluku, ne samo aktivnost. Primjer odluke: smije li se narudžba pustiti u proizvodnju kada artikl nema potvrđen rok isporuke?
Uz odluku navedite donositelja odluke. To može biti prodajni voditelj, planer proizvodnje, računovodstvo ili druga imenovana poslovna uloga. Sustav može primijeniti unaprijed odobreno pravilo, no odgovornost za poslovno pravilo i njegovu izmjenu mora ostati vidljiva.
ORKA definira poslovnu odluku i način primopredaje s odgovornim ulogama. Za specijaliziranu inženjersku izvedbu, primjerice složeniju integraciju ili razvoj prilagođene komponente, relevantan je Trueforce: inženjerska izvedba .
Očekivani ishod mora biti vidljiv u sustavu rada. Navedite gdje nastaje službeni zapis i koja ga uloga može provjeriti.
Dobro formuliran ishod može glasiti: nakon potvrde raspoloživosti, sustav evidentira proizvodni nalog sa statusom koji dopušta planiranje, a planeru je dostupan identifikator naloga.
Takav opis ne propisuje unaprijed tehničko rješenje. Propisuje poslovni rezultat i zapis potreban za rad. Kod ERP procesa službena transakcija, dokument ili status često nosi veću težinu od obavijesti ili privremenog prikaza u pomoćnoj aplikaciji.
Iznimka nije rubna napomena. Ona pokazuje kako proces radi kada stvarni podaci ne odgovaraju idealnom toku.
Za svaku važnu iznimku navedite:
Primjer: ako dokument nema podatak potreban za knjiženje, sustav ne stvara službeno knjiženje. Računovodstvo prima zadatak za dopunu ili odbijanje, a razlog ostaje povezan s dokumentom. Mjera prihvata nije brzina rada bez provjere, nego mogućnost dokazivanja da nijedno nepotpuno knjiženje nije postalo službeni zapis kroz taj scenarij.
Dokaz dovršenog poslovnog toka treba biti dostupan osobi koja preuzima rješenje. Dokaz može uključiti identifikator dokumenta, status, zapis odluke, vezu između ulaznog i izlaznog dokumenta, evidentirani zadatak iznimke ili revizijski trag koji je već predviđen sustavom.
Mjeru prihvata formulirajte kao provjeru, bez izmišljanja početnih ili ciljnih vrijednosti. Primjeri:
Sljedeći je scenarij hipotetski. Ne opisuje ORKA klijenta ni isporučenu mogućnost određenog proizvoda.
Poslovni zahtjev: prodajna narudžba s proizvodnim artiklom treba pokrenuti provjeru prije planiranja proizvodnje.
Provjerljiv scenarij može sadržavati sljedeće:
Ovaj oblik izbjegava nejasan kriterij poput "integracija radi". Integracija može tehnički prenijeti poruku, a poslovni tok ipak može ostati nedovršen, pogrešno usmjeren ili bez odgovorne odluke.
Kada aplikacija koristi AI za razvrstavanje, sažimanje, izdvajanje podataka ili predlaganje radnje, kriterij prihvata mora razlikovati prijedlog od poslovne odluke. Potrebno je navesti tko pregledava prijedlog, kada je ljudska potvrda obvezna, što sustav radi pri nejasnom rezultatu i koji zapis ostaje iza prihvaćanja ili odbijanja.
DORA istraživanje o AI-potpomognutom razvoju softvera razmatra AI u kontekstu organizacije i isporuke. Taj izvor ne predstavlja obećanje učinka za pojedini ORKA projekt ili klijenta. Za konkretan proces potrebno je zasebno provjeriti kvalitetu ulaza, ovlasti, ljudski pregled, put iznimke i dokaz odluke.
Kod AI podrške korisno je prihvat formulirati kroz ponašanje procesa, primjerice:
Previše općeniti kriteriji ostavljaju prostor za različita tumačenja. Previše detaljni kriteriji mogu prerano zaključati izvedbu i prenijeti tehničke odluke u poslovni zahtjev. Ravnoteža nastaje kada kriterij precizno određuje poslovni rezultat, odgovornost i dokaz, a tehničkom timu ostavlja prostor za izvedbu unutar dogovorenih granica.
Ne treba svaki mogući rubni slučaj obraditi prije početka. Potrebno je odabrati iznimke s većim poslovnim utjecajem, češćim pojavljivanjem ili jasnim vlasnikom odluke. Preostale nepoznanice treba otvoreno evidentirati kao pretpostavke ili pitanja za provjeru, a ne prikazivati ih kao dogovorene činjenice.
Za svaki poslovni tok potvrdite sljedeće:
Ako zahtjev još ne može proći kroz ovaj popis, korisnije je prvo razjasniti proces nego započeti izvedbu na temelju općenite funkcionalnosti. Za strukturiranje takve odluke i primopredaje, razgovarajte s ORKA timom .