Enterprise Architecture
Teknisk gæld: renterne betaler I hver dag
Teknisk gæld er ikke et IT-problem. Det er en regning, forretningen betaler, hver gang noget skal ændres.
Enterprise Architecture
Teknisk gæld er ikke et IT-problem. Det er en regning, forretningen betaler, hver gang noget skal ændres.
Kort fortalt
Teknisk gæld er de genveje og udskudte opgraderinger, der gør det dyrere at ændre jeres systemer. Som rigtig gæld har den renter: hver ændring tager længere tid, koster mere og indebærer større risiko, jo mere gæld der har hobet sig op.
Gæld er ikke altid dårlig. En bevidst genvej kan være den rigtige beslutning. Problemet er den gæld, som ingen kender og ingen afdrager på.
Gratis skabelon · Excel
Registrér den tekniske gæld med renter, risiko og forslag til afdrag. Scoren beregnes automatisk, så I kan prioritere efter forretningsrisiko.
Gratis og uden tilmelding.
Flere gratis skabeloner finder I under skabeloner og værktøjer.
Kurven er en illustration, ikke en måling. Mønsteret er dog velkendt: uden afdrag stiger prisen for hver ændring år for år. Med et fast afdrag holder den sig nogenlunde stabil.
Teknisk gæld handler sjældent om grim kode. I et typisk systemlandskab ligger den største gæld i fire områder.
ERP eller database uden support fra leverandøren
Typisk konsekvens
Sikkerhedshuller og dyre nødopgraderinger
Standardsystemer, der er tilpasset så meget, at de ikke kan opgraderes
Typisk konsekvens
Hver opgradering bliver et projekt
Punkt til punkt-integrationer, som ingen har overblik over
Typisk konsekvens
En ændring ét sted giver fejl et andet sted
De samme kundedata i fem systemer med forskellige værdier
Typisk konsekvens
Rapporter, som ingen stoler på
Fra vores egne projekter
Hos en kunde skulle flere tenants lægges sammen. Undervejs viste det sig, at et stort antal applikationer, som ingen havde overblik over, var kritiske for forretningen.
Sammenlægningen endte katastrofalt. Resultatet blev dyr nedetid og et tab, der kunne ses på bundlinjen. Den gæld, ingen kender, er den farligste.
Ikke al gæld skal betales. Noget gæld ligger i systemer, der alligevel skal udfases. Andet koster så lidt, at det kan vente.
Det ældste system bliver udskiftet først, uanset hvad det betyder for forretningen. Giver travlhed, men sjældent værdi.
Gælden bliver afdraget der, hvor den koster mest eller kan gøre størst skade: kritiske systemer uden support og flaskehalse for nye projekter.
Lav et gældsregister: hvad er gælden, i hvilket system, hvad koster den og hvad sker der, hvis I lader den ligge?
Hvor meget gør gælden hver ændring dyrere eller langsommere? Det er renten, ikke selve gælden, I skal prioritere efter.
Reservér en fast andel af udviklingskapaciteten til afdrag, fx 15-20 procent. Uden et fast afdrag taber gælden altid til nye projekter.
Gennemgå registret i arkitekturfunktionen hvert kvartal og rapportér udviklingen til ledelsen.
Erfaring fra vores projekter
Ledelsen siger sjældent ja til at "rydde op". De siger ja til at gøre de næste projekter billigere og hurtigere. Det er det samme arbejde, men en anden samtale. Gæld, der bliver forklaret som renter, bliver prioriteret.
Uden governance og oprydning hober systemer og software sig op over tid. Det sker gennem skygge-IT, opkøb, skiftende ledelser og nye tiltag. Er man ikke konstant over det med et opdateret systemlandskab og EA-governance, samler der sig så mange ubekendte, at overblikket mangler den dag, man beslutter at lægge systemer sammen eller udfase dem. Så bliver et projekt, der burde have været smidigt, uforudsigeligt.
Mere om Enterprise Architecture
Vi hjælper med arkitektur, der hænger sammen med forretningen. Tag en uforpligtende samtale om jeres situation.