Technical Debt

Was bedeutet Technical Debt?

Technical Debt (technische Schulden) bezeichnet den zusätzlichen Aufwand, der bei Weiterentwicklung und Betrieb einer Software künftig entsteht, weil bei ihrer Entwicklung schnellere oder einfachere statt tragfähiger Lösungen gewählt wurden. Wie bei einem Kredit wird heute Tempo gewonnen und später mit Zinsen bezahlt: Jede weitere Änderung dauert länger, bis die Schuld durch Überarbeitung getilgt ist.

Der Begriff beschreibt einen wirtschaftlichen Sachverhalt, keinen Bilanzposten. Technische Schulden erscheinen weder als Verbindlichkeit noch als Rückstellung, sondern zeigen sich in höheren Personalkosten, langsamerer Produktentwicklung und höheren Betriebsrisiken. In Finanzierungsrunden und Unternehmensverkäufen werden sie in der technischen Due Diligence erhoben, also bei der Prüfung von Programmcode, Architektur und Betrieb durch Investoren oder Käufer. Die Ergebnisse fließen in Bewertung, Kaufvertrag und Integrationsplanung ein.

Ursachen

• Bewusste Abkürzungen: Ein Team setzt eine Funktion vereinfacht um, um einen Markttermin zu halten. Das ist legitim, wenn die Entscheidung dokumentiert und die Überarbeitung eingeplant wird, etwa nach einem Minimum Viable Product (MVP), der ersten, bewusst einfach gehaltenen Produktfassung.
• Unbewusste Mängel: fehlendes Wissen, Zeitdruck ohne ausdrückliche Entscheidung oder Personalwechsel. Diese Schulden sind riskanter, weil niemand sie erfasst hat.
• Alterung: Programmbibliotheken und Betriebssysteme veralten, auch wenn am eigenen Code nichts geändert wird. Komponenten ohne Herstellerunterstützung erhalten keine Sicherheitsaktualisierungen mehr.
• Wachstum: Eine Architektur, die für hundert Kunden angemessen war, trägt bei zehntausend nicht mehr. Die Schulden entstehen hier durch veränderte Anforderungen, nicht durch Fehler.

Hinzu kommen fehlende automatisierte Tests und lückenhafte Dokumentation. Beides verteuert jede Änderung, weil Entwickler deren Folgen nicht verlässlich abschätzen können.

Messbarkeit

Technische Schulden lassen sich nicht in einer einzigen Zahl ausdrücken. Aussagekräftig sind ihre Wirkungen, gemessen über die Zeit:

• Auslieferungsfrequenz und Durchlaufzeit, also wie oft und wie schnell fertige Änderungen in den Betrieb gehen,
• Fehlerquote nach Änderungen und Dauer der Wiederherstellung nach Störungen,
• Anteil der Entwicklungskapazität für Fehlerbehebung und Umgehungslösungen,
• Einarbeitungsdauer neuer Entwickler,
• Alter der eingesetzten Komponenten und Zahl bekannter Sicherheitslücken.

Werkzeuge zur automatischen Codeanalyse liefern ergänzende Hinweise, etwa zur Testabdeckung (dem Anteil des Codes, den automatische Tests prüfen) und zur Komplexität. Ohne Zusammenhang sind sie aber wenig aussagekräftig. Sinkt die Auslieferungsfrequenz über Monate, ohne dass das Team kleiner geworden ist, ist das ein deutlicheres Warnsignal als jeder Analysebericht.

Bewertung in der technischen Due Diligence

Käufer und Investoren setzen für die technische Prüfung häufig spezialisierte Berater ein. Diese prüfen den Programmcode und seine Änderungshistorie, sprechen mit den verantwortlichen Entwicklern, prüfen Architektur und Sicherheit und analysieren die eingesetzten Komponenten auf Aktualität und Lizenzen (Open Source). Die Befunde werden nach Schwere eingestuft und, soweit möglich, in Personenmonaten (Arbeitsmonaten einer Vollzeitkraft) und Euro beziffert.

Entscheidend ist die Einordnung. Schulden in Bereichen, die sich kaum ändern, kosten wenig. Schulden in Kernbereichen, die der Käufer ausbauen will, oder in sicherheitsrelevanten Teilen wiegen schwer. Verkäufer können einen Teil der Prüfung vorwegnehmen, indem sie vor dem Verkaufsprozess selbst eine technische Prüfung beauftragen (Vendor Due Diligence).

Investoren einer Finanzierungsrunde fragen weniger nach dem Kaufpreis als nach der Verwendung des neuen Kapitals. Fließt ein großer Teil der Entwicklungskapazität in Reparaturen, wächst das Produkt mit dem eingeworbenen Geld langsamer als geplant. Sie prüfen deshalb, ob die bekannten Schulden im Finanzmodell als Aufwand eingeplant sind und ob Sicherheitsrisiken oder die Abhängigkeit von einzelnen Entwicklern das Wachstum gefährden.

Wirkung auf Kaufpreis und Integrationsplanung

Bezifferte Sanierungskosten mindern den Unternehmenswert, weil sie künftige Zahlungsströme belasten. In der DCF-Bewertung (Discounted Cash Flow), die den Wert aus abgezinsten künftigen Zahlungsüberschüssen ableitet, erscheinen sie als zusätzliche Investitionen oder Personalkosten. Bei Bewertungen über Multiplikatoren, bei denen der Wert aus einem Vielfachen einer Ergebnisgröße abgeleitet wird, erscheinen sie als Abschlag. Käufer versuchen teilweise, aufgeschobene Investitionen als schuldenähnliche Posten in der Überleitung vom Unternehmenswert zum Kaufpreis der Anteile (Equity Bridge) abzuziehen. Kritische Befunde wie offene Sicherheitslücken werden häufig vor dem Vollzug behoben oder, weil sie dem Käufer bekannt sind, über eine gesonderte Freistellung abgesichert.

In der Integrationsplanung entscheidet der Käufer, ob das Produkt weiterentwickelt, auf seine Plattform überführt oder abgelöst wird. Soll es abgelöst werden, verlieren viele Schulden an Bedeutung. Soll es wachsen, gehören Sanierung und zusätzliche Kapazität in das Budget der ersten Jahre.

Rechenbeispiel

Ein Softwareunternehmen beschäftigt 12 Entwickler mit Personalkosten von durchschnittlich 110.000 Euro je Person und Jahr. Die technische Due Diligence ergibt, dass 35 % der Entwicklungskapazität in Fehlerbehebung und Umgehungslösungen fließen. Der Käufer hält 15 % für angemessen.

• Überhöhter Anteil: 35 % minus 15 % = 20 Prozentpunkte
• Gebundene Kapazität: 12 × 20 % = 2,4 Vollzeitstellen
• Laufende Mehrkosten, gewissermaßen die Zinsen der technischen Schulden: 2,4 × 110.000 Euro = 264.000 Euro im Jahr
• Sanierung, also die Tilgung, nach Schätzung der Prüfer: 3 Entwickler über 18 Monate, also 3 × 1,5 × 110.000 Euro = 495.000 Euro
• Amortisation: Sinkt der Anteil danach auf 15 %, spart das Unternehmen 264.000 Euro im Jahr. Die Sanierung ist nach 495.000 geteilt durch 264.000 = rund 1,9 Jahren wieder eingespielt, gerechnet ab ihrem Abschluss, also rund 3,4 Jahre nach ihrem Beginn

Der Käufer kann die 495.000 Euro als Abschlag verlangen oder in sein Integrationsbudget aufnehmen. Welche Lösung gewählt wird, ist Verhandlungssache. Ein Verkäufer, der die Zahlen selbst kennt und einen Sanierungsplan vorlegt, verhandelt aus der stärkeren Position. In einer Finanzierungsrunde zeigt dieselbe Rechnung, dass rund eine halbe Million Euro des neuen Kapitals in die Sanierung statt in neue Funktionen fließt.

Abgrenzung zu verwandten Begriffen

• Tech Stack: die eingesetzten Technologien. Technische Schulden beschreiben nicht deren Wahl, sondern den Zustand ihrer Umsetzung.
• Softwarefehler: ein konkretes Fehlverhalten des Programms. Technische Schulden verursachen häufig Fehler, bestehen aber auch in fehlerfrei laufendem Code.
• Aufgeschobene Investitionen: der kaufmännische Oberbegriff für notwendige, aber verschobene Ausgaben. Technische Schulden sind eine Form davon in der Softwareentwicklung.

Typische Fehler

• Alles neu schreiben wollen. Eine vollständige Neuentwicklung dauert häufig deutlich länger als geplant und liefert Kunden in der Zwischenzeit keinen zusätzlichen Nutzen.
• Schulden nicht erfassen. Was nicht dokumentiert ist, wird weder eingeplant noch in der Due Diligence glaubwürdig erklärt.
• Als reines Technikthema behandeln. Die Abwägung zwischen Tempo heute und Tempo morgen ist eine unternehmerische Entscheidung der Geschäftsführung.
• Kosmetik kurz vor der Transaktion. Prüfer betrachten Verläufe über zwölf Monate und mehr; eine kurzfristige Aufräumaktion verändert diese Reihen kaum.
• Keine feste Kapazität für die Tilgung. Ohne regelmäßigen Anteil der Entwicklungszeit für Überarbeitungen wachsen die Schulden mit jeder neuen Funktion.

Häufige Fragen

Hat jedes Softwareunternehmen technische Schulden?

Ja. Jedes gewachsene Produkt enthält Stellen, die mit heutigem Wissen anders gebaut würden. Entscheidend ist, ob die Schulden bekannt, bewertet und in der Planung berücksichtigt sind.

Wie viel Kapazität sollte für den Abbau eingeplant werden?

Verbreitet ist ein fester Anteil der Entwicklungskapazität, in der Praxis häufig zwischen 10 und 20 %. Wichtiger als die genaue Quote ist, dass der Anteil regelmäßig eingeplant und nicht bei jedem Termindruck gestrichen wird.

Wie werden technische Schulden gegenüber Investoren dargestellt?

Offen und mit Plan. Überzeugend ist eine Übersicht der bekannten Schulden mit ihrer Wirkung auf das Geschäft, der eingeplanten Kapazität und den Kennzahlen, an denen sich der Fortschritt ablesen lässt.

Mindern technische Schulden immer den Kaufpreis?

Nein. Liegen sie in Bereichen, die der Käufer ohnehin ablöst, spielen sie kaum eine Rolle. Kaufpreiswirksam werden sie, wenn sie Kernfunktionen, Sicherheit oder die geplante Skalierung betreffen.

Roemer Capital Perspektive

Mandanten, die einen Verkauf in den kommenden Jahren erwägen, empfehlen wir, Auslieferungsfrequenz, Fehlerquote und den Anteil der Kapazität für Fehlerbehebung laufend zu erfassen. Diese Reihen lassen sich kurz vor einer Transaktion nicht mehr verbessern, und Käufer lesen an ihnen den Zustand des Produkts ab.

In der Vorbereitung des Verkaufs übersetzen wir die bekannten technischen Schulden gemeinsam mit dem Entwicklungsteam in Personenmonate und Euro. So kommt die Zahl vom Verkäufer und nicht erst aus dem Prüfbericht des Käufers, und sie lässt sich als Investitionsplan in das Finanzmodell einbauen.