Build vs. buy: bygge eller købe systemet?
Byg systemer hvor I differentierer jer, og køb hvor I er som alle andre. Det er grundreglen bag build vs. buy. Underbyg beslutningen med en femårskalkule der vejer licens- og tilpasningsomkostninger mod udviklings-, drifts- og vedligeholdelsesomkostninger. De dyreste fejl er at bygge det man lige så godt kunne have købt, og at købe det der er selve forretningen.
“Skal vi bygge det selv eller købe noget færdigt?” er en af de største beslutninger en organisation træffer om sine systemer, og en af de letteste at træffe på mavefornemmelsen. Denne side giver dig ikke en holdning, men en beslutningsmodel: en regel at læne dig op ad, en kalkule at regne på og et kort over de fælder der fanger folk i begge retninger.
Grundreglen: Differentiering afgør
Skræl alt andet væk, og dette er tilbage: Byg hvor I differentierer jer, køb hvor I er som alle andre.
Det spørgsmål du stiller om hvert system, er altså ikke “kan vi bygge det?”, for næsten alt kan bygges. Spørgsmålet er “gør det her os unikke?” Hvis svaret er nej, skal I købe. Et økonomisystem gør jer ikke skarpere end konkurrenterne, hvor flot I end bygger det. Den proces der får kunder til at vælge netop jer, er derimod værd at eje.
Reglen er stærk fordi den flytter fokus fra teknik til forretning. Det er ikke noget udviklingsafdelingen skal afgøre alene, men et spørgsmål om hvor jeres forspring faktisk ligger.
Femårskalkulen
Når reglen ikke giver et oplagt svar, er du nødt til at regne, men på den rigtige måde. Den fejl folk begår, er at sammenligne en synlig indkøbspris med en usynlig udviklingsomkostning. Den rigtige sammenligning er de samlede omkostninger over fem år.
| Vej | Omkostninger at lægge sammen over 5 år |
|---|---|
| Købe | Licenser, tilpasninger, opgraderinger, lock-in |
| Bygge | Udvikling, vedligeholdelse, drift, men fuld kontrol og ingen licens |
| Hybrid | Standardlicens til kernen plus udvikling af de unikke dele |
Et købt system har en lav indgangspris, men løbende licenser og en tilpasningsregning der vokser hver gang en ny version ødelægger det I har skræddersyet. Et egenudviklet system har en høj indgangspris, men ingen licens og fuld kontrol. Hvilken vej der bliver billigst, afhænger af hvor godt et standardsystem faktisk passer, og det er netop pasformen kalkulen tvinger frem i lyset.
De hyppigste fejlbeslutninger i begge retninger
Der er to klassiske måder at tage fejl på, og de er hinandens spejlbilleder.
- Bygge det man kunne have købt. Et team beslutter at bygge sit eget generiske system, ofte fordi det føles sjovere eller mere fleksibelt. To år senere har de en halvfærdig kopi af et standardsystem plus en vedligeholdelsesforpligtelse der aldrig slutter. Konsekvens: penge og tid brændt af på noget uden konkurrencefordel.
- Købe det der er forretningen. En virksomhed presser sin særegne proces ind i et standardsystem for at spare penge. Systemet bøjer sig ikke, så de bøjer sig selv og mister netop det der gjorde dem unikke. Konsekvens: en billig løsning der udhuler selve forretningen.
Et konkret eksempel: En logistikvirksomhed hvis styrke var dens egen ruteoptimering, købte et standardsystem som “næsten” kunne klare det. Næsten viste sig at koste dem det der adskilte dem fra konkurrenterne. Havde de i stedet købt økonomidelen færdig og bygget ruteoptimeringen selv, havde de både fået lave omkostninger og bevaret deres forspring.
Hvem bør eje beslutningen?
En af grundene til at det går galt, er at beslutningen havner på det forkerte bord. Overlades den alene til den tekniske side, frister egenudviklingen fordi det er mere stimulerende at bygge end at konfigurere noget færdigt. Overlades den alene til økonomisiden, frister indkøbsprisen fordi licensen ser billig ud ved siden af et udviklingsbudget. Ingen af vinklerne ser hele billedet alene.
Den rigtige beslutning kræver at både forretning, teknik og økonomi sidder ved samme bord og stiller det eneste spørgsmål der betyder noget: Gør det her os anderledes, eller gør det os som alle andre? Det er et forretningsspørgsmål før det er et teknisk. Hold det spørgsmål i centrum, læn dig op ad femårskalkulen og hav de to klassiske fejlbeslutninger i baghovedet, så lander de fleste valg rigtigt.
Den rigtige beslutning kræver altså at nogen tør stille det ubekvemme spørgsmål om hvor jeres reelle værdi ligger. Vil I have en neutral sparringspartner til netop jeres systemer, drøfter vi i Weapp gerne helheden og kan gennemgå valgene med jer før I binder jer.
Ofte stillede spørgsmål
Hvad er grundreglen for build vs. buy?
Byg hvor I differentierer jer, køb hvor I er som alle andre. Det der gør jer unikke og konkurrencedygtige, er værd at eje og forme selv. Det der ser ens ud i alle virksomheder, som økonomi, løn og e-mail, køber I færdigt. Reglen løser de fleste tilfælde uden at I overhovedet behøver at regne.
Hvordan laver jeg en fair sammenligning af omkostningerne?
Regn på fem år, ikke på indkøbsprisen. Ved køb: licenser, tilpasning og opgraderinger. Ved udvikling: udvikling plus løbende drift og vedligeholdelse. Medregn også hvad henholdsvis lock-in og fuld kontrol koster. Først da sammenligner du de reelle samlede omkostninger i stedet for et synligt prisskilt med et usynligt.
Hvad er den mest almindelige fejlbeslutning?
At bygge det man lige så godt kunne have købt. Teams undervurderer hvor meget arbejde det er at bygge og for evigt vedligeholde noget generisk som allerede findes færdigt. Resultatet bliver en dyr egen variant af et standardsystem uden nogen egentlig fordel sammenlignet med at have købt det.
Og den mest almindelige fejl i den anden retning?
At købe et standardsystem til det der faktisk er selve forretningen. Så bliver I tvunget til at tilpasse jeres unikke proces til systemets måde at arbejde på og mister netop det der adskilte jer fra konkurrenterne. Det I sparede på indkøbet, taber I i konkurrenceevne.
Kan man kombinere at bygge og købe?
Ja, og det er ofte det klogeste. En standardkerne til det generiske kombineret med egenudviklede tilføjelser via API til det unikke giver både lave omkostninger på det almindelige og fuld frihed på det der betyder noget. De fleste modne systemlandskaber ser netop sådan ud.