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 .

Best Practices

Best Practices

Gisteren heb ik een zeer gezellige, maar vooral ook nuttige, bijeenkomst van de werkgroep ASL Best

Practices bijgewoond. Deze werkgroep valt onder de ASL/BiSL foundation, een non-profit organisatie die

zich ten doel stelt het ASL/BiSL raamwerk verder te (doen) ontwikkelen en gebruik hiervan te stimuleren.

Voorafgaand aan het workshop gedeelte gaf Remko van der Pols een vlammend betoog over wat Best Practices

nou eigenlijk zijn en hoe ze te gebruiken. En ook: wat ze niet zijn en hoe ze niet gebruikt dienen te

worden. Buiten Remko’s boeiende stijl van presenteren vond ik dit verhaal zeer interessant, en dat was eigenlijk tegen mijn verwachting in.

Want zeg nou zelf, als u de vraag krijgt “Wat zijn Best Practices ?” dan denkt u waarschijnlijk, net als

ik, aan een kort en krachtig antwoord, gevormd in één of andere definitie. Echter, vaak wordt er als er

over Best Practices (BP’s) wordt gesproken, voorbij gegaan aan twee hele belangrijke aspecten van BP’s.

Hoewel het eigenlijk open deuren zijn, vind ik deze punten dermate belangrijk dat ik ze hier nog eens

even wil aanhalen.

Ten eerste: Best Practices zijn verzamelingen van cases die in bepaalde praktijksituaties hun nut hebben

bewezen.

Dit behelst nogal wat:

- Er kunnen meerdere BP’s zijn voor soortgelijke situaties

- Bij een BP hoort ook een duidelijke beschrijving (typering en categorisatie) van de situatie

- BP’s hebben in een bepaalde situatie voor een bepaalde gebruiker nut gehad (cq. hebben dat nog steeds)

Ofwel: Bij het beoordelen of een BP voor een bepaalde situatie eventueel nuttig kan zijn, is het

belangrijk om zoveel mogelijk informatie te hebben over de situatie waarvoor de BP is toegepast.

Persoonlijk zou ik een BP die zonder verdere toelichting wordt aangeboden met enige argwaan bekijken.

Wat voor de ene situatie werkt, hoeft niet zomaar voor de andere situatie te werken ! En zoals zo vaak:

er leiden meerdere wegen naar Rome. Kies dus uw eigen weg !

Ten tweede: BP’s zijn bedoeld om verder aan te passen aan de eigen situatie !

Vaak worden BP’s of sjablonen van raamwerken of methodieken recht uit het tekstboek overgenomen en

zonder verdere aanpassingen geïmplementeerd. Berucht zijn in mijn ogen bijvoorbeeld de PINO’s (Prince In

Name Only) die het resultaat zijn van het rigide gebruiken van PID (Project Initiatie Document)

sjablonen. Dat is niet wat Prince beoogt ! Zo ook met de ASL Best Practices waar ik gisteravond mee heb

mogen stoeien. Remko gebruikte een -in mijn ogen- briljant en pijnlijk eenvoudig voorbeeld van twee

verschillende supermarktketens om dit punt te verduidelijken. Dit voorbeeld ging over het interacteren

met klanten. Op zeer illustratieve wijze schilderde Remko het verschil in afhandeling van een vraag

zoals “weet u waar de suiker staat” tussen (bijv.) de Lidl en de AH. Hetzelfde proces, maar op twee

totaal verschillende manieren geïmplementeerd. Het punt hier is dat het botweg overnemen van een Best

Practice zonder deze aan te passen op de eigen situatie meestal niet tot de gewenste resultaten leidt.

In deze tekst kan ik u overigens de “real life experience” van Remko’s betoog niet doen beleven, komt u

daarvoor de volgende keer vooral zelf naar zo’n bijeenkomst !

Gisteren heb ik een zeer gezellige, maar vooral ook nuttige, bijeenkomst van de werkgroep ASL Best Practices bijgewoond. Deze werkgroep valt onder de ASL/BiSL foundation, een non-profit organisatie die zich ten doel stelt het ASL/BiSL raamwerk verder te (doen) ontwikkelen en gebruik hiervan te stimuleren.

Voorafgaand aan het workshop gedeelte gaf Remko van der Pols een vlammend betoog over wat Best Practices nou eigenlijk zijn en hoe ze te gebruiken. En ook: wat ze niet zijn en hoe ze niet gebruikt dienen te worden. Buiten Remko’s boeiende stijl van presenteren vond ik dit verhaal zeer interessant, en dat was eigenlijk tegen mijn verwachting in.

Want zeg nou zelf, als u de vraag krijgt “Wat zijn Best Practices ?” dan denkt u waarschijnlijk, net als ik, aan een kort en krachtig antwoord, gevormd in één of andere definitie. Echter, vaak wordt er als er over Best Practices (BP’s) wordt gesproken, voorbij gegaan aan twee hele belangrijke aspecten van BP’s.

Hoewel het eigenlijk open deuren zijn, vind ik deze punten dermate belangrijk dat ik ze hier nog eens even wil aanhalen.

1. Best Practices zijn verzamelingen van cases die in bepaalde praktijksituaties hun nut hebben bewezen.

Dit behelst nogal wat:

• Er kunnen meerdere BP’s zijn voor soortgelijke situaties
• Bij een BP hoort ook een duidelijke beschrijving (typering en categorisatie) van de situatie
• BP’s hebben in een bepaalde situatie voor een bepaalde gebruiker nut gehad (cq. hebben dat nog steeds)

Ofwel: Bij het beoordelen of een BP voor een bepaalde situatie eventueel nuttig kan zijn, is het belangrijk om zoveel mogelijk informatie te hebben over de situatie waarvoor de BP is toegepast.

Persoonlijk zou ik een BP die zonder verdere toelichting wordt aangeboden met enige argwaan bekijken.  Wat voor de ene situatie werkt, hoeft niet zomaar voor de andere situatie te werken ! En zoals zo vaak: Er leiden meerdere wegen naar Rome. Kies dus uw eigen weg !

Impressie ASL Best Practices bijeenkomst 16 juni 2009 (foto: Reyer de Boer)

2.  Best Practices zijn bedoeld om aan te passen !

Vaak worden BP’s of sjablonen van raamwerken of methodieken recht uit het tekstboek overgenomen en zonder verdere aanpassingen geïmplementeerd. Berucht zijn in mijn ogen bijvoorbeeld de PINO’s (Prince In Name Only) die het resultaat zijn van het rigide gebruiken van PID (Project Initiatie Document) sjablonen. Dat is niet wat Prince beoogt ! Zo ook met de ASL Best Practices waar ik gisteravond mee heb mogen stoeien. Remko gebruikte een -in mijn ogen- briljant en pijnlijk eenvoudig voorbeeld van twee verschillende supermarktketens om dit punt te verduidelijken. Dit voorbeeld ging over het interacteren met klanten. Op zeer illustratieve wijze schilderde Remko het verschil in afhandeling van een vraag zoals “weet u waar de suiker staat” tussen (bijv.) de Lidl en de AH. Hetzelfde proces, maar op twee totaal verschillende manieren geïmplementeerd. Het punt hier is dat het botweg overnemen van een Best Practice zonder deze aan te passen op de eigen situatie meestal niet tot de gewenste resultaten leidt.

In deze tekst kan ik u overigens de “real life experience” van Remko’s betoog niet doen beleven, komt u daarvoor de volgende keer vooral zelf naar zo’n bijeenkomst !

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.

Service Assurance – Een pragmatische aanpak

Onderstaand artikel is er eentje uit de oude doos. Ik heb het in 2003 samen met mijn toenmalige collega Evert-Jan Norg geschreven voor IT Service Magazine. Inmiddels is de ontwikkeling op het gebied van Business Service Management alweer een stuk verder, maar omdat sommige principes nog steeds gelden heb ik gemeend het artikel toch nog op te nemen in mijn blog.

Inleiding

Als consultants moeten wij meer dan ooit onze klanten overtuigen van het praktische nut van de dingen die we doen. Iedereen weet dat nog maar enkele jaren geleden de markt compleet overspannen was en allerlei projecten werden opgetuigd waarvan het nut niet direct duidelijk was. Kosten waren nooit een probleem. Tegenwoordig liggen de zaken anders. Klanten willen vóórdat zij een investering doen duidelijk weten wat het nut van een project is. In dit artikel willen wij u vertellen over een project dat wij uitvoeren bij een grote Nederlandse Telecom Operator. Bij dit project is, met als basis enkele vereenvoudigde modellen, gekozen voor een zeer pragmatische aanpak. Sleutelwoorden hierin zijn eenvoud, duidelijke keuzen en het consequent doorvoeren van de gekozen strategie.  

 

Het project behelst het omvormen van de HP OpenView monitoring omgeving van louter element monitoring naar service monitoring. Binnen ons team gebruiken wij hiervoor de term “Service Assurance”. Het doel hiervan is de impact van verstoringen in elementen (bijv. een harde schijf) op een dienst (bijv. e-mail) inzichtelijk te maken. En dan ook nog eens voor niet-technische mensen, namelijk de service managers: de mensen die integraal verantwoordelijk zijn voor het functioneren van een dienst.

Met als basis het TMN (Telecom Management Network) en het SAC (Service Assurance Centre) model is een vertaling naar de daadwerkelijke inrichting ontworpen. In de komende paragrafen leggen wij kort uit waarom deze modellen zijn gekozen en hoe deze zijn vertaald naar de praktijk.

Modellen

Omdat de opdracht zich afspeelt bij een Telecom Operator ligt het voor hand om te kijken naar modellen die in deze branche gebruikelijk zijn. Een heel bekend model voor Telecom bedrijfsvoering is TOM: Telecom Operations Map, beschikbaar via http://www.tmforum.org/. Echter, dit model is zeer uitgebreid en daarom wat minder snel praktisch toepasbaar in onze situatie.  

 

Een voorloper van dit model is TMN: Telecom Management Network (ITU-T M serie, zie http://www.itu.int/). Dit model is iets eenvoudiger van opzet en meer gericht op netwerk management en past dus beter bij onze opdracht. Het doel van dit model is een raamwerk te bieden voor het managen van telecommunicatie netwerken. Het beschrijft hiervoor de management activiteiten, de concepten en het definieert architectuur elementen zoals interfaces, referentie punten en functionele eenheden.

Het TMN model is gesimplificeerd te zien als een piramide met 5 lagen, zie figuur 1.

Het TMN model

Dit model toont ondermeer dat een functionaliteit of ICT diensten is opgebouwd uit componenten zoals databases, processen etcetera, die op hun beurt weer zijn opgebouwd uit componenten zoals CPU’s, disks, enzovoorts.

De bedrijfslaag definieert hoe effectief een functionaliteit is in termen van winstgevendheid. In de hier gevolgde aanpak is deze laag niet geïmplementeerd. Wel is al de wens geuit om hier in de toekomst ook invulling aan te geven, maar daarvoor dienen eerst de daaronder gelegen lagen goed geïmplementeerd te zijn.

Omdat onze opdracht zich in eerste instantie beperkt tot het IT-gedeelte van het netwerk van deze operator is ook de onderste laag (NEL) weggelaten. De NEL laag is vooral van belang voor het managen van het transmissie netwerk, dus het netwerk waar het telefoonverkeer daadwerkelijk overheen gaat. Wij beperken ons hier tot de diensten die geleverd worden vanuit het IT netwerk: SMS, ringtones, etcetera. Hiervoor zijn op het IT netwerk vele systemen nodig die allen interactie hebben met diverse andere systemen.

Gebaseerd op het TMN model kan aldus een service gemodelleerd worden door het in kaart brengen van alle componenten die nodig zijn voor die specifieke dienst, evenals hun afhankelijkheden. Een dergelijk model wordt een Service Model genoemd. Het is dit model dat ten grondslag ligt aan de inrichting van het monitoring systeem, maar daarover dadelijk meer.

Een ander model dat gebruikt is bij het inrichten van de monitoring is het SAC model: Service Assurance Centre model. Dit model is ontwikkeld door BMC software en beschrijft hoe er met de informatie die uit de monitoring systemen komt omgegaan moet worden teneinde een volledige set informatie op de juiste plaats te krijgen.

Het SAC model

Bij dit project gebruiken we dit model om te voorkomen dat we mensen alleen maar point-solutions bieden qua informatie. Iedereen kent wel de situatie dat een service manager vraagt om “dit of dat” aan monitoring “even” door te sturen. Gebleken is dat je op deze manier op zeker moment te maken krijgt met een woud aan point-solutions, maar dat nog steeds niemand integraal een dienst gemonitord krijgt. Er worden dus dingen gemist en dat is zeker niet gewenst. Om van de beheerbaarheid van een dergelijke inrichting nog maar te zwijgen. Kortom, met behulp van dit model is gedefinieerd hoe en welke informatie naar de verschillende informatievragers toe gaat. Vanwege de beperkte ruimte gaan we in dit artikel niet verder in op dit model en richten we ons vooral op de vertaling van het TMN model naar een bruikbare implementatie. Zoals in de inleiding al gesteld ligt de kracht van de gevolgde aanpak hem in de vereenvoudiging die is aangebracht. In de volgende paragraaf wordt besproken hoe we die vereenvoudiging hebben aangebracht en wat hiervan de belangrijkste voordelen zijn.

Vertaling

In een perfect Service Model zouden alle relaties tussen alle componenten gedefinieerd moeten worden. Bijvoorbeeld:  

 

Service A heeft nodig:

Functionaliteit x, die nodig heeft:

Proces 1, dat nodig heeft:
Cpu 1, disk 1, disk 2, geheugen van server 1

Proces 2, dat nodig heeft:

Cpu 1, disk 1, disk 2, geheugen van server 1
Database 1
……

Het probleem is dat deze 100% realistische modellen enorm complex zijn en even zo moeilijk te implementeren. Daarbovenop komt dat deze realistische modellen meteen een break-down structuur hebben die is uitgedrukt in het allerlaagste technische niveau, en daarom moeilijk te begrijpen zijn zonder technische kennis. En één van de zaken die onze aanpak beoogt te bewerkstelligen, is dat juist mensen met een niet-technische achtergrond in staat zijn om bruikbare informatie uit het systeem te verkrijgen.

Daarom tonen in de door ons gevolgde aanpak de service modellen niet exact de relaties tussen de componenten. In plaats daarvan worden componenten die een dienst opmaken logischerwijs gegroepeerd in component groepen. Deze groepen zijn direct afgeleid van het TMN model:

- functionaliteit (afgeleid van de Service Management laag)
- applicaties (afgeleid van de Network Management laag)
- elementen (afgeleid van de Element Management laag)

Hierdoor worden de aldus gemaakte service modellen:

- eenvoudig te maken
- uniform voor alle services
- makkelijk te begrijpen
- pas geleidelijk steeds meer technische details

Dit levert belangrijke voordelen voor de praktijk. Doordat de modellen eenvoudig te maken zijn is de tijd die nodig is om een dienst onder monitoring te brengen drastisch korter dan bij gebruik van waarheidsgetrouwe modellen (enkele weken tegenover misschien wel enkele maanden bij zeer complexe diensten). Bij de hier besproken klant zijn een kleine twintig diensten geïdentificeerd dus het is duidelijk dat deze tijdsverkorting een enorme tijdswinst voor het gehele project teweeg brengt.

Omdat de service modellen uniform zijn, is de presentatie vanuit het monitoring systeem daarvan dat ook. Als een service manager van service X eenmaal bekend is met de presentatie van zijn (of haar) service is het voor hem zeer eenvoudig om ook voor een willekeurige andere service de informatie te vinden en te begrijpen. Met andere woorden: alle service managers gebruiken ineens hetzelfde model en dus dezelfde presentatie voor de voor hen van belang zijnde service. Ze hebben nu dus een gezamenlijke, zelfde, basis wat de communicatie onderling sterk vereenvoudigt.

En omdat de service modellen pas geleidelijk steeds meer technische details bieden, verdrinken mensen niet in technische details. Die worden simpelweg niet weergegeven op het allerhoogste niveau. Dit is overigens geen specifiek kenmerk van de door ons gekozen manier om service modellen te maken, het is inherent aan het concept van service modellen in het algemeen.

Genoeg over de theorie nu, laten we in de volgende paragraaf bekijken hoe een en ander er in de praktijk uit komt te zien.

Implementatie

Bij de bespreking van de modellen is uitgelegd dat er voor gekozen is om elk service model als eerste stap onder te verdelen in 3 hoofdgroepen: functionaliteit, applicaties en elementen. Onder deze groepen zijn subgroepen gedefinieerd, die voor elke service hetzelfde zijn. Ook hier dus weer de consequente doorvoering van hetzelfde uniforme service model. Uiteraard zijn de uiteindelijke basiscomponenten voor iedere service anders, maar niet de presentatie daarvan.

Momenteel worden bij de klant in kwestie de volgende subgroepen ondersteund (onderstreept):

Functionaliteit
Functionele ketens
Applicaties
Databases
Processen
Elementen
Hardware en Operating System componenten
Netwerk Interface componenten

Deze subgroepen zijn dus voor elke service aanwezig, op dezelfde plek.

De monitoring systemen waarmee dit alles ingericht is zijn alle uit de HP OpenView suite. We gebruiken de volgende applicaties om de juiste informatie uit de infrastructuur te krijgen:

- Network Node Manager
- Internet Services
- Reporter
- Operations (inclusief Service Navigator)

Network Node Manager wordt gebruikt om de IP lay-out van het netwerk weer te kunnen geven, evenals via SNMP details over systemen te kunnen raadplegen. Internet Services wordt gebruikt voor het monitoren van de ketenfunctionaliteit. Door middel van probes die gebruik maken van diverse protocollen is vast te stellen of een keten nog functioneert. Reporter wordt gebruikt om rapporten voor de diverse belanghebbenden te genereren. En Operations tenslotte is het centrale punt waar alle informatie bijeenkomt. Bovendien is Operations in staat om op een intelligente manier, al dan niet met gebruik van Agents, allerlei informatie over het functioneren van systemen en applicaties boven water te krijgen. Geïntegreerd in Operations is Service Navigator, een applicatieonderdeel waarmee de conditie van de services grafisch weergegeven kan worden. In de afbeelding hieronder zijn de eerste twee lagen van het service model voor de service Bulk SMS weergegeven.

Een Service View

Zoals gezegd zijn tot en met het derde niveau alle services gelijk gedefinieerd. Pas onder dat niveau krijgt iedere service zijn eigen, specifieke afhankelijkheden geïmplementeerd.
Services zijn hiermee op een zodanige manier gedefinieerd dat de bovenste drie lagen altijd dezelfde betekenis hebben voor service managers.  

 

Zoals gezegd is het goed modelleren van een service geen sinecure. Vooral waar het gaat om de (gedeelde) netwerkverbindingen is het in de praktijk erg moeilijk om precies aan te geven waar een service nou wel en niet afhankelijk van is. Een stap die overigens nog genomen moet worden in dit project is het inbrengen van geleidelijke propagatie. Hiermee wordt bedoeld dat niet alle verstoringen op het laagste (technische) niveau voor 100% gepropageerd moeten worden naar het hoogste niveau. Omwille van eenvoudigheid is er momenteel voor gekozen om deze geleidelijke propagatie niet in te voeren, maar in de toekomst zal dit wel gaan gebeuren.

Denk bijvoorbeeld aan een functionaliteit (e-mail) die draait op 5 servers. Wat is de impact op de service bij een storing op 1 server ? Als het goed is, ligt met het uitvallen van deze ene server de e-mail niet plat, maar is bijvoorbeeld de capaciteit van het e-mail systeem tijdelijk slechts met 20% afgenomen. Dit is slechts een zeer eenvoudig voorbeeld. In de praktijk blijkt dat juist deze propagatieregels zeer moeilijk vast te stellen zijn, het moeilijkst bij in-huis gemaakte services die al geruime tijd draaien. Met het toevoegen van dit soort propagatieregels wordt de alarmering ook een stuk “milder”: bij het uitvallen van een low-level component met beperkte impact op de dienst als geheel wordt niet meteen groot alarm geslagen.

Bij de implementatie is het zaak om degenen voor wie de monitoring wordt ingericht vanaf het begin erbij te betrekken. Dit klinkt wellicht als het intrappen van een open deur, maar in de praktijk blijkt dat dit maar al te vaak mis gaat. Techneuten gaan razend enthousiast aan de gang met het bouwen van de mooiste monitoring systemen, om er na lange tijd zwoegen achter te komen dat het systeem na oplevering niet gebruikt wordt. Herkent u dit ? Zorg dus vanaf het allereerste begin van het project voor betrokkenheid van degenen voor wie het systeem uiteindelijk bedoeld is. Deze mensen kunnen vertellen wat ze van een monitoring systeem willen. Geef mensen ook tussentijds presentaties over hoe het met het project gaat. In ons geval zijn we, na een fase waarin het conceptuele denkwerk werd verricht, met de implementatie van één service begonnen om ervaring op te doen. Daarna de volgende. Daarna nog een. En al snel ontstond er een sneeuwbal effect met reacties zoals “dat wil ik ook”. Het bleek dat toen de eerste paar services daadwerkelijk gemonitord werden, de andere service managers zeer enthousiast werden van wat ze bij hun collega’s zagen. En zo konden we stap voor stap het project vervolgen met volledige acceptatie door de gebruikers.

Conclusie

Door het invoeren van Service Assurance kunnen bedrijven inzicht krijgen in de relaties tussen de IT componenten die een IT dienst opmaken. Door dit inzicht is de impact van een verstoring in een component op een IT dienst snel duidelijk. Hierdoor wordt sneller duidelijk met wat voor prioriteit een storing opgelost dient te worden en kunnen klanten die gebruikmaken van de dienst beter geïnformeerd worden.

Het is echter raadzaam om vooral pragmatisch te werk te gaan en te kiezen voor een uniforme aanpak voor alle services. Verwacht niet meteen elke service 100% natuurgetrouw gemodelleerd te krijgen. Dit is ook niet nodig. Wat nodig is, is een model dat werkbaar is voor de gebruikers. En per definitie is een model een vereenvoudigde weergave van de werkelijkheid.

Door het eenmaal gekozen model uniform en consequent te hanteren voor elke service, wordt het onder monitoring brengen van een service een stuk eenvoudiger dan wanneer men zou proberen elke service volledig waarheidsgetrouw te modelleren. Hierdoor wordt de benodigde tijd voor de implementatie drastisch ingekort. Daarnaast wordt de leerdrempel voor service managers verlaagd en kunnen zij dus ook makkelijker onderling communiceren.

In dit artikel is slechts op hoofdlijnen ingegaan op de belangrijkste aspecten van de gemaakte keuzes bij het invoeren van Service Assurance. Door ruimte gedwongen hebben wij vele zaken weg moeten laten. Mocht u meer willen weten over deze materie, dan bent u van harte uitgenodigd om met de auteurs contact op te nemen.

Dit artikel is in 2003 door Arvid Elstrodt en Evert-Jan Norg samen geschreven toen zij teamgenoten waren bij het Service Assurance Competence Centre van CMG.

Het is in 2003 in de papieren editie van IT Service Magazine gepubliceerd.