Technische Schulden sichtbar machen: Ein leichtgewichtiges Scoring-Modell für Portfolio-Entscheidungen

In vielen IT-Organisationen sind technische Schulden längst ein Dauerzustand: Anwendungen laufen, Prozesse funktionieren, und trotzdem wird jeder Change zäher, jedes Release riskanter und jede Störung teurer. Das Problem ist selten, dass niemand die Risiken sieht – sondern dass sie nicht vergleichbar sind. Wenn fünf Systeme gleichzeitig „kritisch“ sind, ist am Ende keines priorisierbar. Genau hier hilft ein technische Schulden Scoring-Modell: ein leichtgewichtiges, wiederholbares Bewertungsraster, das technische Risiken, Betriebsaufwand und Modernisierungsdruck so abbildet, dass Portfolio-Entscheidungen belastbar werden.

Dieser Beitrag beschreibt ein Scoring-Modell, das ohne Mammut-Assessment auskommt, aber im Alltag von IT-Leitung, Betrieb, Administratoren, Projektverantwortlichen und Fachbereichen funktioniert. Im Fokus stehen nicht interne Code-Details, sondern Auswirkungen auf Betrieb, Sicherheit, Daten, Schnittstellen, Lieferfähigkeit und Wartung. Ziel ist eine gemeinsame Sprache, die Budget- und Priorisierungsdiskussionen entschärft und Modernisierung planbar macht.

technische Schulden Scoring-Modell in der Praxis

Technische Schulden sind ein Sammelbegriff für Entscheidungen und Altlasten, die kurzfristig Zeit gespart haben, langfristig aber Zinskosten verursachen. Diese „Zinsen“ zeigen sich im Unternehmensalltag als längere Durchlaufzeiten, mehr Abstimmung, höhere Fehlerraten, Sicherheitslücken, Spezialwissen bei wenigen Personen oder als Abhängigkeiten von nicht mehr unterstützten Komponenten. Der Haken: Viele dieser Effekte tauchen nicht als klare Kostenstelle auf.

Typische Gründe, warum technische Schulden in Portfolio-Runden untergehen:

• Fehlende Vergleichbarkeit: Ein stabiler Alt-Monolith, ein SaaS-Tool mit wachsendem Lizenzdruck und eine Integrationsstrecke mit Nachtjobs lassen sich ohne Raster schwer gegeneinander abwägen.
• Uneinheitliche Datenlage: Für System A gibt es Incident-Statistiken und Monitoring, für System B nur Bauchgefühl, für System C gar nichts.
• Vermischte Diskussionen: Fachlicher Nutzen, technische Risiken und persönliche Präferenzen (Technologie, Team-Wunsch) landen im selben Topf.
• Zu große Bewertungsmodelle: Umfassende Reifegradmodelle sind sinnvoll – werden aber häufig nicht regelmäßig gepflegt. Für Portfolio-Entscheidungen zählt Wiederholbarkeit.

Ein leichtgewichtiges Scoring-Modell ist keine perfekte Wahrheit. Es ist ein Instrument, um Unsicherheit zu reduzieren und Entscheidungen nachvollziehbar zu machen – inklusive der Annahmen, die dahinterstehen.

Prinzipien für ein leichtgewichtiges Scoring-Modell

Damit ein Scoring-Modell nicht als „Excel-Übung“ endet, sollte es ein paar Grundprinzipien erfüllen:

• Wenige Dimensionen, klare Definitionen: Lieber 6–8 Bewertungsdimensionen sauber erklären als 20 Halbkriterien sammeln.
• Messbar, aber nicht messfixiert: Nicht alles ist als Zahl verfügbar. Wichtig ist, dass die Kriterien konsistent angewendet werden.
• Portfolio-tauglich: Die Bewertung muss systemübergreifend funktionieren – unabhängig davon, ob es sich um individuelle Unternehmenssoftware, Standardprodukte oder Integrationskomponenten handelt.
• Explizite Perspektiven: Betrieb, Security, Daten und Fachbereich sollen im Modell vorkommen, damit nicht nur „Technik gegen Business“ diskutiert wird.
• Regelmäßiger Rhythmus: Ein Score ist nur hilfreich, wenn er mindestens quartalsweise plausibilisiert werden kann – idealerweise an Ereignisse gekoppelt (Release, Incident, Audit, Anbieterwechsel).

In der Praxis hat sich bewährt, den Score als Gesprächsgrundlage zu behandeln: Er liefert eine priorisierte Liste, aber keine automatischen Entscheidungen. Portfolio-Gremien bleiben verantwortlich – und dokumentieren Abweichungen bewusst.

Das Scoring-Modell: 8 Dimensionen, die im Betrieb wirklich zählen

Das folgende Raster nutzt acht Dimensionen, die sich in typischen Unternehmenslandschaften gut erheben lassen. Jede Dimension wird auf einer Skala von 1 bis 5 bewertet (1 = unkritisch/gut beherrscht, 5 = kritisch/akuter Handlungsdruck). Wichtig ist nicht die mathematische Perfektion, sondern die Eindeutigkeit der Kriterien.

1) Betriebsstabilität und Störungsprofil

Hier geht es um die Frage: Wie oft stört das System den Betrieb – und wie teuer sind diese Störungen organisatorisch? Basis sind Incidents (Störungen), wiederkehrende Tickets, On-Call-Eskalationen und ungeplante Wartungen. Auch „leise“ Instabilität zählt, etwa wenn Nachtläufe häufig nachgearbeitet werden müssen.

Bewertungsanker (Beispiele):

• 1: Seltene Incidents, klare Runbooks (Betriebshandbücher), Wiederanlauf geübt.
• 3: Regelmäßige Störungen oder häufige Performance-Themen, aber beherrschbar.
• 5: Wiederkehrende Ausfälle, hohe Supportlast, Workarounds statt Ursachenbehebung.

2) Sicherheits- und Compliance-Risiko

Diese Dimension bewertet, wie gut das System gegen Sicherheitsvorfälle abgesichert ist und wie auditfähig (prüfbar) es sich betreiben lässt. Dazu gehören Patchfähigkeit, unterstützte Komponenten, Authentifizierung (z. B. SSO über SAML/OIDC – also zentrale Anmeldung), Protokollierung (Audit-Trail: nachvollziehbare Ereigniskette) und Schutz sensibler Daten.

• 1: Regelmäßige Updates, klare Rollen/ Rechte, nachvollziehbare Logs, keine bekannten „End-of-Life“-Komponenten.
• 3: Teilweise veraltete Komponenten oder Lücken in Protokollierung/Rezertifizierung, Kompensationsmaßnahmen vorhanden.
• 5: Kritische Altstände, fehlende Patches, ungeklärte Verantwortlichkeiten, Audit-Risiken.

3) Änderbarkeit und Release-Fähigkeit

„Wie schwer ist es, Änderungen sicher auszuliefern?“ Das ist der Kern vieler technischer Schulden. Gemeint sind Testbarkeit (Regression: Wiederholungstests), Deploy-Prozess, Rollback-Fähigkeit (saubere Rückfalloption), Abhängigkeit von Einzelpersonen sowie die Zeit von Anforderung bis Produktivsetzung.

• 1: Reproduzierbare Releases, definierte Umgebungen, planbare Wartungsfenster.
• 3: Releases möglich, aber mit manuellen Schritten und erhöhtem Abstimmungsaufwand.
• 5: Jede Änderung ist Risiko, Deploy nur „mit den richtigen Leuten“, Rollback unklar.

4) Architektur- und Integrationskomplexität

Diese Dimension erfasst nicht, ob eine Architektur „modern“ ist, sondern ob sie beherrschbar ist. Integrationen sind dabei oft der Kostentreiber: Punkt-zu-Punkt-Schnittstellen, spezielle Dateiformate, zeitkritische Batch-Verarbeitung, fehlende Versionierung von APIs (Schnittstellenverträgen) oder enge Kopplung an andere Systeme.

• 1: Klar dokumentierte Schnittstellen, wenige Kopplungspunkte, Änderungen wirken lokal.
• 3: Mehrere Abhängigkeiten, Änderungen erfordern koordinierte Releases.
• 5: „Spaghetti“-Integrationen, unbekannte Datenflüsse, hoher Impact bei kleinen Änderungen.

5) Datenqualität, Datenhoheit und Datenflüsse

Für Portfolio-Entscheidungen ist entscheidend, ob Daten sauber geführt und zuverlässig nutzbar sind. Datenhoheit bedeutet: Es ist klar, wo die „Quelle der Wahrheit“ liegt, wie Stammdaten (z. B. Kunden, Artikel, Lieferanten) entstehen und wie Änderungen nachgelagert wirken. Datenflüsse umfassen auch Exporte, Schattenkopien und manuelle Korrekturen.

• 1: Klare Verantwortlichkeiten, nachvollziehbare Datenwege, definierte Schnittstellen, konsistente Schlüssel.
• 3: Mehrere Datenquellen oder regelmäßige Bereinigungen, aber transparent.
• 5: Unklare Wahrheit, häufige Korrekturen, Reporting nur mit Sonderlogik möglich.

6) Lifecycle-Risiko: Hersteller, Plattform, Skills

Technische Schulden entstehen auch durch Abkündigungen: Betriebssysteme, Datenbanken, Bibliotheken, Hersteller-Support oder Know-how-Verfügbarkeit. Diese Dimension betrachtet bewusst die organisatorische Seite: Gibt es genügend Personen, die Betrieb und Weiterentwicklung tragen? Gibt es einen belastbaren Upgrade-Pfad?

• 1: Aktive Support-Zyklen, Upgrade geplant, Skills breit verfügbar.
• 3: Upgrade steht an, Skill-Lage angespannt, Abhängigkeit von wenigen Schlüsselpersonen.
• 5: End-of-Life, keine Roadmap, Wissen konzentriert, Vendor-Risiko hoch.

7) Kosten- und Aufwandstreiber im laufenden Betrieb

Hier werden nicht nur Infrastrukturkosten bewertet, sondern vor allem variable Kosten: Supportaufwand, manuelle Tätigkeiten, Sonderprozesse, Lizenzwachstum, externe Dienstleisterbindung oder teure Wartungsfenster. Gerade bei Business-Software sind diese indirekten Kosten oft entscheidender als Serverpreise.

• 1: Stabiler Betrieb, wenig manuelle Tätigkeiten, Kosten planbar.
• 3: Erhöhter Betriebsaufwand oder steigende Lizenzkosten, aber steuerbar.
• 5: Betrieb „frisst“ Kapazität, viele manuelle Korrekturen, Kosten schwer prognostizierbar.

8) Business-Kritikalität und Prozessabhängigkeit

Technische Schulden sind für Portfolio-Entscheidungen erst dann relevant, wenn sie mit Prozessrisiko zusammenkommen. Diese Dimension bewertet, wie stark das System Kernprozesse trägt und wie hoch der Schaden bei Ausfall oder Fehlfunktion ist. Wichtig: Kritikalität ist kein Freifahrtschein für „niemals anfassen“, sondern ein Argument für saubere Stabilisierung und Modernisierung.

• 1: Unterstützender Prozess, Ausfall verkraftbar, Workaround vorhanden.
• 3: Wichtiger Prozess, Ausfälle erzeugen Kosten, aber begrenzbar.
• 5: Kernprozess, Ausfall stoppt Wertschöpfung oder führt zu Compliance-Risiken.

Wie aus Scores Portfolio-Entscheidungen werden (ohne Scheingenauigkeit)

Ein Score ist erst dann nützlich, wenn er eine Entscheidung vorbereitet. Dafür braucht es zwei Schritte: Gewichtung und Entscheidungskategorien.

Gewichtung: nicht jedes Kriterium zählt gleich

Viele Organisationen starten mit gleicher Gewichtung, um Diskussionen zu vermeiden. Später lohnt sich eine einfache Gewichtung nach Portfolio-Ziel, etwa:

• Security-first (z. B. nach Audit-Funden): Sicherheits- und Compliance-Risiko doppelt gewichten.
• Lieferfähigkeit erhöhen (z. B. bei hohem Change-Backlog): Änderbarkeit/Release-Fähigkeit stärker gewichten.
• Kosten stabilisieren (z. B. bei steigendem Support): Aufwandstreiber im Betrieb stärker gewichten.

Wichtig ist, die Gewichtung transparent zu dokumentieren und nur selten zu ändern. Sonst wirken Score-Änderungen wie „politisch“ statt wie eine echte Verbesserung.

Entscheidungskategorien: vier klare Handlungsoptionen

Aus den Dimensionen lassen sich vier pragmatische Kategorien ableiten, die sich im Portfolio-Board gut diskutieren lassen:

• Stabilisieren: Hohe Betriebs-/Security-Risiken, aber keine kurzfristige Ablösung möglich. Fokus auf Runbooks, Monitoring, Patchpfade, technische Hygiene.
• Modernisieren: Hohe Änderungs- oder Lifecycle-Risiken bei gleichzeitig hoher Kritikalität. Fokus auf modulare Erneuerung, Schnittstellen entkoppeln, Datenmodelle konsolidieren.
• Konsolidieren/Ersetzen: Doppelte Funktionen, hoher Aufwand, geringe Differenzierung. Fokus auf Abschaltung, Datenmigration, Prozessvereinheitlichung.
• Bewusst akzeptieren: Niedrige Kritikalität oder absehbare Restlaufzeit. Fokus auf Risikokontrollen, minimale Wartung, klare Exit-Option.

Damit das nicht theoretisch bleibt, sollte jede Anwendung zusätzlich einen nächsten sinnvollen Schritt bekommen – maximal 1–2 konkrete Maßnahmen, die in 4–12 Wochen realistisch sind. So wird aus Portfolio-Management ein laufender Verbesserungsprozess statt ein jährlicher Workshop.

Datengrundlage pragmatisch aufbauen: Welche Quellen reichen meist aus

Ein leichtgewichtiges Modell lebt davon, dass die Datenbeschaffung nicht teurer ist als die ersten Maßnahmen. Für viele Unternehmen reichen vier Datenquellen, um seriöse Scores zu vergeben:

• Ticket-/Incident-Daten: Häufigkeit, Wiederholungen, Bearbeitungszeiten, Eskalationen. Wenn es keine saubere Kategorisierung gibt, reicht am Anfang eine grobe Zuordnung (Störung, Anfrage, Change).
• Monitoring/Verfügbarkeit: Nicht nur „Uptime“, sondern auch Performance-Spitzen, Job-Laufzeiten, Fehlerraten, Speicher-/Plattenwachstum.
• Security- und Lifecycle-Infos: Patchstand, End-of-Life-Termine, Abhängigkeiten (z. B. Datenbankversion, Betriebssystem, Authentifizierung), bekannte Ausnahmen.
• Architektur-/Integrationsübersicht: Eine einfache Application-Map (Systemlandkarte) mit Datenflüssen und Schnittstellen. Vollständigkeit ist zweitrangig, Aktualität zählt.

Wenn Zahlen fehlen, sollte das im Score sichtbar sein: „Bewertung 4 aufgrund fehlender Nachweise“ ist ehrlicher als ein zufälliger Mittelwert. Unbekanntes ist im Betrieb häufig riskanter als Schlechtes, das man wenigstens kennt.

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

Ein häufiger Fehler ist, Scoring als Einzelarbeit zu betreiben. Dann wird es entweder zu technisch oder zu politisch. Besser ist ein kurzer Workshop pro System, moderiert und mit klaren Rollen. 90 Minuten reichen für eine erste belastbare Bewertung, wenn die Basisdaten vorliegen.

Teilnehmende (klein, aber vollständig)

• Systemverantwortliche IT: kennt Roadmap, Änderungen, technische Engpässe.
• Betrieb/Administration: kennt Störungen, Wartungsfenster, Monitoring, Backup/Restore.
• Fachlicher Owner oder Key User: kennt Prozesskritikalität, Workarounds, Akzeptanz, Peak-Zeiten.
• Moderation: sorgt für Definitionstreue und dokumentiert Annahmen.

Ablauf (kompakt, wiederholbar)

1. Kontext (10 Min.): Zweck des Systems, Nutzergruppen, Hauptschnittstellen, Betriebsmodell (On-Prem/Cloud/Hybrid).
2. Score je Dimension (45 Min.): Pro Kriterium 3–5 Minuten, mit kurzen Belegen (Ticketzahlen, Patchstand, bekannte Abhängigkeiten).
3. Hotspots identifizieren (15 Min.): Welche 2 Dimensionen treiben Risiko/Kosten am stärksten?
4. Maßnahmen festlegen (15 Min.): 1–2 konkrete nächste Schritte, plus Owner und Zieltermin.
5. Portfolio-Label (5 Min.): Stabilisieren / Modernisieren / Konsolidieren / Akzeptieren.

Als Ergebnis genügen drei Artefakte: Score-Tabelle, kurze Begründung pro Dimension und ein Maßnahmen-Schnipsel. Alles andere ist optional.

Typische Fallstricke – und wie man sie im Modell abfängt

Ein Scoring-Modell kann falsche Anreize setzen, wenn es nicht sauber gerahmt ist. Aus Projekterfahrung sind das die häufigsten Stolpersteine:

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

Wenn Teams mit guter Dokumentation schlechtere Scores bekommen, weil sie Probleme sichtbar machen, ist das Modell kaputt. Gegenmittel: Unbekanntes (fehlende Daten) als eigenes Risiko behandeln und Transparenz ausdrücklich als Pluspunkt anerkennen, z. B. im Kriterium Änderbarkeit (Rollbacks, Runbooks, Monitoring).

Fallstrick 2: Score wird zum Budget-Kürzungsinstrument

Wenn hohe Scores automatisch zu „Projektstopp“ führen, wird das Modell politisch. Besser: Hohe Scores führen zu einer Entscheidungsvorlage mit Optionen (z. B. Stabilisierung vs. Modernisierung) und klaren Konsequenzen. Das Budget folgt der Entscheidung – nicht dem Score allein.

Fallstrick 3: Vermischung von Nutzen und Risiko

Fachlicher Nutzen (z. B. Umsatzpotenzial) ist wichtig, aber eine andere Achse. Ein bewährtes Vorgehen: Nutzen in einem separaten Raster bewerten und dann in einer Portfolio-Matrix zusammenführen (Nutzen hoch/niedrig vs. Risiko/Schulden hoch/niedrig). So wird nicht diskutiert, ob ein Sicherheitsrisiko „durch Umsatz“ kompensiert wird.

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

Portfolio-Entscheidungen scheitern oft an der impliziten Annahme, dass Modernisierung nur als Big Bang geht. In der Realität ist häufig eine modulare Modernisierung sinnvoll: Schnittstellen stabilisieren, Datenzugriffe standardisieren, einzelne Teilprozesse auskoppeln, Parallelbetrieb sauber steuern. Ein Score hilft, die Reihenfolge zu finden, nicht den Endzustand zu erzwingen.

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

Wenn das Modell steht, kommt die eigentliche Arbeit: Maßnahmen so schneiden, dass sie im Alltag neben Projektgeschäft funktionieren. Drei Regeln helfen dabei, aus „wir müssten mal“ konkrete Roadmap-Elemente zu machen:

1) Erst die teuersten Risiken „entschärfen“

In vielen Portfolios sind Sicherheits- und Betriebsrisiken die größten Hebel, weil sie externe Fristen (Audit, End-of-Life) und hohe Folgekosten haben. Typische Entschärfungen sind: Updatepfad herstellen, Logging/Audit-Trail ergänzen, Backup/Restore testen, Single-Point-of-Failure reduzieren, Berechtigungen plausibilisieren.

2) Integrationsknoten vor Funktionsausbau stabilisieren

Systeme mit vielen Schnittstellen sind Multiplikatoren für Change-Kosten. Hier lohnt sich oft zuerst: Schnittstellenverträge definieren (Versionierung, Datenformate, Fehlerbehandlung), Monitoring für Datenflüsse ergänzen, Job-Ketten entkoppeln, Retry-Strategien (Wiederholversuche bei Fehlern) einführen. Das ist selten „sichtbar“ für den Fachbereich, aber es reduziert Ausfallzeiten und Release-Stress messbar.

3) Maßnahmen als „Betriebsverbesserung“ planbar machen

Viele technische Schulden lassen sich als betriebliche Verbesserungen in kleinen Paketen umsetzen: Runbooks, Alarmregeln, Kapazitätsplanung, Standardisierung von Umgebungen, regelmäßige Patchfenster. Das sind keine glamourösen Projekte, aber sie erhöhen Verlässlichkeit – und schaffen Zeitfenster für größere Modernisierungsschritte.

So wird das Scoring dauerhaft: Governance ohne Bürokratie

Ein Modell ist nur dann wertvoll, wenn es nicht nach zwei Quartalen einschläft. Dafür braucht es einen einfachen Prozess, der zum Betriebs- und Projektalltag passt:

• Owner pro Anwendung: Eine benannte Person, die Score und Maßnahmenstatus pflegt (nicht alleine umsetzt).
• Trigger statt Kalenderpflicht: Score-Review nach Incident-Cluster, Major-Release, Audit-Fund oder Plattform-Upgrade.
• Portfolio-Rhythmus: Monatlich/zweimonatlich 60 Minuten für die Top-Risiken, nicht für alle Systeme.
• Entscheidungslog: Kurze Dokumentation, warum ein Risiko akzeptiert oder verschoben wurde. Das verhindert spätere Schuldzuweisungen und macht Annahmen sichtbar.

Wichtig ist die Kopplung an echte Steuerung: Mindestens ein Teil der Kapazität (Budget oder Team-Zeit) sollte explizit für Stabilisierung/Modernisierung reserviert sein. Sonst produziert das Modell nur Erkenntnisse ohne Wirkung.

Fazit: Technische Schulden sichtbar machen, ohne die Organisation zu überfordern

Ein leichtgewichtiges technische Schulden Scoring-Modell ersetzt keine detaillierte Architekturarbeit – aber es schafft etwas, das in Portfolios oft fehlt: Vergleichbarkeit. Mit acht klaren Dimensionen, nachvollziehbaren Bewertungsankern und einem kurzen Workshop-Format lassen sich Risiken, Betriebsaufwand und Modernisierungsdruck so darstellen, dass IT, Fachbereich und Management dieselbe Diskussion führen.

Der wichtigste Effekt ist dabei selten der exakte Zahlenwert. Es ist die Transparenz darüber, wo technische Schulden entstehen, wie sie den Betrieb belasten und welche nächsten Schritte realistisch sind. Wenn Scores regelmäßig überprüft und mit kleinen, konkreten Maßnahmen verknüpft werden, entsteht eine Modernisierungs-Roadmap, die nicht auf dem Reißbrett lebt, sondern im Tagesgeschäft trägt.

Wenn Sie das Scoring-Modell für Ihr Anwendungsportfolio aufsetzen oder die ersten Bewertungen in einem moderierten Format durchführen möchten, finden Sie hier den passenden Einstieg: Kontakt aufnehmen.

Für dieses Thema sind auch Technische Schulden Bewerten und Portfolio-Entscheidungen It wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.

Projekt oder Modernisierungsvorhaben mit Net-Base besprechen.