Wir haben in den letzten Jahren mehrere Ablöseprojekte rund um bekannte Business-Standardsoftware begleitet - darunter Systeme wie Vertec im Professional-Services-Umfeld und Centric im Textilhandel. Die Geschichten ähneln sich, obwohl die Branchen unterschiedlich sind. Dieser Artikel beschreibt das Muster, warum es entsteht und wann eine individuelle Lösung der bessere Weg ist.
Vorweg: Vertec und Centric sind beide keine schlechten Produkte. Sie lösen reale Probleme für viele Unternehmen. Die Frage, um die es in diesem Artikel geht, ist eine andere: Wann kippt das Verhältnis, ab wann arbeitet ein Unternehmen nicht mehr mit dem System, sondern gegen es?
Das immer gleiche Muster
Die Einstiegssituation in den Projekten war verblüffend ähnlich:
Einführung
Die Software wurde vor 5, 10, manchmal 15 Jahren eingeführt - oft als klarer Fortschritt gegenüber dem, was davor da war.
Anfangs-Fit
Zu Beginn passt sie ordentlich: die wesentlichen Prozesse lassen sich abbilden, die Einführung ist dokumentiert, die Anbieterbindung akzeptabel.
Prozess-Drift
Mit der Zeit werden die Geschäftsprozesse spezifischer - neue Geschäftsfelder, neue Kundensegmente, neue Steuerungslogiken.
Flickschusterei
Das System hält mit - aber über Custom-Felder, Workarounds, Excel-Exporte an den Rändern und parallele Datenbanken.
Irgendwann kommt der Punkt, an dem die Ausnahmen mehr werden als die Regeln. An dem in einer Dokumentation zur internen Kalkulation siebzehn Sonderfälle aufgelistet sind, die irgendwo im System stecken, aber nirgendwo sauber modelliert sind. An dem niemand im Haus mehr genau sagen kann, warum eine bestimmte Auswertung so aussieht, wie sie aussieht.
Das ist der Moment, an dem wir typischerweise ins Gespräch kommen.
Warum das passiert - und zwar systematisch
Die Ursache liegt nicht an der Software selbst, sondern an einer strukturellen Eigenschaft von Standardlösungen. Drei Punkte greifen ineinander:
01
Für alle gemacht, für niemanden maßgeschneidert
Standardsoftware verkauft sich über Breite - für 15 MA genauso wie für 400, für Kanzleien wie für Digitalagenturen. Diese Breite wird über Konfigurierbarkeit erkauft: Custom-Felder, freie Workflows, generische Reporting-Engines. Sobald Ihre Geschäftslogik spezifische Kanten hat, beginnt die Konfiguration zur Flickschusterei zu werden.
02
Schnittstellen aus einer anderen Zeit
Datenbankschemata aus den frühen 2000ern, SOAP-APIs mit REST-Fassade überklebt, CSV-Import mit festgelegter Spaltenreihenfolge. Solange Sie innerhalb der Software arbeiten, fällt das nicht auf. Sobald Sie integrieren müssen - CRM, Data Warehouse, BI - wird es schmerzhaft.
03
Updates, die den Workaround bedrohen
Jedes größere Release weckt die Angst: Läuft der Workaround weiter? Hat sich das Feld-Verhalten geändert? Funktioniert das Reporting noch? Wir haben Kunden erlebt, die Updates bewusst zwei Jahre verschleppt haben - aus reiner Risiko-Abwägung.
Das ist der Punkt, an dem eine Standardlösung de facto zur Legacy-Software geworden ist - nur dass man dafür weiterhin Lizenzen bezahlt.
Was wir in den Ablöseprojekten beobachtet haben
Wenn Unternehmen uns mit der Frage einer Ablösung ansprechen, kommen sie praktisch nie mit einem reinen Technik-Argument. Sie kommen mit einem Geschäfts-Argument:
- “Wir wissen nicht mehr, ob unsere Projekte profitabel sind.”
- “Wir brauchen für eine einfache Quartals-Auswertung drei Leute und zwei Wochen.”
- “Neue Mitarbeiter finden sich im System nicht zurecht.”
- “Wir haben eine Idee für ein neues Geschäftsmodell, aber das System kann es nicht.”
Die technische Diskussion kommt danach. Und an dem Punkt wird es spannend, weil es zwei mögliche Antworten gibt:
Antwort A
Innerhalb der Standardsoftware bleiben
Modul erweitern, Workarounds konsolidieren, externes Reporting-Tool anbinden, Prozesse in zweiter Reihe bauen.
Antwort B
Kernprozesse in eine individuelle Lösung überführen
Die Standardsoftware dort behalten, wo sie wirklich Standard abbildet (Buchhaltung, HR, Teile des CRM). Die spezifische Geschäftslogik in einer eigenen Anwendung sauber modellieren.
Die zweite Antwort ist nicht immer die richtige. Aber wenn sie es ist, funktioniert sie in der Regel aus einem simplen Grund: Die eigene Anwendung muss nicht generisch sein. Sie modelliert genau das eine Geschäftsmodell, das sie unterstützen soll. Keine Custom-Felder. Keine Workarounds. Keine Sonderfalldokumentation. Die Geschäftslogik steht direkt im Code und im Datenmodell.
Drei Signale, dass eine Ablösung anstehen könnte
Wir haben für uns drei Signale extrahiert, die in Gesprächen immer wieder auftauchen:
Signal 1
Parallele Excel-Welt
Die Fachabteilung führt eine Excel-Welt parallel zur Standardsoftware - nicht für Notfälle, sondern im Tagesgeschäft. Deutlichster Hinweis, dass das System die reale Arbeit nicht trägt.
Signal 2
Power-User als Risiko
Zwei bis drei Personen verstehen die Besonderheiten - ihr Urlaub bremst Projekte. Schlüsselwissen hängt an Einzelnen, nicht am System.
Signal 3
Strategie-Bremse
„Könnte unser System das?” ist die erste Frage bei jeder neuen Idee - und die Antwort lautet regelmäßig „schwierig”. Das System bremst die Strategie, nicht umgekehrt.
Einzeln ist keines dieser Signale ein Grund, ein etabliertes System über den Haufen zu werfen. In Kombination - und bei einem Unternehmen, das strukturell wachsen will - schon.
Was ein Ablöseprojekt realistisch bedeutet
Wir sind mit der Aussage “wir lösen jetzt ab” bewusst vorsichtig. In den Projekten, die wir begleitet haben, hat sich ein Muster bewährt, das deutlich pragmatischer ist als ein Big-Bang-Austausch:
Phase 1
Discovery
Die tatsächlichen Kernprozesse aufnehmen - nicht die Systemlandschaft. Was muss das Unternehmen können, unabhängig von heutigen Tools?
Phase 2
Schnitt definieren
Was bleibt im Standard (Buchhaltung, HR, Standard-CRM)? Was wird durch eine individuelle Lösung ersetzt (Kernlogik, Reporting, kritische Abläufe)?
Phase 3
Parallelbetrieb
Die neue Lösung läuft parallel. Datenimport, schrittweise Übergabe von Teilbereichen. Altwerte werden übernommen, die Historie bleibt nutzbar.
Phase 4
Abschaltung
Erst wenn die neue Lösung den kompletten Prozess abdeckt und stabil läuft, wird die Altlösung heruntergefahren. Keine Deadline-Kompromisse.
Das ist weniger glamourös als ein Komplettaustausch, aber risikoärmer - und für den Mittelstand meist der einzig gangbare Weg, weil das Tagesgeschäft nicht stehenbleiben kann.
Ehrlich bleiben: wann Standardsoftware weiterhin das Mittel der Wahl ist
Damit dieser Artikel nicht wie ein Plädoyer pro Individualentwicklung wirkt - es gibt klare Fälle, in denen Standardsoftware weiterhin die richtige Wahl ist:
Branchenüblicher Kernprozess. Ein ausgereiftes Produkt bildet ihn gut ab - kein Bedarf für Eigenentwicklung.
Prozesse nicht als USP gewollt. Wenn Abläufe kein Wettbewerbsvorteil sein sollen, müssen sie auch nicht individuell sein.
Randthema, nicht Wertschöpfungs-Kern. Das System ist an der Peripherie, nicht im Zentrum des Geschäfts.
Interne Kapazität für Hersteller-Zyklik. Ihr Team kann mit Konfigurations- und Update-Rhythmen gut leben.
In allen diesen Fällen ist eine Individualentwicklung teuer und bringt wenig. Wir sagen das in Erstgesprächen auch so, wenn es so ist.
