AI, tools en transformatie

Het is erg verleidelijk om te denken dat AI dit grotendeels zal wegvagen. Er is een oude grap dat een ingenieur iemand is die een uur besteedt aan het bouwen van een tool om een taak te automatiseren die slechts 10 minuten in beslag neemt. Maar met AI kun je die tool nu in vijf minuten maken, zonder dat je een ingenieur hoeft te zijn of code hoeft te schrijven. Je kunt het model simpelweg vragen de tool voor je te maken, of, fundamenteler, de taak zelf voor je uit te voeren. In plaats van tools één voor één te moeten creëren, zou software dynamisch, generatief, vrijvormig en spontaan kunnen worden. Er kunnen massaal meer taken worden geautomatiseerd met massaal minder software.

Voor een tool-bouwer — en iedereen in Silicon Valley is een tool-bouwer — is dit een bedwelmend idee. Maar ik denk dat dit miskent waar software vandaan komt, hoe mensen het gebruiken en hoe bedrijven veranderen.

De kloof tussen bouwer en gebruiker

Ten eerste zijn de meeste mensen geen tool-bouwers en denken de meeste mensen niet instinctief na over hoe hun werk op een andere manier gedaan zou kunnen worden. Als je al je tijd in de Silicon Valley-bubbel doorbrengt, is het gemakkelijk om dit te vergeten, omdat je hele wereld draait om het creëren van tools die veranderen hoe dingen worden gedaan.

Maar een echt goede echtscheidingsadvocaat besteedt zijn hele dag aan het nadenken over zijn zaken en zijn cliënten, niet over wat geweldige software voor juridische bewijsvoering zou doen. Een echt goede enterprise-verkoper besteedt al zijn tijd aan het nadenken over zijn product, zijn klanten en zijn concurrenten, niet over hoe geweldige sales enablement-software hem productiever zou kunnen maken.

Producten zoals Excel proberen dit probleem te overbruggen met onboarding-flows, assistenten en sjablonen — alles wat je ziet onder 'Bestand/Nieuw' is een suggestie voor wat je ermee zou kunnen doen. Maar elk van die sjablonen is uiteindelijk een bedrijf geworden, en dat is wat ik ook zie in zaken als 'Claude voor X'; dit is behulpzaam, maar niet het antwoord.

In nauwe zin betekent dit dat de taak die geautomatiseerd moet worden, misschien wel vlak voor iemands neus ligt, maar dat de mensen die die taak uitvoeren het niet zien. Dit leidt tot het idee van de forward-deployed engineer: iemand die een bouwer is, weet wat AI kan bouwen, en 'gewoon' door een advocatenkantoor of architectenbureau kan lopen om de kansen te zien die op tafel liggen, maar die de advocaat of de architect niet ziet. (Dit is ook de ervaring van veel mensen in de tech-sector toen ze 15 waren en stage liepen of op het kantoor van hun ouders waren: "Eh, pap, wist je dat je het gewoon zo zou kunnen doen?").

Het diepere probleem is dat het grootste deel van wat we de afgelopen decennia hebben geautomatiseerd, niet voor de hand lag, zelfs niet voor een tool-bouwer, en ook geen voor de hand liggende oplossing had. We kunnen allemaal voorbeelden bedenken van dingen die we dagelijks gebruiken waarbij onze eerste reactie was: "Waarom zou ik dat willen?". Vaak is het niet duidelijk dat het probleem bestaat, en vaak is het ingebed, gebundeld of verborgen in iets anders. Evenzo is, zelfs als je het probleem ziet of denkt te zien, de juiste manier om het op te lossen vaak niet duidelijk. De oplossing is dan vaak om het probleem te herdefiniëren of te ontbundelen, en dat uitzoeken is moeilijk. Voor veel succesvolle softwarebedrijven gingen er een half dozijn mislukte pogingen aan vooraf die niet precies de juiste aanpak of het juiste probleem vonden.

Niets hiervan wordt opgelost door het schrijven van code gemakkelijker te maken, of door het maken van tools te vergemakkelijken. Het moeilijke deel is weten dat je überhaupt een tool nodig hebt voor een bepaalde zaak, en vervolgens weten wat die tool precies moet doen.

Zelfs als je dat punt bereikt, moet je ervoor zorgen dat iedereen anders het ook gaat gebruiken. Veel van de problemen, workflows en taken die we zouden willen automatiseren, raken 50 of 500 mensen verspreid over vijf verschillende afdelingen, drie verschillende systemen van record en vier verschillende regelgevende regimes. Je kunt een geweldig idee hebben om debiteurenbeheer anders aan te pakken, maar je kunt niet in je eentje veranderen hoe iedereen in het bedrijf dat doet. Dat moet via een aankoop, een besluit en een verkoopproces van 18 maanden.

Geïnstitutionaliseerde versus geïmproviseerde software

Ten tweede betekent dit alles dat software wordt gekocht, gekozen of gecreëerd op een spectrum van top-down naar bottom-up — het bedrijf koopt SAP en de gebruiker maakt een spreadsheet. Ik denk dat het nuttig is om dit ook te zien als een spectrum van geïnstitutionaliseerd naar geïmproviseerd.

Er zijn taken die gemakkelijk uit te voeren zijn in de specifieke tools die je al hebt, of dat nu SAP, Carta of Rippling is. Deze taken en workflows zijn geïnstitutionaliseerd: een groep mensen in die bedrijven en in jouw bedrijf heeft veel tijd besteed aan het uitwerken van de juiste manier om die taak uit te voeren, en het is belangrijk dat iedereen het op dezelfde manier doet met dezelfde tools.

Maar dan heb je uitzonderingen, randgevallen en eenmalige vragen die moeilijk of onmogelijk uit te voeren zijn in die tools. Jouw gebruikers, die bottom-up hun eigen oplossingen creëren, beheren deze in een vage, geïmproviseerde ruimte van vrijvormige substraten zoals Excel, e-mail, gedeelde mappen, Tableau, PowerPoint, CSV's, screenshots, PDF's en conference calls.

Zodra zo'n taak echter iets wordt dat je constant doet, elke keer op dezelfde manier, en waar veel mensen mee bezig zijn, en het belangrijk wordt met bijbehorende omzet en risico's, moet het bedrijf het op een gegeven moment institutionaliseren. Je hebt audit, beveiliging, onderhoud en verantwoordelijkheid nodig. Je bestraat het 'olifantenpad' en betaalt iemand om het in steen te beitelen. Zoals hierboven vermeld, besef je misschien niet dat het pad er is — je realiseert je misschien niet dat honderden mensen elke dag een uur verspillen aan deze taak — en het kan moeilijk zijn om de juiste manier te vinden om dat op te lossen, maar dat proces is de reden waarom een bedrijf honderden apps heeft.

We hebben dit al meegemaakt met de verschuiving naar SaaS, wat een andere orde van grootte betekende in de hoeveelheid software die we hadden, samen met een nieuw operationeel model en een nieuwe cyclusduur. Dat maakte veel gevestigde partijen kapot die de overstap niet konden maken (de werkelijke rationale achter de 'SaaSpocalypse'). Het is een voortdurende en organische stroom van bundelen en ontbundelen. Al die SaaS-apps doen iets wat je ook in SAP, Excel of e-mail zou kunnen doen — Carta is een bedrijf van 4 miljard dollar dat in feite één spreadsheet voor je CFO beheert — en soms verschuiven taken weer terug. Een paar jaar geleden sprak ik een consultant die zei dat de helft van zijn werk bestond uit mensen die Excel gebruikten vertellen dat ze een database moesten gebruiken, en de andere helft was precies het tegenovergestelde.

Als PwC bijvoorbeeld elk jaar 3.000 tot 4.000 afgestudeerden aanneemt, gebruiken ze specifieke, 'geïnstitutionaliseerde' software om dat te beheren. Als je een klein kantoor bent en er vijf of tien aanneemt, gebruik je e-mail, een gedeelde map en Google Sheets. Naarmate dat kleine kantoor groeit, zal het op een gegeven moment die middelen ontgroeien en misschien overstappen naar Notion of een SaaS HCM voor het mkb. Maar een klein team binnen PwC kan ook Google Sheets gebruiken om kandidaten voor een specifieke rol bij te houden omdat Workday te inflexibel is — de ontbundeling begint opnieuw.

De impact van AI op de cyclus

Nu komt AI over dit alles heen te liggen. AI zal alle bestaande apps uitbreiden, en er zullen veel nieuwe verticale apps komen. Excel, Tableau, Google Sheets, e-mail en alle andere vrijvormige ruimtes voor geïmproviseerde oplossingen zullen nieuwe mogelijkheden krijgen. Binnen die cyclus is de chatbot zelf een nieuwe vrijvormige ruimte die naast Excel en e-mail staat, taken van hen en van je apps overneemt, maar ook taken aan die apps verliest.

Dat kleine bedrijf dat tien afgestudeerden aanneemt, blijft nu misschien veel langer in Google Sheets werken omdat AI het schaalbaarder maakt, of je gebruikt het als databron voor Gemini, en je vraagt je af: "Moeten we Claude iets laten maken of dit verplaatsen naar Notion?"... en dan zie je dat er een nieuwe SaaS-app is die precies op jou is gericht en dit probleem oplost, samen met andere problemen waar je niet aan had gedacht. AI verandert de vraag niet: het creëert nieuwe keuzes en verschuift de drempels.

Ik denk dat je dit allemaal terugziet in de ervaringen met de implementatie van enterprise AI in de afgelopen drie jaar. Elk groot bedrijf heeft iedereen Copilot (of misschien ChatGPT of Claude) gegeven. Een klein aantal mensen gebruikt dit veel (sommigen verhoogden hun productiviteit daadwerkelijk), terwijl een grotere groep het een paar keer per week gebruikt en een groot deel van het bedrijf het eigenlijk helemaal niet gebruikt. Dit is ten dele een probleem van verandermanagement en training, maar het is vooral hetzelfde probleem als wanneer je iedereen in het bedrijf een pc en Lotus 123 had gegeven in 1983, of een internetverbinding en een webbrowser in 1997. Hoe vertaalt dit zich precies naar de taken van iedereen en de problemen die ze deze week daadwerkelijk hebben? Ja, je hebt iedereen een pc en Lotus gegeven, maar dat was niet de manier waarop je de efficiëntie van je factuurverwerking transformeerde. Ja, je hebt iedereen een webbrowser gegeven, maar dat was niet de manier waarop je je supply chain management herbouwde rond het internet, en zeker niet hoe een retailer e-commerce ging beheren.

In nauwe zin denken bedrijven over het veranderen van dit soort structurele processen door pilots te starten. Je voert proeven uit met producten (zowel gekocht als intern gebouwd) die de nieuwe mogelijkheden van AI gebruiken om processen te automatiseren die je voorheen niet kon automatiseren. Er zijn nu allerlei gegevens over hoeveel van deze pilots er zijn, hoeveel er werken (ongeveer de helft, wat normaal is — dat is waarom het pilots zijn!) en wat er mis kan gaan.

Maar opnieuw: dit is een zeer ouderwetse CIO-conversatie over use-cases, 'lighthouses', pilots, helden, snelle successen en meetbare resultaten. Ondertussen krabben de CEO en de raad van bestuur zich op het hoofd en zeggen: "Wacht eens, we hebben honderden workflows en we hebben vijf of tien pilots gedaan. Dat lijkt niet schaalbaar." Iedereen in het bedrijf ChatGPT geven is theoretisch wel schaalbaar, behalve dat de meeste mensen geen manier vinden om het echt te gebruiken.

Teruggaand naar het hypothetische voorbeeld van een bank die iedereen in de jaren 80 spreadsheets gaf, of een retailer die iedereen in de jaren 90 een webbrowser gaf: ja, natuurlijk moet je dat doen, en ja, natuurlijk moet je nadenken over training, verandermanagement en al die andere goede dingen waar KPMG je over kan vertellen. Maar dat is niet hoe je denkt over het transformeren van de manier waarop je bedrijf werkt rond een nieuwe, generatie-overschrijdende technologie.

Drie vragen voor transformatie

Als ik een stap terugdoe, lijkt het me dat elk bedrijf bij elke nieuwe transformerende technologie drie soorten vragen moet stellen:

1. Hoe kopen, bouwen en implementeren we dit? Doen we pilots? Kiezen we voor het product dat gebundeld is bij Microsoft/Google/Oracle, bouwen we zelf iets, betalen we iemand om iets te bouwen, of kopen we dit nieuwe ding van een startup?
2. In hoeverre verandert dit onze operaties? Wat betekent dit? Wat betekent e-mail voor ons? Wat betekenen spreadsheets voor ons? Het antwoord daarop kan radicaal verschillen of je nu een verzekeringsmaatschappij of een advocatenkantoor bent.
3. Creëert dit nieuwe uitdagingen voor de economie van ons bedrijf, nieuwe concurrentiedruk, of misschien een existentieel risico?

Je beantwoordt deze vragen niet door iedereen 'Claude voor X' te geven. Sterker nog, dit alles betekent veel nieuwe pitches voor professionele diensten (wat ironisch is, gezien hoeveel vragen AI stelt aan hun eigen bedrijfsmodellen). Wil je uitzoeken hoe je een LLM-gestuurde voice-analytics tool implementeert in je callcenter? Dan bel je waarschijnlijk Accenture. De leveranciers zelf zijn altijd blij om te helpen, en nu hebben de grote labs hun eigen 'deploycos'. We maakten vroeger de grap dat een 'machine learning scientist' een statisticus is die in San Francisco woont; misschien is een forward deployed engineer nu iedereen die OpenAI heeft aangenomen van een systeemintegrator.

Aan de andere kant: bouwt je startup een geweldige nieuwe tool en wil je snel op de markt komen? Dan bel je waarschijnlijk de Big Four. Je bent gefrustreerd door hoe moeilijk het is om AI-software te verkopen aan advocatenkantoren of accountantskantoren. Oké — start dan een 'AI-enabled' advocatenkantoor en zoek uit of dat een belangrijk hefboompunt kan zijn (of dat het is als het starten van een 'PC-enabled' advocatenkantoor in de jaren 80). En natuurlijk, als je het bestuur bent en je probeert uit te zoeken of dit een existentieel risico is of een enorme kans voor omzet, dan denk je aan het bellen van Bain, BCG en McKinsey (of je bevriende M&A-bankier) — dat is waar zij goed in zijn.

Als we nog verder uitzoomen, is er een veel eenvoudigere manier om naar de vraag te kijken. Bij elke nieuwe technologie beginnen we met het gebruik ervan voor het werk dat we al hebben, en we doen dat gewoon meer en sneller. Maar na verloop van tijd maak je volledig nieuwe dingen. We zullen AI gebruiken om brede klassen van zaken te automatiseren binnen bestaande workflows en bestaande bedrijven (hoewel dat, zoals ik hierboven heb uiteengezet, enorm veel meer moeite en werk zal kosten dan alleen iedereen een model geven). Maar bij elke vorige platformverschuiving was hetgeen dat er echt toe deed, hetgeen dat voorheen niet eens mogelijk was en waar niemand zelfs maar van droomde.