Maand: januari 2020

In recente columns heb ik mijn mening gegeven over de kwaliteit van de gegevens die veel bedrijven in hun datawarehouses, -meren of -moerassen hebben staan. Mijn ervaring is dat de meeste gegevens die bedrijven zo zorgvuldig hebben opgeslagen nutteloos zijn en nooit enige waarde voor het bedrijf zullen genereren. De gegevens die wel potentieel bruikbaar zijn, vereisen vaak enorme hoeveelheden voorbewerking voordat ze bijvoorbeeld voor machine learning kunnen worden gebruikt. Als gevolg hiervan wordt in de meeste data science teams meer dan 90 procent van alle tijd besteed aan het voorbewerken van de gegevens voordat ze zelfs maar kunnen worden gebruikt voor analytics of machine learning.

In een artikel dat we onlangs hebben ingediend, hebben we dit probleem bestudeerd voor systeemlogs. Vrijwel elk software-intensief systeem genereert gegevens die de toestand en belangrijke gebeurtenissen in het systeem op belangrijke tijdstippen vastleggen. De uitdaging is dat aan de ene kant de gegevens die worden vastgelegd in logs bedoeld zijn voor menselijke consumptie en dus een grote variabiliteit bevatten in de structuur, inhoud en type van de informatie voor elke logboekvermelding. Anderzijds is de hoeveelheid gegevens die is opgeslagen in logs vaak fenomenaal groot. Het is niet ongewoon dat systemen gigabytes aan gegevens genereren voor zelfs maar één enkele operationele dag.

Het voor de hand liggende antwoord op dit raadsel is om machine learning te gebruiken om de relevante informatie uit de systeemlogs af te leiden. Deze aanpak kent een aantal belangrijke uitdagingen vanwege de manier waarop logs worden gegenereerd. Op basis van ons onderzoek in de literatuur en bedrijfscases hebben we verschillende uitdagingen geïdentificeerd.

Door de aard van de gegevensgeneratie vereisen de logbestanden uitgebreide voorbewerking, wat de waarde vermindert. Het komt ook vaak voor dat meerdere systeemprocessen in hetzelfde logbestand schrijven, wat tijdreeksanalyse en andere machine learning technieken die uitgaan van sequentiële data bemoeilijkt. Omgekeerd genereren veel systemen meerdere soorten logbestanden en voor het vaststellen van een betrouwbare grondwaarheid is het nodig om gegevens uit meerdere logbestanden te combineren. Deze logbestanden bevatten vaak gegevens op fundamenteel verschillende abstractieniveaus, wat het trainen van modellen voor machinaal leren bemoeilijkt. Als we eenmaal in staat zijn om machine learning modellen toe te passen op de voorbewerkte gegevens, vereist de interpretatie van de resultaten vaak uitgebreide domeinkennis. Ontwikkelaars zijn vrij om nieuwe code aan het systeem toe te voegen die logboekvermeldingen in ad-hoc formaten genereert. Het veranderende formaat van logbestanden bemoeilijkt het gebruik van meerdere logs voor het trainen van machine-learning modellen, omdat de logs niet noodzakelijkerwijs vergelijkbaar zijn. Tot slot, alle tools die gebouwd zijn om logbestanden te verwerken, zoals geautomatiseerde parsers, falen onvoorspelbaar en zijn erg broos, waardoor constant onderhoud nodig is.

We hebben het probleem specifiek bestudeerd voor systeemlogs, maar mijn ervaring is dat onze bevindingen vrij typerend zijn voor vrijwel elk type geautomatiseerde gegevensgeneratie. Hoewel dit een enorm probleem is voor bijna alle bedrijven waar ik mee werk en er enorme hoeveelheden middelen worden besteed aan het voorbewerken van gegevens om er waarde uit te halen, is het een verloren strijd. De hoeveelheid gegevens die wordt gegenereerd in elk product, door klanten, in het hele bedrijf, enzovoort, zal alleen maar toenemen. Als we dit probleem niet aanpakken, zal elke datawetenschapper, ingenieur en wiskundige binnenkort weinig anders meer doen dan data voorbewerken.

De oplossing, zoals we die in het artikel voorstellen, is vrij eenvoudig: in plaats van eerst de gegevens te genereren en ze dan voor te bewerken, moeten we software bouwen om gegevens te genereren in een formaat dat helemaal geen voorbewerking vereist. Alle gegevens moeten zo worden gegenereerd dat ze onmiddellijk en automatisch kunnen worden gebruikt voor machinaal leren. Bij voorkeur zonder menselijke tussenkomst.

Het bereiken van dit doel is iets ingewikkelder dan wat ik in deze post kan schetsen, maar er zijn een aantal belangrijke elementen die volgens mij gemeenschappelijk zijn voor elke benadering die dit doel nastreeft. Ten eerste moeten alle gegevens numeriek zijn. Ten tweede moeten alle gegevens van het nominale type (verschillende elementen hebben geen volgorde of relatie tot elkaar) een-hot gecodeerd zijn, wat betekent dat de elementen worden weergegeven in een binaire tekenreeks die net zo lang is als het aantal elementtypes. Ten derde kunnen gegevens van het ordinale type dezelfde aanpak gebruiken of, in het geval van niet-dichotome gegevens, een verscheidenheid aan coderingen. Ten vierde moeten interval- en ratiogegevens worden genormaliseerd (in kaart gebracht naar een waarde tussen 0 en 1) voor optimaal gebruik door machine- en deep-learningalgoritmen. Ten vijfde moet, waar nodig, de statistische verdeling van de gegevens in kaart worden gebracht naar een standaard Gaussiaanse verdeling voor betere trainingsresultaten.

Om dit te bereiken op het moment dat gegevens worden gegenereerd, moeten ingenieurs en ontwikkelaars mogelijk samenwerken met datawetenschappers. Daarnaast vraagt het om afstemming binnen de hele organisatie, wat tot nu toe niet nodig was. Door dit te doen, kunnen bedrijven echter systemen bouwen die volledig autonoom modellen voor machine learning kunnen verzamelen, trainen en hertrainen en deze kunnen inzetten zonder menselijke tussenkomst (zie de figuur).

Systeemregistratie voor machinaal leren

Concluderend zijn de meeste gegevens in de meeste bedrijven nutteloos omdat ze op de verkeerde manier zijn gegenereerd en zonder de juiste structuur, codering en standaardisatie. Vooral voor het gebruik van deze gegevens in het trainen van modellen voor machinaal leren is dit problematisch, omdat het uitgebreide hoeveelheden gegevensvoorbewerking vereist. In plaats van onze activiteiten op het gebied van gegevensvoorbewerking te verbeteren, moeten we gegevens genereren op een manier die voorbewerking helemaal overbodig maakt. Datawetenschappers en -ingenieurs zouden er baat bij hebben als ze zich zouden richten op hoe gegevens gegenereerd moeten worden. In plaats van achteraf te proberen de rommel op te ruimen, moeten we om te beginnen proberen geen rommel te maken.

In het big data tijdperk was een van de belangrijkste uitgangspunten voor het succesvol realiseren van je big data strategie het creëren van een centraal datawarehouse of data lake waar alle gegevens werden opgeslagen. De data-analisten konden dan naar hartenlust hun analyses uitvoeren en relevante correlaties, uitschieters, voorspellende patronen en dergelijke vinden. In dit scenario draagt iedereen zijn gegevens bij aan het data lake, waarna een centrale data science-afdeling deze gebruikt om, meestal uitvoerende, ondersteuning te bieden bij het nemen van beslissingen (figuur 1).

Figuur 1: Iedereen draagt zijn gegevens bij aan het data lake, waarna een centrale data science-afdeling deze gegevens gebruikt om, meestal uitvoerende, ondersteuning te bieden bij het nemen van beslissingen.

 

Hoewel dit er in theorie geweldig uitziet, is de realiteit in veel bedrijven natuurlijk heel anders. We zien ten minste vier uitdagingen. Ten eerste vereist het analyseren van gegevens van producten en klanten in het veld vaak aanzienlijke domeinkennis die datawetenschappers op een centrale afdeling meestal ontberen. Dit leidt gemakkelijk tot onjuiste interpretaties van gegevens en dus tot onnauwkeurige resultaten.

Ten tweede doen verschillende afdelingen en groepen die gegevens verzamelen dit vaak op verschillende manieren, wat resulteert in gegevens die er ongeveer hetzelfde uitzien maar een verschillende semantiek hebben. Dit kunnen kleine verschillen zijn, zoals de frequentie waarmee gegevens worden gegenereerd, bijvoorbeeld seconden, minuten, uren of dagen, maar ook veel grotere verschillen, zoals gegevens over individuele producten in het veld versus vergelijkbare gegevens over een hele productfamilie in een specifieke categorie. Omdat datawetenschappers op een centrale afdeling vaak proberen om gegevens uit verschillende bronnen met elkaar in verband te brengen, kunnen er gemakkelijk onjuiste conclusies worden getrokken.

Ten derde, vooral door de toenemende toepassing van DevOps, zal zelfs dezelfde bron na verloop van tijd andere gegevens genereren. Als de software evolueert, verandert de manier waarop gegevens worden gegenereerd meestal mee, wat leidt tot soortgelijke uitdagingen als hierboven beschreven. Het resultaat is dat de belofte van het big data tijdperk niet altijd uitkomt bij bedrijven en bijna nooit in de volle omvang die werd verwacht bij de start van het project.

Tot slot, om waarde te halen uit big data analytics heb je een sterke data science skillset nodig en er zijn gewoon niet zoveel mensen die deze skillset hebben. Het is een hele uitdaging om je bestaande personeel te trainen in data science-vaardigheden en het is zeker moeilijker dan om engineers en ontwikkelaars te trainen in machine learning.

Velen in de sector zijn van mening dat toepassingen voor kunstmatige intelligentie, en in het bijzonder machine- en deep-learningmodellen, met dezelfde uitdagingen te kampen hebben. Maar hoewel zowel data analytics als ML/DL-modellen sterk gebaseerd zijn op gegevens, is het belangrijkste verschil dat er voor ML/DL geen gecentraliseerd datawarehouse hoeft te worden opgezet. In plaats daarvan kan elk team, bedrijfsonderdeel of productorganisatie aan de slag met AI zonder uitgebreide coördinatie met de rest van het bedrijf.

Elk bedrijfsonderdeel kan zijn eigen ML/DL-modellen bouwen en deze implementeren in het systeem of de oplossing waarvoor ze verantwoordelijk zijn (afbeelding 2). De gegevens kunnen afkomstig zijn van het data lake of van de lokale oplossingen voor gegevensopslag, dus je hoeft niet eens te hebben gekozen voor de aanpak van gecentraliseerde gegevensopslag voordat je begint met het gebruik van ML/DL.

Afbeelding 2: Elke business unit kan zijn eigen ML/DL-modellen bouwen en deze implementeren in het systeem of de oplossing waarvoor ze verantwoordelijk zijn.

Concluderend, AI is **niet** data analytics en vereist niet dezelfde randvoorwaarden. In plaats daarvan kun je vandaag al beginnen met de gegevens die je beschikbaar hebt, zelfs als jij en je team maar aan één functie of subsysteem werken. Kunstmatige intelligentie en vooral deep learning bieden geweldige mogelijkheden om kosten te verlagen en nieuwe zakelijke kansen te creëren. Het is de meest opwindende technologie die in misschien wel tientallen jaren tot wasdom is gekomen. In plaats van te wachten tot de rest van de wereld je inhaalt, kun je vandaag beginnen met het gebruik van AI en DL.

Vrijwel alle organisaties waar ik mee werk hebben terabytes of zelfs petabytes aan gegevens opgeslagen in verschillende databases en bestandssystemen. Er is echter een interessant patroon dat ik de afgelopen maanden ben gaan herkennen. Aan de ene kant zijn de gegevens die worden gegenereerd bijna altijd bedoeld voor menselijke interpretatie. Bijgevolg staan er veel alfanumerieke gegevens, opmerkingen en andere ongestructureerde gegevens in deze bestanden en databases. Aan de andere kant is de omvang van de opgeslagen gegevens zo fenomenaal groot dat een mens er onmogelijk kop of staart aan kan knopen.

Het gevolg is dat er enorme hoeveelheden tijd nodig zijn om de gegevens voor te bewerken om ze bruikbaar te maken voor het trainen van machine-learningmodellen of voor inferentie met behulp van al getrainde modellen. Datawetenschappers bij een aantal bedrijven hebben me verteld dat zij en hun collega’s hier meer dan 90 procent van hun tijd en energie aan besteden.

Voor de meeste organisaties is de enige manier om enige waarde te genereren uit de enorme hoeveelheden gegevens die zijn opgeslagen op hun servers, dan ook om er heel veel personeel tegenaan te gooien. Omdat de business case om dit te doen vaak onduidelijk of onvoldoende is, is de enige logische conclusie dat de overgrote meerderheid van de gegevens die bij bedrijven zijn opgeslagen gewoon nutteloos zijn. Het is dood gewicht en zal nooit enige relevante bedrijfswaarde genereren. Hoewel het gezegde luidt dat “gegevens de nieuwe olie zijn”, is de realiteit dat de meeste gegevens modder zijn die doet alsof het olie is.

Zelfs als de gegevens relevant zijn, zijn er verschillende uitdagingen verbonden aan het gebruik ervan in analytics of machine learning. De eerste is actualiteit: als je een dataset hebt van bijvoorbeeld klantgedrag die 24, 12 of zelfs maar 6 maanden oud is, is het zeer waarschijnlijk dat je klantenbestand geëvolueerd is en dat voorkeuren en gedrag veranderd zijn, waardoor je dataset ongeldig wordt.

Ten tweede, vooral in bedrijven die vaak nieuwe software uitbrengen, zoals bij het gebruik van DevOps, is het probleem dat bij elke softwareversie de manier waarop gegevens worden gegenereerd kan zijn veranderd. Vooral als de gegevens worden gegenereerd voor menselijk gebruik, bijvoorbeeld engineers die systemen in bedrijf debuggen, is het tijdrovend om datasets samen te voegen die door verschillende versies van de software zijn geproduceerd.

Ten derde worden in veel organisaties continu meerdere gegevenssets gegenereerd, zelfs door hetzelfde systeem. Om de informatie af te leiden die echt relevant is voor het bedrijf, moeten vaak gegevens uit verschillende sets worden gecombineerd. De uitdaging is dat verschillende gegevenssets mogelijk niet dezelfde manier van tijdstempelen gebruiken, gegevens op zeer verschillende abstractieniveaus en frequentie kunnen opslaan en op zeer onvoorspelbare manieren kunnen evolueren. Hierdoor kost het combineren van gegevens veel moeite en is automatisering die voor dit doel is ontwikkeld erg broos en zal waarschijnlijk onvoorspelbaar falen.

Mijn belangrijkste boodschap is dat we, in plaats van ons te richten op het voorbewerken van gegevens, veel meer tijd en aandacht moeten besteden aan hoe de gegevens in eerste instantie worden geproduceerd. Het doel moet zijn om gegevens zo te genereren dat ze helemaal geen voorbewerking nodig hebben. Dit opent een groot aantal gebruikssituaties en mogelijkheden die ik in toekomstige artikelen zal bespreken.

Concluderend: ondanks alle aandacht voor gegevens, is het een feit dat de meeste gegevens in de meeste bedrijven nutteloos zijn of onbetaalbare hoeveelheden menselijke inspanning vereisen om de waarde die ze bevatten te ontsluiten. In plaats daarvan moeten we ons richten op hoe we gegevens genereren. Het doel moet zijn om dat op zo’n manier te doen dat de gegevens zonder enige voorbewerking kunnen worden gebruikt voor analyses en machine learning. Ruim dus de rotzooi op, verwijder de nutteloze gegevens en genereer gegevens op manieren die echt zinvol zijn.

 

Bij reinforcement learning (een vakgebied binnen AI) moeten algoritmen leren over een nog niet verkende ruimte. Deze algoritmen moeten een evenwicht vinden tussen exploratie (leren over nieuwe opties en mogelijkheden) en exploitatie (de verworven kennis gebruiken om een goed resultaat te genereren). De algemene vuistregel is dat hoe minder er bekend is over het probleemdomein, hoe meer het algoritme zich moet richten op exploratie. Evenzo geldt dat hoe beter het probleemdomein wordt begrepen, hoe meer het algoritme zich moet richten op exploitatie.

De balans tussen exploratie en exploitatie geldt ook voor bedrijven. De meeste bedrijven hebben lange tijd gewerkt in een zakelijk ecosysteem dat stabiel was en goed werd begrepen. Er waren natuurlijk concurrenten, maar iedereen gedroeg zich in principe hetzelfde, kreeg ongeveer op hetzelfde moment toegang tot nieuwe technologieën, reageerde op dezelfde manier op klanten, enzovoort. In een dergelijke context richt een bedrijf zich van nature meer en meer op exploitatie omdat de beloning voor exploratie laag is. Dit is precies wat ik zie in veel van de organisaties waar ik mee werk: ondanks al het gepraat over innovatie en bedrijfsontwikkeling, is het resultaat bijna altijd duurzame innovaties die het bestaande product- of oplossingenportfolio een beetje beter maken.

Nu digitalisering en de bijbehorende technologieën – software, data en AI – industrie na industrie steeds meer in hun greep krijgen, wordt het stabiele bedrijfsecosysteem op nieuwe en onvoorspelbare manieren verstoord. Veel bedrijven komen er op de harde manier achter dat hun klanten nooit om hun product hebben gegeven. In plaats daarvan had de klant een behoefte en was jouw product toevallig de beste manier om aan die behoefte te voldoen. Wanneer een nieuwkomer een nieuwe oplossing biedt die beter aan de behoefte voldoet, wordt jouw product vervangen door deze nieuwe oplossing.

De enige manier om deze uitdaging aan te gaan is door de hoeveelheid exploratie die je bedrijf uitvoert aanzienlijk te verhogen – we hebben het over echte exploratie, waarbij de uitkomst van de inspanningen onbekend is en waarbij iedereen begrijpt dat de meerderheid van de initiatieven zal mislukken. Om dit te bereiken, heb je echter een spelplan nodig. Dit gameplan moet ten minste vier elementen bevatten: strategische toewijzing van middelen, minder inspanningen voor standaardfunctionaliteit, verkenning van nieuwe bedrijfsecosystemen en/of nieuwe posities in het bestaande bedrijfsecosysteem en verkenning van ontwrichtende innovatie-inspanningen die mogelijk worden gemaakt door data en AI.

Veel bedrijven wijzen het overgrote deel van hun middelen toe aan hun grootste activiteiten. Dit klinkt intuïtief logisch, maar het biedt geen longitudinaal perspectief op de uitdaging van middelentoewijzing. Een model dat zeer nuttig kan zijn in deze context is het drie horizonten model. Dit model structureert de bedrijven waarin het bedrijf actief is in drie groepen. Horizon één zijn de grote, gevestigde bedrijven die vandaag de rekeningen betalen. Horizon twee zijn de nieuwe, snelgroeiende bedrijven die echter veel kleiner zijn dan de bedrijven van horizon één. Het is de bedoeling dat dit onze toekomstige horizon één bedrijven worden. Horizon drie zijn alle nieuwe, onbewezen innovatie-initiatieven en bedrijven waarvan het onzeker is of ze zullen slagen, maar die de voedingsbodem vormen voor toekomstige horizon twee bedrijven. De toewijzing van middelen zou horizon één middelen moeten beperken tot maximaal 70% van het totaal. Horizon twee moet maximaal 20% krijgen en minstens 10% van de totale bedrijfsmiddelen moet worden toegewezen aan horizon drie.

Binnen horizon één zou elk bedrijf zijn grondstoffengebruik langzamer moeten laten groeien dan de inkomstengroei. Dat zou kunnen betekenen dat een horizon één bedrijf dat met 5% per jaar groeit, zijn grondstoffenverbruik met 5% per jaar zou moeten verminderen, omdat dit bedrijf verondersteld wordt te fungeren als melkkoe om de ontwikkeling van toekomstige horizon één bedrijven te financieren.

In de meeste bedrijven zijn omzet en middelentoewijzing nauw op elkaar afgestemd, maar dit is een vergissing vanuit een langetermijnperspectief. Een nieuw bedrijf zal jaren van investeringen vergen voordat het de status van horizon één kan bereiken en dit nieuwe bedrijf kan zichzelf niet financieren. Natuurlijk kun je het zichzelf laten opstarten, maar het resultaat zal meestal zijn dat concurrenten met een meer strategische toewijzing van middelen de marktleiders zullen worden in deze nieuwe activiteiten.

Ten tweede, verminder investeringen in standaard functionaliteit. Uit ons onderzoek blijkt dat bedrijven 80-90% van hun middelen besteden aan functionaliteit en mogelijkheden die klanten als standaard beschouwen. Ik heb dit in eerdere blogposts en columns besproken, maar ik blijf me verbazen over het gebrek aan bereidheid van bedrijven om te kijken naar nieuwe manieren om investeringen te verminderen op plaatsen waar het niet loont. Doe niet zo dom en maak in plaats daarvan een strategische evaluatie van je hele productportfolio en de functionaliteit in je producten en definieer samen met klanten en anderen wat basisproducten zijn en wat onderscheidend is. Zodra je de basisproducten hebt gedefinieerd, **stop** dan vrijwel alle investeringen daarin. U hebt deze middelen nodig voor duurzame innovaties die de differentiatie van uw producten stimuleren.

Ten derde beschouwen veel bedrijven hun bestaande bedrijfsecosysteem als de enige manier om klanten te bedienen. In de praktijk worden ecosystemen echter verstoord en het is veel beter om de verstoorder te zijn dan de verstoorder. Dit vereist een constante verkenning van mogelijkheden om jezelf te herpositioneren in je bestaande ecosysteem, evenals een verkenning van nieuwe ecosystemen waar je capaciteiten ook relevant kunnen zijn.

Tot slot bieden digitale technologieën – met name data en AI – nieuwe manieren om aan de behoeften van klanten te voldoen die je moet onderzoeken om niet verstoord te worden door, met name, nieuwkomers. Accepteer dat de waarde in bijna elke branche verschuift van atomen naar bits, dat gegevens kunnen worden gebruikt om de verkoop van producten in meerzijdige markten te subsidiëren, dat AI het mogelijk maakt om taken te automatiseren die zelfs enkele jaren geleden nog onmogelijk te automatiseren waren en, in het algemeen, onderzoek proactief de waarde die digitale technologieën kunnen bieden voor jou en je klanten. Dit is waar het grootste deel van de middelen naartoe zou moeten gaan die je hebt vrijgemaakt door horizonplanning en het verminderen van investeringen in standaardfunctionaliteit.

Concluderend heb je aan het begin van 2020 een spelplan nodig om de verkenning aanzienlijk uit te breiden ten koste van de exploitatie om nieuwe kansen te identificeren en verstoringsrisico’s op te sporen en om voldoende te investeren in gebieden die groeikansen bieden. Dit vereist strategische toewijzing van middelen, het identificeren en verwijderen van commodity’s, een zorgvuldige herziening van je positie in bestaande en nieuwe bedrijfsecosystemen en grote verkenningsinitiatieven in de data- en AI-ruimte. Het is riskant, het is eng, de meeste initiatieven zullen niets opleveren en klanten, je aandeelhouders en je eigen mensen zullen moord en brand schreeuwen. En toch is het grootste risico om helemaal niets te doen, want dat zal zeker leiden tot de ondergang van je bedrijf. Laat je dat gebeuren terwijl je toekijkt?