Den dolda kostnaden för legacy.

Legacy-system är sällan trasiga. De gör det de byggdes för, med den logik och de antaganden som gällde när de skapades, så kostnaden kommer i stället från det som växer fram runt dem med åren. Den syns framför allt på tre ställen.

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. Den kunskapen finns i huvudet på dem och sällan i dokumentationen.

Varje gång de inte hinner granska en ändring kostar det, och det kostar mer den dag de slutar. För system som fungerat i många år utan att någon prioriterat kunskapsöverföring är det snarare regel än undantag. Ändå syns risken inte i budgeten förrän den faktiskt slår in.

Bräckliga integrationer

Affärskritiska äldre system är sällan isolerade. De pratar ofta med både affärssystemet och rapportverktyget, och integrationerna fungerar fint ända tills något av de kringliggande systemen uppdateras.

Därför kräver varje förändring i omgivningen att någon bedömer vad som händer med det gamla systemet. Det tar tid och bromsar ofta förbättringar som egentligen inte har med legacy-systemet att göra. På IT-avdelningen vet man varför, medan verksamheten mest märker att saker går långsamt.

Möjligheterna ni inte kan ta

Den här kostnaden kommer sällan med i kalkylen, eftersom den inte syns på någon egen rad. Kanske saknar systemet ett API, så att det inte går att koppla till den nya plattformen eller till den integration som era kunder börjar kräva. Ni vet om det, men det går inte att göra något åt utan en stor insats.

Varje sådan begränsning kostar, till exempel när ni förhandlar med leverantörer eller när en kund frågar efter något ni inte kan erbjuda. Ändå räknas den kostnaden sällan ihop med underhållet av systemet.

Hur räknar man då på det? Branschgenomsnitt säger lite om just er situation, så det är bättre att ställa frågor som går att besvara 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?

Med de svaren får ni ett ungefärligt pris på att stå still, och det är ett bättre beslutsunderlag än en principdiskussion om modernisering.

I de diskussionerna förbises ofta att affärslogiken i det gamla systemet är en tillgång. Trettio år av undantag och branschspecifika regler är kodad kunskap om hur er verksamhet faktiskt fungerar. Det motiverar inte att behålla ett inaktuellt system, men det är ett skäl att modernisera med omsorg så att det som fungerar följer med när koden skrivs om.

Därför börjar arbetet med att ta reda på vad systemet faktiskt gör i dag, och det är ofta mer än dokumentationen säger. Den kunskapen sitter i regel hos samma få nyckelpersoner som systemet redan är beroende av.

Vill ni ta ett första steg kan ni börja med att kartlägga nyckelpersonberoendet och de tre viktigaste begränsningarna som legacy-systemet ger er i dag. Ofta räcker det för att avgöra om modernisering är rätt prioritering, och i så fall när.

Om ni vill gå vidare

Vill ni få en samlad bild av läget finns Moderniseringsanalysen, förstudien in i en modernisering. Den tar två till tre veckor och har fast pris. Ni får en karta över era system och beroenden, en bedömning av riskerna per system och en prioriterad plan med kostnadsestimat för det första steget. Därefter bestämmer ni själva om och när ni vill gå vidare.