Harsh Joshi
Co-founder & Technical Director
Sammenlign udvikling, køb og outsourcing af virksomhedssoftware ved hjælp af en praktisk beslutningsmodel, der tager højde for omkostninger, kontrol, tidsplan og langsigtede risici.
En CTO, der står over for et defekt internt værktøj, har tre muligheder: at sætte udviklingsplanen på hold og lade det interne team udvikle en erstatning, at købe et kommercielt produkt og tilpasse forretningen til det, eller at hente et eksternt udviklerteam ind til at udvikle en løsning, der passer til behovene. Hver vej løser det samme problem på sin egen måde, og hver af dem medfører forskellige konsekvenser 18 måneder senere.
Selvudvikling, køb og outsourcing er de tre praktiske veje til virksomhedssoftware, og valget handler ikke egentlig om, hvilken løsning der er billigst i dag. Det handler om, hvilken løsning der passer bedst til, hvor specialiseret softwaren skal være, hvor hurtigt virksomheden har brug for den, og hvor meget løbende teknisk ansvar virksomheden rent faktisk ønsker at påtage sig. Denne guide gennemgår, hvad de enkelte veje indebærer, en praktisk metode til at vurdere dem i forhold til din specifikke situation samt spørgsmålene om de samlede ejerskabsomkostninger, som ofte overses, når der skal træffes en hurtig beslutning. For teams, der ender med at hælde mod outsourcing, dækker Monarch Innovations digitale udviklingsydelser skræddersyet software, cloud- og dataudviklingsarbejde netop i forbindelse med dette beslutningspunkt.
Køb software, når behovet er standardiseret; udvikl selv, når softwaren er strategisk vigtig, og dit team har kapaciteten til det; og udliciter, når du har brug for skræddersyet software, men mangler den interne kapacitet eller den specialiserede ekspertise til at levere den inden for den krævede tidsramme.
Selvudvikling vs. køb vs. outsourcing: Et hurtigt svar
| Valgmulighed | Bedst mulig pasform | Hovedfordel | Den vigtigste afvejning |
|---|---|---|---|
| Byg | Strategisk, differentieret software med intern ekspertise og kapacitet | Fuld kontrol og ejerskab | Større internt teknisk engagement |
| Køb | Standardiserede eller generiske forretningsfunktioner | Hurtigere implementering og leverandørstyret vedligeholdelse | Mindre fleksibilitet og risiko for leverandørbinding |
| Outsource | Behov for specialudviklet software, hvor den interne kapacitet er begrænset, eller hvor der mangler specialiserede kompetencer | Skræddersyet udvikling uden øjeblikkelig ansættelse | Afhængighed af partnerens kvalitet og videnoverførsel |
Hvad »Build, Buy og Outsource« egentlig betyder
At udvikle internt betyder, at jeres eget ingeniørteam designer, udvikler og vedligeholder softwaren ved hjælp af interne medarbejdere og infrastruktur. At købe betyder, at I anskaffer en licens til et kommercielt produkt eller et SaaS-produkt og tilpasser jeres processer, så de passer til produktets funktioner. Outsourcing betyder, at man ansætter et eksternt udviklerteam, enten til et afgrænset projekt eller som et fast dedikeret team, til at udvikle skræddersyet software, som jeres interne medarbejdere ikke har tid eller den nødvendige specialkompetence til at udvikle alene.
Dette er ikke den samme beslutning formuleret på tre forskellige måder. Egenudvikling giver fuld kontrol, men medfører permanente tekniske omkostninger. Køb af software sætter hurtigt gang i projektet, men binder virksomheden til en anden parts produktudviklingsplan. Outsourcing giver skræddersyet software uden at øge medarbejderantallet, men afhænger fuldstændigt af, at man vælger den rigtige partner. Monarch Innovation samarbejder med tekniske ledere i alle tre scenarier og træder oftest til, når et team har besluttet, at skræddersyet udvikling er den rigtige løsning, men ikke har den interne kapacitet til at gennemføre den.
Hvorfor denne beslutning fortjener mere end blot en sammenligning af omkostningerne
De fleste sammenligninger mellem »selvudvikling« og »køb« begrænser sig til at se på licensomkostninger kontra udviklerlønninger. Den sammenligning går forbi det egentlige spørgsmål, nemlig om softwaren udgør en konkurrencemæssig fordel eller blot en standardfunktion, som hundrede andre virksomheder også har brug for.
Et planlægningsværktøj, et udgiftssystem eller et standard-CRM er sjældent værd at udvikle fra bunden, fordi leverandørerne allerede har løst det problem i et omfang, som ingen enkelt virksomhed kan matche. En prisberegningsmotor, der er knyttet til en proprietær forretningsmodel, et produktionsstyringssystem bygget op omkring en specifik produktionsproces eller en intern platform, der direkte former kundernes oplevelse af produktet, er en helt anden sag. Når softwaren definerer, hvordan virksomheden rent faktisk fungerer eller konkurrerer, betyder køb af et generisk produkt, at man omformer virksomheden, så den passer til andres antagelser.
Denne skelnen – om systemet er et konkurrencefordel eller en standardvare – er det første filter, der bør indsnævre beslutningen, længe før omkostningerne overhovedet kommer på tale.
Mulighed 1: Internt udvikling
Når man udvikler internt, får virksomheden fuld kontrol over udviklingsplanen, arkitekturen og den måde, softwaren udvikler sig på i takt med virksomheden. Der er ingen leverandøraftale, der står i vejen mellem et nyt krav og en færdigudviklet funktion, og det team, der udvikler systemet, har også et tilstrækkeligt indgående kendskab til det til at kunne udvide det senere.
Afvejningen står mellem kapacitet og tid. Interne udviklingsprojekter konkurrerer om de samme ingeniørtimer som alle andre punkter på udviklingsplanen, og det tager måneder at ansætte specialiseret personale til et enkelt projekt – uanset om det drejer sig om en bestemt cloud-platform, et dataengineering-område eller et område med strenge compliance-krav – og det er tid, som et hurtigt fremadskridende initiativ ofte ikke har. Intern udvikling medfører også den fulde byrde ved langsigtet vedligeholdelse: sikkerhedsopdateringer, infrastrukturopgraderinger og de endelige omkostninger ved software, der overlever de ingeniører, der skrev den.
Det giver som regel mest mening at udvikle internt, når softwaren er en central del af selve produktet, når teamet allerede har den relevante ekspertise blandt medarbejderne, og når virksomheden er parat til at eje systemet i årevis og ikke blot levere det én gang.
Mulighed 2: Køb af en standardløsning eller en SaaS-løsning
Ved at købe får man hurtigst muligt et fungerende system på plads, ofte inden for dage eller uger i stedet for måneder. Det overfører vedligeholdelse, sikkerhedsopdateringer og infrastruktur til leverandøren, og der følger en supportafdeling med, som allerede har løst de fleste af de almindelige problemer, man ville støde på ved en nyopbygning.
Ulemperne viser sig først med tiden og ikke fra dag ét. Kommerciel software er udviklet til et bredt marked, så den passer sjældent præcist til en specifik arbejdsgang, og dette hul udfyldes med manuelle løsninger eller dyre tilpasninger. Licensomkostningerne stiger i takt med brugen på en måde, der i sidste ende kan overstige, hvad en skræddersyet løsning ville have kostet. Leverandørafhængighed bliver en realitet i det øjeblik, en virksomheds data, integrationer og interne processer er bygget op omkring et produkt, som den ikke selv kontrollerer, og det kan senere blive et større projekt at skifte leverandør end den oprindelige implementering.
Det giver som regel mest mening at købe ind, når der er tale om veldefinerede, standardiserede funktioner, hvor der findes et modent leverandørmarked, og hvor virksomhedens differentiering ligger et helt andet sted.
Mulighed 3: Outsourcing af specialudvikling
Outsourcing ligger midt imellem de to andre løsninger. Den leverer skræddersyet software, der er udviklet specifikt til virksomheden, uden at virksomheden behøver at ansætte, uddanne og fastholde et fuldt internt team til formålet. En ekstern udviklingspartner bidrager med eksisterende ekspertise inden for den relevante teknologiplatform, overtager omkostningerne ved rekruttering og ledelse og kan typisk komme i gang hurtigere, end en intern rekrutteringsproces ville tillade.
Outsourcing er ikke en ensartet ordning. Et projektbaseret samarbejde passer til et leveringsomfang med klart afgrænsede rammer og en defineret start og slutning, såsom udskiftning af et ældre system eller opbygning af en specifik integration. Et dedikeret ingeniørteam, der ansættes på løbende basis, fungerer nærmere som en forlængelse af det interne team og passer til en virksomhed med en kontinuerlig strøm af skræddersyet udviklingsarbejde. Personaleudvidelse tilføjer enkelte ingeniører til et eksisterende internt team og fungerer bedst, når virksomheden allerede har en stærk teknisk ledelse og blot har brug for flere medarbejdere med en specifik kompetence. Monarch Innovations tidligere guide til valg mellem disse samarbejdsmodeller går mere i dybden med, hvordan man tilpasser modellen til arbejdsbyrden.
Ulempen ved outsourcing er, at resultaterne i høj grad afhænger af valg af partner. En svag partner kan medføre samme risiko for at blive låst fast som et dårligt SaaS-køb – dog med mindre dokumentation og en kodebase, som kun partneren selv forstår. En stærk partner kan derimod levere noget, der ligger tæt op ad den kontrol, man har ved en intern udvikling, men med langt mindre besvær i forbindelse med ansættelser. Vejledningen »Product Engineering Outsourcing Cost« dækker en lignende gennemgang af omkostningsrammerne for hardware- og produktudviklingsarbejde, og mange af de samme spørgsmål vedrørende prismodeller (tid og materialer, fast pris, dedikeret team) gælder også for softwareprojekter.
Beslutningsramme for »Selvudvikling, Indkøb eller Outsourcing«
Når spørgsmålet om, hvad der er en standardvare, og hvad der er et differentieringselement, er besvaret, er det disse faktorer, der i høj grad afgør, hvilken vej man skal vælge.
| Faktor | Gavekurv | Køb gaver | Outsourcing af gaver |
|---|---|---|---|
| Strategisk differentiering | Høj, afgørende for konkurrencefordelen | Lav, standardfunktion | Høj, men den interne kapacitet er begrænset |
| Tid til opsendelse | Fleksibel, måneder accepteres | Behov i dage eller uger | Skal være på plads inden for få uger – hurtigere, end det er muligt at ansætte folk |
| Intern ekspertise | Findes allerede blandt personalet | Ikke påkrævet | Tilgængelig eksternt, ikke internt |
| Interesse for langsigtet ejerskab | Højt – holdet vil beholde det i årevis | Lav, leverandøren står for vedligeholdelsen | Middel, afhænger af den valgte engagementsmodel |
| Kompleksitet ved integration | Stor kontrol over API’er og interne systemer | Fungerer bedst, når integrationerne er standardiserede | Nyttigt, når der er behov for tilpassede integrationer eller datamigrering |
| Forventet levetid | Strategisk platform på lang sigt | Kortsigtet eller udskiftelig funktion | Langvarigt skræddersyet system med ekstern leveringssupport |
Ingen enkelt faktor afgør udfaldet på egen hånd. Et system, der er meget specialiseret, men som f.eks. skal være klar om tre uger, taler som regel for outsourcing frem for en egenudvikling, der ikke kan gennemføres hurtigt nok, eller et kommercielt produkt, der ikke kan tilpasses i tilstrækkelig grad.
Et simpelt beslutningstræ: Selvudvikling, køb eller outsourcing
- Er softwaren en standardiseret funktion eller en almindelig funktion?
- Ja: Begynd med at vurdere etablerede kommercielle produkter eller SaaS-produkter.
- Nej: Er softwaren strategisk vigtig for virksomheden?
- Ja: Har I den interne ekspertise og tekniske kapacitet til at udvikle og vedligeholde det?
- Ja: At udvikle internt kan passe ind i udviklingsplanen.
- Nej: Det kan være en bedre løsning at outsource den skræddersyede udvikling.
- Nej: Vurder på ny, om køb af et eksisterende produkt kan opfylde forretningsbehovet uden omfattende tilpasning.
Samlede ejeromkostninger: Et blik ud over det første år
Den mest almindelige fejl i denne beslutning er at sammenligne et internt lønoverslag, et licens tilbud fra en leverandør og en outsourcing-partners timepris, som om det var tal af samme art. Det er de ikke, og en retfærdig sammenligning skal se tre til fem år frem i tiden og ikke blot tage udgangspunkt i den første faktura.
En internt udviklet løsning medfører løbende omkostninger til løn og personalegoder, uanset om der hvert kvartal er aktive opgaver for det pågældende team i henhold til udviklingsplanen, samt omkostninger til infrastruktur, sikkerhed og en eventuel omskrivning, som følger med ethvert system, der er gammelt nok til at blive betragtet som forældet. En købt løsning medfører tilbagevendende licensafgifter, der typisk stiger i takt med brugen eller antallet af brugere, samt omkostningerne til interne løsninger på alt det, som produktet ikke kan udføre som standard, og en reel, ofte undervurderet omkostning ved senere at migrere væk fra det. En outsourcet løsning medfører selve omkostningerne til samarbejdet samt de interne ressourcer, der er nødvendige for at administrere samarbejdet og på sigt vedligeholde eller udvide det leverede system. Derfor skal der fra første dag være klarhed omkring dokumentation og overdragelse i kontrakten.
Ingen af disse løsninger er i sig selv billigere. Den rigtige sammenligning handler om, hvad systemet skal kunne i det tredje år, ikke blot hvad det koster at få det op at køre i den første måned.
Når hver vej giver mening
Et par realistiske scenarier gør det lettere at anvende mønsteret end blot at benytte rammen i sig selv:
- Et standard-CRM-system eller et udgiftsstyringsværktøj. Køb det. Markedet er modent, funktionen er ikke noget, der adskiller leverandørerne fra hinanden, og at udvikle det internt ville betyde, at man skulle løse et problem på ny, som leverandørerne allerede har løst godt.
- Et prisberegnings- eller tilbudssystem, der er knyttet til en proprietær forretningsmodel. Det skal enten udvikles internt eller outsources, afhængigt af den interne kapacitet. Det er netop den type system, der skaber konkurrencemæssige fordele, så et standardprodukt vil ikke kunne anvendes uden store indskrænkninger.
- Et forældet produktionsstyringssystem, der skal udskiftes inden for en stram tidsfrist. Udliciter opgaven. Systemet er så specifikt, at det kræver specialudvikling, men det er sjældent realistisk at rekruttere og oplære et internt team hurtigt nok til at overholde tidsfristen.
- En intern platform, som dit produktteam vil stå for og videreudvikle i det kommende årti. Vent med at udvikle den, indtil teamet har opbygget den nødvendige ekspertise, da det langsigtede ansvar og den dybe interne forståelse her er vigtigere end hastigheden ved lanceringen.
Almindelige fejl i beslutningen om, hvorvidt man skal udvikle selv, købe eller outsource
Der er en række mønstre, der går igen, når denne beslutning går galt. Det mest almindelige er at betragte det som et engangsvalg: Virksomhedens behov ændrer sig, og et system, der blev købt som en standardløsning for to år siden, kan blive en strategisk flaskehals, når virksomheden begynder at differentiere sig på baggrund af det. At sammenligne udelukkende omkostningerne det første år er et andet mønster, da licensafgifter, lønninger og outsourcingpriser alle udvikler sig forskelligt over en horisont på tre til fem år. At undervurdere integrations- og migrationsindsatsen forårsager også reel skade, især med købt software, der skal integreres med fem andre interne systemer fra dag ét. At vælge en outsourcingpartner udelukkende på grundlag af prisen, uden at tjekke dokumentationspraksis, kommunikationsfrekvensen eller hvad der sker med kodebasen, når samarbejdet ophører, har en tendens til at skabe netop det »lock-in«-problem, som outsourcing ellers skulle undgå. Endelig er det en almindelig årsag til, at interne projekter stille og roligt går i stå i et år, når man springer en reel vurdering af den interne kapacitet over og antager, at et overbelastet team kan absorbere et udviklingsprojekt oven på sin eksisterende plan.
Vurdering af en outsourcingpartner, inden du indgår en aftale
Hvis outsourcing er den rette vej at gå, er valget af partner lige så vigtigt som selve beslutningen. Der er et par spørgsmål, det er værd at stille, lige før man underskriver noget: Hvilke konkrete ingeniører skal arbejde på projektet, og forbliver de tilknyttet projektet gennem hele forløbet? Hvilken dokumentation, kildekode og arkitekturbeslutninger overdrages ved projektets afslutning, og i hvilket format? Hvordan håndterer partneren ændringer i kravene midt i projektet, og hvilken indvirkning har det på omkostninger og tidsplan? Hvad sker der med den institutionelle viden, hvis samarbejdet afsluttes, eller hvis nøglemedarbejdere udskiftes? En partner, der besvarer disse spørgsmål konkret i stedet for med generelle forsikringer, er som regel det sikrere valg, og den samme vurderingslogik gælder, uanset om samarbejdet er projektbaseret, omfatter et dedikeret team eller personaleudvidelse.
Vælg en vej, der passer til din plan
»Bygge«, »købe« og »outsource« er ikke konkurrerende tilgange. Det er tre værktøjer, der passer til forskellige situationer, og det rigtige valg for det ene system på din plan kan være det forkerte valg for det næste. De spørgsmål, det er værd at stille, inden man forpligter sig, er, hvor differentieret systemet egentlig er, hvor meget intern kapacitet der er til at drifte det, og hvordan de samlede omkostninger ser ud om tre år frem i tiden snarere end på den første faktura.
Monarch Innovation samarbejder med førende ingeniører inden for specialudviklet software, cloud og dataengineering og træder ofte til netop på dette afgørende tidspunkt, når et system skal skræddersys, men det interne team ikke har kapacitet til at påtage sig endnu et langvarigt projekt. Hvis du overvejer, om du skal udvikle, købe eller hyre et eksternt ingeniørteam til et kommende system, så kontakt Monarch Innovation for at drøfte de specifikke afvejninger i forbindelse med din plan.
Diskuter din strategi for softwareudvikling
Overvejer du, om du skal udvikle løsningen internt, købe et kommercielt produkt eller hyre et eksternt ingeniørteam? Kontakt Monarch Innovation for at drøfte dit systems krav, tidsplan og langsigtede behov med vores ingeniørteam.
Ofte stillede spørgsmål om »Build«, »Buy« og »Outsource«
Hvad er forskellen mellem at udvikle, købe og outsource softwareudvikling?
»Build« betyder, at jeres interne team selv designer, udvikler og vedligeholder softwaren. »Buy« betyder, at I erhverver en licens til et kommercielt produkt eller et SaaS-produkt og tilpasser jeres forretningsprocesser efter det. »Outsource« betyder, at en ekstern teknisk partner udvikler skræddersyet software til jeres organisation, typisk gennem et projektforløb, et dedikeret team eller personaleudvidelse.
Er det bedre at udvikle skræddersyet software eller købe SaaS?
Det afhænger af, om behovet er standardiseret eller strategisk differentieret, hvor meget tilpasning og integration der kræves, hvor hurtigt systemet skal være klar, og om jeres interne team har kapaciteten og ekspertisen til at varetage ansvaret for softwaren gennem hele dens levetid – ikke kun ved lanceringen.
Hvordan vælger jeg mellem at udvikle, købe eller outsource virksomhedssoftware?
Start med at spørge, om systemet udgør en konkurrencemæssig forskel eller blot en standardfunktion. Standardbehov taler normalt for at købe løsningen. Systemer, der udgør en konkurrencemæssig forskel, taler for at udvikle dem selv eller outsource dem, og valget mellem disse to muligheder afhænger ofte af, om jeres interne team har kapaciteten og den nødvendige specialviden til at udvikle det i tide.
Er det billigere at outsource softwareudviklingen end at udvikle den internt?
Det er ikke altid tilfældet, og det er vildledende udelukkende at sammenligne timepriser med månedslønninger. Ved outsourcing undgår man de faste omkostninger ved ansættelse af nye fuldtidsmedarbejdere og den månederlange ansættelsesproces, men de samlede omkostninger afhænger stadig af projektets omfang, antallet af iterationer og hvordan samarbejdet styres over tid.
Hvad er den største risiko ved at købe kommerciel software i stedet for at udvikle den selv?
Leverandørafhængighed udgør den største risiko. Når interne processer, data og integrationer først er bygget op omkring et indkøbt produkt, kan det at skifte til en anden leverandør eller senere udvikle en erstatningsløsning blive et større og dyrere projekt, end den oprindelige implementering nogensinde var.
Hvornår er outsourcing en bedre løsning end at udvikle løsningen internt?
Outsourcing er ofte den bedste løsning, når softwaren skal skræddersys, men det interne team mangler den nødvendige specialviden eller den nødvendige kapacitet til at levere den inden for den krævede tidsramme, da en partner typisk kan komme i gang hurtigere, end det er muligt gennem en fuld ansættelsesproces.
Hvad bør jeg spørge om, før jeg vælger en outsourcingpartner inden for software?
Spørg, hvilke konkrete ingeniører der skal arbejde på projektet, hvilken dokumentation og kildekode du modtager ved projektets afslutning, hvordan ændringer i kravene håndteres undervejs i projektet, og hvad der sker med den opbyggede viden, hvis samarbejdet ophører. Konkrete svar er et stærkere signal end generelle forsikringer.
Er de samlede ejeromkostninger vigtigere end den oprindelige pris?
Ja, i de fleste tilfælde. Selvudvikling, køb og outsourcing medfører alle forskellige omkostningsmønstre over en periode på tre til fem år, herunder vedligeholdelse, stigende licensomkostninger og migrationsomkostninger, og hvis man kun sammenligner den første faktura, ender man ofte med en beslutning, der viser sig at være forkert inden for et år eller to.
Kan en beslutning om, hvorvidt man skal udvikle selv, købe eller outsource, ændre sig med tiden?
Det kan ske, og det sker ofte. Et system, der er købt som en standardløsning, kan blive en strategisk flaskehals, når virksomheden begynder at differentiere sig på baggrund af det. Derfor er det en god idé at genoverveje denne beslutning med jævne mellemrum i takt med, at virksomheden udvikler sig, i stedet for at betragte den som endelig.
