Alternativanalyse – Standarder for publisering av
Alternativanalyse – Standarder for publisering av nettleserbaserte tjenester Utkast versjon 0-8, 13.04.2015 INNHOLD 1 Sammendrag .................................................................................................3 2 Innledning.....................................................................................................7 3 2.1 Bakgrunn ...............................................................................................7 2.2 Kort om standardiseringsarbeidet ..........................................................8 2.3 Om nettleserbaserte tjenester .................................................................9 2.4 Metode .................................................................................................10 Dagens situasjon og behov for standarder for nettleserbaserte tjenester ...11 3.1 Dagens situasjon ..................................................................................12 3.2 Normative behov .................................................................................15 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 3.3 Interessenters behov på området..........................................................17 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 3.4 Oppsummering av behovsanalysen .....................................................22 4 Mål for tiltaket ............................................................................................23 5 Mulighetsrommet .......................................................................................24 5.1 Null+-alternativet, Valgfritt PDF eller HTML på nye tjenester ..........24 5.2 Alternativ 1. Obligatorisk HTML på nye tjenester..............................25 5.3 Alternativ 2. Obligatorisk HTML på nye tjenester og på eksisterende tjenester innen 4 år .........................................................................................25 5.4 Alternativ 3. Obligatorisk HTML for nye tjenester og eksisterende tjenester innen 2 år .........................................................................................26 6 Den samfunnsøkonomiske analysen ..........................................................26 6.1 Forutsetninger for analysen .................................................................26 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 6.2 Prissatte effekter ..................................................................................30 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 6.3 Ikke-prissatte effekter ..........................................................................35 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 6.4 OPPSUMMERING AV PRISSATTE OG IKKE-PRISSATTE EFFEKTER ....................................................................................................40 7 ANBEFALING ..........................................................................................41 7.1 Alternativene .......................................................................................41 7.2 Drøfting ...............................................................................................42 7.3 Konklusjon...........................................................................................45 Vedlegg A – Standarders støtte for ulike funksjoner .........................................47 Side 2 1 SAMMENDRAG Dette 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 3 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: Drivkrefter Hovedmål Effekter • • • Flere og bedre digitale tjenester • Informasjonssikkerhet Effektiv saksbehandling Brukervennlighet • • • Enklere og brukervennlige tjenester Effektiv saksbehandling Tilstrekkelig informasjonssikkerhet Delmål • • • • • 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) Følgende alternativer er inkludert i den samfunnsøkonomiske analysen og bygger på hverandre i en trappetrinnmodell: 0+-alternativet Valgfritt krav om å benytte HTML eller PDF i nye nettleserbaserte tjenester Alternativ 1 Obligatorisk krav til bruk av HTML i nye nettleserbaserte tjenester Alternativ 2 Aternativ 1 pluss obligatorisk krav om å flytte eksisterende nettleserbaserte tjenester over på HTML innen 4 år Alternativ 3 Alternativ 2 men med 2 års overgangsperiode Side 4 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 Alternativ 0 / 0+ Alternativ 1 Alternativ 2 Alternativ 3 Uten skattekostnad 141 684 139 138 983 802 136 565 854 134 575 854 Med skattekostnad Sammenlignet mot nullalternativet (med skattekostnad) 170 020 967 166 780 562 163 879 025 161 490 905 3 240 405 6 141 942 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 Alternativ Alternativ Alternativ 0+ nye overgang overgang tjenester på 4 år på 2 år Utfasing av lukkede og + + ++ ++ uegnede format Tilgjengelighet på ulikt brukerutstyr Tilrettelegging for universell utforming Tilrettelegging for videreutvikling av tjenester Sikkerhet 0 ++ +++ ++++ 0 + +++ ++ 0 + ++++ +++ 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 5 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 6 2 INNLEDNING Det 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. 2.1 Bakgrunn 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 skjematjenester. 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/iktpolitikk/digitaliseringsrundskrivet_2013.pdf 2 Difi (2014): Forprosjekt – Standarder for nettleserbaserte tjenester; http://standard.difi.no/filearchive/forprosjektrapport-standarder-for-nettleserbaserte-tjenester-v10.pdf Side 7 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. 2.2 Kort om standardiseringsarbeidet 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-avnettleserbaserte-tjenester-v1-0.pdf Side 8 2.3 Om nettleserbaserte tjenester 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 9 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. 2.4 Metode 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 10 tjenester. Det har også blitt gjennomført en spørreundersøkelse for å bekrefte/ avkrefte de funn vi har gjort i møtene. 3 DAGENS SITUASJON OG BEHOV FOR STANDARDER FOR 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 11 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. 3.1 Dagens situasjon 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 12 «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 1012 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 13 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 14 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 HTMLløsninger kan generere PDF-skjema automatisk basert på HTML-tjenesten om ønskelig. 3.2 Normative behov 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, Diskrimineringsog 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-avnettleserbaserte-tjenester-v1-0.pdf 9 Departementene (2012): På nett med innbyggerne – regjeringens digitaliseringsprogram; https://www.regjeringen.no/globalassets/upload/fad/kampanje/dan/regjeringensdigitaliseringsprogra m/digit_prg.pdf 10 Kommunsal- og moderniseringsdepartementet (2014): Rundskriv H-7:14 Digitaliseringsrundskrivet; https://www.regjeringen.no/nb/dokumenter/Digitaliseringsrundskrivet/id766322/ Side 15 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 16 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. 3.3 Interessenters behov på området 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/Regjeringenssatsingsomrader/En-enklere-hverdag-for-folk-flest/Fjerne-tidstyver/id753126/ 13 https://www.regjeringen.no/nb/om_regjeringa/solberg/Regjeringens-satsingsomrader/Regjeringenssatsingsomrader/En-enklere-hverdag-for-folk-flest/id752873/?regj_oss=10 Side 17 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 18 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 19 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 20 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 21 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. 3.4 Oppsummering av behovsanalysen 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 IKTkompetanse har et godt offentlig tjenestetilbud. Side 22 4 MÅL FOR TILTAKET I 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. Drivkrefter Hovedmål Effekter • • • Flere og bedre digitale tjenester • Informasjonssikkerhet Effektiv saksbehandling Brukervennlighet • • • Enklere og brukervennlige tjenester Effektiv saksbehandling Tilstrekkelig informasjonssikkerhet Delmål • • • • • 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) 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. Side 23 5 MULIGHETSROMMET Med 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. 5.1 Null+-alternativet, Valgfritt PDF eller HTML på nye 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-avnettleserbaserte-tjenester-v1-0.pdf Side 24 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. 5.2 Alternativ 1. Obligatorisk HTML på nye tjenester 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. 5.3 Alternativ 2. Obligatorisk HTML på nye tjenester og 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 25 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. 5.4 Alternativ 3. Obligatorisk HTML for nye tjenester og 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. 6 DEN SAMFUNNSØKONOMISKE ANALYSEN Hensikten med analysen av prissatte og ikke-prissatte effekter er å beregne samfunnsøkonomisk nytte for løsningsalternativene, sammenliknet med Nullalternativet. I tillegg skal analysen synliggjøre hvilket løsningsalternativ som har størst samfunnsøkonomisk nytte. 6.1 Forutsetninger for analysen 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 26 (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. DFØ (2014): Veileder i samfunnsøkonomiske analyser; http://www.dfo.no/Documents/FOA/publikasjoner/veiledere/Veileder_i_samfunns%c3%b8konomis ke_analyser_1409.pdf 17 Side 27 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 (nullalternativet). 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 28 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 funksjonalitetsbegrensninger. 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 29 6.2 Prissatte effekter 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 HTMLutvikling, 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 30 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 31 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 32 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 % 54 % 59 % 64 % 69 % 75 % 80 % 85 % 90 % 95 % 95 % 1 54 % 59 % 66 % 73 % 80 % 89 % 95 % 95 % 95 % 95 % 2 54 % 62 % 70 % 79 % 88 % 95 % 95 % 95 % 95 % 95 % 3 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 33 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 34 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 regnearkmodell 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 Alternativ 0 / 0+ Alternativ 1 Alternativ 2 Alternativ 3 Uten skattekostnad 141 684 139 138 983 802 136 565 854 134 575 854 Med skattekostnad 170 020 967 166 780 562 163 879 025 161 490 905 Sammenlignet mot nullalternativet (med skattekostnad) 3 240 405 6 141 942 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 6.3 Ikke-prissatte effekter 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 35 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 36 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 37 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 38 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 39 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+ Utfasing av lukkede og uegnede format Tilgjengelighet på ulikt brukerutstyr Tilrettelegging for universell utforming Tilrettelegging for videreutvikling av tjenester Sikkerhet + Alternativ nye tjenester + Alternativ overgang på 4 år ++ Alternativ overgang på 2 år ++ 0 ++ +++ ++++ 0 + +++ ++ 0 + ++++ +++ 0 + +++ ++ 6.4 OPPSUMMERING AV PRISSATTE OG IKKEPRISSATTE EFFEKTER Alternativ Total nåverdi av kostnadene med skattekostnad Sammenligning med null alternativet 0 0+ 1 2 3 167 428 634 167 428 634 167 428 634 167 428 634 167 428 634 - 2 945 730 3 678 914 5 065 790 7 039 574 Side 40 Rangering av ikke-prissatte effekter - 4 3 1 2 I og med at endringen tiltakene fremprovoserer uansett vil skje i nullalternativet, 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. 7 ANBEFALING 7.1 Alternativene 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 41 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 (nullalternativet). For hvert alternativ skjer det en innstramming av kravet. I figuren under illustreres forholdet mellom alternativene, og hvordan de bygger på hverandre. 0+-alternativet Valgfritt krav om å benytte HTML eller PDF i nye nettleserbaserte tjenester Alternativ 1 Obligatorisk krav til bruk av HTML i nye nettleserbaserte tjenester Alternativ 2 Samme som alternativ en men nå også med obligatorisk krav om å flytte eksisterende nettleserbaserte tjenester over på HTML innen 4 år Alternativ 3 Samme som 2 men nå med 2 års overgangsperiode 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. 7.2 Drøfting 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 Side 42 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 43 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 44 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. 7.3 Konklusjon 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 45 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. Side 46 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 Mulighet for sporvalg Hente strukturert informasjon fra eksterne kilder Hente strukturert informasjon internt Lagre data og fortsette søkeprosessen senere Validering Integrasjon med fagsystemer Ivareta informasjonssikkerhet Hjelpetekst med lenker til annen informasjon Signere hele skjema eller deler av skjema og signering fra flere personer oppå hverandre eller ved siden av hverandre Autentisering Beskrivelse 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. 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. 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. 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. Beslutningsgrunnlaget vil bli mer korrekt ved at opplysningene blir kvalitetssikret med en gang. Gir bedre datakvalitet og raskere og enklere saksbehandling. Slipper å fylle inn all informasjon på nytt i virksomheten. 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. En «guide» for å hjelpe brukeren til å fylle ut korrekt. Vil gi bedre datakvalitet, bedre beslutningsgrunnlag og flere som klarer å gjennomføre tjenestene. 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. Format Forutsetter HTML Muliggjør for innsynstjenester og andre personaliserte tjenester. Autorisering vil være med på å kunne lage flere elektroniske tjenester med sensitiv informasjon. Forutsetter HTML Forutsetter HTML Forutsetter HTML Styrket ved HTML Styrket ved HTML Styrket ved HTML Styrket ved HTML Styrket ved HTML Styrket i HTML Funksjon Autorisasjonsløsninger Beskrivelse Muliggjør digitalisering av flere tjenester, der flere skal kunne bruke hele eller deler av tjenesten avhengig av rolle og autorisasjon. Side 48 Format Forutsetter HTML
© Copyright 2024