ERP-Migration ohne Schnittstellenchaos: Integration Layer zuerst

Wer das ERP wechselt oder viele Lieferanten anbindet, darf die Schnittstellen nicht im ERP-Kern lassen. Sonst bauen Sie dieselben Anbindungen zweimal – und der laufende Datenaustausch wird im Cutover zum Risiko.

Wie Sie Systeme verbinden, welche Wege sich eignen und woran Sie Kosten messen, steht im Leitfaden ERP-Integration für KMU. Dieser Artikel geht einen Schritt weiter. Er beantwortet die Architekturfrage vor dem Wechsel: Wohin gehören die Schnittstellen, damit der Kern stabil bleibt?

Die Antwort ist ein Integration Layer ausserhalb des ERP. Middleware as a Service zieht diese Schicht vor dem Systemwechsel ein. Lieferanten, Carrier und Handelspartner merken den Wechsel nicht. Das ERP bleibt das System für Aufträge, Bestände und Finanzen – nicht die Verteilerzentrale für jedes Mapping.

Genau das suchen Inhaber und Geschäftsführungen, die keine zweite IT-Grossbaustelle im Haus wollen. Und genau das suchen IT-Leitungen, die den Kern sauber halten wollen, während das Partnernetz weiterläuft.

Middleware as a Service hält die Verbindungen ausserhalb des ERP

Middleware as a Service ist die Integrationsschicht zwischen Ihrem ERP und allen angebundenen Systemen – geplant, betrieben und überwacht als laufender Service.

Drei Modelle stehen zur Wahl. Sie unterscheiden sich nicht in der ersten Verbindung. Sie unterscheiden sich, sobald Systeme, Partner oder das ERP selbst wechseln.

• Punkt-zu-Punkt verbindet zwei Systeme direkt. Das ist schnell für einen klaren 1:1-Fall. Jede weitere Anwendung braucht eine neue Leitung. Die Logik sitzt verteilt. Niemand hat die Übersicht, wenn eine Datei hängt.
• Ein klassisches Integrationsprojekt baut Mappings und übergibt sie. Danach liegt der Betrieb bei Ihnen. Neue Lieferanten, Formatänderungen und Fehlerfälle treffen wieder dasselbe interne Team.
• Middleware as a Service baut dieselbe Schicht – und behält sie im Betrieb. Monitoring, Fehlerbehandlung und das Onboarding neuer Partner bleiben an einer Stelle. iPaaS bezeichnet die Plattformkategorie: eine Integrationsplattform als Service. Middleware as a Service meint Plattform plus laufenden Betrieb.

Bei uns lizenzieren Sie die Lobster Data Platform direkt bei Lobster. Wir übernehmen Architektur, Profile, Mappings und den Managed Service.

Der Unterschied zeigt sich nicht im Kick-off. Er zeigt sich in Monat zwölf: ein neuer Carrier, ein geändertes IDoc, ein zweites Lager. Im Projektmodell schreiben Sie ein Ticket und warten auf Kapazität. Im Service-Modell gehört diese Arbeit zum Betrieb.

Jede direkte Schnittstelle im ERP macht das nächste Update zum Risiko

Jede direkte Schnittstelle im ERP erhöht den Wartungsaufwand und macht das nächste Update zum Risiko.

Das ERP führt Aufträge, Bestände und Buchungen. Sobald es auch noch Formate übersetzt, Partnerprotokolle spricht und Fehler von Carrier-Dateien abfängt, wird jeder Release zur Probe. Eine Feldänderung im neuen Cloud-ERP bricht nicht eine Verbindung. Sie bricht viele.

Punkt-zu-Punkt wächst nicht linear. Die Zahl der Verbindungen folgt der Formel n(n−1)/2. Drei Systeme brauchen drei Leitungen. Fünf Systeme brauchen zehn. Acht Systeme brauchen 28. Jede Leitung hat eigenes Mapping, eigene Tests und eigene Zuständigkeit.

Die Faustregel aus dem Integrationsleitfaden bleibt gültig: Ab drei Systemen lohnt sich in der Regel eine Middleware. Sie gilt noch schärfer, wenn ein ERP-Wechsel ansteht oder das Lieferantennetz wächst. Dann reicht die Systemzahl allein nicht als Mass. Entscheidend ist, ob der Kern jede Partneränderung mittragen soll.

Ein Wechsel in die Cloud, ein Versionssprung oder ein zweites ERP am Standort ändert an dieser Logik nichts. Ob SAP Cloud, Microsoft Dynamics 365 oder ein anderes System: Die Partner sprechen weiter EDIFACT, VDA, IDoc, XML oder JSON. Das neue ERP spricht oft anders. Ohne Layer übersetzen Sie dasselbe Netz ein zweites Mal.

Dazu kommt die Zuständigkeit. Hängt die Logik im ERP, teilen sich Fachbereich, ERP-Partner und interne IT jeden Fehler. Hängt sie im Layer, sehen Sie Mapping, Protokoll und Zeitstempel an einer Stelle. Das verkürzt nicht nur die Analyse. Es schützt den Kern vor Schnellfixes, die niemand mehr dokumentiert.

Ziehen Sie den Integration Layer vor dem Cutover ein

Ziehen Sie den Integration Layer vor dem Cutover ein. Dann bleibt der Datenaustausch stehen, während das ERP wechselt.

Viele Migrationsprojekte behandeln Schnittstellen als Restarbeit in der Go-Live-Woche. Das ist der teure Weg. Lieferanten schicken weiter Bestellungen und Lieferavise. Carrier melden Status. Der Shop oder das WMS erwartet Bestände. Wenn diese Flüsse erst mit dem neuen ERP neu gebaut werden, steht der Betrieb am Cutover-Tag auf zwei Baustellen.

Der bessere Ablauf trennt die Fragen. Zuerst steht der Layer. Danach wechselt das ERP. Partner-Endpunkte bleiben gleich.

1. Bestandsaufnahme: Welche Verbindungen sind kritisch – Lieferanten, Carrier, WMS, Shop, Finance? Welche Formate, welche Taktung, wer besitzt den Datensatz?
2. Layer aufbauen und bestehende Flüsse darauf umlegen. Das ERP hängt nur noch an einer Verbindung.
3. Parallelbetrieb: Alt-ERP und neues ERP laufen über denselben Layer, bis die Daten stimmen.
4. Cutover nur der ERP-Anbindung. Partner senden und empfangen wie zuvor.
5. Stabilisieren und den Layer weiterbetreiben. Neue Partner docken dort an, nicht im Kern.

Die Bestandsaufnahme entscheidet über den Scope. Listen Sie nicht nur Systeme. Listen Sie Belege: Bestellung, Auftragsbestätigung, Lieferavis, Rechnung, Bestandsbewegung, Sendungsstatus. Notieren Sie Richtung, Takt und was passiert, wenn eine Datei fehlt. Was geschäftskritisch ist, kommt zuerst auf den Layer. Der Rest folgt, ohne den Cutover zu blockieren.

Im Parallelbetrieb prüfen Sie denselben Beleg auf beiden Seiten. Stimmen Menge, Partnernummer und Zeitfenster? Weicht ein Feld ab, korrigieren Sie das Mapping im Layer – nicht die Prozesse im neuen ERP. Erst wenn die Stichprobe über mehrere Tage hält, wechseln Sie die ERP-Anbindung.

Was Lieferanten merken, entscheidet über das Risiko. Dieselbe Adresse. Dasselbe Format. Derselbe Rhythmus. Der Wechsel bleibt intern. Sie prüfen das vor dem Cutover, nicht danach.

Ein Satz zur Marktlage, nicht zum Projektplan: Die Mainstream-Wartung von SAP Business Suite 7 bzw. ECC endet am 31. Dezember 2027. Wer noch wechselt, sollte die Schnittstellenfrage nicht hinter die Lizenzfrage schieben. Dasselbe gilt für jeden anderen ERP-Wechsel ohne Stichtag.

Neue Lieferanten docken an die Middleware, nicht an das ERP

Neue Lieferanten und Carrier docken an die Middleware an, nicht an das ERP.

Ein wachsendes Partnernetz ist der häufigste Grund, warum ein eigentlich stabiles ERP unruhig wird. Jeder neue Lieferant bringt ein Format, ein Protokoll und eine Testphase. Liegt diese Arbeit im ERP, wächst das Risiko mit jeder Anbindung. Liegt sie im Layer, bleibt der Kern unverändert.

Onboarding folgt einem festen Ablauf. Sie klären Belege und Takt. Die Middleware übersetzt in das Format, das Ihr ERP erwartet. Tests laufen gegen den Layer. Der Go-Live ändert eine Verbindung – nicht das Kernsystem.

EDI und API gehören in dieselbe Schicht. Lieferanten senden oft EDIFACT oder VDA. Carrier und Shops sprechen REST, SFTP oder AS2. Das ERP soll das nicht unterscheiden müssen. Der Layer nimmt beide Welten auf und liefert dem Kern eine stabile Struktur.

Dasselbe gilt für interne Systeme neben dem ERP: WMS, TMS, PIM oder Webshop. Jedes davon darf am Layer hängen. Keines davon muss eine eigene Punkt-zu-Punkt-Leitung in den Kern ziehen, nur weil ein neues Modul live geht.

Für Geschäftsführung und Inhaber heisst das: Das Lieferantennetz kann wachsen, ohne dass jede neue Beziehung das ERP-Projekt verlängert. Monitoring liegt an einer Stelle. Wenn eine Datei scheitert, sehen Sie es im Layer – nicht erst in einer fehlenden Bestellung im ERP.

Das entlastet auch das ERP-Projekt selbst. Der Implementierungspartner baut den Kern. Der Layer hält den Markt. Beide Arbeiten laufen parallel, statt sich in derselben Woche zu blockieren. Für ein Familienunternehmen mit schlanker IT ist das oft der Unterschied zwischen einem geplanten Wechsel und einem Wechsel, der den Versand stoppt.

Eine direkte Leitung reicht für den 1:1-Fall – nicht für den Wechsel

Eine direkte Verbindung reicht für einen klaren 1:1-Fall. Ab mehreren Systemen, einem ERP-Wechsel oder einem Lieferantennetz gehört die Logik in den Layer.

Die Mischform ist üblich. Ein einzelner Batch-Export darf direkt bleiben. Sobald Partner, Formate und ein Systemwechsel zusammenkommen, zahlen Sie die direkte Architektur zweimal: einmal heute, einmal im neuen ERP.

Die Entscheidung ist keine Glaubensfrage. Zählen Sie Systeme, Partner und geplante Wechsel. Liegt mehr als ein Kriterium über dem 1:1-Fall, gehört die Logik in den Layer. Dann bleibt das ERP austauschbar. Die Partner bleiben erreichbar.

Sie lizenzieren Lobster. Wir betreiben den Layer.

Sie lizenzieren die Lobster Data Platform bei Lobster. Wir übernehmen Architektur, Mappings, Lieferanten-Onboarding und den laufenden Betrieb.

W4 ist seit 1994 am Markt. Als Schweizer Familienunternehmen und zertifizierter Lobster Integration Partner sowie Value Added Reseller betreiben wir die Plattform im Managed Service auf dem Lobster-Betriebsmodell. Im Alltag heisst das: Tausende Profile laufen unter Monitoring. Neue Lieferanten und Carrier werden strukturiert angebunden. Ihr Team braucht keine eigene Lobster-Bank im Haus.

Die Daten liegen auf Infrastruktur in der Schweiz oder in Deutschland. Standort und Compliance bleiben Ihre Entscheidung.

Im Discovery-Gespräch brauchen wir kein fertiges Lastenheft. Nützlich sind: die Liste der angebundenen Systeme, die kritischen Belege, der geplante ERP-Wechsel und wo der Betrieb heute hängt. Daraus entsteht eine Architekturskizze und ein realistischer erster Scope – nicht ein Versprechen über das gesamte Partnernetz am ersten Tag.

Was wir konkret tun und wie der Einstieg abläuft, steht auf der Leistungsseite Middleware as a Service. Der nächste Schritt ist kein Workshop-Marathon. Ein technisches Discovery-Gespräch klärt Ihre Landschaft, den geplanten ERP-Wechsel und den sinnvollen Scope für den Layer.

Häufige Fragen

Was ist Middleware as a Service?

Middleware as a Service ist die Integrationsschicht zwischen ERP und angebundenen Systemen, inklusive laufendem Betrieb. Sie erwerben die Lizenz der Lobster Data Platform bei Lobster. Wir planen die Architektur, bauen Profile und Mappings und überwachen die Datenflüsse.

Was passiert mit den Schnittstellen bei einem ERP-Wechsel?

Ohne Layer müssen Sie die Verbindungen im neuen ERP neu bauen. Mit einem Integration Layer bleibt der Partner-Endpunkt gleich. Sie ändern nur die Anbindung des ERP an den Layer. Lieferanten, Carrier und Handelspartner merken den Systemwechsel nicht.

Wann lohnt sich Middleware statt direkter ERP-Schnittstellen?

Eine direkte Leitung reicht für einen klaren 1:1-Fall. Ab drei Systemen, bei einem ERP-Wechsel oder bei einem wachsenden Lieferantennetz gehört die Logik in die Middleware. Dann wächst der Aufwand nicht mit jeder neuen Verbindung im Kern.

Wie binde ich Lieferanten an, ohne das ERP zu belasten?

Lieferanten docken an die Middleware an. Mapping, Tests und Go-Live laufen gegen den Layer. Das ERP empfängt eine stabile Struktur und bleibt von Format- und Protokollwechseln der Partner entkoppelt.

Brauchen wir eigene Lobster-Spezialisten?

Nicht zwingend. Wir übernehmen Mapping, Orchestrierung, Onboarding und Support. Wenn Ihr Team Anteile selbst steuern will, schulen wir genau diesen Teil. Der Betrieb muss nicht an einzelnen Personen im Haus hängen.

Wo liegen die Daten?

Auf Infrastruktur in der Schweiz oder in Deutschland. Sie behalten die Kontrolle über Standort und Compliance. Das ist Teil des Setups, nicht eine spätere Zusatzfrage.

Nächster Schritt: Layer klären, bevor das ERP wechselt

Schnittstellen gehören nicht in den ERP-Kern, wenn Sie das System wechseln oder viele Lieferanten anbinden. Der Integration Layer steht zuerst. Das ERP folgt.

Methoden, Kosten und die Regel «direkt oder Middleware» finden Sie im Leitfaden ERP-Integration für KMU. Wie der Layer vor einer ERP-Migration aufgebaut und betrieben wird, steht auf der Seite Middleware as a Service.

Schildern Sie uns die aktuelle Systemlandschaft und den geplanten Wechsel. Im technischen Discovery-Gespräch klären wir, ob Middleware as a Service passt und was der nächste Schritt ist.

Technisches Discovery-Gespräch anfragen →