Tre poster som saknas i er TCO-kalkyl

De flesta kalkyler för en digital lösning har två rader. Bygget, med en siffra som kommer från offerten. Och förvaltningen, med en siffra som ofta är en schablon räknad på bygget.

Den andra raden är problemet. Bakom ordet förvaltning ligger tre kostnader som uppstår av olika skäl, beter sig olika över tid och går att budgetera var för sig. Slår man ihop dem till en klumpsumma spricker budgeten, och den spricker sällan där man tror.

Ett: arbetet som andra beställer åt er

En kundportal eller återförsäljarportal är kopplad till flera system, och vart och ett av dem har sin egen releaseplan. Ni bestämmer inte takten i något av dem.

Titta på Litiums egna release notes för de senaste tolv månaderna, september 2025 till augusti 2026, plattformen räknad utan add-ons. Tolv funktionsreleaser, alltså en i månaden. Sexton rättningsreleaser däremellan, så den som följer den aktuella versionslinjen har tjugoåtta versioner att ta ställning till. Femton av ändringarna är märkta som brytande. Drygt fyrtio rättningar är märkta som kritiska. Två säkerhetsrättningar kom utan förvarning, och den ena av dem släpptes samtidigt till femton versionslinjer bakåt.

Lägg till affärssystemet. Business Central kommer i två stora releasevågor per år, i april och oktober, med kumulativa uppdateringar de flesta månader däremellan. Microsoft publicerar dessutom vilken kod som ska bort. Det som markerats som utgående försvinner efter tre releasecykler, ungefär arton månader. Då kan det som byggts ovanpå sluta fungera, på ett datum som är känt i förväg men satt av någon annan.

Till det kommer fraktbokningen, betaltjänsten och sökmotorn, som alla har sina egna versioner. För betalningarna tillkommer regulatoriska krav, och de kommer när de kommer.

Summan hamnar över fyrtio tillfällen om året då något runt lösningen förändras. De flesta kräver ingen åtgärd hos just er, men någon måste läsa och avgöra det. Den bedömningen kostar tid även de gånger svaret blir nej.

Det här är den mest förutsägbara av de tre posterna, eftersom alla kalendrar är publika. Det är också den som oftast saknas helt i kalkylen.

Två: följdfelen av era egna ändringar

Varje förändring ni gör i lösningen bär en risk att något annat slutar fungera. Det är ingen anklagelse mot den som bygger, utan något som är uppmätt.

I en studie av fyra stora operativsystem, däribland Linux och FreeBSD samt ett kommersiellt system med tolv års historik, visade det sig att mellan 15 och 24 procent av rättningarna efter release var felaktiga på ett sätt som drabbade användarna. Var femte rättning skapade alltså nytt arbete. Studien pekar också ut varför: 27 procent av de felaktiga rättningarna gjordes av utvecklare som aldrig tidigare hade arbetat i de filer de ändrade i.

Räkna med det. Gör ni tjugo förändringar under ett år kommer några av dem tillbaka. Det är inget tecken på en dålig leverantör, utan på att lösningen används och att någon rör vid den.

Den här posten växer med hur mycket ni själva ändrar, vilket också gör den möjlig att styra. Bygger ni lite blir den liten.

Tre: omtagen

Den tredje posten vill ingen budgetera för, eftersom den känns som ett misslyckande. Det är den inte.

Lehmans lagar om programvarans utveckling formulerades på sjuttiotalet och gäller fortfarande. Ett system som används måste förändras, annars blir det gradvis mindre användbart. Och när det förändras växer komplexiteten, om ingen aktivt arbetar för att hålla den nere. Kvaliteten sjunker om ingen underhåller strukturen och anpassar den till omvärlden.

I praktiken betyder det att delar av lösningen då och då behöver göras om från grunden i stället för att lappas ännu en gång. En integration som byggdes mot en version av affärssystemet och sedan anpassats sju gånger är inte samma integration längre. Vid något tillfälle blir det billigare att bygga om den än att fortsätta laga.

Ett omtag vart tredje eller fjärde år på en avgränsad del av lösningen är normalt. Budgeterar ni inte för det kommer det ändå, fast som en obehaglig överraskning mitt i ett verksamhetsår.

Vad som inte hör hemma här

Vidareutveckling. Nya funktioner, nya flöden, en portal till, en marknad till.

Det är en investering i affären och ska ligga på en egen rad, med egen motivering och egen avkastning. Blandas den ihop med de tre posterna ovan händer två saker, båda dåliga. Förvaltningsbudgeten ser uppblåst ut och blir ifrågasatt. Och när pengarna ändå tar slut är det utvecklingen som stryps, alltså precis det ni köpte lösningen för.

Håll dem isär. En rad för att hålla lösningen fungerande och kompatibel. En rad för det ni vill uppnå.

Fråga leverantören vilka av de tre som ingår

Det är en enkel fråga, och svaret säger mycket. Ingår kompatibilitetsarbetet vid uppgraderingar, eller offereras det varje gång? Vem betalar när en rättning behöver rättas? Finns det någon plan alls för omtag, eller lappas det tills något går sönder?

Vi har lagt de två första i en fast månadskostnad genom Glanser Care, och tar ansvar för att lösningen fungerar och följer med när plattformen och integrationerna uppgraderas. Den tredje planerar vi tillsammans med er i förväg, så att den hamnar i en budget i stället för i en akutsituation. Vidareutvecklingen håller vi separat, av samma skäl som ovan.

Vill ni se hur de tre posterna ser ut för er nuvarande lösning gör vi en nulägesanalys. Ni pekar ut er domän och avsätter två timmar för ett möte. Inom 72 timmar efter mötet får ni en inventering av funktionalitet och integrationer, en funktionsspecifikation framåt, en prototyp och en komplett kostnadsbild med tidsplan. Analysen kostar ingenting, och underlaget är ert oavsett vad ni väljer att göra sedan.

Källor

Antalet releaser, brytande ändringar och kritiska rättningar: Litiums publika release notes för plattformen, september 2025 till augusti 2026, räknat utan add-ons och acceleratorer.

Business Centrals releasevågor och hanteringen av utgående kod: Microsoft Learn, Dynamics 365 Business Central.

Andelen felaktiga rättningar: Yin, Yuan, Zhou, Pasupathy och Bairavasundaram, "How Do Fixes Become Bugs?", ESEC/FSE 2011.

Om att system måste förändras och att komplexiteten växer när de gör det: Lehmans lagar om programvarans evolution.