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.
Ik begrijp de discussie niet zo, sterker, ik wil hem niet eens begrijpen. Reden daarvoor, hoezeer ik het ook met de reflectanten eens ben op punten, is dat een CMDB ALTIJD leading dient te zijn.
De reden daarvoor is eenvoudig. Als je namelijk geen ‘single point of reference’ hebt, hoe kun je dan verwachten op welke wijze je billing toe past, wat de depreciation is van al je componenten, je infrastructuur? Hoe wil je plannen zonder een geactualiseerde CMDB?
Sec en simpel gesteld is dit namelijk één van de paradoxen in IT. Velen roepen dat je een CMDB nodig hebt, tegelijkertijd word daar weinig prio aan toegekend. Mij zal het persoonlijk ‘Wurst Kraut Sahne’zijn. Ik hoef namelijk de kosten en verliezen door het slecht funtioneren of ontbreken van die CMDB niet op te hoesten.
Wat dat betreft blijft de discussie wel actueel. Het maakt mij niet uit welk naampje aan dit beestje je op wil hangen. Het niet leading maken van dit onderwerp in ’the enterprise’, kost de enterprise heel veel centjes.
Zaten we nou allemaal niet in een materie die geld moet opleveren door besparen? Nou dan.
@KJ Ik schrijf :” Bij verschillen kan dan actie worden ondernomen om het een (lees de werkelijkheid) of het ander (lees de CMDB) aan te passen en het proces of de boosdoener aan te pakken.
De periodiek vergelijking moet automatisch en vaak gebeuren bijvoorbeeld 1x per dag of een keer per week. Op verschillen moet dan direct actie worden ondernomen.
Maak je de werkelijkheid leading dan ben je dus als organsatie en IT-afdeling verantwoordelijk voor het in de lucht houden van alles wat maar naar binnenkomt.
Simpel voorbeeld: Iemand koop een Apple op afdelingsbudget en sluit hem aan op het netwerk van het bedrijf. Nu is deze onderdeel van de werkelijkheid en moet de IT-afdeling hem beheren, onderhouden en eventueel vervangen.
Overtrokken voorbeeld: Ik koop een WIFI router op batterijen. Deze gooi ik door de ruit naar binnen bij een organisatie. Mijn wifi router is nu onderdeel van de werkelijkheid. M.a.w. de IT-organisatie moet deze aasluiten , configureren en beheren. Nee, waarom niet is hij illigaal? Hoe weet je dat?
@IT-architect & NumoQuest
FYI : sommige CMDB’s hebben honderdduizenden items. Het consistent houden daarvan is extreem duur en in sommige gevallen gewoonweg onmogelijk.
Wees daarom pragmatisch en concentreer je dan ook alleen op het bijhouden van die CI’s waarbij het kosteneffectief en mogelijk is.
En dat bijhouden hoeft niet perse in een CMDB te gebeuren.
De voorbeelden die jij aandraagt houden geen steek: het onduidelijke motief weegt niet op tegen het risico van ontslag vanwege knoeien met de ICT infra.
@KJ
Blijkbaar ben je wel bereid om iemand te ontslaan die zelf wat aansluit terwijl het niet bij zijn functie hoort (en wellicht niet beter weet) maar niet iemand die dat doet uit hoofde van zijn functie maar zijn werk niet behoorlijk uitvoert. (en beter behoord te weten)
Als het om de kosten gaat het is pas duur als niets doen goedkoper is.
Excel kan in sommige gevallen een prima oplossing zijn voor een CMDB.
Zoals ik al eerder schreef assetmanagement hoort niet in een CMDB al is een koppeling wel aan te raden in de meeste gevallen.
@IT-architect
Als het gaat om de kosten is het pas duur als de maatregelen die je moet nemen meer kosten dan de kosten zelf.
Ik ben het met je eens dat assetmanagement iets anders is dan een CMDB, maar dat is weer iets anders. Mijn stelling is dat de CMDB bij grotere bedrijven en organisaties gewoonweg niet te onderhouden is en vrijwel altijd inconsistent is. Of dat al dan niet terecht is doe ik geen uitspraak over. Ik stel vast dat de meeste bedrijven er pragmatisch mee omgaan.