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!
Ik denk dat je gelijk hebt: verandermanagement is zeker belangrijk. Maar dat geldt eigenlijk wel voor ieder managemen pakket.
Wat nog belangrijker is, is zichtbaarheid.
Zolang een beheerder (of de tool implementator) het management niet met enige regelmaat voorziet van:
– onderbouwde verbetervoorstellen of
– het ontzenuwen van een tijdrovend blame game,
dan gaat het ‘vehikel’ ook niet landen.
Sterker nog, ik heb ervaren dat als er een beheerder is die dit actief promoot, dan gaat de verandering in manier van werken eigenlijk van zelf.
Mijn ervaring is vaak dat hoe groter de monitoring tool, hoe meer werk je eraan hebt (het beheer/monitoren van de beheer/monitoring tool).
De inrichting van die tools is vaak ook specialisten werk. Eigenlijk een gemiste kans, want je probeert juist te besparen in kosten.
Belangrijk is om de juiste beheertool te kiezen. De markt maakt dat lastig doordat een goede vergelijking zelden te maken is.
Een monitoring tool signaleert afwijkingen. Vaak dient de tool door de beheerder zelf te worden ingeregeld op het normale situatie, wat te doen bij een afwijkende situatie, en hoe dit in de beheerorganisaties in te bedden.
Wat ik zelf mis is de modulariteit en de standaardisatie van de beheertool zelf.
stel ik heb een multivendor omgeving, met diverse OOTB applicaties (ook multivendor), er zijn maar weinig tools (ben geen expert,maar ik kan ze niet vinden) die de normale/afwijkende situatie kunnen ontdekken. veelal blijft het hangen in het geven van generieke meldingen gebaseerd op thresholds die je zelf maar moet specificeren (de default kloppen zelden)
idee: iedere producent van een OOTB applicatie levert een set gegevens aan waarmee zijn/haar applicatie gemonitoord kan worden.
de monitoring applicatie kan deze set gegevens automatisch actueel houden en kan deze afwijkingen voorzien van de diagnostische applicatie informatie (ook bekend bij de producent en nodig voor troubleshooten) doorgeven aan de beheerder.
antivirus/ids producten gebruiken dit soort abbonnement systemen al, sommige beheerframework vendors ook, het nadeel hiervan is dat dit niet gestandaardiseerd is en dus niet uitwisselbaar.
Voor maatwerkapplicaties kan de ontwikkelaar dan ook aansluiten op een standaard manier van monitoring.
de monitoringsgegevens kun je dan (de performance items) ook weer gebruiken in je itil processen.
Op netwerk gebied doet iedere beheertool vaak wel wat met SNMP, maar gebruikt ook vaak meerdere eigen agents met elk zijn eigen onnavolgbare protocolset.
mijn ideaal beeld van een schaalbaar modulair monitoringoplossing is bijvoorbeeld een gedistribueerde omgeving van probes waaraan je de communicatie kan uitbesteden. bij de meeste oplossingen is dit teveel gevraagd en verwachten een 1 op n connectiviteitsmatrix om de tool werkend te krijgen.
nog veel te doen dus.
Duidelijke visie en aanbevelingen van eenieder. Zelf ben ik als projectmanager nu verantwoordelijk voor een groot project waarbij we op mutivendor basis allerlei verschillende beheertooling gaan migreren, dus vanaf operation management t/m (business) service management aan toe.
Ik onderschrijf alle risico’s en aanbevelingen. Mijn grootste uitdaging zit hem vooral in de Business en de te realiseren benefits. Vragen (eigenlijke risico’s) die ik heb zijn:
1. hoeveel tijd heb ik nu daadwerkelijk nodig om alles goed in te integreren, juist om aan goede verwachtingsmanagement te doen. (tijd – BC). Uitgangspunt OOTB
2. In hoeverre komen er nog extra consultancy kosten bij. Consultancy hongerachtige tooling? Zeker bij multivendor.
3. Wat zijn realistische data’s als we kijken naar verandermanagement (proces) en de mens.
Referentie bezoeken tot op service management niveau (Bottum-up vanaf infrastructuur management) levert wel de pragmatische aanpak, en voortgang (kleine successen), maar ook de complexiteit van het geheel waarmee een hoop consultancy zijn gemoeid, waarbij doel en resultaat nog niet zijn behaald.
Ik ben van mening dat bottum-up en OOTB duidelijkheid schept in scope afbakening en wat betreft verwachtingsmanagement, maar ook dat dit pas het begin voor verdere optimalisatie voor migratie en het betrekken van alle betrokkene partijen (Business-IT)
Mijn taak om dit duidelijk te maken bij de Business, en de Business en IT meer na elkaar te krijgen.