Automatizacija koja se isplati: kako meriti ROI

Pre nekoliko godina sam završio automatizaciju koja je radila savršeno. Slala je izveštaje, popunjavala tikete, sve zeleno. Onda me je CFO pitao "koliko nam ovo donosi" i ja sam imao osećaj, ne broj. Od tada svaki sistem koji gradim ima merenje pre koda. Ovo je playbook koji koristim.

Zašto "osećaj da radi" košta više nego što misliš

Automatizacija bez brojki je politički ranjiva. Prvi put kad neko gore napravi rez budžeta ili promeni prioritete, sistem koji nema ROI broj ide prvi pod nož, bez obzira koliko stvarno štedi. Video sam to više puta. Skripta koja je realno čuvala dva dana mesečno otišla je u smeće jer niko nije znao da to dokaže.

Drugi problem je tehnički. Bez merenja nemaš pojma koji deo pipeline-a najviše vredi, pa optimizuješ pogrešno. Trošiš nedelju dana da ubrzaš Lambda koja se izvršava jednom dnevno umesto da centralizuješ retry logiku u workeru koji obrađuje 40 hiljada poruka.

Zato moj princip glasi: ako ne mogu da napišem rečenicu "ovaj sistem štedi X sati mesečno i Y evra godišnje" pre nego što počnem da gradim, ne gradim ga. Tražim još jedan razgovor sa naručiocem dok ta rečenica ne postoji.

Tri broja koja uvek merim

Postoje tri metrike koje pratim za skoro svaku automatizaciju. One pokrivaju 90 odsto razgovora sa biznisom i sa inženjerima istovremeno.

1. Sati ušteđeni mesečno (hours saved / month). Koliko ljudskog rada bi bilo potrebno da se ovaj zadatak uradi ručno, na istom obimu. Ovo NIJE vreme koje sistem provede izvršavajući se, nego vreme koje bi čovek potrošio na isti output.

2. Trošak godišnje (cost saved / year, neto). Ušteđeni sati pomnoženi sa realnom internom satnicom (ne tržišnom, već fully loaded cost zaposlenog), minus trošak rada samog sistema (cloud, API tokeni, održavanje). Ovo je broj koji ide u finansijski izveštaj.

3. SLA compliance (ili equivalent kvalitet metrika). Koliko često sistem ispuni dogovoreni rok ili kvalitet. Za support tikete to je "first response u roku od X minuta". Za content pipeline to je "objavljeno do petka 9h, sa svim QA proverama prošlim". Bez kvalitet metrike, štednja je lažna, jer možeš da "uštediš" sate tako što ćeš puštati smeće.

Konkretan primer iz jedne moje integracije: AWS + Zendesk serverless sistem za rutiranje tiketa. Prvi put u istoriji tog tima ostvarena je puna SLA usklađenost, i to je bila glavna metrika, ne broj poruka u sekundi. Tehnička metrika je tu da podrži poslovnu, ne da je zameni.

Kako postavljam baseline pre prve linije koda

Ovaj korak svi preskaču. Bez baseline-a, posle godinu dana ne možeš da dokažeš ništa, jer ne znaš odakle si krenuo.

Moj proces, sa kojim god timom radio:

1. Identifikuj nosioca posla danas. Ko trenutno radi tu operaciju ručno? Koliko ljudi? Koji procenat njihovog vremena ide na ovo?
2. Meri nedelju dana ručno. Tražim od tog tima da nedelju dana zapisuje koliko vremena troše na taj specifičan zadatak. Ne procenu, nego sat na stolu. Skoro uvek je broj 30-50% veći od onoga što su mi prvo rekli "iz glave".
3. Zabeleži trenutni kvalitet. Koliki je trenutni SLA hit rate? Koliko grešaka nedeljno? Koliko reklamacija mesečno?
4. Izračunaj baseline troška. Sati nedeljno × 4.33 × satnica = baseline godišnji trošak rada koji automatizacija napada.

Tek tada krećem u arhitekturu. Bez ovog koraka, ROI broj na kraju je marketing, ne računovodstvo.

Šta tačno merim u produkciji

Kad sistem krene, nije dovoljno da imam baseline. Treba mi telemetrija koja stalno potvrđuje da automatizacija i dalje vredi. Sistemi degradiraju, API cene rastu, scope se širi.

Minimum koji ubacujem u svaki sistem:

Ova poslednja je najvažnija i najčešće ignorisana. Automatizacija koja zahteva da neko jednom nedeljno uđe i ručno restartuje ili popravi podatke nije ušteda 10 sati mesečno, već 10 minus to vreme intervencije. Tagujem te intervencije eksplicitno i oduzimam ih od saved hours.

Konkretan kod koji koristim u Node/TS workerima, jednostavan emitter koji šalje u CloudWatch ili Postgres:

type AutomationEvent = {
  system: string;
  unit_of_work: string; // npr "ticket_routed"
  status: "success" | "error" | "manual_fix";
  duration_ms: number;
  error_type?: string;
  human_seconds_saved: number; // koliko bi ručno trajalo
};

async function emit(e: AutomationEvent) {
  await db.insert("automation_events").values({
    ...e,
    ts: new Date(),
  });
}

Sa ovim modelom, ROI report je jedan SQL upit, ne kvartalna prezentacija.

ROI formula koju koristim i kako je odbranim

Volim formule koje stanu u jedan red i koje finansije razumeju iz prve. Moja izgleda ovako:

Godišnji ROI % = ((Annual_Savings - Annual_Cost) / Annual_Cost) × 100

Annual_Savings = (Saved_Hours_Per_Month - Manual_Fix_Hours_Per_Month) × 12 × Loaded_Hourly_Rate
Annual_Cost    = Cloud + API + Maintenance + Initial_Build_Amortized_Over_3_Years

Realan primer iz jednog ekosistema od četiri povezana sistema koji sam izgradio:

• Saved hours per month: 73
• Manual fix hours per month: 2
• Loaded hourly rate: konzervativno postavljen
• Cloud + API + held maintenance: relativno mali fiksni mesečni trošak
• Build cost amortizovan na 3 godine

Rezultat prve godine: 192% ROI. Brojka koja je preživela i CFO i upravni odbor jer su svi inputi bili dokumentovani i merljivi. Trik nije bio u formuli, već u tome što sam imao baseline, telemetriju i konzervativne pretpostavke. Ako overestimuješ ulaz, prvi finansijski review te razbije.

Jedna stvar koju uvek isključim iz Saved Hours: "vreme koje će zaposleni iskoristiti za važniji posao". To je tačno na ljudskoj ravni, ali ne ide u ROI tabelu jer ne mogu da ga dokažem. Ako računovodstvo to ne može da knjiži, ja to ne brojim.

Najčešće greške koje vidim u tuđim ROI proračunima

Posle više od deset godina ovog posla, isti tip greški se ponavlja:

Prebrojavanje sati koji ne postoje. "Štedimo 200 sati mesečno" za zadatak koji ručno nikad nije ni radjen u tom obimu. Ako ručna verzija nikad ne bi proizvela toliko outputa, ne smeš da kažeš da si toliko uštedeo. Saved hours = (ručno vreme za isti realan obim) - (vreme koje sistem zahteva, uključujući intervencije).

Ignorisanje LLM troška u trendu. API troškovi se menjaju, scope raste, tokeni po requestu rastu kako prompts evoluiraju. Pratim cost per unit of work nedeljno. Kad poraste 30% bez razloga, znam da je neko ubacio nepotreban context u prompt.

Brojanje build troška kao jednokratnog. Inicijalna izgradnja je amortizovana, ali održavanje nije. Realno održavanje produkcionog AI sistema je 15-25% inicijalne cene godišnje, više za sisteme oslonjene na third-party API koji se menjaju.

Mešanje tehničkih i poslovnih metrika. P95 latencija nije ROI. Ona je ulaz u SLA, koji je ulaz u Annual Savings. Kad pričam sa CFO, govorim u evrima i satima. Kad pričam sa engineering timom, govorim u P95 i error rate. Ista pojava, dva jezika.

Nemerenje šta se desilo posle. Najteža greška. Sistem krene, svi su srećni, niko ne gleda dashboard šest meseci. Posle godinu dana niko ne zna da li i dalje vredi. Postavljam mesečni automatizovani izveštaj koji ide na email i meni i naručiocu, sa tri ključne metrike. Bez tog ritma, ROI se zaboravi.

Šta bih ja uradio na tvom mestu

Ako razmišljaš o automatizaciji u svojoj firmi, evo redosleda koji bih ja sledio, pre nego što ijedna linija koda bude napisana:

1. Izaberi jedan zadatak. Ne tri, ne ceo "AI transformacioni program". Jedan zadatak, jasno definisan.
2. Meri ga ručno nedelju dana. Realno vreme, ne procena.
3. Napiši jednu rečenicu: "Ovaj sistem treba da uštedi X sati mesečno i Y evra godišnje, uz SLA od Z%". Ako ne možeš tu rečenicu da napišeš, projekat nije spreman.
4. Izgradi MVP koji emituje telemetriju od prvog dana. Ne dodaješ metriku posle, ona je deo definicije sistema.
5. Pusti pilot mesec dana. Uporedi sa baseline-om. Ako brojevi nisu blizu obećanog, zaustavi i preispitaj.
6. Tek kad pilot potvrdi brojeve, skaliraj.

Najveća zamka je obrnut redosled: prvo skaliranje, pa "videćemo da li se isplati". Tako se gube budžeti i poverenje, i posle godinu dana CFO više ne želi da čuje reč AI.

Drugi savet, manje popularan: ne automatizuj sve. Ako zadatak donosi manje od 8 sati mesečno uštede, a zahteva integraciju sa tri sistema, gotovo uvek je bolje da ostane ručno još godinu dana, dok ne nadje par. Mali ROI sa velikim maintenance teretom je zamka koja se ne vidi prve godine.

Zatvaranje

Automatizacija koja se ne meri se ne brani. Sve što ovde pišem deluje očigledno na papiru, ali u praksi 80% sistema koje vidim u domaćim firmama nema baseline ni telemetriju, pa nema ni argument kad dođe trenutak da se brani.

Ako gradiš sistem za koji ne možeš da napišeš ROI rečenicu u jednom redu, ili ako imaš automatizaciju u produkciji a ne znaš da li i dalje vredi, slobodno me kontaktiraj preko lazar-milicevic.com/#contact. Često je dovoljan jedan razgovor da se postavi merenje koje će ti i posle godinu dana davati odgovor bez nagađanja.