appar i offentlig sektor

Åtta skäl för appar i offentlig sektor

Jonas SöderströminUse

21 sep 2011

#offentligapp

@jonas_blind_hen

twitter

Dagens hashtaggar på twitter. Det nedre är jag på twitter, om ni vill följa mig.

Jonas Söderström

tagit fram digitala system

sedan 1994

regeringen.se

riksdagen.se

Konsumentverket

Socialstyrelsen

Försäkringskassan

Räddningsverket

Pensionsmyndigheten

MSB

Jonas Söderström

Jag gav ut boken ”Jävla skitsystem! Hur en usel digital arbetsmiljö stressar oss på jobbet - och hur vi kan ta tillbaka kontrollen”.

Åtta skäl för appar Som jag ser det finns det en rad skäl

för den offentliga sektorn atti större utsträckning tänka ”app”...

... och inte bara tänka ”webb”.

Fler kanaler –större uthållighet

(Snart...)

vargklo / flickr

När det blir snö och oväder drabbas kollektivtrafiken av förseningar. Många människor behöver då besked om tunnelbanan går, om bussarna kommer ...

Bild: vargklo/flickr under CC-licens.

Vid sådana lägen blir belastningen på t ex SLs webbplats mycket stor. Det blir mycket svårt att komma fram och få information.

Bakomliggande system

Webb

Det vore bättre, om vi i stället för en enda kanal har flera:

Bakomliggande system

Webb

API

Cache

Molntjänst

Appar Apparextern part

Om vi skapar ett API mot de bakomliggande systemen kan andra aktörer (men också, i och för sig, myndigheten själv) utveckla appar som en annan kanal där informationen där ta vägen ut.Vi får då inte all belastning i en kanal. Vi kan ha ett aggressivt cache som lagrar informationen ur de bakomliggande systemen med bara en liten, i praktiken betydelselös, fördröjning. Men detta kan också minska belastningen på det bakomliggande systemet betydligt. På klientsidan blir det också lättare, efter som vi till en app inte behöver skicka en hel webbsida för varje svar, utan bara precis den specifika informationen.Poängen är också att det är lättare att snabbat skala upp för den ökande belastningen, om vi lägger tjänsten externt, i molnet (eftersom vi inte alltid kan dimensionera vår drift för de mest extrema situationerna).

Bakomliggande system

Webb

API

Cache

Molntjänst

Appar ApparPush-notis

Ytterligare en poäng är att apparna kan ta emot pushnotiser. Information kan alltså nå mottagarna utan att de ens har applikationen igång.

SL har startat Trafiklab, med uttrycklig hänvisning till för att främja användandet av och diskussionen kring öppna APIer till verksamhetens system.

Peak-situationer• Självdeklaration

• Ansökan till gymnasieskolan

• Ansökan till universitet

Det torde finnas många myndigheter och organisationer, som upplever peak-belastningar några gånger om året. Regelbundet läser vi också om sådant som att ”ansökningen till högskolan kraschade sista dagen för anmälan”. En app-strategi betyder fler kanaler, med ökad redundans och uthållighet.

Kris-situationer• Vi har mobilen med oss när det är kris – 

inte datorn

Peak-situationerna i förra bilden är väl förutsägbara. Andra är det inte. Också i krissituationer kan appar vara att föredra. Typiskt i en kris, att människor har med sig och använder (försöker använda) sina mobiler; de har inte sina laptops.

Smartphone-användare älskar appar

sms 671

använda appar 667

prata 531

surfa 422

minuter/månad

160%

Har man en smartphone lägger man ner mer än 60 % mer tid på att använda appar, mot att surfa på webb.

Fler interaktionsmöjligheter

Touch

Ägarens kamera

Ägarens bildbibliotek

Läge (via accelerometer)

Geografisk position

Jämfört med webb kan vi i en (native) app enkelt erbjuda mycket fler interaktionsmöjligheter. Touchstyrning, appen kan interagera med telefonens kamera och ägarens bildbibliotek, geopositionering och läge.

Touch och bild ger särskilt många nya möjligheter till interaktion, bortom att fylla i fält och skriva text i formulär, som vi kan se i nästa exempel:

VAB-APPEN

Näe ... det var väl du som tog ut en föräldradag?

Var det inte du som var hemma i

förrgår?Tog du ut semester eller

var det en VAB-dag?

Nej - det var i torsdags. Men jag jobbade ju torsdagen i alla fall

hemma och tog ledigt på fredagen i stället.

Tänk om det enkelt gick att hålla koll på

dagarna?

Se filmen på http://www.youtube.com/watch?v=9IcwPVRZZwk

Redan 2008 satte jag ihop ovanstående demo.Filmen går att se på http://www.youtube.com/watch?v=9IcwPVRZZwk

Case:Försäkringskassan

Jag har en direkt, egen erfarenhet av detta. 2007 arbetade jag som interaktionsdesigner för Försäkringskassans självbetjäningssystem - ”Mina sidor”. Bland annat arbetade jag med att förenkla ansökningarna för föräldrapenning och tilfällig föräldrapenning (VAB).

14 sep 2007

Interaktionsdesign: Begär TFPJonas Söderström Försäkringskassans självbetjäningstjänster

PA 06

40

26

Steg1ÖversiktVisar utseende av steg 1 för kund som är anställd.

OBS: Denna

I dag har flödet för Föräldrapenning upp till nio steg. Jag tog ner det till tre och förenklade interaktion och gränssnitt. Här ser ni steg ett.

14 sep 2007

Interaktionsdesign: Begär TFPJonas Söderström Försäkringskassans självbetjäningstjänster

PA 06

40

27

Ordinarie vårdnadshavare sjuk

Steg två ...

... och några prototyper med färg och form.

Våra skisser och prototyper testades och fick mycket höga betyg. Men när Försäkringskassans dåvarande ledning beslöt att använda ett tyskt affärssystem för att bygga lösningen blev det, som ni vet - ett episkt tekniskt haveri. Och det på en grundläggande nivå - långt innan man över huvud taget började sätta samman de lösningar jag designat.

Under lång tid var jag oerhört frustrerad. Jag var säker på att inget av det jag hade designat någonsin skulle se dagens ljus.

Till all lycka hade jag fel. Efter att ha reorganiserat verksamheten efter det tyska debaclet började Försäkringskassan sommaren 2010 lägga ut delar av det jag arbetat med - i första omgången ”Mina sidor”. Det ledde till att kassans webbplats av Internetworld hösten 2010 korades till bästa myndighetswebbplats - med Mina sidor som främsta skäl.

Konkurrenstryck

Men tänk om Försäkringskassan haft ett öppet API för inmatning av VAB? Då hade appen kunnat vara verklighet redan 2008!Poängen här är att öppna APIer och apptänk gör det möjligt för fler att utveckla system som arbetar för medborgarna. Det skapas ett konkurrenstryck som snabbar på utvecklingen.

Beslut!

Myndighetens kärnverksamhet?

Vad är egentligen myndigheternas kärnverksamhet? Att fatta beslut.

Inmatning

Idag är det regelmässigt endast myndigheterna som utvecklar sina inmatningssystem - t ex för att ansöka om bygglov eller föräldrapenning eller något annat. Men att bygga inmatningsformulär på webben ska inte vara myndigheternas kärnverksamhet.

Inmatning

Hade FK haft ett öppet API för inmatning ...

... hade demon kunnat vara verklighet redan 2008.

Myndigheternas kärnverksamhet är att ta emot data och verifiera att de stämmer: personnummer, datum, fastighetsbeteckning etc. Att bygga själva inmatningsgränssnittet måste släpas loss. Genom att definiera ett öppet API för t ex föräldrapenning - defineiera vilka uppgifter som ska matas in - kan vem som helst bygga inmatningsgränssnitt. Vi skulle få en helt annat dynamik och snabbhet i att skapa användarvänliga tjänster.

Inmatning

Man skulle till och med kunna anmäla VAB via en Kinetic, via en Kindle eller en Nintendo Wii - eller vilka nya maskiner som dyker upp på marknaden. Om det finns ett behov, finns det säkerligen någon som vill bygga det.

Med all respekt: ingen myndighet kommer att kunna skapa tillräckligt användar-anpassade tjänster lika snabbt - utan externt hjälp. Och med konkurrenstryck kan vi se till att meborgarna får den bästa tänkbara tjänsten. Om både SEB och Handelsbanken tävlar om att göra en VAB-app; om både ByggMax och Rusta gör en bygglovsapp.

små sammanhängande enheter

Det här är en filosofi som visat sig fungera - både kommersiellt och tekniskt. Appar ÄR världens snabbaste kommersiella it-framgång och snabbaste adoption. Små, oberoende enheter ...

... med gränssnitt och interaktion standardiserade.

En förutsättning är att enheterna ska kommunicera med varandra på ett standardiserat sätt, så att inloggning och informationsutbyte sker enkelt. Så som två appar på din smartphone kommunicerar data med varandra. Dessutom ska de ha likartad och igenkännlig interaktion och gränssnitt för användaren, så det är lätt att skifta fram och tillbaka mellan dem.

Utbytbarhet

I förlängningen gör också app-tänket att vi kan sträva mot sann modularitet - utbytbarhet av delar av de sammanhängande systemen.

E-journalsystem för vården

• På barncancer-avdelningen vågar man inte använda systemet för att hålla reda på cytostatika

• Så svårarbetat att risken för dödliga misstag är oacceptabel

• Problem under många årI ett par e-journalsystem för vården är t ex läkemedelsdelen så dålig att den inte kan användas. Tänk om vi kunde jacka ur läkemedels-”modulen” från Cosmic och jacka in motsvarande modul från TakeCare? Idag är det inte möjligt. I stället kostar det miljoner eller miljarder att byta HELA journalsystemet i ett landsting.

Lättare att dela/sprida:Sambruk

Rimligen skulle också ett ökat app-tänk göra det lättare att dela och sprida moduler/appar mellan aktörer. Appar utvecklade för en kommun bör vara enkla att använda i en annan kommun. Om en lösningi stället ligger i kommunens webb, kan det vara svårare att lyfta över den till en annan kommuns webb; de kan ha olika cms och olika miljöer i sina webbplatser.

Snabbare projekt

Rimligen går det också snabbare att utveckla små, enstaka appar ...

Offentlig sektor särkilt utsatt för snabba politiska förändringar

Det är särskilt intressant för offentlig sektor, eftersom den är särskilt utsatt för snabba politiska vindkantringar. Ett långt projekt riskerar alltid att leverera sub-optimala resultat, just på grund av vad som händer i omvärlden under tiden.

En misslyckad app kan inte kosta 800 miljoner

... och det här är därför ett sammanhängande skäl till att satsa på enkla applikationer, som gör en sak och gör den bra.

”...ett heltäckande PA-system vann överlägset i

upphandlingen...”

”...blev långt mer komplext än vi hade väntat...”

10 månader senare avbryts projektet, systemet skrotas:

Typiskt exempel från verkligheten:

Vi kan också se att det just är i dessa fall som vi får stora, spektakulära krascher. Jag har en hel samling av citat som det ovan:

Det finns en elefant i rummet ...

... som vi inte talar om.I diskussioner om it-lösningar och nya system finns det något som man sällan talar om. En ”elefant i rummet”, som man inte låtsas om.

82

procent av alla it-projekt är misslyckade,enligt beställarna själva.

Elefanten kan uttryckas så här. 82 procent av alla it-projekt i Sverige är misslyckade, enligt beställarna själva. Detta är siffrorna från Projektplatsens undersökning, publicerad 2007.

18

procent av alla it-projekt är lyckade. Det betyder alltså att bara 18 % av projekten betecknas som lyckade - återigen, av beställarna själva. Det är chockerande låga siffror.

42 %TIll och med bottenlaget i elitserien kom upp till 42 procent lyckade projekt - 23 vunna matcher av 55.Om it-branschen vore ett hockeylag, skulle det varje år flyttas ner till en allt lägre serie, och idag möjligen harva i division 5 eller 6.

82

läggs ner på tid/budget men ej

fullfunktion

fullfunktion

men över tid/budget

18

Vad betyder då ”misslyckat”?Av de som misslyckade klassade projekten, lades ungefär hälften ner, utan att någoting alls åstadkoms. Ungefär en fjärdedel lyckades man i alla fall leverera någonting - men inte alls vad man utlovat från början. I ytterligare cirka en fjärdedel levererade man den utlovade funktionaliteten - men långt senare och/eller till en högre kostnad än beräknat.

?procent gav

avsedda effekter18

Men det finns ytterligare ett märkligt förhållande. Låt oss sammantaget titta på de projekt som faktiskt levererade vad de skulle - både de som gick helt enligt plan, och de som blev dyrare/senare än beräknat. Hur många av dessa gav faktiskt de avsedda effekterna, i användning?Projektmåttet berättar bara ju om PROJEKTET gick i mål eller inte? Vad hände sedan? Innebar det levererade systemet den besparing, eller effektivisering, eller kvalitetshöjning man tänkt sig?

Om ingen använder dem, spelar det ingen rollhur fina funktioner systemet har.

Jere

my

Toem

an/

Flic

kr

Nyttan – positiva effekter – av IT uppstår i användningen

Det är en självklarhet som ofta glöms bort: funktionerna ger bara nytta om någon verkligen använder dem. Förmodligen har många av er en sådan här hemma. Ni använder förmodligen en oerhört liten del av de knappar som finns på dem. Alla de oanvända funktionerna är bortslösade investeringar.Ett projekt som levererat all denna funktionalitet kan vara lycket - med avseende på PROJEKTET - men ändå misslyckat, i det att de inte används.

Skälen till att de inte används kan vara flera. Ett är att de är dåligt utformade. Men lika gärna kan det vara så att de helt enkelt inte är anpassade till vad användaren - dvs vi - vill göra. De rimmar inte med våra användningsmål.

Jere

my

Toem

an/

Flic

kr

✘

Använd-ningsmål

#

# tid/order -30 %

misstag -60 %Effekter

Mål-grupper

# ofullständiga ordrar -75 %

Mer effektiv ordermottagning

Order-mottagare

Vill ha färre ofullständiga

ordrar

Åtgärder✔ ✔

✔ ✔

Förenkla orderformuläretValidering

Metoden Effektstyrning

Det finns en etablerad metod som hjälper till att styra mot vekliga effekter, genom att fokusera på användarna (målgrupperna) och deras användningsmål. Metoden kallas Effektstyrning.

Det går att mäta ...

Det är en vanlig missuppfattning att effekter av IT-projekt inte går att mäta.

E-delegationen:Modell för nyttorealisering

E delegationens modell för nyttorealisering är bra. Ladda ner den! Använd den!

... man måste också styra!Men kom ihåg att man genom hela projektet måste fortsätta att styra mot de avsedda effekterna. Projekt avviker alltid från sin planerade bana. Det är då man måste hålla i minnet: vilka effekter var det vi egentligen ville uppnå?

Mål-grupper

Målgrupper i offentlig sektor

Inte ”alla” - utan användningsmönster!

Eftersom vi var ine på målgrupper i offentlig sektor: Det ger föga hjälp att säga att målgruppen för en offentlig tjänst är ”alla”.

Människor med likartade behov, förväntningar och beteende när man använder tjänsten.

Mer fruktbart är att se till likheter och skillnader i människors behov, förväntningar och beteenden - i relation till de effekter ni själva vill uppnå.

✘Föj våra regler!Effekter

Effekt- agenter

behöver fakta

behöver råd

villprata

I ett arbete för Socialstyrelsen var det övergripande målet ”ökad följsamhet mot regelverket”. Efter en undersökning av användarna kom vi fram till att de kunde delas upp i dessa tre typer.

Dessutom: Vi måste förenkla

regelverket

Ytterligare ett memento: Som designer kan jag försöka göra enkla och intuitiva system - fjärrkontroller med färre och enklare knappar. Men inom offentliga sektorn är själva regelverket för tjänsterna ofta groteskt komplicerade.

Till exempel: föräldraförsäkringen. Den är groteskt komplicerad. Den har två olika ersättningsnivåer - varav den ena är så låg att den är praktiskt oanvändbar. Nivåerna har olika antal dagar kopplade till sig, och regler för när och hur man tar ut dem. Pengarna kan tas ut i många olika delar - t ex 75, 50, 25 % - men inte i procenttal som motsvarar att jobba två eller tre dagar av fem, så som de flesta pusslar ihop sina föräldraledigheter. Och så vidare. Bilden ovan visar en liten del av de sidor Försäkringskassan behöver för att förklara regelverket.Jag vill poängtera att jag inte kritiserar Försäkringskassan. I själva veket har FK föreslagit flera förenklingar av regelverket - som regeringen sagt nej till.Regelverket är komplicerat på grund av politiks beslut; ofta av politiker som vill få poäng hos ytterligare någon särskild grupp.

Vältras över på användarna

Men nu skär vi ner förvaltningen, och utvecklar självservicetjänster. Men då vältrar vi över hanteringen av ett överkomplicerat regelverk på användarna. Tjänster som vi tidigare haft specialiserade administratörer som hanterat som en del av sitt yrke.

Vi kan förenkla till en viss gräns - men bara så långt. Det är inte rimligt att lämpa över detta på användarna. Regelverken - t ex de sociala välfärdssystemen - måste bli enklare.

Läs mer på inUse hemsida: http://www.inuse.se

www.javlaskitsystem.se

... och på http://www.javlaskitsystem.se

Finns att beställa hos nätbokhandlar (Adlibris, Bokus, Bokia m fl),

samt hos Akademibokhandeln

Finns att beställa hos nätbokhandlar (Adlibris, Bokus, Bokia m fl), samt hos Akademibokhandeln

”En ögonöppnare ... en ny syn på arbetsmiljö” suntliv.nu

”Årets bästa svenska bok om IT”Web Usability

”Borde läsas av alla arbetsgivare och IT-utvecklare”Västerviks-Tidningen

”sätter ord på något som faktiskt många inte hade identifierat som ett problem tidigare ... ”

Digitala Affärer

Jag föreläser på Kommit / SambrukGöteborg 9 november

Jag föreläser på Kommit/Sambruk i Göteborg i november, på teman som anknyter till detta.

jonas.soderstrom@inuse.se

Twitter:Jonas_Blind_Hen

Slideshare:Jonas_inUse

Sajt:www.javlaskitsystem.se

Mobil:073 660 32 14

Linked In:jonassoderstromkornet

Tack!

Photo: Björn Falkevik

Mail: jonas.soderstrom@inuse.se

Twitter: Jonas_Blind_Hen

Slideshare: Jonas_inUse

Sajt: www.javlaskitsystem.se

Mobil: 073 660 32 14

Linked In: jonassoderstromkornet