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å gjere:

•  Gå gjennom eksisterande driftsavtale(r) og finn ut kva slags regulering som gjeld for avslutning av avtalen / skifte av leverandør.
  • Finn ut kor lang oppseingsfristen er.
  • Finn ut om det er mogleg å forlenge avtalen dersom du ikkje når i mål med å skaffe ny leverandør innan fristen.
  • Finn ut kva eksisterande driftsleverandør er forplikta til å hjelpa til med ved skifte av leverandør.
• Gjer ein grundig analyse av eksisterande driftsteneste:
  • Kva er de fornøgd med, kva bør endrast?
  • Ønskjer dere å endra omfanget av avtalen, ta vekk system, leggja til nye?
• Snakk med dei som følgjer opp avtalen. Er det noko dei ønsker å gjere annleis i oppfølginga av ny avtale?
• Kartlegg marknaden, ha møte med potensielle leverandørar for å finne ut kva dei kan tilby.
• Undersøk om nye måtar å tilby tenester på, som til dømes skytenester kan vere aktuelle.

Viss de skal skaffe 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 levetida til systemet 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 de skal skaffe driftsleverandør til eit system som er under utvikling, bør de først kartlegge om det er mogleg å bruke ein eksisterande driftsavtale. Viss det ikkje er mogleg, kan det vere ein idé å undersøke om kan kjøpe drifta 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, til dømes 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, til dømes 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 løpande tenestekjøpsavtalar som ASP- eller skyteneste-avtalar.

Tenestenivåavtalen beskriv og regulerer ytingsnivået på den løpande 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 ofte 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.

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.

Aktuelle ressursar

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

ITIL er eit strukturert rammeverk for IT-drift. 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 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)

ITIL-standarden er utvikla gjennom eit dugnadsarbeid av ulike bransjeorganisasjonar og verksemder. I Noreg vert ITIL vidareutvikla gjennom itSMF – IT Service Mangement Forum. Dei arrangerer ein årleg konferanse.