Hopp til hovedinnhold

Slik kan dere bruke modellene i ulike faser

Utvikling av en sammenhengende tjeneste har et varierende forløp, og det kan bli behov for å endre både styringsmodell og organisering underveis.

Styring og organisering av en sammenhengende tjeneste og livshendelser må forholde seg til at utviklingen av slike tjenester har et varierende forløp. Forløpet avhenger blant annet av hvor mye en vet om utfordringen og de ulike aktørenes bidrag til å løse den. Etter hvert som en får mer kunnskap om aktører og hvilke aktiviteter som må gjennomføres, kan det bli behov for å endre både styringsmodell og organisering av tiltaket.

Selv om utvikling av sammenhengende tjenester kan ha ulike forløp, er det identifisert tre faser i Digdirs veileder "Hvordan lage sammenhengende tjenester". Fasene illustrerer brukerreisen for tjenesteutvikling i samarbeid med andre og gir forslag til vurderinger og aktiviteter en aktør bør gjøre avhengig av hvor de er i forløpet.

    Modell for sammenhengende tjenester.

    Gjennom alle fasene vil det måtte tas valg når det gjelder styring og organisering, i tillegg til forankring, samarbeid og hvordan brukerperspektivet skal ivaretas. Overgangen mellom fasene er ikke alltid like klar, og ulike deler av et overordnet tiltak kan ha tiltak i ulike faser til samme tid. Et eksempel på dette er livshendelsen Dødsfall og arv hvor man jobbet med å få innsikt i livshendelsen (dvs. forme sammen) samtidig som man jobbet med utvikling og test av løsning (dvs. levere sammen) for et område i livshendelsen (oppgjør etter dødsfall). Når aktørene sammen identifiserer og velger tiltak de ønsker å gjennomføre, er det aktuelt å gjøre nye vurderinger om hvordan samarbeidet skal starte dersom nye aktører trekkes inn i samarbeidet.

    Fasene representerer behovet for et kontinuerlig skifte i oppmerksomheten arbeidet med livshendelser og sammenhengende tjenester vil ha. Modellene, på sin side, representer ulike innganger til styring som kan benyttes i større eller mindre grad i de ulike fasene. Erfaringer fra igangsatt arbeid med livshendelser og sammenhengende tjenester viser at ulike varianter av programmodellen ofte velges. Samtidig er variasjonen stor, og styring og organisering kan endre seg gjennom forløpet som beskrevet i fasene under.

    Nedenfor har vi beskrevet hvordan styring og organisering av Altinn har endret seg over tid. Altinn er i seg selv ingen sammenhengende tjeneste eller livshendelse. Caset er likevel interessant fordi det illustrerer styring og organisering som et forløp med ulike modeller for styring og organisering til ulike tider.

    Da Altinn ble lansert i 2003, var det som et samarbeid mellom Skatteetaten, Statistisk sentralbyrå og Brønnøysundregistrene for å forenkle og effektivisere innrapportering og dialogen med det offentlige. Altinn var opprinnelig en forlengelse av et annet prosjekt de tre samarbeidet om, som skulle gjøre mulig for næringsdrivende å sende blant annet ligningsskjemaer til de tre etatene.

    Oppstarten var knyttet til et avgrenset mål om å levere en plattform for felles innrapportering. Arbeidet ble organisert som et felles prosjekt, med tydelige leveransekrav. Samarbeidet ble ikke besluttet politisk, eller styrt som et oppdrag av departementene, men var behovsdrevet og bygd på erfaringene fra det opprinnelige prosjektet. Etableringen av Altinn var i stor grad drevet av ildsjeler i etatenes toppledelse, og samarbeidet bygget på høy tillit dem imellom. Brukerne, og spesielt «proffbrukerne», ble også tatt med i utviklingsprosessen. Skatteetaten bidro med mest ressurser i spleiselaget for utvikling av Altinn, men styringsformen var basert på samstyring.

    Etter at Altinn var lansert, og tilbakemeldingene var positive, ble også videre utvikling av samarbeidet og funksjonalitet sentralt. Det ble etablert et eget Altinn styringsråd hvor alle tjenesteeierne deltok, og hvor prioriteringer innen utvikling ble samstyrt. Etter hvert ble også grunnfinansiering av Altinn en egen post på statsbudsjettet. Brønnøysundregistrene skulle håndtere styringsdialogen opp mot departementsnivået. Tanken bak det var å unngå at største part, Skatteetaten, skulle bli en for sterk og dominerende aktør. Styringsdialogen var basert på målstyring, mer enn på detaljstyring av leveranser.

    Da Altinn II skulle utvikles, ble det valgt en programmodell for styring og organisering av dette store løftet. Utvikling fikk øremerket finansiering over statsbudsjettet. Altinn II innebar en vesentlig videreutvikling av funksjonalitet og omfang, og ambisjonen var at løsningen skulle bli en plattform for tjenesteutvikling i hele offentlig sektor. I styringen ble det lagt vekt på de omfattende gevinstene dette skulle utløse i offentlig sektor og blant brukerne.

    Altinn har i dag en stabil plattform som er i kontinuerlig utvikling, og en etablert forvaltningsorganisasjon. Altinn styres fortsatt etter hvilke samfunnsgevinster de skal bidra til å oppnå, men har en intern produktorganisering. Det innebærer tverrfaglige team, med fokus på kontinuerlig utvikling og forbedring av Altinn som produkt. Det er fortsatt samstyring med tjenesteeierne som legges til grunn ved spørsmål om prioriteringer. Samtidig har Altinn orientert seg mot å skape en samhandlingsplattform som skal kunne brukes av et større nettverk og økosystem av aktører – også de utenfor offentlig sektor. Samarbeidet rundt DSOP er et eksempel på det.

    Fase 1 Starte sammen

    Ved samarbeid om å lage sammenhengende tjenester starter aktørene med å utforske og definere problemstillingen for det arbeidet som skal settes i gang. Dere må finne og etablere mulige samarbeidsflater, kartlegge interessenter og gjøre de første avklaringer rundt roller og styringsstruktur. Målsettingen med fasen er å få etablert et mer formalisert samarbeid om en sammenhengende tjeneste, med en grunnleggende og felles styringsform, en avgrenset organisering og en felles problemforståelse.

    Fasen kan være preget av mye utprøving og kartlegging. Aktørbildet kan være uklart, og erfaringene tilsier at det er tidkrevende å utrede problemet og identifisere brukerbehov i tillegg til å skape gode samarbeidsrelasjoner. I denne fasen er det viktig at dere i tilstrekkelig grad besvarer utredningsinstruksens første spørsmål: Hva er problemet, og hva vil vi oppnå? I Prosjektveiviseren omtales dette som konseptfasen, mens dette i MSP er fasen «Identifisere programmet», som er prosessen som leder fram mot en fremtidsbeskrivelse. Felles for alle disse rammeverkene er at man starter med en problem- og behovsanalyse som grunnlag for å få fram det som skal oppnås med tiltaket eller tiltakene.

    Svak fellesforståelse av problemstillingen, behovene og hvilke mål som bør legges til grunn, kan innebære at det er større behov for fasilitering enn styring. I slike tilfeller kan arbeidsformen være preget av løse samhandlingsrelasjoner. Da kan jobben handle om å mobilisere ulike aktører og få en oversikt over utfordringsbildet, brukerinnsikt og relevante pågående utviklingsaktiviteter. I slike tilfeller vil nettverksmodellen være en nyttig ramme for å styre denne innsatsen.

    I andre tilfeller vil rammene for å starte sammen være klare, for eksempel ved at det bygger på eksisterende samarbeid, nye reguleringer som er besluttet, en detaljert behovsbeskrivelse eller klare politiske målsettinger. I slike tilfeller vil programmodellen kunne være godt egnet, gjerne i kombinasjon med aktørhåndtering fra nettverksmodellen. Om målet er avklart, og aktører i stor grad er identifiserte, kjenner hverandre og tilhører samme styringslinje, vil også prosjektmodellen kunne passe her.

    Ved utgangen av fasen bør samarbeidsaktørene ha:

    • Identifisert hvilke andre virksomheter som inngår i samarbeidet og hvilke roller og ansvar de ulike partene skal ha i Fase 2

    • Etablert en felles analyse av problemene og behovene som ligger til grunn for det området man ønsker å samarbeide om

    • Beskrevet ønskede mål og forventet effekt av den sammenhengende tjenesten på et overordnet nivå og ha forankret ønskede mål hos egen virksomhet og styrende departement

    • Avtalt hva fase 2 skal inneholde og resultere i eller belyse, inkludert estimater for tid, kostnader og personressurser

    • Inngått en samarbeidsavtale/-erklæring om finansiering, rolle- og ansvarsfordeling samt styringsstruktur for Fase 2

    Produktorientering er en form for organisering som først og fremst sikrer at man bygger det riktige produktet – det som har verdi for brukeren. Nær kontakt med brukere, kontinuerlig utvikling og forbedring står i sentrum. Å bli ferdig med en planlagt mengde funksjonalitet til et gitt tidspunkt og en gitt kostnad er definisjonen på prosjektsuksess – men ikke nødvendigvis på produkt- eller tjenestesuksess.

    Produktutvikling i en slik organisering har ingen ende, men er kontinuerlig og har fokus på forbedring av kvalitet og brukerverdi så lenge produktet lever. Det er altså ikke noen som først lager noe og så overleverer det til noen andre som skal drifte dette. Alt skjer i det samme, tverrfaglig sammensatte produktteamet.

    NAV har siden 2018 organisert seg i produktområder der områdene har ansvar for ulike livshendelser. Eksempelvis har produktområde Helse ansvar for livshendelsen «bli syk», som kan bestå av mange ulike livssituasjoner. Dette er en måte å ramme inn produktene, kompetansen og retningen NAV setter seg for en gitt livshendelse. Så finansierer NAV folk, og ikke oppgaver, slik at teamene settes i stand til å lære brukeren å kjenne. Basert på brukerinnsikt vil produktteamet hele tiden justere og iterere slik at produkter fungerer for både brukeren og forretningen. Altså skal teamene og området selv bestemme hvilke produkter og oppgaver som skal løses, basert på en strategi og retning gitt av eierne av produktområdet.

    Om det er noe helt nytt, men samtidig svært konkret, som skal utvikles, kan det være mer aktuelt å etablere et tverrsektorielt prosjekt for å levere den innledende tjenester. Er mange aktører involvert, og det er en viss åpenhet rundt hva som må gjøres og leveres av de enkelte for å oppnå målsettingen; er et tidsavgrenset program en god løsning.

    Etter de første leveransene vil løsningene mest sannsynlig både være i drift og videreutvikles – kontinuerlig. En løsning som ikke kontinuerlig videreutvikles (basert på endringer i regelverk, brukerbehov, teknologi etc.), havner bakpå, forvitrer og danner teknisk gjeld som krever større investeringer for å komme à jour.

    Det vil uansett være viktig å legge opp til at aktivitetene og leveransene er styrbare. Studier av store prosjekter som har mislyktes de siste 25 årene, peker på at et fellestrekk er svært store og komplekse utviklingsleveranser. Anbefalingene fra bl.a. Simula Research peker i retning av en styring som reduserer størrelsen på leveransene, og dermed ambisjonsnivået per aktivitet. De anbefaler heller hyppige, men mindre leveranser, smidig utviklingsprosesser og en gjennomgående gevinststyring (også omtalt som nyttestyring).

    Om det er mange parallelle og i utgangspunktet uavhengige initiativer som må koordineres for å realisere den sammenhengende tjenesten, kan det med fordel benyttes elementer av nettverksmodellen i en kombinasjon med program- og/eller prosjektmodellene. Programmodellen vil være egnet om fokus i denne fasen legges på gevinststyring og -realisering.

    Drift og forvaltning vil kreve en mer permanent struktur for både styring, organisering og finansiering. Normalt vil allerede eksisterende organisasjoner, f.eks. IT- og driftsavdeling, få ansvaret for drift og feilretting av hele eller deler av løsningen. Forvaltning treffer i større grad faginteressene, og bør underlegges de samme vurderingene som er gjort rundt styring av utviklingsaktivitetene. Styring handler både om finansiering – hvordan de faste og variable utgiftene fordeles, og om rolledeling og ansvar – hvordan beslutninger som innebærer endringer i tjenesten skal fattes. Begge deler bør avtales i god tid før løsningen er ferdig utviklet.

    Digdirs veileder "Hvordan lage sammenhengende tjenester":

    Fase 2 Forme sammen

    Fasen handler om å sammen skaffe tilstrekkelig innsikt i problem, behov og mulige konsepter til at utviklingsarbeidet kan begynne.

    I denne fasen skal utredningsinstruksens spørsmål nummer to til seks besvares. I Prosjektveiviseren omtales dette som konseptfasen, mens i MSP er dette fasen «definere programmet», som er prosessen som leder fram mot en fremtidsbeskrivelse.

    I noen samarbeid vil det raskt være klart hva som skal utvikles for å oppnå målsetting og leveranser, og fasen kan innebære detaljert planlegging. I andre tilfeller må det legges en mer utforskende tilnærming til grunn, og det gir innledningsvis mindre mening med en styringsform som tar utgangspunkt i detaljerte leveransebeskrivelser. Styringen må ta hensyn til kompleksitet, og det kan være riktigere å bli enige om hvilke gevinster en vil oppnå og styre det videre samarbeidet etter disse.

    Det er viktig at dere i denne fasen etablerer en struktur som gjør det mulig å ta en helhetlig og koordinert beslutning om hvordan dere vil gå fram for å oppnå målsettingen(e). Det er avgjørende at det etableres en form for avtale mellom partene i denne fasen som beskriver hva aktørene forplikter seg til når løsningen utvikles og siden forvaltes og driftes.

    Programmodellen vil være en spesielt god ramme for styring og organisering på tvers av virksomheter og sektorer om dere har lykkes med å etablere klare mål og forventede gevinster for livshendelsen og/eller den sammenhengende tjenesten. Om løsningen på problemstillingen fortsatt er helt eller delvis ukjent, og det fortsatt er åpent for å involvere nye samarbeidsaktører underveis, vil elementer fra nettverksmodellen også kunne være nyttig.

    Prosjektmodellen kan være egnet om det er kjente aktører, gjerne i samme styringslinje, som skal samarbeide om en problemstilling det er god oversikt over. Dette kan gi et smalere scope enn det som er ønskelig for en sammenhengende tjeneste.

    Ved utgangen av fasen bør samarbeidsaktørene ha:

    • Avklart hvilke aktører som skal samarbeide

    • Utviklet felles mål og visjon for samarbeidet basert på en felles problemforståelse

    • Utarbeidet ulike konseptforslag som kan svare ut målsettingen, og besluttet hvilket man går for og hvorfor

    • Beskrevet hvilke gevinster som forventes, hvor de skal inntreffe og hvordan de skal realiseres

    • Beskrevet hva som er nødvendig felles arkitektur og hva som kan håndteres hos den enkelte aktør

    • Beskrevet hvilke aktiviteter som vil forventes av de ulike partene

    • Beskrevet hvordan Felles økosystem for nasjonal digital samhandling og tjenesteutvikling økosystemet skal benyttes

    • Beskrevet risiko tilknyttet aktivitetene, og hvordan og av hvem disse skal håndteres

    • Forankret både målsetting, valgt konsept og aktiviteter hos alle berørte aktører, inklusiv virksomhetens ledelse, kommunesektorens representanter og berørte departementer

    • Sikret tilstrekkelig finansiering til at valgt konsept kan realiseres innen forventingene til effekter, leveranser og tid som er satt

    • Kartlagt juridiske forhold eller andre hindringer som krever en aktiv involvering fra departementene, og avklart at dette er mulig

    • Blitt enige om styringsstruktur som har mandat til å fatte beslutninger om å gå videre til Fase 3

    Digdirs veileder "Hvordan lage sammenhengende tjenester":

    Fase 3 Levere sammen

    Levere sammen er fasen der samarbeidet som partene er blitt enige om, skal gjennomføres. Tjenesten skal utvikles, innføres, komme i drift og forvaltes. Når de første delene av løsningen settes i drift, starter den videre forvaltningen. Forvaltning omfatter både administrasjon, feilretting og nødvendig videreutvikling. Basert på det valgte konseptet, skal dere i denne fasen utvikle løsning og etablere et godt og fremtidsrettet regime for styring og forvaltning av tjenesten. Styring handler i stor grad om å sørge for at utviklingen skjer i henhold til forventinger og de avtalene som er gjort, og at risiko overvåkes og håndteres fortløpende.

    Hvor stram styringen av utviklingsaktivitetene skal være, avhenger av hvilke målsettinger dere har definert, og hvor kompleks dere vurderer at oppgaven er.

    Dersom det er få aktører som skal stå for utviklingen, kan det være aktuelt å se på hvordan linjeorganisasjonen kan organiseres for å bidra. Dette kan for eksempel være ved å etablere en produktorganisering som også smidig kan håndtere overgangen til forvaltning.

    Digdirs veileder "Hvordan lage sammenhengende tjenester":

    Har du spørsmål eller tilbakemeldinger?

    Sammenhengende tjenester