Wenn Digitalisierung zur Digitalisierungs-Rücknahme wird: Eine Warnung aus der Praxis

Das perfekte IT-Projekt – und sein unrühmliches Ende

Es war einmal eine maßgeschneiderte Fachanwendung, die genau das tat, wofür sie entwickelt wurde: Sie ersetzte einen fehleranfälligen, Excel-basierten Prozess durch eine robuste, validierte Software-Lösung. Die Fachabteilung arbeitete seit mehreren Jahren zufrieden damit. Fehlerquoten sanken drastisch, die Qualität der an Behörden übermittelten Daten verbesserte sich signifikant, und die Mitarbeiter hatten endlich ein Werkzeug, das ihre tägliche Arbeit erleichterte statt erschwerte.

Dann kam die Management-Initiative.

Unter dem Banner "Digitalisierung und Konsolidierung von IT-Systemen" wurde die bewährte Fachanwendung abgekündigt. Der Prozess wurde aufgebrochen und... [hier endet die Geschichte vorerst, denn wie genau der Prozess neu gestaltet wurde, bleibt im Nebel der strategischen Präsentationen verborgen].

Diese Geschichte ist kein Einzelfall. Sie wiederholt sich in deutschen Unternehmen und Behörden mit erschreckender Regelmäßigkeit. Und sie offenbart ein fundamentales Missverständnis darüber, was Digitalisierung eigentlich bedeutet.

Die Ironie der IT-Konsolidierung

Die Ironie dieser Situation ist kaum zu überbieten: Eine funktionierende digitale Lösung wird im Namen der Digitalisierung abgeschafft. Ein System, das manuell-fehleranfällige Prozesse eliminiert hat, wird zugunsten einer "strategischen Ausrichtung" geopfert.

Lassen wir uns die Ausgangssituation noch einmal vor Augen führen:

Vorher (Excel-basiert):

• Hohe Fehleranfälligkeit durch manuelle Dateneingabe
• Inkonsistente Datenqualität
• Risiko bei behördlichen Meldungen (Compliance-Risiken, potenzielle Bußgelder)
• Fehlende Nachvollziehbarkeit und Audit-Trails
• Abhängigkeit von Excel-Kenntnissen einzelner Mitarbeiter
• Keine systematische Validierung

Nachher (individuelle Fachanwendung):

• Validierte, getestete Software-Lösung
• Eingebaute Plausibilitätsprüfungen und Validierungen
• Reduzierte Fehlerquote
• Nachvollziehbare Prozesse mit Audit-Trail
• Zufriedene Fachanwender
• Compliance-konforme Datenlieferungen an Behörden

Und dann (nach der Konsolidierung):

• ???
  
  

Die drei fatalen Denkfehler bei IT-Konsolidierungen

Denkfehler Nr. 1: "Weniger Systeme = bessere IT"

Die Gleichung "weniger Systeme = niedrigere Kosten und höhere Effizienz" ist verführerisch einfach – und oft genug schlicht falsch. Diese Denkweise verwechselt Quantität mit Qualität und übersieht die eigentliche Funktion von IT-Systemen: Geschäftsprozesse optimal zu unterstützen.

Eine spezialisierte Fachanwendung existiert nicht aus Lust und Laune. Sie existiert, weil Standard-Lösungen den spezifischen Anforderungen nicht gerecht werden. Im beschriebenen Fall ging es um die fehlerfreie Übermittlung kritischer Daten an Behörden – ein Prozess mit null Fehlertoleranz.

Die Konsolidierung auf ein "strategisches" Standardsystem bedeutet in der Praxis häufig

Denkfehler Nr. 2: "Die Fachbereiche müssen sich anpassen"

Ein Klassiker des IT-Managements: "Das neue System kann das zwar nicht genau so, aber die Prozesse müssen sich eben anpassen." Diese Aussage offenbart ein grundlegendes Missverständnis über die Rolle der IT.

IT ist kein Selbstzweck. IT ist Mittel zum Zweck. Der Zweck ist die Unterstützung der Geschäftsprozesse, nicht deren Behinderung.

Wenn eine Fachanwendung über Jahre hinweg zuverlässig einen kritischen Prozess unterstützt hat, dann ist dieser Prozess nicht das Problem. Das Problem entsteht, wenn Management-Entscheidungen fernab der operativen Realität getroffen werden.

Die Frage sollte nicht lauten: "Wie können wir die Fachbereiche zwingen, mit unserem Standard-System zu arbeiten?" Die Frage muss lauten: "Wie unterstützen wir die Fachbereiche optimal bei ihrer Arbeit – auch wenn das bedeutet, spezialisierte Lösungen zu betreiben?"

Denkfehler Nr. 3: "Total Cost of Ownership wird durch Konsolidierung automatisch gesenkt"

Die TCO-Rechnung bei IT-Konsolidierungen ist oft eine Milchmädchenrechnung. Sie berücksichtigt:

Was in der Kalkulation steht:

Was in der Kalkulation fehlt:

Im beschriebenen Fall kommt ein besonders kritischer Faktor hinzu: Das Risiko fehlerhafter Datenlieferungen an Behörden. Die individuelle Fachanwendung hatte dieses Risiko minimiert. Was passiert, wenn nach der Konsolidierung wieder Fehler auftreten?

Was wirklich passiert: Der Teufelskreis der gescheiterten Konsolidierung

Die typische Entwicklung nach einer solchen "strategischen" Entscheidung folgt einem vorhersehbaren Muster:

Phase 1 - Euphorie (Monat 1-3): Das Management präsentiert die Vision der konsolidierten IT-Landschaft. PowerPoint-Charts zeigen vereinfachte Systemarchitekturen. Einsparpotenziale werden quantifiziert. Das Projekt startet.

Phase 2 - Ernüchterung (Monat 4-8): Die ersten Detailanforderungen werden dokumentiert. Es stellt sich heraus, dass das neue System doch nicht alles kann, was die alte Fachanwendung konnte. "Das muss reichen", heißt es. Workarounds werden entwickelt.

Phase 3 - Krise (Monat 9-15): Das System geht live. Die Fachabteilung kämpft mit den neuen Prozessen. Die Fehlerquote steigt. Erste kritische Vorfälle bei behördlichen Meldungen. Notfall-Meetings werden einberufen. Excel-Tabellen tauchen als "temporäre Hilfsmittel" wieder auf.

Phase 4 - Schatten-IT (Monat 16+): Die Fachabteilung entwickelt eigene Lösungen, um die Lücken zu schließen. Excel wird wieder zum Hauptwerkzeug – oft ohne IT-Governance, ohne Backup-Strategie, ohne Validierung. Der Kreis schließt sich: Wir sind wieder beim ursprünglichen Problem, nur mit einem teuren Standardsystem zusätzlich.

Phase 5 - Selektive Erinnerung (Jahr 3+): Niemand spricht mehr über die ursprüngliche Fachanwendung. Das neue System ist "etabliert". Die höheren Fehlerquoten und der zusätzliche manuelle Aufwand sind "neue Normalität" geworden. Die Kosten der Konsolidierung sind in verschiedenen Budgets verteilt und nicht mehr sichtbar. Der Business Case wird nicht mehr hinterfragt.

Die vergessenen Stakeholder: Die Anwender

In all den strategischen Überlegungen zur IT-Konsolidierung wird eine Gruppe systematisch überhört: Die Menschen, die täglich mit den Systemen arbeiten müssen.

Die Fachabteilung im beschriebenen Fall hatte eine Lösung gefunden, mit der sie jahrelang zufrieden arbeitete. Diese Zufriedenheit war kein Zufall:

All das wird mit einem Federstrich zunichtegemacht – nicht weil das System versagt hätte, sondern weil es in eine Management-Strategie nicht mehr hineinpasst.

Die psychologischen und organisatorischen Kosten werden komplett ausgeblendet:

Vertrauensverlust in IT-Entscheidungen.
Demotivation durch erzwungene Verschlechterungen.
Innere Kündigung ("Die da oben haben eh keine Ahnung").
Widerstand gegen zukünftige IT-Projekte.

Bessere Alternativen: Wie Konsolidierung funktionieren kann

IT-Konsolidierung ist nicht per se falsch. Wildwuchs in der Systemlandschaft ist ein reales Problem. Aber die Lösung liegt nicht in blinder Standardisierung, sondern in intelligenter Differenzierung.

Prinzip 1: Differenzierung nach Kritikalität

Nicht jede Anwendung hat dieselbe Bedeutung. Eine sinnvolle IT-Strategie unterscheidet:

Commodity-Prozesse (E-Mail, Office, Basis-ERP):

• Hier ist Standardisierung sinnvoll und kostensparend
• Fachanforderungen sind gering
• Best-Practice-Prozesse sind ausreichend

Differenzierende Prozesse (fachspezifische Kernanwendungen):

• Hier schafft Individualisierung echten Mehrwert
• Fachliche Spezialanforderungen sind hoch
• Standard-Lösungen führen zu Qualitätsverlusten

Kritische Compliance-Prozesse (wie behördliche Meldungen):

• Hier ist Fehlerfreiheit nicht verhandelbar
• Validierung und Qualitätssicherung sind zwingend
• Die Kosten fehlerhafter Prozesse übersteigen jede Lizenzersparnis

Die Fachanwendung im beschriebenen Fall fällt eindeutig in die letzten beiden Kategorien. Hier Konsolidierung um der Konsolidierung willen zu betreiben, ist organisatorischer Selbstmord auf Raten.

Prinzip 2: TCO ehrlich berechnen

Eine ehrliche TCO-Berechnung berücksichtigt:

Direkte IT-Kosten:

• Lizenzen und Wartung
• Infrastruktur und Betrieb
• Support und Administration

Indirekte Kosten:

• Prozessqualität und Fehlerkosten
• Produktivität der Anwender
• Compliance-Risiken
• Flexibilität bei Prozessänderungen

Opportunitätskosten:

• Was könnten Mitarbeiter tun, wenn sie nicht mit schlechten Systemen kämpfen müssten?
• Welche Innovationen werden verhindert?
• Welche Talente verlieren wir an die Konkurrenz?

Oft stellt sich heraus, dass die kleine, spezialisierte Fachanwendung trotz höherer Lizenzkosten pro User insgesamt günstiger ist als die "konsolidierte" Lösung, wenn man ehrlich rechnet.

Prinzip 3: "Make vs. Buy vs. Configure" strategisch entscheiden

Nicht für jeden Prozess muss eine individuelle Lösung entwickelt werden. Aber eben auch nicht für jeden Prozess kann ein Standard-System die optimale Lösung sein.

Standard-Software (Buy) wenn:

• Der Prozess ist nicht differenzierend
• Best-Practice-Prozesse sind akzeptabel
• Das Customizing-Potenzial ist begrenzt

Konfigurierbare Plattformen (Configure) wenn:

• Fachliche Spezialanforderungen bestehen
• Aber grundlegende Prozesse standardisierbar sind
• Low-Code/No-Code-Plattformen können hier Brücken bauen

Individuelle Entwicklung (Make) wenn:

• Hochspezifische, kritische Anforderungen bestehen
• Keine Standard-Lösung die Anforderungen erfüllt
• Die Kosten von Fehlern sehr hoch sind (wie bei behördlichen Meldungen)
• Der Prozess Wettbewerbsvorteile generiert

Die beschriebene Fachanwendung war offensichtlich ein klarer Fall für "Make" – und hatte sich bewährt.

Prinzip 4: Vom Anwender her denken

Jede IT-Strategie sollte mit der Frage beginnen: "Wie können wir die Anwender optimal unterstützen?" Nicht: "Wie können wir unsere Systemanzahl reduzieren?"

Praktische Umsetzung:

• Fachbereiche frühzeitig und ernsthaft einbinden
• Prototypen mit echten Anwendern testen
• Akzeptanzkriterien gemeinsam definieren
• Einen "Veto-Mechanismus" für kritische Funktionen etablieren
• Parallelbetrieb ermöglichen bis die neue Lösung wirklich besser ist

Wenn die Fachbereiche jahrelang zufrieden mit einer Lösung waren, dann sollte die Beweislast bei der IT liegen, dass die neue Lösung mindestens gleichwertig ist – nicht umgekehrt.

Die Lehren für IT-Management und Digitalisierungsinitiativen

Lektion 1: Digitalisierung bedeutet nicht Standardisierung

Digitalisierung heißt, Prozesse durch IT optimal zu unterstützen. Manchmal bedeutet das Standardisierung, manchmal bedeutet das Individualisierung. Die Kunst liegt darin, beides klug zu kombinieren.

Lektion 2: Konsolidierung ist kein Selbstzweck

Eine reduzierte Anzahl an Systemen ist kein Erfolg, wenn die verbleibenden Systeme die Geschäftsprozesse schlechter unterstützen als zuvor.

Lektion 3: Prozessqualität ist wichtiger als Prozessstandardisierung

Besonders bei kritischen Prozessen wie behördlichen Meldungen ist Fehlerfreiheit wichtiger als System-Harmonie. Eine gut funktionierende "Insellösung" ist besser als eine konsolidierte Chaos-Lösung.

Lektion 4: Die Meinung der Anwender zählt

Wenn eine Fachabteilung jahrelang zufrieden mit einem System arbeitet, dann ist das ein starkes Signal. Diese Zufriedenheit leichtfertig aufs Spiel zu setzen, ist riskant.

Lektion 5: Ehrliche Erfolgsmessung

IT-Konsolidierungsprojekte sollten nicht nur nach Systemanzahl und Lizenzkosten bewertet werden, sondern auch nach:

• Prozessqualität (Fehlerquoten vor/nach)
• Anwenderzufriedenheit
• Produktivitätskennzahlen
• Compliance-Kennzahlen
• Tatsächliche TCO über 3-5 Jahre

Fazit

Die Geschichte der abgekündigten Fachanwendung ist eine Warnung. Sie zeigt, wie gut gemeinte Digitalisierungs- und Konsolidierungsinitiativen das Gegenteil dessen erreichen können, was sie bezwecken.

Echte digitale Transformation bedeutet nicht, alle Prozesse in ein Standard-System zu pressen. Sie bedeutet, für jeden Prozess die optimale Lösung zu finden – auch wenn das bedeutet, spezialisierte Fachanwendungen zu betreiben.

IT-Konsolidierung ist dann erfolgreich, wenn sie die Geschäftsprozesse besser unterstützt, nicht wenn sie die Systemlandschaft einfacher macht. Manchmal ist eine etwas komplexere IT-Landschaft mit hochspezialisierten Lösungen der Preis für exzellente Prozessqualität – ein Preis, der sich lohnt.

Die Frage, die sich jedes Management bei solchen Initiativen stellen sollte, lautet nicht: "Wie können wir Systeme konsolidieren?" Die Frage muss lauten: "Wie können wir unsere Geschäftsprozesse optimal unterstützen – und welche IT-Landschaft brauchen wir dafür?"

Im beschriebenen Fall war die Antwort klar: Eine spezialisierte Fachanwendung, mit der die Anwender jahrelang zufrieden gearbeitet haben. Alles andere ist Rückschritt im Gewand der Digitalisierung.

Dieser Artikel basiert auf einem realen Szenario und spiegelt ein weit verbreitetes Muster in deutschen Unternehmen und Behörden wider. Die Namen wurden nicht genannt, weil sie austauschbar sind – dieselbe Geschichte spielt sich in zahllosen Organisationen ab. Wenn Sie sich in diesem Artikel wiedererkennen: Sie sind nicht allein. Und es ist noch nicht zu spät für eine Kurskorrektur.