ITIL processen

 

 

Overzicht van de ITIL processen:

 
 

  • De CMDB (central management database) is de centrale databank waar we alle informatie in stoppen over de klanten en producten waar de dienstverlening op slaat. In onze analogie met een garage: zijn databank dient gegevens over alle klanten, de reparatie- en onderhoudshistoriek van hun auto’s, informatie over de gereedschap en apparatuur in de garage, de voorraad en de technici te bevatten. Telkens een dienst dient geleverd, kan de benodigde informatie uit die centrale databank opgehaald worden en bijgewerkt worden.
 
  • Incident management handelt over het reparatie proces. Bijvoorbeeld een klant brengt een auto binnen met slechte remmen. Je plaatst nieuwe remblokken en alles is terug ok.
 
  • Als een incident maar blijft opnieuw optreden, dan moet er wel een onderliggende oorzaak zijn (“root cause”). Dat “incident” wordt dan een “problem”. En er is meer onderzoek nodig om er definitief vanaf te geraken. Stel dat meer en meer auto’s van een bepaald model terug binnenkomen met falende remmen. Misschien is er dan wel een hele serie van dat model met een productiefout, en moeten, nadat een beter onderdeel ontworpen werd door de fabrikant, alle auto’s van die reeks teruggeroepen worden om dat onderdeel preventief te vervangen. Hier spreken we van problem management.
 
  • Change management handelt over het aanbrengen van wijzigingen. Er is niets defect, men wil een wijziging. Bijvoorbeeld een klant vraagt om zijn stalen velgen te vervangen door aluminium sportvelgen. Changes kunnen gevaarlijk zijn, en dan weer een incident veroorzaken... Als de elektricien in een bedrijf een elektrisch circuit wil uitschakelen omdat hij een wijziging wenst aan te brengen kan dat wel eens grote gevolgen hebben voor machines die aan dat circuit hangen indien hij niet eerst nakijkt of alles eerst mooi tot stilstand gebracht is.
 
  • Release management handelt over alle wijzigingen op zo’n manier aan te brengen dat alles in een precies voor gedefinieerde toestand is. Bijvoorbeeld, stel dat de autofabrikant wat fouten heeft gevonden in de motormanagement software van een bepaald automodel. Een garagist die “release management” toepast draagt er zorg voor dat alle auto’s van zijn klanten die tot dat model behoren zo snel mogelijk op die nieuwste softwareversie geflasht worden.
 
  • Request management gaat over het bestellen van goederen of diensten. Bijvoorbeeld een klant belt om dakrails voor zijn auto te bestellen, hij wil op reis en wil zijn reiskoffer op het dak kunnen monteren.
     

Hoe organiseer je dit binnen een bedrijf ?

Onderstaand plaatje toont hoe de ITIL processen praktisch georganiseerd worden binnen een bedrijf.
 
 

 

Aan de linkerkant zie je eindgebruikers met een “issue” die de service desk wensen te contacteren. De service desk is het “single point of contact” (central contactpunt) voor eindgebruikers die iets wensen te melden of te vragen. Belangrijk is dat je klanten en eindegebruikers niet toelaat om rechtstreeks te bellen met de verantwoordelijke, technicus die iets kan oplossen. Als je toelaat dat gebruikers rondbellen in het bedrijf verlies je alle overzicht over wat er fout loopt binnen je bedrijf en met je klanten. Je kunt geen statische gegevens bijhouden en je zal geen trends ontdekken. Als je iemand rechtstreeks belt ben je ook niet zeker of die persoon die activiteit niet vergeet op te nemen, en eventueel te factureren aan de klant. Gebruik je een centrale service desk, dan zal deze wellicht diezelfde technicus aanroepen, doch wel bewaken dat die activiteit effectief uitgevoerd wordt door die technicus. Eindgebruikers contacteren de service desk via email, gestructureerde email, webformulieren, webchat en telefoon. De meest efficiënte (goedkoopste) technieken zijn webformulier en webchat. Telefonie is duurste techniek, omdat ze een service desk specialist een tijd blokkeert (de duur van het gesprek)


De service desk agent zal bepalen wat de aard van het event is die de eindgebruiker aanmeldt. Is er iets defect (eenIncident). Wil hij dat er iets gebeurt (maar niets is defect) (een Request). Een incident dat door meerdere gebruikers gerapporteerd wordt, en een diepere onderliggende oorzaak heeft wordt een “problem“. Hier zal wellicht interventie door specialisten vereist zijn. Of wil de gebruiker dat een wijziging aangebracht wordt (change request, change management). Wijzingen aanbrengen is vaak gevaarlijk en kan incidenten veroorzaken. Bedrijven zullen vaak een “change manager” hebben die wijzigingen coördineert. Een CAB (change advisory board) is de vergadering binnen een bedrijf of bij een klant die onderzoekt of wijzigingen wel veilig kunnen doorgevoerd worden door de “Change Workers”.

 

Incidents, problems, changes gebeuren op “assets” (de middelen) die klanten en medewerkers gebruiken. Die middelen (apparatuur, software,...), hoe die geconfigureerd is, en alles wat er rond gebeurt (wie zijn de gebruikers), dient in een databank gedocumenteerd te worden. Zo’n databank wordt een “CMDB” (configuration and management database) genoemd. Ze vormt het documentatiehart van de oplossing, en vormt de basis voor rapportage en statistieken (vb. frequentie van defecten, % tickets die te lang open staan, ...)

 

Incident management

Een incident is iets was mis gaat en waarbij je probeert wie door het incident impact heeft zo snel mogelijk weer verder te helpen. Hoe je verder helpt doet er niet toe. Het is zelfs niet vereist hetgene wat misgelopen is op te lossen, het omzeilen is ook goed - zolang de eindgebruiker maar tevreden is. Dat levert volgende definitie op:
 
 
 
 

Bijvoorbeeld:

  • Je auto start niet. De batterij is leeg. Je zoekt niet uit of er iets defect is, maar koppelt startkabels aan de accu van een andere auto, je start, en je rijdt weg – je hoopt dat het niet meer voor komt.
 
  • Een klant heeft een zwaar defect aan zijn auto. De reparatie zal lang duren. I.p.v. eerst de reparatie aan te pakken los je het incident op door die klant een vervangwagen aan te bieden. Voor die klant is het incident tijdelijk gesloten, hij kan immers verder en vindt het nu minder erg dat zijn auto defect is zolang hij maar over de vervangauto beschikt. 

 

Problem management

Probleem: De oorzaak van één of meer incidenten die meer onderzoek vergen dan zo maar een incident. Een voorbeeld: Als een klant de vervanging vraagt van een batterij in een 4 jaar oude notebook, omdat die batterij niet meer oplaadt, dan is dat duidelijk een incident: Het is volstrekt te verwachten dat een 4 jaar oude batterij in een notebook het begeeft. Vervangen met een nieuwe batterij, en de case is gesloten. Bellen echter 100 gebruikers van de 400 die tussen 2 en 5 maanden geleden een notebook model X4000 bij je gekocht hebben met de melding dat hun batterij niet meer oplaadt, dan is dit een compleet ander verhaal: Dat bij één gebruiker een batterij het zeer vroegtijdig begeeft, dan kan altijd wel gebeuren. Maar niet bij 100 kopers op 400. Hier is iets mis met het productieproces van die batterij. Dit is niet zomaar meer een reeks incidenten, maar moet je veranderen van status van incident naar probleem
 
 

Definitie


 

Wat terminologie

  • Root cause: de onderliggende oorzaak van een probleem. (bijvoorbeeld een slecht ontworpen onderdeel)
  • Reactief Probleem Management (je lost de problemen op als ze zich voordoen)
  • Pro-actief Probleem Management (je ziet de problemen aankopen en lost ze op voor het incident dat erbij hoort optreedt. Dit is deel van het continue kwaliteitsverbeteringsproces)

 

 

Je kunt op 2 manieren met problemen omgaan:

  • Reactief Probleem Management: Het incident gebeurt. Je vermoedt een onderliggende oorzaak (root cause) en start het problem management proces. Men noemt dit reactief, omdat je maar handelt als het incident optreedt. Bijvoorbeeld, de accu in de auto is niet meer zo goed. Je wacht tot na een vriesnacht je niet meer kunt starten om de accu te vervangen.
  • Pro-actief Problem Management (deel van het continue kwaliteitsverbeteringsproces): Je wacht niet tot het incident gebeurt, maar grijpt vroeger in. Bijvoorbeeld: Je komt op onderhoud met je auto. De garagist merkt dat je remblokken voor ¾ versleten zijn. Binnen 10000 km zijn ze wellicht volledig op. Hij vervangt nu reeds je remblokken.

 

Pro-actief problem management wordt over het algemeen als een betere aanpak aanzien dan de reactieve. Immers, je vermijdt het  incident met zijn bedrijfsimpact. Toch kiest men er soms bewust voor om reactief te werken. Een machine is afgeschreven, en je wil hem verder blijven gebruiken tot hij in panne valt. Pas dan installeer je een nieuwe. Je doet dit zo om financiële redenen, en omdat het uitvallen van die machine niet zo’n grote bedrijfsimpact heeft.

 

 

Request Management

Het Service Operations Process

 
Er zijn wat variante vormen van Incident Management. Immers, het gaat niet steeds over een "technische panne", een incident, maar het kan ook over vragen om iets uit te voeren gaan - requests dus. Als de juiste technologie er is kunnen incidenten ook automatisch, door sensoren e.d., gemeld worden. Denk aan de boordcomputer van je auto die je vertelt dat er iets mis is lang voor je zelf iets gemerkt had. Bij dat automatisch melden spreekt men van event management
 
Een servicedesk is duur - omdat je mensen nodig hebt. Indien het mogelijk is gebruikers zelf bepaalde zaken te laten uitvoeren (zelf een testprogramma laten lopen, zelf iets oplossen, zelf een aanvraag uitvoeren) dan spaar je tijd en geld: Kijk of selfhelp mogelijk is.
 
 
Laten we het service operations process wat van dichterbij bekijken:

  • Event management betreft die incidenten die door automatische systemen gemeld worden. Bijvoorbeeld een inbraakalarm gaat af, een systeem die het netwerk monitort merkt dat een bepaald gebouw niet meer via het netwerk bereikbaar is, men detecteert dat een server een “blue screen” heeft, enz... Het is altijd beter als een automatisch systeem reeds alarm geeft voor dat de eindgebruikers beginnen te bellen. Dan kun je al sneller beginnen op te lossen, en misschien merken de eindgebruikers het zelfs niet
  • Incident management betreft incidenten door gebruikers aangemeld
  • Request fulfillment: dat zijn niet echt incidenten, maar gebruikers die extra’s vragen. Zoals, ik wil een laserpointer geleverd krijgen want ik moet morgen een presentatie geven voor groot publiek.
  • Self help zijn oplossingen die je voorzien voor gebruikers die een incident hebben of een dienst willen waarbij zehet zelf kunnen oplossen. Bijvoorbeeld je hebt een FAQ voor de klanten met de meest voorkomende incidenten en de oplossing. Je kunt zelfs instructiefilmpjes op je website plaatsen. Dit is veel goedkoper dan een klant minutenlang aan de telefoon hebben, of, nog erger, een technicus moeten ter plaatse zenden. Self Help voor request management kan bijvoorbeeld een soort webshop zijn waarop de gebruiker zelf bestelt wat hij nodig heeft, en het dan later zelf installeert. Is je muis kapot, dan bestel je zo gewoon een nieuwe.
 

Waarom is Self Help een goede techniek ?

Aan een klant hulpmiddelen aanbieden om zelf een aantal eenvoudiger incidenten op te lossen is echt wel een goed idee. Niet iedere klant zal hier op ingaan, doch de meer handige zeker wel en die appreciëert de tijdswinst.
 
 
Self Help kan bijdragen tot:
  • Sneller geholpen. (de klant lost het onmiddellijk zelf op)
  • Minder aanvragen (je technisch team wordt minder belast en kan dus kleiner en goedkoper zijn)
  • Lagere kosten (je hoeft geen technicus ter plaatse te sturen)
  • Helpt bij standaardisering van de oplossing (de klant voert uit wat in de FAQ als oplossing beschreven wordt en improviseert niet zelf iets)
  • Betere kwaliteit (klanten ervaren dit meestal als positief en een betere dienstverlening – hoe gek dit ook moge klinken. Reden is vaak dat snel geholpen worden het belangrijkste is)
 

Request management

Image courtesy of Salvatore Vuono at FreeDigitalPhotos.net

 

Service Requests gaan over iets aanvragen. Er is dus niets defect, je bestelt iets bijkomend, of je vraagt een standaard dienst uit te voeren.

 

Enkele voorbeelden:

  • Een paswoord resetten
  • Een nieuwe medewerker wordt aangeworven in het bedrijf: Dan dienen heel wat zaken te gebeuren op informatica gebied, zoals het aanmaken van een mailbox, een SAP account, HR record, VPN toegang,... De aanvraag om dat allemaal aan te maken is een voorbeeld van service request.
  • Je vraagt je garage een trekhaak op je auto te monteren

 

 

Change Management

 

Change is een bron van incidenten...

 
Eén van de meest voorkomende bronnen van incidenten zijn niet defecten aan apparatuur, maar wel wijzigingen die aangebracht werden zonder doordacht overleg. Vaak krijg je dan een kettingreactie van zaken die misgaan door die wijziging en waardoor het alsmaar erger wordt.
 
 
 
Binnen ITIL probeert change management wat orde te brengen in het veranderproces zodat er minder bij misloopt.
 
 
 
 

Als een medewerker, hoe competent hij ook is, zomaar begint wijzigingen aan een systeem aan te brengen zonder met anderen te overleggen, zonder zijn wijzigingen te documenteren, dat zal er vroeg of laat eens iets heel erg fout lopen in het bedrijf. Stel dat hij ernstig ziek wordt: De documentatie beschrijft de oude toestand en is dus niet meer bruikbaar. Wie wijzigingen aanbrengt is meestal enkel bezig met de gevolgen van de wijziging voor zijn werkgebied. Maar vaak vergeet men de impact op andere domeinen. 

 

Het change management proces poogt wat orde te brengen in wijzigingen door te formaliseren zodat het risico omlaag gaat.

Zelfs kleine bedrijven hebben change management als proces nodig. Het is veel te gevaarlijk voor je bedrijf dit niet te doen. O.a. het betrekken van alle betrokkenen, van managers tot uitvoerende arbeiders is erg belangrijk om te vermijden dat een “change” uitdraait op een groot “incident”

 

De change voorbereiden: changeplan

Iets wijzigen is gevaarlijk. Om het risico te beperken schrijft ITIL voor dat er bij een wijziging een changeplan dient opgesteld wat de wiiziging voorbereidt. De aanvraag tot wijziging (change request) dient bovendien voor ze uitgevoerd wordt eerst tesamen met het changeplan voorgelegd te worden aan de CAB (change advisory board)
 

Changeplan

Uitvoering

Changeplan

Een aanvraag tot wijziging resulteert in een changeplan dat volgende bevat:

• Uitrolpan

• Mogelijke bedrijfsimpact

• Fall back Plan

• Checklist afhankelijkheden

• Formuleer een goed uitgewerkt plan voor de “change”

• Definieer precies de “change”

• Hoe complex is ze: major/minor/regular

• Hoe en wanneer zal de wijziging uitrollen (gebeuren)

• Is er bedrijfsimpact terwijl de “change” wordt geïmplementeerd ?

• Als de “change” mislukt, kun je dan de situatie terugdraaien ?

• Maak een checklist van wat  nodig is voor de change

CAB (Change Advisory Board)

Het beslissingsorgaan die de wijziging beoordeelt en dient goed te keuren. Belangrijk is dat ze alle betrokken partijen voor de “change” opspoort, en goedkeuring verkrijgt voor de wijziging kan plaatsvinden.

 

CAB (Change Advisory Board)

 
Eén van de eerste maatregelen die je kunt treffen volgens ITIL om wijzigingen minder riskant te maken is het inrichten van een CAB (Change Advisory Board).
Dat is een, meestal wekelijkse, statusmeeting waar men alle wijzigingen in het bedrijf bespreekt en nadenkt over wie dient verwittigd, wat de onvoorziene impact kan zijn en wat het plan is indien het mis gaat (een rollback plan, terugkeren naar de oude toestand indien de wijziging niet werkt). Je laat wijzigingen niet toe als ze niet eerst in de CAB besproken werden en daar het changeplan kon ter inzage voorgelegd worden.
 
 

 

Image: https://servicemanagementjourney.blogspot.be/2013/02/change-management-what-not-to-hear.html

 

Men dient die vergadering wel ernstig te nemen. Je wil zeker geen wijsneuzen horen in de CAB die onzin vertellen zoals "dat hoeven we niet eerst te testen", "er is geen impact", "we hebben geen rollback scenario nodig". Want dan wacht de ramp om de hoek...