Technische Schulden beziffern: vier Kennzahlen, die eine Geschäftsführung akzeptiert
Technische Schulden sind der am schlechtesten kommunizierte Sachverhalt in der IT. Entwicklungsteams spüren sie täglich, die Geschäftsführung hört eine Metapher. Der Weg aus dieser Sackgasse führt nicht über bessere Erklärungen, sondern über Zahlen, die aus dem laufenden Betrieb stammen.
Technische Schulden lassen sich mit vier Kennzahlen aus vorhandenen Systemen belegen: Vorlaufzeit für eine kleine Änderung, Anteil der als „zu riskant" vertagten Anforderungen, Änderungsfehlerrate aus dem Ticketsystem und Bus-Faktor je Kernsystem inklusive Abgangsdatum. Aus den vier Zahlen wird eine Reihenfolge abgeleitet, kein Gesamtbetrag — ein Eurobetrag für technische Schulden ist immer angreifbar.
Kennzahl 1: Vorlaufzeit für eine kleine Änderung
Wie lange dauert es von der fachlichen Anforderung bis zur produktiven Auslieferung — bei einer Änderung, die alle Beteiligten als klein einschätzen? Diese Zahl misst nicht Fleiß, sondern Reibung. Sechs Monate für eine kleine Änderung sind kein Kapazitätsproblem, sondern ein Strukturproblem, und in dieser Form versteht es auch jemand ohne IT-Hintergrund.
Kennzahl 2: Anteil vertagter Anforderungen
Wie viele fachliche Anforderungen wurden in den letzten zwei Jahren abgelehnt oder verschoben, weil der Eingriff als zu riskant galt? Diese Liste existiert in jeder Organisation, meist verteilt über Protokolle und Postfächer. Zusammengetragen ist sie die direkteste Übersetzung technischer Schulden in entgangene Geschäftsmöglichkeiten.
Kennzahl 3: Änderungsfehlerrate
Welcher Anteil der Auslieferungen führt zu einem Zwischenfall, einem Hotfix oder einer Rücknahme? Diese Zahl steht in jedem Ticketsystem, sie muss nur ausgewertet werden. Sie ist besonders wirksam, weil sie sich gegen den häufigsten Einwand richtet: Wenn alles in Ordnung wäre, müsste dieser Wert niedrig sein.
Kennzahl 4: Bus-Faktor je Kernsystem
Wie viele Personen können erklären, was das System tut, und wie viele davon sind in drei Jahren noch da? Diese Zahl braucht keine Werkzeuge, nur Ehrlichkeit. Sie ist die einzige der vier, die ein Datum hat — und Zahlen mit Datum bewegen Budgets zuverlässiger als Zahlen ohne.
Was man mit den vier Zahlen macht
Man stellt sie nebeneinander und leitet daraus eine Reihenfolge ab, keine Gesamtsumme. Der Fehler bei technischen Schulden ist der Versuch, sie in einem Eurobetrag auszudrücken — das ist immer angreifbar. Vier belegte Zahlen mit einer daraus abgeleiteten Reihenfolge sind schwerer angreifbar und führen zu einer Entscheidung statt zu einer Diskussion.
Häufige Fragen
Warum keine Gesamtsumme in Euro?
Weil jede solche Zahl auf Annahmen beruht, die sich bestreiten lassen, und die Diskussion dann über die Annahmen läuft statt über die Entscheidung. Vier belegte Einzelkennzahlen führen schneller zu einer Reihenfolge, und eine Reihenfolge ist das, was ein Investitionsgremium tatsächlich braucht.
Woher kommt die Änderungsfehlerrate?
Aus dem Ticketsystem: Anteil der Auslieferungen, die innerhalb einer definierten Frist einen Hotfix, eine Rücknahme oder einen Störungseintrag nach sich ziehen. Die Definition muss vorher festgelegt und dann konstant gehalten werden — der Trend ist aussagekräftiger als der Absolutwert.
Ist der Bus-Faktor nicht zu subjektiv?
Er ist eine Einschätzung, aber eine überprüfbare: Man fragt für jede Kernkomponente, wer eine nicht triviale Änderung ohne fremde Hilfe verantworten könnte. Die Antworten decken sich in der Praxis erstaunlich gut, und die Fälle mit nur einer Nennung sind genau die, die zählen.
Wie oft sollte man diese Zahlen erheben?
Halbjährlich reicht. Wichtiger als die Frequenz ist, dass die Definition stabil bleibt und die Zahlen im selben Gremium landen wie andere Geschäftskennzahlen — technische Schulden werden dort entschieden, wo über Investitionen entschieden wird.
Rechnen Sie Ihre Review-Lücke aus.
Vierzehn Fragen, fünf Minuten. Ihre Zahlen, kein Login.
Engineering-Check starten →
