Traditioneel richtten IT-organisaties zich vooral op software en hardware. De behoeften van de klanten stonden niet altijd per se voorop. Sinds het einde van de jaren 1980 vertegenwoordigt ITIL® het kernidee dat IT-services moeten worden afgestemd op de behoeften van klanten. Bovendien moeten bedrijven expliciete afspraken maken met hun klanten over de geleverde diensten. Hierbij zijn effectieve processen en duidelijk gedefinieerde verantwoordelijkheden doorslaggevend.

Omdat IT-managers zich steeds meer bewust worden van service- en klantgerichtheid, is ITIL® de afgelopen jaren de de facto wereldwijde standaard voor IT-servicemanagement geworden.

De aanbevelingen van ITIL® zijn over het algemeen geldig - ze weerspiegelen de vereisten van de meeste bedrijven en organisaties, ongeacht hun grootte of branche.

ITIL® wordt voortdurend verder ontwikkeld. De nieuwste versie van de catalogus (versie 4, gepubliceerd in 2019) richt zich op het onderwerp end-to-end servicemanagement - van vraag tot waardecreatie.

De rol van de IT-afdeling van een bedrijf is de afgelopen jaren fundamenteel veranderd. Tegenwoordig moet deze afdeling niet alleen zorgen voor eigen software en hardware, maar ook voor IT-diensten van allerlei leveranciers. Denk hierbij aan software voor de salarisadministratie, een extern geboekt ticketingsysteem of de besturing van het brandbeveiligingssysteem. Het vereist dat corporate IT de interactie tussen intern en extern uitgevoerde services orkestreert, plant en bewaakt: IT Service Management (afgekort ITSM).

In de context van deze ontwikkeling is communicatie de grootste uitdaging: ITSM is nodig om bedrijfsoverstijgende processen te ontwikkelen. Om misverstanden tussen alle betrokken partijen te voorkomen, is een uniform communicatieniveau met duidelijk gedefinieerde termen en een gemeenschappelijke reeks doelstellingen essentieel.

Dit is precies waarom ITIL® als gemeenschappelijke standaard vandaag belangrijker is dan ooit tevoren.

Bij de vorige versie, ITIL® v3, ontstond kritiek dat de beschreven processen te star waren voor een zinvolle en praktische implementatie.

Daarom werd bij de herziening van de ITIL® standaarden veel nadruk gelegd op bedrijfs- en branchespecifieke flexibiliteit. Bovendien bevat ITIL®4 evaluatiecycli zodat organisaties beter kunnen reageren op trends en omgevingsinvloeden. Axelos, de bedenker van ITIL®, heeft zich dus gericht op een sterkere praktische oriëntatie bij de ontwikkeling van de nieuwste best practice catalogus en ingespeeld op de behoeften van IT-serviceproviders.

De onderwerpen cloud, IT-beveiliging en moderne communicatiemiddelen komen ook aan bod.

Het Service Value System beschrijft overkoepelende afhankelijkheden en basisprincipes in servicemanagement die voor alle organisaties zouden moeten gelden. Net zoals bij ITIL®4 in zijn geheel, is het SVS gericht op waardevermeerdering. Op basis van een vraag of kans worden nauwkeurige instructies voor actie en processpecifieke praktijken toegepast om services voortdurend te optimaliseren en hun waarde te verhogen (betere kwaliteit of besparing op resources).

• Basisprincipes: De SVS identificeert 7 algemeen toepasbare leidende principes die praktische instructies geven voor actie in elke industrie, bedrijf en voor elke dienst.
• Bestuur: In de sectie governance worden suggesties gegeven voor goed ondernemingsbestuur, aangezien het topmanagement het eerste contactpunt en controlepunt is in zaken van communicatie en strategische richting.
• Servicewaardeketen: De Servicewaardeketen definieert een reeks gekoppelde activiteiten, beschrijft de rollen van de procesdeelnemers en de afhankelijkheden van de opgenomen (sub)activiteiten. De keten begint bij het idee of bij de planning en omvat alle procesgerelateerde communicatie, evenals het ontwerp en de creatie van een product of dienst. Het levert het resultaat en waarde wordt gegenereerd uit dit totale proces.
• Practices: 34 practices behandelen verschillende onderwerpen en zijn verder onderverdeeld in 3 categorieën:
  • 17 Service Management Practices
  • 14 General Management Practices
  • 3 Technical Management Practices

In de SVS zijn 7 leidende principes gedefinieerd die van toepassing zijn op elk serviceproces en algemene, brancheonafhankelijke aanbevelingen bevatten:

• Waardeoriëntatie: In elke activiteit en elk proces staat het genereren van waarde centraal. Een waarde kan bijvoorbeeld een verhoging van de kwaliteit of een verlaging van de kosten zijn.
• Begin waar je bent: Bestaande, functionerende structuren en processen moeten niet volledig opnieuw worden opgebouwd, maar doelgericht verder worden ontwikkeld.
• Iteratieve ontwikkeling met feedback: Processen zijn onderhevig aan voortdurende verandering, waarbij regelmatige evaluaties dienen om ze te optimaliseren. Deze verandering vindt geleidelijk plaats zodat successen ook betrouwbaar kunnen worden gemeten.
• Samenwerking en transparantie bevorderen: Afdelingssilo's (geïsoleerd werk) moeten worden opgelost, omdat de gecombineerde expertise van een bedrijf beschikbaar moet zijn voor innovaties. Het doel is een geleide uitwisseling van kennis en knowhow tussen alle belanghebbenden.
• Denk en werk holistisch: Bij het nemen van beslissingen over procesveranderingen moet rekening worden gehouden met alle afhankelijkheden en randvoorwaarden. Transparante communicatie binnen de organisatie en met klanten en leveranciers wordt aanbevolen.
• Besteed aandacht aan eenvoud en uitvoerbaarheid: Het aantal deelstappen moet zoveel mogelijk worden beperkt. Dit verbetert het begrip van processen en bovendien zijn afhankelijkheden gemakkelijker te herkennen. In het standaardproces is het niet nodig om voor elke uitzondering een oplossing te hebben.
• Optimaliseren en automatiseren: Als processen eenmaal zijn gestroomlijnd, moeten ze zoveel mogelijk worden geautomatiseerd als dat zinvol is. Ondanks automatisering moet er rekening worden gehouden met nalevingsregels, budgetlimieten en andere factoren.

Aan het begin van een ITIL®-project is het raadzaam om de services te definiëren die moeten worden gedekt.

De belangrijkste motivatie voor de invoering van ITIL® is immers een sterkere servicegerichtheid.

Er moet onderscheid worden gemaakt tussen services die aan klanten worden geleverd en services die alleen zichtbaar zijn binnen de serviceverlenende organisatie (de zogenaamde ondersteunende services). Klantenservices worden gekenmerkt door het feit dat ze een waarde vertegenwoordigen voor de klant.

Als een klant een werkende internetverbinding wil (klantenservice), is het niet relevant wat voor technische infrastructuur daarvoor nodig is (ondersteunende service).

Om te beginnen moet je een lijst maken van alle zakelijke diensten op basis van bestaande overeenkomsten en documentatie. Als duidelijk is welke diensten aan de klanten worden geleverd, kun je de benodigde ondersteunende diensten definiëren. Deze zijn vaak direct gekoppeld aan specifieke onderdelen van de technische infrastructuur, zoals een SAP-platform.

Met de lijst van alle services hoef je alleen hun onderlinge relaties vast te leggen om de servicestructuur te definiëren.

Later vormt deze servicestructuur een belangrijke basis voor het implementeren van het beheerproces van de servicecatalogus.

Voor het succes van een ITIL® implementatie is het belangrijk dat de mensen die later de verantwoordelijkheid krijgen voor de uitvoering van bepaalde processen vanaf het begin betrokken zijn bij het ontwerpen van deze processen. Dit zorgt ervoor dat zoveel mogelijk ervaring wordt opgenomen in de procesdefinitie en dat de rol-eigenaren zich kunnen identificeren met de veranderingen in de workflow die ITIL® met zich meebrengt.

De vereiste rollen worden rechtstreeks afgeleid van de nieuwe ITIL® -disciplines die moeten worden ingevoerd. Als bijvoorbeeld Problem Management moet worden ingevoerd, moet de rol van de Problem Manager worden ingevuld.

Vooral in grote bedrijven kan het nodig zijn ITIL® rollen op te splitsen in subrollen, bijvoorbeeld als één Problem Manager alleen niet alle taken aankan die in deze functie voorkomen.

In deze stap hoeven de rollen niet direct in detail te worden gedefinieerd, omdat dit impliciet gebeurt tijdens de gedetailleerde definitie van de processen in latere projectfasen.

Elke nieuwe ITIL® implementatie en procesreorganisatie moet worden voorafgegaan door een analyse van de huidige situatie. Op die manier is het gemakkelijker om te beslissen welke processen dringende actie vereisen en welke kunnen worden uitgesteld. Bovendien bespaart deze aanpak vaak tijd.

Niet alle processen moeten echter in detail worden onderzocht, geanalyseerd en gedocumenteerd, omdat deze inspanning meestal niet in redelijke verhouding staat tot het resultaat.

Een ITIL zelfevaluatie wordt meestal uitgevoerd in de vorm van gestructureerde interviews met het IT-management en geselecteerde functionele managers. De interviewers leiden de vragenlijst door en helpen, indien nodig, met achtergrondinformatie over specifieke vragen.

De daaropvolgende evaluatie heeft betrekking op de volgende punten:

• Bereikt volwassenheidsniveau in de afzonderlijke ITIL® -disciplines.
• Afwijkingen in de beoordeling van de processen door individuele ondervraagden.
• Zwakke punten in de huidige processen, inclusief onderliggende oorzaken, en kansen.

In deze stap bouwt u voort op de resultaten van de 'as-is' analyse uit stap 4 en definieert u de doelprocesstructuur.

Maak eerst een lijst van de ITIL® processen en subprocessen die geïntroduceerd of verbeterd moeten worden. Op deze manier wordt bepaald hoe de processtructuur, inclusief de subprocessen, er uiteindelijk uit moet zien.

In de regel worden de nieuw in te voeren ITIL® processen direct afgeleid van de specifieke doelen van het implementatieproject.

Bijvoorbeeld, als gebruikersondersteuning moet worden uitgebreid, moet incidentmanagement worden geïmplementeerd of verbeterd. Vanwege het nauwe verband met Incident Management, moeten Problem en Configuration Management ook worden opgenomen in de projectscope.

Deze selectie van ITIL® processen is de focus van deze projectstap.

De doelprocesstructuur bevat nog geen gedetailleerde procesbeschrijvingen, omdat deze pas in een latere stap zullen worden ontwikkeld.

Deze stap bepaalt zowel de input die de individuele ITIL® processen van anderen ontvangen als welke output ze moeten leveren om de daaropvolgende processen te laten functioneren.

Vaak treden er zwakke punten op waar het ene proces eindigt en het andere begint. Als de informatie die nodig is voor een soepel proces niet wordt uitgewisseld zoals bedoeld, uit zich dit vaak in onderbrekingen in de gegevensstroom of in systeemonderbrekingen.

Daarom moet de definitie van interfaces als een aparte stap plaatsvinden, zelfs voordat de gedetailleerde processtromen worden gedefinieerd.

Eerst moet worden bepaald op welke inputs van de voorgaande processen kan worden voortgebouwd en welke outputs nodig zijn voor het vervolgproces, voordat de eigenlijke activiteiten binnen een ITIL® proces worden gedefinieerd.

Deze bepaling van noodzakelijke procesinterfaces bouwt voort op de processtructuur die in de vorige projectstap is ontwikkeld.

Een bijzondere uitdaging bij het definiëren van interfaces is het feit dat normaal gesproken niet alle ITIL® processen tegelijk worden ingevoerd. Dit betekent vaak dat sommige inputs die nodig zijn voor een proces nog niet beschikbaar zijn.

Bijvoorbeeld, de Privacy Security Management practice is misschien nog niet expliciet gedefinieerd, terwijl de Service Desk practice al input vereist zoals beveiligingswaarschuwingen.

Zodra de ITIL® processtructuren zijn vastgesteld en de interfaces zijn gedefinieerd, kan de procesbesturing worden opgezet. De volgorde ervan kan alleen zinvol worden ontworpen nadat is bepaald aan welke kwaliteitscriteria een proces moet voldoen.

De besturing definieert geschikte methoden om ervoor te zorgen dat de processen aan hun verwachtingen voldoen. Een goed doordacht concept dient niet alleen als instrument om het bereiken van doelstellingen te evalueren, het levert ook de kerncijfers die nodig zijn voor continue verbetering binnen de servicelevenscyclus op de lange termijn.

Om te kunnen beslissen of een proces "goed loopt" of niet, moeten objectieve kwaliteitscriteria (zogenaamde key performance indicators, kortweg KPI's) worden gedefinieerd.

Voor dit doel moeten de overkoepelende doelen van het ITIL® project worden gedefinieerd, bijvoorbeeld het hoogst mogelijke first resolution rate in de servicedesk. Met deze doelstellingen in gedachten, kunt u de KPI's bepalen die geschikt zijn om een succesvolle procesimplementatie te beoordelen.

De uiteindelijke selectie van de KPI's hangt onder andere af van de bepalingsopties die in het bedrijf beschikbaar zijn. Idealiter worden de KPI's automatisch berekend via een servicedesksysteem. Daarom zijn de hier gedefinieerde meetmethoden ook vereisten voor de te implementeren systemen.

Meer is echter niet altijd beter. In de praktijk blijkt vaak dat een te complexe meetstructuur die onevenredig veel werk met zich meebrengt, niet goed wordt geaccepteerd. Daarom wordt deze na korte tijd niet meer gebruikt.

In plaats daarvan kun je beter een aantal, maar betekenisvolle, kengetallen definiëren om de inspanning voor het bepalen en rapporteren binnen een redelijk bereik te houden.

Bovendien is het niet raadzaam om in de beginfase vaste streefwaarden vast te stellen. Stel eerst geschikte kwaliteitsindicatoren vast en bepaal meetwaarden. Na verloop van tijd, wanneer er een statistisch betekenisvol aantal meetresultaten beschikbaar is, kunnen er op een solide basis streefwaarden worden gedefinieerd.

Deze stap specificeert de activiteiten die binnen elk proces moeten worden uitgevoerd en de checklists en richtlijnen die zullen worden gebruikt om de uitvoering ervan te ondersteunen.

Meestal krijgen de proceseigenaren deze taak toegewezen, maar alle betrokken partijen moeten erbij betrokken worden, vooral de medewerkers die de processen in de toekomst zullen uitvoeren. Dit zorgt ervoor dat het grootst mogelijke niveau van ervaring en kennis wordt opgenomen in het procesontwerp.

Procesontwerpen worden meestal gedocumenteerd als stroomdiagrammen, zodat de vereiste activiteiten en hun volgorde worden weergegeven zonder al te veel in detail te treden. De diagrammen specificeren ook welke rollen verantwoordelijk zijn voor het uitvoeren van de activiteiten.

Om overbelasting van de procesdiagrammen te voorkomen, dient u extra informatie ter ondersteuning van de procesuitvoering als checklists en documentsjablonen aan de diagrammen toevoegen.

Dit kunnen bijvoorbeeld gedetailleerde instructies zijn voor het registreren en doorsturen van incidenten en serviceverzoeken op het 1e niveau.

Nu is het procesontwerp voltooid en kan de implementatie beginnen.

Als er een nieuwe of aangepaste technische infrastructuur nodig is om de processen te ondersteunen, wordt deze nu aangeschaft en opgezet. De afzonderlijke stappen die nodig zijn, hangen volledig af van je project en de geïmplementeerde processen. Daarom wordt in het volgende voorbeeld alleen de definitie van de vereisten voor applicatiesystemen beschreven.

Functionele eisen voor de ondersteunende infrastructuur kunnen vaak worden afgeleid uit het procesontwerp. Dit ontwerp definieert welke werkstappen moeten worden ondersteund door de applicaties.

De input- en outputdefinities van het proces beschrijven welke gegevens door de systemen verwerkt moeten worden. Het incident management proces genereert bijvoorbeeld incident records. Daarom moet het systeem dat dit proces ondersteunt zulke gegevens kunnen beheren.

Tot slot moeten ook niet-functionele eisen worden opgenomen.

Dit resulteert in de volgende structuur voor de vereistencatalogus:

• Functionele eisen
  • Verwijzing naar gedetailleerde procesmodellen
  • Aanvullende functionele eisen
  • Definities van process outputs (gegevensstructuren)
  • Functies van het rapportagesysteem
• Niet-functionele eisen
  • Eisen ten aanzien van capaciteiten en hoeveelheden
  • Prestaties en doorvoer
  • Schaalbaarheid/uitbreidbaarheid
  • Beschikbaarheid
• Eisen vanuit operationeel oogpunt
  • Eisen vanuit het oogpunt van IT-beveiliging
  • Interfaces met andere systemen
  • Bijlage
    • Procesmodellen
    • Gegevens die moeten worden geïmporteerd uit bestaande systemen

Als de catalogus compleet is, maak dan een geprioriteerde lijst van individuele items die zal dienen als een evaluatiematrix voor het selecteren van een geschikt (extern) systeem. De vereisten moeten per categorie worden georganiseerd, zoals in het volgende voorbeeld:

• K.O. criteria (prioriteit 1)
• Belangrijke eisen (prioriteit 2)
• Wenselijke vereisten (prioriteit 3)

Als alle belangrijke partijen betrokken zijn geweest bij het ontwerpen van de processen, zou het niet nodig moeten zijn om de nieuwe processen verder uit te leggen aan de verantwoordelijke medewerkers.

Het kan echter nodig zijn om uw team te trainen in het gebruik van nieuwe applicatiesystemen.

Daarnaast moeten klanten mogelijk worden geïnformeerd als er bijvoorbeeld een nieuwe supportgroep is opgericht voor ondersteuning op het 1e niveau. Daarom is de procedure voor het melden van incidenten veranderd.

Tot slot:

Zorg ervoor dat je veranderingen in processen vroegtijdig communiceert naar alle betrokken partijen. Als procesdeelnemers pas in de laatste fase van een ITIL® project worden geïnformeerd over nieuwe processtromen, is een gebrek aan acceptatie onvermijdelijk. Daarom moeten zoveel mogelijk medewerkers die later de gevolgen zullen ondervinden, betrokken worden bij het ontwerp van de processen tijdens de eerdere fasen van het project.

Deze practice houdt zich bezig met het beheer van technologieën die in de organisatie worden gebruikt.

De practice Software Development and Management biedt een overzicht van de activiteiten van softwareontwikkeling -en beheer.