1. Standarder (ITIL-standarden)

Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Standarder (ITIL-standarden) Bjørn Klefstad 16.08.2013 Lærestoffet er utviklet for faget Systemforvaltning 1. Standarder (ITIL-standarden) Resymé:I denne leksjonen skal vi se nærmere på hvilke standarder vi må ta hensyn til når det gjelder datasikkerhet. Vi skal kort kommentere ISO 27001, ISO 27002 og ISO 9000. Deretter skal vi se nærmere på innholdet i deler av ITIL-standarden (BS 15000). Innhold 1. STANDARDER (ITIL-STANDARDEN)... 1 1.1. SIKKERHETSRELATERTE STANDARDER... 2 1.2. ISO 27001 OG ISO 27002... 2 1.3. ISO 9000... 3 1.4. ITIL (V2)... 3 1.4.1. ITIL-prosessene... 4 1.4.2. Sammenhengen mellom prosessene... 7 1.4.3. Hvordan skal vi ta ITIL i bruk?... 9 1.5. KUNDERELASJONER OG TJENESTENIVÅAVTALER (SLA-AVTALE)... 10 1.5.1. Prosessen Tjenestenivåavtaler... 10 1.5.2. Hovedelementene i en SLA-avtale... 13 1.5.3. Ulike avtaletyper i forbindelse med Tjenestenivåavtaler... 15 1.6. TILGJENGELIGHETSSTYRING... 16 1.6.1. Fordeler med Tilgjengelighetsstyring... 16 1.6.2. Måling av tilgjengelighet... 17 1.7. HENDELSESSTYRING... 18 1.8. ENDRINGSSTYRING... 20 1.8.1. Melde endring... 21 1.8.2. Behandling av endringsforslag... 22 1.8.3. Planlegging og gjennomføring av endring... 22 1.9. ITIL I FREMTIDEN... 23 1.10. LENKER... 24 1.11. TILHØRENDE KAPITLER I LÆREBOKA... 24

Standarder (ITIL-standarden) side 2 av 24 1.1. Sikkerhetsrelaterte standarder Standarder for informasjonssikkerhet og for drift av IT har etter hvert blitt mer og mer aktuelle. Vi skal kort kommentere tre av dem (ISO27001, ISO 27002 og ISO 9000) og se litt nærmere på deler av ITIL-standarden (BS 15000). I dette emnet trekker vi frem ITIL som spesielt viktig da det i løpet av de siste årene har det blitt brukt mye penger blant norske bedrifter for å skolere sine ansatte og innarbeide driftsrutiner i henhold til ITIL-standarden. Dette for å endre driftssituasjonen for IT-systemer fra å drive med brannslukking til en systematisk og strukturert måte å arbeide på. De fleste typer standarder er i stadig utvikling. Her kan vi nevne ISO 27002 som kom i ny versjon i 2005. Denne standarden utvikles i henhold til ISO sine rutiner som er omfattende og tidkrevende. ITIL-standarden derimot er utviklet gjennom et enorm dugnadsarbeid av bransjeorganisasjoner og har en raskere utviklingstakt enn ISO. Dette betyr at vi må følge med når det kommer nye utgaver av de ulike standardene. Nye versjoner avviker som regel en del fra eldre versjoner. Dette henger sammen med den stadige utviklingen i IT-bransjen som gir nye behov. 1.2. ISO 27001 og ISO 27002 Begge disse standardene tar for seg informasjonssikkerhet, men har litt ulikt fokus. ISO 27002 fokuserer på en rekke ulike tiltak som skal bedre informasjonssikkerheten. Dette er en standard som gir anbefalinger for administrasjon av sikkerhet, sett i forhold til all informasjon. Den er et sentralt hjelpemiddel i utformingen av bedriftenes egne sikkerhetsrutiner, og vil være viktig blant annet i et leverandør-kundeforhold. I stadig større grad står organisasjoner og deres informasjonssystemer overfor en rekke sikkerhetstrusler. Standarden gir anbefalinger for administrasjon av informasjonssikkerhet til bruk for dem som er ansvarlige for å opprette, iverksette eller opprettholde sikkerhetsarbeidet i organisasjonen. Den har til hensikt å fremskaffe et felles grunnlag for å utvikle organisasjonens egen sikkerhetsstandard og effektiv sikkerhetspraksis innad i organisasjonen og for å skape tillit mellom samarbeidende organisasjoner. Ved å velge anbefalinger fra standarden sikrer en at bedriftens sikkerhetsrutiner er i overensstemmelse med gjeldende lover og forskrifter. Aktuelle emner for ISO 27002 er: o Etablering av sikkerhetspolicy o Hvor viktig det er å involvere ledelsen og plassere ansvaret i tilknytning til ulike roller o Fysisk sikring o Tilgangkontroll o Drift og vedlikehold. Læreboken vi benytter i dette kurset baserer seg på ISO 27002. Vi regner derfor innholdet i denne standarden som bra dekket og vil ikke her omtale denne standarden ytterligere i denne leksjonen. ISO 27001 fokuserer på selve styringssystemet for informasjonssikkerheten Information Security Management System. Standarden går igjenom hele prosessen med hvordan et slikt

Standarder (ITIL-standarden) side 3 av 24 ISMS skal etableres, forvaltes, overvåkes, vedlikeholdes og dokumenteres. Mål og tiltak i forbindelse med å etablere et slikt system refererer direkte til deler av innholdet i ISO 27002. Et annet hovedmoment i denne standarden er Demingsirkelen for kontinuerlig forbedring, som inneholder prosessene planlegge, utføre, følge opp og iverksette. At prosessene er plassert i en sirkel viser at dette er en prosess som pågår hele tiden uten noen gang å ta slutt. Dersom du er interessert i å vite mer om standarden ISO 27001 og ISO 27002 så kan jeg anbefale kurset LN 471D Informasjonssikkerhetsstyring. Dette kurset tar utgangspunkt i disse to standardene og går grundig igjennom innholdet for å få på plass et ISMS for en bedrift. 1.3. ISO 9000 Dette er en serie standarder for kvalitetssikring og kvalitetssystemer. Kravene til kvalitet går ofte hånd i hånd med kravet til sikkerhet. Standardene setter opp en rekke krav til hva en bedrifts kvalitetssystem bør omfatte uten å gi et fasitsvar på hvordan en bedrift skal bedre kvaliteten på sine produkter. Hvordan disse kravene imøtekommes er det opp til den enkelte bedrift å få på plass. ISO 9000-3 er den standarden som gjelder for IKT. Standarden inneholder retningslinjer for hvordan ISO 9000-1 anvendes på utvikling, leveranse og vedlikehold av programvare. Vi legger liten vekt på denne standarden i dette kurset, da innholdet er meget godt dekket i kurset SO330D Kvalitet i programvaresystemer. For de som er interessert i ISO 9000 kan vi anbefale dette kurset. 1.4. ITIL (V2) Per i dag er det hovedfokus på ITIL V3 i de aller fleste bedrifter rundt omkring. Dette er en meget stor og omfattende standard og den dekker altfor mye til at det er mulig å trekke den inn i dette kurset. Vi skal derfor ta utgangspunkt i ITIL V2 som uansett er den mest naturlige tilnærmingen til ITIL, dersom man ikke har jobbet med dette fra før. Alle de prinsippene vi berører i ITIL V2 har stor overføringsverdi og vil i hovedsak også gjelde for ITIL V3. En IT-organisasjon som skal ha ansvar for drift og forvaltning av kundenes IT-systemer ønsker selvfølgelig å yte best mulig service. Dette gjelder like mye for en intern IT-avdeling i en bedrift som for et firma som selger denne typen tjenester til andre bedrifter (outsourcing). I begge tilfeller må kundene kunne stole på at systemene er tilgjengelige når de trenger dem. De må være trygge på at systemene ikke kan misbrukes, at det ikke oppstår unødige feil og at feil alltid kan oppdages og får kontrollert behandling. De må videre vite og akseptere kostnadene for disse tjenestene. Og kanskje det aller viktigste de må alltid vite hvor de skal henvende seg for å få støtte og hjelp. Og det er nettopp for å løse denne type oppgaver at ITIL (Information Technology Infrastructure Library) kommer inn i bildet. En IT-organisasjon som skal levere slike tjenester vil ha stor nytte av å bruke andres erfaringer som grunnlag for sine egne arbeidsmåter. Vi bruker ofte begrepet beste praksis. Beste praksis kan defineres som en fremgangsmåte som er anerkjent i industrien og som har vist at den gir gode resultater når den følges. Når det gjelder beste praksis for tjenesteleveranse og kundestøtte, tar vi utgangspunkt i et rammeverk som går under betegnelsen ITIL. I ITIL finner vi retningslinjer for et sett av samvirkende prosesser som dekker alle nødvendige oppgaver innenfor tjenesteleveranse og kundestøtte. Retningslinjene i

Standarder (ITIL-standarden) side 4 av 24 ITIL regnes som beste praksis innen området, fordi de er basert på hvordan de beste innen bransjen gjør det. ITIL omhandler det vi på norsk kan kalle IT-tjenestestyring. Det blir derfor naturlig å trekke frem hvordan tjenestebegrepet defineres i ITIL litteraturen allerede i denne innledningen: En tjeneste defineres som et middel som er til hjelp for å levere verdi til kundene. Kundene skal på en enkel måte få tilgang til denne verdien uten at de har eierskap til spesifikke kostnader eller risikoelementer som er forbundet med å produsere tjenestene. Kunden skal altså kjøpe selve resultatet av tjenesteproduksjonen og så er det leverandøren som påtar seg ansvaret med å levere dette. ITIL dreier seg også i stor grad om å beskrive funksjoner og prosesser. Dette betyr at vi trenger å definere disse begrepene: Funksjoner er enheter i en organisasjon som har som oppgave å utføre et bestemt arbeid, og de er ansvarlige for å oppnå et bestemt resultat. De inneholder selv de ressursene de trenger for å utføre sin funksjon og de representerer på mange måter en struktur og en stabilitet i organisasjonen. Prosessene kan bidra til å bedre dette forholdet, ved at de definerer koordinerende aktiviteter og kontroll på tvers av funksjonene. Prosessene definerer aksjoner, avhengigheter og sekvenser i en arbeidsflyt. De er designet for å oppnå et bestemt resultat og de er målbare i forhold til dette. Prosessene skal levere et resultat til kunden som kan være intern eller ekstern. I denne leksjonen ser vi kort på den historiske utviklingen til ITIL. Vi berører hva ITIL er, hvorfor vi bør innføre ITIL og hvordan dette kan gjøres. Videre kommer vi inn på tjenestelivssyklusen som innføres med ITIL versjon 3, 1.4.1. ITIL-prosessene ITIL er altså et sett av integrerte funksjoner og prosesser sammen med en beskrivelse av beste praksis for hver prosess. Disse prosessene er fleksible og skalerbare og hevdes å kunne tilpasses de fleste (alle?) IT-organisasjoner. De kan også innføres gradvis i organisasjonen og det er ikke nødvendig å ta i bruk alle. Selv om det er stor enighet om hva som er beste praksis, er det imidlertid et faktum at ITIL beskriver en relativt stor organisasjon rundt dette og at mindre organisasjoner kan ha visse problemer med å ivareta tilsvarende praksis i et mindre formelt system. ITIL vil allikevel kunne være svært nyttig som et utgangspunkt. Hva ønsker vi å oppnå med å ta i bruk ITIL og hvordan ser de ulike aktørene i forbindelse med leveranse av IT-tjenester på dette. o Kunden vil oppleve at leverandøren forstår hvilke forventninger han har. Videre at kunden blir informert om oppnådd servicenivå og spesielle hendelser eller avvik som måtte oppstå underveis o Brukeren vet alltid hvor han skal henvende seg. Videre at ulike saker løses, følges opp og at brukerne får tilbakemeldinger underveis på hvor saken står o Driftsmiljøet kjenner belastningskravene for tilgjengelighet og ytelse slik at de kan sikre at infrastrukturen er riktig dimensjonert. Dette vil igjen medføre at antall driftsavbrudd blir minimalisert

Standarder (ITIL-standarden) side 5 av 24 o Ansatte vet og har dermed kontroll på sine arbeidsoppgaver, ansvarsområder og myndighet. Videre at det er en fornuftig balanse mellom pålagte rutiner og faglig frihet ITIL prosessene deles i to hovedgrupper (versjon 2) tjenesteleveranse og tjenestestøtte. Målet med standarden er å arbeide systematisk med å forbedre kvaliteten på IT-systemene. Operasjonelle prosesser IT Customer Relationship Management Change Management Configuration Management Release Management Problem Management Incident Management Service Level Management Taktiske prosesser Capacity Management Financial Management IT Service Continuity Management Service Desk Availability Management Security Management Tjenesteleveranse (Service Delivery). Man har taktiske prosesser som fokuserer på tjenesteleveranse. Disse prosessene fokuserer på planlegging og tilrettelegging av tjenestetilbudet og man har stort fokus på forbedringer. Innenfor dette området har vi prosessene: - Tjenestenivåavtaler (Service Level Management). Hensikten med denne prosessen er å sikre at det inngås skriftlige avtaler mellom IT-organisasjonen og kundene, med fokus på dem som skal bruke systemet (SLA-avtaler). Denne prosessen har en meget sentral funksjon i forhold til de andre, siden SLA-avtalene danner grunnlaget for hva vi gjør i de andre prosessene. I tillegg skal prosessen sikre at kvaliteten på tjenestene vedlikeholdes og gradvis forbedres. - Økonomistyring (Financial Management). Hensikten med denne prosessen er å sikre økonomien i tjenestetilbudet gjennom kostnadseffektiv forvaltning av IT-ressursene og styring av kostnader mot fortjeneste. - Kapasitetsstyring (Capacity Management). Hensikten med denne prosessen er å skaffe oversikt over dagens og fremtidens kapasitetskrav, og ut fra det kunne planlegge det fremtidige tilbudet. Det er i denne sammenheng viktig å kunne forstå de potensielle fordelene ved ny teknologi, for å kunne utnytte den som en del av tjenestetilbudet. - Beredskapsplanlegging (Continuity Management). Hensikten med denne prosessen er å planlegge tjenestetilbudet slik at kontinuiteten best mulig kan opprettholdes etter en hendelse. Det omfatter en ballanse mellom tiltak for å redusere risiko sammen med effektive mekanismer for å gjenopprette tilbudet etter en hendelse.

Standarder (ITIL-standarden) side 6 av 24 - Tilgjengelighetsstyring (Availability Management). Hensikten med denne prosessen er å analysere kundenes krav til tilgjengelighet av ulike tjenester og deretter designe, implementere, måle og styre tjenestetilbudet for å møte disse kravene. Av disse prosessene har vi i denne leksjonen valgt å se nærmere på Tjenestenivåavtaler og Tilgjengelighetsstyring. Prosessen Beredskapsplanlegging blir nærmere omtalt i en egen leksjon senere i dette kurset. Tjenestestøtte (Service Support). Man har operasjonelle prosesser der vi gjennomfører de daglige arbeidsoppgavene som er nødvendig for å levere de avtalte tjenestene med tilstrekkelig kvalitet. Hva vi legger i tilstrekkelig kvalitet og hvordan dette skal måles finner vi beskrevet i SLA-avtalene. Her finner vi prosessene: - Servicesenter (Service Desk). Kalles også kundesenter, help desk, brukerstøtte, servicetorg etc. Kjært barn har mange navn. Dette er egentlig ikke en prosess men en funksjon. Og en meget sentral funksjon som er avgjørende for å få tjenestetilbudet, og dermed de andre prosessene vi omtaler til å fungere. Hovedhensikten med denne funksjonen er at kundene skal kunne henvende seg ett sted for å få hjelp, og at ansvaret for å følge opp kundehenvendelsene er plassert ett sted. - Hendelsesstyring (Incident Management). Hensikten med denne prosessen er å etablere normal drift så raskt som mulig etter at en uønsket hendelse har funnet sted. Normal drift defineres som det service-nivået som er beskrevet i SLA-avtalen, se mer om denne senere. Hovedfokus i prosessen er behandling av rapporterte hendelser. Prosessen omfatter identifisering og logging, klassifisering og iverksetting av strakstiltak, undersøkelse og diagnose, iverksettelse av tiltak for å løse problemet så raskt som mulig, oppfølging av saken og informasjon til kunden. Dersom hendelsen er for stor til å løses her blir det sent videre til problemløsning. - Problemstyring (Problem Management). Hensikten med denne prosessen er å minimalisere uheldige effekter på tjenestetilbudet grunnet hendelser og problemer forårsaket av feil i infrastrukturen. Dette skjer ved at prosessen sikter mot å omsette ukjente feil til kjente feil og etablere straksløsninger. Deretter går problemet inn i styrt behandling i prosessen Endringsstyring. - Konfigurasjonsstyring (Configuration Management). Hensikten med denne prosessen er å holde oversikt over komponentene i ulike IT-systemene, sammenhengene mellom dem og hvilken versjon av hvilke komponenter som hører hjemme i en gitt versjon av systemet. Begrepet konfigurasjonsstyring kan i andre sammenhenger også dekke endringsstyring og idriftssetting, men vi holder oss her til ITIL-rammeverket. - Endringsstyring (Change Management). Hensikten med denne prosessen er å sikre at alle endringer blir gjennomførte på en kontrollert og styrt måte, slik at endringene ikke medfører dårligere kvalitet i tjenestetilbudet. - Versjonsstyring (Release Management). Idriftssetting i ITIL terminologien betyr kontrollert utrulling av nye versjoner av applikasjoner og maskinvare. Av disse prosessene har vi i denne leksjonen valgt å se nærmere på Hendelsesstyring og Endringsstyring. Prosessen Servicesenter blir nærmere omtalt i en senere leksjon om Servicesenter og brukerstøtte.

Standarder (ITIL-standarden) side 7 av 24 1.4.2. Sammenhengen mellom prosessene For å fokusere mer på hvilken informasjon som utveksles mellom de ulike prosessene har vi satt opp en figur som viser informasjonsflyten. Her kjenner dere igjen de ulike ITILprosessene og så har vi satt på nummerering på pilene mellom dem. Under finner dere en nummerert oversikt over hvilken informasjon som utveksles for hver av de ulike pilene.

Standarder (ITIL-standarden) side 8 av 24 1. Klager, spørsmål, merknader, forespørsler 2. Løsning på hendelser, status på hendelser 3. Hendelser (gruppert) 4. Endringsforespørsler, serviceforbedringer 5. Rekkefølge på endringer, godkjente endringer 6. Konfigurasjonsinformasjon om alle enheter, statusinformasjon om endringer 7. Konfigurasjonsinformasjon om alle godkjente programmer, maskinvare og relaterte produkter 8. Konfigurasjonsinformasjon til de som skal analysere problemet 9. Konfigurasjonsinformasjon til de som skal analysere hendelsene 10. Endringer i konfigurasjonsinformasjonen 11. Den opprinnelige konfigurasjonsinformasjonen, konfigurasjonsinformasjonsdatabasens editering og revideringsinformasjon 12. Programvare og maskinvareinformasjon, programvare og maskinvare 13. Operative data og rapporter om ulike taktiske prosesser 14. Krav og forespørsler fra kunden 15. Et tjenestenivåforslag, tjenstekatalogen, SLA-avtaler, rapporter om oppnådd tjenestenivå 16. Krav til tjenestenivå på bakgrunn av sannsynlighetsanalyser, SLA-avtaler 17. Informasjon om tjenestekatalogen, tjenestenivå rapporter 18. Relevante finansdata 19. Informasjon om kostander, betalinger, budsjettforslag 20. Penger 21. Prisinformasjon, fakturaer 22. Kundedata, fremtidige krav og forespørsler fra kunden 23. Kundedata, forslag til tilpassninger 24. Informasjon om tilgjengelighet basert på overvåkning og innstillinger 25. Kapasitetskrav i forbindelse med back up steder og enheter 26. Informasjon om bedriftskritiske prosesser/tjenester 27. Vedlikeholdskontrakter 28. Back up kontrakter 29. Informasjon om sikkerhet og sikkerhetspolicy 30. Informasjon om sikkerhet, rapporter om sikkerhetshendelser, problemer og endringer Siden dette totalt sett blir relativt komplekst er det viktig å bruke en del tid på denne figuren.

Standarder (ITIL-standarden) side 9 av 24 Vi kan også se på dette fra en litt annen synsvinkel. Vi kan prøve å se for oss hvordan en bestemt hendelse brer seg mellom de ulike prosessene og til slutt blir løst. ITIL gir et eksempel dette og vi kan se for oss at den får følgende behandling: 1. En bruker kontakter Servicesenteret for å melde problemer med responstiden på et av systemene. 2. Prosessen hendelsesstyring benyttes for å registrere og vurdere hendelsen initielt. 3. Prosessen problemstyring benyttes for å finne årsaken og i den forbindelse involveres prosessen kapasitetsstyring. Prosessen servicavtaler registrerer at SLA-avtalen er brutt. 4. Prosessen endringsstyring registrerer et forslag om å øke kapasiteten og behandler det som et endringsforslag. 5. Prosessen økonomistyring av IT-tjenester vurderer økonomien i å oppgradere maskinvaren for å øke kapasiteten. 6. Prosessen endringsstyring involverer prosessen beredskapsplanlegging for å sikre at endringen kan gjennomføres uten stopp i tjenestetilbudet. 7. Prosessen versjonsstyring kontrollerer at endringen har tilstrekkelig kvalitet til å kunne settes i drift og planlegger utrulling av nye versjoner av maskinvare og programvare. Prosessen konfigurasjonsstyring varsles om de nye versjonene og konfigurasjonene. 8. Prosessen tilgjengelighetsstyring gjør en siste sjekk på at den nye kapasiteten er tilstrekkelig til å møte kravene i SLA-avtale. 9. Prosessen konfigurasjonsstyring sikrer at versjons- og konfigurasjonsinformasjonen om systemet er oppdatert. 10. Gjennom hele behandlingen har Servicesenteret ansvaret for hendelsen og for å gi informasjon til kunden. Som dere ser har vi nå vært innom mange av prosessene for å løse opp i en hendelse. Hele organisasjonen arbeider sammen for å løse ulike problemer og de som deltar i arbeidet har ulike roller/arbeidsoppgaver. 1.4.3. Hvordan skal vi ta ITIL i bruk? Hvordan skal vi så kunne bruke beste praksis innenfor alle disse prosessene. Kan dette puttes direkte inn i vår organisasjon? Svaret på det er nei. Måten dette skal brukes på er at vi skal ta utgangspunkt i en prosess for vår bedrift. Hvordan har vi i utgangspunktet løst de aktuelle arbeidsoppgavene. Etter at vi har kartlagt dette skal vi se nærmere på tilsvarende prosess i ITIL og se på hvilke muligheter dette gir. Deretter skal vi utforme en ny prosess for vår bedrift med bakgrunn i en kombinasjon av dagens rutiner og beste praksis. For å bli god på dette kreves det praktisk trening i en konkret bedrift. Merk at bedrifter med ulike behov bør ende opp med ulike prosesser. ITIL bør også innføres gradvis og over tid. Vi bør implementere deler av standarden og innarbeide dette i vår bedrift før vi utvider med stadig flere prosesser. Hvor mye som skal implementeres avhenger av den enkelte bedrift. Jo større en bedrift er jo mer formaliserte prosesser trenger vi. Det samme gjelder dersom det bedriften produserer er av spesiell interesse for andre (eks. høyteknologi). Merk at enkle problemstillinger krever enkle løsninger. Blir det hele for komplekst vil det nærmest gå i oppløsning, da de ansatte vil arbeide rundt det system vi prøver å innføre.

Standarder (ITIL-standarden) side 10 av 24 1.5. Kunderelasjoner og Tjenestenivåavtaler (SLA-avtale) Utviklingen har de siste årene gått i retning av at bedriftene blir mer og mer avhengige av IT. Tidligere dreide IT seg først og fremst om valg av teknologi og infrastruktur, mens det i dag er hovedfokus på å kunne levere IT-tjenester med kvalitet og tilgjengelighet, definert ut fra forretningens behov. Man ser på IT som en tjenesteleveranse til resten av forretningen. Det er her prosessen Tjenestenivåavtaler, kommer inn i bildet. 1.5.1. Prosessen Tjenestenivåavtaler Tjenestenivåavtaler er den prosessen som skal håndtere og forbedre graden av service mellom to eller flere parter. Dette gjøres gjennom at det lages skriftlige avtaler (SLA-avtale) mellom partene, som definerer kvantitet og kvalitet på de ulike tjenestene. I slike avtaler brukes det objektive kriterier for å beskrive tjenestekvaliteten. Disse skal være målbare slik at det er lett å etterprøve hvorvidt avtalen er overholdt eller ikke. ITIL har definert en bestemt Tjenestenivåavtaleprosess som må planlegges, implementeres, utføres og kontrolleres. Figuren under viser en oversikt over denne prosessen (ITIL 2000). Figur 1-1 Tjenestenivåavtaleprosessen Vi skal se nærmere på planleggings- og implementasjonsdelen av prosessen. Planlegging av prosessen Hvis man starter på bar bakke er det en rekke aktiviteter som må gjennomføres, før man kan gå i gang med implementeringen av Tjenestenivåavtaler. Under har vi satt opp en liste over hva som må gjøres (ITIL 2000):

Standarder (ITIL-standarden) side 11 av 24 - Utnevne en gruppe personer som skal jobbe med dette - Produsere et idègrunnlag for hva som skal skje - Definere mål og rammer for prosessen - Informere resten av organisasjonen og fortelle hvordan dette vil påvirke deres arbeidshverdag - Definere roller, arbeidsoppgaver og ansvarsforhold - Tallfeste aktiviteter, ressurser, finansiering, kvalitetskriterier - Identifisere ulike risikoer - Planlegge en Tjenestekatalog og en SLA-struktur - Skissere et eksempeldokument på en SLA-avtale - Identifisere støtteverktøy (spesielt for overvåkning SLA-avtale) - Sette opp og bli enige om prioritetsnivå for planlagte hendelser og skaleringsnivå sammen med kunder, interne og eksterne leverandører Videre er det en klar suksessfaktor at kapasiteten til å overvåke SLA-avtalene må være stor nok. Alle de punkter som er med i en SLA-avtale må vi være i stand til overvåke og måle ut ifra objektive kriterier. De konkrete kriteriene bør fastsettes sammen med kunden i implementasjonsfasen. Vi trenger derfor en plan for hvordan vi skal sørge for god nok kapasitet. For å ha et sammenligningsgrunnlag for å se effekten av det arbeidet som blir gjort, trenger vi å samle inn data om dagens situasjon før vi setter i gang Tjenestenivåavtaleprosessen. Her må det planlegges hvilke data vi skal samle inn og i hvilket omfang. Den siste fasen i forberedelsene, er en plan for hvordan vi skal revidere eller inngå nye kontrakter med eksterne og interne tjenesteleverandører. Dette vil komme som en naturlig følge av SLA-avtalene når disse blir inngått. Målene beskrevet i SLA-avtalene vil få direkte følger for våre avtaler med både eksterne og interne leverandører. Implementering av prosessen I implementasjonsfasen av Tjenestenivåavtaleprosessen må vi gjennomføre følgende aktiviteter: Man må produsere en Tjenestekatalog. Denne katalogen inneholder for hver tjeneste informasjon om navn, en beskrivelse av tjenesten, en beskrivelse av tjenestenivå, hva som inngår, hva som ikke inngår og kostnader. Alle tjenester som en leverandør ønsker å tilby skal defineres i Tjenestekatalogen. Når kundene skal bestemme hvilke tjenester de ønsker å kjøpe, gjør de oppslag i tjenestekatalogen. På denne måten får de et felles grensesnitt å forholde seg til for de ulike tjenestene, og kan velge ut ifra objektive målbare kriterier. Holde styr på forventningene. Det er viktig å informere alle parter om hvordan denne prosessen foregår og hvilke effekter de kan forvente å se når Tjenestenivåavtaler tas i bruk. Vi må altså styre forventningene til prosessen, slik at de ikke tar overhånd hos enkelte parter og blir urealistiske. En slik prosess

Standarder (ITIL-standarden) side 12 av 24 tar tid og vi vil se effekten gradvis ettersom ting går seg til. Det er viktig å huske at dette vil påvirke arbeidsplassen til svært mange, og mennesker trenger tid til å omstille seg. Planlegge SLA-strukturen Med utgangspunkt i Tjenestekatalogen må vi sette opp en struktur på SLA-avtalene, slik at disse dekker tjenestene og kundene på best mulig måte. Denne strukturen kan bygges opp på flere ulike måter: - Tjenestebasert En SLA-avtale for en bestemt tjeneste for alle kunder - Kundebasert En SLA-avtale for en bestemt kunde som dekker alle tjenester - Flerlagsmodell For eksempel en tre-lagsmodell med bedriftsnivå, kundenivå og tjenestenivå (reduserer unødvendig duplisering og hyppig oppdatering av avtalene) Etablere krav til tjenestenivå og utkast til SLA-avtale Her setter vi opp et forslag enten til tjenestenivå eller SLA-avtaler og arbeider videre på dette sammen med kunden. Dette foregår som regel som en iterativ prosess der det ikke spiller noen rolle om vi setter opp det ene eller det andre først. Her er det viktig at kunden spiller en sentral rolle og klarer å få frem, så konkret som mulig, hvilke krav de stiller. Ordbruken i en SLA-avtale Ulike tolkninger av innholdet i en SLA-avtale vil bare føre til misforståelser og uenighet. Vi må derfor bruke et klart og konsist språk slik at det ikke er rom for ulike tolkninger og misforståelser. Dette er ingen triviell oppgave. Søk enighet For å bli enige om den endelige ordlyden i SLA-avtalen kreves det forhandlinger mellom leverandøren og kunden. Tjenester, tjenestenivå og kostnader står sentralt her. Leverandøren må også sjekke i forhold til sine underleverandører at de krav som kunden stiller kan oppfylles. Etablere overvåkningskapasitet Alt som inkluderes i en SLA-avtale skal overvåkes og måles på en skikkelig måte. Vi må derfor etablere tilstrekkelig kapasitet til at dette blir gjort grundig nok, og slik det er enighet om. Dersom dette ikke er mulig bør SLA-avtalen endres. I forbindelse med overvåkning er det mange fallgruver, slik at her må vi arbeide systematisk og nøyaktig. Mange ulike parametre kan være vanskelig å overvåke. Revurdere kontrakter med eksterne og interne underleverandører De aller fleste tjenesteleverandørene er avhengig av både interne og eksterne underleverandører av tjenester. Avhengig av hvilke SLA-avtaler som inngås, må også avtalene med underleverandørene oppdateres, slik at de stemmer overens med det som er avtalt i SLA-avtalene. Definere rapporterings- og oppdateringsprosedyrer Rapporteringsmekanismer, intervaller og rapportformater i SLA-avtalen må defineres sammen med kunden. Frekvens og format på tjenesterevideringsmøter må også avtales med kunden. Det anbefales at det brukes faste møtetidspunkter, som settes opp i en tidlig fase. Selve SLA-avtalene må også revideres med jevne mellomrom Bekjentgjøre eksistensen og innholdet i de ulike SLA-avtalene

Standarder (ITIL-standarden) side 13 av 24 Det er viktig å bekjentgjøre SLA-avtalene internt i organisasjonen. Alle støttegrupper og teknisk personale, bør utstyres med en oppsummering av nøkkelmålene i avtalene, slik at de hele tiden kan måle sine tjenester opp imot disse. Det blir mye enklere å gjøre en god nok jobb når man vet hvor listen ligger. Tilsvarende gjelder også for kundegruppen. De kan også eventuelt utstyres med nøkkelmålene i avtalene, slik at de vet hva de kan forvente av de tjenestene som avtalen omfatter. Under følger en liste som viser hvilke fordeler tjenesteleverandøren kan forvente å få med å ta i bruk prosessen Tjenestenivåavtaler (ITIL 2000): - Bedre tjenestekvalitet og færre avbrytelser som gir økonomiske innsparinger - IT-tjenestene er kalibrert etter kravene til tjenestenivå - Et bedre samspill med fornøyde kunder - Alle parter som omfattes av en avtale, har et bedre bilde av de ulike partenes rolle og ansvar - IT-innsatsen fokuseres rundt nøkkelområder - Fornøyde kunder som vet hva de får og som har samme oppfatning som leverandøren når det gjelder hvordan kvaliteten skal måles - Overvåkning av tjenestene avslører svake ledd eller områder der effektiviteten bør økes - Redusert tidsforbruk da leverandøren kan bruke samme rammeverk på alle avtaler, kan gjenbruke avtaler, får synkronisert alle personene som jobber med slike avtaler - En samlet oversikt over alle avtaler - En samlet oversikt over alle tjenestene som leverandøren kan tilby i en Tjenestekatalog 1.5.2. Hovedelementene i en SLA-avtale SLA-avtale er en forkortelse for Service Level Agreement og kan oversettes til Tjenestenivåavtale. En SLA-avtale er en kontrakt mellom leverandør og kunde, som definerer hvilke tjenester som skal leveres og hvilket nivå disse tjenestene skal overholde. En SLA-avtale kan benyttes i enhver tjenesteleveranse, der man kan definere objektive mål for kvantitet og kvalitet på tjenesten. I denne sammenhengen fokuserer vi på leveranse av ITtjenester Definisjonen av en SLA-avtale En SLA-avtale innebærer følgende hovedelementer: - Tjeneste (service): En tjeneste som leveres fra leverandør til kunde. Tjenesten er veldefinert og alle parter i avtalen oppfatter tjenesten på samme måte. - Nivå (level): Sier noe om hvilke kvantitative og kvalitative krav som stilles til leveranse av tjenesten. Kunde og leverandør finner sammen et passende tjenestenivå for de komponenter som inngår. - Avtale (agreement): Et gjensidig balansert forhold, som inngås til fordel for to eller flere parter. Partene blir enige om innhold, oppfølging og konsekvenser av avtalen. Ofte inneholder avtalen økonomiske betingelser i tilknytning til tjenesteleveransen. Det som avtales i en SLA-avtale, skal kunne måles og dokumenteres tydelig. Etablering av SLA-avtale er en prosess, som skal sikre at kunde og leverandør har en felles forståelse for

Standarder (ITIL-standarden) side 14 av 24 hva som skal leveres, og til hvilken kvalitet. SLA-avtale avklarer ansvarsforholdet mellom partene, og prosessen bidrar til å skape tillit. SLA-avtale er et arbeidsverktøy som kan sikre en god relasjon mellom partene. SLA-avtale fokuserer sterkt på konkretisering av leveransene hva, hvordan, hvem og når, der også en rekke øvrige forhold relatert til leveransene spesifiseres konkret, f.eks. oppfølging, rapportering, konsekvenser ved manglende oppfyllelse og felles forpliktelser. En SLA-avtale innholder som regel følgende fellespunkter (ITIL 2000) - Introduksjon hvem avtalen gjelder signaturer osv. - Tjenestetider når skal tjenestene være tilgjenglig - Tilgjengelighet oppetid som regel i % - Pålitelighet angis som tid mellom hvert avbrudd - Støttetjenester når er disse tilgjengelige - Trafikkvolum antall brukere, antall overføringer osv. - Responstider responstid fra arbeidsstasjoner - Endringer rutiner for å håndtere endringer - Kontinuitet og sikkerhet beredskapsplaner / tiltak - Kostnader hvordan kostnadene beregnes - Rapportering og revidering innhold og hvor ofte det skal gjennomføres - Konsekvenser av mislighold dagbøter osv ved for lange avbrudd Implementering av en SLA-avtale Et prosjekt for implementering av SLA-avtale i en organisasjon er alltid av et betydelig omfang, og vil gripe inn i arbeidsdagen til mange. Et slikt prosjekt er tidkrevende da det må igjennom en modningsprosess. Prosjektet vil kunne deles inn i følgende faser (Frydenberg 2002): o Oppstartsfasen som skal legge grunnlaget for et effektivt prosjekt. Planlegging og opplæring er sentrale oppgaver. Det er viktig at man i denne fasen skaper entusiasme i organisasjonen, og sikrer at SLA-avtale blir sett på som et skritt videre og en mulighet, ikke som en trussel. o Tjenestedefinisjonsfasen går ut på å kartlegge og definere de tjenester som leveres i dag, og fastlegge hvem som er kundene for den enkelte tjeneste. Her må man trekke med flere, både hos leverandøren og hos kunden. Tjenestedefinisjonene kan bli gjenstand for revisjon senere i prosjektet, men er et viktig utgangspunkt. o Fasen for kvantifisering av tjenester. For et utvalgt sett av tjenester (sjelden alle!) må man gå videre til å se på hvordan disse kan kvantifiseres (måles/telles), og se på attributter som har med kvalitet å gjøre. I denne fasen er det også viktig å se på hvilke tjenester som eventuelt kan slås sammen, for å redusere tjenesteomfanget generelt sett. o Utarbeidelse av de første SLA-avtaler. Med utgangspunkt i erfaringene fra forrige fase, velges det ut noen meget få tjenester, der man er komfortabel med at man kan måle kvantitet og kvalitet, og det utarbeides serviceavtaler for disse.

Standarder (ITIL-standarden) side 15 av 24 På samme måte som for eksempel ISO-sertifisering kan et SLA-prosjekt bli svært omfattende og arbeidskrevende. For at resultatet skal bli bra kreves det innsats fra mange deler av organisasjonen.. Et gjennomført SLA-prosjekt vil, dersom det er korrekt gjennomført, gi som resultat veldefinerte tjenester som leveres med avtalt kvalitet og kvantitet til avtalt pris. Dersom prosessen gjennomføres for raskt vil dette prege resultatet av prosessen. En SLA-rapport kan også si noe om årsaken til redusert kvalitet. F.eks. når en kunde kjøper for lav kapasitet og kundens trafikkmengde over tid øker, slik at responstiden blir for lang. Dette gir grunnlag for reforhandling av avtalen om leveranse av kapasitet. Leverandøren kan være proaktiv ovenfor kunden og få solgt mer. Kunden selv gis også mulighet til å ta initiativ. 1.5.3. Ulike avtaletyper i forbindelse med Tjenestenivåavtaler Figur 1-2 Tjenestenivåavtaler I prosessen Tjenestenivåavtaler skilles det mellom tre ulike typer kontrakter. Hver av dem er beskrevet nærmere under: SLA-avtale er en skriftlig avtale mellom en kunde og en tjenesteleverandør, som dokumenterer hvilke tjenester og kvaliteten på disse, som skal leveres. Innholdet i slike avtaler påvirker innholdet i de to andre avtalene i figuren over. En OLA (Operational Level Agreement) er en intern overenskomst om levering av tjenester. For at en tjenesteleverandør skal være sikker på å levere tjenester til en kunde i henhold til de krav som er beskrevet i en SLA-avtale, trenger de enkle, interne avtaler med enkelte støttegrupper. Disse støttegruppene understøtter deler av bedriftens IT-organisasjon og deres levering av tjenester påvirker de tjenester som leverandøren er i stand til å yte til kunden. Slike avtaler trenger ikke å være så kompliserte. Dersom for eksempel en SLA-avtale inneholder krav om at feil skal rettes opp innen 4 timer, må det etableres interne rutiner slik at den nødvendige beredskapen er på plass for at dette skal oppfylles. OLA-avtaler inngås altså mellom en tjenesteleverandør og en intern underleverandør Understøttende kontrakter (underpinning contract) er en skriftlig avtale mellom en ekstern tjenesteleverandør av IT-tjenester, som understøtter deler av bedriftens IT-organisasjon og deres levering av tjenester. Det er ikke alltid at en bedrift kan dekke alle tjenester selv. Derfor må de i en del tilfeller støtte seg på eksterne tjenesteleverandører. Disse avtalene må, på

Standarder (ITIL-standarden) side 16 av 24 samme måte som OLA-avtalene, underbygge de krav som stilles i en SLA-avtale. Understøttende kontrakter inngås altså mellom en tjenesteleverandør og en ekstern underleverandør. 1.6. Tilgjengelighetsstyring Tilgjengelighetsstyring skal sikre at de tjenestene som leveres tilfredsstiller kundens krav til tilgjengelighet. Målet med tilgjengelighetsstyring er å optimalisere egenskapene til ITinfrastrukturen, tjenestene og hjelpetjenestene mest mulig kostnadseffektivt og sikre et bestemt tjenestenivå. Dette innebærer også å anta og planlegge for forventede feil, og å overvåke SLA-avtalene. Tilgjengeligheten må være på et tilfredsstillende nivå slik at kundens bedrift kan nå sine forretningsmål. Innenfor alle områder der det tilbys tjenester må tilgjengelighetsnivået være definert og målbart i en SLA-avtale. 1.6.1. Fordeler med Tilgjengelighetsstyring En av fordelene med å bruke tilgjengelighetsstyring er at IT-tjenester med krav til tilgjengelighet blir planlagt, implementert og administrert med tanke på å nå det oppsatte målet. Det er altså fokus på tilgjengelighetsstyring hele veien. Vi skal se nærmere på flere fordeler (ITIL 2000). - En bestemt person i IT-organisasjonen blir gjort til ansvarlig for tilgjengeligheten - Alle tjenester utvikles med tanke på å oppnå kravene til tilgjengelighet - Tilgjengelighetsnivået som leveres er dokumentert og forsvarer kostnadene - Det er enighet om tilgjengelighetsnivået som kontinuerlig blir målt og kontrollert for å støtte opp under SLM - Hendelser der tilgjengeligheten blir dårligere enn det oppsatte kravet blir registrert og tiltak iverksatt - Man vurderer tilgjengeligheten både fra bedriftens og brukernes perspektiv for å sikre en optimal IT-infrastruktur - Hyppighet og varighet av feil reduseres over tid - Støttegruppene i IT-organisasjonen endrer fokus fra å rette feil til å forbedre tjenesteleveransen (fra reaktiv til proaktiv) - Man ser at støttegruppene i IT-organisasjonen tilfører bedriften en verdi For å kunne delta i diskusjonen i forbindelse med tilgjengelighet bør vi også kjenne til noen begreper som vi skal forklare nærmere her: Tilgjengelighet (availability) De ulike tjenestene som en bedrift har behov for, skal være tilgjengelig når det er behov for dem. Så nær 100 % oppetid som mulig på IT-systemet og de tjenester det kan tilby. Tilgjengeligheten er avhengig hvordan bedriften takler situasjonen når en feil oppstår. Pålitelighet (reliability) Tjenestene vi har behov for er alltid tilgjengelig og utføres feilfritt. Påliteligheten avhenger av påliteligheten til den enkelte komponent, samt IT-systemets evne til å kompensere for feilsituasjoner (innebygget redundans).

Standarder (ITIL-standarden) side 17 av 24 Feilsituasjon (failure) Svikt eller sammenbrudd av nettet eller tjenestene det tilbyr. Før eller siden vil det oppstå feil og da er det viktig at bedriften har rutinene på plass for raskest mulig å rette opp dette. Reetablering (recovery) Vi retter opp en oppstått feilsituasjon og kommer tilbake til normalsituasjonen, der nettet fungerer og tjenestene det tilbyr er tilgjengelige. Tiden det tar å komme i orden igjen er meget viktig, og det er ofte beskrevet en maksimalgrense i en SLAavtale i forhold til kundene. 1.6.2. Måling av tilgjengelighet Den konkrete målingen av tilgjengeligheten kan gjøres på mange ulike måter. Idet man skriver en SLA-avtale er det viktig at dette blir konkretisert slik at ikke misforståelser oppstår. Vi skal se nærmere på ulike måter denne målingen kan utføres på. - En mulighet er å måle tilgjengeligheten i %. Her er det viktig at man spesifiserer hvordan disse målingene skal foretas. Snakker vi om så og så mange % nedetid pr dag, pr uke, pr måned eller i året. Dette har stor betydning for hvordan vi tolker måleresultatet. 8 timer nedetid vil gi henholdsvis: o 66,7 % oppetid ved måling pr dag o 95,2 % oppetid ved måling pr uke o 98,9 % oppetid ved måling pr måned o 99,9 % oppetid ved måling pr år. Gode resultater med høye tall for oppetiden kan virke motiverende for IT-personalet. Det er også mulig å måle det inverse av metoden over. Altså at man måler nedetid i %. - En annen mulighet er å måle feilfrekvensen. Da registreres kun antall feilsituasjoner, og ingenting om konsekvenser eller nedetid som følge av feilen. Feilsituasjoner som ville gitt dårlige resultater for målemetoden over (4 timer nedetid målt pr uke gir 97,6 % oppetid), teller her bare som 1 hendelse. Denne målemetoden bør brukes sammen med målinger av varighet for hendelser, for å gi et mer balansert bilde. - En tredje mulighet er å måle varigheten av hver hendelse. Denne metoden opererer med timer og minutter istedenfor %. Denne typen måling vil virke motiverende for ITpersonalet. - En fjerde mulighet er å måle gjennomsnittstiden mellom hver gang det oppstår feilsituasjoner. Da registreres kun tiden mellom hver feil og ingenting om konsekvenser eller nedetid som følge av feilen. Denne metoden har en del fellestrekk med metoden over. - En femte mulighet er å måle konsekvensene av en konkret feil. En hendelse som medførte 2 dager nedetid på systemet vil her gi dårlig uttelling, mens det for måling av feilfrekvensen kun vil bli registrert som en enkelt hendelse. Denne metoden gir et godt bilde på hva de ulike hendelsene faktisk medfører av ulemper. Som vi ser av betraktningen over er det svært viktig at man i en SLA-avtale er veldig konkret i sin beskrivelse av hva som skal måles, og at begge partene er enige om og forstår den måten vi ønsker å måle dette på.

Standarder (ITIL-standarden) side 18 av 24 1.7. Hendelsesstyring I (ITIL 2000) defineres en hendelse som noe som skjer, som ikke er del av standard tjenestedrift og som medfører, eller kan medføre, en stopp i eller en reduksjon av kvaliteten av tjenesten Målet for prosessen Hendelsesstyring er å behandle hendelser på en slik måte at standard tjenestedrift, slik den er definert i SLA-avtalen, så raskt som mulig kan gjenopprettes. I tillegg til Servicesenteret, involverer denne prosessen også andrelinjen og tredjelinjen, men det er Servicesenteret som har det overordnede ansvaret for behandlingen av hendelsene. Ikke alle henvendelser til et Servicesenter er rapporter om hendelser, som vi kan se av definisjonen over (men alle skal behandles til kundens tilfredshet). Det er her spesielt viktig å skille ut forslag om endringer (i systemer eller i tjenestenivå) som en egen type henvendelse som skal behandles av en egen prosess versjonsstyring. Oversikt over funksjonene i prosessen Hendelsesstyring I figuren under som vi har hentet fra (ITIL 2000), viser vi en oversikt over hovedfunksjonene i prosessen Hendelsesstyring. Flere av disse funksjonene har vi omtalt under beskrivelsen av Servicesenterets oppgaver. Vi skal her kort oppsummere det viktigste som skjer i hver av funksjonene. Hendelsesrapportering og registrering Klassifikasjon, førstelinjestøtte Oppfølging Endring? nei ja Endringshåndtering Undersøkelse og diagnose ja Løsning og gjenoppretting Endring? nei Avslutning Funksjonene i prosessen Hendelsesstyring Hendelsesrapportering og registrering Alle hendelser skal registreres. Det er viktig å få med så mye informasjon som mulig som kan bidra til å finne en løsning på problemet. Det omfatter: symptomer, andre data som på ulike måter kan støtte diagnosen og informasjon om den systemenheten hvor problemet har

Standarder (ITIL-standarden) side 19 av 24 oppstått. Det er også, som vi har vært inne på tidligere, viktig at alle hendelser registreres selv om Servicesenteret regner med å løse den selv. Hendelser kan rapporteres direkte til Servicesenteret eller registreres på andre måter, for eksempel via automatiske logger. Men det må alltid være Servicesenteret som har full oversikt og kontroll over alle registrerte hendelser. Klassifikasjon og førstelinjestøtte Klassifisering er en av de viktigste oppgavene i Hendelsesstyringen og en krevende oppgave. Klassifisering betyr kort fortalt å identifisere hva problemet er og bestemme hva som skal gjøres. I klartekst betyr det imidlertid å ta stilling til spørsmål som: - type tjeneste som har problemer - hvilken SLA-avtale det gjelder - hvem som bør ta seg av hendelsen - hva slags prioritet hendelsen skal få (dette bestemmes av SLA-avtalen og av problemets art) - hva slags informasjon vi må vi finne og kontrollere for å kunne løse problemet - hva en foreløpig rapport til ledelsen om hendelsen skal inneholde - om vi kan finne noe om tilsvarende hendelser i databasen for Kjente feil og løsninger Dette må gjøres selv om Servicesenteret selv finner løsningen på hendelsen. I så fall registreres hendelsen med klassifikasjonen og løsningen. Det er viktig å ha en oversikt over hvor mange hendelser som får en løsning direkte i førstelinjen. Dette er viktig for å måle tjenestenivået. Hvis Servicesenteret ikke selv finner løsningen går det videre i prosessen. I løpet av dette trinnet i prosessen er det viktig å skille ut hendelser som i virkeligheten er forslag om endringer i et avtalt tjenestetilbud. Disse sendes til prosessen endringshåndtering. Undersøkelse og diagnose Hendelsen sendes til andrelinjen som undersøker problemet videre. Samtidig vurderes om noe kan gjøres for å minske problemene for brukeren. (ITIL 2000) nevner som et eksempel at problemer med en skriver kan reduseres ved at brukerne får tilgang til en annen skriver, selv om den er lengre vekk. Andrelinjen skal, når den mottar en hendelse til behandling gjøre følgende: - registrere tid mottatt (bør gjøres automatisk) - holde alle data om hendelsen oppdatert - informere Servicesenteret om mulige straksløsninger for å minske ulempene for kunden - sammenligne hendelsen med andre hendelser i databasen for Kjente feil og løsninger - diskutere endring av prioritet med Servicesenteret hvis dette vurderes nødvendig eller riktig - registrere alt som skjer i arbeidet med løsning av hendelsen - sende hendelsen tilbake til Servicesenteret når den har fått en løsning

Standarder (ITIL-standarden) side 20 av 24 Gjenoppretting av tjenesten Etter at løsningen er funnet skal den iverksettes. Hvis mulig iverksettes løsningen der og da. Hvis det er nødvendig å gjennomføre endringer for å finne en løsning, utarbeides et endringsforslag som sendes til prosessen endringshåndtering. I så fall kan en foreløpig løsning være å finne reserveløsninger. All informasjon om hva som ble gjort skal registreres. Avslutning Servicesenteret kontrollerer om kunden kan akseptere den valgte løsningen. Servicesenteret kontrollerer også om informasjonen om hendelsen og løsningen er klar og konsistent. Deretter blir hendelsen registret som avsluttet med alle detaljer rundt behandlingen, kundens reaksjon på løsningen etc. Oppfølging Det bør finnes et system som overvåker status for alle hendelser og varsler automatisk når en hendelse står registret for lenge i systemet som ikke-ferdigbehandlet. Det er Servicesenteret som har ansvaret for overvåkingen. 1.8. Endringsstyring For å løse et IT-problem må vi ofte gjøre en endring. Et IT-problem i denne sammenhengen kan være: - Brukerne oppdager feil i systemet, eller i infrastrukturen eller i tjenestetilbudet fra ITorganisasjonen - Det skjer endringer i omgivelsene som gjør at systemet ikke virker som planlagt - Brukerne har nye krav til systemet, bruken av systemet eller til tjenestetilbudet I alle tilfeller vil brukerne henvende seg til Servicesenteret og be om at noe blir gjort. Den siste situasjonen gir en direkte henvendelse om endring. De to første situasjonene vil i første omgang behandles som hendelser. Dette ofte medføre behov for endringer for å finne en løsning på hendelsen. Endringsstyring er den prosessen som skal sikrer at endringsforslag får en ryddig og kontrollert behandling. Det er en kjent sak at endringer ofte fører til nye problemer, et hovedmål med denne prosessen er dermed å sikre at slike følgeproblemer ikke oppstår. I tillegg er det viktig at endringene virkelig er gjennomtenkte og gir det resultatet vi ønsker. En veldefinert endringsprosess skal altså sørge for dette. Men en slik prosess kan fort bli temmelig omfattende og byråkratisk og det er derfor også viktig at vi tar stilling til hvor stor endringen skal være for at den skal fanges opp av denne prosessen. Et finmasket nett gir mye administrasjon og antagelig mye ergrelser hos både IT-personell og brukere. Brukerne fordi de må vente på endringen unødig lenge IT-personell fordi de synes det er blir for mye papirarbeid og byråkrati for en fillesak. Prosessens prosedyrer har lettere for å bli respektert hvis vi sørger for å holde en del mindre endringer utenfor. Som regel ser vi på administrasjon av tilgang til systemene som administrasjon og ikke endring. Vi kan da overlate dette direkte til Servicesenteret uten å involvere prosessen endringshåndtering. Men vi må tenke oss nøye om. Det kan for eksempel være ganske viktig å ha kontroll på hva en konsulent skal ha tilgang til, det kan være flere enn dem han jobber for som må godkjenne dette.

Standarder (ITIL-standarden) side 21 av 24 Hver enkelt bedrift må bestemme seg for hvor grensen går for hva som skal behandles etter endringsstyringsprosessens nokså strenge krav, og når det kan tillates unntak. Det kan være fristende å ikke være så nøye. Men vi som har opplevd at flere av våre mest sentrale kundesystemer ikke er tilgjengelige onsdag morgen, fordi en stresset systemansvarlig har gjort en kvikk fix i løpet av natten, har en tilbøyelighet til å være ganske strenge. Nedenfor viser vi en mulig prosess for endringer. Vi ser at prosessen har ett sentralt register eller en database for registrering av alle endringer. Vi starer med å registrere endringsforslaget. Etter hvert tilføyes alle vurderinger og beslutninger og alt som gjøres med endringen. Målet er at registeret skal inneholde alle data om behandling av endringen og hele tiden være oppdatert med status. Registrering av alle endringer gir bedre sikkerhet fordi: - man kan spore endringer som i ettertid gir problemer, da kan det være nyttig å kunne lese både hvilke vurderinger som ble gjort og hvilke beslutninger som ble tatt - vi øker folks bevissthet forhold til endringer fordi det kreves at de må beskrive ønsket endring og begrunne hvorfor de vil ha en endring - vi kan se flere endringer i sammenheng og dermed kan endringer som er i konflikt med hverandre bli oppdaget La oss se nærmere på hver av hovedaktivitetene i prosessen, se Figur 1-3. Det er vanlig å utpeke noen som er ansvarlig for kontroll av alle endringer. Vi kan kalle vedkommende endringsansvarlig. Det kan være én person eller en gruppe personer, med hvert sitt område. Endrings register validere utvikle klassifisere planlegge teste Melde endring vurdere konsekv. realisere nei Haster? OK? ja idriftssett ja nei hasteprosedyre Figur 1-3 Prosess for endringsstyring 1.8.1. Melde endring Det kan være greit å etablere et standardformular for å melde inn endringsforslag. Alle kan i prinsippet melde inn forslag. Men i større organisasjoner er det vanlig å la en koordinator (eller flere) ta seg av arbeidet med å beskrive endringsforslag. Dette kan være lurt da vedkommende får oversikt, og derfor kan sile ut endringer som allerede er meldt inn, eller

Standarder (ITIL-standarden) side 22 av 24 avslå visse ønsker allerede på dette stadiet. Ofte refererer vi til vedkommende som registrerte endringsønsket som opphavsperson for endringen. 1.8.2. Behandling av endringsforslag Hvert endringsforslag må få en formell vurdering som enten fører til at forslaget blir avvist, eller til at forslaget blir godkjent. Det er endringsansvarlig som i første rekke behandler forslaget. Behandlingen består av validering, dette er en vurdering av om forslaget er klart, komplett utfylt, ikke skyldes en misforståelse, eller ikke allerede er meldt inn og behandlet. Videre vil det bli klassifisert. Klassifiseringen skal være til støtte i prioriteringen av endringsforslaget. Klassifiseringen kan avhenge av - viktighet - type endring - type komponent som skal endres (program, datalager, infrastruktur, maskinvare, driftsprosedyre, tilgang etc.) - nødvendig forarbeide - andre forhold som vurderes som relevante Dernest vurderes konsekvensene av endringen. Det kan være konsekvenser i form av driftsstans, kostnader, driftsegenskaper, brukervennlighet, påvirkning av andre applikasjoner, ressursbruk etc. I dette arbeidet kan endringsansvarlig ha behov for å trekke inn eksperter på den applikasjonen, maskinvaren eller infrastrukturen det gjelder. Tilslutt vurderes om endringen kan gjennomføres som hasteendring. De fleste ITorganisasjoner aksepterer at noen endringer behandles utenom normale prosedyrer. Årsaken er ganske enkelt at de kan gjelde alvorlige feil i høyt prioriterte systemer. Hvis svært viktige systemer ikke kan brukes på grunn av feil, vil det normalt være krav i SLA-avtalen om en maksimal feilrettingstid på noen få timer. Da har vi ikke tid til å følge normale prosedyrer. Konsekvensene av dette er at vi unntaksvis må akseptere feilretting direkte i driftsmiljøet (se mer om dette nedenfor) og at vi kortslutter normale prosedyrer for testing, konfigurering og idriftssetting av nye versjoner av en applikasjon. Men dette krever at vi har høyt kompetente personer, arbeider svært strukturert og rydder opp etterpå. Og at vi ikke faller for fristelsen til å gjøre dette til den normale endringsprosedyren i organisasjonen. Resultatet av behandlingen er at endringen enten avvises, sendes tilbake til videre bearbeiding (hvis vi mangler opplysninger) eller godkjennes, og da enten som hastesak eller som normal endring. 1.8.3. Planlegging og gjennomføring av endring Godkjente endringer (som ikke skal behandles som hastesaker) prioriteres og settes inn i en større sammenheng. Hvordan en endring skal prioriteres og hvilke krav som stilles til tid for gjennomføring, er regulert gjennom SLA-avtalen. For alle endringer, selv om de ikke gjennomføres med engang, skal det angis en tid og hvordan de er prioriterte. Endringene gjennomføres normalt ikke av den endringsansvarlige, men av en som har god kompetanse i det spesielle området. Vedkommende vil rette feil i et program, kjøpe ny skriver og klargjøre denne for installasjon, konfigurere databasen på nytt, lage en ny modul, osv. Alt avhengig av oppgaven. Før endringen gjennomføres, skal det utarbeides en spesifikasjon over hva som vil bli gjort. Det skal legge vekt på å klargjøre at ikke endringen får utilsiktede

Standarder (ITIL-standarden) side 23 av 24 konsekvenser for andre deler av systemet, infrastrukturen eller andre systemer. Det er god praksis at denne spesifikasjonen vurderes av en annen person som kjenner området det gjelder. Det er et viktig prinsipp at vi aldri endrer i den versjonen av systemet som er i drift (med unntak av hastesaker, se over). Driftsversjonen av systemet er en kopi av master, originalen, og vi retter alltid i en ny kopi av master som vi tar inn i det såkalte utviklingsmiljøet. Hensikten med alt dette er selvfølgelig å hindre at vårt arbeid med endringene får utilsiktede konsekvenser for de systemene som er i drift. Når endringene er gjennomførte, må vi alltid sørge for å etablere en ny master. Hvis vi synder mot dette risikerer vi store problemer, for eksempel at endringen forsvinner neste gang vi skal gjøre noe med systemet. Når det er gjort endringer, må systemet testes på nytt. Også om endringene er i maskinvare eller i infrastruktur er det viktig å teste om systemene som er avhengig av de endrede modulene fungerer som før. Først når vi er sikre på at systemene fungerer som før, kan endringene settes i drift i driftsmiljøet. Det er vanlig at ansvarlig for drift skal godkjenne at en endring har god nok kvalitet til å settes i drift i driftsmiljøet. I ITIL sammenheng er det prosedyren Versjonsstyring som sørger for denne kontrollen og påfølgende idriftssetting. Det er ikke sikkert at en gjennomført endring settes i drift med en gang. Det er vanlig å samle opp flere endringer, hvis de ikke haster, og la en ny versjon av systemet inneholde flere ulike endringer. Dette bør være regulert gjennom SLA-avtalen. Avtalen kan for eksempel inneholde et krav om at det ikke skal settes i drift flere enn et vist antall nye versjoner i året, av hensyn til driftsstabiliteten. Selvfølgelig med unntak av retting av alvorlige feil. I dette tilfellet får vi en avveining mellom to tjenestekrav. For å være raske med å rette feil og oppfylle kundenes ønsker burde en endring settes i drift med en gang. For å bevare driftsstabiliteten er det ønskelig å vente. Dette viser hvor viktig det er å samarbeide med kundene om SLA-avtalen. Da får kundene gjøre avveiningene og velge ut fra sine egne prioriteringer. 1.9. ITIL i fremtiden ITIL s popularitet og utberedelse er stadig økende og ITIL omtales i dag som verdens mest utbredte tilnærming til forvaltning av IT-prosesser. For å understreke aktualiteten kan vi for eksempel nevne at vi finner en egen interesseorganisasjon for ITIL i Norge (Itsmf), en egen faggruppe for ITIL i Den Norske Dataforening og at Computerworld distribuerte artikkelsamlingen Seks steg til ITIL i sin kompendiumserie sommeren 2007. Kilden til noe av innholdet i dette avsnittet er fra denne artikkelsamlingen. Videre er det slik at flere leverandører av it-tjenester hevder å gå over til ITIL fordi kundene i dag etterspør dette. Den stadig økende kompleksiteten i tjenester, systemer og løsninger stiller store krav til at rutinene er gjennomtenkt og dokumentert for å få en god og strømlinjeformet tjenesteproduksjon. Dette er argumenter som i dag benyttes når bedriftene går i gang med ITIL. Dersom du ønsker å lære mer om ITIL har vi ved AITeL et eget emne som heter LN780D ITIL beste praksis for drift av IT-systemer. Dette kurset bygger på ITIL versjon 3. Av fordeler som i dag trekkes fram ved innføring av ITIL kan man nevne: Det er tillitsbyggende og fører til økt tilfredshet blant kunder og ansatte. Man øker verdien av it-bruken gjennom høyere produktivitet, bedre arbeidsmoral og reduserte driftskostnader.

Standarder (ITIL-standarden) side 24 av 24 Man får systematisert opplærings- og sertifiseringsoppgaver. Det blir mindre kaos og brannslukking. Problemene kan imidlertid være: For høye ambisjoner og forventninger. Urealistiske forventninger til støtteverktøyene. Motstand mot endringer og for dårlig kompetanse på å lede endringsprosesser. Tjenestenivået går ned i oppbyggingsfasen. Dårlig prosjektledelse. For å lykkes trekker man gjerne fram følgende: Toppledelsen må være involvert, oppmerksom og engasjert. Man må fokusere på noen utvalgte områder som gir såkalte quick wins. Det er viktig at alle berørte parter involveres og at man har en forankring hos alle. Man bør vurdere bruk av ekstern oppstartshjelp og man bør investere i egnede støtteverktøy. 1.10. Lenker Det offisielle nettstedet for ITIL ( http://www.itil-officialsite.com/home/home.asp) Alt om ITIL Computerworld (http://www.idg.no/kunnskapssenter/nettverktelekom/nettverksadministrasjon/article56154.e ce) Betydningen av ITIL (http://www.digi.no/php/art.php?id=782481) Artikkel om ITIL v2 og v3 (http://www.idg.no/computerworld/article198783.ece) 1.11. Tilhørende kapitler i læreboka Kapittel Pensum Navn 9 Ja Serviceledelse (ITIL) 9.1, 9.2, 9.3, 9.5, 9.7, 9.10, 9.14