Fem tecken på att er CMDB-data börjar degradera och vad ni gör åt det

Blogginlägg

En CMDB sjunker inte ihop dramatiskt. Den degraderar långsamt, tyst och ofta utan att någon märker det tills någon behöver lita på den i ett skarpt läge och inser att informationen inte stämmer.

Det är inte ett tekniskt problem. Det är ett underhållsproblem. Och det börjar vanligtvis med ett av dessa fem tecken.

Tecken 1

CI:er utan ägare

Öppna ett slumpmässigt urval av era konfigurationsobjekt och titta på ägarfältet. Hur många är tomma, pekar på en person som slutat, eller visar en avdelning som inte längre finns?

En CI utan ägare är en CI ingen ansvarar för att hålla aktuell. Den registrerades kanske av IT under implementationen men när servern uppgraderades, mjukvaran byttes ut eller utrustningen avvecklades uppdaterades inte databasen, för det var ingen specifik persons ansvar att göra det.

Vad ni gör åt det: Koppla ägarskapet till processer, inte till individer. Det ska finnas ett definierat ansvar för varje CI-typ. Bygg gärna en automatisk notifiering när en CI-ägare slutar eller byter roll.

Tecken 2

Fält som konsekvent lämnas tomma

Om ett fält är tomt i 60 % av alla poster är det antingen ett tecken på att fältet inte tillför värde eller att det är för krångligt att fylla i.

Båda är problem. Det första innebär att ni samlar data ni aldrig använder, vilket skapar brus. Det andra innebär att ni saknar data ni faktiskt behöver, men att systemet är utformat på ett sätt som motverkar korrekt registrering.

Vad ni gör åt det: Gör en fältgranskning. För varje fält: används det faktiskt i rapporter, automatiseringar eller sökningar? Om inte, ta bort det eller dölj det. Om fältet är viktigt men tomt, undersök varför. Är det ett utbildningsproblem, ett gränssnittsproblem, eller saknas en integration som skulle kunna fylla i det automatiskt?

Tecken 3

Relationer som inte stämmer med verkligheten

En CMDB utan relationer är en avancerad hårdvarulista. Men relationer är också det som degraderar snabbast.

Applikationen som ”körs på” en server som avvecklades för ett år sedan. Licensen som fortfarande är kopplad till en användare som slutade. Tjänsten som är beroende av en databas som migrerats till molnet men där den gamla relationen aldrig togs bort.

Felaktiga relationer är värre än inga relationer, för de ger en falsk bild av beroenden. Det kan leda till felaktiga beslut vid incidenter, planerade ändringar och riskbedömningar.

Vad ni gör åt det: Gör regelbundet en relationsrevision för era mest kritiska CI-typerna. Koppla relationsuppdateringar till era change-processer: varje gång en förändring genomförs ska de berörda relationerna granskas.

Tecken 4

Ingen automatisk synkronisering mot verkliga källor

Om er CMDB primärt uppdateras manuellt är det bara en tidsfråga innan den halkar efter verkligheten.

Servrar tillkommer och avvecklas. Licenser löper ut och förnyas. Användare onboardas och offboardas. Om dessa processer inte är kopplade mot CMDB:n – via Active Directory, Entra, övervakningsverktyg eller andra auktoritativa källsystem är er databas alltid en bild av hur det såg ut förut.

Vad ni gör åt det: Identifiera era fem mest föränderliga CI-typer. Finns det ett källsystem som håller ”sanningen” för dessa? Om ja: integrera. Om nej: definiera vem som ansvarar för att uppdatera dem och hur ofta. Manuell uppdatering kan fungera för CI-typer med låg volatilitet men kräver tydligt ägarskap och rutin.

Tecken 5

Ingen vet längre vad som är ”sant”

Det subtilaste och allvarligaste tecknet: IT-teamet slutar använda CMDB:n som referens och börjar lita på informella listor, mejltrådar och ”det vet Kalle”.

Det händer inte med en gång. Det sker gradvis, när tilliten till databasen urholkas av för många tillfällen då informationen inte stämde. Till slut är CMDB:n ett system som är igång men som ingen litar på, vilket är nästan exakt lika användbart som ingen CMDB alls.

Vad ni gör åt det: Mät förtroendet, inte bara täckningen. Fråga IT-teamet: ”Skulle du lita på CMDB:n om du behövde fatta ett beslut om den här servern nu?” Om svaret är nej börja inte med att fylla i fler fält. Börja med att förstå varför tilliten försvann och åtgärda grundorsaken.

Vad är ett rimligt underhållsintervall?

Det finns inget universellt svar, men en enkel tumregel:

Ofta förändrade CI-typer (användare, klientdatorer, mjukvarulicenser): Automatisk synk eller manuell genomgång varje kvartal
Måttligt förändrade CI-typer (servrar, applikationer, nätverksutrustning): Halvårsvis granskning kopplad till change-processen
Sällan förändrade CI-typer (infrastrukturkategorier, tjänstekatalog): Årsvis granskning

Det viktigaste är inte frekvensen i sig utan det är att underhållet är inbyggt i en process, inte beroende av att någon kommer ihåg det.

Hur Easit GO hjälper er att hålla CMDB:n levande

En av de vanligaste anledningarna till att CMDB-data degraderar är att det är för mycket friktion för att uppdatera den. Systemet känns krångligt, ingen har rättigheter eller känslan av ägarskap, och uppdateringar skjuts upp tills ”det finns tid”.

Easit GO är utformat för att minska den friktionen:

Automatisk populering via GO Connect mot Active Directory, Entra och övervakningsverktyg gör att CI:er skapas och uppdateras utan manuell inmatning
Rollbaserade vyer innebär att varje person ser och kan uppdatera de CI:er som faktiskt är deras ansvar
Kopplade processer innebär att ett incident-ärende automatiskt visar berörda CI:er och att en change triggar en påminnelse om att uppdatera relationerna
Konfigurationsbara attribut gör det enkelt att justera vilka fält som finns för varje CI-typ, utan konsultstöd så ni kan ta bort det som inte används och lägga till det ni faktiskt behöver

En CMDB håller sig inte levande av sig självt. Men med rätt systemstöd och rätt process kan underhållet bli en del av det dagliga arbetet och inte en kvartalsvis städinsats.

Vill du se hur CMDB-underhåll kan se ut i Easit GO för just er organisation? Boka en demo

Läs mer

CMDB i praktiken: vad behöver din organisation faktiskt ha koll på?
Praktisk guide till att avgränsa och komma igång med CMDB i fas 1 – inklusive hur man väljer CI-typer och definierar relationer.

Easit GO – funktioner och kapabiliteter
En genomgång av hela plattformen – ärendehantering, CMDB, självbetjäning och automation.

Hur snabbt kan din organisation vara självgående i Easit GO?
Guide till rollerna och tidslinjerna som tar er från implementation till intern kontroll.

E-guider
Fördjupande guider om ITSM, konfigurationshantering och digitalisering av IT-förvaltning.