Sinds enige tijd is er discussie over het uitvoeren van beheer. Best practices zoals Itil voldoen niet of in mindere mate. Te sterk vasthouden aan werken ‘volgens het (Itil-)boekje’ is daar de oorzaak van. Er is een manier nodig om beheer uit te voeren en de uitvoering te verbeteren zonder al te lange maatwerktrajecten die moeizaam verlopen en vaak niet leiden tot het gewenste resultaat. De ism-methode (integrated service management)biedt hiervoor een goede oplossing.
Elke organisatie is afhankelijk van ict, en de wijze waarop ict-producten en diensten beheerd worden. Beheer bestaat op dit moment uit het toepassen van zogeheten ‘best practices’; werkwijzen die in praktijksituaties hebben aangetoond te werken.Veel organisatie vinden het echter moeilijk om gecontroleerd te werken, de prestaties inzichtelijk te maken, en klanten tevreden te stellen, op een zo efficiënte en effectieve wijze. Dit ondanks een ruime ervaring met it service management (Itsm). Het is dan ook de vraag wat hiervan de oorzaak kan zijn. Een van de oorzaken kan gevonden worden in het fenomeen best practice. Het nadeel van best practices is dat verschillende gedocumenteerde best practices onderling niet altijd goed op elkaar hoeven aan te sluiten. Denk bijvoorbeeld aan een overlap tussen Itil-processen als release en change management en de positionering van problem management als uitvoerend proces (terwijl de doelstelling, het voorkomen van zich herhalende incidenten als tactisch beschouwd kan worden). Ten slotte is er op dit moment al veel discussie over het blind opvolgen van ‘wat er in het boekje staat’. Binnen itsmf Nederland is door diverse gastsprekers dit blind opvolgen van de theorie omschreven als ‘frameworkfetisjisme, en wordt veelvuldig de stelling aangehangen dat best practices waar mogelijk vermeden moet worden. Het is echter niet de vraag of je helemaal zou moeten afstappen van best practices, maar de vraag hoe je er verstandig mee omgaat. Strak vasthouden aan wat ‘de theorie zegt’ is onverstandig, maar betekent nog niet dat de theorie volledig fout is. Het gaat er om hóe je met de theorie omgaat.
De ism-methode
Een van de ontwikkelingen die op het gebied van Itsm op dit moment gaande is, is de ISM-methode. De ism-methode is ontwikkeld door het bureau Hoving en van Bon als antwoord op de problematiek op het gebied van beheer. Het is een methode om de it-dienstverlening te organiseren, te borgen en continu te verbeteren. Ruwweg gezegd kan men stellen dat de ism-methode teruggaat naar de basis zoals deze in Itil v2 beschreven is. De ism-methode dient dan ook niet gezien te worden als een complete vervanging van het Itil-gedachtegoed; veel eerder is het een tot de basis omgevormde, gestandaardiseerde methode om beheer uit te voeren en continu te verbeteren. Deze methode bestaat uit drie elementen, te weten het framework, de gestandaardiseerde wijze van invoering en de support die beschikbaar is.Om een korte introductie te geven, wordt het framework dat binnen ism gehanteerd wordt nader toegelicht.
Ism-framework
Het ism-framework bestaat uit alle middelen (binnen de drie-eenheid people, process en product) die een it-beheerorganisatie gebruikt om de procesmatige werkwijze te ondersteunen en te managen. In het framework is er aandacht voor zaken als sla, rapportage, het overkoepelende procesmodel, de procesflow, procesplannen, rollen en functies en standaarddocumentatie en templates. De afbeelding laat zien hoe het procesmodel eruit ziet.
De termen in het procesmodel staan voor het volgende:
• Afspreken: er dienen tussen de klant en de it-beheerorganisatie afspraken gemaakt te worden over de dienstverlening;
• Leveren: er moeten operationele werkzaamheden verricht worden door de it-dienstverlener om de levering van it-diensten mogelijk te maken en blijvend te realiseren;
• Herstellen: als de functionaliteit in het geding komt door falen van ict-middelen,dan dient de dienstverlening hersteld te worden;
• Wijzigen: wanneer het gewenst is (vanuit de klantwens) of nodig is (om de dienstverlening te blijven garanderen) dienen er werkzaamheden uitgevoerd te worden waardoor it-middelen kunnen wijzigen;
• Informeren: het beschikbaar stellen van informatie zodat andere processen daarover kunnen beschikken en daardoor (beter) functioneren;
• Voorkomen: dit houdt in het beperken van risico's die een bedreiging kunnen vormen voor het leveren van de it-dienstverlening.
Vertaald naar ‘standaard' beheerprocessen levert dit de volgende "vertaling" op:
• Afspreken zou gezien kunnen worden als service level management;
• Wijzigen staat voor change management;
• Herstellen kan men zien als het equivalent van het incident management proces;
• Leveren is het uitvoeren van operations management;
• Informeren is gelijk aan configuration management;
• Voorkomen kan gezien worden als kwaliteitsmanagement en herbergt de kern van meerdere Itil-processen zoals problem management, capacity en availability management en security en business continuity management.
Kern van het procesmodel is dat de processen samenhangen via een gedefinieerde set van procesflows. Deze herbergen de meest voorkomende activiteiten zoals deze voorkomen in de praktijk. Te denken valt aan bijvoorbeeld de procesflow voor het afhandelen van een incident, dat verloopt via ofwel het herstel via een reset (met gebruik van operations management) ofwel via een wijziging (met gebruik van het proces change management, configuration management, operations management en afsluitend incident management). Al met al lijkt dit sterk op de procesflows die gevonden kunnen worden in Itil. Het verschil is dat ism uitgaat van een beperkte set aan processen en procesflows, die bovendien gestandaardiseerd zijn en out-of the box geleverd kunnen worden.
Deze out-of-the box levering komt neer het uitvoeren van twee fases. De eerste fase is de installatiefase. Hierin wordt in korte tijd (circa 3 tot 4 maanden) alle voorbereidingen getroffen om te kunnen starten met het procesmatig werken conform ism. De tweede fase is bedoeld om stapsgewijs ism als methode eigen te maken, met als ultieme doel het continu en stelselmatig verbeteren van de kwaliteit van de dienstverlening (en daarmee de kwaliteit van de beheerorganisatie, die groeit in volwassenheidniveau). De aanpassing in de werkwijze is pas afgerond als de medewerkers binnen een organisatie de vastgestelde werkwijze volgen zonder dat daarvoor veelvuldig voor bijgestuurd hoeft te worden. Vanaf dat moment kan de it-organisatie doorgroeien naar een volwaardig professionele organisatie waarin verandering de constante factor is.
Afweging
De ism-methode is voor veel organisaties een nuttig alternatief ten opzichte van de "maatwerk" trajecten om beheer effectief en efficiënt in te regelen over de volle breedte van beheer. Ism borduurt, zoals aangegeven, voort op de best practices en vertaald deze in onder andere de inrichting van tooling, processen en procedures. Gezien de snelheid en de volledigheid van een ISM-traject levert dit meerwaarde op voor organisaties; in relatief korte tijd kan het geheel aan beheerprocessen ingericht worden inclusief tooling en inclusief het aanleveren van de werkwijze voor het continu verbeteren van het uitvoeren van beheer. De ism-methode is echter niet altijd geschikt; incrementele, beperktere trajecten voor bijvoorbeeld de verdere professionalisering van één of een klein aantal processen kan veel beter plaatsvinden via aparte verandertrajecten. Organisaties moeten dan ook een kosten-baten afweging maken als het gaat om het soort traject dat zij in willen gaan om beheer te verbeteren. Welk traject ook wordt gekozen, Itil als best practice is prima te hanteren, als de klant en diens situatie maar altijd het uitgangspunt blijft.
Ik ben het met het allereerste deel van deze beredenering wel eens. Klaarblijkelijk weten veel managers nog niet dat je ITIL moet zien als een ‘scalable’ blauwdruk waarop je je organisatie kunt baseren. Het is feitelijk niet meer dan het aangeven van richtlijnen die zaken zouden moeten kunnen vereenvoudigen.
Wat ik in de beredenering ook mis, en neem me niet kwalijk als ik dat even benoem, want, dat is nog veel belangrijker dan het hele ITIL gebeuren en ook het hier gepropageerde ISM model, er wordt nergens gesproken van en duidelijk weergave van IT als materie en de wijze waarop IT zich als materie beweegt.
Het is namelijk helemaal niet zo zeer dat er met de implementatie van ITIL als basis erg veel dingen mis gaan met alle prijskaartjes van dien. Het gaat namelijk daarvoor al mis namelijk dat je erg veel mensen hebt die werken aan en met een materie maar niet weten hoe de materie zich beweegt. Zou men namelijk de moeite doen zich dat wel eigen te maken, dan zou je plots ontdekken dat ITIL veel meer ‘hout snijd’ als basis dan dat men nu tegen ITIL aan schopt.
Ik kan u namelijk nu al voorspellen dat ISM een prijskaartje zal hebben waarvan de vraag zal zijn of het verdienmodel de ROI later nog zal dekken.
Mijn voorstel? Ga eerst eens aan de slag met de materie, zet dan je model op die zich dan conformeert aan de werking van die materie en dan ga je doen waarvoor IT uiteindelijk is ontwikkeld. Besparen. Je kunt natuurlijk vele nieuwere of aangepaste modellen bedenken, als je niet weet hoe de IT als materie beweegt, blijf je nog heel erg vaak tegen dit soort uitdagingen aanlopen.
@ NumoQuest,
ITIL is sterk aan het verouderen en is nodig aan vernieuwing toe. De tijd dat ITIL de oplossing was voor alles ligt al ver achter ons. Maar hier verschillen de meningen nogal over dat is iedereen zijn of haar goed recht.
Ik zou graag nog eens een artikel hier op de Computable van je willen zien waar in je je veel gemaakte opmerking: “Aan de slag met de materie en de daarbij behorende modellen” eens nader toelicht en beschrijft.
Aangezien je het hier redelijk vaak over hebt, begin je mij nu toch echt zeer nieuwsgierig te maken hoe je hier tegen aan kijkt.
Nog even een reactie op een opmerking over het prijskaartje dat aan ISM zou hangen, en de vraag of het verdienmodel de ROI later nog zal dekken. Ongeacht of je nu ITIL implementeert of kiest voor de ISM-methode, kosten zullen gemaakt moeten worden als in de praktijk blijkt dat “beheer” niet effectief en efficiënt wordt uitgevoerd. Dit heeft in principe niet veel met de methode te maken, sterker nog; veel ITIL-trajecten vallen duurder uit dan ISM-trajecten, vanwege o.a. de grote scope, complexiteit en dergelijke. Vandaar ook de afweging om bij een groter verandertraject te kiezen voor standaardisatie (via ISM) en bij kleinere, incrementelere veranderingen ITIL te pakken en (en hier zou ik de nadruk op willen leggen) het beste uit die best practice te pakken.
Jeroen,
Ik kan mij goed vinden in je bovenstaande reactie. ITIL begint in mijn optiek steeds meer iets uit het verleden te worden aangezien het qua vorm en kosten steeds minder goed bij deze dynamische tijd gaat passen.
Opmerkelijk om in de reacties te stellen dat ITIL verouderd is terwijl ISM hier sterk op gelijkt. Dat ITIL een negatieve bijklank heeft gekregen ligt niet zo zeer aan het framewerk maar eerder aan de mensen. Sommige mensen verschuilen zich nu eenmaal liever achter procedures zodat ze zelf niet hoeven na te denken.
Een andere veel gehoorde klacht is dat implementatie van ITIL veel tijd en geld kost, wat bij ISM niet veel anders lijkt. Een levering van 3 tot 4 maanden voor eerste fase en tijd voor tweede fase niet gegeven lijkt me geen out-of-the-box, eerder veel geld out-of-the-pocket implementatie.
In reactie stellen dat er kosten gemaakt moeten worden als ‘beheer’ niet effectief en efficiënt is lijkt me nogal een contradictio in terminis. Ik kan het beheer bijvoorbeel heel effectief invullen door veel mensen in te zetten. Maar ik kan ook het tegenovergestelde kiezen zodat het efficiënt is.
Zoals ik hele verhaal nu lees is het de zoveelste beschrijving maar geen automatisering. Ik geef in deze NumoQuest dan ook gelijk, ga nu eerst eens kijken wat er nodig is. Een bottom-up benadering door de al aanwezige kennis, hulpmiddelen en beschrijvingen te hergebruiken scheelt een boel geld.
Wat ik vaak mis bij de beheersmodellen is de gebruikersperceptie.
Zomaar even wat voorbeelden uit het verleden ter illustratie:
– applicatie X werkt niet, dus ik (als “domme” eindgebruiker) heb een probleem. De ITIL purist aan de andere kant van de lijn: nee meneer, het is een incident. => Als eindgebruiker ben ik hier eigenlijk helemaal niet geïnteresseerd; ik wil gewoon dat mijn applicatie weer werkt!
– applicatie X werkt niet na inloggen ’s ochtends, ik bel de helpdesk. Na 10 minuten en een standaard vragenlijstje werkt het nog steeds niet. Reactie helpdesk: sorry meneer, ik zal dit moeten doorzetten naar de 2e lijn. Men neemt binnen een dag contact met u op. ==> Sorry, maar ik heb een deadline aan het eind van de dag waarvoor ik deze applicatie nodig heb. Heel leuk die SLA’s, maar die worden afgesloten door mensen die géén affiniteit hebben met mijn belangen en deadlines 🙁
– ik heb over 2 weken 500 GB aan extra diskruimte nodig voor project X. Sorry meneer, dat kan helaas niet. In uw SLA staat dat u maximaal 50 GB aan mag vragen. Geen probleem, mag ik dan 10 keer 50 GB van u? Nee, sorry dat gaat niet. De server zit vol, en als we deze uit willen breiden moeten we eerst …….. enz enz enz
Ik snap best dat je aan de beheerskant afspraken en processen wil gebruiken om het werk beter te managen, maar als eindgebruiker ben ik hier helaas niet altijd bij gebaat.
Bij ISM, zoals beschreven in dit artikel, maar ook bij ITIL zoals ik er destijds mee heb mogen werken, mis ik een terugkoppel-lus met de eindgebruiker, op basis waarvan de service bijgesteld kan worden in de loop der tijd.
(wellicht dat dit er wel ergens inzit, maar het is mij in ieder geval niet bekend)
De koning is dood, leve de koning.
Een mooi artikel dat inmiddels past in een traditie. Discussie over de inzet van practices is er volgens mij al sinds die practices als “good” of “best” werden opgeschreven. Ik wil van ISM best geloven dat het handig is als bepaald (procedure)schrijfwerk al gedaan is. Een integrale (PPT) aanpak is in deze tijd niet meer weg te slaan (ik mis overigens de P’s van Performance en Partners). En het versimpelen van een wereldbeeld tot behapbare brokken helpt uiteraard om de acceptatiegraad te vergroten (overigens doet MOF daar ook een aardige poging toe). Laten we nu verder niet doen alsof je hiermee de Nobelprijs wint.
Laat ik me verder beperken tot een paar specifieke opmerkingen.
Out of the box processen: wat is dit anders dan dat processen al zijn uitgetekend en de impact daarvan op bijv. tooling inrichting al is uitgewerkt (lijsten met categorien, afsluitcodes, gewenste oplosgroepen e.d.). Je hebt je SOLL wel in beeld maar je zult dit nog steeds moeten mappen op je IST (gap analyse). Dat betekent volgens mij nog steeds niet dat een organisatie hier “meteen” mee aan de slag kan (zoals de term ‘out of the box’ voor mij suggereert). Als je dit met voldoende mandaat wel kan afdwingen kun je dat met elke willekeurige methodiek.
Overlap tussen release en change management en de positionering van problem management als uitvoerend proces? Die snap ik niet. Wat wordt bedoeld met ‘uitvoerend’? ‘Herstellend’? (wat change & release management zouden moeten doen?). Dat is dan een leesfout van de gebruiker, niet van de practice. Overigens deel ik de stelling dat je problem management op tactisch niveau zou moeten positioneren.
Het vermijden van een best practice lijkt mij persoonlijk nogal onhandig. Hoe doe je dat dan? Ga je dan niet meer aan event management doen? Sluit je je service desk? Praat je niet meer met die nare klanten?
“De aanpassing in de werkwijze is pas afgerond als de medewerkers binnen een organisatie de vastgestelde werkwijze volgen zonder dat daarvoor veelvuldig bijgestuurd hoeft te worden.” Dat doet me denken aan de ‘ITIL projecten’ (brrr, wat een woord) van 12-15 jaar geleden. Een oorspronkelijke projectscope werd veelvuldig verlengd en mondde uit in een nazorgproject, fase 2 (en 3, en 4) of iets dergelijks. Puur omdat men (te laat) signaleerde dat er aan het einde van fase 1 nog teveel wildgroei, onduidelijkheid en anarchie was en men verzuimde om verbeteringen op dit vlak als kritische succesfactor tijdig door te voeren. Hoe zal het nu anders gaan? Waar ligt de garantie dat je die mensen die na al die jaren nog steeds zo strikt het ITIL boekje volgen, nu met ISM in 3-4 maanden om hebt? Als je dat lukt met ISM moet het ook met ITIL, MOF, ASL, BiSL, ValIT, CobiT of MOF kunnen. Het zijn tenslotte mensen die gebruik (moeten) maken van een practice.
@PaVaKe: die opmerking over de helpdeskmedewerker die zegt “u hebt geen probleem, u hebt een incident”, die vond je een paar jaar geleden standaard in elke ITIL-kritische column als argument tegen. Ik heb gelukkig de afgelopen 17 jaar nog nooit een helpdeskmedewerker aan de lijn gehad die me dat meende te moeten vertellen.