Kärnprocessen: Specificera och planera

Denna delprocess stöttar din verksamhet från beslut om att fördjupa gjord analys till beslut om realisering av framtagen nyttorealiseringsplan. I denna delprocess är det också viktigt att ni etablerar samarbete med stödprocessen ”Säkerställa robust och säker IoT samt informationssäkerhet” i vägledningen för att kunna skapa så heltäckande och bra "business case" och nyttorealiseringsplan som möjligt. Det engelska begreppet ”Business Case” används ofta som benämning på ett fullständigt beslutsunderlag, som motiverar en förändringsinsats eller investering.

Beskrivning av kärnprocessens andra delprocess, Specificera och planera. Alla aktiviteter och delprocessens två beslutspunkter beskrivs nedan

Klicka på bilden för en större version. Beskrivning av kärnprocessens andra delprocess, Specificera och planera.

Efter att ni tagit beslut om en fördjupad analys är nästa steg att ta fram ett eller flera alternativa "business cases" genom att fortsätta fördjupa analys av behov, nuläge och marknad utifrån genomförd initial kartläggning. I Beslutspunkt 2 fattar ni beslut om vilket Business case ni vill gå vidare med och utifrån detta tar ni fram en plan för att realisera identifierade nyttor.

Ni behöver säkerställa att samverkan med stödprocessen ”Säkerställa robust och säker IoT samt informationssäkerhet” sker i hela kärnprocessen och att underlag sammanställs bland annat i det/de business case som tas fram som beslutsunderlag.

Resultat av denna delprocess

  • Vilket business case som ska genomföras och varför (Beslutspunkt 2)
  • Ett beslut om att realisera ett business case (Beslutspunkt 3)

Aktivitet: Utreda vilka verksamhetsmässiga grundförutsättningar som behöver finnas och genomföra marknadsdialog

Att fatta rationella beslut för att starta och styra en förändringsinsats är en relativt komplex historia. Som underlag behöver ni belysa många olika aspekter/grundförutsättningar. Dessa aspekter/grundförutsättningar behöver ni utreda ordentligt inför arbetet med att sammanställa ett eller flera alternativa business case(s) som ni sedan ska utvärdera och besluta om (i Beslutspunkt 2).

Genom att analysera de behov ni identifierat utifrån olika perspektiv såsom nytta, angelägenhet och de eventuella kostnader som behovet medför kan ni efter det prioritera behoven. I ett business case tas även hänsyn till genomförbarhet och risker.

Perspektiv

  • Nytta: Ekonomisk/ kvalitativ nytta, intern/ extern nytta, säker/ osäker nytta.
  • Kostnader: Investering, utredning, införande, förvaltning.
  • Angelägenhet: Hur viktigt är det för organisationen? I förhållande till mål och strategier, värderas ur olika perspektiv politisk/ teknisk/ organisatorisk.
  • Genomförbarhet: Värdering av initiativets genomförbarhet. Perspektiv att beakta är rättsliga förutsättningar - är det lagligt? Organisatoriska förutsättningar, kompetens och resurser, arkitektur och teknik, tidplan, ”projektträngsel”.
  • Riskbedömning: Identifiera utvecklingsinsatsens olika risker samt bedöma sannolikhet och konsekvens för dessa risker.

Se beskrivning av dessa perspektiv i DiGG:s vägledning, kapitel 5.

Vägledning i nyttorealisering, DIGG (PDF)

Marknadsdialog

I allt förändringsarbete är det viktigt med en kontinuerlig dialog med leverantörerna på marknaden. För att ni ska kunna utforma krav och kriterier på ett sätt som både skapar konkurrens och samtidigt ger en leverans i framkant behövs en god kännedom om det aktuella utbudet på marknaden och ofta också om vad som är på väg ut i form av innovationer och ny utveckling. Tidiga marknadsdialoger skapar förtroende hos båda parter och lägger grunden till ett gott framtida samarbete.

Dialog generellt, UHM

Tidig dialog med marknaden, UHM

Dialogmöten med leverantörer, UHM

Marknadsanalys, UHM

Riskanalys, UHM

Request for Information (RFI) och extern remiss, UHM

Testa och kommunicera med marknaden

Innan ni kan färdigställa business casen bör de testas och kommuniceras med marknaden. Marknadsdialogen syftar till att ta vara på leverantörernas kompetens om möjliga lösningar för att möta behoven, samt dess syn på föreslagna business casen. Nedan följer några förslag på dialogområden.

  • Leverantörernas möjligheter att möta behovsområdet.
  • Deras förslagna lösningars förutsättningar och beroenden för implementering i verksamhet, till exempel kompabilitet.
  • Finns det behov av utveckling under avtalstiden? Är samarbeten och partnerskap aktuellt? Och hur kan ett eventuellt samarbete se ut?
  • Drift, service och förvaltning av föreslagna lösningar.
  • Möjliga affärsmodeller utifrån de olika business casen.
  • Vad är kostnadsdrivande i respektive business case? Finns det specifika krav som driver risk och kostnad?
  • Riskhantering och riskfördelning mellan parterna.

Ni kan föra en relativt fri dialog före en eventuell upphandling. Det är bara under tiden mellan annonsering och tilldelning som särskilda förutsättningar gäller och kommunikationen bör initieras/styras av er som upphandlare. Kommunikationen ska huvudsakligen ske elektroniskt, till exempel genom frågor och svar.

Formerna för tidig dialog kan se lite olika ut och här kan ni läsa några exempel.

  • Kontinuerligt kan olika typer av marknadsaktiviteter genomföras via till exempel webb, mässor och konferenser. Detta kan ge en bild av utbudet på marknaden både i och utanför Sveriges gränser.
  • Specifika frågor kan ställas till marknaden i en så kallad Request for information, RFI. Specifika frågor om tjänsterna som till exempel tillgängliga funktioner och tekniska förutsättningar. Men frågan kan även innehålla om leverantörerna och deras gängse affärsmodeller och avtalsvillkor för att bättre förstå hur en eventuell upphandlingen kan utformas.
  • Det är vanligt att bjuda in leverantörer till möten, enskilt eller i grupp, för att de ska få presentera sina tjänster. Det kan då vara lämpligt att bjuda in olika representanter för även blivande användare – både kunder och personal. Viktigt är att göra inbjudan till marknaden så öppen som möjligt så att oskäliga fördelar till en leverantör inte ges. Det finns dock inget krav på att träffa alla leverantörer på marknaden.

En utbredd uppfattning är att möjligheterna till dialog mellan kommuner och leverantörer är starkt begränsade av LOU, vilket inte alls stämmer. Upphandlingsmyndigheten har beskrivit några av de vanligaste missuppfattningarna.

Myter om dialog i offentlig upphandling, UHM

Tabell: Exempel på olika typer av marknadsdialog

Tabellen består av tre kolumner. Scrolla åt höger eller vänd din enhet till horisontellt läge för bästa visningsupplevelse.

Exempel på olika typer av marknadsdialog

Fördelar
Råd
Öppna dialogmöten
– Träffa flera leverantörer på en gång.

– Alla parter får ökad kunskap.
– Bjud gärna in olika branscher, eftersom det kan finnas IoT-tjänster inom en annan bransch som skulle kunna anpassas till behoven.

– Se till att rätt personer från din organisation är på plats.
Enskilda dialogmöten
– Träff med en leverantör i taget.

– Fördjupad information om lösningar och upplägg.
– Förbered frågor om leverantörens lösningar.

– Var tydlig med hur informationen ska användas.
RFI (Request For Information)
– Ger svar på specifika frågeställningar.

– Möjlighet att testa idéer.
– Annonsera brett och ”puffa” för att få in svar.

– Gör gärna ett strukturerat frågeformulär.

Råd

  • Annonsera brett och ”puffa” för att få in svar.
  • Gör gärna ett strukturerat frågeformulär.
  • Er dialog med marknaden får aldrig leda till att en leverantör får en otillbörlig konkurrensfördel. En sådan kan exempelvis bestå i att en leverantör har fått mer information än de övriga och därför har bättre chanser att vinna upphandlingen.
  • Ni bör dokumentera det som kommer fram i dialogerna.
  • Använd gärna RefARK IoT:s Principer i en RFI. Tex för att få en bild från leverantörerna kring hur deras lösningar kan uppfylla dessa principer. Det kan ge bra underlag kring branschens mognad och därmed vilka krav som kan/bör ställas.
  • Det är viktigt att ni redan i detta skede börja tänka "förändringsledning", eftersom det är svårt, för att inte säga omöjligt, att nå ett nytt tillstånd i en verksamhet utan en beteendeförändring. Det gäller oavsett om förändringen handlar om en ny IoT-tjänst, förändrade processer, organisation eller attitydförändringar. Läs vidare om förändringsledning i DIGG:s vägledning i nyttorealisering.

Vägledning i nyttorealisering, DIGG (PDF)

HUKI

Huvudansvarig

  • Verksamhets­utvecklare

Utförs av

  • Verksamhets­utvecklare
  • Controller
  • Informations­ägare

Konsulteras

  • Verksamhets­nära personal

Läs vidare

Aktivitet: Sammanställa business case (förändringsunderlag)

Alla de aktiviteter ni tidigare genomfört i processen kan fram till denna aktivitet itereras/ upprepas/ fördjupas för att förbättras och utvecklas. I den första ”omgången” (det vill säga i delprocessen "Identifiera" innan beslutspunkt 1) gör ni en mer övergripande kartläggning och analys för att i detta skede nu fördjupa dessa i något/några möjliga och alternativa tjänster/funktioner/lösningar.

Dessa alternativ utreds ofta parallellt, till exempel med utgångspunkt i olika typer av användarbehov. Dessa behov kan ställa olika krav på informationssäkerhet, vilket gör att alternativen blir olika omfattande och kostnadsbilden kan också variera kraftigt.

Kravhantering

Det är viktigt att ni, utifrån identifierade behov, börjar samla in, analysera, justera och prioritera de olika krav som ställs på den tänkta IoT-tjänsten och sedan planerar för hur ni ska möta kraven. För att ett krav ska bedömas vara ett ”bra” krav bör det ha vissa egenskaper, vilket kan innebära att kravet ska vara:

  • Specifikt
  • Mätbar eller gå att testa
  • Tydligt och koncist
  • Korrekt
  • Lätt att förstå
  • Genomförbart och realistiskt
  • Nödvändigt och viktigt

Business case

Ett business case hjälper er beslutsfattare med att bland annat att förstå de ekonomiska konsekvenserna av en förändring. Innehållet i ett business case är beroende av omfattningen av själva förändringen/ utvecklingen. Om till exempel hela it-arkitekturen påverkas av förändringen måste det/de aktuella business case(n) återspegla detta och ta hänsyn till alla dess delar. Framför allt, för att ni ska kunna estimera kostnaderna på ett korrekt sätt behöver ett business case ta hänsyn till vilka kostnader som drivs av utveckling av allt från tänkt funktion/ nytta, processer, organisation och styrning till it.

Fram till beslutspunkt två är det bra om ni arbetar med ett antal olika alternativ, som sedan sammanställs i något/några business case som underlag för beslut i beslutspunkt 2 (Besluta om att genomföra en förändring).

Läs vidare om sammanställning av ett business case i DIGG:s vägledning för nyttorealisering. Ni hittar även en mall för beslutsunderlag (business case) i bilaga 11a i vägledningen.

Vägledning i nyttorealisering, DIGG (PDF)

HUKI

Huvudansvarig

  • Verksamhets­utvecklare

Utförs av

  • Verksamhets­utvecklare
  • Controller

Konsulteras

  • Användare
  • It-organisation
  • Leverantör/ Tillverkare av IoT

Läs vidare

Beslutspunkt 2: Besluta om att genomföra en förändring

I denna beslutspunkt tar ni beslut om ett business case, som ska genomföras.

HUKI

Huvudansvarig

  • Verksamhets­ägare/ Beställare

Utförare

  • Verksamhets­ägare/ Beställare

Informeras

  • Verksamhets­utvecklare
  • Verksamhets­nära personal
  • Controller
  • It-organisation
  • Upphandlings­ansvarig
  • Användare (vid behov)

Aktivitet: Ta fram plan för att realisera nyttorna

Nu har ni tagit fram ett business case med förväntade nyttor och därefter beslutat om att genomföra denna förändring/utveckling. Ni vet också hur dessa nyttor värderas och ska mätas och kan nu på riktigt börja planera för hur nyttorna ska realiseras.

Planeringen innebär ofta att definiera vilka förändringsinsatser som ni ska göra, vilka aktiviteter de innefattar, hur dessa ska synkroniseras med andra pågående aktiviteter, vilka möjliggörare som behöver tas fram samt vilka aktiviteter som bör drivas i linjen i befintliga processer och förvaltningsobjekt.

En mall, för att skapa en nyttorealiseringsplan, att utgå ifrån finns i bilaga 11 c i DIGG:s vägledning i nyttorealisering.

Vägledning i nyttorealisering, DIGG (PDF)

Områden som behöver finnas med i er nyttorealiseringsplan

  • Styrform (program, projekt, uppdrag)
  • Budget och ramar för genomförande
  • Ingående aktiviteter
  • Tidplan
  • Roller och ansvar

Verktyg och metoder

  • Nyttorealiseringsplan
  • Projekt- och uppdragsplaner
  • Kommunikationsplan

Förändringsledning välfärdsteknik, utbildning – hur gör man?

Stödmaterial Leda i förändring

Råd

  • Glöm inte plan och aktiviteter för det kommande förändringsarbetet, till exempel utbildning och implementering av förändrade arbetssätt.

HUKI

Huvudansvarig

  • Verksamhets­utvecklare

Utförare

  • Verksamhets­utvecklare
  • Informationsägare

Konsulteras

  • Verksamhets­nära personal
  • Controller
  • It-organisation
  • Upphandlings­ansvarig
  • Användare (vid behov)

Beslutspunkt 3: Besluta om hur vi ska realisera

I denna beslutspunkt fattar ni beslut om vilken styrform (program, projekt, uppdrag) som ska tillämpas för olika aktiviteter och vid framtagning av möjliggörare, vilka ramar dessa aktiviteter har. Här tas ni också initialt beslut om realisering ska ske via inköp alternativt egenutveckling. Observera att detta beslut ev. kan komma att förändras i kommande aktivitet ”Kartlägga och analysera” där ni igen behöver ta ställning till (utifrån marknads­förutsättningar mm) om ni ska köpa in IoT-tjänsten via total­entreprenad, delentreprenad eller utveckla IoT-tjänsten i egen regi.

Ni tilldelar budget, fattar beslut om uppstart och fastställer en tidplan för förändringsarbetet.

Om upphandling ska ske som en del i realiseringen behöver ni även besluta om följande frågeställningar:

  • Var i kommunen läggs huvudansvaret för upphandlingen och hur säkerställs samverkan med övriga interna och externa intressenter?
  • Söks någon form av utvecklingssamverkan med innovatörer/ leverantörer?
  • När är bästa tidpunkten för att genomföra upphandlingen?
  • Ska upphandlingen genomföras av kommunen, gemensamt med andra kommuner eller som en del av en nationell upphandling?
  • Vem ska förvalta och följa upp avtalet?
  • Vem ska ansvara för implementeringen? Det vill säga hur ska verksamheten använda tekniken för att nyttorna ska realiseras, till exempel ändrade arbetsmetoder, förändrings­ledning, juridik med mera.
  • Vilken teknik och vilka verksamheter som upphandlingen ska omfatta.
  • Hur upphandlingen ska förhålla sig till annan närliggande teknik.
  • Om upphandlingsprocessen ska omfatta/föregås av ett utvecklingssamarbete med marknaden eller inte.

Råd

Beslut om att realisera en IoT-tjänst genom egenutveckling bör enbart ske i organisationer där man har tillräckliga resurser för att utveckla, men framför allt för att drifta, förvalta och vidareutveckla IoT-tjänsten.

HUKI

Huvudansvarig

  • Verksamhets­ägare/ Beställare

Utförare

  • Verksamhets­ägare/ Beställare

Informeras

  • Verksamhets­utvecklare
  • Verksamhets­nära personal
  • Controller
  • It-organisation
  • Upphandlings­ansvarig
  • Användare (vid behov)

Kontakta oss

Kontaktformulär SKR