Låt oss låtsas att du har en IT-avdelning. Den kostar 10 miljoner om året. Men trots att den inte får direkt fler system att ta hand om, så levererar den sämre och sämre resultat, för lika mycket pengar.
Nu säger de som arbetar där att de går på knäna. Du tror dem inte riktigt, så du ber att få se vad de lägger sin tid på och ser att de förmodligen har rätt, de har alldeles förfärligt mycket att göra.
Nu räknar de ut att de skulle behöva öka sin budget med 5 miljoner kronor, till 15 miljoner om året. Ska du acceptera? Och hur blev allt så dyrt, plötsligt?
Vi kan beskriva situationen med följande diagram:
Detta är den förväntade nyttan av IT-avdelningens arbete. Vid nollpunkten, längst till vänster, ligger den i paritet med sin driftskostnad på 10 miljoner.
Men det här är den verkliga situationen. Kostnaden är densamma, men nyttan går ner över tid. Kraftigt ned till och med, om det får fortsätta:
Det som händer här är vad som skämtsamt brukar kallas för "bitröta", eller software rot
Bitrötan är på skoj (databitar ruttnar i allmänhet inte), men allt runtomkring systemet rör på sig. Hårdvara blir sämre, ny hårdvara kräver nya operativsystem som kanske har en lite annorlunda hantering av saker och ting, osv osv.
Men i allmänhet beror det på att själva verksamheten ställer något annorlunda krav nu än tidigare på samma system. Datamängder ökar, nya slags transaktioner ska in osv osv.
Även om man underhåller sina system och programmerar in ny funktionalitet, så kan en ursprunglig design eller arkitektur bara tänjas till en viss gräns. Till slut tar kostnaden för all handpåläggning osv ut sin rätt.
Denna ökade arbetsvolym är det gröna fältet nedan:
Det gäller alltså att vara förutseende, och inte anta att ett driftsatt system kräver lika mycket underhåll dag 1 som dag 700. Redan från början ska man planera in tid för en ordentlig översyn och omarbetning av systemet. Givet en "normal" förändringstakt i omgivningen, så är två år en bra tumregel. Men bara som tumregel, verligheten kan se annorlunda ut i dina omgivningar. Allt beror på hurpass robust designen var från början (hur väl man lyckades förutse vad som komma skulle), och hurpass oförändrad din verksamhet är.
Poängen är att alla ska vara medvetna om detta, redan från början. Och två år är ingen dum avskrivningstid. Skulle ditt system ha klarat sig väl på den tiden, så har du en stor fördel under omarbetningen, i det att du kommer att kunna återanvända såpass mycket. Att göra fel åt andra hållet däremot (förutsätta stabilitet över en femårsperiod, men tvingas till förändringar tidigare), är inte ekonomiskt.
Det handlar ju om att stipulera den tid som du ska räkna hem systemet på. Frågan är om man vågar lita på en tidsperiod som är längre än två år. Det är ju mycket som kan hända.
Nå, ska du stillatigande acceptera en ökning av driftsbudgeten med 5 miljoner? Kanske, men förmodligen inte. Inte innan du vet vad du får för pengarna.
Allt vad IT-avdelningen tar sig för är inte lika effektivt. Alla delsystem är inte lika illa däran. Vad du bör göra är att lämna den klumpvisa "IT-drift"-posten åt sitt öde. Den säger ingenting om hur väl spenderade enkronorna är. Istället ska du ta reda på vad det är för system (och tjänster) som du har i verksamheten, och ställa deras kostnader emot intäkterna, vart och ett för sig.
Förmodligen kommer du att behöva rucka på dina prioriteringar på köpet. Du kommer att se vad du betalar för. Du kommer att kunna rätta munnen (IT-behovet) efter matsäcken (IT-tjänsterna) på ett mycket bättre sätt. Och du kommer att frigöra resurser som kan ta itu med den långsiktiga förbättringen av din plattform.
Det är det som är business alignment. Din verksamhet ser över sitt IT-behov, och ändrar sina krav så att det verkliga IT-behovet blir uppfyllt.
Kanske kommer du att finna att 15 miljoner inte är en orealistisk IT-budget. Men du kommer att ha koll, inte bara på vart de nya fem miljoner kronorna går, utan vart alla femton miljoner går. Du skaffar dig koll, och det är bra att ha. Kanske har dina konkurrenter redan koll.
Inga kommentarer:
Skicka en kommentar