Dit jaar wilde onze dochter voor het eerst niet bij ons in de caravan, maar in een tentje slapen. We bestelden online een tentje bij onze voorkeursleverancier, die normaliter snel en betrouwbaar levert. Ondanks een bestelbevestiging én afleverbevestiging, kregen we echter geen tent. De pakketbezorger bleek hem verderop in de straat te hebben bezorgd, bij een adres dat veel op het onze leek. Als consument was ik geïrriteerd, maar vanuit mijn betrokkenheid bij repleniQ gefascineerd. Het deed me denken aan een gesprek dat ik onlangs had met een relatie. Hij vroeg me hoe je replenishment software aansluit op het ERP systeem. Mijn antwoord luidde dat je dit het beste via een Enterprise Service Bus (ESB) doet, wat ik vergeleek met een postbode. Een tussenpartij die producten of informatie van A naar B brengt. ‘Hoe werkt dat dan?’, werd me gevraagd. Deze informatie deel ik ook graag met jullie!
Bestelling wordt automatisch verwerkt in je ERP systeem
Waarom zou een retailer zijn replenishment software willen koppelen aan zijn ERP systeem? De reden is simpel. Door dit te doen, wordt informatie over bestellingen automatisch verwerkt in je ERP systeem. Dat is een groot voordeel. Het betekent namelijk dat je die data niet handmatig hoeft over te nemen, waardoor je altijd verzekerd bent van snelle en tijdige informatie uitwisseling. Voor optimale informatie uitwisseling koppel je idealiter alle gebruikte systemen aan elkaar, dus bijvoorbeeld ook je kassasysteem en promotiemanagementsysteem.
Het risico van systemen op elkaar aansluiten
Een risico is dat je beide systemen foutief koppelt, waardoor ze allebei ‘in de lucht’ moeten zijn om te kunnen werken. Stel dat je replenishment software onderhoud nodig heeft en daardoor tijdelijk offline is, dan werkt in dat geval je ERP systeem niet. Dat wil je voorkomen.
De oplossing: een Enterprise Service Bus (ESB)
De oplossing is systemen niet direct op elkaar aan te sluiten, maar via een zogeheten Enterprise Service Bus (ESB). Dit is een tussenlaag die informatie van en naar systemen stuurt, in de ‘taal’ of het format dat de verschillende systemen hanteren. Hier komt mijn vergelijking met een postbode vandaan. Het mooie aan een ESB is dat het in élke gewenste taal berichten kan doorgeven. Een ESB kan zelfs één bericht naar meerdere formats tegelijk vertalen en verzenden naar verschillende systemen tegelijk. Tot slot bewaart de ESB een bericht als een van de systemen offline is, waarna berichten in chronologische volgorde alsnog verzonden worden.
Een voorwaarde voor het goed functioneren van een ESB, is dat het een beschrijving – oftewel Application Programming Interface (API) – moet hebben van hoe er gecommuniceerd moet worden met de diverse systemen. Met het oog op security is het uiteraard ook belangrijk dat vertrouwelijke informatie enkel encrypted wordt uitgewisseld.
Waaraan moet software voldoen om te communiceren via een ESB?
De software die je gebruikt, moet dus allereerst communiceren volgens een goed gedefinieerde API. Elk bericht bevat bepaalde velden en aan die structuur wordt altijd voldaan. Ook moet de manier van adresseren – naar welk systeem moet er worden gecommuniceerd? – altijd gelijk en universeel zijn.
Maak je gebruik van repleniQ, dan kunnen wij je precies vertellen hoe de API’s eruit zien. En hoe je deze informatie aanbiedt aan het ESB systeem van jouw keuze. Zodat jouw ESB geen fout kan maken á la de bezorger van onze tent.
Wil jij ook een betrouwbaar besteladvies?
De juiste balans in je winkelvoorraad begint bij het genereren van een goed besteladvies. Maar hoe doe je dat? In dit whitepaper…
#1 Ontdek je welke retaildata je allemaal kunt (of moet!) gebruiken
#2 Leggen we uit hoe je van een basisprognose tot een volwaardige forecast komt
#3 Gaan we óók in op diverse uitzonderingssituaties. Wat doe je bijvoorbeeld als er nog geen data beschikbaar is?
#4 En sluiten we af met 5 absolute retaildata do’s en don’ts
