Technische Schulden im Mittelstand:
Warum Ihr IT-Fundament Ihre Digitalisierung ausbremst –
und was das wirklich kostet

In fast jedem Digital Assessment, das ich für mittelständische Unternehmen durchführe, stoße ich auf dasselbe Muster: Das Unternehmen möchte digitalisieren – eine neue Schnittstelle anbinden, ein CRM einführen, Prozesse automatisieren. Und dann stellt sich heraus, dass das bestehende ERP-System aus dem Jahr 2009 keine moderne API kennt. Dass die Kernanwendung auf einem Server läuft, den niemand anfassen will. Dass ein kritischer Geschäftsprozess in einem Excel-Makro steckt, das nur ein Mitarbeiter versteht.

Das sind technische Schulden – und sie entstehen nicht durch Fahrlässigkeit, sondern durch ganz normale unternehmerische Entscheidungen: Heute schnell liefern, später aufräumen. Das Problem: „Später" kommt oft erst dann, wenn das Fundament bereits unter der Last der Digitalisierungsanforderungen kracht.

McKinsey schätzt, dass technische Schulden in Unternehmens-IT-Landschaften 20 bis 40 Prozent des gesamten IT-Werts ausmachen – als unsichtbare Last, die jede neue Investition teurer macht.^[1] Für den deutschen Mittelstand, der gerade unter erheblichem Digitalisierungsdruck steht, ist das kein abstraktes Problem – es ist der häufigste Grund, warum Digitalisierungsprojekte teurer werden als geplant oder ganz scheitern.

Was sind technische Schulden – in Sprache, die das Business versteht?

Der Begriff stammt aus der Softwareentwicklung und wurde vom Entwickler Ward Cunningham geprägt: Wenn man heute eine schnelle, pragmatische Lösung wählt statt der saubereren, aufwendigeren, nimmt man einen Kredit auf – mit Zinsen. Je länger man den Kredit nicht zurückzahlt, desto teurer wird jede weitere Transaktion.

Für Nicht-Techniker lässt sich das direkt übersetzen: Stellen Sie sich vor, Ihr Gebäude wurde vor 20 Jahren ohne ausreichend dimensionierte Elektroinstallation gebaut. Damals war das kein Problem. Heute wollen Sie eine moderne Produktionsanlage einbauen – und stellen fest, dass zuerst die gesamte Elektrik erneuert werden muss. Die Investition, die Sie eigentlich für die Maschine geplant hatten, geht zur Hälfte ins Fundament. Das ist technische Verschuldung – nur im IT-System.

Im Mittelstand zeigt sie sich vor allem in vier Formen:

• Veraltete Kernsysteme ohne moderne Schnittstellen: ERP-, CRM- oder Warenwirtschaftssysteme, die keine standardisierten APIs bieten und jede Anbindung zur Individualentwicklung machen. Neue Software kann schlicht nicht angebunden werden – oder nur mit unverhältnismäßigem Aufwand.
• Excel als Systemer­satz: Wenn Geschäftsprozesse in Excel-Dateien, Makros oder Access-Datenbanken abgebildet sind, weil das eigentliche System die Anforderungen nicht erfüllt. Diese Lösungen funktionieren – solange niemand krank wird, der sie pflegt, und solange keine Integration gefragt ist.
• Fehlende oder veraltete Dokumentation: Software, die niemand mehr vollständig versteht. Systeme, bei denen Änderungen nur von einer Person durchgeführt werden können. Code ohne Tests, der jeden Eingriff riskant macht.
• Aufgeschobene Modernisierung: Sicherheitsupdates, die nicht eingespielt wurden. Betriebssysteme am Ende des Support-Lebenszyklus. Abhängigkeiten von Technologien, die keine aktive Community mehr haben.

Was sagen die Zahlen?

Technische Schulden sind kein deutsches Mittelstandsphänomen – sie sind universell. Die empirischen Daten zeigen allerdings, wie gravierend die Auswirkungen in der Praxis sind:

Was diese Zahlen für ein konkretes KMU bedeuten: Ein Entwicklerteam, das 42 Prozent seiner Zeit mit technischen Schulden verbringt, liefert im Vergleich zu einem Team mit sauberem technischen Fundament weniger als die Hälfte an echtem Mehrwert. Bei einem Jahresbudget von 200.000 Euro für externe Entwicklung bedeutet das, dass rund 84.000 Euro nicht in neue Funktionen fließen, sondern in die Bewältigung selbst verursachter Komplexität.

Warum wächst der Schuldenberg still – und warum wird er so selten angegangen?

Technische Schulden sind deshalb so gefährlich, weil sie lange Zeit keine sichtbaren Symptome zeigen. Das System läuft. Die Prozesse funktionieren. Nur langsam, und mit jeder neuen Anforderung ein bisschen schwieriger. Drei Mechanismen sorgen dafür, dass das Problem systematisch unterschätzt wird:

• Unsichtbarkeit im Tagesgeschäft: Technische Schulden zeigen sich nicht in einem Absturz oder einem Fehler – sondern in der wachsenden Zeit, die jede neue Änderung kostet. „Das Feature hat vier Wochen gedauert" klingt wie ein normaler Entwicklungsaufwand. Dass es ohne den Schuldenberg zwei Tage gewesen wären, ist im Nachhinein schwer zu belegen.
• Konkurrierende Prioritäten: Jedes Quartalsbudget steht unter dem Druck, neue Features zu liefern. Technischen Schulden abzubauen ist schwer zu verkaufen, weil es keine neue Funktionalität erzeugt – auch wenn es langfristig das Fundament für alles andere ist. Die Konsequenz: Das Problem wird regelmäßig verschoben, der Berg wächst.
• Fehlende Sprache zwischen IT und Business: Entwickler wissen genau, was im System nicht stimmt – aber sie haben oft keine effektive Möglichkeit, das Risiko in Businesssprache zu kommunizieren. „Der Code ist unübersichtlich" überzeugt keine Geschäftsführung. „Diese Architektur wird jede weitere CRM-Integration um mindestens 60 Prozent teurer machen" schon eher – aber diese Übersetzung findet selten statt.

Wie technische Schulden konkret Ihr Digitalisierungsvorhaben blockieren

Der direkte Zusammenhang zwischen technischem Schuldenberg und scheiternden Digitalisierungsprojekten lässt sich auf drei wiederkehrende Muster herunterbrechen, die ich in der Beratungspraxis regelmäßig beobachte:

Checkliste: Zehn Warnsignale für einen wachsenden Schuldenberg

Technische Schulden sind aus Unternehmersicht schwer direkt messbar. Diese Warnsignale zeigen jedoch zuverlässig an, wenn das IT-Fundament zum Problem wird – auch ohne tiefen technischen Einblick.

• Neue Features dauern unverhältnismäßig lang Was logisch einfach klingt, braucht Wochen in der Umsetzung. Die IT spricht von „Abhängigkeiten" und „Risiken" – ohne dass das Business genau versteht, warum.
• „Das geht leider nicht" ist eine häufige Antwort der IT Wenn Integrationen oder Automatisierungen regelmäßig als technisch nicht machbar eingestuft werden, liegt das oft nicht an der Aufgabe – sondern am Fundament, auf dem sie umgesetzt werden soll.
• Kritische Prozesse hängen an einer Person oder einer Excel-Datei Wenn ein Mitarbeiter im Urlaub ist und bestimmte Auswertungen nicht erstellt werden können – oder wenn Daten manuell zwischen Systemen übertragen werden – ist das ein strukturelles Risiko.
• Jede Anbindung an neue Software erfordert einen individuellen Aufwand Wenn Ihr zentrales System bei jeder Integrations-Anfrage eine Sonderentwicklung erfordert, statt sich über Standardschnittstellen verbinden zu lassen, ist das ein klares Zeichen.
• Updates und Patches werden aufgeschoben Wenn Sicherheitsupdates nicht eingespielt werden, weil „das letzte Mal etwas kaputt gegangen ist", ist das Fundament fragil – und das Risiko eines Ausfalls oder Sicherheitsvorfalls steigt täglich.
• Gute Entwickler verlassen das Unternehmen schneller als andere Erfahrene Entwickler erkennen, wenn ein System nicht mehr wartbar ist – und suchen sich lieber Projekte, bei denen sie handwerklich sauber arbeiten können. Hohe Fluktuation im IT-Team ist ein indirektes Signal.
• Kosten für externe Entwicklung steigen, ohne dass mehr geliefert wird Wenn derselbe Dienstleister mit demselben Team von Jahr zu Jahr mehr Budget verbraucht, ohne dass der Funktionsumfang proportional wächst, ist das ein Hinweis auf wachsende technische Komplexität.
• Niemand kennt das System vollständig Wenn es kein internes oder externes Wissen darüber gibt, wie alle Teile des Systems zusammenhängen, ist das ein erhebliches Risiko – nicht nur für die Weiterentwicklung, sondern auch für die Betriebsstabilität.
• Digitalisierungsprojekte starten, aber liefern nicht Wenn mehrere Digitalisierungsvorhaben der letzten Jahre das geplante Ziel nicht erreicht haben, liegt die Ursache häufig nicht im Vorhaben selbst – sondern im technischen Fundament, auf das sie aufgebaut wurden.
• „Das haben wir immer so gemacht" gilt als Begründung für IT-Entscheidungen Wenn Prozesse und Systeme nicht nach Effizienz oder Eignung bewertet werden, sondern nach Gewohnheit, ist das ein Zeichen, dass technische und organisatorische Modernisierung längst überfällig ist.

Wie geht man strukturiert vor – ohne alles auf einmal zu reißen?

Die häufigste Fehlannahme im Umgang mit technischen Schulden: Man müsse alles auf einmal modernisieren. Das ist selten notwendig – und fast immer zu riskant und zu teuer. Was stattdessen funktioniert, ist ein priorisierter, schrittweiser Ansatz.

Der erste Schritt ist dabei immer derselbe: Klarheit schaffen. Bevor Entscheidungen getroffen werden – ob modernisieren, ablösen, oder weitermachen –, braucht es eine ehrliche Bestandsaufnahme. Was ist kritisch? Was kann warten? Was lässt sich mit überschaubarem Aufwand bereinigen, bevor das nächste Digitalisierungsvorhaben startet?

Genau das ist der Kern eines strukturierten Digital Assessments: nicht nur zu wissen, wo das Unternehmen digital steht – sondern auch zu verstehen, welche technischen Altlasten den nächsten Schritt teurer oder riskanter machen als nötig.

Fazit: Technische Schulden sind kein IT-Problem – sie sind ein Unternehmensproblem

Das Wichtigste, was ich nach mehr als zwölf Jahren in der Software-Entwicklung und im Product Management gelernt habe: Technische Schulden entstehen nicht, weil IT-Teams schlechte Arbeit machen. Sie entstehen, weil unter Zeitdruck pragmatische Entscheidungen getroffen werden – und weil das Business danach nicht die Ressourcen freigibt, die nötig wären, um das Fundament zu pflegen.

Das macht technische Schulden zu einem unternehmerischen Thema, nicht zu einem technischen. Die Entscheidung, einen Schuldenberg wachsen zu lassen, trifft immer das Business – oft ohne es zu wissen. Die Konsequenzen zahlt das nächste Digitalisierungsprojekt.

Wer heute mit einem Digital Assessment Klarheit darüber schafft, wo die kritischsten technischen Altlasten sitzen, investiert nicht in Vergangenheitsbewältigung. Er investiert in die Voraussetzung dafür, dass das nächste Vorhaben – CRM-Einführung, Cloud-Migration, KI-Initiative – planbar, budgetsicher und erfolgreich wird.