Läser mer i: ESV:s rapport:
Huvudrapporten sid 21-24: ESV har sammanställt it-kostnader som andel av verksamhetskostnad, it-investeringar som andel av verksamhetskostnad, inhyrd it-personal som andel av total it-personal, it-kostnader per användare, kostnad för utkontrakterad it-verksamhet som andel av it-kostnad, kostnad per it-arbetsplats, kostnad för telefoni per användare, utgifternas fördelning mellan att säkerställa, förbättra, nyutveckla, samt kostnader för lagring.
Här är jag inte ense med ESV. Det är möjligt att det finns värden jag inte ser i denna inhämtning, men jag har svårt att se hur dessa tal på något sätt kan sporra till handling när det gäller digitaliseringen. Och alla nyckeltal ska sporra till handling, annars är de meningslösa.
Till att börja med är det som jag skrivit tidigare tveksamt att kunna isolera IT-kostnader på ett vettigt sätt. Och så olika och konstigt som de myndigheter jag sett valt att skilja mellan IT-kostnader och IT-investeringar undrar jag vilken nytta den indelningen gör. Det är mängder med investeringar (permanenta och nyttiga förbättringar i IT-stödet) som bokförs som kostnad och mängder med kostnader (till exempel slöserier inom projekt) som bokförs som investeringar. På samma sätt är skillnaden mellan säkerställning, förbättring och nyutveckling extremt svår att göra när det gäller systemutveckling, och gränsdragningarna sker ofta arbiträrt beroende på humöret hos revisorerna och verksamhetens preferens och förmåga att presentera saker som det ena eller andra.
Och att särskilja telefonikostnaden från IT-arbetsplatsen? Är mobil surf en del av det ena eller det andra? Är Skype telefoni eller IT? Hur kommer de framtida AR-glasögonen att bokföras? Trams a la 1900-talet. I år är vi en sjättedel in på 2000-talet.
Jag ser framför mig att Shekarabi och andra tänkt "Vad dyrt det är med IT! Tag reda på varför!" och att detta helt enkelt är verkets försök att svara på frågan. Men både i tidigare rapporter och i denna så påtalar de svårigheten att mäta den typen av kostnad utan att ha så djup kvalitativ förståelse av vad kostnaden innebär. Man säger på sidan 22 uttryckligen att sifforna bäst kan användas inom en myndighet (inte för jämförelser) och då för att bli medveten om kostnadera och öka lärandet om den egna verksamheten. Man kan inte dra några slutsater om lämpliga åtgärder från dem. Mätvärdena kan inte sporra till handling.
Huvudrapporten sid 26-30: De strategiska IT-projekten har svag målgruppsfokus. Verktygen för att följa upp nyttohemtagningen tillräckligt bra finns inte på plats. Planeringen och budgeten för strategiska IT-projekt revideras i stor utsträckning vilket kan bero på dåliga mål, ineffektiva arbetssätt eller bristfällig styrning och ledning.
Här är ett exempel på en kluvenhet jag märkt tidigare hos ESV vad gäller definitionen av vad som kännetecknar god IT-utveckling. Så här ligger det till: JA, offentlighetens IT-projekt har svagt målgrupps- och nyttofokus. Men det beror som sagt på att man i sina metoder, metoder som inte sällan är beslutade om på hög nivå, väljer att inte följa upp på det lika starkt som man följer upp på de konkreta produktmålen, leverablerna. För du kan ju som sagt inte följa upp på både på effektmål och produktmål. Under resans gång kommer det att visa sig att de initiala ideerna om produktmål inte var så bra som man först trodde.
Och NEJ, detta behöver inte innebära problem. Projektplaner och budgetar revideras. Är det något dåligt? Det beror väl på om de revideras för att man kommer till insikt om att den inslagna vägen leder fel medan den reviderade vägen är bättre? Om man bestraffar eller på annat sätt försvårar förändring kommer man skapa en kraft som in i det längsta hindrar insikten om att det finns en mycket bättre väg att sprida sig och påverka projektet. Den blir då en fördyrande och fördummande kraft. Och med dagens sätt att följa upp projekt på så är den kraften i full gång. Idén att det finns ett egenvärde i att hålla fast vid den plan som spikades vid en tidpunkt då man visste betydligt mindre om verkligheten än idag, den idén är farlig. Den blockerar innovation. Den skapar projekt som fortsätter fast de borde ha ändrat riktning för länge sedan.
Bakom tanken att revideringar är något dåligt ligger tanken att de hade kunnat undvikas om bara folk varit duktigare på att se in i framtiden. Och medan det i teorin är sant, så begränsas vi av vår faktiska förmåga att planera. Här spökar både "hindsight bias" (att vi dömer tidigare insikter baserat på kunskap vi har idag och inte på kunskap man hade då), samt oförmågan att erkänna att komplexa verksamheter (och dit hör tjänsteutveckling) är svåra att förutse.
Rapporten skriver: "Att budget och tidsplaner revideras skulle kunna bero på dåligt uppsatta mål, ineffektiva arbetssätt eller bristfällig styrning och ledning." Är ett bra mål ett som alltid kommer att stå sig oförändrat? Är värdet av förutsägbarhet alltid högre än andra värden? Traditionen bjuder så, och i en straffande organisation (som myndigheter ofta är) finns det ett starkt tryck att inte utsätta någon i högre ställning för överraskningar. Chefen vill inte göra generaldirektören besviken och generaldirektören vill inte få skäll av ansvarig minister. Att inte kunna förutse allt associeras med att inte ha kontroll över sin verksamhet.
Det är en helt igenom tokig idé. Tjänsteutveckling har en ganska hög grad av varians, särskilt när systemutveckling är inblandat. Det kan bero på dålig ledning att den variansen blir högre än nödvändigt, men den riktigt dåliga ledningen är den som kräver noll varians i en verksamhet som har en yttre varians man inte kan göra sig av med. Agila metoder för tjänsteutveckling, som arbetar med att löpande styra på effektmål, bygger på att man kontinuerligt reviderar planer och mål. Och det är inte något ineffektivt arbetssätt som bygger på bristfällig styrning. Tvärtom är styrningen väldigt hård när alla inblandade utövar ett starkt målstyrt ledarskap, och utforskandetekniken med ständiga små förändringar som löpande utvärderas är ett väldigt effektivt sätt att hitta bra vägar för att nå effektmålen.
Så här behöver ESV fundera lite: under vilka omständigheter är det ett problem att budgetar behöver revideras? Särskilt när man dessutom citerar eGovernment Benchmark att målet för styrningen inte kan vara att kunna förutse vad som komma skall utan kunna att hantera förändringen när den väl sker. Jag anar att två motstridiga tankar finns hos ESV här: den om att hålla fast vid planer och den om att hantera förändring, och jag tänker att ESV borde landa i rekommendationen att det effektivaste är att fokusera på nyttohemtagningen och effektiva sätt att styra mot den, även om de effektiva sätten innefattar reviderade planer.
Det finns en ansats till det i att man inte uppmanar till att försöka planera bättre utan i att myndigheterna bör problematisera varför projekten blir så stora att de tar lång tid (och därmed blir känsliga för förändring). Och det är precis den ansats som de agila metoderna tar: vi styr ekonomin i osäkerhet inte genom att försöka förutse allt (eftersom det inte går) utan genom att arbeta i små korta steg där varje steg innebär ett mätbart kliv framåt.
Och som svaret på frågan om varför myndigheternas projekt blir så stora vill jag be ESV att titta på befintliga destruktiva finansieringsmodeller som kräver att varje projekt i sig ska ha ett business case och vara lönsamt. Det finns många behov av stora plattformsarbeten i myndigheternas IT-plattformar för att kunna möjliggöra många framtida smarta effektiva tjänster. Men de möjliggjorda framtida tjänsterna får de inte ta med i beräkningen. Följden blir att de inte får pengar till plattformsarbeten om de inte kan realisera flera av dessa framtida tjänster inom samma projekt. Och då blir allt stort och klumpigt.
Det finns andra sätt att arbeta på, med en arkitekturell plan och en tjänsteutvecklingsplan som löper parallellt där arkitekturarbetet hela tiden föregår tjänsteutvecklingen något. Man kan i en sådan modell särskilja investeringar från ren R&D även utan att behöva gå omvägen via stora projekt, och man kan löpande styra om vad man arbetar med för att alltid arbeta på det som är mest lönsamt. Kostnaden för IT-utveckling är nämligen ganska konstant. Det kostar en viss summa pengar att få igång ett visst antal människor att kunna arbeta inom en viss domän i en viss teknisk miljö. Dessa människor kostar en klump pengar varje månad, oavsett vad du väljer att använda dem till. Fokuset och uppföljningen bör ligga på vad de arbetar med. Arbetar de med det som är mest användbart just nu?
Inga kommentarer:
Skicka en kommentar