In den letzten Jahren haben wir mehrere Ablöseprojekte rund um bekannte Business-Standardsoftware begleitet: Vertec im Professional-Services-Umfeld, Centric im Textilhandel. Unterschiedliche Branchen, dieselbe Geschichte. Und wer heute an die Grenzen seiner Branchensoftware stößt, ob Speditionssoftware, Warenwirtschaft oder Handwerkerlösung, erzählt sie meistens auch.
Vertec und Centric sind gute Produkte. Sie lösen reale Probleme für viele Unternehmen, und in den meisten Fällen bleiben sie die richtige Wahl. Interessant ist der Punkt, an dem das Verhältnis kippt: ab wann arbeitet ein Unternehmen gegen sein System statt damit?
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
Standardsoftware verkauft sich über Breite: für 15 Mitarbeiter genauso wie für 400, für Kanzleien wie für Digitalagenturen. Bezahlt wird diese Breite mit Konfigurierbarkeit. Custom-Felder, freie Workflows, generische Reporting-Engines. Hat euer Geschäft eigene Kanten, wird aus Konfiguration schnell Flickschusterei.
02
Schnittstellen aus einer anderen Zeit
Datenbankschemata aus den frühen 2000ern, SOAP-APIs mit einer REST-Fassade überklebt, CSV-Import mit fester Spaltenreihenfolge. Innerhalb der Software merkt man davon nichts. Beim ersten Anbinden von CRM, Data Warehouse oder BI schon.
03
Updates, die den Workaround bedrohen
Jedes größere Release wirft dieselben Fragen auf: Läuft der Workaround weiter? Hat sich das Feld-Verhalten geändert? Funktioniert das Reporting noch? Wir hatten Kunden, die Updates zwei Jahre lang verschoben haben, aus reiner Risikoabwägung.
An diesem Punkt ist aus der Standardsoftware Legacy-Software geworden. Mit dem Unterschied, dass die Lizenzgebühren weiterlaufen.
Womit die Gespräche anfangen
Wer uns wegen einer Ablösung anspricht, kommt fast nie mit einem Technik-Argument. Sondern mit einem aus dem Geschäft:
- “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 später. Und dann gibt es zwei mögliche Antworten:
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.
Das Datenmodell bildet euer Geschäft direkt ab, ohne Custom-Felder und Sonderfalldokumentation.
Antwort B passt längst nicht immer. Wenn sie passt, dann aus einem einfachen Grund: Eine eigene Anwendung darf spezifisch sein. Sie bildet genau ein Geschäftsmodell ab, nämlich eures. Die Logik steht im Datenmodell statt in einer Sammlung von Custom-Feldern, deren Bedeutung irgendwo dokumentiert ist.
Drei Signale für eine anstehende Ablösung
Drei Dinge tauchen in diesen Gesprächen immer wieder auf:
Signal 1
Parallele Excel-Welt
Die Fachabteilung führt eine Excel-Welt neben der Standardsoftware, und zwar im Tagesgeschäft. Das deutlichste Zeichen dafür, dass die eigentliche Arbeit woanders stattfindet.
Signal 2
Power-User als Risiko
Zwei oder drei Leute verstehen die Besonderheiten wirklich. Wenn eine davon in Urlaub geht, warten Projekte. Das Schlüsselwissen sitzt in Köpfen statt im System.
Signal 3
Strategie-Bremse
Bei jeder neuen Idee lautet die erste Frage „Könnte unser System das?“, und die Antwort regelmäßig „schwierig”. Dann gibt die Software die Strategie vor.
Einzeln rechtfertigt keines dieser Signale, ein etabliertes System über den Haufen zu werfen. Treten sie zusammen auf, und soll das Unternehmen wachsen, sieht das anders aus.
Wie so eine Ablösung wirklich abläuft
Mit dem Satz “wir lösen jetzt ab” sind wir vorsichtig. In unseren Projekten hat sich ein Vorgehen bewährt, das mit dem Big-Bang-Austausch wenig zu tun hat:
Phase 1
Discovery
Die tatsächlichen Kernprozesse aufnehmen, nicht die Systemlandschaft. Was muss das Unternehmen können, unabhängig von den 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.
Weniger spektakulär als ein Komplettaustausch, dafür risikoärmer. Für den Mittelstand ist es meist der einzig gangbare Weg, weil das Tagesgeschäft weiterlaufen muss. Wie wir eine Ablösung konkret angehen, steht auf der Seite Standardsoftware ablösen.
Wann Standardsoftware die richtige Wahl bleibt
In drei Konstellationen raten wir aktiv vom Eigenbau ab:
Branchenüblicher Kernprozess. Ein ausgereiftes Produkt bildet ihn gut ab, oft besser als eine Neuentwicklung.
Prozesse nicht als USP gewollt. Wenn Abläufe kein Wettbewerbsvorteil sein sollen, müssen sie auch nicht individuell sein.
Randthema statt Wertschöpfungskern. Das System sitzt an der Peripherie. Dort reicht Standard.
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.
