Op kleine schaal is computersystemen beheren niet zo moeilijk. Thuis ben ik bijvoorbeeld de enige systeembeheerder, en hoef ik alleen met mezelf te overleggen.
Maar als het groter wordt kan je het niet meer in je eentje af. Er zijn meer mensen nodig, en de verantwoordelijkheid moet verdeeld worden over die mensen. Dat introduceert taakverdeling en overleg tussen die mensen, zodat die hun activiteiten kunnen afstemmen. Om dat een beetje goed te doen moet je dat formaliseren in processen.
De Information Technology Infrastructure Library (ITIL) is een soort van standaard om tegen beheer aan te kijken. Velen hopen dat ITIL ze helpt om hun beheer op een hoger niveau van kwaliteit te brengen. Maar ik zal uitleggen dat het ijdele hoop is om te denken dat ITIL processen levert om je beheer mee te doen.
Overleggen met jezelf gaat een stuk sneller dan overleggen met iemand anders. Dat is vergelijkbaar met het verschil tussen iemand bellen en hem of haar een brief per stoomboot versturen. Een software-installatie bij mij thuis kan ik helemaal zelf overzien. In een grotere it-organisatie is het beoordelen van de gevolgen van een uitbreiding een stuk lastiger, en vergt allerlei gedocumenteerde tussenstappen.
De inrichting van je proces is dus afhankelijk van de snelheid van die communicatie en van de opdeling van het werk. Naarmate je beheerorganisatie groter wordt, wordt het werk verder verdeeld, en krijg je dus andere processen. Bovendien maakt het ook nog uit of dat werk is uitbesteed, en onder welke voorwaarden. Denken dat ITIL je goede processen kan voorschrijven is dus net zo hopeloos als denken dat ITIL je vertelt hoeveel mensen je beheerorganisatie nodig heeft.
ITIL is meer een datamodel dan een procesmodel. ITIL zegt bijvoorbeeld dat je incidenten moet bijhouden en de problemen die de oorzaak zijn van die incidenten. Ja, we weten dat we die dingen moeten doen, maar ITIL zegt ons niet hoe we dat moeten verdelen over onze mensen, afdelingen en leveranciers. Daar moeten we toch echt zelf over nadenken.
Het (Itil) proces is er voor de medewerkers en de medewerkers zijn er niet voor een (Itil)proces. De schrijver van dit artikel maakt een enigszins negatieve kantekening bij Itil, maar het begint met de wil van mensen/medewerkers om de (interne) klanten goed te bedienen. Daarbij kan Itil een goed hulpmiddel zijn.
Alles staat en valt bij een goede communicatie. als er geen goede communicatie is zal Itil bij voorbaat mislukken, maar ook een hoog business afbreukrisico zijn, immers de communicatie is niet op orde!
De schrijver moet procesvorming en communicatie niet met elkaar vermengen en hiervan een negatieve vermenigvuldiging maken. Het 1 kan zonder het andere en beide zaken moeten dan ook los van elkaar gezien en aangepakt worden.
Hebben we eindelijk een verzameling van “best practices” die we kunnen gebruiken om onze eigen processen te ondersteunen lijkt het hier of we terug verlangen naar de “horror of the 80-ties”: het gevreesde methologie (SDM anyone?)
Laten we in hemelsnaam niet het fout maken die zo veel mensen toen maakten, en goede professionals tot wanhoop dreven: een methologie kiezen, deze omsmelten tot het gouden kalf en allemaal in aanbidding ervoor buigen (of barsten). ITIL heeft al genoeg van deze kenmerken meegekregen om je buikpijn te geven (ben jij al gecertificeerd? JA, maar vraag niet in wat)
Processen zijn altijd maatwerk, ITIL levert een aantal handreikingen om deze te ondersteunen en efficiënt in te richten. Er is bestaat geen “one size fits all”, nergens, en we moeten er in hemelsnaam niet meer naar streven.
ITIL biedt inderdaad niet meer dan een standaard checklist (maar wel een heel complete), een kapstok voor het ophangen van mogelijke aktiviteiten in een IT-beheer omgeving.
Hoe die aktiviteiten verder verdeeld kunnen worden over processen en rollen, dat is weer afhankelijk van de organisatie (struktuur&politiek: matrix/hierarchisch, in/extern, on/near/offshore, afdelingen, rapportage/dotted-lijnen, tools, etc).
Uiteindelijk worden die aktiviteiten deels geautomatiseerd en deels uitgevoerd door mensen. Wil eea als een geheel werken (zoals bij dhr. van Eijk thuis) dan is communicatie daar dan weer de bindende faktor bij. En ja: het is zinvol vooral die goed onder de loep te nemen, want precies daar schuilt de overhead (vertraging, onduidelijkheden, misverstanden, politiek) t.o.v. een 1-mans IT-beheersorganisatie.
Een beetje flauwe column. ITIL is wel degelijk een procesmodel wat heel goed te gebruiken is om orde te scheppen in de ICT-beheeractiviteiten. Natuurlijk moet je daarbij steeds een vertaalslag maken naar de juiste schaalgrootte. Thuis vervul ik ook in mijn eentje alle beheerprocessen. Kan ik prima overzien. Maar zonder zo’n kapstok als ITIL proberen orde te brengen in ICT-beheer van enige omvang betekent toch wel nodeloos opnieuw het wiel uitvinden. “Beetje dom” om met Maxima te spreken….
In een ver verleden heb ik ITIL foundation gedaan. Veel van de zaken klonken wel logish, maar er was één ding wat ik niet begreep en nog steeds niet begrijp.
Ik begreep dat ITIL als kapstok diende en zwaar leunde op “best practices”. Vooral het woord “BEST” betekend iets. Er word namelijk nooit over geschreven of gesproken wiens best practices het waren en in welke situatie. Met een generiek model kun je wel een specifiek inrichting maken maar hoe relateer je dat dan aan een best practice. Ik dacht altijd dat je moest kijken naar bedrijven die met dezelfde issues en infrastructuur zaten en dat je daar ging kijken wat het best werkte (en wat niet) en dat je daaruit dan jouw ITIL beleid haalde waardoor je goed aan kon geven dat we dingen “zo en zo deden”, want bij bedrijf X en Y zagen we dat dat goed werkte.
Wat ik momenteel tegen ITIL heb is dat het te complex en te groot geworden is. Als ik als programmeur 300 pagina’s specificaties krijg dan verdwaal ik. Dan moet je van goede huizen komen om dat tot je te nemen.
Aangezien niet iedereen in een bedrijf ITIl 3.0 gaat doen onstaat al snel dat je “ITIL” alleen maar in naam uitvoerd. Net als veel projecten alleen maar in naam Prince2 worden uitgevoerd.
Een quote die ik ook hier gebruik en die ik als best practice hanteer is van John Gall:
A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.
Wat kort door de bocht.
Met behulp van ITIL hebben we in ons vakgebied een aantal veel voorkomende gebeurtenissen benoemd, zodanig dat we daar hetzelde beeld bij hebben.
Het primaire voorbeeld: een incident.
Dit is een meerwaarde van ITIL.
Dat ITIL niet voorschrijft hoe wij e.a.a. in onze organsiaties inrichten is geen nieuws. De toegevoegde waarde van dit stukje lijkt mij dan ook nihil