Der findes en bestemt type møde, som næsten enhver større IT-organisation har haft. Nogen har identificeret et behov, der findes et produkt på markedet, som tilsyneladende kan løse det, og samtidig sidder der et udviklingsteam og siger, at de sikkert kan bygge noget bedre selv. Så begynder diskussionen om licenspriser, udviklertimer, implementeringstid, integrationer og teknologi.
Alt sammen relevante spørgsmål. Men hvis det er dér, diskussionen starter og slutter, synes jeg, man stiller det forkerte spørgsmål.
For build or buy er sjældent først og fremmest en teknisk beslutning. Det er en strategisk beslutning om, hvilke kompetencer, afhængigheder og muligheder virksomheden ønsker at eje. Det afgørende spørgsmål er derfor ikke kun, om vi kan bygge løsningen. Dygtige udviklere kan bygge næsten hvad som helst, hvis man giver dem tid og penge nok.
Det mere interessante spørgsmål er, om det her overhovedet bør være noget, virksomheden selv ejer evnen til at bygge, videreudvikle og drive.
Det er en væsentligt sværere diskussion.
At kunne bygge noget er ikke et argument for at gøre det
Teknologiorganisationer kan have en helt naturlig fascination af at bygge. Det er forståeligt. At skabe noget fra bunden er fagligt tilfredsstillende, og specialister vil som regel hellere udvikle en elegant løsning end konfigurere et standardsystem, som nogen andre har designet.
Men virksomhedens mål er ikke at holde udviklerne teknisk underholdt.
Hvis virksomheden driver et forsikringsselskab, en produktionsvirksomhed eller en detailkæde, er det ikke sikkert, at dens konkurrencefordel ligger i at have udviklet sit eget expense management-system. Hvis 5.000 andre virksomheder har stort set det samme problem, og markedet allerede har brugt milliarder på at løse det, skal der være en virkelig god grund til, at netop vores organisation mener, at den bør starte fra nul.
Og “vi har nogle særlige behov” er ikke altid den gode grund, organisationer tror. Næsten alle virksomheder mener, at deres processer er specielle. I mange tilfælde er de bare gamle, komplicerede eller formet af tidligere systembegrænsninger.
Det er ikke nødvendigvis et argument for at bygge dem ind i næste generation af teknologi.
Hvis standardproduktet ikke passer, er processen måske problemet
En af de mest kostbare varianter af buy-strategien opstår, når virksomheden køber et standardsystem og derefter bruger enorme mængder tid og penge på at få det til at opføre sig præcis som det gamle system.
Det ser man især omkring store forretningssystemer. Organisationen vælger en moderne standardplatform, men hver afdeling møder implementeringen med en liste over de processer, som absolut ikke må ændres. Derefter begynder specialfelterne, specialworkflows, plugins, integrationer, scripts og undtagelserne.
Efter nogle år har virksomheden teknisk set købt et standardprodukt, men resultatet er blevet så specialbygget, at opgraderinger kræver projekter, leverandørskift er næsten umuligt, og ingen længere helt ved, hvor standardproduktet slutter og virksomhedens egne særheder begynder.
Det er egentlig en imponerende bedrift: Man har betalt for fordelene ved standardisering og derefter aktivt fjernet dem.
Hvis man køber et standardsystem og bruger tre år på at få det til at ligne det gamle system, har man ikke moderniseret ret meget. Man har bare bygget en dyrere kopi af fortiden. Nogle gange bør spørgsmålet derfor ikke være, om produktet kan tilpasses vores proces, men hvorfor processen er så hellig, at hele den nye platform skal formes omkring den.
Byg dét, der gør virksomheden speciel
Jeg synes, en mere interessant build-or-buy-model starter med virksomhedens strategi: Hvilke teknologiske evner gør os faktisk bedre end konkurrenterne?
Hvis en bestemt algoritme, kundeoplevelse, platform, datamodel eller automatisering er afgørende for virksomhedens konkurrenceevne, kan der være stærke argumenter for at eje den selv. Ikke nødvendigvis fordi man kan bygge den billigere, men fordi man ønsker at kontrollere tempoet, kompetencerne og udviklingsretningen.
Det er en helt anden begrundelse end “vores udviklere kan godt”.
Hvis teknologi er en central del af det, virksomheden konkurrerer på, kan det være direkte farligt at outsource hele evnen til en leverandør. Man risikerer, at det, man betragtede som en konkurrencefordel, bliver reduceret til endnu en funktion i et standardprodukt, som alle konkurrenterne også kan købe.
Derfor synes jeg, spørgsmålet “Hvor vil vi være forskellige?” bør fylde langt mere i diskussionen. På de områder giver det mening at overveje at bygge. På resten bør vi være langt mindre romantiske.
Hvis noget ikke differentierer virksomheden, kan standardisering og køb af modne produkter ofte være en styrke. Det frigør mennesker, kapital og opmærksomhed til de områder, hvor virksomhedens egne idéer faktisk betyder noget.
En organisation kan ikke være unik på alt. Forsøger den, bliver resultatet ofte bare unik kompleksitet.
“Buy” betyder ikke, at ansvaret forsvinder
Der findes også en farlig forestilling om, at man kan købe sig fri af teknologisk ansvar. Hvis vi vælger en SaaS-platform, tager leverandøren sig jo af det.
Det gør leverandøren måske på infrastrukturniveau. Men virksomheden ejer stadig konsekvensen af beslutningen.
Data skal integreres, identity skal fungere, sikkerheden skal vurderes, compliance skal håndteres, brugerne skal forstå systemet, og processerne omkring løsningen skal fungere. Nogen skal desuden have styr på, hvad der sker, når leverandøren ændrer pris, funktionalitet eller strategi.
Man kan outsource driften. Man kan ikke outsource ansvaret.
Det bliver især vigtigt, når SaaS-løsninger bliver strategisk centrale. Når en stor del af virksomhedens forretningsproces afhænger af én platform, er relationen ikke længere blot et abonnement. Den er blevet en del af virksomhedens arkitektur — og i nogle tilfælde en del af selve strategien.
Når man køber software, køber man også en roadmap
Det bliver ofte overset i business casen. Når virksomheden køber et produkt, køber den ikke kun den funktionalitet, der findes i dag. Den accepterer samtidig, at en anden organisation får betydelig indflydelse på produktets fremtid.
Leverandøren bestemmer, hvilke funktioner der udvikles og udfases, hvornår priserne ændres, hvilke integrationer der prioriteres, og i sidste ende om produktet overhovedet fortsætter.
Det kan sagtens være den rigtige handel. En stærk leverandør kan udvikle hurtigere, investere mere og samle erfaring fra tusindvis af kunder, som én virksomhed aldrig selv kunne matche. Men afhængigheden skal være bevidst.
Det er svært at kalde noget strategisk kontrol, hvis hele virksomhedens plan afhænger af, at leverandørens roadmap tilfældigvis bevæger sig i samme retning som virksomhedens egen strategi.
Lock-in er ikke djævelen
Vendor lock-in bliver nogle gange diskuteret, som om enhver afhængighed automatisk er dårlig arkitektur. Det synes jeg er for simpelt.
Alle teknologiske beslutninger skaber afhængigheder. Hvis organisationen konsekvent vælger den mindst effektive løsning for at undgå enhver form for lock-in, kan prisen på “frihed” blive meget høj. Nogle gange giver det fremragende mening at udnytte en leverandørs proprietære services, hvis de skaber tilstrækkelig værdi.
Det afgørende er ikke, om der findes lock-in, men om vi forstår den handel, vi indgår. Hvad får vi ud af afhængigheden? Hvad giver vi afkald på? Og hvor dyrt bliver det, hvis vi senere ønsker at vælge anderledes?
Bevidst lock-in kan være en rationel strategi.
Ubevidst lock-in er bare dårlig beslutningshygiejne.
Build betyder ikke et projekt. Det betyder et ansvar.
Den samme fejl opstår på build-siden. Organisationen estimerer måske, at en intern løsning kan udvikles på ni måneder, og projektplanen ser glimrende ud. Men det interessante spørgsmål begynder i virkeligheden i måned ti.
Software bliver ikke færdigt på samme måde som en bygning. Det får brugere, bugs, sikkerhedsproblemer, nye krav og afhængigheder, der skal opgraderes. Regulering ændrer sig, nye medarbejdere skal forstå koden, infrastrukturen skal drives, og tekniske valg bliver med tiden til teknisk gæld.
Hvis virksomheden vælger at bygge en løsning, vælger den derfor samtidig at eje et produkt — ikke bare at gennemføre et projekt.
Det betyder, at organisationen bør kunne svare på, hvem der udvikler løsningen om tre år, hvem der finansierer videreudviklingen, og hvad der sker, når de oprindelige udviklere har fået andre roller eller har forladt virksomheden.
Jeg har set interne systemer, der startede som “en hurtig løsning”, og som ti år senere var forretningskritiske applikationer, ingen længere turde ændre. Det var ikke nødvendigvis dårligt software. Problemet var snarere, at et midlertidigt projekt var blevet til et permanent produkt uden nogensinde at få den organisation omkring sig, som et permanent produkt kræver.
Den interne løsning er ikke gratis
Her støder build-diskussionen ofte ind i en anden klassiker: “Vi kan jo bygge det selv. Vi har allerede udviklerne.”
Det argument holder ikke.
Udviklerne er ikke gratis, bare fordi lønnen allerede står i budgettet. Hvis et team bruger seks måneder på at bygge en intern løsning, har virksomheden samtidig besluttet ikke at bruge de seks måneder på noget andet. Det er opportunity cost, og den kan være langt større end selve udviklingsomkostningen.
Hvis de samme specialister kunne have brugt tiden på noget, der faktisk differentierer virksomheden, kan den “gratis” interne løsning være ekstremt dyr. Det er derfor, jeg bliver skeptisk, når business cases sammenligner en konkret leverandørpris med noget, der ligner nul kroner på build-siden.
Interne timer er stadig penge, men endnu vigtigere er de kapacitet. Dygtige teknologifolk er en begrænset ressource, og hvis virksomheden bruger dem på problemer, markedet allerede har løst tilfredsstillende, skal man være temmelig sikker på, at det virkelig er den bedste anvendelse af deres tid.
Men køb heller ikke et produkt bare for at slippe for at tænke
Der findes selvfølgelig en lige så dårlig version af buy-beslutningen. Organisationen står med et komplekst problem, men i stedet for at forstå problemet køber den et system. Produktet bliver næsten en måde at outsource selve tænkningen på.
“Leverandøren siger, at platformen kan det.”
Det er ikke en strategi.
Leverandører er dygtige til at demonstrere den virkelighed, hvor deres produkt er den oplagte løsning. Det er trods alt det, salgsorganisationer bliver betalt for. Organisationens opgave er derimod at forstå sin egen virkelighed.
Hvis man ikke har forstået processerne, dataene, integrationsbehovene og de organisatoriske problemer først, risikerer man bare at digitalisere uklarheden. Software reparerer ikke nødvendigvis dårlige processer. Nogle gange gør det dem bare hurtigere.
Den farligste løsning er ofte den halvvejs
Der findes også et særligt teknologisk ingenmandsland, hvor organisationen både køber og bygger. Man køber en stor platform, men fordi den ikke helt passer, bygger man et omfattende lag af custom software ovenpå.
Det kan være legitimt, men det ender alt for ofte med at kombinere det værste fra begge verdener. Man betaler licensen og ejer samtidig store mængder kode. Man er afhængig af leverandørens roadmap og sine egne udviklere. Opgraderinger af standardplatformen risikerer at ødelægge customizations, mens customizations gør det stadig vanskeligere at skifte platform.
Så har man både vendor lock-in og intern teknisk gæld.
Det betyder ikke automatisk, at arkitekturen er forkert, men det kræver, at man er meget ærlig om, hvad man faktisk har bygget. “Vi køber et standardprodukt” kan være en temmelig kreativ beskrivelse, hvis halvdelen af den reelle funktionalitet efterfølgende skal specialbygges.
Build or buy handler også om kompetencer
Build or buy handler efter min mening også om noget, der ofte bliver undervurderet: Hvilke kompetencer ønsker virksomheden faktisk at have internt?
Hvis teknologi er central for virksomhedens fremtid, kan det være farligt gradvist at outsource hele evnen til at forstå den. Man kan ende i en organisation, hvor alle kritiske systemer drives af eksterne leverandører, alle større ændringer kræver konsulenter, og ingen internt længere har tilstrækkelig teknisk dybde til at udfordre de forslag, organisationen modtager.
Så har virksomheden måske reduceret sin IT-organisation, men den har samtidig reduceret sin teknologiske handlekraft.
Omvendt giver det naturligvis heller ikke mening at insource alle kompetencer “for en sikkerheds skyld”. Nogle teknologier bruges så sjældent, at det ville være absurd at opbygge dyb intern ekspertise.
Derfor er kompetenceperspektivet strategisk: Hvilken viden ønsker vi at være afhængige af, og hvilken viden mener vi, virksomheden selv skal eje? Den diskussion burde efter min mening fylde mindst lige så meget som licensprisen.
Der findes ikke ét rigtigt svar
Jeg tror ikke på en generel regel om, at build er bedre end buy eller omvendt. Men jeg tror på, at der findes temmelig dårlige begrundelser for begge dele.
“Vi kan bygge det” er ikke nok. “Det er billigere at købe” er heller ikke nok. “Alle andre bruger det” er bestemt ikke nok, og “vores behov er helt unikke” bør mødes med en skarp professionel skepsis.
Den gode beslutning kræver, at man ser på virksomhedens strategi, kompetencer, økonomi, arkitektur, risiko og ønskede handlefrihed samlet. Nogle områder bør virksomheden eje dybt. Andre bør den med glæde købe som standardprodukter og aldrig bruge et minut mere på end nødvendigt.
Kunsten ligger i at kende forskellen.
Køb standarden. Byg forskellen.
Hvis jeg skulle reducere hele diskussionen til ét princip, ville det være:
Køb standarden. Byg forskellen.
Det er naturligvis for simpelt til at fungere som universel regel, men som strategisk udgangspunkt synes jeg, det er sundt. Brug markedet til de problemer, hvor virksomheden ikke behøver være unik. Lad leverandører konkurrere om at levere løn, expense management, standard collaboration, commodity infrastructure og de hundrede andre ting, som virksomheden bare har brug for fungerer ordentligt.
Brug så virksomhedens egen teknologiske energi dér, hvor teknologi faktisk kan gøre den bedre end konkurrenterne.
Det kræver disciplin, for det er ofte langt mere spændende at bygge noget nyt end at erkende, at Salesforce, Microsoft, SAP eller en anden leverandør sandsynligvis allerede har løst et problem tilstrækkeligt godt. Men teknologisk modenhed handler ikke om at bygge mest muligt selv. Den handler om at vide, hvad der er værd at eje.
Build or buy er derfor ikke først og fremmest spørgsmålet om, hvilken løsning IT-afdelingen foretrækker. Det er spørgsmålet om, hvilke teknologiske evner virksomheden ønsker skal være en del af dens egen identitet og konkurrencekraft.
Og det er alt for vigtigt et spørgsmål til kun at blive afgjort ud fra en licenspris og et estimat i story points.