Helhetlig design for felles funksjonalitet - Elektroniske tjenester i Oslo kommune

Transkript

1 Oslo kommune Byrådsavdelingen for finans Helhetlig design for felles funksjonalitet Helhetlig design for felles funksjonalitet - Elektroniske tjenester i Oslo kommune Sist endret: Versjon: Status: Godkjent Godkjenning: 1

2 Innholdsfortegnelse 1 Om dette dokumentet Mål og hensikt med «Helhetlig design for felles funksjonalitet» Begrunnelse for og formål med revisjonen Videre forvaltning Dokumentstruktur Bakgrunn Visjon og ambisjonsnivå for elektroniske tjenester Brukerfokus evne til å effektivisere og fornye seg Flere innbyggere og dermed flere henvendelser digitale tjenester skal håndtere økningen Samhandling med innbyggere og næringsliv enklere og raskere Overordnet visjon for felles funksjonalitet Rammebetingelser og prinsipper Tilnærming og metode Behov for felles funksjonalitet Begreper og definisjoner Sentrale interessenter Oslo kommune som konsern Offentlig sektor IKT- leverandørene Virksomheter i kommunen Innbyggere og næringsliv Om innbyggere Om næringsliv Nåsituasjon for elektroniske tjenester Få og mangelfulle elektroniske tjenester Manglende fellesfunksjonalitet hindrer utvikling av nye tjenester Lav digital modenhet Brukerbehov Virksomhetsbehov Konsernbehov Oppsummering Målsettinger for felles funksjonalitet Begreper og definisjoner Overordnede mål for felles funksjonalitet Koordinering på konsernnivå (M1) Kostnadseffektivitet (herunder stordriftsfordeler) (M2) Brukertilfredshet (M3) Sammenheng mellom behov og mål Overordnede krav for felles funksjonalitet Begreper og definisjoner Krav i brukerreisen Overordnede krav Krav til strukturerte og formaliserte henvendelser Krav til felles informasjonskilder Krav til informasjon og veiledning Krav til autentisering og autorisasjon Krav til digitale forsendelser Krav til brukerrettet saks- og tjenesteinformasjon Krav til offentlig innsyn Krav til utforming av teknisk løsning Øvrige identifiserte krav Løsning for fellesfunksjonalitet

3 5.1 Innledning Nærmere om det helhetlige overbygget til virksomhetens fag- og journal/arkivsystemer Nærmere om brukerflaten: Responsivt design og API Målbilde for fellesfunksjonalitet Ansvar Brukerdialog Nettsider ( Veiledet dialog Skjemaløsning (SNOK) Min side Offentlig innsyn Abonnement og varsler Andre dialogformer (chat, sms, epost ) Korrespondanse- og sakstjenester (KOS) InfoInn InfoSak InfoUt Fag- og journal-/arkivsystemer Automatiserte prosesser, transformasjon og integrasjon Støtte- og forretningstjenester Autorisering og samtykke Autentisering Digitale forsendelser Betalingsløsning Økonomi grensesnitt Multikanalplattform Booking og bestilling Informasjonstjenester Digital kontaktinformasjon for innbyggere (ID-porten) Digital kontaktinformasjon for næring (Altinn) Stedfestet informasjon (Oslo digitalt) Matrikkelen Enhetsregisteret Folkeregisteret (DSF) ITAS applikasjons- og integrasjonsplattform Referansearkitektur og egenskaper Driftsmiljø og sikkerhetsmekanismer Transaksjonssikkerhet ITAS som integrasjonsplattform Fra idé til kjørende kode i ITAS ITAS som plattform for realiseringen av «Helhetlig design» Sikkerhet Om personvern Innføring av fellesfunksjonalitet Definisjoner Vedlegg Vedlegg 1: Sentrale brukerhistorier Vedlegg 2: Identifiserte krav Vedlegg 3: Tilnærming og metode for utarbeidelse «Helhetlig design for felles funksjonalitet» versjon Prosesskartlegging Nåsituasjonen, as-is Ønsket situasjon, to-be Analyse Gjennomføring av kartlegging Utarbeidelse av løsningskonseptet Vedlegg 4: Opprinnelig funksjonalitetskartlegging og kobling mellom krav og funksjonalitet og kompleksitetsmatrise

4 8.4.1 Funksjonalitetskartlegging Sammenstilling av fellesfunksjonalitet på tvers av pilotvirksomhetene Kompleksitetsmatrise

5 Godkjenningsliste Enhet / navn Versjon Godkjent Tron Kallum, seksjonssjef og programleder, Byrådsavdeling for finans Arild Sundberg, kommunaldirektør Byrådsavdeling for finans (godkjenning etter gjennomført ekstern kvalitetssikring samt justering av dokument) Tron Kallum, programleder Byrådsavdeling for finans (innstilling til godkjenning etter gjennomført ekstern kvalitetssikring samt justering av dokument) Tron Kallum, Byrådsavdeling for finans (godkjenning, klar til ekstern kvalitetssikring) Endringslogg Endringer Versjon Godkjent Oppdatert etter ekstern kvalitetssikring utført av Holte Consulting Oppdateringen er utført av Programmet for elektroniske tjenester i byrådsavdeling for finans med bistand fra KPMG (Arne Helme og Nora Berg Henriksen) Revidert versjon med oppdaterte beskrivelser pr september 2015, inkludert oppdateringer etter gjennomgang med programleder 30. juni og kvalitetssikring ved Sigmund Evjen. Ingen strategiske endringer Styrende dokumenter Nr Dokumentnavn Dok.id. Versjon av dato S1 Overordnet design- Visjon, strategi og prinsipper for elektroniske tjenester S2 Byrådets forslag til budsjett S3 Byrådets forslag til budsjett S4 Prinsipper for IKT- arkitektur i Oslo kommune 2011 S5 Reglement for informasjons- og kommunikasjonsteknologi og informasjonssikkerhet i Oslo kommune. Vedtatt av byrådet S6 Styringsdokument for program for elektroniske tjenester for perioden S7 Byrådssak 1111/14 Organisering av satsingsområdet modernisering og elektroniske tjenester S8 Byrådets budsjett 2015 og økonomiplan Referanser Nr Dokumentnavn Dok.id. Versjon av dato R1 Designdokument for Sonemodell R2 Strategi for elektroniske tjenester i Oslo kommune - Kartlegging elektroniske tjenester Utarbeidet av (versjon 1.0.0) Enhet / navn, rolle Rolle Enhet Trine Lind Prosjektleder Byrådsavdeling for finans (FIN) Eivind Skjelvik Prosjektdeltaker Byrådsavdeling for finans (FIN) Sven Erik Johansson Prosjektdeltaker Byrådsavdeling for finans (FIN) Carl Jacob Rustad Prosjektdeltaker Byrådsavdeling for finans (FIN) Per Kjetil Grotnes Kjernegruppen Utvikling- og kompetanseetaten (UKE) John Steen Nielsen Kjernegruppen Utvikling- og kompetanseetaten (UKE) Maria Theresa Sanna Kjernegruppen Utvikling- og kompetanseetaten (UKE) Chander Shekar Chawla Kjernegruppen Utvikling- og kompetanseetaten (UKE) 5

6 Enhet / navn, rolle Rolle Enhet Jan Henrik Gundelsby Kjernegruppen Byrådsavdeling for finans (FIN) Jon Sundby Kjernegruppen Byrådslederens kontor (BLK) Tormod Utsogn Kjernegruppen Plan- og bygningsetaten (PBE) Revisjon (versjon 1.1.0) utarbeidet av Enhet / navn, rolle Rolle Enhet Trine Lind Prosjektleder Byrådsavdeling for finans (FIN) Steinar Skagemo Prosjektdeltaker, leveranseansvarlig Byrådsavdeling for finans (FIN) Sven Erik Johansson Prosjektdeltaker Byrådsavdeling for finans (FIN) Per Kjetil Grotnes Prosjektdeltaker Utvikling- og kompetanseetaten (UKE) 6

7 1 Om dette dokumentet Tilrettelegging av felles funksjonalitet er et sentralt element i Oslo kommunes Program for elektroniske tjenester. Med felles funksjonalitet menes funksjonalitet som alle sektorer må ha og som det ikke er kostnadseffektivt for kommunen å utvikle eller anskaffe i hver enkelt virksomhet. Felles funksjonalitet skal brukes til å sikre at brukerperspektivet ivaretas, ved at tjenestetilbudet presenteres på en enhetlig, helhetlig og brukervennlig måte, på tvers av kommunens virksomheter. 1.1 Mål og hensikt med «Helhetlig design for felles funksjonalitet» Versjon 1.0 av dokumentet «Helhetlig design for felles funksjonalitet» ble laget for å synliggjøre strategiske valg, samt gi grunnlag for å starte arbeidet med å definere detaljert design for felles funksjonalitet i kommunen og bruk av nasjonale felleskomponenter. Dokumentet begrunnet og viste hvilken felles funksjonalitet som ble foreslått etablert og hvilke designmessige valg som måtte gjøres på overordnet nivå. Dokumentet beskrev et løsningskonsept for felles funksjonalitet som viste muligheter og avhengigheter innenfor kommunens eksisterende infrastruktur. «Helhetlig design for felles funksjonalitet» versjon 1.0 tok utgangspunkt i felles brukerbehov for elektroniske tjenester på områdene plan- og bygg, barnehage, skatt- og avgift, og salgs-, serverings-, og skjenkebevilling. Dokumentet gjennomgikk ekstern kvalitetssikring i henhold til kommunens investeringsregime høsten I tillegg er dokumentet en del av prosjektplanen til prosjekt for fellesfunksjonalitet Begrunnelse for og formål med revisjonen Første versjon av «Helhetlig design for felles funksjonalitet» var et resultat av fase 1 strategi og utforming i Program for helhetlig design, og har ligget til grunn for fase 2 produksjon og utprøving (pilotering). Dokumentet har vist seg verdifullt og viktig i dialogen med de ulike interessentene i programmet, ettersom den gir en tilstrekkelig detaljert men likevel oversiktlig innføring i hva som kan ventes av fellesfunksjonalitet i årene som kommer. Deler av dokumentet har eksempelvis inngått i konkurransegrunnlag for anskaffelser fra virksomhetene. Den klare forankringen av løsningsforslaget for felles funksjonalitet i behov og krav basert på dialog med pilotvirksomhetene, har også bidratt til å gi tillit til at valg av hva som burde bli felles funksjonalitet var godt begrunnet. Som en naturlig konsekvens av gjennomføringen av fase 2 er det behov for å revidere dokumentet. For det første har fase 2 resultert i at deler av målbildet nå er på plass. For det andre har arbeidet med detaljert design og utprøvingen gjennom etablering av nye elektroniske tjenester det siste året gitt viktige erkjennelser som gir grunnlag for justering av løsningsforslaget. Dette er i samsvar med i programmets strategiske valg om trinnvis gjennomføring med rom for justering av målbilde og iverksettelse av nye tiltak (jfr S1 kapittel 2.7). I tillegg til endringer som følge av erfaringer i fase 2 har også oppstarten av insentivprogrammet og de forslagene som har kommet gjennom det ført til behov for justeringer. 7

8 Helhetlig design v 1.1 Helhetlig design v 1.0 Figur 1 - Sammenhengen mellom programmets faser og revisjonen av dokumentet Hovedhensikten med revisjon av dokumentet er en oppdatering av løsningsforslaget i kapittel 5 for å gjenspeile nåsituasjonen med tanke på hva som allerede er utviklet, samt presentere et oppdatert målbilde for felles funksjonalitet som er justert i tråd med erfaringene fra fase 2. Erfaringene er også reflektert gjennom visse tilleggskrav i kapittel 4. Et sentralt poeng med den første versjonen av dokumentet var å få frem en klar sammenheng mellom de identifiserte behovene hos pilotvirksomhetene, målene for digitaliseringsarbeidet, og forslaget til løsningen. Denne revisjonen innebærer ingen ny vurdering av behov eller mål, og kun noen få endringer på kravene i kapittel 4. Grunnlaget for justeringene som er gjort på målbildet og løsningsforslaget i kapittel 5 på bakgrunn av erfaringene i fase 2 er dokumentert gjennom arbeidet med detaljert design for de tjenestene som er utviklet, i tråd med metoden for tjenestedesign som er utviklet i programmet. Dokumentasjonen finnes i form av brukerreiser, prototyper, funksjonelle spesifikasjoner m.m. på Oslo kommunes prosjekt-wiki. 1 I tillegg har insentivprogrammet sin egen dokumentasjon av prosjektforslag, forslag til samordning av prosjekt m.m. Siden målbildet og løsningsforslaget nå har sin begrunnelse i flere kilder, er det gjort enkelte forenklinger i dokumentet. Bl.a. er den mer omfattende redegjørelsen for tilnærming og metode for utarbeidelse av versjon 1.0 lagt som vedlegg. Hensikten med forenklingene er å gjøre det enklere for de som først og fremst har behov for en innføring i arbeidet med felles funksjonalitet Videre forvaltning Erfaringene viser at dokumentet «Helhetlig design for felles funksjonalitet» spiller en viktig rolle i kommunikasjon med interessentene. Ved endring i det funksjonelle målbildet i kapittel må det vurderes om dokumentet skal revideres. Slike revisjoner, som ikke innebærer større endringer i prioritering av behov og mål eller innretning på programmet utføres av prosjekt for fellesfunksjonalitet og godkjennes av programleder. Denne typen revisjoner får nytt delversjonsnummer, f.eks. fra 1.0 til Se: 8

9 Dersom det gjøres større endringer i behov, mål eller andre former for prioriteringer som endrer retning for programmet, må det en mer omfattende revisjon til. I en slik revisjon må en på nytt etablere sporbarheten gjennom dokumentet (behov, mål, krav og løsning) og dokumentet får da en ny hovedversjon (f.eks. fra 1.2. til 2.0). Det bør i så fall vurderes om det også bør gjennomføres en ekstern kvalitetssikring før dokumentet godkjennes. En ny hovedversjon godkjennes av kommunaldirektør i Byrådsavdeling for finans. 1.2 Dokumentstruktur Dokumentet Helhetlig design for felles funksjonalitet er bygd opp langs linjene Behov Målsettinger Overordnede krav Løsning. Kapittel 1 Om dette dokumentet tar for seg mål og hensikt med dokumentet Helhetlig design for felles funksjonalitet. Kapitlet beskriver visjon og ambisjonsnivå for elektroniske tjenester og overordnet visjon for felles funksjonalitet i Oslo kommune. Videre beskrives rammebetingelser og prinsipper, og tilnærming og metode som er benyttet i utarbeidelsen av dokumentet. Kapittel 2 Behov for felles funksjonalitet beskriver sentrale interessenter for Oslo kommunes satsing på helhetlig design for felles funksjonalitet. Videre beskriver kapitlet nåsituasjonen for elektroniske tjenester i kommunen og behovene knyttet til felles funksjonalitet hos interessentene. Kapittel 3 Målsettinger for felles funksjonalitet beskriver overordnede mål for felles funksjonalitet, samt sammenhengen mellom behov og mål i Oslo kommune. Kapittel 4 Overordnede krav for felles funksjonalitet beskriver brukerreisen og dens sammenheng med overordnede løsningsområder for felles funksjonalitet i Oslo kommune. Videre beskrives overordnede krav, funksjonelle krav, krav til utforming av teknisk løsning, samt øvrige identifiserte krav. Kapittel 5 Løsning for felles funksjonalitet beskriver løsningsprinsipper for felles funksjonalitet i Oslo kommune. Kapittel 6 Innføring av felles funksjonalitet beskriver innføringsstrategien felles funksjonalitet i Oslo kommune. Kapittel 7 Definisjoner beskriver relevante definisjoner knyttet til helhetlig design for felles funksjonalitet. Kapittel 8 Vedlegg oppsummerer sentrale brukerhistorier fra pilotvirksomhetene, samt en oppsummering av identifiserte krav i pilotvirksomhetene. I tillegg er enkelte kapitler fra versjon av dokumentet flyttet hit. 1.3 Bakgrunn Oslo kommune har som visjon å realisere digitalt førstevalg for tjenester til innbyggere og næringsliv. Med digitalt førstevalg menes i denne sammenheng at elektronisk kommunikasjon og samhandling er den primære kanalen for dialog mellom kommunen og innbyggere og næringsliv. I 2011 ble det gjennomført et forprosjekt med kartlegging av elektroniske tjenester mot innbyggere og næringsliv i Oslo kommune. Dette resulterte i en beskrivelse av dagens situasjon som ga grunnlag for anbefaling om å vurdere fellesfunksjonalitet på tvers av kommunens virksomheter. Premissene for digitalt førstevalg trekkes opp i dokumentet Overordnet design for Elektroniske tjenester Visjon, strategi og prinsipper. Overordnet design beskriver det langsiktige målbildet og ambisjonsnivået for Oslo kommunes elektroniske tjenester. Dokumentet gir overordnede føringer for hvordan elektroniske tjenester skal utformes, med fokus på brukeropplevelse. Byrådet i Oslo kommune besluttet i budsjettet for 2013 at arbeidet med elektroniske tjenester skulle organiseres som et program i regi av FIN. Et program som skal ivareta helheten i kommunens 9

10 satsning på elektroniske tjenester, og vise retning og valg for å nå kommunens mål. Fokus i programmets arbeid er å dekke kommunens virksomheter og brukere sine felles behov knyttet til digitalisering av tjenestene 2. For å sikre en behovsdrevet utvikling, samt bidra til å redusere risiko og gi trygghet for de strategiske valg, skal satsningen først piloteres i en mindre skala. For perioden ble følgende pilotvirksomheter prioritert: KOU (Byrådsavdeling for kunnskap og utdanning - barnehageområdet) BYU (Plan- og bygningsetaten) KON (Næringsetaten) FIN (Kemneren - piloterer SvarUt i Oslo kommune) Pilotvirksomhetene ble valgt da disse er vurdert som representative for kommunens øvrige virksomheter. På bakgrunn av Overordnet design og gjennom involvering av pilotvirksomheter har programmet i samarbeid utarbeidet et Helhetlig design for fellesfunksjonalitet (dette dokumentet). Hensikten med helhetlig design er at det skal synliggjøre strategiske valg, gi føringer og grunnlag for å starte arbeidet med å definere detaljert design for fellesfunksjonalitet. Med detaljert design menes her en fremstilling som detaljert beskriver de funksjonelle- og tekniske kravene til komponentene i en løsning, og hvordan komponentene virker sammen, både funksjonelt og teknisk. I budsjett for 2015 og i økonomiplanen for (S8) er effektivisering, forenkling og modernisering av de kommunale tjenestene vurdert som helt avgjørende for å sikre brukerne tjenester av tilstrekkelig god kvalitet. Det er avsatt totalt 550 mill. i investeringsbudsjettet i økonomiplanperioden til satsning på utvikling elektroniske tjenester. For økonomiplanperioden er det avsatt 123 mill. kr til insentivordningen, som skal motivere virksomhetene til å utvikle flere elektroniske tjenester. Byrådet besluttet i 2015 å organisere programmet som en ny seksjon i Byrådsavdeling for finans, samt å etablere en styringsgruppe bestående av kommunaldirektørene og ledet av byråd for finans (S7). Per september 2015 er det realisert flere tjenester og flere elementer i målbildet for felles funksjonalitet, bl.a. Min side (t.o.m. versjon 3), elektronisk forsendelse via FIKS/SvarUT, og oppgaveorienterte elektroniske tjenester i form av «Veiledet dialog». I 2014 ble det lansert 31 nye elektroniske tjenester, og det er planlagt 29 nye i Kapittel 5 reflekterer status på utviklingen av fellesfunksjonalitet. I tillegg har programmets insentivprogram startet opp, og gjennom det har det kommet flere forslag til prosjekter som også peker på behov for felles funksjonalitet. Til sammen danner dette bakgrunn for det justerte målbildet og løsningsforslaget i kapittel Visjon og ambisjonsnivå for elektroniske tjenester Oslo kommune har som visjon å realisere digitalt førstevalg for tjenester til innbyggere og næringsliv. Byrådets ambisjonsnivå og målsetninger for de elektroniske tjenestene er beskrevet i budsjettet for 2013 som følger, jf. S2: Byrådet ønsker å tilby flere elektroniske tjenester til innbyggere og næringsliv på en samlet og brukervennlig måte gjennom digitale kanaler. Økt selvbetjening for kommunens brukere og helelektroniske prosesser i saksbehandling og tjenesteyting er sentralt. Økt tilgjengeliggjøring av kommunens åpne data 3 og grensesnitt vil gi grunnlag for innovasjon i markedet og skape et økt og bredt tjenestetilbud. Ambisjonsnivå og visjoner for kommunen er avgjørende for å stake ut retningen både administrativt og investeringsmessig for kommunen. Byrådet legger følgende ambisjonsnivå til grunn: 2 Dette ble videreført i byrådets forslag til budsjett for 2014, jf S2. 3 Arbeidet med åpne data er prioritert av programmet for elektroniske tjenester. I dette designet for fellesfunksjonalitet behandles området «åpne data» ikke som enkelttiltak. Bruk av standarder og åpne grensesnitt legger til rette for åpne data. Kommunen har også egne prosesser for å øke tilgjengeliggjøringen av kommunens offentlige data på data.norge.no. Videre vil et av prosjektene i insentivprogrammet utforme en strategi for utvikling og bruk av app-er i Oslo kommune, og i den forbindelse forventes det at åpne data blir et tema. 10

11 Brukerfokus evne til å effektivisere og fornye seg Flere innbyggere og dermed flere henvendelser digitale tjenester skal håndtere økningen Samhandling med innbyggere og næringsliv enklere og raskere Byrådets mål og ambisjoner er i tråd med arbeidet som gjøres i regi av regjeringen og på statlig nivå i offentlig sektor Brukerfokus evne til å effektivisere og fornye seg Å ha et brukerfokus medfører at kommunen må ha en evne til å effektivisere og fornye seg i tråd med de ulike brukergruppenes behov, motivasjon, forventninger og opplevelse av kommunens tjenester. Med utgangspunkt i dagens forståelse av de framtidige behov for Oslo kommunes brukere er følgende brukerprinsipper utarbeidet, jf. S1: Tabell 1: Brukerprinsipper basert på brukernes fremtidige behov ID Brukerprinsipper BP1 BP2 BP3 BP4 BP5 BP6 Når jeg trenger informasjon eller en tjeneste fra Oslo kommune, velger jeg de digitale kanalene Når jeg henvender meg til Oslo kommune via en digital kanal, klarer jeg raskt og enkelt å gjennomføre hele prosessen digitalt, og ved hvert steg veiledes jeg med støtte, status og veien videre Når jeg henvender meg til Oslo kommune via en digital kanal, oppleves informasjon og tjenester oppdaterte, etterrettelige, konsistente og forståelige Når jeg trenger eller velger det, oppdaterer og veileder Oslo kommune meg med proaktive digitale tjenester Når jeg trenger informasjon eller tjenester fra Oslo kommune, tilbyr kommunen digitale løsninger som er optimalisert for meg, hvor jeg er og det digitale mediet jeg har tilgjengelig Når jeg har behov utover Oslo kommunes tjenestetilbud, kan andre utvikle løsninger og skape innovasjon i markedet basert på kommunens åpne data og grensesnitt Prinsippene beskrevet ovenfor uttrykker et funksjonelt ambisjonsnivå for hvordan brukerne i fremtiden skal oppleve dialogen for samhandling med kommunen. Prinsippene gir føringer for elektroniske tjenester som tilbys fra kommunen til innbyggere og næringsliv. Løsningene som innfrir disse prinsippene vil være ulike, men utviklet i henhold til gjeldende arkitekturprinsipper og Difis anbefalte modell for digitalisering i offentlig sektor. Se S1 for mer utfyllende beskrivelse av hva som ligger i prinsippene. Helhetlig design detaljerer behov og føringer for arbeidet med realisering av felles funksjonalitet i kommunen og legger prinsippene knyttet til brukerbehov til grunn. I forbindelse med felles funksjonalitet vil prinsipp BP2 og BP4 være sentrale, i tillegg vil BP 1 og BP 5 være grunnleggende i forhold til designets utforming. 4 Det er stort overlapp mellom brukerprinsippene slik de er formulert av Oslo kommune og de syv brukerbehovene som senere er beskrevet i dokumentet «Visjon, ambisjon og strategi for felles kommunal IKT-arkitektur» 5 fra KS/KommIT. Veikart-arbeidet i regi av SKATE har også lagt de samme syv brukerbehovene med tillegget «Forenkling» som utgangspunkt for sitt arbeid. 6 SKATE formidler de samme behovene videre i sitt innspill til regjeringens arbeid med strategi for 4 Prinsipp 3 er ivaretatt gjennom prosjektet for nye nettsider for Oslo kommune, LØFTET. Første versjon av det nye nettstedet ble lansert i februar, og nye versjoner publiseres fortløpende. 5 Juni 2014, se: 6 SKATE-møtet juni 2014, se: 11

12 felleskomponenter. 7 I dette innspillet trekkes også «brukerreiser» frem som metode for å få frem brukerfokus i en helhetlig tilnærming, se også kapittel 4.2. I møtet i juni 2015 ga SKATE sin tilslutning til leveransen «Premisser, visjon, målbilder og strategier» som bl.a. angir «helhetlig tilnærming» og «brukerreiser» som arkitekturprinsipp. I saksfremlegget omtales formålet med brukerreiser: «Brukerreisene som jobbes fram på ulike områder vil definere de sektorovergripende funksjonelle målbildene, sett fra sluttbruker.» Flere innbyggere og dermed flere henvendelser digitale tjenester skal håndtere økningen Digitale tjenester skal legge til rette for at innbyggere og næringsliv gis økt mulighet for selvbetjening på nett, på tvers av brukerens plattformer (web, app, mv.). Arbeidet med digitale tjenester for innbyggere og næringsliv vil også innebære intern effektivisering i saksbehandlingsprosessene. Dette gjelder både i hver enkelt virksomhet og i samhandlingen som foregår på tvers og mellom virksomheter for å levere tjenester til innbyggere og næringsliv. Ambisjonen peker på utfordringen med hvordan kommunen skal håndtere en forventet innbyggerøkning og dermed økt bruk av kommunens tjenester i kombinasjon med endring av arbeidsprosesser som sikrer at tjenestene utvikles på en kostnadseffektiv måte. Gjennom elektroniske tjenester skal kommunen behandle og håndtere flere saker uten at kostnadene øker Samhandling med innbyggere og næringsliv enklere og raskere Samhandlingen og dialogen som foregår mellom kommunens virksomheter og innbyggere og næringsliv skal bli enklere og raskere. Dette gjelder både ved initiering av en tjenesteprosess, underveis i tjenesteprosessen og ved formidling av vedtak og beslutninger. 9 Enkle og gode løsninger som sikrer at rett og fullstendig informasjon skal være tilgjengelig ved behov i tjenesteprosessen, og at endringer eller avklaringer kan gjøres fortløpende når det er nødvendig. I tillegg vil digitale løsninger i forbindelse med forsendelser av vedtak og resultat av tjenesteprosessen være sentralt. Både mulighet til elektronisk dialog og tilgang til informasjon om status i saker vil bidra til at samhandlingen vil gå raskere og enklere i tjenesteprosessen. Utviklingen av digitale tjenester skal forankres i dokumenterte brukerbehov og -ønsker. 1.5 Overordnet visjon for felles funksjonalitet Overordnet visjon for felles funksjonalitet i Oslo kommune tar utgangspunkt i kommunens ambisjon om å realisere et digitalt førstevalg. Gjennom satsing på felles funksjonalitet er Oslo kommune i stand til å: utvikle nye digitale tjenester i takt med endringer i antall brukere og deres behov levere sine digitale tjenester effektivt og hensiktsmessig fremstå enhetlig og helhetlig overfor brukere i digitale kanaler tilrettelegge for at brukere av Oslo kommunes tjenester får løst sine oppgaver enkelt og effektivt i digitale kanaler 7 SKATE-møte april 2015, se: _innspill_fra_skate_til_regjeringens_strategi_for_felleskomponenter.pdf 8 Prosjekt Målbilder og strategier for fellesløsninger i offentlig sektor, leveranse 2: Premisser, visjon, målbilder og strategier. Se: _prosjekt_malbilder_og_strategier_leveranse_2_-_saksframlegg.pdf 9 Tjenesteprosessen er definert i Overordnet design som [ ] virksomhetens interne saksbehandlingsprosess og/eller øvrig behandling av en henvendelse fra en sluttbruker, jf. S1. 12

13 1.6 Rammebetingelser og prinsipper Følgende regelverk foreligger, og er rammebetingelser for arbeidet med helhetlig design: Lov om behandling av personopplysninger (personopplysningsloven) med Forskrift om behandling av personopplysninger (personopplysningsforskriften) Universell utforming - Forskrift om universell utforming av informasjons- og kommunikasjonsteknologiske (IKT)-løsninger Lov om behandlingsmåten i forvaltningssaker (forvaltningsloven) med Forskrift om elektronisk kommunikasjon med og i forvaltningen (eforvaltningsforskriften) Lov om rett til innsyn i dokument i offentleg verksemd (offentleglova). Oslo kommunes interne reglement som setter rammer og/eller påvirker helhetlig design: Reglement for informasjons- og kommunikasjonsteknologi og informasjonssikkerhet i Oslo kommune (IKT-reglementet), byrådssak /10 vedtatt av byrådet (S5). Arkitekturprinsippene i Oslo kommune (S4) Overordnet design Visjon, strategi og prinsipper (S1) I offentlig sektor legges det stor vekt på bruk av fellesfunksjonalitet og nasjonale felleskomponenter på tvers av statlige etater og kommuner. Dette er blant annet nedfelt i Regjeringens digitaliseringsprogram. Oslo kommune deltar aktivt i arbeidet med Veikart for nasjonale felleskomponenter, i regi av SKATE, for på den måten å sikre at de nasjonale felleskomponentene videreutvikles for å dekke kommunes behov. Gjennom Veikart-arbeidet er som nevnt blant annet helhetlig tilnærming samt brukerreiser som metode løftet frem og gitt videre som innspill til regjeringens arbeid med strategi for felleskomponenter Tilnærming og metode Første versjon av «Helhetlig design for felles funksjonalitet» ble jobbet frem av en designgruppe som representerte virksomhetene, og et kjerneteam (arbeidsutvalg). For å utarbeide et helhetlig design for felles funksjonalitet, var det nødvendig å fremskaffe et kunnskapsgrunnlag om brukernes og pilotvirksomhetenes behov og krav knyttet til elektroniske tjenester, som ble sammenholdt med de strategiske valg og prinsipper som er fastlagt i dokumentet Overordnet design Visjon, strategi og prinsipper for elektroniske tjenester. Behov og krav er knyttet til arbeidsprosessene omkring tjenesteleveransene som skal piloteres, og disse ble derfor kartlagt og dannet grunnlaget for en beskrivelse av nå-situasjon. Deretter ble ønsket situasjon beskrevet og til slutt analysert med tanke på å identifisere behov for felles funksjonalitet, og utarbeidelse av løsningskonsept. Dokumentasjonen av prosessen samt deltagerne i arbeidet er beskrevet i vedlegg 3. Gjeldende versjon av dokumentet er basert på et revisjonsarbeid våren 2015 der det primære målet har vært å oppdatere det funksjonelle målbildet for felles funksjonalitet og beskrivelsen av løsningen i kapittel 5. Arbeidet er gjennomført av prosjekt for felles funksjonalitet. Høsten 2014 ble det avholdt en workshop med produktrådet, som består av representanter for pilotvirksomhetene og utviklingsleverandøren, som resulterte i et justert målbilde. En viktig endring var å få med tjenestetypen «Veiledet dialog», som var kommet til som resultat av arbeid med brukerreiser og lansert i første versjon (Skjenkebevilling). Det har ikke vært avholdt nye workshops, men en-til-enmøter med deltagerne i prosjekt for felles funksjonalitet for å få innspill til endringer våren De jevnlige møtene i produktrådet og dokumentasjon på programmets wiki utgjør det viktigste grunnlaget for de reviderte tekstene. Endringene i målbildet og løsningsforslag er basert på erkjennelse og læring gjennom den konstruksjonsfasen programmet har vært igjennom. I gjennomgangen og oppfølgingen av søknadene til insentivordningen er det også identifisert nye og endrede krav til felles funksjonalitet. 10 Se fotnote 7 og 8 over. 13

14 Som en del av programmets fase 2 er det også utviklet en metode for tjenestedesign, «Metode for tjenestedesign i Oslo kommune», som blant annet beskriver bruk av teknikkene «brukerreiser» og utvikling av «proof of concept». Disse teknikkene er sentrale for å identifisere krav til felles funksjonalitet. Denne revisjonen innebærer ingen ny vurdering av behov eller mål, og kun noen få endringer på kravene i kapittel 4. Komponentene i løsningskonseptet er beskrevet i kapittel 5 med følgende egenskaper: 11 Komponentnavn Finnes komponenten fra før? - Er den komplett - Må den tilpasses - Utvikles / Anskaffes Hva er inndata til komponenten Hva produserer komponenten (Utdata / Funksjonalitet) Forutsetninger / Premisser Avgrensninger / Antakelser Avhengigheter til andre, grensesnitt Alternative løsninger Funksjonelt omfang (H/M/L) Unike avhengigheter (H/M/L) Komponentens navn Kort om komponenten finnes, eventuelt i korte trekk hva som må tilpasses. Kort hva som er inndata til komponenten der det er relevant Kort hva komponenten produserer der det er relevant. Eventuelle forutsetninger for realisering av komponenten Eventuelle avgrensninger eller antagelser for realisering av komponenten. Hvilke andre komponenter denne komponenten er avhengig av, eller har grensesnitt til. Kort hvilke alternative løsninger som har vært vurdert i designet. Antall funksjonelle områder eller endrede funksjonelle områder avgjør det funksjonelle omfanget (opptatt av den relative forskjellen mot de andre komponentene). Sammen med unike avhengigheter utgjør funksjonelt omfang komponentens kompleksitet. H = høy, M = middels og L= Lav Kombinasjon av hvorvidt standarder og grensesnitt er kjent, samt avhengigheter og omfang og hvilke andre komponenter denne komponenten er avhengig av, eller har grensesnitt til (opptatt av den relative forskjellen mot de andre komponentene). Sammen med funksjonelt omfang utgjør unike avhengigheter komponentens kompleksitet. H = høy, M = middels og L= Lav 11 Merk at med «komponent» menes i disse tabellene både komponenter og tjenester. 14

15 2 Behov for felles funksjonalitet 12 I dette kapitlet beskrives de interessenter som har interesser knyttet til felles funksjonalitet i Oslo kommune. Videre beskrives nåsituasjonen på området elektroniske tjenester, samt behovene for felles funksjonalitet i kommunen. Behovsbeskrivelsen tar utgangspunkt i en definisjon av hva som anses som behov og hvem det er som har disse behovene. 2.1 Begreper og definisjoner Behov forstås i dette kapitlet som det behovet som setter i gang etablering av felles funksjonalitet innen området elektroniske tjenester i Oslo kommune. Behovene kan være ønsker eller forventninger til felles funksjonalitet, eller en motivasjon/ambisjon om rollen til felles funksjonalitet i kommunen. Det er identifiserte behov som legges til grunn for iverksetting av tiltak, eksempelvis prosjekter, som skal adressere disse behovene på området felles funksjonalitet. En interessent er i dette kapitlet synonymt med en behovshaver eller aktør, det vil si en entitet være seg en fysisk person eller organisatorisk enhet som innehar et behov forbundet med felles funksjonalitet. Ulike interessenter kan ha forskjellige behov på området felles funksjonalitet, men alle interessenter har en interesse av å få sine spesifikke behov adressert. Nåsituasjon beskriver dagens tilstand for elektroniske tjenester i Oslo kommune, og gir mulighet til å identifisere eventuelle gap mellom dagens tilstand, og interessentenes behov og ønsker i fremtiden. 2.2 Sentrale interessenter Interessentene utgjør de sentrale aktørene som har interesser knyttet til felles funksjonalitet i Oslo kommune. Interessentene er gruppert i tre ulike perspektiver; konsernperspektiv, virksomhetsperspektiv og brukerperspektiv Oslo kommune som konsern Med konsernet Oslo kommune menes kommunen som helhet, på tvers av alle virksomhetene. Konsernet har ansvaret for å identifisere behov for sektorovergripende og koordinerende tiltak, herunder å ta initiativ til fellesløsninger for å sikre kvalitet, kostnadseffektivisering og oppfyllelse av politiske vedtak. Konsernet som interessent omfatter to øvrige interessentgrupper. Offentlig sektor, som representerer statlige virksomheter og andre kommuner med grensesnitt mot Oslo kommunes tjenester. Videre omfatter konsernperspektivet også IKT- leverandører, som leverer tjenester til Oslo kommune Offentlig sektor Offentlig sektor består av statlige og kommunale virksomheter. Sektoren er en del-interessent av konsernet, ettersom bruk av nasjonale og kommunale fellesløsninger i sektoren er sentral i forvaltningen og saksbehandlingen i kommunen og virksomhetene. Gjennom de elektroniske tjenestene vil konsernet også være en aktiv pådriver og deltaker i digitaliseringsarbeidet i offentlig sektor generelt, for å gi viktige innspill til utviklingen av nasjonale og kommunale fellesløsinger i sektoren. 12 Dette kapitlet er i hovedsak uendret fra versjon og inneholder den opprinnelige analysen av behov for fellesfunksjonalitet. 15

16 IKT- leverandørene Med IKT- leverandører menes her de eksterne leverandørene som bidrar i utviklingen av elektroniske tjenester for kommunen. De sektorovergripende behovene og løsningene i designet vil gi et viktig bilde av den arkitekturmessige konteksten som de elektroniske tjenestene lever i, og vil således påvirke både lokale og sentraliserte (felles) avtaler mellom kommunen og leverandørene Virksomheter i kommunen Virksomhetsperspektiv (internt) omfatter virksomhetene i Oslo kommune, som er produsentene av tjenester til brukerne. Virksomhetene er representert ved et utvalg av pilotvirksomheter. Flere kommunale virksomheter kan være involvert i å produsere en tjeneste. Kommunens virksomheter har ansvar for utøvelse av myndighet og leveranse av tjenester på sine områder. Det betyr at de også har ansvaret for utforming og innhold av sine tjenesteprosesser Innbyggere og næringsliv Innbyggerne som gruppe er en interessent som brukere av virksomhetenes tjenester. Videre er også næringslivet, inkl. frivillige organisasjoner, som brukere av virksomhetenes tjenester som gruppe en interessent. I denne brukergruppen ligger også andre kommunale og statlige virksomheter som brukere av tjenestene fra kommunens virksomheter. Innbyggere og næringsliv er to ulike interessentgrupper, men blir i dette dokumentet behandlet som en gruppe. Bakgrunnen er at det ikke er funnet hensiktsmessig å skille mellom de to i analysen og kravspesifiseringen knyttet til felles funksjonalitet i Oslo kommune Om innbyggere Innbyggere er hovedbrukerne av Oslo kommunes elektroniske tjenester. Innbyggere er svært sammensatt brukergruppe, med en varierende digital kompetanse og behov. Kommunen leverer tjenester til sine innbyggere i et livsløpsperspektiv gjennom om lag kommunale tjenester, hvorav i underkant av 200 er lovpålagte Om næringsliv Næringsliv er en viktig brukergruppe for elektroniske tjenester. Effektiv elektronisk samhandling mellom næringslivet og kommunen er et mål, enten kommunen opptrer i rollen som tjenesteyter eller som utøver av forvaltningsmyndighet. Næringslivet inkluderer frivillige organisasjoner, både som viktige samarbeidspartnere og som tjenestebrukere. Næringslivet som brukergruppe inkluderer også andre kommunale og statlige virksomheter der disse er brukere av kommunens tjenester. 2.3 Nåsituasjon for elektroniske tjenester I byrådets budsjett for 2013 heter det at Digitalt førstevalg skal være den prioriterte kanalen for dialog med brukerne av kommunens tjenester, jf. S3. Gjennom arbeidet med digitalt førstevalg skal Oslo kommune tilrettelegge for at brukerne (innbyggere og næringsliv) kan kommunisere med kommunen i den digitale kanalen. Ut i fra nåsituasjonen anses derfor digitalt førstevalg som en vesentlig driver for de behovene Oslo kommune har for utvikling av ny felles funksjonalitet. Digitale kanaler er i dag tilgjengelig via en rekke forskjellige plattformer (PC, smart-telefoner, nettbrett mv.), og kommunikasjonsformene kan variere fra for eksempel strukturert innsamling av data gjennom elektroniske skjema, til meldinger på SMS, e-post og annet. Den teknologiske utviklingen på området 16

17 har gått raskt, og er pågående. Det er også grunn til å anta at bruken av de nye plattformene på den digitale kanalen vil vinne stadig større utbredelse ved at flere tar de i bruk til nye oppgaver. Digitale kanaler eksisterer side om side med tradisjonelle kanaler som oppmøte, telefon, fysisk post. Figuren under viser hvordan brukerne kommuniserer på tvers av disse kanalene, og forholdet til virksomhetenes systemer. Figur 2 Brukerne kommuniserer i flere kanaler i sin dialog med kommunen Figuren illustrerer at de tradisjonelle kanalene går via manuelle steg og saksbehandler, mens det i den digitale kanalen kan gå direkte til virksomhetssystemene. Erfaring viser at brukerne vil benytte tilgjengelige kanaler om hverandre i samme saksforhold. Dette krever en tilnærming på tvers av kanaler i kommunens tjenesteytelse, slik at oppdateringer og forespørsler gjort i én kanal, også tar virkning og er tilgjengelig i de øvrige kanalene. I tråd med regjeringens digitaliseringsprogram 13 har Oslo kommune besluttet at det er den digitale kanalen som skal prioriteres, jf. S2. Det er derfor denne kanalen som er hovedfokuset i dette dokumentet. Nåsituasjonen på området elektroniske tjenester ble oppsummert i dokumentet Strategi for elektroniske tjenester (R2), her sammenstilt i Tabell «På nett med innbyggerne» Regjeringens digitaliseringsprogram april

18 Tabell 2:Beskrivelse av nåsituasjon for elektroniske tjenester ID Beskrivelse av nåsituasjon N1 N2 N3 N4 Få og mangelfulle elektroniske tjenester Oslo kommune tilbyr få elektroniske tjenester i tillegg er det manglende integrasjon med sakssystemer. Dette reduserer nytteverdi og effekt, spesielt i forhold til gjenbruk og forvaltning av fellesinformasjon/data. Manglende fellesfunksjonalitet hindrer utvikling av nye tjenester Det er mangel på felles løsningsfunksjonalitet som hindrer at virksomhetene får implementert flere og fullverdige elektroniske tjenester. Dette gjelder både innloggings- og autentiseringsløsning, elektronisk utsendelse, status og innsynsløsning og felles kartløsning for å nevne noe. Lav digital modenhet Lav digital modenhet reduserer kommunens mulighet til å utnytte elektroniske tjenester som virkemiddel for gjennomføring av prosessendringer og effektiviseringstiltak. Begrensninger i dagens IKT-infrastruktur og behov for oppgradering av kommunens grunnmur for presentasjon og tilgjengeliggjøring av elektroniske tjenester 14 Nåsituasjonen for elektroniske tjenester i Oslo kommune har medført at kommunen startet en helhetlig satsning. En nærmere beskrivelse av nåsituasjonen for punktene N1-N3 følger under i kapittel til Merk at beskrivelsene ikke er oppdaterte for å reflektere situasjonen på tidspunktet for revisjon av dokumentet (våren 2015), ettersom dette er begrunnelser som var relevante for å starte arbeidet i sin tid. Kort fortalt er det nå etablert flere nye elektroniske tjenester, jfr N1, og mer felles funksjonalitet er på plass, jfr N2. Men det viktigste å nevne er kanskje erfaringene fra fase 2 som viser at utviklingsmetodikken (tjenestedesign) har stor effekt på den digitale modenheten. Dette gjelder særlig for teknikken «brukerreiser». N4 som omhandler dagens IKT-infrastruktur vil ikke bli behandlet videre i dette dokumentet, da dette inngikk i et eget prosjekt som nylig er gjennomført av Oslo kommune. Det kan komme eventuelle nye endringsbehov i infrastrukturen som følge av arbeidet med elektroniske tjenester. Nye endringsbehov i infrastrukturen er ikke behandlet i dette dokumentet, men fremkommer i detaljert design og gjennomføringsplaner Få og mangelfulle elektroniske tjenester En mangfoldig systemportefølje: Sektoransvaret og forskjellene i kompleksiteten knyttet til saksbehandling på tjenesteområdene har resultert i et antall ulike løsninger og implementeringer av teknologi. Funksjonaliteten som disse systemene tilbyr, er også av ulikt omfang, noe som sammen med ulike grensesnitt har gjort standardisering problematisk. Videre er det i dag hver virksomhet sitt ansvar å håndtere journal- og arkivbehov. Dette har resultert i at det er svært ulikt nivå på løsningene. Mange virksomheter har i dag ikke godkjent elektronisk arkiv, og/eller arkivløsninger som følger NOARK-standarden. Forventninger og krav fra omverden: Forventningene fra kommunens innbyggere og næringsliv endres i takt med en teknologiutvikling og et tjenestetilbud fra både offentlige og private virksomheter utenfor kommunen. Som med kommersielle tjenester, forventer innbyggere og næringsliv i dag å kunne gjennomføre de fleste av sine oppgaver hos kommunen elektronisk, og at de informeres og oppdateres proaktivt om sitt saks- og kundeforhold. 14 Oslo kommune gjennomførte et eget prosjekt for oppgradering av kommunens infrastruktur som ble avsluttet våren

19 2.3.2 Manglende fellesfunksjonalitet hindrer utvikling av nye tjenester Utvikling av nasjonale og kommunale felleskomponenter er pågående: Oslo kommune sin strategi er å ta i bruk eksterne felleskomponenter, samt være involvert og engasjert i arbeidet med styring og utvikling av disse, både på kommunalt og statlig nivå. Det er derfor avgjørende med en fleksibilitet i kommunens IKT-infrastruktur, slik at nødvendige tilpasninger og utskiftninger av systemer kan gjøres på en tids- og kostnadseffektiv måte. Mangelfull utnyttelse av eksisterende fellesløsninger i kommunen: Kommunen har allerede investert i flere integrasjonstjenester og felles grensesnitt mot brukerne og eksterne felleskomponenter. Mangfoldet i systemporteføljen har ført til en lavere utnyttelse av disse enn ønsket. Arkitekturprinsippene i kommunen tilsier videre at disse investeringene skal gjenbrukes i størst mulig grad Lav digital modenhet Begrenset med kompetanse og ressurser i kommunens virksomheter for å utnytte teknologisk muligheter: Hver for seg har kommunens virksomheter begrenset med kompetanse og ressurser knyttet til mulighetsrommet for å endre arbeidsprosesser og tilby digitale tjenester til sine sluttbrukere. Dette i kombinasjon med finansierings- og styringssystemet gjør at kommunen ikke klarer å ta i bruk eller fullt ut utnytte muligheter som foreligger for å realisere nye og proaktive elektroniske tjenester for innbyggere og næringsliv på en systematisk måte. Lite automatisert samhandling på tvers av virksomhetene: Mange virksomheter er avhengig av samhandling på tvers av sektorer i sin tjenesteytelse. Det er i dag svært få integrasjoner mellom systemer på tvers av sektorer og tjenesteområder. Der slike integrasjoner eksisterer, har mangfoldet i systemporteføljen ført til at den elektroniske samhandlingen ivaretas gjennom punkt-til-punkt integrasjoner. Slike integrasjoner medfører igjen et høyt antall avhengigheter som må hensyntas når endringer skal gjennomføres, eksempelvis som følge av krav fra brukere eller politiske føringer. 2.4 Brukerbehov Innbyggere og næringsliv (inkl. frivillige organisasjoner) står sentralt i Digitalt førstevalg. Behovene til innbyggerne og næringslivet knytter seg til brukeropplevelsen som innbyggere og næringsliv forventer at de elektroniske tjenestene skal gi i de digitale kanalene, dvs. over internett, uavhengig av plattform (PC, smart-telefoner, nettbrett, mv.). Behovene er oppsummert i følgende tabell: Tabell 3: Brukerbehov for felles funksjonalitet ID BB1 Identifiserte behov Behov for rask og enkel saksbehandling særlig med tanke på brukerrettet saks- og tjenesteinformasjon og veiledning Ivaretar følgende brukerprinsipper BP2, BP3, BP5, BP6 BB2 Behov for rask og enkel tilgang på informasjon særlig med tanke på bruk av digitale forsendelser, innsyn og autentisering og autorisasjon BP1, BP4, BP6 19

20 2.5 Virksomhetsbehov Virksomhetenes behov er primært knyttet til de tjenestene som skal innfri innbyggerne og næringslivets behov, på sitt tjenesteområde. Virksomhetene har i tillegg behov i sine prosesser som ikke direkte synes for brukeren, knyttet til samhandling og støttetjenester. Behovene er oppsummert i følgende tabell: Tabell 4: Virksomhetsbehov for felles funksjonalitet ID Identifiserte behov VB1 Behov for forenkling, økt selvbetjeningsgrad og innsyn i saksbehandlingsprosesser særlig med tanke på strukturering og formalisering av henvendelser, bruk av felles informasjonskilder og brukerrettet saks- og tjenesteinformasjon. VB2 VB3 Behov for økt samhandling mellom virksomheter og innbygger/næringsliv i den digitale kanalen særlig med tanke på informasjon og veiledning, bruk av digitale forsendelser og innsyn Behov for enklere etterlevelse av lover og forskrifter eksempelvis i forhold til virksomhetenes behov for å sikre komplett saksgrunnlag og likebehandling 2.6 Konsernbehov Oslo kommune som konsern har en rekke overordnede behov knyttet til felles funksjonalitet. Basert på en forståelse av utfordringer i nåsituasjonen for elektroniske tjenester i Oslo kommune er det identifisert et sett overordnede konsernbehov kommunen har knyttet til felles funksjonalitet. Disse behovene er oppsummert i følgende tabell: Tabell 5: Overordnede konsernbehov for felles funksjonalitet ID Identifiserte behov KB1 KB2 KB3 KB4 KB5 KB6 KB7 Behov for flere og rikere elektroniske tjenester særlig med tanke på integrasjon med sakssystemer, og gjenbruk og forvaltning av fellesinformasjon/data Behov for felles funksjonalitet som akselererer utviklingen av nye tjenester særlig med tanke på gjenbruk/utvikling av nasjonale og kommunale felleskomponenter og utnyttelse av eksisterende fellesløsninger i kommunen, samt påvirke og utnytte fremtidige løsninger for offentlig sektor på en kostnadseffektiv måte Behov for økt digital modenhet særlig med tanke på bedre utnyttelse av kompetanse og ressurser for å utnytte teknologiske muligheter, samt endring av arbeidsprosesser Behov for proaktivt møte med brukernes forventninger og krav til kommunens tjenesteytelse Behov for å fremstå enhetlig ovenfor brukerne på tvers av sektorer og digitale kanaler Behov for økt gjennomføringsevne - særlig med tanke på å kunne levere nye tjenester på en raskere måte for å sikre måloppnåelse iht. ambisjonsnivåene Behov for helhetlig håndtering av risiko særlig med tanke på investeringer i nye elektroniske tjenester 20

21 2.7 Oppsummering Nåsituasjonen for elektroniske tjenester i Oslo kommune viser at kommunen har få og mangelfulle elektroniske tjenester, manglende fellesfunksjonalitet som hindrer utvikling av nye tjenester og lav digital modenhet. Med utgangspunkt i nåsituasjonen er det identifisert både overordnede konsern-, virksomhets- og brukerbehov for felles funksjonalitet i Oslo kommune. Som konsern har kommunen behov for flere og rikere elektroniske tjenester, behov for fellesfunksjonalitet som akselererer utviklingen av nye tjenester, behov for økt digital modenhet og behov for å proaktivt møte brukernes forventninger og krav til kommunens tjenesteytelse. Videre har konsernet Oslo kommune behov for å fremstå enhetlig ovenfor brukerne på tvers av sektorer og kanaler, behov for å øke gjennomføringsevnen til konsernet, samt behov for helhetlig håndtering av risiko. Virksomhetsbehovene er knyttet til forenkling, økt selvbetjeningsgrad og åpenhet i saksbehandlingsprosesser, økt samhandling mellom virksomheter og innbygger/næringsliv i den digitale kanalen, samt enklere etterlevelse av lover og forskrifter. Brukerne i Oslo kommune har behov for rask og enkel saksbehandling, og rask og enkel tilgang på informasjon. Som følge av programmets fase 2 produksjon og utprøving er nåsituasjonen allerede forbedret ved at det er realisert noen flere tjenester og felles funksjonalitet. Dette har gitt viktige erfaringer som gjenspeiles i kapittel 5 funksjonelt målbilde og løsningsforslag. 21

22 3 Målsettinger for felles funksjonalitet 15 Dette kapitelet beskriver målsettinger for Oslo kommunes satsing på helhetlig design for felles funksjonalitet. Videre beskriver det i hvilken grad målene adresserer behovene som er identifisert i kapittel Begreper og definisjoner Mål forstås i denne sammenheng som en konkretisering av hva Oslo kommune skal oppnå med felles funksjonalitet innen elektroniske tjenester. Mål kan konkretiseres for nær og fjern framtid, og gir anvisning for kommunens arbeid med felles funksjonalitet, rettferdiggjør arbeidet, skaper motivasjon, virker samlende, og gir kommunen en konkret ambisjon å strekke seg mot. 3.2 Overordnede mål for felles funksjonalitet Oslo kommune som konsern har et overordnet mål om at virksomhetenes tjenesteproduksjon gjøres på en kostnadseffektiv måte for kommunen som helhet, og at kommunen beveger seg i retning av sin visjon og ambisjonsnivå. For konsernet Oslo kommune betyr dette at sektorovergripende bruker- og virksomhetsbehov knyttet til elektroniske tjenester skal adresseres sentralt der dette gir stordriftsfordeler, økt kostnadseffektivitet og/eller høyere brukertilfredshet. Basert på kommunens visjon for felles funksjonalitet, nåsituasjon, identifiserte behov og informasjon fra intervjuer er det definert fire overordnede målkategorier. Målkategoriene og tilhørende målsettinger for felles funksjonalitet er oppsummert i Tabell 6. Tabell 6: Målformulering for kommunens arbeid med helhetlig design for felles funksjonalitet ID Målkategorier ID Målsetting M1 Koordinering på konsernnivå M1.1 Fremstå som et enhetlig konsern ovenfor innbyggere og næringsliv M2 Kostnadseffektivitet (herunder stordriftsfordeler) M1.2 Fremstå som en moden digital aktør ovenfor innbyggere og næringsliv M1.3 God og hensiktsmessig samhandling på konsern- og virksomhetsnivå for utvikling av elektroniske tjenester M2.1 Raskere utvikling av nye elektroniske tjenester for den enkelte virksomhet og for Oslo kommune totalt M2.2 Kostnadseffektiv drifting og forvaltning av nye elektroniske tjenester for Oslo kommune som helhet M2.3 Gjenbruk av funksjonalitet som er felles M2.4 Effektiv tjenesteproduksjon i virksomhetene M3 Brukertilfredshet M3.1 Brukertilfredshet hos innbyggere og næringsliv Målsettingene definerer ambisjonsnivået til Oslo kommune, og deres satsing på felles funksjonalitet. Målsettingene er utdypet ytterligere i kapittel til Det er ingen endringer i dette kapitlet sammenlignet med første versjon av dokumentet målsetningene er de samme. 22

23 3.2.1 Koordinering på konsernnivå (M1) Felles funksjonalitet i Oslo kommune krever koordinering både internt og i forhold til eksterne aktører. En målsetting om økt koordinering på konsernnivå i Oslo kommune innebærer at kommunen skal være en tydelig og faglig sterk samarbeidspartner for å ivareta kommunens behov og krav i utviklingen og forvaltningen av de nasjonale felleskomponentene (stat og kommune). Videre inkluderer målsettingen økt forenkling og modernisering av kommunen som leder til økt digital modenhet Kostnadseffektivitet (herunder stordriftsfordeler) (M2) En overordnet målsetting for Oslo kommunes satsing på felles funksjonalitet er kostnadseffektivitet. Felles funksjonalitet vil gi kommunen stordriftsfordeler ved at virksomhetene kan gjenbruke og eventuelt fase ut systemløsninger for ellers like prosesser. Dette vil føre til økt utnyttelse av informasjon, systemer og løsninger. Videre vil det gi raskere og mer kostnadseffektiv utvikling og drifting av nye tjenester for den enkelte virksomhet og for Oslo kommune totalt. Felles funksjonalitet vil også gi økt automatiseringsgrad og endring av virksomhetenes saksbehandlingsprosesser, og dermed redusering av manuelle prosesser og saksbehandlingstid. Dette vil gi grunnlag for mer proaktive tjenester overfor kommunens innbyggere og næringsliv. Samtidig vil økt digital modenhet i kommunens virksomheter være med å sikre at elektroniske tjenester kan realiseres raskere, enklere og mer effektivt Brukertilfredshet (M3) Oslo kommune har som målsetting å øke brukertilfredsheten hos sentrale brukergrupper. Etablering av felles funksjonalitet vil bidra til økt brukertilfredshet ved at: Kommunens innbyggere og næringsliv kan ta informerte valg, blant annet gjennom veiledet dialog, proaktivitet, abonnementstjenester og innsynsløsninger. Innbyggere og næringslivet kan gjennomføre hele tjenesteprosessen med Oslo kommune digitalt. I tillegg skal felles funksjonalitet sikre bedre innsyn i tjenesteprosessen og status knyttet til denne. Informasjon fra virksomhetenes tjenester tilgjengeliggjøres og presenteres for innbyggere og næringsliv på en felles og standardisert måte i de digitale kanalene Fellesfunksjonalitet vil sikre at innbyggere og næringsliv får en enhetlig opplevelse av Oslo kommunes elektroniske tjenester fordi felles funksjonalitet sikrer mer effektive, likeartede og helhetlige tjenester til sluttbrukere. Økt forutsigbarhet for kommunens brukere. Kommunen tar i bruk nasjonale og kommunale felleskomponenter som fører til at flere vil ta i bruk og gjennomføre tjenestene digitalt. Tjenestene fra offentlig sektor får gjenkjennbare prosesser, uavhengig av hvilke kommunale virksomheter som er ansvarlig for tjenestene og uavhengig av om tjenesten er kommunal eller statlig (lavere brukerterskel). 23

24 3.3 Sammenheng mellom behov og mål Oslo kommunes målsettinger for felles funksjonalitet må ses i sammenheng med identifiserte behov. Tabell 7 nedenfor illustrerer sammenhengen mellom behovene beskrevet i kapittel 2 og målene beskrevet i dette kapitlet. Tabell 7: Illustrasjon av mål versus behov for felles funksjonalitet Målkategori M1: Koordinering på konsernnivå / digital M2: Kostnadseffektivitet (herunder Behov modenhet stordriftsfordeler) KB1: Flere og rikere elektroniske tjenester Økt koordinering på konsernnivå vil bidra til at nye elektroniske tjenester som utvikles fremstår som enhetlige overfor innbyggere og næringsliv. Flere og rikere elektroniske tjenester vil bidra til at en større andel av innbyggere og næringsliv vil foretrekke den digitale kanalen fremfor mer tradisjonelle kanaler. Dette vil bidra til økt kostnadseffektivitet i forhold til Oslo kommunes tjenesteytelse overfor innbyggere og næringsliv. M3: Brukertilfredshet Flere og rikere elektroniske tjenester gjør Oslo kommune i stand til å levere proaktive tjenester som er målrettet og individuelt tilpasset brukerne, og dermed møter de behovene brukerne har på området elektroniske tjenester. Brukertilfredshet kan dermed benyttes til å kartlegge om kommunen evner å utarbeide flere og rikere elektroniske tjenester. KB2: Felles funksjonalitet som akselererer utviklingen av nye tjenester Økt koordinering på konsernnivå vil gi mer forutsigbarhet for virksomhetene i Oslo kommune i forhold til hvilken funksjonalitet som er tilgjengelig i fremtiden og når den blir tilgjengeliggjort for virksomhetene. Felles funksjonalitet gir større fleksibilitet i tjenesteutviklingen for konsernet som helhet, og funksjonaliteten som bygges vil kunne gjenbrukes på tvers av Oslo kommunes virksomheter. Videre vil nye elektroniske tjenester også kunne bygges på gjenbruk av eksisterende funksjonalitet. Dette vil medføre kostnadseffektivisering gjennom kortere utviklingstid, lavere utviklingskostnader og stordriftsfordeler. Utviklingen av nye elektroniske tjenester i Oslo kommune er sentralt for å kunne tilfredsstille brukernes behov. Felles funksjonalitet bidrar til raskere utvikling av nye tjenester. Måling av brukertilfredshet vil bidra til å synliggjøre om kommunen utvikler elektroniske tjenester som dekker brukernes behov. KB3: Økt digital modenhet Koordinering på konsernnivå innebærer bedre utnyttelse av kommunens kompetanse og ressurser i deres tilbud av digitale tjenester, samt økt samhandling og integrasjon mellom systemer på tvers av sektorer og tjenesteområder. Økt samarbeid, forenkling og modernisering vil dermed bidra til økt digital modenhet i kommunen. Innføring av elektroniske tjenester som deler funksjonalitet vil gi stordriftsfordeler og være kostnadseffektivt for Oslo kommune. Gjennom standardisering og bruk av felles funksjonalitet for elektroniske tjenester opparbeides erfaring og kompetanse til å effektivisere og endre arbeidsprosesser, og dette vil således bidra til å øke kommunens digitale modenhet. Ett kjennetegn ved digital modenhet er at man er bevisst hvilke behov brukerne har, og at man klarer å innfri disse behovene ved hensiktsmessige teknologiske løsninger. Brukertilfredshet er målbart og vil dermed bidra til å synliggjøre om Oslo kommune evner å utarbeide nye elektroniske tjenester. 24

25 Behov Målkategori KB4: Behov for proaktivt møte med brukernes forventninger og krav til kommunens tjenesteytelse M1: Koordinering på konsernnivå / digital modenhet Økt koordinering på konsernnivå vil skape en bedre forståelse av hvem brukerne er og dermed bidra til en mer samlet tilnærming for å proaktivt møte innbyggere og næringsliv. M2: Kostnadseffektivitet (herunder stordriftsfordeler) Gjennom mer proaktivt møte med brukerne kan Oslo kommune i større grad styre kommunikasjonen med brukerne, slik at kommunen kan påvirker når henvendelser fra brukerne kommer. Mer proaktiv kommunikasjon med brukerne vil også lede til økt overholdelse av tidsfrister fra brukernes side. Dette vil lede til kostnadseffektivitet gjennom mer effektiv bruk av tid hos saksbehandlere og mer målrettet kommunikasjon. M3: Brukertilfredshet Proaktivt møte brukernes behov, forventninger og krav vil lede til øke brukertilfredshet i Oslo kommune. KB5: Behov for å fremstå enhetlig ovenfor brukerne på tvers av sektorer og kanaler Det vil være enklere for Oslo kommune å fremstå enhetlig ovenfor brukerne ved at elektroniske tjenester i kommunen i større grad er koordinert på konsernnivå enn på virksomhetsnivå. Gjennom etablering av felles funksjonalitet vil Oslo kommune på en kostnadseffektiv måte klare å tilfredsstille behov som er felles på tvers av virksomhetene. Det antas at en enhetlig kommunikasjon mellom Oslo kommunes virksomheter og innbyggere/næringsliv vil lede til økt brukertilfredshet. B6: Behov for økt gjennomføringsevne Koordinering på konsernnivå er en forutsetning for å kunne gjenbruke funksjonalitet som er felles og vil øke Oslo kommunes gjennomføringsevne ved at kommunen på en effektiv måte kan igangsette tiltak på konsernnivå ved utvikling av elektroniske tjenester. Felles funksjonalitet vil bidra til raskere tjenesteutvikling og dermed mer kostnadseffektiv drifting og forvaltning av løsningene i Oslo kommune. Videre vil det øke grunnlaget for større grad av komplett saksgrunnlag. Felles funksjonalitet vil øke kommunens gjennomføringsevne som vil lede til raskere tjenesteutvikling, som igjen leder til at brukerne raskere får tilfredsstilt sine behov. Dette vil lede til økt brukertilfredshet. KB7: Behov for helhetlig håndtering av risiko Økt koordinering på konsernnivå vil danne grunnlag for en helhetlig håndtering av risiko på tvers av Oslo kommunes virksomheter. Dette vil gi muligheter for å adressere risikoområder som går på tvers av virksomhetene bedre enn hvis de blir håndtert av hver enkelt virksomhet. Helhetlig håndtering av risiko vil bidra til kostnadskontroll i forhold til bruk av felles funksjonalitet i Oslo kommune. Helhetlig risikohåndtering vil bidra til at områder som omdømmerisiko vil kunne håndteres bedre på tvers av virksomhetene i Oslo kommune. 25

26 4 Overordnede krav for felles funksjonalitet Dette kapitlet beskriver overordnede krav for felles funksjonalitet i Oslo kommune. Kravene er basert på behov og målsettinger som er identifisert i tidligere kapitler. I tillegg er det lagt til to krav basert på erfaringer fra av programmets fase 2 produksjon og utprøving Begreper og definisjoner Krav definerer hva som kreves av løsningen for at Oslo kommune skal kunne innfri behov og målsetting som er satt for felles funksjonalitet. Krav kan for eksempel dreie seg om krav til ytelse. Krav skal være løsningsnøytrale, og det er god praksis å skille mellom «skal» og «bør» krav. I helhetlig design for felles funksjonalitet defineres de overordnede kravene som fremkommer i kapittel 4 som «skal» krav. I detaljert design vil de overordnede kravene konkretisert nærmere og bli prioritert. En egen klasse krav, de normative kravene, er avledet fra rammene, for eksempel lover og regler. 4.2 Krav i brukerreisen Basert på en analyse av behovene til innbyggere og næringsliv i Oslo kommune er det identifisert en brukerreise som følger brukeren fra en orienteringsfase til hans/hennes oppgaver hos kommunen er fullført. Brukerreisen viser at brukeren har en rekke kontaktpunkter i sin dialog med kommunen, på tvers av kanaler. Brukerreisen er illustrert i Figur 3. Den grunnleggende ideen er at brukeropplevelsen skal være god gjennom hele tjenesteprosessen, understøttet av felles elektroniske støttefunksjoner i kombinasjon med fagspesifikke funksjoner i virksomhetene. Brukeren skal oppleve at tjenestene er enkle å forstå, og gir brukeren en opplevelse av at han eller hun blir betjent på tvers av systemer og sektorer, i en gjenkjennelig brukerfront. Kommunale tjenester skal fremstå som enkle å benytte, selv om innholdet og tjenesteområdene er ulike. Brukerens behov skal innfris gjennom hele prosessen, fra veiledning og orientering, til resultat og svar. Figur 3 Brukerreisen viser et referansebilde av innbyggere og næringslivets opplevelser og behov underveis i møtet med en kommunal tjeneste, på tvers av ulike kanaler 16 Krav K1.10 og K6.7, jfr hhv kapittel og

27 Brukerreisen gir en forståelse av hvordan brukerprinsippene som ble definert i Overordnet Design og skissert i kapittel skal i varetas gjennom på felles funksjonalitet og digital tjenesteytelse ovenfor innbyggere og næringsliv. Gjennom arbeidet med å kartlegge nåsituasjon, behov og mål for felles funksjonalitet er det identifisert syv overordnede løsningsområder i brukerreisen med behov for felles tiltak. Disse syv overordnede løsningsområdene er oppsummert i Tabell 8, og må ses i sammenheng med brukerreisen for innbyggere og næringsliv sin dialog med kommunen i de digitale kanalene. Tabell 8 illustrerer på hvilke områder i brukerreisen de syv løsningsområdene berører. Tabell 8: Sammenheng mellom identifiserte løsningsområder og brukerreisen i Oslo kommune ID Løsningsområder Orientering Dialog Behandling Svar og oppfølging LO1 Strukturerte og formaliserte henvendelser X LO2 Felles informasjonskilder X X X X LO3 Informasjon og veiledning X X X LO4 Autentisering og autorisasjon X X X X LO5 Digitale forsendelser X X LO6 Brukerrettet saks- og tjenesteinformasjon X LO7 Offentlig innsyn X X X 4.3 Overordnede krav Identifiserte løsningsområder oppsummert i Tabell 8 danner utgangspunktet for overordnede krav for felles funksjonalitet. Overordnede krav er oppsummert i Tabell 9. For hver av de syv overordnede kravene er det tilhørende krav til felles funksjonalitet. Disse kravene er nærmere utdypet i Tabell 10 til Tabell 16. Tabell 9: Overordnede krav til felles funksjonalitet ID Type Overordnede krav K1 Funk. Strukturerte og formaliserte henvendelser: Alle henvendelser skal behandles på en strukturert og formalisert måte K2 Funk. Felles informasjonskilder: Det skal benyttes felles informasjonskilder i kommunikasjonen med innbyggere og næringsliv K3 Funk. Informasjon og veiledning: Det skal gis god informasjon og veiledning til innbyggere og næringsliv K4 Funk. Autentisering og autorisasjon: Det skal benyttes autentisering og autorisasjon i kommunikasjonen med innbyggere og næringsliv K5 Funk. Digitale forsendelser: Det skal benyttes digitale forsendelser i kommunikasjonen med innbyggere og næringsliv K6 Funk. Brukerrettet saks- og tjenesteinformasjon: Innbyggere og næringsliv skal gis brukerrettet saks- og tjenesteinformasjon K7 Funk. Offentlig innsyn: Innbyggere og næringsliv skal gis innsyn i offentlig informasjon 27

28 4.3.1 Krav til strukturerte og formaliserte henvendelser For å tilfredsstille konsernet Oslo kommune, virksomhetene og brukernes behov for digitale tjenester må dette skje gjennom strukturerte og formaliserte henvendelser. Tabell 10 inneholder de overordnede kravene til felles funksjonalitet knyttet til strukturerte og formaliserte henvendelser. Tabell 10: Krav til strukturerte og formaliserte henvendelser ID Type Krav K1.1 Funk. Det skal legges til rette for standardiserte henvendelser i de digitale kanalene K1.2 Funk. Henvendelser i de digitale kanalene skal kunne valideres automatisk K1.3 Funk. Brukere som henvender seg i de digitale kanalene skal veiledes og følges opp i en automatisk saksflyt K1.4 Funk. Det skal legges til rette for flere proaktive tjenester i de digitale kanalene K1.5 Funk. Informasjon og saksdokumentasjon fra innbygger og næringsliv skal kunne avgis elektronisk gjennom sikker opplasting og håndtering av vedlegg K1.6 Funk. Informasjon skal kunne ettersendes på en eksisterende sak K1.7 Funk. Saksinformasjon fra brukerdialogen (skjema) skal kunne fordeles til rett adressat gjennom automatisert flyt av til journal/arkivsystem K1.8 Funk. Saker forbundet med henvendelser i de digitale kanalene skal kunne opprettes automatisk i journal-/arkivsystem (integrasjon mellom skjemaløsning og journal- /arkivsystem) K1.9 Funk. I elektroniske skjemaer/skjemadialoger skal brukerinformasjon og annen saksinformasjon kunne preutfylles automatisk fra underliggende informasjonskilder K1.10 (Ny) Funk Korrespondanse med andre aktører underveis i en saksbehandling for å supplere saken med uttalelser eller annen informasjon. I noen tilfeller er kommunen ansvarlig for dette, i andre tilfeller er det søkeren. Partene kan være andre deler av Oslo kommune, andre kommuner, andre offentlige etater, private virksomheter eller personer Krav til felles informasjonskilder Tabell 11 inneholder de overordnede kravene til felles funksjonalitet knyttet til felles informasjonskilder i Oslo kommune. Tabell 11: Krav til felles informasjonskilder ID Type Krav K2.1 Funk. Gjennom deling av informasjonskilder på tvers av virksomhetenes elektroniske tjenester skal innbyggere og næringsliv oppleve Oslo kommune som én koordinert og enhetlig aktør K2.2 Funk. Informasjonskildene skal tilgjengeliggjøres for bruk i virksomhetenes elektroniske tjenester gjennom standardiserte grensesnitt 17 Dette kravet er nytt i versjon 1.1 og er bl.a. identifisert i brukereisen for fornyelse av skjenkebevilling, brukerreisen for nabovarsel og brukerreisen for rammetillatelse 28

29 4.3.3 Krav til informasjon og veiledning Tabell 12 inneholder de overordnede kravene til felles funksjonalitet knyttet til informasjon og veiledning i Oslo kommune. Tabell 12: Krav til informasjon og veiledning ID Type Krav K3.1 Funk. Informasjon om ulike elektroniske tjenester skal presenteres på en enhetlig og felles måte K3.2 Funk. Innbyggere og næringsliv skal veiledes i hvert steg av prosessen, med informasjon om hvor i prosessen saken er og hva som er neste steg K3.3 Funk. Innbygger og næringsliv skal kunne motta varsel om nye og endrede saker, bl.a. ved hjelp av abonnement og tilgang til en digital meldingsboks K3.4 Funk. Innbygger og næringsliv skal varsles om at svar er tilgjengelig i en digital meldingsboks K3.5 Funk. Innbygger og næringsliv skal interaktivt veiledes ved utfylling av søknader ved gjennomføring av søknadsprosesser K3.6 Funk. Innbyggere og næringsliv skal gis mulighet for elektronisk dialog i avklaringsfasen, forut for saksbehandling K3.7 Funk. Løsningen skal kunne vise tilgjengelige tidspunkter for en tjeneste og/eller gi mulighet for bestilling av tidspunkt for tjeneste (kalenderfunksjonalitet) K3.8 Funk. Løsningen skal kunne gi mulighet til å benytte bestillingstjeneste for å vise oversikt over valgte varer/produkter/tjenester før bestilling sendes, gjøre det enkelt å legge til eller trekke fra flere varer/tjenester underveis i bestillingsprosessen, og vise status for bestillingsprosessen (handlekurv) K3.9 Funk. En elektronisk betalingsløsning skal baseres på og gjenbruke felles grensesnitt i eksisterende økonomifunksjon K3.10 Funk. Løsningen skal legge til rette for betaling ved behov i tjenesteprosessen gjennom bruk av tredjeparts betalingsløsninger, samt at klientapplikasjonen skal få beskjed om hvorvidt en betaling er gjennomført og godkjent (betalingsløsning) Krav til autentisering og autorisasjon Tabell 13 inneholder de overordnede kravene til felles funksjonalitet knyttet til autentisering og autorisasjon i Oslo kommune. Tabell 13: Krav til autentisering og autorisasjon ID Type Krav K4.1 Funk. Det skal benyttes offentlige fellesløsninger for verifikasjon av e-id og autorisasjon av roller K4.2 Funk. Relevant informasjon og tjenestetilbud skal tilgjengeliggjøres for innbyggere og næringsliv basert på verifikasjon av e-id og autorisasjon av roller K4.3 Funk. Sikker identifisering av bruker skal tilfredsstille nivå 3 og 4 iht. rammeverk for autentisering og uavviselighet i elektronisk kommunikasjon med og i offentlig sektor 29

30 4.3.5 Krav til digitale forsendelser Tabell 14 inneholder de overordnede kravene til felles funksjonalitet knyttet til bruk av digitale kanaler i Oslo kommune. Tabell 14: Krav til digitale forsendelser ID Type Krav K5.1 Funk. Innbygger og næringsliv skal motta svar fra kommunen elektronisk. Svar til innbyggere og næringsliv skal fortrinnsvis skje digitalt gjennom en felles sikker distribusjonsløsning K5.2 Funk. Den felles sikre løsningen for digitalt svar til brukerne fra kommunen og virksomhetene skal tilfredsstille forvaltningslovens krav til digital kommunikasjon og formidling av vedtak K5.3 Funk. Innbygger og næringsliv skal oppleve rask behandling og raskt svar ved at det tilrettelegges for heldigitale tjenester der dette er mulig Krav til brukerrettet saks- og tjenesteinformasjon Tabell 15 inneholder de overordnede kravene til felles funksjonalitet knyttet til brukerrettet saks- og tjenesteinformasjon i Oslo kommune. Tabell 15: Krav til brukerrettet saks- og tjenesteinformasjon ID Type Krav K6.1 Funk. Innbygger og næringsliv skal få en samlet oversikt over sin kommunikasjon med kommunen på tvers av virksomheter og sektorer K6.2 Funk. Det skal legges til rette for proaktivt informering av innbyggere og næringsliv i de digitale kanalene, eksempelvis ved at informasjon fra brukerens profil benyttes til å selektere relevant informasjon for brukeren K6.3 Funk. Innbygger og næringsliv skal kunne abonnere på informasjon om offentlige saker/dokumenter K6.4 Funk. Innbygger og næringsliv skal gis elektronisk tilgang til dokumenter i mine saker K6.5 Funk. Innbygger og næringsliv skal gis oversikt over status og fremdrift i saker på nett i forhold til normalt saksforløp K6.6 Funk. Innbygger og næringsliv skal kunne abonnere på, og gis varsel om, nye og/eller endrede saker. Tilgang til varsel skal kunne gis til innloggede brukere og/eller andre berørte brukere K6.7 (Ny) Funk Innbygger og næringsliv skal kunne dele en sak, eller dokumenter i en sak (inkludert påbegynte søknader) med den eller de ønsker (fullmektiger) Dette kravet er nytt i versjon 1.1 og er både begrunnet ut fra personvernprinsipp om brukerens kontroll med egne opplysninger, for å redusere risikoen for at brukeren velger å dele innloggingsinformasjon (passord, engangskoder) med andre for å få hjelp til utføre en oppgave eller for å få andres vurderinger på en sak, samt et funksjonelt behov i PBEs brukerreise for rammesøknad (samsvarserklæringer). 30

31 4.3.7 Krav til offentlig innsyn Tabell 16 inneholder de overordnede kravene til felles funksjonalitet knyttet til offentlig innsyn i Oslo kommune. Tabell 16: Krav til offentlig innsyn ID Type Krav K7.1 Funk. Innbygger og næringsliv skal kunne få innsyn i og abonnere på offentlig informasjon som er relevant for dem K7.2 Funk. Innbygger og næringsliv skal kunne gis elektronisk tilgang til og varsles om offentlig saksinformasjon og data. Kommunens virksomheter som har innført elektronisk arkiv og enkelt kan publisere kvalitetssikret saksinformasjon og dokumenter på internett og skal på denne måten proaktivt informere ulike brukergrupper om offentlig tilgjengelige saker K7.3 Funk. Innbygger og næringsliv skal kunne gis innsyn i saker og planer (saksinnsyn, planinnsyn) 4.4 Krav til utforming av teknisk løsning Oslo kommune har utarbeidet et sett med arkitekturprinsipper 19 som skal være førende for utvikling av IKT- løsninger i kommunen. I arkitekturprinsippene er en tjenesteorientert tilnærming sentral, og det er et krav om å vurdere gjenbruk av eksisterende løsninger i utforming av nye løsninger. Oslo kommune har i tillegg et krav om at standard-/hyllevareløsninger alltid skal vurderes. IKT- reglementet for Oslo kommune definerer bl.a. ansvar, styring og eierskap for kommunens IKTløsninger. Eierskapet er delt inn i fire kategorier; virksomhetssystemer, sektorsystemer, tverrsektorielle systemer, og fellessystemer. Ansvaret for IKT- løsningene følger av løsningenes kategorisering innenfor disse. I tillegg er det identifisert følgende krav til felles funksjonalitet som skal danne grunnlag for et helhetlig design. Kravene er oppsummer i Tabell 17. Tabell 17: Krav til utforming av teknisk løsning ID Type Krav K8 Tekn. Det skal tilrettelegges for høy tilgjengelighet for elektroniske tjenester uavhengig av tidspunkt (døgnåpent) Brukerne skal kunne gjennomføre basisoppgaver på det tidspunktet det passer brukeren best i de digitale kanalene. Basisoppgaver defineres som; a. å henvende seg, b. å få bekreftelse på mottatt henvendelse, c. å få så mye informasjon som mulig om videre fremdrift, d. mulighet for å sjekke status e. mulighet for automatisert, regelstyrt saksbehandling som gir umiddelbare tilbakemeldinger K9 Tekn. Felles funksjonalitet skal samvirke med virksomhetenes prosesser Det skal sikres at virksomhetsspesifikke prosesser eies, utformes og vedlikeholdes av virksomhetene selv i henhold til kommunens IKT-reglement og benytter felles funksjonalitet der det er hensiktsmessig 19 Kommunens arkitekturprinsipper bygger på arkitekturprinsippene for offentlig sektor som forvaltes av DIFI. Se Overordnede IT- arkitekturprinsipper for offentlig sektor på 31

32 K10 Tekn. Brukerinteraksjon på ulike digitale medier skal understøttes Det skal gis en enhetlig og helhetlig brukeropplevelse med samme minimumsnivå på tjenestene, uavhengig av område K11 Tekn. Felles funksjonalitet i løsningen skal tilbys som tjenester Det skal være så få avhengigheter til underliggende fag- og journal-/arkivsystemer som mulig K12 Tekn. Eksterne nasjonale og kommunale felleskomponenter Det skal benyttes eksterne nasjonale og kommunale felleskomponenter der disse er tilgjengelige og der det er hensiktsmessig K13 Tekn. Nyutvikling av felles funksjonalitet skal være behovsdrevet Felleskomponenter skal ha sitt utspring i kartlagte og dokumenterte felles behov 4.5 Øvrige identifiserte krav Det er identifisert flere krav som har tilknytning til felles funksjonalitet, men som på nåværende tidspunkt ikke har blitt kategorisert i forhold til brukerreisen eller som er blitt stilt eksplisitt fra virksomhetene. Kravene er sammenstilt i Tabell 18. Tabell 18: Øvrige krav ID Type Krav K14 Andre Det skal foreligge en kost/nytte analyse som rettferdiggjør at en virksomhet i Oslo kommune eventuelt skal kunne avvike fra kravet om å benytte felles funksjonalitet K15 Andre Der Oslo kommune har utviklet felles funksjonalitet, skal disse som hovedregel benyttes av virksomhetene Eksempelvis kan det være tilfelle ved en anskaffelse av nytt fagsystem på et tjenesteområde. Her kan det forekomme at standard hyllevaresystem har overlappende funksjonalitet som dekkes av kommunens felleskomponenter 32

33 5 Løsning for fellesfunksjonalitet 5.1 Innledning Med bakgrunn i behov, målsettinger og identifiserte overordnede krav ble det utarbeidet en løsningstilnærming. I dette kapitlet beskrives løsningstilnærmingen med de justeringer og oppdatert status som resultat av piloteringsfasen. 20 Løsningen bygger på følgende egenskaper: Et helhetlig overbygg over alle de ulike fagsystemene og journal- og arkivsystemene på tvers av alle virksomhetsområder Grunnlag for å kunne realisere en enhetlig basis brukerflate, med enhetlig og helhetlig kommunikasjon og brukeropplevelse Tilby informasjon om sak, saksgang og korrespondanse til brukertjenestene/brukerdialogen En forutsetning for døgnkontinuerlig tilgjengelige tjenester, uten at hvert av de underliggende fag-, journal- og arkivsystemene behøver å ha slik åpningstid. Figur 4 under illustrerer den overordnete løsningsbeskrivelsen som viser hvordan det helhetlige overbygget sørger for grensesnitt og støtte for brukerflaten og de digitale selvbetjeningskanalene gjennom felles funksjonalitet i Oslo kommune. Figur 4 - Overordnet løsningsbeskrivelse 20 I versjon av «Helhetlig design for felles funksjonalitet» inneholdt dette kapitlet også en tabell over funksjonalitetskartleggingen og en matrise som viste felles funksjonalitet koblet mot behovskartleggingen og kravene fra kapittel 4. Disse er tatt inn uendret i vedlegg 4. 33

34 ITAS (se kapittel 5.7) ble valgt som plattform for å realisere det helhetlige overbygget. Gjennom piloteringsfasen er viktigheten av å ha stor grad av fleksibilitet i det helhetlige overbygget blitt tydelig. På den ene siden er det et ønske å begrense mengden fagspesifikk forretningslogikk i overbygget for å unngå å duplisere de enkelte virksomhetenes forretningsregler, og for å holde slike regler samlet innenfor virksomhetenes egen kontroll og ansvar i deres egne fagsystemer. I tråd med dette søkes det bl.a. å utnytte standardiserte grensesnitt til de underliggende fagsystemene og journal- og arkivsystemene. Et eksempel på dette er gjenbruk av SvarUT-grensesnittet (se kapittel 5.5.3). På den annen side er det nettopp gjennom å implementere forretningslogikk i form av transformasjon og skreddersydde integrasjoner, samt valideringsregler og veiledning/beslutningsstøtte for innbyggeren i brukerflaten, at det kan bygges tjenester som realiserer brukerprinsippene (se kapittel 1.4.1) også i de tilfellene der de underliggende fagsystemene og journal- og arkivsystemene ennå ikke har støtte for slik funksjonalitet. Et eksempel på dette er «Veiledet dialog» som i visse tilfeller realiserer fullautomatisert saksbehandling (se kapittel 5.2.2). Fleksibiliteten kan sies å ha en kostnad i form av økt kompleksitet, og det er derfor viktig at virksomhetene som er faglig ansvarlige for de ulike tjenestene er bevisste på hvilke forretningsregler som plasseres i de ulike delene av løsningen. Hovedprinsippet er at virksomhetenes forretningslogikk ligger i virksomhetenes egne fagsystemer. Det helhetlige overbygget gir også et grunnlag for å forbedre den manuelle saksbehandlingen ved at det kan bli enklere å gi saksbehandlere oversikt. Det legges i denne omgang ikke opp til funksjonalitet rettet mot saksbehandlere, men muligheten for å gjøre dette i fremtiden er illustrert gjennom den stiplete linjen i Figur 4 over. Videreutvikling for slik bruk må for øvrig sikre at saksbehandleren bare får tilgang til informasjon som vedkommende har rett til å se Nærmere om det helhetlige overbygget til virksomhetens fag- og journal/arkivsystemer Det helhetlige overbygget inneholder tjenester som er nødvendige for å støtte elektronisk dialog mellom innbygger og næringsliv og Oslo kommune i døgnåpne digitale tjenester. Dette arkitekturvalget er begrunnet i tilgjengelighet (24/7), sikkerhet (personvern) og ikke minst fordi Oslo kommune i dag har en svært heterogen systemportefølje. Vurderingen har vært at det vil være komplisert og kostbart å integrere de enkelte elektroniske tjenestene direkte mot hvert av virksomhetenes fagsystem eller journal- og arkivsystem. Overbygget har tre hovedelementer, jfr Figur 4 - Overordnet løsningsbeskrivelse. Korrespondanse- og saksinformasjon er kjernen. Her er formålet å sammenstille og lagre informasjon fra brukerflaten, inkludert korrespondanse til og fra kommunen, samt felles informasjonstjenester og fag- og journal-/arkivsystemene. Dette kan f.eks. være innbyggerens kopi av en søknad sendt inn via en Veiledet dialog, eller svar eller andre henvendelser fra kommunen til innbyggeren sendt via Digitale forsendelser. Videre kan det være informasjon om saksstatus, om en søknad er mottatt, under behandling etc. Slik statusinformasjon kan f.eks. gjøres tilgjengelig for innbyggeren i Min side. En tredje type informasjon er opplysninger som brukes til forhåndsutfylling av en «Veiledet dialog» eller til andre proaktive tjenester, og som vedlikeholdes i et fagsystem. Der fagsystemet ikke kan forventes å være tilgjengelig 24/7 eller ikke er bygget for å håndtere trafikken en forventer fra de elektroniske tjenestene, kan en vedlikeholde en kopi av de opplysningene som trengs til den elektroniske tjenesten, som del av det helhetlige overbygget. På den måten sikrer en at opplysningene er umiddelbart tilgjengelige for de elektroniske tjenestene. Det er fortsatt virksomhetenes fagsystem og journal- og arkivsystem som er kilden til dataene, og det er derfor en forutsetning at disse systemene blir oppdatert med nye og endrede data fra korrespondanse og saksinformasjon. Slik oppdatering vil nødvendigvis ikke kunne skje i sanntid så saksbehandlingen i virksomhetene må ta høyde for at nye opplysninger eller oppdateringer er mottatt og kvittert for av kommunen, mellomlagret i det helhetlige overbygget, og ligger på kø for å sendes til 34

35 virksomheten. 21 Det normale er likevel at oppdateringen skjer så fort at dette i praksis ikke utgjør noe problem. Korrespondanse- og saksinformasjon kan oppdateres og aksesseres gjennom et sett av Korrespondanse- og sakstjenester. 22 Disse sikrer et enhetlig grensesnitt som gjør det enklere å bygge brukerflaten og koble til nye dialogformer. Grensesnittet til fag- og journal- og arkivsystemer håndteres gjennom automatiserte prosesser, transformasjon og integrasjon. 23 Dette er måten korrespondanse- og saksinformasjon kan utveksles mellom det helhetlige overbygget og de bakenforliggende systemene. Som del av dette ligger også muligheten til automatisering utover det som støttes av fagsystemene, ved å legge inn behandlingsregler (testing av vilkår, beregninger m.m.). I noen tilfeller vil da kunne oppnå fullautomatisert saksbehandling, slik tilfellet er for noen søknader om skjenkebevilling ved bruk av Veiledet dialog Nærmere om brukerflaten: Responsivt design og API Brukerflaten som utvikles som del av programmet, f.eks. Min side og Veiledet dialog, bygges etter prinsippene for «responsivt design». Web-teknologi for brukergrensesnitt (HTML, CSS og JavaScript) beskriver et universelt utformet brukergrensesnitt, som tilpasser seg slik at det lett lar seg bruke uavhengig av skjermstørrelse og om innbyggeren benytter en PC, et nettbrett eller en smarttelefon. En egen forskrift (UU-forskriften 24 ) setter krav til universell utforming av IKT-løsninger, og disse kravene må naturligvis oppfylles. Samtidig viser erfaringene i programmet at innsats for å sikre universell utforming resulterer i en løsning som er bedre å bruke for alle. Gjennom responsivt design reduseres behovet for å utvikle spesifikke brukerflater for f.eks. smarttelefoner, i form av app-er. Men det er samtidig tatt høyde for et slikt behov i fremtiden, ved at de nyutviklete brukerflatene er bygget lagdelt. 25 Den tjenesten som brukeren forholder seg til på sin PC eller mobil, kommuniserer med API-er underveis. Disse API-ene kan danne utgangspunkt for nye produkter, som dedikerte app-er eller andre klienter, på et senere tidspunkt Målbilde for fellesfunksjonalitet Det er utarbeidet et målbilde for felles funksjonalitet basert på kartlagte behov (jf. kapittel 2). Målbildet ble først revidert høsten 2014, og er på nytt revidert som del av versjon 1.1 av dette dokumentet. Figuren nedenfor viser målbildet for eksisterende og ny fellesfunksjonalitet i løsningen. For eksisterende fellesfunksjonalitet er det behov for enkelte tilpasninger slik at disse kan samspille i løsningen. Figuren er fargelagt for å vise hvilke komponenter som ikke trenger justeringer (grønn), hvilke som må endres/tilpasses (gul), hvilke som må nyutvikles (rød) og hva som er virksomhetenes ansvar (blå). 21 Se mer om transaksjonssikkerhet i asynkron kommunikasjon mellom tjenester og fagsystem via ITAS, kapittel Se kapittel Se kapittel Se: 25 Se referansearkitekturen i kapittel

36 Figur 5 Revidert målbilde for fellesfunksjonalitet Figuren viser forholdet mellom felleskomponentene i brukerdialogen, tjenestelaget og de kommunale tjenestene og prosessene. 0. Kommunale tjenester og prosesser illustrerer de enkelte virksomheters fagtjenester og prosesser, og at disse har kontaktpunkter i brukerdialogen gjennom prosessens levetid. 1. Brukerdialog er funksjonelle komponenter i brukergrensesnittet ut mot innbyggere og næringsliv 2. Korrespondanse og sakstjenester (KOS) er systemtjenestene som skal støtte dialogen i brukergrensesnittet. Tjenester som dette laget tilbyr, er felles grensesnitt for innsending av strukturerte og formaliserte data (skjema), uthenting av saksinformasjon, status og dokumenter, samt tjenester for forsendelse av dokumenter til innbygger og tjenester for abonnering på hendelser med varsel. 3. Fag- og journal-/arkivsystem: Automatiserte prosesser, transformasjon og integrasjon består av tjenester for å integrere mot fag-, journal- og arkivsystemer. Her kan det også legges forretningslogikk for automatisert saksbehandling dersom det er hensiktsmessig. Reglene evaluerer opplysninger som enten innhentes fra innbyggeren (funksjonalitetsområde 1), eller gjenbrukes fra fagsystem, eller fra en av informasjonstjenestene (funksjonalitetsområde 5). 4. Støtte- og forretningstjenester er felles komponenter og tjenester som benyttes i brukerdialogen. Komponentene som fremkommer av figuren eksisterer, men tilpasning av løsningene kan være nødvendig for å få tatt de i bruk i Oslo kommune. 5. Informasjonstjenester er eksisterende felles oppslagstjenester mot felles informasjonskilder. 6. ITAS applikasjons- og integrasjonsplattform er plattformen der nyutviklet fellesfunksjonalitet realiseres. ITAS er både utviklingsplattform, kjøreplattform og integrasjonsplattform. Gjennom bl.a. utstrakt automatisering av prosessene rundt oppsett av servere og utrulling av nyutviklet eller endret programvare, gir ITAS mulighet for å levere hyppige oppdateringer til tjenestene som er produksjonssatt, enten det dreier seg om en 36

37 Veiledet dialog fra (funksjonalitetsområde 1) eller en integrasjon med et fagsystem (funksjonalitetsområde 3) 7. Sikkerhet representerer både eksisterende sikkerhetsmekanismer i ITAS og infrastruktur for ivaretakelse av informasjonssikkerhet og personvern, samt et sikkerhetsfokus i utviklingen av løsningene slik at det ikke innføres sårbarheter Ansvar Det funksjonelle målbildet gir et bilde av forholdet mellom løsningene som er virksomhetenes ansvar, og det som utvikles i Program for elektroniske tjenester. Men det er viktig å være klar over at det fagspesifikke også er representert i de ulike delene av fellesfunksjonalitet, bl.a.: - Automatiserte prosesser det er åpenbart at det er et fagansvar å implementere helt eller delvis automatisert saksbehandling - Transformasjons- og integrasjonsregler for utveksling av informasjon med fagsystem og journal- og arkivsystem, inkludert oppslag i fellesregistre - Saksspesifikk status-informasjon i InfoSak - Spørsmålene og veiledningslogikken i veiledet dialog Tilsvarende gjelder at virksomhetene har ansvar for behandling av informasjon i egen tjenesteutøvelse, inkludert «daglig behandlingsansvar» for personopplysningene som inngår i virksomhetens elektroniske tjeneste, selv om informasjonen ligger i systemer som har andre systemeiere. 26 Kapittel 6 om innføring av fellesfunksjonalitet og gjennomføringsstrategi viser hvordan arbeidet er organisert for å ivareta den ansvarsfordelingen som er beskrevet over. 5.2 Brukerdialog Nettsider ( Oslo kommunes nettsider ble lansert i ny versjon vinteren 2015, som resultat av prosjekt «Løftet». De nye sidene er utviklet med mål om at innbyggerne så raskt som mulig skal få løst den oppgaven de har når de kommer til kommunens nettsider, f.eks. å finne åpningstidene til Tøyenbadet eller om det er en friluftsbarnehage i bydelen der de bor. For innbyggerne starter ofte prosessen med å finne svar på slike spørsmål utenfor kommunens sider, f.eks. gjennom søk på Google. Derfor er også god tilrettelegging av innholdet på nettsidene for indeksering et viktig element. Ved utformingen av nettsidene er det lagt stor vekt på universell utforming, brukervennlighet og «responsivt design», det vil si å sikre at sidene vises på en god måte uavhengig av hva slags brukerutstyr innbyggeren har (PC, nettbrett, smarttelefon). Utformingen danner mal for grafisk brukergrensesnittet for de elektroniske tjenestene. For å organisere informasjonen på nettsidene er det utviklet en temastruktur som kombinerer tjenesteområder og prioritering basert på hvilken informasjon som oftest etterspørres. F.eks. vises «Svømmehaller» som første tema under «Natur, kultur og fritid» fordi undersøkelser viser at dette er noe mange er på jakt etter. Oslo kommunes nettsider er en forutsetning for at innbyggerne enkelt skal finne frem til de rette elektroniske tjenestene som utvikles i programmet. 26 Se kapittel 3.2 og 3.3 i «Styring og internkontroll Veileder nr 1 med sjekkliste for tiltak», %20og%20kompetanseetaten%20%28UKE%29/Intranett%20%28UKE%29/Kundeportal/Veileder/Infor masjonssikkerhet%20%28under%20arbeid%29/veileder%201%20styring%20og%20internkontroll.doc x 37

38 Figur 6 - Oslo kommunes nettsider fungerer på ulike typer brukerutstyr (PC, smarttelefon, nettbrett) Veiledet dialog «Veiledet dialog» et rammeverk for å bygge elektroniske tjenester av typen der innbyggeren initierer en saksbehandling i kommunen gjennom å sende en søknad. Et eksempel på en «Veiledet dialog» er «Søknad om skjenkebevilling» fra Næringsetaten: Figur 7 - Eksempel på "Veiledet dialog" Rammeverket for «Veiledet dialog» er et resultat av arbeidet med brukerreiser for pilotvirksomhetenes tjenesteområder, kombinert med brukerprinsippene, særlig prinsippene 2-5, fra «Overordnet design» (S1). Målet er å komme bort fra en omfattende orienteringsfase før man fyller ut et skjema, og over til en situasjon der brukeren får brutt opp informasjonen i mer håndterlige biter og støtte underveis til å fullføre en søknadsprosess. 38

39 Følgende hovedprinsipper ligger til grunn for veiledet dialog: Stegvis og veiledning i prosessen Preutfylling (standard verdier) Gjenbruk av informasjon Automatisering av arbeidsprosesser Universelt utformet og tilgjengelig Nedenfor er en illustrasjon av overgangen fra tradisjonell veiledning i forkant til støtte underveis i prosessen: Fra: Til: Figur 8 - Illustrasjon av hensikten med Veiledet dialog gjennom oppdeling av orienteringsfasen I «Metode for tjenestedesign i Oslo kommune» finnes en gjennomgang av tankegangen som ligger bak «Veiledet dialog»: 27 Å veilede er bedre enn å forklare For en del tjenester er kompleksiteten så høy, at forsøk på å forklare dem i tekst (artikler) blir for omfattende til at vi kan forvente at brukerne vil sette seg inn i alt de trenger å vite. Tekst blir til støy som igjen virker negativt for brukerens opplevelse av en tjeneste. Brukerne må kunne benytte seg av en tjeneste, uten å måtte lese seg opp på hva som gjelder for dem. Skjul kompleksitet Å veilede handler om å stille de riktige spørsmålene. Ved å stille spørsmålene i riktig rekkefølge i riktig sammenheng, kan vi gjøre tjenestene enda enklere og mer tilgjengelige for brukerne. F eks: I byggesaker er listen over mulige tiltak uendelig lang. Men ved først å spørre brukeren om hvilken eiendom/bolig det gjelder, kan vi gjøre listen betydelig kortere. Da blir det enklere for brukeren å fylle ut byggesøknaden. En Veiledet dialog skal være lineær og forutsigbar Å dele opp en Veiledet dialog i avgrensede steg gjør det enklere for brukeren å fullføre en prosess. Forutsetningen er at stegene ikke endrer seg undervegs i prosessen. En steginndelt Veiledet dialog må derfor starte med et nødvendig antall kontrollspørsmål slik at stegene gjennom resten av prosessen kan fastsettes. Først da skal stegene bli synlige for brukeren. 27 «Metode for tjenestedesign i Oslo kommune» beskriver stegene og metodikken for å identifisere og definere gode elektroniske tjenester. Brukerreiser er et sentralt element for å analysere hvordan en kan forbedre brukerens prosess, samtidig som en ser hvilke krav det stiller til organisatorisk og teknisk samspill med aktører og systemer i og utenfor Oslo kommune. 39

40 Så fremt ikke brukeren endrer valg av tjeneste må stegene stå fast, selv når brukeren velger å besvare dem i vilkårlig rekkefølge. Hjelpetekster skal være lett tilgjengelige, men avgrenset og ikke i veien Hvert steg i en Veiledet dialog bør ha en hjelpetekst. Teksten kan presenteres på tre nivå: tittel, ingress og lenke til hjelp. Tittel er ledetekst. Ingress er korte hjelpetekster som alltid er synlig. Sistnevnte er en lenke til mer utfyllende informasjon og eventuelle lenker til relevante eksterne kilder. Hvert enkelt felt innenfor et steg kan ha en kort forklarende tekst under feltets tittel. I tillegg kan feltet ha en lenke til en hjelpetekst. Brukeren skal fylle ut minst mulig, men fremdeles ha ansvar for korrekt informasjon Gjennom integrasjoner med registre og fagsystemer, skal mest mulig av informasjonen i en søknad hentes automatisk. Det vil kreve mye av løsninger og arkitektur, men vil gi store gevinster over tid i form av bedre brukeropplevelse, bedre datakvalitet og mer effektiv saksbehandling For å ivareta personvernet skal det fremgå tydelig hvor informasjon hentes fra, slik at brukeren kan kontakte kilden dersom det er feil i opplysningene. I utgangspunktet bør det være brukerens samtykke som er hjemmel for å hente informasjon fra andre kilder enn virksomheten. Den stegvise tilnærmingen med validering av opplysningene innbyggeren oppgir, og gjenbruk av informasjon som finnes allerede har som resultat at en reduserer antall søknader som må returneres fordi de er mangelfulle eller feil utfylt. Høyere kvalitet på opplysningene i søknadene øker også mulighetene til å automatisere hele eller deler av arbeidsprosessene. Det er et sentralt mål å legge til rette for fullautomatiserte prosesser. En annen effekt av Veiledet dialog er en reduksjon i antall skjema; gjennom opplysningene innbyggerne gir og spørsmålene som stilles underveis i den veiledete dialogen, kan innbyggeren ledes i flere retninger avhengig av hvilken oppgave hun eller han ønsker å løse. Dette er blant annet erfaringen fra Veiledet dialog for skjenkebevilling, som erstatter et sett av ulike skjema for de ulike anledningene en kunne søke skjenkebevilling for, men som forutsatte at innbyggeren hadde nok kunnskap til å vite hva det skulle søkes om. Teknisk sett er hver veiledet dialog separate web-applikasjoner, der hele applikasjonen lastes i nettleseren. Applikasjonen mottar og sender data gjennom egne API for hver Veiledet dialog. Det er i tillegg et felles-api som deles av de ulike Veiledet dialog og som bl.a. gir tilgang til flere ferdige integrasjoner mot både støtte- og forretningstjenester (funksjonalitetsområde 4) og informasjonstjenester (funksjonalitetsområde 5). Eksempler på dette er integrasjon mot Brønnøysundregistrene for validering av organisasjonsnummer, integrasjon mot Kontakt- og reservasjonsregisteret for å hente innbyggerens kontaktinformasjon samt mulighet for å la brukeren oppdatere opplysningene i registeret for deretter fortsette gjennomføringen av Veiledet dialog. For utvikling av nye tjenester av typen «Veiledet dialog» er det laget et rammeverk 28 som viser mer detaljert hvilke komponenter en «Veiledet dialog» består av, hvordan den bygges opp med et sett av steg, et sett av spørsmål pr steg, et beslutningstre, en avsluttende oppsummeringsside før man bekrefter og sender inn, og for enkelte typer spørsmål hva slags svaralternativer som skal presenteres og hvordan. Dette gir et utgangspunkt for virksomhetenes arbeid med funksjonell spesifikasjon. 28 Se 40

41 Komponentnavn Finnes komponenten fra før? - Er den komplett - Må den tilpasses - Utvikles / Anskaffe Veiledet dialog Det er utviklet flere iterasjoner av veiledet dialog, bl.a. skjenkebevilling (flere iterasjoner) fra NAE og forespørsel om fasadeendring og generering av nabolister fra PBE. Videre er det laget et rammeverk i form av dokumentasjon, samt funksjonalitet for gjenbruk og utvikling av nye Veiledet dialoger Hva er inndata til komponenten Utfylt felt og valg fra bruker. Forhåndsutfylte data fra registre og fag- og journal- /arkivsystemer. Nøyaktig hvilke avhenger av hva den konkrete «Veiledet dialog» gjelder. Hva produserer komponenten (Utdata / Funksjonalitet) Forutsetninger / Premisser Avgrensninger / Antakelser Avhengigheter til andre grensesnitt - De aller fleste vil ha påloggingsinformasjon fra innbygger (Kontakt- og reservasjonsregisteret og DSF) eller næringsliv (Altinn rolle med organisasjonstilhørighet) Strukturert og formalisert informasjon (XML, JSON) Endring av fagprosesser hos virksomhetene. Veiledet dialog vil over tid overta for Oslo kommunes skjemarammeverk SNOK. Det vil bli redusert behov for søkers dokumentasjon fordi vi har opplysningene selv, eksempelvis: - samtykke til å innhente skatteattest Korrespondanse og sakstjenester, InfoInn Kontaktregister innbygger (DIFI) Autentisering og autorisasjon: Autentisering fra ID-porten (eksterne) Uthenting av navn fra DSF Uthenting av rolle og organisasjonstilknytning fra Altinn Matrikkelen Funksjonelt omfang (H/M/L) L. Veiledet dialog skal brukes i Oslo kommune for å muliggjøre effektivisering av saksbehandling ved hjelp av bedre veiledning og selvbetjening. Veiledet dialog tar i mot data fra brukeren og avgir data til InfoInn. Komponenten finnes og er i bruk i dag. Ved en migrering av skjema til Veiledet dialog kan dette stige radikalt, men nøyaktig antall er vanskelig å anslå siden én Veiledet dialog erfaringsmessig kan erstatte et sett av skjema. Det antas at omfanget av funksjoner for komponenten vil utvikles videre når flere virksomheter kommer med behov. Pilotenes behov har blant annet identifisert følgende funksjoner: - Automatisering - Lange transaksjoner. Prosesser og meldingsformidling på tvers av virksomheter. - Proaktivitet i forbindelse med pågående utfylling og effekt for bakenforliggende løsninger som 41

42 Unike avhengigheter (H/M/L) M. eksempelvis: o Nabovarsel o Omsetningsoppgave - Samskriving i samme innsending fra flere parter - Gjenbruke og utveksle (tidligere) innsendt informasjon. - Bruk av åpne informasjonskilder eksemplifisert internt via Løftet og eksternt ved kart fra Google. - Kobling mot kalendere. - Sende tilleggsinformasjon i en allerede innsendt sak - Editor for å kunne endre enkle tekster i Veiledet dialog - Standardisering av veiledertyper - Sanntids brukerstøtte / Chat / veiledet diskusjon - Saksbehandler kan se det samme som utfyller - Eksempler på utfylte Veiledet dialog - Informasjon brukt i Veiledet dialog kan også brukes andre steder konseptuelt i henhold til masterdata management (delte tekstkilder). Avhengighet til: - InfoInn - Digital kontaktinformasjon for innbyggere (IDporten) - Autentisering og autorisering Skjemaløsning (SNOK) Skjemaløsningen SNOK brukes i dag av de fleste av Oslo kommunes virksomheter og inneholder over 250 forskjellige elektroniske skjema. Skjemaløsningen er basert på ELMER 2 standarden. Den er utviklet over flere år med utgangspunkt i virksomhetenes behov for funksjonalitet. Komponenten er sentralt plassert i konsernets tjenesteorienterte arkitektur, og er integrert med fagsystemer og andre registertjenester via integrasjonsplattformen. SNOK er utviklet for bruk på datamaskin med mus og tastatur og ikke spesielt tilpasset andre digitale plattformer som mobil og nettbrett. SNOK er presentert og forvaltet adskilt fra publiseringsløsningen og det er et mål at brukeropplevelsen av skjemaene blir forbedret ved at de integreres bedre i brukerdialogen. 42

43 Komponentnavn Finnes komponenten fra før? - Er den komplett - Må den tilpasses - Utvikles / Anskaffe Skjemaløsning (SNOK) Det forventes at de fleste nye tjenester som utvikles i programmet baserer seg på rammeverket «Veiledet dialog» fremfor SNOK. For tjenester der det viser seg hensiktsmessig å basere tjenesten eller deler av den på SNOK er følgende områder aktuelle for tilpasninger: Ved behov skal skjemaløsningen tilpasses flere digitale plattformer som mobil og nettbrett (Responsivt design). Skjemaløsningen skal avgi skjemadata til InfoInn og må tilpasses et standard skjemaformat. Skjemaløsning må støtte at flere brukere skal kunne bidra med utfylling av samme skjema Skjemaløsningen må kunne publisere skjema uten nedetid for at nye elektroniske skjema kan gjøres tilgjengelig på fleksible tidspunkt. Ved behov skal skjemaløsningen støtte sikkerhet på nivå 4 for autentisering, signering og sikker vedleggshåndtering. Hva er inndata til komponenten Utfylt skjema fra bruker. Forhåndsutfylte data fra registre og fag- og journal- /arkivsystemer. Hva produserer komponenten Strukturert og formalisert data fra skjema (XML) (Utdata / Funksjonalitet) Forutsetninger / Premisser Ingen. Avgrensninger / Antakelser Ingen. Avhengigheter til andre, grensesnitt Korrespondanse og sakstjenester, InfoInn Kontaktregister innbygger Autentisering Rolleregister Altinn Funksjonelt omfang (H/M/L) M. Skjemaløsningen SNOK brukes i dag av de fleste av Oslo kommunes virksomheter og inneholder over 250 forskjellige elektroniske skjema. Skjemaløsningen er basert på ELMER 2 standarden. Skjemaløsningen tar i mot data fra brukeren og avgir data til InfoInn. Omfang dreier seg om nødvendig tilpasning av dagens SNOK. Unike avhengigheter (H/M/L) L. Avhengighet til: - InfoInn - Digital kontaktinformasjon for innbyggere (IDporten) - Autentisering og autorisering 43

44 5.2.4 Min side Hensikten med Min side er å tilgjengeliggjøre Oslo kommunes tjenester på en måte som er tilpasset den individuelle brukeren som innbygger eller næringsliv. Gjennom Min side skal innbyggerne få det utvalget av tjenester som er relevant for den situasjonen de er i. Der det er hensiktsmessig inkluderes også elektroniske tjenester for innbyggere og næringsliv som er gjort tilgjengelig av andre, f.eks. statlige tjenester som Kartverkets tjeneste for innsyn i Grunnboka («Se eiendom»), Skatteetatens «Mine arbeidsgivere» og Brønnøysundregistrenes «Vis kontaktinformasjon». Min side bidrar til en brukerflate som gir relevant støtte til utførelse av en brukeroppgave i form av brukertilpasset informasjon og verktøy. For eksempel kan innbyggeren se sine saker og dokumenter, ha mulighet for innsending av tilleggsinformasjon i en sak, endring av brukerprofil, innstillinger for å abonnere på saker, samt annen brukerrelevant informasjon. Som følge av Oslo kommunes strategiske valg om gjenbruk av statlige felleskomponenter presenteres både kommunal og statlig informasjon og verktøy i Min side. Eksempler på det siste er informasjon fra Skatteetaten om «Mine arbeidsgivere» og «Vis kontaktinformasjon» i Altinn. Gjennom å legge til rette slik at innbyggerne enklere kan få oversikt over og innsyn i hvilke opplysninger kommunen har om seg, bidrar Min side til å styrke innbyggernes personvern. Dette er i tråd med Datatilsynets prinsipper for «Innebygget personvern». Min side krever at brukeren er entydig identifisert. Når brukeren er entydig identifisert med fødselsnummer velger vedkommende «rolle»; privatperson eller en virksomhet basert på kobling mellom fødselsnummer og organisasjonsnummer i Enhetsregisteret. Deretter kan tjenester tilpasset brukeren leveres på en effektiv måte. Eksempler på dette er kombinasjoner av: Kommunespesifikk informasjon, som status på henvendelser og saker Ekstern informasjon fra fellesløsninger, eks om brukerens rolle, identitet og kontaktinformasjon, både i Altinn og Difis kontakt- og reservasjonsregister Min side er utviklet i versjon 3 og har bl.a. funksjonalitet for å velge perspektiv (privatperson eller representant for virksomhet), se korrespondanse med kommunen (inkludert mellomlagrete utkast og innsendte søknader fra «Veiledet dialog», og chat-logg), samt administrere abonnement over varsler ved endringer på saker. I tillegg kommer informasjon og tjenester fra eksterne fellesløsninger, som nevnt over. I versjon 4 blir det lagt til funksjonalitet for å samle informasjon og tjenester under ulike domener. Det første domenet blir «Eiendom og bosted». «Økonomi og skatt», «Barnehage og skole», «Helse og velferd» er andre aktuelle domener for fremtidige versjoner. Figur 9 - Prototyp for Min side v 4 med organisering av informasjon og tjenester i domener 44

45 Dersom innbyggeren kun er registrert med en eiendom i Oslo kommune vises adressen til denne eiendommen som tittel for eiendomsdomenet. Ved å gå videre til eiendomssiden, får innbyggeren opp en rekke detaljer om og relevante tjenester for eiendommen sin: Figur 10 - Prototyp som viser hvordan informasjon og tjenester om domenet «eiendom og bosted» kan presenteres Min side er et brukerkonsept som det over tid kan knyttes flere funksjoner til, avhengig av behov og vil være et fokuspunkt for tjenester. Det er en ambisjon at Oslo kommune skal utnytte mulighetene for kontinuerlig læring og forbedring av brukertilpasningen. Komponentnavn Finnes komponenten fra før? - Er den komplett - Må den tilpasses - Utvikles / Anskaffe Hva er inndata til komponenten Hva produserer komponenten (Utdata / Funksjonalitet) Min side Utviklet i versjon 3, funksjonell spesifikasjon for versjon 4 er også på plass, forventes produksjonssatt i høsten 2015 Autorisert og autentisert bruker. Komponenten er et fokuspunkt for tjenester og gir tilgang (brukergrensesnitt) til saksinformasjon og saksstatus innenfor et eller flere tjenesteområder. Saksinformasjonen kan være eksponert fra Korrespondanse og sakskatalogen (KOS) eller som en snarvei /inngang til et fagsystem, dersom dette støttes 45

46 Forutsetninger / Premisser Avgrensninger / Antakelser av det relevante fagsystemet. Brukeren har identifisert seg gjennom ID-porten. Relevant informasjon på tjenesteområdene er tilgjengelig Siden må gi en god brukeropplevelse, og svare til brukernes forventninger når det gjelder informasjonen som ligger der. Det finnes imidlertid mange gode eksempler på tilsvarende løsninger i offentlig og privat sektor. Min Side utvikles gradvis, behovsbasert, for hvert tjenesteområde. Utprøving gjøres gjennom pilottjenestene. Logikk for sammenstilling av informasjon skal ikke ligge i brukergrensesnittet, men implementeres i Korrespondanse- og sakstjenester (InfoSak). Min side for næringslivsbrukere baserer seg på oppslag i Altinn for å finne hvilke virksomheter den innloggede brukeren har en rolle i. Mulighetene for å skreddersy presentasjonen på denne siden vil forbedres når det kommer på plass et bedre kontakt- og adresseregister med adekvate roller for kommunens digitale kommunikasjon med næringslivet. Et slikt register er bl.a. en av anbefalingene i Difi-rapport 2015:3. Avhengigheter til andre, grensesnitt Min side vil bli bedre jo flere tjenester og virksomheter som deltar inn. Det legges til grunn at alle nye elektroniske tjenester i kommunen integreres med Min side slik at innbyggeren etter hvert får den totale oversikten som er ønsket. Korrespondanse- og sakstjenester (KOS) Autentisering (ID-porten). Funksjonelt omfang (H/M/L) H. Brukergrensesnitt mot innbyggere og næringsliv, for autentisert bruker. Viser informasjon om og skal ha funksjonalitet for; - Tilgang til innsendte og mellomlagrete utkast av skjema/veiledet dialog - For næringslivet gir det mulighet for at flere i en virksomhet kan samarbeide om utfylling/innsending av søknader - Saksinformasjon, status og korrespondanse o Eksponering av informasjon o Eksponere sak og behandling av sak o Status i saker inkludert fremdrift og forventet videre fremdrift o Vise innsendinger og forsendelser i sammenheng - Informasjon fra felles offentlige registre - Administrere abonnement på varsler på saker. - Presenterer fokuspunkt for tjenestekategorier/domener som bl.a. «Eiendom og bosted» - Målrettede tjenester, presenterer tjenestene du trenger ett sted - Inneholder tjenester det faktisk er behov for og gir verdi for brukeren 46

47 Unike avhengigheter (H/M/L) H. - Viser relevant informasjon avhengig av hvem du er, f.eks. hjemmelshaver til eiendom eller foresatt til barn i skole) - Samtykke o Innsamling av informasjon for presentasjon på Min side, for eksempel ved første gangs pålogging o Videreformidling, gjenbruk eller utlevering av informasjon på tvers av virksomheter o Oversikt over hvilke samtykke som er gitt og mulighet for å trekke tilbake samtykke - Innsyn o Enkelt for innbyggere å søke innsyn i egne personopplysninger - Mine oppgaver o Oppgaver som kommunen venter på at bruker skal gjøre for videre Avhengighet til: - InfoInn - InfoUt - InfoSak - Autentisering og autorisering - Digital kontaktinformasjon for innbyggere (ID-porten) - Enhetsregisteret - Folkeregisteret (DSF) - Melding og varsler - Digital kontaktinformasjon for næring (Altinn) - Abonnement og varsler - Veiledet dialog - Matrikkelen Offentlig innsyn Offentlig innsyn betyr i denne sammenhengen innsyn i kommunens saker og dokumenter og er en samlebetegnelse for saksinnsyn etter offentleglova og arkivloven (offentlig journal). Fellesnevneren er at dette handler om ulike innganger til informasjon som ligger i offentlige virksomheters arkiv og som skal være tilgjengelig for allmennheten. Offentlig innsyn vil kunne varsle brukere om nye og/eller endrede offentlige saker gjennom en abonnementsfunksjonalitet. Komponentnavn Finnes komponenten fra før? - Er den komplett - Må den tilpasses - Utvikles / Anskaffe Offentlig innsyn Løsning for saksinnsyn og planinnsyn finnes for Plan- og bygningsetaten, som gir innbyggere og næringsliv innsyn i saksinformasjon, dokumenter, status og reguleringskart. I forbindelse med insentivordningen har BLK fått tilsagn om midler til prosjekt for innsyn i politiske saker med forventet produksjonssetting i Et premiss er at det skal utvikles et konsept for offentlig innsyn for å sikre helhet i forhold til alle kommunens virksomheter. 47

48 BLKs planer innebærer en løsning som bygger på og eventuelt utvider felles funksjonalitet, som f.eks. InfoSak. Hva er inndata til komponenten Offentlig tilgjengelige saksdokumenter og relatert informasjon. Hva produserer komponenten Elektronisk tilgang til informasjon og dokumenter som er (Utdata / Funksjonalitet) offentlig tilgjengelig. Forutsetninger / Premisser Alle tjenesteområder som skal tilgjengeliggjøre offentlige saksdokumenter og relatert informasjon i løsningen må ha disse på elektronisk form. Avgrensninger / Antakelser Kvalifisering og kvalitetssikring av informasjon som skal tilgjengeliggjøres i løsningen gjøres av de virksomhetene som eier informasjonen. Skal ikke løse publisering av offentlig postjournal. Realisering av andre prosjekter vil være premissgiver for offentlig innsyn. Avhengigheter til andre, Korrespondanse- og saksinformasjon - InfoSak grensesnitt Funksjonelt omfang (H/M/L) H. Brukergrensesnitt mot innbyggere og næringsliv, for ikkeautentisert bruker. Viser informasjon om offentlig tilgjengelige saker. Kan abonnere på varsler på offentlige saker. Forutsetter at informasjon er klassifisert som offentlig tilgjengelig i journal- /arkiv og fagsystem. Skal kunne publisere data i en form som er mulig for eksterne kilder å indeksere (eksempelvis Google). Unike avhengigheter (H/M/L) H. Avhengighet til: - KOS/InfoSak for tilgang til Journal- og arkivsystem - Matrikkelen - Stedfestet informasjon (Oslo digitalt) - Abonnement og varsler - Klassifisering av informasjon i avgivende systemer - Kommunens nettsider ( Abonnement og varsler Abonnement og varsler er brukerflaten for å la innbyggere og næringsliv angi områder og enkeltsaker for å bli holdt oppdatert få et «pling» ved hendelser eller endringer. Tjenesten forutsetter at det finnes funksjonalitet for å abonnere på endringer og hendelser i underliggende systemer. Selve varselet kan formidles på ulike måter, f.eks. SMS, epost, app-varsel m.m., jfr fellesfunksjonaliteten i kapittel Andre dialogformer (chat, sms, epost ). Det er utviklet en generell funksjon for å administrere abonnement som del av Min side. Abonnementstjenesten er generell og kjenner ikke til faglig innhold i abonnement eller varsler. Løsningen som er realisert har benyttet konkrete behov fra Plan og bygningsetaten for varsling av endringer i byggesaker og for eiendom. Men i prinsippet kan løsningen benyttes til varsling av alle mulige hendelser. 48

49 Figur 11 - Illustrasjon av abonnement på endringer i saker i PBE Innbyggeren skal kunne angi om hun ønsker varsel om statusendringer eller aktuelle tjenester. Eksempelvis får man et varsel/melding om at brev er tilgjengelig i elektronisk meldingsboks. Varselet kan inneholde lenketjeneste som gjør det mulig for brukeren å få tilgang til innholdet. Varsel kan også knytte seg til behovet for å komme i kontakt med en gruppe innbyggere/næringsliv. Eksempelvis varsel om stenging av vann i et område eller vannlekkasje. Da vil tilgang på informasjon om eiendomseiere og kontaktinformasjon til disse være nødvendig å håndtere som felles informasjonstjenester. Kombinert med abonnementstjenester kan innbygger og næringsliv abonnere på bestemte hendelser i egen sak og offentlige hendelser. Komponentnavn Finnes komponenten fra før? - Er den komplett - Må den tilpasses - Utvikles / Anskaffe Hva er inndata til komponenten Hva produserer komponenten (Utdata / Funksjonalitet) Forutsetninger / Premisser Abonnement og varsler Det er utviklet en generell abonnementsfunksjon i Min side som er uavhengig av fagområde. Via den kan brukeren starte og stoppe abonnement, avhengig av hvilke hendelser vedkommende ønsker varsel om. Merk at formidlingen av selve varselet skjer gjennom fellesfunksjonalitet for «Andre dialogformer (chat, SMS, epost )» Statusinformasjon om (endringer i) en sak, eller annen type nyhet innbyggeren ønsker å bli holdt oppdatert om. Avsender (virksomhet). Mottaker (innbygger/næringsliv) En kort melding tilpasset å kunne formidles via SMS, e-post eller ev. App-varsel (se «Andre dialogformer (chat, SMS, epost )») med informasjon om avsender, saken det gjelder og hvor brukeren kan finne mer informasjon. Fagspesifikk tjeneste tilrettelagt for overvåking av nyheter/endringer, tilsvarende PBEs saksinnsyn. Avgrensninger / Antakelser Avhengigheter til andre, Ingen kjente Korrespondanse- og sakstjenester 49

50 grensesnitt Funksjonelt omfang (H/M/L) M. Bruker kan abonnere på hendelser slik som statusendringer på egne og offentlige saker, hendelser basert på stedfestet informasjon og saksområder av interesse for bruker. Unike avhengigheter (H/M/L) M. Avhengighet til: - InfoSak - Andre dialogformer (chat, sms, epost ) Ulike fagsystemer der hvor endringene det skal varsles om, oppstår Andre dialogformer (chat, sms, epost ) I tillegg til de strukturerte formene for henvendelser via skjema (SNOK) eller Veiledet dialog, eller Digitale forsendelser, er det behov for andre måter å kommunisere mellom innbyggere og kommunen. I noen tilfeller er det snakk om varsler f.eks. om endringer i status, jfr fellesfunksjonaliteten «Abonnement og varsler». Når det skjer en endring i en sak eller noe nytt innen et interesseområde innbyggeren har angitt at vedkommende ønsker å bli varslet om gjennom «Abonnement og varsler», formidles selve varselet gjennom en eller flere av kanalene innenfor funksjonalitetsområdet «Andre dialogformer (chat, SMS, epost ) Dette funksjonalitetsområdet kan også brukes i tilfeller hvor det behov for toveis dialog; f.eks. hvis kommunen ønsker tilleggsopplysninger eller innbyggerne har spørsmål eller trenger veiledning. Oslo kommune har bl.a. epost og SMS-komponent per i dag. I tillegg har Kemneren etablert en sikker chat-funksjon, der chat-loggen etterpå gjøres tilgjengelig for innbyggeren i Min side: Figur 12 - Skjermbilde som viser sikker chat med Kemneren 50

51 Som del av insentivordningen planlegger BYM etablering av chat som til forskjell fra Kemneren i første omgang ikke vil kreve innlogging. Andre dialogformer kan både være mer eller mindre synkrone (som chat) eller asynkrone, som epost, eller tilbakemeldingsskjema. Et viktig spørsmål er hvor sikker man kan være på at den kommunen kommuniserer med er den han eller hun utgir seg for å være. Ved web-basert chat som forutsetter innlogging via ID-porten har man høy grad av sikkerhet. Det er en forutsetning for å kunne gjøre chatloggen tilgjengelig for innbyggeren i ettertid via Min side. For andre kanaler er det mer usikkert. Bymiljøetatens «BYMelding»-app er også et eksempel på «andre dialogformer». «BYMelding» er en form for delvis strukturert dialog, siden brukeren må angi kategori for henvendelsen, f.eks. «Brøyting/strøing», «Gatelys» etc. Gjennom en app åpner man for å supplere henvendelsen med kontekst som f.eks. lokasjon, bilder etc. Figur 13 - Skjermdump fra app-en "BYMelding" - viser de ulike meldingskategoriene Dette området dekker ikke Digitale forsendelser (se kapittel 5.5.3). Digitale forsendelser formidles via KS FIKS videre til f.eks. Altinn, Digital post til innbygger eller andre tjenester der innbyggeren logger seg inn for tilgang til forsendelsen, inkludert Min side. Komponentnavn Finnes komponenten fra før? - Er den komplett - Må den tilpasses - Utvikles / Anskaffe Andre dialogformer (chat, sms, epost ) Flere av de ulike kommunikasjonsløsningene finnes allerede enten som fellesløsninger eller i bruk hos en eller flere virksomheter (se under). Det er til gjengjeld ingen løsning pr i dag for å håndtere de ulike dialogformene på en helhetlig måte, f.eks. kø-håndtering på tvers av de ulike dialogformene. Dette må sees i sammenheng med fellesfunksjonalitet for Multikanalplattform, se kapittel Oslo kommune har en felleskomponent for SMS-utsending som brukes av flere tjenester. SMS-utsendingen er imidlertid basert på at virksomhetene (som avsender) selv har kontroll på kontaktinformasjon til mottaker. Komponenten er i dag avhengig av at digital kontaktinformasjon sendes med meldingen, og må tilpasses for å gjøre bruk av felles digitalt kontaktregister (ID-porten). 51

52 Gjennom Digitale forsendelser (KS FIKS) kan mottakere av digitale forsendelser varsles på SMS. KS FIKS står selv for oppslag mot det felles digitale kontaktregisteret. Melding og varsel via e-post bruker Oslo kommunes standard protokoll og plattform (Exchange) for utsendelse av e-post. Hva er inndata til komponenten Hva produserer komponenten (Utdata / Funksjonalitet) Forutsetninger / Premisser Avgrensninger / Antakelser Avhengigheter til andre, grensesnitt Kemneren har implementert web-chat som forutsetter at brukeren logger inn via ID-porten. Det gir mer sikker identifisering enn f.eks. henvendelser via telefon. Chat-log lagres i forsendelseskatalogen og er tilgjengelig for innbyggeren i Min side. Inngående eller utgående henvendelser Kanaler for dialog med innbyggeren Når kommunen skal initiere kontakten: Digital kontaktinformasjon om mottaker må være tilgjengelig. Melding og varsler til næringslivet krever at digital kontaktinformasjon hentes inn via brukerdialogen (skjema) eller fra virksomhetenes (avsender) selv. Merk at innbyggere kan benytte ID-porten for innlogging uten å registrere digital kontaktinformasjon i Kontakt- og reservasjonsregisteret. Avgrensning mot Digitale forsendelser (se kapittel 5.5.3) som bl.a. håndterer Digital post til innbyggere (via KS FIKS) Korrespondanse- og sakstjenester Kontaktregister innbygger (ID-porten) En ønsket fremtidig løsning for kontaktregister næringsliv Altinn Funksjonelt omfang (H/M/L) M. SMS, epost, chat, dialog via app-er à la «BYMelding» fra Bymiljøetaten. Unike avhengigheter (H/M/L) M. Avhengighet til: - InfoUt og forsendelseskatalogen - KS Fiks (SvarUt) - Digital kontaktinformasjon for innbyggere (ID-porten) - Melding transporttjeneste som SMS, e-post, SvarUt, etc. - ID-porten for autentisering 52

53 5.3 Korrespondanse- og sakstjenester (KOS) Korrespondanse- og sakstjenester (KOS) inneholder tjenester som er nødvendige for å støtte elektronisk dialog mellom innbygger og næringsliv og Oslo kommune i døgnåpne digitale tjenester. Sammen med automatiserte prosesser, transformasjon og integrasjon skal KOS kompensere for utfordringer som skapes av at kommunen har en svært heterogen systemportefølje, hvor oppsett og innhold ikke er konsoliderte, og hvor systemene som regel ikke er døgnåpne. 29 Korrespondanse og sakstjenestene (KOS) sammenstiller og lagrer informasjon fra brukerdialogen, felles informasjonstjenester og fag- og journal-/arkivsystemene. Gjennom korrespondanse og sakstjenestene: Kan informasjonen tilgjengeliggjøres døgnkontinuerlig til de brukertjenestene som trenger det, slik som Min side, skjemaløsningen mv. uten at fag- og journal-/arkivsystemene er døgnåpent tilgjengelig. Unngår man at hvert fag- og journal-/arkivsystem må implementere en felles informasjonsmodell, for at disse dataene skal kunne gjenbrukes i brukerdialogen. Unngår man at brukertjenestene må gjøre direkte oppslag i fag- og journal-/arkivsystemene i sann tid, som vil nødvendiggjøre omfattende tilpasninger av grensesnittet hvert enkelt fag- og journal-/arkivsystem har mot brukertjenestene. Direkte oppslag vil medføre at informasjonen i disse systemene må eksponeres direkte til brukertjenestene, noe som vil kunne utløse sikkerhetskrav og ytterligere behov for endringer av de fag- og journal-/arkivsystemene som ikke er tilrettelagt for dette. Etableres et felles tjenestelag for Oslo kommune for digitale forsendelser utenfor kommunen: Oslo kommune har valgt å bruke KS Felles integrasjonsplattform for kommunal sektor (FIKS) som meldingsformidler for digitale forsendelser, jfr kapittel FIKS er videreføringen av SvarUT og supplerer SvarUt bl.a. med inngående forsendelser, f.eks. forsendelser fra andre kommuner som bruker FIKS. Det forventes også at FIKS kan videreformidle forsendelser basert på skjema utfylt i Altinn og eventuelt andre fremtidige felles-offentlige infrastrukturer. Samler integrasjon med KS FIKS et sted, og kan til en viss grad unngå at endringer i KS FIKS krever umiddelbare endringer i virksomhetenes systemer (løse koblinger) åpner for større fleksibilitet i måten virksomhetenes sak/arkiv og fagsystem integreres med FIKS gjør dokumenter og metadata som utveksles mellom virksomhetene og KS FIKS tilgjengelige for øvrig funksjonalitet i KOS muliggjør interkommunale forsendelser uten at forsendelsene går utenfor Oslo kommunes nettverk dersom det er et behov i fremtiden Nedenfor er en illustrasjon som viser hvordan KOS er et felles tjenestelag for dokumenter inn til kommunen (røde piler), enten via SNOK-skjema og en Veiledet dialog. KOS kan også ta imot forsendelser fra innbyggeren til kommunen via andre kanaler, f.eks. søknadsskjema som er på andre portaler. Tilsvarende kan en også motta dokumenter via FIKS. KOS er også et tilsvarende tjenestelag for forsendelser ut, enten de går til innbyggeren eller til andre parter via FIKS (blå piler). 29 Jfr kapittel om det helhetlige overbygget 53

54 Figur 14 - Illustrasjon av KOS rolle som felles tjenestelag for inngående (røde) og utgående (blå) forsendelser 30 Merk at illustrasjonen ikke er uttømmende det kan f.eks. også komme dokumenter inn til fagsystem, på samme måte som det kan gå dokumenter ut fra journal/arkivsystem. I tillegg vil det kunne være integrasjoner mellom fagsystem og journal/arkivsystem slik at en forsendelse finnes begge steder. Forsendelser til og fra innbyggere blir liggende i de respektive katalogene (mottakskatalogen og forsendelseskatalogen). Disse kan innbyggeren eller bedriften få tilgang til via Min side. Det vil også være mulig for en virksomhet i Oslo kommune å sende til andre deler av Oslo kommune via de samme mekanismene. Næringsetaten kan sende en skjenkesak på høring til Kemneren ved bruk av Kemnerens digitale mottaksadresse, og forsendelsen vil bli rutet riktig i KS FIKS. Dersom det senere skulle vise seg å være et behov for å holde slik intrakommunal kommunikasjon intern for Oslo kommune, kan en «kortslutte» forbindelsen mellom InfoUt og InfoInn, og unnlate å sende dokument til KS FIKS. Men i så fall må det sørges for at det etableres kvitteringsmekanismer, eller om det vurderes at dette f.eks. kan dekkes av loggføringen i driftsmiljøet. For forsendelser fra kommunen er løsningen laget slik at man enten kan sende selve dokumentet (kopi) eller bare en referanse (hyperkobling) til det aktuelle dokumentet i forsendelseskatalogen. I sistnevnte tilfellet kan dokumentet lastes ned forutsatt autentisering med tilstrekkelig sikkerhetsnivå. Dette er spesielt nyttig ved store forsendelser. Det er forutsatt at KS FIKS også vil tilby dyplenking til dokumenter som alternativ til dagens løsning. I dag formidler vi selve dokumentet (kopi) til KS FIKS, og ikke bare en referanse (hyperkobling). 30 Merk at illustrasjonen ikke er uttømmende ulike virksomheter vil ha ulik samhandling mellom sine egne systemer og KOS. 54

55 Som del av KOS ligger også annen felles funksjonalitet knyttet til informasjonsflyten rundt de elektroniske tjenestene. Et slikt behov er knyttet til logging. Plan- og bygningsetaten har behov for å dokumentere at deres utlevering av nabolister er i tråd med hjemmelen for slik utlevering, og har følgelig behov for å logge det som leveres ut. Her er selve den tekniske løsningen for å logge en generell felles funksjonalitet, samtidig som det er behov for klare rutiner og sikkerhetsmekanismer for tilgangskontroll og sporing hvis noen skal hente ut data fra loggene. Tjenestene og informasjonen som inngår i KOS utgjør en sentral del av helhetlig design, jfr også omtalen i kapittel Det legges vekt på at utviklingen må være behovsdrevet og at funksjonaliteten utvikles gradvis. Det er også sannsynlig at Oslo kommunes prosjekt for felles avtale for journal- og arkivsystem (earkiv-prosjektet) vil påvirke hvordan en velger å implementere funksjonalitet i KOS InfoInn InfoInn er standardiserte tjenester for å håndtere henvendelser fra innbygger og næringsliv både i form av formaliserte og strukturerte dokument f.eks. søknader levert gjennom en «Veiledet dialog» eller skjemaløsningen (SNOK), og digitale brev fra f.eks. KS FIKS (SvarInn). Komponenten er navngitt InfoInn for å favne bredere enn skjema fordi det i en moderne brukerrettet løsning skal være mulig for en bruker å levere informasjon i en brukerdialog uten at brukeren har opplevelsen av å fylle ut et skjema. I beskrivelsen nedenfor har vi brukt begrepet «henvendelse» for ikke å låse beskrivelsen til tradisjonelle skjemaer. Henvendelser dekker også forsendelser som kommer utenfra, via FIKS. InfoInn implementerer grensesnitt for å motta forsendelser fra FIKS. Det er også mulig å etablere mottak av data fra andre portaler/løsninger enn de som per i dag inngår i «Brukerdialog», ved å implementere nye mottaksgrensesnitt i InfoInn. Barnehageportalen er eksempel på en slik eksisterende portal som tar i mot henvendelser til Oslo kommune (søknad om barnehageplass). Ved å legge til et grensesnitt for barnehageportalen i InfoInn, kan innbyggerne finne igjen søknaden i Min side senere. I tillegg til å håndtere innsending av henvendelser fra bruker inneholder komponenten tjenester for å vise informasjon fra tidligere henvendelser samt for å kopiere informasjon fra tidligere henvendelser for bruk i en ny tilsvarende henvendelse. For at bruker skal finne igjen og kunne gjenbruke informasjon fra tidligere henvendelser lagres dataene i en Mottakskatalog. Behovet for å lagre alle innkommende strukturerte og formaliserte henvendelser (skjema/søknader o.l.) kan kort oppsummeres som følger; Mottakskatalogen sikrer at data fra SNOK og «Veiledet dialog» lagres strukturert på en ensartet måte, slik brukeren fylte de ut, frikoblet fra fag og journal-/arkivsystemene, slik at skjemadata kan benyttes døgnkontinuerlig i brukerdialogen. Det er fag- og journal- /arkivsystemenes ansvar å arkivere den innsendte informasjonen i henhold til arkivloven uansett om dette skjer manuelt eller automatisk. Strukturerte data i Mottakskatalogen benyttes for preutfylling av data fra tidligere henvendelser fra brukeren. Data lagret i mottakskatalogen sikrer døgnåpen tilgjengelighet av skjematjenestene uavhengig av fag og journal-/arkivsystemenes åpningstid. Mottakskatalogen er strukturert på en ensartet måte og vil derfor forenkle tjenestene som benyttes fra «Min Side» InfoInn tar imot data på standardisert format eller dokumenter, lagrer en kopi av henvendelsen i mottakskatalogen og ruter informasjonen videre til fag- eller journal-/arkivsystem. Dersom det ikke er etablert en integrasjon til fag- eller journal-/arkivsystem, kan forsendelsen rutes til Oslo kommunes epost-plattform, som er satt opp med transaksjonssikring og kryptering. 31 Se Figur 14 for illustrasjon av InfoInn (røde piler). 31 Epost er i sin natur ikke transaksjonssikret, men for epost internt i Oslo kommune utnyttes epostplattformens API for å sikre overføringen (kvitteringsmekanismer osv) i tråd med prinsippene i ITAS, jfr kapittel , 55

56 Komponentnavn Finnes komponenten fra før? - Er den komplett - Må den tilpasses - Utvikles / Anskaffe InfoInn For de Veiledet dialog-tjenestene som er i produksjon er det laget integrasjon for å få data inn i InfoInn. I tillegg eksisterer det i dag en komponent for skjemamottak for SNOK Grensesnitt for å motta forsendelser fra Digitale forsendelser (KS FIKS) etableres høsten 2015 Hva er inndata til komponenten Hva produserer komponenten (Utdata / Funksjonalitet) Forutsetninger / Premisser Det er også planlagt grensesnitt mot andre kanaler for henvendelser slik at innbyggeren får en samlet oversikt over sin korrespondanse via Min side, f.eks. Barnehageportalens søknadsskjemaer. Strukturerte og formaliserte henvendelser fra innbygger og næringsliv på standard format. Samt forsendelser via Digitale forsendelser (KS FIKS). Henvendelser lagret i mottakskatalogen Sender henvendelsen til virksomhetsspesifikt fag- og journal- /arkivsystemer via transformasjon og integrasjon. Eksisterende skjema i SNOK løsningen skal kunne sendes inn i løsningen med minimale tilpasninger. SNOK-tilpasning skal sørge for generisk transformasjon av gamle skjema til nytt format. InfoInn skal muliggjøre at det kan sendes strukturerte og formaliserte data fra andre skjemamotorer enn den som er beskrevet i dette dokumentet. Dokumentene som lagres i mottakskatalogen er kun en statisk kopi av det innbyggeren sendte inn. Avgrensninger / Antakelser Avhengigheter til andre, grensesnitt Brukerdialogen benytter denne tjenesten. Denne tjenesten kan benytte meldingsfunksjonalitet som SMS og e-post. Transformasjon- og integrasjonslaget mot fagsystemene. Funksjonelt omfang (H/M/L) M. Standardiserte tjenester for å håndtere henvendelser fra innbygger og næringsliv i form av formaliserte og strukturerte data (skjema). - Motta henvendelser fra innbyggere og næringsliv - Lagre i mottakskatalogen - Tjenester for å håndtere henvendelser i Min side Unike avhengigheter (H/M/L) M. Avhengighet til: - Mottakskatalogen - Transformasjon og integrasjon - Melding og varsler 56

57 5.3.2 InfoSak InfoSak er standardiserte tjenester for å håndtere sak og status informasjon for innbygger og næringsliv i brukerdialogen på en enhetlig måte. Informasjonen er lagret i en Sakskatalog. Sakskatalogen inneholder en felles modell for saksabonnement- og statusinformasjon på tvers av kommunens virksomheter. Denne modellen skal støtte en generell måte å representere fagområdespesifikk informasjon som er viktig i brukerdialogen. Det betyr ikke at all saksinformasjon skal være tilgjengelig i sakskatalogen, men sakskatalogen kan inneholde en dyplenke til fagsystemspesifikk informasjon. Dette betyr at fagspesifikk saksinformasjon ikke lagres i sakskatalogen, men sakskatalogen vil inneholde referanser til denne informasjonen, slik at denne lar seg aksessere. Et eksempel på dette kan være søknad om barnehage der bruker vil se at det finnes en «barnehage sak», men detaljene finnes ved å følge linken til barnehagesystemet som har detaljinformasjonen. Et tilsvarende eksempel er nettbank og efaktura. Selve transaksjonen finnes i nettbanken, men nettbanken har kun en lenke til fakturaen som ligger hos fakturautsteder (eksternt). Behovet for å lagre saksinformasjon og status i sakskatalogen kan kort oppsummeres som følger: Sakskatalogen skal sikre at status og saksinformasjon lagres strukturert på en ensartet måte. Oslo kommune har et mangfold av fag og journal-/arkivsystemer, og det vil være krevende å basere en løsning på direkte tilgang til disse systemene. Isteden kan en se for seg at systemene publiserer fortløpende eller i intervaller endringer i status som InfoSak kan lese. Utfordringen er å finne egnete, generelle status-kategorier. Sakskatalogen er en sammenstilling av data fra fag og journal-/arkivsystemene og benyttes i brukerdialogen. Data i sakskatalogen benyttes ikke til saksbehandling og det er alltid fag- og journal-/arkivsystemene som er autoritativ kilde til slik informasjon. Data lagret i sakskatalogen sikrer døgnåpen tilgjengelighet av saks- og statusinformasjon uavhengig av fag og journal-/arkivsystemenes åpningstid. Sakskatalogen er strukturert på en ensartet måte og vil derfor forenkle tjenestene som benyttes fra «Min Side» Statusinformasjon om hvor saken er i saksgangen skal kunne vises til brukeren. Ved endringer i en sak kan brukeren varsles via f.eks. SMS eller e-post) dersom han har meldt interesse for det (jfr «Abonnement og varsler). Sak og statusinformasjon er publisert fra de virksomhetsspesifikke løsningene gjennom transformasjon og integrasjonstjenestene. Komponenten skal støtte innsyn i egne saker, partsinnsyn og offentlig innsyn. Tjenesten skal håndtere tilgangsstyring til saksdata avhengig av brukerens autorisasjon og informasjonens klassifisering, eksempelvis basert på følgende kontroller: Er brukeren identifisert? Er det en intern bruker eller ekstern bruker? Inneholder informasjonen personopplysninger og eventuelt sensitive personopplysninger? Er informasjonen unntatt offentligheten? Kan informasjonen publiseres? Det er eier av fagsystemene som er ansvarlig for å klassifisere informasjon slik at denne type kontroller kan utføres og informasjon vises/utleveres. 57

58 Komponentnavn Finnes komponenten fra før? - Er den komplett - Må den tilpasses - Utvikles / Anskaffe Hva er inndata til komponenten Hva produserer komponenten (Utdata / Funksjonalitet) Forutsetninger / Premisser Avgrensninger / Antakelser InfoSak Ny. BLKs planlagte prosjekt for ny løsning for innsyn i politiske saker, skal også se på konsept for offentlig innsyn generelt, og tar høyde for etablering av nye og utvidelse av eksisterende fellesfunksjonalitet, og InfoSak er en viktig del av deres tilnærming. Person/organisasjon/saksreferanse Brukers autorisasjon Henter ut informasjon fra sakskatalogen for bruk i brukerdialogen og min side. Saker (sakstittel, sakstype, journaldato, m.m.) Status (mottatt, tildelt saksbehandler, venter på tilleggsinformasjon, avsluttet, m.m.) Håndterer varsler ved statusendring Fagsystemene må klassifisere informasjon Komponenten forholder seg kun til data fra sakskatalogen som er klassifisert med hensyn til tilgang og autorisasjonsdata. Roller er klart definert og begrenses til: Identifisert bruker innbygger Indentifisert intern bruker. Offentlige data Grensesnitt mot hvert enkelt fagsystem ivaretas av transformasjon og integrasjonslaget. Avhengigheter til andre, Min side benytter InfoInn. grensesnitt Avhengig av at fag og journal-/arkivsystemene avgir data til sakskatalogen for at sak og statusinformasjon kan vises i min side. Funksjonelt omfang (H/M/L) H. Standardiserte tjenester for å håndtere sak og status informasjon for innbygger og næringsliv i brukerdialogen på en enhetlig måte. Komponenten skal støtte innsyn og varsling i egne saker, partsinnsyn og offentlig innsyn. Tilgangsstyring av saksdata. Funksjonelt omfang er satt til medium, men dette forutsetter enhetlig modellering av saksdomene. Unike avhengigheter (H/M/L) M. Avhengighet til: - Abonnement og varsler InfoUt InfoUt er standardiserte tjenester for å håndtere forsendelser fra fag- og journal-/arkivsystemer til innbygger/næringsliv. Dette gjelder utgående brev som forvaltningsvedtak og annen informasjon til innbyggere/næringsliv. Tjenesten er uavhengig av leverandør av forsendelsesmetode, forsendelsesarkiv og printleverandør. InfoUt er koblet til Digitale forsendelser (KS FIKS) som i sin tur sørger for at forsendelsene blir formidlet til mottakeren på riktig infrastruktur (enten direkte via KS FIKS, Digital post til innbygger, Altinn eller andre), 58

59 Figur 14 viser hvordan en forsendelse fra fag- og journal-/arkivsystem blir sendt ut via transformasjon og integrasjon til InfoUt og videre til Digitale forsendelser. Uavhengig av varsel i SvarUt kan InfoUt varsle interessenter på samme måte som ved statusendringer i InfoSak. For at komponenten skal kunne tilby tjenester for å vise en samlet oversikt i Min side over brukerens forsendelser i Oslo kommune på tvers av virksomhetsområder, lagres forsendelsen i en Forsendelseskatalog Behovet for å lagre alle utgående forsendelser i forsendelseskatalogen kan kort oppsummeres som følger. Forsendelseskatalogen skal sikre at alle forsendelser fra Oslo Kommune til innbygger og næringsliv lagres på en ensartet måte uavhengig av hvilket fag og journal-/arkivsystem forsendelsen kommer fra eller hvilken leveringstjeneste som benyttes. Det håndteres via Digitale forsendelser. Denne skal tilpasses til å kunne benytte dokumenter som er lagret i forsendelseskatalogen. Dokumentet som lagres i forsendelseskatalogen er brukerens kopi av dokumentet slik det ble sendt ut. Dette sikrer at brukerens kopi er tilgjengelig selv om systemet det ble sendt fra ikke er tilgjengelig eller ikke har tjenester for å gi innbyggeren tilgang til eget dokument. Forsendelseskatalogen er ikke et arkiv for utgående dokumenter. Dette er fremdeles virksomhetens fag og journal-/arkivsystem sitt ansvar. Forsendelseskatalogen kan lagre ulike typer dokumentasjon av dialog. F.eks. blir kopi av chatlogg med Kemneren lagret forsendelseskatalogen per i dag. Forutsetningen er tilstrekkelig grad av sikker identifikasjon av innbyggeren i den dialogformen som er benyttet. Dokumenter lagret i forsendelseskatalogen sikrer døgnåpen tilgjengelighet til forsendelser uavhengig av fag og journal-/arkivsystemenes åpningstid. Forsendelseskatalogen er strukturert på en ensartet måte og vil derfor forenkle tjenestene som benyttes fra «Min Side». Se Figur 14 for illustrasjon av InfoUt (blå piler). Komponentnavn Finnes komponenten fra før? - Er den komplett - Må den tilpasses - Utvikles / Anskaffe Hva er inndata til komponenten Hva produserer komponenten (Utdata / Funksjonalitet) Forutsetninger / Premisser Avgrensninger / Antakelser Avhengigheter til andre, grensesnitt Funksjonelt omfang (H/M/L) M. InfoUt Er utviklet for SvarUt versjon 2 men må videreutvikles for SvarUt versjon 4, som har mulighet for å sende med om hvordan dokumentet er journalført (sak- og dokumentnummer). Dette er en forutsetning for å kunne importere forsendelsene rett i sak/arkiv-system. SvarUt versjon 4 har også støtte for sikkerhetsnivå 4 (sensitive personopplysninger). Identifisering av mottaker, sak og dokument samt nødvendige parametere til Digitale forsendelser (KS FIKS). En forsendelse til Digitale forsendelser (KS FIKS). Fagsystemet må være i stand til å kalle på InfoUt, alternativt benytte manuell opplasting av dokumenter Designet skal være slik at det er mulig å benytte annen forsendelsesmetode enn SvarUt dersom det blir aktuelt. Ingen kjente avgrensninger på nåværende tidspunkt. SvarUt Standardiserte tjenester for å håndtere forsendelser fra fagog journal-/arkivsystemer til innbygger/ næringsliv. Dette vil være utgående brev som forvaltningsvedtak og annen informasjon til innbyggere/næringsliv. Komponenten støtter manuell opplasting (InfoUt-web), samt fletting/masseutsendelse. 59

60 Unike avhengigheter (H/M/L) L. Avhengighet til: - Forsendelseskatalog - Digitale forsendelser (KS FIKS) - Abonnement og varsler 5.4 Fag- og journal-/arkivsystemer Dette kapittelet beskriver forholdet til fag- og journal-/arkivsystemer. Figur 15 Fag- og journal/arkivsystem I Oslo kommune finnes et stort antall forskjellige fag- og journal-/arkivsystemer med forskjellige teknologiske egenskaper og struktur. Løsningen legger opp til at hvert av disse virksomhetsspesifikke systemene kan integreres med korrespondanse og sakstjenestene på virksomhetsløsningenes premisser. I tilfeller der fag- og journal/arkivsystemene ikke selv støtter den grad av automatisering av prosesser som en ønsker å oppnå i en elektronisk tjeneste, kan en implementere prosessflyt og automatisk regelanvendelse utenfor virksomhetenes fag- og journal/arkivsystemer. Den fagspesifikke logikken knyttet til automatiserte prosesser, transformasjon og integrasjon må nødvendigvis implementeres spesifikt for de enkelte tjenestene i tråd med virksomhetenes spesifikasjoner. Det er likevel hensiktsmessig å synliggjøre dette området som et viktig element knyttet til virksomhetenes egne systemer, ettersom det skaper forbindelsen mellom virksomhetenes egne systemer og de andre elementene i felles funksjonalitet som til sammen utgjør grunnlaget for realiseringen av nye, elektroniske tjenester. Selv om forretningslogikken som implementeres her er virksomhetsspesifikk, er den implementert på en felles måte, og er tilgjengelig for gjenbruk i nye tjenester fra andre virksomheter dersom det er likt eller lignende behov Automatiserte prosesser, transformasjon og integrasjon Transformasjon og integrasjonstjenestene har til hensikt å tilpasse og tilgjengeliggjøre opplysninger fra fag- og journal-/arkivsystemene for Korrespondanse- og sakstjenestene, der dette er mulig. Automatiserte prosesser dekker ulike typer for automatisering knyttet til gjennomføringen av en prosess, som f.eks. å utløse automatisk arkivering av dokument i en sak. Det er også etablert automatisk vilkårsprøving og beslutning i enkelte tilfeller knyttet til gjennomføringen av en Veiledet dialog, slik at saksbehandlingen i visse tilfeller er fullautomatisert og innbyggeren får resultatet iløpet av sekunder. 60

61 Det er ikke etablert en egen komponent for automatisering i form av f.eks. en regelmotor. De automatiserte prosessene er utviklet som egne tjenester i ITAS, på samme måte som transformasjon og integrasjon (se kapittel 5.7.3). Nedenfor er et kodeutdrag som viser et prosessteg i fagprosessen for søknad om skjenkebevilling, enkeltanledning. Først kalles en funksjon for å avgjøre om søknaden kan behandles automatisk («kanbehandlesautomatisk). I så fall skjer det («automatiskbehandling) og en funksjon for generering av vedtaksbrev kalt. Hvis ikke går den til manuell behandling. from(fagprosess_nae_avgjor_automatisk_behandling).setproperty(original_body, body()).choice().when(method(kanbehandlesautomatisk)).setbody(property(original_body)).bean(automatiskbehandling).to(fagprosess_nae_generer_vedtaksbrev).otherwise().setbody(property(original_body)).bean(manuellbehandling).to(fagprosess_nae_send_melding_skjenkeansvarlig).endchoice() Kodeutdraget nedenfor viser et eksempel på testene for å avgjøre om en skjenkesøknad kan avgjøres automatisk, og som blir brukt som del av funksjonen «kanbehandlesautomatisk». Utdraget viser testen for om arrangementet det søkes skjenkebevilling for er av typen bryllup; i så fall returneres «true», for alle andre tilfeller returneres «false»: 32 private def hargyldigskjenkekonsept(arrtype :ArrangementType): Boolean ={ arrtype match { case Bryllup => return true case _ => { return false }} } Komponentnavn Finnes komponenten fra før? - Er den komplett - Må den tilpasses - Utvikles / Anskaffe Hva er inndata til komponenten Hva produserer komponenten (Utdata / Funksjonalitet) Forutsetninger / Premisser Automatiserte prosesser, transformasjon og integrasjon Metoder og plattform for å implementere automatiserte prosesser, transformasjon og integrasjon er på plass som del av ITAS. Det er utviklet flere integrasjoner, fagprosess og automatisk vilkårsprøving som del av tjenestene fra NAE og PBE, bl.a. skjenkebevilling og forespørsel om fasadeendring. Den konkrete, fagspesifikke forretningslogikken for nye tjenester må implementeres for seg, men kan gjenbruke lignende logikk og eventuelle like integrasjoner. Eksempel på sistnevnte er gjenbruk av tjeneste for å integrere mot P360 journal/arkivsystem. Komponenten håndterer inndata fra Korrespondanse og sakstjenestene på standard format. Skjemadata og saksdata på fagsystemets format. Virksomhetene må ha elektronisk fag- og journal-/arkivsystem for å kunne utnytte mulighetene i løsningen fullt ut Merk at eksempelet er forenklet (debuggingskode er fjernet) for å gjøre eksempelet lettere å lese 33 Jf. Arkivinstruks for Oslo kommune 61

62 Avgrensninger / Antakelser Det er ikke gjort vurdering i forhold til de enkelte fag- og journal-/arkivsystem. Det er ikke gjort en uttømmende analyse av alle system. Vi antar at det er stort potensiale for gjenbruk av integrasjonsløsninger på tvers av virksomhetene. Standardisering av transformasjonsalternativer er viktig for å minimere kompleksitet og driftsfølgevirkinger. For nye fagsystem bør det kunne stilles krav til at disse skal håndtere felles integrasjonstjenester i en tjenesteorientert arkitektur slik at transformasjonslaget blir så «tynt» som mulig. Basert på erfaringene implementasjon av prinsippet om tjenesteorientert arkitektur og løse koblinger i ITAS, bør det bl.a. stilles krav til REST-baserte API-er eller meldingsprotokoll som JMS, og tilrettelegging for asynkron kommunikasjon. For sak/arkivsystem er det forventet en standardisering for utveksling dokumenter med journalinfo som metadata drevet av arbeidet i FIKS og Difis arbeid med løsning for meldingsutveksling internt i forvaltningen samt arbeid med Nora 5 tjenestegrensesnitt. Avhengigheter til andre, Korrespondanse- og sakskatalogen samt virksomhetenes faggrensesnitt og journal-/arkivsystemer. Funksjonelt omfang (H/M/L) H. Til hensikt å automatisere prosesser, implementere forretningslogikk i form av f.eks. vilkårsprøving, samt tilpasse og tilgjengeliggjøre data til og fra fag- og journal- /arkivsystemene for Korrespondanse- og sakstjenestene; - Transformere til/fra en felles metadatamodell til et format fag- og journal-/arkivsystemet forstår. - Benytte den integrasjonsteknologi for transport av data som er mest hensiktsmessig for mottagende system. Med hensiktsmessig mener vi økonomi, teknologi, hyppighet og antall. Omfang og avhengighet er stor fordi det er mange og uensartede fag- og journal-/arkivsystemer Unike avhengigheter (H/M/L) H. Avhengighet til: - Sakskatalog - Mange fag- og journal-/arkivsystemer 5.5 Støtte- og forretningstjenester Støtte- og forretningstjenester er en gruppe tjenester som benyttes i brukerdialogen mot innbygger og næringsliv, som det fremgår av figur 9 er disse samlet for å synliggjøre felleskomponenter og tjenester som benyttes i brukerdialogen. De fleste av tjenestene finnes i dag på integrasjonsplattformen ITAS, hvor noen av tjenestene kan benyttes slik de er, mens andre må tilpasses eller nyutvikles. 62

63 Figur 16 - Støtte- og forretningstjenester Autorisering og samtykke Autorisering og samtykke har som utgangspunkt at innbyggeren er identifisert på en sikker måte, gjennom autentisering, jfr kapittel Autorisering av roller i næringslivet ivaretas i dag av Altinn. Samtidig viser erfaringene med Digitale forsendelser at det er et behov for å utvide settet med tilgjengelige roller, spesielt knyttet til dialogen med kommunen. Dette vil gjøre det mulig å tilpasse Min side for en virksomhet slik at en kan skille mellom hvilke ansatte som har tilgang til forsendelser og tjenester på ulike tema. Programmet følger opp videreutvikling av de nasjonale felleskomponentene for å støtte behovene gjennom bl.a. KS og SKATE. Gjennom å legge til rette for at innbyggerne kan samtykke til behandling og utveksling av personopplysninger åpnes det for betydelig større tilgang til informasjon, som er nødvendig for å få til bedre og mer brukertilpassete tjenester, samt mer automatisert saksbehandling. Videre kan bruk av samtykke fremfor andre hjemler for tilgang gi innbyggeren økt innsyn i og kontroll med egne opplysninger. Dette er i tråd med programmets målsetninger og vil bidra til å styrke personvernet. Det er en rekke aktører som ser på tematikken samtykke og muligheten for å legge til rette for samtykke gjennom en felleskomponent, bl.a. Altinn og Helsedirektoratet. KS er også interessert i å finne måter å løse dette på og temaet har klare forbindelser til SKATEs arbeid med fullmakter både for innbyggere og næringsliv. Komponentnavn Autorisering og samtykke Finnes komponenten fra før? - Er den komplett - Må den tilpasses - Utvikles / Anskaffe Hva er inndata til komponenten Autorisering av roller i næringslivet ivaretas delvis av Altinn i dag, men det er behov for et utvidet sett av roller og enklere administrasjon. Det er per i dag ingen etablert felleskomponent for samtykke, men det finnes standarder som er knyttet til mekanismene for autentisering som brukes i dag. Roller med organisasjonstilhørighet - Altinn Samtykke knyttet til autentisert bruker Hva produserer komponenten (Utdata / Funksjonalitet) Forutsetninger / Premisser Avgrensninger / Antakelser Autoriserer bruker for tilgang til tjenester eller informasjon Brukeren er autentisert Altinn videreutvikles for å gjøre roller/rettigheter enklere å forstå og bruke. 63

64 Det samarbeides om å finne supplerende roller til de som finnes i dag. Det er økende interesse for samtykke og fullmakter knyttet til elektroniske tjenester og flere aktører ser på muligheten til å etablere støtte for dette i felleskomponenter/felles funksjonalitet. Avhengigheter til andre, grensesnitt Sikkerhetskomponenten benytter - Uthenting av rolle og organisasjonstilknytning fra Altinn Funksjonelt omfang (H/M/L) M. Unike avhengigheter (H/M/L) M. Avhengighet til: - Altinn - Fremtidige løsninger for samtykke Autentisering Når innbyggere skal bruke elektroniske tjenester i Oslo kommune som krever autentisering vil tjenesten videresende brukeren til Oslo kommunes sikkerhetsportal («Security Provider») som umiddelbart vil sende dem videre til den nasjonale felleskomponenten for autentisering, ID-porten. Med forespørselen følger melding om hvilket sikkerhetsnivå som kreves for tjenesten (3 eller 4). ID-porten tilbyr et sett av påloggingsmekanismer på både sikkerhetsnivå 3 og 4. Etter vellykket innlogging kommer innbyggeren tilbake til kommunens sikkerhetsportal med følgende opplysninger: - Den autentiserte brukerens fødselsnummer - Sikkerhetsnivå (3 eller 4) - Språkvalg Basert på fødselsnummer kan det gjøres oppslag mot Altinn for å finne hvilke virksomheter (org.nr) fødselsnummeret er knyttet til, dersom tjenesten er ment for bruk for virksomheter. Videre kan det gjøres oppslag mot folkeregisteret for å få brukerens navn. Den aktuelle informasjonen videreformidles fra kommunens sikkerhetsportal til den elektroniske tjenesten, som også kan gjøre ytterligere oppslag i registre og fagsystem dersom det er relevant for tjenesten, f.eks. Kontakt- og reservasjonsregisteret eller matrikkelen. Den interne tjenesten som krever pålogging vil avgjøre om sikkerhetsnivået er godkjent ved å sjekke mot informasjonen som følger med fra sikkerhetsportalen. Sikring av dialogen mellom ID-porten og Oslo kommunes sikkerhetsportal er kryptert med server og virksomhetssertifikat. Intern dialog videre mot interne tjenester som bruker autentiseringskomponenten vil sikres ved behov og krav til nivå av sikkerhet for den enkelte løsning. 64

65 Figur 17 Figuren viser forholdet mellom ID-porten og Oslo kommunes sikkerhetsportal («Security Provider») Komponentnavn Finnes komponenten fra før? - Er den komplett - Må den tilpasses - Utvikles / Anskaffe Hva er inndata til komponenten Hva produserer komponenten (Utdata / Funksjonalitet) Forutsetninger / Premisser Avgrensninger / Antakelser Autentisering Security Provider komponenten på ITAS plattformen håndterer autentisering Oslo kommune via ID-porten Det må gjøres en vurdering av om Security Provider må videreutvikles for å håndtere sikkerhetsnivå 4 i tillegg til nivå 3 slik den gjør i dag. 34 Påloggingsinformasjon fra innbygger - ID-porten - DSF Autentisert bruker Ingen. Tjenester med risikonivå 4 med tilhørende krav til sikkerhetsnivå 4 er ikke utredet for teknisk komponent (Security Provider) eller kommunens sikkerhetsorganisering (utlevering av nøkler osv.). Krav for sikkerhetsnivå 4 beror på en risikovurdering i tråd med rammeverket for autentisering og uavviselighet i offentlig sektor 35. En slik risikovurdering kan 34 Elektronisk id (eid) for offentlig sektor skiller i hovedsak mellom nivå 3 og 4 når tjenestene omfatter personopplysninger. Nivå 4 er det som kreves hvis tjenestene kan inneholde sensitive personopplysninger (jfr personopplysningsloven 2 nr 8). BankId og Bypass er eksempler på eid løsninger på nivå Se Rammeverk for autentisering og uavviselighet i elektronisk kommunikasjon med og i offentlig sektor 65

66 dokumenteres i tråd med Difis veileder. 36 Risikovurderingen vil fastslå hvilket risikonivå og sikkerhetsnivå tjenesten krever, og skal gjøres som en del av tjenesteutviklingsprosjektene i virksomhetene. Vurderingen skal inngå i detaljert design for autentiseringskomponenten. Avhengigheter til andre, grensesnitt Sikkerhetskomponenten benytter - Autentisering fra ID-porten (eksterne) - Uthenting av navn fra DSF - Uthenting av rolle og organisasjonstilknytning fra Altinn Funksjonelt omfang (H/M/L) L. Løsningen benytter autentisering gjennom ID-porten. IDporten håndterer mekanismen for valg av sikkerhetsnivå (nivå 3 og 4). Sikkerhetsnivået følger med informasjon om påloggingen til Oslo kommunes sikkerhetsportal (Security provider). Komponenten finnes og er i bruk i dag. Unike avhengigheter (H/M/L) M. Avhengighet til: - Digital kontaktinformasjon for innbyggere (IDporten) - Folkeregisteret (DSF) Digitale forsendelser Oslo kommune har valgt å bruke KS «Felles integrasjonsplattform kommunal sektor» (FIKS) som integrasjonspunkt for alle former for Digitale forsendelser. Tjenesten ble opprinnelig kalt «SvarUt» og var en forenkling for alle forsendelser ved at SvarUt håndterte både digital forsendelse (varsel samt lenke via Altinn), og papirforsendelser (uleste brev ble skrevet ut). Etter hvert som flere funksjoner har kommet til benevnes de ulike funksjonene nå som ulike tjenester i FIKS. SvarUt er en meldingsformidler av digitale forsendelser, er utviklet som en standard komponent fra KommIT, basert på en løsning etablert av Bergen kommune i Opprinnelig fungerte komponenten ved at den tar imot elektroniske forsendelser fra fag- og journal-/arkivsystemer, lagrer dokumentene i et forsendelsesarkiv, sender melding til Altinn meldingsboks som skal sende varsel til mottakere (innbyggere og næringsliv 37 ) via digital kontaktregister. Meldingen som legges i postboksen til Altinn er informasjon med lenketjeneste til SvarUt sitt forsendelsesarkiv. Forsendelser som det ikke finnes digital kontaktinformasjon til, skrives ut omgående via felles printløsning. Dersom dokumentet ikke leses via Altinn innen et definert antall dager skrives dokumentet ut på papir og sendes med post Jf. Difis Veileder i risikovurdering av elektronisk kommunikasjon, se 37 Altinn sender ikke varsler til næringslivet i dag, da løsningen ikke er utviklet. Dette er bestilt fra kommunesektoren til Altinn. En melding med varsel anses som kritisk for å sikre at mottakere får informasjon om at det er kommet en forsendelse til postboksen. 38 Det pågår omfattende regelverksutvikling for å tilpasse kravene til Regjeringens mål om digitalt førstevalg. Sentralt i denne forbindelse er overgang fra samtykke til reservasjonsordning for innbyggere. SvarUt løsningen vil kunne justeres i henhold til regelverket når dette trer i kraft. 66

67 Figuren under illustrerer konseptet for forsendelser via SvarUt: Figur 18 - Konsept for SvarUT Beskrivelsen over gjelder løsningen slik den er tatt i bruk av Bergen kommune. For Oslo kommune er grensesnittet mot SvarUt tilpasset gjennom Korrespondanse- og saktjenester (KOS) slik at dokumentet lagres i Oslo kommunes forsendelseskatalog, jfr kapittel 5.3. Lenketjenesten fra Altinn vil etter hvert linke til Oslo kommunes forsendelseskatalog, dette av hensyn til sikkerhet, kapasitet og fleksibilitet i tjenesteutviklingsprosesser for elektronisk dialog. I juni 2015 er SvarUT utvidet til å støtte sikkerhetsnivå 4 og formidling av forsendelser til Difis «Digital post til innbyggere», inkludert håndtering av 18-månedersregelen. Videre suppleres den med en «Mottaksservice» som gjør at en både kan sende og motta forsendelser via komponenten, og dermed har en også endret navnet til FIKS. Muligheten til å bruke FIKS både for å sende og motta, kombinert med at de nyeste versjonene av grensesnittene har støtte for mer Noark-relatert metadata slik at forsendelser som mottas av et sak/arkiv-system i noen tilfeller kan legges rett på riktig sak, åpner for å bruke KS' FIKS som plattform for å få til utveksling direkte mellom ulike sak/arkiv-system både i og utenfor Oslo kommune. I Difis utredning om meldingsutveksling i forvaltningen anbefales det at offentlige virksomheter tar i bruk et såkalt «integrasjonspunkt» for å gjøre det enklere å forholde seg til det settet av ulike infrastrukturer for meldingsutveksling som allerede finnes. FIKS er langt på vei et slikt integrasjonspunkt, som det også fremgår av Difis egne illustrasjoner: 67

68 Figur 19 - Difis illustrasjon av landskapet som eksisterer av infrastrukturer for meldingsutveksling Denne ambisjonen gjenspeiles også i KS presentasjon av sitt syn på Difis løsningsforslag: Figur 20 - KS' illustrasjon av rollen FIKS kan ha som integrasjonspunkt for meldingsutveksling KS og Difi skal samarbeid om en pilot der en skal få på plass en referanseimplementasjon for et slikt integrasjonspunkt, og det er sannsynlig at FIKS på et tidlig tidspunkt vil støtte de infrastrukturene og formatene som referanseimplementasjonen støtter. Det vil i så fall bety at FIKS får støtte for BEST/EDU i tillegg til GI-standarden som den bygger på i dag, for direkte utveksling med sak/arkivsystemer. I tillegg er det trolig at det vil bli lagt til flere infrastrukturer for utveksling («kanaler»), f.eks. den fremtidige felleseuropeiske infrastrukturen for «edelivery». Merk at Oslo kommune ikke integrerer virksomhetenes systemer direkte mot FIKS, men via Korrespondanse og sakstjenester (KOS). KOS kan også overføre inngående forsendelser til Oslo kommunes epostplattform, dersom det ikke er etablert integrasjon mellom KOS og en virksomhets fag- eller journal-/arkivsystem. 68

69 FIKS danner grunnlaget for KS forslag til løsning for «høring», der høringsparter som bruker FIKS kan svare direkte via FIKS, mens andre kan svare via et elektronisk skjema for eksempel Altinn som så formidles via FIKS tilbake til den virksomheten som har sendt forespørselen om uttalelse. Se hhv scenario A og B nedenfor. Figur 21- Illustrasjon av høring (forespørsel om uttalelse pluss svar) implementert gjennom FIKS to ulike scenarier Komponentnavn Finnes komponenten fra før? - Er den komplett - Må den tilpasses - Utvikles / Anskaffe Digitale forsendelser (KS FIKS) KommIT forvalter i dag en felles løsning for FIKS som driftes av Bergen kommune. Oslo kommune har tre pilotvirksomheter koblet til FIKS via InfoUt (del av KOS). Pilotene har implementert følgende løsninger mot InfoUt som igjen benytter FIKS (SvarUt): - Public360 for Næringsetaten - Doculive for Plan- og bygningsetaten - Doculive for Kemneren Det er planlagt å støtte inngående forsendelser via FIKS (SvarInn) for å implementere høring mellom Næringsetaten og Kemneren i forbindelse med fornyelse av skjenkebevilling. 69

70 Hva er inndata til komponenten ForsendelsesService: Digital kontaktinformasjon om mottaker Fysisk kontaktinformasjon om mottaker Metadata fra Korrespondanse og sakstjenester Melding fra InfoUt Mottaksservice: Forsendelse fra ekstern virksomhet Hva produserer komponenten Statusmelding med lenke til forsendelsen til (Utdata / Funksjonalitet) meldingsboken i Altinn Forsendelsen som PDF fil Forutsetninger / Premisser Standardkomponent fra KommIT. Tilpasninger og justeringer gjennomføres koordinert mot KommIT. Avgrensninger / Antakelser Det vil bli behov for ny funksjonalitet når flere virksomheter og tjenester kobler seg på videre. Avhengigheter til andre, grensesnitt Korrespondanse og sakstjenester; InfoUt, InfoInn Kontakt- og reservasjonsregisteret (ID-porten) Meldingsboks i Altinn Digital post til innbyggere Funksjonelt omfang (H/M/L) L. Komponenten tar imot elektroniske forsendelser fra fagog journal-/arkivsystemer, lagrer dokumentene i et forsendelsesarkiv, sender melding til den rette infrastrukturen avhengig av mottageren, f.eks. Altinn meldingsboks. For inngående forsendelser vil Oslo kommune jevnlig sjekke om det er kommet nye forsendelser, og i så fall hente de ut og kvittere for mottak. Komponenten finnes og er i bruk i dag. Tilpasning av printløsning og forsendelsesarkiv for Oslo kommune vurderes. Unike avhengigheter (H/M/L) M. Avhengighet til: - Altinn - Digital kontaktinformasjon for innbyggere (IDporten) - Printløsning og forsendelseskatalog Betalingsløsning Betalingsløsningen er en eksisterende komponent på ITAS som håndterer kortbetaling på nett mot NETS. Nettleseren til brukeren blir omdirigert til nettsider hos NETS, som foretar autentisering av brukeren, validering av saldo etc. Komponenten sørger for at brukeren kan betale en gitt sum via sitt bankkort samt at klientapplikasjonen får beskjed om at betaling er gjennomført. Det er skissert en utvidelse som kobler denne komponenten direkte med økonomi-systemet via grensesnitt for innsending av salgsordre. På den måten kan avstemming skje direkte i økonomisystemet. 70

71 Komponentnavn Finnes komponenten fra før? - Er den komplett - Må den tilpasses - Utvikles / Anskaffe Hva er inndata til komponenten Hva produserer komponenten (Utdata / Funksjonalitet) Betalingsløsning Må tilpasses Komponent for betalingsløsningen finnes allerede, mens kobling til grensesnitt for økonomisystemet må etableres. Transaksjonsdetaljer fra klientapplikasjonen Informasjon om betalingsavtalen som er lagret i komponenten. Transaksjonsdetaljer til NETS Detaljer om hvorvidt transaksjonen gikk ok eller ikke og evt. feilmeldinger som klientapplikasjonen kan benytte i dialog med brukeren. Utvidelsen som er skissert vil i tillegg sende informasjon om transaksjonen til grensesnittet for økonomisystemet. Forutsetninger / Premisser For å kunne benytte betalingsløsningen må det opprettes en egen bankavtale med NETS og banken som skal ha oppgjøret. Referansen til denne avtalen må lagres i komponenten. Avgrensninger / Antakelser Det antas at informasjonsbehovet til økonomisystemet for å kunne lagre transaksjonene korrekt dekkes av allerede eksisterende informasjon i klientapplikasjonen. Avhengigheter til andre, grensesnitt Betalingsløsning hos NETS Økonomi grensesnitt Funksjonelt omfang (H/M/L) L. Komponenten sørger for at brukeren kan betale en gitt sum via sitt bankkort samt at klientapplikasjonen får beskjed om at betaling er gjennomført. Er en eksisterende komponent på ITAS som håndterer kortbetaling på nett mot NETS. Unike avhengigheter (H/M/L) L. Avhengighet til: - Betalingsløsning hos NETS - Økonomi grensesnitt Økonomi grensesnitt Det finnes i dag et felles standard grensesnitt med en felles datamodell for økonomidata uavhengig av implementasjonen av økonomisystemet (Agresso). Det finnes blant annet tjenester for: Mottak av elektroniske fakturaer Salgsordre og hovedboks bilag Henting av faktura- betalingsinformasjon Vedlikehold av kunderegister Økonomigrensesnittet kan benyttes uendret for å automatisere betalingsløsningen som beskrevet i kapittel

72 Komponentnavn Funksjonelt omfang (H/M/L) L. Økonomi grensesnitt Det finnes i dag et felles standard grensesnitt med en felles datamodell for økonomidata uavhengig av implementasjonen av økonomisystemet (Agresso). Unike avhengigheter (H/M/L) L Multikanalplattform Avhengighet til Agresso Bymiljøetaten har erfaring med tjenesten «BYMelding» som lar brukere sende meldinger bl.a. via egen app. I forbindelse med insentivordningen skal etaten etablere en multikanalplattform med chatfunksjon, med tanke på at løsningen skal utgjøre fremtidig fellesfunksjonalitet for Oslo kommune. Målet er å overføre kundekontakt til bl.a. web chat og få til en universal kø med kompetansebasert ruting på tvers av telefoni, epost, sms, web-chat, sosiale medier, BYMelding og avviste meldinger. Løsningen skal kunne integreres med fagsystem. Komponent navn Finnes komponenten fra før? - Er den komplett - Må den tilpasses - Utvikles / Anskaffe Multikanalplattform (med chat) Må utvikles Universal kø med kompetansebasert ruting på tvers av kanalene telefon, epost, sms, chat, sosiale medier, BYMelding (o.a.). BYM har planer for etablering for sitt kundesenter, med opsjon for at andre virksomheter også skal kunne ta den i bruk Hva er inndata til komponenten Hva produserer komponenten (Utdata / Funksjonalitet) Henvendelser på tvers av kanaler. Ruting av henvendelser til riktig kompetanse for besvarelse, mulighet til å besvare på tvers av kanaler. Forutsetninger / Premisser Avgrensninger / Antakelser Avhengigheter til andre, grensesnitt Ingen kjente Eksisterende kanaler for kontakt med innbyggere (telefon, epost, sms) Fagsystem Funksjonelt omfang (H/M/L) M. Unike avhengigheter (H/M/L) M. - Brukerdialog (SNOK, Veiledet dialog) - Andre dialogformer (chat, sms, epost, app-er) - Autentisering av innbyggeren (i første omgang er det ikke planlagt at dialogen skal forutsette autentisering av innbyggerne) 72

73 5.5.7 Booking og bestilling I forbindelse med insentivordningen har en rekke virksomheter foreslått prosjekter som har en eller annen variant av booking av time eller avtale, inkludert støttetjenester som innsyn i hva som er avtalt og mulighet for å avbestille. Det har vært antatt et behov for en funksjonalitet à la dette tidligere, men det har ikke kommet konkret behov i pilotfasen, og funksjonaliteten har ikke blitt utredet. Som følge av insentivordningen iverksettes det nå et samarbeid mellom flere interessenter for denne funksjonaliteten med tanke på å gjøre det til fellesfunksjonalitet. Detaljer om funksjonelt omfang og avhengigheter vil følge som del av dette arbeidet. Komponentnavn Funksjonelt omfang (H/M/L) Unike avhengigheter (H/M/L) Kalender N/A. Ikke vurdert. For lite utredet per i dag til at man kan si noe om komponenten. N/A. Ikke vurdert. For lite utredet per i dag til at man kan si noe om komponenten. 5.6 Informasjonstjenester Informasjonstjenester er en gruppe tjenester som tilbyr informasjon fra offentlige eller kommunale informasjonsregistre. Figur 22 Informasjonstjenester Alle tjenestene finnes, men noen av tjenestene skal tilpasses for å kunne benyttes som standardiserte grensesnitt for Oslo Kommune Digital kontaktinformasjon for innbyggere (ID-porten) I regi av DIFI er det etablert en felleskomponent for digitalt kontaktregister for innbyggere knyttet til IDporten. Kontaktregisteret skal inneholde informasjon om fødselsnummer, digital kontaktinformasjon (epostadresse og mobilnummer). Endringer i eforvaltningsforskriften vil innebære at informasjon om reservasjon og fullmaktsforhold inngår i registeret. 73

74 Komponentnavn Finnes komponenten fra før? - Er den komplett - Må den tilpasses - Utvikles / Anskaffe Hva er inndata til komponenten Hva produserer komponenten (Utdata / Funksjonalitet) Forutsetninger / Premisser Avgrensninger / Antakelser Avhengigheter til andre, grensesnitt Funksjonelt omfang (H/M/L) Unike avhengigheter (H/M/L) Digital kontaktinformasjon for innbyggere (IDporten) Grensesnitt til registeret er tatt i bruk i forbindelse med kommunens bruk av ID-porten, Altinn og kontaktinformasjonsfunksjonalitet i Min side/veiledet dialog. Koblingen til grensesnittet hos DIFI er tilpasset internt i for å kunne tilby standard grensesnitt for Oslo Kommune. Fødselsnummer Digital kontaktinformasjon (e-post og SMS) Kontaktinformasjon skal forvaltes sentralt, og ikke følge den enkelte sak. Kommunen får, sammen med KommIT, ivaretatt kommunenes behov knyttet til registeret. Informasjon i registeret har oppdatert kontaktinformasjon med god nok kvalitet. Kommunen skal ikke forvalte eget kontakt og reservasjonsregister knyttet til innbyggere. Min Side Skjemaløsningen/Veiledet dialog InfoUt Funksjonelt omfang: L Kontaktregisteret inneholder informasjon om fødselsnummer, digital kontaktinformasjon (epostadresse og mobilnummer). Oslo kommune har etablert en fellestjeneste for oppslag i dette registeret på kommunens integrasjonsplattform. Unike avhengigheter: L Avhengighet til: - ID-porten Digital kontaktinformasjon for næring (Altinn) Kommunen har behov for å kommunisere digitalt med både innbyggere og næringsliv. En utfordring med digital kommunikasjon med næringslivet er at en organisasjon, med tilhørende organisasjonsnummer, kan ha mange ulike kontaktadresser (som e-post, telefon, mv.) knyttet til forskjellige roller (daglig leder, regnskapsfører, arkitekt, mv.). Det finnes imidlertid ikke et tilsvarende elektronisk kontaktregister for næringslivet, slik det gjør for innbyggere. Altinn har et kontaktregister for næringslivet med støtte for å knytte enkeltpersoner til overordnede roller i en organisasjon. Kommunen har imidlertid behov for å kunne kommuniseres med flere roller enn det som er støttet i Altinns register. Inntil dette er på plass vurderes det som et alternativ at behovet for kontaktinformasjon i en enkelt sak følger saken, og baseres på virksomhetenes egne adresselister eller innhentet pr. sak via brukerdialogen. Det pågår samtidig et arbeid i regi av SKATE, som ser på kontaktinformasjon og fullmakter knyttet til næringsdrivende. En foranalyse er forventet til SKATE-møte i midten av juni Samtidig ble det i juni 2015 produksjonssatt en ny versjon av Altinn som bl.a. gir mer fleksibilitet rundt kontaktinformasjonen som brukes for varsling, samt at delegering av rettigheter kan gjøres via RESTgrensesnittet, slik at Oslo kommune potensielt kan lage et brukergrensesnitt i en Veiledet dialog som 74

75 åpner for at en innlogget bruker der og da kan delegere rettigheter, uten å gå inn på Altinn. Et konsept for å gjøre tilgangsstyringen enklere er også utviklet men ikke produksjonssatt. 39 Komponentnavn Funksjonelt omfang (H/M/L) M. Økonomi grensesnitt Altinn har et kontaktregister for næringslivet med støtte for å knytte enkeltpersoner til overordnede roller i en organisasjon. Kommunen har imidlertid behov for å kunne kommuniseres med flere roller enn det som er støttet i Altinns register. Inntil dette er på plass vurderes det som et alternativ at behovet for kontaktinformasjon i en enkelt sak følger saken, og baseres på virksomhetenes egne adresselister eller innhentet pr. sak via brukerdialogen. Unike avhengigheter (H/M/L) H Stedfestet informasjon (Oslo digitalt) Avhengighet til Altinn og KS (KommIT) Stedfestet informasjon er informasjon som er knyttet til en adresse eller som angir en posisjon for et objekt (eks. knyttet til en sak). Stedfestet informasjon gjør bruk av Matrikkelen og kart, kartdata og karttjenester. Karttjenester kan være alt fra rene kartinnsynsløsninger på internett, til små skjermbilder i webskjemaer. Et eksempel på stedfesting av informasjon kan være ulike skoletyper vist på et kart. Hver enkelt skole ligger på en bestemt adresse og kan dermed stedfestes ved hjelp av Matrikkelen. Skolene kan så presenteres sammen med inntaksområder på et situasjonskart fra Plan- og bygningsetaten i en kartinnsynsløsning. Komponentnavn Finnes komponenten fra før? - Er den komplett - Må den tilpasses - Utvikles / Anskaffe Stedfestet informasjon (Oslo digitalt) Må tilpasses. For at data fra fag- og journal-/arkivsystemer skal kunne presenteres sammen med et kart må de enten være knyttet til et geografisk sted via koordinater eller de må kunne knyttes til en adresse, eiendom, bydel eller andre geografiske objekter. Oslo kommune har en kartkomponent som brukes av flere virksomheter. PBE tilrettelegger data for denne i dag. Ved utvidelse/skalering av tjenesten må tilretteleggingen automatiseres i større grad. Hva er inndata til komponenten Data fra fagsystemer som inneholder opplysninger som lar seg stedfeste. Hva produserer komponenten Stedfestet informasjon som kan vises i ulike kartgrensesnitt (Utdata / Funksjonalitet) Forutsetninger / Premisser Det er PBE som ajourholder kartdata som tjenesten krever. Utvidet bruk av kartdata fordrer effektivisering av nødvendig tilrettelegging av stedfestet informasjon. Avgrensninger / Antakelser Ingen. Avhengigheter til andre, grensesnitt Matrikkelen Funksjonelt omfang (H/M/L) M. 39 Se: 75

76 Informasjon som er knyttet til en adresse eller som angir en posisjon for et objekt (eks. knyttet til en sak). Stedfestet informasjon gjør bruk av Matrikkelen og kart, kartdata og karttjenester. Tilrettelegging av data er i dag en manuell oppgave som krever kartfaglig kompetanse. Automatisering av dette kan være omfattende. Unike avhengigheter (H/M/L) L. Avhengighet til: - Matrikkelen Matrikkelen Matrikkelen er en nasjonal database med et grensesnitt for uthenting av informasjon fra det offisielle eiendoms-, bygnings- og adresseregisteret. Den sentrale matrikkelen driftes av Statens kartverk. Oslo kommune har en lokal matrikkel som forvaltes av Plan- og bygningsetaten. Komponentnavn Finnes komponenten fra før? - Er den komplett - Må den tilpasses - Utvikles / Anskaffe Hva er inndata til komponenten Hva produserer komponenten (Utdata / Funksjonalitet) Forutsetninger / Premisser Matrikkelen Avgrensninger / Antakelser Avhengigheter til andre, grensesnitt Lokal matrikkel Matrikkelen Funksjonelt omfang (H/M/L) L. Finnes. En komponent som integrerer mot lokal matrikkel er etablert på ITAS. Matrikkelen har et stort utvalg av kall og metoder. ITAS benytter bare enkelte av disse, for noen spesifikke oppgaver. Adresseinformasjon (eks. adresse og del av adresse, gårds- og bruksnummer, koordinater, områder basert på spatial data) Informasjon om eiendommer, eiendomsgrenser, adresser og bygninger Dagens løsning får returnert bydel ut i fra adresse. Plan- og bygningsetaten gir tillatelse til å bruke lokal matrikkel. Grensesnitt mot matrikkelen gjenbrukes fra PBE. Nasjonal database med et grensesnitt for uthenting av informasjon fra det offisielle eiendoms-, bygnings- og adresseregisteret. Den sentrale matrikkelen driftes av Statens kartverk. Komponenten finnes og er i bruk ved at Oslo kommune har en lokal matrikkel som forvaltes av Plan- og bygningsetaten. Unike avhengigheter (H/M/L) L. Avhengighet til: - Den sentrale matrikkelen Enhetsregisteret Enhetsregisteret forvaltes av Brønnøysundregistrene og inneholder informasjon om organisasjoner (enheter og foretak). Oslo kommune har etablert en fellestjeneste for oppslag i dette registeret på kommunens integrasjonsplattform. 76

77 Komponentnavn Finnes komponenten fra før? - Er den komplett - Må den tilpasses - Utvikles / Anskaffe Hva er inndata til komponenten Hva produserer komponenten (Utdata / Funksjonalitet) Forutsetninger / Premisser Avgrensninger / Antakelser Avhengigheter til andre, grensesnitt Enhetsregisteret Finnes. En tjeneste er etablert som felleskomponent på ITAS for oppslag mot Enhetsregisteret. Tjenesten tilbyr nøkkelopplysninger om organisasjoner. Organisasjonsnummer. Organisasjonsopplysninger. Ingen. Ingen. Skjemaløsningen (preutfylling og kontroll) Funksjonelt omfang (H/M/L) L. Forvaltes av Brønnøysundregistrene og inneholder informasjon om organisasjoner (enheter og foretak). Oslo kommune har etablert en fellestjeneste for oppslag i dette registeret på kommunens integrasjonsplattform. Unike avhengigheter (H/M/L) L. Avhengighet til: - Enhetsregistre Folkeregisteret (DSF) Det sentrale folkeregisteret omfatter nøkkelopplysninger om alle personer som er eller har vært bosatt i Norge. Folkeregisteret registrerer opplysninger om blant annet; fødsler, navnevalg, farskap og foreldreansvar flytting endringer i sivilstand dødsfall navneendringer statsborgerskap Oslo kommune har etablert en fellestjeneste for oppsalg mot folkeregisteret på kommunens integrasjonsplattform. Komponentnavn Finnes komponenten fra før? - Er den komplett - Må den tilpasses - Utvikles / Anskaffe Hva er inndata til komponenten Hva produserer komponenten (Utdata / Funksjonalitet) Forutsetninger / Premisser Avgrensninger / Antakelser Avhengigheter til andre, grensesnitt Folkeregisteret (DSF) Finnes. En tjeneste er etablert som felleskomponent på ITAS for oppslag mot Folkeregisteret. Tjenesten tilbyr nøkkelopplysninger om personer, etter behov. Kun felter som virksomhetene har behov for er inkludert. Fødselsnummer. Personopplysninger, slik som navn, relasjoner, fysisk kontaktinformasjon og adresser. Avtale med Skatteetaten for etablering av hver enkelt tjeneste. Kostnader pr. transaksjon. Oppslag i registeret tilgangsstyres, eksempelvis gjennom autentisering og autorisering. Ingen. Skjemaløsningen (preutfylling og kontroll) 77

78 Funksjonelt omfang (H/M/L) L. Unike avhengigheter (H/M/L) L. Det sentrale folkeregisteret omfatter nøkkelopplysninger om alle personer som er eller har vært bosatt i Norge. Oslo kommune har etablert en fellestjeneste for oppsalg mot folkeregisteret på kommunens integrasjonsplattform. Avhengighet til: - Det sentrale folkeregistret 78

79 5.7 ITAS applikasjons- og integrasjonsplattform I målbildet for fellesfunksjonalitet i kapittel er formålet å beskrive hvilken funksjonalitet som etableres, det er ikke et en-til-en-forhold mellom fellesfunksjonaliteten og de kjørende komponenter. Område 6., Applikasjons- og integrasjonsplattform (ITAS), er derimot mer enn bare en funksjonell avgrensning. Med tanke på realiseringen av Helhetlig design har ITAS flere roller: Primært er ITAS applikasjonsplattformen der alle tjenestene som utvikles i regi av prosjekt for fellesfunksjonalitet kjører. Dernest er det en plattform for integrasjon mellom ulike tjenester både interne og eksterne. En viktig egenskap ved ITAS både som applikasjons- og integrasjonsplattform er hvordan plattformen understøtter alle fasene i veien fra ide til kjørende kode inkludert felles logging og overvåking, se mer om det i kapittel Referansearkitektur og egenskaper Nedenfor er referansearkitekturen for implementasjon av fellesfunksjonalitet: Figur 23 - Referansearkitektur for implementasjon av fellesfunksjonalitet De ulike tjenestene er fordelt i logiske lag (presentasjonslag, tjenestelag og integrasjonslag). Men alle tjenestene er realisert på ITAS i tråd med ITAS' arkitektur og metodikk: Arkitektur: Mikrotjenester o Adskilte funksjonelle tjenester som kommuniserer med hverandre o Tjenestene deler ikke data via felles datalager o Små tjenester som kjører i separate "kontainere" og som starter raskt Web-teknologi: o I hovedsak HTTP REST, med JSON som foretrukket utvekslingsformat Feiltoleranse: o Tjenestene skal være "selvforsynte" og ikke være avhengig av andre tjenester 79

80 o Asynkron kommunikasjon så langt det er mulig for å unngå at nedetid/sen respons i et bakenforliggende system forplanter seg og fører til at flere systemer blir utilgjengelige Metodikk: Tilrettelegging for kontinuerlige leveranser gjennom: Automatisering o Konfigurering av servere o Bygging og utrulling (produksjonssetting) av nye eller endrede tjenester o Oppsett av logging og overvåking o Varsling og oppdatering av dokumentasjon "DevOps" o Utviklere kan selv igangsette produksjonssetting av egen kildekode o Kode skal være vurdert av andre før den produksjonssettes o Sammen med automatisering gir det mulighet for å produksjonssette ofte og lite, fremfor sjelden og mye o Det er de samme personene som utvikler tjenestene som også forvalter dem, ved at forvaltningsrollen rullerer mellom utviklerne. På den måten erfarer utviklerne hva som kjennetegner tjenester som er gode å drifte og forvalte Logging og overvåking o Samlet oversikt over status på alle tjenester o Varsler ved problemer med kommunikasjonen mellom tjenestene Driftsmiljø og sikkerhetsmekanismer Kjøremiljøet til ITAS er fordelt på flere virtuelle servere som igjen er fordelt på flere fysiske servere som befinner seg i ulike datahaller. Alle tjenester som kjører er redundante og det er lastbalansering av trafikken. Redundansen utnyttes også for å kunne produksjonssette endringer uten nedetid ved at bare den ene av minst to like tjenester tas ned for oppdatering og startes opp igjen før de øvrige oppdateres. I tillegg til produksjonsmiljøet inngår det flere testmiljøer i ITAS. I tråd med god praksis gir ITAS mulighet for å plasseres tjenester i ulike soner der trafikken mellom sonene kontrolleres av brannmur. Videre er det mekanismer for transaksjonssikring og meldingssikkerhet. Kombinert med mulighet for kanalsikring, gjør det at ITAS kan brukes til personsensitive opplysninger. Men det er per i dag ikke mekanismer for å garantere responstid for en transaksjon, og derfor er det foreløpig ikke anbefalt å bruke ITAS til tidskritiske tjenester ("liv og helse") Transaksjonssikkerhet Nedenfor er en illustrasjon som viser hvordan en kombinerer feiltoleranse i form av asynkrone utvekslinger, samtidig som transaksjonssikkerhet er ivaretatt gjennom kvitteringsmekanismer mellom de enkelte utvekslingene. Illustrasjonen viser overgangen fra Digital forsendelse (KS FIKS) til et av kommunens fagsystem, gjennom en eller flere tjenester i ITAS Som beskrevet i kapittel kan en også gå via eksisterende integrasjon mellom ITAS og kommunens plattform for epost for de som har integrert fagsystemene med epost allerede. 80

81 Figur 24 - Transaksjonssikring ved asynkron kommunikasjon Det gis ikke en kvittering fra siste komponent til første komponent. Når en komponent har avgitt meldingen og fått beskjed om at det gikk greit (synkront) så er det den mottagende komponents ansvar å sende den videre (asynkron). Logging og feilkøer er også en viktig del av dette bildet, og en viktig del av forvaltningen av ITAS er overvåking av logger for raskt å kunne reagere dersom det oppstår problemer ITAS som integrasjonsplattform Når ITAS benyttes til integrasjon er det med utgangspunkt i de samme mekanismene som gjelder for ITAS som applikasjonsplattform. Det etableres egne tjenester som fungerer som bindeledd mellom de tjenestene som skal kommunisere med hverandre (integreres). Hensikten er å samle den kompleksiteten og de gjensidige avhengighetene som mange integrasjoner mellom systemer uunngåelig fører til, ett sted, der en har tekniske og organisatoriske mekanismer for å håndtere kompleksiteten. Under beskrivelsen av arkitekturen nevnes HTTP REST og JSON, men det er viktig å understreke at ITAS ikke legger føringer på hva slags teknologier det skal integreres med. Siden integrasjonsmekanismene ikke er begrenset av ett konkret integrasjonsprodukt og de protokollene og formatene som et slikt produkt støtter, er en av egenskapene til ITAS nettopp høy grad av fleksibilitet; det kan utvikles integrasjonstjenester for å integrere mot alt fra filsystem og FTP til moderne RESTbaserte API. Den tekniske fleksibiliteten forsterkes av fleksibiliteten som følger av støtten for kontinuerlige leveranser og gode mekanismer for overvåking. Integrasjoner som feiler fanges fort opp. Dersom feilen skyldes at det er har skjedd endringer en tjeneste som et av kommunens fagsystem kommuniserer med via ITAS, ligger det organisatorisk og utrullingsmessig til rette for raskt å oppdatere integrasjonstjenestene i ITAS slik at kommunikasjonen fortsatt fungerer. Alternativet ville vært å gjøre endringen på fagsystemet, der de ulike fagsystemleverandørene kan ha ulike responstider (og priser). 41 Nedenfor er en arkitekturfigur som illustrerer hvordan en veiledet dialog består av frontend, API, og oppslag mot både internt fagsystem og eksternt register der begge oppslagene gjøres via integrasjonstjenester på ITAS («eiendomsoppslag» og «matrikkeloppslag»). De tre øverste lagene er alle i ITAS, mens det nederste laget («PBE») er utenfor. 41 Merk at dette er unntakssituasjonen; det normale er at slike endringer er kjent i forkant og at en kan planlegge og gjennomføre nødvendige forberedelser til overgangen. 81

82 Figur 25 - Eksempler på tjenester som integrerer Veiledet dialog med eksterne og interne informasjonstjenester ITAS som integrasjonsplattform operasjonaliserer målsetningen om en tjenesteorientert arkitektur Fra idé til kjørende kode i ITAS Nedenfor er en illustrasjon av hvordan utviklingen av en ny funksjonalitet håndteres i ITAS og støttesystemene. Utgangspunktet er at det er gjort et arbeid med tjenestedesign og brukerreise og det skal etableres en funksjonell spesifikasjon. Funksjonell spesifikasjon utarbeides i Confluence, og det tilhørende diagramverktøyet, og danner utgangspunkt for brukerhistorier, som beskrives i JIRA Utviklingen begynner og kildekode håndteres i Github Etter utviklernes egne tester rulles ny funksjonalitet ut i testmiljø, gjennom automatiserte prosesser for bygging og utrulling av tjenester Testing resulterer i rapportering av feil eller endringsbehov i JIRA, og retting av koden i Github Når leveransen er godkjent produksjonssettes den som en eller et sett av nye og endrede tjenester, og logg- og overvåkingsverktøy oppdateres, og det sendes varsler og oppdateres i driftsdokumentasjonen i tråd med ITIL Dersom produksjonssettingen innebærer endringer på kjørende tjenester gjøres det uten nedetid Overvåkingen vil raskt avdekke om produksjonssettingen skaper problemer for andre tjenester, og i så fall vil endringen rulles tilbake, uten nedetid. Eventuelle feilete meldinger blir liggende på kø-er og er klare til å sendes på nytt når tjenesten er oppe igjen. Når tjenesten er i drift håndteres den av det generelle forvaltnings-, vedlikeholds og endringsregimet (ITIL) ITAS som plattform for realiseringen av «Helhetlig design» Som det fremgår i innledningen til kapittel 5 er det valgt en løsningstilnærming i Program for elektroniske tjenester med et «helhetlig overbygg» for å kunne realisere tjenester som dekker de identifiserte behovene. Det er en konsekvens av at det er et omfattende og komplekst systemlandskap i kommunen og vil være det i lang tid fremover. Derfor er også fleksibilitet en viktig forutsetning for å kunne realisere det helhetlige overbygget. 82

83 ITAS som plattform har gjennom de siste ti årene blitt videreutviklet og modnet til det den er i dag, med stor fleksibilitet både teknisk og organisatorisk/utrullingsmessig, slik det er beskrevet i avsnittet om ITAS som integrasjonslag, ovenfor. Dermed er ITAS godt egnet som plattform for å realisere løsningstilnærmingen for Program for elektroniske tjenester. Nedenfor er en forenklet fremstilling av noen av tjenestene og informasjonsflyten som inngår i tjenesten «Forespørsel om fasadeendring» fra Plan- og bygningsetaten: 42 Figur 26 - Forenklet fremstilling av noen av tjenestene og informasjonsflyten som inngår i en elektronisk tjeneste «[F]asadeendring frontend» kjører i innbyggernes nettleser og kommuniserer med kommunen via «fasadeendring API». Til sammen utgjør dette en veiledet dialog som validerer og veileder basert på informasjon som oppgis av brukeren og informasjon som hentes fra andre informasjonstjenester. Underveis mellomlagres det som er gjort som utkast, slik at det er tilgjengelig via Min side. Dersom Veiledet dialog fullføres og ender i en forespørsel til kommunen, lagres forespørselen i «mottakskatalog» og blir tilgjengelig som sendte henvendelser på Min side. I «fasadeendringfagprosess» kan det legges til ytterligere logikk, f.eks. for å identifisere saker som kan behandles automatisk, før forespørselen formidles til ansvarlig virksomhet og blir lagt i journal/arkivsystemet der. Svar på henvendelsen blir sendt digitalt (SvarUt) og lagret i «forsendelseskatalog» slik at det er tilgjengelig for innbyggeren i Min side. Fleksibiliteten i ITAS gjør det mulig å implementere funksjonalitet som er nødvendig for å skape helhetlige og brukervennlige digitale tjenester: Gjenbruk av informasjon gjennom integrasjon mot eksisterende interne og eksterne informasjonskilder, jfr 5.6 Informasjonstjenester o Forutsetning: Virksomheten som er ansvarlig for tjenesten må ha hjemmel til å bruke informasjonen for det aktuelle formålet. Å be innbyggeren samtykke i gjenbruk er en mulighet for å etablere en slik hjemmel Transformasjon av data, slik at: o Informasjon som er tilgjengelig i henhold til én informasjonsmodell og på ett format, kan transformeres for å passe i nye sammenhenger 42 Figuren viser blant annet ikke integrasjonene mot bl.a. ID-porten, kontakt- og resverasjonsregisteret, matrikkelen og Riksantikvarens "gul liste". 83

84 o Informasjon som er spredt på flere systemer, hentes fra flere kilder, settes sammen til en melding som kan formidles videre (aggregering) o Forutsetning: På samme måte som over må det foreligge en hjemmel for bruk, og virksomheten som er ansvarlig for tjenesten må forsikre seg om at transformasjonen ikke fører til at informasjonen endrer betydning og fører til misforståelser og i verste fall gale avgjørelser Automatisering basert på den informasjonen som foreligger. Dette kan skje: o Som del av den veiledete dialogen informasjon som oppgis et sted gir veiledning til hva som må oppgis videre o Validering - automatiserte tester på om informasjonen er korrekt og komplett slik at det er grunnlag for å behandle søknaden o Saksbehandlingsregler, slik at det kan fattes automatisk vedtak dersom kriteriene for det er tilstede o Forutsetning: I alle tilfellene er det en forutsetning for automatiseringen at den ansvarlige virksomheten forsikrer seg om at automatiseringsreglene er i tråd med det regelverket og de rutinene som gjelder for saksbehandlingen Det vil ofte være en vurdering hvor mye av funksjonaliteten som er nevnt over (forretningslogikk) som bør implementeres i virksomhetenes eget fagsystem, eller som del av de elektroniske tjenestene som utvikles i ITAS. I noen tilfeller vil det være en avveining mellom å få etablert mer brukervennlige tjenester og mer automatisering av saksbehandling på en raskere måte kontra det å implementere og forvalte/holde oppdatert virksomhetens forretningslogikk på flere ulike systemer fremfor å holde dem samlet i ett fagsystem. 5.8 Sikkerhet Løsningen skal ivareta de krav som Oslo Kommune og andre myndigheter har til sikkerhet og personvern. Løsningen baseres på ITAS og utnytter de sikkerhetsmekanismer som finnes der. Løsningen plasseres i en infrastruktur som er basert på sikkerhetsarkitektur i Oslofelles 2.0. Dette innebærer blant annet at alle Oslo kommunes virksomhetssystemer er beskyttet av sine egne autonome sikkerhetssoner, spesifikke sikkerhetsregler og egen policy samt at trafikken er kryptert mellom klienter og applikasjoner. En detaljert beskrivelse av sikkerhetsarkitektur i Oslofelles 2.0 finnes beskrevet i et eget dokument Designdokument for Sonemodell, jf. R1. Oslo kommunes interne brukere autentiseres gjennom en felles intern autentisering og innbyggere/næringslivet autentiseres gjennom offentlige autentiseringsportaler. Autentisering er beskrevet i kapittel Tilgang til informasjon er avhengig av brukerens autorisasjon og informasjonstypens sikkerhetsklassifisering, eksempelvis basert på følgende: Er brukeren identifisert? Er det en intern bruker eller ekstern bruker? Inneholder informasjonen personopplysninger og eventuelt sensitive personopplysninger? Er informasjonen unntatt offentligheten? Kan informasjonen publiseres? Som beskrevet i kapittel er arkitekturen for utviklingen av brukerflaten basert på en tilnærming der en har etablert API-er på serversiden som klientsiden kommuniserer med. Det gir en åpenhet om logikken i tjenestene som kan gi angripere en fordel, fremfor når mer av kildekoden er skjult. Men kravene til sikring av grensesnittene er de samme; valideringsmekanismer for å unngå sårbarheter i form av manipulering av inputverdier, samt autentisering av klienten for å unngå «man-in-the-middle»- angrep er f.eks. like viktig uavhengig av dette valget. 84

85 5.8.1 Om personvern Løsningen sammenstiller og transformerer opplysninger og informasjon om saker og brukere for å kunne presentere dette på en ny og enhetlig måte i den digitale kanalen. Dette skal blant annet føre til økt mulighet for innbyggere og næringsliv til å ivareta sine innsynsrettigheter. Informasjon om brukerne vil i mange tilfeller utgjøre personopplysninger, og vil måtte følge de krav som følger av lovgivningen og kommunens retningslinjer på området. Løsningen er utviklet i tråd med ambisjonene for ivaretakelsen av brukernes personvern som beskrevet i Overordnet design. Føringene knyttet til ambisjonsnivået er vurdert i forhold til detaljnivået som løsningen er beskrevet på i dette dokumentet. Detaljer relatert til implementering av løsningen vil utredes i detaljert design for de ulike komponentene. Under følger en overordnet drøfting av kravene knyttet til elektroniske tjenester i Overordnet design: Mottakere av informasjon som er resultatet av en sammenstilling skal kunne spore alle opplysningene tilbake til kilden. Sporbarhet er en avgjørende forutsetning for innsyn, retting og sletting, eksempelvis hvis ny informasjon viser at en sammenstilling må reverseres. Løsningen sammenstiller og transformerer informasjon. Transformasjonslogikken i løsningen begrenser seg imidlertid til beskrivelser av informasjonen (metadata), og det gjøres ikke endringer i den materielle informasjonen som danner beslutningsgrunnlaget. Løsningen legger til rette for å samle saksinformasjon og saksstatus på et felles sted for brukeren, gjennom en Min side. En felles Min side vil gjøre det enklere for brukerne å benytte seg av sin innsynsrett og bidra til økt kvalitet på opplysninger. Krav til innsyn, retting og sletting skal således fortsatt være virksomhetenes ansvar å ivareta. Beslutninger enten de er automatiserte eller manuelle må tas på et mest mulig oppdatert og konsistent informasjonsgrunnlag på tvers av kommunens virksomheter og etater. Endringer i det delte informasjonsgrunnlaget må gjenspeiles snarest mulig i alle beslutningsstøttesystemer der informasjonen vil utgjøre et beslutningsgrunnlag. Sammenstillinger og avledet informasjon som utgjør grunnlag for beslutninger, må kunne manuelt eller automatisk re-evalueres og eventuelt oppdateres dersom ny eller endret informasjon tilsier det. Informasjon som lagres i løsningen benyttes ikke i virksomhetenes saksbehandling, og er derfor ikke del av beslutningsgrunnlaget. Alle henvendelser og endringer initieres av brukerne eller virksomhetene, og ikke i de enkelte løsningene for fellesfunksjonalitet. Det er et prinsipp i løsningen at det er virksomhetene som eier informasjon knyttet til sine saker og sine brukere. Løsningen gjenspeiler kun denne informasjonen på en standardisert måte. Ethvert oppslag eller flyt av informasjon til tredjepart må logges på en sikker måte, og slik at det alltid er mulig å spore hvem som har sett informasjonen. Alle oppslag og flyt av informasjon til tredjepart, slik som fellesregistre, går i løsningen via kommunens integrasjonsplattform (ITAS) og skal sikres og loggføres i henhold til gjeldende regler og retningslinjer i kommunen. Det må legges til rette for innhenting av samtykke fra brukeren dersom sammenstillingen eller behandlingen krever dette eksempelvis når informasjonen skal overføres til en tredjepart. Løsningen baserer seg overordnet sett på innhenting av samtykke ved funksjonalitet som proaktivt varsel og abonnementstjenester. Løsningen skal gi mulighet for at den enkelte kan få innsyn i opplysningene som skal utleveres før vedkommende gir samtykke til utlevering. Dette vil bidra til at innbyggere i langt større grad vil slippe å gi blanko samtykker ved utlevering/overføring av opplysninger til tredjepart, og vil sikre at samtykke i langt større grad gis på informert grunnlag. Personopplysninger bør hvis mulig - kunne overføres og lagres i anonymisert eller pseudonymisert form. Anonymisert eller pseudonymisert informasjon kan likevel danne avgjørende kontekst og bidra til å øke den samlede informasjonskvaliteten. 85

86 Behov og mulighet for anonymisering eller pseudonymisering av personopplysninger i løsningen vil utredes i forbindelse med implementering av de ulike komponentene og ved utvikling av de enkelte nye tjenestene til innbyggere og næringsliv. 86

87 6 Innføring av fellesfunksjonalitet Programmets gjennomføringsstrategi består av flere elementer. Faseinndeling - tre faser Leveranseplan med tjenestetrapp Metode for tjenestedesign, med brukerreiser og prototyper Behovsdrevet utvikling Gjenbruke eksisterende løsninger Bestiller/utfører med prosjekt for fellesfunksjonalitet (PFF) som utfører Kontinuerlige leveranser og kontinuerlig forbedring Faseinndeling Programmet er delt i tre faser. I den første fasen ble strategi og design utviklet på bakgrunn av analyse av nåsituasjon og overordnet målbilde. I fase 2, produksjons- og utprøvingsfasen, har programmet utviklet felles funksjonalitet og tjenester i samarbeid med pilotetatene. I fase 3 skaleres utviklingsarbeidet opp og flere tjenester vil utvikles, samtidig som gevinster realiseres. Dette sammenfaller også med utviklingsprosjekter identifisert og finansiert gjennom insentivprogrammet. Figur 27 - Gjennomføringsstrategi for program for elektroniske tjenester (jfr S6) Leveranseplan med tjenestetrapp Den siste fasen inkluderer en overordnet plan over hvilke tjenesteområder det skal utvikles tjenester for i de kommende årene, i form av en fireårsplan, også kalt tjenestetrapp. Den viser hvilke tjenesteområder som skal digitaliseres fremover. 87

88 Figur 28 Programmets tjenestetrapp (jfr S6) Metode for tjenestedesign Når arbeidet med digitalisering av et nytt tjenesteområde starter benyttes Oslo kommunes metode for tjenestedesign. Metoden er utviklet i fase 2 (pilotfasen), og sentrale elementer i metoden er bl.a. brukerreiser og prototyper. Metoden skal sikre at virksomhetene har brukerfokus i tjenestedesignarbeidet, samtidig som en øker kommunens digitale modenhet og innovasjonsevne og finner måter å digitalisere prosesser på som både er gjennomførbare på kort sikt, og støtter opp om kommunens konsernbehov. Dette er mulig ved at brukerreisene sees opp mot de bakenforliggende arbeidsprosessene, inkludert hvilke systemer, hvilken informasjon og hvilke andre organisasjoner som er del av prosessen. Oslo kommunes metode for tjenestedesign er dokumentert i et eget dokument. Behovsdrevet utvikling Utvikling av felles funksjonalitet skal være behovsdrevet. Det utvikles ikke ny felles funksjonalitet basert på antagelse om fremtidig behov -- behovet må være reelt og konkretisert. På den måten reduseres risikoen for at det investeres i utviklingsarbeid som ikke gir gevinst, eller der gevinstene ikke kan realiseres før etter lang tid. Gjenbruke eksisterende løsninger Det er et mål for Oslo kommune å gjenbruke eksisterende løsninger fremfor å utvikle funksjonalitet selv dersom det finnes fra før. Som del av dette engasjerer kommunen seg i de fora der en kan påvirke videreutviklingen av nasjonale og kommunale felleskomponenter, og spiller inn endringsforslag med bakgrunn i de behovene som er kommet frem i de tidligere behovsanalysene, eller nye behov som identifiseres i arbeidet med brukerreiser på nye tjenesteområder. Prosjekt for fellesfunksjonalitet For design- og utviklingsarbeidet er det etablert et eget prosjekt (PFF) som leder utviklingsarbeidet. Prosjektet har ansvaret for å sørge for å identifisere og verifisere behov og sørge for utvikling av fellesfunksjonalitet. Det er etablert et «Produktråd» som ledes av PFF og der virksomhetene er representert, hvor formålet er å identifisere og drøfte felles funksjonalitet og felles valg på tvers av de elektroniske tjenestene. På den måten ivaretas helhets- og konsernperspektivet. 88

89 Kontinuerlige leveranser og kontinuerlig forbedring Oslo kommune har et apparat for utvikling av felles funksjonalitet og nye elektroniske tjenester som er svært fleksibelt, og det er mulig å gjøre hyppige produksjonssettinger. Det er viktig for kommunen å levere ny funksjonalitet som har verdi for brukeren så tidlig som mulig. Dette er også den beste måten å få kvalitetssikret leveransene og de valgene som er gjort. Erfaringene med tjenestene danner grunnlag for læring, som igjen kan brukes til å forbedre eksisterende tjenester samt designe nye tjenester. 89

90 7 Definisjoner Tabell 19 under beskriver sentrale begrep i dette dokumentet i konteksten av helhetlig design. 43 Tabell 19: Definisjoner Begrep Arkitekturprinsipper Tjenesteorientert arkitektur Brukerdialog Brukerfront Detaljert design Digital modenhet Digitalt førstevalg Digital kanal Døgnåpen forvaltning Døgnåpen digital forvaltning Elektronisk Digital Elektroniske tjenester Fagsystem Fellesfunksjonalitet Definisjon Med arkitekturprinsippene menes de prinsipper som skal være førende for virksomhetene i kommunen ved valg og utforming av IT- løsninger. Prinsippene referer til Oslo kommunes arkitekturprinsipper, som foreslått for byrådet i Kommunens prinsipper bygger på arkitekturprinsippene til Difi. Prinsippet om tjenesteorientering innebærer at IT- løsningene skal ta hensyn til hvilke tjenester (i forståelsen funksjonalitet) som leveres av en komponent, fremfor hvordan komponenten er sammensatt. Med brukerdialog menes de tjenester og prosesser som brukeren (innbygger/næringsliv) faktisk ser. Med en brukerfront menes de digitale og fysiske kontaktpunktene som møter brukeren (innbygger/næringsliv) i ulike kanaler. At brukerfronten er enhetlig betyr at dette sees på tvers av kommunens virksomheter. Eksempelvis at de elektroniske tjenestene, henvendelser/skjema, svar, veiledning og informasjon på oslo.kommune.no fremstår som enhetlig. Med detaljert design menes i kommunen en fremstilling som detaljert beskriver kravene til komponentene i en løsning, og hvordan komponentene virker sammen, både funksjonelt og teknisk. Med digital modenhet menes her evnen til å endre arbeidsprosesser for å få levert sine tjenester ved hjelp av teknologi. Digitalt førstevalg betyr at digital kommunikasjon skal være den primære kanalen for dialogen mellom innbyggerne og offentlige virksomheter, mellom næringsliv og offentlige virksomheter og mellom offentlige virksomheter. I en digital kanal skjer kommunikasjonen med innbyggere og næringsliv på en eller flere digitale plattformer. Døgnåpen (digital) forvaltning defineres som at brukerne har mulighet for 44 : 1. å henvende seg, 2. få bekreftelse på mottatt henvendelse, 3. få så mye informasjon som mulig om videre fremdrift, 4. mulighet for å sjekke status senere og eventuelt 5. automatisert, regelstyrt saksbehandling som gir umiddelbare tilbakemeldinger. Ordene elektronisk og digital benyttes som synonymer i dokumentet. Med elektroniske tjenester menes offentlige oppgaver der hele eller deler av arbeids- eller kommunikasjonsprosessen som ligger til grunn for oppgaveutførelsen er understøttet av datamaskinsystemer. I konteksten av dette dokumentet innebærer dette at grensesnittet mot brukerne (innbyggere og næringsliv) er digitalisert. Med fagsystem menes et IT-system som støtter et fagområde. Det kan ha i seg også funksjonalitet som dekker journal- og arkivfunksjonalitet. Med fellesfunksjonalitet menes funksjonalitet som dekker et felles behov, og kan gjenbrukes på tvers av organisatoriske skillelinjer, og eventuelt utvikles, forvaltes, videreutvikles, distribueres og/eller driftes felles. Begrepet omfatter både elektroniske fellesløsninger, felleskomponenter, fellesprosesser, fellesregistre og standard grensesnitt. 43 Listen er ikke en uttømmende ordliste over terminologien på området. 44 Definisjonen er hentet fra Difis overordnede arkitekturprinsipper 90

91 Begrep Felleskomponent Grensesnitt Standard grensesnitt Hyllevare Infrastruktur Journal-/arkivsystem Elektronisk arkiv Løsningsbeskrivelse Mellomlag Tjenestelag Overordnet design Proaktivitet Definisjon Med en komponent menes en avgrenset del av en IT-løsning. En IT-løsning kan bestå av flere komponenter. Felleskomponenter defineres som komponenter i IT-løsninger som kan sambrukes eller gjenbrukes i flere ITløsninger i offentlig sektor. Felleskomponenter er felles byggeklosser for å kunne utvikle elektroniske tjenester Med grensesnitt menes forbindelsen mellom aktører (for eksempel systemer) som skal motta eller avgi data. Med standard grensesnitt menes at denne forbindelsen er definert enhetlig og felles. Grensesnitt standardiseres gjerne for å forenkle integrasjon ved gjenbruk. Med hyllevare (COTS Commercial off the shelf)) menes programvare som er felles for flere kunder, og vedlikeholdes felles av leverandøren. For å få fullt utbytte av hyllevare, bør man bruke felles standardiserte oppsett, hvor det skal benyttes flere installasjoner. Tjenester, operativsystemer, maskinvare og kommunikasjonsløsninger som er nødvendig for å få systemer til å fungere og til å samhandle slik at opplysninger kan utveksles mellom virksomheter internt i Oslo kommune og mellom Oslo kommune og kommunens innbyggere, brukere, kunder og næringsliv. Med journal-/arkivsystem menes systemløsning(er) til ivaretakelse av offentlig journal og arkiv etter offentleglova og arkivlova med forskrifter. Et elektronisk arkiv er et arkiv som består av elektroniske dokumenter. I Oslo kommune benyttes i flere tilfeller journal-/arkivsystemer som eneste system i saksbehandlingsprosessen. Med løsningsbeskrivelse menes beskrivelsene av komponentene og prosessene som skal ivareta det funksjonelle målbildet. Med mellomlag eller tjenestelag menes et sett av felles tjenester og komponenter som transporterer og transformerer data mellom systemer. Med overordnet design menes i kommunen et definisjonen som beskriver visjon, mål, strategi og prinsipper for en funksjonell løsning. Jfr S1 Begrepet proaktivitet brukes til å beskrive tjenester som kommunen kan levere til sine brukere hvor brukeren trenger det, eller velger det, uten at brukeren har initiert dialogen selv. Det er et mål for kommunen å opptre mer proaktivt ovenfor brukerne. Proaktivitet vil kunne medføre at kommunen må endre sine arbeidsprosesser. 91

92 8 Vedlegg 8.1 Vedlegg 1: Sentrale brukerhistorier I dette kapitelet følger sentrale brukerhistorier som er kartlagt i pilotvirksomhetene i forbindelse med utarbeidelsen av første versjon av dokumentet, og som er lagt til grunn for krav som stilles til felles funksjonalitet. Innbyggere og næringsliv (inkl. frivillige organisasjoner) står sentralt i Digitalt førstevalg. Behovene til innbyggerne og næringslivet er her representert med et sett med brukerhistorier knyttet til pilotvirksomhetenes tjenesteområder. Brukerhistoriene er knyttet til den ønskede brukeropplevelsen som innbyggere og næringsliv forventer at de elektroniske tjenestene skal gi i den digitale kanalen, dvs. over internett, uavhengig av plattform (PC, smart-telefoner, nettbrett, mv.). Skatt og avgift (KEM) Prosess Søknad om betalingsavtale for skyldig skatt (personlige skattytere) Søknad om skatteattest (næringsdrivende) Søknad om utsettelse på grunn av ligningsklage (personlige skattytere) Søknad om fritak for solidaransvar (næring) Søknad om frigivelse av midler fra skattetrekkskonto (Næringsliv) Kartlagt brukerhistorie Som skatteyter skylder jeg skatt, og ønsker å søke om betalingsavtale. Jeg går på oslo.kommune.no, finner veiledning og elektronisk skjema. Jeg forventer raskt svar, gjerne i en elektronisk dialog. Jeg ønsker å kunne ettersende informasjon på en eksisterende sak. Jeg er næringsdrivende, som skal innlevere tilbud i anbudskonkurranse på tjenester, utlyst av en offentlig etat. Det kreves skatteattest og mva-attest, og jeg går på oslo.kommune.no, hvor jeg finner veiledning og søknadsskjema. Jeg forventer rask behandling, ett sted å henvende meg og svar elektronisk for å spare tid Som skatteyter har jeg klaget på ligningen, og jeg vil også søke om utsettelse med innbetaling av restskatten, inntil ligningsklagen er avgjort. Jeg går på oslo.kommune.no, finner veiledning og elektronisk skjema. Jeg forventer raskt svar, gjerne i en elektronisk dialog. Ved utleie/innleie av arbeidskraft ønsker jeg i rollen som oppdragsgiver eller oppdragstaker å søke om Kemnerens godkjennelse av avtale mellom partene om at ansvaret for at pliktene og ansvaret etter skattebetalingslovens 4-1 (2) kun skal utføres av én av partene. Jeg går inn på oslo.kommune.no, finner veiledning og elektronisk skjema, og gir informasjon og laster opp dokumentasjon i form av avtale og revisorbekreftelse. Jeg forventer raskt svar i elektronisk form. Som arbeidsgiver har jeg betalt ut skattetrekk fra feil konto, eller gjort feilinnbetalinger til skattetrekkskontoen, som gjør at jeg har behov for å få frigitt midler fra skattetrekkskontoen. Jeg går på oslo.kommune.no, finner veiledning og elektronisk skjema, og søker. Jeg forventer raskt svar elektronisk Ivaretas av felles funksjonelle krav - K1: K1.1, K1.2, K1.3, K1.5, K1.9 - K3: K3.1, K3.2, K3.5 - K4: K4.1, K4.2, - K5: K5.1, K5.2, K5.3 - K6: K6.1, K6.4 - K1: K1.1, K1.2, K1.3, K1.5, K1.9 - K3: K3.1, K3.2, K3.5 - K4: K4.1, K4.2, - K5: K5.1, K5.2, K5.3 - K6: K6.1, K6.4 - K1: K1.1, K1.2, K1.3, K1.5, K1.9 - K3: K3.1, K3.2, K3.5 - K4: K4.1, K4.2, - K5: K5.1, K5.2, K5.3 - K6: K6.1, K6.4 - K1: K1.1, K1.2, K1.3, K1.5, K1.9 - K3: K3.1, K3.2, K3.5 - K4: K4.1, K4.2, - K5: K5.1, K5.2, K5.3 - K6: K6.1, K6.4 - K1: K1.1, K1.2, K1.3, K1.5, K1.9 - K3: K3.1, K3.2, K3.5 - K4: K4.1, K4.2, - K5: K5.1, K5.2, K5.3 - K6: K6.1, K6.4 92

93 Plan- og byggesaker (PBE) 45 Prosess Offentlig innsyn Offentlig ettersyn Anmodning om forhåndskonferanse Kartlagt brukerhistorie Jeg vil følge med og si min mening om en sak (innbygger og næring) Som innbygger ønsker jeg å følge med på plan- og byggesaker i mitt område og vil abonnere på informasjon om nye saker/dokumenter. Jeg mottar varsel fra kommunens varselstjeneste og går inn på saken, hvor alle dokumenter ligger elektronisk tilgjengelig. For å få gitt merknad, må jeg logge meg på og får opp et preutfyllt skjema med navn, adresse, saksbenevnelse mv., hvor jeg får gitt min uttalelse til saken. Jeg mottar varsel om offentlig ettersyn (innbygger og næring). Som nabo/berørt skal jeg varsles om offentlig ettersyn. Jeg mottar varsel fra SvarUT, og går inn på inn på saken hvor alle dokumenter ligger elektronisk tilgjengelig. For å få gitt merknad, får jeg opp et preutfylt skjema med navn, adresse, saksbenevnelse mv., hvor jeg får gitt min uttalelse til saken (Jeg er allerede pålogget hvis jeg gjør det direkte fra lenken, ellers må jeg logge meg på.) Jeg har behov for avklaringer angående en byggesak (innbygger og næring). Som tiltakshaver eller søker ønsker jeg å anmode om forhåndskonferanse i forkant av søknad om byggetiltak. Jeg går på kommunens nettside og finner informasjon om byggesaksområdet. Jeg finner ut at jeg ønsker en forhåndskonferanse, finner aktuelt elektronisk skjema og logger meg på. I skjema får jeg veiledning til utfylling av skjema og krav til dokumentasjon. Jeg får også tilgang til kalender med aktuelle tidspunkt for forhåndskonferansen. Når jeg sender skjema inn, får jeg bekreftelse på at det er mottatt og beskjed om videre saksgang. Jeg får eget brev med bekreftelse av timeavtale og evt. anmodning om ytterligere dokumentasjon. Ivaretas av felles funksjonelle krav - K1: K1.1, K1.2, K1.3, K1.4, K1.5, K1.9 - K3: K3.1, K3.2, K3.3, K3.5 - K4: K4.1, K4.2, - K6: K6.1, K6.2, K6.3 - K7: K7.1, K7.2, - - K1: K1.1, K1.2, K1.3, K1.4, K1.5, K1.9 - K3: K3.1, K3.2, K3.3, K3.5 - K4: K4.1, K4.2, - K5: K5.1, K5.2, - K6: K6.1, K6.2, K6.3, K6.4 - K1: K1.1, K1.2, K1.3, K1.4, K1.5, K1.9 - K3: K3.1, K3.2, K3.5, K3.7 - K4: K4.1, K4.2, - K5: K5.1, K5.3 - K6: K Plan- og byggesaksområdet er komplekst, og har mange proseser. Brukerhistoriene fra Plan- og bygningsetaten er knyttet til representative prosesser. 93

94 Barnehage (KOU) Prosess Søknad om barnehageplass - hovedopptaket 46 Kartlagt brukerhistorie Som forelder til et barn under skolepliktig alder vil jeg søke om barnehageplass i årets hovedopptak. Jeg går på kommunens nettside, finner orientering om kommunale og private barnehageplasser osv og elektronisk søknadsskjema. Jeg søker elektronisk, ønsker proaktiv oppdatering av status, og å finne mine saker med status på «Min side. Jeg forventer at videre kommunikasjon skal skje elektronisk, på hensiktsmessige kanaler, herunder melding om opptak og akseptanse av plass Ivaretas av felles funksjonelle krav - K1: K1.1, K1.2, K1.3, K1.4, K1.5, K1.9 - K3: K3.1, K3.2, K3.3, K3.5 - K4: K4.1, K4.2, - K5: K5.1, K5.2, K5.3 - K6: K 6.1, K6.2, K6.4 - K7: K7.1 Skjenkeområdet (NAE) Prosess Kartlagt brukerhistorie Ivaretas av felles funksjonelle krav Søknad om serverings, salgs og skjenkebevilling Søknad om enkeltanledning/ engangsbevilling Som næringsdrivende ønsker jeg å starte opp et serveringssted med skjenkebevilling. Slik bevilling er kritisk for driften, og jeg ønsker å samarbeide med myndighetene om å få avklart saken snarest. Jeg finner orientering på oslo.kommune.no og søknadsskjema, og i forbindelse med at jeg inngir søknad med vedlegg elektronisk via nettet, trenger jeg å vite om søknaden er korrekt utfylt og om alle vedleggene som forventes er mottatt hos næringsetaten. Jeg vet også at søknaden forventes å ta 3 måneder etter at alle opplysninger og vedlegg er mottatt. Avvik fra dette er viktig for meg å vite, i forhold til at feil planlegging er dyrt. God statusrapportering er derfor viktig. Som privatperson eller næringsdrivende ønsker jeg skjenkebevilling for en bestemt anledning. Jeg finner orientering på oslo.kommune.no, hvor jeg finner veiledning og søknadsskjema. Jeg forventer rask behandling, ett sted å henvende meg og svar elektronisk for å spare tid. - K1: K1.1, K1.2, K1.3, K1.4, K1.5, K1.9 - K2: K2.1, K2.2, - K3: K3.1, K3.2, K3.3, K3.5 - K4: K4.1, K4.2, - K5: K5.1, K5.2, K5.3 - K6: K6.1, K6.2, K6.4 - K1: K1.1, K1.2, K1.3, K1.4, K1.5, K1.9 - K2: K2.1, K2.2, - K3: K3.1, K3.2, K3.3, K3.5 - K4: K4.1, K4.2, - K5: K5.1, K5.2, K5.3 - K6: K6.1, K6.2, K Denne brukerhistorien ble innfridd med KOU pilot høsten 2013 for barnehageopptak, og medfører en omfattende digital modenhetsutvikling som krever store tilpasninger eksternt (foresatte) og internt (saksbehandlere). Dette erfaringsgrunnlaget benyttes videre som innspill i programmet og til etablering av nytt fagsystem for barnehager. Endringer i søknadsportalens Min side krever pålogging gjennom MinID. 94

95 8.2 Vedlegg 2: Identifiserte krav I dette kapitelet følger sentrale krav i virksomhetene som er kartlagt i pilotvirksomhetene i forbindelse med utarbeidelsen av første versjon av dokumentet, og som er lagt til grunn for krav som stilles til felles funksjonalitet. Skatt og avgift (KEM) Prosesser Søknad om betalingsavtale for skyldig skatt (personlige skattytere) Søknad om skatteattest (næringsdrivende) Søknad om utsettelse på grunn av ligningsklage (personlige skattytere) Søknad om fritak for solidaransvar (næring) Søknad om frigivelse av midler fra skattetrekkskonto (Næringsliv) Søknad om enkeltanledning/ engangsbevilling Identifiserte krav i virksomheten Ivaretas av felles funksjonelle krav Sikker identifisering av bruker (nivå 3) K4: K4.3 Preutfylling av bruker- og saksinformasjon fra fellesregistre i elektroniske skjema K1: K1.9 Sikker opplasting og håndtering av vedlegg i skjema K1: K1.5 (innsendte elektroniske dokumenter). Ettersending av informasjon på eksisterende sak. K1: K1.6 Automatisert flyt av saksinformasjon fra K1: K1.7 brukerdialogen (skjema) til journal/arkivsystem og fordeling til rett adressat Automatisk opprettelse av saker i journal/arkivsystem K1: K1.8 (integrasjon mellom skjemaløsning og journal- /arkivsystem) Automatiserte og sikre digitale forsendelser til K5: K5.1 brukerne Varsel til bruker (næring) om at svar er tilgjengelig (i K3: K3.4 Altinn) Kopi av svarutsendelse til annen aktør (for eksempel K1: K1.7 NAE vedr skjenkebevillingssaker) Videreformidling av søknad til annen aktør (Skatt øst) vedrørende mva-attest K1: K1.7 Plan- og byggesaker (PBE) Prosesser Offentlig innsyn Offentlig ettersyn Anmodning om forhåndskonferanse Identifiserte krav i virksomheten Ivaretas av felles funksjonelle krav Veiledning på nett for de elektroniske tjenestene som K3: K3.2 er tilpasset brukeren Innsyn i saker og planer (saksinnsyn, planinnsyn) K7: K7.3 Abonnement på og varsel av - nye og/eller K6: K6.6 endrede saker for berørte brukere Preutfylling av saks- og kontaktinformasjon fra K1: K1.9 fellesregistre i elektroniske skjema Automatisk opprettelse av sak i journal/arkivsystem K1: K1.8 (integrasjon mellom skjemaløsning og journal- /arkivsystem) Sikker håndtering av vedlegg i skjema (innsendte K1: K1.5 elektroniske dokumenter) Automatiserte og sikre digitale forsendelser K5: K5.1 Sikker identifisering av bruker (nivå 3) K4: K4.3 95

96 Barnehage (KOU) Prosesser Søknad om barnehageplass - hovedopptaket Identifiserte krav i virksomheten Ivaretas av felles funksjonelle krav Abonnement på og varsel av endringer i sak K6: K6.6 Interaktiv veiledning på nett om status og informasjon K3: K3.2 i saker og søkeprosessen Sikker identifisering av bruker (nivå 3 og 4) K4: K4.3 Sikker opplasting og håndtering av vedlegg K1: K1.5 Preutfylling av bruker- og saksinformasjon fra K1: K1.9 fellesregistre i elektroniske skjema/dialog Oversikt for bruker over status mv. og saker på nett K6: K6.5 Skjema, dokumenter Status på sak (Min side og proaktiv oppdatering) K6: K6.5 Skjenkeområdet (NAE) Prosesser Søknad om serverings, salgs og skjenkebevilling Søknad om enkeltanledning/ engangsbevilling Identifiserte krav i virksomheten Ivaretas av felles funksjonelle krav Sikker identifisering av bruker (nivå 3 og 4) K4: K4.3 Interaktiv veiledning på nett om regelverket, K4: K3.2 søkeprosessen, elektronisk skjema med veiledning Sikker opplasting og håndtering av vedlegg K1: K1.5 On-line betaling av gebyr for tjenesten samtidig som K3: K3.10 søknad leveres Preutfylling av saks- og brukerinformasjon fra K1: 1.9 fellesregistres. Presentere statusinformasjon i saker for K3: K3.2 næringslivsbrukere Abonnement på og varsel av endringer i saker K6: K6.6 Rapportering på fremdrift ut ifra normalt saksforløp K6: K6.5 Mulighet for elektronisk dialog i avklaringsfasen, forut K3: K3.6 for saksbehandling 8.3 Vedlegg 3: Tilnærming og metode for utarbeidelse «Helhetlig design for felles funksjonalitet» versjon 1.0 Det lå en grundig prosess bak utarbeidelsen av første versjon av «Helhetlig design for felles funksjonalitet», som det er relevant å kjenne til. Tilnærming og metode var dokumentert i et eget kapittel (1.7). Nedenfor er dette kapitlet gjengitt i sin helhet. Dette arbeidet har vært drevet frem av programmets designgruppe, som består av representanter for pilotvirksomhetene og et kjerneteam (arbeidsutvalg). Kjerneteamet har hatt ansvaret for å produsere dokumentet basert på felles workshops og innspill fra hele designgruppen. Kjerneteamet er utnevnt med tanke på bred kompetanse og erfaring fra Utviklings- og kompetanseetaten (UKE), Byrådslederens kontor (BLK) og programmet. Øvrige deltakere i designgruppen har fått presentert arbeidet i workshops, og bidratt med innspill, kommentarer og kvalitetssikring i høringsversjoner av dokumentet. I tillegg har det vært gjennomført flere bilaterale møter mellom representanter fra kjerneteamet og øvrige deltakere i designgruppen for å avklare faglige forhold. Dokumentet besluttes i linjen. Medlemmer av designgruppens kjerneteam: 96

97 Trine Lind, Byrådsavdeling for finans (FIN), prosjektleder Per Kjetil Grotnes, Utviklings- og kompetanseetaten (UKE), kjernegruppen John Steen Nielsen, Utviklings- og kompetanseetaten (UKE), kjernegruppen (sluttet i kommunen juni 2013) Shekar Chawla, Utviklings- og kompetanseetaten (UKE), kjernegruppen Maria Therese Sanna, Utviklings- og kompetanseetaten (UKE), kjernegruppen Jon Sundby, Byrådslederens kontor (BLK), kjernegruppen Jan Henrik Gundelsby, Utviklings- og kompetanseetaten (UKE), kjernegruppen Sven Erik Johansson, Byrådsavdeling for finans (FIN), kjernegruppen Eivind Skjelvik, Byrådsavdeling for finans (FIN), kjernegruppen Carl Jacob Rustad, Byrådsavdeling for finans (FIN), kjernegruppen Tormod Utsogn, Plan- og bygningsetaten (PBE), kjernegruppen fra august 2013 Representanter fra pilotvirksomhetene: Cathrin Sundvall, representerer Næringsetaten (NAE) Zubi Ahsan Ullah, representerer Næringsetaten (NAE) Torbjørn Moen, representerer Oslo kemnerkontor (KEM) Kari Opheim, representerer Plan- og bygningsetaten (PBE) Anne Lund, Plan- og bygningsetaten (PBE) Per Johan Smestad, Plan- og bygningsetaten (PBE) Øystein Engeskar, Plan- og bygningsetaten (PBE) Ingar Brauti, representerer Byrådsavdeling for kunnskap og utdanning (KOU) Tore Somdal-Åmodt, representerer programmet i Byrådsavdeling for finans (FIN) For å utarbeide et helhetlig design for felles funksjonalitet, var det nødvendig å fremskaffe et kunnskapsgrunnlag om brukernes og pilotvirksomhetenes behov og krav knyttet til elektroniske tjenester, som ble sammenholdt med de strategiske valg og prinsipper som er fastlagt i dokumentet Overordnet design Visjon, strategi og prinsipper for elektroniske tjenester. Behov og kraver knyttet til arbeidsprosessene omkring tjenesteleveransene som skal piloteres, og disse ble derfor kartlagt Prosesskartlegging Prosesskartleggingen var overordnet inndelt i 3 faser: Kartlegging av nåsituasjon, «as-is» Beskrivelse av ønsket situasjon, «to-be» Analyse av endringsbehov Figur 29 Prosesskartlegging for helhetlig design Nåsituasjonen, as-is Prosesskartlegging er en metodisk tilnærming til virksomhetenes tjenesteleveranser, for å avdekke: Detaljer om hvilke aktiviteter som prosessen består av, som en beskrivelse av nåsituasjonen, as is Oversikt over It-løsninger som understøtter prosessen (fagsystem, journal/arkivsystem, skjematjenester, integrasjoner, informasjonskilder mv) Aktører som deltar i prosessen, med hva, på hvilket trinn 97

98 Informasjonsbehov Kommunikasjon med brukerne av tjenesten Data- og informasjonsflyt, herunder avdekke hvor dataflyten brytes av manuelle operasjoner Hvor kontrollflyten (forretningslogikken) ligger Prosessene ble beskrevet med en tilpasset BPM-notasjon, som er en vanlig brukt og hensiktsmessig måte å dokumentere prosesser på. Et eksempel på en generisk prosess er lagt inn senere i dette kapittel. Eksemplet viser aktører, involverte systemer og felleskomponenter, dataflyt og brudd på den, og kommunikasjon med bruker og andre aktører. Prosessbeskrivelsene omfattet både saksbehandlingen og kommunikasjonen med brukerne. Dokumentasjonen har vært benyttet til å utlede et sett med brukerhistorier og behov hos pilotvirksomhetene, se kapittel Ønsket situasjon, to-be Med bakgrunn i innhentet informasjon og virksomhetens mål- og strategier, utformes ønsket prosess for fremtidig løsning, hvor behov, krav og ønskes ivaretatt. Den enkelte virksomhet har vært førende med hensyn til behov, krav og ønsket løsning for fremtiden Analyse Med bakgrunn i kartleggingen av as-is og to-be prosessene analyseres informasjonen, for å få frem: Gapet mellom nåsituasjonen ( as-is ) og ønsket situasjon ( to-be ). Behov for tiltak opp imot virksomhetenes mål for saksbehandlingstid og kvalitet Grad av automatisering, bruk av teknologi, herunder infrastruktur og fagsystemer samt forhold til regelverket på de ulike tjenesteområdene mv Konsekvenser for drift (krav til oppetider på involverte systemer, svartider og stabilitet) Nødvendig informasjonsgrunnlag for å kunne behandle saken Behov for integrasjoner og håndtering av grensesnitt og avhengigheter mellom ulike komponenter, fagsystemer og registre Gjennomføring av kartlegging Forut for oppstart av designarbeidet, ble det kartlagt arbeidsprosesser hos pilotvirksomhetene Planog bygningsetaten (PBE), Byrådsavdeling for kunnskap og utdanning (KOU) og Helseetaten (HEL), Kemneren (KEM), og Næringsetaten (NAE). 98

99 Et eksempel på hvordan arbeidsprosessene ble kartlagt følger under: Figur 30 Et generisk eksempel på hvordan prosessdiagram er brukt for å dokumentere en saksbehandlingsprosess («to-be») Figuren over viser hvordan prosesskart er blitt brukt til å dokumentere. Kolonnen til venstre i prosesskartet angir aktører (innbygger/næringsliv, virksomhet, andre virksomheter), samt involverte interne og eksterne IKT-systemer iht. kommunens egne begrepsdefinisjoner 47. De ulike stegene i prosessen er angitt som aktiviteter hos den aktøren som utfører aktiviteten. Input og output til aktiviteten er angitt med piler. 47 Jf S5, Kommunens IKT-reglement 99

100 Eksempelprosessen viser både behov for endringer og potensielle gevinstområder for funksjonalitet: 1. Med felles kontaktregister og bruk av DSF (folkeregisteret) tilrettelegges det for elektronisk kommunikasjon, og kontrollert bruk av adresseinformasjon. 2. Varsel av status til bruker skal kunne skje proaktivt, enten det gis kvittering for mottatt søknad, eller senere endring av status ved progresjon i saksbehandlingsprosessen. 3. Lagring av data som PDF-dokument uten strukturert lagring av data i fagsystemet gir brudd i dataflyten, og betinger manuell registrering i fagsystemet. 4. For å avklare forhold under veis, skjer det kommunikasjon med brukeren på forskjellige kanaler. 5. Det er avdekket behov for digital samhandling mellom kommunens virksomheter, andre virksomheter og statlige etater. 6. Det er avdekket behov for at brukeren skal motta - og varsles om - svar på en digital og sikker måte Utarbeidelse av løsningskonseptet Løsningskonseptet skal vise hvordan behov og krav til felles funksjonalitet som det redegjøres for vil bli innfridd av nytt helhetlig design for felles funksjonalitet. Kravene til innbyggere/næringsliv og virksomhetene er kartlagt og analysert med utgangspunkt i en felles brukerreise beskrevet i kapittel 8 sammen med konsernet Oslo kommunes behov beskrevet i kapittel 2. Løsningsbeskrivelsen knyttet til de enkelte fellesfunksjonelle komponentene blir beskrevet i kapittel 5, og er basert behovskartleggingen i kapittel 2, målsettinger i kapittel 3 og overordnede løsningskrav i kapittel 4. Figuren nedenfor illustrerer arbeidet fra mål og behov til analyse og løsningskonsept i dokumentet: Figur 31 Utarbeidelse av helhetlig design for fellesfunksjonalitet Prosesskartleggingen har vært sentral for å forstå virksomhetenes tjenesteprosesser, og brukerhistoriene har gitt grunnlaget for å forstå brukernes behov (innbyggere og næringsliv). Komponentene i løsningskonseptet er beskrevet i kapittel 5 med følgende egenskaper: 100