ZBC Kennisbank

ITIL pragmatisch en flexibel

 

ICT is voor organisaties een belangrijke middel om in te spelen op innovatieve ontwikkelingen. Dat is onomstreden. Maar in deze tijd van crisis, of beter gezegd van de nieuwe realiteit, werken modellen en methoden uit de vorige eeuw niet meer en worden nieuwe denkwijzen gevraagd. Einstein zei al: “Je kunt een probleem niet oplossen met de denkwijze die het heeft veroorzaakt.”. Binnen deze hectiek echter, opereert juist de ICT als een bolwerk van conservatisme en bureaucratie, zoals dat in de vorige eeuw gebruikelijk was, met ITIL als de heilige graal. Dit tot grote frustratie van de business.

Belangrijkste oorzaak hiervoor is misschien wel, dat de ICT alles wil vastleggen en het dan vervolgens het liefst direct voor langere tijd wil bevriezen. Denk hierbij aan contracten, procedures, administraties, systemen en mensen. De processen en vooral de procedures van ITIL ondersteunen dit van harte. Maar het zijn wel de mensen die de keuze maken voor het implementeren en in stand houden van deze procedures. En dat in een tijd, waarin verandering de enige stabiele factor is. Toch hebben organisaties ook steeds meer behoefte om ‘in control’ te zijn. Enerzijds dwingen toezichthouders en wet- en regelgeving dit af, maar anderzijds implementeren bedrijven ook zelf risk management en allerlei managementsystemen om hun operational risks te beheersen. En juist daarvoor is vastlegging een must.
In dit artikel pleit ik er daarom voor om ITIL niet bij het grof vuil te zetten. De logica van ITIL is ook nu nog goed bruikbaar. Wel is het nodig ITIL in een nieuw jasje te stoppen. Niemand zit immers nog op de permanente stiptheidsactie te wachten, die ten gevolge van allerlei ITIL-procedures is ontstaan.

ITIL in de loop der jaren

Beginnende ICT-afdelingen en bedrijven leverden aanvankelijk doorgaans op basis van ‘het onmogelijke doen we direct, wonderen duren iets langer maar we garanderen niets’. Toen in de jaren negentig bedrijven afhankelijker werden van de ICT, was met name het laatste punt niet meer acceptabel. Steeds vaker gingen er zaken fout rond de informatievoorziening. Per definitie kreeg de ICT dan de schuld. Methoden als ITIL en watervalmethoden waren hierop het antwoord. Door deze methoden en vooral door de daarbij behorende procedures strikt toe te passen, bewezen ICT’ers, dat het niet hun schuld was als er iets fout ging met de informatievoorziening binnen een bedrijf. Deze attitude van indekken bestaat nog steeds bij ICT’ers. De methoden die dichterbij de gebruikers staan (Prince 2 geheel vernieuwd; waterval vervangen door agile) zijn flexibeler geworden. ITIL echter, het interne feestje voor ICT’ers, heeft wel een aantal vernieuwingen doorgemaakt, maar is nog steeds conservatief en bureaucratisch. (Zie ook ‘Van ITIL 1 naar ITIL 3: wat bereik je daar als organisatie mee’.) In de huidige vorm is ITIL dan ook ver over de houdbaarheidsdatum.

Tekortkomingen van ITIL

Laten we vooropstellen, dat ITIL diverse elementen bevat, die ook nu nog goed bruikbaar zijn, mits deze worden aangepast aan de eisen van deze tijd en mits ICT’ers bereid zijn zich minder defensief en behoudend op te stellen. Een aantal belangrijke verbeteringen zijn:

  • ITIL wordt passend gemaakt op de behoefte van de organisatie. Het gaat daarbij om de processen en niet om de procedures. De organisatie maakt haar eigen keuzes over de prijs/prestatie, die de ICT levert. Dat betekent, dat van de tactische processen alleen service level management en informatiebeveiliging (eventueel aangevuld met business continuity) overblijven. Deze tactische processen gaan niet uit van de ICT, maar van de behoefte van de interne en externe klanten.
  • ITIL wordt ingericht als een modern managementsysteem. Dit betekent dat er een planning en control cyclus is en een verbetercyclus en dat problem management een uitgebreidere functie krijgt. Helaas biedt ISO 20000 hier nauwelijks handvatten voor.
  • Op operationeel niveau krijgt configuratie management een andere invulling dan de centrale administratie van de ICT. De tijd van een centrale administratie ligt achter ons. Registreren gebeurt bij de bron in een vastgelegde architectuur.

Planning en control cyclus

Onderstaand de planning en control cyclus:

Planning en control cyclus

Helaas zien we in de praktijk vaak, dat er wel beleid, planning en uitvoering zijn, maar dat de relaties hiertussen ontbreken. Omdat de control functie dan doorgaans ook ontbreekt, valt dit niet op. In de managementsystemen van tegenwoordig kom je hier echter niet meer mee weg. Vooral de control functie als startpunt van de verbetercyclus is een eis, net als directieverantwoordelijkheid. Als de directie geen rapportage krijgt over wat wel en niet wordt bereikt, zal bijsturing slechts plaatsvinden op een onderbuikgevoel of naar aanleiding van incidenten.
Ook de planningsfunctie is een keuzeproces, dat primair wordt aangestuurd door de beleidsuitgangspunten van de directie. Omdat deze dikwijls ontbreken, laat de planningsfunctie zich vaak sturen door opgelegde normensystemen, zoals bijvoorbeeld ITIL of ISO 27002.
Tegenwoordig dient het planningsproces als volgt tot stand te komen:

  • De beleidsuitgangspunten zijn leading.
  • Met behulp van externe normensystemen en een risico-inventarisatie worden de beleidsuitgangspunten vertaald in een interne norm.

Hieronder is dit schematisch weergegeven:

PC-cyclus management systeem

ITIL kent niet de control functie voor operational risks. Daardoor wordt de ICT-afdeling vaak als costcenter gezien en uitsluitend gestuurd op budget. Dit wordt dikwijls nog versterkt, doordat ITIL alleen gebruikt wordt voor de operationele processen en dan op een normatieve wijze. Juist dit laatste is een grote valkuil. ITIL heeft de procedures om vrijwel ieder risico af te dekken. Maar meestal zijn allerlei risico’s voor de organisatie zeer onwaarschijnlijk. Als de procedures niet worden afgewogen en in lijn gebracht met de beleidsuitgangspunten, dan wordt ITIL een dogma met binnen de ICT vaak fundamentalistische aanhangers. Hiermee doet de ICT-afdeling zichzelf te kort. Zij levert immers vooral ook toegevoegde waarde. Maar zij zou zichzelf moeten uitdagen om de prijs/prestatie daarvan te optimaliseren. Dat dit voor de ‘business’ een verademing zou zijn, hoeft geen betoog. Door het ontbreken echter van de control functie vindt geen terugkoppeling plaats naar de planningsfunctie.

Opzet van de operationele processen van ITIL

In principe kunnen de operationele processen van ITIL blijven bestaan. De procedures binnen deze processen zullen echter afgewogen moeten worden tegen de werkelijk risico’s en de beleidsuitgangspunten. Hieronder de operationele ITIL-processen in één plaatje:

Planning en control cyclus en ITIL

De start is rechtsboven bij de gebruiker, die een call doet bij de eerstelijns support. Er zijn dan twee mogelijkheden.

  • Deze call kan een incident betreffen. In dat geval moet de eerstelijns support (eventueel met behulp van de tweede- en derdelijns support) zorgen voor een fix, zodat de gebruiker verder kan. Het incident wordt geregistreerd in de Incident Management Database (meestal deel van de CMDB). Als voor het incident nog geen fix geregistreerd is, dan wordt deze als bekende fout vastgelegd in de IMDB. Door registratie van bekende fouten kan de eerstelijns support steeds meer incidenten zelfstandig afhandelen zonder escalatie, zodat op termijn aanzienlijke kostenbesparingen gerealiseerd kunnen worden.
  • De call van de gebruiker kan ook een wijziging inhouden. Eventueel via tussenkomst van functioneel beheer wordt dit geformuleerd als een wijzigingsvoorstel (RfC), dat wordt vastgelegd in de CMDB.
    Bovenstaand proces noemen we Incident Management en is lichtblauw gekleurd in het plaatje. De kosten Incident Management kunnen niet doorbelast worden aan de business.

In het verlengde van Incident Management ligt Problem Management. Vaak wordt dit proces ingevuld met tweedelijns incidentafhandeling, maar dat is niet juist.
Problem Management bekijkt de incidenten en beoordeelt of het wenselijk is om de fout (te vaak, te groot) structureel op te lossen. Problem Management verzint dan een oplossing en dient deze in als een wijzigingsvoorstel (RfC). Dit wordt vastgelegd in de CMDB. Voorts beoordeelt Problem Management of de fix voor nieuwe bekende fouten correct is. Zo nodig past Problem Management de beschrijving van de bekende fout aan.
Het proces Change Management is weergegeven aan de linkerkant. Het begint bij de impact analyse op RfC’s. Helaas wordt vaak alleen gekeken naar tijd en geld, zonder dat de overige operational risks worden bepaald. Dan kan bij de besluitvorming ook alleen worden gekeken naar tijd en geld. De impact van het eventueel introduceren van nieuwe operational risks voor bijvoorbeeld informatiebeveiliging of Business Continuity wordt dan gemist. De wijziging wordt vervolgens gerealiseerd, geaccepteerd en in productie genomen. Van belang is dat de wijzigingen en statusverandering worden vastgelegd in de CMDB. Idealiter ondersteunt het CMDB de aanpassingen, die vervolgens mogelijk ook in het BCP moeten worden gedaan.
Configuration Management is verantwoordelijk voor het ontwerpen van de CMDB (inclusief IMDB) met vooral ook de relaties tussen de configuratie items en het beheer van vooral de structuur. Alleen dan kunnen uit de CMDB allerlei dedicated rapportages en overzichten gehaald worden. Natuurlijk voert het proces Configuration Management niet zelf de CMDB, maar wordt dat bij de bron gedaan.
ITIL kent het proces interne controle dus niet. Het past echter wel in ITIL om het proces ‘Problem Management’ uit te breiden met een aantal activiteiten:

  • Problem Management krijgt ook de rapportage over gedetecteerde incidenten van operations en pakt dit zo nodig op.
  • Problem Management controleert of changes correct zijn doorgevoerd (acceptatie, productie, vastlegging).
  • Problem Management rapporteert aan de directie en de verantwoordelijken voor informatiebeveiliging en Business Continuity.

Met deze activiteiten is, samen met de activiteiten die toch al bij problem management zijn belegd, de control functie gecreëerd.
ITIL pragmatisch en flexibel
Op bovenstaande wijze kunt u ITIL met niet al te veel inspanning verbouwen tot een pragmatisch stelsel van normen, die u als best practices kunt gebruiken als dit strookt met de beleidsuitgangspunten en als dit gezien de risico’s ook daadwerkelijk nodig is. Het is vooral een kwestie van schrappen.
Wat u echter wel nodig hebt, zijn beleidsuitgangspunten. Niet een wollig verhaal, maar concrete punten zoals:

  • De best practices van ITIL vormen, voor zover zij bijdragen aan de optimalisatie van de interne en externe informatievoorziening, het uitgangspunt voor de te definiëren investeringen en wijzigingen.
  • Alleen procedures waarvan naleving goed controleerbaar is, komen in aanmerking voor implementatie. Dit is primair een bedrijfseconomische afweging.
  • Aanschaf, installatie en onderhoud van informatie- en communicatiesystemen, alsmede inpassing van nieuwe technologieën, moeten zo nodig met aanvullende maatregelen worden uitgevoerd, opdat hiermee geen afbreuk wordt gedaan aan andere managementsystemen.
  • Het beheer en de opslag van gegevens zijn zodanig, dat geen informatie verloren kan gaan.
  • Er is een proces om incidenten adequaat af te handelen en hier ‘lessons learned’ uit te trekken.
  • Iedere twee jaar wordt de dienstenportfolio van de ICT-afdeling geëvalueerd en wordt onderzocht of externe partijen een betere prijs/prestatie kunnen leveren.

Wat betreft de ICT-uitgangspunten zijn aanvullingen altijd welkom.
ZBC hoopt hiermee een bruikbare suggestie te hebben gegeven voor de oplossing van enerzijds de behoefte aan flexibiliteit van de ICT en anderzijds de noodzaak om ‘in control’ te zijn.

DownloadDownload artikel als MS Word document Download artikel als PDF document Print deze pagina Verstuur deze pagina naar een vriend (email)
Auteur: Wiebe Zijlstra | 29 januari 2014 | Copyright: ZBC


Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *