Regelmatig lees ik verhalen over it-projecten die niet op tijd zijn afgerond, het budget overschrijden of waar de it-dienstverlening niet voldoet aan de eisen van de business. Deze ontwikkelingen zorgen er mede voor dat de rol van de huidige it-manager verandert. De lat komt steeds hoger te liggen.
De business verwacht immers niet alleen it-middelen, maar volwaardige it-diensten en vaak ook inbreng over de automatisering van bedrijfsprocessen. In plaats van een operationele rol zal de it-manager daarom steeds vaker de it moeten afstemmen op de business. De business moet immers zo optimaal mogelijk functioneren.
Om deze verbetering in de dienstverlening van een it-afdeling te waarborgen wordt vaak Itil toegepast. Itil is een referentiekader voor het inrichten van beheerprocessen en gaat uit van concepten en oplossingen die in de praktijk zijn toegepast. Versie 3 van Itil omvat momenteel 29 processen. Nu it-afdelingen echter steeds vaker worden gepusht om meer te doen met minder, is Itil vaak te omvangrijk en gedetailleerd om volledig uit te kunnen rollen. Het is lastig om uit deze grote hoeveelheid processen de juiste te kiezen die echt bijdragen aan de doelstellingen.
Zes in de basis
Om de it-afdeling optimaal te laten functioneren met een overzichtelijk aantal processen is op basis van Itil, ISM ontwikkeld. Bij ISM is het grote aantal processen van Itil teruggebracht naar zes. Deze reductie is niet simpelweg een kwestie van het schrappen van processen, maar is mogelijk door op een andere manier naar de processen te kijken. Binnen Itil blijkt een deel van de processen grote overeenkomsten te hebben.
De kracht van ISM is om dat deel van de processen niet als proces aan te merken, maar als functie. Zo onderscheidt ISM de zes basisprocessen Service Level Management (SLM), Change Management (CHM), Incident Management (IM), Operations Management (OM), Configuration Management (COM) en Quality Management (QM). Processen worden zo weer tot de basis teruggebracht. Dit klinkt wellicht te mooi om waar te zijn, daarom zal ik dit illustreren met twee voorbeelden.
Verantwoordelijkheid claimen
Binnen ISM wordt voor de meest belangrijke aandachtsgebieden een verantwoordelijke aangesteld die alle zes de basisprocessen afdekt. Neem een securitymanager. Volgens het ISM-principe is de securitymanager vanuit zijn functie verantwoordelijk voor alles wat met beveiliging te maken heeft. Binnen itil zijn hier aparte processen voor gedefinieerd. Als je echter kijkt naar de taken die hieronder vallen, kan de securitymanager prima uit de voeten met zes processen, alleen dan gespecificeerd voor beveiliging. Zo zijn er securityafspraken gemaakt binnen sla's onder Service Level Management, zijn er bepaalde beveiligingsveranderingen doorgevoerd en worden er incidenten opgelost met een securityelement. Met Quality Management kunnen risico's worden onderzocht die eventueel met veranderingen kunnen worden opgelost. De securitymanager dekt dus alle basisprocessen voor zijn functiegebied af en zal binnen de processen zijn verantwoordelijkheid moeten claimen om zijn kpi's te bewerkstelligen.
Een ander voorbeeld is Capacity Management. Ook hiervoor geldt dat als capaciteit een belangrijk onderwerp is voor de organisatie er afspraken binnen sla's zijn gemaakt. Hierbij gaat het om vragen als de mate waarin een database is gevuld of het maximaal aantal gebruikers dat een database aankan. Het loont de moeite om hier een verantwoordelijk persoon voor aan te stellen die de zes processen gebruikt om dit onderwerp te borgen. Ook hier geldt voor alle processen dat de capacitymanager extra let op veranderingen en incidenten die over capaciteit gaan, maar hij zal ook bewaken of er voldoende periodieke controles zijn opgenomen in Operations Management.
Afbakenen
Het terugbrengen van het aantal processen en het aanbrengen van een scheiding tussen een proces en een functie zorgt voor overzichtelijkheid en duidelijkheid binnen it-servicemanagement. Bij het afstemmen van een service level agreement zal de securitymanager betrokken worden voor het afstemmen van de details over security en de mate van beschikbaarheid zal met de verantwoordelijke availabilitymanager worden afgestemd. Verantwoordelijkheden zijn afgebakend en de it-manager kan zich richten op zaken die bijdragen aan het functioneren van de business.
Het lijkt wel alsof er gedacht is: “Als we het niet gebruiken zal het ook wel niet nodig zijn.”
Capacity management een onderdeel van een functie noemen, deze vervolgens niet borgen met processen lijkt me hier een voorbeeld van. En als je iemand ervoor verantwoordelijk maakt, omdat de organisatie het WEL belangrijk vindt dan zal deze toch vroeg of laat processen gaan opstellen.
Nieuwste versie van ITIL ziet capacity trouwens als 3 subprocessen die elk een deel van de service bestrijken. Eén daarvan, nl. service capacity management zit misschien opgesloten in de SLA maar dat geldt meestal niet voor de capaciteit van de resources. En omdat de business afhankelijk is van de service die zelf weer afhankelijk is van de resources weet ik al waar de ‘problem manager’ straks de problemen kan zoeken.
@edekkinga: Wat er is gedacht is: “als je het niet nodig hebt moet je het ook niet willen gebruiken”. Het grote verschil tussen ITIL en ISM is dat ITIL een framework is en ISM een procesarchitectuur biedt, ondersteund door een invoeringsmethode. ISM gaat over slimmer werken, terug naar de basis en gebruik maken van generieke processen zoals ze negen van de tien keer uit ITIL implementaties (als die al lukken) tevoorschijn komen. IT-serviceorganisaties kiezen vervolgens zelf de procedures die passen bij hun beleid, afspraken en standaarduitvoering. Per procedurestap maakt men werkinstructies als binnen de organisatie specifieke afspraken zijn gemaakt over wijze van afhandeling, wie of welke rol dat doet, waar de benodigde informatie is te vinden en volgens welke normen e.e.a. wordt gerealiseerd.
Indien binnen een organisatie een functionaris specifiek is belast met het managen van de capaciteit, bijvoorbeeld omdat daar in de SLA-specifieke afspraken over zijn gemaakt, dan is zijn rol met betrekking tot die specifieke service door de processen heen vastgelegd. Daarmee wordt het signaleren en oplossen van incidenten of risico’s, alsook de registratie van alle relevante informatie op het gebied van capaciteit, zijn verantwoordelijkheid. Hij volgt daarbij de procedures zoals die binnen de IT-serviceorganisatie zijn vastgesteld, gebruikt de daarvoor opgestelde werkinstructies, doet voorstellen voor het aanpassen daarvan of het schrijven van nieuwe werkinstructies en draagt er zo aan bij dat zijn kennis wordt geborgd en kan worden toegepast door anderen.
Processen doen niets uit zichzelf. Een procesmanager richt in, faciliteert en is verantwoordelijk voor het correct uitvoeren van “zijn“ proces conform de daarover binnen de serviceorganisatie gemaakte afspraken. Hij plant en coördineert alle activiteiten binnen het proces. Een ISM procesmanager kan dus een functionaris, ook als die in de lijn niet onder zijn verantwoordelijkheid valt, aanspreken op de wijze waarop hij in zijn rol de activiteiten in het proces uitvoert. Indien nodig (afhankelijk van het gekozen PMM niveau) escaleert de procesmanager naar de lijnmanager. Deze laatste is dan verantwoordelijk voor het functioneren van de persoon.
Binnen ISM heb je dus geen capacity manager meer nodig, maar alleen de rol of functie capacity specialist. En die maakt gebruik van de binnen de verschillende processen (en als het goed is: mede door hem) vastgelegde werkinstructies op het gebied van het leveren, herstellen, wijzigen, registreren en bewaken van de afgesproken capaciteit.
@Ewout
kun jij in ITIL de procesbeschrijving vinden van zoiets als capacity management of security management? Ik niet. En ik heb een hoop ITIL-boeken gelezen 😉
Het probleem zit ‘m in het gegeven dat ITIL de term proces ‘nogal losjes’ gebruikt, zoals ze in verschillende versies zelf ook hebben toegegeven. ITIL bevat een zeer waardevolle set met handreikingen (‘best practices’) voor hoe je met bepaalde praktische zaken om kunt gaan. Helaas draagt ITIL niet echt bij aan procesgericht werken: zoals in de laatste versies te lezen staat is ITIL ‘lifecycle-gericht’, het stadium waarin processen centraal stonden is ver achter ons gelaten.
Helaas zijn vele organisaties nou juist op zoek naar de manier om hun processen onder controle te krijgen, vanuit de overtuiging dat processen de korte weg naar het klantbelang zijn. De practices van ITIL zijn daarbij prima bruikbaar, maar dan als inspiratie voor de toepassing die je zou kunnen nastreven. De kunst is dan om een aanpak te vinden die je daar ook eenvoudig, efficiënt en effectief heen brengt. Dat is de aanpak waar Michiel het over heeft.
Die aanpak streeft naar een eenvoudige en leerbare werkwijze, waarbij er strikt onderscheid wordt gemaakt naar processen, procedures, werkinstructies, en naar de organisatieonderdelen die daar gebruik van maken. En dat is de plek waar je Michiel’s functies tegenkomt. Functies zijn dan organisatorische eenheden die gespecialiseerd zijn in de uitvoering van een bepaald type werk en verantwoordelijk zijn voor bepaalde resultaten. Zoals een capacity manager of een capacity management team. Of een security-team.
Om nou te voorkomen dat vervolgens iedereen maar vanuit die positie z’n eigen werkwijzen bedenkt, wijst Michiel op het feit dat de organisatie (hopelijk) al vastgelegde processen en procedures heeft, die alleen nog hoeven te worden toegepast op het taakgebied van die functie (en als die processen er nog steeds niet zijn dan wordt dat hoog tijd!). Een taakgebied/functie zoals security management of capacity management hoeft dan alleen maar te leren om die processen voor z’n karretje te spannen: maak gebruik van bestaande werkwijzen rond change management, rond incident management, rond service level management, etc., en pas die toe op je eigen domein (capacity, security, continuity, availability, etc.). Daarmee voorkom je redundantie en inconsistentie in de besturing van de organisatie, en bereik je een efficiënte inzet van werkwijzen die goed zijn ingesleten en waar mensen al verantwoordelijk voor zijn gemaakt (change managers, incident controllers, etc.). En je gebruikt ITIL eindelijk op een manier die tot effectieve en efficiënte organisaties leidt.
Stel daar tegenover het scenario waarin elke functie z’n eigen werkwijzen bedenkt, en je nachtmerrie is geboren. De ISM-methode die Michiel aanhaalt werkt met een zuiver procesmodel waaruit procedures worden afgeleid waaruit weer werkinstructies worden afgeleid, die vervolgens kunnen worden toegepast op zaken rond capacity, security, en wat je maar wilt. Maar dan wel onder architectuur, in een logisch, herkenbaar, en leerbaar formaat. Als je die werkwijzen vervolgens integraal ondersteunt met de juiste tooling kun je een heel efficiënt werkende organisatie krijgen die zonder problemen z’n taak m.b.t. capacity of security uitvoert, en daarbij ook nog dankbaar gebruik maakt van de handreikingen die ITIL daarvoor al zo’n 25 jaar biedt. Als je echter ITIL in je organisatie gaat “invoeren” zoals dat in de boeken beschreven staat, dan krijg je de ellende die we even zoveel jaren ook kunnen aantreffen. Gelukkig hoeft dat niet meer. Organisaties zoals transavia.com, FloraHolland, UMCG, DUO, en tientallen andere hebben dat intussen al geleerd en kunnen hun functies efficiënt gebruik laten maken van hun processen. Nu de rest nog.
Jan van Bon
Ik heb ook een hoop boeken gelezen, niet enkel over ITIL maar ook om de technologie te doorgronden. ITIL geeft zelf tenslotte als kritische succesfactor voor capaciteitsmanagement aan dat er kennis nodig is van huidige en nieuwe technologiën. En als risico het ontbreken van betrokkenheid van de business, ontbreken van accurate informatie en te bureaucratische processen.
Niet zelden ontbreekt namelijk accurate informatie vanuit de infrastructuur omdat een incident registratiesysteem geen interfaces heeft met de infrastructuur. Hierdoor ontstaat een theoretisch ´kanban´ systeem waarbij sommige kaarten geen relatie hebben met de voorraad resources die er is. Een werkinstructie is hierdoor soms niet meer dan een titelblad, een leeg kaartje of incidentnummer waarmee het proces gevuld wordt.
De duivel zit nu eenmaal in de details en deze steekt steeds vaker zijn kop op omdat mede door virtualisatie resources vaak als commodity gezien worden. Bezetting van resources was dan ook één van de verkoopargumenten voor virtualisatie en centralisatie van de opslag. Rationaliseren van processen, functies en activiteiten vraagt dus ook aanpassing van het ´mandje´ Component Capaciteitsmanagement (CCM). Laatst heb ik hier met opslag als uitgangspunt nog over geschreven en de I/O heatmap (slide 10) in presentatie http://www.slideshare.net/edekkinga/opslag-bepaalt-het-systeemprestatieniveau laat zien dat efficiëntie op component niveau vaak nog ver te zoeken is.
Dat implementatie van ITIL naar de letter van de boeken niet werkt lijkt me logisch, het zijn tenslotte maar richtlijnen. Maar gooi niet het kind met het badwater weg omdat bepaalde processen niet passen binnen een product dat gebruikt wordt voor ITSM. ´Reversed enginering´ van service processen betekent dat je aanpast wat niet werkt, toevoegt wat ontbreekt en verwijderd wat niet nodig is. Maar ervaring leert meer dan 1000 boeken en de ‘best practices’ van ITSM modellen blijven in mijn ogen toch vooral theorie.
Want naast boeken lees ik ook nog kranten en vraag me daarom regelmatig af of problemen met bijvoorbeeld beveiliging soms niet in de werkinstructies of procesbeschrijvingen zit. Natuurlijk chargeer en generaliseer ik hier en banjer als de spreekwoordelijke olifant door de porseleinkast van de Babylonische spraakverwarring in definities. Maar veel beheerorganisaties zijn ingericht naar het ´OSI-model´ zodat opslag-, netwerk-, server- en applicatiebeheer eilanden zijn geworden. Of delen hiervan zijn uitbesteed waardoor bestaande processen weer aangepast moeten worden. In theorie klopt het dan allemaal maar in de praktijk is toch nog vaak roeien met de riemen die je beloofd zijn.
In de ISM-methode is het kind zeker niet met het badwater weggegooid: ISM gebruikt nuttige kernelementen van beschikbare frameworks, vult die aan, herstructureert ze, en maakt daar een eenvoudige werkzame methode van. Daarmee krijg je dan een toepasbare werkwijze waarbij juist dat kind de beste kansen krijgt. En of dat kind nou Itil, ASL, Cobit, MOF of nog weer een andere bloedgroep heeft, maakt voor ISM niet uit. Het gaat er immers juist om dat we de beste componenten uit al die bloedgroepen combineren tot een efficuient en werkzaam geheel. En ISM is nou juist gebaseerd op de ervaringen die al sinds de allereerste toepassing van die frameworks zijn gemaakt – precies zoals je zelf aanbeveelt.
Je gaat in je reactie vooral in op techniek, maar voor een besturingsmethode maakt techniek juist niet uit. Indachtig het aloude adagium “Organiseer voor je automatiseert” zorgt ISM voor die organisatie, waarna je het resultaat naar eigen wens kunt toepassen op de techniek waar je aandacht aan wilt besteden. Die techniek verschilt overigens weer per organisatie – precies de reden waarom je eerst een generieke methode moet invoeren en deze daarna moet toepassen op een lokale situatie. En dat is precies wat ISM-gebruikers doen. Of ze nou een bloemenveiling, een ziekenhuis, een wegenbouwer, een woningcorporatie, een onderwijsinstelling, een laboratorium, een verzekeraar, een energieleverancier, of iets anders zijn. Of ze nou opslagproblemen hebben, problemen met het gedrag van hun medewerkers, ontevreden klanten, of domweg geen grip op hun eigen werkwijze, in alle gevallen kan een methodische werkwijze de organisatie leren om z’n eigen problemen aan te pakken en op te lossen.
Michiel ging daarbij in op een van de vele aspecten die daarbij geregeld moeten worden: je moet zowel je organisatie als je processen op orde hebben. En daarbij is het verrekte handig als je het verschil tussen processen en functie inziet.
Jan van Bon,
Als fel verdediger van je eigen methodiek geef je een aantal punten aan waar ik het zeker niet mee oneens ben en inderdaad heb ik een sterke techniekfocus. Maar vaak, en jij doet het hier ook, wordt deze als standaard gezien wat het vaak niet is, waardoor aansturing met een blinddoek voor gedaan wordt en grip hierop ontbreekt.
Want zoals jezelf stelt is het adagium ‘Organiseer voor je automatiseert’ al oud, stokoud, omdat het tegenwoordig vaak de business is die bepaalt wat er komt. Deze vergeten niet zelden de non-functionele eisen die beheersbaarheid verbeteren zoals aansluiting op de management protocollen die er in de infrastructuur gebruikt worden.
In de bekende architectuurmodellen kom je daarom ook steeds vaker wolken tegen, iets wat er is of zou moeten zijn maar waarvan we de werking niet geheel begrijpen. Dat is een methodische werkwijze om lijnen in het zand te trekken, die zolang de zee er niet over heen spoelt inderdaad een referentie geven.
Maar bijvoorbeeld server- en desktop virtualisatie zorgt er nogal eens voor dat er discrepantie is tussen theoretische CI’s en wat er werkelijk actief is in de infrastructuur. Je kunt, hoe graag je het ook wilt proces en organisatie namelijk niet geheel loskoppelen van de techniek die steeds vaker en sneller veranderd.
Zoals in eerste en tweede commentaar al aangegeven zie ik weinig toegevoegde waarde van ISM als deze refereert aan bestaande methodieken. Herdefiniëren van functies, anders groeperen van processen en voortbouwen op bestaande activiteiten is niet meer dan een extra ‘schilletje’, dunnetjes nog eens overdoen wat ITIL en MOF al doen.
Laatste heeft trouwens een sterke link met techniek en geeft met Service Center niet alleen goede beschrijvingen van functies (SMF’s), processen en activiteiten maar ook de middelen om beheer of een groot deel hiervan te automatiseren. En het MSF reikt ook nog eens verder dan enkel beheer maar zorgt dat er ontworpen wordt voor beheer.
Goedemorgen heren.
In deze discussie ontstaat er een duidelijk opsplitsing in onderwerpen en zie ik eigenlijk twee discussies ontstaan die niet op elkaar aansluiten. Belangrijk is om duidelijk voor ogen te houden dat mijn artikel gaat over het zo effectief en efficiënt mogelijk aansturen van een IT organisatie waarbij het niet uitmaakt of de klant intern of extern is. Tevens maakt het ook niet uit welke technologie er beheerd wordt. Het mooie van een goed procesmodel en een goede invoeringsmethode is namelijk dat het techniek onafhankelijk is. Door een specifieke architectuur of een bijzondere klantsituatie kan het zijn dat er binnen de processen of functies wel een specifieke focus is. Daarmee blijven nog steeds dezelfde processen van kracht die elementair voor de dienstverlening.
Doel van dit artikel is een wig te slaan in het denken dat meer processen de oplossing is voor een betere dienstverlening en uit te leggen dat met minder processen en het benoemen van de juiste functies of teams (aandachtsgebieden) er versimpeld kan worden. Door versimpeling kan men overhead terugdringen waardoor kosten bespaard zullen worden. Tevens kunnen de diverse teams binnen een IT afdeling weer overzicht krijgen en daardoor veel effectiever en efficiënter werken aan een zo hoog mogelijke klanttevredenheid.
@Michiel
Meer of minder processen is niet mijn punt van discussie, het gaat me om de ruimte die er is tussen praktijk en theorie. Een goed werkend proces, wat misschien niet conform een methodiek als ITIL, ISM of COBIT is kan vaak de aansturing verbeteren. Of zoals ik het vaak zeg: “Je kunt niet verbeteren, veranderen of besturen wat je niet weet”
Beste Michiel, ik zit volgens mij wat langer in het vak dan jij en de ontwikkeling die jij schetst is niet nieuw, zoals jij suggereert. Dat IT afgestemd moet worden op ‘business’ stond al in de boeken voordat jij geboren werd, vermoed ik. Ik vind het jammer dat er wellicht (jongere) vakgenoten dit type artikelen lezen en dan jouw waarheid beschouwen als de werkelijkheid. Vind je het gek dat ‘de business’ IT-ers vaak niet begrijpt, als je schrijft dat die afstemmging nu of recentelijk pas als nodig zou worden gezien….
Succesvol zijn in het IT vak wordt niet gerealiseerd met methoden. Niet met ITIL en ook niet met ISM. Waarvan je jammer genoeg alleen de relatie met ITIL uitlegt, waar ISM volgens mij (veel) verder gaat dan ITIL. Het fundamentele verschil, zoals Jan mij dat ooit uit heeft gelegd, tussen ISM en ITIL/ASL etc zit niet in functies vs processen maar in de best practices. ITIL voldoet ook helemaal prima voor iemand met verstand van zaken. Maar het vergt altijd aanpassing naar een specifieke situatie. En omdat er daar al zoveel van zijn gedaan, is met ISM iets heel moois gedaan: verzameling van kennis en ervaring gebundeld, zodat ook minder ervaren mensen daarvan kunnen profiteren.
Een van die best practices is om beter inzicht en overzicht te houden, simpeler, daarom een andere -logischer- indeling in processen.
Ik zou het erg fijn vinden als wij in dit mooie vak van IT minder bezig zouden houden met zogenaamde noviteiten en trends en verschillen maar met main stream doen waarvoor het vak ongeveer 30-40 jaar geleden is opgezet: organisaties ondersteunen met informatie en communicatie technologie. Ondersteunen is wat anders dan vermoeien en lastig vallen.
ISM is een -mooie- best practice gebaseerd op een aantal -meer complexe en lastig hanteerbare- methoden/raamwerken maar gaat ook verder dan dat. Gebruik die ervaring aub maar beperk je dan tot wat het is en niet als onderdeel van een hoegenaamde verandering van het vak of de IT-manager. Want dat is simpelweg onzin.