Freitagnachmittag, kurzfristige Aktion auf drei Artikel. Jemand aus dem Marketing setzt die Preise im Shopify-Admin, dazu die Streichpreise, alles sauber. Montagmorgen stehen wieder die alten Preise da. Der Anruf kommt dann meistens mit dem Satz, die Schnittstelle habe etwas kaputt gemacht.
Hat sie nicht. Sie hat genau das getan, wofür sie gebaut wurde. Was fehlte, war die Verabredung darüber, wer welches Feld pflegt — und die Kenntnis dieser Verabredung bei den Leuten, die täglich im Backend arbeiten.
Die Frage lautet nicht, welches System führt
In Anbindungsprojekten wird oft nach dem führenden System gefragt, als gäbe es darauf eine Antwort. Gibt es nicht. Die Antwort steht pro Feld, nicht pro System. Ein Shopify-Shop mit angebundenem ERP hat drei Sorten Daten: solche, die das ERP schreibt und der Shop nur anzeigt; solche, die im Shop entstehen und ins ERP laufen; und solche, die der Shop allein verwaltet und die das ERP nie sehen wird.
Die dritte Gruppe wird unterschätzt. Wer nach der Anbindung glaubt, im Shopify-Backend sei nun alles gesperrt, richtet mehr Schaden an als jemand, der einzelne Preise überschreibt — weil dann Kollektionen, Landingpages und Navigation liegen bleiben, mit der Begründung, das mache jetzt das ERP.
Was das ERP schreibt
Der Artikelstamm. Konkret: Titel, Beschreibung, Hersteller beziehungsweise Vendor, Produkttyp, Varianten samt Artikelnummer und Barcode, Gewicht und Maße, Steuermerkmal, Preise und Streichpreise, Staffel- oder Kundengruppenpreise soweit Shopify sie abbildet, Bestand, Bilder in der Regel ebenfalls.
Bestand ist der Sonderfall, über den man früh sprechen muss. Shopify rechnet mit Standorten. Solange nur ein Lager existiert, ist das unauffällig. Sobald ein zweiter Standort dazukommt — Ladengeschäft, Dropshipping-Lieferant, ein Amazon-FBA-Bestand — muss geklärt sein, welche Standorte das ERP bespielt und welche Shopify selbst führt. Wir haben Installationen übernommen, in denen die Schnittstelle den Gesamtbestand auf einen Standort geschrieben hat, während im Laden am zweiten Standort verkauft wurde. Das fällt erst auf, wenn die erste Bestellung nicht lieferbar ist.
Auf der Rückseite schreibt das ERP außerdem in Bestellungen: Fulfillment mit Sendungsnummer und Dienstleister, Teillieferungen, Rückerstattungen, Stornos. Auch das gehört zum Artikelstammthema, weil es dasselbe Prinzip trägt — der Vorgang wird dort abgeschlossen, wo er verbucht wird.
Was im Shopify-Backend bleibt
Alles, was Vermarktung ist und keine Entsprechung im ERP hat. Manuelle Kollektionen und ihre Sortierung, Theme-Inhalte, Menüs, Seiten, Blogbeiträge, Rabattcodes und Aktionen im Shopify-Sinn, Bewertungen, Kundenkonten und deren Passwörter. Metafelder sind gemischt: technische Attribute kommen häufig aus dem ERP, redaktionelle Zusatztexte entstehen im Shop und dürfen dort bleiben.
SEO-Titel und Meta-Beschreibung sind die Stelle, an der wir am häufigsten diskutieren. Beides lässt sich aus dem ERP füllen, wenn dort ordentliche Felder existieren. In der Praxis existieren sie selten, also generiert die Schnittstelle sie aus dem Produkttitel — und überschreibt damit jede Handarbeit. Wenn im Shop redaktionell an SEO gearbeitet wird, muss die Schnittstelle diese beiden Felder auslassen. Das ist eine Zeile Konfiguration und ersparte uns rückblickend viel Ärger.
Automatische Kollektionen liegen dazwischen. Sie werden im Shop gepflegt, aber ihre Regeln greifen auf Felder zu, die das ERP schreibt — Tags, Produkttyp, Vendor. Wer im ERP die Tag-Logik ändert, leert unter Umständen eine Kollektion. Das ist kein Konflikt um Datenhoheit, sondern eine Abhängigkeit, die man kennen muss.
Die vier Stellen, an denen es trotzdem passiert
Erstens der Bulk-Editor. Er ist zu bequem, um ihn nicht zu benutzen. Dreißig Preise in einer Tabelle ändern dauert zwei Minuten, der Weg über das ERP mit Preisliste und Freigabe dauert länger. Rate, was gewählt wird, wenn Freitag eine Aktion startet.
Zweitens die Bestandskorrektur. Nach einer Inventur oder einem Retourenfund korrigiert jemand die Menge direkt in Shopify, weil sie dort sichtbar falsch ist. Die Korrektur hält bis zum nächsten Bestandslauf. Dann ist der alte Wert zurück, und die Vermutung lautet, die Schnittstelle habe Bestand vernichtet.
Drittens das manuelle Fulfillment. Ein Kunde ruft an, will den Status wissen, jemand markiert die Bestellung im Shopify-Admin als versandt, damit die Mail rausgeht. Danach hält das ERP die Position für offen und der Shop für erledigt. Je nach Schnittstelle läuft die Position dann nie mehr durch — oder es geht eine zweite Versandbestätigung raus, wenn das ERP nachzieht. Dasselbe gilt für Rückerstattungen, die im Shopify-Backend angelegt werden: Der Geldfluss stimmt, die Buchhaltung sieht ihn nicht.
Viertens duplizierte Produkte und Apps. Jemand kopiert einen Artikel im Shop, weil es schneller geht als eine ERP-Anlage. Das Duplikat hat keine gültige Artikelnummer, die Schnittstelle findet keine Zuordnung und legt es entweder erneut an oder ignoriert es. Apps, die selbst Produkte oder Varianten schreiben — Bundle-Apps, Abo-Apps, Personalisierung —, gehören in dieselbe Kategorie und werden bei der Feldabsprache regelmäßig vergessen.
Sofort überschreiben ist besser als still divergieren
Der unangenehmere Fall ist nicht der, in dem das ERP eine Änderung nach zehn Minuten zurücksetzt. Der ist ärgerlich, aber selbsterklärend: Man sieht, dass es nicht funktioniert, und ändert das Vorgehen.
Schlimmer sind Schnittstellen, die nur Änderungen übertragen. Wird ein Preis im Shop geändert und im ERP passiert nichts, bleibt der Shop-Preis stehen — wochenlang, bis irgendwann eine unabhängige ERP-Änderung an diesem Artikel den Datensatz erneut überträgt. Dann fällt der Preis ohne erkennbaren Anlass auf einen anderen Wert zurück, und niemand verbindet das mit der Handarbeit vom Vormonat. Bei Beschreibungstexten dasselbe Muster: Der schöne Shop-Text lebt so lange, bis jemand im ERP das Gewicht korrigiert.
Deshalb ist eine der nützlicheren Fragen im Projekt: Überträgt die Schnittstelle vollständig oder nur Deltas, und wenn Deltas — woran erkennt sie eine Änderung. Wer das weiß, kann einschätzen, wann eine Abweichung auffliegt.
Berechtigungen lösen das nur halb
Der naheliegende Reflex lautet, den betroffenen Leuten die Rechte zu entziehen. Das funktioniert nur begrenzt. Shopify-Berechtigungen sind gröber, als man sie hier bräuchte: Wer Kollektionen pflegen soll, braucht Zugriff auf Produkte — und kann damit auch Preise und Titel bearbeiten. Wer den Kundenservice macht, braucht Bestellungen und kann damit Fulfillments setzen.
Was hilft, ist unspektakulärer. Eine Feldliste, in der neben jedem relevanten Feld ein System und ein Name steht, und die nicht im Projektordner liegt, sondern dort, wo die Leute arbeiten. Dazu ein verabredeter Weg für die Fälle, in denen es schnell gehen muss — eine Aktionspreisliste im ERP, die sich in zwei Minuten pflegen lässt, verhindert mehr Bulk-Editor-Einsätze als jede Ansage. Und für die Bestellseite eine klare Regel, dass Statusänderungen im ERP passieren, auch wenn der Weg dorthin unbequemer ist.
Woran du vor dem Start arbeitest
Bevor die Schnittstelle steht, lohnt eine Runde durch das bestehende Shopify-Backend mit der Frage, welche Felder dort heute tatsächlich von Hand gepflegt werden und von wem. Die Liste ist fast immer länger als erwartet — irgendwo hat jemand über Jahre Bilder sortiert, Tags gesetzt, Texte nachgeschärft. Diese Arbeit verschwindet mit dem ersten Vollabgleich, wenn niemand vorher darüber gesprochen hat.
Erst danach ist die Frage sinnvoll, ob das ERP die Felder überhaupt in der Qualität liefern kann, die der Shop heute zeigt. Wenn nicht, ist die richtige Antwort selten, das Feld trotzdem ans ERP zu geben. Sie lautet häufiger: Das Feld bleibt im Shop, und die Schnittstelle lässt es in Ruhe.
KI-generierter Inhalt.