• Hur ska man införa en CMDB, i teorin?

    4 Juni 2019
  • 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:

    Primära relationer innefattar objekt som:

    • Tekniska beroenden: Fysiska beroenden (uppströms och nedströms) mellan en sak och en annan.
    • Logiska beroenden: Processer, system, applikationer och tjänster
    • Prestanda: nivåer av tillgänglighet och mottaglighet
    • Människor: nuvarande ägare och användare

     

    Sekundära relationer kan anses att i hög grad vara missvisande. Detta eftersom relationerna är minst lika avgörande för verksamheten som de primära relationerna. Dock anses sekundära relationer emellertid vara av mindre betydelse än de primära relationerna. Sekundära relationer omfattar:

    • Plats: där CI hittats, där det varit och vart det ännu inte varit
    • Komponenter: saker saken består av
    • Avtal: vilka villkor som gäller för det specifika CI
    • Organisationer: tillverkare, leverantör, ansvarig mm.

     

    Vid tillfällen är det värdefullt att skapa en karta över relationer för att hitta saker som är indirekt kopplade till ett CI. En sådan relation möjliggör en mer avancerad analys av komplexa problem som verkar ha ett linjärt eller direkt samband mellan bidragande faktorer. Indirekta relationer används för att bestämma förstådda relationer men utan att åda sig förvaltningen för att definiera eller underhålla direktlänkar. Relationer som anses som indirekta:

    • Avdelning/team: grupper med personer som har anknytning till det som tillhör dem
    • Kostnadsställe: Finansiella kontokoder som har kopplingar till plats, avdelningar eller affärsenheter.

    Det finns många olika delar att ta hänsyn till vid ett införande. Ta vara på de rekommendationer som böckerna säger, och anpassa arbete efter förutsättningarna som finns hos just ert företag.

    I nästa inlägg går vi igenom vilka svårigheter som man kan vänta sig vid ett införande. Vill ni läsa mer till dess, hittar ni fullständig uppsats inom ämnet här.

  • Skribent

    Som IT-ansvarig på Basalt ansvarar Linn för att skapa de rätta förutsättningarna för en god IT-miljö. Hon är operativt involverad och driver IT-utvecklingen framåt samt är personalansvarig för medarbetarna vid IT-avdelningen. Linn är MCP inom Office 365 och tar externa konsultuppdrag vid behov.