ERP-webshop koppeling: de volledige checklist vóór livegang

Een ERP-webshop koppeling is nooit een eenvoudig project. Zelfs als de individuele systemen goed functioneren, is de integratie ertussen een eigen discipline — met eigen risico's, eigen faalpatronen en eigen succescriteria. Toch zien we bij overnames en audits keer op keer dezelfde fouten: koppelingen die gebouwd zijn zonder eigenaarschapsdefinitie, zonder monitoringplan en zonder go-live strategie. Het resultaat is een systeem dat werkt zolang niemand het test, maar keldert bij de eerste piekperiode.

Deze checklist is opgebouwd op basis van tientallen integratieprojecten. Gebruik hem vóór de build start, niet erna.

1. Datamodellen en eigenaarschap definiëren

De meest fundamentele vraag bij elke integratie is: wie is de bron van waarheid voor welk veld? Klinkt eenvoudig, maar in de praktijk leidt onduidelijkheid hierover tot conflicten, overschrijvingen en data-inconsistentie.

Wat u moet vastleggen:

• Per datadomein (productdata, prijzen, voorraad, klanten, orders) bepaalt u welk systeem de master is — ERP, webshop of middleware.
• Wie mag een veld wijzigen? Een prijs die in het ERP wordt bijgewerkt mag niet door de webshop worden overschreven, en vice versa.
• Documenteer expliciete field-mappings: hoe vertaalt een ERP-artikel naar een webshop-product? Wat gebeurt er met BTW-codes, eenheden, varianten en afbeeldingen?
• Identificeer velden die in beide systemen bestaan maar anders heten of anders zijn geformatteerd — dit zijn de meest voorkomende bronnen van synchronisatiefouten.

Resultaat: een data-ownershiptabel die voor elk systeem en elk veld aangeeft wie schrijft, wie leest en wie valideert.

2. Synchronisatiepatronen kiezen

Niet alle data heeft dezelfde tijdsgevoeligheid. Realtime synchronisatie voor alles is technisch mogelijk maar operationeel riskant en duur. Een goede integratiearchitectuur differentieert op basis van urgentie en volume.

Realtime of near-realtime (event-driven):

• Voorraadwijzigingen na orderplaatsing — klanten mogen niet bestellen wat er niet is.
• Orderbevestigingen richting ERP — verwerking moet direct starten.
• Prijswijzigingen bij tijdgevoelige acties of contractprijzen.

Geplande synchronisatie (batch/polling):

• Productcatalogus updates — dagelijks of uurlijks is voor de meeste webshops voldoende.
• Klantdata en accountwijzigingen — minder tijdskritisch.
• Historische orderdata voor rapportering.

Wat u technisch moet voorzien:

• Wachtrijen (queues) — gebruik een message queue (RabbitMQ, SQS, of een eenvoudiger alternatief) voor alle asynchrone communicatie. Dit isoleert systemen van elkaar en biedt retrycapaciteit bij storingen.
• Idempotentie — zorg dat elke operatie meerdere keren uitgevoerd kan worden zonder ongewenste bijwerkingen. Een order twee keer aanmaken in het ERP is een kritische fout.
• Backpressure — wat gebeurt er als het ERP trager is dan de webshop events genereert? Ontwerp voor piekmomenten, niet voor gemiddeld gebruik.

3. Foutafhandeling en retrylogica

Een integratie zonder expliciete foutafhandeling is een integratie die vroeg of laat stilzal vallen — en het dan niet vanzelf opnieuw zal proberen. Fouten zijn geen uitzonderingen; ze zijn een normaal onderdeel van gedistribueerde systemen.

Categoriseer uw fouten:

• Tijdelijke fouten (netwerktimeout, service tijdelijk down): automatisch retrybaar met exponentiële backoff.
• Validatiefouten (ongeldige data, ontbrekende velden): niet retrybaar zonder menselijke interventie. Stuur naar een dead-letter queue of foutlog.
• Businesslogicafouten (prijs buiten acceptabel bereik, onbekende klantcode): vereisen eigenaarsdefinitie — wie lost dit op?

Retrybeleid:

• Eerste retry na 30 seconden, daarna 5 minuten, 30 minuten, 2 uur. Niet oneindig herhalen — na een maximumaantal pogingen markeren als failed en alerteren.
• Zorg dat retries niet leiden tot dubbele verwerking. Dit is waar idempotentie cruciaal is.

Dead-letter queue:

• Berichten die na het maximumaantal retries nog altijd falen, komen in een dead-letter queue. Hier kunnen operators ze inspecteren, corrigeren en manueel herstarten.

4. Teststrategie uitwerken

Integraties zijn notoir moeilijk te testen omdat ze afhankelijk zijn van externe systemen. Maar een gebrek aan testdekking is de snelste weg naar een verborgen bug die weken later in productie opduikt.

Unit tests:

• Test transformatie- en mappinglogica geïsoleerd. Geef een ERP-object als input, verwacht een webshop-object als output. Geen externe calls.

Integratietests:

• Test de volledige flow end-to-end met echte (test)systemen. Gebruik een staging-omgeving van zowel ERP als webshop.
• Test specifiek de randgevallen: lege velden, maximale waarden, speciale karakters in productnamen, negatieve voorraad.

Scenario-tests:

• Simuleer een volledige orderflow: product aanmaken in ERP → zichtbaar in webshop → order geplaatst → order verwerkt in ERP → voorraad bijgewerkt.
• Test herstelscenario's: wat als de ERP-connectie wegvalt tijdens een ordersync? Herstelt het systeem automatisch?

5. Monitoring en observability

Een integratie die werkt zonder monitoring is een integratie die u pas ziet falen als klanten het u melden. Zet monitoring op vóór livegang, niet erna.

Wat u wil meten:

• Doorvoersnelheid (throughput): hoeveel berichten worden per minuut verwerkt? Een plotse daling signaleert een probleem.
• Foutpercentage: het percentage berichten dat mislukt. Zelfs 1% kan bij hoge volumes betekenen dat honderden orders niet verwerkt worden.
• Latency: hoe lang duurt het gemiddeld voordat een event verwerkt is? Stijgende latency wijst op overbelasting of bottlenecks.
• Queue diepte: hoe groot is de backlog? Een groeiende queue zonder afname is een alarmsignaal.

Alerting:

• Stel drempelwaarden in voor elk van bovenstaande metrics.
• Werk met prioriteitslagen: kritieke alerts (orderverwerking gestopt) gaan direct naar een on-call persoon; waarschuwingen (latency stijgt) mogen naar een dashboard of e-mail.
• Definieer expliciete verantwoordelijkheden: wie krijgt welk alert? Wie is responsible voor triagering?

6. Go-live strategie

De go-live van een integratie is niet het eindpunt — het is het begin van de productieomgeving. Een zorgvuldige go-live beschermt u tegen een kettingreactie van fouten die moeilijk terug te draaien zijn.

Gefaseerde uitrol:

• Begin met een subset van data: één productcategorie, één klantgroep, één magazijnlocatie. Valideer, corrigeer en schaal dan op.
• Run parallelle systemen tijdelijk naast elkaar — het oude manuele proces blijft beschikbaar als vangnet.

Rollbackplan:

• Definieer vóór de go-live wat de drempel is om terug te draaien. Hoeveel fouten per uur? Welke kritieke flows moeten werken?
• Test het rollbackscenario. Een rollbackplan dat niet getest is, is geen plan.

Hypercare-periode:

• Plan de eerste twee weken na go-live als hypercare: hogere alerting-gevoeligheid, dagelijkse statusreviews, directe beschikbaarheid van het ontwikkelteam.
• Communiceer proactief naar interne stakeholders: wat wordt gemonitord, wat zijn de escalatiepaden?

7. Documentatie en kennisoverdracht

Integraties die niet gedocumenteerd zijn, worden black boxes. Wanneer een engineer vertrekt of een systeem geüpdatet wordt, is documentatie het verschil tussen een gecontroleerde wijziging en een nachtmerrie.

Wat u documenteert:

• Dataflow-diagram: welk systeem stuurt wat naar welk systeem, via welk mechanisme.
• Field-mapping tabel: ERP-veld → webshop-veld, inclusief transformatieregels.
• Foutcodes en hun betekenis, met bijbehorende acties.
• Escalatieprocedure bij incidenten.

---

Conclusie: Een ERP-webshop integratie die crasht tijdens Black Friday of piekseizoen is niet alleen een technisch incident — het is een commercieel risico. De investering in een solide architectuur, goede testdekking en proactieve monitoring verdient zichzelf altijd terug. Begin met de juiste fundering, en bouw van daaruit verder.