Учинимо технички дуг видљивим: лаган модел бодовања за доношење одлука о портфељу

У многим ИТ организацијама технички дугови су већ дуго стално стање: апликације раде, процеси функционишу, а ипак свака промена постаје заморнија, свако издање ризичније и свака квар скупљи. Проблем ретко је у томе што нико не види ризике — већ што они нису упоредиви. Ако пет система истовремено има статус „критично“, ниједан на крају није могуће приоритизовати. Управо овде помаже модел оцењивања техничких дугова: лагана, поновљива матрица оцењивања која техничке ризике, оперативни напор и притисак за модернизацију приказује тако да одлуке у портфељу постану поуздане.

Овај чланак описује модел оцењивања који не захтева обимно процењивање, али је употребљив у свакодневном раду ИТ руководства, операција, администратора, одговорних за пројекте и пословних одељења. У фокусу нису унутрашњи детаљи кода, већ утицаји на операције, безбедност, податке, интерфејсе, испоручивост и одржавање. Циљ је заједнички језик који ублажава дискусије о буџету и приоритизацији и чини модернизацију планираном.

Модел оцењивања техничких дугова у пракси

Технички дугови су обухватни појам за одлуке и наслеђене обавезе које су краткорочно уштеделе време, али дугорочно узрокују трошкове. Ове „камате“ се у пословном свакодневном раду огледају као дужи рокови обраде, већа потреба за усаглашавањем, повећане стопе грешака, безбедносни пропусти, експертно знање код појединаца или зависности од компоненти које више нису подржане. Проблем је у томе што се многи од ових ефеката не појављују као јасна ставка у трошковнику.

Типични разлози због којих технички дугови у рундама портфеља пролазе незапажено:

• Недостатак упоредивости: Застарели монолит, SaaS алат са растућим лиценцним притиском и интеграциона траса са ноћним пословима тешко се могу међусобно поредити без јасног оквира.
• Неуједначени подаци: За систем A постоје статистике инцидената и мониторинг, за систем B само осећај, а за систем C ништа.
• Помешане дискусије: Пословна корист, технички ризици и личне преференције (технологија, жеља тима) завршавају у истом лонцу.
• Превелики модели оцењивања: Опсежни модели зрелости имају смисла — али их често не одржавају редовно. За одлуке у портфељу битна је поновљивост.

Лаган модел оцењивања није апсолутна истина. То је инструмент за смањење неизвесности и за чини доношење одлука транспарентним — укључујући и претпоставке које стоје иза њега.

Принципи за лагани модел оцењивања

Да би модел оцењивања не завршио као „Excel вежба“, требало би да испуни неколико основних принципа:

• Мало димензија, јасне дефиниције: Боље је јасно описати 6–8 димензија оцењивања него сакупљати 20 полукритеријума.
• Мерљиво, али не фиксирано на бројеве: Ни све се може изразити бројем. Важно је да критеријуми буду доследно примењивани.
• Погодно за портфељ: Оцењивање мора да функционише преко система — без обзира ради ли се о индивидуалном пословном софтверу, стандардним производима или интеграционим компонентама.
• Експлицитне перспективе: У моделу треба да се појаве операције, безбедност, подаци и пословна јединица, како се не би водила само дискусија „техника против бизниса“.

У пракси се показао као користан приступ третирање оцене као основе за разговор: она даје приоритетну листу, али не и аутоматске одлуке. Портфолио одбори остају одговорни – и свесно документују одступања.

Модел оцењивања: 8 димензија које у раду заиста значе

Следећа мрежа користи осам димензија које се добро прикупљају у типичним корпоративним окружењима. Свака димензија се оцењује на скали од 1 до 5 (1 = некритично/добро контролисано, 5 = критично/акутан притисак за интервенцију). Важно није математичка перфекција, већ јасноћа критеријума.

1) Стабилност рада и профил поремећаја

Ради се о питању: колико често систем ремети рад – и колико су ти поремећаји организационо скупе? Основ представљају Incidents (поремећаји), поновљени тикети, on-call ескалације и неопланирана одржавања. Урачунава се и „тиха“ нестабилност, на пример када се ноћни задаци често морају накнадно радити.

Оријентири за оцењивање (примери):

• 1: Ретки Incidents, јасни runbooks (оперативна упутства), процедуре поновног покретања увежбане.
• 3: Редовни поремећаји или чести проблеми са перформансама, али контролисани.
• 5: Понављајући кварови, велика оптерећеност подршке, привремена решења уместо отклањања узрока.

2) Ризик безбедности и усклађености

Ова димензија оцењује колико је систем заштићен од безбедносних инцидената и колико је оперативно подложан ревизији (проверљив). Обухватају се могућност примене патчева, подржане компоненте, аутентификација (нпр. SSO преко SAML/OIDC – централна пријава), логовање (Audit-Trail: праћење ланца догађаја) и заштита осетљивих података.

• 1: Редовна ажурирања, јасне улоге/права, проверљиви логови, нема познатих компоненти у „End-of-Life“ стању.
• 3: Делимично застареле компоненте или недостаци у логовању/рецертификацији, присутне компензационе мере.
• 5: Критични заостали статуси, недостају патчеви, неразјашњене одговорности, ризици при ревизији.

3) Могућност измена и спровођење релиза

„Колико је тешко безбедно испоручити измене?“ То је срж многих техничких дугова. Мисли се на тестираност (регресија: поновни тестови), процес деплоја, способност за rollback (чиста опција повратка), зависност од појединаца као и време од захтева до пуштања у продукцију.

• 1: Репродуцибилни релизови, дефинисана окружења, планирани прозори за одржаваanje.
• 3: Релизови су могући, али уз ручне кораке и повећан напор у усаглашавању.
• 5: Свака измена представља ризик, деплој само „са правим људима“, rollback нејасан.

4) Комплексност архитектуре и интеграције

Ова димензија не мери да ли је архитектура „модерна“, већ да ли је под контролом. Интеграције су често покретач трошкова: тачка-по-тачка интерфејси, специјални формати датотека, временски критична пакетна обрада, недостатак верзионисања API-ја (уговори о интерфејсима) или тесна повезаност са другим системима.

• 1: Јасно документовани интерфејси, мали број тачака повезивања, измене делују локално.
• 3: Више зависности, измене захтевају координисане релизе.
• 5: „Спагети“-интеграције, непознати токови података, велики утицај при малим изменама.

5) Квалитет података, суверенитет података и токови података

За одлуке о портфељу пресудно је да ли се подаци воде чисто и да ли су поуздано употребљиви. Суверенитет података значи: јасно је где се налази „извор истине“, како настају матични подаци (нпр. купци, артикли, добављачи) и како измене утичу низводно. Токови података обухватају и експорте, сенчане копије и ручне исправке.

• 1: Јасне одговорности, уочљиви путеви података, дефинисани интерфејси, конзистентни кључеви.
• 3: Више извора података или редовна чишћења, али транспарентно.
• 5: Нејасан извор истине, честе исправке, извештавање могуће само уз специјалну логику.

6) Ризик животног циклуса: произвођач, платформа, вештине

Технички дугови настају и услед прекида подршке: оперативни системи, базе података, библиотеке, подршка произвођача или расположивост знања. Ова димензија намерно посматра и организациону страну: да ли постоји довољно људи који могу да одржавају рад и да даље развијају систем? Постоји ли поуздан пут надоградње?

• 1: Активни циклуси подршке, планирана надоградња, вештине широко доступне.
• 3: Надоградња је пред нама, стање вештина је напрегнуто, зависност од неколико кључних лица.
• 5: Крај животног века, нема роадмапе, знање концентрисано, висок ризик добављача.

7) Покретачи трошкова и напора у текућем раду

Овде се не оцењују само трошкови инфраструктуре, већ пре свега варијабилни трошкови: напор за подршку, ручне операције, посебни процеси, раст лиценци, обавезе према спољним добављачима или скупе прозоре за одржавање. Посебно код пословног софтвера ови индиректни трошкови често су важнији од цене сервера.

• 1: Стабилан рад, мало ручних операција, трошкови предвидљиви.
• 3: Повишени оперативни напор или растући трошкови лиценци, али под контролом.
• 5: Операција „гута“ капацитете, много ручних исправки, трошкови тешко прогнозирати.

8) Критичност за пословање и зависност од процеса

Технички дугови постају релевантни за одлуке о портфељу тек када се комбинују са ризиком у процесу. Ова димензија процењује колико систем подржава кључне процесе и колика је штета у случају отказа или неправилног рада. Важно: критичност није карт-бланш за „никад не дирати“, већ аргумент за темељну стабилизацију и модернизацију.

• 1: Помоћни процес, отказ је подношљив, постоји заобилазно решење.
• 3: Важан процес, откази стварају трошкове, али су ограничиви.
• 5: Кључни процес, отказ зауставља стварање вредности или доводи до ризика усаглашености.

Како се из резултата доносе одлуке о портфељу (без лажне прецизности)

Резултат је користан тек када припреми одлуку. За то су потребна два корака: вагање и категорије одлука.

Важење: не сваки критеријум има исту тежину

Mnoge organizacije započinju sa jednakom težinom za sve kriterijume kako bi se izbegle diskusije. Kasnije se isplati jednostavno ponderisanje prema cilju portfolija, na primer:

• Prioritet bezbednosti (npr. prema nalazima audita): rizik po bezbednost i usklađenost ponderisati duplo.
• Povećati isporučivost (npr. pri velikom backlogu promena): veća težina za menjivost/pozajmljivost releasa.
• Stabilizovati troškove (npr. pri rastu podrške): faktore koji povećavaju napor u operacijama vrednovati jače.

Važno je ponderisanje transparentno dokumentovati i retko menjati. U suprotnom promene skorova deluju „politički“ umesto kao stvarno poboljšanje.

Kategorije odluka: četiri jasne opcije delovanja

Iz dimenzija se mogu izvesti četiri pragmatične kategorije koje je lako diskutovati na portfolio-ploči:

• Stabilizovati: visoki operativni/bezbednosni rizici, ali nema kratkoročnog rešenja. Fokus na runbooks, monitoring, puteve za zakrpe, tehničku higijenu.
• Modernizovati: visoki rizici promena ili životnog ciklusa uz istovremenu visoku kritičnost. Fokus na modularnu obnovu, razdvajanje interfejsa, konsolidaciju modela podataka.
• Konsolidovati/Zameniti: duplikatne funkcije, visok napor, niska diferencijacija. Fokus na gašenje, migraciju podataka, standardizaciju procesa.
• Svesno prihvatiti: niska kritičnost ili predvidiv preostali vek. Fokus na kontrole rizika, minimalno održavanje, jasnu exit-opciju.

Da to ne ostane teorija, svaka aplikacija bi dodatno trebalo da dobije jedan najbliži smislen korak – maksimalno 1–2 konkretne mere koje su realne u roku od 4–12 nedelja. Tako iz upravljanja portfoliom nastaje kontinuirani proces poboljšanja umesto godišnje radionice.

Pragmatično izgraditi osnovu podataka: koje izvore obično dovoljno

Lagan model funkcioniše ako prikupljanje podataka nije skuplje od prvih mera. Za mnoge kompanije četiri izvora podataka su dovoljna za pouzdano dodeljivanje skorova:

• Podaci iz tiketa/incidenata: učestalost, ponavljanja, vremena obrade, eskalacije. Ako ne postoji jasna kategorizacija, na početku je dovoljna gruba podela (prekid, zahtev, promena).
• Monitoring/dostupnost: ne samo „dostupnost“, već i vrhovi performansi, trajanja poslova, stope grešaka, rast zauzeća memorije i prostora na disku.
• Podaci o bezbednosti i životnom ciklusu: stanje zakrpa, datumi pRESTanka podrške (End-of-Life), zavisnosti (npr. verzija baze podataka, operativni sistem, autentifikacija), poznata izuzeća.
• Pregled arhitekture/integracija: jednostavna Application-Map (sistemska mapa) sa tokovima podataka i interfejsima. Potpunost je drugorazredna, ažurnost je presudna.

Ako brojke nedostaju, to treba biti vidljivo u skoru: „Ocena 4 zbog nedostatka dokaza“ je iskrenije od slučajnog proseka. Nepoznato je u radu često rizičnije od nečeg lošeg što bar poznajemo.

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

Честа грешка је спровођење оцењивања појединачно. У том случају оно постаје или прекомпликовано технички или превише политичко. Боље је кратка, модерирана радионица по систему, са јасним улогама. 90 минута је довољно за прву поуздану процену ако су основни подаци доступни.

Учесници (мало, али комплетно)

• Одговорна IT особа за систем: познаје roadmapu, измене, техничка уска грла.
• Операције/администрација: познаје прекиде, прозоре за одржавање, monitoring, backup/RESTore.
• Функционални власник или кључни корисник: познаје критичност процеса, заобилажења (workarounds), прихватање, вршне периоде.
• Модерација: осигурава придржавање дефиниција и документује претпоставке.

Ток (компактан, поновљив)

1. Контекст (10 мин.): сврха система, корисничке групе, главни интерфејси, модел рада (On-Prem/Cloud/Hybrid).
2. Оцена по димензији (45 мин.): по критеријуму 3–5 минута, са кратким доказима (број тикета, стање закрпа, познате зависности).
3. Утврђивање критичних тачака (15 мин.): које две димензије највише повећавају ризик/трошкове?
4. Дефинисање мера (15 мин.): 1–2 конкретна наредна корака, плус власник и циљни рок.
5. Ознака портфолија (5 мин.): Stabilizovati / Modernizovati / Konsolidovati / Prihvatiti.

Као резултат довољна су три артефакта: табела оцена, кратко образложење по димензији и кратак исечак мера. Све остало је опционo.

Типичне замке – и како их модел ублажава

Модел оцењивања може створити погрешне подстицаје ако није јасно оквиран. По искуству из пројеката, ово су најчешће замке:

Зamka 1: „Казнимо тимове за транспарентност“

Ако тимови са добром документацијом добијају лошије оцене јер откривају проблеме, модел је неисправан. Противотров: непознато (недостајући подаци) третирати као засебан ризик и јасно препознавати транспарентност као предност, нпр. у критеријуму изменљивости (rollbacks, runbooks, monitoring).

Зamka 2: Оцена постаје инструмент за смањење буџета

Ако високе оцене аутоматски воде ка „заустављању пројекта“, модел постаје политички. Боље: високе оцене доводе до предлога за одлуку са опцијама (нпр. стабилизација vs. модернизација) и јасним последицама. Буџет следи одлуку — не само оцену.

Зamka 3: Мешање користи и ризика

Функционална корист (нпр. потенцијал прихода) је важна, али представља другу осу. Проверено решење: корист пратити у засебној матрици и онда спојити у портфолио-матрицу (корист висока/ниска vs. ризик/дугови високи/ниски). Тако се избегава спор о томе да ли се безбедносни ризик „компензује приходом”.

Зamka 4: „Модернизација“ се схвата као велики пројекат

Одлуке о портфолију често не успевају због имплицитне претпоставке да модернизација може да се спроведе само као Big Bang. У стварности често је прикладније модуларно приступити модернизацији: стабилизовати Schnittstellen, стандартизовати приступе подацима, издвојити појединачне Teilprozesse, и прецизно контролисати паралелни рад. Ein Score помаже да се пронађе редослед, а не да се наметне крајње стање.

Од Score-а до роадмапе: како смислено прилагодити пакете мера

Када модел постоји, следи стварни посао: мере треба тако поделити да у свакодневном раду функционишу поред пројектног пословања. Три правила помажу да се из „wir müssten mal“ развију конкретни елементи роадмапе:

1) Прво „ублажити“ најскупље ризике

У многим портфељима безбедносни и оперативни ризици су највеће полуге јер носе спољне рокове (Audit, End-of-Life) и високе пратеће трошкове. Типичне мере за ублажавање су: успоставити Updatepfad, допунити Logging/Audit-Trail, тестирати Backup/RESTore, смањити Single-Point-of-Failure, проверити и разуманти Berechtigungen.

2) Стабилизовати интеграционе чворове пре проширења функционалности

Системи са многобројним Schnittstellen су множитељи трошкова промена. Често се исплати најпре урадити: дефинисати Schnittstellenverträge (Versionierung, Datenformate, Fehlerbehandlung), допунити Monitoring за tokove podataka, декуплисати Job-Ketten, увести Retry-Strategien (Wiederholversuche bei Fehlern). То ретко буде „видљиво“ за Fachbereich, али мерљиво смањује време неисправности и стрес при релизима.

3) Учинити мере планским као „Betriebsverbesserung“

Многи technische Schulden могу се реализовати као оперативна побољшања у малим пакетима: Runbooks, правила за аларме, Kapazitätsplanung, стандартизација окружења, редовни Patchfenster. То нису гламурозни пројекти, али повећавају поузданост – и стварају временске прозоре за веће кораке модернизације.

Како учинити Scoring одрживим: Governance без бирократије

Модел је вредан само ако не утоне након два квартала. За то је потребан једноставан процес који се уклапа у оперативни и пројектни свакодневни рад:

• Owner pro Anwendung: именована особа која одржава Score и статус мера (не спроводи их сама).
• Trigger statt Kalenderpflicht: Score-Review након Incident-Cluster, Major-Release, Audit-Fund или Plattform-Upgrade.
• Portfolio-Rhythmus: месечно/на свака два месеца 60 минута за највеће ризике, не за све системе.
• Entscheidungslog: кратка документација зашто је ризик прихваћен или одложен. То спречава касније пребацивање кривице и чини претпоставке видљивим.

Важно је повезивање са стварним управљањем: најмање један део капацитета (буџет или време тима) треба експлицитно да буде резервисан за стабилизацију/модернизацију. У супротном модел производи само сазнања без ефекта.

Закључак: Учинити технички дуг видљивим, а да се организација не преоптерети

Један лаган модел оцењивања техничког дуга не замењује детаљан архитектонски рад – али он ствара нешто што у портфељима често недостаје: упоредивост. Са осам јасних димензија, разумљивим критеријумима оцењивања и кратким форматом радионице, ризици, оперативни напори и притисак за модернизацију могу се приказати тако да IT, пословна јединица и менаџмент воде исту дискусију.

Најважнији ефекат ретко је тачна бројчана вредност. Ради се о транспарентности о томе где настаје технички дуг, како оптерећује рад и који следећи кораци су реални. Ако се скорови редовно проверавају и повезују са малим, конкретним мерама, настаје мапа пута модернизације која не живи само на нацрту, већ опстаје у свакодневном раду.

Ако желите да поставите модел оцењивања за свој апликациони портфељ или да изведете прве процене у модерираном формату, овде ћете наћи одговарајући улаз: Контактирајте нас.

За ову тему су такође важни „Процена техничког дуга“ и „Портфељске одлуке за IT“. Чланак разјашњава ове аспекте и показује на шта је у свакодневном раду потребно обратити пажњу.

Разговарајте о пројекту или плану модернизације са Net-Base.