Hoe zet je in de praktijk een goed CMDB op? door Peter Leijdsman,

Hoe zet je in de praktijk een goed CMDB op? door Peter Leijdsman, www.cloudregisseurs.nl

Inleiding Bij veel organisaties is het beeld hetzelfde als je kijkt naar het aanwezige Configuratie Managementproces en de CMDB in het bijzonder. Afhankelijk van de omvang van de organisatie vind je een IT Service Managementtool (ITSM-tool) die voornamelijk gebruikt wordt voor het registreren van incidenten en wijzigingen en als het meezit vind je nog een stuk voorraadbeheer van de meest relevante uitgegeven ICT-middelen als laptops en telefoons. Is er geen ITSM-tool aanwezig dan kom je al snel terecht in spreadsheetmanagement waar iedere afdeling een eigen CMDB(tje) bijhoudt waardoor informatie gefragmenteerd door de hele organisatie aanwezig is. Vaak zijn dit eenvoudige overzichtjes van de spullenboel die men beheert en waarvan niemand echt weet of het volledig en juist is. Configuratie Management is een onderschat proces dat vaak wordt gezien als een administratieve last waarvan de bewerkers vaak niet weten met welk doel gegevens worden vastgelegd of bijgehouden. Hoe komt het toch dat dit proces bij zo veel organisaties het onder geschoven kindje is terwijl een goed ingerichte CMDB van grote waarde kan zijn voor het leveren van managementinformatie voor de ICT-afdeling én de business. Dit artikel gaat in op de voordelen van een goed ingerichte CMDB en laat zien hoe je een waardevolle CMDB kunt realiseren. Hoe zorg je dat je bij de start van de inrichting over een goede set data beschikt, met welke zaken moet je rekening houden bij het ontwerpen van een CMDB, welke beheerprocessen zijn nodig om de CMDB op het gewenste niveau te houden en hoe zorg je dat de medewerkers die de CI’s bewerken dit goed blijven registreren. Dit laatste is misschien wel de belangrijkste succesfactor bij Configuratie Management. Immers een CMDB die niet juist, volledig, tijdig of accuraat is wordt al snel niet meer serieus genomen.

1. De theorie Voor begripsvorming eerst even wat theorie. Voor dit artikel wordt uitgegaan van het ITIL-proces Service Asset and Configuratie Management (SACM). Het proces dat verantwoordelijk is om te zorgen dat bedrijfsmiddelen die nodig zijn om diensten te leveren op een adequate wijze worden beheerd en dat accurate en betrouwbare informatie over die bedrijfsmiddelen beschikbaar is wanneer en waar dat nodig is. Het doel van dit proces is het identificeren, registreren, verifiëren en bewaken van de status (lifecycle) van de componenten van de ICT-infrastructuur, oftewel de Configuratie Items (CI’s). Deze CI’s worden opgeslagen in de Configuratie Management Database, de CMDB. Configuratie Management ondersteunt andere ITIL-beheerprocessen door deze te voorzien van accurate gegevens. Informatievoorziening is dus de primaire taak. Het Change Managementproces is verantwoordelijk voor het doorvoeren van mutaties in de CMDB. Aan iedere mutatie in de CMDB moet in RFC ten grondslag liggen.

Hoe zet je in de praktijk een goed CMDB op?

Pagina: 1 van 10

2. Waarom een CMDB? De CMDB is essentieel voor iedere beheerorganisatie. Het bevat de gehele administratie van de ICTinfrastructuur die beheerd wordt middels het Configuratie Managementproces en van waaruit de andere ITIL-processeninformatie halen. De informatiebehoefte bepaalt in grote mate de structuur van de CMDB, denk hierbij aan de mate van detaillering, relaties e.d. Hierover later meer. De kracht van een goede CMDB ligt dus in het feit dat deze de andere processen van accurate informatie kan voorzien. Zodra de informatie minder accuraat wordt is dit een doodsteek voor het gebruik van de CMDB. Als het vertrouwen in kwaliteit van de CMDB afneemt zullen beheerders al snel overgaan tot het maken van een eigen CMDB. Welke oorzaken liggen hieraan ten grondslag? De voornaamste redenen hiervoor zijn: - Een te brede scope van de CMDB met een te diep detailleringniveau. - Er zijn te veel relaties tussen CI’s aangebracht waardoor er een enorme complexiteit ontstaat. Vergeet niet dat iedere relatie beheerd en onderhouden moet worden. - Het ontbreken van een goed Change Managementproces. - Toegankelijkheid en gebruiksgemak. De beheerder van CI-data moet te veel handelingen uitvoeren om CI-data te kunnen benaderen en te bewerken. - Het is niet duidelijk met welk doel CI-data moet worden ingevoerd of bijgehouden. Houd bij het ontwerpen en implementeren van een CMDB deze valkuilen dus goed in het achterhoofd. Naast het “weten wat je hebt” en een goede informatievoorziening voor de andere ITIL-processen is een CMDB ook van nut bij een aantal andere zaken. 2.1 Stuurinformatie De CMDB kan waardevolle informatie opleveren. Niet alleen informatie op basis waarvan de ICTmanager kan sturen en beslissingen kan maken. Door het combineren en koppelen van verschillende databronnen kan ook de business worden voorzien van waardvolle informatie. Denk aan het koppelen van financiële bronnen waarmee de business inzicht krijgt in wat ze afneemt en waarvoor ze betaald. 2.2 Audit Ook zie je steeds vaker dat organisaties, met name bij de rijksoverheid en financiële instellingen, vanuit weten regelgeving of opgelegde normenkaders als COBIT of ISO27001 verplicht zijn tot het nemen van allerlei maatregelen die laten zien dat men ‘in control’ is over de eigen ICTinfrastructuur. Tijdens een audit moet men dan kunnen aantonen dat geïnstalleerde programmatuur, configuraties en documentatie worden bijgehouden in een configuratiedatabase. 2.3 Impactbepaling Zijn CI’s onderling op een juiste manier met elkaar gerelateerd dan kan een CMDB ook worden gebruikt voor impactanalyses die binnen het Change- en Incident managementproces worden uitgevoerd. Hetzelfde geldt voor Continuity Management, een goede CI-structuur laat precies zien hoe je de uitwijk moet inregelen. Hoe zet je in de praktijk een goed CMDB op?

Pagina: 2 van 10

2.4 Outsourcing Wil een ICT-outsourcingproject succesvol zijn, dan hebben zowel de leverancier als de uitbestedende organisatie, naast de project doelstellingen, een nauwkeurig inzicht nodig van de project scope. In veel gevallen ontstaan hier problemen door het ontbreken van accurate informatie over de huidige inventaris van de ICT-omgeving en andere essentiële informatie waaronder lifecycle status. Accurate CMDB’s zijn in dat geval nuttig voor beide partijen. Onzichtbare problemen Het gebrek aan niet accurate informatie over de huidige ICT omgeving kan flinke gevolgen hebben als blijkt dat er 10% meer desktop PC’s aanwezig zijn, als niet duidelijk is welke software op welke server draait en hoeveel licenties er zijn aangeschaft. Ook komt het bij uitbestedingen voor dat er “ineens” een aantal servers met applicaties boven water komen die al tijden niet meer in gebruik zijn maar waar nog wel veel geld aan uitgegeven wordt voor de hardware, beheer en licenties e.d. Transparate factuur Een goed ingerichte CMDB kan ook helpen bij het transparant maken van de maandelijkse facturen. Dit geldt zowel voor ICT-dienstverlening die is uitbesteed als voor dienstverlening waarbij de interne ICT-afdeling financiële verantwoording moet afleggen aan de eigen business. De afnemer wil graag weten waar ze voor betaalt! Bij uitbestede dienstverlening zie je dat sommige organisaties lang niet altijd goed weten waar ze precies voor betalen. In de meeste gevallen ligt de oorzaak daarvan in het feit dat men ook het beheer van de CMDB naar de leverancier heeft overgedragen waarmee de hele inventaris uit het oog is verloren. Hier is een goede regieorganisatie van belang die zorgt voor duidelijke afspraken m.b.t. het verkrijgen van een up-to-date CMDB, en het organiseren van reguliere audits ter controle van de kwaliteit. Een kwalitatief goede CMDB zorgt dan dus voor: -

Een duidelijk relatie tussen de ICT-infrastructuur en de overeengekomen servicelevels opdat niet wordt betaald voor onbedoelde zaken. Dat er niet te veel CI’s in de CMDB staan. Met name als er op CI-niveau wordt gefactureerd moet er vanuit de opdrachtgever goed worden gestuurd op het verwijderen van CI’s uit de CMDB. Overigens kan het tegenovergestelde ook problemen geven als niet alles in de CMDB staat. Bij het analyseren van incidenten of bij het beoordelen van wijzigingsverzoeken kan veel tijd verloren gaan aan het zoeken naar bepaalde CI’s.

3. Hoe tot een goed ontwerp komen? 3.1 Bepalen van de informatiebehoefte De eerste vraag die je moet stellen is: aan welke informatiebehoefte moet worden voldaan? Om deze vraag te beantwoorden is het goed te starten met een onderzoek naar de informatiebehoefte waarbij onderscheid wordt gemaakt op operationeel, tactisch en strategisch niveau. Wie heeft welke informatie nodig, met welke frequentie en hoe zwaar weegt deze informatie voor de betreffende persoon of afdeling. Deze behoefte zal voor iedere stakeholder anders zijn. Als dit eenmaal goed in beeld is heb je een goed vertrekpunt voor het ontwerpen van een CMDB.


Pagina: 3 van 10

3.2 Uitgangspunten definiëren Vervolgens kan worden begonnen met het verzamelen van allerlei uitgangspunten zoals: - Welke generieke en specifieke ICT-diensten zijn er? Deze moeten in principe overeenkomen met de diensten uit de Producten en Diensten Catalogus (PDC). - Inventariseer welke business functies of processen straks ondersteund moeten worden. - Zorg voor glasheldere definities zodat iedereen weet wat er bedoeld wordt; Wat is een applicatie? Wat is een hybride applicatie? Wat is middleware? Wat een server, fysiek, virtueel? Heb je dit duidelijk, dan voorkomt het een hoop spraakverwarring en discussie. - Leg zoveel mogelijk ontwerpprincipes vast. Bijvoorbeeld, iedere CI heeft één beheerder, wat is een CI? - Indien een bestaande CMDB beschikbaar is, maak een tekening van de huidige structuur (gelaagd) plus de bijbehorende relaties. Dit is je AS-IS situatie en helpt bij de vertaling en het bepalen van de impact naar de TO-BE situatie. - Het Change Managementproces is leidend. 3.3 Metamodel Een belangrijk onderdeel bij het ontwerpen van de CMDB is de realisatie van het metamodel, oftewel de blauwdruk van de CMDB. Het metamodel beschrijft de infrastructuur- en servicecomponenten en hun onderlinge relaties. Het metamodel blijft de praatplaat voor, tijdens en na een CMDB-implementatie. Het bereik van de CMDB geeft aan welke CI-groepen worden vastgelegd. ITIL kent de volgende typen: hardware, software, communicatiemiddelen, procedures en documentatie. Vervolgens kan binnen een CI-groep het bereik worden verfijnd naar categorie en subcategorie. Keuzes die hier gemaakt worden hebben dus impact op de informatievoorziening, wat er niet in gaat, kan er ook niet uitkomen! Hetzelfde geldt ook voor het detailleringniveau van CI’s. Hierbij gaat het om CI-attributen en relaties tussen CI’s. Attributen beschrijven specifieke kenmerken van een CI zoals: merk, type en serienummer, datum in gebruik, status informatie, locatie gegevens, relatie informatie, financiële informatie etc. Belangrijk uitgangspunt bij het gebruik van attributen: leg alleen die zaken vast die je nodig hebt, ieder attribuut moet beheerd en onderhouden worden. 3.4 Service en infrastructuur configuratie De hiervoor genoemde CI-structuur is met name interessant voor de ICT-afdeling omdat dit vragen beantwoord als: wat hebben we allemaal, waar staat het, wat voor status heeft het? Nu kun je boven deze laag, die voornamelijk technische CI’s bevat, een laag aanbrengen van CI’s die diensten (services) of bedrijfsprocessen definiëren. Deze diensten zouden één op één overeen kunnen komen met diensten die worden aangeboden in de PDC en dus ook een directie relatie met SLA’s hebben. Afhankelijk van de informatiebehoefte kan het ook interessant zijn om een CI-relatie met een bedrijfsproces te leggen. Voorbeeld. Je kunt een Service CI definiëren die betrekking heeft op een primair businessproces en waarvan de klant wil weten wat ze qua ICT-middelen precies afneemt en dus voor betaald. Om dat zichtbaar te maken zou je de structuur dus als volgt kunnen vastleggen:


Pagina: 4 van 10

In dit voorbeeld zou het businessproces de afdeling Inkoop kunnen zijn, de business service de maatwerkapplicatie, waarna de technische componenten als servers, databases, operating systems en dergelijke volgen. Een generieke IT-service kan bijvoorbeeld e-mail zijn. Het metamodel borgt dat bij het muteren van de CMDB-structuur alle vereiste relaties consistent blijven. Je zou, zoals eerder gezegd, bij iedere discussie over de CMDB het metamodel als praatplaat op tafel moeten hebben. Ontwerpen van een metamodel kan, afhankelijk van de omvang van de omgeving, een complex proces zijn. De juiste bemensing is bij een dergelijk traject van groot belang. Zorg voor pragmatische mensen die diep de techniek in kunnen en op het juiste moment ook zaken weer op een bepaald niveau kunnen terugbrengen. Techneuten bekijken het vanuit een zeer technisch perspectief en kunnen het moeilijk terugbrengen tot een niveau waar je als niettechneut iets mee kunt. En de niet-techneut ontbreekt het aan kennis van applicaties met al haar relaties. Een goed mix is dus noodzakelijk. 3.5 Lifecycle Een CI lifecylce beschrijft de verschillende stadia in het “leven” van een Configuratie Item. Een CI kent een technische en een functionele status die door een bewerker kan worden aangepast. Het status attribuut van een CI laat zien waar, in welke fase van de lifecycle, een CI zich bevindt. Een technische status kan bijvoorbeeld ‘productie’, ‘verwijderd’, ‘test’, ‘in reparatie’, ‘in bestelling’ of ‘vermist’ zijn.


Pagina: 5 van 10

Een functionele status kan bijvoorbeeld ‘ontwikkel ‘, ‘test’ of ‘productie’ zijn. Het bijhouden van deze status informatie is dus essentieel voor het maken van kwalitatief goede rapportages. Bij het definiëren van de statussen is het dus belangrijk te weten wie je van welke informatiebehoefte gaat voorzien. 3.6 Databronnen In de meeste gevallen zal de CMDB uit één enkele database bestaan. Nu is dit zeker niet strikt noodzakelijk. Wel is er maar één master CMDB met daarin de unieke CI-kern data. Maar vanuit deze master CMDB kunnen meerdere satelliet databases via gelinkte detailinformatie worden benaderd. Dit heet CMDB-federatie. Federatie is een methode waarmee op een enkelvoudige manier toegang wordt verkregen tot data in meerdere verschillende locaties. Federatie laat gebruikers data zoeken en gebruiken zonder dat ze kennis hebben van waar deze data zich bevindt of middels welke technologie ze de data benaderen. Vanuit ITIL gezien vormt de CMDB de centrale (enkelvoudige) plek voor het opslaan van CIgegevens. Maar ITIL zegt niets over hoe die data benaderd of georganiseerd moet worden. De kern data is in dit geval opgeslagen in de CMDB, gerelateerde detailinformatie zijn in een andere database opgeslagen. Vanuit de CMDB is deze data gelinkt en dus benaderbaar voor gebruikers. 3.7 Vertaling naar tool Als het metamodel eenmaal gereed is kan het getest worden binnen een IT Service Management tool (ITSM-tool). Doel hiervan is aan te tonen dat het ontworpen metamodel de gewenste informatie oplevert. Kies voor deze Proof of Concept een applicatie die groot is en de nodige complexiteit qua relaties en structuur kent. Voer de betreffende applicatie volgens het metamodel ontwerp in de CMDB en test of de gevraagde informatiebehoefte gerealiseerd kan worden. Beschrijf goed op welk moment complexiteit in het model wordt geïntroduceerd. En leg vast welke consequenties dit heeft voor het beheer en onderhoud. Een enkele relatie of detaillering kan al een onbeheer(s)bare complexiteit introduceren. Het moet later wel werkbaar blijven voor de beheerders. Zodra een aantal applicaties zijn ingevoerd zullen ook de consequenties van het gekozen model duidelijk worden. Zorg dat deze helder zijn, met name over wie je gaat teleurstellen! Communiceer hier duidelijk en tijdig over.

4. CMDB audit Om te weten waar je nu staat, en om aan te tonen welke verbeteringen de implementatie straks heeft opgeleverd is het noodzakelijk om bij de start en na de voltooiing van een implementatietraject een CMDB-audit uit te voeren. Met het resultaat van de audit, ook wel nulmeting genoemd, heb je de huidige (AS-IS) situatie in kaart gebracht. Door de analyse van de informatiebehoefte hier tegenaan te leggen weet je waar de aandachtspunten liggen en dus wat de TO-BE moet zijn.


Pagina: 6 van 10

Het organiseren en uitvoeren van CMDB-audits is, afhankelijk van de omvang van de organisatie, niet altijd even gemakkelijk en kost veel tijd en resources. Goede voorbereiding is hierbij absoluut noodzakelijk. Bepaal eerst wat “de werkelijkheid” is van hetgeen je gaat auditen. Iedere beheergroep heeft zijn eigen verantwoordelijkheid binnen de CMDB en de structuur is opgezet vanuit de behoefte van hun eigen aandachtsgebied, bijvoorbeeld serverbeheer. Beheerders die hier de administratie bijhouden geven de server een (logische) virtuele naam, de zaalbeheerder die de hardware beheerd zou de fysieke server dus moeten labelen met dezelfde naam. In de praktijk zie je dat, vooral binnen gevirtualiseerde omgevingen, de serverbeheerder een vrijgekomen virtuele server een nieuwe naam geeft zonder de zaalbeheerder hiervan op de hoogte te brengen. Dit kan voor vervelende problemen zorgen. Andersom kan het ook gebeuren dat bij een storing een fysieke server wordt vervangen zonder dat de fysieke naam wordt aangepast. Wat is nu de werkelijkheid? Hetzelfde kan gebeuren met databases die gerelateerd zijn met een database-server. Ook hier zijn twee aparte beheergroepen die CI-data onderhouden met attributen die naar elkaar verwijzen. Bij het voorbereiden van een audit is het dus belangrijk om weten welke brongegevens je gaat gebruiken en naar welke resultaten je straks aan het kijken bent. Het auditproces bestaat globaal uit de volgende stappen:

Procesbeschrijving De Configuratie Management procesbeschrijving bevat alle noodzakelijk uitgangspunten en randvoorwaarden voor het auditproces.

Voorbereiding In de voorbereiding van een CMDB-audit moet worden bepaald ‘wat’ wordt gecontroleerd en ‘hoe’ er wordt gecontroleerd, door ‘wie’ en ‘wanneer’. 1. Moment bepalen Stel een auditmoment vast, bepaal de scope en claim tijd en resources. 2. Bepalen brongegevens De CMDB-audit is gebaseerd op het vergelijken van de informatie. Door middel van de brongegevens wordt per CI aangegeven welke informatie aangeleverd moet worden om de relaties, attributen en statussen van het CI op juistheid te kunnen controleren.


Pagina: 7 van 10

Mogelijke brongegevens zijn: fysieke controle, informatie uit beheerapplicaties en informatie vanuit een leverancier. Per CI zijn meerdere brongegevens mogelijk. 3. Audit opdracht Een CMDB-audit wordt door de configuratie manager geïnitieerd, en uitgevoerd in overleg met het management. Uitvoering De uitvoering van de CMDB-audit bestaat uit het maken van een CMDB-snapshot en het verwerken van de aangeleverde brongegevens. Het resultaat is een verschillenlijst die inzicht geeft in de betrouwbaarheid van de informatie uit de CMDB. 4. Maken CMDB snapshot Op een vooraf bepaald moment wordt een snapshot van de CMDB(s) gemaakt. Dit vormt de ‘digitale’ werkelijkheid voor de audit. 5. Vergelijk de snapshot met de fysieke werkelijkheid Vergelijk de digitale werkelijkheid met de fysieke werkelijkheid. Leg de verschillen vast in een verschillenlijst. 6. Samenstellen verschillenlijst Na aanlevering van de gegevens wordt een verschillenlijst samengesteld. Verwerking De verschillenlijst kan resulteren in nader onderzoek naar ontstane afwijkingen en proces verbetervoorstellen om de betrouwbaarheid van de CMDB-informatie te verbeteren. Na onderzoek van deze lijst zullen de noodzakelijke mutaties moeten worden doorgevoerd in de CMDB zodat deze weer de juiste werkelijkheid weergeeft. 7. Verschillenlijst onderzoeken en CMDB updaten Onderzoek waarom, of wat de oorzaak is, van de verschillen. In overleg met Configuratie Manager zal een change worden aangemaakt om de CMDB up-to-date te maken. 8. Evaluatie De Configuratie Manager evalueert de audit en stelt vast of voorstellen nodig zijn voor het verbeteren van het Configuratie Managementproces. 9. Audit rapportage Eindresultaat van de audit is een audit rapportage met daarin, een verslag, conclusies en aanbevelingen. Succesfactor Bij audits kunnen flink wat mensen worden betrokken vanuit de organisatie. Zorg dat men de audit doelstellingen heel duidelijk op het netvlies heeft staat voordat ze van start gaan.

5. Beheer en onderhoud Het ontwerpen en implementeren van een CMDB is één, het beheer en onderhoud ervan is het volgende. Hoe zorg je dat de kwaliteit van de CMDB op het gewenste niveau blijft? Dat is uiteindelijk waar het om gaat. Veel implementaties mislukken door de het ontbreken, of niet consequent uitvoeren van, het Configuratie Managementproces. Hoe zet je in de praktijk een goed CMDB op?

Pagina: 8 van 10

De Configuratie Manager moet, net als bij andere beheerprocessen, de aanjager zijn en blijven. Naast de noodzakelijke discipline kunnen allerlei (bij voorkeur geautomatiseerde) controlemechanismen ervoor zorgen dat de Configuratie Manager snel inzicht in de kwaliteit van de CMDB krijgt. Die snelheid is essentieel. De aanwezigheid is gewenst van controleprocedures en middelen als scripts, snelle rapportages, Excel-exports of een quick view binnen de ITSM-tool waarmee binnen een paar muisklikken inzicht kan worden verkregen in de kwaliteit en waarmee de verantwoordelijke bewerker direct aangesproken kan worden in geval van omissies. Voor de bewerkers moet het volstrekt duidelijk zijn waarom ze een CMDB-activiteit moeten uitvoeren en met welk doel dat gebeurt. In de praktijk zie je dat beheerders gegevens invullen die totaal geen doel hebben, of men kent het doel niet. Een presentatie waar alle beheerpartijen bij aanwezig zijn doet wonderen. Laat ze het totaalplaatje zien, leg de samenhang uit en met welke doel men CMDB-activiteiten uitvoert. Het wordt natuurlijk helemaal krachtig als aangetoond kan worden dat dit doel direct waarde toevoegt aan een businessproces van de organisatie. Een goede mindset is het halve werk. Daarnaast dient het bewerken van een CI zo laagdrempelig als mogelijk te zijn. Ook hier speelt de ITSM-tool een belangrijke rol. Het Change Managementproces is leidend, en van daaruit dient de bewerker getriggerd te worden om een CI te bewerken. Zorg hierbij dat de tool het proces op een adequate wijze ondersteunt en dat de beschreven proceswerkwijze zoveel mogelijk afgedwongen wordt.

6. Resumé Het ontwerpen en implementeren van een CMDB met bijbehorende beheerprocessen is geen sinecure. Een projectmatige aanpak en voldoende steun op managementniveau is noodzakelijk voor een succesvolle implementatie. Zorg eerst dat de informatiebehoefte glashelder is, dit zorgt voor de juiste focus. Start vervolgens met een CMDB-audit om de huidige situatie duidelijk te krijgen. Bij een migratie moet je zeker weten dat de bestaande data accuraat is: garbage in, garbage out. Als data inaccuraat is, wordt de CMDB als snel niet meer vertrouwd en dus niet meer gebruikt. Zorg vervolgens voor een team met de juiste disciplines en ga van daaruit het ontwerpproces in. Het metamodel vormt de blauwdruk van je CMDB. Afhankelijk van de omvang van de ICTinfrastructuur kan hier veel tijd in gaan zitten, maar het levert ook een hoop op. Omarm het motto: keep it simple! Verzand niet in het ontwerpen van een metamodel dat alles afdekt en iedereen blij kan maken. Dat is een utopie. Zorg voor een top down aanpak waarbij de focus is gericht op de belangrijkste informatiebehoefte. Het kan voorkomen dat bij het bepalen van het metamodel het doel uit het oog wordt verloren door eindeloze discussies. Complexiteit van het applicatie landschap is vaak de grootste oorzaak. In zo’n geval kan het helpen om de zaken om te draaien door een einddoel vast te stellen. Dat kan bijvoorbeeld zijn, een ‘goede’ klantrapportage. Als je weet wat je daarin wilt zien kan je het ontwerp daarop afstemmen. Vereenvoudig het ontwerp in dat geval dusdanig dat er nog wel zo veel mogelijk overeind blijft maar dat het wel voorziet in de belangrijkste informatiebehoefte van de klant.


Pagina: 9 van 10

Als in een Proof of Concept omgeving het metamodel aantoont dat het de gewenste informatiebehoefte oplevert kan de CMDB worden gevuld met data en eventueel worden gelinkt aan andere databronnen. Een ITSM-tool met voldoende integratiemogelijkheden is hierbij essentieel. Omdat handmatig toevoegen van data de nodige risico’s kent is het aan te raden data zoveel als mogelijk geautomatiseerd in de CMDB te krijgen. Om te zorgen dat na een implementatietraject de CMDB de gewenste kwaliteit behoudt, breekt dan de belangrijkste fase aan; het continu beheerproces rondom de CMDB. Belangrijke succesfactoren zijn hier; ervoor te zorgen dat de Configuratie Manager over voldoende mechanismen beschikt waarmee snel inzicht kan worden verkregen over juistheid, volledigheid, tijdigheid en accuraatheid van ingevoerde CI-gegevens. Voor de CI-bewerkers geldt dat men goed moet weten waarom en waartoe men CI-gegevens invoert en dat dit zo makkelijk mogelijk gedaan moet kunnen worden.


Pagina: 10 van 10

Hoe zet je in de praktijk een goed CMDB op? door Peter Leijdsman,

Recommend Documents