Automatizacija koja se isplati: kako meriti ROI, ne osećaj

Najopasnija rečenica u automatizaciji je "čini mi se da nam sad ide brže". Prvi put kad sam morao da pokažem uštedu nekome ko plaća račun, shvatio sam da nemam šta da pokažem, jer nisam izmerio kako je bilo pre. Od tada merenje postavljam pre prve linije koda, i ova stvar mi je promenila način na koji projektujem sisteme.

Osećaj je loš instrument, i to je dokazano

Ako verujete svom osećaju da vam AI ili automatizacija štedi vreme, imate manje podataka nego što mislite. METR je jula 2025. objavio randomizovani kontrolisani eksperiment sa iskusnim open-source programerima: sa AI alatima su im zadaci trajali 19% duže. Pre rada su očekivali ubrzanje od 24%, a posle rada su i dalje verovali da su bili oko 20% brži (METR). Uzorak je mali (16 programera, 246 zadataka u zrelim repozitorijumima), pa ne treba to čitati kao zakon prirode. Ali pouka je jasna: ljudi koji su iznutra gledali sopstveni rad pogrešili su u smeru i po predznaku.

Ne tvrdim da automatizacija ne štedi vreme. Moji sistemi štede, i to merljivo. Tvrdim da bez baseline-a ne možete da razlikujete uštedu od utiska uštede. Isto važi u drugom smeru: jedan izolovan eksperiment (GitHub je za Copilot izmerio ubrzanje od 55% na jednom zadatku, pisanju HTTP servera) ne sme da postane vaše očekivanje za sve poslove. Jedan zadatak nije portfolio.

Baseline pre koda: šta tačno merim pre nego što išta izgradim

Pre nego što napišem prvi Lambda handler ili prompt, tražim tri broja za proces koji se automatizuje: koliko se puta dešava, koliko traje kad ga radi čovek i koliko puta pođe po zlu. Bez ova tri nema ROI-ja, samo nade.

Moj minimalni list za baseline izgleda ovako:

Poslednja stavka mi je presudna. U više projekata se ispostavilo da je čovek "aktivno" radio na zadatku petnaest minuta, a zadatak je ležao danima. Automatizacija nije uštedela petnaest minuta rada, ona je uklonila dane čekanja. To su dve različite vrednosti i dva različita broja, i ako ih ne razdvojite na početku, ne možete da ih objasnite na kraju.

Praktičan savet: baseline merim dve do četiri nedelje pre puštanja sistema, ako je proces dovoljno čest. Ako nije, uzimam istorijske podatke iz sistema u kojem proces već živi. Ne postoji proces koji ne ostavlja trag, samo procesi čiji trag niko nije pogledao.

Tri metrike koje pretvaraju priču u broj

Za svaki projekat vezujem rezultat za tri veličine: sati ušteđeni mesečno, trošak godišnje i usklađenost sa SLA. Svaka ima svoje zamke.

Sati ušteđeni mesečno. Formula je prosta: (vreme po zadatku pre − vreme po zadatku posle) × obim. "Posle" mora da uključi ljudski rad koji ostaje: pregled izlaza, rukovanje izuzecima, održavanje. Ako sistem obrađuje 90% slučajeva sam, a 10% ide čoveku, ti procenti nisu besplatni. Pri svakom takvom računu, pa i na 4-sistemskom ecosystem-u koji sam radio, pazim da vreme koje ljudi troše na pregled izuzetaka uđe u "posle".

Trošak godišnje. Ovde se ljudi sapliću o tokene, a zapravo ih treba pogledati ozbiljno, ali ne preterano. Cena modela se menja i zavisi od izbora. Na primer, prema zvaničnoj dokumentaciji Claude Sonnet 5.5 košta $2 po milionu ulaznih i $10 po milionu izlaznih tokena (dokumentacija), dok Haiku 5.5 košta $0.10 ulaz i $0.50 izlaz za promptove do 100.000 tokena (dokumentacija). Razlika između modela je oko 20 puta, pa izbor modela nije kozmetika nego stavka budžeta.

Tri stvari iz cenovnika koje redovno propuste u kalkulacijama:

• Batch API daje popust od 50% na ulazne i izlazne tokene, što za asinhrone poslove koji ne traže odgovor odmah menja računicu.
• Pogodak u kešu košta 5% standardne ulazne cene (na Sonnetu 5.5 $0.10 po milionu tokena), pa sistemi sa dugim ponovljenim kontekstom koštaju manje nego što izgleda na prvi pogled (cenovnik).
• Korišćenje alata dodaje skrivene ulazne tokene: sistemski prompt za alate na Sonnetu 5.5 i Haiku 5.5 je 286 tokena za tool_choice auto ili none. To ulazi u svaki poziv, pa na milionima poziva nije zanemarljivo.

Cene proveravam na zvaničnoj stranici u trenutku kalkulacije, ne iz sećanja i ne sa agregatora, jer se menjaju. Ali iskreno, u projektima koje sam pratio, tokeni često nisu dominantna stavka, a inženjerski sati za izgradnju i održavanje jesu, pa ih uvek stavljam u isti račun.

SLA. Ovde pomaže pozajmljena disciplina iz SRE sveta. Prema Google SRE knjizi, SLA je ugovor sa korisnicima koji uključuje posledice ispunjenja ili neispunjenja SLO-a, SLO je ciljna vrednost, a SLI je kvantitativna mera nivoa usluge (Google SRE). Tri sloja, tri različita pojma, i ljudi ih stalno mešaju. Kad sam gradio serverless AWS + Zendesk integraciju, rezultat je bio prva usklađenost sa SLA u istoriji tog tima. Ta rečenica ima smisla samo zato što su SLI i SLO bili definisani pre izgradnje: znali smo šta je "dobar događaj" (tiket odgovoren u roku), šta je ukupan broj događaja, i koji procenat ciljamo.

Definišite SLI kao odnos, i čuvajte rezervu

Najkorisnija stvar koju sam preuzeo iz SRE prakse jeste da SLI bude odnos dobrih događaja i ukupnog broja događaja, kako preporučuje Google SRE Workbook (Workbook). Ne "prosečno vreme odgovora", nego "udeo tiketa odgovorenih u roku". Prvo je broj koji se lepo gleda, drugo je broj koji se može ugovoriti.

Ista knjiga razlikuje i budžet greške: 100% minus SLO. Primer iz Workbook-a: SLO od 99.9% na 3 miliona zahteva u četiri nedelje daje budžet od 3.000 grešaka. Meni je ovo korisno i za poslovne automatizacije, ne samo za servise. Ako je cilj da 95% faktura bude obrađeno bez ljudske intervencije, onda 5% je budžet za izuzetke, i svaka nedelja se meri prema njemu, a ne prema utisku.

Dve praktične napomene:

• Google navodi da je SLO iz ugovora obično blaži od internog SLO-a, na primer 99.9% mesečno u ugovoru naspram internog cilja od 99.95% (Google Cloud). Primenjujem istu logiku: onome ko plaća obećavam manje nego što sam sebi zadajem. Rezerva je jeftina, izvinjenje nije.
• Latenciju ne merim prosekom. Prosek može da sakrije repne latencije, zato koristim percentile (Google SRE). Automatizacija koja je u proseku brza, a svaki dvadeseti zahtev čeka deset minuta, ne ispunjava SLA, ma kako lep bio prosek.

Kako izgleda račun na kraju (ilustrativan primer)

Evo izmišljenog, okruglog primera da se vidi struktura, ne stvarni projekat:

Proces: obrada zahteva (ilustrativno)
Obim:                1.000 zahteva / mesec
Pre:                 12 min po zahtevu = 200 h/mesec
Posle:               automatski 85%, čovek 15% sa 8 min pregleda
                     = 15% * 1000 * 8 min = 20 h/mesec
Ušteda:              180 h/mesec

Trošak sistema:      infrastruktura + tokeni + održavanje (godišnje)
Ušteda godišnje:     180 h * 12 * (cena sata)
ROI godine 1:        (ušteda - trošak izgradnje - trošak rada) / trošak

Obratite pažnju na dve stvari. Prvo, trošak izgradnje je u imeniocu, ne samo trošak rada, i to je razlog što prva godina izgleda drugačije od druge. Drugo, sve veličine u formuli su ili izmerene ili zadate unapred. Kod mene je 4-sistemski ecosystem dao 192% ROI u prvoj godini upravo zato što je račun postavljen pre izgradnje, pa sam na kraju mogao da uporedim stvarnost sa planom, a ne sa sopstvenim sećanjem na plan.

Šta bih ja uradio

Ako danas krećete u automatizaciju, redosled bih postavio ovako:

1. Izaberite jedan proces i izmerite ga dve do četiri nedelje pre bilo čega drugog. Obim, vreme (medijana i 90. percentil), stopa ponovnog rada, vreme čekanja.
2. Napišite SLI kao odnos i dogovorite interni SLO strožiji od onoga što ćete nekome obećati.
3. Sastavite račun pre izgradnje, uključujući izgradnju, održavanje i ljudski pregled izuzetaka. Cene modela uzmite sa zvanične stranice na dan kalkulacije.
4. Odlučite unapred šta znači neuspeh. Ako posle tri meseca uštede nisu iznad praga, šta radite? Pravilo koje postavite pre rezultata ne može da se prilagodi rezultatu.
5. Merite posle istim instrumentom kojim ste merili pre. Ne "kako vam se čini", nego iste kolone, isti uzorak.

Ako baseline pokaže da proces nije dovoljno čest ili skup da bi se isplatio, to je pun uspeh merenja: uštedeli ste izgradnju sistema koji ne treba. Ja takve projekte odbijam bez griže savesti, jer je jedini način da vam ROI ostane broj to da povremeno bude i negativan.

Ako razmišljate o automatizaciji i želite da prvo postavimo merenje pa tek onda odlučimo šta se gradi, javite se na lazar-milicevic.com/#contact. Rado ću pogledati vaš proces, bez obaveze.