Referat fra møtet i Standardiseringsrådet mars 2015

Transkript

1 Referat fra møtet i Standardiseringsrådet mars 2015 Tid: 21. mai 2015, kl :30 Sted: SSB, Akersveien 26, Oslo Møteleder: Olaf Østensen, Statens kartverk Referent: Kristian Bergem, Difi Tilstede: Olaf Østensen, Statens kartverk (leder av Standardiseringsrådet) Arne Thorstensen, SKD Viveca Liodden, SKD - Sak Torstein Hoem, SKD Sak Anne Mette Dørum, KS Trygve Falch, SSB Bent Vangli, Riksarkivet Thomas Rosenlund, Helsedirektoratet Morten Brekk, Brreg Per Kjetil Grotnes, Oslo kommune Parastoo Mohagheghi, NAV Knut Lindelien, Standard Norge Bjørn Holstad, Difi Kristian Bergem, Difi Forfall: Sidsel Tønnessen, KMD Rune Sandland, KommIT Jon Arve Risan, Norstella Agenda 1) Godkjenning agenda (beslutningssak) 2) Standarder for publisering av nettleserbaserte tjenester i offentlig sektor (beslutningssak) 3) Dual stack IPv4 og Ipv6 (beslutningssak) 4) edag, Skatteetaten (informasjonssak) 5) Standardiseringsrådets forhold til Veikartarbeidet under Skate (informasjonsarbeid) 6) Generelt obligatorisk krav om bruk av relevante åpne standarder (beslutningssak) 7) Status for standardiseringsarbeidet i Difi (informasjonssak) 8) Eventuelt a. Navn på arbeidsgruppene 1 Godkjenning av agenda (Beslutningssak) Agenda ble godkjent uten kommentarer. 1

2 2 Standarder for publisering av nettleserbaserte tjenester (beslutningssak) Kristian Bergem presenterte den samfunnsøkonomiske analysen utarbeidet for å synliggjøre effekten av et obligatorisk krav om bruk av standarder for publisering av nettleserbaserte tjeneste. Se vedlagt presentasjon. NAV sier at de har beregnet at det vil ta betraktelig mer tid å legge om fra PDF til HTML enn de tallene det opereres med i utredningen og at det for dem tar betraktelig lengre tid å utvikle tjenester i HTML enn i PDF. De nevner tall i størrelsesorden 100 til 1000 timer for å legge om en tjeneste fra PDF til HTML avhengig av tjeneste. I tillegg sier NAV at de ikke ser poenget i å legge om tjenester til HTML, uten å utvikle tjenestene videre. Selv om NAV har laget avanserte tjenester i PDF, er dette anslaget vanskelig å forstå, med mindre de legger andre forutsetninger til grunn enn det som er gjort i utredningen. Det antas at NAV har kommet frem til et slikt anslag, fordi tid til videreutvikling og integrasjon mot bakenforliggende system er inkludert. Utredningen avgrenser seg fra videreutvikling. Dette er ekstraarbeid utover det å legge om tjenester fra PDF til HTML, som vil gi nytte i seg selv. Nytten av videreutviklingen er heller ikke inkludert i denne utredningen. Det antas at nytten av videreutvikling vil være større enn kostnaden, men at dette må vurderes fra tilfelle til tilfelle. Når NAV mener det tar lengre tid å utvikle tjenester på HTML enn å utvikle tjenester på PDF, antar vi at det er fordi tjenestene de beskriver ikke har tilsvarende funksjonalitet, men at når de lager tjenester for HTML, inkluderer de helt annen funksjonalitet og lager mer avanserte tjenester enn det som ellers ville vært gjort i PDF. Alle andre offentlige virksomheter vi har vært i kontakt med og leverandører av tjenesteutvikling på PDF og HTML antar at tilsvarende tjenester vil ta omtrent tilsvarende tid å utvikle, men at man ofte vil velge å lage mer avanserte tjenester i HTML og at det derfor gjerne tar lenger tid. Sekretariatet er enig med NAV i at det å videreutvikle tjenestene er fornuftig. Det at offentlige virksomheter velger å videreutvikle tjenestene når de blir lagt over på HTML er et argument for å velge HTML, men vi mener at denne type videreutviklingen må være gjenstand for en egen kost nytte vurdering for seg, og at videreutviklingen gjennomføres dersom den vurderingen er positiv. Sekretariatet er derimot av den oppfatning, at om det tar for lang tid før en videreutvikle tjenestene kan prioriteres, så er det nødvendig å legge om tjenestene til HTML uten videreutvikling. Dette fordi det vil gjøre tjenestene tilgjengelig på flere typer brukerutstyr og fordi det vil gjøre tjenestene mer tilgjengelig for brukere med nedsatt funksjonsevne. Sekretariatet ser derimot at NAV er i en særstilling, da de har laget en integrasjonsløsning for PDF-skjema, der de kan trekke ut strukturerte data fra PDF-skjemaene og ta dem automatisk inn i fagsystem. NAV vil derfor kunne få betydelig større kostnader, enn andre virksomheter. I tillegg har NAV en del tjenester som krever funksjonalitet som er kostbart å implementere i HTML. NAV vil derfor i mange sammenhenger falle inn under unntaksordningen om at det 2

3 vil være uforholdsmessig kostnadskrevende å flytte tjenestene over på HTML-format og derfor ikke trenger å gjøre det. NAV mener også at Difi har overvurdert kostnaden ved å fjerne PDF som produksjonsformat. Ut i fra den dialogen sekretariatet har hatt med ulike virksomheter har vi forstått at det er en betydelig forskjell mellom å legge ut PDF-skjema for utskrift og det å legge ut PDF-skjema for automatisk utfylling og elektronisk innsending. Sistnevnte krever lisens på Adobe livecycle ES4, og denne kostnaden kan fjernes, hvis man bare legger ut skjema for utskrift. I tillegg vil hovedandelen av mindre og mellomstore virksomheter kjøpe slike tjenester i markedet ferdig driftet hos leverandører. I disse tilfellene har vi lagt til grunn prisene fra leverandørene i markedet. Det er slik at leverandørene priser HTML-skjema mer gunstig enn PDF-skjema. Det ble også diskutert lengden på overgangsordningen. NAV mente at overgangsordningen er for kort, fordi de ikke rekker å videreutvikle alle tjenestene innen tidsfristen, og at de derfor må prioritere og gjøre dette over lengre tid. Enkelte andre så heller ikke behovet for en så rask overgang. De så heller ikke behovet for å legge om enkelte tjenester uten å videreutvikle. Det ble fremhevet av sekretariatet at forslaget ikke er laget slik for å gjøre det bedre for offentlige virksomheter, men i hovedsak for å gjøre de tjenestene vi allerede har laget tilgjengelig på flere typer brukerutstyr og tilgjengelig for brukere med nedsatt funksjonsevne. Tall fra blant annet NAV viser at et stadig større antall brukere velger å benytte tjenester fra mobile enheter. På enkelte elektroniske tjenester benytter opp imot 70% av brukermassen mobile enheter. Det er derfor en balanse mellom det å avvente en omlegging for å få enda bedre tjenester gjennom videreutvikling, og det å få gjort tjenestene tilgjengelig for flere slik de er i dag. 4 år virker som en god balanse mellom disse formålene sett fra sekretariatets side. De fleste rådsmedlemmene var enig i denne vurderingen. I den grad NAV eller andre har særegenheter ved løsningene sine som gjør at det tar betydelig lengre tid å løfte dem over på HTML enn beregnet, kan de benytte seg av unntaksordningen hvis det blir en uforholdsmessig stor byrde. Har de ikke slike særegenheter mener sekretariatet at en kostnad på 8 timer per tjeneste ikke utgjør en uforholdsmessig stor byrde å gjøre da en omlegging vil ha svært positiv effekt for brukerne. Muligheten til å ha en papirløsning ved siden av HTML-tjenesten ble diskutert. Det alternativet som sekretariatet har gått videre med i den samfunnsøkonomiske analysen er alternativet der offentlig virksomhet selv kan velge om det skal gjøres mulig for brukerne å ta utskrift for å sende inn på papir eller ikke, ut i fra egen kjennskap til brukermassen. Det å tilrettelegge for utskrift krever derimot ikke å opprettholde en PDF-tjeneste, da de fleste løsninger kan lage en PDF-utskrift av de skjema som tilgjengeliggjøres i HTML. Det å tilgjengeliggjøre utskrift av HTML-skjema, krever heller ikke de dyre lisensene som kreves for å kunne lage løsninger der man kan fylle ut PDF-skjema elektronisk, lagre og sende inn. Det ble også påpekt at det var viktig å kunne synliggjøre at kvitteringer i slike løsninger burde kunne gjøres tilgjengelig både som HTML og PDF. 3

4 Det ble også en lengre diskusjon om grensen mellom publisering av nettleserbaserte tjenester og publisering av dokumenter. F.eks. hvordan dette faller ut for innsynstjenester, og tjenester der for eksempel arkivverket skal gi tilgang til eldre dokumenter. De kravene som her settes må gjelde løsninger der det er lagt opp til dialog, og ikke der statisk informasjon skal publiseres/ tilgjengeliggjøres for brukeren. Søketjenesten for å finne frem til den informasjonen som skal lastes ned bør derimot være på HTML. Det må komme en tydeligere avgrensning på dette området, slik at det blir tydeligere hva som faller inn under hvilket bruksområdet. Noe av dette kan også håndteres i enkel veiledning. Sekretariatet har valgt å kalle bruksområdet nettleserbaserte tjenester og ikke skjema. Det er fordi man også ønsker å inkludere nyere dialogtjenester som ikke oppfattes som skjema tjenester. Det er derimot nødvendig å tydeliggjøre knytningen til skjema, slik at alle lesere forstår hva det her i hovedsak er snakk om. Det ble en diskusjon om meldeordningen til Difi for de som faller inn under unntaksordningen. Flere trodde at de aller fleste ikke ville ta seg bryet med å melde fra om slikt. Det var derimot enighet om at selv om få ville melde fra, så har Difi mulighet til å etterspørre hvorfor folk ikke følger og dermed kunne få en begrunnelse. Det anses at en slik meldeordning er viktig for å opprettholde betydningen av det obligatoriske vedtaket, slik at det ikke skal fremstå som en anbefaling. Et slikt krav vil også bidra til at virksomhetene i større grad blir bevisst beslutningen sin om eventuelt å ikke følge standardkravet. Det ble en diskusjon også rundt bruksområdet, om ikke noen typer skjema med lite bruk for eksempel burde være unnlat kravet. Sekretariatet fremhevet at flere parameter hadde vært på bordet i utredningen, og at det viktigste parameter, bruksfrekvens av tjenestene, varierer veldig fra virksomhet til virksomhet. For NAV er en tjeneste lite brukt med 100 tusen innsendinger i løpet avåret, mens for andre virksomheter er dette mer enn de mye brukte tjenestene. Det ble derfor vurdert mer hensiktsmessig å knytte en unntaksordning til kravet. En unntaksordning med fokus på kost/ nytte og at tjenester hvor en omlegging vil gi uforholdsmessig høye kostnader kan unnlate å følge kravet. En kost/ nytte vurdering ikke for virksomheten alene, men for virksomhet og brukere. 2.1 Konklusjon Standardiseringsrådet støtter anbefalingen om å gå for alternativ 2. Rådet antar at utfordringene NAV påpeker går inn under unntaksordningen på bakgrunn av kost/ nytte vurderinger, som tar hensyn til både virksomhet og brukere. Sekretariatet må gjøre en jobb for å tydeliggjøre kommunikasjonen rundt kravet, slik at det blir tydeligere hva dette handler om og hvilke tilfeller som faller inn under kravet og hvilke tilfeller som ikke gjør det. 3 Dual stack IPv4 og Ipv6 (beslutningssak) Kristian Bergem presenterte de undersøkelser som er gjort i etterkant av forrige møte for å kvalitetssikre effektene, beregningsmåten og tallene som lå til grunn for den 4

5 samfunnsøkonomiske analysen på området, samt for å sjekke ut i hvilken grad leverandører på området støtter IPv6. Det ble klarlagt at Oslo kommune, Bærum kommune og Sør Trøndelag fylkeskommune, alle var enig i at vi hadde identifisert de rette effektene, at beregningsmetoden var god og at tallene virket rimelige. Det hadde derimot vært noe usikkerhet knyttet til om dette kravet gjaldt interne løsninger eller ikke, noe som har betydelige følger for kostnaden ved innføring. Kraver slik det er utformet i dag gjelder ikke eksisterende interne løsninger. En av kommunene ønsket derimot et sterkere krav også på interne løsninger, for lettere å kunne selge inn behovet for IPv4 og IPv6 til ledere og forvaltningsfaglige, som per dato har mindre forståelse for slike infrastrukturgrep. Dette er derimot vanskelig å imøtekomme. Det har betydelige følger for virksomhetene og har heller ikke betydning for samhandling. Vi regner derimot med at kompetansen som virksomhetene bygger opp ved å implementere dual stack mot eksterne, vil gjøre at de ser nytten også i interne løsninger. De kan da velge å gå over på et tidspunkt som passer best for virksomheten. En av kommunene ønsket å knytte kravet nærmere til gjennomføringen av et innføringsprosjekt, som anbefalt i utredningen. Det er derimot vanskelig å koble budsjett og forskriftsprosesser, som håndteres hver for seg i dag. Men det bør vurderes videre i hvilken grad en greier å synliggjøre denne koblingen best mulig. I Skatteetaten var de enig i kravet når de forstod at kravet var dual stack og ikke IPv6 alene. De ser derimot at 2018 kommer veldig raskt og ønsker at kravet blir lagt til 2021 i stedet. Det er ønskelig å få nærmere avklart hva et slikt krav vil innebære for Skatteetaten fra nettverkssiden for eventuelt å avklare om det er mulig innen 2018, når de tekniske løsningene for gjennomføring avklares. En overgang innen 2018 vil være gjennomførbart for de aller fleste. Kravet er slik at dette kan håndteres i grenseflaten mot eksterne. I tillegg er det slik at 2021 er forholdsvis langt frem i tid. Det introduserer en økt risiko for at eksterne omstendigheter presser frem en raskere overgang, som igjen vil føre til større press på konsulentbransjen og offentlige virksomheter i forhold til å måtte innføre kravet i løpet av et kortere tidsrom og på en mindre planlagt måte. Sikkerhetsrisikoen knyttet til begrenset oppmerksomhet i offentlige virksomheter rundt sikkerhetsrisikoen knyttet til IPv6 er et sterkt argument for å komme raskere over. I tillegg må en nasjon som ønsker å fremme IT-industrien og kunnskapssamfunnet bygge opp en markedsledende infrastruktur på et så sentralt område. 3.1 Konklusjon Standardiseringsrådet støtter anbefalingen om å gå for alternativ 3+, med unntak av Skatteetaten som mener dette ikke er mulig å gjennomføre i deres organisasjon før 2021 og som derfor ønsker alternativ 2+. 5

6 4 edag, Skatteetaten (informasjonssak) Viveca Liodden og Torstein Hoem presenterte edag prosjektet. Hva prosjektet går ut på, fremdriften i prosjektet og videre arbeid på området. Deres presentasjon ligger vedlagt. Standardiseringsrådet fikk avklart mange ting på området og vi takker for presentasjonen. 5 Standardiseringsrådets forhold til Veikartarbeidet under Skate (informasjonsarbeid) Kristian Bergem presenterte noen tanker som har vært diskutert i Difi i forhold til å knytte sammen arbeidet som skjer i Skate og arbeidet som skjer i Standardiseringsrådet. Skate har utviklet seg fra kun å fokusere på felleskomponenter til nå også å fokusere på samhandling generelt. Ved å rapportere inn planer fra Standardiseringsarbeidet til arbeidsutvalget under Skate, så kan arbeidsutvalget se standarder og felleskomponenter i et helhetlig perspektiv. De ser hvilke planer Standardiseringsrådet har og kan komme med ønskede justeringer sett fra sitt ståsted. De kan også presentere strategiske forslag knyttet til standardisering opp imot Skate for å få fokus på viktige områder for samhandling. Standardiseringsrådet støttet tankene og syntes det var en fornuftig måte å knytte disse to initiativene på. Samhandling i offentlig sektor handler om mye mer enn felleskomponenter, og på denne måten får vi en mer helhetlig og bedre tilnærming til samhandling i offentlig sektor. Standardiseringsrådet støttet at sekretariatet sender over en langtidsplan til arbeidsutvalget under Skate. Kristian Bergem sender ut et utkast til rådsmedlemmene, for innspill fra rådet før det sendes over til sekretariatet for arbeidsutvalget under Skate. 6 Generelt obligatorisk krav om bruk av relevante åpne standarder (beslutningssak) Kristian Bergem presenterte foreløpige tanker Standardiseringssekretariatet har gjort seg i forhold til å inkludere et mer generelt krav til bruk av åpne standarder i tillegg til de krav vi har på avgrensede områder i dag. Presentasjonen ligger vedlagt møtereferatet. Det ble tydeliggjort i hvilken grad det allerede er et obligatorisk krav gjennom arkitekturprinsippene for staten og digitaliseringsrundskrivet, og det ble pekt på at det mangler tydeliggjøring av hva en åpen standard er. Det ble skissert 5 ulike alternativer for å sette krav til bruk av åpne standarder i offentlig sektor og diskutert noen fordeler og ulemper med dette. Et slikt krav blir et strategisk virkemiddel og det er vanskelig å lage en samfunnsøkonomisk konsekvensanalyse over tema. Forslaget ble innledningen til en god diskusjon i rådet der mange sider av saken ble belyst. Det er viktig å være oppmerksom på at kommunene har utarbeidet sine egne arkitekturprinsipper, som ikke er lik de statlige arkitekturprinsippene. I tillegg har de åpnet opp for at ulike kommuner kan skreddersy egen arkitekturprinsipper basert på kommunenes 6

7 generelle. Det vil derfor være bedre å legge inn et krav i starten av forskriften om bruk av åpne standarder enn å legge inn et krav om å benytte de statlige arkitekturprinsippene. Det er allerede en sterk anbefaling i kommunal sektor om å benytte arkitekturprisnippene og åpne standarder og det er et obligatorisk krav for statlig sektor gjennom digitaliseringsrundskrivet. Det å komme med et anbefalt krav i referansekatalogen anses derfor som unødvendig. Det er viktig å greie å beskrive hva en åpen standard er og eventuelt hvilke standardiseringsorganisasjoners standarder som skal vurderes benyttet av virksomhetene. Det ble diskutert i hvilken grad man burde ha klarert og identifisert alle åpne standarder man forventer at virksomheter skal vurdere. Dette er derimot en stor jobb, og det ville i så fall kreve et tredje nivå, som ikke er obligatorisk eller anbefalt, men som kun signaliserer at det er en aktuell åpen standard, som bør vurderes på fritt grunnlag. Det ble problematisert i hvilken grad en leverandør kan stoppe en anskaffelse, fordi man har feilet med å vurdere åpne standarder eller har valgt en leverandør som ikke benytter en åpen standard på området. Det var enighet om at så lenge kravet kun gjelder en vurdering bør ikke det være mulig. Det må tydeliggjøres at et eventuelt obligatorisk krav om å vurdere i hvilken grad åpne standarder er aktuelle for anskaffelsen, blir overstyrt på områder der Referansekatalogen gir spesifikke krav. Viktig å utforme kravet på en måte som gjør at dette får en merverdi. Utfordringen er at man setter krav til noe som er veldig ullent. Umulig for en anskaffer å ha oversikt over alle standarder, som kan være aktuelle på et område. Men man kan forvente at den som skal anskaffe gjør en enklere sjekk om det finnes standarder på området og en vurdering av om aktuelle standarder bør pekes på i anskaffelsen. Det ble også spilt inn betydningen av krav som gjør at alle leverandører til offentlig sektor må benytte en åpen standard. Det vil sikre mindre leverandøravhengighet og gjøre det enklere å bytte leverandør i etterkant. Det ble pekt på at en åpen standard på et område kan ha god markedsutbredelse, men at samme standard på et annet område kan være brukt av kun en leverandør. Det kan derfor ha uønskede effekter om man setter generelle krav til standarder uten å ta hensyn til bruksområdet. Det å melde fra til Difi om hvilke standarder som ikke fungerer i praksis eller blir vurdert egnet. Samt gjennomføre en spørreundersøkelse for å få inn erfaringer fra de som benytter åpne standarder, kan gi verdifull tilbakemelding til Difi i forhold til å vurdere potensielle krav i fremtiden. En slik meldeordning må ikke forveksles med en godkjenningsordning. 6.1 Konklusjon 7

8 Rådet var enig i at sekretariatet går videre med å lage et utkast til generelt obligatorisk krav om å vurdere bruk av åpne standarder ved anskaffelser og utvikling av løsninger, i begynnelsen av forskriften. Sekretariatet skal forsøke å utforme en tekst som kan benyttes til formålet, og sende ut til rådet på høring. 7 Status for standardiseringsarbeidet i Difi (informasjonssak) Kristian Bergem informerte om hvilke utredninger vi har jobbet med den siste tiden og hva vi kommer til å fokusere på i tiden som kommer. Presentasjonen ligger vedlagt. 8 Eventuelt 8.1 Navn på arbeidsgruppene I dag har vi et mandat for arbeidsgrupper under rådet. I praksis er det sekretariatet som gjør jobben med å ta frem grunnlag for møtene i arbeidsgruppene, mens medlemmene kun gir innspill på underlaget og diskuterer. Arbeidsgruppene fungerer derfor i praksis som referansegrupper. For å unngå misforståelser og feil forventninger til det som skal skje i arbeidsgruppene foreslår vi å endre navnet på disse gruppene til referansegrupper. Rådet støtter forslaget, selv om arbeidsgruppenavnet har vært benyttet i lang tid. 8.2 Kommende møter i rådet 16 september november 8