Utfordringer for bruk av felles digitale tjenester i det offentlige? Hvorfor fellestjenester - hvilke fellestjenester gjelder det Hvorfor er det så vanskelig : Juridiske, tekniske, organisatoriske, økonomiske og praktiske utfordringer Litt om informasjonsforvaltning Opplysnings-, data- og informasjonskvalitet Teknisk, syntaktiske, semantisk og organisatoriske interoperabilitet er det tilstrekkelig? Fellesløsninger som en del av en offentlig II 1
Felles tjenester, løsninger eller komponenter? Det synes ikke å være en felles terminologi, men et forsøk Nasjonale fellestjenester: En sjølstendig løsning som yter en fullstendig tjeneste. Tilgjengelig i hele forvaltningen Eks: Folkeregisteret, matrikkelen,enhetsregisteret, Kontakt- og reservasjonsregisteret Statlige fellestjenester: Løsning som bare er tilgjengelig for statlige institusjoner [Statlig] felleskomponent Allment tilgjengelig byggekloss som kan inngå i en tjeneste Hva mener DIFI : https://samarbeid.difi.no/difis-felleslosninger https://www.difi.no/sites/difino/files/torgeir_strypet_-_2016-06- 10_spor_4_difi_som_leverandcr_av_felleslcsninger_digitaliseringskonferansen.pdf Arild Jansen, Avd. for forvaltningsinformatikk/senter for rettsinformatikk 2
To typer fellesløsninger (komponenter) Innholdsløsninger (grunndata-registre) som dekker en lovpålagt oppgave I dag: Folkeregisteret, Enhetsregisteret, Matrikkelen, Kontakt- og reservasjonsregisteret Ansvaret for utvikling/drift er knyttes til etaten som forvalter regelverket. Dette ansvaret kan ikke flyttes ut av forvaltningen eller uten videre overføres til andre
To typer felleskomponenter fortsatt Rene tekniske (service) infrastruktur komponenter Ikke lovpålagt, men lovregulert oppgave og nødvendig for den digitale forvaltningen I dag : ID-porten, AltInn, digital postkasse,... Flere er «underveis» Ansvar og styring kan ligge hvor som helst, (også tilbudt av markedet), men nødvendig at et departement har et forpliktende eierskap til hver av disse komponentene 4
Difis nasjonale fellesløsninger Nasjonal arkitektur
Felleskomponenter som byggeklosser Arkitektur-prinsipper er nødvendig 6
Noen sentrale spørsmål knyttet til nasjonale fellesløsninger Hva er det juridiske grunnlaget for hver av dem Mål: Hva er de de primære oppgaver /funksjoner løsninger skal dekke- Hvordan prioritere mellom ulike oppgaver Skal det være frivillig eller obligatorisk å bruke dem Organisering: Hva har ansvaret for utvikling, forvaltning og drift Hvordan skal utviklingsarbeidet organiseres (internt, outsources, Hvordan skal det finansieres (sentral pott, felles mellom brukerne, bruksavgifter, ).. Arild Jansen, Avd. for forvaltningsinformatikk/senter for rettsinformatikk 7
Eksempel det nasjonale folkeregisteret Opprettet for å støtte folketellinger og skatteinnkreving Tidligere en relativt sjølstendig enhet innen skatteetaten, nå tettere integrert I dag i bruk til mange formål og i en lang rekk etater, Eks. Nav, politi, UDI, Helse, Domstoler, kommunene, Svært viktig i framtidig Identitetsforvaltning og kontroll Men Dagens organisering og finansiering er mye «prisgitt» Finansdepartementet prioriteringer Forvaltningsregimet er noe tungrodd Teknisk løsning er basert på kommersiell leverandør 8
Eksempler på mål som felleskomponentene skal bidra til å oppfylle? Effektivitet - fokus på mer kostnadseffektiv utvikling og drift/forvaltning rasjonalisering Kvalitet fokus på bedre data som grunnlag for brukertjenester Økt tilgjengelighet: sikre at alle legitime brukere har tilstrekkelig tilgang til Økt samlet funksjonalitet - utover hva den enkelte virksomhet ønsker Innovasjon og næringsutvikling, stimulere til nyskapning i privat sektor Den enkelte komponent kan ikke oppfylle alle mål samtidig Hvilke av målene skal da ha prioritet?
For ARGUMENTER FOR OG MOT FELLESLØSNINGER Lovregulering pålagt bruk Unngå dobbeltarbeid og parallell utvikling/drift Sikre Opplysningskvalitet : unngå skyggeregistre og parallelt vedlikehold Bedre funksjonalitet når flere formål skal ivaretas Men Vokser til en stor, rigid mastodont- lite innovasjon Ivaretar ikke alle behov Mer byråkratisk organisering Dyrere vedlikehold 10
Noen andre spørsmål knyttet til felleskomponenter Arkitektur og design En sentral fellesløsning Distribuert løsning Andre modeller.. Utviklingstrategi : Spesifikasjonsdrevet (topp-styrt, ofte «revolusjonært) eller brukerdrevet (bottom-up, evolusjonær utvikling) Utvikling drift vedlikehold videreutvikling Standardisering versus fleksibilitet for alle /utvalgte grupper Prinsipper for forvaltning Sentral, desentral eller distribuert forvaltningsmodell Forretningsmodell: Fellesfinansiering, brukerfinansiering, transaksjonskostnads-betaling,
Viktige og nødvendige avklaringer Fastlegge hva som er hovedmålet (ene) med den enkelte felleskomponent Avklare hvem som er primærbrukere Avklare prioriterte funksjonsområder Foreta avveininger mellom: Fleksibilitet eller skreddersøm Minimums- eller maksimumsfunksjonalitet (enkelhet versus kompleksitet ) Sikkerhet og robusthet Unngå bindinger (innlåsing) til lite hensiktsmessige standarder/tidligere løsninger
Informasjons[ressurs]forvaltning i offentlig sektor? Informasjonsforvaltningsrapporten DIFI 2013:10 : «Informasjonsforvaltning betyr eit heilskapleg syn på aktivitetar, verktøy og andre tiltak for å sikre best mogleg kvalitet, utnytting og sikring av informasjon i ei verksemd. Organiseringa av informasjonen skal vere systematisk og henge saman med verksemda sine arbeidsprosessar.» Dette innebærer blant annet : Juridiske spørsmål : legaldefinisjoner, Tekniske utfordringer: Syntaktisk og semantisk interoperabilitet, Bruk av metadata, Organisatoriske og økonomiske og praktiske spørsmål ansvar og myndighet 13
Hvordan framkommer opplysninger og hvordan sikre opplysningskvalitet Tre hovedformer Pålagte innrapportering (Folkeregister, Matrikkelen.. : Sikre kvalitet gjennom kontroll av rutiner for innrapportering Datainnsamling som resultat av oppgaveløsning nær kilden. f. eks. i helsetjenester, løpende observasjoner i politiet Sikre kvalitet gjennom kontroll av behandlingsrutiner, men ikke mulig med etter-kontroll mot kilden Resultat av dataflyt/datautveksling, f eks. Sikre datakvalitet gjennom saksbehandlingsprosessen, f eks. kontrolloppslag, krysskontroller mm, men sjelden mot kilden Er det mulig (eller ønskelig) å utforme en felles modell for informasjonsforvaltning på tvers i forvaltningen? 14
NOEN AKTUELLE PROBLEMSTILLINGER Hvor eller hvordan oppstår opplysningene (kilden) Hvem opplysningene (juridisk eller «organisatorisk») Hvordan kan opplysningen best vedlikeholdes: Sentralisert, desentralisert eller distribuert forvaltning Nærhet til kilden eller Nærhet til brukeren Hvem skal «tjene på» bruk eller salg av opplysninger? En generell erfaring: Sikring av opplysningskvalitet skjer best nær der de oppstår eller der de brukes (av brukere som kan kvalitetssikre dem) 15
Hva er en primæroppgave i et felles, nasjonalt regime for informasjonsforvaltning? Å sørge for at riktige opplysninger er tilgjengelig for rett bruker til ønsked tid og sted Integritet Tilfredsstillende kvalitet Tilgjengelighet Konfidensialitet
INFORMASJONSSYSTEMER ELLER INFORMASJONSINFRASTRUKTUR Mange (alle) av dagens sentrale fellesløsninger (felleskomponenter) får nå rollen som infrastruktur(elementer), dsv. at de inngår som en nødvendig del av en rekke digitale tjenester i forvaltningen Dette har stor betydning for videreutvikling og forvaltning av grunndata (opplysninger) og tilhørende tjenester 17
Felleskomponenter som infrastruktur-elementer Dette stiller strenge krav til løsningen : Åpen, tilgjengelig for alle Basert på standarder så langt mulig Generisk basis for mange typer anvendelser Fleksibel under utvikling Bør (må) unngå innlåsing som hindret ønsket videre utvikling Bruk av en fellesløsning er ikke bare teknisk tilpasning, men innebærer også organisatorisk og ofte også juridisk samordning
Infrastruktur-tenkningen anvendt på fellesløsninger (blant annet) grunndata innebærer: Et stor mangfold av både kilder av brukere med så vel ulike forutsetninger som ulike behov Forutsetninger og behov vil endre seg løpende, men uten at gamle behov nødvendigvis kan droppes (installert base-problemet ) Ingen sentral kontroll er verken ønskelig eller mulig Endringer,(i definisjoner, kvalitetskrav, rutiner..) får ofte ofte uventede konsekvenser andre stder Rettsregler, og blant annet legaldefinisjoner er ofte knyttet til politiske prioriteringer, gjerne kompromisser mellom ulike hensyn, ulike forvaltningshensyn osv. og derfor er en samordning av disse ofte verken ønskelig og mulig
Hva kan vi lære av Internet - tilnærmingen i arbeidet med grunndata (og IKT-arkitektur) Ha et realistisk ambisjonsnivå Metadata og felleskomponenter: starte med noen utvide eter hvert Balansere standardisering og fleksibilitet Åpne og minimale fleksible standarder så langt mulig Vekt på en iterativ (og noe eksperimentell) videreutviklingsstrategi, som også tillater «grasrotinspirert» (bottom-up) initiativ La løsningene vokse fram så langt mulig Både tekniske, organisatoriske og menneskelige aspekter er viktige Standarder og tekniske løsninger er sterkt knyttet til både rettsforhold, organisering og arbeidsprosesser Internet fikk gradvis gjennomslag og vokste gjennom sjølforsterkende effekter, bygget på installert base og positive eksternaliteter Det samme bør også skje med felleskomponenter og den øvrige IKTarkitektur
Men praksis?
Mulig modell for et nytt generisk folkeregister (eller annen fellesløsning) Lokal Reg i NAV Kjerne Folkeregister,.,) Lokal KRR i DIFI Politi/UDI : Lokalt barnehagereg. hver kommune Hvordan få til dette i praksis?
Lære av matrikkelen Tidligere basert på en sentralisert modell Innrapportering fra kildene, men sentral forvaltning Bygningsdelen ble aldri vellykket I dag er vedlikehold av noen data kommunenes ansvar, men koordineres som en del av Matrikkelen Matrikkelen oppfattes å ha relativt god kvalitet Langt på vei åpen for innsyn brukes aktiv av kommunene Lærdom : Forvaltning av data må skje så nær kilden og brukerne som mulig Finn en balanse mellom sentral og distribuert/lokal forvaltning av data 23
Hvorfor er det da så vanskelig? Mange, tildels motstridende krav til en nasjonal informasjonsinfrastruktur Silo-tenkningen gir suboptimalisering) Inkonsistent særlovgivning (begreper, regler) Krevende Installert base: legacy-systemer,mm Rettssikkerhet, personvern og offentlighet Gevinstrealisering følger ikke bevilgningene Brukerne er opportunistiske - handler også ut i fra egeninteresser