Vägskälet för verksamhetens mest kritiska system
Valet mellan SaaS och egenutvecklat har länge beskrivits som en teknisk fråga. I praktiken är det ett strategiskt beslut om hur verksamheten ska skapa värde, hantera risk och använda sina begränsade resurser. När affärskrav, regelverk, kundförväntningar och datamängder förändras snabbt blir det dessutom allt svårare att fatta beslut utifrån enbart inköpspris eller utvecklingstid.
Två förenklade principer leder ofta fel. Den ena säger att allt ska köpas som SaaS. Den andra säger att affärskritiska system måste byggas internt för att ge kontroll. Båda kan vara rätt i vissa situationer, men ingen av dem fungerar som generell strategi. Ett standardsystem kan skapa beroende och begränsa en unik process, medan ett egenutvecklat system kan binda kapital och utvecklingskapacitet till funktioner som konkurrenterna redan köper färdiga.
Det hållbara angreppssättet är därför pragmatiskt. Utgå från var verksamheten verkligen differentierar sig, köp standardiserade stödfunktioner och reservera egen kod för den logik som ger en tydlig och försvarbar konkurrensfördel. Därefter behöver beslutet prövas mot femårig totalkostnad, integrationsbehov, kompetensförsörjning, informationssäkerhet och framtida handlingsfrihet.

Kärnan i beslutet handlar om differentiering och affärslogik
Den mest användbara grundprincipen är enkel: bygg det som gör verksamheten unik och köp det som i huvudsak är standardiserat. Ekonomi, lönehantering, grundläggande ärendehantering och många administrativa arbetsflöden har ofta liknande krav mellan bolag i samma bransch. Där kan SaaS ge snabbare införande, löpande uppdateringar och tillgång till specialistkompetens utan att hela ansvaret hamnar på den egna IT-organisationen.
Den egna utvecklingskapaciteten bör i stället riktas mot processer där en unik metod, datamängd eller optimeringsmodell direkt påverkar intäkter, kundvärde eller kostnadsposition. Ett logistikbolag kan exempelvis köpa ett generellt ekonomisystem men välja att utveckla sin egen ruttoptimering, om den ger bättre leveransprecision eller lägre transportkostnader än konkurrenternas lösningar. På samma sätt kan ett industriföretag köpa ett standardsystem för inköp men behålla egenutvecklad analys som förbättrar produktionsplaneringen.
Innan arkitekturen fastställs behöver varje central process bedömas sakligt. Frågan är inte om processen upplevs som viktig internt, utan om den faktiskt skapar en fördel som kunder märker eller konkurrenter har svårt att kopiera. Följande checklista hjälper ledningsgruppen att skilja strategisk kärna från administrativ hygien:
- Är processen unik, eller följer den etablerad branschpraxis?
- Påverkar processen intäkter, marginal, kundlojalitet eller leveransförmåga?
- Är verksamhetens data eller beslutslogik svår för konkurrenter att återskapa?
- Kan ett standardsystem konfigureras utan att de viktigaste fördelarna försvinner?
- Finns kompetens, finansiering och ägarskap för att förvalta egen kod under minst fem år?
- Vilka konsekvenser får ett byte av leverantör eller en större systemuppgradering?
Det är också viktigt att skilja mellan anpassning och innovation. Ett företag kan ha komplexa interna rutiner som vuxit fram genom historiska undantag, utan att dessa rutiner skapar konkurrensfördel. Att bygga ett särskilt system för att bevara sådana arbetssätt kan innebära att tekniken låser fast ineffektivitet. Vid analys av molntjänster är det samtidigt klokt att utgå från etablerade definitioner av leveransmodeller, exempelvis NIST:s beskrivning av molntjänster, så att SaaS, plattformstjänster och egen drift inte blandas ihop i beslutsunderlaget.
Verklig totalkostnad över fem år avslöjar dolda fallgropar
Den initiala utvecklingskostnaden är bara början på kalkylen för ett egenutvecklat system. Därefter följer livscykelkostnader för produktägare, utvecklare, testning, incidenthantering, infrastruktur, säkerhet, dokumentation, kompetensöverföring och anpassning till nya regelverk. En lösning som kostar 500 000 kronor att bygga kan därför bli betydligt dyrare än väntat när den ska drivas och vidareutvecklas under flera år.
Även SaaS kräver en noggrann kalkyl. Licenser kan öka när fler användare, datamängder eller moduler tillkommer. Konsultkostnader för införande, migrering, utbildning och integration kan bli betydande. Det kan också uppstå kostnader för premiumsupport, särskilda säkerhetskrav och export av data. Skillnaden är att kostnaderna oftare är synliga som återkommande abonnemang, medan egenutvecklingens förvaltning ibland fördelas över flera interna budgetar och därför blir svårare att se.
En rättvis jämförelse bör göras enligt en tydlig modell för Total Cost of Ownership över tid. Följande översikt visar vilka kostnadsdrivare som bör ingå i en femårig jämförelse:
| Kostnadsdrivare | SaaS | Egenutvecklat |
|---|---|---|
| Startkostnad | Införande, konfiguration, migrering och utbildning | Förstudie, arkitektur, utveckling och testning |
| Löpande drift | Abonnemang och eventuella tilläggstjänster | Moln eller datacenter, övervakning, backup och incidenthantering |
| Förvaltning | Leverantörens produktutveckling, men även intern administration | Utvecklare, testare, produktägare och dokumentation |
| Förändringar | Konfiguration, nya moduler och leverantörens uppdateringar | Nyutveckling, teknisk skuld och anpassning till externa förändringar |
| Personalrisk | Beroende av leverantörens kompetens och supportmodell | Beroende av nyckelpersoner, rekrytering och kompetensförlust |
| Exit och kontroll | Dataportabilitet, avtalsvillkor och leverantörsbyte | Större kontroll, men fullt ansvar för hela livscykeln |
Research om egenutvecklade system pekar ofta på att underhåll och personal blir de största posterna över tid. Uppgifter om att organisationer underskattar en stor del av den totala ägandekostnaden ska hanteras med försiktighet när de kommer från kommersiella aktörer, men principen är relevant: den ekonomiska analysen måste inkludera hela systemets livslängd. Även kostnaden för förlorad förändringstakt bör räknas in. Om interna team lägger större delen av sin kapacitet på att hålla ett gammalt system vid liv, minskar utrymmet för nya kundinitiativ och effektiviseringar.
Integrationsfriktion och ekosystemens avgörande roll
Inget affärskritiskt system är en isolerad ö. ERP, CRM, HR, analysplattformar, identitetstjänster, e-handel, produktionssystem och externa partnerlösningar måste utbyta information. Integrationskostnader underskattas systematiskt eftersom projektet ofta fokuserar på den första kopplingen, inte på de år av förändringar som följer när angränsande system byter version, datamodell eller API.
Moderna SaaS-plattformar kan erbjuda öppna API:er, webhooks, färdiga kopplingar och marknadsplatser med kompletterande tjänster. Det kan korta införandet och minska mängden specialkod. Samtidigt måste API-begränsningar, versionshantering, datakvalitet, autentisering och ansvarsfördelning granskas. Ett öppet API innebär inte automatiskt en enkel integration. Skillnader i begreppsmodeller och affärsregler kan kräva betydande analys även när den tekniska anslutningen är väl dokumenterad.
Egenutvecklade integrationer kan ge full kontroll och exakt anpassning, men kontrollen innebär också fullt ansvar. En enklare integration kan ta månader att bygga, medan mer komplexa kopplingar kan kräva ännu längre utvecklingstid. Därefter måste någon övervaka flöden, hantera fel, uppdatera autentisering och testa förändringar. I praktiken bör varje integration betraktas som en produkt med egen livscykel, inte som en engångsuppgift i ett införandeprojekt.
- Definiera en gemensam informationsmodell och tydliga ägare för centrala data.
- Använd standardiserade API:er där de täcker verksamhetens behov.
- Separera integrationslogik från kärnsystemets mest föränderliga delar.
- Dokumentera felhantering, återförsök, loggning och manuella reservrutiner.
- Beräkna underhållstid när något av de anslutna systemen uppgraderas.
Erfarenheter från branscher med höga krav på interoperabilitet visar dessutom att en enda standard sällan löser alla informationsbehov. Vård och omsorg är ett tydligt exempel, där processmodeller, kliniska informationsmodeller och kommunikationsstandarder behöver kombineras. Lärdomen är generell: integrationsstrategin måste börja i verksamhetens informationsbehov, inte i leverantörens marknadsförda anslutningslista.
Hybridmodellen som förenar standard med skräddarsytt
Hybridmodellen är ofta det mest balanserade alternativet för affärskritiska system. Den bygger på en stabil SaaS-kärna för generiska funktioner, kompletterad med egna tjänster, analyslager eller användargränssnitt för det som är specifikt för verksamheten. På så sätt kan organisationen dra nytta av leverantörens drift, säkerhetsarbete och produktutveckling utan att ge upp all flexibilitet.
En sådan arkitektur kräver disciplin. Anpassningar direkt i kärnsystemet bör begränsas, eftersom de kan försvåra uppgraderingar och skapa leverantörsberoende. Unika funktioner bör i stället placeras i fristående extensions med tydliga API-kontrakt. Moderna AI-verktyg kan göra prototyper och nischade arbetsflöden snabbare att utveckla, men de tar inte bort kraven på datakvalitet, behörigheter, spårbarhet, support, juridik och långsiktigt ägarskap. Den sista delen från fungerande demonstration till robust produkt är ofta den mest krävande.
För att undvika inlåsning behöver den tekniska och kommersiella designen planeras samtidigt. Följ en stegvis modell:
- Bestäm vilka funktioner som ska vara systemets standardiserade kärna och vilka som är strategiska extensions.
- Definiera dataägarskap, exportformat, API-rättigheter och krav på dokumentation innan avtalet undertecknas.
- Bygg egna tillägg löst kopplade till kärnan, med testbara gränssnitt och så få leverantörsspecifika beroenden som möjligt.
- Starta med ett avgränsat pilotområde där riskerna är begränsade och effekten går att mäta.
- Fastställ en exitplan som omfattar data, integrationer, kompetens, avtal och realistisk migreringstid.
Hybrid betyder inte att allting ska kopplas ihop med allting. Varje ny komponent ökar den arkitektoniska ytan och kan skapa fler felkällor. Därför bör ett nytt tillägg motiveras med mätbar nytta, exempelvis kortare handläggningstid, bättre prognoser eller högre kundlojalitet. Om funktionen inte ger sådan effekt är standardisering ofta det klokare valet.
Bygg er strategi på faktabaserade avvägningar
Inför nästa plattformsinvestering bör ledningsgruppen undvika att börja med frågan om vilken teknik som är mest modern. Börja i stället med verksamhetens viktigaste värdeskapande processer, deras förändringstakt och den risk organisationen faktiskt är beredd att bära. Ett beslut blir starkare när verksamhet, IT, ekonomi, juridik och informationssäkerhet delar samma beslutsunderlag.
En praktisk rekommendation är att rangordna processerna i tre grupper: standardisera, konfigurera och bygg. Standardisera där kraven är generella. Konfigurera där ett SaaS-system kan stödja verksamheten utan att kärnvärdet urholkas. Bygg endast där egen logik ger en tydlig, mätbar och långsiktigt försvarbar fördel.
- Skapar den här funktionen en konkurrensfördel som kunder eller marknaden faktiskt värderar?
- Är femårskostnaden, inklusive förvaltning, integrationer, kompetens och exit, lägre än värdet av den kontroll som egenutveckling ger?
- Kan arkitekturen förändras utan att organisationen blir beroende av en viss leverantör, teknik eller nyckelperson?
Det viktiga är inte att välja SaaS eller egenutvecklat som ideologisk position. Det viktiga är att köpa standard där standard räcker och investera egen kapacitet där den skapar verkligt affärsvärde. En sådan strategi ger lägre teknisk skuld, bättre förändringsförmåga och ett tydligare långsiktigt ägarskap över de system som verksamheten inte har råd att misslyckas med.










Senaste kommentarer