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