Polisens nya system har hittills kostat 300 miljoner kronor. ”Det är ett krångligt system, som är svårt att förstå. Det tar lång tid. Ju mindre tid vi är ute på gatan, desto mindre tid har ju vi att åka till folk som behöver vår hjälp…” säger en av de poliser som TV4 har intervjuat. Dagens sätt att utveckla system funkar inte, och leverantörerna borde skämmas.

Jag skrev en kort notis om detta när SVT berättade om problemen för någon vecka sedan. De råd jag gav i förra artikeln gäller så klart fortfarande, men nu när TV4 också har uppmärksammat nyheten vill jag komplettera med min bild av varför det ofta går åt skogen när man skall ta fram just ärendehanteringssystem.

Först. Och det här är så klart viktigt. Jag har inte sett Siebel PUST, som systemet heter, så alla reflektioner och slutsatser här nedan är generella, och handlar inte specifikt om PUST.

Generellt brukar det inte vara några större tekniska svårigheter när det gäller utveckling av ärendehanteringssystem. Problemet brukar istället vara de arbetssätt som man ofta använder sig av när man skall bestämma hur systemen skall se ut och fungera.

Ofta sitter man i olika former av referensgrupper och diskuterar fram beskrivningar av de processer som ärendena skall följa, och hur användargränssnitten då skall se ut.

Detta arbetssätt har aldrig fungerat, och kommer aldrig att fungera:

1. Att sätta sig i workshops och diskutera sig fram till hur ett visst arbete går till är omöjligt. Som människor kan vi inte utan vidare reflektera över vad vi faktiskt gör och hur vi gör det. Det är t.ex. därför som alla idrottsklubbar på hyggligt professionell nivå går igenom videoupptagningar från matcher. För att se vad som faktiskt händer, hur man verkligen spelar. Med detta som grund kan man sedan arbeta för att förbättra lagets prestation. För att vi som jobbar med design och utveckling av IT skall lyckas med göra bra system så måste vi göra motsvarande. Vi måste *observera* hur arbetet faktiskt går till för att förstå, och därefter beskriva det på ett sätt som gör det enkelt att utveckla bra systemstöd för arbetet. Det finns bra tekniker för detta, och det är varken svårt eller dyrt.
2. Design av användargränssnitt är inte en gruppaktivitet för entusiaster. Det är ett arbete som kräver oerhört mycket kompetens. I regel krävs det 4 år på högskola, och minst lika många år av intensiv praktisk erfarenhet innan man blir riktigt bra på det. Det här är inte ett område som kravanalytiker, projektledare eller utvecklare kan göra vid sidan av sitt ordinarie arbete. Inte heller är det något som kan överlåtas till användarna, så att de ”får det som de vill ha det”, lika lite som att man kan överlåta till någon som brukar gå på opera att designa ett nytt operahus. Det kan bli underhållande möten, och de som är med kommer att känna sig delaktiga, men resultatet blir så klart riktigt dåligt. Och i enlighet med jämförelsen med operahusets arkitekt så måste den som designat systemets användargränssnitt leda utvecklingsarbetet, inte fungera som vilken rådgivare som helst.
3. En övertro på processer leder nästan alltid till system som blir så stela att de inte går att använda. Många ärendehanteringssystem designas med för mycket styrning på för detaljerad nivå. A måste vara klart innan B får påbörjas, och för att A skall kunna bli klar så måste uppgift C fyllas i. Problemet är man ofta hamnar i en situation där man inte vet C, och inte kommer att få reda på det förrän om flera veckor, men behöver komma vidare till B. Den här situationen är inte ovanlig. I bästa fall slutar den med att användarna hittar olika sätt att komma runt problemen genom att skriva in felaktig data, som de förhoppningsvis kommer ihåg att rätta till senare. I sämsta fall leder det till att man vägrar använda systemet.

Den enda positiva bieffekt man får av att arbeta med referensgrupper för att beskriva hur man jobbar och hur ett system borde se ut är det man brukar kalla för ”förankring”. D.v.s. att de som varit med känner sig delaktiga, och därför kommer att ha mer tålamod med det nya systemet. Det, i sig självt, gör inte systemet bättre, men sannolikheten att få acceptans ökar. Detta är dock bara sant när verksamheten är så liten att en betydande andel av användarna faktiskt varit involverade. I praktiken innebär det att detta arbetssätt blir meningslöst också ur ett förankringsperspektiv för system med fler än ca 50 användare.

Varför är det då fortfarande så att framför allt stora systemutvecklingsprojekt så ofta går till på det här sättet?

Leverantörerna borde skämmas. De är inte korkade, de gör det här ofta. Men de tjänar bra med pengar på den befintliga modellen, och att ändra sitt sätt att tänka och arbeta är både jobbigt och kräver mod. Dagens modell ”fungerar” ju såtillvida att man genom förankringsarbete gentemot beslutsfattare och andra nyckelpersoner vinner förtroende och tar affärer. Man tjänar helt enkelt bra med pengar på dagens sätt att utveckla system, så varför skulle man vilja/våga ändra på det?

Skrivet av Johan Berndtsson. Läs fler inlägg om interaktionsdesign / målgruppsanalys / ärendehantering — 6 kommentarer