Beheersoftware wordt vaak verkeerd gebruikt

In mijn vorige post berichtte ik over de vraag die de redactie van de Computable had gesteld over het in de papieren editie te publiceren artikel over beheersoftware. Op 15 januari 2010 is het artikel in de papieren editie gepubliceerd, met daarin een selectie van het door de beheerexperts van Computable gegeven commentaar. Van mijn inzending werd ook een deel gebruikt, zie bijgevoegde scan.

Leuk om te zien dat juist mijn quote over te rooskleurige verkoopverhalen is gekozen om op te nemen in het artikel. Dit is namelijk iets dat mij zéér na aan het hart ligt. Te vaak zie ik dat oplossingen worden gepresenteerd die te “vol” zijn: teveel producten in te weinig tijd. Waar echt meer bij moet worden stilgestaan dat het professionaliseren van beheer een groeipad is en dat er dus tijd nodig is om dit groeipad te doorlopen. De scope vergroten of het tempo verhogen kan véél makkelijker dan andersom. Niet voor niets blijken jaar in jaar uit vele projecten te sneuvelen, naar mijn mening veelal vanwege deze te grote ambities en te weinig rekening houden met de organisatie die het allemaal maar moet verstouwen, náást het draaiend houden van de spullenboel hetgeen vaak al een hele klus op zich is. Een tool kan héél veel verlichting brengen in de beheerlast, maar moet wel fatsoenlijk geïmplementeerd worden en met de juiste verwachtingen worden aangeschaft. Het is géén puur technische exercitie !

Vier vragen -en antwoorden- over IT Management Software

Recentelijk is door Computable een artikel gepubliceerd met de prikkelende titel: “ICT-beheersoftware is vaak weggegooid geld”:

“Van de miljarden euro’s die bedrijven de afgelopen jaren investeerden in software voor ict-beheer, is een groot deel weggegooid geld. De toepassingen zijn vaak slecht geimplementeerd en sluiten slecht aan op de bedrijfsorganisatie.
Organisaties kunnen hun wensen voor beheersoftware niet door een enkele leverancier laten vervullen, zelfs niet een van de grootste (volgens Forrester BMC, CA, IBM en HP). Ze adviseren daarom niet alleen te kiezen voor de producten van een van grote, maar om die te combineren met een ict-beheerproduct van een kleinere leverancier.”

Het hele artikel is hier te lezen.

Naar aanleiding van dit artikel vroeg de redactie mij om een reactie te geven door het beantwoorden van vier vragen.

Hieronder de 4 vragen en mijn antwoorden daarop.

1: Deel je de mening dat beheersoftware vaak weggegooid geld is?

Ik ben van mening dat vele implementatieprojecten niet opleveren wat ze zouden moeten opleveren omdat klanten onjuiste verwachtingen koesteren, veelal in de hand gewerkt door te rooskleurige verkoopverhalen. Hierdoor worden te ambitieuze projecten opgestart die niet passen bij het huidige volwassenheidsniveau van de klant. Het is niet correct om dan maar de software de schuld te geven, de fout ligt m.i. vrijwel altijd uitsluitend bij de implementatie: men wil vaak teveel in te weinig tijd. Een goede implementatie van een breed scala aan beheersoftware is een groeipad, niet iets wat je “even” doet.

2: Klopt het dat itms-leveranciers geen allesomvattende beheeroplossing bieden en dat je dus meerdere pakketten nodig hebt?

Nee, er zijn wel degelijk leveranciers die één allesomvattende oplossing bieden, maar hiermee gaan grote investeringen gemoeid aan software licenties én personeelskosten voor de implementatie, zowel intern als extern. Wel kan het zijn dat een combinatie van puntoplossingen van diverse leveranciers een beter passende oplossing is dan alles van één leverancier betrekken. Welke oplossing het beste past voor een gegeven situatie moet van geval tot geval apart worden beoordeeld.

3: Wat is je ervaring met itms van grote leveranciers als CA en HP en met de software van kleinere aanbieders? Wat zijn de voor- en nadelen van zulke beheerpakketten?

De voordelen van ITMS pakketten van grotere leveranciers zijn met name de aandacht voor integratie met andere software en de mogelijkheid om makkelijker tot een totaaloplossing te komen. Kleinere leveranciers begeven zich -haast per definitie- in een klein stukje van het spectrum en kunnen zodoende soms op dat éne gebied een betere oplossing bieden dan een grotere leverancier. Wel kan hierdoor integratie met andere tooling lastiger zijn en kan een totaaloplossing bestaande uit pakketten van diverse leveranciers minder krachtig zijn dan een totaaloplossing van één enkele leverancier.

4: Waar moeten organisaties op letten als ze nieuwe beheersoftware overwegen? Kies je bijv een IBM-tool voor een IBM-omgeving en een Cisco-tool voor een Cisco-omgeving? Wat doe je bij hybride omgevingen? Wat doe je bij een beperkt budget?

ITMS tooling dient aangeschaft te worden ter ondersteuning van bepaalde bedrijfsdoelstellingen. Werk dus altijd vanuit die doelstellingen: bepaal wat voor jouw organisatie in deze fase het belangrijkste is en kijk daarnaast waar je over een paar jaar naartoe wil. Ga vervolgens aan de hand van dit groeipad een invulling zoeken. Laat je niet verleiden tot het willen bereiken van perfectie: focus op dat wat de meeste resultaten oplevert met de minste kosten/inspanning. Kies daarbij voor software die zo open mogelijk is qua integratiemogelijkheden en ondersteuning biedt aan open frameworks zoals ITIL(v3). Meer generieke software biedt als voordeel dat je niet bij iedere wisseling in je te beheren omgeving moet zoeken naar een andere tool maar kan wel als nadeel hebben dat in sommige gevallen de “diepte” niet zo groot is als gewenst. En tenslotte: bedenk dat de implementatie van beheertooling voor 20% een technische aangelegenheid is maar voor de overige 80% een organisatorische verandering is en zet de implementatieprojecten dus ook zodanig op.

Projecten in crisistijd

Recentelijk werd ik gevraagd om bij een organisatie een analyse te doen van de status van hun IT monitoring en een

voorstel te doen om de situatie te verbeteren. Deze organisatie had in de afgelopen tijd de nodige problemen gehad

met een belangrijke business applicatie en IT ligt onder vuur vanuit de business – de perceptie is dat IT de zaken

qua monitoring niet onder controle heeft.

Na een paar dagen rondlopen, kijken, vragen en luisteren kreeg ik een aardig beeld van de situatie en ontstonden in

mijn hoofd de contouren van een project dat uitgevoerd zou kunnen worden om de meest prangende zaken aan te pakken.

Hierop toog ik aan het werk om een conceptvoorstel te maken ter bespreking met de projectmanager. Het door mij

voorgestelde project was in mijn beleving nog redelijk klein, maar omvatte toch al gauw een flink aantal manmaanden

werk voor met name de eigen mensen van de organisatie.

Al gauw bleek dat deze aanpak niet zou gaan vliegen – IT Management had al een aantal projecten op dit gebied

proberen op te starten maar dat was telkens geen succes. Bovendien werd duidelijk dat er absoluut geen budget

vrijgemaakt zou worden voor een groot project – ook deze organisatie houdt in deze economisch slechte tijd de hand

stevig op de knip.

Wat nu gedaan ? Aan de ene kant wilde mijn klant écht dingen veranderd hebben maar aan de andere kant wilde men

géén groot project opstarten. De projectmanager gaf aan dat één van de redenen dat er geen budget voor een groot

project zou vrijkomen was dat men niet pas na een lange periode resultaat wilde zien. Wel kon de projectmanager een

aantal dagen werk geregeld krijgen bij de interne mensen en ook had hij wel wat geld om mij een beperkt aantal

dagen in te huren. De truc was dus om het grote project dat eigenlijk gedaan zou moeten op te delen in kleine

stukken waarbij van elk stuk de toegevoegde waarde meteen duidelijk zou worden. En dan te beginnen bij een stuk dat

aan de ene kant door de klant als erg urgent werd ervaren en aan de andere kant relatief makkelijk uitgevoerd zou

kunnen worden. Verder werd mij gevraagd om de scope te beperken tot de inrichting van de monitoring voor de eerder

genoemde belangrijke business applicatie.

Daarom heb ik een matrix gemaakt van de functionele blokken van deze business applicatie op de ene as, en diverse

IT-lagen (hardware, netwerk, storage, os, enzovoorts) op de andere as. Zo ontstaat een matrix van blokken die

allemaal één of meerdere infrastructuur componenten omvatten. Het plan is nu om deze matrix blok voor blok aan te

pakken, in een door de klant te bepalen volgorde. Elk blok op zichzelf is redelijk beperkt in omvang waardoor al na

hele korte tijd een blok “afgevinkt” kan worden. Hiermee heeft IT Management dan ook meteen een hele bruikbare

visualisatie om duidelijk te maken waar zij staan mbt. het op orde brengen van de monitoring voor deze business

applicatie. Ik heb de klant gevraagd om vooraf de matrix intern te bespreken om te bepalen of de door mij opgezette

indeling voor hun bruikbaar is. Voor het werk dat gedaan moet worden maakt de exacte indeling van de matrix niet

echt uit, maar hoe beter de matrix aansluit bij de beleving van de mensen bij de klant, hoe makkelijker deze

gebruikt zal worden. Ook laat ik de klant het eerste aan te pakken blok kiezen zodat zij zelf “in control” komen.

Deze aanpak lijkt goed te vallen: volgende week begin ik met het eerste blokje van de matrix.

Hoe eea. daadwerkelijk verder gaat schrijf ik over een tijdje nog wel eens op.

Natuurlijk is het bovenstaande niet nieuw noch een garantie voor resultaat.

Maar volgens mij kan het geen kwaad om af en toe ook weer eens op een open deur gewezen te worden

Recentelijk werd ik gevraagd om bij een organisatie een analyse te doen van de status van hun IT monitoring en een voorstel te doen om de situatie te verbeteren. Deze organisatie had in de afgelopen tijd de nodige problemen gehad met een belangrijke business applicatie en IT ligt onder vuur vanuit de business – de perceptie is dat IT de zaken qua monitoring niet onder controle heeft.

Na een paar dagen rondlopen, kijken, vragen en luisteren kreeg ik een aardig beeld van de situatie en ontstonden in mijn hoofd de contouren van een project dat uitgevoerd zou kunnen worden om de meest prangende zaken aan te pakken.

Hierop toog ik aan het werk om een conceptvoorstel te maken ter bespreking met de projectmanager. Het door mij voorgestelde project was in mijn beleving nog redelijk klein, maar omvatte toch al gauw een flink aantal manmaanden werk voor met name de eigen mensen van de organisatie.

Al gauw bleek dat deze aanpak niet zou gaan vliegen – IT Management had al een aantal projecten op dit gebied proberen op te starten maar dat was telkens geen succes. Bovendien werd duidelijk dat er absoluut geen budget vrijgemaakt zou worden voor een groot project – ook deze organisatie houdt in deze economisch slechte tijd de hand stevig op de knip.

Wat nu gedaan ? Aan de ene kant wilde mijn klant écht dingen veranderd hebben maar aan de andere kant wilde men géén groot project opstarten. De projectmanager gaf aan dat één van de redenen dat er geen budget voor een groot project zou vrijkomen was dat men niet pas na een lange periode resultaat wilde zien. Wel kon de projectmanager een aantal dagen werk geregeld krijgen bij de interne mensen en ook had hij wel wat geld om mij een beperkt aantal dagen in te huren. De truc was dus om het grote project dat eigenlijk gedaan zou moeten op te delen in kleine stukken waarbij van elk stuk de toegevoegde waarde meteen duidelijk zou worden. En dan te beginnen bij een stuk dat aan de ene kant door de klant als erg urgent werd ervaren en aan de andere kant relatief makkelijk uitgevoerd zou kunnen worden. Verder werd mij gevraagd om de scope te beperken tot de inrichting van de monitoring voor de eerder genoemde belangrijke business applicatie.

Daarom heb ik een matrix gemaakt van de functionele blokken van deze business applicatie op de ene as, en diverse IT-lagen (hardware, netwerk, storage, os, enzovoorts) op de andere as. Zo ontstaat een matrix van blokken die allemaal één of meerdere infrastructuur componenten omvatten. Het plan is nu om deze matrix blok voor blok aan te pakken, in een door de klant te bepalen volgorde. Elk blok op zichzelf is redelijk beperkt in omvang waardoor al na hele korte tijd een blok “afgevinkt” kan worden. Hiermee heeft IT Management dan ook meteen een hele bruikbare visualisatie om duidelijk te maken waar zij staan mbt. het op orde brengen van de monitoring voor deze business applicatie. Ik heb de klant gevraagd om vooraf de matrix intern te bespreken om te bepalen of de door mij opgezette indeling voor hun bruikbaar is. Voor het werk dat gedaan moet worden maakt de exacte indeling van de matrix niet echt uit, maar hoe beter de matrix aansluit bij de beleving van de mensen bij de klant, hoe makkelijker deze gebruikt zal worden. Ook laat ik de klant het eerste aan te pakken blok kiezen zodat zij zelf “in control” komen.

Deze aanpak lijkt goed te vallen: volgende week begin ik met het eerste blokje van de matrix. Hoe eea. daadwerkelijk verder gaat schrijf ik over een tijdje nog wel eens op.

Natuurlijk is het bovenstaande niet nieuw noch een garantie voor resultaat. Maar volgens mij kan het geen kwaad om af en toe ook weer eens op een open deur gewezen te worden .

Waarom beheertooling-implementaties vaak mislukken

Ict-beheer is iets van alle tijden, maar juist in het huidige slechte economische klimaat, zou goed ict-beheer kunnen bijdragen aan het drukken van operationele ict-kosten. Goed ict-beheer begint naar mijn mening met monitoring. Zonder monitoring ‘zie’ je niet wat er in de ict-voorziening gebeurt en zonder dit beeld mis je de informatie die nodig is om je resources te reserveren. Voor het automatiseren van deze beheerfunctie is veel verschillende software (‘tooling’) op de markt. De meeste software biedt behoorlijk goede functionaliteit, maar toch zie ik keer op keer dat de resultaten tegenvallen. Wat mij opvalt is dat implementaties van dit soort software vaak erg lang duren, moeizaam verlopen en uiteindelijk maar voor een fractie van hun potentieel worden benut. Ligt dat aan de software? Of ligt dat ergens anders aan?

Allereerst even dit: met ‘beheertooling’ beperk ik me specifiek voor dit artikel tot het monitoren van de beheerde ict-omgeving. Software dus die beheerders attendeert op afwijkingen zodat ze desgewenst actie kunnen nemen.

Ik denk dat implementaties van beheertooling vaak mank gaan op twee hoofdaspecten:

• De architectuur van de beheeromgeving.
• Het managen van de bijkomende veranderingen (verandermanagement).

Er is een veel fijnmazigere verdeling te maken, maar deze twee aspecten dekken naar mijn mening de lading.

Architectuur
Er bestaat in organisaties nogal eens weerzin tegen ict-architectuur, dit terwijl deze er juist voor zorgt dat de ict doet wat de business verlangt. Alles wat nodig is en niet meer dan dat. Dat zou dus ook kunnen gelden voor de architectuur die een beheer (monitoring) oplossing beschrijft. In de praktijk gaat dit echter veelal niet op. Naar mijn mening komt dat doordat wordt onderschat wat het oplevert om vooraf goed na te denken hoe de oplossing zou moeten functioneren. Of anders gezegd: men onderschat hoe groot de kans is dat de boel in het honderd loopt door niet vooraf goed na te denken. Afstemming met belanghebbenden (stakeholders) helpt overigens niet alleen dit primaire doel maar het vergroot ook nog eens de betrokkenheid van de mensen, maar daarover later meer.

Als er dan eindelijk een beheerarchitectuur is, moeten er functionele en technische ontwerpen gemaakt worden. Ook hier gaat nogal eens wat mis en één van de meest voorkomende discussies die ik hier zie is die van de uiteindelijke monitoringconfiguratie. De set van parameters dus, die bepaalt wat er in de ict-voorziening gemonitord wordt. Hiervoor bestaan twee uitersten: volledig gebruikmakend van ‘out-of-the-box’- (OOTB-)intelligentie van de tool of volledig naar wens geconfigureerd. Ik heb door de jaren heen via beide manieren en alles daartussen implementaties begeleid, en heb ervaren dat beide manieren zowel voor- als nadelen hebben. Helaas leidt niet één van deze keuzes steevast tot een goed resultaat.

Toch heeft een OOTB-implementatie duidelijk voordelen boven een volledig zelf ontwikkelde monitoringconfiguratie. Dat zijn vooral de onafhankelijkheid van kennis in de medewerkers zelf en de grotere beheerbaarheid. Wie kent niet de situatie dat ergens prachtige scriptconstructies zijn gemaakt die in beginsel fantastisch werken, maar een jaar later moeilijk up-to-date blijken te houden, niet in het minst omdat niemand meer precies weet hoe het nou allemaal ook alweer werkte. Ook kan bij gebruik van OOTB-functionaliteit makkelijker teruggevallen worden op de supportorganisatie van de leverancier en kan men bij het inregelen van de software zich concentreren op de functionaliteit in plaats van de manier waarop de functionaliteit bereikt wordt. Een belangrijk nadeel van OOTB-configuraties kan echter zijn dat de oplossing minder makkelijk geaccepteerd wordt door de gebruikers, aangezien het ‘not invented here’ is.

Genoeg zaken dus om terdege rekening mee te houden, nog vóór de implementatie van start gaat. Naast al deze technische aspecten is er ook nog een héél belangrijk aspect dat maar al te vaak verwaarloosd wordt: verandermanagement. Aandacht voor de mensen die (vaak: wéér) een verandering door moeten maken, veelal bovenop hun toch al hectische dagelijkse werkzaamheden.

Verandermanagement
Torenhoge ambities, onrealistisch korte implementatietijden en alleen maar aandacht voor de techniek is kenmerkend voor implementaties van beheertooling. Wie dat niet herkent is een gelukkig mens, zou ik haast zeggen. Vaak heeft de opdrachtgever, veelal gevoed door commerciële contacten, grote verwachtingen en ambities met betrekking tot de beheertooling. De indruk bestaat dat de tooling de panacee is. Wel, ik heb nieuws: die beheertooling is dat niet! Hoewel in een ideale wereld implementaties vanuit een technisch oogpunt makkelijk en vlot zouden moeten kunnen lopen, is de realiteit weerbarstiger. Houd daar dus rekening mee met het inschatten van de implementatietijden en te bereiken mijlpalen. Deel een implementatietraject op in realistische delen en neem tussendoor de tijd om terug te kijken en te leren van de afgelopen periode.

Hoewel het heel goed kan werken om een ‘smalle’ implementatie over de hele diepte van een ict-keten te doen, waardoor er dus een showcase ontstaat om de mogelijkheden van de nieuwe software te laten zien, werkt een solide implementatie bottom-up in veel gevallen beter. Dit hangt echter van een groot aantal factoren af, waaronder de eventueel al aanwezige tooling, het volwassenheidsniveau van de beheerorganisatie, de mogelijkheden van de nieuw te implementeren tooling, de mate waarin de ict-voorziening momenteel voor problemen zorgt en het politieke klimaat in de organisatie.

Maar bovenal: vergeet de mensen niet. Beheerkosten omlaag brengen en tegelijkertijd de kwaliteit verhogen via een implementatie van (betere) monitoring-tooling werkt alleen als de mensen die de tooling zouden moeten gebruiken dat ook echt optimaal doen. Een andere manier van werken, vaak over beheerdomeinen heen is daarbij geen uitzondering. Hier passen modellen zoals ASL/BiSL en ITIL, maar daar wil ik het hier niet eens over hebben. Waar mijn gedachten naar uitgaan is dat de mensen op de ict-afdeling vaak vele veranderingen doorgeduwd krijgen die slecht zijn verlopen. En er dus vaak een voorgeschiedenis is die mensen voorzichtiger maakt om wéér aan een nieuw project deel te nemen. Dat het anders leren werken niet het volgen van een cursus ‘hoe configureer ik de nieuwe tool’ is. Dit soort trajecten vergen aandacht en begeleiding, veel meer dan dat ik doorgaans zie. Wat goed verandermanagement is, is niet wat ik hier wil vertellen. Het punt dat ik wil maken is dat goed verandermanagement essentieel is. Juist bij dit soort ‘technische’ trajecten, omdat hierbij van nature de aandacht naar de techniek uitgaat en niet naar de mensen voor wie de techniek bedoeld is.

Tot dusver in het kort mijn gedachten en ervaringen omtrent het al dan niet slagen van beheertooling-implementaties. Ik ben benieuwd wat jullie hiervan denken. Laat me jullie gedachten en ervaringen weten!

Dit bericht is ook gepubliceerd op de website van Computable:
http://www.computable.nl/artikel/ict_topics/beheer/2876875/1277800/waarom-beheertoolingimplementaties-vaak-mislukken.html

IT trends en oplossingen voor 2009

In oktober 2008 heeft het tijdschrift Computable haar panel-leden gevraagd om in 300 woorden hun top 3 IT trends en oplossingen voor 2009 op te stellen. Deze informatie is vervolgens gebruikt voor de Computable Consultancy gids. Hieronder mijn bijdrage voor deze enquête.

Trends

Beter benutten bestaande capaciteit
Momenteel zie ik, zeker bij outsourcing trajecten, een toename van de aandacht voor de benuttingsgraad van hardware. Dit zal naar mijn mening nog meer versterkt worden door het slechte economische tij in de komende jaren.

Meer en beter automatiseren IT Beheer
Nog te vaak zie ik bedrijven waar IT Beheer ondergeautomatiseerd is. Een voorbeeld hiervan is configuratiemanagement. Dit is vaak nog handmatig proces dat veel tijd kost, foutgevoelig is en steevast achter de feiten aanloopt.

Meer aandacht voor ketenbewaking
Het maakt een eindgebruiker niet uit wat de status van individuele IT componenten is. De eindgebruiker neemt een IT dienst af die bestaat uit een keten van IT componenten. Steeds meer bedrijven zijn zich hiervan bewust en richten zich op implementatie van beheertooling die hieraan invulling kan geven.

Oplossingen

Virtualisatiesoftware
Er is tegenwoordig hele goede virtualisatiesoftware op de markt die ook steeds interessanter wordt voor kleinere bedrijven. Virtualisatie van systemen is een uitstekende manier om de bezettingsgraad van hardware te verbeteren, maar biedt ook voordelen op andere gebieden. Zo is met gevirtualiseerde systemen hardware onderhoud steeds makkelijker te doen zonder downtime en hoeft dit dus steeds minder op “lastige” (en dus dure) tijdstippen te gebeuren. Maar ook uit oogpunt van redundantie en disaster recovery biedt virtualisatie vele mogelijkheden.

Configuratiemanagement software
In de markt is tegenwoordig software te krijgen die het configuratiemanagement proces verregaand kan automatiseren. Bij deze software worden ook de relaties tussen systemen geautomatiseerd in kaart gebracht en up-to-date gehouden. Met name dit laatste is vaak nog een onderbelicht maar wel zeer belangrijk aspect.

Implementaties van geautomatiseerde ketenbewaking
Software die heterogene ketens van IT componenten kan bewaken is niet nieuw. Wel zijn er steeds meer bedrijven die hier invulling aan geven en daarmee beter gehoor geven aan de wensen van eindgebruikers.