Styringsdokument. Godkjennes av Navn: Signatur. Prosjekteier: Styringsgruppe: Jan Chr. Sandberg Jan Chr. Sandberg

Transkript

1 Styringsdokument Dokumentansvarlig: Øyvind Roseth Forfatter: Prosjekt Modernisering av Folkeregisteret Dato opprettet: 19. april 2013 Dato sist endret: 3. juni 2015 Arkivreferanse: Filnavn: Versjon: 1.00 Godkjennes av Navn: Signatur Prosjekteier: Styringsgruppe: Jan Chr. Sandberg Jan Chr. Sandberg 1

2 Endringsoversikt Versjon Dato Beskrivelse Utført av Dokument opprettet Olav Pacyna Distribusjon for kvalitetssikring Versjon Dato Distribuert til Sendt av PROMIS AS Olav Pacyna PROMIS AS Olav Pacyna Forkortelser Forkortelse FIN SKD SKE SITS SKDRE SKDRA SOL SUA SFU NAV UDI HDIR FHI Difi MAG EDAG SL MAP Fullt navn Finansdepartementet Skattedirektoratet Skatteetaten Skatteetatens IT- og Servicepartner Rettsavdeling Skattedirektoratet Regionavdelingen Skatteetatens opplysningstjeneste Servicesenteret for utenlandske arbeidstakere Sentralskattekontoret for utenlandssaker Arbeids- og Velferdsetaten Utlendingsdirektoratet Helsedirektoratet Folkehelseinstituttet Direktoratet for forvaltning og IKT Prosjekt Modernisering av Grunnlagsdata Prosjekt Elektronisk dialog med arbeidsgivere Prosjekt System for ligning Prosjekt Modernisering av Plattform, tidligere Modernisering av Infrastruktur og Driftsarkitektur (MID) Styrende dokumenter Dokumenttittel Modernisering av Folkeregisteret Mandat forprosjekt 2015 ( ) Modernisering av Folkeregisteret Mandat forprosjekt fase 2 ( ) Modernisering av Folkeregisteret Mandat forprosjekt fase 1 ( ) Modernisering av Folkeregisteret Satsingsforslag ( ) Modernisering av Folkeregisteret Satsingsforslag ( ) Modernisering av Folkeregisteret Forstudierapport v2.1 ( ) 2

3 Andre sentrale dokumenter Dokumenttittel "Det sentrale styringsdokumentet", Veileder nr. 1, Versjon 1.1, , NTNU CONCEPT: mentet.pdf EDAG Hovedprosjekt Styringsdokument ekstern (v1.0) Skattedirektoratet, Sentralt styringsdokument for SAFIR prosjektet (v1.0) Skattedirektoratet, Kvalitetssikring av styringsdokumentasjon for EDAG (v1.0) PROMIS AS og Terramar AS, Prosjektstyringsdokument MAG (v1.0) Skattedirektoratet, Styringsdokument Saksbehandlingssystem tilpasset ebr Brønnøysundregistrene, Skatteetatens Prosjektstyringsbok (v2.1) Skatteetaten, Anskaffelsesreglement for Skatteetaten, versjon 1, april 2010 Sluttrapport for LØFT-programmet: Fornyelsen i Lånekasssen Vedlegg Dokumenttittel HL-03a Funksjonell løsningsbeskrivelse v1.5, Modernisering av Folkeregisteret, HL-03a Teknisk løsningsbeskrivelse v1.5, Modernisering av Folkeregisteret,

4 Innholdsfortegnelse 1 Innledning Formål med styringsdokumentet Om arbeidet Hensikten med Folkeregisteret Overordnede rammer Hensikt, krav og hovedkonsept Bakgrunn for prosjektet Prosjektets overordnede hensikt Interessenters forventninger Krav til funksjonalitet Overordnet beskrivelse av løsningskonseptet Avgrensning av omfanget Prosjektmål Samfunnsmål Effektmål Resultatmål Kritiske suksessfaktorer Rammebetingelser Eksterne Interne Helse, miljø, sikkerhet (HMS) Grensesnitt Organisatoriske Kommersielle Tekniske Prosjektstrategi Gjennomføringsstrategi Gjennomføringsmetodikk Strategi for Løsningsbeskrivelse Strategi for Konstruksjon Strategi for Godkjenning Strategi for regelverk Strategi for innføring Strategi for overgang til ny løsning Kontrakts- og anskaffelsesstrategi Føringer for kontraktsstrategien Alternative kontraktsstrategier Oppsummering og anbefaling av kontraktsstrategi Organisering og ansvarsdeling Beslutningsstruktur Forhold til sentrale eksterne interessenter Forhold til program Roller og ansvarsdeling Strategi for styring av usikkerhet Identifisering og håndtering av risikofaktorer Rapportering og oppfølging Risikobilde Muligheter Prosjektstyringsbasis Arbeidsomfang Endringsstyring

5 4.3 Prosjektnedbrytningsstruktur Kostnadsoverslag, budsjett og investeringsplan Estimeringstilnærming Basiskostnad Forventet kostnad og foreslått kostnadsramme Finansieringsbehov Utløsning av midler fra reserveavsetninger Kuttliste Overordnede planer Fremdriftsplan Milepæls- og leveranseplan Kommunikasjons- og forankringsplan Bemanningsplan Kvalitetssikring Gevinstrealiseringsplan

6 1 Innledning 1.1 Formål med styringsdokumentet Formålet med dette dokumentet er å etablere et prosjektstyringsunderlag for gjennomføringen av hovedprosjektet for Modernisering av Folkeregisteret, i perioden Mottager av dette dokumentet er Finansdepartementet. Dokumentet følger veileder for Det sentrale styringsdokument utarbeidet av Finansdepartementet i samråd med aktørene i ordningen for kvalitetssikring av store statlige investeringer (CONCEPTprogrammet). Innholdet bygger på prosjektets forstudierapport (v2.1, ), satsingsforslag overlevert Finansdepartementet vintrene 2013 og 2014, samt tidligere versjon av prosjektets sentrale styringsdokument utarbeidet våren Styringsdokumentet må således sees i sammenheng med disse og en rekke andre underbyggende dokumenter som samlet gir oversikt over sentrale forhold knyttet til prosjektet og ny løsning, på en måte som virker retningsgivende og avklarende for relevante interne og eksterne interessenter. 1.2 Om arbeidet En arbeidsgruppe nedsatt av Fornyings- og Administrasjonsdepartementet og Finansdepartementet leverte i 2007 en rapport kalt "Utveksling av grunndata på personinformasjonsområdet" (Grunndatarapporten). Denne presenterte en analyse av behovet for felles grunndata på personområdet. Grunndatarapporten var et viktig underlag for at Skattedirektoratet i januar 2011 etablerte et eget program for modernisering av Folkeregisteret. På grunnlag av en bred interessentanalyse ble 28 store og viktige brukere av folkeregisteret invitert til å delta i en referansegruppe for programmet. Gruppen leverte en utredning som ble grunnlag for en strategirapport som ble levert Finansdepartementet november 2011 og som beskrev samfunnets behov. I 2012 etablerte Skattedirektoratet et eget prosjekt under programmet for å konkretisere arbeidet med å modernisere Folkeregisteret. Våren 2013 ferdigstilte prosjektet en forstudierapport som inneholdt en analyse av behov, mål, strategier, konseptutredning og en samfunnsøkonomisk analyse. Basert på forstudierapporten ble et satsingsforslag utarbeidet og oversendt Finansdepartementet i november samme år. Våren 2014 ble det utarbeidet et sentralt styringsdokument og senere på året ble et revidert satsingsforslag ferdigstilt. Samtlige av nevnte dokumenter er blitt overlevert Finansdepartementet. Med unntak av forstudierapporten, har dokumentene gjennomgått ekstern kvalitetssikring i regi av Skattedirektoratet. 1.3 Hensikten med Folkeregisteret Lov om folkeregistrering av 1970 bestemmer at det skal være kun ett sentralt register for personopplysninger i Norge, som er Det Sentrale Folkeregisteret. Folkeregisteret utgjør en svært viktig del av samfunnets infrastruktur og har bidratt til store effektiviseringsgevinster for hele det norske samfunn. Registeret er sentralt i offentlig personrelatert saksbehandling og planlegging, men også for store deler av privat sektor er Folkeregisteret en nødvendig informasjonskilde for å utføre lovpålagte oppgaver. Blant de viktigste oppgavene til Folkeregistermyndigheten er følgende: Tildele en unik identifikator per person, både for bosatte og for personer med en midlertidig eller mer perifer tilknytning til Norge. Treffe vedtak om hvor en person er bosatt, innflytting til/fra Norge, registrering av dødsfall, registrering av sivilstand, utstedelse av attester og utskrifter, m.m. iht. lov og forskrift om folkeregistrering. Registrere foreldreansvar iht. Barneloven. Registrere farskap iht. fødselsforskriften (særforskrift tilhørende Lov om folkeregistrering). 6

7 Treffe vedtak om navn iht. Navneloven. Prøve ekteskapsvilkår iht. Ekteskapsloven. Oppdatere fullmakt som verge iht. Vergemålsloven. Folkeregisteret inneholder i dag opplysninger om ca. 7 millioner personer med fødselsnummer som er eller har vært bosatt i Norge. I tillegg kommer ca. 1,4 millioner personer som har fått D-nummer og som har en midlertidig tilknytning til Norge. Det foretas årlig nærmere 2 millioner endringer av opplysningene i databasen. Opplysningene i Folkeregisteret legges til grunn for en lang rekke vedtak av stor betydning for den enkelte person, som f. eks. stemmerett, skatteplikt, krav på statlige og kommunale ytelser, opptak til skole og barnehage, og utstedelse av pass og andre identifikasjonsdokumenter. Folkeregisteret er et vesentlig grunnlag for offentlig administrasjon, samfunnsplanlegging og forskning, blant annet fordi det gir basisinformasjon om samtlige bosatte i Norge og synliggjør personer med en midlertidig tilknytning til landet. Hvem som skal få tilgang til hvilke opplysninger avgjøres av Folkeregistermyndigheten på grunnlag av regler gitt i folkeregisterloven. Registeret inneholder taushetsbelagte og sensitive opplysninger, og derfor er en god tilgangsvurdering nødvendig for å ivareta personvernet. 2 Overordnede rammer 2.1 Hensikt, krav og hovedkonsept Under følger en beskrivelse av prosjektets bakgrunn, hensikt og interessentenes forventninger. Videre beskrives krav og føringer, en overordnet beskrivelse av det valgte konseptet som prosjektet bygger på og avgrensninger av omfanget Bakgrunn for prosjektet Folkeregisteret er utpekt som én av de fem store felleskomponenter i offentlig sektor. Omkring virksomheter i privat og offentlig sektor bruker folkeregisteret som sitt personregister. Kvaliteten på opplysningene har derfor direkte betydning for kvaliteten i både privat og offentlig sektors saksbehandling. Effektiviseringsgevinstene skyldes at de ulike virksomheter slipper å føre egne personregistre. For å fylle rollen som en sentral nasjonal felleskomponent også i fremtiden er det viktig at registeret speiler samfunnets behov. Et sentralt folkeregister anses å være av stor verdi for Norge og det er bred enighet om at Norge fortsatt bør ha et sentralt folkeregister. I 2014 ble nye personer registrert inn i Folkeregisteret. Av disse ble ca født i Norge, ca innvandret til Norge (hvorav ca reinnvandret og hadde d-nummer fra før) og ca fikk tildelt d-nummer som følge av en midlertidig tilknytning til Norge. Et flertall av de nyregistrerte i Folkeregisteret er innvandrere eller personer med midlertidig opphold i Norge. Den endrede befolkningssammensetningen og økningen av personers mobilitet både innenlands og over landegrensene reiser nye samfunnsbehov som dagens folkeregister ikke tar høyde for. Dette gjelder bl.a. utfordringer knyttet til identitetsproblematikk, oversikt over hvem som befinner seg i landet, hvor disse anses bosatt og hvordan samfunnet skal komme i kontakt med personene. Bruken av folkeregisteret har økt i takt med samfunnsutviklingen, mens regelverk og det som registeret bygger på er i stor grad basert på hvordan Norge så ut på tallet. Det er derfor et tydelig krav til flere og mer effektive digitale tjenester, f.eks. knyttet til raskere tilgang til mer oppdaterte opplysninger. Brukerne blir stadig tydeligere i sine krav og forventninger til Folkeregisteret, og dagens løsning gir ikke lenger den verdi som brukerne og samfunnet har behov for. Uten en modernisering vil Folkeregisteret ikke klare å møte forventninger om et register av god nok kvalitet til bruk i offentlig og 7

8 privat saksbehandling, og som et godt grunnlag for samfunnsplanlegging. Det er derfor et tydelig moderniseringsbehov for Folkeregisteret Prosjektets overordnede hensikt Dagens folkeregister krever forbedringer på en rekke områder. Nye behov og muligheter som følge av samfunns- og teknologiutviklingen, og en økende endringstakt, tilsier grunnleggende endringer. Prosjektets overordnede hensikt er å etablere et nytt velfungerende IT-system for forvaltning av folkeregistermyndighetens ansvar og oppgaver, implementere nye tilhørende forretningsprosesser og arbeidsrutiner, og sikre den praktiske bruken og forståelsen av revidert lov om folkeregistrering. I punktene under beskrives hvilke behov som vil forbedres av moderniseringen: Personvern. Det er behov for en lovmessig tydeliggjøring av formålet med Folkeregisteret; hvem skal registreres, hvorfor de skal registreres, hvilke personopplysninger som skal registreres, og hvem som kan få tilgang til de ulike opplysningene. Sistnevnte er viktig for å unngå misbruk av opplysninger og sikre at taushetsbelagt og sensitiv informasjon ikke kommer på avveie. Formålet vil bli tydeliggjort i revidert Lov om folkeregistrering, mens den praktiske håndteringen av dette vil beskrives i forskrifter og rundskriv av SKD RE med støtte fra prosjektet. I ny foreslått løsning skal borgeren få bedre innsyn i og mulighet til å melde i fra om feil, mangler og ønskede endringer av egne opplysninger i Folkeregisteret. Borgeren vil dermed oppleve bedre kontroll over egne persondata som legges til grunn i saksbehandling av offentlig og privat sektor. Sammen med en raskere oppdatering av Folkeregisteret og bedre systemtjenester for å tilgjengeliggjøre opplysninger til autoriserte virksomheter, vil tiltaket bidra til mer konsistente og korrekte persondata. Informasjonssikkerheten vil bli bedre som følge av at behovet for kopier eller andre supplerende persondataregistre hos virksomheter reduseres, noe som igjen vil bidra til å styrke personvernet. Helhetlig identitetsforvaltning og gradering. I Norge er det i dag svake rutiner for å verifisere hvorvidt en fysisk person svarer til en registrert identitet i Folkeregisteret, eller ikke. Rutinene støtter heller ikke godt nok viktige prosesser som utstedelse av pass og andre identitetsdokumenter. Prosjektet foreslår mer hensiktsmessige løsninger for autentisering som vil gjøre det betydelig vanskeligere for én og samme person å operere med én eller flere falske identiteter, registrert i Folkeregisteret. Det foreslås at prosessen med å utstede identitetsdokumenter knyttes tettere opp mot registreringen i Folkeregisteret slik at legitimasjonsdokumenter som asylsøkerbevis og oppholdskort, vil kunne påføres henholdsvis d-nummer eller fødselsnummer. Dette vil bidra til at den enkelte borger bedre beskyttes mot ID-tyveri, da det ikke vil være like lett å utgi seg for å være en annen. For brukerne av registeret er det viktig å vite på hvilket grunnlag en identitet er registrert. Dette fordi registreringen i Folkeregisteret er grunnlaget for bl.a. utstedelse av pass og andre identitetsdokumenter, samt for utbetaling av velferdsgoder og andre ytelser fra samfunnet. Graden av sikkerhet knyttet til entydig, unik og sikker identifisering av de personer som innrulleres i registeret er viktig for brukerne. Samfunnet har behov for at identiteter i registeret er så sikre som mulig, samtidig som det i mange tilfeller har behov for å tildele identiteter også til personer med usikker identitet. Dagens løsning møter ikke behovet for differensiert registrering godt nok. Det foreligger et behov for å skille de registreringer som er basert på en godt dokumentert identitet fra de registreringer som er basert på mer usikkert dokumentert identitet. I tiltaket inngår derfor forslag om å synliggjøre om kvalifisert identitetskontroll er foretatt og om identiteten er unik i Norge, eller ikke. Dette vil gjøre brukerne av registeret bedre i stand til å vurdere hvilken risiko som foreligger, og hvilken ytterligere identitetskontroll det eventuelt er grunn til å foreta eller hvilke ytelser det er forsvarlig å gi basert på sikkerhet for identitet. 8

9 Ajourhold av personopplysninger. Det er et økende behov for å ajourholde personopplysninger for personer med en midlertidig tilknytning til landet, og for personer som har utvandret. I dagens løsning oppdateres for eksempel ikke opplysningene på personer med D-nummer. Foreslåtte tiltak håndterer dette på en mer målrettet og ensartet måte gjennom elektronisk utveksling av opplysninger mellom de virksomheter som innehar nødvendige og relevante opplysninger. Dette vil føre til at opplysningene på hele folkeregisterpopulasjonen blir raskere oppdatert og dermed får høyere kvalitet. Informasjonsutveksling. Digital informasjonsutveksling har overtatt som hovedkanal for kommunikasjon mellom forvaltningen og borgerne. Begge disse parter har økte forventinger til rask, sikker og effektiv informasjonsutveksling, noe den eksisterende tekniske systemløsningen er uegnet for. Dette fordi oppdateringer i folkeregisteret i dag baserer seg på papirmeldinger sendt per post og som deretter registreres manuelt inn i registeret. Dagens folkeregisterløsning har fylt sin oppgave godt i mange år, men ble bygget for en annen tid og med en nå utdatert teknologi. Tiltaket foreslår nye og moderne grensesnitt som vil realisere kravene og behovene til en rask og sikker informasjonsutveksling og dermed et langt bedre oppdatert folkeregister. Teknisk løsning (inkl. plattform). Dagens folkeregistersystem bygger på Skatteetatens stormaskinmiljø. Dette er teknologi som skaper utfordringer med hensyn til dataintegrasjon med andre virksomheters persondatasystemer, opplever en fallende intern og ekstern drift-, forvaltnings- og videreutviklingskompetanse, og har avhengighet til en leverandør i en monopolsituasjon. Skatteetaten har ikke prioritert større investeringer de senere år, hverken i eksisterende folkeregistersystem eller i det interne driftsmiljøet. Som følge av dette er stagnasjon et sannsynlig resultat, med negative konsekvenser for samfunnet som helhet. Tiltaket foreslår utskiftning av dagens tekniske systemløsning med en ny. Den nye skal baseres på velkjente prinsipper, bygges på utbredte teknologiske løsninger og med god tilgang på høy kompetanse i et marked med en sunn konkurranse. I tillegg vil tiltaket bidra til å finansiere videre etablering av Skatteetatens moderniserte driftsplattform og infrastruktur. Tilsammen vil dette bidra til en helhetlig folkeregisterløsning med god datakvalitet, økt tilgjengelighet og evne til å videreutvikle løsningen i takt med samfunnets behov. I tillegg vil forvaltning og videreutvikling sikres i mange år fremover Interessenters forventninger Brukernes forventninger og behov er blitt avklart og forankret helt siden ferdigstillelsen av Grunndatarapporten i 2007, både gjennom skriftlige kommentarrunder, workshoper og løpende møter mellom prosjektet og de enkelte interessentene. Moderniseringsprosjektet har også vært et sentralt diskusjonstema i SKATE, SLG og ELG. I forbindelse med satsingsforslagene i 2013 og 2014 ble i det i tillegg avholdt forankringsmøter og utarbeidet brev for å avklare innholdet i moderniseringen og forventninger til de samhandlingsaktørene som mottar øremerkede midler gjennom satsingsforslaget (NAV, UDI, helsesektoren, nasjonal postadresseleverandør). For å synliggjøre viktigheten av moderniseringen av Folkeregisteret som et sektorovergripende tiltak, ble det høsten 2014 opprettet en midlertidig og tverrsektoriell arbeidsgruppe bestående av representanter for UDI, NAV, Politidirektoratet (POD), Statistisk Sentralbyrå (SSB), helsesektoren og Difi. Gruppen ble initiert av direktøren for NAV for å belyse betydningen for den enkelte virksomhet som bruker Folkeregisteret. Resultatet var et notat som ble fremlagt for SKATE og som synliggjør hvor kritisk det er for den enkelte virksomhet at dagens folkeregister moderniseres Krav til funksjonalitet Under følger sentrale krav til funksjonalitet i modernisert løsning. Disse bygger på gjennomførte analyser av brukerbehov og identifiserte endringsbehov. Modernisert løsning skal: 9

10 dekke forvaltningens behov for grunndata på personinformasjonsområdet, inneholde grunndata knyttet til personer som inngår i dagens folkeregisterpopulasjon, samt legge til rette for eventuelle utvidelser/innskrenkinger i populasjonen, utformes slik at samlet, felles grunndata om personinformasjon er oppdatert og korrekt, samt søkbar og tilgjengelig for brukere, inneholde standardiserte formater for effektiv og sikker informasjonsutveksling mellom interne og eksterne interessenter, muliggjøre digital samhandling mellom relevante interne og eksterne interessenter, inkludert selvbetjeningsløsninger for publikum og effektive integrasjoner mot andre etater og aktører, ivareta informasjonssikkerheten, ha høy tilgjengelighet og være stabil i drift for alle brukergrupper og samhandlende aktører, ha moderne, funksjonelle og effektive brukergrensesnitt tilpasset ulike roller og oppgaver, gi brukere tilgang til personopplysninger i henhold til hjemmel, legge til rette for differensiert tilgang basert på brukergruppe og gruppering av informasjon, inneholde støtte for lagring og analyse av økt volum av strukturert og ustrukturert informasjon, sikre at relevant personinformasjon registreres kun ett sted, dokumentere tydelig på hvilket grunnlag en identitet er blitt tildelt, bidra med informasjon som kan gjøre autentisering av identiteter enklere og sikrere, og som kan bidra til avdekking av identitetstyverier, dekke behov for unike personidentifikatorer som er egnet for entydig identifisering og utveksling av informasjon, føre journal over alle endringer av og innsyn i personopplysninger, kunne registrere identifikatorer som gjør det mulig å utveksle informasjon om personer på tvers av landegrenser, og utformes slik at nødvendige tilpasninger som følge av nye lovverk og endringer i organisering og arbeidsprosesser kan utføres på en ressurseffektiv måte. For en liste over tekniske krav, se Vedlegg A Overordnet beskrivelse av løsningskonseptet Hovedprosjektet baserer seg på anbefalt konsept fra forstudien som ble overlevert Finansdepartementet våren Konseptet har siden blitt bearbeidet og ytterligere detaljert. Følgende tiltak inngår i satsingsforslaget: 1. Forretningsutvikling og regelverksutvikling. Prosjektet vil sammen med relevante interessenter utarbeide og implementere nye og endrede forretningsprosesser, samt tilhørende forskrifter, instrukser og rundskriv tilhørende revidert Lov om folkeregistrering. 2. Nytt saksbehandlingssystem. Prosjektet vil utarbeide, utvikle og implementere et modernisert saksbehandlingssystem med fokus på høy grad av automatisert saksbehandling, og understøttelse av nye/endrede forretningsprosesser. Systemet vil tilby enkle brukerflater for interne saksbehandlere og i enkelte tilfeller eksterne brukere, samt innsynsløsning for borgere. 3. Bidrag til modernisering av Skatteetatens infrastruktur og driftsplattform. Modernisert system for saksbehandling vil ta i bruk og bidra til en videreutvikling av Skatteetatens moderniserte infrastruktur og driftsplattform. Plattformen vil blant annet bidra til å sikre døgnkontinuerlig drift og nye tjenester for tilgjengeliggjøring av folkeregisterinformasjon i maskinlesbar form. Prosjektet vil også bidra til en videreutvikling av nye og gjenbrukbare systemkomponenter i arkitekturen, og skal blant annet bygge en komponent for utveksling av informasjon med Skatteetatens partnere. Dette vil være en gjenbrukbar komponent som vil forenkle og effektivisere Skatteetatens samhandling med andre offentlige samarbeidsaktører som NAV, UDI og helsesektoren. Sentralt i komponenten vil være muligheten for å utveksle 10

11 folkeregisteropplysninger, samt skatt- og avgiftsopplysninger. I tillegg vil prosjektet i etableringen av komponenten vurdere muligheten for å utveksle informasjon på tvers av forvaltningsenheter Avgrensning av omfanget Prosjektet er ikke ansvarlig for øvrige forbedringsaktiviteter i virksomheter som berøres av endringene, utover: de forretningsprosesser som berøres av arbeidsomfanget til prosjektet (se avsnitt 4.1). tilrettelegging av de grensesnitt som inngår i kost-/nytteanalysen (se avsnitt 4.8). Ansvaret for å realisere gevinstene overlates til gevinsteier, dvs. leder for Regionavdelingen i Skattedirektoratet (SKD RA). 2.2 Prosjektmål Prosjektet har flere typer mål, hver med forskjellige funksjoner og egenskaper. Samfunnsmålene angir grunnleggende mål knyttet til prosjektets virkning for samfunnet. Effektmålene er knyttet til konkrete målsatte virkninger for de forskjellige interessentene. Resultatmålene er knyttet direkte til de løsninger prosjektet skal realisere Samfunnsmål Samfunnsmålene er et uttrykk for den nytte eller verdiskaping som et velfungerende modernisert folkeregister vil ha for samfunnet. Målene viser eiers intensjon og ambisjon med tiltaket. Samfunnsmålene for prosjektet er videreført fra Forstudien: S1 Folkeregisteret skal bidra til å gi et godt grunnlag for offentlige og private tjenester, forskning og samfunnsplanlegging. S2 Folkeregisteret skal bidra til effektiv ressursbruk. S3 Folkeregisteret skal bidra til å sikre og ivareta personvern. Det er identifisert en rekke samfunnsmessige nytteeffekter knyttet til moderniseringen. Styringsdokumentet omfatter kun de gevinstene som er direkte knyttet til investeringene i forslaget. Et modernisert folkeregister vil gi et betydelig større gevinstpotensial i den enkelte etat enn det som inngår i forslaget, men dette vil forutsette ytterligere investeringer for den enkelte. Det forventes at et modernisert folkeregister vil gi realiserbare gevinster hos Skatteetaten og hos de største samarbeidsaktørene NAV, UDI og Helse. De realiserbare gevinstene er fordelt på prissatte og ikke-prissatte nytteeffekter. De prissatte effektene er vurdert til å utgjøre MNOK 113 i årlige besparelser, og er oppsummert i tabellen nedenfor: 11

12 Prissatt årlig nytteeffekt fra og med 2020 (MNOK, 2016-tall) Nytteeffekt Skatteetaten Helsesektoren Rekvirenter Asylmottak Borgere Totalt 1. Automatisk tildeling av fødselsnummer til nyfødte 2. Elektronisk overføring av dødsfall fra helsesektoren 3. Elektronisk overføring av informasjon fra utlendingsmyndigheten om personer som har fått oppholdstillatelse 4. Automatisk tildeling av personidentifikator til personer som søker om beskyttelse 5. Økt grad av automatisert innrullering av personer som skal gjennomgå identitetskontroll hos SKE 6. Elektronisk rekvirering av personer med perifer tilknytning til landet 7. Automatisert behandling av flyttemeldinger 8. Reduserte utskrifter av registrerte opplysninger 9. Automatisert prosess for navnevalg/-endring og endring i sivilstand 10. Automatiserte kontroller ved registering av opplysninger Sum Tabell 1: Prissatte årlige gevinster av den foreslåtte løsningen. Full effekt oppnås først etter ett års drift I tillegg til de prissatte gevinstene vil det være en rekke forhold som gir nytte, men som ikke er prissatt. Disse er oppsummert i tabellen under: 12

13 Nytteeffekt Ikke-prissatt nytte fra og med 2020 Saneringsgevinst Økt kvalitet Sikrere og bedre innhold i Folkeregisteret Spart tid / ressurser for brukere Økt servicegrad ovenfor brukerne Økt kvalitet Økt pasientsikkerhet Kriminalitetsforebygging Sikrere identitetsforvaltning Svart økonomi Høyere pasientsikkerhet Økt pasientsikkerhet Kriminalitetsforebygging Sikrere identitetsforvaltning Forebygger økonomisk- og arbeidsmarkedskriminalitet Forebygger svart økonomi Forebygger økonomisk- og arbeidsmarkedskriminalitet Sikrer identitetsforvaltning Forebygger svart økonomi Svart økonomi Bedre identitetskontroll samt mindre risiko og belastning for personer som har søkt om opphold og beskyttelse Redusert behov for oppmøte og veiledning Reduksjon av returpost Forebygger økonomisk- og arbeidsmarkedskriminalitet Forebygger svart økonomi Spart tid / ressurser for brukere Spart tid / ressurser for etatene Økt servicegrad ovenfor brukerne Redusert belastning for personer som har søkt om beskyttelse og opphold Økt kvalitet Forebygger økonomisk- og arbeidsmarkedskriminalitet Sikrer identitetsforvaltning Forebygger svart økonomi Spart tid / ressurser for brukere Økt servicegrad ovenfor brukerne Økt kvalitet Spart tid / ressurser for brukere Spart tid / ressurser for etatene Økt servicegrad ovenfor brukerne Økt kvalitet Tabell 2: Ikke-prissatte årlige gevinster av den foreslåtte løsningen For fullstendig oversikt over de samfunnsmessige nytteeffektene, se avsnitt Effektmål Effektmålene fra forstudierapporten har vært gjenstand for en revisjon for å gjøre de mer konkrete og målbare. De reviderte effektmålene er utformet på bakgrunn av den samme behovsanalysen som i forstudie- og forprosjektfasen, og gir ingen endringer i omfanget. Effektmålene støtter opp under samfunnsmålene. I tabellen under er de forskjellige effektmålene stilt opp. Til hvert effektmål er det satt bestemte kriterier for hvordan effektene skal måles. 13

14 Effektmål Kriterier for måling E1 Mer effektiv saksbehandling 1. Etter 1. års drift skal 80 % av alle personnummer tildeles umiddelbart (totalt tildeles ca i 2012, null umiddelbart i dag) 2. Etter 1. års drift skal behovet for utskrifter av registrerte opplysninger være redusert med 75 % ( attester pr. 2010) E2 E3 E4 Et folkeregister som er brukervennlig, og alltid tilgjengelig Bedre kvalitet på folkeregisteropplysninger En sikrere forvaltning av identiteter og personopplysninger 1. Folkeregisteret skal ha oppetid på 99,98 % for oppslag i personopplysninger (for konsumenter) 2. Etter 1. års drift skal antall fysiske oppmøter i publikumsmottak være redusert med: o Utskrifter av registrerte opplysninger: 75 % (2010: ) o Tildeling av personnummer ved oppholdstillatelse: 80 % (2012: ) o Referansepersoner: 80 % (2012: ) 1. Rask oppdatering øker kvaliteten. Etter 1. års drift skal andel meldinger som behandles innen 1 dag være: o Fødsel: 95 % (2013: 1. dag 19 %) o Innvandring: 80 % (2013: 1. dag 1 %) o Flytting: 85 % (2013: 1. dag 9 %) Etter 3 år med ny løsning skal brukerundersøkelsens indikatorer for korrekthet og fullstendighet av opplysninger på en skala fra 1-7 være økt til minimum 5,9 (2014: 5,0) 1. Etter 1. års drift skal 99 % få riktig gradering for identitet, i forhold til kriteriene for gradering 2. Gjennomført risikovurdering av informasjonssikkerhet skal gi 0 hendelser på rødt risikoområde Resultatmål Tabell 3: Effektmål Resultatmålene er prioritert basert på konsekvensvurderingen av eventuelle valg som vil måtte tas når prosjektet gjennomføres. Resultatmålet for kostnadsrammene veier høyest. Deretter prioriteres tid grunnet den klare forventningen fra sentrale brukere av Folkeregisteret at hele/deler av ny funksjonalitet vil kunne leveres så tidlig som mulig (se Leveranseplan i avsnitt 4.6.2). Til slutt prioriteres omfang, som vil kunne reduseres dersom nødvendig for å holde tid- og kostnadsrammene. At omfanget holder riktig kvalitet ligger som et grunnleggende krav til løsningen og forventes oppfylt uavhengig. For å oppnå de ønskede effektmålene skal prosjektet levere på følgende resultatmål: Prioritet Mål 1 Kostnadsrammer R1 Prosjektet skal ferdigstilles innenfor vedtatte økonomiske rammer (2016-tall, ink. MVA): Basiskostnad: 546 MNOK Forventet kostnad (P50): 584 MNOK 14

15 Prioritet Mål Foreslått kostnadsramme (P85): 653 MNOK 2 Tid R2 Hovedprosjektet skal være ferdigstilt i henhold til utarbeidede fremdriftsplaner. Oppstart hovedprosjekt: Modernisert løsning i full produksjon: Omfang (ikke innbyrdes prioritert) R3 R4 R5 R6 R7 R8 R9 R10 R11 R12 R13 Nye grensesnitt med maskinelle kontroller mot samarbeidsaktører og forretningsprosesser med støtte for umiddelbar tildeling av gradert personnummer er implementert. Sentrale samarbeidsaktører som mottar øremerkede midler gjennom satsingsforslaget har implementert sine grensesnitt. Ny løsning for intern saksbehandling, med maskinelle kontroller og journalføring er implementert. Juridisk grunnlag for operasjonalisering av modernisert folkeregister foreligger. Nye elektroniske løsninger med tilgang til folkeregisterinformasjon for offentlige og private aktører er tilgjengelige. Ny selvbetjeningsløsning for borger med mulighet for innsyn og å melde endring av egne folkeregisteropplysninger er tilgjengelig. Ny informasjonsmodell med metadataregister er implementert. Rutiner og opplæringsopplegg for alle brukergrupper er utviklet og opplæring internt er gjennomført. Ny standardisert tilgangskontroll og sporing av alle hendelser er implementert. Ny teknisk løsning med støtte for nytt personnummer, gradering av identitet og muligheter for kobling mot biometriske personopplysninger er implementert. Ny løsning med gjenbruk av Skatteetatens felleskomponenter er utviklet og produksjonssatt. Tabell 4: Resultatmål Sammenhengen mellom samfunns-, effekt- og resultatmålene vises i Figur 1 under. Resultatmål for kostnad og tid (hhv R1 og R2) er unnlatt. Figur 1: Sammenheng mellom samfunns-, effekt- og resultatmål 2.3 Kritiske suksessfaktorer Kritiske suksessfaktorer (KSF) beskriver hva prosjektet må lykkes med for å oppnå prosjektets hensikt og mål. Det er identifisert 11 overordnede suksessfaktorer for prosjektet, beskrevet i Tabell 5. Det er også beskrevet hvilke tiltak som bør gjennomføres for aktivt å styre etter de kritiske suksessfaktorene. 15

16 KSF-ene er ikke innbyrdes prioritert og graden av samspill mellom dem kan variere gjennom prosjektperioden. Nr Kritisk suksessfaktor Tiltak 1 God styring og ledelse av prosjektet. 2 Måloppnåelse; sikring av at målene for prosjektet nås innen avsatt tid, økonomisk ramme, kvalitet og risiko. 3 Forutsigbarhet; Prosjektet styres slik at framdriften er forutsigbar for departementet, etaten og andre berørte. 4 Transparente beslutningsprosesser; Det er tydelig for interessenter utenfor prosjektet hvordan beslutninger blir tatt og hvordan underlag for slike beslutninger utarbeides. 5 God kommunikasjon internt og eksternt mot interessentgrupper og myndigheter. 6 Samarbeid med linjen og eksterne aktører. Opprettelse og vedlikehold av et godt styringsdokument som definerer tydelig ansvar for gjennomføring og tilstrekkelig involvering av departementet og prosjekteier. En aktiv styringsgruppe som har en god forståelse for prosjektmål og utfordringer ved gjennomføring. Etablere rapportering og møter som sikrer at styringsgruppen har en god innsikt i status, risiko og behov for tiltak i prosjektet. Medlemmene i gruppa tar et aktivt ansvar for sine roller i arbeidet. Effektive beslutningsprosesser for daglige utfordringer gjennom å delegere myndighet så langt ned som mulig. Oppbygning av en prosjektkultur åpen for læring og som er rustet for å løpende håndtere endring (f.eks. gjennom den prioriterte produktkøen som styres av produkteierne). Opprettelse av innføringsplaner tidlig God forståelse av hvilke leveranser som er nødvendige for å nå prosjektmålene. God grunnkalkyle for omfanget av de ulike leveransene og hva de vil kreve fra deltakerne. Realistiske milepæler og framdriftsplan. Tilstrekkelig fleksibilitet i planer og organisasjon til å håndtere nødvendige endringer underveis. God omfangsstyring og klart definerte prosedyrer for endringshåndtering. En prosjektorganisasjon med et tydelig ansvar og definerte roller, som samtidig har fleksibilitet til å trekke sammen mot et felles mål. Realistisk planverk, med en prosjektorganisasjon som løpende lærer basert på egen erfaring. God oppfølging av framdrift og god kontroll over gjenstående arbeid. En prosjektorganisasjon med et tydelig ansvar, definerte roller, og etablerte rapporterings- og eskaleringskanaler. Det er tydelig definerte beslutningspunkter og gode prosesser for hvordan beslutninger skal tas i forholdet mellom prosjekt og linje. Det er definerte prosedyrer for kvalitetssikring av beslutningsunderlag. Utarbeidelse og implementering av en tydelig kommunikasjonsstrategi med plan for intern og ekstern kommunikasjon. Sikring av kommunikasjon gjennom bruk av egnede fora og digitale kanaler. Regelmessige kommunikasjons- og oppfølgingsmøter med interne og eksterne interessenter og aktører. Godt avstemt hva prosjektet skal levere og hva linjen skal bidra med til gjennomføringen. Godt samspill mellom prosjektet og linjen gjennom etablering av 16

17 Nr Kritisk suksessfaktor Tiltak rolle- og ansvarskart. Nødvendig endring gjennomføres og kompetanse overføres til linjen. Det er tydelig avklart hvilke forventninger som stilles til eksterne aktører. 7 Aktiv risikostyring. Aktivt arbeid for løpende å avdekke og håndtere risiko på alle nivåer, for eksempel gjennom usikkerhetsanalyser og tilknyttet metodikk. Gjennomføring av pilotdrift for å redusere omfanget av eventuelle feil/mangler. 8 Tilstrekkelig/riktig kompetanse og kapasitet i prosjektorganisasjonen. 9 God leverandørstyring og godt samarbeid med eksterne tilbydere. Tidlig identifisering og kommunikasjon av prosjektets behov for kompetanse og ressurser. Klare avtaler med linjen for tilgang til/bruk av ressurser. Ansettelse og utvikling av riktig kompetanse i linjen og i prosjektet. Tydelig forankring av oppgaver og avklaring av forventninger. Tydelig avtale over: o hva som skal leveres av leverandøren(e), o hvilket ansvar leverandøren tar i forbindelse med sine leveranser og det ansvar kunden tar, og o hvordan godtgjøringen til leverandøren skal fastsettes. Etableringen av et tillitsfullt samarbeid mellom kunde og leverandør. Prosjektet er satt opp med kompetanse og kapasitet til å løse oppgavene på en god måte. Etablering av rapportering fra leverandøren som redegjør godt for status, avvik og risiko. 10 Vellykket produksjonssetting og implementering. Utarbeidelse av en god migreringsplan Involvering av berørte aktører tidlig i: o designarbeid for å muliggjøre innsyn i valg av systemløsning og teknologi, og o utviklings- og testarbeid for å sikre en transparent løsning. Løpende involvering av og overlevering til interne drifts- og forvaltningsmiljøer. Gjennomføring av PoCer for å redusere risikoer. Gjennomføring av pilotdrift for å redusere omfanget av eventuelle feil/mangler. Sikre at nødvendige rutiner og dokumentasjon er utarbeidet og distribuert, og opplæring gjennomført. 11 Metodikk Opplæring i og bruk av valgte metoder og rammeverk, både i prosjekt og hos drift og forvaltningspersonell. Kvalitetssikring av arbeidsprosesser i henhold til kvalitetsplan. Tabell 5: Kritiske suksessfaktorer med sikringstiltak 2.4 Rammebetingelser Prosjektet vil følge overordnede nasjonale retningslinjer gitt i følgende dokumenter: 17

18 St.meld. nr. 17 ( ) "Eit informasjonssamfunn for alle" St.meld. nr. 19 ( ) "Ei forvaltning for demokrati og fellesskap" Eksterne Følgende eksterne rammebetingelser vil gjelde for moderniseringen: Løsningen må forholde seg til føringer i regjeringens digitaliseringsprogram. Disse peker spesielt på kravene til en effektiv offentlig sektor og elektroniske tjenester til innbyggere og næringsliv (se Digitaliseringsprogrammet). Løsningen må forholde seg til føringer for hvordan virksomheten skal digitalisere for å tilby bedre tjenester og effektivisere driften (se Digitalrundskrivet). Løsningens IKT-arkitektur må samsvare med arkitekturprinsipper for offentlig sektor satt av Direktoratet for forvaltning og IKT (Difi). Disse beskriver krav til tjenesteorientering, interoperabilitet, tilgjengelighet, sikkerhet, åpenhet, fleksibilitet og skalerbarhet (se Difis retningslinjer for arkitektur). Løsningen skal ivareta Lov og forskrift om folkeregistrering inkludert de tillegg og endringer som kommer til før og under prosjektperioden (se folkeregisterloven). Løsningen skal ivareta Lov om behandling av personopplysninger inkludert de tillegg og endringer som kommer til før og under prosjektperioden (se personopplysningsloven). Anskaffelsen av prosjektet skal foregå innenfor rammene av Lov og forskrift om offentlige anskaffelser (se anskaffelsesloven) Interne Følgende interne rammebetingelser gjelder for moderniseringen: Løsningen må forholde seg til gjeldende IKT-strategi og -prinsipper fremsatt av Skattedirektoratet. Viktige hensyn er blant annet å utnytte teknologiske muligheter uten at løsningenes stabilitet trues, bevege seg fra papir til digitale løsninger, bruke felles tjenester og bygge videre i retning av etatens vedtatte virksomhetsarkitektur, vurdere helhet og livsløpskostnader samt å benytte markedet der dette er velfungerende. Løsningen må forholde seg til Skatteetatens styringssystem for informasjonssikkerhet (SFI) for korrekt og sikker håndtering og formidling av informasjon. Her er særlig hensynet til strengt fortrolige opplysninger (kode 6) viktig. Skatteetatens direktiv og rutiner for HMS-arbeid for bl.a. å sikre etterlevelse av Arbeidsmiljøloven, Avtale om inkluderende arbeidsliv (IA-avtalen) og etatens visjon om at "Skatteetaten skal være en attraktiv og inkluderende arbeidsplass hvor arbeidsmiljøet er kjennetegnet av trivsel og arbeidsglede, åpenhet og mangfold." Tjenesteproduksjonen ved Folkeregisteret skal gå som normalt i løpet av prosjektperioden. Linjen skal på sikt selv kunne overta ansvaret for drift, forvaltning og videreutvikling av den moderniserte løsningen. Skattedirektoratet ønsker derfor at det ikke inngår opphavsbeskyttede komponenter i løsningen, og at ny løsning utformes uten avhengigheter og/eller for sterke bindinger til enkeltleverandører. Skatteetaten skal ha alle rettighetene til produktet. Skatteetatens gjeldende rammeverk og metodikk på områder som prosjektgjennomføring- og styring, systemutvikling, kvalitetssikring, m.m. skal følges i den grad dette vurderes som hensiktsmessig. 18

19 2.4.3 Helse, miljø, sikkerhet (HMS) Prosjektet vil følge lov om offentlige anskaffelser 6, som sier at alle statlige organer under planleggingen av den enkelte anskaffelse skal ta hensyn til miljømessige konsekvenser av anskaffelsen. Prosjektet har ingen eksplisitte HMS-utfordringer ut over anskaffelser og bruk av tjenester. Prosjektet vil følge gjeldende strategi for anskaffelser i Skatteetaten, der det kreves at leverandørene legger fram HMS-egenerklæringer i tillegg til de øvrige kvalifikasjonskravene, ved anskaffelser over kr ,- eks. mva. HMS-egenerklæringen gjelder kun ved tjenestekjøp. Det vil måtte vurderes i hvert enkelt tilfelle hvorvidt tilsvarende dokumentasjon for eventuelle underleverandører leverandøren ønsker å benytte skal og omfattes av samme krav. Ut over dette henvises det til Skatteetatens egen HMS visjon om å være en attraktiv og inkluderende arbeidsplass kjennetegnet av trivsel og arbeidsglede, åpenhet og mangfold. Prosjektet og dets ledelse vil således være ansvarlige for gjennomføringen og dokumentasjonen av systematisk HMS-samarbeid med prosjektdeltagerne, med fokus på forebygging av aktuelle risikofaktorer og å skape helsefremmende arbeidsplasser. 2.5 Grensesnitt I dette avsnittet beskrives prosjektets grensesnitt: Organisatoriske grensesnitt mot både eksterne og interne aktører Kommersielle grensesnitt mot leverandører av konsulenttjenester Tekniske grensesnitt mot både eksterne og interne systemer Prosjektinterne grensesnitt For å kunne planlegge og styre prosjektets samhandling med andre aktører og systemer er det nødvendig å identifisere, beskrive og håndtere disse grensesnittene. I det følgende gir vi en oversikt over de mest sentrale grensesnitt med en beskrivelse av hvordan prosjektet skal håndtere disse Organisatoriske Det er identifisert organisatoriske grensesnitt mot både eksterne og interne aktører. Disse er oppsummert i figuren under. Figur 2: Oversikt over eksterne (grønt) og interne (blått) organisatoriske grensesnitt 19

20 Interne interessenter Prosjektet vil forholde seg til flere interessenter som ansees som interne, herunder Finansdepartementet (FIN), Skattedirektoratet (SKD), Skatteetatens IT- og Servicepartner (SITS) og Regionavdelingen med tilhørende skattekontorer og SOL. Disse interessentene, tilhørende grensesnitt og hvordan disse håndteres er beskrevet under i Tabell 6. Interessent Grensesnitt Håndtering Finansdepartementet (FIN) Skattedirektoratet (SKD), herunder SKDRE, SKDRA og SKDIU Skatteetatens IT- og Servicepartner (SITS) Prosjekter/programmer i Skattedirektoratet Finansdepartementet er ansvarlig fagdepartement for Skatteetaten og finansierer prosjektet. Underlagt Finansdepartementet og står for den sentrale faglige, strategiske og administrative ledelse av Skatteetaten. Eier prosjektet. Avgir ressurser til prosjektet fra Rettsavdelingen (SKDRE), Regionavdelingen (SKDRA) og Innovasjon og Utviklingsavdelingen (SKDIU). Organisatorisk del av Skattedirektoratet og ansvarlig for å sette nødvendige strategiske føringer og retningslinjer for valg og etablering av modernisert folkeregisterløsning innenfor områdene Sikkerhet, Kvalitet og Styring (med tilhørende staber). Avgir ressurser til prosjektet fra de ulike avdelingene Planlegging, Utvikling, Tjenester, Brukerstøtte og Anskaffelser Sentral rolle i fremdriftsstyringen av prosjektet for å unngå at øvrig produksjonsvirksomhet til etaten påvirkes av prosjektet. Ansvarlig for å overta drift og forvaltning av ny løsning etter produksjonssetting. Elektronisk dialog med arbeidsgivere (EDAG) og Modernisering av Grunnlagsdata (MAG). Ansvarlig for kunnskapsdeling knyttet til prosjektgjennomføring og utvikling av en rekke felleskomponenter (Mottak, Arbeidsliste, m.m.). Modernisering av Plattform (MAP). Ansvarlig for tjenesteetablering, -drift og -forvaltning, samt for tilrettelegging av utviklings-, test- og produksjonsplattform. Hvordan styringen av og dialog med prosjektet vil foregå må avtales nærmere mellom Skattedirektoratet og FIN. Prosjektet vil håndtere dialogen gjennom tildelte ressurser, samt gjennom formaliserte og avtalte kanaler, beskrevet nærmere i 3.3. Prosjektet vil håndtere dialogen gjennom tildelte ressurser samt gjennom formaliserte og avtalte kanaler, beskrevet nærmere i 3.3. Prosjektet vil ha en tett dialog med dagens forvaltningsorganisasjon gjennom de enkelte delprosjektene, som sammen skal sikre en riktig overlevering med tilstrekkelig opplæring og kompetanseoverføring. Se Prosjektet vil håndtere tverrgående behov med de andre prosjektene formelt gjennom SKD og SITS styringsgruppe, og uformelt gjennom løpende samtaler og møter med prosjektenes ledere. I tillegg for MAP vil det være knyttet en enda tettere dialog. Prosjektstab (se 3.3.4) vil ha som 20

21 Interessent Grensesnitt Håndtering Øvrige pågående og planlagte utviklingsprosjekter i samme periode, eksempelvis SOFUS, SAFIR, Skattemeldingen, RANK og ELSA. Ansvarlig for kunnskapsdeling knytte til prosjektgjennomføring, og ny-/videreutvikling av både felleskomponenter og modernisert applikasjonsplattform. Prosjekt Ny kontorstruktur. Ansvarlig for koordinering og avklaring av etatens kontorstruktur. Prosjektet vil gi innspill til dette arbeidet. Program Samordnet skatt og avgift (SKA) vil være ansvarlig for kunnskapsdeling knyttet til prosjektgjennomføring. ansvar å sikre at øremerkede midler når MAP-prosjektet, og at tidsplaner tilpasses for å møte folkeregisterprosjektets behov. Skatteetatens regioner og skattekontorer (linjen), inkl. Servicesenteret for utenlandske arbeidstakere (SUA), Sentralskattekontoret for utenlandssaker (SFU) Skatteetatens opplysningstjeneste (SOL) Brukere og veiledere av Folkeregisterets nye saksbehandlingsløsning. Prosjektet vil håndtere dialogen med Regionavdelingen og skattekontorene gjennom tildelte ressurser som vil delta i prosjektets løsnings-, test- og innføringsaktiviteter beskrevet i avsnitt Eksterne interessenter Tabell 6: De viktigste interne organisatoriske interessenter Eksterne interessenter omfatter konsumenter og produsenter av folkeregisterdata. Informasjon, kommunikasjon, involvering, forankring og opplæring av disse vil ivaretas av planlagte innføringsaktiviteter. Involvering av brukere vil i tillegg foregå gjennom planlagte testaktiviteter. I tabellen under listes opp kun de interessentene som vil motta egne øremerkede midler gjennom satsingsforslaget. For øvrig interessenthåndtering se avsnitt om Tekniske grensesnitt. Interessent Grensesnitt Håndtering Arbeids- og Velferdsetaten (NAV) Helsesektoren Helsedirektoratet (HDIR) og Folkehelseinstituttet (FHI) Ansvarlig for å gjøre nødvendige tilpasninger på egen side, som skal muliggjøre: rekvirering av D-nummer utveksling av meldinger vedrørende: o utenlandsadresser o dødsfall i utlandet o farskap Ansvarlig for å gjøre nødvendige tilpasninger på egen side, som skal muliggjøre: umiddelbar tildeling av fødselsnummer i forbindelse med fødsel, og oversending av dødsmelding ved død. De enkelte aktørene vil opprette egne mottaksprosjekter med konkrete mandater, som avgrenser bruken av øremerkede midler og forplikter levering til avtalt tid, kost og kvalitet. Dette vil fungere som bilaterale avtaler, og ansvarliggjøre og forplikte involverte parter. De eksterne mottaksprosjektene vil 21

22 Utlendingsdirektoratet (UDI) Aktør ansvarlig for et nasjonalt postadresseregister Ansvarlig for å gjøre nødvendige tilpasninger på egen side, som skal muliggjøre: rekvirering av personnummer for: o personer som er innvilget beskyttelse eller opphold på humanitært grunnlag o arbeidstakere, studenter og familieinnvandrere som er innvilget opphold utveksling av meldinger vedrørende: o statsborgerskap o oppholdstillatelse o andre Ansvarlig for å gjøre nødvendige tilpasninger på egen side, som skal muliggjøre ajourhold og utveksling av postadresseinformasjon. rapportere direkte til prosjektleder i prosjekt MF. Viktige avklaringer som er til hinder for den løpende fremdriften løftes til og drøftes i den eksterne styringsgruppen Kommersielle Tabell 7: Eksterne interessenter som mottar egne midler De kommersielle grensesnittene omfatter forholdet mellom prosjektet og alle kommersielle aktører. Disse grensesnittene vil være beskrevet i egne avtaler med de enkelte aktørene, og ivaretas i henhold til disse i prosjektgjennomføringen. De kommersielle grensesnittene omfatter følgende aktører: Leverandør(er) av konsulenttjenester Leverandør(er) av hardware Leverandør(er) av software Leverandør(er) for distribusjon av folkeregisteropplysninger Alle anskaffelser vil koordineres via SITS Anskaffelser og skal håndteres innenfor rammene av lov og forskrift om offentlig anskaffelse. Det vil utarbeides en leverandørstyringsplan med fokus på gjennomføring av regelmessige møter for å sikre løpende orientering om prosjektets fremdrift og eventuelle behov, samt for fortløpende å håndtere problemstillinger Tekniske Brukere av Folkeregisterets tekniske grensesnitt kan betraktes som konsumenter (henter/leser data) eller produsenter (tilfører opplysninger). Disse brukerne omfatter offentlige etater, kommuner, andre lands myndigheter, næringsliv og innbyggere. Modernisert folkeregisterløsning vil tilby to modeller med underliggende grensesnitt for interaksjon med brukerne, permanente (Tabell 8) og midlertidige modeller (Tabell 9). De permanente grensesnittene representerer nye grensesnittsløsninger. De interessentene som ønsker å nyttiggjøre seg av disse vil selv måtte påta seg ansvaret og kostnaden for nødvendige tilpasninger på egen side. Det finnes flere pågående og planlagte reformer og programmer som disse interessentene kan utnytte for å tilpasse sin tekniske integrasjon mot Folkeregisterets. Interessent Grensesnitt Håndtering Produsenter og konsumenter System til system-grensesnitt meldingsbaserte grensesnitt der meldinger om endrede data kan sendes til Folkeregister, eller det kan spørres om informasjon. Grafisk brukergrensesnitt grafiske grensesnitt som muliggjør konsumenter å gjøre enkeltoppslag eller søke på Prosjektet utvikler standardiserte grensesnitt i samarbeid med de viktigste interessentene. De eksterne interessentene må 22

23 Konsumenter informasjon ved hjalp av søkekriterier. Produsenter vil i tillegg kunne sende meldinger om endrede data til Folkeregisteret gjennom dette grensesnittet. Hendelsesgrensesnitt (feed) grensesnitt der endringer i Folkeregisteret løpende legges ut i sanntid slik at andre kan fange opp og agere på endringene. selv sørge for tilrettelegging av egne systemer og infrastruktur for påkobling mot folkeregisterets nye grensesnitt. Tilgang til de ulike grensesnittene vil reguleres i avtale. Tabell 8: Permanente modeller (nye grensesnitt) Midlertidige modeller representerer dagens grensesnittløsning og vil opprettholdes inntil videre slik at aktuelle konsumenter får nødvendig tid til omstilling. Prosjektet vil i prosjektperioden arbeide med å synliggjøre konsekvensene av å fortsette bruken av dagens (midlertidige) grensesnitt opp mot mulighetene og fordelene som de nye grensesnittene gir. Da det er store forskjeller hos de enkelte etatene og virksomhetene som benytter seg av de midlertidige modellene, vil prosjektet jobbe med hver og én av disse for å avklare et passende løp og tidspunkt der man går over til de permanente modellene. Interessent Grensesnitt Håndtering NAV, SSB, TAD, UDI, Forsvaret, EVRY, Statens kartverk Ekstern distributør (EVRY) Eksisterende Folkeregisterløsning (DSF) Interne systemer i Skatteetaten Videreføring av dagens grensesnitt for: direkte distribusjon av Folkeregisterkopi til eksterne brukere (NAV, TAD, SSB, Forsvaret, UDI og EVRY), og mottak fra eksterne brukere (UDI, Statens kartverk, NAV). Dagens distributør av Folkeregisteret. Paralleldrift/koeksistens mellom dagens (DSF) og modernisert løsning. Dagens interne Skattesystemer mottar folkeregisterdata enten via batch (Partsregisteret) eller gjennom direkte oppslag i databasen (MVA, Sofie, Datavarehus, m.fl.). Dagens grensesnitt videreføres inntil videre. Kravet til dette håndteres av MAP-prosjektet som etablerer en ny plattform med mulighet for videreføring av dagens distribusjon. Prosjektet vil ta opp overgangen til de permanente modellene både i de strategiske og operative møtearenaene. Nytt folkeregister vil ha kapasitet og sikkerhetsløsninger som på sikt gjør et ekstra ledd for distribusjon overflødig. Inntil noe annet er avklart vil derimot grensesnittet håndteres gjennom egen avtale med ekstern distributør. Se avsnitt Disse interne systemene vil i modernisert løsning håndteres på samme måte som eksterne systemer og vil derfor måtte omskrives og tilpasses til de nye grensesnittsløsningene. Dette vil gjøres gjennom løpende dialog og avklaring med dagens linje-it organisasjon. Tabell 9: Midlertidige modeller 23

24 3 Prosjektstrategi Under følger en beskrivelse av ulike metodikker og strategier knyttet til gjennomføringen av hovedprosjektet, samt en beskrivelse av prosjektets organisering og ansvarsdeling. I tillegg drøftes det ulike kontrakts- og anskaffelsesstrategier som skal bidra til å fylle prosjektets behov for ressurser. Strategiene under beskrives ut ifra hvordan prosjektet skal gjennomføres for best å oppnå hensikten og målene beskrevet i kapittelet ovenfor. 3.1 Gjennomføringsstrategi I kapitlene nedenfor redegjøres det for valgte strategier og metodikker for sentrale aktiviteter som vil være med på å definere og påvirke gjennomføringen av hovedprosjektet Gjennomføringsmetodikk Prosjektet MF vil legge til grunn bruken av Skatteetatens smidige gjennomføringsmodell kalt Felles SystemUtviklingsMetodikk (FSUM). Denne baseres på erfaring fra en rekke gjennomførte og pågående systemutviklings- og endringsprosjekter, blant andre prosjektene MAG og EDAG. I tillegg bygger den på i) de smidige prinsippene, ii) Scrums roller, aktiviteter og artefakter, samt iii) kontraktsstandardene PS2000/PS2000 SOL. Modellen inneholder i tillegg metodikk og rammeverk for områder som innføring og regelverk. Figur 3 illustrerer verdikjeden i Skatteetatens smidige gjennomføringsmodell. Den består av stegene Behovsanalyse, Løsningsbeskrivelse, Konstruksjon og Godkjenning. De stegene fra modellen som berører hovedprosjektet er Løsningsbeskrivelse, Konstruksjon og Godkjenning. Disse vil være iterative og gjennomføres for hver av de planlagte hovedleveransene. Stegene utdypes i avsnittene under. Steget Behovsanalyse, som omfatter den overordnede behovskartleggingen i forprosjektet samt KS2- beslutningen, anses som ferdig gjennomført i forkant av hovedprosjektets oppstart. Det vil likevel arbeides videre med behovsdetaljeringen som en del av sprintene i konstruksjonsfasen. Steget Forvaltning omhandler drift, forvaltning og videreutvikling, og anses derfor som utenfor omfanget til hovedprosjektet. Unntaket gjelder prosjektets støtte til drift og forvaltning under paralleldriften mellom eksisterende og modernisert løsning i produksjon (se avsnitt 3.1.7). Prosjektet vil sammen med linjen sikre overføring av kompetanse til de relevante drift- og forvaltningsmiljøene. Figur 3: Skatteetatens smidige gjennomføringsmodell legges til grunn for gjennomføringen av hovedprosjektet. 24

25 3.1.2 Strategi for Løsningsbeskrivelse Ved oppstarten av hovedprosjektet vil prosjektet befinne seg i steget Løsningsbeskrivelse. Prosjektet legger til grunn bruk av SITS' metodikk for kravanalyse og løsningsutforming. Denne er tilpasset gjennomføringsmetodikken og basert på Volere kravmodellering ( samt bruken av Unified Modeling Language (UML). I tillegg bygger metodikken på Skatteetatens erfaringer fra prosjektene MAG, EDAG og RANK. UML fokuserer på standardisering av beskrivelser og modellering av løsningskomponenter, og brukes i forbindelse med fremstilling av behov og krav. I steget Løsningsbeskrivelse gjennomføres en rekke aktiviteter, først og fremst for å sikre en omforent løsningsforståelse, men også for å sikre at estimatene gjenspeiler virkeligheten. For å klare dette vil prosjektet jobbe med å: avgrense omfanget, eksempelvis i form av brukerhistorier, utarbeide løsningsdesign og -arkitektur, designe nye forretningsprosesser og forankre disse med linjen, verifisere estimater på de ulike løsningselementene, prioritere løsningselementer i forhold til kost/nytte, klargjøre for konstruksjon de brukerhistoriene som skal utvikles i den første sprinten (krever større detaljeringsgrad enn de brukerhistoriene som skal utvikles senere), og utarbeide en overordnet leveranseplan for de ulike prosjektleveransene. Løsningsbeskrivelsene og leveranseplanen utgjør omfanget og tidshorisonten som prosjektleder vil styre etter. Dersom det senere i hovedprosjektet kommer forslag om endringer i omfang, fremdrift og kostnader, er det viktig at prosjektet har gode rutiner for endringsstyring. Forslag til endring må deretter legges frem for prosjekteier og styringsgruppen for beslutning, og relevante dokumentasjon må oppdateres. Den viktigste leveransen fra steget Løsningsbeskrivelse er en omforent produktkø. Produktkøen er en sortert liste av funksjonalitet, prioritert i den rekkefølgen som prosjektet forventer å utvikle dem. Listen må sikre at alle elementene fra behovsanalysen er med og at løsningsforslagene har kravpoeng knyttet til seg. Hvert element skal ha minimum ett estimat og én prioritet. Produktkøen må deretter ordnes i en leveranseplan. De egenskapene ved løsningen som antas å ha størst nytteverdi plasseres i de første sprintene (for definisjon av sprint, se avsnitt 3.1.3). Hva som har størst nytteverdi kan endre seg utover prosjektet, slik at produktkøen må revideres underveis. Det vil ikke være nødvendig å fordele produktelementer på sprinter som ligger et stykke ut i hovedprosjektet. Til å begynne med er det tilstrekkelig med en hypotese om antall sprinter og volumet per sprint, slik at det totale volumet tilsvarer volumet av samtlige produktelementer som inngår i løsningen Strategi for Konstruksjon Etter Løsningsbeskrivelse følger steget Konstruksjon. Her etableres ny systemløsning. Prosjektets benyttede systemutviklingsmetodikk bygger på smidige prinsipper. Smidig utviklingsmetodikk bidrar til at man enklere kan justere og prioritere krav og funksjonalitet til løsningen etterhvert som man høster erfaring fra hver sprint. Dette medfører at eventuelle feil og mangler avdekkes raskere. Tidlige og kontinuerlige leveranser bidrar til å bedre samsvaret mellom faktiske behov og levert løsning. Ny systemløsning er fordelt på prosjektets 4 hovedleveranser og vil etableres gjennom såkalte sprinter. En sprint representerer utviklingen av små produktinkrementer og varer mellom én til fire uker. En ny sprint starter umiddelbart etter at forrige sprint er avsluttet. Sprintene avsluttes med en prosjektintern demonstrasjon av kjørende kode. Sluttbrukerne i forvaltnings(linje-)organisasjonen vil får innsikt i sprintene gjennom godkjenningsprøvene (se avsnitt om 'Strategi for Godkjenning'). I forkant av konstruksjonen vil prosjektet sammen med linjen tydelig definere og avklare hvilke kriterier som må være oppfylt for at et sprint kan anses som "ferdig". Dette vil senere gjøre det enkelt å verifisere sprinten. 25

26 For å sikre helheten i Skatteetatens fremtidige IT-arkitektur vil den nye folkeregisterløsningen utvikles i henhold til de målbilder og standarder som er trukket opp av etaten. Dette gir føringer for utviklingsstrategien. Modernisert infrastruktur og driftsarkitektur vil bli nyttiggjort av modernisert løsning, men etableres av et eget prosjekt i Skatteetaten kalt Modernisering av Plattform (MAP). MAP-prosjektet vil få øremerkede midler gjennom prosjekt modernisering av Folkeregisteret, i henhold til beskrivelse i satsingsforslaget fra november Strategi for test Som en videreutvikling av FSUM har SITS utarbeidet en egen testmetodikk. Denne fokuserer på å oppnå høy dekningsgrad på de automatiserte testene. Prosjektet legger til grunn bruken av denne metodikken i hovedprosjektet. Test henger tett sammen med utvikling da målene for test er å avdekke feil og mangler så tidlig som mulig i utviklingsprosessen. Det legges derfor opp til både manuelle og automatisert tester som kjøres fortløpende ved innsjekk av nye komponenter, for å sikre høy kvalitet i alle ledd, og for å avdekke tekniske og funksjonelle feil så tidlig som mulig. Utover dette vil hver sprint gjennomgå enhets-, integrasjons- og systemtester, før den til slutt blir verifisert som "ferdig" gjennom et såkalt kontrollpunkt. I praksis er dette en utvidet demo, hvor man går dypere ned i detaljene. Kontrollpunktet er etablert for å sikre at scrum-teamene får rask respons på koden de har utviklet, samt at den danner grunnlag for godkjenning av levert funksjonalitet etter sprint. Når alle sprintene innenfor en leveranse er verifiserte vil de gjennomgå systemintegrasjonstest for å sikre en velfungerende og helhetlig ende-til-ende løsning. Deretter går man over i steget Godkjenning. Arbeidet med testoppgavene vil starte allerede ved utarbeidelsen av kravspesifikasjonene i forprosjektet, og som et ledd i ferdigstillingen av disse vil delprosjektet Test senere i hovedprosjektet etablere testspesifikasjoner. Testmetodikken skal bidra til utformingen av prosjektets detaljerte teststrategi- og plan, der det blant vil beskrives hvilke typer tester som skal gjennomføres, når og av hvem, akseptable testnivåer, samt hvilke testmiljøer og testdata det vil være behov for Strategi for Godkjenning Etter Konstruksjon følger steget Godkjenning. Her testes alle scenarier, oppgaver og arbeidsprosesser. Disse testene danner grunnlaget for endelig godkjenning av systemet og dermed også for avslutning av hver leveranse og produksjonssettingen av denne. Det er ulik praksis og begrepsbruk i smidig testmetodikk knyttet til godkjenningsprøve (GP) og akseptansetest (AT). Noen prosjekter utfører kun én av disse, mens andre prosjekter utfører begge. Dette har ofte sammenheng med hvordan sprintene er blitt testet og godkjent underveis i utviklingsløpet. Prosjektet MF legger til grunn omfattende tester etter hver sprint, noe man forventer vil redusere antall feil i steget Godkjenning. Dette er både kostnadseffektivt og psykologisk gunstig for mottakerorganisasjonen fordi dette skaper tillit til systemet og gjør det enklere å produksjonssette. Dermed vil den siste og endelige testen av hver leveranse før produksjonssetting være godkjenningsprøven. Prosjektet planlegger derfor 4 godkjenningsprøver, én for hver hovedleveranse. Godkjenningsprøvene skal planlegges av delprosjektet Test og utføres gjennom involvering av sluttbrukerne. Med sluttbrukerne menes her både saksbehandlere, personer og eksterne virksomheter. Blant de viktigste akseptansekriteriene for godkjenningstesten er at organisasjonen er i stand til å forvalte løsningen på egen hånd, noe som krever kapasitet og kompetanse både på forretningssiden og i forhold til infrastruktur, drift og overvåkning på teknisk side Strategi for regelverk I forkant av hovedprosjektet skal Finansdepartementet ha ferdigstilt arbeidet med revidert lov om folkeregistrering. Det er for tiden usikkert om loven vil være trådt i kraft før hovedprosjektet starter. Det vil uansett være behov for nye avklaringer og utredninger, som et resultat av gjenstående og 26

27 uavklarte diskusjoner fra forprosjektet samt inn mot arbeid med nye forskrifter til loven. Dette vil gi grunnlag for videre arbeid i hovedprosjektet. Strategien for regelverksarbeidet i hovedprosjektet er å håndtere følgende fire hovedaktiviteter: Identifisere og utrede både lov- og forskriftsendringer i folkeregisterregelverket. Utredningene kvalitetssikres gjennom Skattedirektoratets Rettsavdeling (SKD RE). Videre lov og forskriftsbehandling forestås av nevnte avdeling i samarbeid med Finansdepartementet. Prosjektets delprosjekt for Regelverk vil bistå inn i dette arbeidet. Utredninger og avklaringer av juridiske problemstillinger som ikke krever regelverksendringer. Utredningene vil i hovedsak berøre prosjektinterne lov/forskriftstolkninger knyttet til nye forretningsprosesser, særlig i forbindelse med detaljering, utvikling og programmering. Dette kan eksempelvis omfatte rettslige begrepsavklaringer og dokumentasjonskrav. Disse vurderingene vil foretas i samarbeid med SKD RE. Delta i utarbeidelsen av og være ansvarlig for den juridiske kvalitetssikringen av saksbehandlingsrutiner for de nye forretningsprosessene. Dette omfatter både saksbehandlingsrutiner for manuell og maskinell håndtering. Kommunikasjon med interne og eksterne samarbeidspartnere om juridiske forhold av betydning for løsningen. De folkeregisterrettslige endringene må kommuniseres og forankres internt og eksternt. Dette omfatter, foruten interne avdelinger, samarbeidende og berørte eksterne aktører som eksempelvis Helse, UDI og NAV. Dette vil foregå gjennom møter og skriftlig korrespondanse. Den enkelte eksterne aktør bærer imidlertid ansvaret for å implementere eventuelle nødvendige endringer i egne regelverk. Delta i opplæringstiltak overfor interne saksbehandlere. Dette omfatter særlig de juridiske sider av nye saksbehandlingsrutiner. De to siste punktene ovenfor vil gjennomføres i tett samarbeid med delprosjekt Innføring, som skal bidra til å sikre at nye rutiner blir implementert og tatt i bruk av sluttbrukerne og at tilstøtende samarbeidspartner får nødvendig informasjon i tide til å gjennomføre tilsvarende endringer/tilpasninger på sin side Strategi for innføring Det skal gjennomføres en rekke tiltak som skal sikre effektiv arbeidsorganisering og optimal bruk av den nye løsningen. For å sikre at interne og eksterne brukere raskt og effektivt er i stand til å nyttiggjøre seg de fordelene som modernisert folkeregisterløsning tilbyr, vil det utarbeides en mer detaljert innføringsplan i tiden frem mot oppstart av hovedprosjektet. Strategien for innføring bygger på Skatteetatens Endrings- og innføringsmetode. Her deles innføringen inn i fire hovedfaser, hver med en konkret hensikt. Figuren under viser disse hensiktene og hvilke spørsmål som hver av fasene skal kunne besvare. Den faseinndelte innføringen er en repetitiv prosess som vil gjentas for hver av prosjektets hovedleveranser. 27

28 Figur 4: Faseinndelt innføring Delprosjekt Innføring vil i samarbeid med linjen være ansvarlig for å gjennomføre de tiltak som må til for å få moderniserte løsninger til å virke hos interne og eksterne parter. Egne team innenfor delprosjektet vil være ansvarlig for å håndtere de ulike områdene som omfattes av innføringsmetodikken: 1. Informasjon, kommunikasjon og forankring - Prosjektet vil fortsette å ha løpende kontakt med sentrale interessenter for å sikre forankring, få støtte for beslutninger og sørge for at brukerne av Folkeregisteret er forberedt på endringene. Dette for at overgangen fra dagens til modernisert løsning skal bli så smidig som mulig, og for å sikre at gevinstpotensialet kan realiseres. Teamet for Informasjon, kommunikasjon og forankring vil skape eierskap og forståelse, og gi interessentene den informasjonen de trenger gjennom ulike kanaler, samt ved workshops, møter, presentasjoner, arbeidsnotater og liknende. 2. Interessentoppfølging - Interessentoppfølging innebærer å ivareta samarbeidet med eksterne aktører i forhold til innføring, ha arenaer og fastsatte fora for å fange opp behov, og ta med tilbakemeldinger tilbake til prosjektet for å håndtere dette på en koordinert og strukturert måte. Dette vil bidra til å sikre at viktige signaler fra interessenter fanges opp og håndteres underveis. 3. Opplæring og kompetanseutvikling Teamet for Kompetanse skal sammen med linjen sikre nødvendige læringstiltak for at interessentene endrer atferd, dyktiggjøres og forstår hvilke roller og saksbehandlingsrutiner som inngår i nye løsninger. Kompetanse skal besvare hvorfor noe endres, hva som skal gjøres, hvordan det skal gjøres, av hvem og når. Opplæring omfatter derfor områdene regelverk og rutiner, arbeidsprosesser og organisering, IT-løsninger og saksbehandling. Derfor vil delprosjektene Regelverk og Løsning bidra i opplæringen av relevante brukere. Innføringsprosjektet vil ha koordineringsansvaret for alle nødvendige saksbehandlingsrutiner. Teknisk og driftsdokumentasjon er unntatt. Delprosjekt Løsning og Regelverk vil bidra både til utarbeidelsen og kvalitetssikringen av saksbehandlingsrutinene, som deretter vil integreres i løsningen av delprosjektet Utvikling. Delprosjektet Innføring vil kvalitetssikre fra et kommunikasjonsståsted. Både linjen og Fagrådet vil ha en aktiv rolle i utformingen, kvalitetssikringen og implementeringen av saksbehandlingsrutinene. 4. Organisasjonsutvikling - Organisasjonsutvikling omfatter de «strukturelle» elementene som må være på plass og tilpasses for å ta i bruk Folkeregisterets nye løsninger på en mest mulig effektiv måte. Modernisert løsning vil medføre effektiviseringer og endring av prosesser, bortfall av oppgaver for noen aktører og tilførsel av nye/endrede oppgaver for andre. For at Folkeregistermyndigheten skal fungere optimalt med moderniserte løsninger, må dagens organisering og organisasjon endres. Dette arbeidet vil ledes av linjen i tett samarbeid med prosjektet. 5. Gevinstplanlegging - Innføringsprosjektet vil fortløpende kvalitetssikre, oppdatere/justere og rapportere gevinstrealiseringsplanene. Gevinstrealiseringsplaner forankres med og overleveres 28

29 til gevinsteier ved prosjektets avslutning. Leder for Regionavdelingen vil være ansvarlig for å realisere beregnede prissatte gevinster for Skatteetaten. Prosjektet vil, sammen med linjen og i forkant av hovedprosjektet, påbegynne arbeidet med utformingen av en mer konkret handlingsplan. Denne vil blant annet beskrive hvordan samhandlingen skal foregå, hvilke krav som stilles til prosjektet og linjen, hvilken ressursbelastning dette vil kreve, samt en tidsplan for sentrale aktiviteter og leveranser. Dette i motsetning til gevinst (realiserings-) planene som gir en beskrivelse av hvilke effekter som skal oppnås som følge av prosjektgjennomføringen, hvordan disse skal realiseres, av hvem, innen når og hvordan. Et utgangspunkt for gevinstplanene er beskrevet i avsnitt 4.8. Gevinstrealiseringsplaner vil utformes løpende underveis i hovedprosjektet, og forankres med berørte parter. Leveranser som støtter opp under de ovennevnte innføringsaktivitetene beskrives nærmere i avsnitt Strategi for overgang til ny løsning Overgangsstrategi Prosjektet har valgt en inkrementell tilnærming ved overgangen fra eksisterende til ny løsning. Dette innebærer at når ny funksjonalitet er implementert, vil den innføres gradvis og erstatte eksisterende (såfremt denne finnes), eventuelt tilby ny funksjonalitet. Dette betyr også at i en gitt periode vil eksisterende og ny løsning koeksistere med hverandre, noe som vil stille høye krav til et tett og velfungerende samarbeid mellom prosjektorganisasjonen og linjeorganisasjonen. Prosjektets plan for overgang henger sammen med prosjektets leveranseplan. I sistnevnte legges det opp til 4 hovedleveranser. I tillegg planlegges det løpende og kontinuerlige aktiviteter knyttet til paralleldriften. Hver av prosjektets hovedleveranser skal ferdigstilles slik at de i prinsippet skal kunne driftssettes i produksjonsmiljøet. Hvorvidt leveranse faktisk vil produksjonssettes er noe som vil måtte detaljplanlegges nærmere leveranseslutt Pilot (og prøvedrift) I en inkrementell overgang legges det opp til flere produksjonssettinger over tid. Dette betyr at det i en gitt periode vil foregå parallell drift av både gammel og ny løsning. Prosjektet jobber med en migreringsstrategi som vil beskrive hvordan dette skal håndteres i praksis. Produksjonssetting av ny løsning vil kunne foregå enten gjennom pilotdrift eller direkte i produksjon for samtlige brukere. Pilotdrift brukes i denne sammenheng som et begrep for at hele eller enkelte tjenester fra ny løsning produksjonssettes og tilgjengeliggjøres for et utvalg av brukere. Prosjektet vil også vurdere prøvedrift, også kalt skyggedrift, som en mulig aktivitet for å avdekke feil/mangler tidligere enn gjennom pilotdriften. I en prøvedrift vil modernisert løsning tilgjengeliggjøres fra et testmiljø for at brukere skal kunne sammenligne resultater fra denne med resultatene fra eksisterende folkeregister i produksjon. I skrivende stund er det planlagt å gjennomføre minst én pilotdrift. Denne pilotdriften skal bidra til å avdekke og korrigere eventuelle feil/mangler/avvik før de resterende brukerne kobles på. I Figur 5 under har man skissert muligheten for at hele leveranse 1 vil inngå i første pilotdrift. Endelig oppstart av denne pilotdriften, hva den skal inneholde samt hvilke eksterne og interne brukere som skal delta er under planlegging og vil kunne ferdigstilles først når teknologi er valgt og en initiell produktkø utarbeidet. Disse planene vil og samkjøres og justeres i samarbeid med eventuell(e) leverandør(er). 29

30 Figur 5: Strategi for overgang fra eksisterende til modernisert løsning. Modernisert løsning illustreres gjennom de planlagte 4 hovedleveransene, mens eksisterende løsning illustreres gjennom funksjonalitet A- E. Etterhvert som hovedleveransene produksjonssettes vil tilsvarende funksjonalitet i eksisterende løsning kunne saneres Utfordringer Det er identifisert en rekke utfordringer knyttet til overgangen fra eksisterende til ny løsning. Enkelte av disse utfordringene skyldes valget om inkrementell overgang, mens andre er uavhengig av hvilken overgangsstrategi som blir gjeldende. Behovet for å håndtere disse er uansett tilstede og vil tas med i det videre planleggingsarbeid. Ikke én-til-én relasjon mellom ny og gammel funksjonalitet. Nye krav og behov til effektivisering, kvalitet, brukervennlighet, osv. medfører nye krav til funksjonalitet. Ny funksjonalitet innebærer bruk av ny teknologi, nye prosesser, nye datamodeller, nye grensesnitt osv. Som følge av dette vil det ikke være en én-til-én relasjon mellom funksjonaliteten i gammel og ny løsning. Eksisterende løsning er ikke modulær. Dagens løsning er kompleks og ikke utviklet modulært. Det vil derfor være vanskelig å fjerne enkelte deler av eksisterende løsningen uten at dette har en direkte påvirkning på andre deler. Dette, sammen med punktet over, vil være en stor utfordring for hvordan inkrementer (dvs. ny funksjonalitet) produksjonssettes og eksisterende funksjonalitet fases ut. Eksisterende løsning bygger på en DB2 database på stormaskin. Utfordringen ligger blant annet i ulike datastrukturer og et generelt ulikt løsningsmønster. I tillegg kjører databasene forskjellige operativsystemer som leveres fra ulike teknologileverandører. Dette skaper kompatibilitetsproblemer i parallell drift. Datakonsistens. Eksisterende løsning vil fungere som masterdatakilde for eksisterende funksjonalitet som gradvis fases ut og erstattes av inkrementer med ny funksjonalitet, mens ny 30

31 løsning vil fungere som masterdatakilde for helt ny funksjonalitet som ikke tilbys i eksisterende løsning. Håndteringen av datakonsistensen vil foretas gjennom en egen applikasjon som skal sørge for en toveis oppdatering og synkronisering av eksisterende og ny løsning. Tett kobling fra eksterne systemer. Folkeregisteret distribueres i dag med fulle kopier og inkrementelle endringsfiler til flere konsumenter, for eksempel til helse- og omsorgssektoren. I modernisert løsning skal distribusjon av kopier, som gjenspeiler dagens filformat og struktur, videreføres i en viss periode. Dette skaper utfordringer ved at man må levere en bakoverkompatibel og "dårligere" kopi/fil basert på en ny datamodell. Sikkerhet. Eksisterende løsning kjører på samme kjøretidsmiljø som enkelte andre interne tilårskomne skattesystemer. Ny løsning vil kjøre på et eget kjøretidsmiljø, separert fra disse skattesystemene. Dette betyr at gammel og ny løsning vil ligge i to ulike sikkerhetssoner, noe som kan by på utfordringer knyttet til synkronisering av data gjennom flere brannmurer. I forkant av hovedprosjektets oppstart er det planlagt å gjennomføre en rekke øvelser, såkalte proof-ofconcepts (PoC). Disse øvelsene vil ta utgangspunkt i blant annet utfordringene over og utforske mulige forbedringstiltak for å håndtere de. Dette vil bidra til å senke usikkerheten knyttet til overgangen til ny løsning Fallbackstrategi Som en del av det å bevege seg mot kontinuerlige leveranser vil Prosjektet utarbeide systemer for tilnærmet automatisk utrulling av nye versjoner av komponenter til et hvilket som helst miljø både test og produksjonsmiljøer. På samme måte vil dette systemet tilby rollback muligheter slik at man umiddelbart kan rulle tilbake til forrige trygge versjon av en komponent dersom det til tross for grundig automatisk og manuell testing likevel viser seg at komponenten forårsaker problemer. Disse systemene vil være klare tidlig i utviklingsløpet for å minimalisere risiko ved og sikre produksjonssetting av komponenter Overlevering fra prosjekt til linje Overlevering fra prosjektet til linjen inntreffer ved hver produksjonssetting. Gitt prosjektets foreløpige leveranseplan betyr dette potensielt 4 driftssettinger. Ettersom moderniseringen medfører et teknologiskifte for Skatteetaten, spesielt for sluttbrukerne/linjeorganisasjonen, vil det være viktig at man sikrer riktig og tilstrekkelig med kompetanse i linjen før overleveringen skjer. Oppbyggingen og overføringen av denne nødvendige kompetansen gjøres løpende av prosjektet i tett samarbeid med linjen. Etter at prosjektet avsluttes skal Skatteetaten ha alle rettigheter til løsningen samt være i stand til å drifte og forvalte ny løsning på egenhånd. Derfor er det kritisk at de interne ressursene i hovedprosjektet skal ha roller og ansvar som ansees som strategisk viktige for Skatteetaten. Dette vil sikre at løsningen utvikles i samsvar med etatens egne føringer, prinsipper og rammer, og at virksomhetskritisk kompetanse beholdes internt. Eksempler på slike roller og kompetanse vil være innen prosjektledelse, behovsanalyse, krav- og løsningsspesifisering (særlig under regelverksutvikling), men også i godkjenningen av sprinter og leveranser. Ressurser i folkeregisterets fagavdelinger som tas ut av produksjon for å delta i prosjektet vil i stor grad bli erstattet med enten nye eller midlertidige ansettelser (f.eks. vikarer). En tilfredsstillende implementering og innføring vil sikres gjennom delprosjektet Innføring og ved å involvere linjeressurser i de øvrige delprosjekter (f.eks. delprosjektene Løsning og Utvikling). 3.2 Kontrakts- og anskaffelsesstrategi I dette kapittelet beskrives kontraktsstrategien for prosjektet Modernisering av Folkeregisteret. Kontraktsstrategien skal beskrive hvordan man sikrer hensiktsmessig konkurranse i utvelgelsesfasen, hvordan man fordeler oppgaver, ansvar og usikkerhet, og hvilke kontraktuelle virkemidler som bør være etablert for å understøtte styring i gjennomføringsfasen. 31

32 Denne kontraktsstrategien gjelder leverandørsiden av prosjektet. Kundesiden av prosjektet vil i utgangspunktet håndteres med ressurser fra Skatteetaten. Dersom det skulle oppstå behov for ekstern bistand på kundesiden så vil prosjektet håndtere dette ved avrop på Skatteetatens eksisterende rammeavtaler for konsulentbistand. For en utdypning i de vurderingskriteriene som ligger til grunn i drøftelsen og anbefalingen, se Vedlegg B Føringer for kontraktsstrategien Under beskrives føringer som legges til grunn for kontraktsstrategien. For gjeldende rammebetingelser, se avsnitt Skatteetatens IT-strategi ( ) I Skatteetatens IT-strategi ( ) understrekes det at markedet skal benyttes der det finnes et fungerende marked. Følgende prinsipper er nedfelt: Markedsløsninger skal benyttes på alle områder av IT-funksjonen, med mindre andre hensyn tilsier noe annet. Etaten har ikke kapasitet eller ressurstilgang som tilsier at alle områder av IT-funksjonen kan dekkes med utelukkende interne ressurser. Etaten må aktivt bruke markedet der hvor disse eksisterer og kontinuerlig søke å utnytte de deler av markedet hvor kostnadseffektiviteten til etaten tilsier det. Ekstern kompetanse skal benyttes på områder som av kapasitets- eller kompetansehensyn ikke anses som strategiske av etaten. Arbeidet skal utføres der kostnadseffektiviteten er høyest for Skatteetaten, hvilket innebærer at de ulike delene av IT-funksjonen må vurderes opp mot de løsninger som markedet tilbyr SITS sourcingstrategi Som en del av den ovennevnte IT-strategien, finner man SITS sin egen sourcingstrategi. Denne strategien omhandler hvilke tjenester som skal anskaffes fra eksterne tjenesteleverandører og hvilken kompetanse det er strategisk viktig at etaten selv besitter. Mao indikerer strategien hvilke kompetanseog funksjonsområder som anbefales at bemannes av interne ressurser og hvilke som kan at bemannes av eksterne ressurser. Strategien skal sørge for at SITS til enhver tid innehar kritisk kompetanse for å effektivt videreutvikle systemporteføljen, med eller uten hjelp av eksterne. Målsettingen er å understøtte og øke den totale utviklingskapasiteten og -kompetansen, samtidig som kostnader reduseres gjennom mer effektiv drift og forvaltning Prinsipper for anskaffelser i Skatteetaten Følgende overordnede prinsipper gjelder for alle anskaffelser i Skatteetaten: Anskaffelser skal ha sitt grunnlag i vedtatte planer og budsjetter. Anskaffelser skal gjennomføres på en slik måte at Skatteetatens behov blir dekket og det oppnås rett kvalitet til best mulige betingelser. Det skal legges vekt på å oppnå økonomiske gevinster eller driftsmessige fordeler gjennom koordinering og samordning av anskaffelser. Skatteetaten skal ha en mest mulig profesjonell, enhetlig og forutsigbar opptreden overfor leverandørene i samsvar med god forretningsskikk. Alle som er involvert i anskaffelser skal utføre arbeidet i henhold til etatens etiske retningslinjer. Utviklingsmetodikk Dette prosjektet har valgt smidig utviklingsmetodikk (se avsnitt 3.1.1). Dette valget gir en fleksibilitet i kunde- og leverandørrelasjonen som svarer godt på flere av de utfordringene som påpekes i forbindelse med risikobildet. 32

33 Skatteetaten har opparbeidet mye erfaring med gjennomføring av systemutviklingsprosjekter gjennom å dele utviklingen og konstruksjonen inn i mindre utviklings- og testløp. Slike sprinter har bidratt til fortløpende læring, og nødvendig justering av krav og funksjonalitet for å sikre samsvar mellom faktiske behov og levert løsning i tidligere prosjekter. Denne utviklingsmetodikken setter imidlertid noen krav til både leverandører og kundesiden i prosjektet. For det første må kontraktspartnerne prioritere ressurser med denne type smidig kompetanse, både i forhold til prosjektledere, teamledere og kontrakts-/forhandlingsansvarlige. Dernest bør smidig utviklingsmetodikk gjenspeiles i både kontraktsvalget (i retning smidig) og de vederlagsordningene som velges (i retning balansere risiko) Alternative kontraktsstrategier Prosjektet har vurdert følgende fire alternative kontraktsstrategier: Alternativ 1: Totalleveranse Alternativ 2: Delleveranser Alternativ 3: Egenregi og enkeltoppdrag Alternativ 4: Egenregi I avsnittene nedenfor følger en nærmere beskrivelse av de ulike alternativene Alternativ 1: Totalleveranse Beskrivelse En totalleveranse innebærer at samtlige leveranser konkurranseutsettes til én ekstern leverandør. Leverandøren får resultatansvar for hele leveransen og er også systemintegrator. Ansvaret for kontraktsoppfølging, prosjektstyring, oppfølging av fremdrift, endringshåndtering, innføring av løsningen og juridiske avklaringer ligger hos Skatteetaten. Skatteetaten må påregne å stille med fagekspertise, funksjonelle arkitekter, tekniske arkitekter og testere til leverandøren. Anskaffelsesprosedyre For dette alternativet kan anskaffelsesprosedyrene konkurransepreget dialog eller konkurranse med forhandling være aktuelle. Konkurransepreget dialog er mest aktuelt i situasjoner der man i større grad velger å fokusere på de overordnede behovene og i mindre grad på detaljerte funksjonskrav i selve konkurransegrunnlaget. I dette prosjektet har man kommer relativt langt i sitt arbeid med å spesifisere behov og funksjonskrav til ønsket løsning. Konkurransepreget dialog har ennå ikke vært benyttet som prosedyre i Skatteetaten, mens etaten har omfattende erfaring med konkurranse med forhandling. På bakgrunn av dette anbefales konkurranse med forhandling som prosedyre ved alternativ 1. Kvalifikasjonskrav og tildelingskriterier Siden leverandøren i dette alternativet skal ha et totalansvar for leveransen anbefales det å stille høye kvalifikasjonskrav til både leverandørens økonomiske/finansielle kapasitet og teknisk/faglige kompetanse. Når det gjelder tildelingskriterier anbefales det å velge det økonomisk mest fordelaktige tilbud med underkriteriene Pris og Kvalitet. Kontraktsstandard Ved en slik totalleveranse vurderes SSA-S eller PS2000 Smidig som mulige kontraktsstandarder. SSA-S er foreløpig lite benyttet i praksis og det er derfor lite erfaring med bruken av den. Dette medfører at det ikke er et realistisk alternativ å benytte SSA-S i dette prosjektet da det er for risikofylt å prøve ut denne standarden i et såpass stort prosjekt. PS 2000 Smidig er velprøvd i både offentlig og privat sektor, og er meget godt tilpasset til smidig metoder. På bakgrunn av dette vurderes PS2000 Smidig som den mest hensiktsmessige kontraktsstandard for dette alternativet. Kompensasjonsformat 33

34 Fastpris fordrer at kravene er beskrevet i detalj og at usikkerheten er lav. Målpris er egnet i alle situasjoner mellom disse ytterpunktene. Målpris egner seg godt i smidige utviklingskontrakter fordi den tilrettelegger for tett og likeverdig samarbeid mellom kunde og leverandør. Målpris med deling av incentiver og sanksjoner sikrer at kunde og leverandør jobber mot samme mål. Dessuten er målpris godt integrert som kompensasjonsformat i PS2000 Smidig kontraktstandard. På bakgrunn av dette vurderes Målpris som mest hensiktsmessig for dette strategialternativet Alternativ 2: Delleveranser Beskrivelse Delleveranser innebærer en konkurranse hvor flere eksterne leverandører gis muligheten til å tilby å levere én eller flere av prosjektets definerte delleveranser. Den enkelte leverandør vil ha resultatansvar for den eller de delleveransene han er tildelt kontrakt på. Skatteetaten har ansvaret for den totale systemleveransen og er systemintegrator. Ansvaret for kontraktsoppfølging, prosjektstyring, oppfølging av fremdrift, endringshåndtering, innføring av løsningen og juridiske avklaringer ligger hos Skatteetaten. Skatteetaten må påregne å stille med fagekspertise, funksjonelle arkitekter, tekniske arkitekter og testere til leverandørene. Anskaffelsesprosedyre For dette alternativet kan anskaffelsesprosedyrene konkurransepreget dialog eller konkurranse med forhandling være aktuelle. Konkurransepreget dialog er mest aktuelt i situasjoner der man i større grad velger å fokusere på de overordnede behovene og i mindre grad på detaljerte funksjonskrav i selve konkurransegrunnlaget. I dette prosjektet har man kommer relativt langt i sitt arbeid med å spesifisere behov og funksjonskrav til ønsket løsning. Konkurransepreget dialog vurderes som mest aktuelt der hvor man skal inngå kontrakt med bare en ekstern leverandør. Konkurransepreget dialog har ennå ikke vært benyttet som prosedyre i Skatteetaten, mens etaten har omfattende erfaring med konkurranse med forhandling. På bakgrunn av dette anbefales konkurranse med forhandling som prosedyre ved alternativ 2. Kvalifikasjonskrav og tildelingskriterier Siden leverandørene i dette alternativet skal ha leveranseansvar anbefales det å stille høye kvalifikasjonskrav til både leverandørens økonomiske/finansielle kapasitet og teknisk/faglige kompetanse. Når det gjelder tildelingskriterier anbefales det å velge det økonomisk mest fordelaktige tilbud med underkriteriene Pris og Kvalitet. Kontraktsstandard Kontraktsstandarden PS2000 Smidig er vurdert som det beste alternativet. Vi viser til vurderingene under alternativ 1 i avsnitt overfor. Kompensasjonsformat Målpris vurderes også her som det beste alternativet. Vi viser også her til vurderingene i avsnitt overfor Alternativ 3: Egenregi og enkeltoppdrag Beskrivelse Dette alternativet innebærer en kombinasjon av at prosjektet har ansvaret for de fleste leveranser i egenregi og at flere eksterne leverandører leverer enkeltoppdrag til prosjektet. De eksterne leverandørene har resultatansvar for de enkeltoppdrag de blir tildelt underveis i prosjektet. For den delen av leveransene som gjennomføres i egenregi vil det inngås parallelle rammeavtaler med flere leverandører for å levere enkeltressurser/team. Ved behov kan det være aktuelt å supplere disse med å foreta avrop på Skatteetatens eksisterende rammeavtaler for konsulenttjenester. Skatteetaten har ansvaret for den totale systemleveransen og er systemintegrator. Ansvaret for kontraktsoppfølging, prosjektstyring, oppfølging av fremdrift, endringshåndtering, innføring av løsningen og juridiske 34

35 avklaringer ligger hos Skatteetaten. Skatteetaten må påregne å stille med fagekspertise, funksjonelle arkitekter, tekniske arkitekter og testere til leverandørene. I tillegg vil det kunngjøres en konkurranse for å inngå parallelle avtaler med flere leverandører som skal konkurrere om enkeltoppdrag underveis i prosjektet. Anskaffelsesprosedyre Anskaffelsen(e) anbefales gjennomført som en konkurransepreget dialog eller konkurranse med forhandling. Kvalifikasjonskrav og tildelingskriterier Det anbefales å stille kvalifikasjonskrav til både leverandørens økonomiske/finansielle kapasitet og teknisk/faglige kompetanse. Kravene kan være noe mer moderate enn for alternativene 1 og 2. Når det gjelder tildelingskriterier anbefales det å velge det økonomisk mest fordelaktige tilbud med underkriteriene Pris og Kvalitet. Kontraktsstandard For den delen som omfatter egenregi av enkeltressurser/team vil prosjektet benytte Skatteetatens eksisterende rammeavtaler. Videre vil prosjektet vurdere PS2000 SOL som kontraktsstandard. For den delen som gjelder leveranser av enkeltoppdrag vil prosjektet ta i bruk den kontraktsstandarden som viser seg å være mest egnet til det konkrete oppdraget. Kompensasjonsformat For enkeltoppdrag kan flere vederlagsmodeller være aktuelle. Ulike varianter av fastpris, timepriser og målpris kan anvendes. Målpris vurderes imidlertid som best egnet da denne løsningen balanserer risikoen godt mellom kundesiden og leverandørsiden. Målpris egner seg godt i smidige utviklingskontrakter, og slik vederlagsform er godt integrert i PS2000 SOL. For rammeavtalene med ren konsulentbistand er timepris det mest aktuelle kompensasjonsformat Alternativ 4: Egenregi Beskrivelse Egenregi innebærer at Skatteetaten selv har alt leveranse- og gjennomføringsansvar (inkludert styring og risiko) for alle leveransene. Skatteetatens egne ressurser suppleres ved behov av enkeltressurser/team fra eksterne leverandører. Det gjennomføres en konkurranse hvor det inngås parallelle rammeavtaler med flere leverandører om konsulentbistand. Disse rammeavtalene omfatter utelukkende adgang til å avrope enkeltressurser/team på timesbasis. Ved behov kan det være aktuelt å supplere disse med å foreta avrop på Skatteetatens eksisterende rammeavtaler for konsulenttjenester. Denne strategien har tidligere vært benyttet i Skatteetatens prosjekter EDAG og MAG, og benyttes nå i SOFUS. Anskaffelsesprosedyre En anskaffelse av rammeavtaler om konsulentbistand vil gjennomføres som åpen eller begrenset anbudskonkurranse. Det antas at vilkårene for å benytte prosedyrene konkurransepreget dialog eller konkurranse med forhandling ikke vil være oppfylt. Kvalifikasjonskrav og tildelingskriterier Det anbefales å stille kvalifikasjonskrav til både leverandørens økonomiske/finansielle kapasitet og teknisk/faglige kompetanse. Kravene kan være noe mer moderate enn for alternativene 1 og 2. Når det gjelder tildelingskriterier anbefales det å velge det økonomisk mest fordelaktige tilbud med underkriteriene Pris og Kvalitet. Kontraktsstandard Som kontraktsstandard vil Skatteetatens egne rammeavtale for konsulenttjenester benyttes. Kompensasjonsformat For rammeavtaler om konsulentbistand er timepriser det aktuelle kompensasjonsformat. 35

36 3.2.3 Oppsummering og anbefaling av kontraktsstrategi Både alternativ 1 og 2 vurderes å medføre relativ høy risiko da det innebærer en sterk avhengighet til den eller de leverandørene som har leveranseansavaret. Det er også slik at valgt realiseringsstrategi og forprosjektet ikke er rigget for å en slik strategi, og det vil kreve mye innsasts fra kritisk kompetanse i Skatteetaten å legge til rette for disse alternativene. Alternativ 3 og 4 vurderes å medføre vesentlig lavere prosjektrisiko enn alternativ 1 og 2. Lignende strategier har også vært byttet med suksess i andre større offentlige prosjekter som Perform (Statens pensjonskasse) og LØFT (Lånekassen). Alternativ 4 har vært benyttet med gode erfaringer i tidligere prosjekter i Skatteetaten, som MAG og EDAG. Alternativ 3 gir i tillegg ytterligere økt fleksibilitet ved at det gir mulighet for underveis i prosjektet å sette ut enkeltoppdrag på konkurranse mellom utvalgte leverandører Anbefaling På bakgrunn av utførte vurderinger, anbefaler prosjektet alternativ 3: Egenregi og enkeltoppdrag som kontraktsstrategi. 3.3 Organisering og ansvarsdeling Skattedirektoratet har besluttet at hovedprosjektet skal bemannes med inntil 70 % eksterne og 30 % etatsinterne ressurser. Den relativt store graden av eksterne ressurser har bakgrunn i flere forhold: Prosjektets profil og leveransenes art. I motsetning til flere av de andre store utviklingsprosjektene, vil mye av utviklingsarbeidet i dette tilfellet ikke være av virksomhetsunik karakter. Det er derfor enklere og mer forsvarlig å kjøpe utviklingskapasitet i markedet. Det planlegges innleie av eksterne konsulenter med spesialkompetanse på verktøy og øvrige kompetanseområder som organisasjonen mangler. Investering i en nasjonal felleskomponent. Da effektene av moderniseringen kommer alle brukerne til nytte, mener Skattedirektoratet at det er forsvarlig med en høyere konsulentandel enn vanlig. Direktoratets ressurssituasjon under gjennomføringsperioden. En rekke andre store etatsinterne prosjekter vil pågå samtidig og kreve beslag på interne ressurser. Sistnevnte påvirker valg knyttet til gjennomføringen av pilot- og prøvedrift. Disse aktivitetene vil kreve en innsats og forpliktelse av forvaltningsorganisasjonene internt i Skatteetaten og eksternt hos berørte aktører, og dermed vil det være spesielt viktig for Skatteetaten å vurdere disse aktivitetene opp mot bemanningssituasjonen i SITS. Under følger en oversikt over prosjektets interne organisering, både i forhold til overordnet fagdepartement og andre aktuelle organer i og utenfor etaten. Det gis en beskrivelse av hvilke fullmakter og mandat de ulike organene og/eller instansene har Beslutningsstruktur Prosjektet vil motta øremerkede midler fra Finansdepartementet og vil derfor i stor grad følge modellen for prosjektstyring som er beskrevet i Skatteetatens prosjektstyringsbok. Modellen gir tydelige føringer for organiseringen og styringsregimet rundt og i prosjektorganisasjonen. I tillegg er modellen tilpasset de erfaringer etaten har gjort seg i forbindelse med gjennomføringen av MAG og EDAG prosjektene. 36

37 Figur 6: Organisering av Prosjekt Modernisering av Folkeregisteret Teksten under gir en overordnet beskrivelse av de mest sentrale aktørene i prosjektets beslutningsstruktur. For en mer detaljert beskrivelse henvises det til Skatteetatens prosjektstyringsbok. Finansdepartementet (FIN) er ansvarlig departement for prosjektet. FIN fastsetter rammene for gjennomføringen av prosjektet og styrer prosjektet etter foreslått kostnadsramme (P85). Skattedirektøren rapporterer direkte til FIN gjennom møter i Kontaktforum, hvor hovedlinjene i prosjektet gjennomgås: fremdrift, status, avvik, risiko og økonomi. I kontaktforumet sitter også representanter for hver av de samarbeidende departementer og eksterne mottaksprosjektene. Skattedirektoratet (SKD) har ansvaret for prosjektgjennomføringen. Dette utøves styringsmessig gjennom direktoratets prosjektansvarlig, Skattedirektøren, som har ansvaret for at hovedprosjektet gjennomføres på en godt koordinert måte og i henhold til omfanget, framdriften og kostnadsrammene (P50) som framgår av dette dokument. Ved behov, kaller skattedirektøren inn de berørte etatslederne til møte. Styringen utøves gjennom Skattedirektørens ledelse av: Skattedirektoratets ledergruppe (SLG), som består av lederne i avdelingene og stabene i direktoratet samt leder av SITS, Etatens ledergruppe (ELG) hvor regiondirektørene, direktør i Skatteopplysningen og medlemmer i SLG deltar, samt Porteføljestyret, som prioriterer og beslutter etatens utviklingsaktiviteter, herunder om prosjekter skal igangsettes eller stoppes. Styret har et helhetlig ansvar for Skatteetatens ressursbruk og skal bidra til å sørge for at nødvendig kompetanse fra hele virksomheten (SITS, SKD, region) blir gjort tilgjengelig for prosjektet ved behov. Det operative ansvaret for gjennomføringen er delegert til prosjekteier, som er direktør for Innovasjons- og utviklingsavdelingen i Skattedirektoratet. Prosjekteier etablerer og leder: ekstern styringsgruppe, som i tillegg består av prosjektleder og ansvarlig for endringer hos de 3 eksterne samarbeidsaktørene NAV, UDI og Helsedirektoratet. Formålet med gruppen er å koordinere aktiviteter, avklare behov og løfte eventuelle risikofaktorer. 37

38 SKD styringsgruppe, som i tillegg består av lederne i berørte avdelinger og staber i SKD, oppdragsansvarlig fra SITS og tjenesteeier for Folkeregisteret. Deltakerne i styringsgruppen må gjennom sin representasjon være i stand til å rådgi prosjekteier slik at vedkommende skal kunne å ta nødvendige beslutninger. I tillegg bistår styringsgruppen prosjektleder i håndteringen av saker med betydning for SKD og linjen. I henhold til Skatteetatens egen prosjektstyringsmetodikk oppfordres prosjekter av en viss størrelse, kompleksitet og risiko til å innhente ekstern bistand i kvalitetssikringen. Prosjektet har vurdert det som hensiktsmessig å engasjere en ekstern kvalitetssikrer for å sikre riktig gjennomføring av hovedprosjektet. Den eksterne kvalitetssikreren vil rapportere til prosjektets styringsgruppe (SKD). Prosjektleder er ansvarlig for den daglige ledelsen av prosjektet. Prosjektleder etablerer og organiserer SITS styringsgruppe. Styringsgruppen bistår prosjektleder med nødvendig støtte og raske beslutninger vedrørende forhold som berører SITS. Prosjektleder har i tillegg ansvar for løpende å holde orientert sentrale brukere av Folkeregisteret, representert gjennom prosjektets referansegruppe. Denne gruppen videreføres fra forstudiefasen til prosjektet og vil brukes til å forankre og avklare behov og løsning. Det etatsinterne fagrådet ledes av programleder MF og består av ledere eller bemyndigede innenfor aktuelle fagområder. Rådet tar faglige beslutninger og bistår prosjektleder og prosjektet med nødvendige faglige avklaringer, prioriteringer og anbefalinger. Delprosjektledere i prosjektet er ansvarlige for den operative gjennomføringen av de enkeltes delområder. Disse rapporterer regelmessig til prosjektleder. For mer utfyllende beskrivelse av roller og ansvar for prosjektleder og delprosjektledere, se avsnitt Figur 7: Intern organisering av prosjektet Forhold til sentrale eksterne interessenter Folkeregisteret brukes av svært mange private og offentlige aktører. Mange av aktørene som blir berørt av endringene i folkeregisterprosjektet er sentrale bidragsytere av informasjon (produsenter) og vil ha et særlig behov for en tett involvering gjennom hovedprosjektet. Det er særlig fire aktører som vil gjennomgå teknologiske og forretningsmessige endringer som følge av endrede prosesser og teknologi i modernisert løsning (se avsnitt for en beskrivelse av disse aktørene). Øremerkede midler skal sikre at nødvendige forberedelser og tekniske grensesnittstilpasninger til modernisert folkeregisterløsning i disse virksomhetene blir ivaretatt. For NAV, UDI og helsesektoren vil det opprettes egne mottaksprosjekter som vil være ansvarlige for leveranser på sin side. Rapporteringen fra ansvarlige for disse mottaksprosjektene vil gå direkte til prosjektleder i prosjekt MF. Den operative kommunikasjonen vil foregå på delprosjektnivå. Dialogen mellom prosjekt MF og leverandøren av et postadresseregister må avklares i forkant av hovedprosjektet. En mulig løsning er å betrakte opprettelsen av grensesnittet som en ordinær leveranse som prosjektet betaler for. Ansvaret for leveringen av postadresser avhenger av modernisert postlov, som er under høring våren

39 3.3.3 Forhold til program Prosjektet Modernisering av Folkeregisteret inngår i et program ved samme navn, og deler således samme styringsgruppe (SKD). Det vil likevel være et tydelig skille mellom og forventning til disse to. Prosjektleder vil være ansvarlig for prosjektets leveranser og rapportere på tid, kost og kvalitet direkte til prosjekteier og styringsgruppen (SKD). Programleder vil være ansvarlig for å inneha et helhetlig overblikk over samtlige aktiviteter og initiativ som berører moderniseringen av folkeregisteret, på flere områder enn kun de som inngår i prosjektets omfang. Både prosjekt- og programleder vil løpende holde hverandre orienterte og sammen koordinere saker og aktiviteter med felles interesse. Figur 8: Forhold mellom prosjektet og Program Modernisering av Folkeregisteret Roller og ansvarsdeling Hovedprosjektet for Modernisering av Folkeregisteret vil bestå av delprosjektene Regelverk, Løsning, Utvikling, Innføring og Test. Disse delprosjektene skal sammen sørge for at modernisert løsning, herunder ny systemteknisk folkeregisterløsning, understøttende lovverk, tilhørende forretningsmessige prosesser og aktiviteter, samt nødvendige innføringsaktiviteter, blir utformet og implementert. I tabellen under beskrives roller og ansvar for de ulike prosjektdeltagerne i prosjektets administrasjon: Aktør Prosjektleder Prosjektstab Delprosjektledere Roller, ansvar, fullmakt Prosjektleder har ansvaret for totalgjennomføringen av prosjektet, og rapporterer til prosjekteier. Prosjektleder er ansvarlig for prosjektets fremdrift, kvalitet og økonomi i daglig drift. Vedkommende ivaretar prosjektets ledende funksjon. Prosjektstaben skal støtte prosjektleder i det daglige og operative arbeidet med styringen av prosjektet, samt uføre de oppgavene som er spesifikt tillagt deres rolle. I Prosjektstab inngår følgende roller: Prosjektsekretær, som også er stedfortreder for prosjektleder Endringsansvarlig Kvalitetsansvarlig Risikoansvarlig Controller Delprosjektledere vil ha ansvar for den operative utførelsen av de til enhver tid gjeldende planer, aktiviteter og leveranser for sine delprosjekt. I dette inngår: Planlegging og organisering av delprosjektets arbeidsaktiviteter Regelmessig rapportering og statusoppdatering om fremdrift til prosjektleder Identifisering av potensielle usikkerhetsfaktorer Identifisering og eskalering av nye/endrede behov Koordinering med øvrige delprosjekter og delprosjektledere Deltagelse på møter med prosjektstab og øvrig påkrevd møtevirksomhet. Tabell 10: Beskrivelse av roller 39

40 Delprosjekt Løsning Delprosjektet Løsning skal sikre at alle aktiviteter knyttet til behovsanalyse og utarbeidelse av løsningsbeskrivelser (se gjennomføringsmetodikken i avsnitt 3.1.1) gjennomføres. Dette omfatter å: etablere prosesser for behovsanalyse og løsningsbeskrivelser i henhold til SITS metodikk, ivareta både funksjonelle og ikke-funksjonelle krav, jobbe tett med forretningssiden for å sikre at løsningsforslag blir forsvarlig behandlet og fulgt opp, samt lagt til utviklingsteamenes produktkø for prioritering av oppgavene, jobbe tett med både forretningssiden og de viktigste aktørene for å designe gode og realiserbare forretningsprosesser som skal legge til rette for effektiv utnyttelse av ny teknologi internt og eksternt (egne mottaksprosjekter hos de eksterne interessenter vil håndtere dialogen med prosjektet, blant annet i utarbeidelsen av nye forretningsprosesser på tvers, se avsnitt og 3.3.2), sikre god dialog mellom utviklere og løsningsarkitekt(er), koordinere arbeidet med behovsanalyser, løsningsbeskrivelser og test med regionene, tilrettelegge og ivareta produktkøen og andre løsningsartefakter slik at den til enhver tid er tilstrekkelig detaljert for neste sprint, bistå i prioriteringen av produktkøen for delprosjektet Utvikling og påse at sprintteamet jobber med de riktige tingene ut i fra et forretningssynspunkt, estimere løsningselementer i henhold til kost og nytte, dokumentere og vedlikeholde løsningsartefakter som prosessmodeller, brukstilfeller, informasjonsmodeller, behandlingsregler og testcases, støtte de øvrige delprosjektene med løsningskompetanse og -forståelse, bidra i utviklingen og kvalitetssikringen av saksbehandlingsrutiner, bistå delprosjektene Utvikling og Test i gjennomføringen av testløpet, og bistå i opplæringen av brukere. Roller i delprosjektet inkluderer: Delprosjektleder Prosessleder(e)/Metodeansvarlig(e) Produkteier(e) Fagekspert(er) Funksjonell(e) arkitekt(er) Teknisk(e) arkitekt(er) Informasjonsarkitekt(er) Brukskvalitetsansvarlig(e)/Interaksjonsdesigner(e) Sikkerhetskoordinator Dokumentasjonsansvarlig(e) Enkelte av de ovennevnte rollene vil bidra direkte inn i scrum-teamene, organisert under delprosjektet Utvikling Delprosjekt Utvikling Delprosjektet Utvikling vil være ansvarlig for samtlige utviklingsaktiviteter. I dette inngår å: etablere ny systemløsning, sanere eksisterende løsning, sette opp utviklingsverktøyet, etablere, drifte og forvalte utviklings-, opplærings- og testmiljøer, i samarbeid med linje IT, sørge for forberedelse av produksjonsmiljøet, samt bistå for å sikre én eller flere produksjonssettinger, inngå dialog med driftsarkitekturmiljøene i SITS, 40

41 bidra til utarbeidelse av testscenarier, utvikle og gjennomføre test i sprintene, som omfatter både enhetstest av den utviklede koden i hver sprint og integrasjonstest mot øvrige komponenter, utvikle og bistå i systemtester og ende-til-ende tester (systemintegrasjonstester), og utarbeide teknisk løsningsdokumentasjon. Delprosjektet vil bestå av flere scrum-team. Hvert team inneholder en scrum master samt minimum én teknisk arkitekt, én utvikler miljø, én utvikler test, én utvikler applikasjon og en funksjonell arkitekt (fra delprosjektet Løsning). I tillegg vil produkteier inneha sentrale roller i de ulike scrum-teamene. Det forutsettes en gradvis overgang av arkitekter fra Løsning til Utvikling. Roller i delprosjektet inkluderer: Delprosjektleder Scrum master(e) Utvikler(e) (miljø, test, applikasjon) Teknisk(e) arkitekt(er) Delprosjekt Test Delprosjektet Test vil ha ansvar for teststrategien presentert i , herunder å: sikre sporbarhet mellom krav og test, etablere prosjektets testprosess i kontrollpunktene og godkjenningsprøvene, fasilitere kontrollpunktene, der scrum-teamene står for gjennomføringen og produkteieren godkjenner, planlegge tekniske tester, og eventuelt bistå i gjennomføringen av disse dersom det ikke viser seg hensiktsmessig at scrum-teamene gjør dette selv, planlegge, beskrive og gjennomføre systemtester og godkjenningsprøver (sistnevnte i samarbeid med sluttbrukere fra linjeorganisasjonen), og utarbeide testdokumentasjon. Roller i delprosjektet inkluderer: Delprosjektleder/Testleder Tester(e) Utover disse vil det, særlig i gjennomføringen av godkjenningsprøvene, være aktuelt å trekke på ressurser fra linjen Delprosjekt Regelverk Delprosjekt Regelverk vil håndtere det rettslige grunnlaget presentert i 3.1.5, herunder ha ansvar for å: utrede behovet for ytterligere endringer i folkeregisterregelverket, vurdere juridiske problemstillinger i nye forretningsprosesser, bidra i utviklingen av og være ansvarlig for den juridiske kvalitetssikringen av saksbehandlingsrutinene, delta i kommunikasjonen med samarbeidspartnere for harmonisering av lovverk (i samarbeid med delprosjekt Innføring), og bidra i opplæringen av brukere. Kompetansen i delprosjektet vil være aktuell for de øvrige delprosjektene, eksempelvis i utformingen av funksjonelle løsningsbeskrivelser, utvikling av forretningslogikk og regelverksmotor, og i innføringsaktiviteter og dialogen med linjeorganisasjonen. Roller i delprosjektet inkluderer: Delprosjektleder Jurist(er) 41

42 Det vil være naturlig å bemanne opp juridisk delprosjekt med stor grad av interne ressurser, og supplere med eventuelle eksterne ressurser fra andre etater og/eller virksomheter som kjenner tilhørende og tilstøtende lovverk på en god måte Delprosjekt Innføring Delprosjekt Innføring vil ha ansvar for innføringsstrategien presentert i og følgelig være inndelt i team ansvarlig for de ulike innføringsområdene. Roller i delprosjektet inkluderer: Delprosjektleder Kommunikasjonsansvarlig(e) Informasjonsansvarlig(e) Kompetanseansvarlig(e) Opplæringsmedarbeider(e) Endringsansvarlig(e) Organisasjonsmedarbeider(e) Interessentoppfølger(e) Innføringsprosjektet vil ha koordineringsansvaret for alle nødvendige saksbehandlingsrutiner (med unntak av teknisk og driftsdokumentasjon), samt det operative samarbeidet med de fire eksterne samhandlingsaktørene beskrevet i avsnitt Strategi for styring av usikkerhet I forbindelse med usikkerhetsanalyser og usikkerhetsstyring blir usikkerhet ofte definert som differansen mellom den informasjonen som er nødvendig for å ta en sikker beslutning og den informasjonen som er tilgjengelig på tidspunktet for beslutningen (se blant annet Kristensen og Kreiner 1991, Husby et al. 1999, og Statens Vegvesen 2005). Denne differansen medfører altså mangel på en fullstendig sikkerhet, dvs. at det eksisterer mer enn ett mulig utfall. I dette kapittelet gjennomgås usikkerhetsbildet for hovedprosjektet med tanke på å realisere prosjektets hensikt, mål og kritiske suksessfaktorer Identifisering og håndtering av risikofaktorer En usikker hendelse som oppstår og som slår positivt ut for prosjektet kalles gjerne for en mulighet. I motsatt tilfelle, der en usikker hendelse inntreffer og slår negativt ut for prosjektet kalles dette for en risiko. For å avdekke både mulighetene og risikoene samt håndtere disse når de inntreffer, vil prosjektet regelmessig gjennomføre risikoanalyser. I figuren under illustreres denne prosessen. Figur 9: Prosess for å avdekke og håndtere risikoer Risikoanalyser har til hensikt å fange opp alle risikomomenter på en strukturert måte. Tiltak skal identifiseres, prioriteres og iverksettes for å redusere eventuelle negative virkninger som kan påvirke prosjektets gjennomføring. Hensikten med tiltakene er å: redusere sannsynligheten for at risikoen oppstår, minimalisere konsekvensene dersom risikomomentet inntreffer, og øke sannsynligheten for at muligheter blir utnyttet. Det er gjennomført en initiell vurdering av prosjektets usikkerheter. Resultatet av denne beskrives i avsnittene under. 42

43 3.4.2 Rapportering og oppfølging I prosjektstaben vil det være en egen risikoansvarlig som løpende skal arbeide med risikohåndtering. I tillegg til denne rollen forventes det at enhver prosjektmedarbeider i det daglige bidrar til å identifisere risikoer og melde disse til delprosjekt- eller prosjektleder. Prosjektleder har hovedansvaret for risikostyringen i prosjektet, herunder ansvar for at viktige saker løses før de blir kritiske for prosjektets fremdrift, kostnadsbilde og kvaliteten på sluttleveransen. Løpende risikovurderinger og tiltak som påvirker vedtatte planer, budsjett eller ytelse, samt organisasjonen utenfor prosjektet, rapporteres månedlig fra prosjektleder til: SITS Prosjektkontor, prosjekteier, og prosjektets styringsgruppe (SKD). Tiltak må drøftes og godkjennes før iverksetting. 43

44 3.4.3 Risikobilde I tabellen under listes opp risikofaktorer som, dersom de inntreffer, medfører at gjennomføringen av hovedprosjektet kan bli vanskeligere enn planlagt. For hver av disse faktorene har vi listet opp en rekke tiltak som skal bidra til å redusere sannsynligheten for at de inntreffer. ID Risikofaktor (navn) Ans. Mulig årsak Konsekvensbeskrivelse Tiltak A Risiko for at løsningens omfang økes/reduseres ila prosjektperioden PL DPL Nye brukerkrav fremmes av eksisterende brukere Nye brukerkrav fremmes av nye brukere Nye/endrede regulatoriske krav Forsinkelser i modernisert lov om folkeregistrering Juridiske, tekniske eller forretningsmessige hindre/begrensninger Kravspesifikasjonen er ikke dekkende Prosjektomfanget er ikke godt nok kommunisert til/avgrenset ift linjeorganisasjonen Misoppfatning av prosjektets omfang/avgrensning eksternt Ambisjonsnivå øker ("scope creep") med tilhørende behov for nye utredninger, beslutninger og valg av løsningens utforming Forsinket fremdrift Økte kostnader Redusert måloppnåelse som følge av redefinering av tiltak Feil/mangelfull utforming av løsning, prosjektet leverer ikke funksjonalitet iht opprinnelige avtaler Økt risikobilde for prosjektet som følge av endringer i planer og forutsetninger Tydelig beskrivelse og avgrensning av omfang før oppstart av utviklingsaktiviteter o Forankring av omfanget og beskrivelser hos relevante deler av prosjektorganisasjonen, samt eksternt mot samarbeidende aktører Tydelig forankret plan for hovedprosjektet, med tilhørende rapportering- og oppfølgingsstruktur Tidlig etablering av en robust prosess for endringsstyring Godt planlagt og systematisk oppfølging av fremdrift fra prosjektledelsen, inkl. tidlig identifisering og håndtering av risikoer o Eskalering av nødvendige avklaringer gjennom etablerte kanaler Klare og tydelige kontraktfestede avtaler med tjenesteleverandører o Systematisk og løpende oppfølging av tjenesteleverandører Utarbeidelse og forankring av innføringsplan og -strategi Tidlig operasjonalisering av 44

45 kommunikasjon- og forankringsplan med sentrale interne interessenter (SLG, PFS, osv.), brukergrupper, tilstøtende prosjekter og miljøer i SKD/SKE/SITS (inkl. regionavdelingen) o Systematisk og løpende oppfølging av interessenter B Risiko for at planlagt teknologi ikke er brukbar (markedsteknologi, felleskomponenter, plattform/infrastruktur) PL DPL Feil i forutsetninger knyttet til bruk av felleskomponenter/-plattform Relativ ny teknologi i markedet og manglende erfaring med bruk av denne linjen Forsinket fremdrift som følge av nye utredninger, beslutninger og valg av teknologi Forsinket fremdrift og økte kostnader som følge av behov for nyutvikling av komponenter Manglende innføring og forberedelse for ny løsning og nye arbeidsprosesser kan føre til feil i saksbehandling Etablering av prosesser for løpende identifisering og håndtering av uforutsette hendelser (risikoer/endringer) Implementering av effektive prosesser for fremdriftsrapportering Systematisk og løpende oppfølging av tjenesteleverandører Avsatt tilstrekkelig med tid og ressurser til opplæring av og innføring i linjeorganisasjonen Løpende dialog og erfaringsutveksling med andre pågående interne prosjekter (f.eks. SOFUS og SAFIR) C Risiko for at faktisk bemanning avviker fra planlagt (enten i antall ressurser eller kvaliteten på disse) PL DPL Det frigis ikke tilstrekkelig med interne ressurser, eller med riktig kompetanse Leverandører klarer ikke å stille med nok ressurser, eller med riktig kompetanse Forsinket fremdrift som følge av manglende/feil type ressurser Økte kostnader som følge av økt behov for ekstern bistand, som må erstatte opprinnelig planlagte interne ressurser o Redusert måloppnåelse om kompetanseoverføring til linjeorganisasjonen Behov for replanlegging Tidlig identifisering av prosjektets bemanningsbehov og rapportering om dette til SKD, SKE, SITS Godt forankrede og tydelige avtaler om intern ressurstilgang Sikre kompetent deltagelse fra regionene ved at rette fagpersoner hentes inn i prosjektet, i tide Utarbeidelse og inngåelse av klare og tydelige kontraktfestede avtaler med 45

46 tjenesteleverandører vedrørende levering av ressurser Etablering av prosesser for løpende identifisering og håndtering av uforutsette hendelser (risikoer/endringer) Implementering av effektive prosesser for fremdriftsrapportering D Risiko for at forankring og avklaring ikke er tilstrekkelig PL DPL Utilstrekkelig dialog med: o o o o o Finansdepartementet SKD/SKE/SITS Samarbeidsaktører øvrige interessenter programmet/øvrige programaktiviteter Utilstrekkelig dialog internt i prosjektet Oppstår usikkerhet og mistillit mellom prosjektet og Finansdepartementet, risiko for stans av prosjektet Forsinket fremdrift som følge av misforståelser mellom prosjektet og sentrale beslutningstagere Forsinket fremdrift som følge av manglende støtte fra linjen Prosjektet går glipp av synergier ved at interessenter gjør tilpasninger uten hensyn til prosjektets moderniseringstiltak (som følge av manglende dialog) Utarbeidelse, forankring og implementering av en kommunikasjon- og forankringsplan med relevante interessenter o Plan må inneholde en tydelig ansvarsfordeling og krav til fremdriftsrapportering mot sentrale aktører Gjennomføring av plan o Eskalering av nødvendige avklaringer gjennom etablerte kanaler Etablering av endringsnettverk E Risiko for at eksterne og/eller interne leveranser ikke blir levert i tide PL DPL Felleskomponenter/-plattform forsinket Eksterne delleveranser forsinket Forsinket fremdrift og økte kostnader som følge av behov for nyutvikling av komponenter Løpende dialog med ansvarlige for utarbeidelse av felleskomponenter/- plattform God leverandørstyring og fremdriftsrapportering til prosjektet 46

47 F Risiko for at brukere ikke har tilstrekkelig kompetanse for å håndtere nye løsninger PL DPL Det settes av for lite tid og ressurser til å sikre tilstrekkelig med innføringsaktiviteter Brukere i linjen blir ikke frigjort til opplæring Relativ ny teknologi i markedet og derfor manglende erfaring med bruk av denne linjen Det ikke gis tilstrekkelig med opplæring i og/eller innføring av nye arbeidsrutiner og/eller nye systemløsninger. Opplæring og innføring ikke tilstrekkelig for operasjonalisering av prosjektets tiltak Økte kostnader som følge av forlenget behov for ekstern bistand etter produksjonssetting Redusert måloppnåelse om kompetanseoverføring til linjeorganisasjonen Feil i saksbehandlingen fører til misfornøyde borgere, økte kostnader hos andre avhengige aktører, dårlig publisitet for prosjektet og etaten Utarbeidelse og forankring av innføringsplan og -strategi Tidlig operasjonalisering av kommunikasjon- og forankringsplan med sentrale interne interessenter (SLG, PFS, osv.), brukergrupper, tilstøtende prosjekter og miljøer i SKD/SKE/SITS (inkl. regionavdelingen) Systematisk og løpende oppfølging av interessenter Tilstrekkelig avsatt tid og ressurser til opplæring og innføring, både fra prosjektet og hos linjeorganisasjonen o Sikre tidlig at linjelederne frigjør sine ansatte til å motta opplæring og innføring. G Risiko for at nødvendige grensesnittstilpasninger ikke blir levert i tide og/eller iht avtale PL DPL Eksterne samarbeidsaktører setter av for lite tid og ressurser til å gjennomføre nødvendige endringer Tilstøtende prosjekter hos samarbeidende aktører blir kansellert, forsinket eller avviker vesentlig i planlagt omfang Redusert og/eller forsinkede samfunnsmessige gevinster Redusert renomé for Skatteetaten Kortere tid til testing og kvalitetssikring av grensesnitt Kortere tid til nødvendige innføringsaktiviteter Utarbeidelse av godt koordinerte og avtalte samarbeidsplaner Etablering av effektive prosesser for samarbeid, som sikrer løpende avklaringer og tidsriktig fremdriftsrapportering Etablering av felles prosesser for løpende identifisering og håndtering av uforutsette hendelser (risikoer/endringer) Tabell 11: Risikovurderinger 47

48 Figuren under viser tallene fra usikkerhet i en risikomatrise. Tallene viser til punktene i tabellen ovenfor Muligheter Figur 10: Risikomatrise I tabellen under gjennomgås hvilke muligheter som foreligger for at prosjektet skal kunne gå enda bedre enn planlagt, og hvordan disse mulighetene potensielt kan realiseres. Nr Aktivitet med mulighet Konsekvensbeskrivelse Forslag til tiltak for å realisere mulighetene 1 Anbudskonkurranse: Mulighet for å tiltrekke seg gode utviklingsmiljøer til å gjennomføre utviklingen kostnadseffektivt 2 Involvering og læring i Skatteetaten: Mulighet for høy involvering med høyt læringsutbytte for Skatteetaten Leverandører tilbyr svært gode utviklingsressurser til en relativt lav pris Prosjektet holder kostnadene nede ved begrenset involvering av eksterne ressurser. Skatteetaten er i bedre stand til å forvalte systemet etter endt utvikling Bygge opp et bilde av prosjektet som et prestisjeprosjekt Fremstå som en profesjonell kunde Sikre god organisering av prosjektressurser fra Skatteetaten, slik at den interne kompetansen blir godt brukt. Sikre dokumentasjon av erfaringene fra hovedprosjektet slik at Skatteetaten tar læringen med seg videre Tabell 12: Mulighetsmatrise 48

49 4 Prosjektstyringsbasis Prosjektstyringen av hovedprosjektet vil ta utgangspunkt i metodikken beskrevet i Skatteetatens prosjektstyringsbok, samt de erfaringer Skatteetaten har gjort i andre lignende prosjekter, som f.eks. Sofie, SL, MAG og EDAG. 4.1 Arbeidsomfang Hvilke mål som skal oppfylles og hva som inngår i modernisert løsning er tidligere beskrevet i kapittel 2. I avsnittene under beskrives omfanget til modernisert løsning. Omfanget defineres utifra en logisk samling av funksjonalitet. Denne samlingen består av en rekke funksjonelle områder. De funksjonelle områdene brytes ned i 1) faglige områder, og 2) tverrgående områder, som vist i Figur 11. Disse områdene danner grunnlaget for inndelingen og prioriteringen av hovedprosjektets 4 hovedleveranser, og som utdypes i de påfølgende avsnittene. Figur 11: Funksjonelle områder i modernisert folkeregisterløsning Hver av de faglige funksjonelle områdene beskriver funksjonalitet som henger logisk sammen fra et bruker- og et folkeregisterperspektiv. Folkeregisteret registrerer livshendelser for populasjonen i registeret, der hver type hendelse utgjør et faglig funksjonelt område. Enkelte hendelser registreres av borgeren selv (eksempelvis melding om flytting eller valg av navn), mens de fleste kommer fra andre offentlige etater og Skatteetaten selv (eksempelvis melding om fødsel eller dødsfall). De tverrgående områdene representerer ulike systemmessige egenskaper som går på tvers av de faglige områdene. Disse egenskapene er nødvendige for at løsningen skal være i stand til å oppfylle samfunnsbehovet til folkeregistermyndigheten. En detaljert beskrivelse av fagområdene finnes i dokumentene 'HL-03a Funksjonell løsningsbeskrivelse v1.5' og 'HL-03a Teknisk løsningsbeskrivelse v1.5'. 4.2 Endringsstyring Basisestimatene som ligger til grunn for forslaget til gjennomføring, samt vurderingene av usikkerhet og risiko er basert på de forutsetninger og rammer som det er redegjort for i dette styringsdokumentet. Effektiv og forutsigbar gjennomføring forutsetter aktiv oppfølging av endringer på alle nivåer i prosjektet. Om det fra overordnet myndighets side gjøres vesentlige endringer i forutsetninger og rammer med hensyn til hvordan ulike tiltak utformes og iverksettes vil dette kunne utløse behov for revisjon av 49

50 prosjektstyringsunderlaget. Endringer i slike forutsetninger vil kommuniseres skriftlig til de berørte interessenter. Gjennom utviklingsarbeidet i prosjektet vil de krav og behov som skal ivaretas omsettes til løsninger og leveranser. Prosjektet vil ha formaliserte prosesser for styring av innholdet i leveranser og av endringer i dette innholdet, innenfor de mål og rammer som er gitt i styringsunderlaget. Endringsforslag skal behandles på det nivået i prosjektet som har myndighet til å beslutte om endringen skal gjennomføres. Prosjektet vil etablere en strukturert prosess for endringshåndtering ved inntruffet usikkerhet. Denne prosessen vil utformes i tråd med god praksis for gjennomføring av utviklingsarbeid, og den vil være et vesentlig element i styringssystemet for å sikre styring av framdrift og kostnader. 4.3 Prosjektnedbrytningsstruktur Med utgangspunkt i gjennomføringsstrategien, prosjektorganisasjonen og arbeidsomfanget, defineres prosjektets nedbrytningsstruktur (PNS). Per skrivende stund har prosjektet planlagt med 4 hovedleveranser (L1-L4). En femte leveranse, kalt 'Andre', inneholder aktiviteter som vil pågå parallelt med hovedleveransene. PNSen består av følgende nivåer: Nivå 1: Hovedprosjektet Nivå 2: Delprosjekter Nivå 3: Delprosjektenes leveranser Nivå 4: Aktiviteter/funksjonelle områder som må gjennomføres for å kunne levere delprosjektenes leveranser På grunn av en tett knytning og sammenheng mellom planlagte aktiviteter og leveranser for delprosjektene Løsning og Utvikling, sees disse to i sammenheng. PNSen illustreres i Figur 12. Figur 12: Prosjektets nedbrytningsstruktur (PNS) PNSen er utgangspunkt for planleggingen og oppfølgingen av hovedprosjektet ved at delprosjektene, leveransene og aktivitetene legges inn i et planleggingsprogram. Hver aktivitet vil bli tilordnet en periode, forventet timebruk og ressurstype. På den måten vil prosjektnedbrytningen bidra til å styre og rapportere fremdrift på ulike nivåer og dimensjoner, samt på en enkel måte gi en oversikt over forbrukt og gjenstående budsjett. 50

51 4.4 Kostnadsoverslag, budsjett og investeringsplan I avsnittene under gis en overordnet beskrivelse av estimeringstilnærmingen og resultatene fra denne. En grundigere gjennomgang av estimater, vurderinger, referansetall, forutsetninger, m.m. finnes som et eget vedlegg til dette dokument (se Vedlegg C) Estimeringstilnærming PNSen fungerer som utgangspunkt for estimeringen av prosjektets grunnkalkyle. I figuren under vises hvilke tilnærminger som er benyttet for å estimere de ulike komponentene Figur 13: Nedbrytning av prosjektet i estimerbare komponenter (grønne bokser) og benyttede estimeringstilnærminger (hvite bokser) Fasebasert modell Erfarings- og fasebasert estimeringsmodell er benyttet for delprosjektene Løsning, Utvikling og deler av Test. Modellen bygger på Skatteetatens estimeringsmetode for IT-utvikling og er basert på erfaringstall fra tidligere gjennomførte samt pågående prosjekter i Skatteetaten (eksempelvis MAG og EDAG), Skatteverket i Sverige og referansetall fra Gartner. I modellen estimeres først timer for utvikling og enhetstest basert på 1) antall og kompleksiteten av brukstilfellene, og 2) arkitektur-/applikasjonskomponentene i løsningen. Deretter benyttes det påslagsprosenter for å estimere de øvrige aktiviteter som inngår i utformingen, utviklingen og implementeringen av løsningen. Det totale antall timer gir grunnlaget for estimatene bak delprosjektene Løsning, Utvikling og deler av Test (unntaket er estimater for testledelse, som estimeres som en varighetsdreven rolle) Varighets-/rolledrevne estimater Denne estimeringsmetoden er benyttet for delprosjektene Prosjektstab, Regelverk, Innføring og ledelsen i Test. Timeestimatene er beregnet på bakgrunn av sammenlignbare erfaringstall fra prosjekter i Skatteetaten og rolleanbefalinger i prosjektstyringsmetodikken PRINCE Kostnad per enhet Denne estimeringsmetoden omfatter estimater for 1) de nye tekniske grensesnittene som skal opprettes mellom modernisert løsning og eksterne samhandlingsaktører, 2) øvrige innføringskostnader (dvs. som kommer i tillegg til de estimater for innføringsårsverk, og 3) leie av prosjektlokaler. 51

52 For innføringskostnadene (info- og opplæringsmateriell, kurslokaler, m.m.) er det estimert et ulikt antall kostnadstyper som er blitt multiplisert med en enhetskost. Tilsvarende for grensesnittene er, basert på mottatte referansetall fra Difi og Helse, beregnet en kostnad per grensesnitt, og for leie av prosjektlokalene, som er basert på innhentet tilbud gjennom SITS Eiendom Bidrag modernisering Det er planlagt en ny felles infrastruktur og driftsplattform i Skatteetaten. Utviklingskostnadene knyttet til denne skal fordeles på de prosjekter som skal anvende den, herunder prosjekt MF. Den moderniserte infrastrukturen, også kjent som modernisert applikasjonsplattform (MAP), skal huse ulike "leietakere" i samtidighet. Med "leietakere" menes tjenester (dvs. ulike fagapplikasjoner) som bygger på samme arkitektur og en felles utviklingsplattform/-standard. Dette gjør at man kan forutsette at plattformtjenestene er generiske og felles for alle leietakerne. Ettersom estimatet representerer prosjektets bidrag til en felles driftsarkitektur er disse kostnadene estimert utenfor prosjektet Basiskostnad Basiskostnaden regnes som prosjektets styringsmål og er kostnadsrammen som prosjektleder styrer etter. Denne kostnaden består av grunnkalkylen og en uspesifisert post som skal ta høyde for uteglemte kostnader. Grunnkalkylen er estimert i henhold til tilnærmingen presentert i Posten for uspesifisert består av det tilsvarende beløpet fra estimeringen gjennomført høsten 2014, men nå indeksregulert til 2016-tall. Beskrivelse Antall timer MNOK (2016-tall, ink. MVA) MNOK (2016-tall, eks. MVA) Delprosjekt Prosjektstab Delprosjekt Innføring Delprosjekt Regelverk Delprosjekt Løsning Delprosjekt Utvikling Delprosjekt Test SUM Ressurser Innføringsaktiviteter Grensesnitt Driftsarkitektur Leie av lokaler Grunnkalkyle Uspesifisert Basiskostnad Tabell 13 oppsummerer tallene som inngår i basiskostnaden. Beskrivelse Antall timer MNOK (2016-tall, ink. MVA) MNOK (2016-tall, eks. MVA) Delprosjekt Prosjektstab Delprosjekt Innføring Delprosjekt Regelverk Delprosjekt Løsning Delprosjekt Utvikling

53 Delprosjekt Test SUM Ressurser Innføringsaktiviteter Grensesnitt Driftsarkitektur Leie av lokaler Grunnkalkyle Uspesifisert Basiskostnad Tabell 13: Styringsmål for prosjektet Forventet kostnad og foreslått kostnadsramme Prosjektets største usikkerhet knytter seg til estimatene. For å håndtere denne usikkerheten vil prosjektet regelmessig gjennomføre kvantitative usikkerhetsanalyser som synliggjør kostnadsusikkerhet og tryggheten i kostnadsrammer. Disse analysene vil utføres etter samme metodikk som benyttes i Finansdepartementets KS-ordning. Figuren under skisserer prosessen for gjennomføringen av slike analyser. Figur 14: Prosess for usikkerhetsanalyse i henhold til Finansdepartementets KS-ordning Utfallet av den ovennevnte usikkerhetsanalysen gir kostnadspåslagene Forventet tillegg og Usikkerhetsavsetning. Disse to påslagene legges til basiskostnaden og utgjør henholdsvis direktoratets styringsramme (P50) og departementets (P85) kostnadsramme. En grundigere beskrivelse av hvordan disse påslagene er blitt beregnet fremgår i egen rapport fra usikkerhetsanalysen utarbeidet av ekstern kvalitetssikrer. Under følger en oppsummering av tallverdiene for prosjektet: Finansieringsbehov MNOK (2016-tall, ink. MVA) MNOK (2016-tall, eks. MVA) Basiskostnad Forventet tillegg Forventet kostnad (P50) Usikkerhetsavsetning Foreslått kostnadsramme (P85) Tabell 14: Styrings- og kostnadsramme for SKD (P50) og FIN (P85) Prosjektet er helfinansiert, dvs. samtlige investeringsmidler fremkommer som øremerkede midler fra Finansdepartement. Prosjektets budsjett utgjør derfor finansieringsbehovet. Tabellen under viser dette behovet periodisert. Investeringskostnader (2016-tall, ink. MVA) SUM MNOK

54 Grunnkalkyle Uspesifisert Basiskostnad Forventet tillegg Forventet kostnad (P50) Usikkerhetsavsetning Foreslått kostnadsramme (P85) Investeringskostnader (2016-tall, eks. MVA) SUM MNOK Grunnkalkyle Uspesifisert Basiskostnad Forventet tillegg Forventet kostnad (P50) Usikkerhetsavsetning Foreslått kostnadsramme (P85) Tabell 15: Finansieringsbehov over på prosjektets levetid Utløsning av midler fra reserveavsetninger Finansdepartementet disponerer kostnadsrammen som inkluderer en usikkerhetsavsetning (P85). Midler fra denne usikkerhetsavsetningen bør primært utløses for å håndtere endringer/usikkerhet som ligger utenfor prosjektets påvirkningsmulighet. Dokumentasjon av inntruffet usikkerhet av denne typen og kommunikasjon av dette vil skje skriftlig. Utløsing av denne usikkerhetsreserven skal primært begrunnes i de viktigste usikkerhetene fra usikkerhetsanalysen. 4.5 Kuttliste Kuttlisten er prioritert slik at kuttmuligheten med prioritet 1 (øverst i tabellen) er den som kuttes først hvis det skulle bli nødvendig å kutte. Partnerportalen er en konkret leveranse til fellesskapet og er planlagt levert gjennom prosjektet. Mulig kutt baserer seg på at prosjektet kun utvikler den delen av funksjonaliteten i komponenten som er tilstrekkelig for Folkeregisterets formål. Det betyr at den ekstra utviklingen som opprinnelig var planlagt og som ville gjøre komponenten gjenbrukbar for øvrige systemer, enten blir utsatt eller overlatt til andre å utvikle. De øvrige kutt kandidatene er kun knyttet til forretningsbehovet og gevinstbildet i prosjektet, og vil kunne realiseres uten at dette for konsekvenser for den totale porteføljen og moderniseringsplanene i Skatt. Prioritet Mulige kutt Potensiell besparelse (2016-tall, ink. MVA) 1 2 Saksbehandling redusert ambisjonsnivå for graden av automatisert saksbehandling Partnerportalen redusert ambisjonsnivå for utviklingen av den generiske og gjenbrukbare delen av komponenten MNOK MNOK 54

55 3 Oppslag redusert ambisjonsnivå for grad av selvbetjening MNOK Tabell 16:Kuttliste Når en prioritert produktkø foreligger, vil de nederste elementene representere kuttlisten. Dermed vil den initielle kuttlisten gjennomgås underveis i prosjektet, nye kandidater vil legges til og prioritet endres. 4.6 Overordnede planer Det vil utarbeides detaljerte fremdriftsplaner som inneholder sentrale aktiviteter, milepæler, leveranser, kommunikasjons- og forankringspunkter, samt avhengigheter mellom disse. Disse planene vil utarbeides først når tjenesteavtaler og kontrakter med leverandører er inngått. Senere vil de bli benyttet i styringen av prosjektet og oppfølgingen av fremdriften. I dette kapittelet gjennomgås overordnede planer for prosjektet med de viktigste aktivitetene, milepælene, og leveransene Fremdriftsplan Figur 15 viser en foreløpig overordnet fremdriftsplan for hovedprosjektet. Denne må sees i sammenheng med gjennomføringsstrategien beskrevet i avsnitt 3.1, ansvarsdelingen i avsnitt 3.3, samt milepæls- og leveranseplanen under. Fremdriftsplanen Antall sprinter er kun ment for illustrative formål Milepæls- og leveranseplan Figur 15: Overordnet fremdriftsplan Prosjektet planlegger med 4 hovedleveranser som skal leveres inkrementelt. Parallelt vil det løpe en rekke aktiviteter som inngår i leveransen 'Andre'. Figuren under illustrerer leveransenes tidslinjer og tilhørende funksjonsområder innen hver leveranse. 55

56 Figur 16: Overordnet og foreløpig leveranseplan for hovedprosjektet Tabell 17 viser overordnede tidsperioder for hovedleveransene og sentrale aktiviteter fordelt på de ulike delprosjektene. En detaljert planlegging av de enkelt e aktivitetene vil inngå i prioriteringsarbeidet knyttet til produktkøen. Delprosjekt Tid Prosjektstab Innføring Løsning/ Utvikling Leveranse 1 Q Q Bemanne opp prosjektorganisasjonen Etablere nødvendige styrings- og rapporteringsstrukturer Avklare endringshåndterings-, risikostyrings- og kvalitetssikringsprosesser Utarbeide og forankre kommunikasjonsplan Leveranse 2 Q Q Leveranse 3 Q Q Prosjektledelse, -oppfølging og -monitorering Kvalitetssikre, styre endringer og håndtere risiko Utarbeide innføringsmateriale Arbeide med: o Kommunikasjon/forankring o Interessentoppfølging o Kompetanseutvikling o Organisasjonsutvikling o Gevinstplanlegging Gjennomføre aktiviteter iht kommunikasjonsplan Vedlikeholde og justere kommunikasjonsplan Leveranse 4 Q Q Avgrense omfang til leveranser gjennom brukerhistorier Ferdigstille løsningsdesign og -arkitektur Utforme og forankre nye forretningsprosesser Løpende vedlikeholde produktkø Detaljplanlegge sprintene, releasene og leveransene Delta i funksjonelle testaktiviteter Planlegge og gjennomføre datakonvertering/migrering fra eksisterende til modernisert løsning 56