Bouwen versus kopen is dood – AI heeft het zojuist gedood

Stel je dit eens voor: je zit in een vergaderruimte, midden in een verkooppraatje. De demo ziet er solide uit en de prijs ligt binnen het budget. De tijdlijn lijkt ook redelijk. Iedereen knikte.

Je bent letterlijk minuten verwijderd van het zeggen van ja.

Dan komt iemand van je financiële team binnen. Ze keken naar het dek en fronsten. Een paar minuten later sturen ze je een bericht in Slack: “Eigenlijk heb ik hier vorige week een versie van gemaakt. Het kostte me 2 uur in Cursor. Wil je het zien?”

Wacht… wat?

Dit mensen coderen niet. Je weet zeker dat ze nog nooit in hun leven een regel JavaScript hebben geschreven. Maar hier zijn ze dan, ze laten je een werkend prototype zien op hun laptop, dat is… precies wat de leverancier aanbiedt. Natuurlijk zijn er wat ruwe kantjes, maar het werkt. En de kosten bedragen nog geen zes cijfers. Slechts twee uur van hun tijd.

Plotseling heb je de aannames over hoe software ontwikkeldwie beslissingen neemt en hoe beslissingen daarover worden genomen – dingen beginnen uit elkaar te vallen.

Oud raamwerk

Al tientallen jaren stelt elk groeiend bedrijf dezelfde vragen: Moeten we het zelf maken of kopen?

En decennialang is het antwoord vrij duidelijk geweest: Bouw wat de kern van uw bedrijf is; koop het als dat niet het geval is.

De logica is logisch, want bouwen is duur en betekent dat je tijd moet lenen van overwerkte ingenieurs, specificaties moet schrijven, sprints moet plannen, de infrastructuur moet beheren en je moet voorbereiden op onderhoud op de lange termijn. Koop sneller. Veiliger. U betaalt voor ondersteuning en gemoedsrust.

Maar er is iets fundamenteels veranderd: AI heeft bouwen voor iedereen toegankelijk gemaakt. Wat vroeger weken duurde, duurt nu uren, en wat ooit vloeiendheid in een programmeertaal vereiste, vereist nu vloeiend Engels.

Toen de kosten en complexiteit van ontwikkeling drastisch instortten, stortte 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 van de tools die we gebruiken te maken. We moeten gewoon bouwen omdat de dingen die we nodig hebben niet bestaan. En door dat proces ontwikkelen we een diep begrip van wat we echt willen, wat nuttig is en wat wel of niet kan worden gedaan. Niet wat leveranciers zeggen dat we nodig hebben of wat analistenrapporten zeggen dat we zouden moeten willen, maar wat ons bedrijf feitelijk drijft.

We ontdekken welke problemen de moeite waard zijn om op te lossen, en welke niet. waar AI echte impact creëert en op die plek is het alleen maar lawaai. En pas dan, zodra we de zwaarbevochten duidelijkheid hebben verkregen, beginnen 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 stellen vragen die verkopers nerveus maken, omdat we een basisversie hebben gemaakt van wat ze verkopen.

Wanneer iedereen binnen enkele minuten kan bouwen

Vorige week merkte iemand van ons CX-team feedback van klanten op over een bug in Slack. Gewoon een kleine klacht van een klant, geen probleem. Bij andere bedrijven zou dit een supportticket openen en wachten tot iemand anders het zou afhandelen, maar dat is hier niet het geval. Ze openen de Cursor, leggen de wijzigingen uit en laten de AI de oplossing schrijven. Vervolgens dienen ze een pull-verzoek in dat door technici wordt beoordeeld en samengevoegd.

Slechts 15 minuten nadat de klacht in Slack verscheen, was er een oplossing in productie.

De mensen die dit doen zijn helemaal geen technische mensen. 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 creëren van relatief eenvoudige code dat het 80% van de problemen aankan waarvoor normaal gesproken een sprintplanningsvergadering en twee weken engineeringtijd nodig zijn. Het verwijdert de grenzen tussen technisch en niet-technisch. Werk dat ooit door engineering werd belemmerd, wordt nu gedaan door de mensen die het dichtst bij het probleem staan.

Dit gebeurt momenteel bij bedrijven die echt opletten.

De omkering die plaatsvond

Dit is waar het interessant wordt voor financiële leiders, omdat AI feitelijk de hele strategische logica van de beslissing over bouwen versus kopen op zijn kop heeft gezet.

Het oude model ging als volgt:

1. Bepaal de behoeften.

2. Bepaal of u wilt bouwen of kopen.

Maar het definiëren van vereisten kost veel tijd en vereist diepgaande technische expertise, anders besteedt u veel geld aan de proefondervindelijke implementatie door leveranciers. Je doorloopt talloze demo’s en probeert je voor te stellen of dit je probleem echt oplost. Vervolgens onderhandel je, implementeer je, verplaats je al je gegevens en workflows naar de nieuwe tool en zes maanden en zes cijfers later kom je erachter of (of niet) je hebt eigenlijk gelijk.

Nu wordt de hele reeks op zijn kop gezet:

1. Bouw iets lichts met AI.

2. Gebruik het om te begrijpen wat u echt nodig heeft.

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

Met deze aanpak kunt u gecontroleerde experimenten uitvoeren. Je ontdekt of het probleem belangrijk is. In de demo ontdekt u welke functies waarde bieden en welke er goed uitzien. Dan jij gaat winkelen. In plaats van externe leveranciers u te laten verkopen wat u nodig heeft, moet u erachter komen of u die behoefte ook daadwerkelijk heeft.

Bedenk eens hoeveel softwareaankopen u heeft gedaan waarmee u achteraf gezien een probleem had kunnen oplossen dat u in werkelijkheid niet had. Hoe vaak ben je drie maanden bezig geweest met een implementatie en dacht je: “Wacht, helpt dit ons echt, of proberen we alleen maar de kosten die we maken te rechtvaardigen?”

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

Die herkadering verandert het hele gesprek. Het lijkt erop dat u oproepinformatie van een leverancier ontvangt. Je stelt scherpere vragen en onderhandelt vanuit een sterke positie. Het allerbelangrijkste is dat u de duurste fouten in bedrijfssoftware vermijdt, namelijk het oplossen van problemen die u eigenlijk nooit heeft gehad.

Valkuilen die u moet vermijden

Nu deze nieuwe mogelijkheden zich aandienen, zie ik dat bedrijven de verkeerde kant op gaan. Ze weten dat ze AI onder de knie moeten krijgen, dus gaan ze winkelen. Ze zijn op zoek naar door AI aangedreven tools en vullen hun stapels met producten met GPT-integratie, chatbot-UI of ‘AI’ ingebakken in marketingsites. Ze dachten dat ze aan het transformeren waren, maar blijkbaar niet.

Weet je nog wat natuurkundige Richard Feynman noemde? vrachtcultuswetenschap? Na de Tweede Wereldoorlog bouwden eilandbewoners in de Stille Zuidzee valse landingsbanen en controletorens, in de hoop dat de overbelaste vliegtuigen zouden terugkeren. Ze beschikken over alle luchthavenfuncties: torens, headsets en zelfs mensen die zich voordoen als vluchtleiders. Maar er landden geen vliegtuigen, omdat vorm geen functie is.

Dat is wat er overal gebeurt met de AI-transformatie in vergaderruimtes. Leiders kopen AI-tools zonder zich af te vragen of ze de manier waarop het werk wordt gedaan kunnen veranderen, wie ze kunnen machtigen of welke processen ze mogelijk kunnen maken.

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

En de hele markt is er feitelijk op gericht om jou in deze val te laten trappen. Nu wordt alles bestempeld als AI, maar niemand lijkt zich iets aan te trekken van de daadwerkelijke functie van deze producten. Aan elk SaaS-product is een chatbot of autocomplete-functie gekoppeld en er is een AI-label op geplakt, waardoor het label zijn betekenis verliest. Dit is eenvoudigweg een selectievakje dat leveranciers moeten aanvinken, ongeacht of het daadwerkelijke waarde voor de klant creëert.

Fde nieuwe superkracht van het financiële team

Dit is het deel dat mij enthousiast maakt over wat financiële teams vandaag de dag kunnen doen. Je hoeft niet meer te raden. U hoeft geen zes cijfers in te zetten op een verkoopstapel. Je kunt dingen testen, en je kunt daadwerkelijk iets leren voordat je het uitgeeft.

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

Dit betekent niet dat je alles intern gaat bouwen – natuurlijk niet. Vaak koop je het toch, en dat is prima, want bedrijfstools zijn er om goede redenen (schaal, ondersteuning, beveiliging en onderhoudbaarheid). Maar nu koop je met je ogen wijd open.

Je zult weten hoe ‘goed’ eruit ziet. U komt naar de demo en begrijpt al de randgevallen, en weet binnen ongeveer 5 minuten of ze uw specifieke probleem echt begrijpen. Je implementeert het sneller. Je onderhandelt beter omdat je niet volledig afhankelijk bent van de oplossing van de verkoper. En je kiest ervoor omdat het echt beter is dan wat je zelf zou kunnen bouwen.

Je hebt de vorm die je nodig hebt in kaart gebracht en je hoeft alleen nog maar de beste versie te vinden.

Nieuw paradigma

Jarenlang was het mantra: bouw het of koop het.

Nu is het eleganter en slimmer: word wakker en ontdek wat u moet kopen.

En dit is geen toekomstige situatie. Dit is gebeurd. Op dit moment gebruikt een klantvertegenwoordiger ergens AI om een ​​productprobleem op te lossen dat hij minuten geleden heeft ontdekt. Elders zijn financiële teams bezig met het prototypen van hun eigen analysetools, omdat ze beseffen dat ze sneller kunnen itereren dan het schrijven van vereisten voor engineering. Ergens in de loop van de tijd realiseerde een team zich dat de grenzen tussen technisch en niet-technisch altijd eerder cultureel dan fundamenteel waren.

Bedrijven die deze veranderingen omarmen, zullen sneller handelen en hun geld slimmer uitgeven. Zij zullen hun activiteiten beter kennen dan welke leverancier dan ook. Ze zullen minder kostbare fouten maken en betere gereedschappen kopen omdat ze echt begrijpen wat een gereedschap goed maakt.

Bedrijven die zich aan de oude richtlijnen houden, zullen zich houden aan biedingen van leveranciers en akkoord gaan met budgetvriendelijke voorstellen. Ze zullen ruzie maken over het schema en professionele discussies blijven verwarren met de daadwerkelijke oplossing.

Totdat iemand in hun team zijn laptop openklapt en zegt: “Ik heb daar gisteravond een versie van gemaakt. Wil je het eens proberen?”, En hen iets laat zien dat ze in twee uur hebben gemaakt en dat 80% bedraagt ​​van de prijs van zes cijfers die ze zouden hebben betaald.

En zomaar veranderden de regels voor altijd.

Siqi Chen is de mede-oprichter en CEO van Runway.

Lees meer van ons gastauteur. Of overweeg om uw eigen bericht in te dienen! Bekijk ons richtlijnen hier.