Amore OMS

Kontext

Der Kunde betreibt mehrere Storefronts und versendet in verschiedene europäische Märkte. Auftragsannahme, Fulfillment und Carrier-Versand waren auf plattformspezifische Tools und carrier-spezifische Workflows verteilt. Mit steigendem Volumen wuchs auch der operative Aufwand. Das Hauptproblem war nicht ein fehlendes Feature, sondern das Fehlen einer einheitlichen Betriebsübersicht und einer vorhersehbaren Zustandsverwaltung.

Problem

Das Kernproblem war nicht ein Mangel an Features, sondern fehlende Kontrolle und Zuverlässigkeit.

• Bestellungen wurden von Storefronts ohne normalisierte interne Repräsentation übernommen.
• Der Carrier-Versand erforderte je nach Anbieter unterschiedliche Schritte (Labels, Formate, Tracking).
• Warehouse-Workflows (Picking/Packing) waren ohne Tooling schwer zu standardisieren.
• Adressen- und Telefonformate variierten je nach Land, was vermeidbare Zustellfehler verursachte.
• Dem Betrieb fehlte eine zuverlässige Möglichkeit, „hängende" Bestellungen abzugleichen (bezahlt aber nicht versendet, versendet aber nicht getrackt).

Projektziele

• Zentralisierung der Auftragsverwaltung über alle Storefronts in einem operativen System.
• Schaffung eines vorhersehbaren Auftragslebenszyklus mit expliziten Zuständen und Ausnahmen.
• Standardisierung von Warehouse-Abläufen (Batching, Scanning, Packing) zur Reduzierung menschlicher Fehler.
• Integration mehrerer Carrier mit konsistentem Versand- und Tracking-Verhalten.
• Ermöglichung der Expansion in neue Märkte/Carrier ohne Neuprogrammierung des Kernsystems.

Rahmenbedingungen & Herausforderungen

• Keine Ausfallzeit für die Auftragsannahme der Storefronts.
• Mehrere MwSt.-Sätze und länderspezifische Versandregeln/-ausnahmen.
• Mehrere Zahlungsarten (inkl. Nachnahme) und operative Varianten pro Markt.
• Unterschiedliche Carrier-APIs, Label-Formate und Tracking-Kennungen.
• Legacy-Daten und inkonsistente Payloads externer Systeme.

Die Lösung musste mit der bestehenden Umgebung koexistieren, bevor sie schrittweise zum primären operativen System wurde.

Lösungsüberblick

Wir haben ein individuelles OMS entwickelt, das als operative Kontrollschicht zwischen Storefronts und Logistik fungiert. Das OMS ersetzt die Storefronts nicht. Es orchestriert das Fulfillment: Aufnahme, Normalisierung, Zustandsverfolgung, Versand, Tracking und operative Workflows.

• Single Source of Truth für den Auftragsstatus
• Explizite Zustandsübergänge und Abgleich
• Verifizierte eingehende Events (Webhooks) und deterministische Updates
• Klare Trennung zwischen Aufnahme, Operations und Carrier-Integrationen

Architektur & technischer Ansatz

Das System ist als pragmatische Operations-Webanwendung mit relationaler Datenbank implementiert. Der Kern des Designs ist das Datenmodell: Bestellungen, Sites, Status, Batches, Produkte und Carrier-Artefakte.

• Order Ingestion: verifizierte Webhooks für Storefront-Events und Auftragserstellung mit Duplikatsschutz.
• Normalisierung: konsistente interne Repräsentation (Adressen, Telefonnummern, Länder-/MwSt.-Regeln, SKUs).
• State Management: explizite Status und Exception-Handling für operative Vorhersehbarkeit.
• Operational UI: Filterung, Triage, Batch-Vorbereitung und auftragsweise Aktionen für das Operations-Team.
• Warehouse-Tooling: Barcode-Scanning und Batch-Workflows für Packing/Versand.
• Carrier-Layer: Integrationen für Label-Generierung, Tracking-Zuweisung, Stornierung und Tracking-Updates.
• Background-Jobs: geplante Abgleiche und Tracking-Updates zur Finalisierung von „On-Hold"-Zuständen.

Jede Integration ist isoliert, sodass Änderungen ohne Auswirkung auf das Kernsystem möglich sind. Diese Struktur unterstützt schrittweisen Rollout und vorhersehbare Erweiterungen (neue Storefronts, Carrier, Märkte).

Technologie-Stack

• Backend: PHP
• Datenbank: MySQL
• UI: Server-gerenderte interne Web-UI (MDL + JS-Utilities)
• Background-Jobs: Cron-basierte geplante Tasks
• Integrationen: Shopify-Webhooks + mehrere Carrier-APIs/SDKs (DPD, GLS, Packeta, UrgentCargus, BRT), Tracking-Exporte/-Importe
• Dokumente: PDF-Generierung für operative Artefakte (Labels, Dokumente)

Die Technologieauswahl priorisierte Stabilität, Wartbarkeit und Team-Vertrautheit gegenüber experimentellen Lösungen.

Implementierungsprozess

1. Geschäftsprozessanalyse und -mapping
2. Definition des Auftragslebenszyklus und der Zustände
3. Inkrementelle Implementierung von Ingestion, internem Datenmodell und operativer UI
4. Carrier-Integrationen nacheinander hinzugefügt mit konsistenten Abstraktionen und Fallbacks
5. Schrittweiser Rollout von Warehouse-Tooling (Batching, Scanning) und Background-Abgleich

Regelmäßige Checkpoints mit dem Kunden sicherten die Abstimmung zwischen technischen Entscheidungen und operativer Realität.

Ergebnisse & Auswirkungen

• Reduzierte manuelle Auftragsbearbeitung und weniger Versandfehler.
• Bessere Transparenz für Operations- und Support-Teams (eine zentrale Stelle für den Auftragsstatus).
• Schnelleres Onboarding neuer Carrier/Märkte dank expliziter Integrationsgrenzen.
• Eine stabile Grundlage für Automatisierung und operatives Reporting.

Das OMS wurde zu einem kritischen Bestandteil des täglichen Betriebs.

Reflexion

Die Entscheidung, sich auf Orchestrierung statt Ersatz zu konzentrieren, erwies sich als entscheidend. Sie minimierte das Risiko und ermöglichte dem Kunden, früh im Projekt Mehrwert zu erzielen. Rückblickend war die wirkungsvollste Investition die detaillierte Vorab-Modellierung von Auftragszuständen und -übergängen, die operative Unklarheiten während der Entwicklung und zukünftiger Änderungen reduzierte.

Zusammenfassung

Dieses Projekt demonstriert, wie ein gut konzipiertes individuelles System Ordnung und Stabilität in komplexe E-Commerce-Operations bringen kann, ohne das bestehende Geschäft zu stören. Es zeigt einen pragmatischen, architekturgetriebenen Ansatz zur Lösung realer operativer Probleme.