alternativanalyse standarder for publisering av ... · 6.3.2 tilgjengelighet til tjenester fra...
TRANSCRIPT
Alternativanalyse – Standarder for publisering av nettleserbaserte tjenester
Utkast versjon 0-8, 13.04.2015
INNHOLD
Sammendrag .................................................................................................3 1
Innledning .....................................................................................................7 2
Bakgrunn ...............................................................................................7 2.1
Kort om standardiseringsarbeidet ..........................................................8 2.2
Om nettleserbaserte tjenester .................................................................9 2.3
Metode .................................................................................................10 2.4
Dagens situasjon og behov for standarder for nettleserbaserte tjenester ...11 3
Dagens situasjon ..................................................................................12 3.1
Normative behov .................................................................................15 3.2
3.2.1 Digitaliseringsprogrammet ...........................................................15
3.2.2 Universell utforming og digitalt førstevalg ..................................16
3.2.3 Uttalte målsetninger fra regjeringen .............................................16
3.2.4 Vurdering av normative behov .....................................................17
Interessenters behov på området..........................................................17 3.3
3.3.1 Innbyggere og næringsliv .............................................................18
3.3.2 Offentlige virksomheter med underleverandører .........................18
3.3.3 Tjenesteutvikling – funksjonelle krav ..........................................19
3.3.4 Ulike typer brukerutstyr ...............................................................21
3.3.5 Vurdering av interessentgruppenes behov ...................................22
Oppsummering av behovsanalysen .....................................................22 3.4
Mål for tiltaket ............................................................................................23 4
Mulighetsrommet .......................................................................................24 5
Null+-alternativet, Valgfritt PDF eller HTML på nye tjenester ..........24 5.1
Alternativ 1. Obligatorisk HTML på nye tjenester ..............................25 5.2
Alternativ 2. Obligatorisk HTML på nye tjenester og på eksisterende 5.3
tjenester innen 4 år .........................................................................................25
Alternativ 3. Obligatorisk HTML for nye tjenester og eksisterende 5.4
tjenester innen 2 år .........................................................................................26
Den samfunnsøkonomiske analysen ..........................................................26 6
Forutsetninger for analysen .................................................................26 6.1
6.1.1 Metode ..........................................................................................27
6.1.2 Levetid ..........................................................................................28
6.1.3 Om utbredelse av HTML .............................................................28
6.1.4 Volum, beregning av antall nettleserbaserte tjenester ..................29
Side 2
Prissatte effekter ..................................................................................30 6.2
6.2.1 Kostnadskomponenter ..................................................................30
6.2.2 Kompetanse ..................................................................................30
6.2.3 Kostnader ved utvikling av nye tjenester .....................................31
6.2.4 Overflytting av tjenester fra PDF til HTML ................................31
6.2.5 Driftskostnader .............................................................................33
6.2.6 Prosjektkostnader .........................................................................34
6.2.7 Vurdering av realopsjoner ............................................................34
6.2.8 Sammenstilling av prissatte effekter (kostnader) .........................35
Ikke-prissatte effekter ..........................................................................35 6.3
6.3.1 Utfasing av proprietære og/eller uegnede format .........................36
6.3.2 Tilgjengelighet til tjenester fra brukerutstyr .................................37
6.3.3 Tilrettelegging for universell utforming .......................................38
6.3.4 Tilrettelegging for tjenesteutvikling .............................................38
6.3.5 Informasjonssikkerhet ..................................................................39
6.3.6 Oppsummering ikke prissatte effekter .........................................40
OPPSUMMERING AV PRISSATTE OG IKKE-PRISSATTE 6.4
EFFEKTER ....................................................................................................40
ANBEFALING ..........................................................................................41 7
Alternativene .......................................................................................41 7.1
Drøfting ...............................................................................................42 7.2
Konklusjon...........................................................................................45 7.3
Vedlegg A – Standarders støtte for ulike funksjoner .........................................47
Side 3
SAMMENDRAG 1Dette er en alternativanalyse for å synliggjøre konsekvensene av å innføre ulike
krav til bruk av standarder for publisering av nettleserbaserte tjenester i
offentlig sektor.
Regjeringens mål om et enklere Norge for folk flest, baserer seg blant annet på
kostnadseffektive og brukervennlige tjenester. Det krever at offentlige
virksomheter samarbeider, lager arbeidsrutiner og IT-løsninger som kan
samhandle seg i mellom og med brukerne. Elektronisk samhandling internt i en
offentlig virksomhet, mellom offentlig virksomheter eller med innbyggere og
næringsliv, krever elektroniske løsninger som «snakker samme språk», altså
forstår hverandre og kan utveksle data. En forutsetning for å kunne samhandle i
et nettverk satt sammen av ulike IT-løsninger, er at alle følger et felles sett av
organisatoriske, semantiske og tekniske standarder.
Private virksomheter går konkurs hvis de ikke følger med den teknologiske
utviklingen. Offentlige virksomheter er ikke utsatt for samme press, og har blitt
hengende noe etter, selv om det finnes noen hederlige unntak. Mange offentlige
virksomheter har blitt kritisert i media for å levere dårligere tjenester og for å
være antikvariske. Det snakkes ofte om «å sette strøm på papir», implementere
gårsdagens manuelle arbeidsrutiner direkte i elektronisk form uten å utnytte de
nye mulighetene teknologien gir.
Analysen vurderer format for publisering av nettleserbaserte tjenester. Den
vurderer ikke andre standarder i forbindelse med tjenestene, som standarder for
innsendingsformat, integrasjon med fagsystem, validering av input data,
informasjonssikkerhet og overflytting av skjema fra en produksjonsplattform til
en annen. I tillegg fokuserer analysen på publisering av nettleserbaserte
tjenester, ikke tjenester produsert for bruk på andre plattformer, som for
eksempel Iphones og Androides App-plattformer. Publiseringsformatet må
allikevel understøtte en del avgjørende funksjonalitet på de andre del-områdene.
Analysen bygger på informasjon hentet inn gjennom dokumentstudier,
intervjuer av offentlige virksomheter og deres underleverandører, samt en
arbeidsgruppe nedsatt for å gi råd til sekretariatet i utredningsarbeidet. Det har
også vært gjennomført en spørreundersøkelse blant offentlige virksomheter.
Offentlig sektor publiserer i underkant av 20 tusen nettleserbaserte tjenester på
nett i dag. Av disse er omtrent 50% på HTML, 40-45% på PDF med ulik grad
av parallell-publisering med andre format, og de resterende 5-10% er på andre
dokumentformater som ODF, DOC, DOCX, XLS og XLSX.
Mange av tjenestene som tilbys er ikke tilgjengelig på brukerutstyr som
smarttelefoner og PAD-er. Mange av tjenestene er skjema som må skrives ut og
Side 4
sendes inn på papir, e-post eller lastes opp. Informasjonen blir ofte tastet inn på
nytt i ulike systemer. Mange har feilet i å utnytte potensialet teknologien gir.
Offentlige virksomheter trenger et format for publisering av nettleserbaserte
tjenester som tilfredsstiller følgende behov:
- Sikrer at alle kan benytte offentlige tjenester uavhengig av hva slags
brukerutstyr de benytter og hvilken programvare de har på brukerutstyret.
- Sikrer at man kan videreutvikle tjenester med ny funksjonalitet som sikrer
brukervennlige og effektive tjenester. Samt mulighet til å levere
sammensatte tjenester på tvers av virksomheter og mulighet for utveksling
av informasjon mellom virksomhetene.
- Sikre at alle kan benytte offentlige tjenester uavhengig av funksjonsnivå.
Målet for å innføre tiltak er som følger:
Følgende alternativer er inkludert i den samfunnsøkonomiske analysen og
bygger på hverandre i en trappetrinnmodell:
Valgfritt krav om å benytte HTML eller PDF i nye nettleserbaserte tjenester
Obligatorisk krav til bruk av HTML i nye nettleserbaserte tjenester
Aternativ 1 pluss obligatorisk krav om å flytte eksisterende nettleserbaserte tjenester over på HTML innen 4 år
Alternativ 2 men med 2 års overgangsperiode
• Informasjon som utveksles og sendes har tilstrekkelig grad av struktur for automatisering• Tilstrekkelig informasjonssikkerhet for elektronisk innsending• Tilgjengelighet til tjenester uavhengig av funksjonsnivå, teknisk kompetanse og utstyr• Brukervennlige tjenester – helhetlig, enkelt, tydelig og intuitivt• Godt beslutningsgrunnlag - tilstrekkelig og rett informasjon(gjenbruk, validering og veiledning)
• Informasjonssikkerhet• Effektiv
saksbehandling• Brukervennlighet
• Flere og bedre digitale tjenester
• Enklere og brukervennlige tjenester
• Effektiv saksbehandling• Tilstrekkelig
informasjonssikkerhet
Drivkrefter Hovedmål Effekter
Delmål
0+-alternativet Alternativ 1 Alternativ 2 Alternativ 3
Side 5
I den samfunnsøkonomiske analysen blir de prissatte og de ikke prissatte
effektene beregnet, basert på innhentet informasjonsmateriale.
Kostnadene ble prissatt og hadde følgende kostnadselementer: - Kompetanseutvikling
- Utvikling av nye tjenester
- Overflytting av eksisterende tjenester til HTML-format
- Driftskostnader
- Prosjektkostnader
Den totale nåverdien av kostnadene ble beregnet til følgende:
Total nåverdi av kostnadene
Uten skattekostnad
Med skattekostnad
Sammenlignet mot nullalternativet (med skattekostnad)
Alternativ 0 / 0+ 141 684 139 170 020 967
Alternativ 1 138 983 802 166 780 562 3 240 405
Alternativ 2 136 565 854 163 879 025 6 141 942
Alternativ 3 134 575 854 161 490 905 8 530 062
Offentlige virksomheter vil oppleve en liten kostnad ved overflytting av
tjenester til HTML. Når overflyttingen er ferdigstilt vil de derimot kunne fase ut
utviklings- og driftsplattformen for PDF og få besparelser som er litt større enn
overflyttingskostnadene. Derfor får beregningene en positiv nåverdi som øker i
med hastigheten på innføring av HTML. Kostnadene er av en størrelsesorden
som bør kunne håndteres innenfor dagens ramme. Det er usikkerhet knyttet til
de anslag som er gjort, men en analyse viser at betydelige endringer i usikre
inputverdier ikke endrer resultatene i betydelig grad.
De ikke prissatte effektene har blitt validert iht. hvor stor effekten er i
sammenligning med null-alternativet. Beregningene er som følger:
Alternativ
0+
Alternativ
nye
tjenester
Alternativ
overgang
på 4 år
Alternativ
overgang
på 2 år
Utfasing av lukkede og
uegnede format
+ + ++ ++
Tilgjengelighet på ulikt
brukerutstyr
0 ++ +++ ++++
Tilrettelegging for
universell utforming
0 + +++ ++
Tilrettelegging for
videreutvikling av
tjenester
0 + ++++ +++
Sikkerhet 0 + +++ ++
Alternativ 2 og 3 gir best effekt fordi de dekker et størst mulig nedslagsfelt og
dermed vil ha størst effekt på overgangen til HTML. Analysen viser at den
Side 6
løsningen med lengst overgangsordning, alternativ 2, vil gi best resultater. Det
er fordi en lang overgangsordning vil gjøre at mange vil videreutvikle
tjenestene sine i det de legger om til HTML. En kortere overgangsordning vil
føre til at et større antall tjenester kun vil bli lagt over i sin opprinnelige form.
Utredningen anbefaler alternativ 2 som innebærer å gjøre HTML til en
obligatorisk forvaltningsstandard for publisering av nettleserbaserte tjenester i
offentlig sektor, med mindre det er en særlig uforholdsmessig byrde å oppfylle
den obligatoriske standarden. Da kan forvaltningsorganet unnlate helt eller
delvis å oppfylle kravet. Forvaltningsorganet skal straks melde fra til
Direktoratet for forvaltning og IKT om dette og begrunne hvorfor det unnlater å
oppfylle kravet.
I tillegg til å gjøre HTML til en obligatorisk standard anbefales det å sette
anbefalte krav om bruk av ISO 639 for deklarering av språkkoder, CSS for
formattering av nettsider og hvis virksomheten velger å gjøre bruk av
Javascript, anbefales det at man baserer seg på W3C sin versjon av Document
Object Model (DOM). Dette anses som støtte standarder til HTML og benyttes
på samme måte for publisering av dokumenter på offentlige nettsider.
I tillegg anbefales det å vurdere etablering av et kompetansesenter for utvikling
av elektroniske tjenester i offentlig sektor, selv om ikke utredningen kan
underbygge dette samfunnsøkonomisk.
Side 7
INNLEDNING 2Det varierer i hvilken grad offentlige virksomheter leverer gode elektroniske tjenester,
og i hvilken grad de greier å utnytte teknologien til å utvikle bedre prosesser for
brukerne og seg selv.
Virksomheter som har greid å utnytte de mulighetene teknologien gir har økt
kvaliteten og effektiviteten i tjenesteproduksjonen betraktelig.
Difi har utredet behovet for anbefalte eller obligatoriske krav til standarder ved
publisering av nettleserbaserte tjenester. Dette for å understøtte digitaliseringen og
samhandlingen i offentlig sektor. Utredningen konkluderte med at det bør settes et
obligatorisk krav om å benytte HTML.
Denne utredningen er en alternativanalyse for å synliggjøre konsekvensene av å
innføre ulike krav til bruk av standarder for publisering av nettleserbaserte tjenester.
Bakgrunn 2.1
I offentlig sektor har det vært krav til bruk av standarder ved publisering av
dokumenter på offentlige nettsider siden 2007. Kravet har ikke inkludert skjema-
tjenester.
I 2013 sa regjeringen gjennom Digitaliseringsrundskrivet1 at det er et mål at
forvaltningens kommunikasjon med innbyggere og næringsliv skal være nettbasert. På
kort sikt skal virksomheten som et minimum tilgjengeliggjøre for eksterne brukere alle
relevante søknader, skjemaer og rapporteringer for digital utfylling og digital
innsending. Tjenester med årlig innsendingsvolum over 5000 skjema skal
tilgjengeliggjøres innen 30.06. 2014. Tjenester med årlig innsendingsvolum mellom
3000 og 5000 skal tilgjengeliggjøres innen 30.06. 2015. I tillegg kom Forskrift om
universell utforming og satt krav til tjenester på Internett.
Disse to hendelsene førte til at Difi i 2014 prioriterte å utrede behovet for standarder
også for skjema-tjenester. Men med et litt bredere bruksområdet kalt
nettleserbaserte tjenester.
Det ble først skrevet en forprosjektrapport2. Den identifiserte ulike delområder innen
nettleserbaserte tjenester som kan standardiseres, vurderte hvilken effekt eventuell
standardisering på de ulike delområdene vil ha for brukere av offentlige tjenester og
for offentlige virksomheter selv og til slutt anbefalte i hvilke grad de ulike
delområdene burde prioriteres videre utredet for å gi grunnlag for eventuelle
anbefalte eller obligatoriske krav til bruk av standarder på delområdene.
1 Fornyings-, Administrasjons- og Kirkedepartementet (2013): Rundskriv P4-2013 Digitaliseringsrundskrivet; https://www.regjeringen.no/globalassets/upload/fad/vedlegg/ikt-politikk/digitaliseringsrundskrivet_2013.pdf
2 Difi (2014): Forprosjekt – Standarder for nettleserbaserte tjenester; http://standard.difi.no/filearchive/forprosjektrapport-standarder-for-nettleserbaserte-tjenester-v1-0.pdf
Side 8
På bakgrunn av forprosjektrapporten gikk Difi videre og utredet delområdet
standarder for publisering av nettleserbaserte tjenester3. I utredningen anbefales det
å gjøre HTML til en obligatorisk forvaltningsstandard på området.
Denne samfunnsøkonomiske konsekvensutredningen er en direkte følge av
anbefalingen om et obligatorisk krav, som krever en alternativanalyse som synliggjør
konsekvensene av de ulike alternativene i større detalj.
Kort om standardiseringsarbeidet 2.2
Offentlig sektor skal levere brukervennlige tjenester på en mest mulig
kostnadseffektiv måte. Det krever at offentlige virksomheter samarbeider, lager
arbeidsrutiner og IT-løsninger som kan samhandle seg i mellom og med brukerne.
Elektronisk samhandling internt i en offentlig virksomhet, mellom offentlig
virksomheter eller med innbyggere og næringsliv, krever elektroniske løsninger som
«snakker samme språk», altså forstår hverandre og kan utveksle data. En forutsetning
for samhandling i et nettverk satt sammen av ulike IT-løsninger, er at alle følger et
felles sett av organisatoriske, semantiske og tekniske standarder.
I mange år tok offentlige IT-prosjekter i for liten grad hensyn til åpne standarder når
de anskaffet/ utviklet IT-løsninger, og den grad det ble gjort tok de kun høyde for
egne behov. Skal man oppnå samhandling i offentlig sektor er man nødt til å finne
standarder som går utover egne ønsker og behov, og som kan være felles for alle
prosjekter. Det ble derfor vedtatt i stortingsmelding «Eit informasjonssamfunn for
alle», å lage en liste over anbefalte og obligatoriske IT-standarder i offentlig sektor,
som skulle gi felles rammer for alle offentlige IT-prosjekt.
Difi har fått i oppgave og forvalte listen over anbefalte og obligatoriske IT-standarder
som skal ligge til grunn for digitalisering og samhandling i offentlig sektor. De
obligatoriske kravene er i hovedsak nedfelt i Forskrift om IT-standarder i
forvaltningen, men også i enkelte andre sektorovergripende forskrifter. Alle kravene,
både anbefalte og obligatoriske, finnes i én samlet oversikt på http://standard.difi.no.
Det er utarbeidet en egen arbeidsmetodikk for hvordan man skal utrede og forankre
felles krav til IT-standarder i offentlig sektor. Metoden inkluderer et bredt
sammensatt Standardiseringsråd med representanter fra 17 ulike kommunale og
statlige virksomheter. Standardiseringsrådet er et rådgivende organ som skal
medvirke til at offentlig sektor tar i bruk IT-standarder på en måte som er best for
brukerne av offentlige elektroniske tjenester. Rådet sikrer at Difi i sine utredninger i
tilstrekkelig grad tar hensyn til den reelle bruken av IT i offentlige virksomheter.
3 Difi (2014): Utredning – standarder for publisering av nettleserbaserte tjenester; http://standard.difi.no/filearchive/utredning-forvaltningsstandarder-for-publisering-av-nettleserbaserte-tjenester-v1-0.pdf
Side 9
Om nettleserbaserte tjenester 2.3
Med en nettleserbasert tjeneste menes en selvbetjeningsløsning beregnet for
nettlesere på ulikt brukerutstyr, der brukeren kan rapportere inn informasjon eller
søke om ytelser fra offentlig sektor. I noen tilfeller vil tjenesten kun bestå i å bekrefte
tidligere innrapporterte data. En nettleserbasert tjeneste kan også være en kalkulator
der brukeren kan gjennomføre beregninger av f.eks. pensjon eller kostnader ved
import.
Mange slike tjenester er ofte forbundet med det som tidligere ble realisert i form av
skjema eller blanketter på papir. På nett blir det ofte realisert i form av dialogbaserte
løsninger, der brukeren blir ledet gjennom et ulikt sett av spørsmål avhengig av
brukerinformasjon og svar på spørsmål underveis, derfor har vi valgt å utvide
begrepet til å være nettleserbaserte tjenester og ikke benytte skjema begrepet som i
større grad assosieres med papirbaserte tjenester.
I forprosjektrapporten ble det identifisert en rekke delområder, som kan
standardiseres. I figur 1 er disse områdene identifisert i forbindelse med et vanlig
oppsett rundt nettleserbaserte tjenester. Begrunnelsen for hvorfor standarder for
publisering av nettleserbaserte tjenester ble prioritert kan leses i den rapporten.
Figur 1 Delområder for mulig standardisering knyttet til nettleserbaserte tjenester
På bakgrunn av forprosjektrapporten har vi i denne omgang fokusert på delområdet;
standarder for publisering av nettleserbaserte tjenester.
Side 10
En standard kan ha ulik status på ulike bruksområder. På et område kan en standard
være anbefalt, på et annet obligatorisk og på et tredje kanskje ikke nevnt i det hele
tatt. Årsaken til ulike krav kan ha med ulike funksjonelle behov fra område til område
og det kan ha med ulik utbredelse av standarder i løsninger beregnet for ulike
bruksområder. Derfor utredes alltid et spesifikt bruksområde av gangen og det settes
krav til standarder for akkurat det bruksområdet. Her har vi avgrenset oss til
bruksområdet publisering av nettleserbaserte tjenester.
Selv om de andre del-områdene skissert i figur 1 ikke er prioritert, må formatet for
publisering allikevel understøtte en del funksjonelle krav som har sitt utspring i de
andre områdene, som sikkerhet, innsending, validering, etc.
Det finnes også andre måter å gjøre tjenester tilgjengelig for ulikt brukerutstyr, for
eksempel gjennom de ulike plattformene for App-er. Slike tjenester er ikke inkludert i
denne utredningen.
Det finnes ulike typer virkemidler i offentlig sektor for å oppnå en ønsket effekt. Disse
virkemidlene er økonomiske, organisatoriske, pedagogiske, juridiske og teknologiske.
Ofte vil en kombinasjon av tiltak være nødvendig for å oppnå spesifiserte mål. Vi har i
denne sammenheng avgrenset oss fra å se nærmere på de pedagogiske,
organisatoriske og økonomiske virkemidler, og kun sett på juridiske virkemidler. Det
juridiske virkemiddelet vi her vurderer er ulike krav til standarder for publisering av
nettleserbaserte tjenester.
Det at vi avgrenser oss til et virkemiddel i denne sammenheng betyr ikke at det ikke
er behov for andre typer virkemidler. I utredningen som vurderte ulike aktuelle
standarder for publisering av nettleserbaserte tjenester kom det blant annet frem et
mulig behov for et kompetansesenter for utvikling av elektroniske tjenester. Mange
offentlige virksomheter har begrenset kompetanse på området og et sentralt
kompetansemiljø, som kan veilede på området kunne vært et mulig tiltak.
Metode 2.4
Forprosjektrapporten som identifiserte, vurderte og prioriterte mellom ulike
delområder og utredningen om hvilke standarder som er best egnet for publisering av
nettleserbaserte tjenester er basert på arbeidsmetodikken for
standardiseringsarbeidet. Videre behandling av denne rapporten er også iht. den
arbeidsmetoden. Denne spesifikke samfunnsøkonomiske analysen utføres iht.
veiledning fra Finansdepartementet og Direktoratet for økonomistyring.
I arbeidet med å innhente informasjon har Difi gjennomført dokumentstudier. Vi har
også hatt møter med flere offentlige virksomheter, som leverer elektroniske tjenester
på nett i dag. Det har også vært gjennomført en rekke møter med tilbydere av
løsninger og tjenester for nettleserbaserte tjenester. I tillegg har det vært
gjennomført flere møter i Standardiseringsrådets arbeidsgruppe for nettleserbaserte
Side 11
tjenester. Det har også blitt gjennomført en spørreundersøkelse for å bekrefte/
avkrefte de funn vi har gjort i møtene.
DAGENS SITUASJON OG BEHOV FOR STANDARDER 3FOR NETTLESERBASERTE TJENESTER
Digitalisering i virksomhetene skjer på ulike sett, og noen offentlige virksomheter har
større modenhet enn andre. Det er vanlig å beskrive digital modenhet gjennom
tjenestetrappa, og vi kan også anvende dette til å illustrere forskjellen mellom
publisering av tjenester på PDF- og HTML-format.
Figur 4 – Tjenestetrappa
Mange virksomheter har startet forsiktig når de har tatt i bruk elektroniske kanaler.
De har rekonstruert den manuelle arbeidsmetoden de benyttet tidligere i den
elektroniske verden, «satt strøm på papiret». Ved å ta i bruk elektroniske kanaler har
man derimot betydelige muligheter som kan utnyttes til å lage brukervennlige og
effektive tjenester på en helt annen måte enn tidligere. Noen få virksomheter har
utnyttet en større del av disse mulighetene og høstet betydelige gevinster.
Offentlige virksomheter benytter ulike format til å publisere elektroniske tjenester.
Noen av formatene har derimot svært begrensede muligheter. Skal virksomhetene
utvikle seg å få til en god vertikal (trinn 3) og horisontal (trinn 4) integrasjon er det
nødvendig å velge rett format. PDF har ikke tilstrekkelig funksjonalitet for å
gjennomføre trinn 3 og 4 på en tilfredsstillende måte, mens HTML kan håndtere alle
trinnene.
Side 12
Det er en utbredt oppfatning at videre digitalisering forutsetter at virksomheter
anvender HTML-formatet, og at dette er en løsning for framtiden. Virksomhetene
som i dag utarbeider nye nettbaserte tjenester velger som regel dette. Imidlertid er
det eksempler på offentlige tjenester som nylig er utviklet i PDF. Derfor har
Standardiseringsrådet gitt råd til Difi om at de bør utrede konsekvensene av å gjøre
HTML til en obligatorisk standard for publisering av nettleserbaserte tjenester.
I dette kapitlet vil vi først beskrive dagens situasjon i forhold til anvendelse av
formater for nettleserbaserte tjenester. Deretter vil vi gjennomføre en
behovsanalyse av normative behov og interessentgruppebaserte behov. Med
normative behov mener vi behov som er nedfelt i overordnede politiske
vedtatte strategier, nasjonale målsettinger og lovverk, etc. Med
interessegruppebaserte behov mener vi interessegruppers behov i forbindelse
med et problemkompleks.
Dagens situasjon 3.1
Av rapporten «Digitalt førstevalg – om status for elektroniske tjenester i staten»4
(2011) gikk det fram at 82 % av skjema tilgjengelig på virksomheters nettside var
tilgjengelig i den enkleste formen; skjema til utfylling eller nedlastning. Skjema med
elektronisk innsending hadde et mye lavere tall. Det var 36 % av de undersøkte
tjenestene som hadde mulighet for elektronisk innsending. 15 % av de undersøkte
tjenestene var ikke å finne tilgjengelig på nett i noen form. Vi kan regne med at
andelen tjenester i elektronisk form har steget etter denne undersøkelsen i 2011.
I 2012 gjorde Oslo Economics en konsekvensutredning av digitaliserte skjemaer i
staten5. I denne undersøkelsen ble det lagt til grunn at Altinn omfattet ca. 1000
statlige skjema (Economics, 2012). I tillegg ble antallet digitalisert innsendinger av
skjema i staten estimert. De antok at det i snitt var ett skjema per statlig virksomhet
og at det til sammen blir omlag 1 250 digitaliserte statlige skjemaer. Med bakgrunn i
rapporten Digitalt førstevalg – om status for elektroniske tjenester i staten kom de
fram til at det var ca. 3 500 unike statlige skjemaer. De kom videre fram til at det var i
underkant av 40 millioner skjemaer fra næringsliv og publikum som ble sendt inn til
staten (både digitalt og fysisk). Våre vurderinger er at antallet elektroniske tjenester i
staten er noe høyere i dag, enn i 2012. På bakgrunn av våre undersøkelser har vi
anslått at antallet nå har kommet opp i 4000 skjema.
I 2013 gjennomførte Difi en ny statuskartlegging6 av digitale innbyggertjenester.
Denne kartleggingen viste at det fortsatt var mange tjenester som bare var som
4 Difi (2011): Rapport 2011:2 Digitalt førstevalg – om status for elektroniske tjenester i staten; http://www.difi.no/sites/difino/files/digitalt-forstevalg-status-difi-rapport-2011-2.pdf
5 Oslo economics (2012): Rapport 11:2012 Digitalisering av skjemaer I staten; http://osloeconomics.no/wp-content/uploads/2012/12/Rapport-Digitalisering-av-skjema.pdf
6 Difi (2013): Rapport 2013:9 Digitale tjenester i staten – statuskartlegging; http://www.difi.no/sites/difino/files/digitale-tjenester-i-staten-statuskartlegging_1.pdf
Side 13
«skjema på nett», altså skjema i WORD, PDF, ODF osv. som brukeren må laste ned,
fylle ut og sende som vedlegg til e-post, laste opp på nettstedet eller skrive ut, fylle ut
og sende per brevpost. Totalt fant de 776 tjenester. Av disse var 183 av tjenestene
rettet mot innbyggere.7 Denne rapporten opererer med et betraktelig lavere antall
tjenester enn oss, det er knyttet til en strammere definisjon som blant annet krever
digital innsending via web. Rapporten peker på at kun 20% av virksomhetene har
tjenester som ikke er skjema på nett, og av disse tjenestene kommer over 50% fra et
lite knippe offentlige virksomheter som er betraktelig mer modne enn andre
virksomheter. (Rapporten er basert på en helt annen type kartlegging enn det vi har
benyttet i vår informasjonsinnhenting og har blitt brukt aktivt i kvalitetssikring av våre
tall.)
I forbindelse med denne utredningen ble det gjennomført en spørreundersøkelse
blant statlige, kommunale og fylkeskommunale virksomheter. Vi mottok 108 svar
fordelt utover ulike typer virksomheter og ulike størrelser. Blant de største
virksomhetene og fylkeskommunene, som er mindre målgrupper, gir den lave
svarprosenten større usikkerhet i tallgrunnlaget enn for de små, hvor det uansett er
et forholdsvis stort antall svar.
Resultatene av undersøkelsen viser at 85% av offentlige virksomheter har minst en
tjeneste på HTML. Men at ikke mer enn 53% av deres tjenester er på HTML.
Resterende tjenester er tilgjengeliggjort på en eller fler av følgende format; PDF, doc,
docs, odf, xls eller xlsx. Hvorav PDF, med eller uten parallellpublisering utgjør
hovedandelen på over 90%. Det er kun 3% av virksomhetene som oppgir at de ikke
publiserer elektroniske tjenester på nett i det hele tatt. Når vi ser på antall tjenester
de ulike virksomhetene rapporterer å ha, ser vi at antallet tjenester for statlige etater
bør økes til 4000. Når det gjelder små, middels, store og de 5 aller største
kommunene, så har de respektivt 20, 40, 80 og 150 tjenester i gjennomsnitt hver seg.
Fylkeskommunene har veldig stor variasjon i svarene sine, men har omtrent 50
tjenester hver seg i snitt.
70% av virksomhetene setter ut arbeidet med å lage nettleserbaserte tjenester på
HTML til underleverandører, når det gjelder nettleserbaserte tjenester på PDF er det
kun 15% som setter det ut. Det er i hovedsak større virksomheter, som velger å sitte
på kompetansen selv. Undersøkelsen viser at de fleste virksomheter som lager
nettleserbaserte tjenester selv har sentralisert ansvaret for å utvikle dem. Antall som
jobber med dette går fra 1-2 i de mindre virksomhetene, 3-6 i de mellomstore og 10-
12 personer i de virkelig store virksomhetene. Men det varierer noe, der enkelte
virksomheter velger å spre ansvaret forholdsvis bredt, mens enkelte kun har noen få
spesialister som jobber med det.
Det er en klar oppfatning både hos offentlige virksomheter og deres leverandører at
fremtiden ligger i å benytte HTML fremfor de andre formatene. Det blir derimot
7 http://www.difi.no/filearchive/digitale-tjenester-i-staten-statuskartlegging_1.pdf
Side 14
fremhevet at virksomhetene har en del gamle skjema, som blir så sjelden benyttet at
de ikke ser poenget i å konvertere tjenestene til andre format. Mange av disse
tjenestene er også under utfasing på grunn av endring i behov og regelverk. I tillegg er
det noen skjema som krever funksjonalitet som virksomhetene ikke oppfatter som
lett tilgjengelig i markedet, f.eks. doble signaturer. Vi antar at disse tjenestene til
sammen utgjør omtrent 10% av alle tjenester. Virksomhetene er opptatt av at det
kommer en avgrensning i kravet eller en unntaksordning, som gjør det mulig å fase ut
disse skjemaene sakte. Det kan derimot bli uforholdsmessig dyrt å opprettholde et
eget utviklingsmiljø og nødvendig kompetanse for å vedlikeholde et så lite antall
skjema.
Videreutvikling av arbeidsrutiner og tjenester er noe man ikke gjør så ofte i offentlig
sektor. Styringssystemet er i stor grad lagt opp til at det som fungerer bør videreføres.
Flere virksomheter har derfor uttrykt at de nettleserbaserte tjenestene som er på PDF
i dag, ikke vil bli lagt om før om svært lenge, med mindre det kommer krav til det. I
tillegg har de etablerte rutiner for mindre tekstlige oppdatering som fungerer greit og
omlegging til HTML vil medføre ønske om å videreutvikle tjenestene. Mange
virksomheter har derfor en oppfatning om at det å legge om til HTML vil være en stor
jobb.
Leverandørene til offentlige virksomheter anbefaler stort sett kundene å velge HTML
ved utvikling/ anskaffelse av nye tjenester. De har også en prismodell, som oppfordrer
kundene til å velge HTML.
Utviklingsjobben for å lage tjenester med tilsvarende funksjonalitet i PDF og HTML er
forholdsvis lik for mindre avanserte tjenester. For litt avanserte tjenester er
kostnaden knyttet til PDF større, mens for avanserte tjenester er det kun mulig å
realisere dem i HTML.
Det å legge en tjeneste over fra PDF til HTML tar med dagens løsninger et snaut
dagsverk inkludert testing (Her regner vi ikke med eventuell testing for integrasjon
mot bakenforliggende system da dette ikke handler om publiseringsformat, men
innsendingsformat). Inkludert i dagsverket er mindre forbedringer for å tilfredsstille
høyere krav til funksjonalitet i HTML løsninger. Det inkluderer ikke videreutvikling av
selve arbeidsprosessen med påfølgende justering av tjenesten. I kommunesektoren
har leverandørene utviklet ferdige standardtjenester, som knapt krever tilpasning, og
kan tas i bruk nesten umiddelbart.
Intern drift av få tjenester på HTML er noe dyrere å drifte enn få tjenester på PDF.
Dette fordi HTML tjenester krever investering i applikasjonstjenere. Har man større
volum av tjenester eller setter driften av tjenester ut til underleverandører, blir det
billigere å benytte HTML i større volum.
I dag har mange offentlige virksomheter høyere kostnader enn nødvendig, fordi de
har kompetanse og drifter løsninger på to teknologier.
Side 15
I rapporten for publisering av nettleserbaserte tjenester8 vurderte Difi behovet for å
ha tjenester tilrettelagt for brukere med lav IT-kompetanse. Antallet brukere, som har
begrenset kompetanse og evne til å ta i bruk mer avanserte tjenester er fortsatt
betydelig. Mange mener derfor at skjema fortsatt må være tilgjengelig på papirformat
(PDF). I dialogen med leverandørene til offentlige virksomheter og med
virksomhetene selv, kom det derimot frem at mange brukere heller ber om hjelp til å
gjennomføre den elektroniske tjenesten de forsøker å ta i bruk på HTML enn å skrive
ut, fylle ut og sende inn per post. I tillegg viser det seg at de som ikke greier å
håndtere de elektroniske tjenestene publisert i HTML, heller ikke greier å håndtere
tjenestene i PDF. De trenger rett og slett veiledning i selve utfyllingsprosessen. Her gir
HTML større muligheter for passiv og aktiv veiledning enn HTML. Det er slik at HTML-
løsninger kan generere PDF-skjema automatisk basert på HTML-tjenesten om
ønskelig.
Normative behov 3.2
Med normative behov menes lover og forskrifter, overordnede politiske mål, gitte
rammebetingelser etc. Disse behovene skal ha et nasjonalt perspektiv og kan bli
førende for tiltaket. På dette området er Digitaliseringsprogrammet, Diskriminerings-
og tilgjengelighetsloven og regjeringens uttalt mål viktige normgivende kilder.
3.2.1 Digitaliseringsprogrammet
Regjeringen la i april 2012 fram digitaliseringsprogrammet9. Målet var at statlig
forvaltning i størst mulig grad skulle være tilgjengelig på nett, at nettleserbaserte
tjenester skal være hovedregelen for kommunikasjon med innbyggere og næringsliv
og at digitalisering av forvaltningen skal bidra til å frigjøre ressurser og heve kvaliteten
på tjenestene.
Digitaliseringsrundskrivet10 har fulgt opp Digitaliseringsprogrammet og sier at på kort
sikt skal virksomheten som et minimum gjøre tilgjengelig for eksterne brukere alle
relevante søknader, skjemaer og rapporteringer for digital utfylling og digital
innsending. Tjenester med årlig innsendingsvolum over 5000 skjema skal ha blitt
tilgjengeliggjort innen 30.06.2014. Tjenester med årlig innsendingsvolum mellom
3000 og 5000 skal tilgjengeliggjøres innen 30.06.2015. Unntak fra disse kravene gis for
tjenester hvor digitalisering ikke lønner seg verken for bruker eller forvaltning, og for
8 Difi (2014): Utredning – standarder for publisering av nettleserbaserte tjenester; http://standard.difi.no/filearchive/utredning-forvaltningsstandarder-for-publisering-av-nettleserbaserte-tjenester-v1-0.pdf
9 Departementene (2012): På nett med innbyggerne – regjeringens digitaliseringsprogram; https://www.regjeringen.no/globalassets/upload/fad/kampanje/dan/regjeringensdigitaliseringsprogram/digit_prg.pdf
10 Kommunsal- og moderniseringsdepartementet (2014): Rundskriv H-7:14 Digitaliseringsrundskrivet; https://www.regjeringen.no/nb/dokumenter/Digitaliseringsrundskrivet/id766322/
Side 16
tjenester hvor det foreligger konkrete planer om digitalisering før 2015 innenfor
gjeldende budsjettrammer. Virksomheten må på forespørsel kunne dokumentere og
begrunne unntak fra kravene.
Digitalt førstevalg forutsetter at brukere finner tjenester tilgjengelig digitalt når de har
behov, at løsningene er brukervennlige og enkle. Et sentralt virkemiddel i målet om
digitalt førstevalg er at elle relevante søknader eller innrapporteringer er tilrettelagt
for digital utfylling og innsending, altså at tjenester i staten er digitalisert.
3.2.2 Universell utforming og digitalt førstevalg
Det er ca. 900 000 innbyggere i Norge som kan ha utfordringer med å bruke offentlige
tjenester. Dette er tall Difi har estimert etter ulike undersøkelser som måler IKT-bruk
og IKT-ferdigheter. På bakgrunn av dette ser man at det er viktig at offentlige
tjenester er tilpasset brukernes teknologiske ferdigheter, slik at flere kan bruke
tjenestene.
Diskriminerings- og tilgjengelighetsloven11 sier i §11 følgende: Nye IKT-løsninger som
underbygger virksomhetens alminnelige funksjoner, og som er hovedløsninger rettet
mot eller stillet til rådighet for allmennheten, skal være universelt utformet fra og
med 1. juli 2011, men likevel tidligst tolv måneder etter at det foreligger standarder
eller retningslinjer for innholdet i plikten. For eksisterende IKT-løsninger gjelder
plikten fra 1. januar 2021.
3.2.3 Uttalte målsetninger fra regjeringen
Regjeringen ønsker å fjerne tidstyvene i offentlig sektor. Tidstyver er unødvendig
administrasjon som gjør at mange yrkesgrupper i offentlig sektor i dag bruker mer tid
på administrasjon og mindre tid på å hjelpe dem de skal. Det kan være tungvinte
arbeidsrutiner, regler og rapporteringer som stjeler tid fra de brukerrettede
oppgavene. Manuelt arbeid kunne i mange tilfeller vært løst digitalt. Å fjerne tidstyver
i det offentlige vil kunne gi mer tid til de brukerrettede oppgavene.
Tidstyvene rammer også innbyggerne direkte. Eksempler på tidstyver er å oppgi
samme opplysninger flere ganger, måtte møte opp på et kontor for å få løst en
oppgave som kunne vært løst digitalt eller at de digitale tjenestene er vanskelig å
11 Lovdata (2013): Lov om forbud mot diskriminering på grunn av nedsatt
funksjonsevne (diskriminerings- og tilgjengelighetsloven);
https://lovdata.no/dokument/NL/lov/2013-06-21-61?q=diskriminerings
Side 17
bruke. Dårlig språk i regelverk, brev, skjema og på nettsider stjeler også tid fra
innbyggerne.12
Regjeringen ønsker en enklere hverdag for folk flest ved å gi enkeltmennesket større
frihet til å styre sitt eget liv. De vil skape mer innovasjon, større valgfrihet og et mer
variert tilbud til et mangfold av brukere. For å få til dette vil Regjeringen utnytte de
store mulighetene som ligger i den moderne informasjons- og
kommunikasjonsteknologien for å skape et enklere møte med en døgnåpen offentlig
sektor, høyere kvalitet i tjenestene, økt verdiskapning og bedre beslutninger.13
Dette krever en plattform som muliggjør videreutvikling av arbeidsprosesser med
tilhørende IT-løsninger og tjenester.
3.2.4 Vurdering av normative behov
Offentlig sektor må fornye seg selv og jobbe med kontinuerlig forbedring av
arbeidsprosesser og de understøttende løsningene, for å opprettholde gode
brukervennlige tjenester produsert på en effektiv måte. Dette er tydelig nedfelt i den
strategien og det regelverket offentlige virksomheter skal følge.
Dette er behov som styrer og strekker seg langt utenfor den problemstillingen som
behandles i denne konsekvensvurderingen. Men behov som også styrer denne delen.
Når det kommer til publisering av nettleserbaserte tjenester så krever disse
normative behovene, at man bygger en plattform for publisering av tjenester som har
bred støtte i ulikt brukerutstyr og programvare. En plattform med tilstrekkelig
funksjonalitet for å møte brukerbehov vi er pålagt å understøtte, og som tilfredsstiller
offentlige virksomheters egne behov for å bygge kostnadseffektive tjenester.
Interessenters behov på området 3.3
Det er hentet inn informasjon om hva interessentene er opptatt av. Hvilke
forretningsmessige behov de har og hvordan det gir utslag i mer konkrete behov
knyttet til praktisk implementering av nettleserbaserte tjenester. Disse behovene vil
også indirekte speile de normative behovene virksomhetene må tilfredsstille.
I denne analysen er interessegruppene:
- Innbyggere og næringsliv som brukere av offentlig tjenester
- Offentlige virksomheter med underleverandører, som tjenesteleverandører
- Nasjonale myndigheter som styrer og regulerer (håndtert under normative
behov)
12
https://www.regjeringen.no/nb/om_regjeringa/solberg/Regjeringens-satsingsomrader/Regjeringens-satsingsomrader/En-enklere-hverdag-for-folk-flest/Fjerne-tidstyver/id753126/
13 https://www.regjeringen.no/nb/om_regjeringa/solberg/Regjeringens-satsingsomrader/Regjeringens-satsingsomrader/En-enklere-hverdag-for-folk-flest/id752873/?regj_oss=10
Side 18
3.3.1 Innbyggere og næringsliv
Brukere har behov for tjenester som er brukervennlig; med enkelt språk,
intuitivt og lett brukergrensesnitt og med forståelig informasjon om plikter og
rettigheter. Det må være enkelt å få opp ytterligere veiledning, også interaktiv
kontakt bør være tilgjengelig. Tjenesten må være universelt utformet.
Tjenestene må være effektive å bruke og bør helst være satt i en helhetlig
sammenheng, slik at bruker ser alle aktuelle tjenester for den situasjonen
brukeren er i.
Brukeren ønsker ikke å måtte gi fra seg mer informasjon enn nødvendig, og
informasjon offentlig sektor allerede har bør kunne hentes inn automatisk uten å
fylles inn en gang til. Informasjonen bør helst verifiseres av brukeren, så det er
klart hvilket informasjonsgrunnlag som blir lagt til grunn.
Brukere forventer i stadig økende grad å få personlig tilpassede tjenester ut i fra
egne preferanser.
Tjenestene må fungere på alle typer brukerutstyr, slik at brukeren får tilgang til
tjenestene uavhengig av når og hvor brukeren er og hvilket brukerutstyr som er
tilgjengelig. Tjenesten må også fungere på hjelpemidler for brukere med
spesielle behov.
Offentlig sektor er en tjenesteyter og må oppføre seg som det.
3.3.2 Offentlige virksomheter med underleverandører
Offentlige virksomheter har behov for å kunne lage brukervennlige og gode
tjenester, slik at flest mulige brukere velger en løsning som i størst mulig grad
er automatisert.
Tjenestene må ha funksjonalitet som gjør at virksomhetene greier å tilfredsstille
normative behov, som f.eks. krav til universell utforming og
informasjonssikkerhet.
Tjenestene må ha funksjonalitet som gjør det mulig å realisere
forvaltningsoppgavene på en best mulig måte og ivareta forretningsmessige
behov.
Tjenesten skal understøtte og gjøre det lett å være offentlig ansatt. De skal
fjerne tidstyver fra arbeidet offentlige ansatte gjør og bidra til at de kan fokusere
på kjerneoppgavene.
Tjenestene må ha funksjonalitet som gjør at datakvaliteten og
beslutningsgrunnlaget blir best mulig, slik at man får færrest mulig returer på
grunn av feil og færrest mulig klager. Bruk av informasjon i ulike offentlige
virksomheter bør ses i sammenheng. Økt bruk av informasjon gir bedre kvalitet.
Det må sikres at informasjonsflyten er strukturert slik at informasjonen er
konsistent alle steder.
Sammensatte tjenester krever en intern strukturering slik at prosessene flyter
godt og ansvaret er klart fordelt. Organiseringen må være slik at det er enkelt
for kunden å forholde seg til slike tjenester.
Side 19
Tjenestene må kunne integreres mot de andre systemene i virksomheten for å få
størst mulig grad av automatisering. Det må tilrettelegges for i stor grad å kunne
behandle saker automatisk, samtidig som det må være mulig å sile ut å vise
skjønn i aktuelle saker.
Tjenestene må bygge på teknologi som gir stabil og effektiv drift.
3.3.3 Tjenesteutvikling – funksjonelle krav
Virksomhetene har sine tildelte forvaltningsoppgaver. De utføres gjennom et sett av
arbeidsprosesser og brukertjenester. Stadig ny teknologi gjør det mulig å forbedre
måten forvaltningsoppgavene løses på. Virksomhetene må hele tiden forstå sitt
faglige behov og de teknologiske mulighetene. Tenke kreativt i forhold til hvordan
man kan bedre arbeidsprosesser og tjenester, for å tilby bedre kvalitet til brukerne,
tilfredsstille normative krav og skape mer effektiv tjenesteproduksjon.
Når man kjenner det faglige behovet og ser de tekniske mulighetene oppstår det et
sett med funksjonelle krav som en ønsker støtte for i de tekniske løsningene som skal
etableres for å implementere interne arbeidsprosesser og brukertjenester.
Brukertjenester er sammensatt av flere systemer. Interne systemer hos virksomheten
som leverer tjenesten og ulike eksterne systemer hos brukerne som benytter
tjenesten. Skal funksjonaliteten fungere, må den støttes i alle aktuelle løsninger.
Dette sikres gjennom standarder for publisering av nettleserbaserte tjenester.
Behovene som er identifisert i delkapitlene over gir grunnlag for å stille opp noen
funksjonelle behov. I delkapitlene under spesifiseres de viktigste funksjonelle
behovene.
3.3.3.1 Hente strukturert informasjon internt og fra eksterne kilder
Mulighet til å hente strukturert informasjon internt og fra andre eksterne kilder vil gjøre at beslutningsgrunnlaget blir mer korrekt. Dette gjør søkeprosessen enklere og mer effektiv for brukerne ved at de slipper å fylle ut informasjon som allerede eksisterer på nytt og virksomhetene kan få allerede lagret informasjon om brukeren direkte inn i fagsystemet. I tillegg gir det muligheter for bedre personvern, ved at kun tilstrekkelig informasjon oversendes. I dag på man ofte legge ved hele selvangivelsen for å vise hva man tjener, i stedet for å bare hente inn inntekten direkte fra skatteetaten/ NAV, eller bare få et ja eller nei på om man tjener over eller under en grense som avgjør ytelser.
3.3.3.2 Validering
Validering vil gi bedre beslutningsgrunnlag og bedre datakvalitet ved at opplysningene blir kvalitetsjekket mens man gjennomfører søkeprosessen. Fyller man for eksempel ut feil fødselsnummer vil man få beskjed med en gang, og kan rette opp i feilen før man sender fra seg søknaden. Ved hjelp av validering vil opplysningene brukeren sender og opplysningene virksomhetene får inn være korrekt, og ikke gjenstand for feil som kan føre til avslag eller retur av søknad. Validering vil derfor være med på å gjøre saksgangen mer effektiv for alle parter. En slik funksjon er positiv både for brukere og tjenesteeiere.
Side 20
3.3.3.3 Hjelpetekst
Hjelpetekst er en viktig funksjon for at beslutningsgrunnlaget og datakvaliteten skal bli så god som mulig. En hjelpetekst vil kunne guide brukeren og fortelle hvilken informasjon det spørres etter. Det vil også kunne hjelpe brukeren til å finne ut hvilke rettigheter man har, og om man oppnår kriteriene for å søke. Hjelpetekst vil på mange måter erstatte en fysisk person til å hjelpe brukeren til å fylle ut en søknad, og dermed også spare betydelige ressurser i brukerstøtteapparatet.
3.3.3.4 Autentisering
Autentisering er viktig for å vite hvem som logger seg på og gjennomfører tjenesten/søkeprosessen. God autentiseringsløsning er med på å ivareta informasjonssikkerheten.
3.3.3.5 Autorisasjonsløsning
Det er viktig at man kan logge seg inn i en løsning med den rollen man har i det
aktuelle tilfellet, for eksempel revisor eller regnskapsfører. I andre tilfeller må samme
person kunne logge seg inn som privatperson. Viktig å skille mellom hvilken rolle man
har i de ulike løsningene. I noen tilfeller vil det også være en verge som må logge seg
inn i stedet for den opplysningene gjelder.
3.3.3.6 Informasjonssikkerhet
Offentlige virksomheter må ivareta både normative og forretningsmessige krav
behov for informasjonssikkerhet. Vi må sikre tilstrekkelig tilgjengelighet,
integritet og konfidensialitet i løsningene. Det gjelder særlig tilgjengelighet til
tjenester og informasjon, slik at løsningene er tilgjengelig til enhver tid. I tillegg
er det viktig at informasjonen ikke endrer seg underveis, men at integriteten
ivaretas. Det gjelder ikke bare integriteten i data, men også integriteten i selve
tjenesten. Offentlige virksomheter behandler mye informasjon som er
konfidensiell, da er det viktig å sikre seg mot uautorisert aksess.
3.3.3.7 Elektroniske signaturer
Mange av de tjenestene offentlig sektor leverer manuelt har behov for sikre en
signatur fra brukeren som gir uavviselighetsbeskyttelse. Dette må videreføres i
den elektroniske verden. Signaturer må kunne tilføres på ulikt vis, både parallelt
nøstet. I tillegg må det være mulig å signere kun ulike deler av innholdet, f.eks.
revisor som skal signere det regnskapsfører har signert, men kun deler av
innholdet.
3.3.3.8 Personlig tilpassing og spor valg
Brukere forventer i stadig større grad å få personlig tilpassede tjenester ut i fra
egne preferanser, situasjon og ut i fra hva de har tenkt å gjøre. Sporvalg er et
eksempel på slik personlig tilpasning, purringer og tilpassede tilbud på rett tid
kan være andre.
Side 21
3.3.3.9 Midlertidig lagring
En del tjenester kan kreve informasjonsinnhenting eller avklaringer med andre
enn brukeren selv, slik at de får behov for å kunne fortsette prosessen på et
senere tidspunkt. I slike tilfeller er det viktig at brukeren kan lagre og fortsette
på et senere tidspunkt.
3.3.4 Ulike typer brukerutstyr
Når offentlige virksomheter publiserer på nett, vil brukeren som leser informasjonen og bruker tjenesten, benytte ulikt brukerutstyr med ulik programvare, f.eks. nettbrett, mobil og PC. Brukerne ønsker å benytte seg av det utstyret de har tilgjengelig når de skal kommunisere med forvaltningen. Stadig flere benytter alternativer til PC, som mobiltelefon og nettbrett i sin kommunikasjon med offentlig sektor. Nav har erfaringstall, som viser at på selv avanserte tjenester best egnet for PC, så er andel brukere på smarttelefon helt oppe i 70%. Det vil derfor være et behov for en standard som støtter funksjoner som er vanlig på alle disse plattformene.
(HTML har slik funksjonalitet, mens PDF fungerer best på PC.()
Figur 3 – Beskrivelse av bruksområde
For offentlige tjenesteleverandører er tilgjengelighet viktig, og at tjenestene kommer ut til borgerne på det brukerutstyret de benytter. Ved å være tilgjengelig vil man kunne få høyere bruk av de digitale tjenestene. Det gir økte gevinster.
I HTML har man i tillegg mulighet til å benytte responsiv design som gjør at nettsidene tilpasser seg skjermstørrelsen og slik sett kan fungere bedre på ulike typer brukerutstyr.
Side 22
3.3.5 Vurdering av interessentgruppenes behov
Det er av stor interesse for alle de ulike interessentgruppene at standarden som
velges for publisering av nettleserbaserte tjenester på nett har tilstrekkelig
funksjonalitet til å støtte videreutvikling av nye innovative tjenester. Det muliggjør
brukervennlige tjenester og effektiv tjenesteproduksjon. Det er også viktig at disse
tjenestene kan fungere godt på alle typer brukerutstyr.
Oppsummering av behovsanalysen 3.4
Behovsanalysen viser at det er stor grad av felles behov og interesser mellom ulike
grupper, tjenesteleverandører og brukere. Vi kan oppsummere de identifiserte
behovene i fire punkter:
1. Tjenesteutvikling. Både normative- og interessegruppebaserte behov
adresserer nødvendigheten av kontinuerlig tjenesteutvikling for å utnytte
nyvinninger til å skape stadig mer effektive tjenester som er enkle å bruke.
2. Tjenestene er tilgjengelig på ulikt brukerutstyr. Dette er et felles behov for
virksomheter og brukere av tjenestene. Brukere av bekvemmelighetshensyn
og offentlige virksomheter for økt bruk av tjenestene.
3. Redusere antallet tidstyver. Det er et behov for stadig kvalitetssikring for å
bedre arbeidsprosesser og fjerne unødvendige tidstyver, slik at interne
saksbehandlere kan fokusere på hovedoppgaver og brukere kan få
gjennomført offentlige tjenester enkelt og raskt.
4. Offentlige tjenester er tilgjengelighet for alle. Nettbaserte tjenester skal ha
universell utforming og være tilgjengelig for personer med nedsatt
funksjonsevne. Likeledes er det behov for at personer med lav IKT-
kompetanse har et godt offentlig tjenestetilbud.
Side 23
MÅL FOR TILTAKET 4I dette kapitlet formulerer vi hovedmål og delmål for tiltaket.
I rapporten for publisering av nettleserbaserte tjenester så Difi på det overordnede
formålet med å publisere tjenester på nett, som er oppsummert i figuren nedenfor.
Figur 2 – Oversikt over drivkrefter, hovedmål, delmål og effekter
Vi skal få til en enklere hverdag for folk flest gjennom flere og bedre digitale tjenester.
Publisering av nettleserbaserte tjenester må gjøres på et format med tilstrekkelig
funksjonalitet til at tjenestene gir grunnlag for utvikling av gode og effektive
arbeidsprosesser. I tillegg må de være tilgjengelig på ulikt brukerutstyr for alle
uavhengig av funksjonsnivå og digital modenhet.
• Informasjon som utveksles og sendes har tilstrekkelig grad av struktur for automatisering• Tilstrekkelig informasjonssikkerhet for elektronisk innsending• Tilgjengelighet til tjenester uavhengig av funksjonsnivå, teknisk kompetanse og utstyr• Brukervennlige tjenester – helhetlig, enkelt, tydelig og intuitivt• Godt beslutningsgrunnlag - tilstrekkelig og rett informasjon(gjenbruk, validering og veiledning)
• Informasjonssikkerhet• Effektiv
saksbehandling• Brukervennlighet
• Flere og bedre digitale tjenester
• Enklere og brukervennlige tjenester
• Effektiv saksbehandling• Tilstrekkelig
informasjonssikkerhet
Drivkrefter Hovedmål Effekter
Delmål
Side 24
MULIGHETSROMMET 5Med bakgrunn i behovsanalysen og mål for tiltaket inneholder dette kapitlet en
beskrivelse av mulighetsrommet og alternativene som videreføres til den
samfunnsøkonomiske analysen.
Denne utredningen har begrenset seg til juridiske virkemidler i form av obligatoriske
krav om bruk av alternative standarder.
Universell utforming er et sterkt normativt krav som ikke bare er nedsatt i en strategi,
men som er lov- og forskriftsfestet. Dette behovet vil derfor veie spesielt tungt.
Det er gjennomført analyse av aktuelle alternativer i rapporten
«Forvaltningsstandarder for publisering av nettleserbaserte tjenester»14. I denne
rapporten ble ulike formater som kunne være aktuell for publisering vurdert.
Formatene som ble evaluert var HTML, PDF, ODF og OOXML. Evalueringen kom fram
til at HTML er egnet som forvaltningsstandard, PDF delvis egnet som
forvaltningsstandard, mens ODF og OOXML ikke er egent som forvaltningsstandard.
På området. Denne utredningens vedlegg A er det i tillegg beskrevet i hvilken grad
HTML og PDF støtter de ulike funksjonelle behovene identifisert over.
Alternativene som tas med videre i den samfunnsøkonomiske analysen er beskrevet
nedenfor. Alternativene er styrt av 3 ulike parameter. Første parameter handler om
hvilken standard; PDF og/eller HTML. Det andre handler om nedslagsfeltet, om kravet
skal gjelde kun nye tjenester eller også eksisterende tjenester. Den siste dimensjonen
til dreier seg om overgangsordning, dvs. hvor raskt tiltaket eventuelt innføres på
eksisterende tjenester.
I de skisserte alternativene under er det viktig å huske at denne utredningen har
avgrenset seg til å vurdere juridiske virkemidler. Selv om formatene tilrettelegger for
å kunne nå oppsatte mål, kreves det ytterligere videreutvikling for å nå disse målene.
Videreutvikling som offentlige virksomheter selv må prioritere å gjennomføre.
Null+-alternativet, Valgfritt PDF eller HTML på nye 5.1
tjenester
Dette alternativet lar virksomheten selv velge om de ønsker å benytte PDF
eller HTML ved utvikling av nye tjenester. Virksomheten kan da ut i fra
modenhet og eksisterende kompetanse velge det formatet de selv ønsker.
Dette alternativet ligger veldig nært null-alternativet, ved at de fleste
virksomheter i hovedsak bruker enten PDF eller HTML i dag.
Dette tar hensyn til behovet til virksomhetene om å utnytte eksisterende
kompetanse og rutiner. Mindre hensyn til behovet for å fungere på alle typer
14
Difi (2014): Utredning – standarder for publisering av nettleserbaserte tjenester; http://standard.difi.no/filearchive/utredning-forvaltningsstandarder-for-publisering-av-nettleserbaserte-tjenester-v1-0.pdf
Side 25
brukerutstyr og tilgjengelig funksjonalitet. På enklere tjenester, kan tilsvarende
funksjonalitet lages på begge format.
Tiltaket vil sikre at andre formater som ODF, doc, xls og OOXML ikke kan
benyttes i nye tjenester.
Alternativ 1. Obligatorisk HTML på nye tjenester 5.2
Dette alternativet krever at alle nye tjenester blir utviklet på HTML-format,
men overlater til virksomheten å vurdere om det er behov for en
utskriftsmulighet på bakgrunn av deres kjennskap til egen brukergruppe.
Dette forslaget tar hensyn til behovet om tilrettelegging for tjenesteutvikling
ved at det formatet med størst funksjonalitet blir obligatorisk. Det vil også
tilrettelegge for å lage universell utformede tjenester. Til slutt vil det støtte alle
typer brukerutstyr.
De fleste offentlige virksomheter velger HTML for utvikling av nye tjenester i
dag, men et slikt krav vil sikre at alle går i rett retning. Virksomhetene gir klart
inntrykk av at de velger å gjennomføre videreutvikling av arbeidsprosesser og
tjenesteutforming ved overgang til HTML, selv om det er like enkelt å sette
«strøm på papiret» også ved bruk av HTML.
Det er derimot et stort antall tjenester som allerede er på andre format og
dette tiltaket vil ikke bidra til å gjøre noe med disse. Det vil derfor gå lang tid
før man får en helhetlig tjenesteportefølje fra etatene som kan ses i
sammenheng. Det vil fortsatt være begrenset brukervennlighet i mange av
disse tjenestene og de vil ha begrenset støtte i brukerutstyr.
Alternativet gir retning på videreutviklingen av offentlige tjenester, men løser
bare deler av oppgaven.
Alternativ 2. Obligatorisk HTML på nye tjenester og 5.3
på eksisterende tjenester innen 4 år
Dette alternativet innebærer at HTML blir obligatorisk både for nye og eksisterende tjenester, med en overgangsordning på 4 år for de eksisterende tjenestene.
Mange offentlige virksomheter gir klare indikasjoner på at det vil ta lang tid før de flytter eksisterende tjenester over på HTML-formatet uten et sentralt krav. Det betyr at de utsetter videreutvikling av disse tjenestene langt fremover i tid. I tillegg vil tjenesteporteføljen blir mindre helhetlig og det blir vanskeligere å levere sammensatte tjenester knyttet til livssituasjoner på tvers av enkelttjenestene.
Side 26
Dette alternativet presser alle tjenester over på et format som gjør det enklere å videreutvikle tjenestene gradvis. Tjenester kan overføres direkte fra PDF til HTML uten vesentlig tjenesteutvikling med en lav kostnad, og deretter kan videreutvikling skje gradvis.
De fleste virksomheter ser det som naturlig å gjennomføre forvaltningsutvikling når en tjeneste skal legges over på HTML. En overgangsordning på 4 år gir god tid til tjenesteutvikling og det kan antas at mange tjenester vil bli betydelig forbedret allerede i overgangen. Dette skaper en høyere takt i videreutviklingen.
Alternativet gir retning i digitaliseringsarbeidet og bidrar til mer videreutvikling.
Alternativ 3. Obligatorisk HTML for nye tjenester og 5.4
eksisterende tjenester innen 2 år
Dette alternativet er som det forrige, bare med kortere overgangsperiode for eksisterende tjenester.
Mange brukere oppfatter offentlig tjenestetilbud som «steinaldersk», og mener det er et stort behov for å revidere både arbeidsprosesser og utforming av tjenester umiddelbart.
En overgang på 2 år, vil gi et enda høyere trykk enn ved 4 år, men vil også utfordre gjennomføringskapasiteten til offentlige virksomheter. For rask overgangsordning kan føre til at flere velger bare å overføre tjenestene som de er til HTML for så å videreutvikle, i stedet for å gjøre videreutviklingen umiddelbart. Det er derfor ikke sikkert at dette alternativet vil bidra vesentlig i takten på videreutviklingen, selv om det vil bidra til en raskere overgang til HTML.
En overgang til HTML gir bedre brukervennlighet og støtte i brukerutstyr, selv uten betydelig videreutvikling av tjenestene. Full utnyttelse av mulighetene det nye formatet gir vil kun komme gjennom en mer betydelig videreutvikling av tjenestene.
Alternativet gir retning i digitaliseringsarbeidet og bidrar til trykk for videreutvikling.
DEN SAMFUNNSØKONOMISKE ANALYSEN 6Hensikten med analysen av prissatte og ikke-prissatte effekter er å beregne
samfunnsøkonomisk nytte for løsningsalternativene, sammenliknet med Null-
alternativet. I tillegg skal analysen synliggjøre hvilket løsningsalternativ som har størst
samfunnsøkonomisk nytte.
Forutsetninger for analysen 6.1
I en samfunnsøkonomisk analyse skal de verdsatte nytte- og kostnadsvirkningene som
forventes i ulike fremtidige perioder, omregnes til dagens verdi. En slik omregning
Side 27
(neddiskontering) må gjøres for at virkningene på tvers av tiltakene skal bli
sammenlignbare. Dette omtales som nåverdiberegning.
En kalkulasjonsrente på 4 % er benyttet i den samfunnsøkonomiske analysen, i
henhold til rundskriv fra Finansdepartementet om samfunnsøkonomiske analyser,
R109/14.15
Det beregnes en skattekostnad av investeringskostnader og andre kontantstrømmer via
offentlige budsjetter på 20 % av netto finansieringsbehov. Finansieringsbehovet er
netto virkning på offentlige budsjetter, og er summen av lønnskostnader (inklusiv skatt
og arbeidsgiveravgift og innsatsvarer eksklusiv MVA).
I tillegg er følgende forutsetninger lagt til grunn for analysen:
Offentlig sektor består av 622 virksomheter.16
Null-alternativet utgjøres av dagens situasjon, justert for den forventede
utviklingen i analyseperioden, ved fraværet av sentrale tiltak. Det er
null-alternativet som er referansepunktet for å vurdere gevinster og
kostnader ved det enkelte løsningsalternativ.
Prisnivå for innsamlede data er januar 2015.
Alle økonomiske størrelser er gitt eks. merverdiavgift.
Det legges til grunn at prosjektoppstart er 2016. De prissatte effektene
blir neddiskontert til 2016.
I denne analysen begrenser beregningene seg til effekten av arbeidet med å
publisere elektroniske tjenester på de ulike formatene. Videreutvikling av
arbeidsprosesser og påfølgende justering av tjenester og integrasjon mot
fagsystemer er ikke inkludert i analysen. Vi har hverken tatt med kostnadene
eller gevinstene av dette.
6.1.1 Metode
Arbeidsmetodikken i prosjektet er basert på anerkjent rammeverk og metode for
gjennomføring av samfunnsøkonomiske analyser, beskrevet i
Finansdepartementets veileder for samfunnsøkonomiske analyser og DFØs
håndbok i samfunnsøkonomiske analyser.17
En viktig del av datagrunnlaget for dette prosjektet er dokumentstudium av
tidligere rapporter og erfaringer fra andre offentlige prosjekter relevant for
nettleserbaserte tjenester. Det er gjennomført et forprosjekt som har vurdert
aktuelle alternativer (Difi, 2014). Det er gjennomført prosjekter innen
meldingsutveksling i offentlig sektor. Fornyings-, administrasjons- og
kirkedepartementet har tidligere fått gjennomført en konsekvensvurdering av
digitalisering av skjemaer i staten (OsloEconomics, 2012). Data fra denne
15
Finansdepartementet (2014): Rundskriv R109/14 Prinsipper og krav ved
utarbeidelse av samfunnsøkonomiske analyser mv.;
https://www.regjeringen.no/globalassets/upload/fin/vedlegg/okstyring/rundskriv
/faste/r_109_2014.pdf 16
428 kommuner, 18 fylkeskommuner og 197 statlige virksomheter. 17
DFØ (2014): Veileder i samfunnsøkonomiske analyser; http://www.dfo.no/Documents/FOA/publikasjoner/veiledere/Veileder_i_samfunns%c3%b8konomiske_analyser_1409.pdf
Side 28
rapporten har vært et viktig innspill til å beregne antall nettleserbaserte tjenester
i statlig sektor.
For øvrig består datagrunnlaget av en spørreskjemaundersøkelse sendt til
samtlige offentlige virksomheter, gjennomført spesielt for denne analysen. Det
er 108 virksomheter som har levert svar. Svarprosenten er lav på under 20
prosent. I beregningene har vi antatt at det til en viss grad er virksomheter som
er interessert og har nettleserbaserte tjenester som har deltatt i undersøkelsen.
Det er få av de største virksomhetene som har deltatt i undersøkelsen. Dette er
til dels oppveid ved at prosjektet har gjennomført møter med store virksomheter
som Oslo kommune, NAV og Toll- og avgiftsetaten.
Det er også gjennomført flere møter med offentlige tjenesteytere og deres
leverandører. Underveis har en ekstern arbeidsgruppe blitt konsultert, bestående
av offentlige virksomheter.
6.1.2 Levetid
Med tiltakets levetid mener vi perioden som gevinster og kostnader skal beregnes for.
Utgangspunkt for fastsettelse av levetid er at den må være tilstrekkelig lang til at
analysen inkluderer alle sentrale kostnader og gevinster, også om de kommer langt
fram i tid.
Vi har lagt til grunn en levetid på 10 år for denne analysen. Dette er begrunnet med at
mange virksomheter allerede i dag har kompetanse om HTML og har innført
nettleserbaserte tjenester med HTML format. Virksomhetene er godt kjent med
formatet og dette er i dag standard hyllevare.
Om lag 90 prosent av virksomhetene som svarte på spørreundersøkelsen oppga at alle
tjenestene ville være publisert på HTML format innen 10 år. Dette gjelder også uten en
obligatorisk standard. Med bakgrunn i dette antar vi at innen 10 år har HTML i praksis
100 prosent utbredelse, og at dette også vil gjelde uten et sentralt tiltak (null-
alternativet).
6.1.3 Om utbredelse av HTML
Med bakgrunn i spørreskjemaundersøkelsen har vi lagt til grunn at 54 prosent av
nettleserbaserte tjenester vil være publisert på HTML-formatet ved oppstart av
prosjektet i 2016. Alle tjenester i Altinn er blant annet i HTML. De største
leverandørene for kommunene oppgir at de i stadig mindre grad leverer elektroniske
tjenester på PDF format. Uten et sentralt tiltak vil en stor andel av nye tjenester
utvikles i HTML format.
Det er omtrent 9 prosent av virksomhetene som oppgir at alle skjemaene aldri vil bli
konvertert til HTML formatet. Vi forstår at dette kan være skjema med få brukere eller
som ikke lenger er i særlig bruk, og at man derfor velger ikke å endre formatet til noen
skjemaer. Ut i fra det virksomhetene selv oppgir har vi antatt at ca. 5 prosent av
skjemaene ikke vil bli tatt over til HTML. Dette vil gjelde uavhengig av alternativene
og uttrykker maksimal utbredelse uavhengig tiltak.
Side 29
6.1.4 Volum, beregning av antall nettleserbaserte tjenester
Digitalisering av offentlige tjenester har pågått i flere år, og de aller fleste
offentlige virksomheter har i dag etablert nettbaserte tjenester. Mange av
tjenestene er enkle med lav funksjonalitet. Blant virksomhetene vi har snakket
med er samtlige skjema tilgjengelig digitalt, men ikke alle er tilrettelagt for
digital innsending. Spørreundersøkelsen viser at 3% av virksomhetene ikke har
publisert tjenester på nett i det hele tatt.
Som grunnlag for den samfunnsøkonomiske analysen har vi beregnet at det er
ca. 4000 unike digitale tjenester i statlig sektor. Dette tallet er et omtrentlig
anslag som bygger på:
- Altinn opplyser at det er 1269 statlige tjenester tilgjengelig på Altinn
(flertallet med lenker). Tjenestene er i hovedsak næringsrelaterte, og gir
et godt bilde av volumet mot private virksomheter.
- I tillegg til tjenestene gjennom altinn vil det være mange statlige
tjenester rettet mot innbyggere. Spørreundersøkelsen indikerer at det
kan være mellom 4000 og 5000 statlige skjema totalt, om vi legger til
grunn de virksomhetene som har svart.
Vi legger til grunn et konservativt estimat på 4000 fordi vi tror at virksomheter
med mange digitale tjenester er noe overrepresentert blant respondentene. Et
anslag på 4000 skjema i statlig sektor i 2015 underbygges av Oslo Economics
beregning i 2011, hvor antall statlige skjema ble anslått til 3472. På dette
tidspunktet var 1097 skjema tilgjengelig gjennom Altinn. 4000 gir tilsvarende
økning i det generelle antall skjema, som økningen hos Altinn.
Flest nettleserbaserte tjenester finner vi i kommunal sektor. For å beregne
antallet tjenester har vi lagt til grunn svarene i spørreundersøkelsen, hvor ca. 80
kommuner har deltatt. Med bakgrunn i dette har vi beregnet at
kommunesektoren har om lag 14 600 tjenester. Vi legger til grunn at en
gjennomsnittlig liten kommune med under 4000 innbyggere har 20 tjenester. En
mellomstor kommune mellom 4000 og 30 000 innbyggere har 40 tjenester. En
stor kommune med over 30 000 innbyggere har 80 tjenester. Mens de 5 største
kommunene er i estimert til å ha 150 tjenester. Disse estimatene samsvarer med
opplysninger vi har fått oppgitt fra underleverandører til kommunene.
Intervju med offentlige virksomheter og deres leverandører viser at
utviklingstid og kost for nye tjenester med samme funksjonalitet er omtrent lik
for PDF og HTML. Er tjenestene avanserte blir kostnaden knyttet til bruk av
PDF noe høyere og etter hvert ikke mulig på grunn av funksjonalitets-
begrensninger. Siden kostnaden knyttet til utvikling av nye tjenester vil være
omtrent tilsvarende uavhengig av alternativ, er disse tjenestene utelatt fra
volum-beregningene. Nye tjenester som ikke allerede er publisert på et
elektronisk format vil uansett ikke få følger for kostnadsberegningene.
Side 30
Prissatte effekter 6.2
Prissatte effekter er virkninger som lar seg kvantifisere. I denne analysen er det kun
kostnadene som er prissatt, da gevinster ikke har vært mulig å kvantifisere.
Analysen vil derfor synligjøre merkostnadene ved de ulike alternativene 0+, 1, 2 og 3.
Noen virksomheter vil få reduserte kostnader som følge av at lisenskostnadene til
dagens PDF-løsninger reduseres. Disse besparelsene eller økonomiske gevinstene er
inkludert under driftskostnader, og er omtalt nedenfor.
Det er forholdsvis stor usikkerhet knyttet til kostnadsestimatene, da det er for
kostnadskrevende å innhente mer presise tall enn det vi har gjort i denne utredningen.
Dette er gjennomført noen enkle usikkerhetsberegninger for å se nærmere på hvilke
følger eventuelle justeringer av estimat vil kunne gi.
6.2.1 Kostnadskomponenter
Denne analysen består av følgende kostnadskomponenter:
Kompetanse,
Utvikling,
Omlegging fra PDF eller andre formater til HTML,
Drift og
Prosjektkostnader.
Disse er omtalt i hvert sitt avsnitt nedenfor.
6.2.2 Kompetanse
De som utvikler/ videreutvikler elektroniske tjenester i en virksomhet må enten ha
kompetanse til å lage disse selv eller kjøpe denne kompetansen fra en underleverandør.
I hovedsak er dette snakk om å ha kompetanse for å utforme tjenester i PDF eller
HTML format.
Omtrent 70% av offentlige virksomheter kjøper denne kompetanse for HTML-
utvikling, og omtrent 15% kjøper denne kompetansen for PDF-utvikling, og trenger i
liten grad opplæring av interne ansatte.
Utviklingskompetanse på et format må opparbeides enten når virksomheten tar i bruk
et nytt format, eller ved naturlig utskifting av ansatte.
85% av offentlige virksomheter har allerede tjenester på begge format, og har dermed
opparbeidet kompetanse selv eller anskaffet den i markedet. Vi har antatt at naturlig
utskiftingsraten på utviklingsressurser er 5 år, og at nyansatte må kurses.
Intervjuer med offentlige virksomheter og deres underleverandører viser at en utvikler
bør jobbe heltid med utvikling av elektroniske tjenester for å være effektiv, derav også
den høye graden av kjøp i markedet.
Spørreundersøkelsen viser at de fleste har omtrent samme antall som jobber med både
HTML og PDF, med unntak av mellomstore kommuner, som har betydelig flere på
PDF. Mindre virksomheter har 2-3 utviklere som jobber med utvikling på hvert format,
mellomstore virksomheter har 6-7 utviklere, mens store virksomheter har 6-11
utviklere. For store virksomheter så har kommunene betraktelig flere som jobber med
dette enn i staten. Trolig fordi statlige etater i større grad sentraliserer slik kompetanse,
mens i større kommuner blir de ulike etatene mer autonome og har egne ressurser.
Side 31
Det er noe ulik tilnærming på de som utvikler selv. Særlig på PDF varierer det mellom
noen virksomheter som velger å sentralisere kompetansen hos et fåtall eksperter, mens
andre overlater til ulike fagmiljø å forvalte egne tjenester.
Det er en klart trend at det er de større virksomhetene som velger å sitte på
kompetansen selv.
En god del virksomheter vil måtte opprettholde en del PDF-kompetanse selv om
tjenester flyttes over på HTML, fordi kommunikasjonsfolkene trenger dette for andre
formål. Men dette antas å være andre ressurser enn de som jobber med
tjenesteutvikling.
PDF og HTML er etablerte teknologier med godt utbygd leverandørmarked og ulike
kurstilbud.
I markedet for kurs tilbyr flere leverandører opplæring både i å utvikle tjenester basert
på PDF og HTML. Disse kursene har en varighet på 1 – 2 dager. Det tilbys også noen
spesialistkurs på 5 dager. Antatt behov for opplæring er i gjennomsnitt 1,5 dager på
HTML og 2 dager på PDF. Et typisk kurs koster 3000 kroner for HTML og 7000 for
PDF. I tillegg kommer verdien av tiden som er tilbrakt på kurset.
Det antas at en virksomhet vil kunne redusere antall utviklere når de flytter alle
tjenestene over på samme format. Men det vil være behov for å øke kompetansen på
det gjenværende formatet når det andre fases ut. Antallet utviklere på det gjenværende
formatet antas å være 80% av antallet de hadde med to format.
Ut fra en totalvurdering, etter å ha drøftet kompetansebehovet med flere offentlige
virksomheter, gjort estimater og usikkerhetsberegninger, viser det seg at det ikke er
merkbare gevinster eller kostnader ved sterkere konsentrasjon om HTML. Våre
beregninger viser at sannsynligheten er like stor for at kostnadene øker som at de blir
redusert. Vi har derfor utelatt kompetanse fra analysen over prissatte effekter.
6.2.3 Kostnader ved utvikling av nye tjenester
Kostnadene knyttet til utvikling er i denne sammenheng tiden som går med til å
utforme tjenester på det valgte formatet. Arbeid med eventuell videreutvikling
av arbeidsprosesser og påfølgende endringer i tjenester er ikke tatt med, men
heller ikke gevinster av dette. Kostnader knyttet til utviklingsmiljø for de ulike
formatene er håndtert under driftskostnader.
Intervjuer av offentlige virksomheter og deres underleverandører viser at de
benytter omtrent den samme tiden til å utvikle tilsvarende tjenester på PDF og
HTML. Er tjenestene avanserte vil det ta noe mer tid å utvikle disse på PDF og
hvis de er veldig avanserte så er det ikke mulig å utvikle tjenestene i PDF.
Da utviklingstiden beregnes til å være tilsvarende på de ulike formatene, vil
valg av ulike format ikke påvirke kostnaden mellom de ulike alternativene. Vi
har derfor utelatt utvikling av nye tjenester fra analysen over prissatte effekter.
6.2.4 Overflytting av tjenester fra PDF til HTML
I snitt har offentlige virksomheter fordelt de elektroniske tjenestene sine 50/ 50
mellom HTML og andre dokumentformat som PDF, odt, doc, docx, xls og xlsx.
Kostnaden med overflytting er gitt av hvor mange tjenester som må flyttes fra
et av de andre formatene til HTML.
Side 32
Det er gjort en vurdering av utbredelsestakten på HTML avhengig av hvilket
tiltak/ alternativ som velges. Oversikten viser hvor mange tjenester som
forventes flyttes over hvert år i de ulike tilfellene. Dette gjelder kun allerede
digitaliserte tjenester.
Kostnadene vil være ulik avhengig av om man er en kommune som kjøper en
ferdig tjeneste fra en tjenesteleverandør med ferdige grunntjenester som kan tas
i bruk uten større tilpasninger, eller om det er en offentlig virksomhet som må
utforme tjenesten på nytt i HTML.
Gjennom intervjuer med kommuner og deres underleverandører har vi funnet at
omtrent 70% av kommunene velger å kjøpe tjenestene i markedet og av disse
velger 85% å kjøpe de ferdige tjenestene fremfor å utvikle egne tjenester. Når
en kommune kjøper nye tjenester vil det være en kostnad på mellom 0,5-2 timer
å gjøre tjenestene tilgjengelig for kommunen. Virksomheter vil ha ulik
innføringsstrategi. Noen vil ta en og en tjeneste over på nytt format, mens andre
vil løfte over alle på en gang. I våre beregninger legger vi til grunn at
kommuner bestiller to tjenester i snitt hver gang de kobler opp nye tjenester. I
snitt beregnes oppkoblingen per tjeneste til å ta 1 time. Ekstern timepris er
beregnet til tusen kroner eks. moms.
De resterende virksomhetene vil utvikle sine egne tjenester. Tidsforbruket med
å utforme en ny tjeneste vil variere noe avhengig av hvor avansert tjenesten er,
men gitt at tjenesten har vært implementert på et annet dokumentformat med
begrenset funksjonalitet tidligere, antas de fleste å være forholdsvis enkle.
Tiden en offentlig virksomhet velger å benytte på å videreutvikle tjenesten er i
hovedsak ikke tatt med her, heller ikke gevinstene ved å forbedre tjenesten. Det
er kun iberegnet en enkel videreutvikling fordi brukeres forventninger til
HTML-tjenester er noe høyere enn til PDF-tjenester. Forventninger som for
eksempel at poststed skal komme opp automatisk når man har fylt inn
postnummer. Kostnadene for å flytte over en tjeneste fra et av de andre
formatene til HTML er beregnet til å ta 8 timer, da er det iberegnet 2 timer til
feilretting den første tiden tjenesten er i bruk. Ekstern timepris for den 70% som
velger å kjøpe kompetanse hos leverandørene er satt til 1000,- kroner eks.
moms. Intern timepris for den 30% som velger å utvikle selv er satt til 490,-
kroner.
Ikke alle offentlige virksomheter, som ikke har kompetanse selv, har en
eksisterende avtale med en underleverandør, som kan levere en ferdig tjeneste
eller bistå med å utvikle tjenesten. Disse vil få kostnader knyttet til anskaffelser.
Dette er tatt inn under prosjektkostnader.
6.2.4.1 Utbredelsestakt
Utbredelsestakten beskriver hvor mange tjenester det antas vil bli flyttet over
fra andre format til HTML hvert år avhengig av hvilket tiltak/ alternativ som
blir vedtatt implementert.
Utbredelse er beregnet frem til 95%. Det er fordi vi har lagt til grunn at ikke alle
tjenester skal over på HTML, men at noen vil forbli på PDF til de fases ut eller
Side 33
ny teknologi blir tilgjengelig (f.eks. doble signaturer), slik at de kan flyttes over
på et senere tidspunkt.
Utbredelsestakten er beregnet ut i fra at ikke alle greier å tilfredsstille kravene
som stilles til rett dato. Det er antatt at noen starter litt på forhånd derfor blir
ferdig før kravet inntrer og at noen får noe forsinkelse i innføringsplanene sine
og derfor ikke vil overholde kravene den første tiden.
Utbredelsestakten er beregnet til å være som følger: Alternativ 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025
0 og 0+ 54 % 58 % 62 % 66 % 70 % 74 % 78 % 82 % 87 % 95 %
1 54 % 59 % 64 % 69 % 75 % 80 % 85 % 90 % 95 % 95 %
2 54 % 59 % 66 % 73 % 80 % 89 % 95 % 95 % 95 % 95 %
3 54 % 62 % 70 % 79 % 88 % 95 % 95 % 95 % 95 % 95 %
6.2.5 Driftskostnader
Kostnadene knyttet til drift er avhengig av om tjenestene kjøpes ferdig driftet
fra en underleverandør eller om de driftes selv.
Det antas at 70% av de offentlige virksomhetene kjøper tjenestene ferdig driftet
hos underleverandører. Da er prisene knyttet til årlig kostnad per tjeneste for
HTML- og PDF-tjenester. Det er for disse virksomhetene en fordel å samle seg
om HTML-tjenester, da leverandørene gir kvantumsrabatt til de som har mange
tjenester på HTML. Prisene benyttet i beregningene er basert på oppgitte priser
fra leverandører i markedet.
De 30% av offentlige virksomheter som velger å drifte tjenestene selv vil ha et
annet kostnadsbilde. Kostnadene vil være knyttet til to faktorer. Først
lisenskostnaden knyttet til utviklingsmiljøet, deretter kostnaden knyttet til drift
av applikasjonstjenere for de som drifter HTML-tjenester.
85% av virksomhetene har allerede tjenester på begge format og de som
foreløpig ikke har tjenester på begge format antas å være den type virksomhet
som kjøper i markedet, og dermed ikke får egne lisenskostnader.
Det antas at de som drifter tjenester på PDF, både trenger lisens på Adobe pro
til utviklerne inklusive Adobe Dreamweaver. De som skal utvikle på HTML
trenger en lisens for utviklingsverktøy for HTML fra en av leverandørene i
markedet. Det antas at det betales 20% vedlikehold på HTML-produktene.
Det er anslått at de som drifter HTML-tjenester vil ha to applikasjonstjenere, for
å få tilstrekkelig redundans i systemet. Har en offentlig virksomhet over 50
tjenester anslås det et økt behov til tre applikasjonstjenere. Kostnaden for kjøp
av disse serverne er tatt inn under prosjektkostnader. Det er anslått et behov for
3 timer vedlikehold på 2 applikasjonstjenere per mnd og 5 timer vedlikehold på
3 applikasjonstjenere per mnd. For de største kommunene med opp i mot 150
tjenester anslås behovet å være 10 timer vedlikehold per mnd. Det anslås ingen
kostnad for å drifte en tjeneste på PDF. Eventuelle tid gått med til å rette feil i
tjenesten er inkludert i kostnaden knyttet til å flytte tjenestene over på HTML.
Side 34
De 12% som har digitale tjenester, men foreløpig ikke har en eneste realisert på
HTML-format, antas i hovedsak å være mindre virksomheter som velger å
kjøpe slike tjenester i markedet. De virksomhetene som velger å utvikle og
drifte selv er normalt sett større virksomheter med egenkompetanse og som er
forholdsvis tidlig ute med å ta i bruk ny teknologi.
Det er utfordrende å finne en god modell for når ulike virksomheter kommer
over en terskel for når de kan kutte ut PDF, og når de kommer over en terskel
som gir høyere driftskostnad. Vi har løst dette ved at vi har distribuert
kostnadene lineært utover. Noe vi mener vil være representativt, noen kostnader
vi da komme litt for tidlig og noen vil komme litt for sent. Vi mener det vil
jevne seg ut.
6.2.6 Prosjektkostnader
Prosjektkostnadene vil være knyttet til tre elementer: - Kostnad ved å gjennomføre en anskaffelse for de som ikke allerede har
en avtale med en leverandør på området.
- Kostnad ved å gjennomføre et innføringsprosjekt.
- Kostnader for ekstra applikasjonstjenere, for de som i løpet av perioden
vil krysse et antall tjenester, som krever et økt antall tjenere.
85% av offentlige virksomheter har allerede løsninger for HTML, og det anslås
at 90% av disse har en avtale de kan gjenbruke for å hente inn ytterligere
tjenester på området. 3% har ikke tjenester i det hele tatt, og vil uavhengig av
alternativ måtte skaffe seg en løsning, og er derfor ikke tatt med i denne
beregningen. 12% har ikke HTML-tjenester i dag og må gjennomføre en
anskaffelse. Til sammen omtrent 20% av virksomhetene trenger en anskaffelse.
Tiden det tar å gjennomføre en anskaffelse vil variere fra virksomhet til
virksomhet. De fleste som ikke har avtale vil være mindre virksomheter, som
skal kjøpe standard kommunetjenester eller enkle HTML-tjenester for å erstatte
de PDF-tjenestene de har per dato. Anskaffelsen anslås å ta i snitt 100
arbeidstimer.
Tilsvarende vil mange av virksomhetene som skal gjennomføre prosjekter være
forholdsvis små og enkle. Vi anslår at prosjektene vil kreve 75 arbeidstimer.
De virksomhetene som ikke har avtale antas å skulle kjøpe i markedet. De vil få
en initial kostnad på 10000 overfor leverandøren, som ikke eksisterende kunder
vil få når de utvider antall tjenester de drifter hos leverandøren per dato.
De virksomhetene som får over 50 tjenester antas å måtte anskaffe en ekstra
applikasjonsserver. De virksomhetene som kommer helt opp i 150 tjenester
antas å måtte anskaffe 4 ekstra applikasjonstjenere.
6.2.7 Vurdering av realopsjoner
En type gevinst er knyttet til hvor fleksibel løsningen er når det gjelder å gjøre
endringer i framtiden. En fleksibel løsning gir mulighet for realopsjoner. Man kunne
tenke seg at ved å utsette beslutningen så fikk man et bedre beslutningsgrunnlag som
gav helt andre utslag.
Side 35
Når det gjelder PDF, er det tilnærmet usannsynlig at Adobe skal greie å løfte
nye løsninger, som kan utkonkurrere HTML når det gjelder å levere gode
elektroniske tjenester.
Andre mulige endringer vi kan se for oss i fremtiden, som kunne utløse helt
andre utslag er om andre teknologier tok over for nettlesere og HTML. Da er
det snakk om nye teknologier mer i retning av App-plattformene. Det er
foreløpig ingen indikasjoner på at disse plattformene skal bli standardisert og
utkonkurrere HTML, som den hovedplattformen HTML er i dag. App-er har i
utgangspunktet et annet formål, de er beregnet for oppgaver man skal gjøre ofte
og dermed trenger som egen applikasjon. Offentlige tjenester er ofte av en art,
som skal gjøres sjelden og derfor passer mindre som APP-er. Enkelte tjenester
benyttes allikevel så ofte at de kan tenkes utviklet som App-er, men da som et
tillegg til HTML. En slik utvikling vil derfor ikke medføre et annet utfall, vi
trenger fortsatt å flytte tjenestene til HTML.
6.2.8 Sammenstilling av prissatte effekter (kostnader)
Med utgangspunkt i anslagene for kostnader og utbredelse, har vi bygget en regneark-
modell som beregner kostnadseffekter i løpet av analyseperioden. Tabellen under den
totale nåverdien av kostnadene for de ulike alternativene
Total nåverdi av kostnadene
Uten skattekostnad
Med skattekostnad
Sammenlignet mot nullalternativet (med skattekostnad)
Alternativ 0 / 0+ 141 684 139 170 020 967
Alternativ 1 138 983 802 166 780 562 3 240 405
Alternativ 2 136 565 854 163 879 025 6 141 942
Alternativ 3 134 575 854 161 490 905 8 530 062
Tabellen viser at det er en liten gevinst ved å gjennomføre tiltakene. Gevinsten
er økende jo raskere overgangen til HTML er. Det er derimot usikkerhet i
tallene, men analysen viser at det ikke er betydelige kostnader knyttet til å flytte
digitale tjenester fra PDF til HTML.
Usikkerhet
Ikke-prissatte effekter 6.3
Ikke-prissatte effekter er virkninger som ikke lar seg kvantifisere. De omfatter både
fordeler og ulemper. Virkningene er vurdert i henhold til metode for å systematisere
ikke-prissatte virkninger, ofte omtalt som «pluss-minus metoden».18
I pluss-minus metoden vurderes det enkelte løsningsalternativ opp mot en rekke
kriterier. Disse kriteriene er omtalt senere i dette kapittelet. For hvert kriterium skal
løsningsalternativet vurderes i tre trinn:
1. Betydning Vurderingen baserer seg på hvorvidt effektene av løsningsalternativet
18
Finansdepartementets veileder i samfunnsøkonomiske analyser (2005) 4.5
Side 36
påvirker noe som har samfunnsmessig verdi. Skalaen som benyttes er
liten, middels eller stor.
2. Omfang
Vurderingen handler om hvor stor påvirkningskraft løsningsalternativet
antas å ha for det aktuelle området, jf. trinnet over. Skalaen som
benyttes er stort negativt omfang, middels negativt omfang, intet
omfang, middels positivt omfang og stort positivt omfang.
3. Konsekvens Dette trinnet består i å fastsette løsningsalternativets antatte konsekvens,
basert på vurderingene av betydning og omfang.19
For et gitt kriterium
vil betydningen være det samme for alle løsningsalternativene. Omfang,
og dermed konsekvens, vil variere for de ulike løsningsalternativene, pr.
kriterium. Null-alternativet brukes som referansepunkt for å fastsette
konsekvensen. Skalaen som benyttes er ni-delt og er som går fra (- - - -)
til (++++) som illustrert nedenfor.
Kriteriepoeng
+ + + + Meget stor positiv
+ + + Stor positiv
+ + Middels positiv
+ Liten positiv
0 Ubetydelig
- Liten negativ
- - Middels negativ
- - - Stor negativ
- - - - Meget stor negativ
Tabell 11: Skala for vurdering av ikke-prissatte effekter
6.3.1 Utfasing av proprietære og/eller uegnede format
Beskrivelsen av nåsituasjonen viser at de aller fleste tjenester er på HTML eller
PDF alene eller parallell-publisert med et annet format. Det er derimot enkelte
tjenester som fortsatt er publisert kun på ODF, DOC, DOCX, XLS eller XLSX.
DOC og XLS er proprietære format og krever at brukeren har tilgang på
programvare fra en spesifikk leverandør. Formatene har derimot levd så lenge
at konkurrerende programvare til stor utstrekning har lært seg å tolke de
lukkede formatene. Uansett er det ikke heldig å gjøre bruk av lukkede
proprietære format.
Rapporten «Forvaltningsstandarder for publisering av nettleserbaserte tjenester»
vurderer i hvilken grad disse standardene er egnet for publisering av
nettleserbaserte tjenester, og slår fast at ingen av dem er egnet. De har ikke den
19
Som støtte i evalueringen brukes matrise fra .. s. 241 s. 241 http://www.regjeringen.no/pages/38440617/PDFS/NOU201320130010000DDDPDFS.pdf
Side 37
nødvendige funksjonaliteten nødvendig for å lage gode tjenester, og de fungerer
heller ikke tilfredsstillende på alle typer brukerutstyr. Det er også
kompatibilitetsutfordringer mellom ulik programvare når disse standardene
benyttes.
Det å få flyttet over de tjenestene som er på disse formatene vil derfor ha en
effekt for samfunnet, for brukerne og for offentlige virksomheter.
Det er få virksomheter, som vil velge å utforme nye tjenester på disse formatene
i dag. Alternativ 0+ og 1 vil derfor ha liten effekt da de i hovedsak setter krav til
nye tjenester.
Alternativ 2 og 3 vil ha større effekt. Disse setter krav til overflytting av
eksisterende tjenester til nye format. Det er eksisterende tjenester som i
hovedsak er på disse formatene, og antallet er beskjedent.
Selv om det ikke er en stor andel av de eksisterende tjenestene som ligger ute på
disse formatene, så er det uheldig. Det vil derfor ha en god men forholdsvis
beskjeden effekt å få fjernet dem. Akternativ 0+ og 1 vil ha en svært liten
effekt. Det er derimot viktig at vi hindrer nye skjema å bli utformet på disse
formatene, så vi gir alternativene en pluss. Alternativ 2 og 3 vil ha større effekt
og får to plusser.
6.3.2 Tilgjengelighet til tjenester fra brukerutstyr
Tidligere har de fleste tjenester vært utviklet med tanke på at brukerne benytter
PC-er. Bruken av nettlesere på Pad-er og smarttelefoner øker derimot kraftig,
særlig for unge.
Det er en klar trend at et økende antall brukere benytter alternativt brukerutstyr i
stadig større grad. Dette gjelder også profesjonelle brukere, som gjerne har
behov for å få utført tjenester på farten. Det er også enkelte brukergrupper som
begynner å droppe PC-en helt til fordel for alternativt brukerutstyr.
Et konkret eksempel er NAV som har målt at opptil 70 prosent av brukerne av
en tjeneste, utviklet med tanke på PC, anvender smarttelefon. Dette til tross for
at tjenesten var forholdsvis omfattende.
Det at tjenester fungerer på alle typer brukerutstyr har en stor betydning for
både profesjonelle og private brukere. De har behov for å få tilgang til
tjenestene uavhengig av hvor de er og hva slags utstyr de har tilgjengelig.
Offentlige virksomheter har også stor nytte av at tjenestene fungerer på ulikt
brukerutstyr. Digitalisering av tjenester gir ofte mer effektiv tjenesteproduksjon
og gevinstene øker i takt med antallet brukere. Tjenester som kan nås fra flere
typer brukerutstyr vil gi økt bruk av tjenestene, og økte gevinster for
virksomhetene.
0+-alternativet vil bidra lite i forhold til å bedre tilgjengeligheten på ulikt
brukerutstyr og får dermed ingen plusser.
1-alternativet vil bidra noe, selv om alternativet kun setter krav til nye tjenester
som vil bli lagt om til HTML, og disse i stor utstrekning blir lagt til HTML
uavhengig av alternativ. Dette alternativet får to plusser.
Side 38
2-alternativet vil gi stor effekt på å fase ut formatene som fungerer dårlig på
ulikt brukerutstyr. Overgangsordningen er derimot lang. Dette alternativet får
tre plusser.
3-alternativet vil gi stor effekt på å fase ut formatene som fungerer dårlig på
ulikt brukerutstyr og gir en raskere overgang, om enn kanskje noe enklere
tjenester i starten. Dette alternativet får fire plusser.
6.3.3 Tilrettelegging for universell utforming
Universell utforming er et viktig prinsipp. Vi ønsker å gi flest mulig brukere mulighet
til å benytte de tjenestene offentlige virksomheter leverer uten ekstra hjelpemidler,
både for i størst mulig grad å likestille alle uavhengig av funksjonsevne og fordi
løsningene på denne måten som regel blir bedre for alle.
Økt bruk av teknologi både privat og på arbeid har økt kunnskapen om antall personer
med begrensede funksjonsevner på ulike områder. Grupper som blinde og svaksynte,
hørselshemmede, ordblinde og de med nedsatt kognitive evner er store. Universell
utforming er ikke bare for mindre grupper som forholdsvis enkelt kunne vært håndtert
med ekstra hjelpemidler. Flere av disse gruppene er store, og de trenger løsningene
ikke bare for underholdning, men for å fungere i samfunnet på en tilfredsstillende
måte.
PDF har vært en utfordring for flere grupper med nedsatt funksjonsevne. HTML er et
betraktelig bedre format for å lage universelt utformede tjenester som vil fungere for
alle og i tillegg enkelt kan tilpasses ulike brukergrupper med behov for spesielle
hjelpemidler.
En overgang til HTML har derfor stor betydning for de med nedsatt funksjonsevne.
0+-alternativet vil ikke gi noe ekstra her i forhold til 0-alternativet og for 0.
1-alternativer gir effekt for nye tjenester, som det kommer stadig fler av, men håndterer
ikke alle de tjenestene som allerede er ute på PDF. Dette alternativet får en pluss.
2- og 3-alternativet inkluderer eksisterende tjenester og får derfor svært god effekt.
2-alternativet har en overgangsordning på 4 år. Det gir virksomhetene bedre tid og flere
vil ha mulighet til å gjennomføre tjenesteutvikling i løpet av overgangsperioden, i
stedet for å bare flytte tjenestene direkte over på HTML. Det vil føre til at flere
virksomheter i større grad vil utnytte mulighetene til å lage gode universelt utformede
tjenester. 2-alternativet får derfor tre plusser.
3-alternativet gir litt raskere overgang til et godt format, men den korte
overgangsperioden på 2 år vil føre til at færre rekker å forbedre tjenestene og gjøre
dem universelt utformede. Alternativ 3 får derfor bare to plusser.
6.3.4 Tilrettelegging for tjenesteutvikling
«Strøm på papir» er et begrep som ofte brukes om digitaliseringsarbeid. Det begrepet
benyttes om virksomheter som gjenskaper dagens arbeidsprosesser i digital form i
stedet for å utnytte de nye mulighetene digitale løsninger gir. Dette er en praksis vi
ønsker å komme bort i fra.
Det er mulig å sette «sette strøm på papir» på både PDF- og HTML-format. HTML har
derimot mye større funksjonalitet og lar tjenesteytere i mye større grad utnytte
mulighetene i elektroniske løsninger. PDF er i utgangspunktet skapt for å fryse et
Side 39
dokument for å få rett utskrift, og er dermed mindre egnet for å utnytte mulighetene i
elektroniske løsninger.
Det å velge HTML som et obligatorisk format sikrer ikke gode digitale tjenester alene.
Bruk av HTML åpner derimot mulighetene for å drive tjenesteutvikling, som gjør det
mulig. Det viser seg at det er lettere å videreutvikle tjenester som allerede er på HTML,
særlig når kompetansen i virksomheten knyttet til HTML øker og man ser hva som er
mulig. I tillegg er det en klar oppfatning i offentlige virksomheter om at det er naturlig
å gjennomføre forvaltningsutvikling når man legger over en tjeneste på HTML-format,
så mange virksomheter vil mest sannsynlig forsøke å benytte overgangen til å
gjennomføre en god del tjenesteutvikling.
Det å gjøre HTML til et obligatorisk format for publisering av nettleserbaserte
tjenester, vil medføre en høyere takt i videreutviklingen av eksisterende tjenester. Det
er positivt, fordi slik videreutvikling fører mange gode gevinster med seg både for
brukerne og offentlig sektor. Det har derimot også en betydelig kostnadsside. I denne
analysen har vi ikke beregnet de kostnadene eller gevinstene som kommer fra slik
videreutvikling. Hvert enkelt prosjekt må selv gjøre en vurdering av om en slik
videreutvikling vil være kostnadseffektiv.
0+-alternativet vil ha ubetydelig effekt på tilrettelegging for videreutviklingen av
tjenester i offentlig sektor og får ingen plusser.
1-alternativet vil ha en god effekt, men kun for nye tjenester. Dette alternativet får en
pluss.
2- og 3-alternativene vil ha en særdeles god effekt da de også gjelder eksisterende
tjenester. Ved å ha en romslig overgangsordning i alternativ 2 vil flere virksomheter ha
kapasitet til å drive tjenesteutvikling som en del av prosessen med å flytte tjenestene
over til HTML, mens alternativ 3 har så knapp frist at mange trolig vil legge over
tjenestene uten å gjøre videreutvikling i første runde. På dette punktet får alternativ 2
fire plusser, mens alternativ 3 får tre plusser.
6.3.5 Informasjonssikkerhet
PDF har fått en økt funksjonalitet for sikkerhet, men kan allikevel ikke matche
sikkerhetsfunksjonaliteten og fleksibiliteten som ligger i HTML.
PDF blir derimot aldri benyttet i en tjeneste helt alene, den blir som regel
benyttet i sammenheng med e-post eller med HTML for nedlasting og
opplastning.
PDF har derfor gjennom sambruken med HTML nesten samme mulighet for å
bruke sikkerhet som HTML. Det er derimot få tjenester på PDF i dag som tar i
bruk sikkerhetsløsninger for integritets-, konfidensialitets- og
uavviselighetsbeskyttelse. En overgang til HTML vil åpne for videreutvikling
av tjenestene på en måte som gir bedre informasjonssikkerhet.
HTML alene kan i tillegg benyttes på en måte som gjør det mulig å sikre
mindre deler av informasjonen hver for seg, noe som kan ha stor betydning for
mulighetene i videreutviklingen av tjenester.
0+-alternativet for også her null plusser.
Alternativ 1 får en pluss for den fleksibiliteten som sikres gjennom å sikre bruk
av HTML i nye tjenester.
Side 40
Alternativ 2 får tre plusser for den fleksibiliteten som sikres gjennom å sikre
bruk av HTML på nye tjenester, og for å kreve omlegging av eksisterende
tjenester med et tidsaspekt som gir rom for videreutvikling.
Alternativ 3 får to plusser for den fleksibiliteten som sikres gjennom å sikre
bruk av HTML på nye tjenester, men får ikke mer enn en ekstra pluss for
omlegging av eksisterende tjenester, da tidsfristen er så kort at man ikke kan
regne med at de rekker å videreutvikle og sikre tjenestene på en god måte. Men
det tilrettelegges for en videreutvikling av tjenestene i neste omgang.
6.3.6 Oppsummering ikke prissatte effekter
I tabellen under kan man se de ulike effektene av å gjennomføre de ulike
alternative tiltakene. Effektene er alle positive, da de negative effektene har blitt
prissatt.
Alternativ
0+
Alternativ
nye
tjenester
Alternativ
overgang
på 4 år
Alternativ
overgang
på 2 år
Utfasing av
lukkede og
uegnede format
+ + ++ ++
Tilgjengelighet
på ulikt
brukerutstyr
0 ++ +++ ++++
Tilrettelegging
for universell
utforming
0 + +++ ++
Tilrettelegging
for
videreutvikling
av tjenester
0 + ++++ +++
Sikkerhet 0 + +++ ++
OPPSUMMERING AV PRISSATTE OG IKKE-6.4
PRISSATTE EFFEKTER
Alternativ 0 0+ 1 2 3
Total nåverdi av
kostnadene med
skattekostnad 167 428 634 167 428 634 167 428 634 167 428 634 167 428 634
Sammenligning
med null
alternativet - 2 945 730 3 678 914 5 065 790 7 039 574
Side 41
Rangering av
ikke-prissatte
effekter
- 4 3 1 2
I og med at endringen tiltakene fremprovoserer uansett vil skje i null-
alternativet, er det i hovedsak effekten av å gjøre dette tidligere eller senere som
framkommer i analysen.
Kostnadsmessig skiller alternativene seg ikke betydelig fra hverandre.
Beregningene viser at ved å fremskynde overgangen vil offentlig sektor
realisere en liten besparelse. Den er i hovedsak knyttet til muligheten for å fase
ut utviklingsmiljøet for PDF-tjenester.
Noen av tallene benyttet i beregningene er knyttet til stor usikkerhet. Variasjon
av de mest usikre tallene gir derimot ingen betydelige endringer av anslagene.
Det er viktig å være oppmerksom på at tiltaket vil fremprovosere andre
prosjekter. knyttet til videreutvikling av eksisterende tjenester, som vil ha
ytterligere kostnader, men også gevinster. Disse kostnadene og gevinstene er
ikke tatt med inn i denne vurderingen, men vil være gjenstand for egne
vurderinger av hver enkelt tjeneste som velges å videreutvikles i hver
virksomhet.
De ikke-prissatte effektene viser at en raskere overgangen fra PDF til HTML
gjennom et obligatorisk krav vil være positivt. En raskere overgang til HTML
vil tilrettelegge for hurtigere videreutvikling av offentlige tjenester, med
mulighet for bedre informasjonssikkerhet, mulighet for høyere
automatiseringsgrad, mulighet for bedre brukervennlighet og mulighet for bedre
universell utforming av tjenestene. I tillegg vil en raskere overgang gjøre flere
tjenester raskere tilgjengelig på alle typer brukerutstyr som for eksempel
smarttelefoner og PAD-er.
Offentlig sektor som helhet ligger etter i utviklingen av gode elektroniske
tjenester, selv om det finnes noen hederlige unntak. I privat sektor vil
virksomheter som ikke følger med i utviklingen bli utkonkurrert og gå konkurs
forholdsvis raskt. En offentlig virksomhet kan fortsette sin virksomhet med
utdaterte løsninger uten tilsvarende følger. Det er derfor viktig at det kommer
krav som dette, for å skape et trykk for videreutvikling av offentlige tjenester.
ANBEFALING 7
Alternativene 7.1
Utviklingen går i retning av at de aller fleste offentlige tjenester vil overføres til
HTML innen en 10 års periode. De tiltak som her pekes på er ulike krav til bruk
av standarder som kan bidra til fremskynde denne utviklingen, og dermed
Side 42
tilrettelegge for en raskere innføring av bedre offentlige tjenester og bedre
samhandling mellom virksomhetene.
Denne analysen forsøker å svare på to hovedspørsmål: - Vil det være samfunnsøkonomisk lønnsomt å anvende sentrale politiske
virkemidler for å fremskynde en overgang fra å publisere
nettleserbaserte tjenester på PDF til HTML i offentlig sektor.
- Vil standardisering være er et egnet virkemiddel til å framskynde
gjennomføringen, eventuelt om dette bør kombineres med andre tiltak.
For å besvare disse spørsmålene har vi vurdert 4 ulike alternativer, med
forskjellig omfang av standardisering i tillegg til dagens situasjon (null-
alternativet). For hvert alternativ skjer det en innstramming av kravet. I figuren
under illustreres forholdet mellom alternativene, og hvordan de bygger på
hverandre.
Alternativ 1 og 2 innebærer mer omfattende krav enn alternativ 0+, og
alternativ 3 innebærer en raskere overgangsperiode enn alternativ 2.
En flytting av alle tjenester til HTML vil innebære kostnader for overflytting til
HTML, men også innsparinger ved utfasing av PDF-løsninger. Til sammen gir
beregningene en liten besparelse som øker jevnt med strengere tiltak, som fører
til en raskere overgang.
Det har kun vært mulig å prissette kostnadene, mens nytteeffektene er behandlet
som ikke-prissatte effekter. Dette betyr at vi har måttet vurdere prissatte
kostnader opp mot nytteeffekter som ikke er prissatt for de ulike alternativene.
Drøfting 7.2
Beregningene viser en liten besparelse i hver virksomhet. Virksomhetene vil
først få en økt kostnad ved overflytting av tjenester til HTML, for deretter å få
en besparelse i det den siste tjenesten på PDF kan fases ut og utviklingsmiljøet
for PDF kan kuttes. Dette vil gi en dreining av markedet fra PDF-løsninger mot
Valgfritt krav om å benytte HTML eller PDF i nye nettleserbaserte tjenester
Obligatorisk krav til bruk av HTML i nye nettleserbaserte tjenester
Samme som alternativ en men nå også med obligatorisk krav om å flytte eksisterende nettleserbaserte tjenester over på HTML innen 4 år
Samme som 2 men nå med 2 års overgangsperiode
0+-alternativet Alternativ 1 Alternativ 2 Alternativ 3
Side 43
HTML-løsninger. Dette er et skifte i markedet som foregår og som vår
beslutning vil ytterligere fremskynde, men ikke ha avgjørende effekt på.
Kostnadene ved å legge tjenester over på HTML-format som her er beregnet,
vil være små i forhold til de økte kostnadene knyttet til påfølgende
tjenesteutvikling. Tjenesteutviklingen vil være knyttet til egne kost-/ nytte
vurderinger, der endringene vil kunne gi betydelige gevinster.
Kostnadene per virksomhet for å legge om til HTML for publisering av
nettleserbaserte tjenester er små og må kunne håndteres innenfor gjeldende
budsjettrammer. Ved sluttføringen av tiltaket, vil de offentlige virksomhetene
ha fått besparelser som overgår investeringene.
En del virksomheter fremhever at de har tjenester som ikke bør løftes over av
ulike årsaker. Dette bør vurderes over tid, da den ene eller de få tjenestene vil
være de som holder igjen muligheten til å fase ut utviklingsmiljøet for PDF.
I dag publiserer en del offentlige virksomheter tjenester på dokumentformater
som er lite egnet for tjenesteutvikling og som til dels krever at brukere kjøper
programvare fra en spesifikk leverandør for å kunne benytte dem. Dette er
uheldig praksis som vi ønsker å komme bort i fra. I tillegg ser vi at en overgang
til HTML muliggjør en videreutvikling av tjenester som tilfredsstiller behov
både brukere av offentlige tjenester og offentlige virksomheter selv har.
Nær halvparten av de eksisterende nettleserbaserte tjenestene er publisert på
PDF. Dette er en standard som ved bruk i elektroniske tjenester mangler mye av
den funksjonaliteten som er nødvendig for å gjøre tjenester universelt utformet
og dermed tilgjengelig for flest mulig. I tillegg gir HTML muligheter som gjør
det lettere å benytte tjenestene med hjelpemidler for de som trenger ytterligere
tilpasning.
HTML har en funksjonalitet som gjør det mulig å etablere tjenester med
funksjoner som gir offentlige virksomheter det de trenger fremover.
Funksjonalitet som gjør det mulig å hente inn og preutfylle eksisterende
informasjon i stedet for at brukeren skal taste inn alt på nytt. Funksjonalitet som
gjør det mulig å bedre kvaliteten på data gjennom validering av input data,
automatisk innsending og strukturering av data for integrasjon mot
underliggende fagsystemer. Funksjonalitet for å sikre integritet,
konfidensialitet, autentisering og uavviselighet. Funksjonalitet som gjør det
mulig å lage mye mer brukervennlige tjenester enn det man har i dag, med
muligheter for gode hjelpetekster og interaktivitet for oppfølging av brukere
med behov for brukerstøtte. HTML gjør det mulig å gi brukerne et helhetlig
tilbud gjennom sammensatte tjenester, som tilbyr et sett med tjenester fra ulike
etater, som samler de tjenester brukeren må forholde seg til i en gitt situasjon.
Det er en klar trend mot større bruk av smarttelefoner og PAD-er. Brukere
ønsker å ta i bruk tjenester på det tidspunktet og sted som passer dem. HTML er
en standard som gjør det mulig. I tillegg vil en slik mulighet mest sannsynlig
øke bruken av de digitale tjenestene og på den måten gi innsparingsmuligheter
for offentlige virksomheter.
Side 44
Alternativ 0+ og 1 dekker et mindre område enn Alternativ 2 og 3.
Alternativene er dyrere og gir mindre effekt. Alternativ 2 og 3 dekker samme
område, men har ulik overgangsordning. Alternativ 3 kommer best ut
kostnadsmessig. På de ikke prissatte effektene, er alternativ 3 best på et område,
mens alternativ 2 er bedre på flere andre. Til sammen blir alternativ 2 rangert
over alternativ 3.
Alternativ 3 har en veldig rask overgangsordning. Det vil føre til at mange
virksomheter ikke har kapasitet til å gjennomføre videreutvikling av tjenester i
overgangen fra PDF til HTML. En hurtig overgang til HTML vil føre til at
tjenestene raskt blir tilgjengelig på flere typer brukerutstyr, men mulighetene
for å forbedre tjenestene vil ikke utnyttes på grunn av tidspresset og alternativet
scorer derfor dårligere på de andre ikke-prissatte effektene. I alternativ 2 vil det
drøye litt lenger før alle tjenestene er over, men de vil i større grad komme over
på en forbedret måte.
Det har vært vurdert å ha et alternativ med 6 års overgangsperiode. I dette
tilfellet mener vi at det tar for lang tid, både til å forbedre tjenestene og gjøre
dem tilgjengelig for fler typer brukerutstyr. Det er mange som er misfornøyd
med dagens tjenester fra offentlig sektor, og det er stadig nyhetssaker der
offentlig sektor fremstilles som brukerfiendtlig og steinaldersk. Det er viktig å
finne en god balanse der man opprettholder en tilstrekkelig fremdrift, uten at det
i for stor grad går utover det videreutviklingsarbeidet som bør gjennomføres.
Enkelte mener at ved å gå inn å kreve bruk av en standard på denne måten, så
blander politikerne seg for mye inn i hver offentlig virksomhets selvråderett.
Politikerne skal derimot ta vare på offentlig sektor som en helhet. De skal sikre
et godt samarbeid mellom virksomhetene slik at de kan levere best mulig
tjenester til innbyggere og næringsliv for en lavest mulig kostnad. Bruk av
felles standarder er nødvendig for å få til dette. Erfaring tilsier at virksomhetene
i for liten grad tar hensyn til andre prosjekters krav i gjennomføring av eget
prosjekt og trenger dette som sentrale føringer.
De nasjonale felleskomponentene er viktige elementer i den helhetlige
offentlige virksomhetsarkitekturen. Det er derfor avgjørende og se hvordan de
forholder seg til en overgang til HTML. Dialogen med Altinn og MinSide viser
at de benytter HTML i dag, og ønsker et slikt krav velkommen. Det er heller
med på å fremme bruken av felleskomponentene enn å legge hinder for bruken
av dem.
En av de utfordringene, som har vært krevende er å definere grensen for når
kravet om bruk av HTML skal gjelde. Skal kravet gjelde alle tjenester, de
tjenester som har et vist brukervolum eller tjenester med en viss kompleksitet.
Det har vært vanskelig å finne eksakte parameter som vil gi en klar grense for
når et slikt krav på gjelde. Det vi har falt ned på er tilsvarende unntaksordning
som det vi i dag har for felles tegnsett: «Er det en særlig uforholdsmessig byrde
å oppfylle den obligatoriske standarden, kan forvaltningsorganet unnlate helt
eller delvis å oppfylle kravet. Forvaltningsorganet skal straks melde fra til
Direktoratet for forvaltning om dette og begrunne hvorfor det unnlater å
oppfylle kravet»
Side 45
Det er en klar forskjell på private virksomheter og offentlige virksomheter når
det kommer til å være innovative og utnytte ny teknologi for å være
konkurransedyktige. En privat virksomhet går konkurs. En offentlig leder
unngår risikoen for å feile. Noe som kan koste ham jobben. Det er derfor viktig
å få frem på plass krav til offentlige virksomheter som bidrar til utvikling.
Det har vært utfordrende å avgrense den samfunnsøkonomiske analysen. En
viktig del av nytten ved å sette et krav til bruk av standard for publisering av
nettleserbaserte tjenester er å tilrettelegge for og fremskynde videreutviklingen
av offentlige tjenester. I så måte vil kravet påføre offentlige virksomheter større
kostnader enn det vi beregner i denne analysen, fordi virksomhetene vil velge å
videreutvikle mange av tjenestene i det de legger om til HTML. Det er derimot
slik at disse tjenestene vil ha egne kost/ nytte vurderinger og det er umulig for
oss å gå inn i alle kostnader og gevinster i alle disse ulike utviklingsløpene. Vi
har derfor i denne analysen måttet avgrenset oss til den konkrete overgangen.
Et krav om full overgang til HTML for nettleserbaserte tjenester er ikke nok
alene for å ta ut alle potensielle effekter. En slik overgang tilrettelegger for
utvikling, men sikrer ikke at virksomhetene gjennomfører denne utviklingen.
Vi ser at mange offentlige virksomheter har begrenset kunnskap om
mulighetene som ligger i ny teknologi og i mindre grad vet hvordan de skal ta i
bruk den nye teknologien for å bedre arbeidsprosesser og tilhørende tjenester.
En god del av denne kompetansen kan kjøpes hos leverandører i markedet, og
vil bidra til å løfte markedet på dette området, ikke bare for offentlig sektor selv
men generelt.
Det kunne allikevel vært nyttig å ha et kompetansesenter for utvikling av
elektroniske tjenester i offentlig sektor, som veileder og viser best praksis for
utvikling av elektroniske tjenester til enhver tid. På samme måte som Difi har
for informasjonssikkerhet og universell utforming.
Variasjonen i offentlige tjenester er derimot enorm og det er utrolig vanskelig å
gi et anslag på hvor store besparelser som vil kunne tas ut i de 20 tusen ulike
tjenestene offentlig sektor publiserer på nett. Det er derfor ytterst vanskelig å
lage en samfunnsøkonomisk analyse som kan gi gode estimeringer på nytten av
et slikt forslag, som derfor ikke er inkludert i denne utredningen.
Konklusjon 7.3
Utredningen anbefaler alternativ 2 som innebærer å gjøre HTML til en
obligatorisk forvaltningsstandard for publisering av nettleserbaserte tjenester i
offentlig sektor, med mindre det er en særlig uforholdsmessig byrde å oppfylle
den obligatoriske standarden. Da kan forvaltningsorganet unnlate helt eller
delvis å oppfylle kravet. Forvaltningsorganet skal straks melde fra til
Direktoratet for forvaltning og IKT om dette og begrunne hvorfor det unnlater å
oppfylle kravet.
I tillegg til å gjøre HTML til en obligatorisk standard anbefales det å sette
anbefalte krav om bruk av ISO 639 for deklarering av språkkoder, CSS for
formattering av nettsider og hvis virksomheten velger å gjøre bruk av
Side 46
Javascript, anbefales det at man baserer seg på W3C sin versjon av Document
Object Model (DOM). Dette anses som støtte standarder til HTML og benyttes
på samme måte for publisering av dokumenter på offentlige nettsider.
I tillegg anbefales det å vurdere å etablere et kompetansesenter for utvikling av
elektroniske tjenester i offentlig sektor, selv om ikke denne rapporten direkte
kan underbygge dette samfunnsøkonomisk.
Vi mener i drøftingen å ha konkludert med at det å ta i bruk HTML som en
obligatorisk standard vil være samfunnsøkonomisk nyttig. Bruk av standarder
er viktig for å gjennomføre de politiske målsetninger for digitaliseringen av
offentlig sektor og for å tilfredsstille kravene satt i tilgjengelighetsloven til
nettleserbaserte tjenester.
VEDLEGG A – STANDARDERS STØTTE FOR ULIKE
FUNKSJONER I arbeidet med å vurdere ulike alternative krav til standarder, som skal legges til grunn
for alternativanalysen, er det viktig å vurdere i hvilken grad de ulike standardene
tilfredsstiller behovene.
Under følger en tabell som oppsummerer noen av de funksjonene en standard må
støtte for å tilfredsstille identifiserte behov.
Funksjon Beskrivelse Format
Mulighet for sporvalg Sporvalg gjør at skjemaet tilpasser seg ut fra svarene du gir/opplysningene du oppgir. Sporvalg vil gjøre søkeprosessen enklere ved at man ikke trenger å forholde seg til informasjon/ spørsmål som ikke angår seg selv.
Forutsetter HTML
Hente strukturert informasjon fra eksterne kilder
Slipper å fylle ut og sende inn informasjon som allerede finnes i forvaltningen. Det blir bedre kvalitetssikring av data, som gir bedre beslutningsgrunnlag. Det legger til rette for større grad av automatisert saksbehandling.
Forutsetter HTML
Hente strukturert informasjon internt
Vil gi bedre beslutningsgrunnlag og legger til rette for bedre kvalitet på data. Det legger til rette for større grad av automatisert saksbehandling ved at man slipper å fylle ut mer informasjon enn nødvendig. Gir mulighet for å gi svar med en gang om man har krav på en tjeneste eller ikke.
Forutsetter HTML
Lagre data og fortsette søkeprosessen senere
Man kan stoppe midt i en søkeprosess, hvis man for eksempel mangler nødvendig informasjon. Etter å ha innhentet informasjon kan man fortsette der man slapp, i stedet for å starte på nytt. Dette gjør prosessen mer brukervennlig og åpner for at flere fullfører.
Styrket ved HTML
Validering Beslutningsgrunnlaget vil bli mer korrekt ved at opplysningene blir kvalitetssikret med en gang.
Styrket ved HTML
Integrasjon med fagsystemer
Gir bedre datakvalitet og raskere og enklere saksbehandling. Slipper å fylle inn all informasjon på nytt i virksomheten.
Styrket ved HTML
Ivareta informasjonssikkerhet
Gjør at data ikke kan endres etter innsending, som det blir høyere datakvalitet av. Kan gi mer automatisering av tjenester med sensitiv informasjon. Økt grad av integritet, konfidensialitet og tilgjengelighet.
Styrket ved HTML
Hjelpetekst med lenker til annen informasjon
En «guide» for å hjelpe brukeren til å fylle ut korrekt. Vil gi bedre datakvalitet, bedre beslutningsgrunnlag og flere som klarer å gjennomføre tjenestene.
Styrket ved HTML
Signere hele skjema eller deler av skjema og signering fra flere personer oppå hverandre eller ved siden av hverandre
Flere vil kunne bruke en tjeneste når man skal signere i samme tjeneste. Vil komme frem hvem som har benyttet seg av tjenesten, mer effektivt og etterprøvbart i ettertid.
Styrket i HTML
Autentisering Muliggjør for innsynstjenester og andre personaliserte tjenester. Autorisering vil være med på å kunne lage flere elektroniske tjenester med sensitiv informasjon.
Forutsetter HTML
Side 48
Funksjon Beskrivelse Format
Autorisasjonsløsninger Muliggjør digitalisering av flere tjenester, der flere skal kunne bruke hele eller deler av tjenesten avhengig av rolle og autorisasjon.
Forutsetter HTML