INHOUDSOPGAVE "ITIL" 1
Algemene Inleiding
1.1
Procesbenadering
1.2
Doel en structuur van het boek
1.3
Enkele basisbegrippen
1.3.1
IT infrastructuur
1.3.2
Beheer en exploitatie
1.3.3
Gebruiker versus opdrachtgever
1.4
Samenhang basisprocessen
2
Helpdesk
2.1
Doel van de helpdesk
2.2
Het incident
2.3
Activiteiten van de helpdesk
2.3.1
Communicatie en promotie
2.3.2
Incidentbeheer
2.3.3
Informatievoorziening
2.4
Samenvatting en aandachtspunten
3
Probleembeheer
3.1
Doel probleembeheer
3.2
Problemen, fouten en incidenten
3.2.1
Probleem
3.2.2
Bekende fout
3.2.3
Het onderscheid
3.3
Activiteiten
3.3.1
Probleemidentificatie en registratie
3.3.2
Classificatie
3.3.3
Allocatie mensen en middelen
3.3.4
Onderzoek en diagnose
3.3.5
Foutbeheer
3.3.6
Informatievoorziening
3.4
Samenvatting en aandachtspunten
Verklarende woordenlijst HOOFDSTUK 1 ALGEMENE INLEIDING Procesbenadering - Doel en structuur van het boek - Enkele basisbegrippen - Samenhang basisprocessen
Inhoudsopgave - Volgende hoofdstuk - Verklarende woordenlijst
H 1 Algemene inleiding Dit artikel geeft inzicht in de mogelijkheden om meer grip te krijgen op de kwaliteit van de IT dienstverlening. In de loop der tijd zijn verschillende methoden en technieken ontwikkeld om het ontwikkeltraject beheersbaar te maken. Het ontwerpen en bouwen van informatiesystemen is al lange tijd onderwerp van studie en verbetering. Voor veel informatiesystemen geldt echter dat de kosten van de totale levenscyclus voor slechts een derde gedurende het ontwikkelingstraject gemaakt worden. Daarnaast worden de opbrengsten volledig gedurende de exploitatie van het systeem gerealiseerd. In dit licht is het vreemd dat de meeste theorievorming heeft plaatsgevonden op het gebied van informatieanalyse en systeemontwikkeling en niet op het gebied van de exploitatie en het beheer van de ontwikkelde systemen. De basis van dit boek wordt gevormd door Information Technology Infrastructure Library (ITIL). ITIL kan worden beschouwd als de beschrijving van een op de exploitatie van de IT infrastructuur toegespitst kwaliteitssysteem. Ten behoeve van de IT dienstverlening wordt een aantal noodzakelijke processen onderscheiden en beschreven. De kwaliteit van de dienstverlening en de toegevoegde waarde voor de afnemers staan hierbij centraal. De methodiek is in Engeland door de Central Computer & Telecommunications Agency (CCTA) ontwikkeld. De CCTA is de instantie die de Engelse overheid ondersteunt bij het inrichten van de automatisering. Naast ITIL zijn door de CCTA verschillende andere methodieken ontwikkeld en beschreven zoals de Quality Management Library, PRINCE (Projects IN Controlled Environments), CRAMM (CCTA Risk Analysis and Management Method) en SSADM (Structured Systems Analysis and Design Method). 1.1 Procesbenadering In dit boek worden de processen beschreven die noodzakelijk zijn ter ondersteuning van de exploitatie van de IT infrastructuur. Deze processen zijn: - configuratiebeheer - helpdesk - probleembeheer - wijzigingsbeheer - programmatuurbeheer en distributie. Bij het beschrijven van deze processen zijn twee zaken van belang. Ten eerste dient voor elk proces het doel of de bijdrage aan de organisatie duidelijk te zijn. Daarnaast dient het proces zodanig ingericht te zijn dat dit doel daadwerkelijk gerealiseerd wordt. Kenmerkend voor de procesbenadering is dat deze activiteiten niet noodzakelijk bij een afdeling of functionaris ondergebracht zijn. De activiteiten die deel uitmaken van configuratiebeheer worden bijvoorbeeld uitgevoerd bij afdelingen als computer operations, systeemprogrammering, applicatiebeheer, netwerkbeheer, systeemontwikkeling en de administratie. Een ander kenmerk van de procesbenadering is dat niet de middelen, maar juist de te realiseren doelen centraal staan. 1.2 Doel en structuur van het boek Dit boek is zowel geschreven voor personen die direct betrokken zijn bij de exploitatie van de IT infrastructuur als voor afnemers van automatiseringsdiensten. Voor beide partijen is het van belang dat de kwaliteit van de IT diensten optimaal is en dat tegelijkertijd deze diensten tegen gerechtvaardigde
kosten gerealiseerd worden. Om hierover afspraken te kunnen maken is het noodzakelijk dat bij alle betrokkenen duidelijkheid bestaat over: - de gehanteerde begrippen - de te realiseren doelen - de benodigde inspanning. Deze drie aspecten worden voor elk proces in een apart hoofdstuk beschreven. Ten eerste wordt aangegeven waarom het proces noodzakelijk is. Nadat de problematiek duidelijk is, worden het doel en het te beheren object beschreven. Met de definitie van het object wordt tevens het proces afgebakend. Vervolgens worden de noodzakelijke activiteiten beschreven om het geformuleerde doel te realiseren. Het theoretische deel wordt gevolgd door praktijkvoorbeelden. Hierbij zijn vragen opgenomen die kunnen dienen als basis voor discussie of als individuele oefening. Elk hoofdstuk wordt afgesloten met een samenvatting en een aantal aandachtspunten. Er is nadrukkelijk geen poging gedaan richtlijnen te geven voor de implementatie en beoordeling van de processen. Voor belangstellenden wordt deze problematiek uitvoerig beschreven in de Engelstalige ITIL modulen. 1.3 Enkele basisbegrippen In dit boek wordt een aantal processen beschreven die het beheer en de exploitatie van de IT infrastructuur ondersteunen. Voor een goed begrip van de hoofdstukken waarin de processen beschreven worden, dienen eerst de basisbegrippen gedefinieerd te worden. Deze begrippen zijn: - IT infrastructuur - beheer en exploitatie - gebruiker en opdrachtgever. 1.3.1 IT infrastructuur De IT infrastructuur bestaat uit het geheel van apparatuur, programmatuur, datacommunicatiefaciliteiten plus de daarop van toepassing zijnde procedures en documentatie, dat benodigd is voor de IT dienstverlening Daar waarin het boek gesproken wordt van infrastructuur, wordt gedoeld op de gehele IT infrastructuur. De IT infrastructuur wordt beschouwd als de verzameling productiemiddelen die door de automatiseringsafdeling of het facilitair bedrijf ingezet wordt voor het realiseren van de IT diensten. Zoals alle productiemiddelen moet ook de IT-infrastructuur onder controle gebracht worden om de kwaliteit van de IT dienstverlening zeker te stellen. De kwaliteit van de dienstverlening uit zich hierbij niet alleen in stabiliteit, maar ook in de flexibiliteit van de beheerorganisatie om de infrastructuur aan te passen aan de veranderende behoeften van de afnemers. 1.3.2 Beheer en exploitatie Onder beheer wordt verstaan het uitoefenen van toezicht op en het besturen van de IT infrastructuur. Het uitoefenen van toezicht op de infrastructuur bestaat uit het bewaken van de status en de inzet van (delen van) de infrastructuur. Dit houdt in dat van componenten uit de infrastructuur de status bijgehouden wordt en dat de daaruit voortvloeiende beperkingen in acht genomen worden. Zo kan een systeem dat getest wordt ten behoeve van exploitatie pas na het met goed gevolg doorlopen van de testen ter beschikking gesteld worden voor gebruik. Onder het besturen vallen alle activiteiten die bijdragen aan het op de gewenste wijze doen functioneren van de infrastructuur. Hieronder vallen bijvoorbeeld de bediening van apparatuur, maar ook het aanpassen van de infrastructuur teneinde verstoringen het gebruik op te lossen of te voorkomen. Onder exploitatie van de IT infrastructuur wordt verstaan het tegen gerechtvaardigde kosten ter beschikking stellen van de IT infrastructuur aan de gebruikers teneinde het met de opdrachtgeer overeengekomen of verwante dienstenniveau te realiseren. Naast het beschikbaar stellen van gegevensverzamelingen en de daarbij behorende toepassingsprogrammatuur, de geautomatiseerde informatievoorziening, bestaat de IT dienstverlening ook in toenemende mate uit het ter beschikking stellen van apparatuur, basisprogrammatuur en datacommunicatiefaciliteiten waarvoor de gebruiker zelf, naar behoefte, de toepassing bepaalt. Voor de automatiseerder verplaatst het accent zich hierbij
van informatieanalyse en systeemontwikkeling naar het inrichten en ter beschikking stellen van apparatuur, basisprogrammatuur en datacommunicatiefaciliteiten. 1.3.3 Gebruiker versus opdrachtgever In het boek wordt onderscheid gemaakt tussen directe gebruiker en opdrachtgever. Onder de directe gebruiker wordt verstaan de functionaris of medewerker die voor zijn dagelijkse werkzaamheden gebruik maakt van de IT diensten. Deze diensten kunnen bestaan uit het ter beschikking stellen van een PC of een werkstation tot het verstrekken van gedrukte gegevens. Onder de opdrachtgever wordt verstaan de functionaris die formeel bevoegd is tot het sluiten van een overeenkomst over het kwaliteitsniveau en de kosten van de IT diensten. Dit zal in veel gevallen de budgethouder zijn. Wanneer zowel de gebruiker als de opdrachtgever bedoeld wordt, wordt in het boek de term afnemers gebruikt. 1.4 Samenhang basisprocessen IT diensten worden gerealiseerd door verwerking, netwerkbeheer en beheer van decentrale systemen en werkstations. Verwerking is het proces dat zorgt voor de dagelijkse bediening van alle systemen in de IT infrastructuur. Netwerkbeheer brengt de datacommunicatiefaciliteiten onder controle. Samen met het beheer van decentrale systemen en werkstations worden door deze processen daadwerkelijk de IT diensten gerealiseerd. In de exploitatie van de IT infrastructuur kunnen afwijkingen in de dienstverlening optreden. Deze worden geconstateerd door de gebruikers, apparatuurbediening of netwerkbeheer en doorgegeven aan de helpdesk. Helpdesk is het proces dat enerzijds gebruikers ondersteunt bij het gebruiken van de IT diensten en anderzijds deze afwijkingen of incidenten probeert te verhelpen. Het verhelpen van incidenten moet niet beperkt blijven tot symptoombestrijding. Probleembeheer is het proces dat de achterliggende problemen identificeert en hun oorzaken achterhaalt. Om deze oorzaken weg te nemen en vanwege de veranderende behoefte van gebruikers moeten wijzigingen aan de IT infrastructuur plaatsvinden. Wijzigingsbeheer is het proces dat ervoor zorgt dat deze wijzigingen gecontroleerd ingevoegd worden. Configuratiebeheer is het proces dat de componenten van de IT infrastructuur onder controle brengt. Het verzorgt tevens de informatievoorziening voor de voornoemde processen over de infrastructuur. Programmatuurbeheer en distributie geeft speciale aandacht aan het onder controle brengen van de programmatuur van de IT infrastructuur. Daarbij zorgt het ook voor de distributie van de programmatuur. In de beschrijving van de verschillende processen wordt regelmatig gesproken over het onder controle brengen van objecten of activiteiten. Hieronder wordt verstaan het meester zijn van of in bedwang hebben. Er is bijvoorbeeld sprake van het onder controle hebben van programmatuur wanneer men weet waar deze zich bevindt, in welke toestand deze zich bevindt en men overtuigd is van de kwaliteit van de programmatuur. Inhoudsopgave - Volgende hoofdstuk - Verklarende woordenlijst HOOFDSTUK 2 HELPDESK Doel van de helpdesk - Het incident - Activiteiten van de helpdesk - Samenvatting en aandachtspunten
Inhoudsopgave - Volgende hoofdstuk - Verklarende woordenlijst
H 2 Helpdesk Bij een hoge automatiseringsgraad neemt de afhankelijkheid van de IT infrastructuur in de organisatie toe. Ook de kennis en de verwachting met betrekking tot de mogelijkheden van de automatisering zijn in dat soort organisaties hoog. Automatiseringsafdelingen zijn slechts zeer gedeeltelijk sturend in het
hoe, waar, waarom en wanneer van automatisering. Dit gebeurde in het verleden slechts op basis van execursieve kennis met betrekking tot elkaar snel opvolgende ontwikkelingen en de algemeen geldende noodzaak tot het verspreiden van automatiseringmiddelen. In toenemende mate worden de automatiseringsafdelingen geconfronteerd met de wensen en eisen van gebruikers. De gebruiker ontwikkelt zich tot (betalende) klant, een veeleisende afnemer van IT diensten. Waar een automatiseringsafdeling zich ten opzichte van de klant wil kunnen manifesteren, moet deze afnemers actief benaderen op alle niveaus, zowel op dat van de opdrachtgever als dat van de directe gebruiker. Met de opdrachtgever dienen afspraken vastgelegd te worden over de aard, omvang en kosten van de IT dienstverlening. Het opstellen, beheren en controleren van deze overeenkomsten is het doel van het proces dienstenniveaubeheer (service level management). Dit hoofdstuk gaat over de helpdesk, het proces dat zorgdraagt voor de dagelijkse contacten met de directe gebruiker. De helpdesk is het eerst aanspreekpunt voor alle gebruikers voor vragen, opmerkingen en klachten over het gebruik of de inzet van de automatiseringsmiddelen. 2.1 Doel van de helpdesk Door middel van de helpdesk wordt de IT afdeling toegankelijk gemaakt voor (potentiële) klanten door te functioneren als een punt voor dagelijks contact met betrekking tot het gebruik van de IT infrastructuur. De helpdesk moet hierbij niet alleen in staat zijn om te reageren op vragen van afnemers, zij dient zich ook actief te richten op deze afnemers om op die manier de totale automatiseringsafdeling te profileren als betrouwbare en flexibele partner in het realiseren van de algemene bedrijfsdoelstellingen. Het professionaliseren van deze contacten moet leiden tot wederzijds begrip tussen de directe gebruiker en de IT afdeling. Verhoging van de toegevoegde waarde van de IT dienstverlening kan in veel gevallen gerealiseerd worden door te weten wat de wensen en behoefte van de gebruikers van IT diensten zijn. Anderzijds moeten de gebruikers inzicht krijgen in de mogelijkheden en onmogelijkheden van de automatiseringsafdeling. Door het verbeteren van de ondersteuning aan de gebruiker en daardoor het gezicht van de automatiseringsafdeling. Samenvattend kunnen dan ook als doelen van de helpdesk gesteld worden: - Acceptatie door directe gebruikers van de IT afdeling als dienstverlenend orgaan dat een herkenbare toegevoegde waarde heeft bij de uitvoering van de bedrijfsprocessen. - Toegankelijkheid van de IT afdeling voor vragen, klachten en opmerkingen van directe gebruikers met betrekking tot het inzetten van de beschikbaar gestelde automatiseringsmiddelen. - Continuïteit in de dienstverlening door een zo spoedig mogelijk herstel van het afgesproken dienstenniveau wanneer een afwijking hierop wordt geconstateerd. 2.2 Het incident Tijdens het ter beschikking stellen van de IT infrastructuur kunnen zich allerlei situaties voordoen waarin de gebruiker niet optimaal gebruik kan maken van de faciliteiten. Deze situaties kunnen zich voordoen als gevolg van het niet naar wens of verwachting functioneren van de infrastructuur. Een andere reden kan echter zijn dat er onvoldoende kennis bij de gebruiker bestaat om de systemen ten volle te benutten. In beide gevallen kan dit tot gevolg hebben dat een gebruiker een beroep doet op ondersteuning van de automatiseringsafdeling. Naast meldingen van gebruikers kunnen ook storingen voorkomen waarvan de gevolgen niet direct zichtbaar zijn voor de gebruikers. Hierbij kan gedacht worden aan onvolkomenheden in de batchverwerking of voor de gebruiker transparante (niet zichtbare) verstoringen in datacommunicatie faciliteiten. Hoewel er geen directe consequenties voor de gebruiker zijn, duiden deze verstoringen wel op onvolkomenheden in de infrastructuur of in de organisatie. De genoemde voorbeelden zijn in meer of mindere mate relevant voor het kwaliteitsniveau van de IT dienstverlening. Deze verstoringen worden incidenten genoemd en worden beheerd door de helpdesk. Een incident is gedefinieerd als elke gebeurtenis die afwijkt van de (verwachte) standaardwerking van
een systeem. Een incident heeft invloed op een systeem, hoewel deze invloed klein of zelfs transparant kan zijn voor de gebruiker van het systeem. Incidenten kunnen verschillend van aard zijn. Niet alleen incidenten als gevolg van storingen in de apparatuur of programmatuur worden door de helpdesk beheerd, ook incidenten als gevolg van fouten in procedures of onbekendheid met de wijze waarop toepassingsprogrammatuur gebruikt wordt kunnen tot het aandachtsgebied van de helpdesk behoren. Zoals bij configuratiebeheer is het van belang de reikwijdte en daarmee de verantwoordelijkheid van de helpdesk af te bakenen. Dit gebeurt in eerste instantie door nadere invulling van het begrip incident. Het dient voor zowel de helpdesk als de gebruikers duidelijk te zijn welke gebeurtenissen als incident bij de helpdesk aangemeld kunnen worden. Hierbij dient rekening gehouden te worden met zowel de aard van de gebeurtenis als de component waarop de gebeurtenis betrekking heeft. Vragen met betrekking tot de toepassing van programmatuur kunnen bijvoorbeeld zoveel specialistische kennis van de bedrijfsactiviteiten vereisen dat het ondoenlijk is deze kennis bij de IT helpdesk onder te brengen. Aan de andere kant kan een redelijk eenvoudig te beantwoorden vraag met betrekking tot het configureren van een printer buiten het verantwoordelijkheidsgebied van de helpdesk vallen in het geval dat de configuratie niet tot de automatiseringsafdeling te beheren infrastructuur behoort. 2.3 Activiteiten van de helpdesk Om de gestelde doelen te realiseren worden drie activiteiten van de helpdesk onderscheiden die in de volgende paragrafen zullen worden beschreven, te weten: - communicatie - incidentbeheer - rapportage aan het management 2.3.1 Communicatie en promotie Het belangrijkste doel van de helpdesk is ervoor te zorgen dat de automatiseringsafdeling toegankelijk is voor directe gebruikers en dat deze de automatiseringsafdeling accepteren als een partner in het realiseren van de bedrijfsdoelstellingen. Acceptatie is nauwelijks te realiseren als de communicatie tussen de helpdesk en de gebruikers van IT diensten niet optimaal is. Hiervoor is het noodzakelijk dat de helpdesk inzicht heeft in zowel de verschillende groepen gebruikers als de diensten die door de automatiseringsafdeling geleverd worden. Promotie van bestaande en mogelijk nieuwe diensten kan een bijdrage leveren aan de acceptatie. Nog steeds blijken in veel organisaties bestaande IT diensten niet bekend bij potentiële gebruikers. Hetzelfde geldt voor de mogelijkheden die technologische ontwikkeling of uitbreiding van de infrastructuur bieden. Hierbij dient vanzelfsprekend rekening gehouden te worden met het stadium waarin de automatisering zich bevindt. In een omgeving waar verbreiding van de automatisering prioriteit heeft, zal meer aandacht besteed worden aan de promotie en het stimuleren van IT diensten dan in een omgeving waar consolidatie of bezinning op de inzet van de informatietechnologie plaatsvindt. Promotie van diensten dient daarom altijd afgestemd te zijn op de informatieplanning en het automatiseringsbeleid. Concreet kan deze activiteit bijvoorbeeld ingevuld worden door het uitgeven van een informatieblad, het verzorgen van cursussen en presentaties of het organiseren van excursies. Naast het actief profileren van de IT organisatie door middel van promotie en voorlichting wordt het beeld van de automatiseringsafdeling ook voor een groot deel bepaald door de mate waarin deze toegankelijk is voor vragen, klachten en opmerkingen met betrekking tot de diensten die geleverd worden. Hiervoor dient de helpdesk op de afgesproken tijden bereikbaar te zijn voor gebruikers. Dit stelt eisen aan de personele bezetting en aan de communicatiemiddelen die de helpdesk ter beschikking staan. Om geloofwaardig met klanten te kunnen communiceren moeten de helpdeskmedewerkers bekend zijn met de processen die door middel van automatisering ondersteund worden. Ze moeten zich bewust zijn van de mate waarin deze processen afhankelijk zijn van de automatisering. Alleen dan kan de toegevoegde waarde van de IT afdeling uitgedragen worden. Hierbij dient rekening gehouden te worden met het feit dat voor elke individuele gebruiker de beschikbaarheid van ‘zijn systeem’ voor hem de hoogste prioriteit heeft. Het tijdig verstrekken van informatie over de
operationele systemen zoals een wijziging in de openstellingstijden of het beschikbaar komen van nieuwe documentatie kan veel vragen en ongenoegen voorkomen en zal bijdragen tot de betrokkenheid van de gebruikers bij de automatisering. 2.3.2 Incidentbeheer Een belangrijke taak van de helpdesk is het zorgdragen voor de continuïteit van de dienstverlening. Bij het ter beschikking stellen van informatiesystemen doen zich altijd verstoringen voor. Deze verstoring leidt tot inefficiënties in de bedrijfsprocessen en dienen dus zo spoedig mogelijk verholpen te worden. Deze activiteit wordt incidentbeheer genoemd. Een voorbeeld van een incident is een niet functionerende, ‘hangende’ applicatie. Dit incident kan tot gevolg hebben dat (een deel van) de primaire bedrijfsprocessen onderbroken worden. In dat geval dient het incident zo spoedig mogelijk verholpen te worden. Hierbij kan het voldoende zijn de applicatie opnieuw te starten zodat de benodigde functionaliteit weer beschikbaar komt voor de gebruikers. Op het moment dat de gebruikers weer naar tevredenheid met de applicatie kunnen werken kan het incident worden afgesloten. Er dient duidelijk afgebakend te zijn wat het bereik van de helpdesk is. Worden vragen van procedurele aard ook door de helpdesk beantwoord of beperkt de helpdesk zich slechts tot het (doen) oplossen van storingen met betrekking tot de infrastructuur? Behoren vragen over de administratieve organisatie tot de verantwoordelijkheid van de helpdesk of beperkt de ondersteuning van de helpdesk zich tot de functionaliteit van een applicatie? Hierover moet duidelijkheid bestaan bij de helpdeskmedewerkers en bij de directe gebruikers die een beroep doen op de helpdesk. Incidentbeheer draagt bij aan de beschikbaarheid van de dienstverlening door incidenten zo snel mogelijk te herstellen. Daarbij is het gezichtspunt van de eindgebruiker het uitgangspunt. Voor incidentbeheer kan een aantal deelactiviteiten onderscheiden worden: - detectie en registratie - classificatie en toewijzing - diagnose en oplossing - afsluiting Deze worden in de volgende alinea’s toegelicht. Detectie en registratie Incidenten kunnen in verschillende domeinen hun oorsprong hebben: - centrale faciliteiten - netwerk en datacommunicatie - werkstations en terminals - gebruik en functionaliteit - organisatie en procedures Om incidenten zo snel mogelijk te herstellen zal er actief aandacht besteed moeten worden aan het detecteren van defecten of storingen in alle domeinen. Dit kan bijvoorbeeld gebeuren met behulp zogenaamde monitors. Hiermee wordt voorkomen dat de helpdesk slechts reactief te werk gaat. Incidenten komen dan niet pas onder de aandacht van de helpdesk wanneer zij gemeld worden door een gebruiker. In het beste is een incident reeds verholpen voordat een gebruiker er iets van heeft gemerkt. Op het moment dat een afwijking geconstateerd wordt, vindt registratie van het incident plaats. Dit is noodzakelijk om de voortgang te bewaken en om gegevens ten behoeve van diagnose en oplossing ter beschikking te hebben. Hiervoor worden de symptomen van het incident genoteerd en indien mogelijk het configuratie item waarop het incident betrekking heeft. Vervolgens wordt onderzocht of er een routinematige oplossing bekend is voor het incident. Deze kan bijvoorbeeld vastgesteld zijn in de registratie van problemen en bekende fouten. Indien de juiste oplossing van het incident (nog) niet bekend is, kan eventueel van een tijdelijke herstelactie gebruik gemaakt worden. Een tijdelijke herstelactie kan bijvoorbeeld bestaan uit het ter beschikking stellen van
een reserve werkstation of een vorige versie van de programmatuur. Ook kan de helpdesk bevoegd zijn door wijzigingsbeheer om bepaalde incidenten direct op te lossen door het uitvoeren van een (kleine) wijziging, zoals het tijdelijk vergroten van de toegestane gebruikersruimte op een schijfeenheid. Classificatie en toewijzing Wanneer meerdere, niet direct op te lossen incidenten tegelijkertijd bij de helpdesk in behandeling zijn, zullen er prioriteiten gesteld moeten worden. De prioriteit geeft het onderlinge, relatieve belang aan van de incidenten met betrekking tot snelle afhandeling. Om de prioriteitsstelling te kunnen bepalen vindt eerst classificatie van incidenten plaats. Op basis van de prioriteitsstelling wordt de inzet van beschikbare capaciteiten gericht en bestuurd. De prioriteit van incidenten wordt bepaald door de volgende factoren: - impact - urgentie - verwachte inspanning De impact van een incident is gedefinieerd als de mate waarin dit incident leidt tot een afwijking van het normale niveau van dienstverlening. Voor het definiëren van de impactcodes is het daarom noodzakelijk inzicht te hebben in de wijze waarop de diensten opgebouwd zijn en hoe deze ondersteunend zijn aan de bedrijfsprocessen. De criteria voor de impactbepaling worden in overleg met de organisatie vastgesteld. Bij het bepalen van de impact van een incident spelen de relaties tussen de verschillende componenten in de infrastructuur een belangrijke rol. Deze zijn in de configuratiebeheer database vastgelegd. Met behulp van de configuratiebeheer database kan men bijvoorbeeld achterhalen dat het niet functioneren van een bepaalde applicatie (het incident) een hoge impact heeft, omdat deze applicatie de consistentie van een gegevensverzameling controleert en zekerstelt. De urgentie is de mate waarin de oplossing van een incident uitstel kan verdragen. De urgentie mag niet verward worden met prioriteit. Aspecten die de urgentie beïnvloeden zijn bijvoorbeeld de beschikbaarheid van een tijdelijke oplossing of de mogelijkheid tot het gepland uitstellen van een oplossing. Een werkstation dat dagelijks gedurende kantooruren gebruikt wordt en waarvan het eerste station niet functioneert, kan niet opgestart worden. Voor dit incident is de urgentie voor herstel hoog. Wanneer echter in mei een afwijking geconstateerd wordt in de datumnotatie op de facturen voor het komende jaar, dan dient deze hersteld te zijn voor 1 januari. Hoewel de termijn waarop de correctie gerealiseerd dient te zijn vastgesteld kan worden is in mei de urgentie voor dit incident laag. In tegenstelling tot de urgentie is de impact van dit incident op het moment dat de fout optreedt hoog. In praktijk blikt dat de prioriteit niet alleen door impact en urgentie wordt bepaald, maar dat ook de verwachte inspanning een rol speelt. Een incident met een lage impact en middelmatige urgentie dat echter met relatief weinig inspanning direct verholpen kan worden wordt in veel gevallen direct verholpen. Dit kan bijvoorbeeld het vrijmaken van een toegangscode zijn. Aangezien deze incidenten ook bij de gebruiker als eenvoudig te verhelpen bekend zijn leidt een langere wachttijd als gevolg van lage prioriteit snel tot ongenoegen bij de gebruiker over het functioneren van de automatiseringsafdeling. Dit incident wordt in de praktijk met voorrang verholpen omdat het direct en snel opgelost kan worden. Voor de afhandeling van dit soort routinematig op te lossen incidenten staan veelal macro’s of commandoprocedures ter beschikking die bij acceptatie en registratie van het incident door de helpdesk direct gestart kunnen worden. Incidenten worden in eerste instantie gemeld bij de helpdesk; dit is de eerstelijnsondersteuning. Incidenten waarvoor geen routinematige oplossing beschikbaar is of die het kennisniveau van de helpdesk te boven gaan, worden toegewezen aan functionarissen buiten de helpdesk; dit is de tweedelijns-ondersteuning. Om het toewijzen van de incidenten aan tweedelijns-ondersteuning soepel te laten verlopen dient het voor de helpdesk duidelijk te zijn welke incidenten door welke functionarissen verholpen dienen te worden. Door de verantwoordelijkheid voor categorieën van configuratie items duidelijk in de organisatie te plaatsen wordt de helpdesk in staat gesteld incidenten
met betrekking tot deze configuratie items direct toe te wijzen aan de juiste functionarissen. Hoewel de verantwoordelijkheid voor herstel hiermee overgedragen wordt, blijft de voortgangsbewaking bij incidentbeheer. Diagnose en oplossing Incidentbeheer wordt voornamelijk gekenmerkt door snelheid in het oplossen van incidenten. Op basis van de classificatie en de registratie vindt het diagnosticeren en zo spoedig mogelijk oplossen van incidenten plaats. Er moet een voor de gebruiker bevredigende oplossing aangebracht worden. In het geval dat dit langere tijd in beslag neemt, is het van belang dat de gebruiker op de hoogte gehouden wordt van de voortgang en eventueel op de hoogte gebracht wordt van de ondernomen acties. Om de voortgang van de incidentafhandeling te bewaken is registratie van het oplossingstraject noodzakelijk. Wanneer een incident niet binnen de gestelde tijd opgelost kan worden, dienen maatregelen genomen te worden om de incidentafhandeling te bespoedigen. Het inzetten van meer personen of van personen met meer specialistische kennis is dan een mogelijkheid. Dit wordt escalatie genoemd. Hierbij wordt onderscheid gemaakt tussen functioneler en hiërarchische escalatie. De criteria voor escalatie dienen duidelijk vastgelegd te zijn, evenals de betrokken personen. Bij functionele escalatie wordt een horizontal beroep gedaan op de organisatie om meer gedetailleerde kennis of expertise ter beschikking te stellen. In dit geval betreft het met name gebrek aan specialistische kennis bij de helpdesk. Hoewel het oplossen van het incident dan in een ander deel van de organisatie plaatsvindt, blijft de helpdesk verantwoordelijk voor de voortgangsbewaking van het incident. Bij een fout in een applicatie zal een programmeur ingeschakeld moeten worden. Deze beschikt over de specifieke kennis om een codeerfout te herstellen en heeft toegang tot de bij de applicatie behorende documentatie. In geval van een slechte responsietijd wordt een beroep gedaan op de kennis van een systeemprogrammeur of netwerkspecialist. Bij een hiërarchische escalatie wordt een verticaal beroep gedaan op de organisatie omdat de bevoegdheid om de benodigde beslissing te nemen niet op de helpdesk aanwezig is. In de meeste gevallen zal hierarchische escalatie noodzakelijk zijn voor het ter beschikking krijgen van (meer) mensen en middelen. Deze kunnen bijvoorbeeld nodig zijn voor het op korte termijn herstellen van een reeks fouten in verschillende commandoprocedures. Het kan echter ook zo zijn dat de beslissing genomen moet worden om een bepaalde activiteit juist niet in te voeren. Een systeem voor raadpleging kan beter niet ter beschikking worden gesteld op het moment dat men niet zeker is van de juistheid van de gegevens of de toegangsbeveiling. Afsluiting Afsluiting van het incident kan pas plaatsvinden op het moment dat een voor de gebruiker bevredigende oplossing gevonden en doorgevoerd is. Bij afsluiting hoort ook het coderen van de incidenten zodat analyse op de incidentgegevens door probleembeheer mogelijk gemaakt wordt. Codering van de incidenten vindt plaats bij afsluiting, aangezien pas dan met redelijke zekerheid de categorie, het incidentverloop en de herstelactie bepaald zijn. Het sluiten van het incident wil niet zeggen dat het incident verwijderd kan worden uit de registratie. De geregistreerde gegevens dienen beschikbaar gehouden te worden voor probleem-identificatie en diagnose. 2.3.3 Informatievoorziening De informatie die door de helpdesk opgeleverd wordt, heeft tot doel inzicht te geven in het functioneren van de helpdesk en in de kwaliteit van de dienstverlening. Een indruk van de kwaliteit van de dienstverlening wordt verkregen door informatie over het aantal incidenten waarbij een uitsplitsing naar aard en oorsprong inzicht geeft in zwakke plekken in de infrastructuur. Door de incidenten te groeperen op basis van de impact en te combineren met de hersteltijd kan inzicht verkregen worden in het effect van de verstoringen op de bedrijfsprocessen.
Om inzicht te krijgen in de kwaliteit van de dienstverlening kunnen de volgende gegevens in de rapportage verwerkt worden: - aantal incidenten uitgesplitst naar: dienst impact categorie gebruikersgroep probleem (hierop wordt bij probleembeheer verder ingegaan) - gemiddelde en maximale storingstijd - verdeling storingstijd - bestede tijd / kosten als gevolg van incidenten door: helpdeskmedewerkers tweedelijns-ondersteuning toeleveranciers. Om het functioneren van de helpdesk te beoordelen dient inzicht verkregen te worden in de werklast, uitgedrukt in bijvoorbeeld het aantal en de aard van de afgehandelde incidenten. De tijdsbesteding die hiervoor nodig was, afgezet tegen het aantal beschikbare arbeidsuren, geeft een indruk van de belasting van de helpdesk. Het percentage geëscaleerde of doorverwezen incidenten toont het vermogen van helpdesk om incidenten zelfstanding op te lossen. De door tweedelijns-ondersteuning bestede tijd aan doorverwezen incidenten geeft een indruk van het beroep dat op de ondersteunende groepen gedaan is door de helpdesk. De totaal aan incidenten bestede tijd is indicatief voor de kosten die gemaakt worden als gevolg van fouten in de infrastructuur. 2.4 Samenvatting en aandachtspunten Door te functioneren als een punt voor dagelijks contact met betrekking tot het gebruik van de IT infrastructuur maakt de helpdesk de IT afdeling toegankelijk voor (potentiële) klanten. In het gebruik kunnen zich allerlei situaties voordoen waarin niet optimaal gebruik gemaakt kan worden van de faciliteiten. Deze situatie kunnen zich voordoen als gevolg van het niet juist functioneren van de infrastructuur. Een andere reden kan zijn dat er onvoldoende kennis bij de gebruiker bestaat om de systemen ten volle te benutten. Deze gebeurtenissen vormen incidenten. Ondersteuning van de gebruiker in deze situaties verhoogt de kwaliteit van de IT dienstverlening. Om de incidenten zo snel mogelijk op te lossen worden vier deelactiviteiten onderscheiden: - detectie en registratie - classificatie en toewijzing - diagnose en oplossing - afsluiting Om goed met de gebruikers te onderhouden en aan de andere kant de incidenten te laten oplossen door de beheerorganisatie is het voor de helpdesk essentieel dat de medewerkers over goede contactuele eigenschappen beschikken. Aandachtspunten bij de helpdesk zijn: Draag er zorg voor dat de helpdesk bij alle directe gebruikers bekend is als hét contactpunt naar de IT afdeling Voorkom dat de helpdesk door gebruikers ervaren
wordt als vertragende factor Stel zeker dat de helpdesk over voldoende communicatiemiddelen beschikt om in elke situatie als contactpunt op te kunnen treden. Zorg dat de verantwoordelijkheden ondubbelzinnig verdeeld zijn over de helpdesk en de ondersteunende groepen. Houd er rekening mee dat het beschikken over goede sociale vaardigheden de belangrijkste eigenschap van de helpdeskmedewerker is. Inhoudsopgave - Volgende hoofdstuk - Verklarende woordenlijst HOOFDSTUK 3 PROBLEEMBEHEER Doel probleemleer - Problemen, fouten en incidenten - Activiteiten - Samenvatting en aandachtspunten
Inhoudsopgave - Verklarende woordenlijst
H 3 Probleembeheer In het vorige hoofdstuk werd beschreven hoe incidenten afgehandeld worden door de helpdesk. Hierbij werd het voorbeeld gebruikt van de applicatie die niet meer reageert op invoer van een gebruiker. In veel gevallen kan een incident als dit verholpen worden door de applicatie opnieuw te starten waarna de gebruiker weer verder kan werken. De eigenlijke oorzaak van de verstoring in de dienst is daarmee niet achterhaald, en derhalve ook niet weggenomen. Op geen enkele manier kan gegarandeerd worden dat bij dezelfde of een andere applicatie vijf minuten later dezelfde storing niet ook optreedt. Om de kwaliteit van de diensten op een hoger niveau te brengen zal een inspanning geleverd moeten worden om de achterliggende oorzaak van de incidenten te achterhalen en weg te nemen. In het voorbeeld kan dan blijken dat de connectoren naar de terminals verouderd zijn en voor een slechte verbinding zorgen. Door nieuwe connectoren te installeren kan het aantal incidenten met de terminals drastisch worden verlaagd. Bij het verhelpen van incidenten reageren de medewerkers continue op de gebeurtenissen in de exploitatie. Bij elk incident dat plaatsvindt moet zo spoedig mogelijk het dienstenniveau hersteld worden. Onder deze omstandigheden bestaat nauwelijks de mogelijkheid tot diepere analyse of beoordeling van de gebeurtenissen. Om de oorzaak van de incidenten te achterhalen dient de infrastructuur structureel gecontroleerd te worden op fouten. Het achterhalen en wegnemen van fouten in de infrastructuur is het belangrijkste doel van probleembeheer. 3.1 Doel probleembeheer Probleembeheer streeft naar een zo hoog mogelijke stabiliteit van de IT dienstverlening door het achterhalen en wegnemen van fouten in de infrastructuur. Met de stabiliteit van de dienstverlening wordt bedoeld het met zo min mogelijk verstoringen beschikbaar stellen van de IT infrastructuur. Op het moment dat zich verstoringen voordoen is het de taak van incidentbeheer de gevolgen van de verstoring zo veel mogelijk te beperken. De belangrijkste bijdrage van probleembeheer is het nemen van structurele maatregelen om (herhaling van) verstoringen te voorkomen. Door de inspanning van de organisatie te verleggen van het reageren op grote aantallen incidenten naar het voorkomen van deze incidenten, kan doelmatiger gebruik worden gemaakt van de beschikbare kennis in de beheerorganisatie. Incidenten die zich op willekeurige momenten voordoen vergen meer tijd van de beheerorganisatie dan het aanbrengen van een structurele wijziging waarmee
deze incidenten voorkomen worden. Dit is met name het geval wanneer zich veel overeenkomstige incidenten voordoen. Tevens kan het gericht zoeken naar structurele verbeteringen van de infrastructuur op een meer planmatige manier plaatsvinden, zodat een grotere controle over de werkzaamheden wordt verkregen. Hoewel in eerste instantie een grotere inspanning van de organisatie vereist is, zal na verloop van tijd het aantal incidenten teruglopen als gevolg van een stabieler systeem. Daar waar de helpdesk zich voornamelijk richt op het oplossen van incidenten, bestaat het doel van probleembeheer uit het wegnemen of voorkomen van fouten in de infrastructuur teneinde een zo hoog mogelijke stabiliteit in de IT dienstverlening te bereiken. 3.2 Problemen, fouten en incidenten De objecten die door probleembeheer onder controle gebracht worden zijn; incidenten, problemen en bekende fouten. Incidenten werden reeds in het hoofdstuk over de helpdesk geïntroduceerd. De begrippen probleem en bekende fout worden in de volgende paragrafen toegelicht. 3.2.1 Probleem Het incident met betrekking tot de ‘hangende’ applicatie wijst op een fout in de IT infrastructuur. Waar deze fout zich bevindt, is het echter nog onbekend. Deze fout kan bestaan uit een defect in de apparatuur, een codeerfout bij het programmeren maar ook een procedurefout gedurende de compilatie. In feite geldt voor alle incidenten dat hieraan een fout ten grondslag ligt. In deze gevallen wordt een probleem geïdentificeerd. Een probleem is gedefinieerd als een ongewenste situatie, geïdentificeerd uit incidenten, die indicatief is voor een fout in de IT infrastructuur. Deze fout, die de oorzaak is van de incidenten, is nog onbekend. Het is van belang dat het probleem onderkend wordt, zodat de gevolgen hiervan beperkt kunnen worden en gericht gezocht wordt naar de fout in de infrastructuur. 3.2.2 Bekende fout Pas op het moment dat de werkelijke oorzaak van de incidenten gevonden is, is sprake van een bekende fout. Een bekende fout is gedefinieerd als de ongewenste situatie met betrekking tot de IT infrastructuur, waarbij een bepaald configuratie item geïdentificeerd is als de oorzaak van een (potentiële) degradatie van het IT dienstenniveau. Een bekende fout komt in de meeste gevallen voort uit een probleem. Door het met succes onderzoeken en diagnosticeren van een probleemsituatie wordt een probleem omgezet in een bekende fout. Terugblikkend op de "hangende" applicatie blijkt bijvoorbeeld dat de oorzaak te vinden is in slechte verbindingen. De connectoren van de werkstations blijken van slechte kwaliteit te zijn en worden aangemerkt als dat gedeelte van de IT infrastructuur waar de fout in zit. Aan de basis van alle incidenten ligt een fout in de IT infrastructuur. Deze fouten kunnen niet alleen apparatuur of programmatuur betreffen, ook procedures of documentatie kunnen als foutief configuratie item geïdentificeerd worden. Het betreffende configuratie item zal door een wijziging hersteld, aangepast of vervangen moeten worden. Niet alleen als gevolg van incidenten en probleemdiagnose kunnen fouten in de infrastructuur bekend worden. Ook door leveranciers en gebruikersgroepen kan informatie verstrekt worden over foutieve configuratie items. Voorbeelden hiervan zijn de regelmatige verbeteringen en correcties die leveranciers van basisprogrammatuur ter beschikking stellen om geconstateerde fouten te verhelpen. Hetzelfde geldt voor nieuwe of gewijzigde applicaties die door systeemontwikkeling opgeleverd worden. Door tijdsdruk of als gevolg van wettelijke bepalingen kan toepassingsprogrammatuur die tijdens het testen niet geheel foutvrij blijkt toch in exploitatie worden genomen. Indien deze fouten bekend zijn bij systeemontwikkeling dient de informatie hierover tezamen met de applicatie beschikbaar gemaakt te worden voor probleembeheer. 3.2.3 Het onderscheid Incidenten treden op bij het beschikbaar stellen of de exploitatie van de IT infrastructuur. Elk incident is het gevolg van een fout in de te beheren infrastructuur. Om die fout te achterhalen wordt een probleem
geïdentificeerd. Wanneer is vastgesteld wat het foutieve configuratie item is, wordt het probleem een bekende fout. Een bekende fout moet door een wijziging hersteld worden. Na een succesvolle wijziging is de oorzaak van de incidenten, de fout, weggenomen en zullen deze incidenten, niet meer voorkomen. Pas dan is een structurele oplossing voor de incidenten aangebracht. Kenmerkend voor incidenten is dat deze plaatsvinden in de exploitatie van de IT infrastructuur. In de exploitatie van de infrastructuur vinden die gebeurtenissen plaats die van invloed zijn op de kwaliteit van de diensten. Problemen en bekende fouten hebben betrekking op de IT infrastructuur zelf. Bij het bepalen van de fout wordt gezocht naar het configuratie item dat de oorzaak is van de incidenten. Voor de directe gebruiker van de IT infrastructuur is het van essentieel belang dat incidenten zo spoedig mogelijk worden verholpen. De dienst dient met minimale gevolgen voor de afnemers hersteld te worden. Dit is met name de taak van de helpdesk. Voor het kwaliteitsniveau van de diensten is het van belang dat de infrastructuur zodanig is ingericht dat incidenten zoveel mogelijk voorkomen worden. Probleembeheer richt zich op het aanbrengen van structurele verbeteringen op de infrastructuur. 3.3 Activiteiten Daar waar de helpdesk zich voornamelijk richt op het oplossen van incidenten, bestaat het doel van probleembeheer uit het wegnemen of voorkomen van fouten in de infrastructuur teneinde een zo hoog mogelijke stabiliteit in de IT dienstverlening te bereiken. Het probleemafhandelingstraject begint met het identificeren van een probleem en eindigt met het afsluiten van de bekende fout. Om dit proces inhoud te geven worden zes activiteiten onderscheiden: - probleemidentificatie en registratie - classificatie - allocatie mensen en middelen - foutbeheer - rapporteren aan management In de volgende paragrafen zal nader op deze activiteiten worden ingegaan. 3.3.1 Probleemidentificatie en registratie Bij het identificeren van problemen wordt uitgegaan van het principe dat aan elk incident een fout ten grondslag ligt. In dat geval dat een incident optreedt waarvan de oorzaak (nog) niet bekend is, wordt gesproken van een probleem. Het aantal fouten in de infrastructuur zal in het algemeen beduidend lager zijn dan het aantal incidenten dat daar het gevolg van is. Wanneer het eerste incident optreedt, is dat direct aanleiding tot identificatie van probleem A. De kenmerken van het probleem worden vastgelegd evenals de relatie met incident 1. Indien mogelijk wordt incident 1 opgelost en afgesloten. De oplossing wordt vastgelegd bij probleem A. Bij het optreden van incident 2 worden de kenmerken van het incident vergeleken met die van probleem A. In het geval dat de kenmerken overeenkomstig zijn, wordt bij probleem A de relatie met incident 2 geregistreerd. De bij probleem A vastgelegde oplossing kan gebruikt worden om incident 2 af te sluiten. Dezelfde procedure kan doorlopen worden voor incident 3 en 4. Wanneer bij incident 5 de kenmerken niet overeenkomen met de beschrijving bij probleem A, wordt een nieuw probleem geïdentificeerd. Ook voor probleem B worden de kenmerken en de oplossing van het incident vastgelegd. Wanneer bij detectie van incident 6 de kenmerken van probleem A en B niet overeenkomen met de incidentkenmerken, vindt identificatie van probleem C plaats. Hierbij bestaat de mogelijkheid dat voor incident 6 geen herstelactie beschikbaar is. Incident 7, met de kenmerken van probleem C, wordt toegevoegd aan hetzelfde probleem. Door het toevoegen van dit incident wordt de noodzaak om een oplossing te vinden voor probleem C groter: hieraan zijn nu twee openstaande incidenten gerelateerd. Bij het optreden van incident 8 vindt weer vergelijk van de kenmerken met de bestaande problemen plaats. Op dit moment bestaan er voor het incident drie mogelijkheden: er wordt een oplossing gevonden voor het incident bij probleem A of B, het incident wordt toegevoegd aan probleem C, of het incident leidt tot identificatie van probleem D.
Door op deze wijze te werk te gaan zal altijd elk incident aan een probleem gekoppeld zijn. Hiermee wordt voorkomen dat incidenten verholpen worden zonder dat aandacht besteed wordt aan de onderliggende oorzaak, ook wanneer het incident inmiddels verholpen en afgesloten is. Door de oplossing voor de incidenten vast te leggen bij de problemen blijft de kennis opgedaan uit het oplossen van incidenten beschikbaar voor de organisatie. Wanneer een probleem geïdentificeerd wordt, vindt direct registratie van het probleem plaats. Belangrijk is dat bij registratie de kenmerken, de aan het probleem gerelateerde incidenten en een eventueel beschikbare oplossing worden vastgelegd. Met behulp van deze gegevens kan incidentafhandeling sneller plaatsvinden. Probleemregistratie is tevens noodzakelijk om te voorkomen dat problemen aan de aandacht van de organisatie ontsnappen. Dit risico bestaat met name wanneer de aan het probleem gerelateerde incidenten eenvoudig opgelost kunnen worden. Naast de eerder genoemde informatie dienen daarom ook gegevens vastgelegd te worden ten behoeve van het bewaken van de problemen. Hieronder vallen de status van het probleem, welke functionaris betrokken is bij de verdere afhandeling van het probleem en welke acties inmiddels uitgevoerd zijn. Met behulp van deze informatie kan voortgangscontrole op de probleemafhandeling plaatsvinden. 3.3.2 Classificatie Wanneer een probleem geïdentificeerd is, dient bepaald te worden of en hoeveel aandacht besteed dient te worden aan dit probleem teneinde het foutieve configuratie item in de infrastructuur te ontdekken en te herstellen. Hiervoor is het noodzakelijk inzicht te hebben in de gevolgen van de fout voor de dienstverlening. Na identificatie van een probleem wordt daarom altijd overgegaan tot classificatie van het probleem. Voor classificatie van problemen dienen de volgende stappen genomen te worden: - categoriseren - de impact bepalen - de urgentie bepalen - de prioriteit bepalen Onder categoriseren wordt verstaan het indelen van de totale verzameling problemen in bruikbare groepen. De groepering kan bijvoorbeeld gebaseerd worden op de verantwoordelijkheidsgebieden zoals die zijn gedefinieerd in de beheerorganisatie. Een veel voorkomende indeling is: - apparatuur en basisprogrammatuur - netwerk en datacommunicatie - werkstations en terminals - toepassingsprogrammatuur en functionaliteit - organisatie en procedures Vervolgens moet de impact van het probleem worden bepaald. Het impact wordt bedoeld de uitwerking (in de vorm van gerelateerde incidenten) die een probleem op de overige delen van de IT infrastructuur kan hebben en de gevolgen daarvan voor het dienstenniveau. Hierbij kan rekening gehouden worden met de kans op het optreden van gerelateerde incidenten. Bij het vaststellen van de impact op de configuratie kan een goed ingerichte configuratiebeheer database een belangrijke rol spelen. Door het structureel doorzoeken van de configuratiebeheer database op basis van de gedefinieerde relaties wordt het mogelijk gemaakt de configuratie items te identificeren die afhankelijk zijn, deel uitmaken van of identiek zijn aan het CI waar het incident op van toepassing is. Een optimale situatie ontstaat wanneer in de configuratiebeheer database de hiërarchische relaties tussen de configuratie items gebruikt zijn om de belangrijkheid van de configuratie items voor een of meerdere diensten weer te geven. Met behulp van deze relaties kan dan bepaald worden welke CI’s van belang zijn voor het realiseren van een bepaalde dienst.
Naast de impact dient ook de urgentie vastgesteld te worden. De urgentie waarmee een probleem afgehandeld moet worden bepaald door de mate waarin het wegnemen van de fout uistel kan verdragen. De urgentie kan bijvoorbeeld beïnvloed worden door de frequentie waarmee van de dienst gebruik gemaakt wordt. Een incident met betrekking tot een applicatie die slechts één maal per kwartaal gebruikt wordt kan een hoge impact hebben op de dienstverlening op het moment dat het incident optreedt. Mits het incident wordt verholpen, is aan het begin van het kwartaal de urgentie voor het wegnemen van de fout echter beperkt. Aangezien de beschikbare capaciteit om problemen af te handelen in de meeste gevallen beperkt is, zullen de problemen van een prioriteit voorzien moeten worden. Prioriteit is een ander begrip dan urgentie. De prioriteit geeft de relatieve belangrijkheid van een probleem aan ten opzichte van andere problemen. Het bepalen van de prioriteit heeft dus ook pas zin wanneer een verzameling problemen beschouwd wordt. Het belang van een probleem wordt beïnvloed door de impact en de urgentie van het probleem. Naarmate de gevolgen voor het dienstenniveau en de urgentie tot herstel toenemen, wordt ook het relatieve belang tot het afhandelen van het probleem groter. Het stellen van prioriteiten bij de probleemafhandeling bestaat dus ui het bepalen van de relatieve belangrijkheid van deze problemen. Een bruikbare methode hiervoor is de Pareto-analyse. Pareto-analyse De Pareto-analyse is een methode van onderzoek waarbij alle gebeurtenissen die bijdragen tot een bepaalde conditie worden gerangschikt naar hun relatieve belangrijkheid. Hiermee voorkomt men dat gedetailleerd onderzoek plaatsvindt naar gebeurtenissen die relatief van minder belang zijn. Op basis van de frequentie waarmee de incidenten plaatsvinden kan men zo de aandacht van de beheerorganisatie richten op die problemen waar de gebruikers het meest last van ondervinden. Aan de basis van deze analyse ligt de veronderstelling dat 20% van de problemen 80% van de servicedegradatie veroorzaakt. Om de beschikbare mensen zo efficiënt mogelijk in te zetten kan men zich dus in eerste instantie beperken tot deze 20%. Bij het maken van een Pareto-analyse wordt op basis van de incidentenregistratie de frequentie bepaald waarmee bepaalde incidenten voorkomen. Eventueel wordt in dezelfde grafiek met behulp van een lijndiagram het cumulatieve percentage weergegeven. Het resultaat is een inzichtelijke weergave van de meest relevante problemen. 3.3.3 Allocatie mensen en middelen Identificatie, onderzoek, diagnose en foutbeheer zijn belangrijke activiteiten van probleembeheer. Deze activiteiten moeten leiden tot benoeming en omschrijving van het probleem, het omzetten van het probleem in een bekende fout en het wegnemen van de fout. Gezien de beperkte beschikbaarheid van mensen en middelen in een organisatie zal vastgelegd moeten worden waar en wanneer deze ingezet worden. Op basis van de classificatie van de problemen is het mogelijk de juiste mensen en middelen in te zetten op de problemen met de hoogste prioriteit. Hiervoor dient voldoende inzicht te bestaan in de kennis die in de organisatie aanwezig is. Voor sommige problemen is het noodzakelijk een beroep te doen op externe expertise. In deze gevallen zal de inhoud van onderhoudscontracten en garantiebepalingen bekend moeten zijn. Voor zowel de interne als de externe medewerkers dient duidelijk te zijn welke verantwoordelijkheden en bevoegdheden zij hebben bij het afhandelen van het probleem. 3.3.4 Onderzoek en diagnose Onderzoek en diagnose moet leiden tot het vaststellen van de werkelijke oorzaak van de incidenten. Hierbij is het van belang dat men zich niet beperkt tot de apparatuur, programmatuur en datacommunicatiefaciliteiten. In veel gevallen zal de fout gevonden kunnen worden in procedures, documentatie of menselijk handelen. Om al deze aspecten te kunnen betrekken in het onderzoek is een breed, multidisciplinair team nodig. Het kan bijvoorbeeld noodzakelijk zijn om de afdeling systeemontwikkeling of de leverancier te betrekken bij het onderzoek en de diagnose. Voor diagnose van het probleem dienen zowel feitelijke gegevens als historische en diagnostische gegevens verzameld te worden. Feitelijke gegevens kunnen bijvoorbeeld bestaan uit systeemdocumentatie en installatievoorschriften. Op schrift gestelde procedures en interne werkinstructies kunnen in combinatie met systeemdocumentatie en technische specificaties fouten aan
het licht brengen. De configuratiebeheer database geeft inzicht in de relatie van het betreffende item met andere delen van de IT infrastructuur. Historische gegevens zijn van belang om de ontwikkeling van een probleem inzichtelijk te maken. Deze kunnen verzameld worden aan de hand van de incidenten-, probleem- en foutregistratie. Ook informatie met betrekking tot uitgevoerde wijzigingen kan hierbij relevant zijn. Voor diagnose van het probleem kunnen gegevens worden verzameld in de vorm van een geheugendumps, journalen en logboeken. Met speciale daartoe geëigende diagnostische hulpprogrammatuur kunnen de precieze locaties en de omstandigheden opgespoord worden waaronder het incident optreedt. Om diagnose en onderhoud aan toepassingen te vereenvoudigen is het aan te bevelen diagnostische routines in de programmatuur op te nemen. 3.3.5 Foutbeheer Wanneer de oorzaak van de incidenten door onderzoek en diagnose van het probleem geïdentificeerd is, resulteert dit in een bekende fout. Hoewel een groot deel van de fouten aan het licht gebracht worden door probleemanalyse kan ook systeemontwikkeling een bron van bekende fouten zijn. Tijdens de ontwikkeling van nieuwe systemen kunnen zich problemen voordoen die door onderzoek en diagnose een (voor systeemontwikkeling) bekende fout worden. Als gevolg van interne of externe factoren, bijvoorbeeld nieuwe producten of wettelijke maatregelen, is het mogelijk dat een programma in exploitatie genomen moet worden inclusief de op dat moment bekende fouten. In deze situaties is het noodzakelijk da met de bij de programmatuur behorende documentatie ook de bekende fouten worden overgedragen aan de beheerorganisatie. Het doel van foutbeheer is het verhelpen van fouten in de IT infrastructuur, zodat het overeengekomen dienstenniveau gerealiseerd kan worden. Naast het wegnemen van fouten bestaat foutbeheer ook uit het minimaliseren van de negatieve gevolgen van een bestaande fout. Om een fout te herstellen zal in veel gevallen een wijzing op de IT infrastructuur nodig zijn. Het uitvoeren van deze wijziging vindt plaats onder controle van wijzigingsbeheer. Het voorbereiden van een wijzigingsvoorstel is onderdeel van foutbeheer. Het voorbereiden van een wijzigingsvoorstel houdt onder andere in dat verschillende oplossingsalternatieven afgewogen worden. Een van deze alternatieven dient uitgewerkt te worden met betrekking tot de benodigde middelen en de te verwachten inzet. Pas wanneer de evaluatie van de wijziging heeft plaatsgevonden en is vastgelegd dat de oorzaak van de incidenten inderdaad is weggenomen kan de bekende fout worden afgesloten. 3.3.6 Informatievoorziening Ook probleembeheer levert enerzijds informatie aan het management ten behoeve van het bewaken van het proces zelf en anderzijds informatie ter ondersteuning van de overige processen. De managementrapportage dient inzicht te geven in de belasting van de organisatie als gevolg van het onderzoeken, diagnosticeren en oplossen van problemen. Hierbij is het van belang ook inzicht te geven in de voortgang die hierbij geboekt wordt. Met name bij probleemanalyse is dat niet eenvoudig, omdat werkelijke oorzaak van de incidenten nog niet bekend is. Bij foutbeheer is duidelijker aan te geven wat de beoogde resultaat is en welke activiteiten daarvoor uitgevoerd moeten worden. Ten behoeve van de managementrapportage kan de volgende informatie opgenomen worden: - bestede tijd aan onderzoek en diagnose per afdeling of toeleverancier uitgesplitst naar de verschillende problemen - korte beschrijving van reeds ondernomen acties - planning openstaande problemen met betrekking tot inzet van mensen inzet van middelen kosten - korte beschrijving van te ondernemen acties
Informatie over zwakke componenten in de infrastructuur en afwijkingen van de met toeleveranciers overeengekomen ondersteuningsniveaus is van belang voor beschikbaarheidbeheer. De frequentie en de duur van incidenten is een belangrijke bron van informatief voor controle van het overeengekomen dienstenniveau: - aantallen problemen uitgesplitst naar: status dienst impact categorie gebruikersgroep - doorlooptijd van gesloten problemen - verstreken tijd openstaande problemen - eventuele tijdelijke herstelacties - verwachte oplossingstermijn openstaande problemen. 3.4 Samenvatting en aandachtspunten Het doel van probleembeheer is een zo hoog mogelijke stabiliteit van de IT dienstverlening door structurele oplossingen te vinden voor problemen in de dienstverlening. Problemen ontstaan als gevolg van een fout in de IT infrastructuur. Incidenten maken het mogelijk deze problemen te identificeren. Door de aandacht van de IT organisatie te richten op het wegnemen van de onderliggende fouten wordt doelmatiger gebruik gemaakt van de kennis die in de organisatie aanwezig is en zal het niveau van dienstverlening structureel verbeterd worden. Op het moment dat een probleem geïdentificeerd wordt, dient zo spoedig mogelijk de fout achterhaald te worden zoadat maatregelen genomen kunnen worden om de fout te herstellen. Het probleemafhandelingstraject begint met het identificeren van een probleem. Om de mensen en middelen waarover de organisatie beschikt optimaal in te zetten wordt het probleem eerst geclassificeerd. Op basis van deze classificatie worden de mensen ingezet om het probleem te onderzoeken en te diagnosticeren. Hiermee wordt het probleem omgezet in een bekende fout. Om de fout uit de infrastructuur te verwijderen moet in de meeste gevallen een wijziging uitgevoerd worden. Pas nadat de wijziging is uitgevoerd, kan de bekende fout afgesloten worden. Aandachtspunten bij probleembeheer zijn: Draag zorg voor optimale verhoudingen tussen wijzigingsbeheer, de helpdesk en de ondersteunende afdelingen. Voorkom dat probleembeheer ondergeschikt wordt aan ad hoc incidentafhandeling Voorzie de betrokken medewerkers van voldoende hulpmiddelen om het onderzoek en de diagnose juist uit te voeren Stel zeker dat in de ontwikkelomgeving bekende fouten met de nieuwe of gewijzigde programmatuur worden overgedragen. Inhoudsopgave - Verklarende woordenlijst
VERKLARENDE WOORDENLIJST "ITIL" Terug naar Inhoudsopgave
A-B-C-D-E-F-G-H-I-J-K-L-M-N-O-P-Q-R-S-T-U-V-W -X-Y-Z Nederlandse term (ITIL-term) Definitie -A-BBasisconfiguratie (Baseline) Een selectie van de configuratiebeheer database die apart wordt opgeslagen voor een bepaald doel. Dit kan bijvoorbeeld bestaan uit het vastleggen van de opbouw van (een deel van) de IT infrastructuur in een stabiele situatie, zodat men hierop terug kan vallen Beheer Het geheel van activiteiten ten behoeve van het bestuur van en het toezicht op onder controle te brengen objecten. Bekende fout (known error) Een conditie in de IT infrastructuur waarbij een bepaald configuratie item geïdentificeerd is als de oorzaak van een (potentiële) degradatie van het overeengekomen serviceniveau. -CCBDB detailleringniveau (CI level) Het laagste niveau waarop nog uniek identificeerbare items onderscheiden worden. Classificatie Waarderende ordening op basis van categorie, impact en urgentie. Kan ondersteunend gebruikt worden aan prioriteitsbepaling. Configuratie item (Configuration item) Een component deel uitmakende van of direct gerelateerd aan de IT infrastructuur zoals documentatie. Een eenheid kan zowel dingen als functies of beide, en in bepaalde gevallen ook mensen betreffen. Een aantal eenheden, bijvoorbeeld een populatie van eenheden of een samengestelde groep van eenheden, kan zelf ook weer als een eenheid worden beschouwd. Configuratiebeheer (Configuration Management) Het proces dat alle componenten fan de IT infrastructuur (automatiseringsmiddelen) en de daaraan gerelateerde documentatie onder controle brengt ter ondersteuning van de overige Service Management processen (in het bijzonder incident, probleem en wijzingbeheer) om tegen gerechtvaardigde kosten kwalitatieve diensten te realiseren in de context van steeds wijzigende gebruikerswensen. Configuratiebeheer database (Configuration Management Database) De gegevensverzameling waarin informatie met betrekking tot de Configuratie Eenheden wordt vastgelegd en beheerd. -DDirecte gebruiker (User) De directe afnemer van IT Services. Deze kan uit alle managementof operationele niveaus van de organisatie komen, zowel van de kern- als van ondersteunende of besturende delen. Ook in de IS-ontwikkelingorganisatie en de exploitatie- en beheerorganisatie vinden wij klanten. -EExploitatie Het tegen gerechtvaardigde kosten ter beschikking stellen van de IT infrastructuur aan de gebruikers teneinde het met de opdrachtgever overeengekomen of verwachte dienstenniveau te realiseren. -FFoutbeheer (Error Control) Het verhelpen van fouten in de IT infrastructuur zodat het
overeengekomen dienstenniveau gerealiseerd kan worden. Naast het wegnemen van fouten bestaat foutbeheer ook uit het minimaliseren van de negatieve gevolgen van een bestaande fout. Functionele escalatie Bij functionele escalatie wordt een horizontaal beroep gedaan op de organisatie om meer gedetailleerde kennis of expertise ter beschikking te stellen. -G-HHelpdesk (Help desk) Het proces dat de IT afdeling toegankelijk maakt voor (potentiële) afnemers van de IT diensten door te functioneren als een punt voor dagelijks contact met betrekking tot het gebruik van de IT infrastructuur. Hiërarchische escalatie Bij hiërarchische escalatie wordt een verticaal beroep gedaan op de organisatie omdat de bevoegdheid om een noodzakelijke beslissing te nemen niet aanwezig zijn. -IImpactanalyse (Impact Analysis) Een kwantitatieve onderzoeksmethode waarbij een studie wordt verricht naar de uitwerking die een fout kan hebben op de overige delen van de configuratie en de gevolgen daarvan voor het dienstenniveau, waarbij rekening wordt gehouden met de kans op optreden en de ernst van de fout. Incident Elke gebeurtenis afwijkend van de (verwachte) standaardwerking van een systeem. Het heeft invloed op dit systeem hoewel deze invloed klein of zelfs transparant kan zijn voor de gebruiker van dit systeem. De beëindiging van de mogelijkheid van een Configuratie Eenheid om een vereiste functie te vervullen. Na het incident vertoont het object een fout. Een incident is dus een gebeurtenis in tegenstelling tot een fout, die een toestand weergeeft. Incidentbeheer (incident control) Beheer van het volledige oplossingstraject van alle zich voordoende incidenten. IT infrastructuur Het geheel van technologische componenten, systeem- en toepassingssoftware, procedures en documentatie benodigd voor het beschikbaar stellen van een of meerdere informatiesyste(e)m(en). -J-KKwaliteitsniveau Een maat voor kwaliteit, uitgedrukt in termen van een kwantitatieve grootheid, zoals foutieve producten, beschikbaarheidspercentage, responsietijd, enzovoort -L-M-N-OOpdrachtgever Functionaris bevoegd tot het onderhandelen van Service Niveau Overeenkomsten. Dit wil zeggen dat zowel de afspraken met betrekking tot de diensten als de daarmee gepaard gaande kosten bindend vastgelegd kunnen worden. -PPareto-analyse Een methode van onderzoek waarbij alle factoren die bijdragen tot een bepaalde gebeurtenis (fout) worden gerangschikt naar hun relatieve belangrijkheid met het doel zich voor verdere gedetailleerd onderzoek te kunnen beperken tot de meest belangrijke factoren. Prioriteit De relatieve waardering van een activiteit ten opzichte van andere activiteiten. Eigenschap van vooraf te gaan aan of voorrang te hebben boven iets of iemand anders.
Probleem (Problem) Een conditie van de IT infrastructuur geïdentificeerd uit incidenten met overeenkomstige symptomen, of een significant incident, indicatief voor een fout waarvan de oorzaak nog onbekend is. Probleembeheer (Problem control) Het achterhalen en wegnemen van fouten in de infrastructuur. Probleemdiagnose De handelingen die leiden tot het onderkennen van een fout, het lokaliseren van de storing en het vaststellen van de oorzaak. Programmatuur item (Software item) Een logisch geheel van systeem- of toepassingsprogrammatuur, indien mogelijk in de vorm van broncode, plus de daarbij behorende documentatie. Programmatuuruitgave (Release) Het geheel van nieuwe, gewijzigde of bestaande programmatuur items dat op een moment beschikbaar wordt gemaakt voor exploitatie. Programmatuurbeheer en distributie (Definitive Software Library) De verzameling van alle versies van programmatuur items die door systeemontwikkeling of externe leveranciers zijn overgedragen voor exploitatie. De programmatuur items worden in definitieve, geteste vorm vastgelegd. -Q-R-S-T-UUrgentie De mate waarin een handeling geen uitstel kan verdragen. -VVisgraatdiagram Een diagram dat laat zien hoe een bepaalde foutensoort in een geheel verband houdt met mogelijke foutensoorten van onderdelen van onderdelen, met uitwendige omstandigheden of met een combinatie daarvan. (Ook: Storingsboom) -WWijziging (Change) Een handeling die leidt tot een nieuwe status van een of meerdere configuratie items. Wijzigingsbeheer (Change Management) Het zodanig uit (laten) voeren van wijzigingen, dat verstoringen en afwijkingen van het dienstenniveau als gevolg van deze wijzigingen zo min mogelijk voorkomen. Hiertoe wordt er op toegezien dat beproefde methoden en technieken gebruikt worden voor de voorbereiding, bouw, test en implementatie van nieuwe of gewijzigde configuratie items. Wijzigingscommissie (Change Advisory Board) Deze commissie is verantwoordelijk voor beoordeling en planning van alle wijzigingen van meer dan geringe omvang. Alle betrokkenen en belanghebbenden zijn hierin vertegenwoordigd zodat het hele wijzigingstraject beoordeeld en gepland kan worden. Wijzigingsvoorstel (Request for Change) In het wijzigingsvoorstel is vastgelegd waaruit de wijziging bestaat en op welk configuratie item de wijziging betrekking heeft. Aan de hand van dit voorstel worden de gevolgen beoordeeld en het verdere verloop van de wijziging gepland. -X-Y-ZTerug naar Inhoudsopgave
