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 |
Ditt svar hjälper oss att förbättra sidan
Senast uppdaterad: