Bygge eller kjøpe systemet?
Bygg systemer der dere skiller dere ut, og kjøp der dere er som alle andre. Det er kjerneregelen bak build vs. buy. Underbygg beslutningen med en femårskalkyle som veier lisens- og tilpasningskostnad mot utviklings- og forvaltningskostnad. De dyreste feilene er å bygge det man like gjerne kunne ha kjøpt, og å kjøpe det som er selve virksomheten.
«Skal vi bygge det selv eller kjøpe noe ferdig?» er en av de største beslutningene en virksomhet tar om systemene sine, og en av de letteste å ta på magefølelsen. Denne siden gir deg ikke synsing, men en beslutningsmodell: en regel å støtte deg til, en kalkyle å regne på og et kart over fellene som fanger folk i begge retninger.
Kjerneregelen: differensiering avgjør
Skrell bort alt annet, og dette står igjen: bygg der dere skiller dere ut, kjøp der dere er som alle andre.
Spørsmålet du stiller om hvert system, er altså ikke «kan vi bygge det?». Nesten alt kan bygges. Spørsmålet er «gjør dette oss unike?». Er svaret nei, bør dere kjøpe. Et økonomisystem gjør dere ikke skarpere enn konkurrentene, uansett hvor fint dere bygger det. Prosessen som får kunder til å velge nettopp dere, er derimot verdt å eie.
Regelen er kraftfull fordi den flytter fokuset fra teknologi til forretning. Dette er ikke noe utviklingsavdelingen skal avgjøre alene, men et spørsmål om hvor forspranget dere har, faktisk ligger.
Femårskalkylen
Når regelen ikke gir et selvsagt svar, må du regne, men på riktig måte. Feilen folk gjør, er å sammenligne en synlig innkjøpspris med en usynlig utviklingskostnad. Riktig sammenligning er totalkostnaden over fem år.
| Vei | Kostnader å summere over 5 år |
|---|---|
| Kjøpe | Lisenser, tilpasninger, oppgraderinger, innlåsing |
| Bygge | Utvikling, forvaltning, drift, men full kontroll og ingen lisens |
| Hybrid | Standardlisens for kjernen pluss utvikling av de unike delene |
Et kjøpt system har lav inngangsterskel, men løpende lisenser og en tilpasningsregning som vokser hver gang en ny versjon ødelegger det dere har skreddersydd. Et egenutviklet system har høy inngangsterskel, men ingen lisens og full kontroll. Hva som blir billigst, avhenger av hvor godt et standardsystem faktisk passer, og det er nettopp passformen kalkylen tvinger frem i lyset.
De vanligste feilbeslutningene, i begge retninger
Det finnes to klassiske måter å gå feil på, og de er hverandres speilbilder.
- Bygge det man kunne ha kjøpt. Et team bestemmer seg for å bygge sitt eget generiske system, ofte fordi det føles morsommere eller mer fleksibelt. To år senere har de en halvferdig kopi av et standardsystem, pluss en vedlikeholdsforpliktelse som aldri tar slutt. Konsekvens: penger og tid brent på noe uten konkurransefortrinn.
- Kjøpe det som er virksomheten. Et selskap presser sin særegne prosess inn i et standardsystem for å spare penger. Systemet bøyer seg ikke, så det er de som bøyer seg, og de mister nettopp det som gjorde dem unike. Konsekvens: en billig løsning som uthuler selve forretningen.
Et konkret eksempel: Et logistikkselskap som hadde sin styrke i en egen ruteoptimalisering, kjøpte et standardsystem som «nesten» klarte det. Det «nesten» viste seg å koste dem det som skilte dem fra konkurrentene. Hadde de i stedet kjøpt økonomidelen ferdig og bygget ruteoptimaliseringen selv, ville de ha fått lav kostnad og samtidig beholdt forspranget.
Hvem bør eie beslutningen?
En årsak til at det går galt, er at beslutningen havner på feil bord. Overlates den bare til teknologisiden, frister egenutvikling, for det er mer stimulerende å bygge enn å konfigurere noe ferdig. Overlates den bare til økonomisiden, frister innkjøpsprisen, for lisensen ser billig ut ved siden av et utviklingsbudsjett. Ingen av perspektivene ser hele bildet alene.
Riktig beslutning krever at forretning, teknologi og økonomi sitter ved samme bord og stiller det eneste spørsmålet som betyr noe: Gjør dette oss annerledes, eller gjør det oss som alle andre? Det er et forretningsspørsmål før det er et teknisk spørsmål. Hold det spørsmålet i sentrum, støtt deg til femårskalkylen og ha de to klassiske feilbeslutningene i minnet, så lander de fleste valg riktig.
Riktig beslutning krever altså at noen tør å stille det ubehagelige spørsmålet om hvor den virkelige verdien i virksomheten ligger. Vil dere ha en nøytral sparringspartner for akkurat systemene dere har, drøfter vi i Weapp gjerne helheten og kan gå gjennom valgene med dere før dere binder dere.
Ofte stilte spørsmål
Hva er kjerneregelen for build vs. buy?
Bygg der dere skiller dere ut, kjøp der dere er som alle andre. Det som gjør dere unike og konkurransedyktige, er verdt å eie og forme selv. Det som ser likt ut i alle virksomheter, som økonomi, lønn og e-post, kjøper dere ferdig. Regelen løser de fleste tilfeller uten at dere engang trenger å regne.
Hvordan gjør jeg en rettferdig kostnadssammenligning?
Regn på fem år, ikke på innkjøpsprisen. For kjøp: lisenser, tilpasning og oppgraderinger. For egenutvikling: utvikling pluss løpende forvaltning. Ta også med kostnaden ved henholdsvis innlåsing og full kontroll. Først da sammenligner du reell totalkostnad i stedet for en synlig prislapp mot en usynlig.
Hva er den vanligste feilbeslutningen?
Å bygge det man like gjerne kunne ha kjøpt. Utviklingsteam undervurderer hvor mye arbeid det er å bygge og for alltid vedlikeholde noe generisk som allerede finnes ferdig. Resultatet blir en dyr egen variant av et standardsystem, uten noen egentlig fordel sammenlignet med å ha kjøpt det.
Og den vanligste feilen i motsatt retning?
Å kjøpe et standardsystem for det som faktisk er selve virksomheten. Da blir dere tvunget til å tilpasse den unike prosessen til systemets måte å jobbe på, og dere mister nettopp det som skilte dere fra konkurrentene. Det dere sparte på innkjøpet, taper dere i konkurransekraft.
Kan man kombinere bygge og kjøpe?
Ja, og det er ofte det klokeste. En standardkjerne for det generiske kombinert med egenutviklede tillegg via API for det unike gir både lav kostnad på det vanlige og full frihet på det som betyr noe. De fleste modne systemlandskap ser nettopp slik ut.