IT-drift

Ein vanleg grunn til å kjøpe drift av system er at det er krav om at systemet skal vere oppe heile døgnet, sju dagar i veka, og at dei interne ressursane berre kan ta ansvar for drift innanfor vanleg kontortid. Ei anna grunn kan vere kapasitetsproblem, eller at systemet køyrer på ein plattform som interndrift ikkje har kompetanse på.

Viktige ting du må gjøre:

•  Gå igjennom eksisterende driftsavtale(r) og finn ut hvilke bestemmelser som gjelder rundt avslutning av avtalen/skifte av leveradør.
  • Finn ut hvor lang oppsigelsesfristen er.
  • Finn ut om det er mulig å forlenge avtalen dersom du ikke når i mål med å anskaffe ny leverandør innen fristen
  • Finn ut hva eksisterende driftsleverandør er forpliktet til å bistå med ved skifte av leverandør.
• Gjør en grundig analyse av eksisterende driftstjeneste:
  • Hva er dere fornøyd med, hva bør endres?
  • Ønsker dere å endre omfanget av avtalen, ta vekk systemer, legge til nye?
• Snakk med de som følger opp avtalen. Er det noe de ønsker å gjøre annerledes i oppfølging av ny avtale?
• Kartlegg markedet, ha møter med potensielle leverandører for å finne ut hva de kan tilby.
• Undersøk om nye måter å tilby tjenester på, som f.eks. skytjenester kan være aktuelle.

Viss det skal skaffast drift av eit system som vert drifta internt i dag, bør de ha eit godt grunnlag for å spesifisere driftstenesta. De bør likevel gjere ei grundig marknadsundersøking for å finne ut kva slags driftstenester som finst, kva slags krav som kan vere kostnadsdrivande osb. før de utarbeider konkurransegrunnlaget.

Viss de skal skaffe drift av eit system som er under utvikling, må driftsanskaffinga gå delvis parallelt med systemutviklingsprosjektet eller systemanskaffinga. Dette kan vere utfordrande. Tidlegare var det vanleg å kjøpe drift som ein del av systemutviklingsprosjektet med driftsleverandøren som underleverandør. Det er fleire grunnar til at dette ikkje er ei heldig løysing:

• Det er vanskeleg å få den beste driftsleverandøren: Når systemet skal utviklast, er det naturleg å legge mest vekt på den som tilbyr den beste systemløysinga. Men i løpet av systemets levetid vil driftskostnadene i dei aller fleste tilfella langt overskride utviklingskostnadane.
• Når systemet har kome i driftsfasen, har utviklingsleverandøren lite med løysinga å gjere. I og med at dei er kontraktspart, må kommunikasjonen med underleverandøren som leverer drifta likevel gå gjennom systemleverandøren, og det kan ofte skape problem.

Det å ha separate driftsleverandørar for ulike IT-system kan lett føre til at verksemda ender opp med ei mengd siloløysingar som det er vanskeleg å få til å kommunisere med kvarandre. Det kan også vere tidkrevjande å kommunisere med mange ulike driftsleverandørar. Vidare er det vanskeleg å få tatt ut synergiar og stordriftsfordelar når IT-driftsporteføljen vert så oppstykka.

Viss det skal skaffast driftsleverandør til eit system som er under utvikling, bør det først kartleggjast om det er mogleg å bruke ein eksisterande driftsavtale. Viss det ikkje er mogleg, kan det vere ein idé å undersøke om drifta kan kjøpast som ei ASP-løysing eller skyteneste. For at dette skal kunne vere ei god løysing, bør systemet vere et standardsystem. Viss ikkje vil det kunne føre til særs sterk leverandørbinding.

Avgjersla om å sette ut all IT-drift (outsource) er gjerne forankra i ein IT-strategi eller eit strategisk vedtak på leiarnivå.

Når du skal lage konkurransegrunnlaget er det viktig å gjere ei grundig kartlegging av alle systema i verksemda. Hugs system som lett fell mellom fleire stolar, t.d. testsystem og system som skal brukast til opplæring. Sjekk også om det er system der drifta allereie er sett ut (til dømes ASP- eller skyløysingar). Viss du vil halde fram med same driftsleverandør for desse, kan det hende du må gjere endringar i avtalen t.d. fordi det vert endringar i integrasjonar med system der drifta no vert sett ut.

Ein Service Level Agreement (SLA) eller tenestenivåavtale vert inngått i samband med drifts- eller vedlikehaldsavtalar eller andre jamlege tenestekjøpsavtalar som ASP- eller skyteneste-avtalar.

Tenestenivåavtalen beskriv og regulerer ytingsnivået på den jamlege tenesta. I Statens standardavtaler for høvesvis kjøp av driftstenester (SSA-D) og vedlikehaldstenester (SSA-V) inngår tenestenivåavtalen i vedlegg 5. 

Tenestenivåavtalar for ulike tenestekjøp har ulikt fokus. I samband med IT-drift er gjerne oppetid og responstid hovudfokus, medan det i samband med support eller vedlikehaldsavtalar er reaksjonstid, dvs. kor fort kunden får svar på ein førespurnad, som er det viktigaste.

Servicenivå eller ytingsnivå gjer greie for forventa eller garantert kvalitet for ei teneste, som anten kan vere standardisert på tvers av alle tenester, eller som kan vere nivåregulert.

Døme på tenester kan vere opningstider for brukarstøtte, kor raskt nye brukarar skal opprettast, kor rask respons brukaren skal ha, oppetider for IT-systemet i prosent, kor lang tid det skal ta ved rollback osv. Ofte er både kvalitet og kvantitet definert.

Tenesteavtalen baserer seg på den meir formelle kontrakten mellom oppdragsgivar og leverandør, men har ei meir uformell og listebasert form. Den er primært for brukarane av tenesta, og ikkje kontraktsforvaltaren.

Tenesteavtalen skal vere enkel å måle, og oftast leverer tenesteytar jamlege rapportar til kunden som viser i tal korleis tenesta har vorte levert. Rapporteringa er som regel grunnlaget for betaling. Til dømes kan nedetid eller dårleg responstid resultere i prisavslag.

Ved inngåing av ein tenesteavtale er det viktig å avklare forventningar hos tenesteytar og tenestemottakar.

Når vert tenesteavtalen oppretta?

For offentlege oppdragsgivarar vil ein starte med å lage ein tenesteavtale når konkurransegrunnlaget vert utarbeidd. Ved bruk av SSA-D (Driftsavtalen) vil tenesteavtalen ligge i vedlegg 5. Her skal ein sette opp krav til tenestene ein ønsker levert.

Tenesteavtalen må spegle reelle behov og kor kritisk kravet er, ikkje "kjekt å ha", sidan krava vil kunne vere særs kostnadsdrivande. Til dømes treng eit system som skal administrere medisinar på eit sjukehus 24 timars oppetid 7 dagar i veka. Det vil ikkje vere tilfelle for eit internt sak- og arkivsystem. Her er det viktig at brukarane av avtalen kjem tidleg inn og vert høyrde og tatt omsyn til.

Det er også viktig at krava vert sett opp på ein så konkret måte at det ikkje er rom for tolking. Det må beskrivast kva som skal leverast, korleis det skal målast og reknast ut og kva som er konsekvensen viss det ikkje vert levert.

Når dette er på plass gir tenesteavtalen eit effektivt og godt verktøy for kontraktsoppfølging.

Ulike typar tenesteavtalar

Ein tenesteavtale mellom ein kunde og ein ekstern leverandør vert kalla en SLA (Service Level Agreement) og ein tenesteavtale mellom interne vert kalla ein OLA (Operational Level Agreement). Ei serviceerklæring er ofte ei meir einsidig og enkel skildring av tenestene og tenestekvaliteten frå ein leverandør, og vert ikkje brukt så ofte i IT-samanheng.

Tenestekatalog

Tenesteavtalen er oftast basert på ein tenestekatalog.

Tenestekatalogen

• skildrar tenestene og tenestenivået (kvaliteten)
• bør vere skriven i eit enkelt, ikkje-teknisk språk slik at alle involverte kan forstå den
• må vere lett tilgjengeleg for brukarar, tenestetilbydar og for dei som følger opp avtalen
• skal vere lett å følge opp
• skal oppdaterast slik at den alltid inneheld gjeldande tenester
• skal ta vare på interessene til både kunde og leverandør
• gjer det enklare å følge opp og måle leveransane     

Tenesteavtale og ITIL

Tenesteavtale og ITIL (IT Infrastructure Library) er to omgrep som går hand i hand når det kjem til IT-tenester. ITIL er eit prosessorientert rammeverk for å levere gode IT-tenester til brukarar eller kundar. Her er tenesteavtalar eit sentralt element. Arbeidet med tenesteavtalar vert dekt av prosessområdet "Service Level Management" i ITIL-rammeverket.

ITIL vert vidareutvikla gjennom itSMF – IT Service Mangement Forum.

Aktuelle ressursar

Dataforeningen har etablert ei eiga faggruppe for Service Management med formål å dele kunnskap om styring av IT-tenester.

ITIL er eit strukturert rammeverk for IT Service Management. Rammeverket baserer seg på beste praksis frå privat og offentleg sektor, og er i dag den breiast aksepterte tilnærminga til styring og kontroll av IT-tenester.

ITIL V3 er organisert rundt eit livssyklusperspektiv og omfattar:

• Service strategy (tenestestrategi)
• Service design (tenestedesign)
• Service transition (tenesteinnføring)
• Service operation (driftsfase)
• Continual service improvement
     (kontinuerleg forbetring)

TILs offisielle nettside har informasjon på engelsk. Der finn du også ei engelsk-norsk ordliste over alle omgrepa i ITIL V3.

I Noreg vert arbeidet drive av itSMF (IT Service Management Forum). Dei arrangerer ein årleg konferanse og har oppdaterte nyheitsbrev.

ITIL-bakgrunn

ITIL-standarden (BS 15000) er eit registrert varemerke for det britiske Office of Government Commerce (OGC), og har sidan 1980-talet vore eit rammeverk for å finne dei beste løysingane innanfor IT-leiing. ITIL-standarden er utvikla gjennom eit dugnadsarbeid av ulike bransjeorganisasjonar og verksemder.

Med ITIL V3 gjekk ITIL frå å primært fokusere på prosessane rundt drift av tenester til å også omfatte den forretningsmessige sida av IT, dei organisatoriske funksjonane og styringsmodellar, samt verdien av IT.