Appar i offentlig sektor

1,690 views

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,690
On SlideShare
0
From Embeds
0
Number of Embeds
603
Actions
Shares
0
Downloads
9
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Appar i offentlig sektor

  1. 1. Åtta skäl för appari offentlig sektorJonas SöderströminUse21 sep 2011
  2. 2. twitter #offentligapp @jonas_blind_henDagens hashtaggar på twitter. Det nedre är jag på twitter, om ni vill följa mig.
  3. 3. Jonas Söderström tagit framdigitala system sedan 1994
  4. 4. Jonas Söderström regeringen.se riksdagen.se Räddningsverket Konsumentverket Socialstyrelsen MSB FörsäkringskassanPensionsmyndigheten
  5. 5. Jag gav ut boken ”Jävla skitsystem! Hur en usel digital arbetsmiljö stressar oss på jobbet -och hur vi kan ta tillbaka kontrollen”.
  6. 6. Åtta skäl för apparSom jag ser det finns det en rad skäl för den offentliga sektorn att i större utsträckning tänka ”app”... ... och inte bara tänka ”webb”.
  7. 7. Fler kanaler –större uthållighet
  8. 8. (Snart...)vargklo / flickrNär det blir snö och oväder drabbas kollektivtrafiken av förseningar. Många människorbehöver då besked om tunnelbanan går, om bussarna kommer ...Bild: vargklo/flickr under CC-licens.
  9. 9. Vid sådana lägen blir belastningen på t ex SLs webbplats mycket stor. Det blir mycket svårtatt komma fram och få information.
  10. 10. Bakomliggande system WebbDet vore bättre, om vi i stället för en enda kanal har flera:
  11. 11. Bakomliggande system API Cache Molntjänst extern part Appar Appar WebbOm vi skapar ett API mot de bakomliggande systemen kan andra aktörer (men också, i ochför sig, myndigheten själv) utveckla appar som en annan kanal där informationen där tavägen ut.Vi får då inte all belastning i en kanal. Vi kan ha ett aggressivt cache som lagrarinformationen ur de bakomliggande systemen med bara en liten, i praktiken betydelselös,fördröjning. Men detta kan också minska belastningen på det bakomliggande systemetbetydligt. På klientsidan blir det också lättare, efter som vi till en app inte behöver skicka enhel 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 vilägger tjänsten externt, i molnet (eftersom vi inte alltid kan dimensionera vår drift för demest extrema situationerna).
  12. 12. Bakomliggande system API Cache Molntjänst Appar Appar Webb Push- notisYtterligare en poäng är att apparna kan ta emot pushnotiser. Information kan alltså nåmottagarna utan att de ens har applikationen igång.
  13. 13. SL har startat Trafiklab, med uttrycklig hänvisning till för att främja användandet av ochdiskussionen kring öppna APIer till verksamhetens system.
  14. 14. Peak-situationer • Självdeklaration • Ansökan till gymnasieskolan • Ansökan till universitetDet torde finnas många myndigheter och organisationer, som upplever peak-belastningarnågra gånger om året. Regelbundet läser vi också om sådant som att ”ansökningen tillhögskolan kraschade sista dagen för anmälan”. En app-strategi betyder fler kanaler, medökad redundans och uthållighet.
  15. 15. Kris-situationer • Vi har mobilen med oss när det är kris –  inte datornPeak-situationerna i förra bilden är väl förutsägbara. Andra är det inte. Också i krissituationerkan 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.
  16. 16. Smartphone-användare älskar appar
  17. 17. minuter/månad sms 671 använda appar 667 160% prata 531 surfa 422Har man en smartphone lägger man ner mer än 60 % mer tid på att använda appar, mot attsurfa på webb.
  18. 18. Fler interaktionsmöjligheter
  19. 19. Touch Ägarens kamera Ägarens bildbibliotek Läge (via accelerometer) Geografisk positionJä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 ochskriva text i formulär, som vi kan se i nästa exempel:
  20. 20. VAB-APPEN
  21. 21. Var det inte du som var hemma i förrgår? Näe ... det var väl du som Tog du ut semester eller tog ut en föräldradag? var det en VAB-dag? Nej - det var i torsdags. Menjag jobbade ju torsdagen i alla fall hemma och tog ledigt på fredagen i stället.
  22. 22. Tänk om det enkeltgick att hålla koll på dagarna?
  23. 23. Se filmen på http://www.youtube.com/watch?v=9IcwPVRZZwkRedan 2008 satte jag ihop ovanstående demo.Filmen går att se på http://www.youtube.com/watch?v=9IcwPVRZZwk
  24. 24. Case: FörsäkringskassanJag har en direkt, egen erfarenhet av detta. 2007 arbetade jag som interaktionsdesigner förFörsäkringskassans självbetjäningssystem - ”Mina sidor”. Bland annat arbetade jag med attförenkla ansökningarna för föräldrapenning och tilfällig föräldrapenning (VAB).
  25. 25. Interaktionsdesign: Begär TFP PA 06 26 Jonas Söderström Försäkringskassans självbetjäningstjänster 14 sep 2007 40 Steg1 Översikt Visar utseende av steg 1 för kund som är anställd. OBS: DennaI 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 stegett.
  26. 26. Interaktionsdesign: Begär TFP PA 06 27 Jonas Söderström Försäkringskassans självbetjäningstjänster 14 sep 2007 40 Ordinarie vårdnadshavare sjukStegtvå ...
  27. 27. ... och några prototyper med färg och form.
  28. 28. 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öratt bygga lösningen blev det, som ni vet - ett episkt tekniskt haveri. Och det på engrundläggande nivå - långt innan man över huvud taget började sätta samman de lösningarjag designat.Under lång tid var jag oerhört frustrerad. Jag var säker på att inget av det jag hade designatnågonsin skulle se dagens ljus.Till all lycka hade jag fel. Efter att ha reorganiserat verksamheten efter det tyska debacletbörjade Försäkringskassan sommaren 2010 lägga ut delar av det jag arbetat med - i förstaomgången ”Mina sidor”. Det ledde till att kassans webbplats av Internetworld hösten 2010korades till bästa myndighetswebbplats - med Mina sidor som främsta skäl.
  29. 29. KonkurrenstryckMen tänk om Försäkringskassan haft ett öppet API för inmatning av VAB? Då hade appenkunnat 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 somarbetar för medborgarna. Det skapas ett konkurrenstryck som snabbar på utvecklingen.
  30. 30. Myndighetens kärnverksamhet? lut! B esVad är egentligen myndigheternas kärnverksamhet? Att fatta beslut.
  31. 31. InmatningIdag är det regelmässigt endast myndigheterna som utvecklar sina inmatningssystem - t exför att ansöka om bygglov eller föräldrapenning eller något annat. Men att byggainmatningsformulär på webben ska inte vara myndigheternas kärnverksamhet.
  32. 32. Hade FK haft ett öppet API för inmatning ... 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änssnittetmåste släpas loss.Genom att definiera ett öppet API för t ex föräldrapenning - defineiera vilka uppgifter somska matas in - kan vem som helst bygga inmatningsgränssnitt. Vi skulle få en helt annatdynamik och snabbhet i att skapa användarvänliga tjänster.
  33. 33. InmatningMan 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 detsäkerligen någon som vill bygga det.Med all respekt: ingen myndighet kommer att kunna skapa tillräckligt användar-anpassadetjänster lika snabbt - utan externt hjälp. Och med konkurrenstryck kan vi se till attmeborgarna får den bästa tänkbara tjänsten. Om både SEB och Handelsbanken tävlar om attgöra en VAB-app; om både ByggMax och Rusta gör en bygglovsapp.
  34. 34. små sammanhängande enheterDet här är en filosofi som visat sig fungera - både kommersiellt och tekniskt. Appar ÄRvärldens snabbaste kommersiella it-framgång och snabbaste adoption. Små, oberoendeenheter ...
  35. 35. ... 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 smartphonekommunicerar data med varandra. Dessutom ska de ha likartad och igenkännlig interaktionoch gränssnitt för användaren, så det är lätt att skifta fram och tillbaka mellan dem.
  36. 36. UtbytbarhetI förlängningen gör också app-tänket att vi kan sträva mot sann modularitet - utbytbarhet avdelar av de sammanhängande systemen.
  37. 37. 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 kananvändas. Tänk om vi kunde jacka ur läkemedels-”modulen” från Cosmic och jacka inmotsvarande modul från TakeCare?Idag är det inte möjligt. I stället kostar det miljoner eller miljarder att byta HELAjournalsystemet i ett landsting.
  38. 38. Lättare att dela/sprida: SambrukRimligen skulle också ett ökat app-tänk göra det lättare att dela och sprida moduler/apparmellan aktörer. Appar utvecklade för en kommun bör vara enkla att använda i en annankommun.Om en lösningi stället ligger i kommunens webb, kan det vara svårare att lyfta över den till enannan kommuns webb; de kan ha olika cms och olika miljöer i sina webbplatser.
  39. 39. Snabbare projektRimligen går det också snabbare att utveckla små, enstaka appar ...
  40. 40. Offentlig sektor särkilt utsatt för snabba politiska förändringarDet är särskilt intressant för offentlig sektor, eftersom den är särskilt utsatt för snabbapolitiska 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.
  41. 41. 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, somgör en sak och gör den bra.
  42. 42. Typiskt exempel från verkligheten: ”...ett heltäckande PA- system vann överlägset i upphandlingen...” 10 månader senare avbryts projektet, systemet skrotas: ”...blev långt mer komplext än vi hade väntat...”Vi kan också se att det just är i dessa fall som vi får stora, spektakulära krascher. Jag har enhel samling av citat som det ovan:
  43. 43. 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.
  44. 44. 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, enligtbeställarna själva. Detta är siffrorna från Projektplatsens undersökning, publicerad 2007.
  45. 45. 18 procent av alla it-projekt är lyckade.Det betyder alltså att bara 18 % av projekten betecknas som lyckade - återigen, av beställarnasjälva.Det är chockerande låga siffror.
  46. 46. 42 %TIll och med bottenlaget i elitserien kom upp till 42 procent lyckade projekt - 23 vunnamatcher av 55.Om it-branschen vore ett hockeylag, skulle det varje år flyttas ner till en allt lägre serie, ochidag möjligen harva i division 5 eller 6.
  47. 47. 82 18 läggs ner på tid/ budget full funktion men ej men full över tid/ funktion budgetVad 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 allsvad man utlovat från början. I ytterligare cirka en fjärdedel levererade man den utlovadefunktionaliteten - men långt senare och/eller till en högre kostnad än beräknat.
  48. 48. ? procent gav avsedda 18 effekterMen det finns ytterligare ett märkligt förhållande. Låt oss sammantaget titta på de projektsom faktiskt levererade vad de skulle - både de som gick helt enligt plan, och de som blevdyrare/senare än beräknat. Hur många av dessa gav faktiskt de avsedda effekterna, ianvä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öjningman tänkt sig?
  49. 49. Nyttan – positiva effekter – av IT uppstår i användningen Om ingen använder dem, spelar det ingen roll hur fina funktioner systemet har. Jeremy Toeman/ FlickrDet ä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 vadanvändaren - dvs vi - vill göra. De rimmar inte med våra användningsmål.
  50. 50. Jeremy Toeman/ Flickr
  51. 51. Metoden Effektstyrning Effekter Mer effektiv ordermottagning ✘ # # tid/order -30 % misstag -60 % Mål- Order- grupper mottagare Vill ha färre ofullständiga Använd- # ordrar -75 % ofullständiga ningsmål ordrar Validering ✔ ✔ Förenkla orderformuläret Åtgärder ✔ ✔Det finns en etablerad metod som hjälper till att styra mot vekliga effekter, genom attfokusera på användarna (målgrupperna) och deras användningsmål. Metoden kallasEffektstyrning.
  52. 52. Det går att mäta ...Det är en vanlig missuppfattning att effekter av IT-projekt inte går att mäta.
  53. 53. E-delegationen: Modell för nyttorealiseringE delegationens modell för nyttorealisering är bra. Ladda ner den! Använd den!
  54. 54. ... man måste också styra!Men kom ihåg att man genom hela projektet måste fortsätta att styra mot de avseddaeffekterna. 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å?
  55. 55. Målgrupper i offentlig sektor Inte ”alla” - utan användningsmönster! Mål- grupperEftersom vi var ine på målgrupper i offentlig sektor: Det ger föga hjälp att säga attmålgruppen för en offentlig tjänst är ”alla”.
  56. 56. 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 ochbeteenden - i relation till de effekter ni själva vill uppnå.
  57. 57. Effekter Föj våra regler! ✘ Effekt- agenter behöver behöver vill fakta råd prataI 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 tretyper.
  58. 58. Dessutom: Vi måste förenkla regelverketYtterligare 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älvaregelverket för tjänsterna ofta groteskt komplicerade.
  59. 59. Till exempel: föräldraförsäkringen. Den är groteskt komplicerad. Den har två olikaersättningsnivåer - varav den ena är så låg att den är praktiskt oanvändbar. Nivåerna harolika antal dagar kopplade till sig, och regler för när och hur man tar ut dem. Pengarna kantas ut i många olika delar - t ex 75, 50, 25 % - men inte i procenttal som motsvarar att jobbatvå 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örklararegelverket.Jag vill poängtera att jag inte kritiserar Försäkringskassan. I själva veket har FK föreslagit fleraförenklingar av regelverket - som regeringen sagt nej till.Regelverket är komplicerat på grund av politiks beslut; ofta av politiker som vill få poäng hosytterligare någon särskild grupp.
  60. 60. Vältras över på användarnaMen nu skär vi ner förvaltningen, och utvecklar självservicetjänster. Men då vältrar vi överhanteringen av ett överkomplicerat regelverk på användarna. Tjänster som vi tidigare haftspecialiserade 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 dettapå användarna. Regelverken - t ex de sociala välfärdssystemen - måste bli enklare.
  61. 61. Läs mer på inUse hemsida: http://www.inuse.se
  62. 62. www.javlaskitsystem.se... och på http://www.javlaskitsystem.se
  63. 63. Finns att beställa hos nätbokhandlar (Adlibris, Bokus, Bokia m fl), samt hos AkademibokhandelnFinns att beställa hos nätbokhandlar (Adlibris, Bokus, Bokiam fl), samt hos Akademibokhandeln
  64. 64. ”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 intehade identifierat som ett problem tidigare ... ” Digitala Affärer
  65. 65. Jag föreläser på Kommit / Sambruk Göteborg 9 novemberJag föreläser på Kommit/Sambruk i Göteborg i november, på teman som anknyter till detta.
  66. 66. Tack! jonas.soderstrom@inuse.se Twitter: Jonas_Blind_Hen Slideshare: Jonas_inUse Sajt: www.javlaskitsystem.se Mobil: 073 660 32 14 Linked In: jonassoderstromkornetPhoto: 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

×