Hur införde vi på Basalt CMDB?

Nu är det dags att gå in på hur vi införde CMDB hos oss på Basalt. För att kunna få mätbara effekter genomförde vi en enkät innan införandet och en enkät efter. Den första enkäten som genomfördes handlade om att få driftteknikernas syn på hur arbetssituationen var innan CMDB infördes.

Respondenterna förväntade sig att en CMDB skulle ge en bättre överblick över de komponenter som utgjorde den interna IT-miljön. De ville kunna härleda och avhjälpa problem på ett bättre sätt. Respondenterna var överens om att en CMDB skulle hjälpa till att visa de samband som fanns mellan olika tjänster och hårdvara. Samtidigt fanns det förväntningar på att en CMDB skulle hjälpa till på att ett bättre sätt härleda problem och avhjälpa dem. Det fanns även förväntningar att en CMDB skulle underlätta i licenshanteringen, på att sådant vis att det skulle bli lättare att se vilka de vanligaste relationerna var samt vilka licenser som oftast användes. En av de tillfrågade visste inte riktigt vad CMDB skulle tillföra.

Planering av ITIL

ITIL (2015) nämner planering av CMDB som en av nyckelaktiviteterna kring införandet. Planeringen skedde genom att skapa ett projekt i Manage Engine Servicedesk Plus. Projektplanering genomfördes i samråd med en kollega för att inte glömma några viktiga delar. Fyra viktiga milstolpar identifierades med tillhörande uppgifter. Alla uppgifter beskrevs och tidsuppskattades. Beskrivningen skulle vara så pass tydlig att vem som helst skulle kunna genomföra uppgiften. Projektplanen hade tydliga riktlinjer, mål och syfte med CMDB fanns. Utifrån vad ITIL säger, är dessa de viktigaste områdena att täcka.

För att en CMDB ska innehålla vettig information gäller det att tänka till när det är dags att definiera CI typer. På företaget finns det många CI som ska finnas med i CMDB, men för att undvika att någon viktig del glöms bort identifierades några övergripande typer som gav en överblick över alla delar som skulle finnas med i CMDB. Det är svårt vid införandet att anpassa en CMDB som passar alla detaljnivåer i ett företag, för att öka chansen att täcka så mycket som möjligt att en CI-typ skapats. På Basalt valde vi att dela in detta i sex olika CI-typer.

• Den första CI-typen är Business Process. Genom att ta med affärsprocesserna så presenteras affärsnyttan med IT-systemet och företaget skaffar sig en helhetsbild, istället för att se IT-systemet som endast en del av företaget.
• Den andra CI-typen är Services, som innehåller alla tjänster som människor, både personal och kunder, kan tänkas använda. Exempel två tjänster som används mycket inom företaget är t.ex. mail, versionshantering och dokumenthantering.
• Den tredje CI-typen är Applications. Varje Service tillhandahålls av en eller flera applications dvs programvaror och liknande.
• Den fjärde CI-typen är Virtual Infrastructure. I detta lager finner företaget den virtualiserade miljön.
• Den femte CI-typen är Physical Infrastructure och den innefattar den utrustningen som faktiskt går att ta på.
• Den sjätte CI-typen är Fixed Infrastructure som ska innehålla den utrustning som håller allt på plats. Det kan vara t.ex. rack och lokaler.

Som nivå och tillhörande exempel beskriver, se nedanstående bild, är nivå 1 den som anses som mest kritisk då den påverkar hela företaget. Exempel på CI har nivå 1 är servrar, mail och intranät. Lönehantering hamnar under nivå 2 eftersom det är en tjänst som endast påverkar administration om den inte skulle fungera. Många CI hamnar under nivå 1 eller 2. Självklart kan det endast vara en enstaka person som har problem med en VM, så graderingen av denna är beroende från gång till gång. Skulle en VM sluta fungera för t.ex. alla på utveckling skulle det bli nivå 1. Att VMs fungerar på företaget är en viktig del, därav placeras den under nivå 1.

Vi beslutade att ha vår CMDB på engelska, och började därefter att definiera relationer. Manage Engine ServiceDesk Plus hade sedan innan exempel på relationer som normalt sett användes i en CMDB. Dessa sparades, för att sedan lägga till de relationer som ansågs saknas. De relationer som lades till var beroende av de CI-typer som lagts till.

CI-relationernas gruppering

Relationerna har grupperats utifrån primära-, sekundära- och indirekta relationer som nämnts i teorin. Exempel på primära relationer är t.ex. logiska beroenden som finns mellan CI-typerna Services och Applications. Men även beroende till människor utifrån vem som är systemägare för tjänsten. Tekniska beroenden finns i högsta grad, en virtuell server finns alltid i ett kluster. För att visa hela kedjan för intranätet och tillhörande relationer, finns de i tekniska- och logiska nivåer samt människor (vem som är systemägare).

Sekundära relationer finns även med, men är till vis del missvisande. Exempel på sekundära relationer är plats, komponenter, avtal och organisationer. Här passar det lagret Fixed Infrastructure in ganska väl, i och med den bland annat innehåller CI-typen Room.

Indirekta relationer finns i t.ex. process beskriver vilka affärsprocesser som ar relationer till olika tjänster. Dessa affärsprocesser visar indirekt vilka avdelningar som finns på företaget.

Efter att relationer var bestämda var det dags att populera med CI. Populeringen bestod till mesta del av att skriva in alla CI och tillhörande relationer. Det identifierades attribut som var unika för varje CI-typ. Under tiden populeringen med CI utfördes definierades ett fåtal nya relationer som ansågs saknas. Detta var för de CI-typer som inte fanns med i verktyget ServiceDesk Plus innan populeringen påbörjades. Det fanns inga relationer definierade för t.ex. business process så dessa fick definieras manuellt.

Hur ser det ut för användaren?

ServiceDesk Plus som användes till att populera CI gjorde det lättare att se en överblick över alla relationer som finns mellan olika CI. Nedanstående bild visar hur det kan se ut om användaren väljer att visa många relationer. En ordentlig överblick där de utropstecken som visas betyder att den aktuella CI har antingen en request, ett problem eller en change kopplat till sig. Nedanstående bild visar även hur CI och dess relationer ser ut i verktyget ServiceDesk Plus. Utropstecken visar vilka CI som har aktuella request, problem eller change kopplat till sig.

Om användaren väljer att zooma in en specifik CI är det möjligt att få en mer läsbar vy. Figur 4 visar vilka de närmsta relationerna en drifttekniker har. Bilden visar bland annat att driftteknikern Linn Leneklint är responsible for Portalen. Portalen har en request och ett problem kopplat till sig.

Väljer man att titta närmare på informationen kring Portalen är det möjligt att få en bättre översikt av vad som finns kopplat till den. Det går även att se mer information kring respektive ärende som finns kopplat. Informationen kring varje CI kan vara väldigt innehållsrik. Det finns attribut som är särskilda för olika CI-typer. Detta kan anpassas till den individuella CI-typen om så önskas.

Efter införandet genomfördes ytterligare en enkät, för att se hur driftteknikerna uppfattade införandet och efterföljande effekter. Detta går vi in mer på i nästa avsnitt. Vill du läsa mer fram till dess kan du läsa här.

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.