Eine Source of Truth für den Bestand: Was eine Unified-Commerce-Architektur wirklich verlangt

Suchen Sie nach diesem Begriff, und fast jedes Ergebnis liefert Ihnen dasselbe: eine Checkliste mit Komponenten und eine Plattform zum Kaufen. Zentrale Daten, einheitliche Kundenprofile, Bestand in Echtzeit, native Integrationen, bitte hier unterschreiben. Falsch ist die Checkliste nicht. Sie überspringt aber genau den Teil, der entscheidet, ob Ihr Bestand verlässlich ist. Eine Unified-Commerce-Architektur ist weniger ein Produkt, das Sie kaufen, als eine Entscheidung darüber, welches System danebenliegen darf. Die eigentliche Anforderung ist eine Reihenfolge: Legen Sie für jede Art von Daten ein führendes System fest, definieren Sie, wie dessen Zahl alle anderen Systeme erreicht, und halten Sie diese Zuständigkeit stabil, während Ihr Stack wächst. Dieser Beitrag geht die Reihenfolge durch, samt der zwei Stellen, an denen die meisten Projekte ins Stocken geraten.

Die Checkliste reicht nicht, weil eine Komponentenliste Ihnen sagt, was Sie zusammensetzen müssen, aber nicht, wie die Teile sich einig werden. Vier Systeme können jeweils die besten ihrer Klasse sein und trotzdem uneins darüber, wie viele Stück im Regal liegen. Keine Komponentenliste legt fest, wer gewinnt, wenn zwei davon unterschiedliche Zahlen führen. Genau diese Festlegung ist die Architektur. Im Folgenden steht die Bauabfolge, die über alle Kanäle einen verlässlichen Bestand liefert. Sie richtet sich an Teams, die den Aufbau bereits beschlossen haben und wissen wollen, was er verlangt.

Der Anfang: Welches System darf danebenliegen?

Noch vor jedem Connector steht die Grundsatzentscheidung: Welches System hält für jede Art von Daten die maßgebliche Zahl? Alle anderen Systeme richten sich danach, statt eine eigene Zahl durchzusetzen. Das ist es, was „Single Source of Truth“ in der Praxis bedeutet. Kein Produkt, sondern ein Urteil: Wenn zwei Systeme sich widersprechen, gewinnt dieses, und jenes gibt nach. Alles Weitere ist die Mechanik, mit der Sie dieses Urteil durchsetzen.

Die Frage, welches System „danebenliegen darf“, ist der nützlichste Blickwinkel. In jedem realen Stack halten Systeme kurzzeitig unterschiedliche Zahlen. Die Architektur muss das nicht verhindern, das kann sie auch nicht. Sie muss vorab festlegen, wessen Zahl zählt, wenn es passiert. Danebenliegen darf jedes System außer dem führenden. Ein nachgelagertes System mit einer veralteten Zahl korrigiert sich beim nächsten Ereignis von selbst. Liegt dagegen das führende System daneben, ist das der einzige Fehler, der bei einem Kunden als falsches Versprechen ankommt. Wenn Sie das führende System benennen, benennen Sie die eine Zahl, die immer stimmen muss.

Treffen Sie diese Entscheidung pro Datendomäne, nicht einmal für den ganzen Stack. Bestand, Bestellungen, Kunden und Preise brauchen jeweils ein führendes System, und oft sind das unterschiedliche. Wer es pauschal entscheidet („das ERP führt alles“), bekommt für manche Domänen ein führendes System, das dafür nie gedacht war.

Schritt eins: Domänen erfassen und jeder ein führendes System zuweisen

Der erste Bauschritt: Listen Sie Ihre Datendomänen auf und weisen Sie jeder genau ein führendes System zu. Halten Sie schriftlich fest, was die anderen Systeme mit diesen Daten tun dürfen. Bestand, Bestellungen, Kundendaten, Preise, Produktkatalog. Pro Domäne schreibt ein System die Wahrheit, alle anderen lesen sie.

Am wichtigsten ist hier die Frage, welches System beim Bestand führt, und darauf gibt es drei gängige Antworten. Liegt Ihre physische Zählung im ERP oder im Lagerverwaltungssystem am nächsten an der Wirklichkeit, dann führt dieses System den physischen Bestand, und die E-Commerce-Plattform liest daraus eine abgeleitete verkaufsfähige Zahl. Ist Ihre Allokations- und Kanallogik in einem Order-Management-System am weitesten ausgebaut, dann führt das OMS die Verfügbarkeit, und Filiale wie Webshop lesen beide daraus. Sind Sie ein Händler, der um Shopify herum aufgestellt ist und dessen Bestand vor allem in Shopify liegt und sich dort bewegt, kann die Plattform selbst führen, und das ERP gleicht sich damit ab. Im Zweifel gilt der sichere Standard: Das System, in dem Ware physisch den Besitzer wechselt, führt den physischen Bestand. Die verkaufsfähige Verfügbarkeit wird eine Ebene darüber berechnet.

Die Regel, die Sie aufschreiben, ist so wichtig wie die Wahl selbst. „Das ERP führt den physischen Bestand; Shopify verantwortet beim Bestand nichts außer der verkaufsfähigen Zahl, die es erhält“ ist eine Regel, die ein Entwickler umsetzen und ein Team verteidigen kann. „ERP und Shopify halten den Bestand beide synchron“ ist keine Regel. Es ist das Fehlen einer Regel, und genau dort beginnen die Zahlen auseinanderzulaufen.

Schritt zwei: Festlegen, was „verfügbar“ heißt und wer es berechnet

Die Architektur muss die verkaufsfähige Zahl als Formel definieren und ein System bestimmen, das sie berechnet, denn „verfügbar“ ist keine rohe Zählung. In den meisten Commerce-Systemen ist der verfügbare Bestand der physische Bestand abzüglich dessen, was zugesagt und nicht verfügbar ist. Rechnet jedes System diese Subtraktion mit seiner eigenen Sicht auf das Zugesagte, entstehen aus demselben Regal unterschiedliche verkaufsfähige Zahlen. Ein System muss die Berechnung verantworten.

Die Anforderung ist also eindeutig. Wählen Sie das System, das die verkaufsfähige Verfügbarkeit berechnet. Legen Sie genau fest, welche Größen es abzieht (offene Bestellungen, Reservierungen, beschädigte Ware, Sicherheitspuffer). Und lassen Sie jeden Kanal diese berechnete Zahl anzeigen, statt eine eigene abzuleiten. In diesem Schritt wird aus dem Prinzip „ein führendes System“ eine Zahl, der ein Kunde vertrauen kann. Das führende System hält nicht nur den physischen Bestand. Es veröffentlicht die eine verkaufsfähige Zahl, auf deren Basis der gesamte Stack verkauft.

Das geht oft unbemerkt schief, weil die Zahl jedes Systems für sich genommen korrekt aussieht. Die Bestandsschicht zwischen ERP und Shopify ist genau die Stelle, an der eine klare Definition verhindert, dass der Bestand zerfasert. Definieren Sie die Formel einmal, an einem Ort, und der Rest der Architektur hat etwas Solides, das er weitergeben kann.

Schritt drei: Wie die maßgebliche Zahl alle anderen Systeme erreicht

Stehen führendes System und Formel fest, brauchen Sie einen Weg, die Zahl zu verteilen. Wie gelangt die maßgebliche Zahl zu jedem System, das nur liest, und wie oft prüfen Sie, ob sie angekommen ist? Zur Wahl stehen ereignisgesteuert und zeitgesteuert. Für einen verlässlichen Bestand ist das eigentlich keine Wahl.

Bei ereignisgesteuerter Verteilung schickt jede Änderung im führenden System sofort ein Update nach außen. Die lesenden Systeme bleiben so nahezu live, und das ist der richtige Standard. Bei zeitgesteuerten Batches kopiert ein Job die Zahlen nach Zeitplan. Zwischen zwei Läufen arbeitet dann jedes System mit veralteten Daten, deshalb sollten Sie das für Daten reservieren, die sich wirklich nicht schnell ändern. Ereignisgesteuert allein genügt aber nicht, und das unterschätzen die meisten Projekte. Eine Nachricht kann sich verzögern, verloren gehen oder gedrosselt werden. Die Architektur braucht deshalb auch einen geplanten Abgleich: eine regelmäßige Prüfung, die die Zahl des führenden Systems mit jedem lesenden System vergleicht und jede Abweichung meldet. Events halten den Stack aktuell. Der Abgleich hält ihn ehrlich. Sie brauchen beides, und den Rhythmus des Abgleichs festzulegen ist eine Anforderung an den Aufbau, kein nettes Extra.

Erste Hürde: Bewegungen, die die Synchronisierung nie sieht

Die erste Hürde kommt, sobald der Idealfall auf Retouren, Reservierungen und mehrere Standorte trifft. Ein Aufbau, der nur abgeschlossene Verkäufe synchronisiert, ignoriert stillschweigend jede andere Art, wie sich Bestand bewegt. Hier wird eine Architektur, die fertig aussah, undicht. Das ist so vorhersehbar, dass Sie es von Anfang an einplanen können.

Retouren sind das deutlichste Beispiel. Ein zurückgesandter Artikel ist physisch wieder da, aber erst verkaufsfähig, wenn er geprüft und im führenden System wieder in einen verkaufsfähigen Status gebucht wurde. Die Architektur muss diesen Weg also festlegen, statt davon auszugehen, dass eine Retoure den Bestand automatisch wiederherstellt. Reservierungen und Bestellentwürfe sind das Spiegelbild: Ware, die für einen Kunden zurückgehalten wird, ist vergeben, ohne verkauft zu sein. Das führende System muss sie als zugesagt behandeln, damit die verkaufsfähige Zahl sinkt. Mehrere Standorte machen aus „wie viele“ die Frage „wie viele, und wo“. Eine Bestellung wird nämlich an einem bestimmten Standort zugesagt, nicht aus einem unternehmensweiten Topf, und die Architektur muss entscheiden, welche Standorte in die Online-Verfügbarkeit einfließen. Ein Aufbau, der den sauberen Verkauf abdeckt und diese drei Fälle auslässt, hat später kein Bestandsproblem. Er hat jetzt eine unfertige Architektur. Den Retourenweg, die Reservierungsstatus und die Standortregeln auszuarbeiten, unterscheidet eine Demo von einem System.

Zweite Hürde: Governance und das Erkennen von Abweichungen

Die zweite Hürde ist Governance: festlegen, wer die maßgebliche Zahl ändern darf und wie Abweichungen auffallen. Ohne das bröckelt die Source of Truth ab, eine manuelle Korrektur nach der anderen. Ein Aufbau kann korrekt live gehen und trotzdem über Monate schlechter werden. Mitarbeitende nehmen in bester Absicht direkte Korrekturen in Systemen vor, die eigentlich nur lesen sollten, und jede davon reißt die Lücke wieder auf, die die Architektur geschlossen hatte.

Zwei Anforderungen halten das zusammen. Erstens darf nur das führende System die maßgebliche Zahl schreiben, über die dafür festgelegten Wege. So kann ein lesendes System nicht unbemerkt zum zweiten schreibenden werden. Zweitens ist der Abgleich aus Schritt drei so eingerichtet, dass er einen Menschen alarmiert, sobald er eine Abweichung findet. Dann fällt sie auf einem Dashboard auf und nicht erst, wenn ein Kunde etwas kauft, das nicht mehr da ist. Governance ist die Anforderung, die sich am leichtesten überspringen lässt, weil an dem Tag, an dem Sie sie überspringen, nichts kaputtgeht. Es geht langsam kaputt, und das ist schlimmer: Bis der Bestand wieder unzuverlässig ist, weiß niemand mehr, welche Korrektur es ausgelöst hat. Eine Architektur ohne Governance ist keine schlanke Variante einer einheitlichen. Sie ist eine einheitliche mit Verfallsdatum.

Was Sie außerdem einplanen sollten

Über die zwei Hürden hinaus plant ein belastbarer Aufbau die Wege ein, auf denen er später bricht. Ein Sync-Token läuft ab, und Bestellungen kommen nicht mehr an. Nichts stürzt sichtbar ab, nur die Datenlücke wächst. Die Architektur braucht deshalb Alarme für die Authentifizierung und den Zustand der Synchronisierung, nicht nur für die Daten selbst. Eine Aktion auf einem Kanal verschiebt die Bestandsallokation bewusst, also müssen die Regeln gewollte Unterschiede von versehentlichen Abweichungen trennen können. Und im zweiten Jahr kommt ein neues System dazu. Das ist trivial, wenn es sich an das führende System anschließt und die veröffentlichte Zahl liest, und teuer, wenn es Punkt für Punkt mit allem verdrahtet wird, was schon läuft.

Dieser letzte Punkt zeigt, warum klare Zuständigkeiten über die Bestandsgenauigkeit hinaus zählen. Eine sauber aufgebaute Unified-Commerce-Architektur macht die nächste Integration günstig, weil es ein festes Zentrum gibt, an das man andockt. Flatline hat genau so ein Zentrum in Projekten gebaut wie der Zusammenführung von Shopify Plus, POS, ERP und WMS bei OGÉR und der Middleware, die die Webshops von North Actionsports mit ERP und Fulfillment verbindet. Der Wert lag dort weniger in einem einzelnen Connector als in der abgestimmten Struktur, nach der sich die Systeme richten.

Check: Sind Sie bereit für den Aufbau?

Sie sind bereit, wenn Sie vier Fragen beantworten können. Welches System führt den Bestand? Welche Formel definiert die verkaufsfähige Verfügbarkeit? Wie wird die Zahl verteilt, und wie oft gleichen Sie sie ab? Und wer darf sie schreiben? Haben alle vier eine klare Antwort, ist der Aufbau vor allem Umsetzung. Lautet eine davon noch „beide Systeme halten es synchron“, ist das die Lücke, die Sie schließen müssen, bevor auch nur ein Connector geplant wird. Auf genau diese Lücke geht jedes spätere Problem zurück.

Die meisten Teams können eine oder zwei der vier Fragen sicher beantworten und werden beim Rest still. Das ist ein normaler Ausgangspunkt, kein Versäumnis. Die vier Fragen sind die eigentliche Spezifikation einer Unified-Commerce-Architektur, mehr als jede Komponentenliste, weil sie festlegen, welches Verhalten die Komponenten liefern müssen.

Wenn Sie Ihre Optionen für die Source of Truth sortieren, ist das die Entscheidung, die stimmen muss, bevor Sie Connectors kaufen. Flatline ist Shopify Platinum Partner mit langer Erfahrung in Integrationen und Middleware, von individuellen Connectors und ERP-Integrationen bis zu kompletten Unified-Commerce-Projekten. Möchten Sie eine zweite Meinung dazu, wo die Source of Truth Ihres Bestands liegen sollte? Wir bieten Ihnen ein unverbindliches Gespräch über Ihre Architektur an. Melden Sie sich, und wir gehen die vier Fragen gemeinsam mit Ihnen durch.

Häufige Fragen

Was ist eine Unified-Commerce-Architektur?

Eine Unified-Commerce-Architektur ist ein Systemdesign, in dem es für jede Art von Daten einen maßgeblichen Datensatz gibt. Jeder Vertriebskanal und jedes Backend-System liest daraus und schreibt dorthin, statt eine eigene Kopie zu führen. Ihr Kennzeichen ist eine Single Source of Truth pro Domäne, sodass Bestand, Bestellungen und Kundendaten online und im Geschäft in Echtzeit übereinstimmen.

Was braucht eine Unified-Commerce-Architektur?

Vier Dinge: ein führendes System pro Datendomäne, eine festgelegte Formel für die verkaufsfähige Verfügbarkeit, die an einer Stelle berechnet wird, ereignisgesteuerte Verteilung kombiniert mit geplantem Abgleich sowie Governance, die regelt, wer die maßgebliche Zahl schreiben darf. Die einzelnen Tools zählen weniger als diese Entscheidungen, weil diese festlegen, welches Verhalten die Tools liefern müssen.

Braucht Unified Commerce eine einzige Plattform, oder können Sie Systeme integrieren?

Eine einzige native Plattform ist nicht nötig. Unified Commerce definiert sich über eine Source of Truth pro Domäne. Die erreichen Sie auf einer nativen Plattform oder, indem Sie Best-of-Breed-Systeme um einen zentralen maßgeblichen Datensatz oder eine Integrationsschicht herum verbinden. Entscheidend ist, dass sich jedes System nach einer maßgeblichen Zahl richtet, nicht, dass alle in einem Produkt stecken.

Wo sollte die Source of Truth für den Bestand liegen?

In dem System, das am nächsten an der physischen Bewegung der Ware liegt, mit der verkaufsfähigen Verfügbarkeit eine Ebene darüber berechnet. Sind die physischen Zählungen im ERP oder Lagerverwaltungssystem am genauesten, führt dieses System den physischen Bestand, und der Shop liest eine abgeleitete Zahl. Ist die Allokationslogik in einem Order-Management-System am weitesten ausgebaut, kann dieses die Verfügbarkeit führen. Die Regel zählt mehr als das konkrete System.

Wo geraten die meisten Unified-Commerce-Projekte ins Stocken?

An zwei Stellen. Erstens bei Retouren, Reservierungen und Beständen an mehreren Standorten, die Ware auf Wegen bewegen, die eine Synchronisierung nur abgeschlossener Verkäufe nie sieht. Zweitens bei der Governance, wenn keine Regel festlegt, wer die maßgebliche Zahl schreiben darf, und die Source of Truth durch gut gemeinte manuelle Korrekturen langsam erodiert. Beides planen Sie von vornherein ein, statt es später zu entdecken.

Das Wichtigste in Kürze

• Eine Unified-Commerce-Architektur ist eine Bauabfolge, keine Produkt-Checkliste. Ihre Kernanforderung: pro Datendomäne entscheiden, welches System danebenliegen darf.

• Weisen Sie pro Domäne ein führendes System zu und schreiben Sie die Regel auf. „Beide Systeme halten es synchron“ ist das Fehlen einer Regel und der Ursprung von Abweichungen.

• Verkaufsfähige Verfügbarkeit ist eine Formel, keine rohe Zählung. Ein System muss sie berechnen und die eine Zahl veröffentlichen, auf deren Basis jeder Kanal verkauft.

• Die Verteilung braucht beide Hälften: ereignisgesteuerte Updates, um aktuell zu bleiben, und geplanten Abgleich, um ehrlich zu bleiben.

• Projekte stocken an zwei vorhersehbaren Stellen: bei Bewegungen, die die Synchronisierung nie sieht (Retouren, Reservierungen, Standorte), und bei fehlender Governance darüber, wer die maßgebliche Zahl schreiben darf. Planen Sie beides von Anfang an ein.

Eine Unified-Commerce-Architektur verdient die Bezeichnung „eine Source of Truth“ erst, wenn sich der ganze Stack nach einer einzigen Zahl richtet, die alle lesen können. Das ist zuerst eine Entscheidung und dann ein Bauprojekt, und erst die richtige Entscheidung macht den Aufbau lohnend. Wenn Sie die vier Fragen beantworten können, haben Sie den Großteil geschafft. Wenn noch nicht, ist genau das das Gespräch, das sich lohnt, bevor der erste Connector gekauft wird.