KS KS SvarUt Delprosjekt felleskomponent SvarUt Beskrivelse og design av løsningen. Versjon

Transkript

1 SvarUt Delprosjekt felleskomponent SvarUt Beskrivelse og design av løsningen Versjon EKOR AS Postboks 1406 Vika, 0115 Oslo Telefon: org.nr

2 SvarUt Side 2 av 35 Innhold 1. Innledning Hensikten med dette dokumentet Behov for endringer i dagens SvarUt komponent Mål og mandat Mandat Mål Nasjonale føringer Kommunal felles-komponent? Hva er tidligere sagt om «felleskomponenter»? Case: SvarUt Ulike tilnærminger Ulike konstellasjoner av samme løsning Lisensiering Forvaltning Oppsummering SvarUt som kommunal felleskomponent Hva er SvarUt Forutsetninger Felles prosesstilnærming digitale tjenester Digitale tjenester krever elektronisk arkiv Innsynsløsning i en kommune Organisatoriske utfordringer Prosessen med å innføre SvarUt Gevinsthåndtering Anbefalt teknisk løsning for pilot Begreper og forkortelser Funksjonalitet Hvordan tar en kommune SvarUt i bruk? Bruksmønster Grensesnitt Forvaltning Overvåkning og logging Sikkerhet Drift Sentrale sak-/arkiv leverandører Vedlegg 1: Dagens løsning i Bergen kommune Overordnet systembeskrivelse SvarUt-applikasjonen Hva gjør selve SvarUt-applikasjonen? Forutsetninger Grensesnittene Informasjon ut fra SvarUt Meldingstjeneste... 32

3 SvarUt Side 3 av 35 Utskrift, frankering og postlegging Overvåking Vedlegg 2: Organisering av prosjektet Vedlegg 3: Referanser og piloter... 35

4 SvarUt Side 4 av Innledning har søkt om støtte til utvikling av en kommunal felleskomponent SvarUt. En del av en felles IKT-arkitektur vil være kommunale felleskomponenter. SvarUt er en løsning Bergen kommune har etablert for å kunne sende utgående post fra kommunen i et elektronisk format og for å innføre sentralisert løsning for utsending av vanlig brevpost. Dette er identifisert som en løsning det er mulig å gjenbruke for alle kommuner. Denne komponenten implementeres mellom kommunens egne fagsystemer (systeminfrastruktur) og den nasjonale meldingstjenesten altinn.no. Oppgaven denne komponenten løser er distribusjon av meldinger/vedtak til riktig meldingstjeneste, nødvendig loggføringer og eventuell distribusjon til ordinær postgang. SvarUt komponenten er tilrettelagt som en fri programvarekomponent. Prosjektet skal utrede løsningen som en sentral kommunal felleskomponent, men skal legge til rette for at enkeltkommune eller samarbeidende kommuner ønsker «lokale» løsninger. Hensikten med prosjektet er først å fremst å gjennomgå funksjonalitet i dagens løsning, vurdere teknisk design for så å tilpasse komponenten slik at det er mulig å gjennomføre planlagt pilot. Det er prosjektets ansvar å legge planer for hva piloten skal gjøre, hvem som skal gjøre det og på hvilket tidspunkt. Prosjektet skal utrede hvilke forhold pilotkommunene må ta ansvar for både organisatorisk, teknisk og legge til rette for at sikkerheten blir ivaretatt på alle nivå Hensikten med dette dokumentet Dette dokumentets primære hensikt er å legge grunnlaget for pilotene. I dokumentet redegjør vi for bakgrunnen for SvarUt-prosjektet, refererer til nasjonale føringer og andre forutsetninger og beskriver SvarUt, primært med tanke på pilot. Etter gjennomføringen av pilotene vil erfaringer danne grunnlaget for en sluttrapport som skal beskrive SvarUt slik den skal tilbys alle kommuner og fylkeskommuner. Prosjektet vil underveis i pilotperioden utrede og legge til rette for en videre forvaltning (utvikling og drift) i regi av /KommIT Behov for endringer i dagens SvarUt komponent Dagens løsning i Bergen kommune danner basis for utvikling av en versjon som skal tilbys som en sentralisert kommunal felleskomponent og testes i pilot. Prosjektet tar høyde for nødvendige justeringer underveis i piloten. Følgende stikkord beskriver endringene i dagens versjon: Tilrettelegging for bruk av flere kommuner samtidig Funksjoner for konfigurasjon av den enkelte kommunes bruk av SvarUt Forsendelsesarkiv for mellomlagring av utsendte dokumenter Generell løsning for manuell utskrift av forsendelser, for videre konvoluttering, frankering og postlegging Nye grensesnitt mot fagsystemer og FA-komponenter, herunder sak/arkivsystemene Nye grensesnitt for automatisk overføring til printleverandør Tuning av systemet for økt belastning

5 SvarUt Side 5 av Mål og mandat 2.1. Mandat Prosjektets mandat er å etablere prosjekt og utvikle løsningen SvarUt til å bli en kommunal/offentlig sektor felleskomponent. Løsningen skal sees i sammenheng med FA (Felles Arkitektur Kommunal Sektor) Mål Prosjektets mål er at det på basis av SvarUt, skal utvikles et design og ferdig beskrevet løsning som skal kunne implementeres i kommunesektoren. Løsningen skal sees i sammenheng med FA (Felles Arkitektur Kommunal Sektor). Løsningen skal implementeres i minimum en av partnerkommunene i prosjektet utenom Bergen kommune.

6 SvarUt Side 6 av Nasjonale føringer I digitaliseringsprogrammet understrekes det at regjeringen ønsker en sterk og effektiv forvaltning for å sikre en god samfunnsutvikling i Norge. Og at det er viktig å kontinuerlig utvikle offentlig sektor for å møte nye behov, nye muligheter og for å sikre at innbyggerne har tillit til og støtter opp om de offentlige løsningene Regjeringens program for fremtidens digitale forvaltning bygger på følgende prinsipper: 1. Digital kommunikasjon skal være hovedregelen for kommunikasjon med forvaltningen 2. Forvaltningen skal tilby helhetlige og brukervennlige digitale tjenester 3. Innlogging til offentlige nettjenester skal være enkel og sikker 4. Innbyggere og bedrifter skal få post fra forvaltningen i én sikker, digital postkasse 5. Innbyggere og bedrifter skal få varsling på sms og e-post 6. Innbyggere skal få hjelp til å finne fram til og bruke digitale tjenester 7. Utvikling av IKT-løsninger skal sees i sammenheng med forvaltningens arbeidsprosesser og organisering 8. Hensyn til personvern og informasjonssikkerhet skal ivaretas 9. Digitaliseringstiltak som har betydning for flere tjenester, skal samordnes Utfordringene som kommunal sektor står overfor innenfor IKT-utvikling er mange. Utfordringene er ikke nødvendigvis spesifikke for kommunal sektor, men forsterkes siden kommunal sektor består av et stort antall selvstendige juridiske enheter (429 kommuner og 19 fylkeskommuner) med varierende grad av modenhet, kompetanse og kapasitet. Utfordringene for den enkelte kommune og fylkeskommune vil derfor i mange tilfeller være vanskeligere å takle, spesielt for mindre kommuner.

7 SvarUt Side 7 av Kommunal felles-komponent? I arbeidet med SvarUt tvinger det seg frem en avklaring av begrepet "felleskomponent". Begrepet må konkretiseres, ulike tilnærminger må drøftes og det må utarbeides ulike lisensieringsordninger og forvaltningsprinsipper Hva er tidligere sagt om «felleskomponenter»? Begrepet er i liten grad drøftet tidligere. Det oppfattes nærmest som selvforklarende. Først når begrepet skal benyttes om noe konkret ser vi behovet for å gjøre en del avklaringer. I Stortingsmelding nr. 17 fra leser vi blant annet: Med IKT-arkitektur meiner vi eit rammeverk for oppbygging av IKT-system og samhandling mellom systema. For å sikre betre samhandling i det offentlege, skal det etablerast nokre overordna og sektorovergripande arkitekturprinsipp basert på ein såkalla tenesteorientert IKT-arkitektur. Den kan delast i tre lag; eit presentasjonslag, eit felleskomponentlag og eit systemlag som er særskilt for verksemda. Samspelet i og mellom laga baserer seg på opne standardar som er etablerte som forvaltningsstandardar, og meir felles krav til informasjonstryggleik. I en tilhørende figur er det listet noen eksempler på offentlige felleskomponenter: Formidlingssentral Skjemamotor Autentisering/eID Arkiv/meldingsboks Tjenestekatalog Felles registerdata Metadata Med utgangspunkt i denne listen ser vi at felleskomponenter kan anta mange former, fra rene datakilder til applikasjoner og støttetjenester. I analysen og anbefalingene fra "Forprosjekt for felles tjenesteorientert arkitektur i kommunal sektor" er det videre listet opp flere eksempler på felleskomponenter i kommunal sektor: Byggsøk Norge.no og MinSide Nasjonal tjenestekatalog Resultat-XML Prosjektet "Tjenester på nett" Prosjekt for standardisert grensesnitt mellom sak-/arkivsystem og Byggsøk Forprosjekt om revisjon av Geolok-standarden (Forprosjektet til GeoIntegrasjon) ELIN-k Meldingsløftet eresept ELIN-t Kjernejournal Feide-utrulling

8 SvarUt Side 8 av 35 Utrulling av kommunale næringslivsrelaterte tjenester i Altinn De fleste av disse er prosjekter i oppstart eller som fremdeles er i utviklings- eller implementeringsfasen. Unntakene er blant annet Byggsøk, norge.no, MinSide og Nasjonal tjenestekatalog. De er alle sentraliserte nettjenester, enten i form av komplette applikasjoner, sentrale informasjonskilder eller sentrale støttetjenester Case: SvarUt Med SvarUt dukket det opp en ny og svært interessant løsning som kan utvikles og tilbys kommunene. Men der de før nevnte felleskomponenten i stor grad var sentraliserte, så man i utgangspunktet for seg at kommunene selv hentet ned applikasjonen, konfigurerte denne og kjørte denne lokalt, eventuelt i regi av et kommunesamarbeid. Underveis har prosjektet snudd i retning av at SvarUt også kan tilbys som sentralisert løsning, men da først og fremst som tilbud til de små kommunene eller kommuner som ikke ønsker dette installert og driftet lokalt. Dessuten er vesentlige deler SvarUt-konseptet selve grensesnittene mot fagsystemer, sak/arkiv-systemene, meldingstjenesten og printleverandøren (som her forestår utskrift, konvoluttering, frankering og postlegging av brevpost). Prosjektet er så langt av den oppfatning at det er mest hensiktsmessig å etablere en sentralisert kommunal felleskomponent som testes ut i pilot. Det er ikke utenkelig å se for seg en modularisering av SvarUt, slik at ulike deler i større eller mindre grad blir felleskomponenter i seg selv. Svært aktuelt er grensesnittet mot Altinn. Det er uttalt fra styringsgruppen i SvarUt at Altinn skal benyttes som meldingstjeneste i prosjektet, på tross av erfaringene med Altinn som stort og til dels uhåndterlig og hvor velkjente tilgjengelighetsproblemer har resultert i en viss skepsis. Men styringsgruppen i SvarUt-prosjektet har adressert disse utfordringene ved å beslutte at grensesnittet mellom SvarUt og Altinn skal håndteres sentralt, på vegne av alle kommuner Ulike tilnærminger Med utgangspunkt i SvarUt som case kan vi se for oss ulike tilnærminger av begrepet "felleskomponent". Disse skal kort beskrives og drøftes En applikasjon I enkleste form kan SvarUt oppfattes som en applikasjon. I Bergen kommune foreligger den allerede som en komplett løsning, utviklet i Java, tilgjengelig for hvem som helst på GitHub og inkluderer også basistjenester som mail, database, grensesnitt, osv. Med beskjedne krav til maskinvare og basis programvare kan løsningen relativt enkelt installeres og settes i drift, slik den allerede kjøres i Bergen kommune. Slik ble nok også SvarUt som felleskomponent først oppfattet, på tross av at dette innebærer en ganske annen driftsløsning enn hva felleskomponenter ellers har vært oppfattet å være underlagt Et grensesnitt De største utfordringene med implementasjonen av SvarUt ligger neppe i selve applikasjonen. Denne har allerede vært i drift, med godt resultat, i Bergen kommune. Applikasjonen er lett tilgjengelig, komplett og stiller beskjedne tekniske krav. Utfordringene ligger i de mange grensesnittene ut og inn av applikasjonen. Ett av disse er grensesnittet mot meldingstjenesten, som styringsgruppen for SvarUt har besluttet skal være Altinn. Dette er i seg selv krevende, både teknisk og ikke minst administrativt. Styringsgruppen

9 SvarUt Side 9 av 35 har derfor også besluttet at grensesnittet skal håndteres sentralt. Rent teknisk er grensesnittet basert på Web Services mellom SvarUt og Altinn. Det kan derfor være aktuelt å se dette grensesnittet isolert som en felleskomponent, som blant annet SvarUt benytter En nettjeneste Underveis i SvarUt-prosjektet ble tanken om en sentralisert løsning unnfanget. Dette ble først og fremst gjort av hensyn til små kommuner som hverken har ønske om, kunnskap eller ressurser til å installere og kjøre dette lokalt. En sentralisert løsning er derfor svært aktuell for SvarUt, slik felleskomponenter stort sett har vært inntil nå En avtale I ytterste konsekvens kan vi også se en avtale som en felleskomponent. Det mest nærliggende eksempelet er allerede nevnt flere ganger, nemlig behovet for at det tegnes en avtale med Altinn på vegne av alle kommuner Ulike konstellasjoner av samme løsning På bakgrunn av arbeidet så langt med SvarUt er det også lett å se for seg ulike konstellasjoner av felleskomponentene. Prosjektet hadde som mål å teste SvarUt i flere pilotkommuner og i flere konstellasjoner. Noen kommuner, som f.eks. Bærum og Askøy kommuner har både ressurser og muligens også ønske om å kjøre SvarUt-applikasjonen lokalt, foreta konfigurasjonene mot sine sak/arkivsystemer og tilrettelegge dette for print innenfor kommunens egne tjenester. Drammen IKT vil også kjøre dette lokalt, men for et kommunesamarbeid som omfatter fire kommuner. Slike kommunesamarbeider kan ha noen kommunespesifikke grensesnitt, der f.eks. kommunene benytter ulike sak/arkiv-løsninger, men felles utskrift og forsendelse av brevpost. Grensesnittet mot Altinn skal uansett håndteres sentralt. Prosjektet vil teste en sentralisert løsning. Denne vil selvsagt teknisk sett være ganske lik løsninger for kommunesamarbeid. Forskjellene ligger mer på det administrative, og da spesielt med hensyn på avtaleverk og forvaltning. Som pilot er det tenkt at installasjonen i Bergen fungerer som sentral løsning Lisensiering For distribusjon av fri programvare er det i dag utviklet en mengde ulike lisenser. SvarUt er f.eks. i dag tilgjengelig gjennom GitHub under betingelsene i GNU General Public License (GPL). Denne lisensen er den klart overlegne i bruk for distribusjon av fri programvare. Denne lisensen krever at koden alltid skal være tilgjengelig, også gjennom distribusjonene. I motsetning til BSDlisensen krever også GPL at dersom du inkluderer GPL-lisensiert kode i en annen løsning, vil hele denne løsningen også lisensieres under GPL. Distribusjon og bruk av felleskomponenter må ha et bevisst forhold til lisensiering. Bevisst forhold til lisensiering bestemmer i hvilken grad programvaren, som åpen kildekode, forblir fri, men også i hvilken grad ulike løsninger underlagt ulike lisenser kan integreres Forvaltning Forvaltning av systemer i sin alminnelighet, og kanskje felleskomponenter i særdeleshet er helt sentrale problemstillinger. SvarUt er eksempelet på en felleskomponent som vil bli en særdeles viktig komponent i kommunens infrastruktur, siden komponenten vil håndtere det meste av

10 SvarUt Side 10 av 35 korrespondanse fra kommunen til innbyggere, næringsliv og andre offentlig institusjoner. Det er derfor vanskelig å se for seg at SvarUt distribueres "without any warranty"... Det må derfor etableres et forvaltningsapparat som omfatter både systemeierskap, ansvar for drift og vedlikehold, ansvar for grensesnitt og avtaleverket. Med ulike konstellasjoner for installasjon og drift, kan vi også se for oss ulike forvaltningsprinsipper. Der forvaltningsapparatet i en tilnærmet fullstendig sentralisert løsning er enkel å beskrive, vil dette raskt bli mer problematisk der deler eller hele løsningen kjøres lokalt. Ansvaret for implementasjon og drift vil bli lagt lokalt, mens ansvaret for det programtekniske vedlikeholdet av applikasjonen vil være avhengig av lisensbestemmelser og i hvilken grad det er gjort tilpasninger og endringer lokalt Oppsummering Det er ikke enkelt, og kanskje ikke heller ønskelig, å definere begrepet "felleskomponent" snevert. Det vi i dag ser som SvarUt kan komme til å bli implementert på ulike måter, og hvor ulike deler av totalkonseptet underlegges ulike lisensbestemmelser og forvaltningsapparat. Dessuten er det ikke vanskelig å tenke seg en modularisering av SvarUt slik at de enkelte delene fremstår som separate "felleskomponenter". Det er i den forbindelse interessant at grensesnittet mellom SvarUt og meldingstjenesten, altså den komponenten som trolig i størst grad blir håndtert sentralt, er omtrent det tilsvarende som allerede i Stortingsmelding 17 fra ble listet som "Arkiv/meldingsboks". På bakgrunn av dette oppsummerer vi med følgende: En "felleskomponent" kan være både en konkret applikasjon, et grensesnitt mellom systemer, en nettjeneste (skytjeneste) og et avtaleverk for regulering av grensesnitt mellom systemer. En "felleskomponent" kan også inkludere flere av disse, slik at SvarUt som felleskomponent omfatter selve applikasjonen og grensesnittene mot sak/arkiv og printtjenestene, mens grensesnittet mot meldingstjenesten skilles ut som egen komponent. Ulike konstellasjoner krever ulike lisensbestemmelser og ulik organisering av forvaltningsapparatet. Innholdet i en «felleskomponent» må i hvert enkelt tilfelle spesifiseres SvarUt som kommunal felleskomponent Som beskrevet i dette kapittelet vil SvarUt kunne oppfattes som en kommunal felleskomponent på flere måter. Vi velger likevel å fokusere på følgende karakteristika: SvarUt er en applikasjon som skal installeres og driftes sentralt for alle kommuner og fylkeskommuner som ønsker å ta tjenesten i bruk. På denne måten kan SvarUt sies å være en skytjeneste. SvarUt tilbys også som kildekode for de kommuner og fylkeskommuner som ønsker å videreutvikle eller tilpasse dette til eget bruk.

11 SvarUt Side 11 av Hva er SvarUt Hensikten med SvarUt er å foreta en rimelig, effektiv og sikker formidling av post til innbyggere, næringsliv og andre mottakere. SvarUt er utviklet av Bergen kommune og er i drift i kommunen i dag. Kort fortalt er SvarUt en løsning for å kunne sende utgående post fra kommunen i et elektronisk format og som sentralisert løsning for utsending av vanlig brevpost SvarUt plasserer seg med dette mellom fagsystemer og sak/arkiv-systemene på den ene siden og hvor det i andre enden tilstrebes elektronisk formidling av informasjonen til innbyggere og næringsliv. Det er selvsagt også inkludert ordinær formidling gjennom brevpost. Hensikten med løsningen er i første rekke å hente gevinster gjennom økt digitalisering av grensesnittet ut mot innbyggere og næringsliv effektivisering av formidlingen av ordinær brevpost I tillegg vil løsningen fremme bruken av sak-/arkivsystemene og elektronisk dokumentforvaltning. Skal man hente ut gevinst internt, er det en forutsetning at man benytter elektronisk saksbehandling og har elektronisk arkiv på de fagområdene løsningen tas i buk. Men det er ingen ting i løsningen som hindrer kommunen i å fortsette med «manuell» saksbehandling og papirarkiv så lenge man har dokumentene i elektronisk form. For innbyggerne/brukerne vil mottaket oppleves som fullverdig og man vil dermed kunne fremstå som en kommune som tilpasser seg innbyggernes/brukernes behov og ønsker. Det kan være en grei overgangsordning da det å få på plass nye administrative rutiner og verktøy kan ta tid. I små kommuner har innbyggerne stort sett de samme behovene og forventningene til sin kommune som i store kommuner, da kan det være hensiktsmessig å finne alternative løsninger for å nå innbyggerne/brukerne. Figur 1: Overordnet systembeskrivelse for SvarUt

12 SvarUt Side 12 av Forutsetninger Fornyelse av offentlig sektor og kravene til døgnåpen forvaltning, elektronisk tjenesteyting, elektronisk postjournaler og elektronisk samhandling med innbyggerne/brukere forutsetter både elektronisk arkiv og saksbehandling. Elektronisk saksbehandling innebærer en gjennomgående IT-støtte til utførelsen av saksbehandlingsprosesser. Elektronisk saksbehandling kan føre med seg en rekke kvalitative, men også kvantitative, gevinster. Økt rettssikkerhet, mer offentlighet og bedre sporbarhet, samt reduserte kostnader til lagring, gjenfinning og behandling av dokumenter er viktige stikkord. Kommunal sektor skal i stor grad yte de samme tjenestene til sine innbyggere uavhengig av kommunale og fylkeskommunale grenser. Behovene for samhandling og koordinering internt i kommuner, mellom kommuner og mellom kommuner og staten øker, og for å imøtekomme behovet for økt samhandling og koordinering på IKT-området i kommunal sektor, er det behov for en mer helhetlig tilnærming til IKT-strategi, felles arkitekturprinsipper og felles standarder. Det er stor aktivitet på disse områdene i kommunal sektor. Noe av arbeidet er organisert gjennom sentralt styrte prosjekter men i hovedsak pågår aktivitetene lokalt i fagmiljøene i den enkelte kommune eller organisert gjennom ulike samarbeid. Det legges ned betydelig ressurser i å tilby bedre tilpassede tjenester gjennom å utnytte tilgjengelig teknologi. Det utvikles nye og smarte løsninger som fører til en mer effektiv administrasjon og som gir helt andre muligheter i dialogen mellom forvaltning og bruker. Dette kan igjen føre til at man vil oppleve kommunal sektor som smart, effektiv og fremtidsrettet Felles prosesstilnærming digitale tjenester Norske kommuner (og leverandører) har gjennom de siste tiårene brukt mye ressurser på å forsøke å effektivisere saksbehandlingen gjennom bruk av elektroniske verktøy (sakarkivløsninger baser på NOARK standarden). Dette har først og fremst handlet om å ivareta dokumentasjonskravet og det å gjøre tilgjengelig informasjonen på en hensiktsmessig måte. Man burde i mye større grad også ha satt fokus på arbeidsprosessene og sett på hvilke muligheter effektive verktøy kan gi. Det er i utgangspunktet ingen hindring at for eksempel lovverket ikke muliggjør endinger det er «bare» å sørge for at regelverket tilpasses dagens behov og muligheter. Det er ingen tvil om at vi kan effektivisere kommunal administrasjon gjennom å ta i bruk teknologi, men skal vi lykkes må vi ta tak i den enkelte prosess, vurdere oppgaven som skal løses og finne ut og hvordan vi kommer dit på smarteste og mest effektive måte.

13 SvarUt Side 13 av 35 Generelt kan en regelstyrt prosess beskrives som fremstilt i skissen under. Figur 2: Felles prosesstilnærming - digital tjeneste Brukeren finner beskrivelse av tjenesten gjennom tjenestebeskrivelsen på kommunens portal. Dialogen kan starte gjennom et forhåndsdefinert skjema eller via en annen på forhånd definert kanal. Så snart skjemaet er sendt inn eller dialogen har startet bekreftes dette gjennom en kvittering til bruker. Saksbehandlingen starter, automatisert eller på annen definert måte. Når saksbehandlingen er ferdig og vedtaket fattet informeres brukeren om dette gjennom et varsel fra kommunens SvarUt tjeneste. Dokumentene ligger i kommunens arkiv og kun der. Brukeren når dette på en sikker måte gjennom Altinn pålogging. Er det ikke ønskelig eller hensiktsmessig å formidle vedtaket elektronisk, sørger SvarUt tjenesten for at dette oversendes brukeren via papirpost. Dagens SvarUt tjeneste overvåker om brukeren åpner varselet fra Altinn innen et på forhånd bestemt antall dager, om så ikke er tilfelle ekspederes forsendelsen via papirpost. Denne tjenesten kan fjernes så snart regjerningens intensjon om at digital kommunikasjon skal være hovedregelen Digitale tjenester krever elektronisk arkiv Forvaltningens saksdokumenter er offentlige. Både arkivloven, offentlighetsloven, forvaltningsloven og personopplysningsloven stiller krav til offentlige organer når det gjelder arkiv. Arkiv består av dokumenter på et medium som lagrer informasjon for senere lesing, lytting, framvisning eller overføring. Arkivloven og forskriftene gjelder for alle typer arkiv og stiller krav til oppbevaring, håndtering og tilgjengeliggjøring. Dette gjelder også informasjon og dokumentasjon som håndteres i sak-/arkivsystem og fagsystem. Kommuner og fylkeskommuner må ha tilgang til digitalt depot som sikrer tilgang til dokumentene over tid. Elektronisk arkiv er en av forutsetningene for elektronisk kommunikasjon og effektivisering av interne prosesser. Elektroniske saksbehandlingsløsninger som sikrer overføring av data mellom portaler, databaser, sak-/arkivsystemer og fagsystemer for de viktigste løsningene, krever at det utvikles standarder for dette, både organisatorisk, semantisk og teknologisk. Kravene til et elektronisk arkiv er definert av Noark-standarden som utformes av Riksarkivet. Det er også Riksarkivet som godkjenner løsninger for bruk i offentlig forvaltning. Den overordnede målsettingen med å innføre elektronisk arkiv er å effektivisere, forenkle og forbedre ressursbruk. Målsetningen kan deles inn i:

14 SvarUt Side 14 av 35 Mer effektiv ressursbruk, gjennom automatisering og forenkling av rutinebaserte handlinger samt plassbesparende. Unngå dobbeltarkivering. Mindre personavhengig og bedre tilgang til informasjonen hele døgnet, større medarbeidertilfredshet. Kvalitativt bedre oppgaveløsning, gjennom bedrede muligheter for å følge og dokumentere formelle saksbehandlingsrutiner og for å konsultere bakgrunnsinformasjon. Økt dokumentfangst til arkivet, mer komplett arkiv. Mer robust arkivløsning og forskriftsmessig arkivdrift. Enklere informasjonsdeling. Gjenbruk av tekst Innsynsløsning i en kommune Vi beskriver og gir her et eksempel på innsynsløsning i en kommune ved å presentere Bergen kommune sin satsning på dette området. Som del av sine elektroniske tjenester tilbyr Bergen kommune sine innbyggere en innsynsløsning: Figur 3 Innsynsløsningen tilbyr innbyggerne en oversikt over sitt «kundeforhold» til kommunen, og en finner en oversikt over blant annet: Dine saker Saker fra sak-arkivsystem, innsendte skjema, vedtak fra byggesaker med mere. I tilknytning til pågående saker er det også mulig å gi kommentarer direkte på sak. Disse kommentarene, med eventuelle vedlegg, vil bli automatisk lagt i sak-arkivsystemet på riktig sak. Dine saker utvides fortløpende etter hvert som også fagsystemer (f.eks. skole) kobles mot sak-arkivsystemet.

15 SvarUt Side 15 av 35 Dine Personalia Viser status på pålogget bruker med siste gyldige adresse fra folkeregisteret. Mulighet for å melde adresseforandring om feil. Adresse kan vises i kartløsning som i tillegg til eiendomskart også kan vise veikart, teknisk kart, turkart med mere. Dine fakturaer Viser alle fakturaer Bergen kommune har sendt innbyggerne med angivelse av forfallsdato med mere. Dine eiendommer Viser oversikt over dine eiendommer med kobling til kart og relevante arealplaner for den aktuelle eiendom. Innsynsløsningen vil i snar fremtid bli utvidet med Din side organisasjon, der næringsliv, lag og organisasjoner vil få en tilsvarende oversikt som innbyggerne. Bergen kommune innfører elektronisk utsending ved bruk av den offentlige meldingsboksen i Altinn. Tilgang til meldingsboksen finnes direkte fra innsynsløsningen. Når bruker er innlogget i Bergen kommune vil tilgang til meldingsboksen ikke kreve ny pålogging. Tilgang til innsynsløsningen krever pålogging ved bruk av ID-Porten Bruksmønster Bergen kommune opplever en stadig økende bruk av innsynsløsningen. Som statistikken viser øker antallet påloggede brukere fra 2011 til Det forventes en ytterligere kraftig økning når Din side organisasjon etableres. Figur 4

16 SvarUt Side 16 av Organisatoriske utfordringer Arbeidet med å digitalisere kommunale tjenester pågår for fullt. Men dette arbeidet handler ikke først og fremst om infrastruktur og det å lage gode web-tjenester/apper. Det handler mest om å utvikle måten tjenestene produseres og leveres på gjennom å utvikle prosessene og organisasjonen. Dette er langt vanskeligere og mer omfattende en å tilgjengeliggjøre tjenester på nett. Når arbeidet med digitalisering starter har man som regel for lite fokus på om de organisatoriske forutsetningene er til stede. Har kommunen nødvendig utviklings- og omstillingsevne i form av ledelse og strukturer, kultur og kunnskaper, teknologi og økonomi? Det å sette strøm på gamle arbeidsmåter og introdusere dette som fornying gjennom digitalisering er ikke løsning på utfordringen. Man har ikke noe valg, her må man gå grundigere til verks. Hvordan kan vi jobbe smartere og mer effektivt med hjelp av ny teknologi? Mange kommuner har allerede kommet langt i fornyingsarbeidet og har ambisiøse planer bl.a. knyttet til samhandling med andre offentlige virksomheter. Utfordringen de møter er ofte knyttet til at fornyingsarbeidet generelt går for langsomt og at man derfor lykkes i mindre grad, fordi de man ønsker å samhandle med hverken har vilje, økonomiske rammer eller ressurser til å møte kravene fra brukere eller samhandlende virksomheter. Hverdagen handler i realiteten om at saksmengden skal håndteres samtidig som arbeidsmåten skal fornyes. Kortsiktige hensyn må veies mot langsiktig fornyingsarbeid. Her er vi også inne på et sentralt punkt for kommunene. Skal den enkelte basere seg på egne løsninger, eller bidra til å utvikle fellesløsninger? Det er brukerne og hvordan de opplever tjenesten som avgjør om dette blir en suksess eller ikke. Figur 5: Skisse hentet fra Bergen kommune 7.1. Prosessen med å innføre SvarUt Vi presenterer her erfaringene fra Bergen kommune med innføringen av Svar Ut. Takk til Bergen for at dere deler erfaringer med oss. Sentralisert og elektronisk utsending (SvarUt) ble innført i Bergen kommune for byggesaker ved Etat for byggesak og private planer (EBPP) i februar Ved årsskiftet 2012 ble SvarUt implementert hos oppmåling/deling i EBPP og Samferdselsetaten fra 1. februar Private planer i EBPP startet i april Volumet i 2011 var ca dokumenter. Forsendelsene er pt dokumenter fra Sak- arkivsystemet, og erfaringene så langt er at løsningen fungerer godt teknisk sett og at de fleste dokumenter (>99 %) fra sak- arkivsystemet har korrekt

17 SvarUt Side 17 av 35 og format (PDF) for utsendelse. For å sikre elektronisk utsending må adresseinformasjon inneholde fødselsnummer eller organisasjonsnummer. Innføringen av sentralisert og elektronisk utsending (SvarUt) i Bergen kommune har vært meget positiv. Som grafen viser har antall dokumenter har per september 2012 allerede oversteget hele 2011, og det forventes et totalt antall for 2012 på mellom dokumenter. Figur 6 For å sikre god forvaltning av SvarUt arbeides det kontinuerlig med forbedringer knyttet til mindre vedlikehold, loggføring, rutiner med mere Gevinstmodell SvarUt i Bergen kommune Bergen kommune har beregnet en besparelse på ca. 10,- kroner for utsendelse pr post og ca. 25,- kroner for elektronisk. Dokument sendt som post via ekstern printleverandør gir besparelse på ca. 10,- pr dokument med de samme forutsetninger som over sammenlignet med faktiske kostnader ved bruk av ordinær utsending fra kommunen. I tillegg følger gevinster som oppfølging av digitalt førstevalg, bedre service overfor brukere, bedre kvalitet og økt sikkerhet. Aggregerte kvantitative gevinster som følge av innføring av SvarUt i Bergen kommune passerte i 2011 kr ,- I 2012 forventes dette å øke til over ,-

18 SvarUt Side 18 av 35 Figur Gevinsthåndtering Det kan være en utfordring å arbeidet med gevinstrealisering i kommunene, da dette også betinger en god forståelse av hvordan IKT kan tilføre organisasjonen verdi. Arbeidet med digitalisering skal understøttes av den IKT-faglige kompetansen, men prioriteringene rundt selve utviklingen må initieres av de faglige miljøene. Dette krever at den digitale kompetansen bygges opp, og at kjennskapet til egen arbeidsflyt og prosesser prioriteres av de respektive faglige lederne. Den enkelte kommune må være innstilt på å innrette organisasjonen i henhold til de teknologiske mulighetene som finnes og ikke la den eksisterende organiseringen stå i veien for effektiviseringer, gevinster, økt samhandling og større brukertilfredshet ved bruk av IKT.

19 SvarUt Side 19 av Anbefalt teknisk løsning for pilot Vi vil her beskrive den tekniske utformingen av et sentralisert SvarUt, med mål om å skape et grunnlag for implementering av løsningen. Målgruppen er arkitekter, utviklere og andre deltagere i prosjektgruppen. Beskrivelsen vil hovedsakelig være på et funksjonelt nivå, med en oversikt over teknisk implementasjoner gitt på sentrale punkter, hovedsakelig for grensesnitt. SvarUt Sak/Arkiv B 8.1. Begreper og forkortelser SvarUt: Applikasjon for mottak av forsendelser fra kommunene og påfølgende videresending digitalt til Altinn og fysisk via brevpost. Forsendelse: Ett eller flere dokumenter som sendes og/eller leses samlet. Fagsystemer Figur 8: SvarUt-konseptet Print-leverandør: Selskap som leverer trykk og frankeringstjenester med integrasjon mot SvarUt. I denne beskrivelsen vil begrepet «print-leverandør» også omfatte tilsvarende tjenester i regi av en kommune eller et kommunesamarbeid. Forsendelsesarkiv: SvarUts «database» over utsendte forsendelser (metadata og PDFfiler). Dette er en midlertidig og tidsbegrenset mellomlagring, med eneste hensikt at mottaker skal kunne hente den forsendelsen kommunen varsler gjennom meldingstjenesten i Altinn. For de kommunene som har etablert innsynsløsning som et tilbud til sine innbyggere/brukere skal prosjektet vurdere å gi mulighet til å hente ut dokumentene ved utsendelse av meldingen.

20 SvarUt Side 20 av Funksjonalitet Prosess for mottak og utsending av forsendelser Flyten i mottak og videresending av en forsendelse til SvarUt er beskrevet i figur 9. Listen nedenfor beskriver de enkelte stegene i prosessen: Generell innsynsløsning Kvittering Bruker Manuell innsending I.b Forsendelses arkiv Send post V Automatisk utsending? Ja Printleverandør VI.a Nei II Nei Nei Gyldig? Ja Arkiver fil og send meldingsvarsel Lest? IV Manuell utskrift VI.b Eksternt system Innsending over Webservice I.a Nei III Ja Forsendelse utført Meldingsboks Figur 9: SvarUt komponenten 1. Innsending SvarUt mottar forsendelser gjennom to kanaler; en SOAP-basert Web Service (markert I.b i figur 9) og ved manuell opplasting (markert I.a). I begge tilfeller sjekkes fil og metadata for validitet før forsendelsen sendes videre i løpet. 2. Arkiver fil og send melding-varsel Hvis SvarUt godkjenner forsendelsen, blir filen og tilhørende metadata arkivert i SvarUts forsendelsesarkiv, og meldingsvarsel sendt til innbygger via Altinn. 3. Altinn-meldingsboks Meldingen er tilgjengelig for innbygger i Altinns meldingsboks, med tekst basert på forsendelsesmetadata og predefinert meldingstekst fra kommunen og tilhørende lenke til dokumentet i forsendelsesarkivet.

21 SvarUt Side 21 av Lesing i AltInn Hvis innbygger følger lenken i Altinn-meldingen vil nedlasting av den aktuelle filen fra SvarUts forsendelsesarkiv starte og meldingen vil bli markert som "lest", forsendelsen markeres som utført når nedlastingen er fullført. Merk at filen fortsatt vil være tilgjengelig i forsendelsesarkivet for senere nedlastinger. Tidsperioden skal defineres. 5. Send post Om meldingen ikke er lest i Altinn innen en predefinert tidsfrist vil prosessen gå videre til levering pr. brevpost. SvarUt tilbyr her to kanaler, print-leverandør (markert VI.a) og manuell utskrift (markert VI.b). Den første forutsetter at kommunen har konfigurert (og gjort avtale med) en ekstern tilbyder av print-tjenester, eller tilbyr tilsvarende funksjon i egen regi. Forsendelsen vil da bli sendt til denne leverandøren, og kvittering mottatt når leverandøren bekrefter at utsending er utført. Denne kommunikasjonen vil typisk skje via Web Services. Om kommunen ikke har satt opp en print-leverandør kan forsendelsen forvaltes videre via grensesnittet for manuell utskrift. Denne gir mulighet for å hente forsendelser via en nettside, og å markere forsendelsen som utført når den er skrevet ut og formidlet videre av kommunen Hvordan tar en kommune SvarUt i bruk? Det er et mål å forenkle de nødvendige stegene for at en kommune skal kunne ta sentralisert SvarUt i bruk. I utgangspunktet vil prosessen bli som følger i piloten: 1. Kommunen tar kontakt med SvarUt forvalter, og blir tildelt brukernavn og passord. 2. Kommunen konfigurerer løsningen gjennom et web-grensesnitt (oppsett av meldingstekster, valg av print-leverandør og frister for digital lesing osv.) For detaljer, se punkt SvarUt er nå klar til å bli tatt i bruk. Typisk vil kommunen teste sitt oppsett ved å foreta manuell utsendelse via web-grensesnittet før man tar automatiske løsninger i bruk Bruksmønster Et viktig mål under utforming av en sentralisert SvarUt løsning er at den skal kunne tilfredsstille de varierende behovene til norske kommuner, med ulike forsendelsesvolum og tekniske løsninger. I denne seksjonen vil vi skissere ulike måter løsningen kan tas i bruk og integreres i kommunenes IKT-infrastruktur.

22 SvarUt Side 22 av Manuell løsning Dette bruksmønsteret involverer ingen integrasjoner med kommunens systemer. Utsendelse til SvarUt foregår via det manuelle web-grensesnittet som vist i figuren. I hovedsak er dette bruksmønsteret aktuelt under oppstart og testing av en kommunes bruk av SvarUt, men det gir også en kanal for adhoc utsendelser fra systemer som ikke har integrasjoner mot SvarUts Web Service. Man kan også tenke seg at de minste kommunene med få forsendelser gjør dette manuelt Selvstendige integrasjoner Dette er tenkt som det typiske bruksmønsteret. Her snakker hver komponent i kommunens IKT-infrastruktur selvstendig med SvarUt. Merk at selv om man i utgangspunktet må bygge denne integrasjonen for hvert system, er det tenkt at man for sentrale systemer som er i bruk i mange kommuner (som for eksempel arkivsystemer) kan få levert standard integrasjons-moduler. Ansvaret for en slik utvikling vil i utgangspunktet ligge på den enkelte systemleverandør. Det er også mulig å tenke seg at andre integrasjons-komponenter kan utvikles som delt kode mellom kommunene. Blant fagsystemer inngår også kontor-applikasjoner som tekstbehandlere. I Bergen kommunes er en plugin som tillater ansatte å sende SvarUt meldinger direkte fra MS Word under utvikling. Lignende plugins kan også lages for andre systemer. Figur 10: Grensesnitt for innsending gjennom web-grensesnitt Altinn SvarUt Fagsystem Sak/arkiv Orkestrering Figur 11 Bruksmønster hvor det benyttes egen integrasjonskomponent for hver applikasjon.

23 SvarUt Side 23 av FA-komponent som integrasjons-komponent Altinn SvarUt Fagsystem FAkomponent Orkestrering Figur 12 FA-komponent som integrasjonskomponent En ulempe med løsningen beskrevet i punkt er at man må utvikle selvstendige integrasjoner for de ulike komponentene. En alternativ løsning er å benytte en FA-komponent som en lokal port til SvarUt - dette kan være hensiktsmessig for kommuner hvor fagsystemene som skal foreta utsendelser allerede har integrasjoner mot en slik komponent, og dette igjen er integrert mot SvarUt Sak/arkiv som integrasjons-komponent Altinn SvarUt Fagsystem Sak/arkiv Orkestrering Figur 13:Bruksmønster hvor sak/arkiv-systemet brukes som lokal integrasjonskomponent. Dette alternativet er identisk med 8.4.3, men her er det eksplisitt sak/arkiv-systemet som opptrer som lokal integrasjonskomponent.

24 SvarUt Side 24 av Grensesnitt Forsendelses-mottak Innsending av forsendelse vil kunne gå via en SOAP basert Web Service. Andre grensesnitt kan lages etter behov. Figur 14: Altinn meldingsboks I kallet mot innsendingstjenesten må følgende metadata legges ved forsendelsen: Autentiseringsinfo (bruker, passord). Kan sendes som http basic autentication headere. Mottakerinfo (adresse, org/fødselsnummer, navn, adresse). Altinn krever fødselsnummer/organisasjonsnummer for meldinger. Adresse og navn blir brukt til forsendelse gjennom post. Avsenderinfo (navn, adresse). Informasjon om avsender, brukes både i Altinn-meldinger og postlagte forsendelser. Forsendelsesinfo (tittel). Tittel på forsendelsen. Tittel blir vist i tittelfeltet på melding til Altinn, og i listen over innkommende meldinger, se figur14. Første tittel i dette eksempelet er "Vedr. saksnr , journalnr ". I figur 15 kan en se tittel i svart fet skrift etter "Mottatt melding:". Meldingsoverskriften er lik, men står over i meldingen.

25 SvarUt Side 25 av 35 Figur 15: Altinn melding Printkonfigurasjon (farge/svart hvitt, tosidig, brevtype). Det vil være mulig å legge til rette for forskjellige preferanser for print. Svart hvitt/farge, tosidig print, A-post, B-post eller rekommandert. Konteringskode. Kode som beskriver faktureringskonto for forsendelsen. Kan benyttes for å gruppere meldings-statistikk gjennom forvaltningsløsningen, og sendes videre til print-leverandør. I tillegg inneholder forsendelsen en liste med PDF-filer som utgjør dokumentene i forsendelsen. PDF-filene blir satt sammen til en større fil før de sendes videre i prosessen. Hovedsakelig gjøres denne operasjonen for å gjøre forsendelsen enklere for print-leverandør, siden de da kan skrive den ut som ett dokument. Merk at det under denne konverteringen er potensiale for at feil kan oppstå (uventet PDF innhold, beskyttet innhold, ikke støttede bilde-formater osv.). Derfor bør denne konverteringen skje før SvarUt godtar forsendelsen, slik at eventuelle feilmeldinger kan returneres på web-service kallet Manuell innsending Et utkast til webside for manuell innsending er vist i figur 10. Brukeren velger fil for opplasting, og får en forhåndsvisning av dokumentet som blir sendt. Man spesifiserer så mottaker for forsendelsen. Her kan man se for seg ulike løsninger. Den enkleste vil være å vise felt for fødselsnummer/organisasjonsnummer, navn, adresse og bruke dette direkte uten noen form for validering. Automatisk søk etter fødselsnummer og adresse fra folkeregisteret, eller organisasjon fra Brønnøysundregistrene, vil øke datakvalitet og være enklere for bruker, men i så fall må eventuelle personvernhensyn avklares.

26 SvarUt Side 26 av Konfigurasjon En del av funksjonaliteten i SvarUt vil være kommune-spesifikk, og må settes opp av den enkelte kommune gjennom et web-grensesnitt. Altinn. Meldingstittel og meldingsoverskrift spesifiseres for hver forsendelse, men meldingsteksten kan ha en generell del som hver enkelt kommune redigerer. Teksten vil blant annet inneholde nedlastingslenke for forsendelsen. SvarUt. Hver kommune må velge hvilken print-leverandør de ønsker å benytte. SvarUt kan legge til rette for et utvalg print-leverandører, slik at kommunens valg kan gjøres uten ytterligere konfigurasjon. Eventuelt kan manuell utskrift velges (se neste punkt). I tillegg vil det tilbys et webgrensesnitt for SvarUt-administrator, hvor man kan legge til kommuner, og sette eller re-sette passord for disse Manuell utskrift Hvis kommunen ikke ønsker å benytte seg av ekstern leverandør for print kan kommunen selv besørge print og postlegging. Hvis dette alternativet blir benyttet, og forsendelsen ikke blir lest i Altinn innen fristen eller hvis brukeren ikke har konto hos Altinn, vil forsendelsen fremkomme i web-grensesnittet for manuell print. En dedikert bruker kan så laste ned dokumentet, velge print og postlegge dette. Når det er postlagt trykker han på knappen "Postlagt", dette vil markere forsendelsen som utført i SvarUt Innsyn Noen kommuner har egne innsynsløsninger, men det store flertallet av kommuner mangler gode løsninger. SvarUt forutsetter imidlertid en form for «innsyn», siden meldingen som formidles gjennom Altinn kun har en lenke til selve dokumentet. Dette løses gjennom bruk av forsendelsesarkivet. Lenken i Altinn-meldingen går ganske enkelt til en https-server knyttet til forsendelsesarkivet, gjennom en automatisk autentisering. Det skal imidlertid også tilbys støtte for de kommuner som har egne innsynsløsninger. Dette kan løses på forskjellige måter. Noen kommuner ønsker overføring av dokumentene til egen portal for derved å tilby innsyn. Dette kan f.eks. tilbys gjennom en sikret ftp-sever tilknyttet forsendelsesarkivet. Andre vil baser innsynsløsningen på knytning mot dokumentet i forsendelsesarkivet gjennom https-serveren Printleverandør Grensesnittet mot print-leverandørene må ivareta to prosesser: Forsendelsen av dokumentet og mottak av kvittering når dokumentet er postlagt. Til Bergen kommunes print-leverandør sendes i dag følgende informasjon: id, fargeprint, posttype (rekommandert, A-post/B-post) og tosidig. Som kvittering får vi tilbake id for forsendelsen, antall sider postlagt, dato og tid postlagt. Denne informasjonen blir lagt til de eksisterende data for forsendelsen i forsendelsesarkivet. En sentralisert SvarUt løsning vil sannsynligvis måtte håndtere ulike print-leverandører. Dette kan i hovedsak løses på to måter: Leverandørene kan pålegges å forholde seg til et standardisert grensesnitt, spesifisert under utvikling av sentralisert SvarUt, eller spesifikk kode kan lages for å integrere seg mot hver enkelt leverandør. Hvilken løsning som blir enklest kommer an på hvor mange print-leverandører SvarUt skal benytte, og hvor ofte disse skifter. Det er ikke sikkert at leverandørene har mulighet til å integrere mot et standardisert grensesnitt, og dette vil

27 SvarUt Side 27 av 35 uansett koste leverandøren både tid og penger i en oppstartsfase. Leverandøren kan også mangle kompetanse for å tilpasse seg til et standardisert grensesnitt. Alternativet blir at det blir laget modulbasert kode som integrerer mot den enkelte leverandør som en del av SvarUt prosjektet. Ulempene her er at ansvaret for utvikling og vedlikehold av denne koden blir lagt på SvarUts side. For pilotperioden inngås det avtale med Bergen kommunes print-leverandør Forvaltning For pilotperioden inngår prosjektet avtale om drift og utvikling med Bergen kommune. Det er et mål at ansvar for drift og forvaltning overtas av /KommIT så snart pilotperioden er avsluttet Overvåkning og logging Forvaltnings-grensesnittet er ment for kommunenes SvarUt-ansvarlige. Her finnes funksjonalitet for å overvåke og rette opp ting som har feilet. I første omgang bør følgende funksjonalitet utvikles: Søke opp en forsendelse. Se siste forsendelser. Laste ned dokumentet for forsendelsen. Sporlogg for hver forsendelse (alle steg forsendelsen har vert gjennom med dato/tid, innsendt, sendt Altinn, sent print-leverandør, postlagt print-leverandør, lest elektronisk, send Altinn feilet, send print-leverandør feilet). Oversikt over forsendelser som er i feil tilstand, dvs. dokumenter som feilet til printleverandør eller Altinn. Mulighet for å tvinge postlegging av en forsendelse, uavhengig av tilstand for forsendelsen. Det kan for eksempel være hvis en innbygger/bruker ikke får lest forsendelsen elektronisk. Hente ut kostnad basert på konteringskode og kommune for et dato-intervall, med spesifisert kostnad per forsendelse Sikkerhet Det er prosjektets ansvar å utrede alle forhold knyttet til sikkerhet i SvarUt komponenten som gjøres tilgjengelig i pilotperioden. Prosjektet har ansvar for at all informasjon og at alle forhold rundt sikkerhet og sikkerhetsnivå blir videreformidlet til mottaksprosjektet for piloten i den enkelte pilotkommune, samt påse at de har tilstrekkelig kompetanse til å sette seg inn i konsekvensene Autentisering ved mottak av forsendelse Kommunen autentiseres ved sending av hver forsendelse, enten gjennom Web Service eller manuell utsending. Vi anbefaler da å bruke SSL/TLS kryptering sammen med enten brukernavn/passord eller klient sertifikat. Begge deler burde være enkelt å få tak i via forvaltningsløsningen for kommunen.

28 SvarUt Side 28 av Autentisering ved nedlasting av forsendelse Nedlasting av dokumenter vil skje gjennom en lenke i Altinn-meldingen. Denne lenken vil være beskyttet av ID-portens innlogging. Brukeren er mest sannsynlig allerede innlogget via Id-porten i Altinn, og vil da ikke merke noe til autentiseringen. Hvis han ikke skulle være innlogget vil han få opp ID-portens innloggings-side. Den enkelte kommunen må være oppmerksomme på at ID porten operer med ulike sikkerhetsnivåer og at bruker må ha tilgang til eid på rett sikkerhetsnivå. Prosjektet må utrede hvordan man best skal kunne legge til rette for at den enkelte kommune er i stand til å sikre at tjenestene er sikret på riktig nivå. Vi har enda ingen god løsning for meldinger til organisasjoner. Det er i dag kun Altinn som har informasjon om hvilke personer som har tilgang til dokumenter for en organisasjon, og vi har ikke klart å få noen tjeneste hos Altinn hvor vi kan hente denne informasjonen. Bergen kommune har forsøkt å løse dette ved å re-dirigere til en side i Altinn hvor brukeren kan velge organisasjon. Vi vil da få tilbake dette valget via innloggings informasjon (SAML). En ulempe med denne løsningen er at nedlastingen feiler om brukeren velger en annen organisasjon enn den som er koblet til den aktuelle forsendelsen Autentisering ved pålogging til forvaltning Vi anbefaler at hver kommune får tildelt et felles brukernavn/passord for forvaltnings innlogging fra SvarUt administrator Drift Dette dokumentet vil ikke gå inn på detaljer vedrørende drift av sentralisert SvatUT, men vil presentere noen viktige momenter. Responstid for nedlasting. Dokumenter må kunne leveres raskt til bruker. Nedlastingen bør starte innen ett sekund. Lagringsplass for forsendelsesarkiv. Alle dokumenter som blir sendt må lagres. Det må avklares, hvor lenge dokumentene skal/kan ligge lagret her. Det må tas høyde for plassbehov på serveren og filområdet må kunne utvides under bruk. Bergen kommune har mange f.eks. forsendelser som er under 100 KB men også noen som er oppe i MB. Skalerbarhet Løsningen må kunne skalere både for nedlasting og utsending. Programmet bør derfor kunne installeres på flere servere med lastbalansering for grensesnitt. En må kunne regne med at i peak-perioder vil det kunne komme flere forsendelser hvert sekund.

29 SvarUt Side 29 av Sentrale sak-/arkiv leverandører Prosjektet har vært i dialog med de mest sentrale sak- arkiv leverandørene (Noark5 godkjente) og beskrevet SvarUt komponenten for å informere og få tilbakemeldinger knytet til utfordringene de mener å ha med å tilpasse systemene de har levert til kommunene. I møter har alle sak- arkiv leverandørene bekreftet at de kan ha løsninger klar i løpet av desember Kontaktpersoner hos de ulike leverandørene: Evry, leverandør av ESA og ephorte o Espen Sjøvold o Sjur Østvold o Knut Magnus Aasli SI, leverandør av DocuLive og 360 o Morten Jensen o Halvor Walla ACOS, leverandør av Websak o Even Syvertsen o Ivar W. Thomassen

30 SvarUt Side 30 av 35 Vedlegg 1: Dagens løsning i Bergen kommune Overordnet systembeskrivelse SvarUt er en løsning for å kunne sende utgående post fra kommunen i et elektronisk format og for utsending av vanlig brevpost SvarUt er en komponent som er tett integrert med sak/arkiv-systemet og støtter både elektronisk forsendelse og tradisjonell post. SvarUt loggfører, overvåker og kontrollerer. SvarUt er utviklet i Bergen kommune og har vært i drift i en periode med godt resultat. Følgende skisse viser SvarUt og tilhørende grensesnitt. Figur 16 Dagens løsning i Bergen kommune SvarUt-applikasjonen SvarUt er utviklet i Java og er i sin helhet fritt tilgjengelig gjennom GitHub på adressen I korte trekk består SvarUt av: svarutlib: svarutsample: svarutsampletests: Selve SvarUt-applikasjonen. Java-prosjekt for oppsett av SvarUt. Java-prosjekt for unit-tester av applikasjonen og grensesnittene.