"Effekthemtagning", eller som det också kallas: "nyttohemtagning", är ett begrepp som handlar om hur mycket goda effekter man får av en förändring i en verksamhet, till exempel av en tjänst. Man vill ju inte att en tjänst ska finnas till bara för sin egen skull, man vill ju att den ska leda till något man värdesätter.
Inom tjänsteutvecklingen, och i synnerhet inom systemutveckling, har frågan om nyttohemtagning blivit viktigare med åren. Det kostar mycket att genomföra förändringar i tjänster, inte minst i form av ledtider. Får vi rätt effekt av förändringen?
Jag är mycket angelägen om att myndigheter i Sverige ska fungera smidigt. De är bland de viktigaste verksamheterna vi har, och till skillnad från företag kan vi inte bara byta ut dem om de tappar stinget. Myndigheter hanterar ju dessutom ofta ärenden som är särskilt känsliga: ser till att brottslingar grips och vi får leva i trygghet, försvarar vårt oberoende, ger oss sjukersättning, utbildning och annat viktigt. Därför måste vi alla hjälpas åt så att våra myndigheter verkligen fungerar.
När jag har arbetat åt myndigheter med att hjälpa till med att införa agila metoder inom IT-utveckling har jag flera gånger stött på strukturella hinder för att få till smidighet. När jag grävt i det har jag hittat regler och direktiv som på olika sätt försvårar smidighet, fördyrar förändringarna, och minskar chansen att lyckas. Naturligtvis inte med avsikt men systemeffekter av regleringar tar ju inte hänsyn till regelmakarnas goda vilja.
Ekonomistyrningsverket (ESV) granskar och följer upp hur myndigheternas investerinar i IT-stöd genomförs. Det finns inom Myndighetssverige en stark önskan om större smidighet och att man använder digitaliseringens möjligheter bättre, så man är villig att satsa på IT. Men man kan konstatera att effekten av satsningarna inte alltid blir vad man har tänkt sig. Varför? Det är en av de saker som Ekonomistyrningsverket ska ta reda på.
Jag har börjat läsa igenom verkets rapporter nu, och det som slår mig är att det som rapporterna önskar delvis motverkas av precis det som rapporterna föreslår. Inte minst för att det man föreslår förutsätter IT-utveckling som bygger på projektarbete och på uppdelning mellan beställare och utförare. Det kan vara svårt att förklara vad som är problematiskt med andra människors förslag om dessa bygger på en tankemodell som på avgörande punkter helt skiljer sig från den man själv har. Men jag kan ju försöka.
Vi tar ett exempel. I rapporten Fördjupat it-kostnadsuppdrag – Delrapport 2: Kartläggning av it-kostnader finns ett resonemang runt just nyttohemtagning. Man har kartlagt hur stor andel av ett antal myndigheter som har en modell för nyttohemtagning och konstaterar att myndigheter generellt är svaga på detta. Men sedan fortsätter man
ESV anser att det inför projektstart är självklart att göra en kalkyl som även omfattar effekter av eller nyttan med projektet. Det är också självklart att man efter genomfört (it-)projekt säkerställer att den tilltänkta nyttan tas hem. En modell för nyttohemtagning som tillämpas konsekvent i alla projekt säkerställer att de effekter som projektet syftar till faktiskt fokuseras och realiseras.
Ett av skälen till att agila metoder alls finns är att vi i början av något antingen kan bestämma oss för vilka nyttor vi ska sträva emot, eller så bestämmer vi oss för vilken lösning vi ska ha, men vi kan aldrig garantera bägge. Det beror på att vi saknar kunskapen.i början. Vi står inte helt handfallna utan oftast brukar vi kunna skapa mer eller mindre välgrundade hypoteser. Men så bra kunskap att vi kan prognosticera vilken effekt en viss lösning kommer att få, det har vi inte. Inte ens efter en förstudie. Särskilt inte om det finns organisationspolitiska skäl att genomföra projektet,då kommer tillräckligt många att helt enkelt anta goda effekter. Kalkyler är väldigt enkla att utföra när man saknar data. Och prognoserna kan bara verifieras i efterhand.
Så vi kan bestämma oss för vilka effektmål vi vill uppnå, och vi kan utforma den initiala idén om lösningen i den riktningen, men vi kan inte se in i framtiden.
Den andra meningen får mig också att fundera: "Det är också självklart att man efter genomfört (it-)projekt säkerställer att den tilltänkta nyttan tas hem." Men efter ett genomfört projekt kan man inte säkerställa någonting alls. Då sitter man med det man fick i knäet. Förhoppningsvis kan det vara till nytta för någon, men det går liksom inte att göra om alla de vägval som gjorts under resans gång.
Om man läser den tredje meningen så att den syftar på att arbetet ska bedrivas på ett sådant sätt att vi löpande siktar mot effektmålen under hela utvecklingen, då går det att genomföra. Det är under resans gång man når insikt om vad som faktiskt hjälper oss att uppnå målen. Inte innan, och efteråt är det för sent.
Men för att förverkliga det behöver å andra sidan myndigheterna ge upp projekten (som flera myndigheter lyckligtvis är inne på att göra). Samtliga projektmodeller jag sett som faktiskt används bygger på idén att lösningen ska vara detaljerad på ett mycket tidigt stadium, och sedan styr man mot den fastslagna lösningen i enlighet med den på förhand utlagda planen. I många beställar/utförarmodeller försöker man dessutom aktivt förhindra nya insikter genom att strypa kommunikationen mellan beställare och utförare så att inte den ursprungliga idén (som togs fram när kunskapsnivån var som lägst) hotas.
Agila arbetssätt bygger istället på löpande omplanering och omdesign. Vi vet vilka effektmål vi ska styra på, och utifrån det kan vi designa en minimal lösning som vi förmodar leder till dessa. Den hypotesen prövas och kunskaperna vi får fram matas in i nästa iteration och så vidare. Planerings- och budgeteringstekniker anpassade för arbetssättet ser till att effekten per krona blir optimal i varje stund. Löpande effektkartläggning och andra tekniker ser till att vi filtrerar fram de bästa hypoteserna att bygga vidare på.
Mjukvara är kodifierad kunskap. Kunskap tas fram successivt i samspel mellan de som har pusselbitarna (verksamhet, IT, medborgarna). All erfarenhet av systemutveckling sedan 60-talet har pekat på att tätt samarbete mellan beställare och utförare där man tar fram lösningar löpande är det som snabbast och billigast tar en till målet. Det är det som måste vara vår mentala modell för hur systemutveckling ska bedrivas om vi verkligen vill säkerställa nyttohemtagning.
Inga kommentarer:
Skicka en kommentar