Home Nieuws Bouwen versus kopen is dood – AI heeft het zojuist gedood

Bouwen versus kopen is dood – AI heeft het zojuist gedood

8
0
Bouwen versus kopen is dood – AI heeft het zojuist gedood

Stel je dit eens voor: je zit in een vergaderruimte, halverwege een leverancierspresentatie. De demo ziet er solide uit en de prijzen liggen ruim binnen het budget. Ook de timing lijkt redelijk. Iedereen knikt.

Je bent letterlijk minuten verwijderd van het zeggen van ja.

Dan komt iemand van je financiële team binnen. Ze zien het dek en fronsen. Een paar minuten later sturen ze je een bericht op Slack: “Eigenlijk heb ik vorige week een versie hiervan samengesteld. Het kostte me 2 uur met Cursor. Wil je het eens bekijken?”

Wacht… wat?

Dit de persoon codeert niet. Je weet zeker dat ze in hun hele leven nog nooit een regel JavaScript hebben geschreven. Maar hier zijn ze dan, ze laten je een werkend prototype op hun laptop zien dat vrijwel precies doet wat de verkoper voorstelde. Natuurlijk heeft het wat ruwe kantjes, maar het werkt. En het kostte geen zes cijfers. Slechts twee uur van hun tijd.

Plotseling kwamen de aannames waarmee je binnenkwam – over het hoe de software wordt ontwikkeldwie het doet en hoe er beslissingen over worden genomen – alles begint uit elkaar te vallen.

Het oude schilderij

Al tientallen jaren stelt elk groeiend bedrijf zichzelf dezelfde vraag: Moeten we het zelf bouwen of moeten we het kopen?

En decennialang was het antwoord vrij eenvoudig: Bouw als het van cruciaal belang is voor uw bedrijf; kopen als dat niet het geval is.

De logica klopte, want bouwen was duur en betekende het lenen van tijd van overwerkte ingenieurs, het schrijven van specificaties, het plannen van sprints, het beheren van de infrastructuur en het voorbereiden op een lange wachtrij voor onderhoud. De aankoop verliep sneller. Veiliger. Je hebt betaald voor ondersteuning en gemoedsrust.

Maar er is iets fundamenteels veranderd: kunstmatige intelligentie heeft de bouw voor iedereen toegankelijk gemaakt. Wat vroeger weken duurde, duurt nu uren, en wat vroeger de beheersing van een programmeertaal vereiste, vereist nu de beheersing van gewoon Engels.

Wanneer de kosten en complexiteit van de bouw zo dramatisch instorten, stort het oude raamwerk mee in. Het is niet langer bouwen versus kopen. Het is iets vreemds waar we nog niet de juiste woorden voor hebben gevonden.

Wanneer de markt (nog) niet weet wat jij nodig hebt

Mijn bedrijf was nooit van plan zoveel tools te bouwen die we gebruiken. We moesten gewoon bouwen omdat de dingen die we nodig hadden niet bestonden. En door dit proces ontwikkelden we een diepgeworteld begrip van wat we echt wilden, wat nuttig was en wat het wel en niet kon doen. Niet wat leveranciersdecks ons vertelden dat we nodig hadden of wat analistenrapporten zeiden dat we zouden moeten willen, maar wat feitelijk de doorslag gaf in ons bedrijf.

We begrepen welke problemen de moeite waard waren om op te lossen, en welke niet. waar AI een echte hefboomwerking heeft gecreëerd en waar alleen maar lawaai was. En pas toen, toen we die zuurverdiende duidelijkheid hadden, begonnen we met kopen.

Op dat moment wisten we precies wat we zochten en konden we in ongeveer vijf minuten onderscheid maken tussen inhoud en marketing. We stelden vragen die de verkopers zenuwachtig maakten, omdat we al een rudimentaire versie hadden gemaakt van wat ze verkochten.

Wanneer iedereen binnen enkele minuten kan bouwen

Vorige week merkte iemand van ons CX-team feedback van klanten op over een bug in Slack. Even een kleine klacht van een klant, niets ernstigs. Bij een ander bedrijf zou dit een supportticket hebben geactiveerd en zouden ze hebben gewacht tot iemand anders het zou regelen, maar dat is hier niet gebeurd. Ze openden Cursor, beschreven de wijziging en lieten de AI de oplossing schrijven. Vervolgens stuurden ze een pull-verzoek dat door engineering werd beoordeeld en samengevoegd.

Slechts 15 minuten nadat de klacht op Slack verscheen, was de oplossing al in productie.

De persoon die dit heeft gedaan, is in het geheel niet technisch. Ik betwijfel of ze je het verschil tussen Python en JavaScript konden vertellen, maar ze hebben het probleem toch opgelost.

En dat is het punt.

AI is zo goed geworden in het produceren van relatief eenvoudige code dat het 80% van de problemen oplost waarvoor voorheen een sprintplanningsvergadering en twee weken ontwerptijd nodig waren. Het vervaagt de grens tussen technisch en niet-technisch. Werk dat vroeger door engineering werd belemmerd, wordt nu gedaan door de mensen die het dichtst bij het probleem staan.

Dit gebeurt nu in bedrijven die daadwerkelijk opletten.

De omkering die plaatsvindt

Dit is waar het voor financiële leiders fascinerend wordt, omdat AI feitelijk de hele strategische logica van de beslissing om te bouwen versus de beslissing om te kopen heeft omgedraaid.

Het oude model zag er ongeveer zo uit:

  1. Definieer de behoefte.

  2. Bepaal of u wilt bouwen of kopen.

Maar het definiëren van de behoefte duurde een eeuwigheid en vergde diepgaande technische expertise, anders zou je geld hebben verspild door middel van proefondervindelijke implementaties van leveranciers. Je zou talloze demo’s moeten doorlopen en proberen je voor te stellen of dit je probleem daadwerkelijk oploste. Vervolgens onderhandelt u, implementeert u, verplaatst u al uw gegevens en workflows naar de nieuwe tool, en zes maanden en zes cijfers later komt u erachter of (of niet) eigenlijk had je gelijk.

Nu is de hele reeks omgekeerd:

  1. Bouw iets lichts met AI.

  2. Gebruik het om erachter te komen wat je echt nodig hebt.

  3. Beslis vervolgens of u het wilt kopen (en u weet precies waarom).

Met deze aanpak kunt u gecontroleerde experimenten uitvoeren. Ontdek of het probleem belangrijk is. Ontdek welke functies waarde bieden en welke er in demo’s gewoon goed uitzien. Dan ga winkelen. In plaats van je door een externe leverancier te laten verkopen wat de behoefte is, kun je erachter komen of je die behoefte überhaupt hebt.

Bedenk eens hoeveel softwareaankopen u heeft gedaan waarmee u achteraf gezien problemen heeft opgelost die u in werkelijkheid niet had. Hoe vaak heb je drie maanden aan een implementatie besteed en gedacht: “Wacht, helpt dit ons echt of proberen we alleen maar te rechtvaardigen wat we hebben uitgegeven?”

Wanneer u nu iets koopt, rijst de vraag: “Lost dit het probleem beter op dan wat we al hebben bewezen te kunnen bouwen?”

Die herkadering verandert het hele gesprek. Nu verschijnt u op de hoogte van telefoontjes van leveranciers. Stel scherpere vragen en onderhandel vanuit kracht. Wat nog belangrijker is, u vermijdt de duurste fout in bedrijfssoftware: het oplossen van een probleem dat u eigenlijk nooit heeft gehad.

De valkuil die je moet vermijden

Nu deze nieuwe mogelijkheid zich aandient, zie ik dat bedrijven de verkeerde kant op gaan. Ze weten dat ze AI-native moeten zijn, dus gaan ze winkelen. Ze zoeken naar door AI aangedreven tools en vullen hun stapel met producten met GPT-integraties, chatbot-gebruikersinterfaces of ‘AI’ ingevoegd in de marketingsite. Ze denken dat ze aan het transformeren zijn, maar dat is niet zo.

Denk aan wat hij de natuurkundige Richard Feynman noemde vrachtcultuswetenschap? Na de Tweede Wereldoorlog bouwden de eilandbewoners in de Stille Zuidzee nep-landingsbanen en controletorens, waarbij ze nabootsten wat ze tijdens de oorlog hadden gezien, in de hoop dat vliegtuigen vol vracht zouden terugkeren. Ze hadden alle uiterlijke vormen van een luchthaven: torens, koptelefoons en zelfs mensen die luchtverkeersleiders imiteerden. Maar er landde geen vliegtuig, omdat vorm geen functie was.

Dit is precies wat er gebeurt nu AI directiekamers over de hele wereld transformeert. Leiders kopen AI-tools zonder zich af te vragen of ze de manier waarop het werk wordt gedaan aanzienlijk veranderen, wie ze machtigen of welke processen ze ontsluiten.

Ze hebben de landingsbaan aangelegd, maar de vliegtuigen komen niet.

En de hele markt is er feitelijk op gericht om jou in deze val te laten trappen. Nu wordt alles bestempeld als kunstmatige intelligentie, maar het lijkt niemand iets uit te maken wat deze producten eigenlijk doen. Elk SaaS-product heeft een chatbot- of autocomplete-functie gebruikt en er een AI-label op geplakt, en het label heeft alle betekenis verloren. Het is gewoon een selectievakje dat verkopers denken te moeten aanvinken, ongeacht of het daadwerkelijke waarde voor klanten creëert.

De fde nieuwe superkracht van het financiële team

Dit is het deel dat mij enthousiast maakt over wat financiële teams nu kunnen doen. Je hoeft niet langer te raden. Je hoeft geen zes cijfers in te zetten op een verkoopstapel. Je kunt dingen uitproberen en je kunt daadwerkelijk iets leren voordat je geld uitgeeft.

Dit is wat ik bedoel: als u software voor leveranciersbeheer evalueert, maak dan een prototype van uw kernworkflow met AI-tools. Ontdek of u een gereedschapsprobleem of een procesprobleem oplost. Ontdek of u software nodig heeft.

Dat betekent niet dat je alles in eigen beheer gaat bouwen, natuurlijk niet. In de meeste gevallen zul je uiteindelijk toch kopen, en dat is prima, want bedrijfshulpmiddelen bestaan ​​om goede redenen (omvang, ondersteuning, beveiliging en onderhoud). Maar nu koop je met je ogen wijd open.

Je zult weten wat ‘goed’ betekent. U komt naar de demo’s en begrijpt al de randgevallen en weet binnen ongeveer 5 minuten of ze uw specifieke probleem daadwerkelijk oplossen. Je implementeert sneller. Je onderhandelt beter omdat je niet volledig afhankelijk bent van de oplossing van de verkoper. En u zult ervoor kiezen omdat het werkelijk beter is dan wat u zelf zou kunnen bouwen.

Je hebt de vorm van wat je nodig hebt al in kaart gebracht en gaat alleen op zoek naar de beste versie.

Het nieuwe paradigma

Het mantra is al jaren: bouwen of kopen.

Nu is het slanker en veel slimmer: bouw om te leren wat je moet kopen.

En het is geen toekomstige staat. Dit gebeurt al. Op dit moment gebruikt een klantvertegenwoordiger ergens kunstmatige intelligentie om een ​​productprobleem op te lossen dat een paar minuten geleden is opgemerkt. Ergens anders is een financieel team bezig met het prototypen van hun analysetools, omdat ze zich realiseerden dat ze sneller kunnen itereren dan dat ze technische vereisten kunnen schrijven. Ergens realiseert een team zich dat de grens tussen technisch en niet-technisch altijd eerder cultureel dan fundamenteel is geweest.

Bedrijven die deze verandering omarmen, zullen sneller handelen en slimmer uitgeven. Ze zullen hun activiteiten beter kennen dan welke leverancier dan ook ooit zou kunnen. Ze zullen minder kostbare fouten maken en beter gereedschap kopen, omdat ze daadwerkelijk begrijpen wat het gereedschap goed maakt.

Bedrijven die vasthouden aan het oude draaiboek zullen leverancierspresentaties blijven bijwonen en knikken naar handige voorstellen. Ze zullen ruzie maken over deadlines en professionele decks blijven verwarren met echte oplossingen.

Totdat iemand in hun team zijn laptop openklapt en zegt: “Ik heb gisteravond een versie hiervan gebouwd. Wil je het proberen?”, en hen iets laat zien dat ze in twee uur hebben gebouwd en dat 80% bedraagt ​​van waar ze zes cijfers voor gaan betalen.

En zomaar veranderen de regels voor altijd.

Siqi Chen is mede-oprichter en CEO van Runway.

Lees meer van onze gastschrijvers. Of overweeg om uw eigen bericht in te dienen! Zie de onze richtlijnen hier.

Nieuwsbron

LAAT EEN REACTIE ACHTER

Vul alstublieft uw commentaar in!
Vul hier uw naam in