Du vet redan varför en CMDB behövs. Du har förmodligen läst om konceptet, kanske sett en demo, och tagit beslutet att det är rätt väg framåt.
Nu kommer nästa fråga – den som de flesta guider hoppar över: var börjar du egentligen?
En konfigurationsdatabas kan i teorin innehålla allt. I praktiken är det den egenskapen som gör att CMDB-projekt fastnar i fas 1 och aldrig levererar värde. Den här artikeln handlar om hur du undviker det.
Börja smalt
Ett vanligt misstaget är att försöka fånga allt på en gång. Servrar, laptops, mobiltelefoner, mjukvarulicenser, nätverksutrustning, tjänster, avtal – det är lätt att modellera en perfekt framtidsvision och sedan inse att du har halvt gjort arbete i tio kategorier.
En CMDB som innehåller 70 % av era laptops och 60 % av era servrar är inte en halv CMDB. Det är en opålitlig CMDB. Och en opålitlig CMDB är värre än ingen alls, för den skapar falsk trygghet i beslutsfattandet.
Strategin som fungerar: välj ut tre till fyra CI-typer och gör dem kompletta. Typiska startpunkter:
- Servrar (fysiska och virtuella) – ofta redan delvis dokumenterade, hög nyttoeffekt för incident och change
- Klientdatorer – direkt koppling till onboarding/offboarding-flöden och behörighetshantering
- Affärskritiska applikationer – skapar grunden för servicekartläggning
- Nätverksutrustning – om ni har pågående övervakningsbehov
Börja där det gör som mest ont. Inte där modellen är som renast.
Relationsmodellen – det som de flesta underskattar
Om CI-listan är skelettet i en CMDB, är relationsmodellen hjärtat. Det är i relationerna – vad som är beroende av vad – som verkliga insikter uppstår.
Frågan ”vilka system påverkas om den här servern går ner?” kan bara besvaras om du modellerat relationen mellan servern och de applikationer som körs på den. Utan relationer är din CMDB en avancerad hårdvarulista.
Tre relationstyper att prioritera tidigt:
Kör på / Hostat av
Applikationer på servrar, virtuella maskiner på fysiska hosts. Ger omedelbar nytta vid incident och planerat underhåll.
Ägs av / Tilldelad till
Kopplar utrustning till person och avdelning. Grunden för offboarding-automatisering.
Beroende av
Tjänst X är beroende av databas Y, som körs på server Z. Det här är den mest kraftfulla men också mest tidskrävande relationstypen. Bygg den iterativt.
För varje CI-typ du lägger till, definiera minst en relation till något du redan har i databasen. Isolerade CI:er utan kopplingar tillför lite.
Vanliga fallgropar i fas 1
Manuell datainmatning som primär metod
Om din plan är att låta IT-personal manuellt mata in all utrustning väntar er ett projekt som aldrig blir klart. Koppla mot befintliga källor så tidigt som möjligt: Active Directory, Entra, övervakningsverktyg osv. Det behöver inte vara perfekt, det ska vara utgångspunkten som sedan valideras.
För mycket klassificering från start
Trettio CI-typer, tjugo statusvärden och femton prioritetsnivåer låter noggrant. I praktiken leder det till att ingen fyller i fälten korrekt och att data snabbt degraderar. Börja med få fält och lägg till fler när ni faktiskt saknar dem.
CMDB utan ägare
En konfigurationsdatabas kräver löpande underhåll. Utrustning byts ut, applikationer avvecklas, folk slutar. Utan en utnämnd roll/person, eller process, som ansvarar för att hålla databasen aktuell sjunker datakvaliteten inom månader. Bestäm ägarskapet innan ni börjar fylla i data.
Att vänta på en perfekt plan
En CMDB med 80 % täckning och hög datakvalitet är exponentiellt mer värdefull än en perfekt spec som aldrig implementerats. Sätt ett datum för en liten men komplett fas 1, leverera den, och bygg vidare.
Vem äger CMDB och vad innebär det i praktiken?
Dataägande i en CMDB är ett organisatoriskt beslut, inte ett tekniskt. Frågorna att besvara:
- Vem är ansvarig för att en CI registreras när ny utrustning köps in?
- Vem uppdaterar status när en server avvecklas?
- Vem granskar datakvaliteten – och hur ofta?
- Vad händer när en CI ägs av en avdelning som inte har IT-kompetens?
I mindre organisationer är svaret ofta ”IT-avdelningen ansvarar för allt”. Det fungerar i fas 1, men skalar dåligt. En mer hållbar modell: IT äger strukturen och CI-typerna, men enskilda avdelningar ansvarar för att hålla sina objekt uppdaterade med IT som granskare.
Så gör Easit GO CMDB till ett projekt din organisation kan äga
En av de vanligaste anledningarna till att CMDB-projekt fastnar är att systemet kräver konsultstöd för varje förändring. Vill du lägga till en ny CI-typ? Ringa leverantören. Vill du ändra ett fält? Ny konfigurationsorder.
Easit GO är byggt för att din organisation ska kunna äga och vidareutveckla CMDB-strukturen internt. Det innebär att IT-koordinatorer och systemansvariga kan:
- Definiera och anpassa CI-typer och attribut
- Bygga relationsmodeller och visualisera beroenden
- Koppla CMDB mot ärendehantering så att ett incident-ärende automatiskt visar berörda CI:er
- Integrera mot AD, Entra och övervakningsverktyg för automatisk populering
Det minskar projektkostnaden i fas 1 och, viktigare, det gör att CMDB faktiskt lever kvar och förbättras efter implementationen.
Vill du se hur en CMDB-implementation kan se ut för just din organisation? Boka en demo
Läs mer
Vad är CMDB – hur du kommer igång och varför det är viktigt
En introduktion till CMDB-konceptet för dig som vill förstå grunderna innan implementationen.
Easit GO – funktioner och kapabiliteter
En genomgång av hela plattformen – ärendehantering, CMDB, självbetjäning och automation.
Kundcase: Sydnärke – från beslut till driftsatt på drygt två månader
Hur Sydnärkes IT-förvaltning implementerade Easit GO och vad det gav dem i praktiken.
E-guider
Fördjupande guider om ITSM, konfigurationshantering och digitalisering av IT-förvaltning.
Henrik Resare
Commercial Product Manager
henrik.resare@easit.com
+46 70 249 36 06