Varför registret behövs

Nyttan blir konkret vid tre tillfällen.

När något ligger nere. Ni ser omedelbart vilka tjänster som påverkas och vilka användare som drabbas, i stället för att vara beroende av att någon minns hur systemen hänger ihop.

När något ska förändras. En planerad ändring kan riskbedömas mot faktiska beroenden i stället för mot en gissning. Det är också därför förändringshantering utan CMDB blir en formalitet snarare än en riskbedömning.

När någon frågar vad ni har. Vid revision, upphandling, försäkringsfrågor eller licensgranskning är ett aktuellt register skillnaden mellan ett svar och en veckas arbete.

Vad ska ligga i registret?

Ett konfigurationsobjekt är allt som kan förändras och påverka en tjänst. Frågan är inte vad som kan registreras utan vad som är värt att hålla aktuellt.

Ett användbart test: skulle ni behöva veta att det här finns när något går sönder klockan två på natten? Om svaret är nej hör objektet hemma i inventarieförteckningen, inte i CMDB:n.

Börja uppifrån: definiera tjänsterna verksamheten faktiskt använder, och arbeta nedåt mot vad de är beroende av. Det omvända – att börja med att inventera all hårdvara – ger en lång lista utan sammanhang.

Beroenden är hela poängen

En lista över servrar är en inventering. Det som gör en CMDB värd arbetet är kopplingarna mellan objekten.

Tre relationer bär det mesta av värdet: vad en tjänst körs på, vad den är beroende av för att fungera, och vilka användare eller kunder som påverkas om den slutar svara.

Med de tre på plats kan ni både bedöma risk före en förändring och svänga snabbt vid en störning. Utan dem har ni ett kalkylblad med fler kolumner.

Den vanligaste fällan

De flesta CMDB-projekt havererar av samma skäl: ambitionen att dokumentera allt.

Ett register som försöker beskriva varje komponent i detalj blir aldrig färdigt, och då slutar man lita på det. Ett register som inte går att lita på används inte, och då föråldras det snabbare.

Börja med de tjänster som får verksamheten att stanna om de slutar fungera. Utöka när det finns ett konkret behov.

Håll det levande automatiskt

Det som avgör om en CMDB överlever är inte hur den byggs, utan hur den underhålls.

Koppla den till övervakningsverktyget, katalogtjänsten och dokumentationssystemet så att grunddata uppdateras av sig själv. Det som kräver manuell inmatning kommer att bli inaktuellt – frågan är bara hur snabbt.

Automatisk upptäckt löser dock bara halva problemet. Verktygen hittar vad som finns, men inte vad det används till eller vem som är beroende av det. Den delen kräver ett beslut från en människa, och det är därför registret behöver en ägare även när inmatningen är automatiserad.

Livscykeln

Tillgångshantering följer utrustningen från inköp till avveckling: inventering, garantitider, licensförnyelser och avveckling med dokumenterad radering av data.

Det sista steget är det som oftast glöms, och det som blir dyrast när det glöms. En avvecklad server som ligger kvar i registret ger falsk trygghet; en som avvecklats utan dokumenterad radering ger ett problem vid nästa revision.

Förnyelsedatum är den andra posten som brukar smälla. Licenser och supportavtal som förnyas automatiskt för system ingen använder längre är en återkommande och helt onödig kostnad.

Två tal som säger om det fungerar

Hur stor andel av era förändringar kan riskbedömas mot registret? Är svaret lågt används inte CMDB:n i praktiken, oavsett hur komplett den ser ut.

Hur ofta stämmer den vid stickprov? Kontrollera tio slumpvis valda objekt per kvartal. Det tar en halvtimme och ger ett ärligare svar än någon rapport.

För MSP:er

Med många kundmiljöer förändras kraven. Registret måste hålla isär kunder, klara att samma leverantörsprodukt ser olika ut hos olika kunder, och kunna svara på vilka kunder som påverkas när en gemensam tjänst ligger nere.

Grunddatan bör hämtas från PSA och RMM, som redan vet vilka kunder och enheter som finns. Att bygga upp registret manuellt per kund är ett arbete som aldrig blir färdigt.