Učiniti tehnički dug vidljivim: lagani model bodovanja za odluke o portfelju

U mnogim IT-organizacijama tehnički dug odavno je stalno stanje: aplikacije rade, procesi funkcioniraju, a ipak svaka promjena postaje sporija, svako izdanje rizičnije i svaki kvar skuplji. Problem rijetko leži u tome da nitko ne vidi rizike – već u tome što nisu usporedivi. Ako je pet sustava istovremeno „kritično“, na kraju nijedan nije moguće prioritizirati. Upravo tu pomaže model bodovanja tehničkog duga: lagana, ponovljiva matrica ocjenjivanja koja tehničke rizike, operativni napor i pritisak na modernizaciju prikazuje tako da odluke o portfelju postanu utemeljene.

Ovaj članak opisuje model bodovanja koji ne zahtijeva opsežno procjenjivanje, ali je primjenjiv u svakodnevnom radu IT-uprave, operacija, administratora, odgovornih za projekte i poslovnih odjela. U fokusu nisu unutarnji detalji koda, nego utjecaji na operacije, sigurnost, podatke, sučelja, sposobnost isporuke i održavanje. Cilj je zajednički jezik koji umiruje rasprave o proračunu i prioritizaciji i čini modernizaciju planiranom.

Model bodovanja tehničkog duga u praksi

Tehnički dug je zbirni pojam za odluke i zaostavštine koje su kratkoročno uštedjele vrijeme, ali dugoročno stvaraju „kamatu“. Te „kamate“ u poslovnom svakodnevnom radu očituju se kao dulji prolazni rokovi, više koordinacije, veće stope pogrešaka, sigurnosne ranjivosti, specifično znanje kod nekoliko osoba ili ovisnosti o komponentama koje se više ne podržavaju. Problem je u tome što se mnogi od tih efekata ne pojavljuju kao jasna stavka troškova.

Tipični razlozi zašto tehnički dugovi u raspravama o portfelju ostanu zapostavljeni:

• Nedostatak usporedivosti: stabilni naslijeđeni monolit, SaaS alat s rastućim pritiskom na licence i integracijska rješenja koja obavljaju noćne poslove teško je bez jasne matrice međusobno usporediti.
• Neravnomjerna dostupnost podataka: Za sustav A postoje statistike incidenata i monitoring, za sustav B samo osjećaj, a za sustav C ništa.
• Pomiješane diskusije: Stručna korist, tehnički rizici i osobne preferencije (tehnologija, želje tima) završavaju pomiješane.
• Preopširni modeli ocjenjivanja: Sveobuhvatni modeli zrelosti imaju smisla – ali se često ne održavaju redovito. Za odluke o portfelju presudna je ponovljivost.

Lagani model bodovanja nije savršena istina. To je alat za smanjenje nesigurnosti i za transparentno donošenje odluka – uključujući pretpostavke koje stoje iza njega.

U praksi se pokazalo korisnim tretirati Score kao polazište za razgovor: on daje prioritetizirani popis, ali ne automatske odluke. Portfolio-odbori ostaju odgovorni – i svjesno dokumentiraju odstupanja.

Model bodovanja: 8 dimenzija koje u radu zaista znače

Sljedeće raster koristi osam dimenzija koje se u tipičnim korporativnim krajolicima mogu pouzdano prikupljati. Svaka dimenzija vrijednuje se na skali od 1 do 5 (1 = nekritično/dobro pod kontrolom, 5 = kritično/akutni pritisak za djelovanjem). Važno nije matematičko savršenstvo, nego jednoznačnost kriterija.

1) Stabilnost rada i profil kvarova

Radi se o pitanju: koliko često sustav remeti rad – i koliko su ti kvarovi organizacijski skupi? Osnova su Incidents (kvarovi), ponavljajući ticketi, eskalacije tijekom dežurstva i neplanirana održavanja. U obzir dolazi i „tiha“ nestabilnost, npr. kada noćni procesi često zahtijevaju naknadne popravke.

Referentne vrijednosti (primjeri):

• 1: Rijetki Incidenti, jasni Runbooks (operativne upute), ponovno pokretanje uvježbano.
• 3: Redoviti kvarovi ili česti problemi s performansama, ali pod kontrolom.
• 5: Ponavljajući prekidi, veliki opterećenje podrške, privremena rješenja umjesto otklanjanja uzroka.

2) Rizik sigurnosti i usklađenosti

Ova dimenzija procjenjuje koliko je sustav zaštićen od sigurnosnih incidenata i koliko je upravljiv u pogledu revizijske provjerljivosti. U obzir ulaze mogućnost primjene zakrpa, podržane komponente, autentikacija (npr. SSO preko SAML/OIDC – tj. centralno prijavljivanje), protokoliranje (Audit-Trail: rekonstruabilan lanac događaja) i zaštita osjetljivih podataka.

• 1: Redovite nadogradnje, jasne uloge/privilegije, rekonstruabilni logovi, nema poznatih „End-of-Life“-komponenti.
• 3: Djelomično zastarjele komponente ili praznine u protokoliranju/ponovnoj certifikaciji, postoje kompenzacijske mjere.
• 5: Kritične zaostalosti, nedostajuće zakrpe, nejasne odgovornosti, rizici pri reviziji.

3) Mogućnost izmjena i sposobnost releasa

„Koliko je teško sigurno isporučiti promjene?“ To je srž mnogih tehničkih dugova. Misli se na testabilnost (regresija: ponovljeni testovi), proces deploya, sposobnost rollbacka (jasna opcija povratka), ovisnost o pojedincima te vrijeme od zahtjeva do puštanja u produkciju.

• 1: Reproducibilna izdanja, definirana okruženja, planirani prozori održavanja.
• 3: Releasi su mogući, ali uz ručne korake i povećani koordinacijski napor.
• 5: Svaka promjena je rizik, deploy samo „s pravim ljudima“, rollback nejasan.

4) Arhitektonska i integracijska složenost

Ova dimenzija ne utvrđuje je li arhitektura „moderna“, nego je li podatna za upravljanje. Integracije su često glavni pokretač troškova: izravna sučelja, specifični format datoteka, vremenski osjetljiva batch obrada, nedostatak verzioniranja API-ja (ugovora o sučelju) ili tijesna povezanost s drugim sustavima.

• 1: Jasno dokumentirana sučelja, malo točaka povezivanja, promjene djeluju lokalno.
• 3: Više ovisnosti, promjene zahtijevaju koordinirana izdanja.
• 5: „Spaghetti“ integracije, nepoznati tokovi podataka, velik utjecaj pri malim promjenama.

5) Kvaliteta podataka, suverenitet podataka i tokovi podataka

Za odluke o portfelju presudno je jesu li podaci uredno vođeni i pouzdano upotrebljivi. Suverenitet podataka znači: jasno je gdje leži „izvor istine“, kako nastaju osnovni podaci (npr. kupci, artikli, dobavljači) i kako promjene utječu nizvodno. Tokovi podataka obuhvaćaju i izvoze, sjenovite kopije i ručne ispravke.

• 1: Jasne odgovornosti, pratljivi putovi podataka, definirana sučelja, konzistentni ključevi.
• 3: Više izvora podataka ili redovita čišćenja, ali transparentno.
• 5: Nejasan izvor istine, česte ispravke, izvještavanje moguće samo putem posebne logike.

6) Rizik životnog ciklusa: proizvođač, platforma, vještine

Tehnički dug nastaje i zbog ukidanja podrške: operativni sustavi, baze podataka, biblioteke, podrška proizvođača ili dostupnost znanja. Ova dimenzija svjesno promatra organizacijsku stranu: ima li dovoljno ljudi koji nose rad i daljnji razvoj? Postoji li pouzdan put nadogradnje?

• 1: Aktivni ciklusi podrške, planirana nadogradnja, vještine široko dostupne.
• 3: Nadogradnja predstoji, stanje vještina je napeto, ovisnost o nekolicini ključnih osoba.
• 5: End-of-Life, nema roadmapa, znanje koncentrirano, visoki rizik od dobavljača.

7) Pokretači troškova i opterećenja u tekućem radu

Ovdje se ne vrednuju samo troškovi infrastrukture, nego prije svega varijabilni troškovi: napor podrške, ručni poslovi, posebni procesi, rast licenci, ovisnost o vanjskim dobavljačima ili skupa održavanja. Posebno kod poslovnog softvera ovi neizravni troškovi često su odlučujući, više nego cijene servera.

• 1: Stabilan rad, malo ručnih poslova, troškovi planabilni.
• 3: Povećani operativni napor ili rast licenci, ali upravljivo.
• 5: Operacija „pojede“ kapacitete, mnogo ručnih ispravki, troškovi teško predvidljivi.

8) Poslovna kritičnost i ovisnost o procesima

Tehnički dug postaje relevantan za odluke o portfelju tek kad se spoji s rizikom procesa. Ova dimenzija ocjenjuje koliko sustav nosi ključne procese i kolika je šteta u slučaju zastoja ili pogrešne funkcije. Važno: kritičnost nije dozvola za „nikad dirati“, već argument za temeljitu stabilizaciju i modernizaciju.

• 1: Pomažući proces, kvar je podnošljiv, postoji workaround.
• 3: Važan proces, kvarovi stvaraju troškove, ali su ograničivi.
• 5: Ključni proces, kvar zaustavlja stvaranje vrijednosti ili vodi u rizike usklađenosti.

Kako rezultati ocjene postaju odluke o portfelju (bez lažne preciznosti)

Ocjena je korisna tek kad pripremi odluku. Za to su potrebna dva koraka: ponderiranje i kategorije odluka.

Ponderiranje: nije svaki kriterij jednako važan

Mnoge organizacije započinju s jednakim ponderiranjem kako bi izbjegle rasprave. Kasnije se isplati jednostavno ponderiranje prema cilju portfelja, primjerice:

• Prioritet sigurnosti (npr. prema nalazima audita): sigurnosne i usklađenosti rizike dvostruko ponderirati.
• Povećati sposobnost isporuke (npr. kod velikog backloga promjena): sposobnost izmjena/izdavanja jače ponderirati.
• Stabilizirati troškove (npr. pri rastućoj podršci): faktore troškova u operacijama jače ponderirati.

Važno je ponderiranje transparentno dokumentirati i mijenjati ga rijetko. Inače promjene skora izgledaju „politički“ umjesto kao stvarno poboljšanje.

Kategorije odluka: četiri jasne opcije djelovanja

Iz dimenzija se mogu izvesti četiri pragmatične kategorije koje se dobro raspravljaju u portfolio-panu:

• Stabilizirati: Visoki operativni/sigurnosni rizici, ali nije moguća kratkoročna zamjena. Fokus na Runbooks, monitoring, putovima primjene zakrpa, tehničkoj higijeni.
• Modernizirati: Visoki rizici izmjena ili lifecycle uz istodobno visoku kritičnost. Fokus na modularnoj obnovi, dekoplovanju sučelja, konsolidaciji modela podataka.
• Konsolidirati/Zamijeniti: Duple funkcije, veliki napori, mala diferencijacija. Fokus na gašenju, migraciji podataka, ujednačavanju procesa.
• Svjesno prihvatiti: Niska kritičnost ili predvidivo preostalo trajanje. Fokus na kontrolama rizika, minimalnom održavanju, jasnoj izlaznoj opciji.

Da to ne ostane teorija, svaka aplikacija treba dodatno dobiti sljedeći smisleni korak – maksimalno 1–2 konkretne mjere koje su realne u roku 4–12 tjedana. Tako portfeljno upravljanje postaje kontinuirani proces poboljšanja umjesto godišnje radionice.

Podizanje podatkovne osnove pragmatično: koje izvore obično je dovoljno koristiti

Lakši model živi od toga da prikupljanje podataka ne bude skuplje od prvih mjera. Za mnoge tvrtke dovoljna su četiri izvora podataka za pouzdano dodjeljivanje skora:

• Podaci iz tiketa/incipienata: učestalost, ponavljanja, vremena obrade, eskalacije. Ako nema uredne kategorizacije, na početku je dovoljna gruba dodjela (kvar, upit, promjena).
• Monitoring/dostupnost: Ne samo „Uptime“, već i vrhovi opterećenja, vremena izvršavanja poslova, stope pogrešaka, rast zauzeća memorije i diska.
• Sigurnosne i lifecycle informacije: status zakrpa, datumi End-of-Life, ovisnosti (npr. verzija baze podataka, operativni sustav, autentikacija), poznate iznimke.
• Pregled arhitekture/integracija: Jednostavna Application-Map (karta sustava) s tokovima podataka i sučeljima. Potpunost je manje važna, ažurnost je presudna.

Ako nedostaju brojke, to bi trebalo biti vidljivo u skoru: „Ocjena 4 zbog nedostatka dokaza“ je iskrenije od slučajnog prosjeka. Nepoznato u produkciji često je rizičnije od lošeg, kojeg barem poznajete.

Scoring-Workshop u 90 Minuten: Ablauf, Rollen, Ergebnisartefakte

Česta pogreška je provoditi ocjenjivanje kao pojedinačan posao. Tada ono postaje ili previše tehničko ili previše političko. Bolje je kratka, moderirana radionica za svaki sustav, vođena i s jasnim ulogama. 90 minuta su dovoljna za prvu pouzdanu procjenu ako postoje osnovni podaci.

Sudionici (malo, ali potpuno)

• Odgovorna IT osoba za sustav: poznaje roadmap, promjene i tehnička uska grla.
• Operacije/Administracija: poznaje incidente, prozore za održavanje, monitoring, backup/RESTore.
• Poslovni vlasnik ili ključni korisnik: poznaje kritičnost procesa, zaobilazna rješenja, prihvaćanje i vršna opterećenja.
• Moderacija: osigurava pridržavanje definicija i dokumentira pretpostavke.

Postupak (kompaktan, ponovljiv)

1. Kontekst (10 Min.): svrha sustava, skupine korisnika, glavna sučelja, model rada (On-Prem/Cloud/Hybrid).
2. Score po dimenziji (45 Min.): po kriteriju 3–5 minuta, s kratkim dokazima (broj ticket-a, stanje patcha, poznate ovisnosti).
3. Identificirati hotspotove (15 Min.): koje dvije dimenzije najviše povećavaju rizik/troškove?
4. Odrediti mjere (15 Min.): 1–2 konkretna sljedeća koraka, plus vlasnik i ciljni rok.
5. Oznaka portfelja (5 Min.): Stabilizirati / Modernizirati / Konsolidirati / Prihvatiti.

Kao rezultat, dovoljna su tri artefakta: tablica ocjena (Score), kratko opravdanje po dimenziji i isječak mjera. Sve ostalo je opcionalno.

Tipične zamke – i kako ih model može ublažiti

Model ocjenjivanja može stvoriti pogrešne poticaje ako nije jasno ograničen. Iz iskustva na projektima, ovo su najčešće zamke:

Zamka 1: „Kažnjavamo timove za transparentnost“

Ako timovi s dobrom dokumentacijom dobiju lošije ocjene zato što otkrivaju probleme, model je pokvaren. Protivmjera: tretirati nepoznato (nedostajući podaci) kao vlastiti rizik i eksplicitno priznati transparentnost kao pozitivan faktor, npr. u kriteriju mogućnosti izmjene (rollbackovi, runbookovi, monitoring).

Zamka 2: Score postaje instrument za rezanje budžeta

Ako visoke ocjene automatski vode do „zaustavljanja projekta“, model postaje politički. Bolje: visoke ocjene vode do odluke s opcijama (npr. stabilizacija vs. modernizacija) i jasnim posljedicama. Budžet slijedi odluku – ne samo ocjenu.

Zamka 3: Miješanje koristi i rizika

Poslovna korist (npr. potencijal prihoda) je važna, ali predstavlja drugu os. Dokazani pristup: ocijeniti korist u zasebnoj tablici i zatim ih objediniti u portfelj-matricu (korist visoka/niska vs. rizik/dug visok/nizak). Tako se ne raspravlja treba li sigurnosni rizik „kompenzirati prihodom“.

Zamka 4: „Modernizacija“ se shvaća kao veliki projekt

Odluke o portfelju često ne uspiju zbog implicitne pretpostavke da se modernizacija može provesti samo kao Big Bang. U praksi je često smisleno modularno moderniziranje: stabilizirati sučelja, standardizirati pristupe podacima, izdvojiti pojedinačne dijelove procesa, uredno upravljati paralelnim radom. Ocjena pomaže pronaći redoslijed, ne nametnuti krajnje stanje.

Od ocjene do roadmap-e: kako se paketni mjere smisleno oblikuju

Kada je model postavljen, dolazi stvarni posao: mjere oblikovati tako da u svakodnevnom radu funkcioniraju uz projektne aktivnosti. Tri pravila pomažu pretvoriti „trebali bismo“ u konkretne elemente roadmap-e:

1) Prvo najskuplje rizike „ublažiti“

U mnogim portfeljima sigurnosni i operativni rizici imaju najveći utjecaj jer imaju vanjske rokove (Audit, End-of-Life) i visoke naknadne troškove. Tipične ublažavajuće mjere su: uspostaviti put ažuriranja, dopuniti logging/audit-trail, testirati backup/RESTore, smanjiti pojedinačne točke otkazivanja (Single-Point-of-Failure), provjeriti i uskladiti dozvole.

2) Stabilizirati integracijske čvorove prije proširenja funkcionalnosti

Sustavi s mnogo sučelja multipliciraju troškove promjena. Ovdje se često prvo isplati: definirati ugovore o sučeljima (verzioniranje, formati podataka, rukovanje pogreškama), dopuniti monitoring za tokove podataka, odvojiti lance poslova, uvesti retry-strategije (ponovljeni pokušaji pri pogreškama). To rijetko bude „vidljivo“ poslovnom području, ali mjerljivo smanjuje vrijeme zastoja i stres pri releasima.

3) Mjere planirati kao „poboljšanje u radu“

Mnoge tehničke dugove moguće je provesti kao operativna poboljšanja u malim paketima: Runbooks, pravila za alarme, planiranje kapaciteta, standardizacija okruženja, redoviti prozori za patchiranje. To nisu glamurozni projekti, ali povećavaju pouzdanost – i stvaraju vremenske prozore za veće korake modernizacije.

Kako ocjenjivanje postaje trajno: upravljanje bez birokracije

Model vrijedi samo ako se ne uspava nakon dva kvartala. Treba jednostavan proces koji se uklapa u svakodnevni rad i projekte:

• Vlasnik po aplikaciji: Imenovana osoba koja održava ocjenu i status mjera (ne provodi ih sama).
• Okidači umjesto obaveznog kalendara: Pregled ocjene nakon klastera incidenata, Major-Release, nalaza iz Audita ili nadogradnje platforme.
• Ritam portfelja: Mjesečno/na svaka dva mjeseca 60 minuta za top-rizike, ne za sve sustave.
• Dnevnik odluka: Kratka dokumentacija zašto je rizik prihvaćen ili odgođen. To sprječava naknadna prebacivanja krivnje i čini pretpostavke vidljivima.

Važno je povezati to s djelotvornim upravljanjem: najmanje dio kapaciteta (proračun ili vrijeme tima) treba biti izričito rezerviran za stabilizaciju/modernizaciju. Inače model proizvodi samo uvide bez učinka.

Zaključak: Tehnički dug učiniti vidljivim bez opterećenja organizacije

Jednostavan model bodovanja tehničkog duga ne zamjenjuje detaljan rad na arhitekturi – ali stvara nešto što često nedostaje u portfeljima: usporedivost. S osam jasnih dimenzija, razumljivim ocjenjivačkim sidrima i kratkim formatom radionice moguće je prikazati rizike, operativni napor i pritisak za modernizacijom tako da IT, poslovna jedinica i uprava vode istu diskusiju.

Najvažniji efekt rijetko je točna brojka. Riječ je o transparentnosti oko gdje nastaje tehnički dug, kako opterećuje rad i koji su sljedeći realistični koraci. Kad se rezultati bodovanja redovito provjeravaju i povežu s malim, konkretnim mjerama, nastaje roadmap za modernizaciju koji ne ostaje na papiru, već podupire svakodnevno poslovanje.

Ako želite uspostaviti model bodovanja za vaš portfelj aplikacija ili provesti prve procjene u moderiranom formatu, ovdje ćete pronaći odgovarajući početak: Kontaktirajte nas.

Za ovu temu su također važni Ocjenjivanje tehničkog duga i odluke o IT portfelju. Članak ove aspekte razumljivo razvrstava i pokazuje na što se u svakodnevnoj praksi treba fokusirati.

Razgovarajte o projektu ili o planu modernizacije s Net-Base.