Mulighetsstudie Vergemålsapplikasjonen

Transkript

1 Justisdepartementet Utarbeidet av konsulentselskapet Steria AS Dato: Mulighetsstudie Vergemålsapplikasjonen

2 Innholdsfortegnelse 1 Innledning Fremgangsmåte Oppsummering Bruk av eksisterende avtaler Møte med Datatilsynet Databehandleransvar Teknisk løsning og arkitektur Hjemmel for behandling av personopplysningene i vergemålsloven Altinn Løsningsskisse Vergemålsportalen Grensesnittjenester Vergemålsregister Arkiv Arbeidsflate for vergemålsmyndigheten Autentisering Internkontrollsystem Oppdatert løsningsskisse Oppdatert Leveranseplan Oppdatert prosjektplan og kostnadsestimater Oppdatert prosjektrisiko Steria AS Side 2 av 14

3 Figurliste Figur Figur 2: Faseinndelt prosjektplan Tabbeliste Tabell 1: Leveranseplan Tabell 2: Faser og estimerte kostnader Tabell 3: Endringer til Håndtering av usikkerhet Steria AS Side 3 av 14

4 1 Innledning Steria fikk den 15. juni i oppdag av Justis- og Politidepartementet følgende oppgaver: Å utrede vider de tre løsningsalternativene og komme med en entydig anbefaling til løsning når det gjelder funksjonalitet og teknisk oppbygning. Om nødvendig å foreta ytterligere spesifikasjon av løsningen for å tydeliggjøre forutsetningene for anbefalingene Med bakgrunn i valgt løsningsalternativ, gjøre en oppdatert vurdering av design av realiseringsprosjektet, framdrift/faser, risikovurderingene og kostnadene Gjennomføre et møte med Datatilsynet for å sjekke ut at løsningen er realiserbar innenfor de hensyn som Datatilsynet er satt til å ivareta Avklare om fylkesmennenes eller Statens sivilrettsforvaltnings avtale med EDB Ergogroup for ephorte kan benyttes for realiseringen av vergemålsapplikasjonen Steria AS Side 4 av 14

5 2 Fremgangsmåte Vi har i mulighetsanalysen tatt utgangspunkt i rapporten Arbeidsprosesser og datastøtte i vergemålsforvaltningen og arbeidet som ble gjort i delprosjektet. Vi har gjennom arbeidet med mulighetsstudiet vært i dialog med: Altinn Datatilsynet EDB Ergogroup Fylkesmannen i Sogn og Fjordane KPMG AS Statens sivilrettsforvaltning Løsningen og de anbefalinger som vi gir er i tillegg blitt styrt av Overordnede IKTarkitekturprinsipper for offentlig sektor og ikke minst personopplysningsloven. 3 Oppsummering Ut fra de funn som er gjort gjennom mulighetsstudiet presenterer vi et entydig løsningsforslag i kapitel 7. Bakgrunnen for de valg som er gjort i den nye løsningen er beskrevet i kapitel 4 og 5. Vi har også valgt å endre grensesnitt-tjenestene til en tjenestebuss for å reflektere at det her er snakk om en komponent som knytter helle løsningen sammen, og ikke bare er et grensesnitt mot eksterne systemer. Som beskrevet i kapitel 4 er det ikke mulig å bruke komponenter fra eksisterende anskaffelser for å bygge vergemålsapplikasjonen. Det må med andre ord gjøres anskaffelser av programvare for å kunne bygge vergemålsapplikasjonen. Anskaffelsen vil kunne være både innkjøp av standardløsninger (om mulig), tilpasning av standardløsninger eller eksterne utviklingsprosjekter, samt konsulentbistand. Hva som velges vil måtte være en balanse mellom at risikoen for forsinkelser øker jo mer tilpasning og utvikling som skal gjøres, veiet opp mot at det kan være vanskelig å dekke funksjonaliteten i løsningen kun med standard komponenter. I Arbeidsprosesser og datastøtte i vergemålsforvaltningen anbefalte vi å inngå en uforpliktende rammeavtale med minimum tre leverandører. Dette kan fortsatt være en aktuell tilnærming, men det bør i så fall gjøres en separat anskaffelse av programvare komponenter. Alternativt kan det gjøres en felles anskaffelse av programvare og tjenester. Dette er mer effektivt i forhold til tidsbruk på selve anskaffelsen, men gir mindre fleksibilitet under prosjektgjennomføringen. Steria AS Side 5 av 14

6 De funn og avklaringer som er gjort har også resultert i at leveranseplan, prosjektplan, risiko vurderinger og kostnadsestimater er oppdatert som beskrevet i kapitel 9 og 10. Endringen er hovedsakelig forårsaket av at prosjektet må starte med anskaffelse av programvare komponenter. 4 Bruk av eksisterende avtaler Det blir i løsningsforslag 3 i dokumentet Arbeidsprosesser og datastøtte i vergemålsforvaltningen foreslått å bruke ephorte som arkiv, under forutsetning av at eksisterende ephorte installasjon og lisenser hos Fylkesmann eller Statens sivilrettsforvaltningen kan brukes. Dette har vist seg å være problematisk. Eierskapet til applikasjonen er forutsatt plassert hos sivilrettsforvaltningen, og deres lisenser dekker kun den installasjonen de har i dag, med noe utvidelse av bruksområde. Det er med andre ord kun mulig å benytte sivilrettsforvaltningens ephorte lisens, hvis samme installasjon blir brukt for vergemålsapplikasjonen. Det er teknisk problematisk å gjenbruke den eksisterende installasjonen av ephorte hos sivilrettsforvaltningen for vergemålsapplikasjonen, da konfigurasjon og bruksmåte er vidt forskjellige. Det er heller ikke identifisert andre anskaffelser hos sivilrettsforvaltningen som kan brukes for Vergemålsapplikasjonen. 5 Møte med Datatilsynet Som del av mulighetsanalysen ble det gjennomført et rådgiving- og veiledningsmøte med Datatilsynet. Det ble i møtet drøftet flere problemstillinger rundt vergemålsapplikasjonen, og vi vil i dette kapitelet gå igjennom disse, og de anbefalinger og forutsetninger som kom ut av dette møtet. Temaene som ble drøftet i møtet var: Databehandleransvar Teknisk løsning og arkitektur Hjemmel for behandling av personopplysningene i vergemålsloven 5.1 Databehandleransvar Datatilsynet er tydelige på at databehandleransvaret må være tydelig plassert for vergemålsapplikasjonen. Alternativene for hvor databehandleransvaret skal plasseres er: Hos sentral vergemålsmyndighet Hos hver enkelt fylkesmann Delt databehandlingsansvar Det vil være databehandlere hos både vergemålsmyndighet og hos hver fylkesmann. Men det er hos hver fylkesmann at brorparten av saksbehandlingen vil foregå. Hos sentral vergemålsmyndighet vil databehandlingen skje i form av behandling av klager og tilsyn, og ved drift av løsningen. Ut fra dette er det naturlig å plassere databehandler ansvaret hos hver enkelt fylkesmann. De er ansvarlige for saksbehandlingen, og bør derfor også være ansvarlige for at personopplysningene blir behandlet på en korrekt måte. Steria AS Side 6 av 14

7 5.2 Teknisk løsning og arkitektur Datatilsynet har en rekke kommentarer og anbefalinger til hvordan vergemålsapplikasjonen teknisk bør håndtere en del sikkerhets og personvern hensyn. Generelt var Datatilsynet tydelige på at det var viktig å tydelig skille på den delen av applikasjonen som skal brukes til forvaltning, og den delen som skal være tilgjengelig på Internett for verger m.fl. Ved å ha disse arbeidsflatene tydelig adskilt reduserer en risikoen for rollesammenblandinger og datalekkasje ved feil i systemet. Med dette som bakteppe hadde Datatilsynet råd rundt temaene autentiseringsmekanismer og infrastruktur. Autentiseringsmekanismene som ID-porten og MinID kan ikke brukes som autentiserings mekanisme for arbeidsflate for vergemålsmyndigheten, siden dette er mekanismer som er knyttet til den enkelte som privat person. Datatilsynet er tydelige på at dette er problematisk i henhold til personopplysningsloven 12 som legger til grunn at arbeidsgiver som hovedregel ikke kan kreve at ansatte skal bruke fødselsnummer som pålogging til datasystemer, da det som regel vil være tilstrekkelig at det opprettes et annet brukernavn som er entydig for brukeren. For å lette hverdagen til saksbehandlerne kan det være ønskelig å bruke Single Sign-On for arbeidsflate for vergemålsmyndigheten. Datatilsynet ser at dette er enkelt for brukeren, men mener også at dette gjør det vanskeligere å holde systemer og arbeidsoppgaver adskilte. Datatilsynet anbefaler at vi vurderer å plassere vergemålsapplikasjonen på sikker nettverkssone i forvaltningen. Dette i seg selv gir bedre sikring av informasjonen lagret i løsningen, men må ikke være noen sovepute for en komplett vurdering av sikkerheten i vergemålsapplikasjonen. 5.3 Hjemmel for behandling av personopplysningene i vergemålsloven Datatilsynet gir utrykk for at forutsatt at det er hjemmel for å behandle de aktuelle personopplysningene i vergemålsloven, så er deres behandling av vergemålsapplikasjonen formelt bare en meldingssak. 6 Altinn Etter møte med Altinn ble det klart at løsningen beskrevet i løsningsalternativ 3 fra Arbeidsprosesser og datastøtte i vergemålsforvaltningen er den beste løsningen. I denne løsningen har vergemålsapplikasjonen sin egen vergemålsportal, og Altinn bruker dialoger presenteres i portalen gjennom dyplenking. Vergemålsapplikasjonen får informasjon fra Altinn gjennom web services kall, og vergemålsapplikasjonen kan forhånds utfylle skjemaer via web services kall mot Altinn. Steria AS Side 7 av 14

8 I møtet med Altinn ble det også klart at Altinn mener at de har løst problemstillingene rundt Datatilsynets bekymring ved at data blir mellomlagret hos Altinn. I følge Altinn vill informasjon tilknyttet vergemålsapplikasjonen lagret i to sammenhenger i Altinn: I brukerens meldingsboks, hvor brukeren selv har full kontroll på dataene. Og som utfylte skjemaer, hvor vergemålsapplikasjonen vil ha full kontroll på dataene. 7 Løsningsskisse På bakgrunn av de funn som er beskrevet i kapitel 4,5 og 6 skisseres her et entydig løsningsforslag basert på de tre løsningsforslagene som er beskrevet i dokumentet Arbeidsprosesser og datastøtte i vergemålsforvaltningen. 7.1 Vergemålsportalen De tre løsningsalternativene som ble presentert i dokumentet Arbeidsprosesser og datastøtte i vergemålsforvaltningen beskriver tre løsninger som hovedsakelig er forskjellige i hvordan vergemålsportalen skal løses, og eventuelt integreres med Altinn. Det er et sterkt krav til vergemålsapplikasjonen om at den skal bruke nasjonale felleskomponenter. Altinn er av Difi definert som nasjonal felleskomponent og er derfor et naturlig valg for utfylling skjemaer, meldingsboks, og samhandlingstjenester. Valget av Altinn utelukker løsningsalternativ 1 hvor Altinn ikke er en del av løsningen. For å ha best mulig fleksibilitet for å lage en vergemålsportal som er så brukervennlig som mulig for alle eksterne aktører, vil vi anbefale at vergemålsportalen er en egen portal i vergemålsapplikasjonen som bruker tjenester i Altinn igjennom dyplenking og bruk av Web Servises grensesnittet til Altinn. Dette er også en løsning som Altinn ser som mer og mer vanlig, og støttes fullt ut. Det vil si at for Vergemålsportalen er det løsningen beskrevet som løsningsalternativ 3 som anbefales. 7.2 Grensesnittjenester Vergemålsapplikasjonen er bygget opp av et sett med mer eller mindre frittstående komponenter som bruker tjenester hos de andre komponentene i applikasjonen. I tillegg trenger vergemålsapplikasjonen å kommunisere med eksterne systemer som for eksempel folkeregisteret, SSØ, løsøreregisteret og Altinn. Alle disse grensesnittjenestene bør for å oppnå en løs kobling mellom komponentene, så langt som mulig etableres i form av en integrasjonsbuss. Dette vil gjøre det mulig å endre eller skifte ut enkeltkomponenter i vergemålsapplikasjonen uten at dette påvirker de andre komponentene. Spesielt integrasjon mot eksterne systemer er spesielt viktige å integrere gjennom en integrasjonsbuss, for å sikre at disse er så løst koblet til vergemålsapplikasjonen som mulig. Det bør her også bemerkes at de ikke er nødvendig at all integrasjon skal gå igjennom en integrasjonsbuss. I noen tilfeller er komponenter så tett integrert at dette ikke er formålstjenlig. Eller Steria AS Side 8 av 14

9 det kan mangle åpne grensesnitt som gjør det mulig å bruke integrasjonsbussen. Men dette må være veloverveide unntak. 7.3 Vergemålsregister Data som skal lagres i vergemålsapplikasjonen kan grovt sett deles i tre typer: Arkivverdig informasjon Ikke arkivverdig informasjon o o Vergemåls relaterte data Systemdata Den arkivverdige informasjonen må lagres i et Noark sertifisert arkiv som blir nærmere beskrevet i kapittel 7.4. Den i ikke arkivverdig informasjonen kan deles i to typer. Den som er vergemåls relatert, og data som brukes av systemet for konfigurasjon og lagring av sesjons informasjon med mer. System informasjonen vil i stor grad bli håndtert internt i hver av komponentene. Skulle en eller flere komponent ha behov for å benytte en sentral database bør det gjøres en grundig sikkerhets vurdering før en bruker samme database som for vergemålsrelaterte data. Det som da står igjen er vergemålsrelatert data. Dette er data som ikke er direkte arkivverdig, men som er tett knyttet til vergemålet, og saksbehandling i samband med vergemålet. Det har av leverandører av arkivløsninger blitt foreslått at denne informasjonen kan lagres som metainformasjon i arkivet. Dette har den fordelen at en slipper å vedlikeholde en separat database for denne informasjonen. Ulempen er at det skaper en mye tettere knytning mellom vergemålsapplikasjonen og arkivsystemet. Det gir også strengere ikke funksjonelle krav til arkivløsningen, som for eksempel at arkivløsningen må ha en responstid som er lav nokk for sanntids oppslag. Vår anbefaling er at det brukes en egen database for vergemålsregisteret, men at arkivsystemet kan vurderes brukt hvis det gir en betydelig økonomisk besparelse. 7.4 Arkiv All arkivverdig informasjon som behandles i Vergemålsapplikasjonen skal lagres i et saksarkiv. Dette inkluderer både informasjon fra skjemaene og saksbehandlingen av dem. Arkivkomponenten har ansvaret for å ivareta slik funksjonalitet etter arkivloven. Dette medfører at arkivkomponenten i henhold til arkivforskriften må være Noark godkjent. I tillegg et det ønskelig at arkivet kan integreres i vergemålsapplikasjonen gjennom åpne web services grensesnitt. Som beskrevet i kapitel 4 kan ikke ephorte lisensene til Statens sivilrettsforvaltning brukes til vergemålsapplikasjonen. Vi har ut fra dette ikke lenger grunnlag for å anbefale ephorte fremfor noen annet NOARK godkjent arkivløsning. Steria AS Side 9 av 14

10 7.5 Arbeidsflate for vergemålsmyndigheten Dette er fylkesmannens og sentral vergemålsmyndighets system for saksbehandling og administrasjon av vergemålssaker. Komponenten presenterer et sett med menyer og arbeidsflater gjennom brukernes web-leser. Applikasjonen gir bl.a. tilgang til saksregistrering og saksbehandling (beskrevet under prosessmotor). Det må eksistere arbeidsflater for følgende roller: Fylkesmannen Sentral vergemålsmyndighet Det blir i løsningsforslag 3 i dokumentet Arbeidsprosesser og datastøtte i vergemålsforvaltningen foreslått å bruke SharePoint som system for arbeidsflaten. Det er ut fra konklusjonen i avsnitt 7.4 ikke lenger grunnlag for å anbefale SharePoint spesielt, siden SharePoint ble anbefalt på grun av eksisterende integrasjon med ephorte. I stede vil vi generelt anbefale at det anskaffes komponent for arbeidsflate for vergemålsmyndigheten, som har ferdig integrasjon mot arkivkomponenten. 7.6 Autentisering Det er etter møte med Datatilsynet nødvendig å presisere at vergemålsportalen og arbeidsflate for vergemålsmyndigheten ikke kan benytte samme autentiseringsmekanisme. For vergemålsportalen er ID-porten og MinID eneste aktuelle løsning for å oppnå nivå 3 og 4 autentisering for privatpersoner. Det vil si at selve autentiseringen gjøres i en for vergemålsapplikasjonen ekstern komponent, og vergemålsapplikasjonen trenger da å bruke en standardisert integrasjonsmekanisme mot ID-porten. Denne mekanismen er av Difi definert til å være SAML 2.0. Dette medfører at vergemålsportalen må kunne støtte SAML 2.0. Mekanismen for autentisering for arbeidsflate for vergemålsmyndigheten kan med fordel være det samme som andre applikasjoner brukt av Fylkesmannen og Sentral vergemålsmyndighet. Dette betyr i utgangspunktet kun brukernavn og passord. For å lette arbeidsdagen, kan det også være aktuelt å vurdere Single Sign On (SSO) mellom arbeidsflate for vergemålsmyndigheten og andre applikasjoner brukt av vergemålsmyndigheten. Det bør i så fall gjøres en risiko vurdering før SSO eventuelt introduseres. 7.7 Internkontrollsystem Som del av mulighetsstudie har KPMG sett på muligheten for å automatisere og digitalisere kontrollen av vergens økonomiske disposisjoner. En slik automatisering vil gjøres i en ny komponent kalt internkontrollsystem. KPMG beskriver et internkontrollsystem som alarmerer ut fra enkelt transaksjoner eller transaksjonsmønstre. Internkontrollsystemet henter informasjon fra banker og mellomlagrer informasjonen i vergemålsregisteret. Internkontrollsystemet må også integreres med vergemålsportalen for redegjørelser og fullstendighetserklæring fra vergen. Kjernefunksjonaliteten til internkontrollsystemet kan enten være basert på ekspert regler eller på statistiskanalyse eller en kombinasjon. Reglene som må defineres for internkontrollsystemet i Steria AS Side 10 av 14

11 vergemålsapplikasjonen er svært like de som defineres for systemer som i dag brukes for å stoppe hvitvasking og kredittkortsvindel. Det finnes med andre ord leverandører som tilbyr denne funksjonaliteten som mer eller mindre skreddersydde transaksjons-sikkerhetsløsninger. Slike løsninger kan integreres i vergemålsapplikasjonen igjennom integrasjonsbussen. 7.8 Oppdatert løsningsskisse Ut fra anbefalinger gitt i kapitel 6 vil den oppdaterte løsningsskissen bli som vist i Figur 1. Dette er en løsningsskisse bygget på en standard mønster for applikasjoner bygget etter en tjenesteorientert arkitektur. Arkitekturen vist i Figur 1 gir en fleksibilitet i valget av komponenter Figur 1 8 Oppdatert Leveranseplan Ut fra de funn vi har gjort i mulighetsanalysen har vi valgt å oppdatere leveranseplanen, for å vise at det er nødvendig med en anskaffelse av programvarekomponentene i vergemålsapplikasjonen. Dette vil forskyve de andre fasene i prosjektet. I tillegg har vi delt regnskap og diverse grensesnitt i regnskap og etablering av tjenestebuss. Tabellen under gir en oppdatert oversikt over de anbefalte fasene ved en oppdeling i leveranser og lister opp de komponenter som inngår i leveransen. Fase Beskrivelse Komponenter Funksjonalitet 1. Gjennomføre anskaffelse av de nødvendige Steria AS Side 11 av 14

12 programvarekomponentene i løsningen. 2. Vergemålsregister og løsning for registrering av verger, klienter og saker. Implementering eller tilpasning av arkivløsning Arbeidsflate for vergemålsmyndigheten (kun registreringsbilder for verger, klienter og saker) Vergemålsregister (komplett datamodell for adm. av verger, klienter, saker osv.) Etablere ny arkivløsning Gjør FM i stand til å registrere inn alle eksisterende verger, klienter og saker fra kommunene. Arkiv oppdateres med alt arkivverdig materiale fra saker som konverteres inn fra kommunene. 3. Design av skjemaer (i AltInn eller annen skjemaløsning) Design av skjemaer Overføring av skjemadata fra AltInn til FM (grensesnittjenester) Åpner for at klienter, pårørende, verger og andre interessenter kan fylle ut og sende inn skjemaer til FM via AltInn. Dette er aktuelt blant annet for brukere som ikke er tiltenkt å logge seg inn i en Vergemålsportal (leger, pårørende m.fl.). 4. Vergemålsportal og skjemaregistrering for verger Autentisering gjennom ID-Porten Vergemålsportalen (kun arbeidsflate for verger) Skjemamotor Web-basert vergemålsapplikasjon for verger. Tilgang til klientlister, saksdetaljer, og annen data som vergene har behov for. Skjemaregistrering og - innsending. Brukerne kan logge på med et tilfredsstillende sikkerhetsnivå. 5. Arbeidsflate for vergemålsmyndigheten med prosessmotor (mottak og behandling av skjemaer) og generering av brev/meldinger Klart definert grensesnitt for import av skjemadata Utvidet arbeidsflate for FM Prosessmotor (mottak og saksbehandling) Arkiv (eksportfunksjoner fra arkivkomponenten til ephorte eller alternativ arkivløsning) Rapportmotor evt. med integrering mot rapportsystem Funksjonalitet for saksbehandling for FM. Generering av brev (til forskjellige aktører) vil skje fra rapportmotoren. En løsning for sending av meldinger til verger må ligge i både Vergemålsportalen og arbeidsflate for vergemålsmyndigheten. Det skal være mulig for verger og fylkesmannen å utveksle meldinger/spørsmål med mer. Meldingstjeneste (utvidelser i både Vergemålsportalen og arbeidsflate for vergemålsmyndigheten) 6. Regnskap i Vergemålsportalen og Arbeidsflate for vergemålsmyndigheten, Regnskap/økonomimotor Grensesnitt mot andre fagsystemer Grensesnitt mot bank og eventuelt VPS Grensesnitt mot andre dataregistre Å få regnskapet inn i portalen vil være viktig siden dette er svært tidkrevende og viktig arbeid. Videre bør det vurderes å integrere portalen mot andre fagsystemer og eksterne dataregistre for å få ytterligere effektivisering. For eksempel vil integrering mot bank gjøre økonomiske transaksjoner og godkjenning av disse mye enklere. 7. Etablering av integrasjons tjenestebuss Tjenestebussen Etablering av tjenestebussen for å enhetlig kommunikasjon mellom komponentene i løsningen og lettere integrasjon av eksterne datakilder og tjenester. 8. Portalløsning m/autentisering for klienter Autentisering gjennom ID-Porten Vergemålsportalen (arbeidsflate for klienter) Skjemamotor Web-basert vergemålsapplikasjon for klienter. Tilgang til klientlister, saksdetaljer, økonomidata m.m. Funksjonalitet for utfylling og innsending av skjemaer. 9. Etablering av internkontrollsystemet Tabell 1: Leveranseplan Internkontrollsystemet Samle informasjon om transaksjoner, redegjøringer og fullstendighetserklæringer. Alarmere ved mistenkelige transaksjoner. Steria AS Side 12 av 14

13 9 Oppdatert prosjektplan og kostnadsestimater Justeringene av prosjektplan og kostnadsestimater blir som leveranseplanen påvirket av at det må gjøres anskaffelse av programvare. Dette er et løp som for en applikasjon av denne størrelsen raskt kan ta 6 måneder. Første del av en anskaffelsesprosess er å gjennomføre kartlegging og analyse av krav og behov. Denne analysen er til stor grad gjennomført i forprosjektet og vi har redusert estimatet til 4 måneder. Løsningen beskrevet i kapitel 6 gir gode muligheter for å jobbe med flere deler av løsningen samtidig. Som tidligere foreslått er det naturlig å dele i to hovedløp. Et for den interne brukerflaten, og en for den eksterne. I tillegg bør etableringen av tjenestebussen starte samtidig som et tredje løp. Figur 2: Faseinndelt prosjektplan Eventuelle leverandører vil selvsagt være med å legge prosjektplaner for de enkelte faser, men tabellen under er et utgangspunkt for videre diskusjoner (beskrivelse av fasene er i tabell 1). Fase Beskrivelse Fra-dato Til-dato Estimerte kostnader 1. Anskaffelse av programvare og tjenester < 3 mill 2. Løsning for registrering av verger, klienter og saker, implementering av arkivløsning < 2 mill 3. Etablering av tjenestebuss <1 mill 4. Design av skjemaer i AltInn < 1 mill 5. Vergemålsportal og skjemaregistrering for verger < 5 mill Sikkerhetsnivå 4 krever Buypassbrikker, noe som påvirker kostnadene betraktelig 6. Arbeidsflate for vergemålsmyndigheten med prosessmotor (mottak og behandling av skjemaer), generering av brev og meldinger < 5 mill Krav til rapportering og statistikk kan øke kostnadene Steria AS Side 13 av 14

14 Grad Påvirker Arbeidsprosesser og datastøtte i vergemålsforvaltningen 7. Regnskap i Vergemålsportalen og arbeidsflate for < 2 mill vergemålsmyndigheten. 8. Vergemålsportal og skjemaregistrering for klienter < 1 mill 9. Etablering av internkontrollsystemet <3 mill Tabell 2: Faser og estimerte kostnader De totale kostnadene for løsningen estimeres, på bakgrunn av kunnskap på nåværende tidspunkt, til å være ca.23 millioner kroner. Kostnadene for de enkelte fasene må sees som veiledende. De estimerte kostnadene er basert på erfaringstall fra sammenlignbare prosjekter som Steria har gjennomført. Vi vil understreke at det er stor usikkerhet knyttet til kostnadsanslagene, og de er blant annet sterkt avhengige av løsningsarkitekturen som velges og omfanget av nødvendige anskaffelser. 10 Oppdatert prosjektrisiko Den oppdaterte løsningen, leveranseplanene, prosjektplanen og kostnadsestimatene gir noen endringer i prosjekt risiko tabellen under viser de risikoelementene som er endret. ID Usikkerhet/ Problem Mulig(e) konsekvens(er) Tiltak for å håndtere risiko Effekt av tiltak S K P3 Tidspress med politiske datoer som er urealistiske å nå KV Innføring av dårlig løsning med mangelfull eller utilstrekkelig funksjonalitet for å realisere ny vergemålsreform Styre datoer dersom mulig God dialog med det politiske miljøet og beslutningstagere En bedre og sikrere løsning 3 4 P4 Denne faller bort da de i denne løsningen kun er snakk om en arkiv instans. Ulik bruk av ephorte instansene som benyttes i fylkene KV Problemer eller feil ved lagring av dokumenter i ephorte arkiv og bruk av metadata Opprette en ny felles ephorte instans. Konsistent arkiv 3 4 Tabell 3: Endringer til Håndtering av usikkerhet Steria AS Side 14 av 14