O365 - Innledning

UNINETT har gjennom UH-Sky programmet i aktiviteten "Office 365 Startpakke" utformet et beste praksis dokument som skal være til hjelp for UH-institusjonene som ønsker å ta i bruk Office 365 eller lignende «basis samhandlings- og kontorstøtte skytjenester». Startpakken beskriver prosessene fra definering av behov, via utforming av kravspesifikasjon, risiko- og sårbarhetsanalyse og sikkerhetsvurderinger, til teknisk implementering og forvaltning av en slik tjeneste. O365 og tilsvarende tjenester består i praksis av et «økosystem» av ulike moduler som er mer eller mindre flettet inn i hverandre, og det er ofte vanskelig å se i hvilken rekkefølge og hvor raskt de ulike modulene bør implementeres for å få best mulig nytte av tjenesten. Et «beste praksis» -dokument skal gi råd og starthjelp for oppsett av slike tjenester, basert på erfaringer fra virksomheter som har tatt i bruk tjenesten og fra konsulentbransjen som bistår med å sette opp løsningene.

Det skal ligge et definert behov bak innføringen av nye IT-systemer. En behovsanalyse starter med å vurdere hvilken hensikt systemet skal tjene. Typisk for virksomheter som innfører O365 er at de i flere år har benyttet Office-produktene til kontorstøtte, kanskje har de allerede brukt lokalt installert Exchange e-postserver (med Outlook e-postklient), og mange har tatt i bruk Lync/Skype for intern samhandling i virksomheten. Utviklingen av slike tjenester går i retning av stadig mer integrasjon mellom tjenestene og mot nye moduler og applikasjoner som utvikles. Det er naturlig at steget videre går i retning av skyløsninger, da leverandørenes åpenbare strategi er å levere tjenestene i skyen.

En behovsanalyse må være forankret i bedriftens generelle virksomhetsstrategi, evt. IT-strategi eller sky-strategi hvis man har det, og ta høyde for de endringer og utviklingsønsker som er definert i strategiene. Man ser at stadig flere virksomheter utvikler en egen sky-strategiplan i tillegg til planen for virksomhetsstrategi eller som en del av IT-strategiplanen. Dette er å anbefale for virksomheter av en viss størrelse.

Behovsanalysen må også se på markedet og de endringene i arbeidsprosesser og arbeidsmetoder som til enhver tid kommer som følge av ny teknologi. Det er naturlig å kjøre behovsanalyse som en intern prosess i en arbeidsgruppe bestående av representanter fra ulike deler av virksomheten. Dersom IT-sjefen allerede har et etablert rådgivende IT-utvalg med representanter fra både fagansatte, administrativt tilsatte, studentene og tillitsvalgte, kan det være et naturlig forum for behovsanalyse. Alternativt kan behovsanalyse gjennomføres i et ad hoc nedsatt utvalg/arbeidsgruppe for anledningen. Det er viktig å ha for øye at innføring av en tjeneste som Office 365 vil være altovergripende; det vil influere de fleste arbeidsprosessene i virksomheten, det vil berøre alle brukere og det vil sannsynligvis være et system som virksomheten vil/må benytte i mange år framover.

I forlengelsen av behovsanalysen må det utvikles kravspesifikasjon, som grunnlag for en anskaffelse. Detaljeringsgraden i kravspesifikasjonen avhenger av hvordan man ser for seg at anskaffelsen skal gjøres.

Har man Office fra før, er tilsluttet en godkjent rammeavtale og er klar på at det er tjenester fra denne leverandøren som skal kjøres videre, trenger ikke kravspesifikasjonen være veldig detaljert.

Skal man legge anskaffelsen ut på anbud må kravspesifikasjonen ha større detaljeringsgrad og tildelingskriterier må defineres og vektes, som beskrevet i «Lov om offentlige anskaffelser».

Det bør uansett skrives en anskaffelsesprotokoll der det går fram hvilke betraktninger som er gjort rundt anskaffelsen, og hvilke kriterier som er lagt til grunn for valget av system/tjeneste/leverandør.

En integrasjonsstrategi innebærer at men har en plan for hvordan de ulike modulene som du finner i Office 365 skal samhandle, i hvilken rekkefølge de skal innføres og i hvor stor grad de ulike modulene skal være prefererte (offisielle) tjenester i virksomheten.

Prefererte, offisielle tjenester krever integrasjonsløsninger mot andre IT-systemer som benyttes, spesielt i forhold til identitetshåndtering (autentisering og tilgangsstyring) og dataflyt mellom systemene. Slike integrasjonsløsninger blir gjerne betegnet som «mellomvareløsninger» og består av «connectorer» som flytter grunnlagsdata mellom tjenestene, hjelpesystem for organisering og presentasjon av data gjennom standard API-er, og støttesystem som i seg selv ikke er å betrakte som selvstendige tjenester, men som bidrar til at standardtjenestene blir mer brukervennlige og relevante.

Integrasjonsstrategien må inneholde en plan for hvordan slike mellomvareløsning skal utvikles, innføres og forvaltes.