Was gehört in eine Exit-Strategie beim ERP?
Export, Verträge, Anpassungen und Betrieb vor dem Go-Live klären. Eine Exit-Strategie ist Risikovorsorge für Geschäftsführung und IT, nicht Misstrauen gegenüber dem Anbieter.
Eine Exit-Strategie beim ERP beantwortet eine einfache Frage: Was tun Sie, wenn Konditionen sich ändern, ein Modul eingestellt wird, der Support entfällt oder Sie den Betreiber wechseln wollen? Sie klingt für viele nach Misstrauen. In der Praxis ist sie normale Risikovorsorge. Wer erst beim Wechselwunsch klärt, verhandelt aus der Schwäche. Wer vorher prüft, behält Handlungsfähigkeit.
Geschäftsführung und IT sollten vor dem Go-Live die folgenden Punkte beantworten können. Nicht als Papierübung, sondern mit konkreten Nachweisen.
Warum eine Exit-Strategie vor dem Vertrag zählt
ERP-Systeme bündeln Aufträge, Bestände, Finanzen und oft Produktion über Jahre. Der Wechselaufwand steigt mit jedem undokumentierten Customizing und jeder proprietären Schnittstelle. Eine Exit-Strategie ist deshalb Teil der Anbieterbewertung, auf Augenhöhe mit Funktionsumfang und Preis. Sie schützt nicht nur vor dem Worst Case. Sie verbessert auch die Verhandlungsposition bei Laufzeiten, Preisen und Service Levels.
Vendor Lock-in entsteht oft genau dann, wenn Exit-Optionen ungeprüft bleiben. Die Strategie gehört also in die RFP und den Vertragsentwurf, nicht in die Nachsorge nach dem ersten Streit.
Was beim Datenexport geprüft werden muss
Export ist der Kern jeder Exit-Strategie. Fragen Sie konkret:
- Lassen sich Stammdaten und Bewegungsdaten vollständig und maschinenlesbar exportieren?
- Welche Formate stehen zur Verfügung, und reichen sie für eine Migration in ein anderes System?
- Gibt es Limits bei Volumen, Historie oder Belegarten?
Testen Sie mit einer Stichprobe: Artikel, Kund*innen, Aufträge, Buchungssätze, Lagerbewegungen. Ein PDF-Export einzelner Masken reicht nicht. Entscheidend ist, ob die Daten ohne den Anbieter weiterverarbeitet werden können. Dokumentieren Sie den Test und wiederholen Sie ihn nach größeren Releases.
Welche Vertragsklauseln Sie brauchen
Prüfen Sie vor Unterschrift:
- Datenportabilität und Übergabeformate bei Kündigung
- Kündigungsfristen und Mitwirkungspflichten des Anbieters
- Löschfristen und Nachweis der Löschung
- Rechte an Anpassungen, Skripten und Konfigurationen
- Zugang zu Backups und Wiederherstellungsmedien nach Vertragsende
Unklare Formulierungen zu „angemessener Unterstützung beim Exit“ sind riskant. Besser: konkrete Fristen, Formate und Verantwortlichkeiten. Juristische Prüfung im Einzelfall bleibt sinnvoll. Dieser Beitrag ersetzt sie nicht.
Wie Anpassungen und Betrieb wechselfähig bleiben
Viele Unternehmen stecken nicht am Kernprodukt fest, sondern an undokumentierten Erweiterungen. Metadaten, Regeln, Masken und Schnittstellen müssen so dokumentiert sein, dass ein anderes Team den Betrieb übernehmen kann. Fragen Sie:
- Liegt die Dokumentation bei Ihnen, nicht nur beim Implementierungspartner?
- Können Sie Anpassungen ohne Hersteller-Sonderrechte weiterführen?
- Sind Schnittstellen und Credentials inventarisiert?
Beim Betrieb gilt dasselbe: Backups und Wiederanlauf unabhängig vom Anbieter-Backup verifizieren. Ein Cloud-Snapshot beim Hosting-Partner reicht nicht, wenn Sie ihn im Ernstfall nicht selbst einspielen können.
Was offene ERP-Plattformen am Exit ändern
Offene Plattformen ersetzen die Exit-Prüfung nicht. Sie erleichtern sie: Quellcode, Daten und Erweiterbarkeit bleiben beim Unternehmen. Betrieb und Betreuung lassen sich wechseln, ohne dass die fachliche Logik im Blackbox-Format stecken bleibt. Mehr Kontext: Digitale Souveränität und Open Source ERP.
Nuclos steht unter der GNU AGPL 3.0. Kund*innen behalten Zugriff auf Quellcode und Daten. Das ist ein struktureller Vorteil für die Exit-Option, kein Freibrief, Export und Verträge ungelesen zu lassen.
Exit-Strategie gehört in jede ERP-Entscheidung. Wer sie vor dem Go-Live klärt, kauft sich Handlungsfreiheit für den Tag, an dem sie gebraucht wird.