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!
Hoe ontwikkel je een voorspelmodel voor de vraag naar levensmiddelen?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.
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.
1. Een feature is een individueel meetbare eigenschap die je als voorspellende variabele kunt opnemen in een model.
Hier komt de sidebar