.svg)
Was Auftragsorchestrierung in der E-Commerce-Landschaft bedeutet
Jedes E-Commerce-Unternehmen führt bereits einen orchestrierten Prozess durch, ob dieser nun geplant wurde oder nicht. Der Order-to-Cash-Prozess beginnt im Shop und endet, wenn die Finanzabteilung den Umsatz verbucht. Dazwischen durchläuft er das ERP für Preise und Kreditwürdigkeit, das Lagersystem für Zuweisung und Kommissionierung, einen Versanddienstleister für Etiketten und Tracking sowie einen Zahlungsanbieter für Einzug und Abrechnung.
Die Auftragsorchestrierung steuert diesen Ablauf. Sie legt fest, welcher Schritt in welcher Reihenfolge ausgeführt wird, von welchen Bedingungen er abhängt und was passiert, wenn ein Schritt ein unerwartetes Ergebnis liefert. Jede Übergabe hat ihre eigenen Bedingungen. Ein Rückstand ändert den Erfüllungspfad. Eine Teillieferung splittet die Rechnung. Ein fehlgeschlagener Zahlungseinzug sollte die Kommissionierung stoppen, anstatt sie freizugeben.
Der Unterschied zur reinen Konnektivität ist gering, aber kostspielig. Eine Verbindung garantiert, dass das Lager einen Kommissionierauftrag erhält. Die Orchestrierung entscheidet, ob dieser Auftrag überhaupt gesendet werden sollte, sobald der Bestand reserviert und die Zahlung eingegangen ist. Diese Entscheidung liegt über den einzelnen Systemen, in der Integrationsschicht, die bereits den Datenverkehr zwischen allen Systemen abwickelt.
Warum reduziert die Verbindung von mehr Systemen nicht die Komplexität?
Die Anzahl der zu verbindenden Systeme und die prozessübergreifende Logik sind zwei verschiedene Probleme, und Integrationsprojekte lösen meist nur das erste. Ein Unternehmen kann jede Punkt-zu-Punkt-Verbindung durch eine verwaltete Anbindung ersetzen und dennoch zusehen, wie Aufträge an denselben Stellen hängen bleiben.
Die Konsolidierung dieser Verbindungen auf einer E-Commerce-Integrationsplattform beseitigt doppelte Arbeit und bietet Teams einen zentralen Ort zur Überwachung des Datenverkehrs. Was sie jedoch nicht klärt, ist, was geschehen soll, wenn das Lager eine Kommissionierung für einen Bestand bestätigt, den das ERP bereits einem anderen Auftrag zugesichert hat. Das ist eine Entscheidung, keine Datenübertragung.
Komplexität in einem etablierten Systemverbund ist eher bedingt als strukturell. Nehmen wir einen Einzelhändler, der seit drei Jahren zwei Webshops, einen Marktplatzkanal und zwei Logistikstandorte betreibt. Die Anzahl der Systeme hat sich kaum verändert. Die Anzahl der Wege, die ein Auftrag nehmen kann, hat sich jedoch vervielfacht, da jede Ausnahme einen neuen Zweig hinzufügt: eine geteilte Lieferung, eine Teilrückerstattung, eine Vorbestellung, eine Click-and-Collect-Abholung, die niemand abholt, oder eine Retoure, die eintrifft, bevor die Rückerstattung genehmigt wurde.
Diese Zweige existieren, ob sie nun geplant wurden oder nicht. Da sie nicht konzipiert wurden, verteilen sie sich auf Shop-Plugins, ERP-Anpassungen und eine Tabellenkalkulation, die jemand im operativen Geschäft im Stillen pflegt. Der Prozess läuft zwar weiter, aber niemand kann ihn überblicken oder sicher anpassen.
Wo ein Order Management System an seine Grenzen stößt
Ein Order Management System (OMS) ist wirklich gut in dem, wofür es zuständig ist: welcher Standort versendet, was aufgeteilt wird und wie der Bestand über Kanäle hinweg zugewiesen wird. Für einen Einzelhändler mit vielen Logistikstandorten lohnt es sich, diese Logik zu kaufen, anstatt sie selbst zu entwickeln.
Seine Zuständigkeit endet jedoch an der eigenen Schnittstelle. Das OMS benötigt weiterhin saubere Aufträge aus jedem Kanal, eine Abstimmung mit dem ERP bezüglich Preisen und Kreditbedingungen, Aufgabenübergaben an ein Lagersystem sowie Statusrückmeldungen an die Finanzabteilung und den Kunden. Diese systemübergreifende Choreografie ist keine Funktion eines OMS. Sie gehört in die Integrationsschicht.
Der Kompromiss muss klar benannt werden. Unternehmen mit einer wirklich verteilten Logistik benötigen in der Regel beides. Unternehmen, die ein OMS kaufen, in der Erwartung, dass es einen systemübergreifenden Prozess repariert, enden mit einer präzisen Routenplanung, während die Aufträge weiterhin zwischen den Systemen feststecken.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
