For spesielt interesserte

idea dg1 analysis dg2 realize dg3 deploy dg4 drift dg5 exit

Vedtakspunkt 5 (V5)

I dette vedtakspunktet beslutter vi om en tjeneste skal avvikles. Tjenesten vil fortsatt være i drift under avviklingsperioden. Nedenstående spørsmål skal dokumenteres i malen for tjenestenedleggelse.

  • Er levedyktighet vurdert ved hjelp av forhåndsdefinert måleparametere (KPI)?
  • Er konsekvensanalyse utført?
  • Er tjenestenedleggelsen forankret hos interessentene?
  • Har prioriteringsrådet for tjenesteområdet uttalt seg om tjenestenedleggelsen?

Mal for tjenestenedleggelse nederst på denne siden brukes i vedtakspunkt 5 (V5).

Grunnlaget for avgjørelsen om at en tjeneste skal legges ned kommer fra en evaluering av gevinstestimat definert tidligere i livssyklusen målt opp mot tilbakemeldinger fra tjenesteporteføljegjennomgangene.

Vedtakspunkt 4 (V4)

Vedtakspunkt 4 er overgangen til drift i produksjon. Nedenstående spørsmål og krav skal være oppfylt.

  • Hvilken prosessvariant er brukt (felles offentlig anskaffelse, anskaffelse med utprøving, egenutviklet tjeneste)?
  • Sikre at nødvendig opplæring er fullført
  • Sikre at nødvendig brukerstøtte er klart
  • Sikre at målparametre for gevinst (Key Performance Indicators) er definert
  • Spesifiser hvor lenge UNINETT binder seg til at tjenesten skal være i drift (default er to år)
  • Sikre at interessenter som skal rådføres og/eller informeres om endringer er definert

Ved vedtakspunkt 4 vurderes dokumentasjon av disse punktene i evalueringsrapporten (B4) fra prosjektrammeverket.

Vedtakspunkt 3 (V3)

De nedenstående spørsmål knyttet til vedtakspunkt 3 skal dokumenteres i overleveringsplan (B3) eller beslutningsgrunnlag.

  • Hvilken prosessvariant er brukt (felles offentlig anskaffelse, anskaffelse med utprøving, egenutviklet tjeneste)?
  • Dokumenter at tjenesten oppfyller kvalitetskravene definert i V2
  • Gjennomføre en risikovurdering. Ta kontakt med infosikk@uninett.no 
  • Sikre at de etterspurte opplysninger om kundetjenesten er lagt inn i tjenesteregisteret
  • Sikre at de etterspurte opplysninger om systemtjenesten er lagt inn i systemtjenesteregisteret
  • Sikre at rollen driftsansvarlig er besatt og at navnet er registrert i systemtjenesteregisteret
  • Sikre at driftsinstruks er beskrevet
  • Sikre at hensiktsmessig logging og monitorering av tjenesten er definert og klargjort 

Ved vedtakspunkt 3 vurderes dokumentasjon av disse punktene i overleveringsplanen (B3) fra prosjektrammeverket.

 

Vedtakspunkt 2 (V2)

Dette vedtakspunktet inneholder krav som sier noe om estimert størrelse på forventet gevinst ("business case"), om integrasjon med helheten (arkitektur), og om etableringsplanen. Nedenstående spørsmål knyttet til vedtakspunkt 2 skal dokumenteres i prosjektplan (B2) eller beslutningsgrunnlag. 

  • Hvilken prosessvariant er valgt (felles offentlig anskaffelse, anskaffelse med utprøving, egenutviklet tjeneste)?
  • Hvem er tjenesteansvarlig?
  • Hvem er tjenesteeier?
  • Er tjenesten registrert i tjenesteregisteret?
  • Hva er navnet på tjenesten (sjekk med kommunikasjon)?
  • Beskriv forholdet til andre løsninger eller systemer (porteføljekontekst). Finnes det lignende tjenester i vår portefølje, i UH-sektoren eller på markedet? Hvilke integrasjonsbehov har tjenesten?
  • Har prioriteringsrådet for tjenesteområdet uttalt seg om tjenesten?
  • Beskriv hvordan tjenesten skal finansieres, inkludert skisse til betalingsmodell

 

 

Vedtakspunkt 1 (V1)

Nedenstående spørsmål knyttet til vedtakspunkt 1 skal dokumenteres i malen for forretningslerret som vedlegg til prosjektmandat (B1) eller beslutningsgrunnlag og godkjennes av UNINETTs ledergruppe. ​

  • Beskrive en skisse til forretningsmodell ved hjelp av forretningslerret. Ta kontakt med tjenestehjelp@uninett.no for bistand. * 

Ved vedtakspunkt 1 skjer to ting utover go/no go:

  1. Det blir avgjort om behandling av V2, V3 og V4 skal skje i ledergruppen eller om det skal delegeres.  
  2. Det avgjøres hvorvidt tjenesten trenger en mentor/revisor fra UNINETTs arkitekturforum til å følge den opp i utviklingen gjennom livssyklusen. Som en del av denne oppfølgingen kan det avholdes "review" etter behov.

* Forretningslerretet tar utgangspunkt i Business Model Canvas fra Strategyzer.

 

Avviklingsfasen

I denne fasen driftes tjenesten som normalt. Kunder benytter avviklingsperioden til å finne alternative løsninger. Aktiviteter relatert til tjenesten i denne fasen inkluderer følgende:

  • Drift fram til sluttdato.  Default sluttdato er to år fra tjenesten er bestemt nedlagt.  Andre datoer kan besluttes med begrunnelse.
  • Etter driftslutt ryddes ressurser knyttet til tjenesten (data, programvare, utstyr).
  • Tjenesten har status ”utfasing”

Drift- og videreutviklingsfasen

I denne fasen er tjenesten i drift.

Aktivitetene knyttet til tjenesten inkluderer:

  • Løpende drift av tjenesten.
  • Årlig vurdering av tjenestens gevinst i henhold til målparametre (KPI) i tjenesteporteføljegjennomgangen
  • Videreutvikling av tjenesten i henhold til plan
  • Datamodellering relatert til videreutvikling av tjenesten (tilpasning til UNINETTs overordnede datamodell) etter behov.

Tjenesten har status ”produksjon”

Utrullingsfasen

Formålet med utrullingsfasen er å samle erfaringer fra en prøvedrift som er så lik produksjon som mulig. 

I utrullingsfasen skal ansvaret for forvaltningen av tjenesten overføres fra den midlertidige organisasjonen (prosjekt, faggruppe, IoU, el. l.) til linjeorganisasjonen og/eller kunden. Følgende må vurderes/være på plass i denne fasen:

  • Opplæring
  • Brukerstøtte
  • Løpende drift
  • Ev. videreutvikling av tjenesten på grunnlag av erfaringer med eksperimentell tjeneste/pilot. (Dette må være avsluttet før evt. overlevering av tjenesten, ev. inngå i plan for videreutvikling i produksjonsfasen.)

Disse punktene skal beskrives når evalueringsrapporten fylles ut i prosjektrammeverket.  

En eventuell pilottjeneste kan etableres i denne fasen, og en eventuell eksperimentell tjeneste må endre status til pilot (eller legges ned).

Realiseringsfasen

I realiseringsfasen skal tjenesten utvikles eller anskaffes og klargjøres for pilotering.

Tjenesterealisering inkluderer følgende:

  • Tjenesten designes og utvikles for ferdigstilling i henhold til planen for etablering
  • Eventuell datamodellering for tjenesten, med tilpasning til UNINETTs overordnede datamodell.
  • Dersom det skjer signifikante endringer knyttet til områder dekket av arkitekturprinsippene må arkitekturforumet konsulteres underveis

En eventuell eksperimentell tjeneste kan etableres eller videreføres i denne fasen.

Analysefasen

Dersom det besluttes å gå videre med idéen (fase 1: idé), går man inn i analysefasen. Her kartlegges alternative tjenester i porteføljekonteksten og videreutvikles forretningsmodellen med videre detaljering av business-case og estimater på kostnadene og finansieringen. 

I denne fasen skal det:

  • Beskrives forholdet til andre løsninger eller systemer (porteføljekontekst) som første steg:
    • Finnes det lignende tjenester i vår portefølje, i UH-sektoren eller på markedet?
    • Hvilke integrasjonsbehov har tjenesten?
  • Lages business-case for tjenesten ved å estimere områdene i forretningsmodellen
  • Utredes konsekvenser av å innføre tjenesten på virksomhetsarkitekturen i UNINETT (både prosesser og systemer)
  • Planlegges etablering av tjenesten

Disse punktene skal beskrives når prosjektplan fylles ut i prosjektrammeverket.  

En eventuell eksperimentell tjeneste kan etableres eller videreføres i denne fasen.

Idéfasen

Idéfasen gjennomføres kontinuerlig i linjeorganisasjonen, og omfatter perioden fra en idé oppstår til det besluttes å gå videre for å etablere en tjeneste. En idé kan komme fra ulike kilder, og den enkelte medarbeider oppfordres til å spille inn tjenesteideer til ledelsen etter hvert som de dukker opp. 

Når en idé til en tjeneste eller et oppdrag om å etablere en tjeneste dukker opp i organisasjonen må følgende gjøres:

  • Skissere en forretningsmodell.
    • Hvilke behov skal tjenesten dekke – hvilke fordeler gir den kunden/brukeren?
    • Hvilke brukergrupper er tjenesten tiltenkt?
    • Hvilke type forlhold skal vi ha til kunden (f. eks. personlig oppfølging, selvbetjening, samarbeid)
    • Hvilke salgs-, distribusjons- og kommunikasjonskanaler ønsker våre kunder å bli nådd gjennom?
    • Hvordan blir tjenesten produsert og levert?
    • Hvilke ressurser blir brukt for å produsere tjenesten (f. eks. HW/SW, personell, kunnskap)?
    • Hvilke bidrag trenger vi fra andre samarbeidspartnere?
    • Hva er de viktigste kostnadene i forretningsmodellen og hvordan påløper de (f. eks. faste eller variable kostnader, stordriftsfordeler, kostnadssynergier ("economy of scope")
    • Hvilken inntekt eller andre gevinster forventes for UNINETT eller kunden/UH-sektoren?
  • Kartlegge relevante eksisterende tjenester (i vår portefølje, i UH-sektoren eller på markedet).
    - Finnes det tjenester som direkte eller gjennom videreutvikling kan dekke samme behov?
    - Hvilke andre tjenester vil tjenesten ha betydning for, eller være avhengig av?

Disse spørsmålene skal besvares når prosjektmandat fylles ut i prosjektrammeverket.  

I idéfasen er det mulig å etablere en eksperimentell tjeneste for å teste ut idéen, ev. videreføre en eksperimentell tjeneste som er opphav til idéen.

Felles prosesselementer

UNINETTs tjenestelivssyklus er et rammeverk som bidrar til god tjenesteforvaltning, prioritering og porteføljestyring. Den benyttes av UNINETT selv for egne tjenester og av grupper av institusjoner som deltar i felles anskaffelser for universitets- og høgskolesektoren. 

Syklusen hjelper organisasjonen med å ta de riktige skrittene for å realisere tjenesten. Den brukes også til å finne ut om organisasjonen er klar til å etablere den, om det er tilstrekkelige ressurser til å forvalte tjenesten og om et eventuelt driftsapparat er klart.

Lyseblå og mørkeblå felter
Tjenestelivssyklusen er vist i to farger: lyseblå og mørkeblå. De første lyseblå fasene utføres vanligvis innenfor prosjekter. Vedtakspunktene V1–V4 utføres som tilleggsinstruks til prosjektrammeverkets B1–B4.

Tre varianter
Tjenestelivssyklusen har tre varianter som er tilpasset de forskjellige tjenesteetableringsprosessene vi benytter. Velg prosessvariant ut fra ditt anvendelsesområde. Mer detaljerte beskrivelser av anvendelsesområdene finnes på sidene for prosessvariantene. Ta kontakt med tjenestehjelp@uninett.no om du lurer på noe. Aktiviteter og sjekklistepunkter som er spesifikke for den valgte prosessvarianten vises med gul bakgrunn.

Hurtiglenker:

Tillegg for anskaffelse med utprøving (iterativ)
  • Produktutprøving
Tillegg for anskaffelse med utprøving (iterativ)
  • Høring med brukergruppen
Tillegg for anskaffelse med utprøving (iterativ)
Ingen tillegg.
Tillegg for anskaffelse med utprøving (iterativ)
Ingen tillegg.
Tillegg for anskaffelse med utprøving (iterativ)
Ingen tillegg.
Tillegg for anskaffelse med utprøving (iterativ)
Ingen tillegg.
Tillegg for anskaffelse med utprøving (iterativ)
Ingen tillegg.
Tillegg for anskaffelse med utprøving (iterativ)
  • Rutinen for arkitekturvurdering av tjenester skal følges. Beskriv hvordan tjenesten oppfyller UNINETTs arkitekturprinsipper og Felles IKT-arkitekturprinsipper for universitets- og høgskolesektoren. Tjenester med systemteknisk implementasjon skal dokumentere systemarkitektur med tegninger over:
    1. ​​Hvilke moduler inngår i systemet? Hvilke grensesnitt finnes mellom dem? Hvilke data flyter gjennom grensesnittene?
    2. Hvilke grensesnitt finnes mot andre systemer i omgivelsene? Hvordan flyter data gjennom grensesnittene?
    3. Hvilke data brukes og genereres, og hva er relasjonene mellom dem (hva er den logiske datamodellen)?
    4. Hvilke autentiserings-, autorisasjons- og konteringsmekanismer finnes i systemet?
  • Beskrivelsen skal gjennomgås med UNINETTs arkitekturforum. Ta kontakt med arkforum@uninett.no så tidlig som mulig for å avtale gjennomgang og eventuell bistand. 

  • Definere hva som er god nok kvalitet for tjenesten (inklusiv konfidensialitet, integritet og tilgjengelighet) og hvordan vi kan måle det (kvalitetskrav)
  • Gjennomføre en risikovurdering. Ta kontakt med infosikk@uninett.no 
  • Utarbeide prosjektplan for etablering av tjenesten
  • Estimer direktekostnader og timekostnader fram til V3
  • Anslå behov for fellestjenester (f. eks. driftssenter, orakeltjeneste, etc.)
  • Må ha en aktiv brukergruppe
  • Oppsummer brukergruppens syn på forslaget
  • Hva er konsekvensene av å innføre tjenesten (inkludert eventuelle endringer i systemportefølje og arbeidsprosesser) for UNINETT?
  • Hva er konsekvensene av å innføre tjenesten (inkludert eventuelle endringer i systemportefølje og arbeidsprosesser) for kundene?
Tillegg for anskaffelse med utprøving (iterativ)
Tillegg for anskaffelse med utprøving (iterativ)
  • Direkte og indirekte kostnader for livsløpet
  • Estimert gevinst (inntekt eller besparelser) for livsløpet
  • Rettferdiggjør bruksvolumet tjenesten?
Tillegg for anskaffelse med utprøving (iterativ)
Ingen tillegg.

Anskaffelse med utprøving (iterativ) brukes når det er behov for en sektoravtale forvaltet av UNINETT, og når man ønsker å prøve den ut hos brukergruppen for å se om den slår an før man binder seg til å tilby tjenesten over tid. En del av tjenestene som har kommet gjennom eCampus-programmet er eksempler på dette.

Tillegg for felles offentlig anskaffelse (fossefall)
Ingen tillegg.
Tillegg for felles offentlig anskaffelse (fossefall)
  • Gjennomføre høring i sektoren
  • Sondere leverandører og tilgjengelige systemer
  • Utrede konsekvenser av å innføre tjenesten (inkluderer eventuelle endringer i systemportefølje og arbeidsprosesser)
Tillegg for felles offentlig anskaffelse (fossefall)
  • Detaljere kravspesifikasjon om nødvendig
  • Gjennomføre anbud
  • Skrive kontrakt
Tillegg for felles offentlig anskaffelse (fossefall)
Ingen tillegg.
Tillegg for felles offentlig anskaffelse (fossefall)
  • Når det nærmer seg kontraktens utløp skal det gjøres en vurdering på om kontrakten skal utlyses, og om opsjonen for forlengelse eventuelt skal benyttes
  • Ved ny kontrakt må prosessen tilbake til analysefasen
Tillegg for felles offentlig anskaffelse (fossefall)
Ingen tillegg.
Tillegg for felles offentlig anskaffelse (fossefall)
Ingen tillegg.
Tillegg for felles offentlig anskaffelse (fossefall)
  • Beskriv tjenesten
  • Beskriv overordnede krav til leverandøren(e)
  • Spesifiser arkitekturkrav til anskaffelsen i henhold til Felles IKT-arkitekturprinsipper for universitets- og høgskolesektoren. Krav skal inneholde forespørsel om dokumentasjon av systemarkitektur med tegninger over:
    1. ​​Hvilke moduler inngår i systemet? Hvilke grensesnitt finnes mellom dem? Hvilke data flyter gjennom grensesnittene?
    2. Hvilke grensesnitt finnes mot andre systemer i omgivelsene? Hvordan flyter data gjennom grensesnittene?
    3. Hvilke data brukes og genereres, og hva er relasjonene mellom dem (hva er den logiske datamodellen)?
    4. Hvilke autentiserings-, autorisasjons- og konteringsmekanismer finnes i systemet?
  • Spesifiser anskaffelseskrav som sikrer ønsket kvalitet (inklusiv konfidensialitet, integritet og tilgjengelighet) og hvordan vi kan måle det
  • Spesifiser sikkerhetskrav til anskaffelsen
  • Gi føringer på implementeringsbehov
  • Estimer direktekostnader og timekostnader for forventet livsløp
  • Anslå behov for fellestjenester (f. eks. driftssenter, felles førstelinje, etc.)
  • Estimer inntekter og/eller besparelser for forventet livsløp
  • Hva er konsekvensene av å innføre tjenesten (inkludert eventuelle endringer i systemporteføljen og arbeidsprosessene) for UNINETT?
  • Hva er konsekvensene av å innføre tjenesten (inkludert eventuelle endringer i systemporteføljen og arbeidsprosessene) for kundene?
  • Dersom det ikke er mulig å besvare noen av spørsmålene, gjerne fordi informasjonen ikke finnes, begrunn manglende informasjon
Tillegg for felles offentlig anskaffelse (fossefall)
Tillegg for felles offentlig anskaffelse (fossefall)
Ingen tillegg.
Tillegg for felles offentlig anskaffelse (fossefall)
Ingen tillegg.

Felles offentlig anskaffelse (fossefall) anvendes når UNINETT er koordinator for felles anskaffelser i UH-sektoren. Her er det prosjektstyringsgruppen for anskaffelsen som gir innspill til styring av tjenesten gjennom idé, analyse, realisering og utrulling. Prioriteringsrådet for området overtar denne rollen når tjenesten kommer i normal drift. Prosessen er definert i henhold til lov om offentlige anskaffelser. Den legger opp til et samarbeid med deltakende institusjoner om en detaljert tjenestespesifikasjon tidlig i prosessen og håndtering av tilbud fra potensielle leverandører. Denne prosessvarianten benyttes oftest for administrative og undervisningsnære tjenester.

Tillegg for egenutviklet tjeneste (iterativ)
  • Eksperimentering
  • Prototypeutprøving
Tillegg for egenutviklet tjeneste (iterativ)
  • Spesifisere prosessplan, men ikke detaljerte leveranser
  • Spesifisere krav- og utviklingsprosesser
  • Høring med brukergruppen
Tillegg for egenutviklet tjeneste (iterativ)
  • Utviklingsprosessen må bygge inn sjekk for at porteføljeansvarlige godtar utviklingen underveis
Tillegg for egenutviklet tjeneste (iterativ)
Ingen tillegg.
Tillegg for egenutviklet tjeneste (iterativ)
Ingen tillegg.
Tillegg for egenutviklet tjeneste (iterativ)
Ingen tillegg.
Tillegg for egenutviklet tjeneste (iterativ)
Ingen tillegg.
Tillegg for egenutviklet tjeneste (iterativ)
  • Rutinen for arkitekturvurdering av tjenester skal følges. Beskriv hvordan tjenesten oppfyller UNINETTs arkitekturprinsipper og Felles IKT-arkitekturprinsipper for universitets- og høgskolesektoren. Tjenester med systemteknisk implementasjon skal dokumentere systemarkitektur med tegninger over:
    1. ​​Hvilke moduler inngår i systemet? Hvilke grensesnitt finnes mellom dem? Hvilke data flyter gjennom grensesnittene?
    2. Hvilke grensesnitt finnes mot andre systemer i omgivelsene? Hvordan flyter data gjennom grensesnittene?
    3. Hvilke data brukes og genereres og hva er relasjonene mellom dem (hva er den logiske datamodellen)?
    4. Hvilke autentiserings-, autorisasjons- og konteringsmekanismer finnes i systemet
  • Beskrivelsen skal gjennomgås med UNINETTs arkitekturforum. Ta kontakt med arkforum@uninett.no så tidlig som mulig for å avtale gjennomgang og eventuell bistand. 
  • Definere hva som er god nok kvalitet for tjenesten (inklusiv konfidensialitet, integritet og tilgjengelighet) og hvordan vi kan måle det (kvalitetskrav)
  • Gjennomføre en risikovurdering. Ta kontakt med infosikk@uninett.no 
  • Utarbeide prosjektplan for etablering av tjenesten
  • Estimer direktekostnader og timekostnader for forventet livsløp
  • Anslå behov for fellestjenester (f. eks. driftssenter, orakeltjeneste, etc.)
  • Estimer inntekter og/eller besparelser for forventet livsløp
  • Beskriv krav- og utviklingsprosessene
  • Må ha en aktiv brukergruppe
  • Redegjør for hvordan brukergruppen fungerer
Tillegg for egenutviklet tjeneste (iterativ)
Tillegg for egenutviklet tjeneste (iterativ)
  • Oppdatert direkte og indirekte kostnader for livsløpet
  • Oppdatert estimert gevinst (inntekt eller besparelser) for livsløpet
  • Rettferdiggjør estimert bruksvolum tjenesten?
Tillegg for egenutviklet tjeneste (iterativ)
Ingen tillegg.

Egenutviklet tjeneste (iterativ) brukes av UNINETT for egen tjenesteutvikling. Det er en iterativ prosess, og passer godt sammen med SCRUM, DevOps og andre smidige utviklingsmetoder. Her er det det mindre vekt på detaljspesifikasjon av fremtidig leveranse og mer vekt på å sikre en god læringsprosess der man gjennom hyppige tilbakemeldinger fra interessenter er i stand til å ta gode valg underveis. Eksempler på tjenester som kan være godt egnet for denne prosessvarianten er tjenester muliggjort av nye teknologier som IoU eksperimenterer med.