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

U mnogim IT-organizacijama tehnički dug je odavno stalno stanje: aplikacije rade, procesi funkcionišu, a ipak svaka promjena postaje tromija, svako izdanje rizičnije i svaki poremećaj skuplji. Problem rijetko leži u tome da niko ne vidi rizike – već u tome što oni nisu usporedivi. Ako je pet sistema istovremeno „kritično“, na kraju nijedan ne može biti prioritet. Upravo ovdje pomaže ein model ocjenjivanja tehničkog duga: lagan, ponovljiv okvir ocjenjivanja koji prikazuje tehničke rizike, operativni napor i pritisak na modernizaciju tako da odluke o portfelju postanu pouzdane.

Ovaj članak opisuje model ocjenjivanja tehničkog duga koji funkcioniše bez masovnog assessmenta, ali u svakodnevnom radu IT-rukovodstva, operacija, administratora, odgovornih za projekte i poslovnih odjela. U fokusu nisu unutrašnji detalji koda, nego utjecaji na Operacije, Sigurnost, Podaci, Interfejsi, Sposobnost isporuke i Održavanje. Cilj je zajednički jezik koji ublažava rasprave o budžetu i prioritetima i čini modernizaciju planiranom.

Model ocjenjivanja tehničkog duga u praksi

Tehnički dug je zbirni pojam za odluke i naslijeđa koja su kratkoročno uštedjela vrijeme, ali dugoročno stvaraju kamatne troškove. Te „kamate“ se u svakodnevnom poslovanju manifestuju kao duže vrijeme obrade, više usklađivanja, veće stope grešaka, sigurnosni propusti, specijalizirano znanje kod malog broja ljudi ili kao zavisnosti o komponentama koje se više ne podržavaju. Problem je u tome što se mnogi od ovih efekata ne pojavljuju kao jasna troškovna stavka.

Tipični razlozi zbog kojih tehnički dug u portfeljnim rundama ostane zapostavljen:

• Nedostatak usporedivosti: Stabilan naslijeđeni monolit, SaaS-alat s rastućim pritiskom licenciranja i integracijska staza s noćnim zadacima teško se bez okvira međusobno ocjenjuju.
• Nekonzistentna baza podataka: Za sistem A postoje statistike incidenata i monitoring, za sistem B samo osjećaj, za sistem C ništa.
• Pomiješane diskusije: Poslovna vrijednost, tehnički rizici i osobne preferencije (tehnologija, želja tima) miješaju se u istoj raspravi.
• Preopširni modeli ocjene: Opsežni modeli zrelosti imaju smisla – ali često se ne održavaju redovno. Za odluke o portfelju presudna je ponovljivost.

Lagani model ocjenjivanja tehničkog duga nije apsolutna istina. To je alat za smanjenje neizvjesnosti i za činjenje odluka razumljivim – uključujući pretpostavke koje stoje iza njih.

Principi za lagani model ocjenjivanja tehničkog duga

Da model ocjenjivanja ne bi završio kao „Excel-vježba“, trebao bi ispuniti nekoliko osnovnih principa:

• Par dimenzija, jasne definicije: Bolje jasno objasniti 6–8 ocjenjivačkih dimenzija nego skupljati 20 polukriterija.
• Mjerljivo, ali ne striktno kvantitativno: Nije sve dostupno u brojkama. Važno je da se kriteriji dosljedno primjenjuju.
• Prikladno za portfelj: Ocjena mora funkcionisati preko sistema – neovisno o tome radi li se o individualnom poslovnom softveru, standardnim proizvodima ili integracijskim komponentama.
• Eksplcitne perspektive: Operacije, Sigurnost, Podaci i Poslovni odjel trebaju biti zastupljeni u modelu, kako se ne bi raspravljalo samo „tehnika protiv poslovanja“.

U praksi se pokazalo korisnim tretirati skor kao osnovu za razgovor: on daje prioritetnu listu, ali ne automatske odluke. Odbori za portfelj ostaju odgovorni – i svjesno dokumentiraju odstupanja.

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

Sljedeća matrica koristi osam dimenzija koje se u tipičnim korporativnim okruženjima mogu dobro prikupiti. Svaka dimenzija se ocjenjuje na skali od 1 do 5 (1 = nekritično/dobro pod kontrolom, 5 = kritično/akutan pritisak za djelovanjem). Važno nije matematička perfekcija, nego jednoznačnost kriterija.

1) Stabilnost rada i profil smetnji

Riječ je o pitanju: koliko često sistem ometa rad – i koliko su te smetnje skupe s organizacijskog aspekta? Osnova su Incidents (poremećaji), ponavljajuće tikete, on-call eskalacije i neplanirana održavanja. U obzir ulazi i „tihi“ nestabilitet, npr. kada se noćni poslovi često moraju naknadno doraditi.

Orijentiri za ocjenu (primjeri):

• 1: Rijetki Incidents, jasni Runbooks (operativni priručnici), ponovno pokretanje uvježbano.
• 3: Redovne smetnje ili česti problemi s performansama, ali svladivo.
• 5: Ponavljajući kvarovi, visoko opterećenje podrške, privremena rješenja umjesto otklanjanja uzroka.

2) Rizik sigurnosti i usklađenosti

Ova dimenzija ocjenjuje koliko je sistem zaštićen od sigurnosnih incidenata i koliko je audibilan (provjerljiv) u radu. U to spadaju mogućnost patchovanja, podržane komponente, autentifikacija (npr. SSO preko SAML/OIDC – dakle centralna prijava), logovanje (Audit-Trail: rekonstruabilan lanac događaja) i zaštita osjetljivih podataka.

• 1: Redovna ažuriranja, jasne uloge/privilegije, rekonstruabilni logovi, nema poznatih „End-of-Life“ komponenti.
• 3: Djelimično zastarjele komponente ili nedostaci u logovanju/recertifikaciji, kompenzacione mjere su prisutne.
• 5: Kritični zastarjeli elementi, nedostaju patch-evi, nejasne odgovornosti, audit-rizici.

3) Izmjenjivost i sposobnost izdanja

„Koliko je teško sigurno isporučiti promjene?“ To je srž mnogih tehničkih dugova. Misli se na testabilnost (regresija: ponovljivi testovi), proces deploy-a, rollback-sposobnost (čista opcija povratka), ovisnost o pojedincima te vrijeme od zahtjeva do puštanja u proizvodnju.

• 1: Reproducibilni release-ovi, definirana okruženja, planirani vremenski prozori održavanja.
• 3: Release-ovi su mogući, ali uz manuelne korake i povećan koordinacijski napor.
• 5: Svaka promjena nosi rizik, deploy samo „sa pravim ljudima“, rollback nejasan.

4) Arhitektonska i integracijska kompleksnost

Ova dimenzija ne procjenjuje je li arhitektura „moderna“, nego je li upravljiva. Integracije su često pokretač troškova: point-to-point sučelja, specijalni formati datoteka, vremenski kritične batch-obrade, nedostatak verzioniranja API-ja (ugovora o sučeljima) ili uska povezanost s drugim sustavima.

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

5) Datenqualität, Datenhoheit und Datenflüsse

Za odluke o portfelju ključno je jesu li podaci uredno vođeni i pouzdano upotrebljivi. Vlast nad podacima znači: jasno je gdje leži „izvor istine“, kako nastaju matični podaci (npr. kupci, artikli, dobavljači) i kako promjene djeluju nizvodno. Tokovi podataka obuhvaćaju i izvoze, sjenkaste kopije i ručne korekcije.

• 1: Jasne odgovornosti, razumljivi putevi podataka, definirana sučelja, konzistentni ključevi.
• 3: Više izvora podataka ili redovne čišćenja, ali transparentno.
• 5: Nejasan izvor istine, česte korekcije, izvještavanje moguće samo uz posebnu logiku.

6) Lifecycle-Risiko: Hersteller, Plattform, Skills

Tehnički dug nastaje i zbog ukidanja komponenti: operativni sustavi, baze podataka, biblioteke, podrška proizvođača ili dostupnost know-how-a. Ova dimenzija svjesno promatra organizacijsku stranu: ima li dovoljno ljudi koji pokrivaju rad i dalji razvoj? Postoji li pouzdan put za nadogradnju?

• 1: Aktivni ciklusi podrške, nadogradnja planirana, vještine široko dostupne.
• 3: Nadogradnja predstoji, stanje vještina napeto, ovisnost o nekoliko ključnih osoba.
• 5: End-of-Life, nema roadmap-a, znanje koncentrirano, visok vendor-rizik.

7) Kosten- und Aufwandstreiber im laufenden Betrieb

Ovdje se ne vrednuju samo troškovi infrastrukture, nego prije svega varijabilni troškovi: opterećenje podrške, ručne aktivnosti, posebni procesi, rast licenci, ovisnost o vanjskim pružateljima usluga ili skupa održavanja. Upravo kod poslovnog softvera ti indirektni troškovi često su važniji od cijene servera.

• 1: Stabilan rad, malo ručnih aktivnosti, troškovi planirani.
• 3: Povećan operativni napor ili rastući troškovi licenci, ali kontrolabilno.
• 5: Operativni rad guta kapacitete, mnogo ručnih korekcija, troškovi teško prognozirati.

8) Business-Kritikalität und Prozessabhängigkeit

Tehnički dug postaje za odluke o portfelju relevantan tek kada se upari s rizikom procesa. Ova dimenzija procjenjuje 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 „nikada dirati“, već argument za temeljitu stabilizaciju i modernizaciju.

• 1: Proces koji podržava, kvar je podnošljiv, postoji zaobilazno rješenje.
• 3: Važan proces, kvarovi stvaraju troškove, ali ograničivi.
• 5: Ključni proces, kvar zaustavlja stvaranje vrijednosti ili vodi do rizika usklađenosti.

Wie aus Scores Portfolio-Entscheidungen werden (ohne Scheingenauigkeit)

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

Gewichtung: nicht jedes Kriterium zählt gleich

Mnoge organizacije započinju sa istom težinom kako bi izbjegle rasprave. Kasnije se isplati jednostavno ponderiranje prema cilju portfelja, npr.:

• Prioritet sigurnosti (npr. prema nalazima audita): dvostruko ponderirati rizik sigurnosti i usklađenosti.
• Povećati sposobnost isporuke (npr. kod velikog backlog-a promjena): jače ponderirati mogućnost izmjena / sposobnost izdanja.
• Stabilizirati troškove (npr. pri rastućoj podršci): jače ponderirati faktore koji povećavaju napor u operacijama.

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

Kategorije odluka: četiri jasne opcije za djelovanje

Iz dimenzija proizlaze četiri pragmatične kategorije koje se dobro mogu raspraviti u Portfolio-Boardu:

• Stabilizirati: Visoki operativni/ sigurnosni rizici, ali kratkoročno zamjenu nije moguće provesti. Fokus na Runbooks, monitoring, puteve za patchanje, tehničku higijenu.
• Modernizirati: Visoki rizici izmjena ili životnog ciklusa uz istovremeno visoku kritičnost. Fokus na modularnu obnovu, dekoplovanje sučelja, konsolidaciju modela podataka.
• Konsolidirati/Zamijeniti: Duplikatne funkcije, veliki napor, mala diferencijacija. Fokus na isključivanju, migraciji podataka, standardizaciji procesa.
• Svjesno prihvatiti: Niska kritičnost ili predvidivo preostalo vrijeme rada. Fokus na kontrolama rizika, minimalnom održavanju, jasnoj Exit-Option.

Da to ne ostane teorija, svaka aplikacija bi trebala dobiti dodatno jedan sljedeći smislen korak – najviše 1–2 konkretne mjere koje su realistične u roku 4–12 sedmica. Tako portfeljno upravljanje postaje kontinuirani proces poboljšanja umjesto godišnje radionice.

Pragmatično izgraditi podatkovnu osnovu: Koji izvori su obično dovoljni

Lagan model živi od činjenice da prikupljanje podataka ne smije biti skuplje od prvih mjera. Za mnoga preduzeća četiri izvora podataka su dovoljna za dodjelu ozbiljnih skorova:

• Podaci o ticketima/incidentima: učestalost, ponavljanja, vremena obrade, eskalacije. Ako nema čiste kategorizacije, na početku je dovoljna gruba dodjela (poremećaj, zahtjev, promjena).
• Monitoring/dostupnost: ne samo „Uptime“, već i vrhovi performansi, vremena izvršavanja poslova, stope grešaka, rast memorije/diska.
• Podaci o sigurnosti i životnom ciklusu: stanje patcha, datumi End-of-Life, ovisnosti (npr. verzija baze podataka, operativni sistem, autentifikacija), poznati izuzeci.
• Pregled arhitekture/integracija: jednostavna Application-Map (mapa sistema) sa tokovima podataka i sučeljima. Potpunost je sekundarna, ažurnost je bitna.

Ako brojevi nedostaju, to bi trebalo biti vidljivo u skoru: „Bewertung 4 aufgrund fehlender Nachweise“ je iskrenija nego slučajni prosjek. Nepoznato je u operacijama često rizičnije nego loše, što bar poznajemo.

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

Česta greška je provođenje ocjenjivanja (Scoring) kao pojedinačan zadatak. Tada ono postane ili previše tehničko ili previše političko. Bolje je kratak, moderiran workshop po sistemu, s jasno definisanim ulogama. 90 minuta je dovoljno za prvu pouzdanu procjenu ako su osnovni podaci dostupni.

Sudionici (mali, ali potpuni)

• Systemverantwortliche IT: poznaje roadmapu, promjene, tehnička uska grla.
• Betrieb/Administration: poznaje incidente, prozore za održavanje, monitoring, backup/RESTore.
• Fachlicher Owner oder Key User: poznaje kritičnost procesa, zaobilazna rješenja, prihvaćenost, peak‑vremena.
• Moderation: osigurava dosljednost definicija i dokumentira pretpostavke.

Tijek (kompaktan, ponovljiv)

1. Kontext (10 min.): svrha sistema, korisničke grupe, glavne integracijske točke, operativni model (On-Prem/Cloud/Hybrid).
2. Ocjena po dimenziji (45 min.): po kriteriju 3–5 minuta, s kratkim dokazima (broj tiketa, status zakrpa, poznate zavisnosti).
3. Identifikacija kritičnih tačaka (15 min.): koje 2 dimenzije najviše povećavaju rizik/troškove?
4. Utvrđivanje mjera (15 min.): 1–2 konkretna naredna koraka, plus vlasnik i ciljni rok.
5. Oznaka portfelja (5 min.): Stabilizirati / Modernizirati / Konsolidirati / Prihvatiti.

Kao rezultat dovoljna su tri artefakta: tabela ocjena, kratko obrazloženje po dimenziji i isječak s mjerama. Sve ostalo je opciono.

Tipične zamke – i kako ih u modelu ublažiti

Model ocjenjivanja može stvoriti pogrešne poticaje ako nije jasno ograničen. Iz projektnog iskustva ovo su najčešći spotersi:

Zamka 1: „Wir bestrafen Teams für Transparenz“

Ako timovi s dobrom dokumentacijom dobiju lošije ocjene zato što čine probleme vidljivim, model je neispravan. Protumjera: nepoznato (nedostajući podaci) tretirati kao poseban rizik i izričito priznati transparentnost kao prednost, npr. u kriteriju Mogućnost izmjene (Rollbacks, Runbooks, Monitoring).

Zamka 2: Ocjena postaje instrument za rezanje budžeta

Ako visoke ocjene automatski vode do „zastoja projekta“, model postaje politički. Bolje: visoke ocjene iniciraju odluku s opcijama (npr. stabilizacija vs. modernizacija) i jasnim posljedicama. Budžet slijedi odluku – ne ocjena sama za sebe.

Zamka 3: Miješanje koristi i rizika

Poslovna korist (npr. potencijal prihoda) je važna, ali druga je osa. Dokazano rješenje: koristi ocijeniti u zasebnoj matrici i zatim ih spojiti u portfolio‑matricu (korist visoka/niska vs. rizik/dug visok/nizak). Time se izbjegava rasprava da li sigurnosni rizik „kompenzira“ prihod.

Zamka 4: „Modernisierung“ wird als Großprojekt verstanden

Odluke o portfelju često ne uspiju zbog implicitne pretpostavke da modernizacija može biti samo kao Big Bang. U praksi je često smislen modularni pristup: stabilizirati interfejse, standardizirati pristupe podacima, izdvojiti pojedinačne podprocese, uredno upravljati paralelnim radom. Ein Score pomaže pronaći redoslijed, ne nametnuti krajnje stanje.

Vom Score zur Roadmap: wie Maßnahmenpakete sinnvoll zugeschnitten werden

Kada je model postavljen, počinje stvarni posao: mjere krojiti tako da pored projektnih aktivnosti funkcioniraju i u svakodnevnom radu. Tri pravila pomažu pretvoriti „trebali bismo“ u konkretne elemente Roadmap-e:

1) Erst die teuersten Risiken „entschärfen“

U mnogim portfeljima sigurnosni i operativni rizici imaju najveći utjecaj jer su vezani uz vanjske rokove (Audit, End-of-Life) i dovode do visokih naknadnih troškova. Tipične mjere za ublažavanje su: uspostaviti put nadogradnje, dopuniti Logging/Audit-Trail, testirati Backup/RESTore, smanjiti Single-Point-of-Failure, provjeriti i uskladiti ovlaštenja.

2) Integrationsknoten vor Funktionsausbau stabilisieren

Sistemi s mnogo interfejsa multipliciraju troškove promjena. Ovdje se često prvo isplati: definirati ugovore o sučeljima (versioniranje, formati podataka, obrada grešaka), dopuniti monitoring za tokove podataka, razdvojiti lance zadataka, uvesti retry-strategije (ponovni pokušaji pri greškama). To je rijetko „vidljivo“ poslovnom odjelu, ali mjerljivo smanjuje vrijeme zastoja i stres pri izdanjima.

3) Maßnahmen als „Betriebsverbesserung“ planbar machen

Mnogi tehnički dugovi mogu se rješavati kao operativna poboljšanja u malim paketima: Runbooks, pravila alarma, planiranje kapaciteta, standardizacija okruženja, redovni prozori za patchiranje. To nisu glamurozni projekti, ali povećavaju pouzdanost – i stvaraju vremenske prozore za veće korake modernizacije.

So wird das Scoring dauerhaft: Governance ohne Bürokratie

Model vrijedi samo ako ne utihne nakon dva kvartala. Zato je potreban jednostavan proces koji se uklapa u svakodnevni operativni i projektni rad:

• Vlasnik za aplikaciju: imenovana osoba koja održava Score i status mjera (ne provodi ih samostalno).
• Okidači umjesto obaveznog kalendara: pregled Scorea nakon incident-klastera, Major-Release, nalaza iz audita ili nadogradnje platforme.
• Ritam portfelja: mjesečno/dva mjeseca 60 minuta za top-rizike, ne za sve sustave.
• Log odluka: kratka dokumentacija zašto je rizik prihvaćen ili odgođen. To sprječava naknadne optužbe i čini pretpostavke vidljivima.

Važna je povezanost sa stvarnim upravljanjem: najmanje dio kapaciteta (budžet ili vrijeme tima) trebao bi biti izričito rezervisan za stabilizaciju/modernizaciju. Inače model proizvodi samo uvide bez učinka.

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

Jednostavan model bodovanja tehničkog duga ne zamjenjuje detaljan rad na arhitekturi – ali stvara ono što često nedostaje u portfeljima: usporedivost. Sa osam jasnih dimenzija, transparentnim kriterijima ocjenjivanja i kratkim formatom radionice, rizike, operativni napor i pritisak za modernizaciju moguće je prikazati tako da IT, poslovni odjel i menadžment vode istu raspravu.

Najvažniji efekt rijetko je precizna brojka. Riječ je o transparentnosti oko toga gdje nastaje tehnički dug, kako opterećuje operacije i koji su realni naredni koraci. Ako se ocjene redovno provjeravaju i povezuju s malim, konkretnim mjerama, nastaje mapa puta za modernizaciju koja ne ostaje na nacrtu, već se primjenjuje u svakodnevnom radu.

Ako želite uspostaviti model bodovanja za svoj portfolio aplikacija ili provesti prve ocjene u moderiranom formatu, ovdje ćete naći prikladan početak: Kontaktirajte nas.

Za ovu temu su također važni „Ocjenjivanje tehničkog duga“ i „IT-odlučivanje o portfelju“. Članak ove aspekte jasno razlaže i pokazuje na što treba obraćati pažnju u svakodnevnom radu.

Razgovarajte o projektu ili poduhvatu modernizacije s Net-Base.