AI u razvoju softvera uprava treba procjenjivati kroz ishod isporuke: prihvaća li korisnik promjenu, radi li stabilno u stvarnom procesu i koliko se brzo otklanjaju problemi. Broj generiranih linija koda, završeni zadaci ili kraće vrijeme pisanja koda mogu biti korisni operativni signali, ali nisu poslovni dokaz vrijednosti. Poslovno mjerenje AI potpomognutog razvoja počinje povezivanjem brzine izrade s prihvatom, kvalitetom i vremenom oporavka.
Stručni autor: Ivan Lozančić Stručni recenzent: Tomislav Strugačevac
AI alati mogu promijeniti način pripreme koda, testova, dokumentacije i analize grešaka. To može skratiti pojedine korake rada. Međutim, isporuka softvera prolazi i kroz poslovna pravila, integracije, podatke, sigurnosne provjere, korisnički prihvat i rad u produkciji.
Ako tim završava više razvojnih zadataka, a poslovni korisnici odbijaju promjene ili se nakon objave povećava broj incidenata, veća brzina nije nužno napredak. Slično vrijedi kada se incidenti rješavaju sporije jer tim prvo mora razumjeti kod, odluke ili vanjske ovisnosti nastale tijekom razvoja.
Uprava stoga ne treba pitati samo: "Koliko je brže izrađeno?" Korisnija pitanja su:
Ovakav pristup ne umanjuje korist AI-a. On usmjerava procjenu na rezultat koji poslovanje stvarno koristi.
DORA State of AI-assisted Software Development 2025 promatra AI potpomognuti razvoj u kontekstu organizacije i isporuke softvera. Taj je okvir koristan upravi jer razvoj ne promatra kao izoliranu aktivnost programera, nego kao dio sustava ljudi, procesa, platformi i načina rada.
Nalaze takvog istraživanja treba čitati metodološki oprezno. Istraživanje može pokazati obrasce i povezanosti među praksama, organizacijskim uvjetima i prijavljenim ishodima. Ne daje automatski uzročnu formulu za pojedinu organizaciju. Razlike u vrsti proizvoda, naslijeđenim sustavima, kvaliteti podataka, reguliranim procesima, složenosti integracija i zrelosti tima mogu bitno promijeniti rezultat.
Za ORKA klijenta DORA nije obećanje učinka. To je poticaj za provjeru vlastitog sustava isporuke: gdje AI mijenja tok rada, tko provjerava izlaz i koje poslovne posljedice treba mjeriti.
Najkorisniji okvir povezuje četiri razine. Svaka razina treba imati vlasnika, dokaz i odluku.
Početak nije AI alat, nego jasno definiran zahtjev. Vlasnik poslovnog procesa treba opisati problem, korisnike, pravila, dopuštene iznimke i posljedicu pogreške. Kod ERP promjene to uključuje službene transakcije, uloge, matične podatke, knjiženja i integracije na koje promjena utječe.
Vlasnik ulaza može biti poslovni vlasnik procesa, uz potvrdu odgovorne osobe za sustav. Razvojni tim ne bi trebao samostalno pretvarati nejasan zahtjev u poslovno pravilo samo zato što AI može brzo predložiti implementaciju.
Dokaz prihvata ulaza može biti odobren skup scenarija: redovni tok, rubni slučaj, zabranjena radnja i postupak povratka na prethodno stanje.
Tim može koristiti AI u odabranim koracima, primjerice za nacrt koda, prijedlog testova, objašnjenje postojećeg modula ili analizu zapisa greške. Odgovornost za odluku i provjeru ostaje kod ljudi koji isporučuju promjenu.
Pratite vrijeme od odobrenog zahtjeva do promjene spremne za provjeru, ali uz njega pratite pokrivenost dogovorenih scenarija, rezultat pregleda koda i status provjera integracija. Mjera brzine bez dokaza provjere potiče pogrešan optimizam.
Za promjene s većim poslovnim rizikom uvedite eksplicitni trag: koji je AI izlaz korišten, što je izmijenjeno, tko je pregledao rješenje i na temelju čega je odobreno. Takav trag nije administracija radi administracije. Omogućuje kasniju analizu kada dođe do odstupanja.
Poslovni prihvat treba potvrditi očekivani ishod, ne samo tehničku izvedbu. Primjerice, kod promjene obračunskog pravila prihvat ne završava prolaskom automatiziranog testa. Potrebno je provjeriti očekivani rezultat službene transakcije, knjiženje, izvještaj, ovlasti korisnika i ponašanje integracije kada nedostaje ili kasni podatak.
Mjeru prihvata oblikujte kao provjerljivu izjavu: svi unaprijed odobreni scenariji imaju zabilježen očekivani i stvarni rezultat, a odstupanja imaju odluku vlasnika procesa. Ne treba izmišljati početnu ni ciljnu vrijednost prije prvog mjerenja. Najprije treba ustanoviti pouzdan način prikupljanja podataka.
Nakon objave pratite incidente vezane uz promjenu, vrijeme do uočavanja problema, vrijeme do ograničavanja učinka i vrijeme do trajnog rješenja. Razdvojite hitni povratak na prethodno stanje od stvarnog uklanjanja uzroka. Oba podatka imaju vrijednost, ali odgovaraju na različita pitanja.
Kvaliteta i stabilnost isporuke nisu samo odgovornost razvoja. Vlasnik procesa procjenjuje poslovni učinak, operativni tim vodi postupanje u incidentu, a razvojni tim analizira i uklanja tehnički uzrok. Uprava treba osigurati jasne granice odgovornosti prije prve ozbiljne iznimke.
Zamislimo hipotetsku promjenu u ERP integraciji. Tim uz AI pomoć brzo pripremi izmjenu mapiranja podataka i objavi je nakon prolaska osnovnih testova. U produkciji rijedak format ulaznog podatka prekine obradu dijela dokumenata. Problem se može brzo vratiti na staro stanje, ali analiza traje dulje jer dokumentacija odluke i pokrivenost rubnog slučaja nisu jasne.
Zaključak nije da AI uzrokuje problem. Uzrok može biti nepotpun zahtjev, izostanak scenarija, slab pregled ili nejasna odgovornost. Lekcija je drugačija: brzina izrade treba ostati povezana s kvalitetom ulaza, prihvatnim kriterijima i mogućnošću brzog oporavka.
Jedinstveni skup metrika neće odgovarati svakom timu. Manja interna automatizacija i promjena koja utječe na financijske evidencije nemaju isti rizik ni istu razinu provjere. Previše mjera može usporiti odlučivanje, a premalo mjera skriva posljedice.
Važno je izbjeći i pogrešnu upotrebu mjerenja. Metrika ne smije postati individualni rang programera prema količini proizvedenog koda ili broju zatvorenih zadataka. Takav pristup može potaknuti količinu umjesto razumijevanja, suradnje i održivosti.
Dobro početno pitanje glasi: koja odluka postaje bolja uz ovu mjeru? Ako mjera ne pomaže odlučiti o ulaganju, opsegu provjere, prihvatu ili načinu rješavanja incidenta, vjerojatno nije prioritet.
Prije šire primjene AI potpomognutog razvoja zabilježite sljedeće:
Ako je prvi korak nejasan, krenite od Screeninga poslovnog procesa . Za organizacije koje žele povezati svakodnevnu suradnju, ERP službene transakcije i odgovornost kroz operativni model, koristan je i ORKA operativni sustav .