8 Införandestrategi - Färdplan

Rekommenderad avgränsning

Utifrån analysfasen med många intressenter, på grund av att adressregister är ett förutsättningsskapande byggblock, rekommenderar projektgrupp att ta ett inriktningsbeslut om byggblock adressregister ska vara ett sammanhållande adressregister för många initiativ, eller att fokusera på att realisera adressregister utifrån ett, möjligtvis två prioriterade initiativ. Dock att Projektgruppen rekommenderar att bemöta behov som lyfts inom SDG och SDK, och samtidigt bevaka och standardisera teknik i den mån det är möjligt. Prioritering kan genomföras mellan olika delprojekt inom resp. uppdrag. T.ex. första prioritet att utveckla adressering av bevistjänster, följt av andra prioritet att skapa förutsättningar gällande SDK Adressbok.

Ledning och styrning

För ett framgångsrikt arbete, krävs beslut om styrning och ledning av realisering av adressregister ska fortsatt ske inom Ena, eller om det ska ägas av regeringsuppdrag SDG eller RU SDK. Det skapas då tydliga beslutsvägar och effektivitet inom initiativet.

Projektgrupp och kompetenser

Digg som byggblocksansvarig bör utse ett delegerat uppdragsledningsansvar. Uppdragledare ska ansvara för att arbetet fortlöper. Uppdragsledare är en central roll, men för att lyckas i arbetet behövs, som nämnts i finansieringsanalysen:

  • Arkitektur (Teknik/Information)
  • Utvecklingsteam
    • Systemutvecklare (backend/frontend)
    • UX/kravbearbetning
    • DevOps
    • Scrum master
  • Verksamhetsexpert (Produktägare)
  • Verksamhetsutvecklare/processutvecklare
  • Informationssäkerhet
  • Juridik

Kravinsamling och prioritering

Utifrån rekommendation att avgränsa arbetet till ett eller två uppdrag som signalerat behov av adressering. Påbörjas en djupare analys i form av kravfångst och kravhantering av adressering. Första steg är att sammanställa redan identifierade user stories och användingsfall kopplat till adressregistret. Nästa steg är att komplettera user stories med hjälp av exempelvis en referensgrupp inom Ena. Utifrån sammanställning och komplettering av krav och behov, prioriteras dessa behov. Olika metoder kan användas för detta ändamål, exempelvis impact mapping. Utifrån detta förfinas och fördjupas kraven ytterligare för att få en gemensam backlog för Adressregister. Backlogen kan förslagsvis ha inslag av både t.ex. SDG och SDK, eller andra prioriterade ärenden.

Lösningsarkitektur

Utifrån prioriterade krav utarbetas förslag på lösningsarkitektur, förslagsvis utgå från befintliga förslag gällande konceptuellt lösningsförslag. I lösningsarkitektur framgår bland annat att utveckla API för att hitta adresser. En frågeställning att ta med vid utarbetning av arkitektur är det ska utvecklas nytt eller om befintlig lösning ska skalas upp, eller det ska vara en samordning av befintliga lösningar. Rekommendation gällande kartläggning är att återanvända befintliga och slutförda utredningar. Det finns mycket dokumentation och kunskap om adressering. Det behövs ett jobb att samla allt på ett ställa. Utifrån sammanställning tas beslut om lösningsarkitektur.

Utveckling

Utifrån prioriterade krav och beslutade lösningsarkitektur hanteras det vidare av utsett utvecklingsteam. Utvecklingsteamet tillsammans med utsedd uppdragsledare och produktägare (verksamhetsexpert), planerar in arbetet i iterationer. På Digg idag finns väletablerade utvecklingsteam som arbetar enligt scrum, med två veckors sprintar. Denna typ av arbete användes framgångsrikt vid utveckling av eDelivery SMP, och rekommenderar därför att detta används för utveckling av adressregister. Centralt för ett framgångsrikt resultat är att arkitekt, produktägare och verksamhetsexperter och utvecklingsteam har ett nära samarbete. Fördelaktigt att dessa samlas vid sprintplanering, prioriterade standups, och vid demo av utvecklade krav.

Dessa ceremonier kan med fördel kompletteras med nödvändiga kompetenser för att realisera Adressregistret, exempelvis informationssäkerhet, juridik, samt representanter av verksamhetsutvecklare gällande central anslutningsprocess.

Processutveckling och livscykelhantering

Projektgrupp rekommenderar att i första hand att det sker ett samarbete att utarbeta enade processer för till exempel anslutning och avveckling sker gemensamt inom Ena. Även fördelaktigt att livscykelhantering enas och bedrivs på likartat sätt inom Digg, och Ena.

Standardutveckling

Behov av standard för semantik gällande adressering har uppkommit i analysen. Rekommendationen är att genomföra en kartläggning av slutförda utredningar och utvecklade standarder, i syfte att återanvända tidigare arbeten. Exempelvis finns det standarder och dokumentation inom eDelivery, Peppol, SDK som kan återanvändas för att utarbeta en standard gällande semantik. Utsedda verksamhetsutvecklare utvecklar och sammanställer standard.

Drift

Förutsatt att Digg ska äga utvecklat adressregister, bör drift av tekniska komponenter ske enligt Diggs riktlinjer gällande drift och livscykelhantering. Idag är det främst Försäkringskassan som driftar Diggs komponenter. Rekommendationen är att även denna applikation driftas hos Försäkringskassan, och följer samma process som t.ex. eDelivery SMP.

Milstolpeplan för färdplan

Nedan specificeras milstolpar för färdplan av adressregister år 2022-2025. Mer detaljerad beskrivning finns i dokument Milstolpeplan Adressregister – färdplan.

Milstolpe

Klartkriterier

Klar (tertial)

Beslutad inriktning och innehåll för adressregister

Dokumenterat beslut av behöriga beslutsfattare om val av inriktning gällande adressregister. Om beslutet innehåller ett flertal utvecklingsinitiativ för att realisera olika typer av federationer, byggblock eller motsvarande, ska dessa tydligt vara prioriterade.

Q3-Q4 2022

Beslutad organisation inkl. ledning och styrning av byggblock

Dokumenterat beslut av behöriga beslutsfattare om hur byggblock ska bedrivas, tex vilken styrning, uppdragsledningsansvar samt i vilken samverkan med andra aktörer.

Q3-Q4 2022

Genomförd kravinsamling

Dokumenterad och presenterad kravinsamling för potentiella användare av byggblocket. Samt beslutad prioritering utifrån inriktningsbeslut och behov från målgrupp. Dessa krav dokumenteras enligt user stories i backlog.

Q3-Q4 2022

Genomförd kravinsamling

Dokumenterad och presenterad kravinsamling för potentiella användare av byggblocket. Samt beslutad prioritering utifrån inriktningsbeslut och behov från målgrupp. Dessa krav dokumenteras enligt user stories i backlog.

Q1 2023

Genomförd lösningsarkitektur

Dokumenterad och presenterad lösningsarkitektur för gruppering med beslutsmandat om fortsättning.

Q1-Q2 2023

Påbörjad utveckling av prioriterade krav och lösningsarkitektur

Definierat Definition of Ready (DOR), beslutad utvecklingsteam samt produktägarskap med beslutsmandat

Q2-Q4 2023

Genomförd demo av MVP gällande adressregister

Genomförd demo av utvecklingsteam för tänkt användargrupp. Dokumenterat feedback av utveckling från användargrupp.

Q3-Q4 2023

Genomförd synkning av gemensamma verksamhetsprocesser inom Ena

Dokumenterat beslut om hur Adressregister kan bidra till gemensamma processer inom Ena eller motsvarande.

Q3-Q4 2023

Processutvecklat och implementerat initiala nödvändiga verksamhetsprocesser för användning av adressregister

Dokumenterad, presenterad och beslutat förslag gällande verksamhetsprocesser, samt beslut om implementering av mest nödvändiga verksamhetsprocesser.

Q1 2024

Framtagen/vidareutvecklad standard gällande semantik

Dokumenterad, presenterad och beslutat förslag gällande standard för semantik. Samt hur detta ska vidareutvecklas.

Q1 2024

Utvecklad och genomförd demo av förädlad version av adressregister

Genomförd demo av utvecklingsteam för tänkt användargrupp. Dokumenterat feedback av utveckling från användargrupp.

Q1-Q4 2024

Förvaltningslagd adressgister av teknisk utveckling, verksamhetsprocesser

Beslutad om utsedd organisation för livcykelhantering inkl. drift, verksamhetsutveckling, ägarskap, utvecklingsteam för adressregister.

Q1-Q3 2025

Hjälpte denna information dig?

Ditt svar hjälper oss att förbättra sidan

Senast uppdaterad: