Technische Schulden quantifizieren: Wie man den Rückstand in Euro berechnet
Wie hoch sind die technischen Schulden in Ihrer Software? Wenn Sie darauf keine Zahl nennen können, sind Sie in guter Gesellschaft. Die meisten Unternehmen kennen ihren technischen Rückstand nur als Gefühl. Der Entwickler seufzt bei jeder Änderung. Kleine Anpassungen dauern Wochen. Aber im Budget taucht davon nichts auf.
Dabei lassen sich technische Schulden messen. Nicht auf den Cent genau, aber genau genug für Entscheidungen. Dieser Artikel zeigt drei Wege zu einer belastbaren Zahl. Und eine einfache Formel, mit der Sie noch heute anfangen können.
Warum eine Zahl in Euro so viel verändert
Was technische Schulden sind, haben wir in unserem Grundlagenartikel über technische Schulden erklärt: der Preis für die schnellen Lösungen von gestern. Das Konzept leuchtet den meisten Entscheidern sofort ein. Trotzdem passiert danach oft: nichts.
Der Grund ist einfach. Ein Gefühl bekommt kein Budget. Eine Zahl schon. Solange der Rückstand nur als Klage aus der IT existiert, verliert er gegen jedes andere Projekt. Steht er als Betrag im Raum, ändert sich das Gespräch. Aus "der Code ist alt" wird: "Wir zahlen jedes Jahr 40.000 Euro Zinsen auf ein Darlehen, das wir nie aufgenommen haben."
Wer technische Schulden messen will, braucht dafür keine Doktorarbeit. Drei Ansätze führen zu dieser Zahl. Sie ergänzen sich und lassen sich einzeln oder zusammen nutzen.
Ansatz 1: Code-Metriken als Ausgangspunkt
Werkzeuge für statische Code-Analyse untersuchen den Quellcode automatisch. Statische Analyse bedeutet: Das Werkzeug liest den Code, ohne ihn auszuführen. Bekannte Vertreter sind SonarQube oder PHPStan.
Diese Werkzeuge zählen, was im Code auffällt. Dazu gehören doppelter Code, zu komplexe Funktionen, veraltete Abhängigkeiten und bekannte Sicherheitsprobleme. Für jeden Fund schätzt das Werkzeug einen Aufwand für die Behebung.
Das Ergebnis ist eine Liste mit Stunden. Zwanzig Minuten für diese Stelle, drei Stunden für jene. Summiert ergibt das eine erste Größenordnung des Rückstands.
Wichtig für die Einordnung: Diese Zahl ist ein Startpunkt, kein Urteil. Nicht jeder Fund muss behoben werden. Ein Modul, das seit Jahren stabil läuft und nie angefasst wird, darf Schulden tragen. Teuer sind die Stellen, an denen Ihr Team regelmäßig arbeitet. Dort zahlen Sie bei jeder Änderung drauf.
Ansatz 2: Wartungsaufwand erfassen
Der zweite Ansatz schaut nicht in den Code, sondern auf die Arbeitszeit. Er beantwortet die Frage: Wie viel Zeit kostet uns der Rückstand jeden Monat?
Dafür teilen Sie die Entwicklerzeit in zwei Töpfe. In den ersten Topf fallen neue Funktionen und geplante Verbesserungen. In den zweiten fällt alles andere: Fehler beheben, Altlasten umschiffen, das System am Laufen halten.
Gesunde Systeme brauchen für den zweiten Topf grob 10 bis 20 Prozent der Zeit. Liegt Ihr Wert bei 40 oder 50 Prozent, arbeitet Ihr Team zur Hälfte für die Vergangenheit.
Diese Differenz können Sie direkt in Geld übersetzen. Ein Beispiel: Ihre Entwicklung kostet 200.000 Euro im Jahr. Statt 15 Prozent fließen 35 Prozent der Zeit in Fehler und Umwege. Die 20 Prozentpunkte Differenz kosten Sie 40.000 Euro im Jahr. Das ist der Zins auf Ihren technischen Rückstand.
Für diese Erfassung brauchen Sie keine neue Software. Ein wöchentlicher Blick in das Ticketsystem reicht für den Anfang. Zählen Sie, wie viele erledigte Aufgaben Fehlerbehebungen waren. Nach vier bis sechs Wochen haben Sie eine brauchbare Quote. Wichtig ist nur, dass Sie ehrlich zählen. Auch der Nachmittag, an dem der Entwickler eine unverständliche Funktion entziffert hat, gehört in den zweiten Topf.
Falls Sie unsicher sind, ob Ihr System betroffen ist: Die typischen Warnsignale technischer Schulden haben wir in einem eigenen Artikel gesammelt.
Ansatz 3: Schätzmodelle wie SQALE
Für größere Systeme gibt es formalisierte Modelle. Das bekannteste heißt SQALE, kurz für Software Quality Assessment based on Lifecycle Expectations.
Die Idee dahinter ist gut nachvollziehbar. Jede Abweichung von definierten Qualitätsregeln bekommt eine geschätzte Behebungszeit. Alle Zeiten zusammen ergeben die sogenannte Remediation Cost, also die Gesamtkosten der Aufräumarbeit.
SQALE setzt diese Summe zusätzlich ins Verhältnis zur Größe des Systems. Daraus entsteht eine Note von A bis E, ähnlich einem Schulzeugnis. Ein System mit Note A hat wenig Rückstand. Bei Note D oder E kostet die Aufräumarbeit einen erheblichen Teil dessen, was eine Neuentwicklung kosten würde.
Der Vorteil dieses Modells liegt in der Vergleichbarkeit. Sie können die Bewertung jedes Quartal neu erheben und sehen, ob der Trend stimmt. Werkzeuge wie SonarQube haben SQALE bereits eingebaut. Der Einstieg kostet also wenig.
Die einfache Formel für den Einstieg
Sie brauchen kein zertifiziertes Modell, um anzufangen. Zwei Zahlen reichen für ein erstes, ehrliches Bild.
Die erste Zahl ist die Ablösesumme. Lassen Sie den Behebungsaufwand schätzen, per Analyse-Werkzeug oder durch einen erfahrenen Entwickler. Multiplizieren Sie die Stunden mit Ihrem Stundensatz. 400 Stunden mal 100 Euro ergeben 40.000 Euro. So viel würde es kosten, den Rückstand abzutragen.
Beim Stundensatz zählt der volle Satz, nicht nur das Gehalt. Für interne Entwickler rechnen Sie mit Lohnnebenkosten und Arbeitsplatzkosten. Für externe Dienstleister nehmen Sie den vereinbarten Tagessatz. Sonst rechnen Sie sich die Sanierung schöner, als sie ist.
Die zweite Zahl ist der jährliche Zins. Nehmen Sie dafür den überhöhten Wartungsanteil aus Ansatz 2. Im Beispiel oben waren das ebenfalls 40.000 Euro pro Jahr.
Jetzt wird die Entscheidung greifbar. Kostet die Sanierung 40.000 Euro und spart danach 40.000 Euro jährlich, rechnet sie sich im ersten Jahr. In der Praxis sind die Verhältnisse selten so glatt. Aber selbst bei halber Ersparnis hätte sich die Investition nach zwei Jahren bezahlt gemacht.
Mit diesen Zahlen können Sie auch Ihr Wartungsbudget realistisch planen, statt es jedes Jahr neu zu verhandeln. Ein begründeter Posten übersteht Budgetrunden deutlich besser als ein pauschaler.
Was die Zahlen nicht zeigen
Eine ehrliche Einschränkung gehört dazu. Messwerkzeuge sehen nur, was im Code steht. Manche der teuersten Schulden stehen dort nicht.
Fehlende Dokumentation zum Beispiel. Oder Wissen, das nur in einem einzigen Kopf existiert. Kündigt dieser Kollege, wird aus einem unsichtbaren Risiko ein sehr sichtbarer Notfall. Solche Posten bewerten Sie besser über eine andere Frage: Was würde der Ausfall dieser Person das Unternehmen kosten?
Auch die Schätzungen selbst haben Spielraum. Zwei Werkzeuge liefern zwei verschiedene Zahlen. Das ist kein Grund, die Messung bleiben zu lassen. Ein Schätzwert mit 30 Prozent Unsicherheit schlägt ein Bauchgefühl mit 100 Prozent Unsicherheit immer noch deutlich.
Fazit: Erst messen, dann abbauen
Technische Schulden messen heißt: aus einem diffusen Problem eine Managementaufgabe machen. Code-Metriken liefern den Startpunkt. Die Aufwandserfassung zeigt die laufenden Kosten. Modelle wie SQALE machen den Fortschritt über die Zeit vergleichbar.
Liegt die Zahl auf dem Tisch, folgt der nächste Schritt: priorisieren und abtragen. Wie das ohne Stillstand im Tagesgeschäft funktioniert, zeigt unser Leitfaden zum Abbau technischer Schulden.
Oder Sie lassen sich die Zahl liefern. Wir analysieren Ihr System und rechnen Ihnen vor, wo Sie stehen und was zuerst dran ist. Sprechen Sie uns an. Das Erstgespräch ist kostenlos.
