Over EDI en het Foodware Data Exchange Framework

Geschreven door Dänny Hellemons, Schouw Informatisering, Product Development Manager

Ongeveer twee jaar geleden besloten we bij Schouw Informatisering om opties voor een verbeterde EDI propositie te onderzoeken. Hiervóór was EDI onderdeel van ons op Dynamics NAV gebaseerde product SI Foodware en onze implementatie services. Het verwerken van het Order-To-Cash proces en Vendor-Managed-Inventory. Voor de Dynamics AX kant van onze product- en implementatieservices hadden we een vergelijkbare propositie: met voornamelijk focus op de ERP zijde van de EDI propositie. Het EDIFACT berichttransformatie en –transport, evenals de implementatie, werden afgehandeld via Value-Added-Network leveranciers (VAN), zoals Descartes, Generix en Tie Kinetix. VAN leveranciers verwerken veel EDIFACT berichten en verzorgen het gerelateerde verkeer tussen voedingsmiddelenbedrijven en retailers. Waarnaast Schouw Informatisering de specifieke EDI-mapping en -verwerking in de back-end van de ERP applicatie van het bedrijf verzorgt.

Uitdagingen op het gebied van timing en projectmanagement

Er waren dus altijd drie partijen bij een EDI implementatieproject betrokken. De klant, de VAN leverancier en het Schouw projectteam. Waar de laatste twee op een verschillend ritme werkten: een ERP-projectimplementatie versus een EDI service setup. Dit leidde vaak tot uitdagingen op het gebied van timing en projectmanagement, met de klant die daar tussenin zat. De behoefte aan flexibiliteit en een korte time-to-market verhoogde de lat alleen maar. Daarbij gingen onze klanten leveren aan nieuwe retailers in andere markten buiten Nederland, waardoor er aanvullende vereisten en uitgebreide EDI-processen (en dus mappings) nodig waren. Een uitdaging die opgelost moest worden, omdat we ernaar streven een meer volwaardige servicepartner te worden voor onze klanten. We willen op een flexibele en getimede manier presteren om te voldoen aan de EDI-eisen van retailers, om onze klanten te ontzorgen.

De basis voor EDI bouwen

Als eerste stap moesten we onze EDI-kennis vergroten. We hebben intussen de essentiële EDI-kennis in huis, vanuit alle drie de hoeken: de VAN partner, de retailer en onze klant; het foodbedrijf. Het onderzoek dat we gedaan hebben, deed ons beseffen dat we het EDI-proces los moesten koppelen van onze andere software. Gevolgd door de wens om de data mappings los te koppelen van de EDI verwerkingsstappen in de ERP-oplossing. En een stap verder zou ook rekening houden met EDIFACT mappings. Dit op een manier dat onze consultants in staat zijn om deze taken uit te voeren; het toevoegen of aanpassen van mappings voor onze klanten.

Naarmate we vorderden, ontstond een drielaags model.

  • In de eerste laag worden de geïntegreerde EDI processen die beschikbaar zijn binnen het Foodware 365 platform losgekoppeld met behulp van staging tables.
  • Vervolgens wordt er een mapping gemaakt op basis van een intern XML-based data model. Dit maakt standaardisatie van dataverkeer mogelijk op basis van de bedrijfsentiteiten, zoals orders en facturen. Deze zijn gebaseerd op de mogelijkheden van het ERP back-end, waardoor er minder afhankelijkheden ontstaan van een mogelijk groot aantal externe standaarden.
  • Door de transformatie en het transport te scheiden, stellen we klanten in staat om de EDIFACT-berichtafhandeling bij een VAN te laten of zelf de volledige controle te nemen.

Een audittrail zorgt voor de registratie aan beide kanten en dient om fouten te onderzoeken.

Oftewel, een gestandaardiseerde gelaagde aanpak om flexibiliteit, ontkoppeling en uitbreidbaarheid te bieden voor andere externe data uitwisseling standaarden en de behoefte aan klantaanpassingen. We leveren hiermee een complete serviceaanpak tijdens ERP-implementaties. Dus nu hebben we een functionele blauwdruk om de zoektocht naar tooling en een platform te starten. Meer dan alleen een EDI framework, een Data Exchange Framework.

Een framework gebaseerd op Azure Services

In de loop van de tijd hebben we naar verschillende iPaaS platforms gekeken, omdat we op zoek waren naar een platform die ons transformatie-, integratie- en transportmogelijkheden kon bieden. Bovendien moest het een pay-as-you-grow model zijn voor het MKB. Een model dat stapsgewijs kan worden opgebouwd, waarbij je gaandeweg kunt leren en uitbreiden. Het was dichterbij dan we hadden verwacht, Azure Serverless Apps: Azure Services zoals Logic Apps, Azure Functions, Azure Service Bus, Azure Event Grid etc.

Met begeleiding en validatie van Microsoft-architecten, zijn we begonnen met het definiëren van onze architectuur met Azure services bouwstenen. Dit stelt ons in staat om ons Data Exchange Framework stapsgewijs te bouwen. Daarnaast hebben we besloten om Altova Mapforce als een visuele data mapping & transformatie tool te gebruiken. Om consultants en klanten zelf in staat te stellen de mappings uit te voeren in plaats van deze taak aan ontwikkelaars te moeten geven.

EDI proces in Foodware propositie

Ons product is afgelopen zomer ontstaan. Het compleet herbedenken en opnieuw ontwikkelen van het EDI proces in onze Foodware propositie. Het resultaat: een oplossingsgericht framework dat het Order-To-Cash EDI proces en proces voor leveranciers ondersteunt, gebaseerd op Azure Services. Het is meer dan alleen EDI. Het is een eerste versie van ons Data Exchange Framework dat alle mogelijke manieren van dataverkeer, transformatie en verwerking aankan.

Vorig najaar zijn we gestart met een ERP implementatieproject bij een van onze grotere foodklanten in Nederland. We hebben dit gecombineerd met de implementatie van ons Data Exchange Framework voor het Order-To-Cash EDI proces. Het project is in maart live gegaan en is daarmee onze eerste succesvolle implementatie. Daar zijn we trots op.

Later dit jaar is er een connectie van het framework met Business Central SaaS gepland. We gaan Foodware 365 uitbreiden met de mogelijkheden van het Data Exchange Framework.