Forutsetninger for fremtidig drift av Felles ressursregister

Transkript

1 Forutsetninger for fremtidig drift av Felles ressursregister (Unntatt offentlighet ihht. offentleglova 21 Dato Versjon Ansvarlig Versjon 1 Gjermund Hartviksen

2 Forutsetninger for fremtidig drift av Felles ressursregister (Unntatt offentlighet ihht. offentleglova 21)

3 Sammendrag BarentsWatch fikk i desember 2015 i oppdrag fra Samferdselsdepartementet å belyse nødvendige forutsetninger for fremtidig drift av et felles ressursregister. Relevant skriftlig materiale som rapporter, prosjektplaner, presentasjoner, systembeskrivelser, møtereferater etc. er samlet inn og gjennomgått og en foreløpig analyse er drøftet med etatene som inngår i brukergruppen. Tilbakemeldingene er tatt hensyn til i den endelige analysen, der hovedpunktene er som følger: Behovet for et verktøy som gir de operative redningsetatene informasjon om tilgjengelige ressurser de kan allokere ved behov, deres kapasitet, status, posisjon, tilgjengelighet og kontaktinfo, er grundig dokumentert i andre kilder. BarentsWatch har satt i gang arbeidet med å utvikle et moderne, databasert register som skal gi etatene dette verktøyet og der ressurseierne selv skal legge inn og vedlikeholde informasjonen. Felles ressursregister er verktøyet som sikrer at denne informasjonen deles kun med de som har et legitimt behov for den i henhold til ressurseiernes ønsker. Ut fra kriterier som mandat/forretningsområde, uttrykt interesse og kapasitet, har tre etater blitt vurdert som aktuelle til å påta seg ansvar for å løse oppgavene knyttet til drift av Felles ressursregister. Konkurranseutsetting har også blitt vurdert og teknisk drift, som omfatter sikker infrastruktur, basis drift og applikasjonsdrift anbefales utlyst som en offentlig anskaffelse. Anbefalingen er gjort ut fra en vurdering av at dette vil gi den beste pris og kvalitet samt gi Felles ressursregister en nødvendig uavhengighet. Det anbefales videre at førstelinje brukerstøtte blir løst gjennom utstrakt bruk av superbrukere i de ulike organisasjonene, og at tredjelinje brukerstøtte kjøpes som høyteknologisk ekspertise. Andrelinje brukerstøtte ses i sammenheng med applikasjonsforvaltning og foreslås løst av BarentsWatch på grunn av deres kunnskap om aktørene, teknisk innsikt i løsningen, synergi med andre prosjekter i regi av BarentsWatch, jfr. felleskomponenter som sikker pålogging og tilgangskontroll, kartløsninger, sporingsfunksjonalitet og sikret samhandling mellom etatene. Den forvaltningsmessige plassering er knyttet til produkteierskap og forankring i etatene. Her er flere løsningen aktuelle, men foreløpig anbefales også denne lagt til BarentsWatch. Det anbefales videre at brukermedvirkningen prioriteres gjennom et styrket brukerforum og at BarentsWatch sin ordinære styringsstruktur foreløpig fungerer som styringsgruppe for prosjektet. En årlig driftskostnad på 6-7 millioner kroner er vurdert opp mot tre alternative gevinstanslag, og denne vurderingen gir en netto nåverdi på mellom 50 og 870 mill med en analyseperiode på ti år. Gitt at BarentsWatch blir bedt om å ta ansvar for driften av systemet i 2016 vil driftsorganisasjonen kunne være operativ i Forutsetninger for fremtidig drift av Felles ressursregister (Unntatt offentlighet ihht. offentleglova 21)

4 Forutsetninger for fremtidig drift av Felles ressursregister (Unntatt offentlighet ihht. offentleglova 21)

5 Innhold Sammendrag... III 1. Oppdragsbeskrivelsen BarentsWatch Bakgrunnen for Felles ressursregister Prinsippene for arbeidet med samfunnssikkerhet Behov for informasjon om eksterne ressurser Løsningsarkitektur Status på utvikling og utrulling Basis funksjonalitet Utvidet funksjonalitet Forutsetninger for drift av systemet Et veldefinert behov Løsningsdesign Drift og forvaltning... 8 Teknisk drift... 8 Applikasjonsforvaltning... 9 Brukerstøtte Forankring og strategisk arbeid Sikkerhet og sårbarhet Oppgaver som skal løses i en driftsfase Teknisk drift Applikasjonsforvaltning Brukerstøtte Forankring og strategisk arbeid Hvem som potensielt kan løse oppgavene fire alternativer Kostnader og gevinster Kostnader Gevinster Verdsatte virkninger Brukergruppe og styringsgruppe Anbefaling Økonomisk og administrative konsekvenser Gjennomføringsplan Referanser Forutsetninger for fremtidig drift av Felles ressursregister (Unntatt offentlighet ihht. offentleglova 21)

6 Forutsetninger for fremtidig drift av Felles ressursregister (Unntatt offentlighet ihht. offentleglova 21)

7 1. Oppdragsbeskrivelsen BarentsWatch fikk i desember 2015 i oppdrag fra Samferdselsdepartementet å belyse nødvendige forutsetninger for fremtidig drift av et felles ressursregister. Departementet ba om å få oversendt utredningen innen 30. mars 2016, en frist som senere ble forlenget til 1. juni Oppdragets ordlyd: Felles ressursregister - oppdrag om utredning Vi viser til møte 14.april 2015 med berørte etater og departementer hvor utvikling av et felles ressursregister ble diskutert, og hvor betydningen av å få fastlagt driftsorganisasjon ble understreket. Justisdepartementet og Samferdselsdepartementet har diskutert hvordan dette arbeidet best bør legges opp og har besluttet å be BarentsWatch i dialog med brukergruppen, utrede spørsmålet. Utredningen bør belyse nødvendige forutsetninger for fremtidig drift av et felles ressursregister i lys av prosjektvisjonen om at registeret skal sørge for at operative etater med ansvar for liv, helse, miljø og materielle verdier, hurtig finner de rette ressursene. Utredningen bør videre inneholde følgende elementer: beskrivelse av oppgavene ved registeret i en driftsfase, med ressursbehov, drøfting og anbefaling av alternative modeller for oppgaveløsing, med budsjett, drøfting av registerets forvaltningsmessig plassering, tilknytningen til BarentsWatch og brukergruppen, anbefalt løsning, økonomiske og administrative konsekvenser forslag til tidsplan for gjennomføring Utredningen bes oversendt innen 30. mars Arbeidet med utredningen på pågått siden januar 2016 og er utført av ansatte i BarentsWatch. Skriftlig materiale som er relevant for utredningen ble samlet inn og gjennomgått, eksempelvis rapporter, prosjektplaner, presentasjoner, systembeskrivelser, møtereferater etc. Kun deler av prosjektbeskrivelsen for Felles ressursregister (BarentsWatch, 2015) er inkludert i dokumentet. For øvrig følger strukturen i store trekk de spørsmålene departementet har bedt om skulle bli belyst. Etter at det forelå en foreløpig analyse ble etatene som har deltatt i brukergruppen kontaktet og forespurt om å ta et møte for å få deres innspill til utredningen. Forespørselen gikk til direktørnivået i HRS, Kystverket, DSB, og Politidirektoratet og med disse har vi gjennomført gode møter og fått tilbakemelding på utkast til rapport som har blitt presentert. Rapporten har gjennomgått flere iterasjoner med tilbakemelding internt i BarentsWatch og fra etatene. 2. BarentsWatch BarentsWatch er et samarbeid mellom 10 departementer med mandat til å organisere og gjøre tilgjengelig data, informasjon og kunnskap fra et trettitalls ulike statlige etater og forskningsinstitusjoner. Dette brede mandatet har gjort det mulig, i tett samarbeid med etatene, å utvikle konkrete tjenester som henger sammen i er et helhetlig system for å samle, utvikle og dele informasjon, og for å overvåke de norske hav- og polare områdene, og understøtte våre interesser i nordområdene. Kystverket er oppnevnt som vertsetat for BarentsWatch og ett av systemene som er under utvikling innenfor disse rammene er Felles ressursregister. Forutsetninger for fremtidig drift av Felles ressursregister (Unntatt offentlighet ihht. offentleglova 21) Side 1 av 23

8 3. Bakgrunnen for Felles ressursregister Siden oppstarten av BarentsWatch i 2012 har behovet for å utvikle et felles ressursregister vært trukket frem som en av de oppgavene Barentswatch burde løse. Særlig har Hovedredningssentralene (HRS) etterlyst et verktøy som sikrer etaten oppdatert informasjon om ressurser sentralen kan allokere ved behov. Men også andre etater, eksempelvis Kystverket, trenger ofte eksterne ressurser ved oljevernaksjoner og Gjørvkommisjonen påpekte i sin rapport etter 22. juli at politiet i sin aksjon ikke hadde fullgod oversikt over tilgjengelige ressurser som kunne vært satt inn ved Utøya (NOU 2012: 14, s 134). Operativ ekspertgruppe BarentsWatch oppsummerer etatenes behov for å dele slik ressursinformasjon i rapporten Overordnet behovsanalyse av BarentsWatch Lukkede Tjenester (Bjørsvik et. al., 2014) 1. Dette var noe av bakgrunnen for at Nærings- og fiskeridepartementet i proposisjon til Stortinget for budsjettåret 2014 listet opp Felles ressursregister som en av de oppgavene BarentsWatch skulle prioritere i 2014: Satse på å starte den nye tjenesten felles ressursregister i samarbeid med blant andre Direktoratet for samfunnssikkerhet og beredskap og Hovedredningssentralene (Prop. 1 S ( ), s. 135). Etter å ha drøftet med de viktigste etatene som har et operativt ansvar for å redde liv, helse, miljø og materielle verdier om hvilke behov tjenesten burde dekke, kom en frem til en første liste med funksjonelle og ikke-funksjonelle krav. En brukergruppe med representanter fra HRS, Kystverket, politiet og DSB ble opprettet og Barentswatch inngikk en flerårig rammeavtale med Steria AS om å gjøre den tekniske utviklingen av systemet, med oppstart av første avrop i august Dermed var utvikingsprosjektet Felles ressursregister i gang, se upublisert prosjektbeskrivelse fra BarentsWatch (2015) Prinsippene for arbeidet med samfunnssikkerhet For å forstå nødvendigheten av å dele informasjon om ressurser mellom etatene, kan det være lurt å se litt på noen prinsipper som ligger til grunn for arbeidet med samfunnssikkerhet og organiseringen av redningsberedskapen her i landet, slik Samferdselsdepartementet (2015) har beskrevet dem: 1. Ansvarsprinsippet betyr at den myndighet eller virksomhet som til daglig har ansvaret for et område, også har ansvaret for forebygging, beredskapsplanlegging og håndtering innen det samme området. 2. Likhetsprinsippet betyr at den organisasjonen man opererer med under uønskede hendelser skal være mest mulig lik den organisasjonen man har til daglig. Likhetsprinsippet er en utdyping av ansvarsprinsippet ved at det understreker at ansvarsforholdene internt i virksomheter og mellom virksomheter ikke skal endres i forbindelse med håndtering av uønskede hendelser. 3. Nærhetsprinsippet betyr at uønskede hendelser organisatorisk skal håndteres på et lavest mulig nivå. Nærhetsprinsippet gjelder ikke ved sikkerhetspolitiske kriser. 4. Samvirkeprinsippet innebærer at myndigheter og virksomheter har et selvstendig ansvar for å sikre et best mulig samvirke med relevante aktører i arbeidet med forebygging, beredskapsplanlegging og håndtering av uønskede hendelser. Spesielt samvirkeprinsippet har siden 1970-tallet bidratt til at redningstjenesten må kunne sies å ha fungert svært godt, jfr. Bjørsvik et. al. (2014). For redningstjenesten v/hrs og Lokale redningssentraler (LRS) innebærer samvirkeprinsippet at alle offentlige etater som disponerer ressurser egnet for søk, redning og annen hjelpeinnsats, plikter å bidra med personell og materiell ved naturkatastrofer, ulykker og redningsaksjoner, både i hendelser og øvelser. Dette gjelder kommunale, fylkeskommunale og statlige etater som i tillegg plikter å stille ulike rådgivningsfunksjoner og redningsrelevante data mm. kostnadsfritt til disposisjon for redningstjenesten. Også private og frivillige organisasjoner og virksomheter plikter å stille relevante ressurser til rådighet, men da mot å få dekket påløpte kostnader. 1 Unntatt offentlighet Forutsetninger for fremtidig drift av Felles ressursregister (Unntatt offentlighet ihht. offentleglova 21) Side 2 av 23

9 3.2. Behov for informasjon om eksterne ressurser HRS og LRS er eksempler på etater som ikke selv er satt opp med tilstrekkelig mengde redningsressurser for alle redningstilfeller og som dermed er avhengig av eksterne ressurser. Men også andre operative etater har av og til behov for å få tilgang til ressurser de ikke disponerer selv, eksempelvis gjelder det brannetaten, interkommunale utvalg mot akutt forurensning (IUA) og Kystverket. Kystverkets beredskapsorganisasjon har som oppgave å forebygge og identifisere akutt forurensning og å påse at ansvarlig forurenser iverksetter nødvendige tiltak når akutt forurensning inntreffer. Dersom ansvarlig forurenser ikke klarer å gjennomføre nødvendige tiltak, kan Kystverket aksjonere på vegne av skadevolder. I praksis dreier dette seg om innsats mot oljeutslipp fra skip og skipsvrak eller ukjente kilder. Det vil også si at dersom en kjent og ansvarlig forurenser ikke selv er i stand til å aksjonere, kan Kystverket om nødvendig overta aksjonsansvaret. Slike aksjoner kan være kompliserte og ressurskrevende. Felles for disse operative etatene er at de har beredskap 24/7/365. Enten det er snakk om redningsaksjoner, akutt forurensning eller andre ulykker, vil tidsaspektet være kritisk for å kunne begrense skaden. Etatene har derfor uttrykt et stort behov for å ha oversikt over alt av lett tilgjengelige ressurser som kan benyttes i en aksjon. Å ha et register over tilgjengelige beredskapsressurser er helt essensielt for å kunne finne, velge ut og alarmere de nærmeste og beste ressurser i en aksjon, det være seg redningsaksjon, akutt forurensning eller andre hendelser. Måten etatene har løst dette er gjennom personlig kjennskap til andre ressurseiere, gjennom manuelt å ajourføre forskjellige lister over tilgjengelige ressurser og gjennom å kontakte andre ressurseiere via telefon når de har behov om hjelp. Det vanlige er at lister skrives ut på papir og sendes pr post eller som vedlegg til e- post mellom ressurseier og ressursbruker. Selv om data om egne ressurser gjerne er lagret på digital form i et regneark, Word-dokument eller lignende, er det altså ingen kommunikasjon mellom registrene og dermed i svært liten grad liten grad noen utveksling av søkbar informasjon mellom etatene. Ressursbrukeren vil da ikke kunne søke opp ønsket ressurs og risikerer å måtte basere seg på informasjon om aktuelle ressurser som ikke er oppdatert. En ressurs kan siden sist ha byttet eier, flyttet seg fysisk, endret kontaktinformasjon, midlertidig være ute av drift eller av andre årsaker ikke være tilgjengelig eller mulig å få tak i, noe som vil forsinke prosessen med å få tilgang på relevante ressurser. HRS drifter eksempelvis sitt eget register over om lag ressurser der redningslederne etter beste evne oppdaterer informasjon andre organisasjoner eier, når ny informasjon foreligger. Det går ofte bra men er ikke optimalt. I samtaler med etatene har det blitt nevnt eksempler på at ressurseiere har rapportert sine båtressurser inn til en redningsetat og åpenbart trodd at dermed visste hele Beredskapsnorge at vedkommende båt kunne kontaktes ved behov, men uten at dette var tilfelle. Ressursoppdatering basert på annenhånds informasjon forringer med andre ord datakvaliteten og manuelle rutiner for å dele ressursinformasjonen gjør at det går unødig mye arbeidstid med til å oppdatere samme data flere steder. En samfunnsøkonomisk bedre løsning vil være å oppdatere informasjonen ett sted, helst så nært ressurseieren som mulig, og så dele den oppdaterte informasjonen med de som har legitim interesse av den. Behovet for en forbedret håndtering av ressursinformasjon har for øvrig blitt grundig dokumentert av forprosjektet til NARRE (Røang og Villanger, 2000), i prosjektforslaget Nasjonalt ressursregister for redning og beredskap - RESSREG (Direktoratet for Samfunnssikkerhet og beredskap, 2013) og av Bjørsvik et. al. (2014). 4. Løsningsarkitektur I arkitekturen for Felles ressursregister opereres det med to ulike roller, Ressursbrukere og Ressurseiere. Ressursbrukere er offentlige etater som har behov for å søke opp ressurser og anvende dem i operasjoner. Ressurseiere er etater, frivillige organisasjoner og private selskaper og personer som disponerer ressurser som er etterspurt av ressursbrukere. I utgangspunktet så en for seg at kun ressursbrukere (offentlige etater) skulle Forutsetninger for fremtidig drift av Felles ressursregister (Unntatt offentlighet ihht. offentleglova 21) Side 3 av 23

10 ha lesetilgang til andre organisasjoners ressurser, men underveis ble det klart at også ressurseiere kan ha behov for å se andre organisasjoners ressurser, for eksempel på tvers av de frivillige organisasjonene innenfor ett og samme distrikt. Skillet mellom ressursbruker og ressurseier, som i utgangspunktet var rimelig klart, har dermed etter hvert blitt noe utvisket. Nytten av å gjøre dette skillet har også blitt mindre da tilgangen til hver enkelt ressurs defineres gjennom en egen modul som styrer tilgangsreglene. Begrepene Ressursbruker og Ressurseier brukes imidlertid fortsatt men mest av pedagogiske årsaker. For at en etat eller organisasjon skal bli en godkjent aktør i systemet kreves det at en person med myndighet på vegne av sin organisasjon, undertegner en standardavtale med BarentsWatch der forventningene til de ulike partene er beskrevet. Dette gir tilgang til systemet gjennom en webapplikasjon (Min Side i Figur 1), eller gjennom organisasjonens eget fagsystem via et maskinelt grensesnitt. Organisasjonen kan på den måten registrere data om sine ressurser inn i systemet og vedlikeholde dem der. Ressursbrukere kan i tillegg få tilgang til ressurser som andre aktører har registrert. Hvilke data som den enkelte ressursbruker kan se, reguleres av samarbeidsformen som er satt opp i systemet mellom ressursbrukeren og ressurseierne. Eksempler på hva denne samarbeidsformen kan regulere er: Hvilken informasjon om egne ressurser aktøren ønsker å vise til andre aktører. Hvilken informasjon om andres ressurser aktøren er interessert i å få lesetilgang til. Hvor ofte aktøren ønsker at ressurseier skal validere informasjonen han har lesetilgang til. Figur 1 viser på et overordnet nivå hvordan løsningen fungerer funksjonelt. Figur 1 Overordnet arkitekturskisse Felles ressursregister. Oppe til venstre illustreres en ressurseier som benytter webgrensesnittet til å vedlikeholde sine data. Han har også et samarbeid med begge de to ressursbrukerne som er illustrert til høyre i figuren, slik at disse har lesetilgang til hans data. Nede til venstre vises en annen måte å tilgjengeliggjøre informasjon om egne ressurser. Her registrer ressurseieren data i sitt lokale system, som så pusher dataene videre til Felles ressursregister gjennom et maskinelt grensesnitt. På samme måte kan ressursbrukerne til høyre velge å vedlikeholde sine data i Felles ressursregister ved å bruke webgrensesnittet eller eget fagsystem. Forutsetninger for fremtidig drift av Felles ressursregister (Unntatt offentlighet ihht. offentleglova 21) Side 4 av 23

11 5. Status på utvikling og utrulling Sommeren 2016 er det utviklet et teknisk rammeverk for Felles ressursregister som støtter: Deling av ressursinformasjon i et selvbetjent samarbeid mellom ressurseier og ressursbruker der aktørene selv styrer hva de deler og med hvem Sikker autentisering av brukere gjennom ID-porten 2 Fokus på gjenkjennelige datastrukturer for dem som skal vedlikeholde data Søkefunksjonalitet for dem som skal søke opp og bruke ressursene Maskinelt grensesnitt mellom enkelte parter med egne fagsystem Forenklet støtte for oppfølging av ressurseier i tilfelle ressurser trenger validering Multi-site løsning for å redusere sårbarheten i tilfelle bortfall av Internett Pålogging med autentisering fra eget fagsystem for å unngå plunder med kodebrikke, time-out etc. Mange etater og organisasjoner har vært involvert og gitt sine innspill: Hovedredningssentralene kjører test av systemet i parallell med gammel løsning. Norske Redningshunder, NAKs Flytjeneste, Røde Kors, Kystverket og en mengde private ressurseiere vedlikeholder helt eller delvis sine ressurser som er relevant for andre ressursbrukere gjennom systemet Basis funksjonalitet Felles ressursregister videreutvikles gjennom at løsningen kvalitetssikres, ny funksjonalitet utvikles og flere ressurseiere og ressursbrukere rulles inn. Herunder jobbes det med å: Videreutvikle løsningens kjernefunksjonalitet Utvikle aktørtilpassede, webbaserte brukergrensesnitt for nye ressurseierne Utvikle tilsvarende grensesnitt for ressursbrukerne Der det er formålstjenlig utvikles det maskingrensesnitt for kommunikasjon mellom Felles ressursregister og ressurseiernes interne system Automatisere undertegning av standardavtalen som regulerer tilgang til Felles ressursregister Utvikle funksjonalitet som på en fleksibel måte minner ressurseier på å verifisere informasjonen som er lagt inn om egne ressurser Ferdigstille integreringen av Felles ressursregister hos HRS Utvikle løsning for Kystverket og teste ut med tanke på full integrasjon tilsvarende som for HRS Motivere nye aktører til å kople seg på systemet Arbeide for å få opp en løsning lokale redningssentraler kan ha nytte av, samt andre offentlige etater, eksempelvis de interkommunale utvalgene mot akutt forurensning (IUA) Utvidet funksjonalitet Felles ressursregister er utviklet primært med tanke på å dekke behovene for å registrere, vedlikeholde og dele informasjon og å søke opp informasjon om ressurser. Basisfunksjonalitet nevnt over dekker dette. Parallelt med Felles ressursregister utvikler BarentsWatch et system for sporing og samhandling mellom operative etater og noe av funksjonaliteten er tatt frem med tanke på å være gjenbrukbare felleskomponenter. Dermed vil Felles ressursregister fremover kunne dra nytte av utviklingssamarbeid med andre BarentsWatch prosjekter. 2 ID-porten er en felles innloggingsløsning til offentlige tjenester på nett, og tilbyr sikker innlogging ved bruk av elektronisk ID. Forutsetninger for fremtidig drift av Felles ressursregister (Unntatt offentlighet ihht. offentleglova 21) Side 5 av 23

12 En slik felleskomponent er kartløsningen med integrerte posisjonsdata fra blant annet AIS 3. Løsningen som er utviklet i Sporingsprosjektet er betydelig mer gjennomarbeidet enn den enkle kartløsningen Felles ressursregister tilbyr og etter planen vil den bli utvidet med posisjonsdata fra Nødnett og andre kilder. Tilgangskontroll og tilgangsstyring er andre felleskomponenter som alle systemene vil ha nytte av. For mange tjenester BarentsWatch utvikler, er kontroll over hvem som har tilgang til hva, ansett som svært viktig. En egen IAM 4 modul er derfor under utvikling og Felles ressursregister vil profitere på å ta denne i bruk når den er ferdig. En samhandlingsløsning under utvikling for andre formål er også relevant for beredskapsetatene ved at den kan vise aktørene et felles situasjonsbilde av aksjonen og gi dem anledning til å kommunisere internt og eksternt om relevante ressurser. Dette forutsetter imidlertid at kommunikasjonen mellom etatene foregår på en sikret måte, noe etatene mangler i dag. Derfor har BarentsWatch tatt mål av seg å etablere et ende-tilende kryptert etatsnettverk som sikrer kommunikasjon mellom operative etater. Servernodene som er plassert i de to HRS-lokasjonene (multi-site løsning) kan ses på som starten på dette. Etter planen skal etatsnettverket utvides til andre operative etatene. Med dette på plass vil aktørene enkelt og sikkert utveksle sensitivt materiale seg imellom, for eksempel kan HRS og politiet utveksle data om personer om bord på et fartøy i nød på en sikret måte. Av andre funksjoner som er utviklet, og som ikke faller inn under basis funksjonalitet, er en løsning for å forberede utkalling av ressurser, illustrert av følgende case: HRS blir varslet om at det har gått et snøras som kan ha tatt skiløpere og ønsker at et SeaKing helikopter skal plukke opp lavinehundekvipasjer på turen til rasstedet. HRS søker opp aktuelle hundeførere i Felles ressursregister og sender dem en SMS og ber de bekrefte sin posisjon og om de er tilgjengelig for oppdrag ved å klikke på en lenke som er lagt inn i meldingen. Ut fra responsen kan HRS velge ut de ekvipasjene som egner seg best og avtale med helikopteret hvor disse kan plukkes opp. I dette tilfellet er tidsfaktoren kritisk og Felles ressursregister bidrar til en rask identifisering av egnede ressurser som kan settes inn. Oppsummert vil felleskomponenter fra andre prosjekter i BarentsWatch kunne bidra med ny funksjonalitet som aktører i dag mangler. Om aktørene ikke skulle ønske slik utvidet funksjonalitet, er den konfigurerbar og kan dermed velges bort i enkelte instanser av løsningen. 6. Forutsetninger for drift av systemet I departementets oppdragsbrev blir BarentsWatch bedt om å belyse nødvendige forutsetninger for fremtidig drift av et felles ressursregister i lys av prosjektvisjonen om at registeret skal sørge for at operative etater med ansvar for liv, helse, miljø og materielle verdier, hurtig finner de rette ressursene. Det er særlig fire forutsetninger som må på plass for at Felles ressursregister skal kunne nærme seg visjonen som er valgt for prosjektet: 1. Klarhet i hvilket problem det er som skal løses 2. Hvilken tilnærming en tar til problemløsningen systemarkitektur og utviklingsmetode 3. Hvordan en sikrer at det som så langt er utviklet blir tatt vare på drift og forvaltning 4. Hva som skal til for at systemet holdes levende og til nytte også på lengre sikt (5-10 år). 3 AIS er et Automatisk Identifikasjons System og et antikollisjonshjelpemiddel som er innført av FNs sjøfartsorganisasjon IMO for å øke sikkerheten for skip og miljø, samt forbedre trafikkovervåking og sjøtrafikktjenester. 4 Identity Access Management (IAM) bidrar til å holde kontroll både på hvem som bruker systemet (autentisering) og hva brukerne har lov å gjøre (autorisering). Forutsetninger for fremtidig drift av Felles ressursregister (Unntatt offentlighet ihht. offentleglova 21) Side 6 av 23

13 6.1. Et veldefinert behov En første forutsetning for at et system skal kunne utvikles til å bli et godt og nyttig verktøy er at en, når en går i gang, har et noenlunde klart definert formål med systemet. I dette tilfelle synes alle å være av den oppfatning at Beredskapsnorge har et stort behov for å ha en felles oversikt over rednings- og beredskapsressursene med beskrivelse av deres kapasiteter og tilgjengelighet, inklusiv kontaktdata. At denne informasjonen skal være oppdatert og tilgjengelig for alle aktører med et tjenstlig behov for å se den, er i realiteten en forutsetning for at samvirkeprinsippet skal fungere i praksis. Datamengden i systemet bør heller ikke være for omfattende men primært begrense seg til å vise ressurser som andre aktører etterspør. Løsningen skal med andre ord være et felles ressursregister med trykk på FELLES, og dekke et behov som funksjonelt sett kan sies å være todelt: 1. Ressurseiere må kunne registrere, vedlikeholde og dele informasjon om egne ressurser med andre. 2. Ressursbrukere må kunne søke opp informasjon om andres ressurser og prosessere denne i en felles applikasjon eller i eget fagsystem Løsningsdesign Det neste spørsmålet en kan stille er hva som er den grunnleggende logikken som skal dekke dette behovet og hvordan løsningen arkitekturmessig skal se ut. Felles ressursregister er bygd på arkitekturen vist i Figur 1 og utviklet innenfor et såkalt smidig (Agile) rammeverk. Smidig utvikling skiller seg fra fossefallsmodeller ved at den fremhever 5 Personer og samspill (fremfor prosesser og verktøy) Programvare som virker (fremfor omfattende dokumentasjon) Samarbeid med kunden (fremfor kontraktsforhandlinger) Å reagere på endringer (fremfor å følge en plan) Flere store og komplekse systemer er utviklet smidig og metoden preges av sterk brukermedvirkning og relativt hyppige leveranser av funksjonalitet, noe som gjør at systemet gror frem stegvis, både i funksjonalitet og dataomfang. BarentsWatch normale arbeidsmetode, som går ut på at en hurtig skaffer seg innsikt i brukerbehovene, utvikler, bygger, tester og så setter ny funksjonalitet i produksjon, i tillegg til den potensielt store mengden av ressursbrukere/-eiere og det store mangfold av teknologisk modenhet blant etater og brukere, tilsa at arbeidet burde organiseres smidig. Smidigprinsippet om at tidlig og fortløpende brukerinteraksjon er mye mer verdifullt enn detaljerte spesifikasjoner og planverk, har vært fulgt i utviklingsperioden ved at utviklingsteamet har benyttet en tilnærmet Kanban 6 metode. Felles ressursregister har ikke tatt mål av seg å erstatte etatenes eksisterende fagsystem (som i tilfelle HRS er SARA). Etatene kan velge mellom å søke opp mulige ressurser, deres posisjon og status og få dem presentert i kart eller som lister i et webgrensesnitt, eller de kan gjøre det direkte fra sitt eget fagsystem via et maskinelt grensesnitt. Dette gir en fleksibilitet ved at organisasjoner som mangler egne system kan bruke funksjonalitet i Felles ressursregister mens etater som har egne fagsystem kan importere data og bearbeide dem videre der. Videre skal Felles ressursregister i utgangspunktet ikke rokke ved ansvarsforholdene i Beredskapsnorge, men understøtte samarbeidet som er etablert mellom organisasjonene. Felles ressursregister er utviklet som en modul med standard grensesnitt som de operative etatene kan kople sine beslutningsstøttesystem, fagsystemer, operative system etc. opp mot. Løsningen legger opp til at ressurseierne selv skal oppdatere egne data og selv bestemme hvilke etater som skal få lesetilgang til disse. Autentisering ved bruk av ID-porten og autorisasjon av brukernes datatilgang, er viktige deler av systemet. Systemet støtter også at redningslederne i HRS får direkte tilgang til Felles 5 Manifestet for smidig programvareutvikling, se Besøkt A brief introduction to kanban, se Besøkt Forutsetninger for fremtidig drift av Felles ressursregister (Unntatt offentlighet ihht. offentleglova 21) Side 7 av 23

14 ressursregister fra sitt fagsystem når de er på jobb i HRS sine lokaler. HRS har hele tiden vært tydelig på at de for all del ønsker å unngå omstendelige påloggingsrutiner når det er som mest hektisk, og problemet er løst uten at det har gått på bekostning av sikkerheten i systemet. Tilsvarende løsning er aktuell for andre etater, for eksempel politiet. Lokalt ansvar for vedlikehold av data er viktig men erfaringsmessig utfordrende. For at dette skal fungere i praksis for Felles ressursregister er det for hver ressurs satt opp et standardintervall for hvor hyppig status på ressursene bør oppdateres/valideres. Når fristen nærmer seg vil det gå ut en påminnelse til ressurseieren om at ressursbrukerne snart forventer en validering. Det er i tillegg laget støtte for at ressurseiere og ressursbrukere kan bli enige om å justere intervallet mellom hver validering dersom dette er ønskelig. En begrensning er at det foreløpig ikke er mulig å allokere ressurser og i etterkant av en operasjon frigi dem og foreta økonomisk oppgjør. Dette kan så langt gjøres bedre i andre systemer, men om etatene skulle melde et behov for å gjøre det i Felles ressursregister, er systemet mulig å utvide. Fra starten av prosjektet var blant annet HRS helt klar på at systemet måtte utvikles til å bli et verktøy for bruk i aksjoner både på land og hav. Dette har også prosjektet tatt høyde for når det gjelder datamengde og datatyper. Men for å kunne arbeide smidig ble et begrenset antall etater valgt ut og prioritert. Hvilke dette skulle være ble gjort ut fra relevansen for Barentswatch på det tidspunkt, etatenes egne tilbakemeldinger på om de ønsket å bidra og ut fra forventninger om hvor viktig deres bidrag ville være med hensyn til å få frem mangfoldet den endelige løsningen måtte ta hensyn til. Ut fra disse kriteriene er det HRS, Kystverket, NAKs flytjeneste, Norske Redningshunder og enkelte små private firma med ressurser HRS har benyttet, som i størst grad har bidratt. Som en del av prosjektet er det etablert en nødvendig infrastruktur for å understøtte tjenesten som leveres. Når tjenesten settes i produksjon for ressursbrukere må brukerne være forsikret om at denne infrastrukturen fortsatt vil være sikker, robust og fleksibel. At det kontinuerlig kommer ny teknologi på markedet gjør at prisen på infrastrukturtjenester ventelig vil gå ned. Men Felles ressursregister vil også ha behov for videreutvikling og innovasjon, noe som vil virke ekspansivt. Hvordan disse to hensynene lar seg forene 7 i måten systemet blir tatt videre på kan bli et suksesskriterium for løsningen. Prosjektets tilnærming til design av Felles ressursregister har vært presentert for mange interessenter, selv om ikke samtlige organisasjoner i Beredskapsnorge, av praktiske årsaker, har fått seg forelagt prosjektet. Oppsummert har tilbakemeldingene vært at det tekniske designet er fornuftig anlagt Drift og forvaltning Den tredje forutsetningen er at det som er utviklet så langt, både applikasjonen og dataene, blir driftet og forvaltet på en god måte. Brukergruppen ville tidlig i prosjektet forsikre seg om at systemet ville bli driftet ut over utviklingsperioden. Også for nye etater som vurderer å investere tid og penger i å kople seg på systemet betyr det mye at de kan føle seg sikre på at systemet blir tatt vare på i de kommende årene. Drift og forvaltning av et system innebærer minst tre forskjellige oppgaver som hører sammen. En kan skille mellom teknisk drift av systemet, applikasjonsforvatning og brukerstøtte. I tillegg kommer oppgaven med å holde systemet vitalt gjennom å følge med på endringer i brukermassen og utvikle ny funksjonalitet som kan forlenge levetiden på systemet, noe som omhandles under den fjerde forutsetningen. Dette kan fremstilles i en lagdelt struktur der en oppgave på et nivå blir påvirket av hvordan en underliggende oppgave er løst. Teknisk drift Teknisk drift innebærer for det første at applikasjonen kjøres på en infrastruktur av maskin- og basis programvare som er robust, stabil og med forutsigbar ytelse. Infrastrukturen må videre tilby gode sikkerhetsløsninger for brukerne, blant annet ivareta kravene til tilgjengelighet, åpenhet og samhandling samt 7 IT-konsulentselskapet Gartner beskriver denne tilnærmingen som bimodal IT. Forutsetninger for fremtidig drift av Felles ressursregister (Unntatt offentlighet ihht. offentleglova 21) Side 8 av 23

15 redusere sårbarheten og styrke person- og identitetsvernet. Tilgang på avbruddssikker strøm, kjøling, nettverk, fysisk sikring og overvåkning av infrastrukturen inngår typisk som tjenester en driftsorganisasjon må tilby. Slik basis drift kan gjøres innomhus men det har etter hvert blitt ganske vanlig blant både private og offentlige aktører å sette dette ut på anbud fordi oppgaven ikke er å anse som en del av kjernevirksomheten. Da velges leverandør ut fra kriteriene over men en tar gjerne med i vurderingen hvorvidt løsningen kan skalere (det vil si takle endring i antall aktører, brukere og bruksvolum) og eventuelt andre behov for ulike typer fleksibilitet. Kompetanse hos tilbyderne er viktig men ofte vanskelig å måle selv om en i noen grad kan bruke renommé. Pris og oppetidsgaranti er selvfølgelig også avgjørende kriterier som lar seg nedfelle i en tjenestegaranti (SLA). Forenklet kan en si at oppgaven til Basis teknisk drift er å tilby infrastruktur til og med operativsystemnivået. Ideelt sett kan dette gjøres av teknikere uten kjennskap til hvilke applikasjoner som kjører der. På nivået over ligger applikasjonsdrift. Dette krever noe mer kjennskap til applikasjonen da det omfatter overvåking av systemoppførsel og bruken av løsningen. At løsningen fungerer uten forstyrrelser og avbrudd tyder på en vellykket applikasjonsdrift. For Felles ressursregister er det naturlig å stille krav til SLA for teknisk drift av systemet. HRS har også gitt uttrykk for at de vil stille strenge krav til oppetid, stabilitet og robusthet for at systemet skal bli innfaset, noe som i praksis betyr døgnkontinuerlig beredskap 24/7. For å sikre seg mot bortfall av tjenesten er det for HRS etablert egne noder innomhus både i HRS Nord og HRS Sør replikert mot hovedserveren. Ved brudd i internettforbindelsen kan redningslederne likevel ha full tilgang til tjenesten unntatt andre aktørers oppdateringer gjort etter at internettforbindelsen gikk ned. Dersom en ønsker en ytterligere sikring er det mulig å utvide løsningen med en frittstående backup-løsning, med nyere men ikke alltid hundre prosent oppdaterte data, som redningslederne kan starte dersom systemet av eller annen grunn kompromitteres eller er ute av drift. Applikasjonsforvaltning På nivået over applikasjonsdrift ligger applikasjonsforvaltning. Her ligger ansvaret for å rulle ut nye versjoner av applikasjonen, overvåking av bruk og ytelse på applikasjonsnivå, enkel videreutvikling, vedlikehold, samarbeid med aktørene om røkting av datagrunnlag med mer. En annen viktig del av applikasjonsforvaltning er å utvikle prosedyrer for å oppdage sikkerhetsbrudd og å sette i verk tiltak dersom dette skjer. Sammenlignet med teknisk drift stiller applikasjonsforvaltning større krav til kompetanse hos de ansatte. På den ene siden kreves det tilstrekkelig kunnskap om teknologi og drifting av systemet, på den andre siden er det viktig hele tiden å ha et brukerperspektiv der en kjenner bruken av systemet og kan gi råd og svare på spørsmål i en andrelinjes brukerstøtte. Felles ressursregister vil, etter hvert som flere aktører leverer data og nye fagsystem blir integrert med systemet, kunne bli en utfordrende applikasjon å forvalte, da det vil kreve kjennskap til et stort antall aktører. Også på dette nivået er det naturlig å stille krav til SLA, noe som igjen må tilpasses de underliggende avtaler med teknisk drift. Trolig innebærer det en eller annen form for døgnkontinuerlig beredskap 24/7. Forutsetninger for fremtidig drift av Felles ressursregister (Unntatt offentlighet ihht. offentleglova 21) Side 9 av 23

16 Brukerstøtte Brukerstøtte er nødvendig å yte, også på flere nivå, men det er også en potensielt stor kostnadsdriver. Overordnet vil det derfor være nødvendig å forsøke å styre brukernes forventninger til brukerstøtten rimelig strengt og formidle at det vil kunne bli nødvendig å prioritere enkelte brukergrupper foran andre. På laveste nivå er det lagt opp til at superbrukere i den enkelte organisasjon kan registrere nye brukere, foreta opplæring i bruk av systemet og være ressurspersoner i egen organisasjon. Ut fra et kostnadsperspektiv er det spesielt viktig at behovet for sentral førstelinjestøtte holdes så lavt som mulig når antallet brukere øker. For ressurseierne, som primært bruker systemet til å vedlikeholde sine data, vil det trolig være tilstrekkelig å ha tilgang til superbrukere i egen organisasjon, mens ressursbrukerne, dvs. etater som skal søke opp og alarmere ressurser, må få anledning til å kontakte en mer sentralisert brukerstøtte ved behov. Ressursbrukere gis derfor muligheten til å kontakte andrelinjes brukerstøtte direkte, på samme måte som superbrukere kan det. En fordel med Felles ressursregister slik løsningen er implementert, er at det ikke introduserer en ny bruker-id og et nytt passord for brukeren å holde rede på. Innlogging via Bank-ID eller lignende er noe brukerne allerede er fortrolige med og dermed er én type henvendelser til brukerstøtte ryddet vekk. Andrelinje brukerstøtte til de operative etatene og til superbrukerne hos ressurseiere er en funksjon som bør bli utført sentralt. Hvordan denne brukerstøtten skal utøves må detaljeres nærmere men både telefon, e-post, nettprat, sosiale medier og fysisk tilstedeværelse må bli vurdert. Teknisk problemløsing er kompetansemessig knyttet til applikasjonsforvaltning og disse to funksjonene kan med fordel ligge samlet og gjerne bli ivaretatt av de samme personene. Kjennskap til teknisk løsning og til brukerne gjør det mulig for de som skal betjene brukerne på dette nivået å ha tilstrekkelig kunnskap og myndighet til å ta en avgjørelse om eventuell videre eskalering til tredjelinje brukerstøtte. Tredjelinje brukerstøtte ligger i å involvere høykompetanse på løsningen. Dette vil kunne bli dyrt og derfor bør en slik skalering ikke gjøres av brukerne direkte men gjennom andrelinjetjenesten. En siste oppgave som hører med i brukerstøtte er å utvikle FAQ-databaser som inneholder tidligere henvendelser, kjente problem og tilhørende fiks-er og måter å komme rundt problemene på Forankring og strategisk arbeid En fjerde forutsetning for fremtidig drift er den strategiske røktingen av systemet. Dette innebærer blant annet å sørge for at inngåtte avtaler følges opp og fornyes/erstattes, at en tar inn over seg nye behov fra brukerne og utvikler ny funksjonalitet og at nye aktører integreres med systemet. Stikkord under denne forutsetningen er retningsangivelse og styring, blant annet gjennom å legge til rette for brukermedvirkning, at styringsgruppen bidrar til forankring hos aktørene, at kostnadene holdes under kontroll samt at en sørger for en forutsigbar finansiering. Et suksesskriterium for prosjektet er hvorvidt ressurseierne faktisk gjør den nødvendige jobben med å holde ressursoversikten oppdatert. Mens det er grunn til å tro at private aktører og de frivillige organisasjonene har stor motivasjon for dette, da deres synlighet overfor ressursbrukerne er selve grunnlaget for at de skal bli brukt, kan det vise seg å bli en større utfordring å få offentlige ressurseiere til å holde informasjon om sine ressurser oppdatert. Løsningen har innebygd funksjonalitet for å minne ressurseierne på at fristen for validering nærmer seg men dersom det skulle vise seg at så ikke skjer bør de aktuelle tilsynsmyndigheter kunne pålegge sine enheter dette. Selv om Felles ressursregister fra 2016/17 må forventes å ha gått fra utviklingsfase til driftsfase betyr ikke det at behovet for videreutvikling faller bort. Som tidligere nevnt tar smidig systemutvikling høyde for at det skal være mulig å holde en god og kostnadseffektiv drift samtidig som systemet videreutvikles med kort vei mellom behovsforståelse utvikling drift. En annen oppgave på dette nivået går derfor ut på å vurdere de ulike behovene etatene uttrykker og å foreta en prioritering mellom dem. Dette er en aktivitet som i større grad avhenger av aktørenes strategiske tilstedeværelse enn det de andre driftsoppgavene krever. Oppsummert betyr det at Felles ressursregister Forutsetninger for fremtidig drift av Felles ressursregister (Unntatt offentlighet ihht. offentleglova 21) Side 10 av 23

17 forvaltningsmessig i realiteten vil være plassert i den organisasjonen som får ansvaret for forankring og strategisk arbeid lagt til seg. 7. Sikkerhet og sårbarhet Etableringen av Felles ressursregister vil gi Beredskapsnorge et viktig verktøy. I dette perspektivet bør en tilstrebe størst mulig grad av kunnskapsdeling etter prinsippet need-to-share. Men systemet vil også inneholde informasjon som er sensitiv og som kan misbrukes dersom den kommer på gale hender. Nedenfor er gjengitt noen begreper innen datasikkerhet som brukes til å vurdere trusler, som enten kan være forårsaket av uhell eller som følge av tilfeldige feil, eller som resultat av bevisste handlinger gjort med hensikt. Hensynet til konfidensialitet handler om at opplysninger om enkeltressurser, for eksempel personer, deres operative status og posisjon hentet fra ulike sensorer ikke skal komme uvedkommende i hende. Dette er noe Personvern- og personopplysningsloven regulerer. Konfidensialitet handler også om å hindre at sammenstilte data som viser større deler av landets ressursmengde eksponeres for personer eller organisasjoner med onde hensikter om å ta ut disse ressursene som en del av en planlagt aksjon. Hvordan en skal forholde seg i et slikt tilfelle reguleres av andre lover. Bortfall av tilgang til løsningen gjør at ressurseierne mister muligheten til å oppdatere ressurser, og ressursbrukerne muligheten til å søke dem opp. Dette kan forårsakes av programmeringsfeil, dårlige driftsrutiner, menneskelig feil eller forsøk på bevisste lovbrudd, eksempelvis for å ville ta ned systemet som en del av en ulovlig aksjon. Dette handler om hensynet til systemets tilgjengelighet. Feil i datagrunnlaget som følge av mangelfull oppdatering, feil i synkroniseringsmekanismene eller andre systemfeil eller brukerfeil, eller at utro tjenere eller uvedkommende bevisst har skadet systemet betyr at systemets integritet er truet og innebærer en sårbarhet for brukerne. Lovverket skiller gjerne mellom informasjonssikkerhet og objektsikkerhet. I tilfellet Felles ressursregister vil informasjonssikkerhet omfatte hvordan dataene som ligger i systemet beskyttes mot uønsket innsyn, uønsket endring og helt eller delvis bortfall av tjenesten. Dette gjøres gjennom autentisering i henhold til Difis sikkerhetsnivå 4 8, autorisering i henhold til IAM, det at ressurseiernes gis anledning til å skjerme informasjon om egne ressurser etter prinsippet need-to-know, logging, back-up på strategiske steder og andre mekanismer som naturlig inngår i etablering av et sikret nett. Detaljene rundt dette er ikke naturlig å gjengi her men vil finnes i BarentsWatch risiko- og sårbarhetsanalyse (ROS) som er under utarbeidelse. Objektsikkerhet angår i første rekke servernodene som er plassert innenfor aktørenes brannmur og som skal gi Felles ressursregister den robusthet det krever. Her settes det krav til infrastruktur hos de som skal ha disse nodene innomhus, blant annet sikring av selve bygget nodene står i. Detaljene rundt dette hører også inn under ROS-analysen. Logging av alle transaksjoner bidrar også til at to tilleggsmål for datasikkerhet kan oppnås, nemlig at alle endringer kan vises som historiske data (gir sporbarhet) og at de som har oppdatert datagrunnlaget ikke uten videre kan unndra seg ansvaret for å ha gjort det (såkalt ikke-benekting). En sikkerhets- og sårbarhetsvurdering må balansere kravet til åpenhet i forvaltningen opp mot kravet om beskyttelse av informasjon som krever det. I tilfellet Felles ressursregister er vurderingen den at systemet ikke kvalifiserer til å sortere under sikkerhetsloven men at det likevel krever strenge sikkerhetsmekanismer. Utviklingsprosjektet er klar over dette og sikkerhet er styrende for prosjektet. 8 Det innebærer innlogging via BankID, Buypass eller Commfides som er såkalte tofaktor løsninger der brukeren vet sin egen PIN-kode/passord og har en kodebrikke (BankID), smartkort (Buypass) eller en USBpinne (Commfides). Elektronisk ID på nivå 4 blir bare utlevert ved personlig oppmøte der brukeren må legitimere seg. Forutsetninger for fremtidig drift av Felles ressursregister (Unntatt offentlighet ihht. offentleglova 21) Side 11 av 23

18 8. Oppgaver som skal løses i en driftsfase Drift og forvaltning av applikasjonen Felles ressursregister kan oppsummeres i følgende mer detaljerte oppgaver, gruppert i henhold til beskrivelsen av forutsetningen drift og forvaltning, se Figur Teknisk drift Figur 2 Oppgaver i en driftsfase. Teknisk drift (markert som røde bokser) omhandler hvordan en får den fysiske infrastrukturen, maskin- og programvare til å spille sammen slik at applikasjonen enkelt lar seg forvalte. Infrastrukturtjenesten skal sørge for at maskin- og programvare befinner seg i fysisk sikrede lokaler med avbruddssikker strøm, kjøling etc. med redundans og katastrofesikring som sikrer høy grad av oppetid for applikasjonen. Basis drift skal sørge for at applikasjonen kjører på maskinvare (minne, diskplass, CPU-kraft etc.), basis programvare (operativsystem etc.) og datanettverk av betryggende kvalitet. Drift på de to laveste nivåene kan i dag kjøpes som skytjenestene, gjerne kalt Infrastructure as a service (IaaS) og Platform as a service (PaaS). Applikasjonsdrift skal sørge for at applikasjonen fungerer optimalt, blant annet innebærer det å ta back-up og gjøre gjenoppretting, følge med på køer, prosesser som har stoppet opp, rette feil i importerte data og annen overvåking av bruk og ytelse på applikasjonsnivå. Applikasjonsdrift må også kommunisere godt med Applikasjonsforvaltning Applikasjonsforvaltning Applikasjonsforvaltning innebærer å administrere løsningen i hele dens livssyklus, herunder: Versjonshåndtering og ansvar for å rulle ut nye versjoner av applikasjonen Kvalitetssikring og test av leveranser før produksjonssetting Gjøre enkel videreutvikling, for eksempel integrasjon mot nye aktører, vedlikehold og samarbeid med aktørene om røkting av datagrunnlaget Planlegge systemvedlikehold i samarbeid med teknisk drift Følge opp innmeldte feil Følge opp driftsavtalen og ivareta kontakten med driftsleverandøren Påse at applikasjonen oppfyller BarentsWatch krav til IS/IT-arkitektur og -sikkerhet Forutsetninger for fremtidig drift av Felles ressursregister (Unntatt offentlighet ihht. offentleglova 21) Side 12 av 23

19 Ha beredskap som sikrer tilgjengelig kompetanse på applikasjonen overfor førstelinjetjenesten i brukerstøtte I noen grad brukerforvaltning Øvrige oppgaver knyttet til det operative eierskap til løsningen 8.3. Brukerstøtte Oppgaven med å gi brukerstøtte kan deles inn i flere nivå, når det gjelder brukere av Felles ressursregister vil det være formålstjenlig å fordele disse på tre nivå. Som nevnt tidligere er det grunn til å skille mellom Ressurseiere og Ressursbrukere der sistnevnte i utgangspunktet bør ha prioritet. Førstelinje brukerstøtte går ut på å yte service til sluttbrukerne. Det kan dreie seg om brukeradministrasjon, enkel problemløsing, råd om hvor en kan finne hjelp etc. Dette bør som nevnt primært gjøres av superbrukere i den enkelte organisasjon. Jobben som skal gjøres sentralt kan begrenses til å lage informasjonsmateriell. Ressursbrukerne jobber operativt 24/7 og dermed vil det kunne oppstå behov for brukerstøtte ut over det som superbrukere i egen organisasjon kan gi. Andrelinje brukerstøtte vil også motta henvendelser fra brukerrepresentanter/superbrukere hos ressurseierne når disse står fast. Frivillig arbeid gjøres ofte etter vanlig arbeidstid, noe som innebærer at det må være en viss beredskap utenom ordinær arbeidstid. Tredjelinje støtte kan involveres av underliggende nivå som må ha kunnskap og myndighet til å avgjøre i hvilke tilfeller tredjeline skal involveres. Som en del av brukerstøtten inngår det å utvikle et verktøy som tar vare på erfaringshistorikken Forankring og strategisk arbeid For at Felles ressursregister skal bli det gode verktøyet for aktørene over lengre tid, er det nødvendig å holde oppe en strategisk oppmerksomhet rundt systemet. Dette kan løses ved å plassere de mer operative deloppgavene inn under applikasjonsforvaltning og ha en styringsgruppe som tar det strategiske ansvar for løsningen, eller så kan denne oppgave løses i en egen enhet, som beskrevet under: Være produkteier Rapportere til styringsnivået og tolke styringssignaler Ha kontakt med etatene for å finne strategier for å oppnå høyest kvalitet på data fra aktørene og best mulig oppetid. Kontrollere ressursbruken og sørge for langsiktig finansiering Følge opp inngåtte driftsavtaler og foreta utlysing av nye, jfr. Ha ansvar for risiko- og sårbarhetsarbeidet Ha ansvar for eventuelt utrednings- og analyseaktivitet i forbindelse med utvikling eller videreutvikling Drive et brukersamfunn (community) for Felles ressursregister. Den forvaltningsmessige plasseringen av Felles ressursregister vil som tidligere nevnt være knyttet til organisasjonen som ivaretar dette strategiske ansvaret. Forutsetninger for fremtidig drift av Felles ressursregister (Unntatt offentlighet ihht. offentleglova 21) Side 13 av 23