Next Generation met Doctor Who

Eén van mijn jeugdhelden is Doctor Who. Deze sympathieke avonturier beleefde spannende avonturen in tijd en ruimte om de mensheid voor allerhande kwaad te behoeden. En nog steeds, want momenteel zendt de BBC alweer het 38ste seizoen uit van de oudste nog lopende TV serie ter wereld. Al heeft de Doctor wel wat veranderingen ondergaan en is hij inmiddels een tijdreizigster geworden.

Het fenomeen van tijdreizen is een populair onderwerp in fictie. Eén van de eerste boeken hierover was The Timemachine van H.G. Wells. Denk ook aan films als de Back to the Future reeks, 12 Monkeys, Groundhog Day en de verschillende iteraties van Star Trek. En wie is er niet groot geworden met de Teletijdmachine van professor Barabas?

Nu biedt het leven van een software ontwikkelaar vele uitdagingen, maar degene die de gemiddelde tijdreiziger het hoofd moet bieden ken ik dan weer niet. Alhoewel?

Ik houd mij vooral bezig met het ontwikkelen, en aanpassen van, bedrijfskritische business applicaties. De afgelopen tijd heb ik verschillende leuke opdrachten voor Ahold mogen uitvoeren op het gebied van Store Replenishment. De meest recente klus betreft het NGR project bij Albert Heijn. NGR staat voor Next Generation Replenishment. Eén van de slogans van dit project is “Bettering the Best” en daarmee is denk ik niets teveel gezegd.

De maatwerk Applicaties binnen het huidige Replenishment landschap hebben Albert Heijn namelijk al veel goeds gebracht op het terrein van beschikbaarheid, winkelbeeld en afboekingen. Om verdere voordelen op het gebied van onder andere transport te kunnen behalen, is besloten om een extra laag toe te voegen die winkelorders nog beter in hun onderlinge samenhang kan optimaliseren. Daarnaast is er de wens om meer gebruik van A.I. elementen te kunnen maken en verschillende functionaliteiten breder binnen het bedrijf beschikbaar te stellen. Mede daarom is er voor gekozen om het NGR project op het Azure cloud platform te ontwikkelen, waarbij functies middels API’s toegankelijk zijn voor andere applicaties.

Omdat NGR vooralsnog een extra laag “bovenop” de bestaande systemen vormt, moest er een integratie met de huidige applicaties worden gemaakt. Binnen Orcado hebben we een ruime ervaring met de ontwikkeling en het onderhoud van de Store Replenishment systemen van Albert Heijn en ook ik heb daar zeer veel jaren aan mogen bijdragen. Aan ons de schone taak om de DESO applicatie te laten integreren met NGR.

En onwillekeurig voel ik mij toch een beetje een tijdreiziger in dit project. Want ga maar na; de winkelorder wordt berekend in de huidige applicatie (DESO), maar stuurt zijn uitkomst naar de toekomstige wereld: NGR. De winkel order wordt daar geoptimaliseerd door deze te combineren met andere winkelorders en wordt weer teruggezonden naar DESO voor verdere verspreiding. Heden communiceert met toekomst en vice versa.

Maar zoals dat met tijdreizen gaat, dienen er wel een aantal regels in acht te worden genomen om tijdsparadoxen en ander ongemak te vermijden:

Het heden is onafhankelijk van de toekomst.

In verband met het volume en stringente afspraken voor doorlooptijden binnen de supply chain is het berekenen van winkelorders aan een strikt tijdschema gebonden. DESO is dan ook gevoelig voor performance invloeden. Het gebruik van API’s is in dit verband niet de meest ideale oplossing, omdat je de winkelorderberekening niet afhankelijk wil laten zijn van de performance van een externe applicatie; NGR in dit geval. Er is daarom gekozen voor een ontkoppelde interface met een request en reply structuur, gelinkt middels een requestid. Op deze manier is DESO nog steeds baas in eigen huis en kan het de verantwoordelijkheid blijven nemen over zijn eigen tijdspaden. Mocht de reply vanuit NGR onverhoopt te laat zijn, dan wordt deze niet verwerkt en geldt de door DESO berekende winkelorder, die dan dus niet geoptimaliseerd is, als output.

Wijzingen aangebracht in het verleden hebben effect op de toekomst.

DESO berekent niet enkel de actuele winkelorder, maar tevens een set van winkelorders voor de toekomst, om op die manier beter inzicht te verkrijgen in de supply chain keten (over tijdreizen gesproken). Men noemt dit de SDF (Store Demand Forecast). Omdat NGR meerdere winkelorders combineert, heeft elke wijziging in de berekende winkelorder dus een mogelijk effect op de optimalisatie  van andere winkel orders. Elke wijziging in een berekende SDF dient dan ook met NGR te worden gecommuniceerd. Daarnaast brengt NGR ook zelf wijzigingen aan op de winkelorder in het kader van de optimalisatie. Deze worden als reply weer naar DESO verzonden. Om te voorkomen dat DESO deze weer als wijziging naar NGR moet versturen, die weer mogelijk opnieuw geoptimaliseerd zou worden en daarmee een oneindige loop start , slaat NGR zijn eigen wijzigingen ook onafhankelijk op.

Weet waar je bent; bepaal je positie in tijd en ruimte

Bijkomende uitdaging binnen dit project, en vaak binnen grote organisaties, is het feit dat er meerdere projecten tegelijkertijd actief zijn, die elk wijzingen aanbrengen op de applicatie. Het gevaar bestaat dus dat er simultane werkelijkheden ontstaan, helemaal als er gedeelde functionaliteit in het spel is. Continue afstemming tussen de (SCRUM-) teams is daarom van groot belang evenals een zorgvuldig versiebeheer. Weten op welke versie van de code je de wijzigingen aanbrengt, wanneer elk project een (deel)oplevering naar de productie omgeving doet en hoe je alle wijzingen correct administreert is daarbij essentieel. Een TARDIS zou handig zijn.

Waarmee we dan weer bij Doctor Who zijn aanbeland. De eerste twee afleveringen van het huidige seizoen gaan overigens voor een deel over Ada Lovelace en Charles Babbage, geen onbekenden voor degenen met interesse in de oorsprong van het vakgebied van IT en software ontwikkeling. En mochten deze namen je  niets zeggen, zoek ze een keertje op. Een kleine reis door de tijd is zo op zijn tijd de moeite waard!

VMI, waarom moet dat?

In de afgelopen jaren ben ik veelvuldig betrokken geweest bij het implementeren van het VMI model in de Food Retail sector. VMI staat voor Vendor Managed Inventory. Dit is een business model waarbij leveranciers zelf verantwoordelijk zijn voor het bijhouden van de juiste voorraden ten behoeve van de (winkel)verkopen van een retailer. De leverancier wordt daarbij, vanuit de retailer, gevoed met informatie over de actuele voorraadstanden in het distributiecentrum en over de verwachte verkopen in de komende periode. Op basis van deze parameters kan de leverancier zelf berekenen hoeveel artikelen hij wanneer moet leveren aan het distributiecentrum. Doelstelling is om daarbij niet te veel voorraad aan te houden, maar ook weer niet te weinig. Te veel voorraad leidt tot hogere kosten en verhoogt het risico op derving omdat producten in de voorraad over de datum (THT/TGT) gaan voordat ze zijn verkocht aan de retailer. Te weinig voorraad leidt tot gemiste (winkel)leveringen en dat betekent omzetverlies en een verslechtering van de relatie met de retailer. Voor een leverancier betekent VMI vooral het continu zoeken naar een juiste balans hierin.

Vanuit de praktijk heb ik gemerkt dat leveranciers zeer wisselend reageren op de overstap naar VMI. Deze overstap wordt hen vaak opgelegd door de retailer. Een groot deel van de leveranciers is niet direct enthousiast. De eerste reactie is vaak: “waarom moet dat?”. Dat is begrijpelijk omdat deze leveranciers gewend zijn aan een overzichtelijke situatie waarbij zij orders ontvangen die geleverd en gefactureerd kunnen worden. Daar hebben deze leveranciers hun processen en systemen op ingericht. VMI vereist dat deze leveranciers ineens zelf moeten berekenen wat er geleverd moet worden. Fouten die daarbij gemaakt worden zijn vaak ook voor hun eigen rekening of zo wordt het in ieder geval gepercipieerd.

Aan de andere kant is er ook altijd een groep leveranciers die het VMI model gelijk omarmt. Vaak zijn dit leveranciers die al geïnvesteerd hebben in en/of willen investeren in processen en systemen die wendbaar zijn en die reageren op actuele informatie. Zij zien de voordelen van VMI en, wellicht nog belangrijker, kunnen dit snel implementeren in hun organisatie. En die voordelen zijn er zeker voor leveranciers. Zo kunnen zij met VMI:

VMI biedt dus zeker voordelen. Maar is het makkelijk? Nou dat is het niet voor iedereen. Vanuit supplybrain hebben we daarom besloten om VMI software te maken om de VMI implementatie te vergemakkelijken voor leveranciers. Natuurlijk doen we dat omdat we daar een business case in zien. Maar we doen dit ook omdat wij geloven dat dergelijke oplossingen bijdragen aan een duurzamere samenleving. De beste manier om dervingen en daarmee voedselverspillingen tegen te gaan is immers door er voor te zorgen dat al het voedsel dat wordt geproduceerd ook daadwerkelijk wordt verkocht (en geconsumeerd). En niet in voorraden blijft liggen om uiteindelijk te worden vernietigd omdat de houdbaarheid is verstreken. VMI levert hier zeker een verbetering in. Dit effect wordt nog groter als de betrouwbaarheid van de informatie over de verwachte verkopen wordt vergroot. Hoe beter en eerder je weet wat er verkocht gaat worden, des te beter je kan bevoorraden. Vandaar dat supplybrain ook een module heeft ontwikkeld voor forecasting. Op die manier hopen we een bijdrage te leveren aan een duurzamere supplychain en daarmee een duurzamere samenleving. Daarnaast vinden wij dit ook gewoon leuk en uitdagend om te doen. Het is een mooi vooruitzicht om hiermee het nieuwe decennium in te gaan!

Hoe ontwikkel je een voorspelmodel voor de vraag naar levensmiddelen?

Ervaringen van een product owner

Binnen supplybrain maken we (onder andere) voorspelmodellen om de vraag naar levensmiddelen in (web)winkels te kunnen voorspellen. Een belangrijke vraag voor mij als product owner is dan ook: Wat is een goed model en hoe ontwikkel je dat? Met een model bedoel ik hier een methode om op basis van historische gegevens de toekomstige vraag naar een artikel te voorspellen.  Laten we voor het gemak stellen dat het beste model het model is met de hoogste modelscore. Over hoe je deze modelscore meet kun je een heel verhaal houden. Laten we er echter even van uitgaan dat er voor een bepaalde methode is gekozen. Als product owner ben je voor het ontwikkelen van een model afhankelijk van de data scientists in je team. Op basis van hun ervaringen en belangstelling zullen zij voorstellen doen voor een model. Dat kan een “verklaarbaar” model of een meer “black box” model zijn.

Maar let op! Als product owner heb je te maken met veel meer stakeholders met ideeën over modellen. Aandeelhouders en managers die worden afgerekend op de beurswaarde zijn bijvoorbeeld vaak geïnteresseerd in “coole” zelflerende modellen met “coole” features1. Denk hierbij bijvoorbeeld aan het aantal specifieke zoekopdrachten op internet, likes op social media, lokale gebeurtenissen etc.. Het is hip en leuk om daar over te vertellen en zelfs als het met een grote inspanning weinig waarde toevoegt zou je toch kunnen overwegen om deze features op te nemen. Ook HR managers worden hier blij van. Het versterkt het vaak gewenste beeld dat het bedrijf een “tech”-organisatie is en je trekt er mogelijk nieuw data science talent mee aan.

De saneerders binnen de organisatie hebben echter al snel een voorkeur voor technieken die zelf de features bepalen die in een model worden opgenomen. Het idee is dan dat je zonder business kennis, en met weinig inspanning, altijd automatisch een kwalitatief goede voorspelling hebt. Dat kan in de praktijk nog wel eens tegenvallen. De uitrol van een dergelijk model kan stroef verlopen als de eerste resultaten niet direct aan de verwachtingen voldoen.

De procesmanagers en continue veranderaars zien daarentegen liever een eenvoudig en verklaarbaar model. Zo krijg je snel draagvlak binnen het hele bedrijf en kun je het model makkelijker integreren binnen de organisatie. Vervolgens zou je in kleine stappen het model kunnen verbeteren. Probleem van deze aanpak is dat het de meer ondernemende manager wellicht niet snel genoeg gaat. Daarnaast kunnen sommige data scientists en andere inhoudelijk betrokkenen moeite hebben om bij deze aanpak concessies ten aanzien van de voorspellende performance te doen. Wel een voordeel van een start met een eenvoudig model is dat het aan iedereen sneller duidelijk is dat data science een continu proces is en dat onderhoud van modellen nodig is en loont.

De strak plannende manager heeft het vaak juist moeilijk in een data science traject. Er zit altijd een zekere mate van creativiteit in die maakt dat de tijd die nodig is om een model te bedenken onvoorspelbaar is. Bij een strakke planning kan het dan zijn dat het model nog niet af is terwijl er toch geoperationaliseerd moet worden. Een teleurstelling ligt dan op de loer.

Tot slot is de combinatie van SCRUM en data science lastig. In iedere sprint werkende software opleveren is iets anders dan modelinzichten creëren.

Wat is nu de beste aanpak? Het zou te makkelijk zijn om simpelweg te zeggen dat je met alle bovenstaande zaken rekening moet houden. Daarom geef ik een aantal tips die volgens mij goed werken.

  1. Neem ruim de tijd voor verkennende data-analyse (EDA= exploratory data analysis). Dit geeft inzicht in of je 1 of meerdere modellen nodig hebt, aan welke eigenschappen een model zou moeten voldoen en de benodigde complexiteit.

  2. Probeer of je in een vroeg stadium in een proefopstelling verschillende soorten modellen (XGBoost, Moving average, Prophet etc.) naast elkaar kunt laten draaien. De resultaten geven je een indruk van kansrijke modellen. Je krijgt zo ook snel duidelijk of een bepaald type model het voor alle artikelen goed doet, of dat je voor bepaalde artikelgroepen een ander model nodig hebt. Een groot voordeel van deze aanpak is dat je snel output hebt. Daarnaast kun je aantonen dat je met je team productief bent en waarde gaat toevoegen. Ik zou altijd proberen om deze modellen ook later aan te laten staan omdat ze makkelijk een indicatie kunnen geven van verschuivend consumentengedrag.

  3. Zowel bij grote als kleine organisaties zou ik de performance van modellen dagelijks meten en de resultaten automatisch verspreiden naar alle belanghebbenden. Zo weet iedereen direct hoe goed het gaat en kun je een relatie leggen met actuele gebeurtenissen. Je houdt focus en richt je zo automatisch op relevante elementen die nog ontbreken of verfijnd moeten worden in de modellen.

  4. Wees open en transparant over de resultaten en aanpak. Het is belangrijk dat iedereen beseft dat een goed model alleen toegevoegde waarde heeft als de gebruikers er mee kunnen omgaan en dat een ieder begrijpt dat ook het beste model er wel eens naast zit.

Het ontwikkelen van een voorspelmodel blijft ontzettend leuk. Het is een feest om te zien dat iets wat je bedenkt ook met echte data in de praktijk blijkt te werken. Te snelle aannames worden vanuit de data menigmaal ontkracht. Dagelijks bezig zijn met modelleren houdt je scherp van geest en, niet onbelangrijk, helpt om logistieke verspilling tegen te gaan.

Noten

1. Een feature is een individueel meetbare eigenschap die je als voorspellende variabele kunt opnemen in een model.

EDI – de ultieme integratie

Ik ben inmiddels al ruim 13 jaar bezig met EDI. Dat is best lang. Zo lang dat ik bij veel collega’s zelfs bekend sta als “Mister EDI”.

En het is ook alweer zo’n 9 jaar geleden dat ik voor het eerst te maken kreeg met het vakgebied van Integration en Middleware. In mijn geval betreft dat voornamelijk het werken met webMethods.

In al die jaren is mij een aantal zaken opgevallen. Als ik in mijn werk betrokken ben als EDI Architect dan komt heel vaak het volgende voorbij:

  1. EDI? Is dat niet een beetje ouderwets? Die EDI-berichten bestaan al zo’n 20 jaar en zijn nog steeds hetzelfde. Moeten we dat niet eens gaan moderniseren?
  2. Die EDI-berichten zijn wel simpel zeg. Dat is absoluut geen rocket science.
  3. Wisselen we EDI-berichten uit met meer dan 1000 handelspartners? Oh, dat wist ik niet eens.
  4. Hebben we minder dan 10 EDI berichttypen in gebruik om elk jaar miljoenen business transacties uit te wisselen met die handelspartners? Dat is ook niet veel zeg.

In mijn werk als Integration Architect hoor ik vaak heel veel ambities voorbij komen:

  1. We moeten voor onze middleware oplossing goede standaardberichten ontwerpen. Het is belangrijk dat we dit meteen goed doen, want elke aanpassing aan deze berichten brengt, nadat ze zijn geïmplementeerd, grote kosten met zich mee.
  2. Onze standaardberichten moeten generiek worden opgezet zodat verschillende applicaties en/of pakketten hiermee met elkaar kunnen communiceren.
  3. Al onze bedrijfsonderdelen moeten met dezelfde set van standaardberichten kunnen werken.
  4. Dat willen we inderdaad allemaal. Maar we willen dit werk natuurlijk wel allemaal outsourcen en offshoren. Dus houd alles wel enigszins overzichtelijk. We willen geen wildgroei aan berichttypen en versies daarvan.

Tja, dan denk ik soms wel eens: dat ouderwetse EDI, is dat eigenlijk al niet decennia lang de ultieme vorm van Integration?

Hier komt de sidebar

Volg ons op

© Orcado B.V. | 1999 - 2020