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 .

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.