Herinnert u zich nog de beloftes van ‘IT for IT’ medio vorig decennium? Na erp en crm voor de business waren nu it-organisaties eindelijk zelf aan de beurt om hun eigen processen te automatiseren. Is dat een daverend succes geweest? Wanneer bedrijven hun erp net zo zouden hebben ingericht als it-organisaties hun eigen itsm-tooling, zouden de meeste bedrijven allang failliet zijn. De herkansing voor ‘ERP for IT’ is begonnen.
Tool fools. Cio’s hebben fors geïnvesteerd in IT Service Management tooling. Maar functioneert it als corporate function nu ook beter? Misschien wel, maar vaak zijn implementaties half geslaagd. Hoeveel cmdb’s zijn correct gevuld, compleet en actueel? Veel te weinig! ServiceNow speelt met ‘itsm uit de cloud’ handig in op de latente aversie van veel cio’s tegen de suites van oude marktleiders als HP, CA en IBM. Het is echter naïef om te denken dat de belofte van ‘IT for IT’ nu plotseling wel uitkomt. Nog steeds wordt te veel gedacht in tooling als silver bullet. Neem de cmdb als de gegevensverzameling van alle configuration items die tezamen een it-dienst vormen. Klopt die voor het managen van een complexe applicatieportfolio?
Even een testje. Staan de antwoorden op de volgende vragen op de eigen cmdb? Wie is de eigenaar van een applicatie? En hoeveel gebruikers heeft die applicatie? In welke mate is de applicatie missiekritisch voor de business? En binnen welke businessketen? Welke licentieverplichtingen zijn er? Nog voor hoe lang? Wie zijn de mensen met inhoudelijke kennis over de applicatie? Waar werken die? Is er een datum wanneer de applicatie buiten gebruik wordt gesteld? Wie deze vragen niet goed kan beantwoorden heeft de cmdb waarschijnlijk afgetankt met technische data, zoals gegevens over software en hardware. Zonder managementinformatie kun je echter geen goede besluiten nemen over rationalisatie en consolidatie. Dan ben je een ‘fool with a tool’.
Succes zit in de basishouding. Het gebruik van itsm tooling zegt iets over de cultuur binnen een it-organisatie. Is die insight-out met tool-lovers? Of outside-in en gericht op de business? Een herstart voor ‘IT for IT’ begint met heel simpele dingen als het uniformeren van definities en processen in de incidentketens. Een voorbeeld: niet elke call naar een servicedesk is een uniek incident, gebruikers kunnen namelijk ook bellen over een eerder aangemeld incident. Het incident is dan een child en de initiële call is de parent. Wanneer je niet duidelijk maakt dat een call iets anders is dan een incident, worden de rapportages over kritische incidenten onnauwkeurig: het aantal kritische incidenten is veel te hoog. Eenduidig vastleggen en uitwisselen zorgt ervoor dat er ook een goed datamodel is voor rapportages en analyses. One version of the truth!
Herkansing. Het ownership voor ‘IT for IT 2.0’ moet bij de cio liggen. Dat begint met de tooling, datamodellen en automatische gegevensuitwisseling voor ketens waar meerdere partijen actief moeten samenwerken bij changes en calamiteiten. Of met rationalisatie van kernapplicaties waarover je directe zeggenschap hebt als cio, zoals over communicatie, collaboration en hr, finance en compliance. Dan bewijs je dat je klaar bent voor het grotere werk: rationalisatie van de honderden of zelfs duizenden applicaties in het hart van de business.
T.a.v. het testje: Je gooit Configurationmanagement en Assetmanagent op een hoop. Maar ik ben met je eens dat de informatie wel voorhanden moet zijn in een systeem.
Ja ja, met de beentjes vast op de grond blijven was altijd al een goede raad.
Ik moest lachen bij “even een testje”, wie die zaken niet op orde heeft hoort niet in dit vak.
Ik vraag me af dat werkelijk voorkomt, dat ICT management die vragen niet beantwoord hebben, kan het me moeilijk voorstellen.
Een ieder die werkelijk wat jaren het beheer van ICT heeft uitgevoerd in een grote of middelgrote organisatie weet dat de CMDB een utopie is. Vragen als: wat is de granulariteit van de objecten (welk niveau moet worden gemodelleerd), wat zijn precies de relaties tussen de componenten en hoe moet je deze modelleren, hoe wordt de CMDB initieel gevuld en wie gaat dat dan vervolgens bijhouden en betalen ? Wie waarborgt de consistentie en betaalt voor de noodzakelijke periodieke inventarisaties ? De werkelijkheid blijkt (ook hier) weerbastiger dan de ITIL theorie.
Lees eens over de werkelijkheid : http://www.itskeptic.org/itil-cmdb-skeptic
Marco,
Aangaande CMDB’s – repositories is hier een betere naam – heb ik hier al eens wat over geschreven in ‘Release of relatie management’ en de knelpunten op de verschillende lagen wat verder uitgewerkt in een presentatie:
http://www.slideshare.net/edekkinga/building-a-service-knowledge-dashboard
In de praktijk gebruiken managers trouwens vooral Excel om zonodig de werkelijkheid aan te passen aan de gewenste antwoorden. Dus klachten over geen up-to-date informatie of met technische data afgetankte CMDB’s zijn niet terecht. En even voor de duidelijkheid, handmatig een CMDB bijhouden gaat dus niet door de snelheid van wijzigingen en virtualisaties.
Rationalisatie en consolidatie is ook een jarenlange wens van IT maar dan moeten er wel eerst een paar onteigeningen van stokpaardjes plaats vinden. Er is dus nog één vraag die ik mis: “Wat is de waarde, het rendement van investeringen?”
KJ: Ik snap het punt van de schrijver van het artikel, maar zoals ook al in de commentaar staat: Wat is het alternatief? Niets doen en vastleggen?
Het mooiste artikel waarin ik zeer veel herken is dit:
PJ : If skeptic means someone who only sees problems, not solutions, then I would agree, you are definitely a skeptic. There are so many of you working in large organisations that it is a wonder that anything gets done at all!
En dan het antwoord van Rob England (The IT Skeptic) de schrijver van het artikel:
If IT technical means gung-ho naive disregard for the practical, financial and business implications of idealised technical solutions to non-technical problems, then you are definitely a tech.
There are so many of you working in large organisations that it is a wonder that any are still in business.
On Topic: Ik wilde weerstand voelen tegen dit Computable artikel, maar uiteindelijk vind ik het wel aardig.
Henri: ja dat antwoord had ik ook gezien, idd. Rob England draait al lang mee, is uitstekend op de hoogte van ITIL en de laatste ontwikkelingen daarin en laat zich niet zomaar in de hoek zetten.
De CMDB wordt meestal als onderdeel van een standaard pakket meegeleverd en vanwege de niet strikt afgedwongen consistentie (we willen allemaal wel kunnen werken met die nieuwe change tool) treedt er na verloop vervuiling op. Een klein voorbeeld, een CI wordt verhuisd naar een andere lokatie, maar de change-indiener weet de code van de nieuwe lokatie niet en de tool ondersteunt geen lookup lijstjes, waardoor de nieuwe lokatie niet wordt ingevuld in de change. Na verloop van tijd is de CMDB dermate vervuild dat hij onbruikbaar is geworden.
Gegevens die echt noodzakelijk zijn voor operaties en/of business moeten dan ook uit de werkelijkheid gehaald worden en niet uit een kopie ervan.
Herkenbaar verhaal..
De valkuil die ik keer op keer terug zie komen is dat organisaties de neiging hebben hun processen aan te passen, doordat tooling ergens niet mee overweg kan. Onzin natuurlijk. Tooling dient aan te sluiten op aanwezige, bewezen processen. Dit betekent vaak echter veel, en kostbaar, meerwerk, waardoor onderaan de streep vaak halfbakken oplossingen neergezet worden.
KJ: Als je bedoeld dat je in plaats van een CMDB bij te houden de gegevens uit de werkelijkheid haald dan ben ik het niet met je eens.
De werkelijkheid zou wel eens zo kunnen zijn als ze niet zou moeten zijn. Dus iemand heeft iets neergezet, aangesloten en of geconfigureerd waar geen toestemming voor is, niet conform richtlijnen/standaarden en of niet conform design.
Wat m.i. wel een goed idee is om de CMDB regelmatig en automatisch te vergelijken met de werkelijkheid. Bij verschillen kan dan actie worden ondernomen om het een of het ander aan te passen en het proces of de boosdoener aan te pakken.
JN: Lijkt me geen goed idee om de CMDB leading te maken teneinde de werkelijkheid te gaan aanpassen, vanwege de inherente inconsistentie ervan (zie mijn eerdere voorbeeld).
Gezien de omvang en hoeveelheid items in sommige CMDB’s is periodieke inventarisatie geen haalbare kaart vanwege de kosten die daarmee zijn gemoeid.
Als je wilt weten hoe de werkelijkheid eruit ziet, moet je de data niet uit een inconsistent model van die werkelijkheid halen, maar uit de werkelijkheid zelf, via beheertooling, scripts etc.
Een CMDB leading maken is vandaag de dag steeds lastiger.
In een hiërarchische netwerkstructuur waar alles gedefinieerd moet zijn wil het überhaupt werken kun je dit nog wel afdwingen.
Maar, met BYOS, BYOD, flexplekken, mensen die zelf hardware verhuizen omdat dit hun handiger uitkomt etc. zal het helaas bij een nobel streven blijven.