Det kan anses som svårt att införa en CMDB i en organisation. Hur beskriver teorin att man på bästa sätt ska bedriva införandet?
En av de svårigheter man kan stöta på vid införandet är att det kan upplevas som svårt att bygga ett system som ska fungera på alla detaljnivåer i organisationen. Det är inte heller alltid organisationens egna processer stämmer överens med processerna som ITIL arbetat fram. Processerna kan påverka hur CMDB ska komma att fungera. För att kunna använda en CMDB korrekt, krävs det kunskap om ITIL. Detta gäller inte enbart beslutsfattare, utan även slutanvändare kan ha nytta av att förstå processflödet.
Det bästa sättet att införa en CMDB att förenkla processen, hålla sig till grunderna och hitta detaljerna för CI. Med andra ord är meningen att definiera djupet för de kategorier som ska upptäckas och behållas i och med CMDB. Man ska komma ihåg att utveckla en egen CMDB inte är någon lätt uppgift. Även om man använder verktyg som automatiskt hittar korrekt CI att använda i CMDB så tar det lång tid. Teorin beskriver att man bör räkna i år snarare än månader när det gäller ett införande, och det är ett ständigt pågående arbete.
Införandet av en CMDB bör enligt ITIL ske i fem steg; planering, identifiering, kontroll, övervakning samt till sist verifiering. Planeringen syftar på att förstå och definiera syfte, mål, riktlinjer och rutiner som anses lämpliga och nödvändiga inom ramen för organisationen. Identifiering av konfigurationsmodell, tillgångar och CI. CI ska identifieras utifrån dess attribut, tillhörande dokumentation och relationer till andra objekt och register. Unika identitetsbeteckningar ska etableras för CI, dokumentation, och mallar för t.ex. bibliotek. Kontrollen riktar in sig på de metoder som används för att styra varje CI. Med att styra syftar ITIL på att skapa, bygga, installera, flytta, lägga till och ändra ett objekt. Övervakning är steg nummer fyra. Övervakningen ska innehålla både aktuell och historisk information om CI och dess livscykel. Sista steget är att regelbundet kontrollera och verifiera CI uppgifter i databasen mot vad som finns i den verkliga världen.
Teorin menar på att den primära förutsättningen för att lyckas med CMDB är att glömma vad böckerna säger och använda sunt förnuft. Det är viktigt att processerna genomförs vid rätt tidpunkt, detta för att alla inblandade parter ska vara mogna. Nästa steg är att bestämma vad som ska finnas i CMDB. Det gäller att ha gränser för vilken information som ska finnas tillgänglig där. En CMDB bör innehålla:
- IT-objekt som är affärskritiska
- Hur objekten är relaterade till varandra
- Hur relationerna påverkar organisationen
Låt oss ta ett exempel: Hummer som arméfordon. Fordonet infördes för att konsumenterna skulle kunna njuta av upplevelsen, på samma sätt kan en CMDB falla i samma väg. Den kan anpassas och utvidgas för att senare hantera all daglig IT-infrastruktur. Nästa steg är att ange relationer mellan CI. Precis som relationer mellan människor, kan relationerna mellan CI vara komplicerade. Det är viktigt att veta vad som körs på varje maskin, vilka relationer som finns samt vilken påverkan det blir om ett CI är nere eller inte går att nå. Detta ska CMDB hjälpa till med.
Det är ofta skrämmande att se över den verkliga omfattningen av uppgiften, för att upprätthålla ett fullständigt och korrekt register över alla de IT-tillgångar som finns inom verksamheten. Av denna anledning är det därför många verksamheter som beslutar sig för att initialt fokusera på en specifik delmängd av alla tillgångar.
För att veta vilka objekt som ska ingå kan man ta hjälp av tre kriterier:
- Kategorisering – begränsar övervakningsverksamheten till CI inom ett specifikt tillgångsområde.
- Kostnadströsklar – spårning av CI som är över ett visst ekonomiskt värde.
- Riskbaserad – spåra CI som har en viktig roll inom tillhandahållande av tjänster och support.
Även om man använder de ovanstående kriterierna för att identifiera CI i en inledande fas, finns det inget som säger att organisationen måste skapa ett register över varje del av IT-utrustningen. Begreppet ”avsevärd” används flitigt inom finansvärlden för att definiera relevanta nivåer där objekt inte längre är betydliga för den övergripande finansiella delen för företaget. Detta kan vara bra att ha i bakhuvudet även när det kommer till identifiering av CI.
Detaljnivåer för CI varierar mellan organisationer, men en gemensam nämnare som finns är att de ofta är indelade hierarkiskt. Enligt teorin kan organisationer välja att detaljerat gå in på varje skruv som finns i en dator, men detta skapar samtidigt en större mängd extraarbete. Företaget bör alltid väga arbetsinsatsen mot affärsnyttan för att lägga sig på en realistisk nivå. Det är inte lönt att gå längre med detaljerna än att de ger stöd för andra processer samtidigt som företagen bör undvika CI som inte kan flyttas, förändras eller kopieras enskilt. CI som är kritiska för tjänster som används, är viktigt att ha lite extra kontroll på.
Viktig information att ha med kring CI menar ITIL går att dela upp i tre områden:
- Tekniska detaljer – data som beskriver CI kapacitet, innehåller programversion, modellnummer, hårdvara och tillverkarens specifikationer. Andra tekniska detaljer som nätverkshastighet och storlek för datalagring anses också värdefullt. Tillbehör som kablage, möss, tangentbord etc. betraktas som förbrukningsvaror.
- Ägare – ägarhistorik, inköpsdatum, garanti, plats och ansvarig person för CI. Identifieringsnummer som streckkoder, typ, mjukvara, hårdvara och dokumentation räknas även det som ägarattribut.
- Relationer – Relationer mellan hårdvarukomponenter, mjukvara och användare. T.ex. en dator som används av Kalle har programvaran Office installerad.
Relationer kan man se på utifrån tre grupperingar:
