Build vs buy

Build vs buy er valget mellem at bygge en AI-løsning internt, typisk ved at bruge en stor sprogmodel via API og tilpasse den, eller at købe en færdig løsning fra en leverandør. Beslutningen hænger på tre konkrete spørgsmål: hvor unik processen er, hvor hurtigt systemet skal fungere, og hvem der skal drifte og betale ved vækst.

Vigtige kriterier: hvad I skal vurdere

Start med at vurdere, hvor unik arbejdsprocessen er i forhold til standardløsninger. Hvis opgaven er smal og veldefineret, taler meget for at købe; hvis den kræver virksomhedsspecifik viden eller komplekse regler, kan bygge være rimeligt. Tidshorisonten fylder: har I brug for en løsning om uger eller om måneder? Købe giver ofte hurtigere gevinst, bygge kræver tid til udvikling og drift. Hvem skal eje drift og videreudvikling? Internt har I kontrol, men også løbende omkostninger og behov for kompetencer, leverandør holder oftere vedligehold, men kan skabe Vendor lock-in. Skalerbarhed, prisstruktur og datatilladelse skal tænkes sammen; en billig startpris kan blive dyr ved vækst.

Når I står med et tilbud: Build vs buy for beslutningstageren

Når et salgsteam kommer med et tilbud, skal du læse tre ting først: om løsningen kræver, at I deler jeres data, hvordan prisen skalerer, og hvilke exit-muligheder I har. Spørg om datahåndtering: bliver jeres data sendt til leverandørens model eller kan den køre i jeres miljø? Tjek prisens elementer: abonnement, forbrug, opstart, og pris ved 10x brug. Krav til referencer og supportniveau er ikke pynt; de fortæller, om leverandøren kan holde løftet efter kontrakten er underskrevet.

Mellemvejen: køb platform, byg tilpasning

Ofte er svaret ikke enten-eller, men en kombination: køb en platform eller model fra en leverandør og byg forretningslogik ovenpå. Det giver hurtig opstart og samtidig mulighed for at gemme virksomhedsspecifik viden lokalt eller som proprietære indstillinger. Ulempen er ofte ekstra integrationsarbejde, og I kan stadig blive låst til leverandørens dataformat eller prismodel.

Eksempel: Økonomichefen og automatiseret fakturahåndtering

Økonomichefen i en handelsvirksomhed modtager et tilbud onsdag formiddag, tre uger før budgetmødet. Tilbuddet lover automatiseret bogføring fra leverandørens model for 150.000 kr i opstart og et månedligt abonnement. Økonomichefen spørger om leverandøren må bruge tidligere fakturaer i træningen, hvad der sker, hvis virksomheden skifter leverandør, og får referencer fra to kunder i samme branche. Efter et Pilotprojekt på fire uger vælger økonomichefen at købe platformen og lade regnskabsteamet udvikle to automatiske regler internt; implementeringen tog tre uger, men krævede fortsat månedlig support fra leverandøren. Konflikten kom, da leverandørens pris steg ved 5x volumen og regnskabsteamet måtte balancere intern vedligeholdelse mod eksternt supportgebyr.

Hvad du skal spørge en leverandør om

1. Data: hvem ejer input og output-data, og må leverandøren genbruge dem?
2. Exit: hvordan får I jeres data og modeludtræk ud, hvis I vil skifte?
3. Prissætning: hvordan ændrer prisen sig ved vækst, og er der volume-rabatter?
4. Referencer og drift: kan I tale med en kunde, der bruger løsningen i praksis, og hvilken SLA tilbyder I?
5. Sikkerhed og compliance: hvor hostes systemet, og hvilke krav opfylder leverandøren?

Start altid med et Pilotprojekt, men krav til exit og referencer gælder også for piloten. Sørg for kontraktklausuler om dataeksport, prisloft og rettighed til forbedringer, lav en plan for, hvordan systemet migreres, hvis I vil forlade leverandøren. Og husk: Build vs buy er et beslutningsspørgsmål om økonomi og drift, ikke en teknisk definition af Agentic commerce eller andre modetrends.

Skal I beslutte, hvor meget build vs buy må fylde hos jer, er det den slags valg, AI-rådgivning handler om.