Den dolda kostnaden för legacy.

Legacy-system är sällan trasiga. De gör vad de ska göra — det de byggdes för, med den logik och de antaganden som gällde när de skapades. Problemet är inte systemet i sig. Det är vad som tillkommer med åren.

Nyckelpersonberoendet

De flesta äldre system har en eller två personer som verkligen förstår dem. De vet vilka undantag som hanteras var, varför ett visst fält alltid är tomt och vad som händer om man gör fel i steg fyra. Kunskapen sitter inte i dokumentationen — den sitter i huvudet på dem.

Det kostar vid varje ändring de inte är tillgängliga för att granska. Det kostar mer om de en dag slutar.

Det är inte en ovanlig situation. Det är normen för system som driftsatts, fungerat och aldrig prioriterats för kunskapsöverföring. Och det är en risk som inte syns i budgeten förrän den realiseras.

Bräckliga integrationer

Affärskritiska äldre system är sällan isolerade. De pratar med affärssystemet, med portalen, med rapportverktyget. Integrationerna fungerar — tills ett kringliggande system uppdateras.

Varje förändring i omgivningen innebär en riskbedömning: vad händer med det gamla systemet? Den bedömningen tar tid och bromsar ofta förbättringar som i sig inte har med legacy-systemet att göra. IT-avdelningen vet vad som händer. Verksamheten märker att saker går långsamt utan att alltid förstå varför.

Möjligheterna ni inte kan ta

Det här är den kostnad som sällan tas med i kalkylen eftersom den inte syns på en rad. Systemet saknar ett API. Det går inte att koppla till den nya plattformen. Det stöder inte den integration som era kunder börjar kräva. Ni vet om det men kan inte göra något åt det utan en stor insats.

Var och ett av de exemplen är en begränsning som kostar — i konkurrenskraft, i förhandlingsutrymme med leverantörer, i vad ni kan erbjuda era kunder. Och den kostnaden räknas sällan ihop med underhållskostnaden för systemet.

Hur räknar man på det? Svaret är inte att söka branschgenomsnitt och jämföra sig. Det är att ställa de frågor som faktiskt kan besvaras med era egna siffror:

• Hur många timmar per vecka lägger nyckelpersonerna på att stödja eller förklara systemet för andra?
• Hur ofta behöver ni skjuta upp en förändring i ett kringliggande system på grund av legacy-beroendet?
• Vilka förbättringar har ni skrinlagt de senaste tolv månaderna för att de krävde att legacy-systemet behövde röras?

De svaren ger ett ungefärligt pris på status quo. Det är ett bättre beslutsunderlag än en principdiskussion om modernisering.

En sak som ofta förbises i de diskussionerna: affärslogiken i det gamla systemet är en tillgång. Trettio år av undantag, anpassningar och branschspecifika regler är kodad kunskap om hur er verksamhet faktiskt fungerar. Det är inte ett skäl att behålla ett inaktuellt system — men det är ett skäl att modernisera med omsorg och bevara det som fungerar, inte bara skriva om koden.

Gaia har gjort det arbetet för organisationer som arbetat med sina system sedan 90-talet. Det kräver tid att förstå vad systemet faktiskt gör, inte bara vad det ser ut att göra.

Om ni funderar på att ta ett första steg: börja med att kartlägga nyckelpersonberoendet och de tre viktigaste begränsningarna som legacy-systemet ger er idag. Det är ofta nog för att avgöra om — och när — modernisering är rätt prioritering.