OMS für den Onlineshop: Wann ein separates System nötig ist

Ein OMS für den Onlineshop wird nicht allein deshalb benötigt, weil der Umsatz wächst. Ein separates Auftragsmanagementsystem ist dann gerechtfertigt, wenn Website, Marktplätze und Lager nicht mehr gemeinsam entscheiden können, wer die Ware erhält, von wo sie versendet wird und was nach einer Auftragsänderung geschieht. Setzt die bestehende Plattform oder das ERP diese Regeln zuverlässig um, kann ein zusätzliches Produkt den Betrieb lediglich komplizierter machen.

Beginnen Sie mit einem Konfliktszenario: Wer erhält das letzte Stück eines Artikels, das gleichzeitig auf der Website und über einen anderen Kanal bestellt wurde? Im Folgenden finden Sie Entscheidungskriterien, Zuständigkeitsgrenzen der Systeme und einen Pilotplan.

Wo Synchronisierung endet und Orchestrierung beginnt

Synchronisierung überträgt Daten: Ein neuer Auftrag erreicht das Warenwirtschaftssystem, der Bestand auf der Website wird aktualisiert. Orchestrierung legt die Abfolge der Schritte fest: Verfügbarkeit prüfen, Ware reservieren, Lager auswählen, einen Kommissionierauftrag übermitteln und auf eine Ablehnung reagieren. Eine gemeinsame Entscheidung für mehrere Kanäle statt einer weiteren Auftragsliste ist die Aufgabe eines OMS.

Ein hypothetisches Beispiel: Die Website hat die Zahlung für ein Set angenommen, doch ein Marktplatz hat einen Bestandteil bereits zuvor reserviert. Ein zweites Lager hat den benötigten Artikel, aber eine separate Lieferung würde die vereinbarten Bedingungen ändern. Dafür braucht es eine festgelegte Regel: Sendung aufteilen, einen anderen Termin anbieten oder den Ausnahmefall an einen Mitarbeiter weiterleiten. Eine Bestandsaktualisierung allein beantwortet diese Frage nicht.

Sammeln Sie wiederkehrende Störungen: manuelle Lagerneuzuweisung, Verkauf nicht verfügbarer Ware, hängen gebliebene Reservierungen und Teilstornierungen. Notieren Sie jeweils Ursache, Zuständigkeit und Folge. Eine falsche Artikelnummer oder ein nicht übermitteltes Ereignis wird in den Daten beziehungsweise der Integration korrigiert, nicht durch den Kauf eines neuen Systems.

Was in ERP, WMS und Handelsplattform bleibt

Vereinbaren Sie vor der Produktauswahl, welches System für jede Entscheidung zuständig ist. Das ERP übernimmt üblicherweise Buchführung und Finanzdokumente, das WMS die Lagerabläufe und die Handelsplattform den Bestellabschluss. Ein OMS kann die Abwicklung zwischen ihnen koordinieren. Das ist eine Architekturvereinbarung, keine allgemeingültige Eigenschaft der Bezeichnungen: Konkrete Produkte überschneiden sich funktional.

Beispielsweise beschreibt die Shopify-Dokumentation zum Routing aufeinanderfolgende Regeln zur Standortauswahl, darunter die Minimierung geteilter Sendungen. Mehrere Lager belegen daher noch keinen Bedarf an einem separaten OMS. Vergleichen Sie Ihre Szenarien, nicht die Zahl der Funktionen in einer Präsentation.

Ein Drupal-Shop muss nicht zwangsläufig sämtliche Abläufe steuern. Bestimmen Sie bei der Planung des Websystems und seiner Integrationen, welches System den bestätigten Auftragszustand verantwortet. Wenn Website und ERP unabhängig voneinander den Versand freigeben, beseitigt eine neue Oberfläche den Widerspruch nicht.

Warenreservierung: Bestand ist nicht gleich Verfügbarkeit

Warenreservierung verknüpft die verfügbare Menge mit einer konkreten Zusage gegenüber einem Kunden. Physisch liegt die Ware noch im Regal, darf aber keinem anderen Auftrag mehr zugesagt werden. Unterscheiden Sie buchmäßigen Bestand, verkaufbare Menge und bestätigte Reservierung, statt zwischen Systemen nur ein Feld „verfügbar“ auszutauschen.

Eine zentrale Entscheidung über die Verfügbarkeit

Microsoft Inventory Visibility beschreibt weiche Reservierungen: Der Dienst prüft die Verfügbarkeit, reduziert die für weitere Reservierungen verfügbare Menge und liefert eine Reservierungskennung zurück. Der physische Bestand ändert sich dabei nicht zwangsläufig. Zum Schutz vor Doppelreservierungen müssen alle betreffenden Kanäle den vereinbarten Mechanismus nutzen, statt nur regelmäßig eine Kopie der Bestände zu erhalten.

Das bedeutet nicht, dass jede Integration Überverkäufe garantiert verhindert. Für einen Kanal, der keine sofortige Reservierungsanfrage unterstützt, muss das Verhalten gesondert vereinbart werden: ein begrenztes Warenkontingent, Sicherheitsbestand oder Auftragsannahme ohne endgültige Bestätigung. Kunden sollte keine garantierte Verfügbarkeit zugesagt werden, solange diese technisch noch nicht geprüft wurde.

Der Lebenszyklus einer Reservierung

Legen Sie fest, wann eine Reservierung entsteht und unter welchen Bedingungen sie verlängert oder aufgehoben wird. Ein unbezahlter Warenkorb, ein bestätigter Auftrag und Ware in der Kommissionierung erfordern unterschiedliche Regeln. Nach einer Stornierung muss die Reservierung die Verfügbarkeit wiederherstellen; nach dem Versand muss sie korrekt in einen tatsächlichen Bestandsabgang übergehen, ohne die Menge doppelt zu reduzieren.

Adobe Commerce beschreibt kompensierende Reservierungen für Stornierungen und Änderungen der verkaufbaren Menge. Das ist ein Beispiel für eine konkrete Umsetzung, keine Anleitung für alle Plattformen. Ihre Architektur benötigt eine eigene Ereignistabelle: Welche Aktion verändert Reservierung, Bestand und Status, wer bestätigt sie und wie wird ein unvollständiger Übergang erkannt?

Auftragsrouting muss das Kundenversprechen berücksichtigen

Auftragsrouting bedeutet, Ort und Art der Abwicklung auszuwählen, nicht nur das nächstgelegene Lager. Zunächst werden Einschränkungen geprüft: verfügbare Ware, zulässiger Transportdienstleister, Annahmeschluss und die Möglichkeit, ein Set zusammenzustellen. Danach gelten Prioritäten: Warenkorb nicht aufteilen, Standort nicht überlasten und den vereinbarten Termin einhalten.

Die Reihenfolge der Regeln verändert das Ergebnis. Shopify wendet sie nacheinander an; die Regel für den nächstgelegenen Standort verwendet die Luftlinie, nicht die Fahrstrecke. Geografische Nähe allein garantiert daher weder eine günstigere noch eine schnellere Lieferung. Prüfen Sie im Pilotprojekt die tatsächlichen Einschränkungen Ihrer Logistik, nicht nur die Lageradresse.

Beschreiben Sie die Teilabwicklung gesondert. Wenn einige Positionen bereits an das Lager übergeben wurden, dürfen eine spätere Adressänderung oder Stornierung den bisherigen Auftrag nicht stillschweigend überschreiben. Erforderlich sind eine Bestätigung des Stopps, eine neue Entscheidung über die restlichen Waren und eine verständliche Nachricht an den Kunden. Geldrückerstattung und Wiederfreigabe von Ware zum Verkauf sind unterschiedliche Prozesse.

Mitarbeiter benötigen eine Warteschlange für Ausnahmefälle mit Ursache, zulässiger Aktion und Entscheidungshistorie. Sie müssen erkennen können, ob der Standort geändert werden darf, ob die Zustimmung des Kunden erforderlich ist und ob bereits verpackt wird.

So prüfen Sie den OMS-Bedarf vor einer großen Einführung

Ein Pilotprojekt muss die Geschäftsentscheidung durchgängig prüfen, nicht nur die Übertragung eines Testauftrags. Wählen Sie eine begrenzte Gruppe von Produkten, Kanälen und Lagern mit einem konkreten Konflikt. Vereinbaren Sie vorab das erwartete Ergebnis jedes Szenarios, die Protokolle als Nachweis und die Befugnis zum Abbruch des Tests.

1. Gleichen Sie Artikelnummern, Mengeneinheiten und Standortkennungen in allen Systemen ab. Ein Set und seine Bestandteile dürfen nicht versehentlich als unabhängiger Bestand gezählt werden.
2. Senden Sie aus verschiedenen Kanälen gleichzeitige Anfragen für das letzte Stück. Prüfen Sie, wer die Reservierung und welche Antwort der andere Kunde erhalten hat.
3. Senden Sie dasselbe Zahlungs- oder Auftragserstellungsereignis erneut. Eine Wiederholung darf keinen zweiten Auftrag und keinen zusätzlichen Bestandsabgang erzeugen.
4. Unterbrechen Sie einen Austauschkanal und stellen Sie ihn anschließend wieder her. Prüfen Sie Ereignisreihenfolge, erneute Zustellung und ob Änderungen verloren gegangen sind.
5. Führen Sie eine Teilstornierung, einen geteilten Versand und eine Retoure durch. Prüfen Sie Geld, Reservierung, physischen Bestand und Kundennachrichten getrennt.
6. Simulieren Sie nach dem Routing eine Ablehnung durch das Lager. Stellen Sie sicher, dass der Auftrag entweder sicher neu zugewiesen oder an den zuständigen Mitarbeiter übergeben wird.
7. Gleichen Sie die Ergebnisse mit den Quellsystemen ab und üben Sie den Rollback. Die Rückkehr zum alten Prozess darf keine doppelten aktiven Reservierungen hinterlassen.

Messen Sie die Zeit von der Auftragsannahme bis zur bestätigten Reservierung, manuelle Eingriffe, Verfügbarkeitsabweichungen und unvollständige Übergänge. Grenzwerte richten sich nach Ihren betrieblichen Anforderungen und werden nicht aus einer fremden Fallstudie übernommen. Reicht es aus, einen einzigen Konnektor oder die Plattformregeln zu korrigieren, ist auch das ein vollwertiges Pilotergebnis.

Risiken einer neuen Steuerungsebene

Die größte Gefahr ist eine weitere Quelle widersprüchlicher Statusangaben. Bewahren Sie Auftrags-, Positions- und Reservierungskennungen systemübergreifend. Die erneute Verarbeitung einer Nachricht muss idempotent sein: Dasselbe Ereignis löst keine wiederholte Geschäftsaktion aus. Für verspätete Nachrichten sind Versionsregeln oder Regeln für zulässige Zustandsübergänge erforderlich.

Übernehmen Sie nicht sämtliche historischen Fehler in das OMS. Legen Sie fest, welche aktiven Aufträge in die neue Steuerung wechseln und welche im alten System abgeschlossen werden. Beschränken Sie manuelle Änderungen durch Berechtigungen, protokollieren Sie den Eingriffsgrund und gleichen Sie Reservierungen regelmäßig mit der Abwicklung ab. Automatisierung ohne Verantwortliche für Ausnahmefälle häuft ungelöste Situationen lediglich schneller an.

Prüfen Sie auch die Anbieterabhängigkeit: Zugriff auf Ereignisprotokolle, Zustandsexport, Integrationsgrenzen und Wiederherstellung nach Störungen. Ein OMS korrigiert weder ungenaue Lagerbestände noch eine uneinheitliche Retourenpolitik. Kann das Team diese Regeln noch nicht formulieren, muss zuerst am Prozess gearbeitet werden.

Wovon Zeitrahmen und Kosten abhängen

Der Zeitrahmen umfasst mehr als die Softwareinstallation. Benötigt werden Prozessbeschreibung, Stammdatenbereinigung, Zugang zu Testumgebungen, Entwicklung des Datenaustauschs, Szenariotests und Mitarbeiterschulung. Die Abstimmung von Marktplatzzugängen oder der Möglichkeiten eines externen Lagers kann zur kritischen Abhängigkeit werden, selbst wenn die eigene Entwicklung bereits fertig ist.

Planen Sie Prüfpunkte statt eines geratenen Termins

Gliedern Sie das Projekt in Regelabstimmung, technischen Prototyp, Pilot und Erweiterung. Jeder Übergang erfordert einen Nachweis: ein freigegebenes Zustandsmodell, einen reproduzierten Reservierungskonflikt, korrekt wiederhergestellten Datenaustausch und einsatzbereite Mitarbeiter. Präzisieren Sie den Termin des vollständigen Starts nach Prüfung der riskantesten Integrationen, statt ihn an eine allgemeine Zeitangabe aus einer Marktübersicht zu knüpfen.

Trennen Sie im Angebot Lizenz oder Abonnement, Geschäftsanalyse, Konnektoren, Migration aktiver Aufträge, Tests und Einführung. Laufende Kosten umfassen Infrastruktur, Monitoring, Wartung des Datenaustauschs, Änderungen an Partner-APIs und die Weiterentwicklung der Regeln. Vergleichen Sie die Gesamtbetriebskosten mit dem Ausbau der bestehenden Plattform für dieselben Szenarien.

Die Entscheidung: OMS kaufen oder das bestehende System stärken

Ein separates OMS ist sinnvoll, wenn mehrere unabhängige Kanäle eine gemeinsame Steuerung von Reservierungen und Abwicklung benötigen und die vorhandenen Mittel die vereinbarten Tests nicht bestehen. Verschwinden die Probleme nach Korrektur der Daten, eines Konnektors oder der Routingregeln, ist ein separates Produkt vorerst nicht zwingend. Auswahlkriterium ist ein kontrollierter Auftragslebenszyklus, nicht die Bezeichnung einer Systemklasse.

Bereiten Sie für ein Gespräch mit GL.ua (Glyanec) eine Übersicht der Kanäle und Lager, eine Integrationsliste und Störungsbeispiele ohne personenbezogene Daten vor. Besprechen Sie die Onlineshop-Architektur und Integrationen, um die Pilotgrenzen festzulegen und ein separates OMS vor der Produktauswahl mit dem Ausbau der bestehenden Lösung zu vergleichen.