ERP-Modernisierung und SAP-ECC-Ausstieg: die Technik rund um die Migration, die niemand eingeplant hat

In jeder ERP-Migration stecken zwei Projekte. Das eine steht im Plan: das neue System, das Prozessdesign, der Systemintegrator. Das andere taucht im vierten Monat auf, wenn jemand die Schnittstellen zählt.

Dieses zweite Projekt ist unseres. Die achtzig individuellen Schnittstellen, die Auswertungen, auf die sich das Rechnungswesen verlässt und für die sich niemand zuständig fühlt, die Lagerterminals, die an einem Datenbank-View hängen, das Kundenportal, das direkt aus den alten Tabellen liest, und zwanzig Jahre Daten, die im neuen System in einer Form ankommen müssen, die es akzeptiert. Das steht selten im ursprünglichen Umfang und bestimmt häufig den Termin.

Warum das jetzt im Kalender steht

Die Mainstream-Wartung für SAP ECC 6.0 endet am 31. Dezember 2027. Mit erweiterter Wartung kommt ein Unternehmen bis Ende 2030, gegen Aufpreis und mit eingeschränktem Umfang. Ein großer Teil der Installationsbasis hat noch nicht begonnen, Migrationen dauern üblicherweise achtzehn bis sechsunddreißig Monate, und die Kapazitäten der Partner und Hyperscaler dafür werden gerade verplant.

Derselbe Druck besteht außerhalb der SAP-Welt. Oracle-EBS-Kunden haben ihren eigenen Support-Horizont, Installationen von Dynamics AX und NAV werden Richtung Business Central und Dynamics 365 geschoben, und eine lange Reihe von Unternehmen betreibt ein ERP, das vor einem Jahrzehnt von Menschen stark angepasst wurde, die das Haus längst verlassen haben.

Wohin die Reise auch geht, das Problem hat immer dieselbe Gestalt: Das ERP ist keine Insel, und was daran hängt, ist in der Regel undokumentiert.

Was wir tun

Schnittstellen erfassen und inventarisieren

Bevor irgendetwas geplant werden kann, muss jemand feststellen, was tatsächlich mit dem ERP spricht. Das machen wir empirisch (über Datenbankprotokolle, Netzwerkverkehr, eingeplante Jobs, die Konfiguration der Integrationsmiddleware und den Quellcode), und nicht, indem wir einen Fragebogen herumschicken und hoffen.

Ergebnis ist eine Inventur jeder Schnittstelle mit Richtung, Protokoll, Frequenz, Datenvolumen, fachlichem Verantwortlichen, sofern sich einer finden lässt, und einer Einschätzung, ob sie neu gebaut, abgeschaltet oder angepasst werden kann. Kunden finden regelmäßig zwei- bis fünfmal so viele Schnittstellen wie erwartet, und ein nennenswerter Teil davon bedient am Ende gar nichts.

Die Integrationsschicht neu bauen

Wir bauen die Schnittstellen neu, die überleben müssen, und zwar vorzugsweise gegen eine Abstraktion statt direkt gegen das neue System. Eine Integrationsschicht zwischen Ihren Satellitensystemen und dem ERP sorgt dafür, dass die nächste Migration (und es wird eine geben) diese Übung nicht wiederholt. Außerdem können Sie Anwendungen dann in Wellen umziehen statt an einem einzigen Cutover-Wochenende.

Die Arbeit reicht von IDoc- und BAPI-Schnittstellen über OData-Dienste und SOAP-Endpunkte aus einer früheren Epoche bis zu Flatfile- und SFTP-Austausch, der immer noch die Hälfte des europäischen B2B-Geschäfts trägt, dazu Message Queues und moderne REST-APIs auf der neuen Seite.

Datenmigration als Entwicklungsaufgabe

Extraktion, Bereinigung, Transformation, Laden und (der meist unterschätzte Teil) Abstimmung. Wir bauen die Migration als wiederholbaren Code, nicht als einmaliges Skript, damit sie dutzendfach gegen zunehmend saubere Daten laufen kann und die Ergebnisse jedes Mal automatisch verglichen werden.

An der Abstimmung entscheidet sich die Glaubwürdigkeit. Das Rechnungswesen gibt eine Migration nicht frei, weil der Ladelauf durchgelaufen ist; es gibt sie frei, weil Salden stimmen, Mengen stimmen und die verbleibenden Differenzen erklärt und schriftlich akzeptiert sind.

Eigenentwicklungen, die das ERP überleben

Die meisten Unternehmen haben Anwendungen rund um das alte ERP, die etwas abbilden, was das ERP nicht konnte: einen Konfigurator, ein Preiswerkzeug, ein Terminal in der Fertigung, ein Kundenportal, eine Planungstabelle, die irgendwann tragend geworden ist. Manches davon sollte in der Standardfunktionalität des neuen Systems aufgehen. Manches ist echter Wettbewerbsvorteil und sollte ordentlich als eigenständige Anwendung neu gebaut werden, nicht länger verschweißt mit einem Datenbankschema, das sich gerade ändert.

Wir helfen Ihnen, beides auseinanderzuhalten, und bauen dann das, was sich zu behalten lohnt.

Reporting und die Schatten-Datenlandschaft

Um jedes langlebige ERP wächst eine Schicht aus Auswertungen, Extrakten und Tabellen außerhalb des Systems. Sie brechen beim Cutover laut zusammen und stehen fast nie im Plan. Wir inventarisieren sie, bestimmen die, auf denen das Geschäft wirklich läuft, und bauen sie gegen das neue Datenmodell neu oder gegen eine Reporting-Schicht, die sie davon abschirmt.

Stilllegung und Datenaufbewahrung

Im Altsystem stehen Aufzeichnungen, die Sie nach dem Abschalten noch Jahre aufbewahren müssen. ECC ein Jahrzehnt lang im Lesezugriff weiterlaufen zu lassen, ist eine teure Art, eine Aufbewahrungspflicht zu erfüllen. Wir bauen die Extraktion in ein zugängliches Archiv, mit den Such- und Exportwegen, nach denen Prüfer und Finanzverwaltung tatsächlich fragen, damit das alte System ausgehen kann.

Was wir nicht tun

Wir sind keine SAP-Fachberatung. Wir customizen kein FI/CO, wir entwerfen keine Prozessvorlagen, und wir sind nicht der Partner, der das S/4HANA-Programm führt. Das sind Spezialistenrollen, und dafür sollten Sie Spezialisten holen.

Wir sind das Entwicklungsteam, das neben diesem Partner an allem arbeitet, was das ERP berührt, was das ERP-Programm selbst aber nicht abdeckt. In der Praxis werden wir entweder direkt vom Kunden beauftragt, um dessen Seite des Programms abzusichern, oder als Subunternehmer des Systemintegrators, der es führt.

Wenn Sie jemanden suchen, der die gesamte S/4HANA-Konversion verantwortet, sagen wir Ihnen, dass wir das nicht sind, und zwar lieber im ersten Gespräch als im dritten.

Wo wir arbeiten

Neben einem S/4HANA-Programm: Neubau der Schnittstellen, Datenmigration, Arbeit an den Satellitensystemen und Stilllegung der Altlandschaft.

Bei Migrationen weg von SAP: zu Odoo, Dynamics 365 Business Central, ERPNext, Netsuite oder einem branchenspezifischen System; am häufigsten im Mittelstand, für den S/4HANA unverhältnismäßig ist. Hier machen Schnittstellen und Daten den Großteil des Projekts aus.

In Oracle-, Dynamics-AX/NAV- und Infor-Landschaften, die unter demselben Lebenszyklusdruck stehen, nur mit weniger Aufmerksamkeit.

Bei Unternehmen, die gar nicht migrieren und sich entschieden haben, vorerst zu bleiben, aber die umliegenden Systeme modernisieren, die Schnittstellen wartbar machen und das Risiko in der Zwischenzeit senken wollen.

Ablauf eines Projekts

Discovery, drei bis sechs Wochen. Schnittstelleninventur, Bewertung der Datenqualität, Sichtung der Satellitensysteme und ein schriftlicher Bericht darüber, wie die umgebende Landschaft tatsächlich aussieht. Das gibt es bewusst auch als eigenständiges Projekt: mehrere Kunden haben damit Umfang und Preis eines Integratorenangebots neu verhandelt, was die Kosten mehr als eingespielt hat.

Umsetzung, parallel zum Hauptprogramm: Integrationsschicht, Migrationsstrecke, Neubau von Anwendungen, nach Ihrem Zeitplan und auf Ihren Cutover-Termin hin.

Cutover-Begleitung, einschließlich der Generalproben, der Abstimmungsläufe und der Hypercare-Phase, in der die Schnittstellen, die im Test nie ganz durchgespielt wurden, endlich beansprucht werden.

Stilllegung, sobald das neue System stabil läuft und das Archiv abgenommen ist.

Technik

Java, .NET, Python, Node.js und PHP auf der Anwendungsseite; SAP-Schnittstellentechnologien einschließlich IDoc, BAPI, RFC und OData; Middleware wie MuleSoft, Apache Camel, Kafka und Azure Integration Services; SQL Server, Oracle, DB2, HANA und PostgreSQL; AWS und Azure. Wo die bestehende Landschaft auf Älterem läuft (Delphi, VB6, PowerBuilder, COBOL neben dem ERP), ist das für uns vertrautes Gelände und keine Überraschung.

Häufige Fragen

Wann genau endet der Support für SAP ECC?

Die Mainstream-Wartung für SAP ECC 6.0 endet am 31. Dezember 2027. Erweiterte Wartung ist gegen Aufpreis und mit eingeschränktem Umfang bis Ende 2030 erhältlich. Klären Sie die Einzelheiten für Ihr Enhancement Package und Ihren Vertrag direkt mit SAP, denn die Konditionen unterscheiden sich.

Wir haben bereits einen Systemintegrator beauftragt. Wo passen Sie hinein?

Daneben. Der Integrator verantwortet die ERP-Konversion, wir verantworten die Landschaft drumherum: Schnittstellen, Datentechnik, Satellitensysteme, Reporting und Stilllegung. Diese Aufteilung ist üblich, sie hält den Integrator bei dem System, auf das er spezialisiert ist, und sie sorgt dafür, dass jemand für die Teile zuständig ist, die sonst zwischen zwei Verträge fallen.

Ist ein vollständiger Ausstieg aus SAP realistisch?

Für manche Unternehmen ja. Es hängt davon ab, wie viel von dem, was Sie tun, Standard ist, wie viel in Anpassungen steckt und ob eine kleinere Plattform Ihr Volumen und Ihre regulatorischen Anforderungen tragen kann. Für mittelständische Hersteller und Distributoren ist es eine echte Option, für komplexe multinationale Konzerne eine schlechte. Die Discovery-Phase liefert Ihnen die Belege für die Entscheidung statt der Argumente.

Wie lange dauert die Schnittstelleninventur?

Für die meisten mittelständischen Landschaften drei bis sechs Wochen. Begrenzt wird sie vor allem durch den Zugang: wie schnell wir an Logs, Quellcode, Middleware-Konfiguration und an die Menschen kommen, die sich erinnern, warum es etwas gibt.

Können Sie das Altsystem nach dem Abschalten für Prüfungen verfügbar halten?

Ja. Wir bauen die Extraktion in ein abfragbares Archiv, mit der Aufbewahrungsfrist sowie den Such- und Exportmöglichkeiten, die Ihre Prüfer und die Finanzverwaltung verlangen. Das ist in der Regel deutlich günstiger, als ein lizenziertes ERP ein Jahrzehnt lang im Lesezugriff weiterzubetreiben.

Was, wenn wir vorerst nicht migrieren?

Das ist eine legitime Entscheidung, zumal die erweiterte Wartung bis 2030 verfügbar ist. Die Arbeit besteht dann darin, in der Zwischenzeit Risiko abzubauen: Schnittstellen dokumentieren und stabilisieren, abschalten, was niemand nutzt, und die Anwendungen rund um das ERP modernisieren, damit die umgebende Landschaft beim späteren Umzug nicht zum Hindernis wird.

Erste Schritte

Sagen Sie uns, was Sie betreiben, wo Sie in der Entscheidung stehen und ob bereits ein Integrator beauftragt ist. Wir sagen Ihnen, was die umgebende Landschaft Sie voraussichtlich kosten wird und wo wir anfangen würden.

Vereinbaren Sie ein Gespräch zur Schnittstellen- und Datenerhebung.

Weitere Leistungen

Wartung von Altsystemen: für die Systeme, die bleiben, wo sie sind
E-Rechnung Schnittstellen: die Pflicht, die häufig mitten in der Migration eintrifft
Personalverstärkung & Outsourcing: Entwickler, eingebunden für die Dauer des Programms