Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

A fool with a tool is just a fool

 

Computable Expert

Marco Gianotten
Managing Director, Giarte Media Group. Expert van Computable voor het topic Outsourcing.

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.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/4813796). © Jaarbeurs IT Media.

?


Lees meer over


 

Reacties

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.

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.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×