Maand: november 2020

Omdat het vorige week Thanksgiving was in de VS, wilde ik even stilstaan bij het begrip schaarste en overvloed. Velen in het bedrijfsleven werken met een schaarste-mentaliteit, in de overtuiging dat eigenlijk alles wat ons bezighoudt slechts in beperkte hoeveelheden beschikbaar is. Of het nu gaat om het ‘binnenhalen’ van een klant, promotie of het krijgen van een project waar je om hebt gevraagd, de basisaanname is dat of iemand anders het krijgt of jij het krijgt. Het is een win-verlies situatie.

De reden hiervoor is natuurlijk te vinden in de evolutie van de mens. Gedurende de honderdduizenden jaren dat de voorgangers van de moderne mens op aarde rondzwierven, werd alles gedreven door schaarste. Voedsel was schaars, veilige plekken om te wonen waren schaars, mensen om veilig mee samen te werken waren schaars, enzovoort. En dit vertaalt zich in veel van onze huidige gedragingen in de maatschappij. Bij voetbalwedstrijden wint het ene team en verliest het andere. In televisieshows is er één winnaar. In computerspellen doorlopen de battle royale-spellen opeenvolgende gevechtsronden tot er nog maar één speler over is.

Voor vrijwel iedereen in de westerse wereld is schaarste grotendeels een illusie. We hebben allemaal toegang tot voedsel, een veilige plek om te wonen, toegang tot gezondheidszorg, bescherming tegen bedreigingen, enzovoort. Met de theorie van Maslov als basis, wordt er grotendeels voorzien in onze fysiologische en veiligheidsbehoeften en deze basisbehoeften waren historisch gezien waar schaarste bestond. Onze psychologische behoeften en behoeften aan zelfvervulling zijn meestal niet waar schaarste een probleem is. Als iemand anders een relatie aangaat, vermindert dat niet jouw kansen om een relatie aan te gaan. Als een collega van mij een artikel publiceert, heeft dat geen invloed op mijn mogelijkheden om een artikel te publiceren.

In onze economie en ons bedrijfsleven hebben we dezelfde misvatting van schaarste. De meeste mensen lijken te missen dat de economie voortdurend groeit. Groei van het BBP betekent dat er meer waarde, met geld als proxy, wordt gecreëerd door een economie. Die waarde en dat geld betekenen niet dat een land moest verliezen om een ander land te laten winnen. Op een bepaalde manier creëren we waarde en geld ‘uit het niets’ (zie Wikipedia voor een langere verkenning van dit onderwerp). Dankzij de digitalisering van de samenleving is steeds meer van die waarde digitaal, zoals blijkt uit de waarderingen van technologiegiganten als Microsoft, Facebook en Google. En daardoor zijn de fysieke hulpbronnen van onze planeet steeds minder de bron van waardecreatie, wat een goede zaak is vanuit milieuperspectief.

Het punt dat ik probeer te maken is dat we in een tijdperk van overvloed leven. Voor de meesten van ons geldt dat we vrijwel al onze levensenergie kunnen steken in zelfverwerkelijking en het creëren van een positieve impact op de wereld waarin we leven. We kunnen dit doen door middel van werk, vrijwilligerswerk, relaties, gemeenschapswerk, politiek of wat dan ook. Maar we moeten de wereld om ons heen bekijken door de lens van overvloed, in plaats van de lens van schaarste.

In het bedrijfsleven betekent dit dat een concurrent of partner die het goed doet, niet betekent dat je kansen mist om het goed te doen. Sterker nog, verschillende startups waar ik bij betrokken ben vieren het wanneer bedrijven in dezelfde sector het goed doen, omdat het betekent dat de taart groter wordt. Vooral voor nieuwe bedrijven is het niet de concurrentie waar het om gaat, maar het overwinnen van niet-consumptie, bijvoorbeeld bedrijven die pen en papier blijven gebruiken in plaats van de handige tool die jij hebt gemaakt. Dus, in plaats van te concurreren op het scherpst van de snede met een schaarste-mentaliteit, zoek naar manieren om win-winsituaties te creëren en neem een overvloed-mentaliteit aan. Er is meer dan genoeg voor ons allemaal. Jouw groei helpt mijn groei alleen maar!

Velen die dit lezen zullen ongetwijfeld wijzen op alle pijn en lijden die nog steeds in de wereld bestaan en ik wil dat niet negeren of onder het tapijt vegen. Maar het is een feit dat vrijwel elke metriek met betrekking tot de kwaliteit van leven in de wereld, variërend van oorlogsdoden en mensen die in armoede leven tot kindersterfte en levensverwachting, verbetert en de mensheid heeft nog nooit in een betere tijd geleefd. We leven in het tijdperk van overvloed en ondanks alle problemen in de wereld van vandaag, denk ik dat het goed is om dat te onthouden en er dankbaar voor te zijn.

Deze week was ik aanwezig bij de International Conference on Software Business(ICSOB 2020) en gaf ik een presentatie over autonoom verbeterende systemen. De kerngedachte is dat software-intensieve systemen hun prestaties kunnen meten, weten waarvoor ze moeten optimaliseren en autonoom kunnen experimenteren met hun eigen gedrag.

De geschiedenis van software-intensieve systemen kan worden verdeeld in drie hoofdfasen. In de eerste fase bouwden we systemen volgens een specificatie. Deze specificatie kon afkomstig zijn van de klant of van productmanagers, maar het doel van het R&D team was om een systeem te bouwen dat voldeed aan de eisen in de specificatie.

Veel online bedrijven, maar ook de eerste embedded-systems bedrijven, bevinden zich in de volgende fase. Hier krijgen teams geen specificatie, maar eerder een set van één of meer geprioriteerde KPI’s om te verbeteren. In e-commerce is conversie vaak de belangrijkste KPI; in embedded systemen wordt vaak een gewogen mix van prestatie, betrouwbaarheid en andere kwaliteitsattributen gebruikt. Teams krijgen als doel een of meer van deze KPI’s te verbeteren zonder de andere (significant) te verslechteren. Ze moeten hypotheses hierover ontwikkelen en deze in het veld testen met behulp van bijvoorbeeld A/B-experimenten.

Hoewel de tweede fase voor veel bedrijven een grote stap voorwaarts is, is het probleem dat het nog steeds het team is dat al het zware werk doet. Vooral het uitvoeren van veel A/B-experimenten kan veel moeite kosten. De volgende stap die sommige bedrijven beginnen te verkennen is om het systeem zijn eigen experimenten te laten genereren met de bedoeling te leren over manieren om zijn eigen prestaties te verbeteren. Theoretisch valt dit in de categorie van reinforcement learning, maar het blijkt een hele uitdaging om dit in een empirische, industriële context te realiseren.

De evolutie die bedrijven doormaken om dit derde stadium te bereiken, kan in een model worden gezet, dat de activiteiten en technologieën toont die op elk niveau kunnen worden gebruikt. Vanaf niveau 2 zien we een aantal autonoom verbeterende systeemgedragingen, zoals het toevoegen van intelligente, online selectie van experimenten en het automatisch genereren van experimenten. Dit resulteert in allerlei uitdagingen, waaronder het voorspellen van de slechtste prestaties van de gegenereerde alternatieven. Als een systeem autonoom experimenten genereert en inzet, kunnen sommige van deze experimenten zeer slechte prestaties laten zien, wat betekent dat het systeem modellen nodig heeft om de slechtste uitkomst voor elk experiment te voorspellen, evenals oplossingen om lopende experimenten te annuleren als de prestaties negatief worden beïnvloed.

Met de toenemende prevalentie van AI moeten we beginnen te kijken naar online reinforcement learning in software-intensieve systemen, omdat dit het autonoom verbeteren van systemen zou vergemakkelijken. Deze ambitie gaat gepaard met grote uitdagingen die we nu aan het onderzoeken zijn. Ik moedig je echter aan om te onderzoeken waar de systemen die je bouwt autonoom hun eigen gedrag zouden kunnen verbeteren. Zelfs beginnen in een klein, risicovrij hoekje van het systeem kan heel nuttig zijn om dit paradigma te leren kennen. Het algemene doel is dat elke dag dat ik je product gebruik, ik wil dat het beter wordt!

Onlangs, in een gesprek met een bedrijf over datagedreven worden, liep ik tegen dezelfde uitdaging aan als zo vaak: het bedrijf beweert zoveel gegevens te verzamelen, maar de hoeveelheid waarde die uit die gegevens wordt gegenereerd is erg klein. Je vraagt je af wat er ten grondslag ligt aan deze patronen van, ogenschijnlijk, enorme hoeveelheden gegevens die worden verzameld, maar heel weinig van die gegevens die worden gebruikt om iets van waarde te creëren. Mijn ervaring is dat er ten minste drie factoren een rol spelen: gevoel van eigenaarschap, lokale optimalisatie en de kosten van het ‘produceren’ van gegevens.

Een typisch patroon in veel organisaties is dat teams die gegevens genereren en verzamelen voor hun doeleinden, zich sterk eigenaar voelen van die gegevens en niet willen dat anderen met hun grote, dikke vingers aan “hun gegevens” komen peuteren. Het is van hen en als iemand anders soortgelijke gegevens nodig heeft, kunnen ze die zelf gaan verzamelen in plaats van ze gratis van het team te krijgen.

Dit leidt tot veel kleine eilandjes van gegevens die volledig losgekoppeld zijn en niet samenkomen in iets dat waardevoller is dan de som der delen. Teams kunnen opscheppen over al hun gegevens, maar niemand anders kan ze gebruiken.

Elk team dat besluit dat ze gegevens nodig hebben om de kwaliteit van hun beslissingen te verbeteren, zal zich richten op hun eigen uitdaging en alleen verzamelen wat ze nodig hebben op het niveau van detail, frequentie en aggregatie dat ze nodig hebben. Bovendien kunnen ze op elk moment beslissen om de manier waarop gegevens worden verzameld en welke gegevens worden verzameld fundamenteel te veranderen.

Het gevolg is dat de gegevens meestal moeilijk te gebruiken zijn buiten de onmiddellijke context waarvoor ze gegenereerd werden. Dit leidt ertoe dat verschillende teams zeer gelijkaardige gegevens verzamelen door een gebrek aan coördinatie. Ook kunnen teams die zich realiseren dat ze gegevens nodig hebben, omdat weinig teams nadenken over het bredere gebruik, de bestaande gegevens niet hergebruiken omdat ze zo specifiek zijn voor de use case waarvoor ze zijn verzameld.

Als een team besluit om zijn gegevens beschikbaar te stellen voor anderen, moet het documentatie over de semantiek van de gegevens verstrekken, een systeem opzetten voor het vinden en downloaden van gegevenssets, ervoor zorgen dat wijzigingen in de manier waarop gegevens worden verzameld, de semantiek, enzovoort, zorgvuldig worden gecommuniceerd met belanghebbenden en natuurlijk reageren op verzoeken van deze belanghebbenden en wijzigingen aanbrengen in de gegevensverzamelingsprocessen, niet om er zelf beter van te worden, maar om anderen in de organisatie te helpen. En, last but not least, kan het team gemakkelijk verantwoordelijk worden gehouden voor privacy, GDPR, beveiliging en andere zorgen die bedrijven hebben rond de opgeslagen gegevens.

Het gevolg is dat, tenzij er een tegenkracht aanwezig is, teams actief zullen proberen om gegevens niet te delen vanwege de moeite en de kosten van het delen met anderen in de organisatie. Dit leidt weer tot veel gegevens die worden vastgelegd, opgeslagen en gebruikt voor specifieke, smalle use cases, maar geen synergie, geen end-to-end begrip van systemen in het veld en de manier waarop klanten ze gebruiken, enzovoort.

De oplossing voor deze uitdagingen is een hiërarchische benadering van waardemodellering waarbij je top-down bedrijfs-KPI’s verbindt met meetgegevens op een lager niveau die direct uit het veld kunnen worden verzameld. Door deze hiërarchische, acyclische, gerichte grafiek op te bouwen en de relatie tussen factoren op hoger en lager niveau kwantitatief vast te stellen, kunnen we eindelijk beginnen met het genereren van bedrijfswaarde uit alle gegevens die we verzamelen.

Het is niet eenvoudig om van de huidige staat naar dit hiërarchische waardemodel te gaan, al was het maar omdat de meeste mensen in de bedrijven waar ik mee werk het extreem moeilijk vinden om te bepalen voor welke kwantitatieve factoren we optimaliseren, en als we het al weten, is de relatieve prioriteit van deze factoren een bron van aanzienlijke discussie. Het biedt echter enorme voordelen, omdat je het verzamelen van gegevens kunt richten op de dingen die er toe doen, de gegevens kunt gebruiken om beslissingen van hogere kwaliteit te nemen en op gegevens gebaseerde aanbiedingen aan klanten kunt doen die je anders niet had kunnen doen. Zoals het gezegde luidt: het gaat er niet om wat je hebt, maar hoe je het gebruikt!

Een ingenieur vraagt:

Ik werk al vele jaren als chief design engineer. Toch krijg ik regelmatig te horen dat ik beter moet communiceren. Inmiddels ben ik op het punt gekomen dat ik wat verbeteringen wil aanbrengen, maar wat bedoelen ze precies met “beter communiceren” en hoe doe ik dat?

De communicatietrainer antwoordt:

Goede communicatievaardigheden zijn nodig om goed samen te werken in complexe projecten. Het komt erop neer dat je weet hoe je een boodschap geeft en hoe je de informatie die iemand anders je geeft op de juiste manier ontvangt. De noodzakelijke voorwaarde om dit te laten slagen is contact tussen zender en ontvanger.

Contact maak je door aandacht te besteden aan de persoon met wie je praat. Je moet dus interesse tonen in de ander. Als de ander ook aandacht voor jou heeft, is het contact gelegd. Vergelijk het met het bellen van een collega. Op het moment dat de verbinding er is en de lijn geruisloos is, kun je dingen gaan bespreken.

Door actief te luisteren, zorg je ervoor dat je de boodschap van de ander begrijpt. Dit doe je door toe te passen: luisteren, samenvatten en vervolgvragen stellen. Luisteren betekent aandacht hebben voor de ander. Je vat samen door bijvoorbeeld te zeggen: “Oké, ik begrijp dat …” of “Oké, ik hoor je dit en dat zeggen, klopt dat?”. De andere persoon hoort wat je hebt geleerd en krijgt de bevestiging dat je het goed hebt begrepen, of hij heeft de gelegenheid om wat correcties aan te brengen of het niveau van zijn uitleg aan te passen aan het niveau van jouw begrip. In beide gevallen is dit prettig voor degene die vertelt en schept het duidelijkheid.

Wanneer je je boodschap verstuurt, is het belangrijk om zo concreet mogelijk te zijn. Kwantificeer waar je kunt. Dit maakt je verhaal altijd beter. Stem je verhaal af op het begripsniveau en de focus van de ander. Wat wil de ander weten? Waarschijnlijk is je projectmanager vooral geïnteresseerd in de planning, risico’s of kosten en minder in technische details. De salesmanager is waarschijnlijk meer geïnteresseerd in de gevolgen voor zijn klant dan in het probleem zelf. Je kunt dit van tevoren inschatten en er rekening mee houden in je verhaal.

Maar nu het belangrijkste. Het spel van zenden en ontvangen verloopt zelden soepel. Simpelweg omdat we allemaal ons eigen referentiekader hebben en elkaar dus niet meteen begrijpen. Het is daarom uiterst belangrijk dat je altijd oplet of je boodschap overkomt en dat je reageert als dat niet zo is.

Je merkt dat je boodschap overkomt als de ander aandachtig naar je verhaal luistert en misschien af en toe instemmend knikt. Als de ander echter plotseling van houding verandert, fronst of iets begint te zeggen, kan dit een teken zijn dat je boodschap niet goed overkomt. Het kan zijn dat de ander iets niet begrijpt, een interessante associatie heeft of het er niet mee eens is. Je weet het pas als je het controleert.

En dat laatste is dus wat je moet doen. Doorgaan met je eigen verhaal terwijl de ander afdwaalt in zijn eigen gedachten bereikt weinig. Op het moment dat je merkt dat er iets gebeurt met de aandacht van de ander, draait de communicatie honderdtachtig graden en schakel je over van zenden naar ontvangen. Je vraagt: ”Ik zie je fronsen, vertel …” of ”Wil je iets zeggen, vertel …”. Op deze manier schommelt de communicatie heen en weer en kom je snel tot helderheid.

Moet je onmiddellijk stoppen met je verhaal bij elke spier die de ander vertrekt? Nee, maar het is wel aan te raden om je altijd bewust te blijven van de reactie van de ander op je verhaal terwijl je het vertelt. Check het in ieder geval om de zoveel tijd door te vragen: “Hoe klinkt het tot nu toe? Op die manier nodig je de ontvanger van je boodschap uit om te reageren en krijg je feedback over hoe je verhaal is aangekomen.

De afgelopen weken ben ik met verschillende bedrijven in gesprek geweest en hetzelfde probleem deed zich voor: mijn contactpersonen stelden een verandering aan de orde die ze in hun organisatie wilden realiseren en vroegen me om hulp bij het realiseren ervan. Toen ik vroeg hoe ze in de situatie terecht waren gekomen die deze verandering noodzakelijk maakte, waren de meesten stomverbaasd – het was duidelijk dat ze hier niet aan hadden gedacht.

Natuurlijk zijn we als ingenieurs getraind om in oplossingen te denken en velen van ons volgen die training op de voet. Het ontwikkelen van een oplossing voor een probleem dat eigenlijk een symptoom en het gevolg van iets anders is, is echter volkomen nutteloos omdat de kans dat de oplossing iets oplost net zo groot is als de overlevingskans van een sneeuwvlok in de hel.

Verschillende R&D-afdelingen willen bijvoorbeeld continuous deployment of DevOps introduceren in hun bedrijf, maar stuiten op sterke weerstand van sales en customer support. Velen klagen dat de mensen aan de andere kant van het hek het gewoon niet snappen. Als je de situatie echter analyseert, is het duidelijk dat de introductie aanzienlijke kosten met zich meebrengt en een fundamenteel andere relatie met klanten. En zonder een businessmodel om de continue levering van waarde te gelde te maken, heeft het geen zin om DevOps in te voeren. Dus, in plaats van te benadrukken dat de mensen aan de zakelijke kant idioten zijn, werk samen met hen om uit te zoeken hoe je bedrijfsmodellen en klantbetrokkenheidsmodellen kunt creëren die zinvol zijn en werk vervolgens samen met leidende klanten om te experimenteren met dit nieuwe model.

Velen kennen de “regel van 5 waarom’s”: het idee om na het observeren van een probleem vijf keer “waarom” te vragen om van de waargenomen symptomen naar de werkelijke hoofdoorzaken te gaan. De uitdaging is dat deze regel in de praktijk lang niet zo vaak wordt gevolgd als zou moeten.

Een verwante en volgende uitdaging is dat zelfs als we de hoofdoorzaak hebben geïdentificeerd en een idee hebben om het op te lossen, er een enorme weerstand in de organisatie is om alles te implementeren wat nodig is om daadwerkelijk vooruitgang te boeken. In plaats daarvan is er de neiging om de implementatie van iets kleins te ondersteunen, zodat het voor iedereen in het bedrijf aanvaardbaar is. Het resultaat is vaak een verwaterd en verkleind voorstel dat brede steun krijgt, maar dat weinig meer biedt dan een symbolische inspanning met weinig echte impact op het bedrijf. In het algemeen is mijn ervaring dat hoe meer een organisatie gepolitiseerd is, hoe meer ze geneigd is zich te richten op symptomen in plaats van op de hoofdoorzaken en hoe meer ze geneigd is zich te richten op verwaterde veranderingsinitiatieven die de illusie van actie wekken maar niet leiden tot echte verandering.

Mijn advies ligt voor de hand. Gebruik eerst je intelligentie en ervaring om een goed begrip te ontwikkelen van de onderliggende oorzaken van waargenomen verschijnselen. Trap niet in de val om te geloven wat iedereen gelooft. Ten tweede, gebruik je sociale en interactievaardigheden om je begrip met anderen te bevestigen en een gemeenschappelijk platform op te bouwen van een op de onderliggende oorzaken gericht begrip. Ten derde, als je eenmaal een gemeenschappelijk begrip hebt vastgesteld, onderzoek dan meerdere (in plaats van slechts één) wegen om de geïdentificeerde hoofdoorzaak aan te pakken en bouw een platform op voor de weg die de vereiste impact heeft terwijl de bijkomende schade tot een minimum wordt beperkt. Ten vierde, als er voldoende overeenstemming is, ga dan verder met de uitvoering op een iteratieve, experimentele manier waarbij je één end-to-end deel van de organisatie door de verandering haalt, de impact observeert en meet, dienovereenkomstig aanpast en verder gaat met het volgende deel. Vind gedurende dit alles de juiste balans tussen het aansturen en toegewijd zijn aan het realiseren van de verandering en een objectieve, reflectieve houding waarbij je in staat bent om de nadelen van de verandering en de noodzaak voor aanpassing waar nodig te identificeren.

Zoals de boeddhisten zeggen, ligt het verschil in het kleine venster tussen trigger en reactie. In plaats van instinctief te reageren op wat het leven je voor de voeten werpt, sta je even stil, denk je na en neem je een beslissing over een actie die daadwerkelijk resulteert in wat je wilt bereiken. Met andere woorden, denk in plaats van te reageren.

Onlangs heb ik als expert een workshop verzorgd bij een bedrijf dat datagedreven wilde worden. Anders dan de productbedrijven waar ik normaal gesproken mee werk, is dit bedrijf een dienstverlener met een groot aantal medewerkers die diensten aanbieden aan klanten. Tot de deelnemers aan de workshop behoorden de CEO en het hoofd bedrijfsontwikkeling, evenals verschillende anderen die deel uitmaken van het managementteam van het bedrijf of daar dicht bij staan.

In veel opzichten lijkt dit de ideale opstelling te zijn, omdat je ervan uitgaat dat we alle managementondersteuning hebben die we nodig hebben en een aantal van de slimste mensen in het bedrijf bij ons hebben. Dit werd zelfs versterkt doordat verschillende mensen in het bedrijf vertelden dat ze al heel lang met gegevens werken. Desondanks liepen we tegen een aantal aanzienlijke uitdagingen aan en kwamen we lang niet zo ver als we hadden gehoopt.

De eerste uitdaging was om concreet te worden over specifieke hypotheses om te testen. Hoewel we concrete voorbeelden van hypotheses en bijbehorende experimenten deelden toen we begonnen met brainstormen en teamwerk, had iedereen het ongelooflijk moeilijk om van een doel op hoog niveau, het verhogen van een specifieke bedrijfs-KPI, bijvoorbeeld klanttevredenheid, naar een specifieke hypothese en een bijbehorend concreet experiment te gaan. Daar zijn veel redenen voor. Een voor de hand liggende is dat veel mensen vinden dat ‘iemand’ ‘iets moet doen’ aan datgene waarover ze zich zorgen maken, maar nooit veel hersencycli besteden aan het nadenken over hoe dat eruit zou zien.

De tweede uitdaging was dat voor alle gegevens die het bedrijf tot zijn beschikking had, de gegevens die relevant waren in de betreffende situatie vaak niet beschikbaar waren. Veel bedrijven waar ik mee werk beweren dat ze heel veel gegevens hebben en velen in de organisatie zijn dan echt verbaasd dat ‘gewoon’ de gegevens die ze nodig hebben niet zijn vastgelegd. Als je erover nadenkt, ligt het voor de hand dat dit het geval zou zijn, aangezien het aantal hypotheses dat je kunt formuleren vrijwel oneindig is en de kans dat gegevens niet beschikbaar zijn dus vrij groot is.

De derde uitdaging waar we tegenaan liepen was dat zelfs in de gevallen waarin de gegevens beschikbaar waren, deze geaggregeerd bleken te zijn en/of een te lage registratiefrequentie hadden om relevant te zijn voor het doel dat we voor ogen hadden. Dus, we hebben de gegevens, maar ze zijn in een vorm die niet de analyse mogelijk maakt die we willen doen.

De reactie op deze uitdagingen is, zoals je zou verwachten, erop uit gaan en verzamelen wat we nodig hebben om het experiment voort te zetten om tot een bevestiging of verwerping van de hypothese te komen. Het grappige besef dat ik had, is dat hoe relevanter en belangrijker de hypothese is vanuit een zakelijk perspectief, hoe waarschijnlijker het is dat het te maken heeft met regelgevende beperkingen die beperken wat kan worden verzameld zonder door een heleboel disclaimers en toestemmingen te gaan. We kwamen dus in de situatie terecht dat verschillende veelbelovende hypotheses niet testbaar waren vanwege juridische beperkingen.

Tot slot, zelfs als we een specifieke hypothese en bijbehorend experiment hadden en we in staat waren om de gegevens te verzamelen die we nodig hadden, bleek het ontzettend moeilijk om op te schalen naar het punt van statistische significantie. Het uitvoeren van een grootschalig experiment dat een behoorlijke kans op mislukking heeft, maar dat erg duur en riskant is om uit te voeren, doet het doel van experimenteren een beetje teniet.

Een datagestuurde organisatie worden is een van de belangrijkste doelen die elk bedrijf zou moeten hebben. Het zorgt voor een veel hogere kwaliteit van besluitvorming en activiteiten en bereidt je voor op het gebruik van AI als een belangrijke differentiator en enabler. De stap van woord naar daad is echter een uitdagende reis waarbij je idealiter leert van de fouten van anderen voordat je zelf nieuwe fouten maakt. We hebben de gegevens nodig, maar we moeten het slim uitvoeren.