Amore OMS

Context

De klant beheert meerdere storefronts en verzendt naar verschillende Europese markten. Order intake, fulfillment en carrier dispatch waren verdeeld over platform-specifieke tools en carrier-specifieke workflows. Naarmate het volume toenam, groeide de operationele overhead mee. De grootste pijn was niet een ontbrekende feature, maar het ontbreken van één operationeel overzicht en voorspelbare statusafhandeling.

Probleem

Het kernprobleem was niet een gebrek aan features, maar een gebrek aan controle en betrouwbaarheid.

• Orders werden uit storefronts ingelezen zonder genormaliseerde interne representatie.
• Carrier dispatch vereiste verschillende stappen per provider (labels, formaten, tracking).
• Magazijnworkflows (picking/packing) waren moeilijk te standaardiseren zonder tooling.
• Adres- en telefoonformaten varieerden per land, wat vermijdbare leveringsfouten veroorzaakte.
• De operatie had geen betrouwbare manier om “vastgelopen” orders te reconciliëren (betaald maar niet verzonden, verzonden maar niet getrackt).

Projectdoelen

• Ordermanagement over storefronts centraliseren in één operationeel systeem.
• Een voorspelbare orderlifecycle creëren met expliciete states en exceptions.
• Magazijnflows standaardiseren (batching, scanning, packing) om menselijke fouten te verminderen.
• Meerdere carriers integreren met consistent dispatch- en trackinggedrag.
• Uitbreiding naar nieuwe markten/carriers mogelijk maken zonder het core systeem te herschrijven.

Beperkingen & Uitdagingen

• Geen downtime voor order intake vanuit storefronts.
• Meerdere btw-tarieven en landspecifieke verzendregels/uitzonderingen.
• Meerdere betaaltypen (incl. COD) en operationele varianten per markt.
• Verschillende carrier API’s, labelformaten en tracking-identifiers.
• Legacy data en inconsistente payloads uit externe systemen.

De oplossing moest naast de bestaande omgeving kunnen draaien en geleidelijk het primaire operationele systeem worden.

Oplossingsoverzicht

We hebben een maatwerk OMS ontworpen en gebouwd dat fungeert als operationele control layer tussen storefronts en logistiek. Het OMS vervangt storefronts niet. Het orkestreert fulfillment: ingestie, normalisatie, statustracking, dispatch, tracking en operationele workflows.

• Eén bron van waarheid voor orderstatus
• Expliciete statusovergangen en reconciliatie
• Geverifieerde inkomende events (webhooks) en deterministische updates
• Duidelijke scheiding tussen ingestie, operations en carrier-integraties

Architectuur & Technische aanpak

Het systeem is geïmplementeerd als een pragmatische operations webapplicatie met een relationele database. De kern van het design is het datamodel: orders, sites, statussen, batches, producten en carrier artifacts.

• Order ingestie: geverifieerde webhooks voor storefront events en orderaanmaak, met duplicate protection.
• Normalisatie: consistente interne representatie (adressen, telefoonnummers, land-/btw-regels, SKU’s).
• Statusbeheer: expliciete statussen en foutafhandeling voor operationele voorspelbaarheid.
• Operationele UI: filtering, triage, batchvoorbereiding en per-order acties voor het operations-team.
• Magazijntooling: barcodescanning en batchworkflows voor packing/dispatch.
• Carrier-laag: integraties voor labelgeneratie, tracking toewijzing, annuleren en tracking updates.
• Background jobs: geplande reconciliatie en tracking updates om “on-hold” operationele states te finaliseren.

Elke integratie is geïsoleerd, zodat wijzigingen het core systeem niet beïnvloeden. Deze structuur ondersteunt geleidelijke uitrol en voorspelbare uitbreidingen (nieuwe storefronts, carriers, markten).

Technologiestack

• Backend: PHP
• Database: MySQL
• UI: Server-rendered interne web-UI (MDL + JS-hulpfuncties)
• Background jobs: cron-gebaseerde geplande taken
• Integraties: Shopify webhooks + meerdere carrier API’s/SDK’s (DPD, GLS, Packeta, UrgentCargus, BRT), tracking exports/imports
• Documenten: PDF-generatie voor operationele artifacts (labels, documenten)

Technologiekeuzes gaven prioriteit aan stabiliteit, onderhoudbaarheid en bekendheid bij het team boven experimentele oplossingen.

Implementatieproces

1. Analyse en mapping van businessprocessen
2. Definitie van orderlifecycle en states
3. Incrementele implementatie van ingestie, intern datamodel en operationele UI
4. Carrier-integraties één voor één toegevoegd met consistente abstracties en fallbacks
5. Geleidelijke uitrol van magazijntooling (batching, scanning) en background reconciliatie

Regelmatige checkpoints met de klant zorgden voor alignment tussen technische beslissingen en operationele realiteit.

Resultaten en impact

• Minder handmatige orderafhandeling en minder dispatchfouten.
• Meer transparantie voor operations en support (één plek om orderstatus te zien).
• Snellere onboarding van nieuwe carriers/markten dankzij expliciete integratiegrenzen.
• Een stabiele basis voor automatisering en operationele reporting.

Het OMS werd een kritisch onderdeel van de dagelijkse operatie.

Reflectie

De keuze om op orkestratie te focussen in plaats van vervanging bleek cruciaal. Het minimaliseerde risico en zorgde ervoor dat de klant vroeg waarde kon realiseren. Achteraf gezien was de meest impactvolle investering het gedetailleerde upfront modelleren van orderstates en transitions, wat operationele ambiguïteit tijdens ontwikkeling en toekomstige wijzigingen verminderde.

Samenvatting

Dit project laat zien hoe een goed ontworpen maatwerksysteem orde en stabiliteit kan brengen in complexe e-commerce operations zonder het bestaande bedrijf te verstoren. Het benadrukt een pragmatische, architecture-driven aanpak voor het oplossen van echte operationele problemen.