ERP-Konnektor oder Middleware: Welche Anbindung passt?

Wann reicht ein direkter ERP-Konnektor?

Wenn das konkrete Systempaar Ihre notwendigen Geschäftsfälle abdeckt und der Betrieb geklärt ist. Prüfen Sie die tatsächliche Unterstützung statt nur den Produktnamen.

Beschreiben Sie zunächst die Kette vom Artikel über Bestellung und Reservierung bis zu Versand und Retoure. Markieren Sie die Übergaben und die dort nötigen Regeln. So erkennen Sie, ob vor allem eine Standardverbindung fehlt oder mehrere Systeme gemeinsam gesteuert werden müssen.

Verwenden Sie dieselben Fälle für jedes Angebot. Ein Konnektor mit gut abgedecktem Standardprozess kann ausreichend sein. Eine zusätzliche Plattform bringt dann Nutzen, wenn ihre Regeln, Überwachung oder weiteren Anschlüsse tatsächlich gebraucht und betreut werden.

Wo sollten Regeln und Datenumwandlungen liegen?

Ordnen Sie Zuordnungen und Statusregeln einem dokumentierten Verantwortlichen zu. Die technische Zwischenstation ersetzt keine fachliche Datenhoheit.

Prüfen Sie, wo Zuordnungen, Statusübersetzungen und fachliche Regeln liegen. Bei einer direkten Verbindung können sie im Konnektor stecken; bei einer Middleware häufig in deren Konfiguration. Entscheidend ist, wer sie versteht, ändern darf und nach einer Änderung abnimmt.

Vermeiden Sie verdeckte Mehrfachverantwortung. Wenn Shop, ERP und Middleware denselben Preis oder Bestand unabhängig verändern, benötigen Sie klare Konfliktregeln. Das führende System sollte je Datenbereich benannt werden, unabhängig davon, über welchen technischen Weg die Daten reisen.

Fragen Sie nach besonderen Datenformen wie Sets, Varianten und Teilmengen. Eine Feldzuordnung genügt nicht, wenn eine fachliche Aktion mehrere Datensätze verändern muss. Lassen Sie darstellen, wann ein Vorgang vollständig ist und was bei einem Abbruch dazwischen geschieht.

Wie vergleicht man die Fehlerbearbeitung?

Lassen Sie einen fehlerhaften und einen fehlenden Vorgang zeigen. Prüfen Sie gezieltes Fortsetzen, Schutz vor Doppelverarbeitung und den fachlichen Abgleich.

Lassen Sie einen bewusst fehlerhaften Auftrag vorführen. Ihr Team sollte erkennen können, welcher Vorgang betroffen ist, warum er nicht verarbeitet wurde und welche Korrektur möglich ist. Ein Dashboard voller grüner Verbindungssymbole sagt darüber wenig aus.

Prüfen Sie gezielte Wiederholung und Schutz vor Doppelverarbeitung. Eine erneute Zustellung muss denselben Geschäftsvorgang wiedererkennen. Wenn mehrere Schritte betroffen sind, braucht es einen nachvollziehbaren Stand und einen kontrollierten Weg zum Fortsetzen statt pauschalem Neustart.

Ereignisbasierte Systeme wie Shopify zeigen, warum zusätzlich ein fachlicher Abgleich nötig sein kann. Eine ausgebliebene Meldung muss auffallen, obwohl kein sichtbarer Fehler entstanden ist. Fragen Sie deshalb sowohl nach fehlerhaften Vorgängen als auch nach fehlenden Vorgängen.

Beleg: Shopify: Webhooks

Welche Kosten gehören zum Middleware-Vergleich?

Berücksichtigen Sie Einrichtung, Lizenz, Betreuung, Entwicklung und typische Änderungen. Rechnen Sie dieselben Mengen und denselben benötigten Umfang.

Erfassen Sie Einrichtung, laufende Lizenz, betreuten Betrieb und zusätzliche Entwicklung. Halten Sie fest, ob nach Verbindungen, Vorgängen oder einem anderen Maß abgerechnet wird. Verwenden Sie Ihren normalen Monat und eine Lastspitze als gemeinsame Vergleichsgrundlage.

Planen Sie einen typischen Änderungsfall: ein weiteres Lager, eine neue Statusregel oder ein zusätzlicher Verkaufskanal. Wer setzt die Änderung um, welche Tests sind nötig und was bleibt dokumentiert? Die Antwort zeigt oft mehr über die spätere Zusammenarbeit als eine allgemeine Skalierungszusage.

Prüfen Sie den Export von Konfiguration und Zuordnungen. Selbst wenn eine technische Plattform weiter genutzt wird, sollte Ihr Team die tatsächlich geltenden Regeln nachvollziehen können. Verlassen Sie sich nicht ausschließlich auf die Kenntnisse einer einzelnen betreuenden Person.

Wie wird die Anbindungsentscheidung belastbar?

Bewerten Sie Mussfälle als Standard, Konfiguration, Entwicklung oder Lücke. Beziehen Sie die Personen ein, die Fehler und Änderungen später tatsächlich bearbeiten.

Erstellen Sie eine Abdeckungsliste Ihrer Fälle und kennzeichnen Sie Standardfunktion, Konfiguration, Entwicklung und Lücke. Gewichten Sie notwendige Betriebsfälle höher als eine lange Liste ungenutzter Anschlüsse. Eine nicht erfüllte Mussanforderung sollte sichtbar bleiben.

Nehmen Sie den späteren Betreiber in die Entscheidung auf. Der Anschluss muss zu dessen Zugriffsrechten und verfügbaren Kenntnissen passen. Eine komfortable Entwicklungsoberfläche ist nicht automatisch eine verständliche Arbeitsansicht für das Shopteam.

Dokumentieren Sie den Grund für Ihre Wahl zusammen mit Annahmen und bekannten Grenzen. Bei einer späteren Erweiterung können Sie so prüfen, ob die ursprüngliche Architektur noch passt. Eine universell beste Anbindungsart gibt es für unterschiedliche Prozesse nicht.