Involvera utövarna i behovsanalysen

Läget är allvarligt. Att döma av Unionens rapport om vilka de verkliga problemen med våra IT-system är så kan vi bli avsevärt bättre på att ta fram rätt IT-stöd för våra medarbetare. Tyvärr så visar svaren på hälften av frågorna att det blivit sämre ställt med det.

Det intressanta är att systemen ofta fungerar rent tekniskt. Funktioner finns och de fungerar för att göra allehanda uppgifter. Problemet är att systemen inte stödjer ett effektivt och ändamålsenligt arbetssätt. Det är inte rätt system.

Det är inte ovanligt att när ett projekt levererar så anses det framgångsrikt eftersom tekniska tester såväl som acceptanstester passerar. Tyvärr sker det ofta utan att i tillräcklig grad involvera utövarna och tillåta dem säga hur det borde vara. ”Visst kan inte allt bli perfekt”, blir oftast den inte så värdebringande slutsatsen att stänga ett projekt för att i förvaltningen försöka skruva om systemen efter feedback från användarna. Eller så får man leva med problemen för att pengarna är slut.

På detta sätt abdikerar man från de verkliga effektmålen och blundar för dolda kostnader i form av ineffektivitet och stress. I längden blir detta också ett arbetsmiljöproblem.

Typiskt har man bortsett från två avgörande framgångsfaktorer:

Behovsanalys

Detta omfattar en fördjupning i dagens arbetssätt och vilken förändring till ett nytt arbetssätt som är den bästa. Vanligtvis görs denna alldeles för ytligt och man underskattar utmaningen att formulera och förstå tjänstemännens arbetssätt.

Somliga kallar detta för verksamhetsanalys. Andra ser det som en naturlig del av kravarbetet som sker innan man försöker formulera några detaljerade systemkrav. Självklart tar vi först reda på hur verksamheten kan komma att arbeta mest effektivt innan vi börjar titta på potentiellt IT-stöd?

Lansering

När systemet är klart ska det föras in i verksamheten. Lanseringen utgör en pendang till behovsanalysen. Det omfattar förändringsledning och utbildning. Detta kan företrädelsevis initieras redan när ett projekt inleds men den riktiga förändringen i verksamheten är den som ska ske när systemet är klart och ska börja användas. Tyvärr har man sällan planerat för detta och delegerar ansvar för förändring och acceptans till enskilda medarbetare.

Att behovsanalysen brister beror kan bero på många olika saker. Ett axplock:

1. Ansvariga tror att de redan vet hur verksamheten arbetar.

Många ansvariga chefer vet faktiskt ofta inte alls hur tjänstemännen i praktiken arbetar eller vilka deras faktiska utmaningar är. En övergripande förståelse och kunskap om att det finns förbättringspotentialer är ungefär så mycket detaljer som en chef hinner med. De vet vanligtvis inte heller hur man på rätt sätt blottlägger, fångar in och formulerar förväntningar på arbetssätt.

Måste ansvariga chefer kunna detta? Nej, inte alls. En chef – eller ledare – behöver naturligtvis inte ha all detaljkunskap i varje ögonblick (men i så fall gärna vara ödmjukt medveten om just detta). Ledaren målar med de stora penseldragen och ska skapa förutsättningar. Detta betyder likväl att det är lämpligt att någon gör en klok behovsanalys. Företrädelsevis med de rätta och effektiva metoderna.

2. För lite tid ges för att reflektera över och förändra arbetssättet

Ingen medarbetare är 100% medveten om sitt eget arbetssätt eller hur det skulle kunna fungera bättre. Men det beror på att man inte getts utrymme till detta. Att involvera tjänstemännen när systemstöd ska utformas innebär att man sätter igång en process där de börjar reflektera över sitt arbetssätt.

Om analysen görs rätt så är det inte bara systemstödsdiskussionen som kommer i fokus utan en diskussion om vilket arbetssätt som är det bästa. Det blottlägger brister och otydligheter i organisationens arbetsprocesser som måste lösas innan man kan bygga något effektivt stöd för dem.

3. Behovs- och problemanalys ses som svårt, onödigt och tidsödande

Relaterat till föregående punkt är att man har bråttom och kanske dåliga erfarenheter av behovsanalys. Kanske vet man inte riktigt hur man ska göra. Misslyckanden kan bero på att man inte har haft rätt metodik. Det finns alldeles för få personer som kan och tillåts applicera rätt metoder i rätt sammanhang. Problemanalys handlar om att hitta och formulera rätt problem; problemlösning om att lösa ett av alla identifierade problem.

Om man förväntar sig lösningar och får fler problem att förhålla sig till så är det inte konstigt att man blir frustrerad. Man är otålig att ”komma vidare”. Ett problem har identifierats och det anses handlingskraftigt att snabbt lösa problemet. ”Vi är doers!”.

Men en väl utförd problemanalys blottlägger ofta andra problem. Inte sällan avslöjar man då att det redan identifierade problemet var det som var lättast att identifiera och lättast att lösa men som kostar för mycket och ger för liten effekt att lösa.

4. Fokuserar på systemlösningar för tidigt

Detaljer i ett befintlig eller ett nytt IT-system börjar analyseras långt innan man har en övergripande förståelse för hur man vill arbeta. Otålighet och oförmåga gör att man utgår från de lösningar man ser framför sig i stället för de utmaningar och problem som måste lösas. Man lyckas inte ta ett steg tillbaka och tappar således helhetsbild och effektmål.

Ofta finns det system eller koncept på marknaden som man ser att många andra företag använder och man går i fällan att tro att saken är så gott som klar eftersom det ”bara innebär mindre anpassningar”. Att rusa in i denna fälla är mer kostsamt och resulterar i sämre lösningar. Det blir ofta fler olyckliga anpassningar av användarna än av systemet med ineffektivitet och stress som resultat.

En bakomliggande orsak är också att man fokuserar på det system som man har makt att påverka i stället för att se på en medarbetares hela arbetssätt.

5. En övertro på leverantörer

En IT-leverantörs affärsmodell skiljer sig från beställarens. Leverantörer förutsätter att beställaren har full kunskap om sina behov samt kompetens att värdera den eller de lösningar som föreslås. Beställaren utgår från att leverantörerna tar fullt ansvar för att helheten kommer att fungera utifrån kundens behov.

Dessa olika perspektiv gör att leverantör och beställare inte talar samma språk vilket leder till ökade kostnader och misslyckanden. För att komma till rätta med detta kommunikationsproblem måste främst beställaren göra ett förarbete.

6. Misslyckat införande av nya utvecklingsmetoder

Med agila systemutvecklingsmetoder som Scrum och Kanban och förhållningssätt som ”knappt tillräckligt” så hittar man argument att inte göra så särskilt mycket analys innan utvecklingsprojektet kickas igång. Utvecklare och utövare ska ju dagligen kommunicera med varandra för att säkerställa kvalitet!

Åtminstone två misstag begås.

Det första misstaget är att indirekt lämna över den övergripande verksamhetsanalysen till ett projekt som ska bygga ett system. Det gör att projektet antingen misslyckas med att ge effektivt stöd i en arbetsprocess (som ingen har visualiserat) eller att det tar mycket längre tid eftersom man måste stanna upp och fundera på ”vad de verkliga kraven är” (för det har ingen på verksamhetssidan getts tid att tänka på). Då gör man det ofta fort och fel eftersom det är kostsamt att ha ett projekt igång.

Det andra misstaget är att inte göra rätt verksamhetsutövare tillgängliga. Det räcker inte med att ”avvara någon slutanvändare”. Det måste vara någorlunda erfarna verksamhetsutövare som har förmåga och tillåtelse att ifrågasätta systemlösningarna.

7. En övertro på utvecklares verksamhetskompetens.

I den bästa av världar har vi uteslutande briljanta arkitekter och programmerare som samtidigt har utmärkt kunskap och förståelse av affärs- eller verksamhetperspektivet. Sådana finns det några stycken av men de är alldeles för få.

Det krävs starka, erfarna individer som kan säkerställa att ett utvecklingsteam fokuserar på verksamhetsproblemen och försöker lösa dem i stället för att identifiera enstaka funktioner utan sammanhang eller ta fram tekniskt lättförvaltade system som är verksamhetsmässiga mardrömmar.

Det är tyvärr inte så lätt att sätta samman ett fantastiskt utvecklingsteam. Man hamnar snarare lätt i fenomen som ”funktionell nedbrytning” vilket ger just de system i vilka funktionerna i bästa fall fungerar i isolering men som tillsamman inte stödjer ett effektivt arbetssätt.

Lösningen!

Lösningen på ovanstående är enkel att föreslå men uppenbarligen svår att lyckas med: stanna upp och lägga rätt tid och energi på behovs- och problemanalys innan ni bestämmer sig för en viss typ av lösning.

Detta kan åstadkommas av en analytiker med rätt profil tillsammans med rätt representanter från verksamheten. Arbetet tar 3-9 månader beroende på komplexiteten i verksamhetsområdet (det brukar underskattas). Visar det sig att det finns bakomliggande organisatoriska utmaningar så kommer arbetet ta en annan riktning. Oavsett utfall kommer investeringen att vara ovärderlig.

Så målet är att beslutsfattare såväl som tjänstemän är på det klara med varför systemen ska finnas och hur dessa på bästa sätt ska vara utformade. Det går bara att lösa genom att involvera utövarna.

Som chef över en verksamhet får du fundera på om du ska göra det fort och fel nu och ta de dolda kostnaderna av ineffektivt systemstöd, stressade medarbetare och minskade intäkter. Eller om du göra det bättre och lika billigt genom att stanna upp och använda effektivare metoder.