Bygga eller köpa systemet?
Bygg system där ni differentierar er och köp där ni är som alla andra. Det är kärnregeln bakom build vs buy. Underbygg beslutet med en femårskalkyl som väger licens- och anpassningskostnad mot bygg- och förvaltningskostnad. De dyraste felen är att bygga det man lika gärna kunnat köpa, och att köpa det som är själva verksamheten.
“Ska vi bygga det själva eller köpa något färdigt?” är ett av de största besluten en verksamhet fattar om sina system – och ett av de lättaste att göra av magkänsla. Den här sidan ger dig inte en åsikt utan en beslutsmodell: en regel att luta dig mot, en kalkyl att räkna på och en karta över de fällor som fångar folk åt båda hållen.
Kärnregeln: differentiering avgör
Skala bort allt annat och det här återstår: bygg där ni differentierar er, köp där ni är som alla andra.
Frågan du ställer om varje system är alltså inte “kan vi bygga det?” – nästan allt går att bygga. Frågan är “gör det här oss unika?” Om svaret är nej ska ni köpa. Ett ekonomisystem gör er inte vassare än konkurrenterna, hur fint ni än bygger det. Den process som får kunder att välja just er, däremot, är värd att äga.
Regeln är kraftfull för att den flyttar fokus från teknik till affär. Det är inte utvecklingsavdelningen som ska avgöra det här ensam, utan en fråga om var ert försprång faktiskt sitter.
Femårskalkylen
När regeln inte ger ett självklart svar behöver du räkna – men på rätt sätt. Felet folk gör är att jämföra ett synligt inköpspris med en osynlig utvecklingskostnad. Rätt jämförelse är den totala kostnaden över fem år.
| Väg | Kostnader att summera över 5 år |
|---|---|
| Köpa | Licenser, anpassningar, uppgraderingar, inlåsning |
| Bygga | Utveckling, förvaltning, drift – men full kontroll, ingen licens |
| Hybrid | Standardlicens för kärnan plus bygge av de unika delarna |
Ett köpt system har lågt inträde men löpande licenser och en anpassningsnota som växer varje gång en ny version bryter det ni skräddarsytt. Ett egenbygge har högt inträde men ingen licens och full kontroll. Vilket som blir billigast beror på hur väl ett standardsystem faktiskt passar – och det är just passformen kalkylen tvingar fram i ljuset.
De vanligaste felbesluten – åt båda håll
Det finns två klassiska sätt att gå fel, och de är varandras spegelbilder.
- Bygga det man kunnat köpa. Ett team bestämmer sig för att bygga sitt eget generiska system – ofta för att det känns roligare eller mer flexibelt. Två år senare har de en halvfärdig kopia av ett standardsystem, plus ett underhållsåtagande som aldrig tar slut. Konsekvens: pengar och tid brända på något utan konkurrensfördel.
- Köpa det som är verksamheten. Ett bolag pressar in sin särskiljande process i ett standardsystem för att spara pengar. Systemet böjer sig inte, så de böjer sig – och tappar just det som gjorde dem unika. Konsekvens: en billig lösning som urholkar själva affären.
Ett konkret exempel: ett logistikbolag vars styrka var en egen ruttoptimering köpte ett standardsystem som “nästan” klarade det. Nästan visade sig kosta dem det som skilde dem från konkurrenterna. Hade de i stället köpt ekonomidelen färdig och byggt ruttoptimeringen själva hade de fått både låg kostnad och behållit sitt försprång.
Vem bör äga beslutet?
En orsak till att det blir fel är att beslutet hamnar på fel bord. Lämnas det enbart till tekniken lockar egenbygget, för det är mer stimulerande att bygga än att konfigurera något färdigt. Lämnas det enbart till ekonomin lockar inköpspriset, för licensen ser billig ut mot en utvecklingsbudget. Ingen av vinklarna ser hela bilden på egen hand.
Rätt beslut kräver att både affär, teknik och ekonomi sitter vid samma bord och ställer den enda fråga som betyder något: gör det här oss annorlunda, eller gör det oss som alla andra? Det är en affärsfråga innan det är en teknisk. Håll den frågan i centrum, luta dig mot femårskalkylen och ha de två klassiska felbesluten i minnet, så landar de flesta val rätt.
Rätt beslut kräver alltså att någon vågar ställa den obekväma frågan om var ert verkliga värde ligger. Vill ni ha ett neutralt bollplank för just era system, resonerar vi på Weapp gärna kring helheten och kan gå igenom valen med er innan ni binder upp er.
Vanliga frågor
Vad är kärnregeln för build vs buy?
Bygg där ni differentierar er, köp där ni är som alla andra. Det som gör er unika och konkurrenskraftiga är värt att äga och forma själva. Det som ser likadant ut i alla bolag – ekonomi, lön, e-post – köper ni färdigt. Regeln löser de flesta fall utan att ni ens behöver räkna.
Hur gör jag en rättvis kostnadsjämförelse?
Räkna på fem år, inte på inköpspriset. För köp: licenser, anpassning och uppgraderingar. För bygge: utveckling plus löpande förvaltning. Ta även med kostnaden för inlåsning respektive full kontroll. Först då jämför du verklig totalkostnad i stället för en synlig prislapp mot en osynlig.
Vilket är det vanligaste felbeslutet?
Att bygga det man lika gärna kunnat köpa. Team underskattar hur mycket arbete det är att bygga och för evigt underhålla något generiskt som redan finns färdigt. Resultatet blir en dyr egen variant av ett standardsystem, utan någon egentlig fördel jämfört med att ha köpt det.
Och det vanligaste felet åt andra hållet?
Att köpa ett standardsystem för det som faktiskt är själva verksamheten. Då tvingas ni anpassa er unika process till systemets sätt att arbeta och tappar just det som skiljde er från konkurrenterna. Det ni sparade i inköp förlorar ni i konkurrenskraft.
Kan man kombinera bygga och köpa?
Ja, och det är ofta klokast. En standardkärna för det generiska kombinerad med egenbyggda tillägg via API för det unika ger både låg kostnad på det vanliga och full frihet på det som betyder något. De flesta mogna systemlandskap ser ut just så.