Wie der Mittelstand Altsysteme schrittweise statt per Big Bang ablöst

Parallel dazu drängt die Frage, wie ein Altsystem überhaupt abgelöst wird. Ein Big-Bang-Cutover wirkt auf dem Papier effizient. In der Praxis scheitert er häufig nicht an der Technik, sondern an Datenqualität, unklaren Zuständigkeiten und fehlenden Rückfallpfaden.

Dieser Beitrag ordnet die Entscheidung Standard versus Individual ein und zeigt, warum eine schrittweise Ablösung für den Mittelstand meist die belastbarere Strategie ist.

Wann Standardsoftware reicht – und wann Individualsoftware wirtschaftlich wird

Standardsoftware ist die richtige Wahl, wenn Ihre Prozesse nah am Branchenstandard liegen, die Software Ihre Kernabläufe abbildet und Anpassungen sich auf Konfiguration, wenige Schnittstellen und dokumentierte Erweiterungen beschränken. Dann sprechen kurze Einführungszeiten, ein bestehendes Partnernetzwerk und planbare Updates für den Standard.

Individuelle Software wird interessant, wenn genau jene Prozesse Ihren Wettbewerbsvorteil ausmachen – besondere Preismodelle, Freigabelogiken, branchenspezifische Disposition oder Verknüpfungen zwischen Shop, Portal und ERP, die kein Paket ohne teure Sonderlocke abbildet. Dann zahlen Sie bei Standardsoftware oft zweimal: einmal für Lizenzen und Module, einmal für Anpassungen, die bei jedem Major-Release erneut geprüft werden müssen.

Drei Kriterien helfen bei der Einordnung:

1. Prozess als Differenzierung: Ist der Ablauf austauschbar oder Teil Ihres Markenversprechens?

2. Integrationsaufwand: Wie viele Systeme müssen zuverlässig und bidirektional angebunden werden? Je höher die Kopplung, desto stärker entscheidet die Architektur der Schnittstellen.

3. Gesamtkosten über die Nutzungsdauer: Lizenz, Betrieb, Anpassung, Test bei Updates und internes Know-how gehören in dieselbe Rechnung.

In der Praxis entsteht häufig ein Hybrid: Standard dort, wo Commodity-Funktionen reichen (Buchhaltung, HR, Basiskatalog), Individual dort, wo Prozess und Integration das Geschäft tragen. Entscheidend ist, dass Sie diese Grenze bewusst ziehen – und nicht nachträglich mit Workarounds zudecken, die bei jedem Update erneut getestet werden müssen.

Warnsignale gewachsener Altsysteme

Typische Warnsignale im Mittelstand:

– Insellösungen: Fachbereiche betreiben eigene Tools, die per Export und Import „integriert“ werden.

– Excel-Brücken: Kritische Preise, Bestände oder Freigaben leben in Tabellen, die niemand versioniert.

– Wissen bei Einzelpersonen: Dokumentation fehlt; nur wenige wissen, warum ein Batch nachts läuft.

– Doppelpflege: Dieselben Stammdaten existieren in Shop, ERP und PIM in leicht abweichenden Varianten.

– Änderungsangst: Jeder Eingriff gilt als riskant, weil Seiteneffekte unbekannt sind.

Solche Systeme müssen nicht sofort ersetzt werden. Sie signalisieren aber, dass ein Big Bang die Risiken bündelt statt sie zu reduzieren: Am Stichtag müssen Daten, Prozesse, Schulung und Integrationen gleichzeitig funktionieren.

Warum der Big Bang im Mittelstand oft scheitert

Ein Big-Bang-Go-live verspricht einen sauberen Schnitt. Häufig scheitert er an unterschätzter Datenmigration, fehlendem Parallelbetrieb zum Vergleich von Alt und Neu, einer Organisation, die neue Masken ohne geänderte Freigaben und Eskalationen erhält – und an fehlendem Rückfall, wenn der Stichtag nicht hält. Bei kleinen, klar abgegrenzten Anwendungen ohne tiefe Integration kann ein Big Bang trotzdem sinnvoll sein. Sobald Shop, ERP, PIM und Portale ineinander greifen, verschiebt sich das Risiko zugunsten einer inkrementellen Ablösung.

Schrittweise Ablösung: Schnittstellen zuerst, Module nacheinander

Architektonisch entspricht das dem Strangler Fig Pattern: Das Altsystem wird nicht umgeworfen, sondern nach und nach von neuen Komponenten umschlossen und ersetzt. Eine Anticorruption Layer – eine klar begrenzte Übersetzungsschicht zwischen Alt und Neu – verhindert, dass alte Datenmodelle ungefiltert einwandern.

Konkret bewährt sich oft diese Reihenfolge:

1. Schnittstellen und Datenflüsse zuerst klären. Welche Systeme sind führend für Artikel, Preis, Bestand, Auftrag? Wer darf schreiben?

2. Einen begrenzten fachlichen Schnitt herauslösen – etwa Online-Auftragserfassung oder Preisauskunft – bei laufendem Altkern.

3. Alt und Neu eine Zeit lang parallel betreiben, damit Abweichungen sichtbar werden, bevor der alte Pfad abgeschaltet wird.

4. Module nacheinander ablösen, sobald Monitoring, Fehlerraten und Fachabteilung grünes Licht geben.

5. Altsystem gezielt stilllegen – mit Datum, Verantwortlichen und Nachweis, dass keine kritischen Abhängigkeiten mehr bestehen.

Dieser Weg dauert länger als ein PowerPoint-Zeitplan für den Big Bang. Er verteilt aber Risiko, Lernen und Investition und hält das Tagesgeschäft lauffähig. Gerade im Mittelstand, wo dieselben Personen Projekt und Betrieb stemmen, ist das kein Luxus, sondern Voraussetzung. In Integrationsprojekten zeigt sich regelmäßig: Nicht die API-Technologie entscheidet über Stabilität, sondern Idempotenz, Wiederholversuche und die Sichtbarkeit von Fehlern. Dieselbe Logik gilt für die Ablösung.

Governance: Was vor dem Start geklärt sein sollte

Technik allein trägt keine Migration. Vor dem ersten Sprint sollten mindestens stehen:

• Datenqualität und Ownership: Wer ist fachlich für welche Stammdaten verantwortlich?

• Erfolgskriterien: messbare Größen statt nur „Go-live erfolgt“ – Fehlerrate der Schnittstellen, Dauer kritischer Prozesse, manuelle Nacharbeiten.

• Verantwortlichkeiten: Auftraggeber, Architektur, Betrieb, Fachseite; klare Eskalation bei „Standard anpassen oder Prozess ändern“.

• Sicherheits- und Betriebsmodell: Rechte, Protokollierung, Restore-Tests, Monitoring der Schnittstellen.

• Risikoregister: Abbruchkriterien, Fallback, Kommunikation bei Verschiebung eines Teilschritts.

Häufige Risiken sind Scope-Creep, versteckte Excel-Prozesse und Update-Fähigkeit, die durch zu tiefe Eingriffe in Standardsoftware verloren geht. Gegenmittel sind kleine Inkremente und die Disziplin, Commodity-Funktionen nicht individuell nachzubauen.

Einordnung statt Dogma

Für IT-Entscheider heißt das: Die Frage „Standard oder Individual?“ ist der Einstieg, nicht das Ziel. Mindestens genauso wichtig ist, wie Sie vom Ist-Zustand dorthin kommen, ohne das laufende Geschäft zu gefährden.

Weder Standard noch Individualsoftware ist per se modern oder veraltet. Entscheidend ist, ob die Lösung Ihren differenzierenden Prozess trägt, ob Integrationen beherrschbar bleiben und ob Sie das Altsystem so ablösen, dass Lernen und Betrieb Schritt halten. Für viele mittelständische IT-Landschaften ist die Antwort deshalb nicht der große Stichtag, sondern die kontrollierte, schrittweise Herauslösung – mit klaren Schnittstellen, parallelem Nachweis und Governance, die vor dem Code steht.