Ihr Geschäft ausbauen

Ihr ERP anbinden

Produkte, Preise, Bestand, Kunden, Bestellungen: in der richtigen Richtung, im richtigen Takt, mit einem Besitzer pro Feld.

Ihr ERP führt das Unternehmen seit fünfzehn Jahren. Alle vertrauen ihm, alle arbeiten um seine Ecken herum, und niemand hat aufgeschrieben, was es besitzt. Jetzt braucht ein Commerce-Projekt von ihm Produkte, Preise und Bestand und will Bestellungen zurückgeben. Die ehrliche Zusammenfassung: Das ERP bestimmt den Zeitplan und entscheidet, ob das Projekt funktioniert. Diese Seite ist für das Unternehmen, das das zum ersten Mal macht: ein Betrieb, den der Innendienst trägt, ohne eigene Entwicklung, mit einem ERP-Partner auf Tagessatz.

Warum das schwerer ist, als es klingt

Die erste Überraschung: „Das ERP" ist kein System. Es ist ein ERP, plus ein Lagermodul, das jemand angeschraubt hat, plus ein CRM mit den echten Kontaktdaten, plus eine Konditionentabelle auf dem Laufwerk der Vertriebsleitung, plus eine Access-Datenbank mit Verpackungseinheiten, weil das ERP die nicht konnte. Jedes davon ist eine Quelle, und die letzten beiden finden Sie mitten im Projekt, durch jemanden, der annahm, Sie wüssten Bescheid.

Die zweite: Die zentrale Entscheidung ist nicht technisch. Sie lautet wer welches Feld ändern darf. Die meisten Felder existieren an zwei oder drei Stellen; die Frage ist, welches System schreiben darf. Zwei Systeme, die dasselbe Feld schreiben, sind der Fehler, der nie diagnostiziert wird: Beide Seiten arbeiten korrekt, und der Wert springt jede Nacht zurück. Schreiben Sie die Datenhoheit auf, Feld für Feld, bevor jemand irgendetwas verbindet. Das ist jetzt ein Nachmittag und später zwei Wochen Forensik.

Drittens: Der Takt wird pro Datenart entschieden. Ein Nachtlauf für alles ist die Standardeinstellung, die den Shop kaputt macht, weil die zwei Zahlen, an denen Kunden Sie messen, die zwei sind, die keinen Tag alt sein dürfen.

Fluss	Richtung	Takt, der funktioniert	Warum
Bestellungen	Shop → ERP	Sofort, mit Wiederholung	Dem Kunden wurde die Bestätigung schon angezeigt; das Versprechen ist gemacht
Bestand	ERP → Shop	Live-Abfrage oder Minuten	Eine Bestandszahl ist ein Versprechen. Das Versprechen von gestern ist keines
Preise	ERP → Shop	Live für Kundenkonditionen; Stapel für Listenpreise	Ein falscher Preis verliert den Kunden dauerhaft, nicht für eine Bestellung
Produkte	ERP oder PIM → Shop	Nächtlich reicht	Beschreibungen und Gewichte ändern sich nicht stündlich
Kundenstamm	ERP ↔ Shop	Nächtlich, eine Richtung, ausdrücklich entschieden	Das Feld, das am ehesten von beiden Seiten geschrieben wird, und das schlechteste dafür
Dokumente	ERP → Shop	Nächtlich	Rechnungen und Lieferscheine sind Self-Service, keine Echtzeit

Kaufen Sie die Anbindung, bauen Sie sie nicht. Handgeschriebene Middleware kostet beim Bau und bei jedem ERP-Release wieder, für immer, und am Ende wartet sie der eine Dienstleister, der sie versteht. Nutzen Sie die Konnektoren der Plattform, ihren Dateiaustausch und ihre Workflows, und heben Sie eigenen Code für die Ausnahmen auf, die Ihr Geschäft tatsächlich hat. Wenn Sie Code schreiben, um ein Feld von A nach B zu bewegen: anhalten und prüfen, ob eine Feldzuordnung das nicht schon tut.

Viertens: Ihr ERP wurde nicht dafür gebaut, von einem Shop gelesen zu werden. Rechnen Sie mit Artikelnummern mit führenden Nullen, die eine Tabellenkalkulation gefressen hat, mit Verkaufseinheiten, die von Basiseinheiten abweichen (Sie verkaufen den Karton mit 100, das ERP zählt Stück), mit Einheitencodes, die keinem Standard entsprechen, und mit Konditionentabellen, die mehr Ebenen haben, als sich jemand erinnert. Nichts davon ist exotisch. Alles davon kostet Tage.

Fünftens, eine Terminrealität: Ihr ERP-Partner hat eine Warteschlange und einen Tagessatz, und alles auf seiner Seite ist eine Anfrage, keine Aufgabe, die Sie steuern. Buchen Sie ihn früh, mit einer schriftlichen Spezifikation, und planen Sie keinen Go-live um einen Termin herum, den Sie nicht bekommen haben.

Und zuletzt das, was entscheidet, ob die Anbindung ihr erstes Jahr übersteht: Jemand muss sie nach dem Go-live verantworten. Schnittstellen gehen kaputt, und zwar lautlos. Wenn niemand benannt ist, merkt es zuerst ein Kunde.

Die Hebel

Aufschreiben, wem welches Feld gehört

So sieht es gut aus: eine Tabelle (Feld, besitzendes System, Richtung, Takt) über Produkte, Preise, Bestand, Kunden, Bestellungen und Dokumente. Jede Zeile hat genau einen Besitzer, und wo zwei Systeme schreiben wollen, wird das auf dem Papier gelöst statt durch die Schnittstelle.

Wovon es abhängt: davon, Vertrieb, Lager und Finanzbuchhaltung einmal in einen Raum zu bekommen. Sie werden sich widersprechen, und der Widerspruch ist das nützliche Ergebnis.

Einen Takt pro Datenart und einen Weg pro System wählen

So sieht es gut aus: Jeder Fluss hat einen festgelegten Takt und einen festgelegten Mechanismus (ein API-Aufruf, ein Webhook, ein geplanter Lauf oder eine Dateiablage für das ERP, das nur CSV spricht), gewählt nach dem Zweck der Daten statt danach, was am leichtesten zu bauen war.

Wovon es abhängt: davon zu wissen, was Ihr ERP bieten kann. Manche haben eine brauchbare API, manche einen nächtlichen Export und sonst nichts. Diese Einschränkung prägt den ganzen Entwurf und gehört in die erste Woche.

In einer Sandbox bauen, mit eingeschränkten Zugangsdaten

So sieht es gut aus: Der Integrator arbeitet gegen einen Tenant, den Sie kaputtmachen dürfen, mit Testdaten, die der Produktion ähneln, und einem API-Schlüssel, der auf die Flüsse beschränkt ist, die er baut. Nichts wird zum ersten Mal gegen echte Kundendaten getestet.

Wovon es abhängt: davon, die Sandbox bereitzustellen, bevor der Integrator anfängt, nicht wenn er fragt. Das ist die billigste Terminersparnis im Projekt.

Betreiben: überwachen, abgleichen, jemanden benennen

So sieht es gut aus: Für jeden Fluss sehen Sie den letzten erfolgreichen Lauf, ein Fehler alarmiert eine benannte Person, und ein wöchentlicher Abgleich vergleicht, was der Shop gesendet und das ERP empfangen hat.

Wovon es abhängt: davon, die Anbindung als betriebenen Dienst zu behandeln statt als abgeschlossenes Projekt. Das ist der Unterschied zwischen einer Verbindung, die hält, und einer, die verfällt, bis jemand sie neu baut.

Eine sinnvolle Reihenfolge

Vorab eine Unterscheidung: Das Erstladen der Produkte und der ersten Preisliste ist ein Import. 8.000 Artikel einmal aus einer Datei zu laden, ist eine Datenvorbereitung mit klarem Ende; lassen Sie daraus nicht Ihre erste Schnittstelle werden. Siehe Importdatei vorbereiten und Produkte massenhaft importieren.

Phase 1: Bestellungen raus. Die erste Schnittstelle, die Sie bauen, schreibt Bestellungen aus dem Shop ins ERP. Sie läuft in eine Richtung, sie hat einen eindeutigen Test (Bestellung aufgeben, dieselbe Bestellung im ERP finden, mit denselben Positionen, Einheiten und Nettowert), und sie beseitigt den manuellen Schritt mit den höchsten Kosten und der höchsten Fehlerquote. Alles andere lässt sich eine Weile von Hand pflegen; Bestellungen abtippen nicht. Voraussetzung: die Sandbox, abgestimmte Einheitenkonventionen und eine Entscheidung, was bei einem fehlgeschlagenen Schreibvorgang passiert: Warteschlange, Wiederholung und eine benannte Person, die es erfährt.

Phase 2: Bestand rein, dann Preise rein. Bestand zuerst: Es ist ein Lesevorgang, er ist übersichtlich, und es ist die Zahl, die entscheidet, ob Einkäufer dem Kanal vertrauen. Preise als Zweites, weil dieser Fluss die meiste Geschäftslogik trägt (Konditionsebenen, Staffeln, Gültigkeiten, kundenspezifische Einträge) und ein Fehler dort der teuerste ist, den es gibt. Beginnen Sie mit Preisen erst, wenn die Datenhoheitstabelle sagt, welche Konditionen das ERP besitzt und welche die Plattform halten darf. Voraussetzung: Phase 1 hat Verbindung, Zugangsdaten und Überwachung an einem Fluss belegt, den Sie Datensatz für Datensatz prüfen können.

Phase 3: Kundenstamm, Dokumente und der Rückweg. Der Kundenstamm kommt zuletzt, obwohl alle damit anfangen wollen: Die Kundennummern Ihres ERP den Organisationen und Kontakten in der Plattform zuzuordnen, ist eine Stammdatenmigration, mit Dubletten, toten Konten und geteilten Logins darin. Parallel dazu Rechnungen und Lieferscheine in den Self-Service und Versanddaten zurück zum Kunden. Voraussetzung: Phase 2, und jemand, der danach die Stammdatenpflege verantwortet.

Typische Fehler

Mit dem Kundenstamm anfangen. Er fühlt sich an wie das Fundament und ist eine Migration. Fangen Sie mit Bestellungen raus an.
Ein Nachtlauf für alles. Der billigste Entwurf, und er macht Bestand und Preise genau in den Momenten falsch, in denen sie zählen.
Zwei Systeme schreiben dasselbe Feld. Niemand diagnostiziert das. Es sieht aus wie ein Geist.
Eigene Middleware bauen. Sie kostet beim Bau und bei jedem ERP-Update wieder, und sie hängt an einer Person.
Den Go-live planen, bevor der ERP-Partner einen Termin gegeben hat. Seine Warteschlange bestimmt Ihr Datum.
Niemand verantwortet es nach dem Go-live. Schnittstellen fallen lautlos aus, und die erste Meldung kommt von einem Kunden, der schon beim Wettbewerber angerufen hat.

Woran Sie erkennen, dass es funktioniert

Anteil der Bestellungen, die das ERP erreichen, ohne dass ein Mensch sie anfasst. Die Kennzahl dieses Ziels, und die, auf der der Business Case ruht.
Zeit von Bestelleingang bis Bestellung im ERP. Achten Sie auf die Ausreißer statt auf den Durchschnitt; die langsamen tragen die Probleme.
Fehlgeschlagene Läufe pro Woche und Zeit bis zum Bemerken. Das Zweite zählt mehr. Wird es in Tagen gemessen, ist die Überwachung Dekoration.
Von Kunden gemeldete Preisabweichungen. Jede einzelne bedeutet, dass eine Konditionsebene nicht gelesen wird; siehe Häufige Preisprobleme.
Überverkäufe durch veralteten Bestand. Das direkte Maß dafür, ob der Bestandstakt stimmt.
Felder mit mehr als einem Schreiber. Ziel ist null, und die Zahl existiert nur, wenn Sie die Datenhoheitstabelle geschrieben haben.

Was Sie bauen

Sechs Flüsse zwischen ERP und Plattform, jeder mit einem Besitzer, einer Richtung und eigenem Takt. Bestellungen verlassen die Plattform im Moment der Aufgabe und kommen mit Wiederholungsmechanismus im ERP an; Bestand und Vertragspreise kommen oft genug herein, um vertrauenswürdig zu sein; Produkte, Kundenstamm und Dokumente kommen nächtlich. Jeder Fluss ist ein Workflow oder ein Importprofil im Integration Studio, mit sichtbarer Laufhistorie und einer benannten Person, die bei Fehlern alarmiert wird.

flowchart LR
  ERP["Ihr ERP, WMS, CRM"]
  SFTP["SFTP-Ablage für Systeme, die nur CSV können"]
  subgraph IS["Integration Studio"]
    WF["Workflows und Importprofile"]
    EV["Ereignisse und Webhooks"]
    RUN["Läufe und Alarme"]
  end
  subgraph CS["Commerce Studio"]
    P["Produkte"]
    PR["Preise: Listen und Einträge"]
    INV["Bestand: Bestände"]
    C["Kunden: Organisationen, Kontakte"]
    O["Bestellungen"]
  end
  subgraph XS["Experience Studio"]
    SF["Storefront"]
    DOC["Dokumente und Messaging"]
  end
  ERP -- "Artikel, nächtlich" --> WF
  ERP -- "Bestand, Minuten" --> WF
  ERP -- "Konditionen, stündlich bis täglich" --> WF
  ERP -- "Kundenstamm, nächtlich" --> WF
  ERP -- "Rechnungen, Lieferscheine" --> WF
  SFTP --> WF
  WF --> P
  WF --> PR
  WF --> INV
  WF --> C
  WF --> DOC
  SF -- "Bestellung aufgegeben" --> O
  O -- "Ereignis" --> EV
  EV -- "Bestellung, sofort mit Wiederholung" --> WF
  WF -- "Bestellung" --> ERP
  WF --> RUN

Was Sie brauchen

Eine Liste jedes Quellsystems, einschließlich der Tabellen und Nebendatenbanken — Datenhoheit festlegen
Die Datenhoheitstabelle: Feld, besitzendes System, Richtung, Takt — Integrationsmuster
Abgestimmte Konventionen für Artikelnummern, Kundennummern, Verkaufseinheiten und Einheitencodes — Feldzuordnung
Eine Aussage, was Ihr ERP bieten kann: API, Export, Dateiablage — Die Schnittstellen der Plattform auf einer Karte
Einen Sandbox-Tenant mit Testdaten und einem eingeschränkten API-Schlüssel, bevor der Integrator anfängt — Eine Sandbox einrichten
Produkte und die erste Preisliste einmal aus einer Datei geladen, als Import — Produkte massenhaft importieren
Einen gebuchten Termin bei Ihrem ERP-Partner, gegen eine schriftliche Spezifikation — Ein System anbinden
Eine benannte Person, die die Anbindung nach dem Go-live verantwortet — Synchronisationen überwachen

So bauen Sie es

Listen Sie jedes Quellsystem und schreiben Sie die Datenhoheitstabelle, Feld für Feld — Datenhoheit festlegen
Stimmen Sie Artikelnummernformate, Kundennummernabgleich, Verkaufseinheiten und Einheitencodes mit der ERP-Betreuung ab — Feldzuordnung
Wählen Sie den Weg pro Fluss nach dem, was das ERP bietet: API, Webhook, Zeitplan oder Dateiablage — Integrationsmuster
Stellen Sie die Sandbox bereit und legen Sie einen API-Schlüssel an, der auf den ersten Fluss beschränkt ist — Einen API-Schlüssel anlegen
Laden Sie Produkte und die erste Preisliste einmal aus einer vorbereiteten Datei — Importdatei vorbereiten
Hinterlegen Sie die ERP-Verbindung und ihre Zugangsdaten — Zugangsdaten
Bauen Sie den Workflow für Bestellungen raus: Ereignis Bestellung aufgegeben, Feldzuordnung, Schreiben ins ERP, Wiederholung, Alarm — Einen Workflow bauen
Testen Sie ihn: Bestellung in der Sandbox aufgeben, im ERP Position für Position wiederfinden — Eine Integration durchgängig testen
Bauen Sie den Bestandsfluss nach Zeitplan oder als Live-Abfrage und prüfen Sie ihn gegen das Lager — Bestandsgenauigkeit
Bauen Sie den Preisfluss: Listenpreise im Stapel, Vertragskonditionen als Preiseinträge pro Organisation — Preise massenhaft importieren
Beobachten Sie die Laufliste und leiten Sie Fehler an die benannte Person — Läufe
Ordnen Sie die ERP-Kundennummern Organisationen und Kontakten zu, eine Richtung, nächtlich — Organisationen
Holen Sie Rechnungen, Lieferscheine und Versanddaten für den Self-Service herüber — Mit dem ERP abgleichen
Führen Sie den wöchentlichen Abgleich durch und testen Sie nach jedem ERP-Release erneut — Häufige Synchronisationsfehler

Entscheidungen, die Sie treffen müssen

Entscheidung	Die Abwägung	Wohin die meisten Kunden gehen
API, Dateiaustausch oder Konnektor? Die API des ERP aufrufen, Dateien auf dem SFTP-Server der Plattform ablegen, oder einen fertigen Konnektor nutzen, wo es einen für Ihr ERP gibt.	Eine API liefert minutenalte Daten und braucht ein ERP, das eine hat. Dateien kann jedes ERP, und sie sind nie frischer als der Zeitplan. Ein Konnektor spart die Zuordnungsarbeit und bindet Sie an sein Feldmodell.	Dateien per SFTP für Produkte, Listenpreise und Dokumente; API oder Webhook für Bestellungen und Bestand; ein Konnektor überall dort, wo es einen für das eingesetzte ERP gibt. Der Weg wird pro Fluss entschieden, nie pro Projekt.
Wem gehört der Kundenstamm? Dem ERP, der Plattform, oder aufgeteilt.	Das ERP kennt Kundennummern, Zahlungsbedingungen und Kreditlimits und hat kein Modell für einzelne Personen. Die Plattform braucht Kontakte und Rollen, die das ERP nicht halten kann. Schreiben von beiden Seiten ist der Geisterfehler.	Das ERP besitzt die Organisation, ihre Nummer, Zahlungsbedingungen und Kreditlimit; die Plattform besitzt Kontakte, Rollen und die Freigabegrenze pro Kontakt. Der Fluss geht in eine Richtung, vom ERP zur Plattform, nächtlich. Neue, selbst registrierte Organisationen gehen als manueller oder geplanter Schritt zurück ins ERP, nie live in beide.
Wo werden Preise gerechnet? Die Plattform preist aus eigenen Listen, Konditionen werden als Preiseinträge synchronisiert, oder die Preisfindung des ERP wird beim Seitenaufbau aufgerufen.	Synchronisierte Einträge sind schnell und können Minuten bis einen Tag alt sein. Ein Live-Aufruf ist immer aktuell und macht die Seitengeschwindigkeit davon abhängig, dass das ERP läuft.	Konditionen in Preislisten und Preiseinträge synchronisiert, stündlich bis täglich, mit ereignisgesteuerter Aktualisierung bei Konditionsänderung. Der Live-Aufruf ins ERP bleibt den Fällen mit Konfiguration vorbehalten, in denen keine Liste die Antwort halten kann.
Was passiert, wenn das Schreiben einer Bestellung fehlschlägt? Wiederholen, bis es klappt, die Bestellung anhalten, oder an eine Person übergeben.	Stille Wiederholungen verbergen ein kaputtes ERP tagelang. Die Bestellung anzuhalten widerspricht der Bestätigung, die der Käufer schon hat.	Automatisch für einen begrenzten Zeitraum wiederholen, beim ersten Fehlschlag eine benannte Person alarmieren, und die Bestellung gegenüber dem Kunden durchgehend bestätigt lassen. Der Käufer sieht die Wiederholung nie.
Wer verantwortet die Anbindung nach dem Go-live? Der ERP-Partner, eine interne Kollegin, oder ein Plattform-Partner auf Retainer.	Der ERP-Partner kennt das ERP und nicht die Plattform. Eine interne Person kennt das Geschäft und ist eine Person. Ein Retainer kostet jeden Monat Geld.	Eine benannte interne Person, die täglich die Laufliste liest, plus den ERP-Partner auf Retainer für Releases. Der interne Name sorgt dafür, dass Fehler bemerkt werden; der Retainer dafür, dass sie behoben werden.