Technische Schulden sind ein Begriff, der in vielen IT-Organisationen ständig verwendet wird und trotzdem selten sauber geklärt ist. Mal geht es um alte Systeme, mal um schlechten Code, mal um gewachsene Sonderlösungen.
Das eigentliche Missverständnis liegt tiefer. Die wenigsten technischen Schulden entstehen, weil jemand schlechte Technik wollte. Meist entstehen sie durch Entscheidungen. Durch verschobene Modernisierung, kurzfristige Prioritäten, Budgetdruck oder den Wunsch, schnell lieferfähig zu bleiben.
Damit sind technische Schulden in vielen Fällen kein reines IT-Problem. Sie sind eine Führungsfrage.
Technische Schulden entstehen nicht über Nacht
Wenn Unternehmen über technische Schulden reden, meinen sie meist die Symptome. Veraltete Systeme, Legacy-Anwendungen, komplizierte Architekturen. Die Ursache liegt woanders. Sie liegt in einer langen Reihe von Entscheidungen, die jede für sich plausibel war.
Ein Upgrade wird verschoben. Ein Sicherheits-Patch wartet auf das nächste Wartungsfenster. Eine Schnittstelle wird schnell gebaut statt sauber. Eine Individualentwicklung ersetzt den Standard, weil sie näher am Wunsch des Fachbereichs liegt. Eine Migration wird vertagt, weil ein Kundenprojekt wichtiger ist.
Keine dieser Entscheidungen ist für sich genommen dramatisch. Das Problem entsteht über Jahre. Deshalb fällt es lange nicht auf. Bis jede weitere Veränderung spürbar schwerer wird.
Die meisten Schulden entstehen aus guten Gründen
Technische Schulden entstehen selten aus Nachlässigkeit. Häufig entstehen sie aus wirtschaftlich nachvollziehbaren Prioritäten. Ein Projekt bringt Umsatz und bekommt deshalb Vorrang. Eine neue Funktion zählt mehr als die Bereinigung einer Altlast. Eine Modernisierung wird bewusst verschoben, weil das Geld an anderer Stelle dringender gebraucht wird.
Das ist legitim. Unternehmen müssen priorisieren. Nicht jede Modernisierung ist automatisch wichtiger als Umsatz, Lieferfähigkeit oder ein kritisches Kundenprojekt. Schwierig wird es erst, wenn niemand ausspricht, was diese Entscheidung später kostet. Technische Schulden funktionieren wie ein Kredit. Man darf ihn aufnehmen. Man sollte nur wissen, zu welchem Zins.
Dieser Teil wird gern weggelassen. Das passiert nicht aus Unfähigkeit. Solche Gespräche sind schlicht unbequem.
Technische Schulden kosten selten sofort Geld
Ein ausgelassenes Upgrade schreibt keine Rechnung. Eine verschobene Modernisierung taucht in keinem Budget auf. Eine weitere Sonderlösung sieht im Moment sogar günstiger aus als eine saubere Bereinigung. Es fühlt sich an, als hätte man gespart.
Bezahlt wird trotzdem. Nur später. Durch mehr Betriebsaufwand, mehr Abhängigkeiten, höhere Risiken und langsamere Veränderungen. Diese Rechnung steht in keiner Quartalsauswertung. Sie kommt verspätet, und sie kommt höher.
Die teuersten Schulden stehen in keinem Register
Unternehmen führen Risikoregister, Asset-Listen, Projektpläne, Vertragsdatenbanken. Technische Schulden stehen dort selten vollständig drin, oft gar nicht. Das Teuerste an ihnen lässt sich nämlich gar nicht auflisten. Es ist die Komplexität, die zwischen den Systemen gewachsen ist.
Ein Muster, das ich in verschiedenen Unternehmen ähnlich gesehen habe: Ein ERP-System wird über Jahre an jede neue Anforderung angepasst. Erst ein kleines Feld, dann eine Sonderlogik, später eine Schnittstelle, irgendwann ein eigener Prozess neben dem Standard. Jede Anpassung war begründet. In Summe entsteht eine Landschaft, die niemand mehr so bauen würde.
So etwas steht in keinem Register. Sichtbar wird es erst, wenn jemand etwas verändern will.
Der Preis zeigt sich erst bei Veränderung
Im Tagesgeschäft fallen technische Schulden oft kaum auf. Die Systeme laufen, die Prozesse funktionieren, die Anwender kommen klar.
Spürbar werden sie in dem Moment, in dem sich etwas ändern soll. Eine Cloud-Migration, ein Security-Projekt, eine Akquisition oder eine ERP-Transformation. Auf einmal wird klar, wie viele Abhängigkeiten gewachsen sind und wie viele Ausnahmen niemand mehr vollständig überblickt. Der wahre Preis technischer Schulden entsteht nicht im laufenden Betrieb. Er entsteht bei jeder Veränderung.
McKinsey beschreibt diesen Effekt in seiner Analyse zur Modernisierung. Technische Schulden lassen Systeme selten von heute auf morgen ausfallen. Sie machen jede Veränderung langsamer und teurer, und darin liegt ihr eigentlicher Schaden.
Eine Frage von Steuerung, nicht von Technik
Wer lange genug in IT-Verantwortung steht, landet bei diesen Schulden fast immer am selben Punkt. Das Problem ist nicht allein die Schuld. Das Problem ist, dass kaum jemand sie sauber bewertet. Oft ist nicht klar, welche Schulden wirklich kritisch sind und welche einfach nur unschön wirken.
Gartner ordnet technische Schulden ebenfalls als strukturelle Frage ein. Entscheidend sind Steuerung, Priorisierung und Lebenszyklus, nicht nur Technologie. Das deckt sich mit meiner Erfahrung. Solange niemand die Folgen bewertet und Modernisierung immer weiter nach hinten rutscht, funktioniert die Organisation zwar weiter, wird aber Schritt für Schritt schwerer zu verändern. Das ist die teuerste Form technischer Schulden. Sie kommt schleichend, als langsame Erosion der Handlungsfähigkeit.
Die Frage ist deshalb nicht, ob ein Unternehmen technische Schulden hat. Das hat fast jedes. Die Frage ist, welche es bewusst trägt und welche nicht.
Nicht jede Schuld muss sofort weg
Damit kein falscher Eindruck entsteht. Technische Schulden sind nicht grundsätzlich etwas, das man sofort beseitigen muss. Manche sind bewusst aufgenommen, manche bringen auf Zeit einen echten Vorteil, manche sind über Jahre völlig vertretbar. SAP nennt in seinem Leitfaden zu technischen Schulden den günstigen Fall. Bewusst eingegangene Schulden sind kein Problem, solange sie gesteuert und nicht vergessen werden.
Gefährlich wird die andere Sorte. Die Schulden, die niemand bewusst eingegangen ist und an die sich später keiner erinnert. Sie tauchen genau dann wieder auf, wenn man sie am wenigsten gebrauchen kann.
Worauf es hinausläuft
Technische Schulden entstehen selten, weil jemand schlechte Technik wollte. Sie entstehen, weil Unternehmen immer wieder nachvollziehbare Entscheidungen treffen, ohne die Folgekosten sichtbar zu machen. Deshalb lassen sie sich auch nicht im Rechenzentrum lösen.
Sie müssen geführt werden. Mit Transparenz, mit Prioritäten und mit der Bereitschaft, unbequeme Altlasten auf die Management-Agenda zu setzen. Sonst läuft das System weiter, aber das Unternehmen wird langsamer.
Quellen
- Gartner: Reduce and Manage Technical Debt — gartner.com
- McKinsey & Company: Breaking Technical Debt's Vicious Cycle to Modernize Your Business — mckinsey.com
- SAP: What Is Technical Debt? — sap.com
