Az informatikain rendszerek legnagyobb ellensége a slendrián kódolás, a rossz rendszertervezés és az elmaradt karbantartás. Rövidtávon mindegyik hasznosnak tűnhet, de aztán jönnek a miattuk keletkező költségek, amelyeket valahogy el kellene tüntetni.

Amikor a felső vezetőket képbe kell helyezni az elöregedett infrastruktúra speciális költségeiről és kockázatairól, az informatikai főnökök elkezdik számszerűsíteni az IT szervezetek technikai adósságát. Mivel az utóbbi időben szinte lehetetlen pénzt szerezni olyan beruházásokra, amelyek nem hozhatók közvetlen összefüggésbe a profittermeléssel, az egyes részlegek vezetőinek kreatív megközelítésekkel kell előállniuk, ha át akarják hágni ezt az akadályt. A technikai adósság kiszámítása is erről a tőről fakad, hiszen nélküle nem tudnák alátámasztani, hogy szükségük van IT-beruházási és karbantartási pénzekre.

A technikai adósság koncepciója eredetileg a gyors és tisztátlan kódolási gyakorlatra vonatkozott, mára azonban alkalmazzák egyéb informatikai területekre is, beleértve az infrastruktúrát, az architektúrát, az integrációt és a folyamatokat is.

Mike Habeck, a Deloitte tanácsadócég igazgatója nemrégiben a Wall Street Journalban fejtette ki, hogy egyre több CIO szentel figyelmet a technikai adósságnak. Leginkább azonosítani és kategorizálni akarják, illetve meg akarják határozni e költségek mértékét, illetve annak a haszonnak a nagyságát is, amelyet a technikai adósság alacsonyabb szintre szállításával elérhetnek.

A tanácsadócég egy másik igazgatója, Scott Buchholz pedig arra hívta fel a figyelmet, hogy a CIOk különböző okoknál fogva igyekeznek megmérni a technikai adóságot az üzleti építkezéstől fogva, a központi projektek megújításán keresztül, a karbantartási összegek megnöveléséig, illetve az üzleti diszfunkciók kialakulásának megelőzéséig. A CIOk ennek érdekében hajlandók belevágni a technikai adósság egész portfóliót felölelő felértékelésbe, hogy feltárják az informatikai részlegek legköltségesebb és súlyosabb problémáit, ami segít fontossági sorrendbe tenni a karbantartási munkákat.

a_levelBuchholz rámutatott, hogy a módszerek nem egyformán fejlettek a különféle területeken. A gyenge kódolásból származó minőségi adósság kiszűrésére sokkal fejlettebb és a számszerűsítést jobban támogató folyamatokat használnak, mint az informatikai infrastruktúra, az architektúra, az integráció és a folyamatok területén tapasztalható technikai adósság meghatározására. Habár ez méréstechnikai adósság, de az utóbbi területeken még mindig inkább művészet, mint tudomány a helyes becslés kialakítása. A Deloitte szakértői szerint azonban az informatikai vezetők mégis helyesen orientáló becsült költségekhez jutnak a gyenge költséghatékonyságú rendszerekről és az elavult infrastruktúráról.

Az IT vezetőknek fontos magukban tisztázniuk, hogy miféle eredmény kívánnak elérni, hiszen a felhasználhatóságuk is ettől függ majd. Például az a CIO, aki cserélni szeretne egy öreg rendszert, annak nincs szüksége egy listára, amely minden kódolási hibát tartalmaz. Ehelyett azt kell kimutatnia, hogy mennyivel jár jobban a vállalat, ha a cserét elvégzi. Ezzel szemben az a CIO, aki ki kívánja javítani a rendszert, meg kell, hogy határozza a problémákat, azok súlyosságát, valamint a javítási költségeket.

Az informatikai vezető így aztán egy célt szem előtt tartva választhatja ki, hogy melyik megközelítést alkalmazza a technikai adósság meghatározásához. Alapvetően két út kínálkozik: alulról felfelé és felülről lefelé.

Az alulról felfelé technikát elsősorban a kódolás minőségének vizsgálatánál használják, amikor a legalacsonyabb költségszintet és a legmagasabb javítási költségeket vetik össze az adósság értékének meghatározásához. Azután, hogy meghatározták a hibák számát, súlyosságát és típusát, már kiszámíthatóvá válik, hogy ez mekkora technikai adósságot hordoz, beleértve a jelenlegi rendszer fenntartását és az üzleti zavarok potenciális költségét. Végül ennek alapján az adóssággal kapcsolatba hozható munkaerőköltség is kalkulálhatóvá válik a ráfordított munkaidő alapján.

A felülről lefelé megközelítés inkább az IT infrastruktúra, az architektúra, integráció és folyamatok esetében alkalmazható. Ez sokkal szubjektívebb az előbb ismertetett eljárásnál, és sokkal erősebben támaszkodik a benchmarkokra, becslésekre. Ha a CIO szabványosítani szeretné a gépparkot, akkor tisztában szeretne lennie vele, hogy a rendszerben telepített szerverek hányfélék, mennyi van belőlük, ezeknél mekkora a hibaarány és a karbantartási költség, az egy rendszeradminisztrátorra jutó szerverszám, e munkatársakra eső munkaerőköltség. Az adatok birtokában már ki tudja mutatni, hogy a szabványosítás mennyivel csökkentheti a munkaerő- és karbantartási költségeket, az informatikai rendszer bonyolultságát vagy a hardverhiba esélyét.

A technikai adósság kiszámítása, különösen az alulról felfelé haladó elemzést használva az egész alkalmazás portfólióban, igen jelentős vállalkozás. Buchholz szerint ez könnyen hónapokig is eltarthat. Ezzel szemben az egyetlen rendszerben alulról felfelé haladó vizsgálat, vagy az infrastruktúra technikai adóságának felülről lefelé való becslése lényegesen rövidebb idő alatt elvégezhető.

Keretes Mit lehet kezdeni a technikai adóssággal?

Két fő szempontot szokás a technikai adósság kezelésénél figyelembe venni. Az első, hogy tudjuk, hol állunk. Ha már ismert a tartozás, akkor már egyszerűbb meggyőző módon leírni ennek potenciális hatását azok számára, akik befolyással vannak az IT kiadásokra. Ha azok a döntéshozók ráébrednek, hogy a technikai adósság áramkimaradások okozhat a kritikus rendszerekben, úgy talán inkább különítenek el pénzt az eltüntetésére. A műszaki adósság egy olyan mutató, amelyre az IT-szervezetnek nem csak a tervezésben és a portfolió menedzsmentben, hanem a projektek megvalósításakor is figyelni kell.

A második szempont foglalkozik a technikai adósság tényleges menedzselésével. Több út is van ennek megközelítésére. Meg lehet próbálni mindent egyszerre kijavítani egy hatalmas erőfeszítéssel, de ez ritkán működik. Illetve szelektív megközelítést alkalmazva szisztematikusan csökkenthető a szükséges javításokban mutatkozó elmaradás. A stratégiai célok elérését figyelembe véve a feladatok akár több évre is eloszthatók, s így kisebb teher nehezedik a szervezetre. Ez a gyakorlat segít azonosítani és rangsorolni a portfóliónak azokat az elemeit, amelyeket frissíteni vagy cserélni kell.