Wanneer is jouw bedrijf klaar voor AI?

Dankjewel.

Ja, daar zit een klein verhaaltje achter. Dat was een film die gemaakt werd door Data EQ, een data science softwareplatform. Dat is volgens mij in 2018 geweest. Die wilden een film maken over een aantal data scientists en data engineers, en zodoende ben ik daar ook voor een interview geweest. Ik had eigenlijk geen idee dat dat ook gepubliceerd werd en op IMDb terechtkomt. Als je mij googelt, dan zie je ineens dat ik ook op IMDb verschijn. Ik heb alleen net geen enkele Hollywoodfilm gespeeld.

Dankjewel.

Ik ben nu vooral actief met pilates, daar geef ik ook les in. Hardlopen, zwemmen, fietsen, krachttraining.

Nee, ik ben hem vergeten. Dat is jammer, ik heb er niet meer aan gedacht. Maar hij ligt nog wel in de vriezer. Volgende keer.

Ouderwetse groentesoep.

Ja, dat is natuurlijk echt een hele vervelende vraag, want ik denk allebei niet per se. Maar ik moet natuurlijk kiezen, dan zeg ik eerder IT.

Ik zou ook eerder IT zeggen, maar eigenlijk beide.

Ik zou ook IT zeggen, maar eigenlijk geen van beide.

Nou, het is eigenlijk groot genoeg om een aparte afdeling te rechtvaardigen. Dus je hebt IT, je hebt finance, je hebt marketing, je kunt ook gewoon data als afdeling hebben. Je hebt nu natuurlijk al een hele tijd CDO's, hè, Chief Data Officers. Als er zo'n CDO is, wat voor mensen heeft die dan onder zich? Nou ja, datamensen misschien. Het is ook een data afdeling. Dus net zozeer als je een CFO hebt, een chief finance officer, die heeft dan de finance afdeling onder zich, zou je van een CDO ook verwachten dat hij dan een data afdeling onder zich zet. Dus dan is het niet IT of finance of marketing, maar data. Maar goed, niet elk bedrijf kan zich zoiets permitteren.

Ja, classic, it depends. Centraliseren zeg ik dan.

Ook hier zou ik zeggen beide. Daarom is het een dilemma. Als je organisatie daar groot genoeg voor is en klaar voor is, wil je je platform en je standaarden centraliseren. Maar tegelijkertijd zou je denk ik ook teams dicht bij de business willen, zodat ze ook snel waarde toe kunnen voegen.

Ja, het is ook zo'n gemene, klassiek inderdaad. Over de jaren heen zie je ook een beetje van die cycles, dat het een beetje de kant op dreigt te gaan naar centraliseren, en dan zie je ineens weer een beweging dat het toch allemaal apart is. Ik denk dat je misschien wel moet beginnen met centraliseren. En als het groot genoeg wordt, mag het zich misschien apart afsplitsen.

Ja, weer een lastige vraag. Moet weer één antwoord, hè? Ik ga dan voor de manager.

Oké. Ik ga voor de product owner.

Ik denk dat het meer de manager is. Product owner klinkt meer in de zin dat je al bezig bent, dat je een product owner hebt voor een bepaald iets of project. Uiteindelijk kies ik toch voor de manager.

Omdat ik denk dat een product owner zich bezighoudt met hoe een team waarde toe kan voegen. En ik denk dat dat precies is wat je met data wilt doen. Dat je data als een product kunt zien dat waarde toevoegt.

Zal ik hem aftrappen? Nou, ik heb bij heel veel opdrachten gemerkt dat in een silo zitten vooral ook het besef niet hebben is dat er heel veel meer met data gebeurt binnen een organisatie dan je zelf eigenlijk weet. En dat kan meerdere oorzaken hebben, waar we denk ik zo meteen ook nog wel op ingaan. Maar ik denk dat een belangrijk onderdeel is dat het eigenlijk ook gewoon onvoldoende kennis is. En je ziet dat vooral bij grotere organisaties, en niet per se bij wat kleinere. Dat je gewoon niet weet wie er eigenlijk allemaal wat met data doet en hoe ze dat dan doen. En hoe we elkaar daarmee dan helpen. Dat is voor mij een belangrijke.

Ja, ik denk dat er ook een verschil is tussen de technische silo's en de afdelingssilo's, of zal ik zeggen, de politieke silo's zelfs. Zeker bij grote bedrijven ontkom je er niet aan om mee te moeten vechten met bedrijfspolitiek. Dan hebben we het over politieke silo's. Je ziet bepaalde groepen mensen of afdelingen die zich een bepaald domein hebben geclaimd. En dat kan overlappend zijn met andere groepen of afdelingen binnen het bedrijf die ook een domein hebben geclaimd. Daar zit overlap in, en ze willen van elkaar niet weten. Of er ontstaat juist politieke struggle zelfs. En ik weet niet wat er erger is, een technische silo of een politieke silo. Het is allebei niet leuk. Maar dan zie je inderdaad, wat Auke ook net zegt, je doet eigenlijk dezelfde dingen. Je vindt opnieuw het wiel uit, je loopt tegen dezelfde problemen aan. En dan valt er inderdaad wat voor te zeggen om een meer centraal datateam te hebben, of data scientists of AI mensen die dat overstijgen en aan één churnmodel werken. En niet dat verschillende afdelingen allemaal hun eigen churnmodel maken, om even heel specifiek één voorbeeldje te noemen. En dat zie je helaas bij veel bedrijven.

Bij bijna allemaal.

Bij alle bedrijven. En dat zijn eigenlijk de moeilijkste silo's om te doorbreken. De technische silo's zijn meer dat elke afdeling zijn eigen database heeft opgezet waarin wat data staat, en de andere afdeling heeft een vergelijkbare database opgezet met weer andere data. Daar kun je technisch nog iets mee. Stel dat dat in Databricks is, dan kun je daar weer een grotere Databricks omgeving omheen zetten met Unity Catalog of wat dan ook.

Ja, maar dat is dan meer een technische silo. Dus ik zie wel twee verschillen in die silo's. We hebben niet eens één silo, dus dat maakt het alleen nog maar lastiger.

Ik denk dat er wel wat voordelen aan zitten. Het zorgt voor rust en focus. Je kunt je binnen je silo focussen op de dingen waar je op dat moment zelf mee bezig bent, dat je optimaliseert voor jezelf. Maar dat moet denk ik niet te lang duren, want dan optimaliseer je binnen je eigen hokje, en heb je kans om de samenhang te verliezen.

Ik denk dat het ook een kwestie van perspectief is. Want vanuit je eigen silo is het heel prettig, precies wat Cathy zegt. Je kunt focussen, je kunt doen wat je wil, je hebt je eigen definities, je kunt snel gaan. Maar voor een bedrijf lijkt het me niet zo handig. Want als je dat meerdere keren hebt, dan heb je verschillende waarheden, verschillende silo's, andere definities, andere werkwijzes. Misschien doe je werk dubbel. Misschien werkt de een in Google en de andere in Databricks en een derde in Microsoft. Dan betaal je drie keer. Dus ik denk dat het ook afhangt van aan wie je het vraagt. Vraag je het aan de mensen in een silo, dan zullen die het denk ik prettig vinden, want dan kunnen ze alles zelf doen en hoeven ze niet bij IT langs om iets te regelen. Maar vanuit het bedrijfsperspectief denk ik dat het niet positief is.

Het kan voordelig zijn, het hangt ook van de fase af waarin je je als bedrijf bevindt. In een silo werk je afgebakend in je eigen domein. Als je silo-overstijgend moet zijn, dan wordt het al snel een groot project. Dan moet je met iedereen rekening houden. Dat kunnen projecten van jaren zijn, dat heb ik ook meegemaakt. Daar kom je ook niet vooruit. Terwijl, als je alleen maar hoeft te focussen op je ene domein, marketing bijvoorbeeld, en daarbinnen een heel specifiek dingetje, dan kun je daar wel stappen maken. En wat je doet is dan misschien niet in overeenstemming met wat anderen doen, maar daar heb je dan even niks mee te maken. Maar dan kun je in ieder geval stappen maken. En dat is soms ook belangrijk om de data science aan de gang te krijgen.

Ja, dus ook als je als organisatie hebt afgesproken om met één soort platform te werken en dat is hoe we het gaan doen, dan zie ik nog steeds dat er ook daarbinnen silo's ontstaan. Denk dan aan de teams die bezig zijn met het fundament, met de standaarden. Die denken in termen als stabiliteit en veiligheid. En de teams die wat dichter bij de business zitten, die willen snel waarde toevoegen. En dat komt niet helemaal overeen en dat botst af en toe.

Ja, dus dan zit je eigenlijk al in dezelfde keten, maar toch heb je andere belangen. Dat is misschien vaak ook een bron van zo'n silo, dat de belangen niet op één lijn liggen.

Nee, en dat ontstaat denk ik ook niet uit onwil. Dat ontstaat juist meer omdat mensen graag hun werk goed willen doen, en snel hun werk willen doen.

Eens. Ja, je hebt ook wel situaties, je had het over de politieke silo's, ik denk dat dat nog wel een ding kan zijn, dat mensen ook doelbewust silo's creëren, omdat het gewoon echt handiger is als je dingen zelf kan doen. Er zijn genoeg casussen te verzinnen waarin je zegt: hé, ik heb nu alle rechten om zelf mensen toegang te geven, dus dan kan ik meteen schakelen als iemand iets nodig heeft. Versus dat je een ticket moet indienen, die wordt in behandeling genomen, daar wordt drie weken over gedaan, en dan wordt die afgeschoten omdat die niet voldoet aan de standaard. Dat is wel een reden voor mensen, dat roept frustratie op. En dat werkt zo'n silo weer in de hand.

Ja, maar dan is de vraag denk ik wel: help je dan jezelf? Help je je eigen team? Of help je de hele organisatie?

Ja, dat is denk ik steeds een vraag die je daarin hebt. Klopt.

Laten wij het even oplossen. Ja, dat is heel lastig. Als we even doorgaan op die scheiding tussen de technische en niet-technische silo's, dan denk ik dat je voor de technische, inderdaad wat Longhow zegt, oplossingen kunt verzinnen, dat is relatief makkelijker dan de niet-technische silo's. Omdat je dan gewoon met mensen te maken hebt. En ik denk dat dat het lastigste onderdeel is. Techniek is heel goed te vormen, daar kun je van alles mee. Maar mensen zijn wat lastiger mee te krijgen in allerlei initiatieven. Maar ik denk wel dat daar de sleutel ligt, eigenlijk.

De klassieke silo, als we het over datasilo's hebben, die zijn tegenwoordig met moderne platforms zoals Snowflake of Databricks eigenlijk wel goed op te lossen. Het is eigenlijk geen excuus meer dat je lokaal als afdeling een SQL servertje hebt draaien, en dat iedereen moet smeken om daarbij te kunnen komen. Dat is niet meer van deze tijd natuurlijk. Maar inderdaad, dat is eigenlijk een soort wet van behoud van ellende, de politieke silo's. Mensen claimen een bepaald domein, houden daaraan vast, dit doe ik gewoon. En als jij dat al doet, ja, ik weet dat dat niet zomaar op te lossen is.

Het gaat ook best diep, want het zijn heel vaak ook dingen die mensen aan het hart liggen. Want wij zijn van HR, of wij zijn van marketing, dus wij weten het beste hoe dit moet. En vervolgens kom je wat wij dan zo mooi noemen bij de business, en die hebben daar toch net een ander idee over. Nou, dan gaan die belangen een beetje botsen. En dan gaan mensen toch weer proberen eromheen te werken. Dat zijn eigenlijk allemaal best wel lastige dingen, omdat het dus niet alleen om feiten gaat, maar vaak ook een beetje om gevoel. Om dingen die je hebt opgezet, die je aan het hart liggen, of waarvan je vindt dat je daar vanuit je achtergrond verantwoordelijk voor bent. En dat maakt het ook zo lastig, dat je daar steeds discussies over kunt krijgen. Vaak is het allerlastigste dat het in het midden ligt. Sommige definities zijn heel strak vanuit een bepaalde HR-theorie heel goed te duiden, alleen in de praktijk werkt dat dan gewoon niet zo. En daar zijn ze zich vanuit een HR-afdeling niet zo van bewust, of ze vinden gewoon dat het op die manier moet. Ja, dat zie je heel erg terugkomen, dat dat dan gaat botsen in dit soort situaties. En probeer dat dan maar eens op een goede manier op te lossen. Dat is eigenlijk heel ingewikkeld. Tenminste, dat vind ik altijd heel ingewikkeld.

Ik denk dat het bij de technische silo's ook heel moeilijk is. Je noemde inderdaad al dat er tools en platformen zijn die je daarvoor kunt gebruiken, die je daarbij helpen. Maar toch denk ik dat het niet een technisch probleem is. Het blijft een mensenprobleem, dus ook bij de technische teams. Het is een organisatieprobleem, en je hebt te maken met mensen, met een bepaalde cultuur, met bepaalde belangen. Dus ik denk dat daar niet één tool of standaardproces voor is dat dat allemaal in één keer oplost. Zo makkelijk is het niet. Dus dat vraagt gewoon heel veel vertrouwen, samenwerking, gedeelde doelen, al dat soort dingen waarmee je mensenproblemen zou kunnen oplossen.

Dat is waar. Al denk ik wel dat het op de techniek ook een beetje aan de kwaliteit van je team ligt. Kijk, als je hele goede mensen hebt die conceptueel heel goed begrijpen wat er allemaal moet gebeuren, dan is een tool ook maar een tool. En dan kun je sneller stappen zetten tussen tools. Een database is een database. Als je daar verstand van hebt, dan kun je daar wel mee uit de voeten, of het nou van leverancier A of B is. Dus ik denk dat het op die manier wel makkelijker op te lossen is. Maar als je die kennis niet hebt, dan wordt het natuurlijk wel lastig. Dan kunnen tools en technische achtergronden dus ook een probleem vormen.

Ja, en dat ligt er denk ik ook aan hoe groot de organisatie is. Als je net begint met iets met data doen, en het is nog maar een heel klein stukje binnen de organisatie, of nog maar een aantal mensen die daar iets mee doen, dan is het natuurlijk veel makkelijker om samen te werken in dat kleine groepje. Maar als je een hele grote organisatie hebt met allemaal verschillende teams die op verschillende plekken iets met data doen, wordt dat veel moeilijker.

Ja, het meest absurde voorbeeld dat ik hier kan vertellen, is een grote leasemaatschappij die per land georganiseerd was. Elk land was een eigen bedrijf. Dan had je een centrale organisatie die de landen aanstuurde. Dan had je een digital organisatie en een innovatieafdeling. Dus op vier niveaus werd er gewerkt aan een machine learning model om de restwaarde van een leaseauto te voorspellen. Met vier verschillende tools, vier verschillende teams van data scientists en data engineers. Het is nooit gelukt om iets samen te doen, want de belangen waren te afzonderlijk. Daar is gewoon geen oplossing voor. Dat is wat het is. En dan moet je ook choose your battles, dan ga je daar ook niet meer proberen iets te centraliseren. Dus dan is soms ook een conclusie van: oké dan, doe ik mijn ding.

Wat wel heel jammer is, natuurlijk.

Wat heel jammer is. En dan helpt het dus als er iemand op C-level niveau is die daar wel iets van vindt en daar ook iets mee doet.

Ja, dan moet er zo iemand zijn die die knoop kan doorhakken. Of inziet dat als we hier samen aan werken, dat dat eigenlijk veel efficiënter is en misschien tot betere modellen of betere analyses leidt.

Mijn moeder ondertussen ook inderdaad.

Leg dat even uit. Kijk, ik draai al een tijdje mee, je noemde net mijn leeftijd, ik ben al ruim 20 jaar aan het werk. En wat je eigenlijk ziet, en dat is niet alleen van de laatste twee jaar met de komst van OpenAI, maar al veel eerder, is dat veel dingen opeens AI zijn gaan heten. Toen ik afstudeerde was ik toegepast statisticus, data-analist, dataminer. Op een gegeven moment kreeg je big data, data science, machine learning. Ik kan wel zeggen dat eigenlijk al die dingen die ik sinds mijn afstuderen heb gedaan, op een gegeven moment gewoon onder de term AI zijn geschoven. Dus dat is al één ding: wat is precies AI? Dan kun je misschien nog een onderscheid maken met klassieke AI, zeg maar de data science, de klassieke machine learning modellen, een regressiemodelletje en een decision tree, weet je wel. Maar dat is op een gegeven moment ook gewoon AI gaan heten. En de modernere dingen die op een gegeven moment kwamen, dus machine learning, computer vision, NLP. En NLP is helemaal modern geworden met de ChatGPT-achtige modellen, zeg maar de grote LLM's. En of een bedrijf klaar is voor AI, dat is een te grote vraag. Waar ben je als bedrijf klaar voor? Voor welk onderdeeltje van dat hele spectrum? Een klantclusteranalyse doen, kun je ook zeggen, ja, dat is gewoon AI hoor. Ben je daar klaar voor? Ja, want we hebben de data, we willen bepaalde persona's gaan creëren, nou dan ben je daar klaar voor. Maar misschien ben je niet klaar om chatbots te gaan maken. Dat is misschien ook helemaal niet nodig. Of om Gen AI modellen zelf te gaan fine-tunen. Nou, dat is echt best wel een stap verder dan gewoon een clusteranalyse doen. Dus het hangt ervan af. AI zie ik als een rugzak met verschillende dingen erin. En dan pakken we er één dingetje uit, omdat je dat wil inzetten om je bedrijfsvoering te optimaliseren. Daarvoor kun je klaar zijn, zeg maar. Zo zou ik hem een beetje willen afbakenen.

Je vraag was: wat is AI? Ik denk dat je het heel simpel zou kunnen samenvatten als software die van data leert. Met alles wat daaronder valt natuurlijk, inderdaad van de simpele modellen naar de wat complexere modellen. Uiteindelijk heeft het data nodig. Als input, eerst om van te leren, daarna als input om iets mee te doen. Dus ik denk dat je data vooral goed op orde moet zijn voordat je klaar bent om het op grote schaal toe te kunnen passen.

Ja, Gen AI modellen in het algemeen natuurlijk. ChatGPT is natuurlijk een mooie naam van OpenAI, maar er zijn meerdere aanbieders van dat soort dingen. En LLM's, large language models, is natuurlijk ook maar één aspect, want je hebt nu ook veel toepassingen op het gebied van het genereren van plaatjes en het genereren van video's. Daar zie ik op zich nu nog niet zozeer hele voor de hand liggende use cases bij bedrijven. Die plaatjes, die video's, natuurlijk wel heel specifiek in niches, voor de filmindustrie bijvoorbeeld. Maar die LLM's komen wel nu. Daarvan zien we wel dat bedrijven de waarde ervan in gaan zien om toe te passen in hun bedrijfsvoering, naast de klassieke, de gewone AI, zeg maar. Maar begin altijd met de basis. Als je nog niet eens een gewone clusteranalyse kunt doen, dan moet je je afvragen of je dan al die grotere stap met LLM's moet gaan doen.

Ik denk, wat Cathy terecht aangaf, de data moet op orde zijn. En op orde betekent niet 100% op orde, want met machine learning en met statistische modellen kun je er nog mee wegkomen dat sommige data ontbreken. Als je een goed beeld wil hebben van het inkomen van Nederland, hoef je niet alle mensen te vragen, een goede sample is soms voldoende. Dat je dan sommige dingen mist, daar kun je mee wegkomen. Maar je moet in ieder geval iets van data hebben. Maar belangrijker nog is eigenlijk dat je een organisatie moet hebben die ook weet wat ze met zo'n clusteranalyse willen en kunnen doen. Dat is misschien nog wel belangrijker. Als ze data hebben, kan ik bij wijze van spreken morgen een clusteranalyse voor je draaien. Maar wat ga je ermee doen? En daar zie ik veel bedrijven mee struggelen. Dan heb ik als data scientist een model gemaakt, maakt niet uit wat voor model, en dan moet ik met dat model binnen het bedrijf gaan leuren van: hé kijk, je kunt hier iets mee doen. En dan krijg je gesprekken met marketeers. Oh ja, zouden we campagnes kunnen draaien? Kunnen we dit überhaupt? Gepersonaliseerde uitingen? We sturen nu standaard één keer per week een e-mail, dit is gewoon hartstikke standaard. Maar nu moeten we voor iedereen een ander soort boodschap brengen of een ander soort aanbieding. Kunnen ze dat überhaupt? En dat is eigenlijk al de eerste vraag aan mij als ik bij een bedrijf binnenkom: zijn jullie daar überhaupt toe in staat? En als het antwoord nee is, en ja, dat hebben we ook vaak genoeg meegemaakt, nou ja, dan kun je wel een machine learning model maken, maar als we niet iedereen individueel een aanbieding kunnen doen, dan hoef ik eigenlijk niet eens te komen.

Precies. En wat je zegt vind ik een hele belangrijke. Want dat zie je zowel bij data als bij AI: omdat het zo hip is, wil men het. Maar het hebben van AI op zich kan eigenlijk nooit een doel zijn. Het echte doel mist men dan vaak. En dat zie je zowel vanuit de data als vanuit de AI. Dat men zegt: ja, ik ga van alles met data doen, ik wil data verzamelen, dat is leuk. Maar wat ga je er dan mee doen? Wat is jouw doel met het verzamelen van data? Want alleen het verzamelen van data, of het hebben van een dashboard, kan nooit het doel zijn. Je moet daar wat mee doen.

En dat zie je dus ook hier bij AI, omdat iedereen zegt: ik moet mee met die trein, ik moet AI hebben, het is zo booming. Maar ik heb er nog geen doel voor, ik weet het eigenlijk niet, maar we doen wel wat met AI. En dat betekent dan meestal mailtjes laten typen door ChatGPT. Dan doe je wat met AI, maar dan mist het hele doel. En ik denk dat dat een heel belangrijk punt is wat Longhow hier zegt. Dat je daar eigenlijk heel goed over na moet denken. Wat lost het dan voor mij op? Wat kan het voor mij oplossen? En als je dat niet weet, is het eigenlijk zonde om eraan te beginnen.

Ja, je dreigt dezelfde val in te lopen als een tijdje geleden met big data en data science. Hele teams zijn opgetuigd, ik heb er ook in gezeten, in dat soort big data teams, data science teams. Konden we vanuit onszelf allemaal interessante use cases verzinnen. Maar dan had je die gebouwd, en dan begon de moeilijkheid daar eigenlijk pas. En nu zie je inderdaad ook nog een soort scheiding. Ik noemde net klassieke AI en Gen AI, maar je hebt nog een soort scheiding eigenlijk. En dat is meer de AI voor een bedrijf als productiviteitstool. Dat je een copilot naast je hebt, die maakt wat Word-documenten voor je en doet leuke PowerPoints. Dat is natuurlijk super handig, dat wordt echt al heel veel gebruikt. Maar dat noem ik nog niet zozeer de AI die, zoals de klassieke AI, een clusteranalyse maakt om je bedrijfsvoering verder te helpen. Want dat is veel lastiger.

Ik denk dat die productiviteit vaak iets is wat men ziet als AI. Een soort automatisering plus. En dat noemen we dan AI, en dan doen we iets cools. Alleen dat betekent dat ik een mailtje stuur als ik een ander berichtje heb binnengekregen of zo. Dat is niet per se AI, dat kan ook op een heel andere manier gewoon geautomatiseerd worden.

Dat zouden mensen AI noemen. Dat zou ik ook AI noemen.

Maar de zelfrijdende auto, hoe helpt dat een groot MKB-bedrijf om zijn klanten beter te bedienen? Het is natuurlijk wel AI.

En daarom, AI is nu een groot containerbegrip geworden waar bijna alles onder kan vallen. En ook automatisering. Ja, we moeten deze procesflow met AI gaan bewerken, want we kunnen dingen automatiseren. Oh, maar je bent gewoon aan het automatiseren, daar is niet per se AI voor nodig. Maar ja, je kunt er een AI-sausje overheen gooien.

Nou ja, dat zie je nu sterk in opkomst. De klassieke manier om waarde uit je data te halen als data-analist, is om je data te gaan bewerken, het resultaat ervan in een dashboard gooien waarschijnlijk, en dan inzien van: oh ja, dit is een outlier, of er zit zo'n trend in. Nou, dat is natuurlijk klassiek werk, dat doen data-analisten, data scientists. Maar dat is eigenlijk alleen voorbehouden aan mensen die verstand hebben van SQL of Python of visualisatie. De gewone business user wil eigenlijk vragen stellen in gewone taal aan de data, zonder SQL te hoeven kennen. Geef mij een trend van de laatste vijf jaar. En waarom zijn hier outliers? Waarom is de trend naar beneden? En is dat voor alle landen bijvoorbeeld? En daar zien we een tool als Snowflake opkomen, die jouw data dat soort vragen gewoon kan laten beantwoorden, de grafiekjes uitspuugt, en ook de bijbehorende SQL, als je het eventueel nog zelf zou willen valideren. En dat zie ik sterk in opkomst. Vroeger noemde men dat een zogenaamde citizen data scientist, volgens mij is dat een term ooit van Gartner, waarbij je met allerlei tools, klik-en-flow-tools, point-and-click-tools, dingen voor elkaar kon krijgen. Maar nu hoef je niet eens te point-and-clicken, want dat is eigenlijk nog redelijk technisch, dan moet ik menuutjes aanklikken en flowtjes opzetten. Nu stel je gewoon de vraag in je gewone taal. De voorwaarde is wel dat je data goed op orde moet zijn. Er moet een goede semantische laag over die data heen zitten: wat betekent dit veld? Wat voor data zit erin? Wat zijn de mogelijke waarden en de beschrijving van de data? Dat zie ik nu in opkomst. Misschien ook omdat de mensen die SQL en Python echt goed kennen om inzichten uit data te halen beperkt zijn, en er steeds meer ad hoc vragen vanuit de business komen.

Het hangt af van de hoeveelheid data en of je data goed gemodelleerd is.

Het systeem helpt daar ook bij, inderdaad. Dus als je één tabel hebt waar bij wijze van spreken alles in staat, dan is dat natuurlijk een makkelijker datamodel dan een model met verschillende tabellen, feiten en dimensies. Daar kan het systeem ook wel mee overweg, maar die moet je dan wel vertellen: deze tabel is met die gerelateerd, dit zit er in deze tabel, de link gaat via deze keys. Dat zijn dingen die je toch al moet doen voor een goed datamodel. Om je data te documenteren, je relaties tussen tabellen, wat er in de data zit. Dus eigenlijk moet je dat toch al op orde hebben.

Daar wordt trouwens ook wel op ingesprongen door bijvoorbeeld Microsoft. Die hebben dit stukje voor de semantic models in Power BI ingericht, zodat je met AI veel makkelijker met die modellen kan communiceren. Zodat alle dingen die Longhow nu aangeeft, dat je die er veel makkelijker uit kan halen. Juist om dit soort dingen te vergemakkelijken, omdat dat volgens mij nog een groot struikelblok is, slash was. Dus je ziet ook wel opkomen dat mensen daar dan weer oplossingen voor gaan verzinnen en inbouwen. Dat is wel interessant, dus het helpt elkaar op die manier ook steeds een beetje verder.

Mensen stellen vragen in natuurlijke taal die niet per se overeenkomt met de technische kolomnamen, of relaties in de data warehouse. Dus je moet een soort laag hebben die die vertaalslag maakt. En dat wordt denk ik heel belangrijk. De semantische view, de semantische laag op data, werd misschien al een tijd lang als een beetje suffig iets beschouwd, van: ja, dat moeten we ook maar bijhouden. Maar nu, voor AI, om je te helpen met een Power BI of met een Snowflake of Databricks, gaat dat belangrijk zijn.

Ja, mij schiet nog iets te binnen. Het lastige is dat bij dit soort dingen de interpretatie van de data nog steeds best wel mensenwerk is. Want ook al heb je het goed voor elkaar, en kun je bijvoorbeeld vragen: wie heeft er het slechtst gepresteerd afgelopen jaar? Dan kun je daar een heel goed antwoord op krijgen vanuit de data. Persoon X was dit jaar het slechtst qua productiviteit. Maar waarom iemand het slechtst was qua productiviteit, dat zit daar niet in. Dat is gewoon puur de data, en dat kan kloppen en dat kan er via AI uitkomen. Maar waarom dat zo is, dat kan bijvoorbeeld zijn omdat die persoon, en dat heb ik in het echt ook gezien, afdelingen helpt met IT. Dus in principe had die persoon eigenlijk declarabel moeten zijn, maar helpt 20, 30, 40 man declarabeler te zijn, door problemen weg te nemen. Maar uit de data komt hij er dan dus eigenlijk slecht uit. En dat zijn dingen waar ik nog een beetje het gevaar van inzie bij dit soort exercities. Want mensen weten die achtergrond eigenlijk niet, die weten niet waar het over gaat. Je vraagt wel wie eigenlijk het slechtst is, of zet mensen op volgorde, en dan ga je heel snel conclusies aan verbinden die niet per se de juiste zijn.

Maar dat is meer een algemeen gevaar. Je had dat lijstje ook zelf in SQL kunnen maken.

Precies. Maar voor mijn gevoel zit je er dan dieper in en weet je beter wat je doet, omdat je daadwerkelijk moet queryen. Dan heb je waarschijnlijk wat technische achtergrond, je weet wat meer over die data. Als je nu bij een willekeurig persoon dat hele technische stuk weghaalt en hij kan het gewoon vragen, weet die persoon het dan ook? Nou ja, oké, niet helemaal willekeurig.

Nee, maar dat is wel een nuance. Degene die je achter zo'n agentic AI zet om vragen of antwoorden uit die data te halen, die moet wel weten: oh ja, Jantje staat nu slechter, maar ik weet van hem dat hij dit en dit heeft gedaan. Of een marketeer die weet: ik heb verschillende campagnes gedaan, misschien zijn sommige campagnes nog niet verwerkt in het systeem, dus als ik dit vraag, dan komt dat er nog niet uit. Dat is wel een grote voorwaarde.

Dat is ook wat ik probeerde te zeggen. Maar het gevaar is, het wordt steeds makkelijker. Dus in die zin wordt het gevaar steeds groter, omdat steeds meer mensen het zouden kunnen. Dat is dan misschien inderdaad de nuance. Die vind ik in ieder geval belangrijk.

Spiderman, hè? Met grote kracht komt grote verantwoordelijkheid.

Het hangt er weer vanaf.

Ad hoc vragen zijn eigenlijk geschikt voor dit soort chat-achtige sessies. Maar als je gelikte en betrouwbare dashboards hebt, en dan is het bijna meer reporting, jaarcijfers of kwartaalcijfers die elke keer in dit formaat gepubliceerd moeten worden, dan kom je er niet onderuit om klassieke dashboards op te richten die elke maand ververst worden. Maar wat ik zie, en daarom denk ik dat dat een oplossing kan zijn, is dat BI-afdelingen overspoeld worden met ad hoc vragen vanuit de business. En voor elke ad hoc vraag kun je dan een Power BI dashboard gaan optuigen. Er wordt een paar keer naar gekeken, en dan wordt het ineens een weesdashboard, want niemand bekommert zich er meer om. Dan krijg je letterlijk bedrijven met duizenden dashboards. Dat is niet overdreven, ik denk dat iedereen dat voorbeeld wel kent. En dat zou je misschien kunnen voorkomen door business users gewoon een ad hoc vraag te laten stellen aan zo'n systeem, en dat ze een antwoord krijgen dat ze kunnen duiden en valideren. Maar goed, niemand kan de toekomst voorspellen of dit ook echt zo zal zijn. En de techniek moet ook nog verbeteren, denk ik.

Ja, van ad hoc naar semi-ad hoc naar permanent.

Nou, het heeft deels heel erg te maken met metadata, denk ik. Dus data over je data.

Ja, eigenlijk de data over je data. Dus bijvoorbeeld: wat voor datatype is het? Wat is de min en de max? Dat is denk ik een mooie basis. En daarnaast moet je ook duiding geven aan die data, voor zo'n model om het te kunnen snappen. En ik denk dat die combinatie eigenlijk is waar jij het vooral over hebt. Kijk, voor een systeem is een kolom met eentjes en nulletjes gewoon een kolom met eentjes en nulletjes. Maar jij moet duiding geven dat dat bijvoorbeeld ja en nee is. Maar waar gaat die ja en nee dan over? Bijvoorbeeld: heeft iemand een huisdier, ja of nee? Als jij alleen een kolom hebt die misschien zelfs een naam heeft als X, Y, Z, het heeft niks te maken met huisdieren, en er staan eentjes en nulletjes in, dan weet zo'n systeem niet dat het over huisdieren gaat en of iemand wel of niet een huisdier heeft. En dat is een beetje waar jij denk ik op doelt: die context schetsen bij die informatie. Dat is die semantische laag waar je het dan over hebt.

Het is data over data, metadata. Een kolomnaam is "inkomen", maar iemand anders noemt het "salaris", en weer iemand anders vraagt: wat is het maximumsalaris? Terwijl je in de database een kolom hebt met alleen de kolomnaam "inkomen". Dan is het lastig die link te leggen. Maar als jij in die semantische laag de data voorziet van: ja, deze kolom kan ook salaris genoemd worden, of uitbetaling, of bonus, weet je wel, dan als je een vraag stelt in natuurlijke taal, heb je veel meer kans dat je er iets van kan bakken. Dus dat kost werk, dat kost tijd. En je kunt soms AI gebruiken om op basis van een bestaande dataset al een eerste aanzet te maken voor een semantische view of model, hoe je het noemen wil. En dan zie je vaak dat je in een tweede of derde iteratie met business stakeholders dat gaat aanpassen. Oh, maar deze kolomnaam, kun je die ook zo noemen als iemand een vraag zou stellen? Of inderdaad, wat jij zegt, een 1 en een 0 betekent een ja en nee. Maar wat is dan die ja en nee? Ja, heeft hij een huisdier. Welk huisdier? Wat zijn de huisdieren die jij beschouwt dan?

Dat moet jij dan vastleggen.

Het kan heel ver gaan. En dat kost ook heel veel tijd. De vraag is ook: wil je dat doen, en welke waarde heeft het je nog meer? Maar dat je zoiets moet gaan hebben, is eigenlijk onontkoombaar.

Ja, maar we hebben het nu over het gebruik van de data, denk ik. We hebben het nu over het semantische laagje, dus op het moment dat je data klaarstaat om gebruikt te worden, eventueel door AI. Maar ik denk dat er nog veel meer stapjes aan voorafgaan. Die data komt ergens vandaan, dat moet geprocessed worden, dat moet klaargezet worden. En ik denk dat dat proces minstens net zo belangrijk is.

Zeker.

Als alle dingen die we net besproken hebben.

We gaan ervan uit dat er al iets is.

Je gaat ergens van uit. En daar ligt ook exact het punt. Je gaat ervan uit dat je data klopt. Daar ga je iets op bouwen, een model, daar komt iets uit, er komen conclusies uit. En misschien kloppen die conclusies helemaal niet. Dus als je data niet klopt, krijg je verkeerde conclusies. Als je data niet op orde is, krijg je eigenlijk gewoon een soort geautomatiseerde rommel.

Voor dat semantische laag, voordat je daar überhaupt aan kunt denken, heb je al een heel proces.

Ja, en dat proces is heel belangrijk, denk ik.

Zeker. Je data komt ergens vandaan, waarschijnlijk uit meerdere bronnen. Het hangt er ook weer vanaf hoe groot de organisatie is en wat voor data jij gebruikt.

Bijvoorbeeld. Of een andere organisatie, of Excel. Dat kan allemaal. Dus het komt ergens vandaan, en dat moet allemaal op een gestandaardiseerde manier ergens opgeslagen worden, zodat het ook gebruikt kan worden. Een AI kan namelijk niet zelf nadenken, het is geen magie of zo. Het is gewoon iets wat ooit gemaakt is door iemand, uiteindelijk is het gewoon wiskunde en data. Een model leert van de data die je erin stopt. Dus die data die je erin stopt, moet ook goed gestructureerd zijn, anders kan er niks mee. Het moet kloppen, het moet betrouwbaar zijn. Dus ik denk dat dat een heel belangrijk punt is: je moet vertrouwen kunnen hebben in je data. En dat heb je alleen als je weet waar het vandaan komt, wie ervoor verantwoordelijk is, wat ermee gedaan wordt. En dan kom je uiteindelijk op dat punt van je semantische model.

Veel bedrijven zien dat ook wel, denk ik. De focus ligt vaak eerst op data engineering, en dat soort rollen om de data van de bron naar een eindbestemming te krijgen. Dat is een heel proces. Dus als data scientist zie je ook: tien of vijftien jaar geleden werd de data scientist als God geroepen, maar eigenlijk is het de data engineer of dat soort mensen, als ik het zo generiek mag zeggen.

Ja, en het is nog een leuke anekdote. Als je die data hebt, kun je bijvoorbeeld aan het eind vragen: geef mij de beste vestigingen die ik heb. Maar ik heb situaties gehad dat bepaalde vestigingen dat systeem überhaupt niet gebruikten, dus die data zat er helemaal niet in. Dus als je dan aan het eind gaat vragen om de beste vestigingen, ja, dan doe je het met wat je hebt. En als processen niet gevolgd worden, en die data er dus überhaupt niet is, of niet goed is, dan ga je nat. Dus dat zijn, wat Cathy zegt, hele belangrijke dingen die je snel vergeet, snel overheen stapt, maar die in dat hele proces superbelangrijk zijn.

Ja, en ook, het zijn details, maar van de bron tot een bepaald eindsysteem zitten soms nog hele handmatige stappen. Mensen krijgen zelfs data gemaild, of moeten het ergens van een FTP-site downloaden. Het zijn van die dingen waar je eigenlijk, als je een goed proces wil hebben, niet van afhankelijk wil zijn. Ik heb zelfs een organisatie meegemaakt waar de databeschikbaarheid echt afhankelijk was van of iemand wel of niet met vakantie was. Dat zijn van die hele basale dingen waar je eigenlijk al iets van moet vinden en die je moet oplossen voordat je überhaupt naar een semantische laag gaat.

Dat hoort er dus allemaal bij: hoe betrouwbaar is je data nou eigenlijk? De eindgebruiker moet vertrouwen kunnen hebben in dat model en dus in de data. Dus als de eindgebruiker bijvoorbeeld weet dat dit resultaat afhankelijk is van of persoon A of B op vakantie is, dat is heel erg.

Er zijn situaties waarin mensen gewoon systemen overtypen. Dan moet je wachten tot iemand in het ene systeem heeft getypt wat er in een ander systeem staat. En dan gaat het soms een keer fout, en dan moet dat hersteld worden. Als dat het proces is, dan is het natuurlijk erg lastig om daar goed op te kunnen bouwen.

Het zijn dat soort kleine dingetjes inderdaad. Het gaat al fout bij waar de data vandaan komt, dat is de invoer. Als mensen in een vrij veld iets kunnen invoeren, geslacht, man of vrouw, nou denk je, hoe moeilijk kan het zijn? Maar je krijgt misschien wel 80.000 verschillende mogelijkheden. Haal hier maar eens man, vrouw of onbekend uit. Daar begint het al. M, V, F, enzovoort.

Ja, ze hebben nu Copilot ingebouwd in Microsoft Fabric. Nou ja, dat werkt, dus dat is op zich prima.

Ja, die kent dan de context. Alleen, bij Microsoft koop je een bepaald aantal capacity units, en Copilot gaat ook van die capacity units af. Dus in die zin is het denk ik nog niet zo mooi vrijblijvend. Tenminste, als je geld genoeg hebt kun je dat natuurlijk gewoon gebruiken. Maar ik denk dat dat voor veel organisaties nog even een dingetje is om dat nog niet aan te zetten. Toevalligerwijs probeert Microsoft dat wel heel erg te pushen. Volgens mij hadden ze deze week zelfs weer een instelling die standaard aanstaat waardoor iedereen op zijn scherm krijgt: probeer nu eens, een beetje wat jij net hebt uitgelegd, jouw vraag te stellen aan Copilot. Want dat triggert mensen natuurlijk weer van: oh, kan ik dus ook AI gebruiken in mijn dashboard? Het idee vind ik wel heel goed, vooral omdat heel vaak de context mist. En dat is een beetje het verlengde van zo'n semantische laag. Waar hebben we het nou over? Ik ben een stuk code aan het maken dat over data X, Y, Z gaat. En als je dat weet, is het veel makkelijker voor zo'n model om daar iets zinnigs over te zeggen. Dus in dat opzicht denk ik dat het fijn is als het geïntegreerd is. Maar ik denk ook dat we daar nog even moeten kijken naar wat financieel haalbaar is, en hoe we dat dan echt goed gaan gebruiken.

Maar ik denk dat dat binnenkort niet alleen de kosten zijn. Je ziet bij sommige bedrijven dat ze het juist bewust niet aan hebben staan, omdat ze bang zijn voor vertrouwelijke informatie.

Privacy is een belangrijk onderdeel. Wat Microsoft of wie dan ook ermee doet, dat heb ik nog niet eens genoemd, maar zeker weten.

Ja, die hebben dat natuurlijk ook.

Ja, als je bijvoorbeeld in een notebook werkt, dan maakt die heel makkelijk je zin af. Dus dat helpt natuurlijk bij het schrijven van code, het is een productiviteitstool. Dus dat is heel makkelijk. Ik denk wel dat datgene waar die grote platformen vooral in helpen, is dat het toegankelijker wordt om binnen je eigen organisatie AI toe te passen. En dan bedoel ik niet de productiviteitstool, dus het helpen met het schrijven van code, maar dan bedoel ik meer: zelf modellen gebruiken, zelf modellen maken op basis van je eigen data en dat binnen de organisatie gebruiken. Want wat een heel groot voordeel is van al die grote platformen, is dat je een combinatie van verschillende dingen hebt. Je hebt je dataopslag, je compute, je data lineage, je data governance, dat heb je allemaal op één plek. Dus dat maakt het veel toegankelijker om op een juiste manier gebruik te maken van je data.

Ja, dat hangt van het bedrijf af, van de volwassenheid van het bedrijf. Om een voorbeeld te geven uit een hele andere vergelijking: mobiliteit. Auto's zijn voor veel bedrijven best wel belangrijk. Maar je ziet bijna geen enkel bedrijf zijn eigen auto's bouwen. Ze hebben die niet eens op de boeken staan, ze leasen het soms zelfs. Zo zou je misschien ook eens kunnen denken over AI. Als jij als bedrijf niet een groot bedrijf bent, maar wel van AI afhankelijk kunt zijn of wil profiteren, dan kun je misschien ook gewoon AI inkopen. Dat hangt ook weer af van wat voor soort AI je inkoopt. Sommige dingen kun je heel makkelijk inkopen, zoals een copilot, want dan heb je eigenlijk minder je eigen data nodig. Maar ook voor modellen zie je nu vaak een soort data science as a service ontstaan. En dan kun je specialisten of externe consultants inhuren. Dat is natuurlijk ook een vorm van data science laten doen door andere bedrijven. En het hangt er maar net vanaf wat verdedigbaar is. Het is vrij specialistisch werk natuurlijk. En niet elk bedrijf kan ineens een team van data engineers aannemen. Want het is niet alleen die ene data scientist, maar het is ook de hele achtergrond van data engineers. En dat maakt het voor een bedrijf misschien makkelijker om ofwel kant-en-klare modellen in te kopen, voor zover dat mogelijk is, of specialisme in te huren. Je hoeft niet alles zelf te doen. En ook dus qua mensen, maar ook qua platform inderdaad: Snowflake en Databricks of Fabric. Misschien ook een interessante podcast voor later. Een paar grote platformen die ontstaan, wanneer gebruik je wat, wat zijn de voor- en nadelen.

Nou, ik laat me altijd inspireren door de quote van Johan Cruijff: voetbal is simpel, maar simpel voetbal is het moeilijkste wat er is. En dat geldt ook een beetje voor data en data science. Je hebt een tijd lang gehad, en nog steeds, dat mensen het overcomplex willen maken, het meest geavanceerde machine learning algoritme ertegenaan willen gooien. Terwijl soms een heel simpel model al werkt. Om dat simpele model werkend te krijgen, dat is best wel lastig, of kan lastig zijn. En ja, dat vind ik wel een mooie filosofie van Johan.

Dus dat probeer ik altijd, als ik bij bedrijven binnenkom, om zo simpel mogelijk te beginnen.

Nou, een beetje in het verlengde. Wat denk ik ook wel best relevant is tegenwoordig: iedereen doet mee aan die AI-wedloop, zowel op techniek als op materialen. En ik heb daar een leuk boek over gelezen, AI Superpowers. Dat gaat over de strijd tussen China en de Verenigde Staten. En ik denk vooral in de huidige context dat het best interessant is om dat een keer te lezen.

Om nog even terug te komen op die silo's: ik denk dat het goed is om verder te kijken dan je eigen team. En dat data pas echt waarde toe gaat voegen als je samenwerkt en als het van de hele organisatie is.