Utbildning #2 - Ineras app-strategi

REVISION GODKÄND

Inledning

Syfte: Gå igenom denna utbildning för att lära dig om Ineras app-strategi.

Målgrupp: VD, avdelningschefer, sektionschefer, projektledare, affärsområdesansvariga, tjänsteområdesansvariga, chefsarkitekt - samt namngivna som dessa bjuder in.

Instruktion för användning: Hur jobbar Inera med appar? När du gått igenom denna utbildning kommer du att ha lärt dig

• bedöma när appar skulle kunna ge mervärden i Ineras tjänster och i så fall med vilka konsekvenser

• hur appar hanteras i Ineras processer Hantera Behov (beredning/utveckling) och Tjänstehandboken (förvaltning)

• hur Inera utvecklas till app-kompetent organisation genom utveckling och förvaltning av app-strategin

WORK IN PROGRESS - Arbete kvar längst ned (generellt om app-strategin) -och- idé: låt de 8 stegen i flödet vara ett steg ned i hierarkin, accessa genom att klicka på varje bubbla i flödet.

Bakgrund

I utbildning #1, Varför app?, har du lärt dig vad appar är, vilka för- och nackdelar de har jämfört med webbappar och lite om hur man utvecklar och distribuerar appar. Detta är en lämplig bakgrund för att kunna tillgodogöra sig Ineras app-strategi. Du behöver också känna till hur Inera tar fram och förvaltar tjänster - det vill säga /wiki/spaces/UtvR/pages/2471166600och Tjänstehandboken (under revision).

Ineras app-strategi

Ineras app-strategi är ett steg mot att göra Inera till en app-kompetent organistion. På sikt kommer Inera att kunna bedöma

• när appar är bättre lämpade än annan teknik för att skapa värdefulla tjänster

• vilka konsekvenser appar ger på tjänstens livscykel - i Utvecklingsramverket och Förvaltningshandboken

För att uppnå en position där kompetens och process för appar är helt integrerat i verksamheten tas ett viktigt steg i denna utbildning om Ineras app-strategi.

Upplägg

I denna utbildning illustreras Ineras app-strategi genom att en tänkt app-baserad tjänst följs från ursprunglig idé till lanserad tjänst som gått i förvaltning.

Detta är ett illustrerande exempel som pedagogiskt grepp - inte ett nödvändigt flöde för att ta fram en app-baserad tjänst. Varje tjänsteidé är unik och förtjänar en anpassad process inom ramen för /wiki/spaces/UtvR/pages/2471232501.

Efter genomgång av det illustrerande exemplet beskrivs app-strategin generellt. Dessutom beskrivs hur app-strategin är tänkt att förvaltas, utvecklas och slutligen avvecklas när Inera är en app-kompetent organisation.

Appar på Inera 2021

Inera har redan då detta skrivs tre app-baserade tjänster i drift. Det finns alltså redan historik och erfarenheter i organisationen som förtjänar en kortare genomgång.

1177 Vårdguiden

Appen 1177 vårdguiden upphandlades och utvecklades ursprungligen av en region. Appen övergick sedan till Inera för förvaltning.

SITHS eID

SITHS eID är app som tillsammans med ett antal bakomliggande serverkomponenter utgör en ny inloggninslösning för inloggning med SITHS e-legitimation på kort och som även möjliggör Utfärdande och inloggning med Mobilt SITHS.

SITHS eID har upphandlats av Inera och utvecklas av en underleverantör. En revision av tjänsten pågår i skrivande stund.

UMO

Umo.se är en webbplats om sex, hälsa och relationer för unga mellan 13 och 25 år. (Finns en UMO-app?)

Illusterande case - tidbokningsapp

För att illustrera en tänkbar användning av Ineras app-strategi använder vi ett fiktivt case. På ett komprimerat sätt följer vi detta case från idé till lanserad tjänst med fokus på huruvida tjänsten skall realiseras som en app.

Case

Inera får önskemål från flera regioner om att skapa en app som kan användas för att boka tider nationellt för kommande pandemier. Det rör sig om bokning av vaccination och provtagning.

Arbetet inleds

Tjänsteutveckling på Inera följer /wiki/spaces/UtvR/pages/2471166600och processen /wiki/spaces/UtvR/pages/2471232501. Då regionerna är av uppfattningen att en app förmodligen skulle ge goda förutsättningar för en lyckad tjänst kan Inera använda app-strategin för att undersöka konsekvenserna av att välja en app-baserad tidbokningstjänst.

App-strategin i case

Steg 1 - utvärdering av app-initiativ

Då det finns ett önskemål från kunden (Regionerna) att realisera tidsbokningstjänsten som en app kan Inera tidigt undersöka förutsättningarna för detta genom en del av app-strategin: Utvärdering av app-initiativ.

Utvärdering av app-initiativ är den enda delen av app-strategin som är en egen delprocess. Som sådan behöver beslutsfattare initiera utvärderingen och är också mottagare för det resulterande beslutsunderlaget. Resten av app-strategin är integrerad i utvecklingsramverkets del-processer/aktiviteter.

Denna utvärdering är en riskanalys som går igenom risker med stora konsekvenser om en tjänst skulle realiseras med en app. Syftet med denna riskanalys är att med en begränsad insats tidigt fånga graverande skäl vid användning av en app i tjänsten.

Riskanalysen använder en frågelista som på ett överskådligt sätt presenterar svaren så att de kan användas som beslutsunderlag. Svaren på varje fråga kan vara

• - OK att gå vidare processen!

• 😡 - Ej OK att gå vidare!

• 🔎 - vidare utredning behövs - dock inte nödvändigt att slutföra denna specifika utredning i detta skede

Om beslutsunderlaget enbart visar och 🔎 kan den app-baserade tjänsten gå vidare i processen Hantera Behov. 🔎 kan då utredas ytterligare i senare steg i processen.

Om beslutsunderlaget resulterar i en eller flera 😡 så kan man till exempel

• gå vidare i processen utan att realisera tjänsten med en app

• studera om förutsättningarna för tjänsten kan förändras så att diskvalificerande skäl kan undvikas

För vårt fiktiva case med tidbokningsapp antar vi här att beslutsunderlaget visar att processen kan gå vidare med att realisera tjänsten som en app men att ytterligare utredning 🔎 krävs kring om/hur appen kan

• integreras i befintlig 1177-app

• förvaltas efter lansering med avseende på den kompetens och större insats som krävs för appar

Steg 2 - Juridisk förberedelse - inför utredning vid app-initiativ

Appar har egenskaper som kräver speciell uppmärksamhet när man studerar de juridiska förutsättningarna för en tjänst. En juridisk utredning genomförs av specialister enligt de unika förutsättningar som finns för varje enskild tjänst.

Som ett stöd för de utredare som studerar tidboknings-appen finns i app-strategin förberedande tips inför en ev juridisk utredning.

Tipsen bygger på en frågelista med typiska frågeställningar som kan vara viktiga vid en juridisk utredning. Genom att gå igenom dessa frågor blir man som utredare bättre förberedd för denna utredning.

I vårt fiktiva case leder den juridiska utredningen till två konsekvenser att ta hänsyn till i vidare utredning:

• det finns tidbokningsappar i drift i marknaden - finns samordningsmöjligheter?

• tjänsten förutsätter inloggat läge (BankID) - korrekt hantering av personuppgifter krävs

Steg 3 - Nyttorealisering och effekthemtagning

Värdet i en tjänst kan beräknas med en Nyttokalkyl. I stort är nyttokalkylen oberoende av vilken teknik som används för realisering av tjänsten.

Appar ger dock förutsättningar att realisera tjänsten på ett sätt som höjer nyttan av tjänsten. App-strategin föreslår ett antal områden där det finns potential att höja nyttan av tjänsten - läs mer här.

I vår fiktiva tidbokningstjänst ser vi några nyttor för medborgaren som gör tjänsten mer värdefull som app:

• enklare att logga in med BankID via app som redan finns på telefonen (tidsbesparing)

• enklare att lägga gjord bokning i sin kalender (tidsbersparing och trygghet)

• användning av push-notiser för att påminna om, förbereda för eller vid förändringar av bokningen (trygghet och frigjord tid i vården pga färre missade tider samt fler och bättre förberedda besökare)

• möjligt att hitta till besöksadressen med navigationsapp direkt från push-notis (tidsbesparing/trygghet)

Steg 4 - Digital Tillgänglighet

Digital tillgänglighet är lagstadgad för offentliga digitala tjänster. I stort sett är kraven likadana för appar och webbappar. Inera har utöver detta en egen kravbild för digital tillgänglighet - mer om detta här.

De som utvecklar app-plattformar (Google och Apple) erbjuder dock verktyg för digital tillgänglighet som går utöver lagstadgade och Ineras krav. Detta ger tjänsten ökad tillgänglighet med hjälp av Apples, Googles och tredje parts tillgänglighetsverktyg för appar. Här finns app-strategins stöd för digital tillgänglighet.

För tidbokningsappen görs inga speciella noteringar kring digital tillgänglighet. Dock är detta första gången som en app kvalitetssäkras mot WCAG 2.1 varför Nordic Medtest behöver en något större insats.

Steg 5 - User Experience

UX är annorlunda för appar än för webbappar. Av nödvändighet - appen är kod som exekverar direkt ovanpå telefonens/surfplattans operativsystem medan webbappen exekverar i en webbläsare. Denna skillnad ger också utvecklaren större möjligheter att skapa exakt den UX man eftersträvar.

Detta innebär att Inera måste hantera UX annorlunda för appar. App-strategin ger stöd för detta här. Bland annat krävs annorlunda och ytterligare insatser kring

• UX-Krav för tredjepartsleverantörer

• Appspecifika komponenter

• Gestures för mobila applikationer

• Appikoner

• Dark mode

För bokningsappen innebär detta möjlighet att skapa bättre UX än för en webbapp dock med en ökad insats. Om bokningsappen utgår från en kommersiellt tillgänglig produkt (“off-the-shelf”) måste man försäkra sig om att denna kan uppfylla Ineras krav på digital tillgänglighet, UX och exponering av varumärke.

Steg 6 - Utveckling

I utbildning 1 har du lärt dig de grundläggande skillnader som finns mellan appar och webbappar och vilka olika sorters appar som är vanliga - native, cross-platform och hybridappar.

Utveckling av appar kräver annan kompetens/andra utvecklare än webbappar. Dessutom behövs en större insats - appar utvecklas för två olika plattfomar (Android och iOS). Om man väljer att utveckla native appar betyder detta att man utvecklar och underhåller två helt separata kodbaser. Genom att utveckla sin app cross-platform har man (i stort) en kodbas. Här finns app-strategins beslutsstöd för utveckling av appar.

Kompetensbasen för app-utveckling är i skrivande stund smalare än för webbappar vilket ger ett mindre urval av utvecklare (för anställning likväl som vid upphandling) vilket påverkar ledtid/kvalitet/kostnad.

För tidbokningsappen väljer vi att basera den på en tillgänglig produkt. Detta innebär att kraven från UX (ovan) på en tredjepartsprodukt blir aktuella. För att Inera skall kunna förvalta och vidareutveckla appen krävs dessutom insikt i appens natur - arkitektur, utvecklingsverktyg, licenser - och tydliga avtalsvillkor med leverantören för att kunna hantera appen under tjänstens tänkta livscykel.

Steg 7 - Test och kvalitetssäkring

Webbappar uppträder likadant i moderna versioner av populära webbläsare. Om webbappen är responsiv spelar inte skärmens storlek och orientering någon större roll för tjänstens utseende och beteende. Äldre versioner av webbläsare kan fungera sämre - varje webbapp bör specificera lägsta version som krävs för tjänsten.

För appar är bilden mer komplex. Dels exekverar appar på två olika operativsystem - Android och iOS. Dels så finns apparater (telefoner och surfplattor) i en variation av storlekar och versioner som dessutom kan köra vitt skilda versioner av operativsystemen. Skall tjänsten vara tillgänglig och likvärdig på pappas Samsung Galaxy S7 från 2016 likväl som på dotterns nya iPhone 13?

Specifikation för vilka versioner av Android och iOS som tjänstens appar kräver blir avgörande för insatsen som krävs för test och kvalitetssäkring. Genom att enbart specificera nyare versioner blir insatsen både för utveckling och test lägre. Samtidigt kommer man att nå en mindre marknad med tjänsten - de med äldre versioner av operativsystem kommer inte åt tjänsten. Eventuellt kan pappa uppgradera sin S7a till Android 8.0 och på så vis få tillgång till tjänsten - men denna typ av krav på handhavande skapar en tröskel.

Här finns app-strategins stöd vid Test och kvalitetssäkring av appar - framtagen av Nordic Medtest.

En ytterligare komplexitet tillkommer i och med att Google och Apple årligen släpper nya versioner av sina operativsystem. Ofta krävs uppdateringar av koden för appen för att tjänsten skall stödja telefoner med den nya versionen. När appen uppdaterats krävs en aktiv handling från användaren för att ladda ned den nya versionen från aktuell app store.

Denna komplexitet drabbar förvaltningen av den app-baserade tjänsten fordrar planering av distribution.

För vår tidsbokningstjänst flaggar Nordic Medtest för att man tidigt vill veta vilka versioner av Android och iOS Inera avser stödja och med vilken frekvens man (dvs i detta fall tredje part) avser uppdatera appen till nya versioner. Detta för att kunna planera test och kvalitetssäkring. Nordic Medtest noterar också att man önskar tillgång till källkoden för tredjepartsappen för att kunna säkra hanteringen av personuppgifter (tjänsten kräver ju enligt ovan inloggning med BankID).

Steg 8 - Förvaltning

Som noterat i flera av stegen i flödet ovan krävs en större insats vid förvaltning av app-baserade tjänster jämfört med webbappar. Några av de drivande skälen till detta är:

• två kodbaser förvaltas (om appen är native)

• Android och iOS kommer årligen i nya versioner som kräver uppdateringar av appen

• test och kvalitetssäkring är mer komplex - även vid mindre justeringar av appen

• app stores har betygssystem för publicerade appar (rating) som bör följas som en ytterligare kanal för felrapporter och annan återmatning från användare

• dessutom kräver varje ny version av appen en publiceringsprocess som driver ledtid och kan resultera i bakläxa som kräver ytterligare utveckling och test (dvs även ytterligare ledtid) - mer om detta här

För tidsbokningsappen kräver förvaltningen att man planerar en strikt roadmap för tjänsten där tredjepart rekommenderar uppdatering av appen som mest på årlig basis i samband med uppdatering av Android/iOS. Samtidigt med detta kommer även stöd för telefoner med äldre versioner av operativsystemen att upphöra. Man avsätter även tid/resurs för att hantera den nya kanal som app stores innebär för kommunikation med användare av tjänsten.

Case - sammanfattning

I caset med tidsbokningsappen har vi fått en inblick i hur app-strategin stödjer framtagning av app-baserade tjänster.

Vi har i konkreta exempel sett hur appar kan skapa en mer värdefull tidbokningstjänst, dock med ett antal konsekvenser i form av mer komplex utveckling och kvalitetssäkring av apparna (en för Android, en för iOS) och en större insats i förvaltningen.

Notera igen att detta case är fiktivt liksom förutsättningarna för tjänsten.

App-strategin är givetvis avsedd för att hantera verkliga tjänster - med varierande syfte, målgrupp och andra förutsättningar. Härnäst tittar vi på hur app-strategin fungerar i det generella fallet.

App-strategin - helheten

Stöd i Utvecklingsramverket

Ineras app-strategi ger stöd under en tjänsts livscykel - från idé till avveckling. Ineras utvecklingsramverk beskriver hur vi jobbar med utveckling av tjänster på Inera. Utveckling av app-baserade tjänster följer processen Hantera Behov genom att ge app-specifikt stöd för aktiviteter där appar ger väsentlig påverkan.

App-strategis i processens steg

Stegen i Hantera Behov är:

• Fånga behov

• Bereda behov

• Utveckla ny eller förändrad tjänst

  • Utarbeta tjänstedesign

  • Utveckla och paketera tjänst

• Överlämna paketerad tjänst

Under första steget, Fånga Behov, bedöms inte teknik (som appar) påverka arbetet och här finns således inget stöd från app-strategin.

App-strategin under beredning

Under beredning vägs en tjänsts värde/nytta mot dess kostnad. App-strategin stödjer detta genom stöd i beredningens aktiviteter (se nedan). Det finns även speciellt stöd för den utredare som leder beredningen i form av Utvärdering av app-initiativ (se ovan) och en sammanfattning av tips för app-baserade tjänster.

App-strategin under utveckling

App-strategin vid överlämning

App-strategin i processens aktiviteter

Det finns för närvarande femton /wiki/spaces/UtvR/pages/2472313315:

• Behovsdriven kravställning

• Intressentanalys

• Nyttorealisering & effekthemtagning

• Krav på servicenivå

• Informatik

• Informationssäkerhet

• Digital tillgänglighet

• UX-ramverket

• NMI - Nationella medicinska informationssystem

• eKlient

• Teknik-arkitektur

• Tjänstekontraktsutveckling.

• Test och kvalitetssäkring

• Tjänstepaketering.

• Överlämning till förvaltning

Aktiviteterna i fetstil bedöms påverkas väsentligt av appar - dvs konsekvensen av att realisera en tjänst med appar förändras för dessa aktiviteter jämfört med om tjänsten realiseras med webbappar.

Vid utveckling och driftsättning

Förvaltning av app-strategin

Aktiviteter

Roadmap

Avveckling

Kontaktpersoner och återmatning

Utvärdering

Länklista