Mali projekt ne gubi smjer zbog samog dodatnog zahtjeva, nego kada tim prihvati promjenu bez jasne odluke o koristi, utjecaju i dijelu posla koji odlazi u kasniji ciklus. Kontrola opsega poslovne aplikacije počinje jednostavnim pravilom: prvo provjeriti radi li dogovoreno ponašanje. Ako radi, novi prijedlog tretirati kao promjenu opsega, a ne kao kvar koji se mora odmah otkloniti.
To pravilo čuva dogovoreni poslovni cilj, budžet vremena i odgovornost za odluke. Posebno je važno u ERP projektima, računovodstvenim tokovima, proizvodnji i integracijama, gdje mala izmjena često utječe na podatke, službene transakcije, ovlasti ili svakodnevni rad tima.
Prije rasprave o zahtjevu zapisati cilj postojećeg ciklusa u jednoj provjerljivoj rečenici. Primjer strukture:
Cilj nije popis svih želja. On je granica za odluku. Ako je cilj, primjerice, uredno evidentirati odobrenu narudžbu kroz dogovorenu ERP transakciju, dodatni prikaz, drugačiji izvoz ili novo pravilo obavijesti nisu automatski dio tog cilja. Mogu imati vrijednost, ali zahtijevaju zasebnu odluku.
Za početno razjašnjenje procesa koristan je Screening poslovnog procesa . Njegova je svrha utvrditi tok rada, službene izvore podataka, odgovorne uloge i točke na kojima promjena može proizvesti operativni rizik.
Najčešća greška nastaje kada se svaka prijava nazove "bugom". Naziv ubrzava prihvaćanje posla, ali prikriva promjenu dogovora.
Kvar u dogovorenom ponašanju postoji kada sustav ne radi ono što je već potvrđeno u opisu, kriteriju prihvata ili demonstriranom toku. Primjeri pitanja:
Novo ponašanje postoji kada korisnik traži novu radnju, dodatni podatak, drugačije pravilo, novu integraciju, novu ulogu ili izmijenjeni prikaz koji nije bio dio dogovora. Zahtjev može biti razuman i hitan, ali nije kvar samo zato što se pojavio tijekom testiranja.
Postoji i treća kategorija: nejasan dogovor. U tom slučaju ne odlučivati prema dojmu. Prikupiti zapis odluke, testni slučaj i stvarni podatak koji pokazuje razliku. Ako prethodni dogovor nije dovoljno određen, potrebno je prvo utvrditi tumačenje koje vrijedi za nastavak rada.
Odluka o dodatnom zahtjevu nije pitanje sviđa li se timu prijedlog. Potrebno je povezati zahtjev s poslovnom koristi, utjecajem i odgodom.
Za svaki zahtjev prikupiti kratak zapis:
Ovaj zapis ne mora biti dug. Njegova vrijednost leži u tome što sprječava nevidljivu razmjenu prioriteta. Svaki prihvaćeni dodatak mijenja raspoloživi kapacitet, čak i kada sama izrada izgleda mala. Treba uključiti analizu, razvoj ili konfiguraciju, provjeru podataka, testiranje, dokumentiranje i komunikaciju s korisnicima.
Prihvaćanje promjene bez uklanjanja ili pomicanja drugog rada nije plan, nego pretpostavka o dodatnom kapacitetu. U malom projektu takva pretpostavka brzo ugrožava osnovni cilj.
Pri donošenju odluke navesti jednu od sljedećih posljedica:
Bez imenovane odgode tim ne može procijeniti stvarni prioritet. Rečenica "učinit ćemo i jedno i drugo" ne opisuje odluku.
Pretpostavimo da je cilj malog ciklusa omogućiti računovodstvu unos i provjeru odobrenih ulaznih računa u dogovorenom ERP toku. Tijekom korisničke provjere pojavljuje se zahtjev za novim izvozom podataka za vanjsku analizu.
Prvo pitanje glasi: radi li postojeći unos i provjera prema dogovorenim kriterijima? Ako ne radi, riječ je o kvaru ili nejasnom dogovoru unutar postojećeg opsega. Ako radi, izvoz je novi zahtjev.
Sljedeći korak nije automatska procjena tehničkog rješenja. Poslovni vlasnik treba navesti čemu izvoz služi, koji se podaci smiju uključiti, tko ga koristi i kakva je posljedica čekanja. Tehnički i procesni vlasnici zatim procjenjuju utjecaj na izvor podataka, ovlasti, format, integraciju i testiranje.
Ako se izvoz prihvati sada, odluka treba sadržavati i odgodu. To može biti kasniji prikaz pomoćnog statusa, druga varijanta obavijesti ili drugi prethodno planirani dodatak. Ako nema prihvatljive odgode, novi izvoz prelazi u sljedeći ciklus. Time se ne odbacuje poslovna potreba, nego se čuva odgovornost prema postojećem cilju.
Za male promjene često je dovoljan redovit, kratak pregled otvorenih zahtjeva. Pregled treba imati stalne sudionike: poslovnog vlasnika, vlasnika procesa, osobu odgovornu za ERP službene transakcije gdje je primjenjivo, te tehničkog vlasnika.
Na pregledu ne raspravljati samo o rješenju. Proći kroz četiri pitanja:
ORKA pristup naglašava vlasništvo nad poslovnim procesom i svakodnevnom suradnjom, dok ERP službene transakcije ostaju mjerodavan operativni zapis. Kada promjena traži specijaliziranu inženjersku izvedbu, relevantan je i Trueforce: inženjerska izvedba . Podjela odgovornosti treba biti vidljiva prije početka rada, ne tek nakon problema.
AI prijedlog u malom projektu ne treba automatski dobiti poseban status. Zahtjev poput sažimanja dokumenata, klasifikacije upita ili pripreme nacrta također mora imati poslovnog vlasnika, određen ulaz, dopuštenu upotrebu rezultata i kriterij prihvata.
DORA istraživanje o AI-potpomognutom razvoju softvera za 2025. razmatra AI u kontekstu organizacije i isporuke. Taj kontekst podržava potrebu za jasnim procesom, ljudskom odgovornošću i provjerom rada. Ne predstavlja obećanje učinka za pojedini ORKA projekt ili klijenta.
Kod AI promjene posebno provjeriti:
Kontrola opsega ne uklanja sve neizvjesnosti. Otkrivanje stvarnih podataka, povezanih procesa ili iznimaka može pokazati da je početna procjena bila nepotpuna. Tada problem ne treba skrivati iza prvotnog plana. Treba ažurirati utjecaj, ponovno potvrditi prioritet i evidentirati promijenjenu odluku.
Okvir također ne služi odbijanju korisnika. Njegova je svrha učiniti kompromise vidljivima. Ponekad je novi zahtjev toliko važan da treba promijeniti glavni cilj ciklusa. Takva promjena je legitimna kada poslovni vlasnik preuzme odluku i kada tim jasno navede što zbog nje više nije dio isporuke.
Prije početka rada zatvoriti sljedeći popis:
Ako otvoreni zahtjevi redovito prelaze dogovoreni cilj, sljedeći korak nije dodavanje još jedne liste želja. Potrebno je ponovno pogledati proces, odgovornosti i granice ciklusa. ORKA tim može pomoći u tom razgovoru kroz Razgovarajte s ORKA timom .