Att synliggöra tekniska skulder: en lättviktig scoringsmodell för portföljbeslut

I många IT-organisationer är teknisk skuld länge ett permanent tillstånd: applikationer körs, processer fungerar, och ändå blir varje förändring segare, varje release mer riskfylld och varje incident dyrare. Problemet är sällan att ingen ser riskerna – utan att de inte är jämförbara. När fem system samtidigt är „kritiska“ går det i slutändan inte att prioritera någon. Precis här hjälper en scoringmodell för teknisk skuld: ett lättviktigt, upprepbart bedömningsramverk som avbildar tekniska risker, driftsinsats och moderniseringstryck så att portföljbeslut blir tillförlitliga.

Detta inlägg beskriver en scoringmodell som klarar sig utan ett mammut-assessment, men som fungerar i vardagen för IT-ledning, drift, administratörer, projektansvariga och verksamhetsområden. I fokus står inte interna koddetaljer, utan effekter på drift, säkerhet, data, gränssnitt, leveransförmåga och underhåll. Målet är ett gemensamt språk som avdramatiserar budget- och prioriteringsdiskussioner och gör modernisering planbar.

Scoringmodell för teknisk skuld i praktiken

Teknisk skuld är en samlingsbeteckning för beslut och arvlast som kortsiktigt sparat tid men som långsiktigt orsakar räntekostnader. Dessa „räntor“ visar sig i vardagen som längre ledtider, mer samordning, högre felkvoter, säkerhetsluckor, specialistkunskap hos få personer eller som beroenden av komponenter som inte längre stöds. Problemet är att många av dessa effekter inte framträder som en tydlig kostnadsställning.

Typiska skäl till att teknisk skuld försvinner i portföljomgångar:

• Avsaknad av jämförbarhet: En stabil äldre monolit, ett SaaS-verktyg med växande licenstryck och en integrationskedja med nattkörningar är svåra att väga mot varandra utan ett ramverk.
• Oenhetligt dataläge: För system A finns incidentstatistik och övervakning, för system B bara magkänsla, för system C ingenting.
• Blandade diskussioner: Verksamhetsnytta, tekniska risker och personliga preferenser (teknologi, teamets önskemål) hamnar i samma gryta.
• För stora bedömningsmodeller: Omfattande mognadsmodeller är meningsfulla – men de underhålls ofta inte regelbundet. För portföljbeslut är upprepbarhet avgörande.

En lättviktig scoringmodell är ingen perfekt sanning. Det är ett verktyg för att minska osäkerhet och göra beslut spårbara – inklusive de antaganden som ligger bakom.

Principer för en lättviktig scoringmodell

För att en scoringmodell inte ska sluta som en „Excel-övning“ bör den uppfylla några grundläggande principer:

• Få dimensioner, tydliga definitioner: Hellre 6–8 bedömningsdimensioner förklarade noggrant än att samla 20 halvkriterier.
• Mätbart, men inte mätfixerat: Inte allt finns tillgängligt som siffra. Viktigt är att kriterierna tillämpas konsekvent.
• Lämplig för portfölj: Bedömningen måste fungera över system – oberoende av om det gäller företagsanpassad programvara, standardprodukter eller integrationskomponenter.
• Explicitare perspektiv: drift, säkerhet, data och verksamhetsområde bör finnas med i modellen, så att man inte bara diskuterar „teknik mot verksamhet“.

I praktiken har det visat sig fungera att behandla scoren som underlag för samtal: den levererar en prioriterad lista, men inga automatiska beslut. Portföljkommittéer förblir ansvariga – och dokumenterar avvikelser medvetet.

Scoring-modellen: 8 dimensioner som verkligen räknas i driften

Följande rutnät använder åtta dimensioner som enkelt kan insamlas i typiska företagsmiljöer. Varje dimension bedöms på en skala från 1 till 5 (1 = okritiskt/god kontroll, 5 = kritiskt/akut åtgärdsbehov). Viktigt är inte matematisk perfektion, utan tydligheten i kriterierna.

1) Driftstabilitet och störningsprofil

Här handlar det om frågan: Hur ofta stör systemet driften – och hur kostsamma är dessa störningar organisatoriskt? Basen är incidents (störningar), återkommande tickets, on-call-eskalationer och oplanerade underhåll. Även „tyst“ instabilitet räknas, till exempel när nattkörningar ofta måste efterbearbetas.

Bedömningsankare (exempel):

• 1: Sällsynta incidents, tydliga runbooks (driftmanualer), återstart övad.
• 3: Regelbundna störningar eller frekventa prestandaproblem, men hanterbara.
• 5: Återkommande avbrott, hög supportbelastning, workarounds istället för att åtgärda grundorsaken.

2) Säkerhets- och efterlevnadsrisk

Denna dimension bedömer hur väl systemet är skyddat mot säkerhetsincidenter och hur revisionsbart det är i drift. Det innefattar patchbarhet, stödda komponenter, autentisering (t.ex. SSO via SAML/OIDC – alltså central inloggning), loggning (Audit-Trail: spårbar händelsekedja) och skydd av känsliga data.

• 1: Regelbundna uppdateringar, tydliga roller/rättigheter, spårbara loggar, inga kända „End-of-Life“-komponenter.
• 3: Delvis föråldrade komponenter eller luckor i loggning/recertifiering, kompensationsåtgärder finns.
• 5: Kritiska eftersläpningar, saknade patchar, oklara ansvarsförhållanden, revisionsrisker.

3) Änderbarkeit und Release-Fähigkeit

„Hur svårt är det att leverera ändringar säkert?“ Det är kärnan i många tekniska skulder. Det avser testbarhet (regression: återupprepningstester), deploy-process, rollback-förmåga (ren återfallsoption), beroende av enskilda personer samt tiden från krav till produktionssättning.

• 1: Reproducerbara releaser, definierade miljöer, planbara underhållsfönster.
• 3: Releaser möjliga men med manuella steg och ökat behov av samordning.
• 5: Varje ändring är en risk, deployment endast „med rätt personer“, rollback oklart.

4) Arkitektur- och integrationskomplexitet

Denna dimension fångar inte om en arkitektur är „modern“, utan om den är hanterbar. Integrationer är ofta kostnadsdrivare: punkt-till-punkt-gränssnitt, speciella filformat, tidskritiska batchbearbetningar, saknad versionshantering av API:er (gränssnittsavtal) eller tät koppling till andra system.

• 1: Klart dokumenterade gränssnitt, få kopplingspunkter, förändringar får lokal påverkan.
• 3: Flera beroenden, ändringar kräver koordinerade releaser.
• 5: „Spaghetti“-integrationer, okända dataflöden, hög påverkan vid små ändringar.

5) Datenqualität, Datenhoheit und Datenflüsse

För portföljbeslut är det avgörande om data hålls rena och kan användas tillförlitligt. Dataägarskap innebär: det är tydligt var „källan till sanningen“ finns, hur stamdata (t.ex. kunder, artiklar, leverantörer) uppstår och hur ändringar påverkar efterföljande system. Dataflöden omfattar också exporter, skuggkopior och manuella korrigeringar.

• 1: Klara ansvarsförhållanden, spårbara datavägar, definierade gränssnitt, konsekventa nycklar.
• 3: Flera datakällor eller regelbundna rensningar, men transparent.
• 5: Otydlig sanning, frekventa korrigeringar, rapportering endast möjlig med speciallogik.

6) Lifecycle-Risiko: Hersteller, Plattform, Skills

Teknisk skuld uppstår också genom avvecklingar: operativsystem, databaser, bibliotek, leverantörsstöd eller tillgängligt kunnande. Denna dimension granskar medvetet den organisatoriska sidan: finns tillräckligt många personer som kan driva drift och vidareutveckling? Finns en pålitlig uppgraderingsväg?

• 1: Aktiva supportcykler, uppgradering planerad, kompetens brett tillgänglig.
• 3: Uppgradering står för dörren, kompetensläget spänt, beroende av några nyckelpersoner.
• 5: Utgånget, ingen roadmap, kunskap koncentrerad, leverantörsrisk hög.

7) Kosten- und Aufwandstreiber im laufenden Betrieb

Här bedöms inte bara infrastrukturkostnader, utan framför allt variabla kostnader: supportinsats, manuella arbetsuppgifter, särskilda processer, licenstillväxt, beroende av externa leverantörer eller kostsamma underhållsfönster. Särskilt för affärssystem är dessa indirekta kostnader ofta viktigare än serverpriser.

• 1: Stabil drift, få manuella arbetsuppgifter, kostnader planbara.
• 3: Ökat driftarbete eller stigande licenskostnader, men hanterbart.
• 5: Driften „äter“ kapacitet, många manuella korrigeringar, kostnader svåra att prognostisera.

8) Business-Kritikalität und Prozessabhängigkeit

Teknisk skuld blir relevant för portföljbeslut först när den kombineras med processrisk. Denna dimension bedömer hur mycket systemet bär kärnprocesser och hur stor skadan blir vid störning eller fel. Viktigt: kritikalitet är ingen ursäkt för att „aldrig röra“, utan ett argument för noggrann stabilisering och modernisering.

• 1: Stödjande process, driftstörning hanterbar, work-around finns.
• 3: Viktig process, driftstörningar medför kostnader men kan begränsas.
• 5: Kärnprocess, driftstopp stoppar värdeskapande eller leder till regelöverträdelser.

Wie aus Scores Portfolio-Entscheidungen werden (ohne Scheingenauigkeit)

Ett score är först användbart när det förbereder ett beslut. För detta krävs två steg: viktning och beslutskategorier.

Gewichtung: nicht jedes Kriterium zählt gleich

Många organisationer börjar med lika viktning för att undvika diskussioner. Senare är det vettigt med en enkel viktning efter portföljmål, till exempel:

• Säkerhet först (t.ex. efter revisionsfynd): säkerhets- och regelefterlevnadsrisker vikta dubbelt.
• Öka leveransförmågan (t.ex. vid hög förändringskö): ändringsbarhet/releaseförmåga viktas högre.
• Stabilisera kostnader (t.ex. vid ökande support): kostnadsdrivare i driften viktas högre.

Det är viktigt att dokumentera viktningen transparent och bara ändra den sällan. Annars uppfattas poängändringar som ‚politiska‘ snarare än verkliga förbättringar.

Beslutskategorier: fyra tydliga handlingsalternativ

Utifrån dimensionerna kan fyra pragmatiska kategorier härledas som lämpar sig för diskussion i Portfolio-Board:

• Stabilisera: Höga drift-/säkerhetsrisker, men ingen kortsiktig ersättning möjlig. Fokus på runbooks, övervakning, patchvägar, teknisk hygien.
• Modernisera: Höga förändrings- eller livscykelrisker samtidigt som hög kritikalitet. Fokus på modulär förnyelse, lösgörning av gränssnitt, konsolidering av datamodeller.
• Konsolidera/ersätta: Dubbla funktioner, höga kostnader, låg differentiering. Fokus på nedstängning, datamigrering, processharmonisering.
• Medvetet acceptera: Låg kritikalitet eller förutsägbar återstående livslängd. Fokus på riskkontroller, minimalt underhåll, tydlig exit-option.

För att detta inte ska förbli teoretiskt bör varje applikation dessutom få ett nästa meningsfulla steg – högst 1–2 konkreta åtgärder som är realistiska på 4–12 veckor. På så sätt blir portföljhantering en löpande förbättringsprocess istället för en årlig workshop.

Bygg datagrundlaget pragmatiskt: vilka källor räcker oftast

En lättviktig modell lever på att datainsamlingen inte är dyrare än de första åtgärderna. För många företag räcker fyra datakällor för att tilldela seriösa poäng:

• Ticket-/incidentdata: frekvens, upprepningar, handläggningstider, eskalationer. Om det inte finns en ren kategorisering räcker i början en grov indelning (störning, förfrågan, ändring).
• Övervakning/tillgänglighet: Inte bara ‚uptime‘, utan också pRESTandatoppar, jobbkörtider, felkvoter, minnes-/disktillväxt.
• Säkerhets- och livscykelinfo: patchstatus, end-of-life-datum, beroenden (t.ex. databasversion, operativsystem, autentisering), kända undantag.
• Arkitektur-/integrationsöversikt: En enkel Application-Map (systemkarta) med dataflöden och gränssnitt. Fullständighet är sekundärt, aktualitet räknas.

Om siffror saknas bör det synas i poängen: ‚Betyg 4 på grund av saknade bevis‘ är ärligare än ett slumpmässigt medelvärde. Okänt är i drift ofta mer riskabelt än dåligt som man åtminstone känner till.

Scoring-workshop på 90 minuter: förlopp, roller, resultatartefakter

Ett vanligt fel är att genomföra poängsättning som en individuell uppgift. Då blir den antingen för teknisk eller för politisk. Bättre är en kort workshop per system, ledd och med tydliga roller. 90 minuter räcker för en första tillförlitlig bedömning om grunddata finns tillgängliga.

Deltagare (få men fullständiga)

• Systemansvarig IT: känner till färdplan, förändringar, tekniska flaskhalsar.
• Drift/administration: känner till incidenter, underhållsfönster, övervakning, backup/RESTore.
• Affärsansvarig eller nyckelanvändare: känner till processkritikalitet, workarounds, acceptans, topptider.
• Mötesledare: säkerställer efterlevnad av definitionerna och dokumenterar antaganden.

Genomförande (kompakt, upprepbart)

1. Kontext (10 min): systemets syfte, användargrupper, huvudsakliga gränssnitt, driftsmodell (On-Prem/Cloud/Hybrid).
2. Poäng per dimension (45 min): per kriterium 3–5 minuter, med korta belägg (antal ärenden, patchnivå, kända beroenden).
3. Identifiera hotspots (15 min): vilka 2 dimensioner driver risk/kostnader starkast?
4. Fastställ åtgärder (15 min): 1–2 konkreta nästa steg, plus ägare och måldatum.
5. Portföljetikett (5 min): Stabilisera / Modernisera / Konsolidera / Acceptera.

Som resultat räcker tre artefakter: poängtabell, kort motivering per dimension och ett åtgärdsutdrag. Allt annat är valfritt.

Typiska fallgropar – och hur man fångar dem i modellen

En poängsättningsmodell kan skapa felaktiga incitament om den inte är tydligt inramad. Utifrån projekterfarenhet är detta de vanligaste fallgroparna:

Fallgropar 1: „Vi straffar team för transparens“

Om team med god dokumentation får sämre poäng därför att de synliggör problem är modellen undermålig. Motmedel: behandla okänt (saknade data) som en egen risk och erkänn transparens uttryckligen som en fördel, t.ex. i kriteriet ändringsbarhet (rollbacks, runbooks, övervakning).

Fallgropar 2: Poängen används som verktyg för budgetnedskärningar

Om höga poäng automatiskt leder till „projektstopp“ blir modellen politisk. Bättre: höga poäng leder till ett beslutsunderlag med alternativ (t.ex. stabilisering vs. modernisering) och tydliga konsekvenser. Budgeten följer beslutet – inte enbart poängen.

Fallgropar 3: Blandning av nytta och risk

Affärsnytta (t.ex. intäktspotential) är viktig, men en annan axel. Ett beprövat förhållningssätt: bedöm nytta i ett separat rutnät och sammanför sedan i en portföljmatris (nytta hög/låg vs. risk/teknisk skuld hög/låg). Då behöver man inte diskutera om en säkerhetsrisk kan kompenseras „genom intäkt“.

Fallgropar 4: „Modernisering“ uppfattas som ett stort projekt

Portföljbeslut misslyckas ofta på grund av det underförstådda antagandet att modernisering bara kan ske som en Big Bang. I verkligheten är en modulär modernisering ofta mer ändamålsenlig: stabilisera gränssnitt, standardisera dataåtkomst, avgränsa enskilda delprocesser, styra parallellkörning på ett ordnat sätt. En Score hjälper till att hitta ordningsföljden, inte att tvinga fram ett slutligt tillstånd.

Från Score till roadmap: hur åtgärdspaket skärs till på ett ändamålsenligt sätt

När modellen är på plats börjar det egentliga arbetet: att dela upp åtgärder så att de fungerar i vardagen vid sidan av projektverksamheten. Tre regler hjälper till att omvandla „vi borde“ till konkreta roadmap-element:

1) Först minska de dyraste riskerna

I många portföljer är säkerhets- och drift risker de största hävstängerna, eftersom de har externa tidsfrister (Audit, End-of-Life) och höga följdkostnader. Typiska åtgärder för att mildra dessa är: säkerställa en uppdateringsväg, komplettera logging/audit-trail, testa Backup/RESTore, minska Single-Point-of-Failure, verifiera behörighetsinställningar.

2) Stabilisera integrationsknutpunkter före funktionsutbyggnad

System med många gränssnitt multiplicerar förändringskostnaderna. Här är det ofta värt att först: definiera gränssnittsavtal (versionering, dataformat, felhantering), lägga till monitoring för dataflöden, avkoppla jobbkedjor, införa retry-strategier (upprepade försök vid fel). Det är sällan synligt för verksamheten, men det minskar driftstopp och release-stress mätbart.

3) Göra åtgärder planbara som „driftsförbättringar“

Många tekniska skulder kan genomföras som operativa förbättringar i små paket: Runbooks, larmregler, kapacitetsplanering, standardisering av miljöer, regelbundna patchfönster. Det är inga glamorösa projekt, men de ökar tillförlitligheten – och skapar tidsfönster för större moderniseringssteg.

Så blir scoringen varaktig: styrning utan byråkrati

En modell är bara värdefull om den inte somnar in efter två kvartal. För det krävs en enkel process som passar drift- och projektvardagen:

• Owner per applikation: En namngiven person som underhåller Score och åtgärdsstatus (implementerar inte ensam).
• Trigger istället för kalenderplikt: Score-Review efter incidentkluster, Major-Release, Audit-Fund eller Plattform-Upgrade.
• Portföljrytm: Månatligen/varannan månad 60 minuter för toppriskerna, inte för alla system.
• Beslutslogg: Kort dokumentation om varför en risk accepterades eller sköts upp. Det förhindrar senare skuldbeläggning och gör antaganden synliga.

Viktigt är kopplingen till verklig styrning: Minst en del av kapaciteten (budget eller teamtid) bör uttryckligen reserveras för stabilisering/modernisering. Annars levererar modellen bara insikter utan effekt.

Slutsats: Göra tekniska skulder synliga utan att överbelasta organisationen

Ett lättviktigt scoringsmodell för tekniska skulder ersätter inte detaljerat arkitekturarbete – men det skapar något som ofta saknas i portföljer: jämförbarhet. Med åtta tydliga dimensioner, spårbara bedömningsankare och ett kort workshopformat går det att presentera risker, driftinsats och moderniseringstryck så att IT, verksamheten och ledningen för samma diskussion.

Den viktigaste effekten är sällan det exakta siffervärdet. Det är transparensen kring var tekniska skulder uppstår, hur de belastar driften och vilka nästa steg som är realistiska. Om scoringsvärden regelbundet granskas och kopplas till små, konkreta åtgärder uppstår en moderniseringsfärdplan som inte lever på ritbordet utan bärs i det dagliga arbetet.

Om du vill upprätta scoringsmodellen för ditt applikationsportfolio eller genomföra de första bedömningarna i ett modererat format hittar du här en lämplig ingång: Ta kontakt.

I anslutning till detta ämne är även bedömning av tekniska skulder och portföljbeslut för IT viktiga. Artikeln placerar dessa aspekter på ett begripligt sätt och visar vad som är avgörande i vardagen.

Diskutera projekt eller moderniseringsinitiativ med Net-Base.