Konfigurationshantering enligt ITIL-modellen

Transkript

1 Konfigurationshantering enligt ITIL-modellen LARS HOLMBERG Examensarbete Stockholm, Sverige 2004 TRITA-NA-E04134

2 Numerisk analys och datalogi Department of Numerical Analysis KTH and Computer Science Stockholm Royal Institute of Technology SE Stockholm, Sweden LARS HOLMBERG TRITA-NA-E04134 Examensarbete i affärsutveckling och medieteknik om 20 poäng vid Programmet för datateknik, Kungliga Tekniska Högskolan år 2004 Handledare vid Nada var Björn Hedin Examinator var Nils Enlund

3 Sammanfattning IT Infrastructure Library (ITIL) definierar en metod för att bedriva produktion av IT-tjänster. Som en del av detta beskrivs utförligt hur man bör lagra information om de komponenter som används i arbetet, samt vilka steg som bör vidtagas för planera och genomföra förändringar av dessa. Platsen för lagringen av denna information kallas för en Configuration Management Database (CMDB). Detta examensarbete utreder hur man implementerar en CMDB, och vilka fördelar respektive problem som ITIL-modellen har. Några av slutsatserna som dras i rapporten är: En CMDB som ska passa alla är svår att utveckla, eftersom organisationer kan variera så mycket i storlek och arbetssätt. ITILs beskrivningar är ibland inte tillräckligt tydliga utan lämnar utrymme för missförstånd. För att kunna använda en CMDB korrekt krävs att användarna har kunskap om ITILprocesserna. En CMDB kan och bör integreras med ett antal ytterligare verktyg för att nå sin fulla potential. Configuration management according to the ITIL model Abstract The IT Infrastructure Library (ITIL) defines a method for the provision of IT-services. As a part of this, it describes how to store information on the components used in this procedure, and the steps which should be taken to plan and execute changes of these components. The information is stored in what is called a Configuration Management Database (CMDB). This thesis concerns the implementation of a flexible CMDB, and the advantages and drawbacks of the ITIL-model. Some of the conclusions drawn in this report are: It is difficult to construct a CMDB that fits any type of organization, since size and work-methods differ. The descriptions in the ITIL-literature are sometimes too vague, making them easy to misinterpret. In order to use a CMDB correctly, its users must have at least a basic understanding of the ITIL processes. A CMDB must be integrated with a number of additional tools to reach its full potential. ii

4 Förord Denna rapport beskriver mitt examensarbete vid Kungliga Tekniska Högskolan. Arbetet utfördes för institutionen för Numerisk analys och datalogi (NADA) inom kompetensinriktningen affärsutveckling och medieteknik (AFM). Arbetets uppdragsgivare var Meteorit AB. Jag vill tacka min handledare på NADA, Björn Hedin, särskilt för hans förslag och idéer kring vad arbetet skulle fokuseras på. Jag vill även tacka alla på Meteorit Stockholm som hjälpte till under arbetet, särskilt min handledare Mats Ståhl, som tog sig tid att hjälpa mig varje gång jag hade några frågor eller problem. Stockholm, juli 2004 Lars Holmberg iii

5 Innehållsförteckning 1 Inledning Bakgrund Frågeställning Syfte Målsättning Avgränsningar Metod IT Infrastructure Library Definitioner Processerna Att implementera ITIL Implementation CMDB Vidareutvecklingsförslag Analys Brister i ITIL-modellen Andra svårigheter i designen av en CMDB Slutsatser / Rekommendationer Möjliga vidare studier Referenser Bilaga A - Databasdokumentation Hur läser man den här dokumentationen? Namngivningskonventioner i databasen Tabeller Främmande nycklar Dataåtkomst ifrån webbapplikationen Relaterade dokument Bilaga B - Databasinnehåll Bilaga C - Användarhandledning Introduktion Ej fungerande komponenter Överblick Processerna Bilaga D Vidareutvecklingsförslag Integration med programbeställningsverktyg Problem/uppenbara begränsningar...55 iv

6 12 Bilaga F - Kravspecifikation Mål och omfattning Informationsanvändare Process / funktionskrav Generella principer Servicekrav Påverkan på verksamheten Avgränsning Krav som ej ska uppfyllas...65 v

7 Figurförteckning Figur 1: Modell för processförbättring...10 Figur 2: Generell ITIL-process...11 Figur 3: Configuration Management...13 Figur 4: Change Management...15 Figur 5: Change Management/Urgent Procedures...16 Figur 6: Beröringspunkter för Change Management och Project Management...18 Figur 7: Release Management...19 Figur 8: Incident Management...22 Figur 9: Problem Management...24 Figur 10: Överblick och indelning av processerna...27 Figur 11: Incidenteditor...29 Figur 12: Problemeditor...30 Figur 13: Request For Change-editor...31 Figur 14: Release-editor...32 Figur 15: Konfigurationseditor...33 Figur 16: Beroendeeditor...34 Figur 17: Historik...34 Figur 18: Integrationsalternativ...35 vi

8 1 Inledning 1.1 Bakgrund Utvecklingen inom IT har haft stor inverkan på hur organisationer fungerar. Allt snabbare produkt- och tjänsteutveckling har lämnat traditionella hierarkiska organisationer på efterkälken och gjort att utvecklingen gått mot mer flexibla organisationer. Istället för en strikt hierarkisk indelning i olika vertikala avdelningar/funktioner fokuserar många organisationer istället på horisontella processer där flera olika avdelningar kan vara inblandande för att nå ett gemensamt mål. 1 Organisationer är också mer beroende av IT än någonsin tidigare, vilket satt fokus på högkvalitativa IT-tjänster anpassade till affärsbehov och användaren. 2 Grunden till The IT Infrastructure Library (ITIL 3 ) lades under 1980-talet av den brittiska myndigheten Central Computer and Telecommunications Agency (nu en del av Office of Government Commerce, OGC). ITIL togs fram för att tillhandahålla ett effektivt tillvägagångssätt för brittiska myndigheter och offentlig sektor att hantera IT. ITIL växte fram ur de bästa praxis (best practices) som observerats i företag som tillhandahåller IT-tjänster. I böckerna i ITIL-serien definierar OGC en praxis för produktion av IT-tjänster och beskriver denna med hjälp av ett stort antal processbeskrivningar, checklistor, uppgifter, och ansvarsfördelningar. Dessa är allmänt formulerade och kan tillämpas i de flesta organisationer, trots vitt skilda arbetssätt. Ett antal stora företag har vidareutvecklat ITIL och utvecklat sina egna modeller och stödverktyg baserade på denna. Bland de mest kända exemplen finns Microsoft Operations Framework, Hewlett & Packard IT Service Management Reference Model och IBM IT Process Model 4. ITIL har haft stort genomslag och är idag den i klart viktigaste standarden för produktion av IT-tjänster. ITIL ägs av OGC och är vare sig vinstdrivande eller kontrollerat av något specifikt företagsintresse, vilket bidragit till dess spridning. 5 Det finns en mängd datorhjälpmedel som är användbara för den som tillämpar ITIL, men inga särskilda ITIL-verktyg ifrån OGC. 6 Enligt ITIL bör man ha en Configuration Management Database (CMDB) för att hålla reda på information om de komponenter (mjukvara, hårdvara, dokumentation, etc.) som behövs för att tillhandahålla tjänsten. Trots ITILs ingående beskrivning av vad en CMDB bör innehålla och vad den ska kunna göra är det långt ifrån självklart hur en sådan ska konstrueras. Detta examensarbete utreder hur man implementerar en CMDB, och vilka fördelar och problem som ITIL-modellen har. 1.2 Frågeställning Detta examensarbete ska i huvudsak besvara en fråga: Hur bör man implementera en flexibel CMDB enligt ITIL-modellen? Redan innan jag slutfört min litteraturstudie stod det klart att man ställs inför ett antal problem i detta arbete: 1 IT Service Management Forum (itsmf), IT Service Management, an introduction, 2002, s 11 2 The Stationary Office, Best Practice for Service Support, s xiii 3 ITIL är ett registrerat varumärke tillhörande Office of Government Commerce 4 Se litteraturlista för referenser 5 Mats Ståhl 6 Se litteraturlista för exempel på verktyg 1 / 72

9 ITIL bestod tidigare av hela 50 böcker som nu sammanfattats till 8 stycken 7,8. Det är en mycket stor mängd information att bearbeta och ta hänsyn till när man ska bygga ett datorstödssystem. Naturligtvis berör inte allt som står i böckerna CMDB:n, men eftersom allt inte är samlat på ett ställe så måste man gå igenom en stor mängd information för att hitta allt man behöver veta om den. En CMDB är ett ganska avancerat system. Även efter att ha läst och förstått alla krav som ställs på den så är det långt ifrån självklart hur den ska konstrueras. Texten i ITIL-böckerna är formulerad väldigt allmänt för att medge att man anpassar deras råd till just sin organisations behov. Detta leder tyvärr även till att allting blir väldigt otydligt för en konstruktör, och det är väldigt svårt att hitta några fasta riktlinjer. 1.3 Syfte Detta examensarbete ska undersöka möjligheterna och svårigheterna i ITIL-modellen, med särskild fokus på CMDB:n, och även i viss mån de processer som interagerar med den. Denna rapport riktar sig till den som är intresserad av ITIL och IT-tjänsteproduktion i allmänhet. 1.4 Målsättning Redogöra för ITIL och de av ITIL definierade processerna, med fokus på det som berör CMDB:n Utreda om det går att bygga en generell och flexibel CMDB som stöder arbetsflöden och rutiner i enlighet med ITIL modellen för IT-tjänsteproduktion och i så fall genomföra detta. Se metodavsnittet samt bilaga F Kravspecifikation för en mer detaljerad beskrivning av detta. Dokumentera databasen och föreslå möjligheter till vidareutveckling Besvara den ovan nämnda frågeställningen och resonera kring den 1.5 Avgränsningar Databasen som utvecklas ska inte vara en fullfjädrad CMDB, eftersom en sådan helt uppenbart tar för lång tid att konstruera. Målet med den är att utreda hur man bör lägga upp en sådan och demonstrera att det är praktiskt genomförbart. CMDB:n har konstruerats utan någon egentlig mottagare, vilket gör att jag inte kunnat titta på de svårigheter som kan tänkas uppstå när man anpassar den till ett specifikt företag. Systemet byggs utan hänsyn till säkerhets- och prestandaaspekter, något som ITIL egentligen anser som mycket centralt. En CMDB bör även kunna sammankopplas med ett antal andra system. Exempel på dessa finns under rubriken Analys senare i denna rapport. Dessa verktyg torde förhoppningsvis kunna kopplas ihop med CMDB:n som utvecklas, men även detta ligger utanför examensarbetets ram. Utformningen av gränssnittet till databasen har inte prioriterats, och därför är det mycket möjligt att systemet har brister i användarvänlighet. I bilaga F Kravspecifikation finns en detaljerad listning av vilka gränssnittskrav och ITIL-krav som inte uppfyllts. 7 Office of Government Commerce, ITIL Publications < 8 United Nations System, Developing a Compendium of Good Practices for Information and Communication Technologies in UN System Organizations, < sida 6 2 / 72

10 Ursprungligen var det tänkt att systemet skulle kunna kopplas ihop med EBI Systems 9 produkt Platina. Detta skulle bland annat göra det möjligt att fritt bygga nya processflöden, men det visade sig vara ogenomförbart eftersom Platina var allt för komplext. I framtiden kan det dock vara en intressant möjlighet. Under rubriken Implementation/Vidareutveckling hittar du mer om detta. 9 EBI Systems AB, 3 / 72

11 2 Metod Mitt första steg i utredningen var att läsa igenom de ITIL-böckerna som berör konfigurationshantering, Service Support och Service Delivery, och sammanfatta de delar som var relevanta för de frågor som jag valt att studera. Sammanfattningen börjar på nästa sida, och de problem och frågetecken som jag stötte på finns under rubriken Analys. I denna fas sökte jag även efter källor för kritisk analys av ITIL. 10 För att utreda problemet ytterligare konstruerade och dokumenterade jag en förenklad CMDB med grundläggande stöd för de av ITILs processer som ligger närmast CMDB:n (Configuration, Change, Release, Incident och Problem Management). Projektet att ta fram databasen genomfördes enligt Project Management Method 11 (PMM), en metod som utvecklats av Avesta Polarit 12 i samarbete med Meteorit. Tyvärr finns det väldigt lite information om denna metod som är offentlig. Det är osannolikt att det metodvalet påverkat resultaten som presenteras i denna rapport, även om den säkerligen kan ha betytt en del för de mer tekniska utvecklingsresultaten. Det viktigaste målet för utvecklingen var att utreda om det går att bygga ett flexibelt system som stöder arbetsflöden och rutiner i enlighet med ITIL-modellen för IT-produktion, men den fördjupade kunskap i ITIL man får av att faktiskt konstruera en CMDB var en viktig bieffekt. Tiden för ett exjobb är alldeles för kort för att man ska hinna implementera ett system som täcker in alla ITIL-kraven. Därför har jag i text försökt beskriva hur det jag byggt skulle kunna vidareutvecklas till en fullfjädrad CMDB. Resultaten utvärderades enligt följande kriterier: Systemet ska uppfylla ITIL:s grundläggande krav. I det fall att tiden inte räcker till så ska det åtminstone vara dokumenterat vilka vidare åtgärder man måste vidta för att systemet ska bli fullständigt. Eventuella otydligheter eller problem i modellen ska kunna lösas utan att bryta mot några av ITIL:s principer och regler. Systemet ska vara flexibelt, på så sätt att det inte är låst till en särskild organisations implementation av ITIL-processerna. 10 För sökningarna använde jag Google, < 11 Meteorit AB, Vår projektstyrning, < 12 Avesta Polarit, < 4 / 72

12 3 IT Infrastructure Library Detta avsnitt av rapporten ger en introduktion till dig som inte redan känner till ITIL så att du kan ta till dig resonemanget i senare delar. 3.1 Varför ITIL? 13 För att bedriva effektiv produktion av tjänster inom IT krävs tre komponenter: människor, verktyg och processer. Människor är ett område som oftast har en lång tradition av effektiv hantering, och det är oftast inga problem att hitta människor med rätt kompetens eller att vidareutveckla de människor som finns i organisationen. Verktygen för att hantera de komponenter och system som krävs för IT-produktion har utvecklats starkt under de senaste åren. Därför är det oftast inga problem att hitta lämpliga verktyg för att stödja IT produktionen. Den tredje komponenten, processer, är däremot fortfarande en aning eftersatt. Om man jämför metoder och arbetssätt mellan produktion av IT tjänster och nästan vilken annan producerande verksamhet som helst så framstår IT-produktionen som rena hantverket. Det är detta problem som ITIL försöker lösa. 3.2 Definitioner En gemensam terminologi är en av grundstenarna i ITIL. Jag har valt att inte försvenska de ITIL-begrepp som inte har någon vedertagen översättning, eftersom en sådan översättning skulle förstöra denna ansträngning Kund Kunden är den i mottagarorganisationen som är behörig att betala ut ersättning till tjänsteproducenten samt att skriva på avtal med denne Användare Användaren är den som i slutändan använder programmet eller tjänsten i sitt dagliga arbete Organisationer För att kunna ta till sig såväl ITIL som resten av den här rapporten är det viktigt att ha en viss inblick i hur organisationer fungerar. De följande punkterna är en vanlig uppdelning av hur en organisation kan beskrivas, oavsett om det handlar om ett vinstdrivande företag, en myndighet eller någon annan sammanslutning: 16 Vision. Det långsiktiga målet för organisationen - ska vara utmanande, innovativt och framåtblickande. Exempel: Förena det stora IT-företagets styrka med det lilla företagets engagemang 17 eller Quick Couriers should become synonymous with express delivery in downtown Amsterdam Mats Ståhl. Se även under rubriken Bakgrund i bilaga F - Kravspecifikation 14 itsmf, s24 15 itsmf, s24 16 itsmf, s19-20 samt R. Lefton & V. Buzzota, Know Where You Are Going 17 Meteorit AB, Affärsidé och vision, < 18 itsmf s195 5 / 72

13 Mission/Strategi. Hur vi ska ta oss till målet? Definierar saker som organisationens affärsverksamhet, målmarknader, kunder och finansiella mål. Värderingar. Etiska riktlinjer som ska vägleda organisation och medarbetare att uppnå vision och mission. Exempel: lagarbete, öppenhet, ansvar och respekt för medmänniskor. Verksamhetsmål. Detta är i mycket detsamma som mission, men mer detaljerat och konkret. Målen ska vara specifika, mätbara, välvalda, realistiska och tidsbegränsade. Exempel: Två av verksamhetsmålen för Mälardalens högskola under 2003 var att ha minst 25 professorer anställda samt att ha uppnått ställning som tekniskt universitet och bedriva forskarutbildning inom minst två vetenskapsområden. 19 Policy. Rangordnar verksamhetsmålen utefter vad som är mest prioriterat, och hur de ska uppnås. Tydliga policies gör att medarbetarna kan använda sitt eget omdöme istället för att behöva detaljerade beskrivningar av exakt vad de ska göra. Detta arbetssätt bidrar till att göra organisationen mer flexibel. Planering. Förklarar hur policy ska omvandlas till specifika aktiviteter. Innehåller ett aktivitetsschema, lista över resurser som krävs, samt specifikation av kvantitet och kvalitet på det som ska levereras (ofta indelade i faser för att ge milstolpar) Handling. Aktiviteter delas ut till anställda eller kontrakteras till någon part utanför organisationen. Implementation. Aktiviteterna genomförs. Det här kan förstås gå mer eller mindre bra beroende på hur bra de anställda är på att utföra sin uppgift, men har man utfört de övriga stegen korrekt så har man i alla fall gett de bästa möjliga förutsättningarna för att det ska gå bra. För att få organisationen att röra sig i rätt riktning måste man mäta och kontrollera hur väl dessa olika delar fungerar. Framför allt är det viktigt att mission, verksamhetsmål och policy inte glöms bort Organisationskultur Sättet som människorna i organisationen handskas med andra människor, sättet beslut fattas och förverkligas samt de anställdas inställning till sitt arbete, kunder, leverantörer, överordnade och kollegor utgör vad som kallas för organisationens kultur. Kulturen kan ha stor inverkan på en organisations funktion och verkar ofta konservativt när man vill införa förändringar. Organisationskulturen kan inte kontrolleras fullt ut, men den kan påverkas. Bra ledarskap och en tydlig och konsekvent policy krävs för att förändra kulturen. 20 ITIL förespråkar att man försöker uppnå en servicekultur inom organisationen, en kultur där alla engagerar sig i att kunden blir nöjd. Målet är att kunden ska känna sig nöjd efter varje transaktion med leverantören Tjänst En av grundvalarna i ITIL är att IT-organisationen tillhandahåller en tjänst, inte bara en produkt. När någon köper en produkt är det bara genom själva valet av vilken produkt man köper som man påverkar kvaliteten. Producenten försöker uppnå en konstant och hög kvalitet genom att 19 Mälardalens högskola, Verksamhetsmål intill 2003, < 20 itsmf s The Stationary Office, Best Practice for Service Support, 2002, kap / 72

14 optimera tillverkningsprocessen, men försäljning och användningen av produkten är nästan helt åtskilda ifrån denna. 22 Tjänster däremot produceras i samarbete mellan kunden och tjänsteleverantören. Kvaliteten hos tjänsten beror alltså till viss del på hur kunden och leverantören interagerar med varandra. 23 En annan viktig insikt inom tjänsteproduktion är att det kunden vill köpa är en lösning på ett problem. Det är oftast ointressant för kunden huruvida produkten är bra eller inte enligt någon annan bedömningsgrund än om den löser problemet på ett effektivt sätt. 24 Tjänsten som tillhandahålls kan vara nästan vad som helst, till exempel en e-posttjänst, en lokalbokningstjänst eller leverans och installation av pc-datorer. Tjänsten definieras i termer av tillämpningar, snarare än i komponenter (till exempel e-post-server eller program för lönehantering ), eftersom det är kundens språk Kvalitet Quality is the totality of characteristics of a product or service that bear on its ability to satisfy stated and implied needs (ISO-8402) 26 Kvalitet kan vara olika saker för olika kunder. Det som en kund ser som grundläggande krav, kan en annan mycket väl se som en onödig extra finess. Kvaliteten bedöms normalt efter dessa kriterier: Uppfyller tjänsten mina förväntningar? Kan jag lita på att tjänsten fungerar likadant nästa gång? Är priset på tjänsten rimligt? Om tjänsten uppfyller förväntningarna eller inte bestäms av huruvida dialogen om vad som skulle levereras fungerade bra samt om tjänsteproducenten lyckades leverera det man åtagit sig. Leverantören måste aktivt ta reda på vad kunden tycker om tjänsten och anpassa den därefter för att kunden ska fortsätta vara nöjd. Kundens förväntningar ändras med tiden, och det gäller att vara medveten om detta. För att kunna komma överens om ett pris där bägge parter är nöjda måste producenten vara medveten om vilka kostnader som man kommer att ha för att tillhandahålla tjänsten samt vad konkurrenter tar för liknande tjänster Kvalitetssäkring Kvaliteten på en tjänst beror till stor del på hur aktiviteterna för att få fram den organiserats. Det finns många modeller för hur kvalitetsarbete ska bedrivas. En generell metod ges av Demings kvalitetscirkel. Metoden går ut på att man går igenom dessa fyra steg upprepade gånger: 27 Plan: Identifiera problemen och kom på idéer på hur de ska kunna lösas. Bestäm vad som ska göras, när det ska göras, vem som ska göra det, hur det ska göras och med vad det ska göras. Do: Utför de planerade aktiviteterna i liten skala eller i en experimentmiljö. Check: Undersök om det förväntade resultatet uppnåddes 22 itsmf s13 23 itsmf s13 24 itsmf s13 25 SSup s57 26 itsmf s13 27 itsmf s15 samt HCI, PDCA Cycle, < 7 / 72

15 Act: Förverkliga planen i stor skala. Se till att involvera de som berörs av förändringen och de som kan dra nytta av dina erfarenheter. I begreppet kvalitetssäkring ingår alla åtgärder och procedurer som organisationen vidtar för att försäkra sig om att tjänsten fortsätter att uppfylla kundens förväntningar och det man avtalat med denne Kvalitetsstandarder och certifieringar ISO 9000 (International Organization for Standardization, web) består av en serie standarder för quality management. ISO 9000 är en processtandard, inte en produktstandard. Att man uppfyller standarden är alltså ingen garanti på att man kommer leverera produkter/tjänster av hög kvalitet, men visar att man tar arbetet med kvalitetssäkring på allvar. Bland annat ingår följande krav: 28 organisationen har vidtagit åtgärder för att kunna ge den kvalitet man kommit överens med kunden om ledningen utvärderar regelbundet hur kvalitetssystemet fungerar och använder resultaten för att genomföra förbättringar där det behövs organisationens procedurer är dokumenterade och kommuniceras till dem som berörs av dem klagomål ifrån kunder registreras, hanteras inom rimlig tid och används för att förbättra produkten/tjänsten där det är möjligt organisationen har sina produktionsprocesser under kontroll och kan förbättra dem Vissa organisationer kräver att deras leverantörer är certifierade enligt till exempel ISO 9000 eller Dessa certifikat utfärdas av ett antal olika organisationer (dock inte av ISO själva). Att tillämpa ITIL i sin organisation är inte någon garanti för certifiering i sig, men kan vara ett stort steg på vägen. Kvalitetstänkandet i ITIL är starkt kopplat till ISO 9000 och European Foundation for Quality Management Organisationers mognadsgrad 31 Organisationer kan delas in i olika mognadsgrader efter följande skala, där varje steg i viss mån inkluderar de föregående: 32 Produktfokuserad. Arbetet i organisationen styrs helt utefter vilken insats som behövs just nu, och det finns ingen medveten styrning Processfokuserad. Organisationens prestation är planerad och kan upprepas. Systemfokuserad. Samarbetet mellan olika avdelningar i organisationen fungerar. Kedjefokuserad. Organisationen fokuserar på värdet den tillför i den leverantör-tillkund-kedjan som den tillhör. Detta innebär ett ökat samarbete med både kunder och leverantörer. Total kvalitetsfokus. Organisationen har nått så långt att kontinuerlig och balanserad förbättring är något helt naturligt. 28 itsmf, s16 29 ISO är en standard som specificerar hur man ska strukturera ledningsarbetet för miljöarbete. Titta på tvättmedlen i din lokala matbutik så kanske du hittar en populär felanvändning av ISO certifiering nämligen som miljömärkning! 30 European Foundation for Quality Management, < 31 itsmf, s itsmf s17 8 / 72

16 På samma sätt kan man dela in processer utefter hur mogna de är: Initial processen utförs helt utefter de krav som dyker upp Repeterbar processerna är under så pass stor kontroll att man presterar en jämn kvalitet. Definierad processen är dokumenterad, standardiserad och väl integrerad i organisationen. Managed organisationen mäter processens resultat och använder dem medvetet för att förbättra tjänstekvaliteten Optimerad organisationen optimerar medvetet processupplägget för att öka tjänstekvaliteten eller utveckla nya tjänster Organisationsnivåer Arbetsledningen som sker inom en organisation kan delas in i tre nivåer: 33 Strategisk planering - formulera målen för organisationen, formulera policies och verksamhetsmål, sätt budgetar etc. Taktisk ledning - omvandla strategiska mål till operationella och distribuera resurserna för att uppnå dessa mål. Operationell kontroll - verifiera att procedurer för att utföra enskilda uppgifter fungerar effektivt. Många operationella uppgifter kan specificeras explicit i förväg (som ett kokboksrecept) och är därför lätta att kontrollera och resultatet lätt att verifiera. Information flödar nedåt i denna hierarki i form av policy och kontroll samtidigt som resultat rapporteras uppåt Service Level Agreement (SLA) En SLA är ett avtal mellan IT-organisationen och kunden som beskriver tjänsten/tjänsterna som ska levereras. Den beskriver tjänsten i icke-tekniska termer och fungerar som en måttstock för hur väl tjänsten fungerar och hur den behöver förändras Kundrelationer 35 På den strategiska nivån arbetar IT-leverantören för att utforska möjligheterna att matcha sina egna mål med kundens. Detta sker huvudsakligen genom att hålla bra kontakt så att ett långsiktigt partnerskap kan uppnås. Den taktiska nivån arbetar med att ta fram och besluta om avtalen (SLA:s) mellan kund och leverantör. Relationen på den operationella nivån består av att kunden använder sig av leverantörens support och lämnar eventuella förslag eller krav på ändringar Process 36 ITIL definierar en process som en serie handlingar, aktiviteter, förändringar eller dylikt, utförda av agenter i avsikt att uppnå ett mål. 33 Michael Middleton, Information management: a consolidation of operations, analysis and strategy. Centre for Information Studies, Charles Sturt University, 2002, kapitel itsmf s23 35 itsmf s24 36 itsmf kapitel / 72

17 Processtyrning definieras i sin tur som aktiviteten att planera och reglera en process i syfte att få den att uppfylla kraven som ställts på resultaten och förbruka minimalt med resurser. Aktiviteter organiseras i olika processer utefter vilken nytta de bidrar med till verksamheten, alltså vilket mål den har. 37 En process beskrivs med hjälp av följande punkter: Vad som måste göras. Vad som är det förväntade resultatet (kvalitetskrav, kvalitetsstandarder). En metod med vilken man jämför det faktiska resultatet med det förväntade resultatet. En beskrivning av hur processen påverkar andra processer. En av de stora fördelarna med att indela arbetet i klart definierade processer är att förbättringsarbetet blir mer strukturerat. Processförbättring kan bedrivas enligt följande modell: Where do we want to be? Vision and business objectives Where are we? Assessment How can we get where we want to be? Process improvement How do we know that we have arrived? Metrics Figur 1: Modell för processförbättring 38 En av processmodellens fördelar är att varje enskild process har klara överlämningspunker där processens kvalitet kan mätas, samt att den möjliggör samarbete mellan olika funktioner i organisationen på ett strukturerat sätt. Måldefinitionen för processen används för att ta fram kvalitetsparametrar och (performance indicators) och vad som kan förväntas (standards) samt att försöka styra processen mot dessa mål. 37 itsmf s itsmf, s25 10 / 72

18 Process Owner Process Goal Quality Parameters and Key Performance Indicators Process control Input and Input Specifications Process Activities and Subprocesses Output and Output Specifications Process enablers Resources Roles Figur 2: Generell ITIL-process Procedur En procedur är en beskrivning av logiskt relaterade aktiviteter och vem som utför dem. En procedur kan inkludera steg ifrån flera olika processer. Den definierar klart vem som är ansvarig för olika moment Arbetsinstruktion En arbetsinstruktion (work instruction) definierar hur en eller flera av aktiviteterna i en procedur ska utföras Roller Alla aktiviteter i en process utförs av så kallade roller. En roll kan fyllas av en människa eller ett datorprogram. Roller kan i vissa fall delas upp mellan flera personer, och ofta kan en och samma person ha inneha flera roller. 42 ITIL definierar även ett antal specifika roller (i princip en per process): Configuration Manager, Change Manager etc. Dessa äger sin process, och är ansvariga för denna. Ansvarsfördelningen är viktig, eftersom aktiviteterna i en process kan utföras av många olika människor från olika avdelningar inom organisationen Ytterligare definitioner Övriga termer definieras under den process de är relevanta för (se nedan). 3.3 Processerna ITIL beskriver totalt elva processer. Detta examensarbete fokuserar i första hand på processerna Configuration, Change och Release Management, men tar även upp Incident, och Problem 39 itsmf, s27 40 itsmf, s27 41 itsmf, s27 42 The Stationary Office, Best Practice for Service Support, s19 11 / 72

19 Management samt funktionen Service Desk eftersom det är de som stöds direkt av verktyget som ska utvecklas. Det är omöjligt att ta upp alla dessa i detalj här (i ITIL-böckerna tar de upp ett antal hundra sidor), men denna korta introduktion bör räcka för att förstå sammanhangen i resten av rapporten Configuration Management Mål 43 sammanställa alla IT-tillgångar och konfigurationer 44 inom organisationen och dess tjänster ge tillförlitlig information om konfigurationer och deras dokumentation för att stödja de andra Service Management-processerna, särskilt Incident, Problem, Change och Release Management verifiera konfigurationsinformationen mot den faktiska infrastrukturen och rätta till eventuella undantag Definitioner Configuration Item (CI) är ett centralt koncept inom Configuration Management. En CI är en av alla de komponenter i hela det system som krävs för att kunna tillhandahålla en tjänst. Några exempel på CIs är: mjukvaruprodukter (affärssystem, systemprogramvara etc.) datorer (servrar, stordatorer, arbetsstationer etc.) dokument (systemdokumentation, specifikationer, processdokumentation, arbetsplaner, licenser, kontrakt etc.) databaser andra resurser (användare, leverantörer, etc.) CIs är ofta indelade hierarkiskt och detaljnivån varierar mellan organisationer. I teorin kan man välja att gå till den nivån där man detaljerat beskriver varenda skruv i varenda dator i organisationen, och därmed skapa en oändlig mängd extra arbete åt sig själv. Om man inte tycker att det verkar så pass engagerande att man vill ägna sig åt detta på sin fritid så bör man väga den arbetsinsatsen mot affärsnyttan. Det är ingen mening i att gå längre än att detaljerna verkligen är nyttiga i stödet för de andra processerna eller kontrollen av företagets tillgångar. Det är inte heller meningsfullt att inkludera CIs som inte kan flyttas, kopieras eller förändras enskilt. CIs som är särskilt kritiska för tjänsterna som produceras är viktigast att hålla kontroll över. Centrala nätverkskomponenter, strömförsörjning och säkerhetsutrustning är exempel på sådana. 45 En, bland annat följande: namn ID-nummer relationer till andra CIs ( använder, är en del av, är kopplad till etc.) status ( under utveckling, testas, använd i produktionsmiljön, arkiverad etc.) vem som är ansvarig för CI:n 43 The Stationary Office, Best Practice for Service Support, s Se nedan för definition av ordet konfigurationer 45 The Stationary Office, Best Practice for Service Support, s / 72

20 versionsnummer eventuella prestandaspecifikationer relaterade incident/problemärenden pris tjänster som är beroende av den Se bilaga B Databasinnehåll för fler attribut som är relevanta. Configuration Management Database (CMDB) är databasen där man lagrar alla CIs. Den är på flera sätt mittpunkten för många av ITIL-processerna. En del av målet i detta examensarbete är att implementera en rudimentär CMDB och utreda vilka lärdomar man kan dra under det arbetet. En detaljerad beskrivning av vad en CMDB ska innehålla och vilka funktioner den ska tillhandahålla finns i bilaga B Databasinnehåll och bilaga E Kravspecifikation. Baseline är ITILs term för en gruppering av CIs av specificerade versioner. En baseline kan bestå av diverse olika hårdvaru- och mjukvarukomponenter som man vet fungerar tillsammans. Ofta inkluderar det även dokumentation och specifika inställningar. Ett exempel skulle kunna vara en komplett arbetsstation, med programvara och specificerade inställningar gjorda. Syftet med en baseline är att man enkelt och kontrollerat ska kunna återgå till ett fungerande tillstånd om det uppstår problem med nyinförda versioner av hård-/mjukvara. Processdiagram Input Activities Output to other processes Request For Change System documents Configuration Management process collects information for and maintains CI :s maintaining a baseline supports all other processes with information about the infrastrukture management reporting CMDB Special reports Periodic reports Aktiviteter Figur 3: Configuration Management 46 Planering. I detta ingår att komma överens om och definiera följande: 47 o Syfte och omfattning för arbetet med Configuration Management. Detta inkluderar att bestämma hur små CIs man tänker spåra, samt hur mycket information man behöver om varje CI. o Namngivningssystem för CIs o CMDB:ns utformning och var dess data ska lagras o Val av stödverktyg (installationsverktyg etc.) o Schemaläggning och procedurval för övriga aktiviteter inom Configuration Management 46 The Stationary Office, Best Practice for Service Support 47 The Stationary Office, Best Practice for Service Support, s / 72

21 o Plan över kommande större förändringar samt processens krav på arbetsinsatser och resurser Identifiera och undersök CIs. Alla CIs och deras relationer lagras nu i CMDB:n. Statusövervakning. Uppdatera statusen för existerande CIs om det sker några förändringar, till exempel om en komponent går sönder. Kontroll. Här ingår det kontinuerliga hanterandet och uppdaterandet av CMDB:n. Bland annat ska man registrera nya CIs, ändra ägarskap för en CI och kontrollera att man har licensrättigheter för alla installerade CIs, allt enligt beslut i Change och Release Management-processerna. Det är också viktigt att skydda CIs, till exempel genom spärrar i operativsystemet, mot otillåten förändring. Verifikation. Kontrollera att CIs verkligen används på det sätt som det sätt som det står i CMDB:n. Såväl manuella kontroller som automatiska verktyg kan användas för detta. Utred varför dessa förändringar skett! Change Management Mål 48 att möjliggöra snabb förändring med minsta möjliga påverkan på tjänstens kvalitet samt att göra förändringar spårbara Definitioner Request For Change (RFC) är ett formulär som används för att registrera detaljerna i en förfrågan om ändringar till någon eller några Configuration Items eller processer inom infrastrukturen. En RFC bör innehålla information om bland annat vilka CIs den påverkar, anledningen till förslaget, vem som föreslagit den, status (föreslagen, accepterad, avslagen, genomförd etc.) med mera. Forward Schedule of Change (FSC), ett dokument som innehåller alla planerade förändringar. Denna distribueras med fördel till användare, kunder, utvecklare, Service Desk etc. Change Management Advisory Board (CAB) är det huvudsakliga beslutande organet för Change Management. Där ska bland annat kunden, användarna, utvecklare, tekniker och servicepersonal vara representerade. Urgent changes är oplanerade förändringar som av någon anledning måste genomföras under kraftig tidspress, till exempel om en allvarlig brist i någon mjukvara dyker upp eller om en oförutsedd belastning på något system kräver en insats. Testning i den kontrollerade testmiljön är fortfarande mycket viktigt och får inte hoppas över om det alls är möjligt att hinna med itsmf, s87 49 The Stationary Office, Best Practice for Service Support, s / 72

22 Exempel på processdiagram Change initiators Change Manager Filters requests Accept Change Manager Allocates initial priority Reject Configuration Manager Initial Logging of RFC Configuration Manager Updates log Urgent? NO Change Manager Decides category and /or use of standard model YES Urgent procedures Standard Model? YES Standard model Minor Significant Major Change Manager Board Change Manager Authorises and Schedules Passes approved Circulates RFC:s to Changes. Changes to CAB for CAB members Reports to CAB actioning CAB Members Estimate impact and resources, confirm agreement to Change, confirm priority, Schedule Changes May be iterative Configuration Manager Updates log, Issues forward Schedules NO Authorised Configuration Manager Updates log YES Change Builder Builds Change, devises back-out and testing plan Configuration Manager Updates log with progress reports Independent Tester Tests Change Configuration Manager Updates log NO Test ok? YES Change Manager Coordinates implementation of change Configuration Manager Informs Users, Updates log Working NO Change Builder Back-out plans implemented YES Configuration Manager Updates log Elapsed time Change Manager Change review Success NO To start Configuration Manager Updates log, associates any new RFC with old one YES Closed Configuration Manager Closes RFC in log Figur 4: Change Management The Stationary Office, Best Practice for Service Support, s / 72

23 Exempel på processdiagram del 2: urgent procedures From regular procedures Change Manager Calls CAB or CAB/EC meeting Elapsed Time Configuration Manager Initial logging of RFC CAB or CAB/EC Quickly assesses impact resources and urgency Back to regular procedures NO Urgent Elapsed Time YES Change Builder Urgently prepares change Elapsed Time Configuration Manager Updates log progress report Time for test? NO YES Independent Test Urgent testing NO Success YES Change Manager Coordinates change implementation Elapsed Time Configuration Manager Updates log, inform Users Working NO Change Manager Back-out plans implemented YES Change Manager Ensures records are brought up-to-date Configuration Manager Updates log with all details to date. Sets documentation in order Elapsed time Change Manager Reviews changes Back to regular procedures NO Success YES Close Configuration Manager Closes RFC in log Aktiviteter Figur 5: Change Management/Urgent Procedures 51 Loggning och filtrering. RFC:n lagras och läggs in i CMDB:n. Change Managern filtrerar bort ointressanta eller upprepade förslag samt meddelar den som lämnade förslaget om detta. Kategorisering och initial prioritering. De föreslagna ändringarna fördelas i fördefinierade kategorier, utefter hur pass stor effekt förändringen skulle få, hur stora resurser som behövs initialt respektive löpande. Ändringar med liten effekt hanteras av Change Management internt, större ändringar av CAB:n och riktigt stora ändringar som kräver stora resurser eller sannolikt påverkar andra avdelningar kräver godkännande ifrån organisationens topp. Den preliminära prioriteringen avgör huruvida det är så bråttom med förändringen att man måste följa en förkortad process. Prioritering. Prioriteringen görs i samråd mellan den som rapporterat och Change Managern samt CAB:n, i de fall det anses nödvändigt. 51 The Stationary Office, Best Practice for Service Support, s / 72

24 Planering och bedömning av förändringens effekter och resurskrav. Förändringens effekter bedöms med avseende på: o business operations o Infrastrukturen och den primärt berörda tjänsten o Kapacitet, prestanda, pålitlighet och säkerhet o Eventuella andra tjänster som också kan påverkas Godkännande. För att man ska kunna besluta att genomföra en förändring så måste den uppfylla de finansiella, tekniska och affärsmässiga krav som ställs. Konstruktion. Att konstruera en förändring kan till exempel gå ut på att göra något av de följande sakerna: o skapa en ny version av någon mjukvarukomponent o köpa in utrustning eller tjänster utifrån o förbereda en hårdvarumodifikation o skapa ny eller utökad dokumentation o förbereda ny användarutbildning Testning. Här kontrolleras aspekter som prestanda, säkerhet, underhåll, support, pålitlighet, funktionalitet samt återställningsmöjligheter i fall att förändringen inte håller måttet (se Release Management). Implementation. Här genomförs förändringen i produktionsmiljön och CMDB:n uppdateras för att reflektera dessa förändringar. Utvärdera den genomförda förändringen och avsluta den. Här ingår saker som att kontrollera att förändringen hade de förväntade effekterna och att kund och användare är nöjda med förändringen. Beskrivning En mycket viktig del av arbetet i en IT-organisation går åt till att utvärdera förändringar i affärsverksamhetens effekter på IT-systemen och förändringar i IT-systemens effekter på affärsverksamheten. Att lyckas med detta minskar risken för problem vid förändringar, begränsar problemens omfattning och kan få fram positiva effekter av förändringar snabbare. Det är viktigt att notera att vare sig Incidenter eller Problem nödvändigtvis leder till en Change. Fullt definierade och godkända förändringar behandlas och loggas individuellt, men behöver inte utvärderas av Change Management varje gång de genomförs. De förändringar Det finns alltså en gräns för hur små eller rutinmässiga förändringar man väljer att behandla. Det är viktigt att alla inom kund- och IT-organisationen kan be om en Change, annars riskerar man att missa innovativa idéer och viktiga problem. Om antalet förfrågningar från användare är allt för stort kan man låta förfrågningar ifrån dem gå via deras närmaste chefer så att de kan filtrera upprepade eller irrelevanta förfrågningar utan att de måste genomgå hela processen. ITIL rekommenderar att en strukturerad projekthanteringsmetod tillämpas, men binder inte upp sig till någon särskild modell. Det finns dock en särskild modell (PRINCE2) som är anpassad för ITIL och utvecklad av OGC 52 Interaktionen mellan Change Management och projektorganisationen beskrivs i nedanstående diagram: 52 The Stationary Office, Best Practice for Service Support, s16 17 / 72

25 Registration and Classification Monitoring and Planning Approval Authorization and Implementation Change Monitoring Building Testing Evaluation (e.g Post- Implementation Review) Implementation Change Management Programme/ Project Management Figur 6: Beröringspunkter för Change Management och Project Management 53 Personer som arbetar med till exempel Incident control, operativt datorstöd och nätverkssupport kan ha fullmakt att göra förändringar för att lösa vissa typer av Incidents (om till exempel någon hårdvara slutar fungera) utan att först få godkännande ifrån Change Management. Dessa förändringar ska dock begränsas till saker som inte förändrar några CIs Release Management Mål 55 att sörja för upprätthållande av överenskommen Service Level genom kontrollerad hantering och distribution av mjuk- och hårdvara Definitioner Release, en samling auktoriserade förändringar för en IT-tjänst. Release unit, den normala nivån (systemnivå, programnivå, modulnivå etc.) som en Release görs på. Argumenten för val av olika Release unit tänker jag inte gå in på här. En Release kan implementeras på följande sätt: Full release, där alla komponenter i en release unit byggs, testas, distribueras och implementeras tillsammans. Delta release, där endast de CIs som uppdaterats distribueras. Package release, där flera Releaser, full eller delta, distribueras tillsammans. 53 The Stationary Office, Best Practice for Service Support, s The Stationary Office, Best Practice for Service Support, s The Stationary Office, Best Practice for Service Support,s / 72

26 Releases delas ofta in i tre olika slag: 56 Större uppgraderingar, som normalt innehåller mycket ny funktionalitet. En sådan release innehåller ofta alla mindre uppgraderingar Mindre uppgraderingar, som normalt innehåller små förbättringar och lagningar, av vilka en del kanske redan funnits som Emergency fixes. Emergency fixes, som normalt bara innehåller rättningar till ett litet antal kända problem. För att stödja Release Management så bör man ha ett Definitive Software Library (DSL), en plats där alla auktoriserade versioner av alla olika mjukvaru-cis lagras och skyddas. Specifikationen av en organisations DSL bör innehålla bland annat följande punkter: 57 lagringsmedium, fysisk plats, hårdvara och mjukvara som används för lagring och distribution backup och återställningsprocedur för DSL namnkonventioner för filer och fysiska media regler för vad som ska lagras i DSL (källkod, objektkod, dokumentation etc.) hur länge gamla releaser ska lagras För hårdvara har man ett så kallat Definitive Hardware Store (DHS), en säker lagringsplats för ersättningshårdvara. Där lagrar man komponenter och sammansatta system som uppdateras på samma sätt som övrig hårdvara. Dessa kan sedan användas i fall att ett tillfälligt behov av hårdvara uppstår, eller om en större Incident inträffar som gör att man behöver ersätta någon viktig hårdvara. Back-out-procedur, ett tillvägagångssätt (programmerat eller människoutfört) för att dra tillbaka en release och återupprätta funktionaliteten som fanns innan den genomfördes. Processdiagram Development Environment Controlled Test Environment Live Env. Release Policy Release Planning Design and develop, or purchase the software Build and configure the Release Fit-forpurpose testing Release Acceptance Roll-out Planning Communication Preparation and Training Distribution & installation CMDB & DSL Aktiviteter Figur 7: Release Management 58 Utveckla en policy för framtida releaser. Alla involverade i processen måste förstå sin roll och andras roller. I policyn ingår dessutom saker som hur man numrerar releaser och ungefär hur ofta man vill släppa nya releaser. 56 The Stationary Office, Best Practice for Service Support, s The Stationary Office, Best Practice for Service Support, s The Stationary Office, Best Practice for Service Support, s / 72

27 Planera releasen. Här ingår bland annat att göra en grov tidsplanering, undersöka vilken hårdvara och mjukvara som används, planera vilka resurser som kommer att behövas, samt att förhandla med leverantörer om ny hårdvara, mjukvara och/eller installationstjänster. Bygga och konfigurera releasen. I denna fas skapar man exakta instruktioner för hur releasen ska byggas, automatiserade installationsskript, testplaner och gör beställningar från leverantörer. När man är klar med det framställer man originalexemplar av installationsmedia och installationsinstruktioner för lagring i Definitive Software Library samt designar back-out-procedurer som genomförs om det visar sig att releasen inte fungerar tillräckligt bra utan måste dras tillbaka. Testa och godkänna releasen. Under detta moment testas Release-komponenter, installationsprocedurer och back-out-procedurer. Övriga utdata inkluderar huvudsakligen dokumentation av testresultat, kända problem, beredskapsplaner samt godkända och påskrivna acceptanstestsdokument. Planera utrullning. Här utökas releaseplanen med detaljer som ett exakt schema och resursplan, en lista över alla CIs som ska installeras eller tas bort med beskrivningar av hur det ska gå tillväga, information som ska kommuniceras till slutanvändare, inköpsplaner med mera. Även inköp av ytterligare hårdvara och mjukvara genomförs här. Det är viktigt att tillse att dessa lagras säkert fram till dess att de installerats. Kommunikation, förberedelse och utbildning. Nu är det dags att informera kundkontakter, kunder, användare och supportpersonal om den förestående releasen. Detta görs normalt genom träningssessioner och att övriga parter involveras i test/acceptans-fasen. Man framställer även de slutgiltiga versionerna av användardokumentation och supportinformation. Distribution & installation. Procedurer för inköp, lagring, leverans, mottagande och undangörande av varor ska finnas på plats för att garantera att utrustningen kommer fram till sin destination i gott skick. Automatiserad mjukvarudistribution, via nätverk, kan vara till stor hjälp här. Under installationen är det bra att verifiera att hårdvarukraven uppfylls, och det är också viktigt att CMDB:n uppdateras för att reflektera förändringar och eventuella upptäcka fel i den. Till slut är det också viktigt att kontrollera att slutanvändaren blev nöjd med den nya Releasen. Beskrivning Release Management ska kontrollera följande komponenter: egenutvecklad mjukvara externt utvecklad mjukvara (inklusive standardmjukvara och mjukvara utvecklad av kund) system inköpta från en underleverantör hårdvara och hårdvaruspecifikationer monteringsinstruktioner och dokumentation, inklusive användarmanualer Release management arbetar med att försäkra sig om att de back-out-planer som Change Management har utvecklat fungerar tillsammans när förändringarna kombinerats i en release. I back-out-planen ska till exempel innehålla information om huruvida mjukvara måste backas upp innan installationen av ett nytt system (i fall att installationen skulle misslyckas) och hur länge man har på sig att försöka få en release att fungera innan man måste initiera back-out-planen för att inte påverka kunden. Det bör också noteras att arbetet i Release Management påverkas mycket av hur applikationerna designas. I till exempel klient-server-applikationer finns det ett starkt beroende mellan de olika komponenterna som måste iakttas. Här kan det vara rimligt att bygga in versionskontroller som 20 / 72

28 rapporterar om någon försöker koppla upp sig med en föråldrad version som inte längre stöds på serversidan Incident Management Mål att reducera och eliminera störningar i IT-tjänsterna så fort som möjligt Definitioner En incident är en händelse som inte är del av den normala funktionen hos en tjänst och som orsakar eller kan orsaka en störning eller minskning i tjänstens kvalitet. 59 Definitionen av incidenter är väldigt bred och inkluderar inte bara fel i mjukvara och hårdvara utan även så kallade Service Requests. En Service Request är en förfrågan ifrån en användare om support, dokumentation, leverans eller något annat som inte beror på ett fel i infrastrukturen. 60 Till exempel kanske en användare glömt bort sitt lösenord och måste be om ett nytt, eller så har en användares konto blivit fullt och han/hon vill be om mer lagringsutrymme på servern. Funktionell/horisontell eskalation att tillföra specialister eller personer med större systemrättigheter för att lösa ett problem. Hierarkisk/vertikal eskalation att tillföra personer med större makt eller beslutanderätt inom organisationen. Incident Managern ska se till att det finns resurser för funktionell eskalation så att man i normala fall inte behöver göra någon hierarkisk eskalation. 59 The Stationary Office, Best Practice for Service Support, s71 60 itsmf, s43 21 / 72

29 Processdiagram 61 The Incident Management process Service request procedures Service Desk Routing Computer Operations Networking Procedures Other sources of Incident Incident enter process Resolution/ Workarounds leave process Incident Management process Incident detection and recording classification and initial support investigation and diagnosis resolution and recorery Incident closure Incident ownership, monitoring, tracking and communication Configuration details RFC Resolution Resolution/ Work-around Change Management process Problem/error database CMDB Figur 8: Incident Management Livscykeln för en incident 62 Aktiviteter Samla in och registrera Incidenter. Incidenter kan bland annat rapporteras ifrån Service Desk, automatiska övervakningssystem eller ifrån de andra processerna. Incident Management registrerar de grundläggande detaljerna kring incidenten och uppmärksammar relevanta specialistgrupper utefter behov. Om incidenten har en känd lösningsprocess hanteras den som en Service Request, och följer de steg som beskrivs för just den typen av incident. Klassificera och ge första support till användaren. o Matcha incidenter mot kända fel och problem. o Informera Problem Management om nya problem och omatchade incidenter. o Ge incidenten en prioritet. En incident ska prioriteras utefter dess urgency (den acceptabla fördröjningen för de påverkade användarna eller affärsprocesserna) och dess impact (storlek på avvikelsen från normal servicenivå i termer av antalet påverkade användare eller affärsprocesser som påverkas). o Koppla incidenten till relaterad konfigurationsinformation (CIs) o Ge första support försök hitta en snabb lösning eller work around. o Avsluta incidenten eller skicka den vidare till en specialist och informera användaren. Undersökning och diagnos. Hitta en lösning som fungerar och skicka problemet vidare till ytterligare specialister vid behov. I första hand får användaren hjälp ifrån Service 61 The Stationary Office, Best Practice for Service Support, s72 62 itsmf s49 22 / 72

30 Desk-funktionen, sedan av experter, sedan mjukvaruutvecklarna/arkitekterna och i det fall det blir nödvändigt och relevant av IT-organisationens underleverantörer. Lösning och återhämtning. Lös incidenten med hjälp av den lösning eller work around som hittats, alternativt skicka in en request for change för behandling i Change Management-processen. Avslutning. Verifiera lösningen med kund eller den som rapporterade incidenten. Ändra incidentens status till avslutad. Spåra och kommunicera incidentens status. Under hela processens gång ska incidentens status vara åtkomlig för den som rapporterat den och han eller hon ska informeras om förändringar. I fall att det tar för lång tid innan en lösning kan tas fram ska eskalering ske automatiskt. Beskrivning CMDB:n är mycket viktig för incident management eftersom den definierar relationerna mellan resurser, tjänster, användare och service levels. Till exempel visar den vem som är ansvarig för en komponent i infrastrukturen, och möjliggör därför för en enklare dirigering av incidenten. Den kan också ge information om mer praktiska detaljer, som till exempel vart utskrifter kan dirigeras om i fall att en skrivare slutar fungera. När en incident registreras så länkas den till de Configuration Items som den berör, för att på så sätt ge mer information om felet till dem som ska lösa det. Utan CMDB måste man hitta info om beroenden manuellt för Incident Management, vilket även gör det svårare och mer tidskrävande att bedöma impact och urgency för incidententen. En databas för att hålla reda på Incidents och Problems (se nedan) är nästan ett krav för att Incident och Problem Management ska fungera bra. En bra sådan kan dessutom möjliggöra för användaren att söka igenom kända fel och lösa problemet själv istället, utan att belasta Service Desk. Det är viktigt att man inte skjuter upp registreringen av incidenter, utan gör det direkt. Annars riskerar man att flera arbetar på samma incident samtidigt, och kan dessutom inte längre övervaka huruvida eventuella tidsbegränsningar för incidenthantering i SLA:n efterföljs Problem Management Mål att hitta den underliggande orsaken till Incidenter och förebygga nya sådana Beskrivning Problem Management arbetar för att upprätthålla tjänstens kvalitet. Korrekt bedriven hindrar den organisationen ifrån att fastna i den vanliga fallgropen med många snabba fixar som inte löser de underliggande problemen i infrastrukturen. 63 itsmf, s49 23 / 72

31 Processdiagram Known Errors Request for Change (RFC) Incident details from Incident Management Configuration details from CMDB Defined Workarounds Problem Management process Problem control error control the proactive prevention of Problems identifying trends obtaining management information from Problem Management data the completion of major Problem reviews Updated Problem record or closed Problem record Response from Incident matching to Problems or Known Errors Figur 9: Problem Management Management information Aktiviteter Problem Control Identifiera problem och hitta orsaken. o Identifikation och registrering. I princip ska alla incidenter med okänd orsak relateras till ett Problem, men ofta blir det för mycket jobb att göra detta om inte incidenten är allvarlig eller upprepad. o Klassifikation. Dela in problemen efter följande saker:! Kategori: Domänen för problemet; hårdvara, mjukvara etc.! Impact: Hur stor effekt problemet har för affärsverksamheten?! Urgency: Hur länge är det acceptabelt att inte lösa problemet?! Prioritet: Kombination av urgency och impact samt den risk och de resurser som krävs för att lösa problemet! Status: problem, känt fel, löst o Undersökning och diagnos. Detta är en iterativ fas där man söker problemets underliggande orsak, bland annat genom att försöka reproducera fel i en kontrollerad miljö. Det är viktigt att veta att felet inte nödvändigtvis ligger i mjuk- eller hårdvara, utan även kan vara i processer, dokumentation eller människors arbete med tjänsten. När den underliggande orsaken är känd upprättas en koppling till de CIs som bidragit till felet. Error Control Övervaka och korrigera kända fel tills de är lösta. o Identifikation av kända fel och registrering av dessa. I många fall finns redan här en så kallad work-around, som låter användaren fortsätta som vanligt tills problemet löst slutgiltigt. Annars försöker man utveckla en sådan här. o Undersök lösningar. Här utvecklar man olika förslag på lösningar och undersöker påverkan på SLA:s, kostnader och förtjänster med en lösning. o Definiera den valda lösningen. Om den bästa lösningen är motiverad att genomföra (inte tar för lång tid eller resurser relativt förtjänsten med att lösa problemet), så utformar man här en Request For Change som Change 24 / 72

32 Management kan ta ställning till. Får man avslag på denna kanske man måste börja om och hitta på en annan lösning. o Post Implementation-Review. Kontrollera att problemet löstes av förändringen, och avsluta problemet. Ofta väntar man med att ändra problemets status till löst innan alla incidenter relaterade till problemet är avslutade. Spårning och övervakning. Under hela processen ska Problem Management hålla sig informerade om vilka framsteg som görs i lösningsprocessen för olika problem, samt om något problem förvärras Service Desk Mål 64 understödja tillhandahållandet av tjänster genom att garantera att IT-organisationen är tillgänglig för användare och kunder minska arbetsbelastningen på andra processer genom att tjäna som en central första kontaktpunkt för användare och kunder vidarebefordra ärenden till rätt support-grupp inom IT-organisationen marknadsföra tjänsten, det vill säga se till att kunden är nöjd 65 Beskrivning Service Desk är en funktion (en avdelning inom en organisation), inte en process, men den är helt central för IT Service Management och utför många moment i ITIL-processerna. Jag beskriver den mer kortfattat än processerna, eftersom den inte är lika central för examensarbetet. Det finns ett antal andra namn för ungefär samma sak som en Service Desk, bland annat Call Centre, där tyngdpunkten ligger på att professionellt hantera stora mängder telefonsamtal samt Help Desk, vars huvudsyfte är att ta emot och lösa incidentärenden så fort och smidigt som möjligt. Service Desk är en vidareutveckling av dessa och inkluderar bland annat även samarbete med processerna Change, Service Level och Configuration Management. Personalen i Service Desk representerar IT-producenten mot kunden och användarna, och här är det än mer viktigt att man verkligen bryr sig om att alltid göra kunden nöjd. Aktiviteter 66 Svara på telefonsamtal och e-post. Det är Service Desk som är ansvariga för att registrera Incidents och se till att användare med problem får hjälp eller skickas vidare till rätt person. Hålla användare och kunder informerade om förestående förändringar i system, incidentstatus etc. I det fall att IT-leverantören tar extra betalt för vissa tjänster (till exempel support eller bandbreddsanvändning) är det upp till Service Desk att kommunicera detta. Sköta kontakten med leverantörer. Service Desk är ofta ansvarig för att kontakta underhållsleverantörer när de behövs. Det kan röra saker som reparation av skrivare, telefonsystem eller liknande. Operationellt datorstöd. Detta inkluderar saker som att skapa backuper, hantera diskutrymme på lokala servrar, skapa konton och dela ut lösenord. 64 itsmf s Mats Ståhl 66 itsmf s / 72

33 Övervaka infrastrukturen. Service Desk kan använda sig av verktyg för automatisk övervakning av nätverk, datorer, med mera för att upptäcka fel när de uppstår. Även andra supportenheter (expertgrupper, utvecklare, underleverantörer etc.) kan använda dessa verktyg, men det är Service Desk som är den primära användaren Övriga processer ITIL definierar även följande sex processer för IT Service Management. Dessa kommer inte att behandlas närmare, eftersom de inte är lika relevanta för examensarbetet. 67 Service Level Management förhandlar, definierar, mäter, hanterar och förbättrar ITtjänsternas kvalitet till acceptabel kostnad. Arbetar med att hitta den rätta balansen mellan kvalitet och kostnad för kunden. Capacity Management tillhandahåller IT resurser (lagringsutrymme, nätverkskapacitet etc.) vid rätt tidpunkt och till rätt pris. Förutsäger framtida behov, undersöker och försöker förstå behoven för tjänsterna man tillhandahåller Financial Management for IT Services hjälper organisationen att hantera resurserna som behövs för att tillhandahålla IT-tjänster på ett kostnadseffektivt sätt. Budgeterar utgifter, håller reda på vad som kostar samt prissätter och tar betalt för olika tjänster och tjänsteutnyttjande. Availability Management arbetar för att ge en överenskommen tillgänglighetsnivå på ett kostnadseffektivt sätt. Aktiviteter inkluderar bland annat undersökning av krav på tillgänglighet, identifiera potentiellt sårbara komponenter i system och övervakning av tillgänglighet. IT Service Continuity Management identifierar och bedömer risken för olika katastrofer (brand, jordbävning, hårdvarufel mm) som kan påverka IT-verksamheten, samt utvecklar planer för hur verksamheten ska kunna återupptas. 67 itsmf & The Stationary Office, Best Practice for Service Support 26 / 72

34 3.3.8 Överblick och indelning av processerna 68 Service Desk Incident Management Problem Management Operativ Användare Kund Change Management Configuration Management Release Management CMDB Ordning och reda Service Level Management Availability Management Continuity Management Ekonomi och kundrelationer Finance Management Capacity Management Figur 10: Överblick och indelning av processerna 3.4 Att implementera ITIL Själva införandet av ITIL-modellen i en organisation kräver en hel del eftertanke. Faktum är att ITIL ägnar en hel bok 69 åt detta ämne. Man tar bland annat upp saker som att åstadkomma och kommunicera snabba vinster med Service Management, och att involvera kunder och ledning. Eftersom det inte är relevant för examensarbetet så beskriver jag det inte närmare Mats Ståhl 69 The Stationary Office, Planning to Implement Service Management, I Best Practice for Service Support (s ) finns mer information om detta 27 / 72

35 4 Implementation 4.1 CMDB Systemet som jag utvecklat är implementerat som en normal webbapplikation med en databas bakom. Databasen är en vanlig relationsdatabas (Microsoft SQL Server 71 ), och själva gränssnittet är designat i Visual Studio.net 72 med hjälp av språket C# 73. Jag kommer här att fokusera på gränssnittet, databasen är dokumenterad i bilaga A Databasdokumentation. Viss ytterligare information om hur man faktiskt går till väga när man använder gränssnittet finns i bilaga C Användarhandledning. Användaren kan skapa och redigera CI:s samt manipulera ärenden (Incidenter, Problem, Known Errors, RFCs). De flesta händelser/ändringar är spårbara för användaren. Till exempel kan man se vem som gjort ändringar till en RFC eller en CI. Det är också enkelt att se sambanden mellan olika ärenden, till exempel vilka problem som ska lösas med en RFC eller vilka incidenter som orsakats av ett visst problem. Det går dessutom lätt att skapa ett nytt ärende som bygger vidare på det man just tittar på. Till exempel kan man titta på ett särskilt problem och därifrån skapa en RFC för att lösa detta Incident Incidenter hanteras minimalt i systemet. Det är tänkt att inrapportering av dessa ska ske i ett annat verktyg, till exempel ett helpdeskstöd. Incidenter hanteras inte alls i gränssnittet. Det enda som finns är en skärm som visar hur det skulle kunna se ut (en så kallad mock-up-skärm). 71 Microsoft SQL Server 2003, < 72 Microsoft Visual Studio.Net 2003, < 73 Microsoft Visual C#, < 28 / 72

36 Figur 11: Incidenteditor Problem / Known Errors / Personer Ifrån dessa skärmar kan man visa och redigera Problem, Known Errors respektive personer. Se bilaga C Användarhandledning för mer information. 29 / 72

37 Figur 12: Problemeditor RFCs Här kan man visa och redigera RFCs. Här kan man även ange saker som vilka CIs en RFC påverkar, samt godkänna den för genomförande. 30 / 72

38 Figur 13: Request For Change-editor Releaser Här visas RFCs som är redo att implementeras, och genomförda RFCs som kan rullas tillbaka. När en RFC genomförs så ändras dess relaterade CIs på det sätt som specificerats under CI. 31 / 72

39 Figur 14: Release-editor CIs Här kan man visa och redigera CIs, samt skapa olika beroenden mellan olika CIs. 32 / 72

40 Figur 15: Konfigurationseditor 33 / 72

41 Figur 16: Beroendeeditor SLAs Ej implementerad (mock-up-gränssnitt). I framtiden kan man tänka sig att Service Level Managern får ställa in saker som olika eskaleringstider för olika kunder här Historik När man tittar på en specifik CI/RFC/Problem så kan man även få se dess historik. Figur 17: Historik 4.2 Vidareutvecklingsförslag I ett examensarbete, eller för all del i alla projekt, har man bara en begränsad mängd tid till förfogande. Därför var jag tvungen att avsluta mitt arbete innan CMDB:n fått alla de förbättringar och tillägg som skulle kunna ha gjort den till en färdig produkt Programbeställningsverktyg En rekommendation hos ITIL är att en förändring i CMDB:n ska driva förändringen av omvärlden. Med andra ord ska till exempel en versionsuppdatering av en mjukvaru-ci i CMDB:n helst kunna utlösa programdistribution till användarna automatiskt. För detta krävs ett programdistributionsverktyg, det vill säga ett program som kan hämta en installationsfil ifrån en viss plats och installera det på en klientmaskin. 74 Om en ny eller uppdaterad CI inte ska installeras på samtliga maskiner kan det också vara viktigt för slutanvändarna att kunna beställa en installation. Denna ska sedan kunna godkännas eller avslås av respektive användares chef. En integration mellan mitt system och ett sådant verktyg vore en användbar utvidgning. Eftersom Meteorit redan hade ett sådant program så undersökte jag vad som skulle krävas för en integration med det programmet. Bilaga D Vidareutvecklingsförslag innehåller mer praktisk 74 The Stationary Office, Best Practice for Service Support, s / 72