Bakgrunn og begrunnelse for prosjektet
USIT har i lang tid sett behovet for et Software Asset Management (SAM) -system, som kan styre anskaffelse og omfordeling av programvarelisenser på UiO.
Et SAM-system kan innføres med forskjellige grader av funksjonalitet.
En full innføring kan bety helautomatikk fra et brukerbehov oppstår til programvare er kjøpt og distribuert til bruker, flytting av lisenser mellom brukere, og bruksstatistikk. Dette er et ambisiøst mål, som må fungere uavhengig av hvilket økonomisystem UiO velger. Et alternativ er ikke å integrere med økonomisystemet, men eventuelt ha det som en mulighet på et senere tidspunkt.
Vi vil både måtte finne ut hvilket nivå av funksjonalitet vi ønsker å benytte, hvilket system som er best egnet til å dekke dette formålet, samt avklare om et eventuelt samarbeide med førstelinjeforum og Uninett er hensiktsmessig.
Vi ser også en økende mengde programvare tilgjengeliggjort via for eksempel Apple sin "Appstore", Google sin "Play" og Microsoft sin "Windows Store". I dag foregår det en del kjøp med personlig kredittkort og påfølgende refusjon av utlegg her. Det er verdt å undersøke om et moderne SAM-system kan håndtere dette.
Vi ser en økende mengde programvare som tilbys som en skytjeneste. For eksempel Microsoft Office365 og Adobe Creative Cloud. Det er interessant å se på i hvilken grad moderne systemer for SAM, adresserer denne utviklingen.
Sentralt på tiltak 979059 faktureres i underkant av 10 mill.pr år. 60 % av dette på de to store postene MS Campus og SPSS. Det kjøpes i tillegg programvare lokalt. UiO har et økonomisk innsparingspotensiale ved å frigjøre lisenser når en ansatt slutter eller ikke lenger har behov. Vi har også en mulig økonomisk gevinst ved mer effektivt å kunne vurdere alternative lisensregimer, så som enkeltlisenser, volum eller site.
Mål og ønskede gevinster
| Nivå | Begrunnelse | Suksesskriterie |
|---|---|---|
|
Overordnet:
|
Det er et strategisk mål for UiO å redusere administrativ belastning | Mindre tid og oppmerksomhet brukt på lisenshåndtering |
|
Langsiktige gevinster:
|
Vi har i dag et system som ikke gir den oversikt og effektivitet mer moderne SAM-løsninger kan gi. Vi har ikke det styringsgrunnlaget vi kunne hatt, vi har flere manuelle oppgaver enn vi behøver, og vi har en større risiko for unøyaktigheter knyttet til menneskelige feil. Dette gjelder spesielt dersom det skulle dukke opp behov for oversikter vi ikke vedlikeholder løpende. Vi ser også nye lisensregimer, som nevnt over. Dagens rutiner fanger ikke opp disse på en god måte. Et moderne SAM-system vil gi bedre kontroll og mer effektiv distribusjon og redistribusjon av lisenser. Vi vil bruke mindre tid på manuelle oppgaver, kunne se bedre hvor vårt lisensregime er ineffektivt, og mer effektivt kunne levere oversikter og rapporter det måtte være behov for. |
Mer effektive bestillingsrutiner for programvare i systemet Enkelt å refordele lisenser, også for nye lisensregimer Mulighet for å produsere oversikter over reell bruk |
|
Prosjektets resultatmål:
|
Vi har ikke erfaring med moderne SAM. Vi må derfor gjøre et tilstrekkelig arbeid for å kunne fatte riktig valg av løsning. | Aksept for beslutning |
Rammebetingelser
En implementasjon må ikke komme i konflikt med Personopplysningsloven.
Lov om offentlige anskaffelser med forskrift blir ikke direkte en del av prosjektet. Prosjektet skal ikke selv anskaffe systemet. Hvorvidt løsningen utløser en anskaffelsesprosess og hvilken dette i tilfelle blir, vurderes i etterkant.
Konsekvenser for samordning i et fremtidig BOTT-samarbeid skal være en del av vurderingene.
Prosjektets leveranser og avgrensninger
| Leveranser | Beskrivelse |
|---|---|
| Anbefaling av hvilket (hvis noe) nivå av Software Asset Management som bør innføres på UiO | Vi må ha en realistisk vurdering av ressursbruk for å sette opp ny SAM, som tross alt er en støttetjeneste |
| Evaluering av ulike systemer for SAM og finne frem til systemet som passer best i forhold til UiOs behov | Vi kjenner ikke dette markedet i særlig dybde, og trenger et beslutningsgrunnlag. |
| Vurdering av om systemet bør kjøpes som en ren skytjeneste, settes opp i samarbeide med andre parter i UH-Sektoren, eller kjøres utelukkende for UiO | Vår strategisk føring er å samarbeide om fellesløsninger i sektoren der dette er mulig. Vi må som minimum ikke gjøre valg nå som forhindrer dette. |
| Sette opp en skisse av oppgaver og roller i systemet | Dette kan eventuelt skje parallelt med anskaffelse |
Avgrensninger:
Prosjektet skal komme med anbefalinger og underlag for anskaffelse, men ikke selv anskaffe eller implementere systemet.
Vurdering av prosjektets usikkerheter, trusler og muligheter
Interne og eksterne forhold som påvirker prosjektets leveranser (hva er det viktig at prosjektet forholder seg til?):
| Trusler | Beskrivelse | Reduserende tiltak |
|---|---|---|
| Ulike rolledefinisjoner i organisasjonen | Forskjellige enheter kan ha ulik arbeidsflyt og rollefordeling | Intervjuer med lokalmiljøene |
| Integrasjon med eksisterende systemer | Et effektivt SAM må minimum integreres med identitetshåndtering og deployering. Erfaringsmessig introduserer dette komplikasjoner. Hvis konkrete konsekvenser av dette ikke er tilstrekkelig forstått, kan implementasjonen bli forsinket. | Kommunikasjon med driftsorganisasjonen |
| App- og skylisensmarkedet er relativt nytt | Vi har begrenset erfaring med å systematisere administrasjon av apps og med lisensregimer som f.eks. Creative Cloud. Vi må forstå hvilke behov vi får, og hvilke hensyn vi må ta. | Kommunikasjon med eksterne partnere |
| Ressurstilgang | Enkeltpersoner er tett booket | Utnytte tiden, fokusere på "godt nok", ikke forfølge løsninger som ikke har realistisk mulighet for å komme ut som den beste løsningen |
| Muligheter | Beskrivelse | Tiltak |
|---|---|---|
Valg av alternativ kost/nytte-vurdering
Alternative løsninger/konsepter med vurdering og valg
Avgrensingen er valgt for å få en så enkel og oversiktlig prosess som mulig.
En funksjonell anbudsforespørsel vil uansett kreve en tilsvarende utredning av behov og føringer. En helt åpen forespørsel uten kunnskap om produktområdet innebærer en betydelig risiko for feilanskaffelse.
Det mest realistiske alternativet er fortsette som i dag, med samme arbeidsflyt.
Gevinstoversikt
| Gevinster | For hvem, og hvordan fremkommer gevinsten? | Forutsetninger for at gevinsten skal realiseres |
|---|---|---|
| Raskere løp fra behov til installert programvare |
Faglig ansatte: Kan bestille når behovet faktisk materialiserer seg Lokal-IT og lokal bestillingsfunksjon: Enklere og mindre arbeidskrevende prosess |
Brukervennlig system Oversikt over arbeidsflyt og roller Mulighet for lokalt å flytte lisenser |
| Mindre overlisensiering |
Faglig ansatte: Må i mindre grad bestille preemptivt, men kan vente til behovet materialiserer seg USIT: Kan forhandle riktig lisensregime Lisensbetalere lokalt og sentralt: Mer effektiv utnyttelse av lisensene |
At de forskjellige deler av organisasjonen legger inn relevante programvarelisenser i systemet God rollebasert tilgang At lisenser kan flyttes og frigjøres |
| Oversikt over alle større programvareporteføljer | Lokal-IT: Kan enkelt se hvilken programvare som er i utstrakt bruk, hvilke lisenser som er i bruk, og økonomisk konsekvens |
At de forskjellige deler av organisasjonen legger inn relevante programvarelisenser i systemet God rollebasert tilgang |
| Samlet oversikt over økonomiske konsekvenser av lisensbehov | Lokal og sentral ledelse: Beslutningsunderlag for budsjettarbeid | At de forskjellige deler av organisasjonen legger inn relevante programvarelisenser i systemet |
Nytte/kost-vurderinger
| Økonomiske hovedtall/kvalitative gevinster | 2017 | 2018 |
|---|---|---|
| Prosjektutgifter eksterne | Minimale | |
| Prosjektutgifter interne (ressursbruk personell) | Inntil 2 månedsverk | |
| Økonomiske gevinster (besparelser) | Anbefalingen i seg selv gir ikke direkte gevinst | Effektivisering av arbeid og lisensbruk som følge av implementasjon (dette vil være en egen oppgave etter avslutning av prosjektet). Prosjektet vil vurdere hva disse innsparingene kan bli. |
| Kvalitative gevinster | ||
|
Mindre distraksjon med administrative oppgaver | |
|
Bedre beslutningsgrunnlag for avgjørelser om lisensiering, bedre treffsikkerhet |
Grov tidsplan og milepæler
- 1. oktober Levert anbefaling
- 15. oktober Beslutning, påbegynt anskaffelse
- 15. desember Produksjonssatt
Organisering, roller og ansvar
Prosjekteier Anders Vinger
Prosjektleder Øyvin Wormnæs
Prosjektdeltagere Karine Fluge Ulleberg, Mohammed Abdulhamid Hamza, Andre Øien, Gunnar Horrigmo
Prosjektleder 2 månedsverk
Prosjektdeltakere 3 ukeverk per person
Interessenter/målgrupper
Interessenter, påvirkning på prosjektet eller påvirket av prosjektet
- Crayon
- CMDB
- Andre USIT
- Innkjøp
- Klientdrift
- Serverdrift
- Integrasjonsarkitektur
- Lokal-IT
- Økonomi/regnskap
- Juristene
Budsjett
Noe kostnader til møtevirksomhet/reisevirksomhet må påberegnes.
Endringslogg
<Prosjektbeskrivelsen vedtas som utkast før planleggingsfase, og i endelig versjon i overgang til gjennomføringsfasen. Ved store endringer i prosjektet underveis, og minst i overgang mellom definerte gjennomføringsfaser skal dokumentet oppdateres. Ved overgang fra planleggings- til gjennomføringsfase, og ved senere revisjoner, skal det angis hvilke endringer som er gjort, hvem som har gjort endringen, og hvem som har godkjent at endringen blir foretatt.>
| Versjon | Dato | Endring | Ansvar for å beskrive endring | Ansvar for godkjenning av endring |
|---|---|---|---|---|
Distribusjonslogg
<For å sikre at alle relevante interessenter har mottatt siste versjon av prosjektbeskrivelsen, må distribusjonsloggen oppdateres i tråd med versjonshåndteringen.>
| Versjon | Dato | Mottakere |
|---|---|---|