Systemförvaltningsmodell, vad ska man välja?

Frågorna

• Vilken systemförvaltningsmodell ska vi välja?
• Vilken modell löser alla våra problem på en gång?
• Vilken uppsättning roller, processer, mallar och checklistor ska vi följa?

Det känns som en stor del av förvaltnings-sverige har sökt efter svar till dessa frågor på senare år. Ganska många har valt modell för några år sen och börjar nu så sakta inse att modellen och verkligheten inte riktigt matchar.

Befriande uppvaknande

Det kändes som ett befriande uppvaknande när jag läste Sundsvall 42:s beskrivning av årets systemförvaltningskonferens. Den skulle äntligen handla mindre om modeller, och mer av verkligheten, eller åtminstone om gränslandet där de möts: teorin och praktiken.

Bra med modell, men löser inte allt

I grund och botten är det inget fel med en teoretisk modell som beskriver våra roller och vårt agerande. Den kan vara lite för omfattande men trots allt är den mer bra än dålig. Felet vi ofta gör är att tro för mycket på den. Vi tror att bara för att någon har en doktorstitel i systemförvaltning så måste ju de ha prickat rätt, och det borde ju passa oss? Varför skulle just vår verksamhet vara annorlunda? När man sedan får problem så är min erfarenhet att man hamnar i en av två fållor:

• Antingen blir man modell-religiös och desperat försöker anpassa verkligheten till modellen, verksamheten blir intvingad i ett mönster som inte passar.
• Eller så inser man att modellen "inte stämmer", förlorar förtroendet för den och använder den mindre och mindre och till slut är den bara en papperstiger.

Modellskaparnas svar

Frågar man personerna på På, företaget bakom den mest populära modellen Pm3, vad man gjort för fel och hur man skall göra istället så får man svaret:

"Du måste anpassa modellen till din verksamhet och ta bort det som är onödigt för er"!

Man ska ta fram Ockhams rakkniv och dissikera modellen ner till en storlek och omfattning som passar. Det är ett ganska bra råd förutom på en punkt: Man förväntas bara vara kreativ med att ta bort onödiga delar!

Agil systemförvaltning - det bästa svaret

Agila metoder inom systemutveckling kom som en våg över stockholmsområdet för 5-6 år sedan. Nu har vågen dragit förbi, Scrum används fortfarande men mer på rutin. Det finns mycket att lära av den resan, det som passar bäst inom systemförvaltning är kanske att Scrum gjorde en stor grej av att vara "den minsta möjliga modellen". Där utgår man från den enkla och lägger på om det skulle behövas. 

Här tror jag att vi hittar det bästa svaret: 

Använd den modell ni redan har, men var inte rädd att lägga till, förändra, experimentera, ta bort och förbättra över tiden.Våga tänka själv.

Och använd så många grundläggande agila värderingar du kan på vägen: 

Utvärdera löpande, bilda team och samarbeta över gränser, prioritera allt du gör, gör inte allt på en gång, leverera löpande och visualisera det du gör!

Mer press gör oss bättre!

Ofta uppfattar vi orden stress och press som något negativt. Jag tycker inte att det är det. Snarare tvärtom. Utan yttre press ifrån kunder, uppdragsgivaren, användare och övriga intressenter till våra IT-system så levererar vi sämre värde. Skulle Sveriges bästa systemutvecklare få fria händer i 3 månader utan någon yttre press, så skulle det bli ett sämre slutresultat än om de hade pressats framåt av en drivande produktägare. Jag är helt övertygad!


Agila metoder och press
Inom agila metoder och scrum i synnerhet så förespråkas ofta att man skall hålla ett "lagom" tempo, inte driva på för hårt utan satsa på kvalitet (i kod och test) hellre än fler funktioner (värden) i systemen. I grund och botten är detta en sund filosofi och bra värderingar. Men jag undrar om det i långa loppet inte leder oss in i en fälla. När grundtesen är att det kommer att ta längre tid att skapa system med kvalitet, så luras vi nog också att använda onödigt krånglig och ny teknik, alltför avancerad arkitektur och omfattande tester.

Lean, mindre "Waste"
Ibland kan en tydlig yttre press vara en viktig faktor för att hålla både verksamhet och utvecklare på spåret. Det kan hjälpa verksamheten att prioritera: vad är det egentligen som är viktigt? Vad händer om vi inte får funktion X? Mindre nödvändiga funktioner som kanske inte skulle ha använts så mycket lyfts ut ur projektet, vi producerar mindre "waste". Men det bidrar också till att sätta systemet i drift efter varje sprint. Nåt som man ska göra, men alltför ofta så går det 2-3sprintar innan det faktiskt görs.

Keep it simple
Press hjälper inte bara verksamheten, det hjälper systemutvecklarna också. Även om de inte gärna erkänner det. Yttre press tvingar utvecklarna att omvärdera teknik och arkitekturbeslut, inte tänka lite mycket på alla framtida eventualiteter som *skulle kunna ske* utan fokusera på vad systemet ska göra idag. I bästa fall blir systemet enklare, mer effektivt och mer anpassat till den faktiskt uppgiften.

Myntets baksida
Tyvärr tror jag inte att "mer press" är en universell princip som funkar i alla lägen. Riktigt så enkelt är det nog inte. Men när både verksamhet och utveckling har jobbat med varandra en tid, samarbetet fungerat bra och båda parter har förtroende för varandra, då är det läge att lägga på lite press! Men tänk på att det bör finnas erfarenhet på både sidor. Att sätta extra press på personer som är nybörjare i sin roll kan lätt leda till att fel krav blir realiserade, utvecklarna producerar "spaghettikod" och då står där med en produkt som är nästintill omöjlig att förvalta.

Jävla skitanvändare!

Användarmedverkan i systemutveckling/förvaltning har varit på modet de senaste åren. För något år sedan kom boken "Jävla skitsystem", som tar upp att användarna känner sig frustrerade över dåligt utformade (förvaltade!) IT-system. Nu ger sig en kollega sig in i debatten och hävdar att IT-system endast blir lönsamma om användarna får bestämma över systemet och inte tvärtom.

Användarna är viktiga
Användarna är en väldig viktig del av ett bra utformat IT-system, både i utvecklingen av ett nytt system och i underhållet av det över tid. Om man inte lyssnar på dem riskerar man att bygga dåliga och olönsamma system. Men man kan inte hissa upp användarna till skyarna och säga att de ska bestämma!

Men viktig innovation bidrar de inte med
Får användarna bestämma kommer säkerligen kostnaden för användandet av systemet att minska på sikt. Användarna borde rimligtvis få ett system som är mer anpassat till deras upplevda behov, just nu. Men det hela bygger på premissen att användarna vet "precis vad de vill ha" för att bli mer effektiva i sitt arbete... Min erfarenhet är snarare att användare "vill ha det precis som det var förut (i det gamla systemet), bara en gnutta bättre".  Innovativa idéer som revolutionerar hur de arbetar med IT-stödet i sin vardag kommer oftast inte ifrån den breda användarmassan, istället andra grupper/personer bidra, t.ex. affärsutvecklare, konsulter, förvaltningsledare, användbarhetsexperter m.fl.

Vissa lyssnar inte alls
Steve Jobs sa för något år sedan: "We do no market research...". Världens just nu största företag lyssnar inte aktivt på sina existerande kunder/användare. Och de skapar fantastiska nya produkter som underlättar vår vardag!  Jag tror att de inte lyssnar för att de vet vilka svar de kommer få.

Lyssna på användarne vid förbättringar, inte förnyelse
Ska man skapa nånting nytt: en ny funktion, ett nytt system, en ny arbetsprocess så ska man ta lättare på det användarna säger än om man förbättrar något existerande. Det användarna främst bidrar med är ju erfarenheten av användandet. Och det har man ju bara efter att man använt något, det är omöjligt att ha erfarenhet av något som ännu inte finns. Därför kommer användarnas feedback som helhet alltid vara en aning bakåtsträvande och fast i det gamla, det som finns idag. 

Våga göra stora förändringar
I förvaltningen är användarnas input ovärderlig när det gäller små, effektiviserande förändringar av system. Men som förvaltningsledare får du inte bara lyssna på dem, se till att få input ifrån fler intressenter till systemet innan förbättringen genomförs. Annars genomförs inte tillräckligt innovativa och genomgripande förändringar och systemet blir snart förlegat, utbytt och olönsamt!

Höga kostnader för systemförvaltning?

Systemförvaltning har alltid varit lite baktalat och förknippat med höga kostnader. Många tycker att man inte får ut så mycket för pengarna och blir mer och mer sugen på att bygga nytt istället. Jag tycker att man aldrig ska tveka att avveckla system som inte bidrar med mer nytta till verksamheten än vad kostnaderna för att vidmakthålla dem motiverar. Men... vad är egentligen höga eller låga kostnader för systemförvaltning?

Kostnader ur flera perspektiv
Alla kostnader kan givetvis mätas i pengar, men säger det så mycket? Det är klart att om man lägger ner åtskilliga miljoner på sin systemförvaltning per år så kan det vid första anblicken tyckas mycket. Men för att förstå om det är högt eller lågt bör man sätta det i relation till något annat. Nedan kommer lite tips på hur du kan motivera dina förvaltningskostnader för någon som har känslan av att de är för höga.

• Jämför kostnaderna med nyttan för verksamheten, även om nyttan är notoriskt svårt att mäta. Tänk på att inte jämföra med "hela nyttan av systemet", det är ju förvaltningen vi pratar om! Nyttan av att systemet kontinuerligt anpassas till verksamheten är det vi jämför med.
• Jämföra med investerings- och förvaltningskostnaden för att bygga ett nytt system.
• Lyft fram fakta: 80% av kostnaden för ett system kommer under förvaltningen, att förvaltningskostnaderna över tid blir högre än investeringskostnaden är inget konstigt!
• Bryt ner kostnaden i sina beståndsdelar: drift, vidmakthållande och vidareutveckling. Vidmakthållande är de kostnader som krävs för att upprätthålla samma funktion i systemet över tid.
• Bryt ner kostnaden baserat på hur många som använder systemet! 5 miljoner i vidmakthållande kanske känns mycket, men 5000kr per användare och år känns rentav billigt för ett system som används av 1000personer. Vad kostar t.ex. en bärbar dator per användare och år?
• Om systemet skulle sluta förvaltas kan det vara svårt att förutse konsekvenserna på kort tid. Titta istället bakåt i tiden och fundera på vad som skulle hänt om förra årets förvaltningsaktiviteter inte hade genomförts.

Förvaltning är bra, men tveka inte att bygga nytt!

Att sätta förvaltningskostnaderna i perspektiv med annat är alltid nyttigt. Men om du inte lyckats motivera kostnaderna och förvaltningen redan har dragits ned till ett minimum under ett antal år, kanske kostnaden för att komma ikapp med förvaltningen är lika stor som att bygga ett nytt system? Att bygga nytt är alltid något som bör beaktas, alltid något som ska utmana den existerande förvaltningen!

ITIL vs pm3, slaget om rätt förvaltningsmodell?

Besökte nyligen dataföreningens frukostseminarium om Itil och pm3, likheter, skillnader samt värdet av kombinationen. Noterade redan innan seminariet började att det var ovanligt många kvinnliga deltagare, de var i majoritet skulle jag nog säga. Tolkade jag publiken rätt så var kvinnorna där för pm3 (och de kom i huvudsak ifrån verksamheten), och männen där för ITIL (och kom ifrån IT-avdelningen eller var konsulter). Föga förvånande var sedan att männen tog upp mest plats med många detaljfrågor och diskussioner. Männen kände nog att "deras ITIL" inte riktigt fick det erkännande som anstod modellen. Seminariet utvecklades till ett riktigt skyttegravskrig mellan ITIL-förespråkarna och föredragshållaren ifrån På.

Tillsammans är vi starka
Diskussioner om vilken modell man bör använda inom systemförvaltning är nog inte över efter detta utan lär nog fortsätta ett tag till. En intressant iakttagelse var på vilket sätt som de olika modellerna definierar gränslandet mellan verksamheten och IT. I ITILs värld heter det "IT-tjänster" och i pm3:s värld heter det "förvaltningsprodukter" (inte helt jämförbart, jag vet). Det intressanta är just hur dessa definieras. I ITILs värld är det IT-avdelningen som tar initiativet och paketerar det de gör till en tjänst och sätter prislappen på det. Det är ett tydligt kund - leverantörsförhållande där risken och kostnaden ligger hos IT. Medan i pm3:s värld är definitionen av förvaltningsobjekten och dess ingående produkter något som verksamheten och IT gör tillsammans! Där delas risk och kostnader! Exakt var gränserna ska gå i det enskilda fallet är upp till båda parter att reda ut, inte något som en väldefinierad tjänst löser åt en.

Affärsmässig fel ord
Pm3 försöker förklara denna så enormt viktiga samverkan mellan verksamheten och IT med ordet "affärsmässig". Men där skjuter de helt fel. ITIL-anhängarna har en annan relation till det ordet, de tänker paketerade och väldefinerade IT-tjänster med tydliga kontrakt och SLA:ar när någon säger affärsmässig. Vad de istället borde använda sig av är ju mer mjuka ord som "tillsammans", "samarbete", "gemensam". Lämna orden "kontrakt", "avtal", "SLA" till ITIL istället. För det är just i de mjuka områdena som pm3 skiljer sig mest ifrån ITIL, om man nu ens bör jämföra dem.

Gemensam förvaltningsstyrning
Kanske borde pm3 byta ut affärsmässig förvaltningsstyrning till "gemensam förvaltningstyrning" för att göra detta tydligare för alla fanatiska ITIL-människor?

Glöm aldrig bort det som är BRA!

Inom systemförvaltning såväl som andra områden så fokuserar vi gärna på det som funkar mindre bra.
Vi letar efter problem som kan fixas för att skapa nåt som är "lite bättre". Men allt som oftast så glömmer vi helt bort det som faktiskt funkar BRA.

Under ett av årets julbord så gled samtalet in på en liknande situation. En relativt ny mellanchef tyckte att en medarbetare inte bidrog med något och vill avveckla tjänsten... Kunskapen om värdet av det han gjorde hade gått förlorad över tiden. Ingen (högre upp i organisationen) visste längre varför tjänsten var viktig. Men de som hade varit med en längre tid förstod vikten av att tjänsten var kvar och försökte avstyra det hela fem i tolv. Jag tror att de lyckades...

Samma sak kan lätt drabba oss inom systemförvaltning.
Frågor som de här kan komma upp efter en tid:

• Varför har vi det här systemet? 
• Liknande funktionalitet finns ju i vårt affärssystem?
• Avdelning X har ju ett standardsystem, kan vi inte använda deras system istället?
• Vi måste minska förvaltningskostnaden med 90%

När de kommer är det ett säkert tecken på att man glömt bort nyttan av systemet. Det finns inte längre något skrivet eller kommunicerat om hur systemet stödjer verksamheten, varför det inte går att använda ett standardsystem eller affärsnyttan av aktivt systemunderhåll. Det är inte så konstigt att man i det läget ifrågasätter existensen av systemet, kanske till och med ett sundhetstecken att man gör det?

Hur undviker vi liknande situationer?
Genom att kontinuerligt beskriva och omvärdera nyttan av systemen vi förvaltar så kan vi enkelt undvika sådana diskussioner. Gör en årlig översyn av hur systemet stödjer verksamheten. Var inte rädd för att fråga personer i verksamheten:

• Vad är det som är så bra med systemet?
• Vad skulle du göra om systemet inte fungerade under en vecka?
• Vilken funktion använder du mest?
• Vilken förändring av systemet under 2010 var till störst nytta för dig?

Du får snabbt en bra överblick över nyttan, och ett fantastiskt underlag för nya visioner om hur systemet kan utvecklas! Det är lätt att fokusera på det som "inte funkar", men om vi glömmer bort det som är bra så kan fort vår verklighet förändras i grunden! Glöm aldrig!

Sänkta timpriser skapar aldrig effektivare förvaltning!

Det är svårt att skapa incitament i IT-branschen som fungerar i det långa loppet. Jag har sett det flera gånger förut: personliga bonusar för utvecklare som leder till att ingen vill ta ansvar när projekten kraschar (när projektet drar över budget får man ju inte längre någon bonus, bara lön). Flera gånger har jag suttit med i referensgrupper och försökt utforma det "perfekta bonussystemet" för utvecklare... slutsatsen? Ekonomiska incitamentsprogram är ingen lätt uppgift.

Det verkar Stockholms stad också ha insett. De hade en formulering i avtalet med Tieto som syftade till att Tieto skulle ta ansvar för att Stockholms stad sparade/tjänade på de IT-förbättringar som gjordes och i utbyte skulle få ta del av "besparingen". Tieto utnyttjade aldrig den möjligheten. Intressant idé, synd att vi aldrig fick se om/hur den skulle fungerat.

Nu vill istället Stockholms stad pressa Tieto med stadigt sjunkande timpriser för att få "effektivare systemförvaltning". Från att ha varit ganska kreativa så är de tillbaka på spåret att lägre timpriser måste  innebära lägre kostnader. Kostnaden per timme kommer garanterat att sjunka, men är det verkligen det bästa sättet att effektivisera sin systemförvaltning? Knappast.

Tittar vi lite hur forskningen ser på vilka situationsfaktorer som är viktigast för att lyckas med sin systemförvaltning så är det dessa två:

1. Kunskap om verksamhetens behov
2. Tillgång till kompetent personal

Så om man vill skapa incitament för effektiv förvaltning, så bör man rikta in sig på dessa två istället för timpriser. Det finns förstås flera olika sätt men man kan ju börja med dessa:

1. Se till att de som jobbar med systemförvaltningen kan din verksamhet, dina behov, dina affärer och din organisation.
2. Se till att de som förvaltar dina system kan dem, vet varför de finns och hur de används av din verksamhet.

Har du säkerställt att ovanstående är uppfyllt så kommer du spara timmar istället för 1,5% av timkostnaden. Är det nån som tror att man på ett 100h uppdrag inte skulle spara minst 2h om ovanstående var uppfyllt?