Inhoudsopgave

1. Inleiding 
2. Samenhang tussen Probleem- , Wijzigings-  en Configuratiebeheer 
3. Specificatiebeheer 
4. Configuratiebeheer 
5. Probleembeheer
6. Wijzigingsbeheer
7. Prestatiebeheer
8. Beveiligingsbeheer 
9. Operations beheer
10. Slotopmerking

1. Inleiding

Het functionele applicatiebeheer is in veel organisaties nog steeds een ondergeschoven kindje. In veel gevallen komt dit door de gerichtheid van methodieken als ITIL op de ICT-afdeling en het ontbreken van de invalshoek van de gebruikers. Als basis voor dit artikel hebben we gekozen voor de benadering van professor Looijen, die in zijn modellen wel de invalshoek van de gebruikers belicht en tevens met zijn modellen zodanig dicht bij ITIL staat dat er geen spraakverwarring zal ontstaan. Wel hebben we het onderscheid aangehouden tussen operationele en tactische processen, zoals ITIL dit hanteert.
Het artikel is tamelijk theoretisch van opzet; in de praktijk zal bekeken moeten worden wie wat uitvoert. Aandacht voor het beleggen van verantwoordelijkheden is echter wel van belang. (Zie ook ‘Blauwdruk processen IT-organisatie’.)
Dit artikel is onderdeel van een serie artikelen, die alle bepaalde aspecten belichten van dit onderwerp. Op de rubriekspagina vindt u een totaal overzicht van de artikelen, die intussen zijn verschenen.
Laat u niet in de war brengen door de verschillende benamingen die u in de praktijk tegenkomt, zoals bijvoorbeeld functioneel beheer, functioneel systeembeheer, klantenbeheer, applicatiebeheer en dergelijke. Wij hanteren in de artikelen consequent het begrip ‘functioneel applicatiebeheer’.
In dit artikel zullen de processen beschreven worden, welke binnen het functioneel applicatiebeheer op operationeel niveau een belangrijke plaats innemen. De processen worden conform Looijen beschreven in hun meest ideale vorm, gebaseerd op een horizontale en verticale functiescheiding binnen de Bedrijfsvoering van Informatievoorziening. (Zie ‘Organisatie en inrichting functioneel applicatiebeheer’.)

1.1 Procesvelden binnen het operationeel functioneel applicatiebeheer

In de volgende hoofdstukken gaan we in op de samenhang tussen de procesvelden Probleem-, Wijzigings- en Configuratiebeheer. Vervolgens werken we alle procesvelden voor het operationeel functioneel applicatiebeheer op hoofdlijnen verder uit.

2. Samenhang tussen Probleem- , Wijzigings-  en Configuratiebeheer

Het Probleem-, Wijzigings- en Configuratiebeheer is niet alleen zaak voor het functioneel applicatiebeheer of voor één van de andere bedrijfsvoeringsfuncties. Op beheerniveau verloopt er namelijk een wisselwerking tussen alle drie de bedrijfsvoeringsfuncties via het afhandelen van incidenten, problemen, wijzigingsvoorstellen en wijzigingsverzoeken. De samenhang wordt verder in de volgende paragrafen toegelicht. Deze toelichting zal echter wel, in het kader van dit artikel, expliciet vanuit het Gebruiken beschreven worden.

2.1 Afhandelen van incidenten

Gebruikers melden hun incidenten aan bij de Helpdesk. De Helpdesk probeert het incident zo goed mogelijk af te handelen. Daarnaast registreert de Helpdesk de gemelde incidenten en de wijze van afhandeling. Vervolgens worden deze registraties naar het Probleembeheer overgebracht binnen de Bedrijfsvoeringsfunctie Gebruiken. Eén (de)centrale functioneel applicatiebeheerder is vaak verantwoordelijk voor dit Probleembeheer.
Indien de functioneel applicatiebeheerder bepaalt dat een incident niets met Gebruiken te maken heeft, draagt deze het incident over aan het Probleembeheer binnen het Exploitatiebeheer. Het Exploiteren is immers verantwoordelijk voor het beschikbaar en werkend zijn van de automatiseringsmiddelen.
Een omgekeerde situatie kan zich ook voordoen, wanneer het Probleembeheer binnen Exploiteren een incident aangemeld heeft gekregen dat direct met het Gebruiken te maken heeft. In een dergelijk voorkomend geval zal het Probleembeheer binnen Exploitatiebeheer dit incident of probleem overdragen aan de functioneel applicatiebeheerder die verantwoordelijk is voor het Probleembeheer binnen het Gebruiken.
Ten aanzien van het Probleembeheer zal het functioneel applicatiebeheer zijn aandacht primair richten op het herstellen van de dienstverlening.
Natuurlijk geldt dit ook voor het Probleembeheer binnen het Exploiteren. Daarvoor zal men, aan de hand van symptomen van de geregistreerde incidenten, trachten deze te clusteren tot een herkenbaar probleem. Daarna zal men gaan zoeken naar de werkelijke oorzaak van het probleem. Slaagt het functioneel applicatiebeheer hierin niet, dan wordt het probleem aangemeld bij het Probleembeheer binnen de Bedrijfsvoeringsfunctie Onderhouden.

2.2 Afhandelen van problemen

Wanneer de werkelijke oorzaak van een probleem gevonden is, is er sprake van een bekende fout of afwijking. Deze afwijking dient vervolgens hersteld te worden. Om het herstelproces in gang te zetten kan het functioneel applicatiebeheer de afwijking indienen bij het wijzigingsbeheer.
Was het functioneel applicatiebeheer niet in staat om de werkelijke oorzaak van een probleem te bepalen, dan dient het Probleembeheer van het Onderhouden deze oorzaakbepaling uit te voeren. Hiertoe zal men dan vaak specialistische hulp inroepen. In de eerste plaats zal deze hulp bestaan uit een advies inzake het zonodig spoedig herstellen van de dienstverlening.
Zodra de dienstverlening hersteld is, wordt nagegaan of daarmee ook de oorzaak verholpen is. Is dat niet het geval dan blijft het probleem aangemeld staan bij het Probleembeheer binnen Onderhouden.
Dit Probleembeheer regelt dat binnen Onderhoud het probleem geanalyseerd en de oorzaak van het probleem opgespoord wordt. Aan de hand van de analyse en de oorzaak kan het Probleembeheer binnen Onderhouden een oplossing aangeven voor het probleem.
Deze oplossing wordt dan teruggemeld aan het functioneel applicatiebeheer of aan het Probleembeheer binnen Exploiteren.
Ook kan het voorkomen dat een probleem niet op te lossen is. In een dergelijk geval wordt het probleem als onoplosbaar teruggemeld. Een probleem kan onoplosbaar blijken te zijn, wanneer de oorzaak niet te achterhalen is. Het incident is dan ook niet te reproduceren en in de meeste gevallen zijn er te weinig gegevens vastgelegd over de incidentsituatie.
Na de terugmelding dat een probleem een afwijking is, zal het Probleembeheer binnen het functioneel applicatiebeheer de afwijking indienen bij het Wijzigingsbeheer. Het Wijzigingsbeheer zorg ervoor dat de afwijking (op basis van de aangedragen oplossing voor het probleem) verholpen wordt en zal, zodra de afwijking daadwerkelijk verholpen is, dit terugmelden aan het Probleembeheer.

2.3 Afhandelen wijzigingsvoorstellen

Het Wijzigingsbeheer binnen het Gebruiken registreert de aangemelde afwijkingen en wijzigingsvoorstellen. Vervolgens dient het Wijzigingsbeheer er zorg voor te dragen dat de wijziging die noodzakelijk is naar aanleiding van de afwijking of het wijzigingsvoorstel in een wijzigingsverzoek herschreven wordt. Hiervoor zal vaak de hulp van het decentraal functioneel applicatiebeheer ingeroepen worden. Meerdere afwijkingen en/of wijzigingsvoorstellen kunnen tot één wijzigingsverzoek gecombineerd worden.
Het wijzigingsverzoek dient aan het Onderhoudsbeheer ondubbelzinnige duidelijkheid te verschaffen over de wijziging die gewenst wordt.
Het registreren van afwijkingen en wijzigingsvoorstellen en het samenstellen van wijzigingsverzoeken kunnen belegd zijn bij het (centraal) functioneel applicatiebeheer.

2.4 Afhandelen van wijzigingsverzoeken

Het wijzigingsverzoek gaat naar het Wijzigingsbeheer van de Onderhoudsfunctie. Dit draagt er zorg voor dat binnen het Onderhoudsbeheer een impactanalyse wordt uitgevoerd. De impactanalyse geeft aan wat de consequenties zijn van de wijziging en op welke termijn de wijziging gerealiseerd kan worden. De bepaalde consequenties worden in overleg tussen de verschillende Bedrijfsvoeringsfuncties geëvalueerd, waarna een besluit genomen wordt ten aanzien van de realisatie van de wijziging. Dit besluit kan zijn: realiseren, uitstellen of afwijzen.
Nadat het besluit tot realisatie is genomen, draagt het Wijzigingsbeheer binnen de Bedrijfsfunctie Onderhouden zorg voor de coördinatie van alle activiteiten om de voorgenomen wijziging te bewerkstelligen. Daartoe geeft het Wijzigingsbeheer een opdracht tot wijziging aan het procesveld Uitvoeren van Onderhoud.
Wanneer de wijziging gereed is, meldt het Wijzigingsbeheer van de Onderhoudsfunctie dit aan het Wijzigingsbeheer van de Gebruiks-  en Exploitatiefunctie. In gezamenlijk overleg wordt de in-bedrijfname gecoördineerd, eventueel met assistentie van de Onderhoudsfunctie.

2.5 De helpdesk

In sommige gevallen is het erg moeilijk om vast te stellen of een incident een gebruiks- of een exploitatie-incident is. Daarom kan het zinvol zijn om het Probleembeheer van de Gebruiks- en Exploitatiefunctie samen te voegen. In de meeste gevallen wordt een dergelijke samenvoeging van processen ‘Helpdesk’ genoemd. Door middel van de Helpdesk ontstaat er een punt voor dagelijks contact met betrekking tot het gebruik van automatiseringsmiddelen.
Het professionaliseren van deze contacten moet leiden tot een wederzijds begrip tussen de directe gebruiker en de functionarissen die verantwoordelijk zijn voor de automatiseringsmiddelen. Door het verbeteren van de ondersteuning aan de gebruiker zal verstoring van de primaire bedrijfsprocessen gereduceerd kunnen worden, wat natuurlijk de gehele organisatie ten goede komt.
De procesvelden die binnen een Helpdesk voor komen kunnen uitgebreider zijn dan alleen het Probleembeheer.
Ook het assisteren bij incidenten en een eerste analyse van een probleem kunnen ondergebracht zijn bij de Helpdesk. Daarnaast kan De Helpdesk ook het aannemen en coördineren van wijzigingsvoorstellen uitvoeren. Op deze wijze kan de Helpdesk fungeren als een communicator voor alle Bedrijfsvoeringsfuncties.
De belangrijkste reden voor het inrichten van een Helpdesk is, dat er één punt binnen de organisatie bestaat waar men met incidenten, vragen en opmerkingen inzake de informatievoorziening terecht kan.

3. Specificatiebeheer

Het Specificatiebeheer binnen het Gebruiksbeheer valideert de functionele specificaties ten behoeve van het gebruik en de standaards inzake de onderhoudbaarheid van de automatiseringsmiddelen. Op basis van deze functionele specificaties en standaards accepteert het Specificatiebeheer de gewijzigde automatiseringsmiddelen.
Bij specificaties ten behoeve van het gebruik kan met betrekking tot het functioneel applicatiebeheer in de eerste plaats gedacht worden aan de functionele specificaties. Deze functionele specificaties beschrijven de functionaliteit van de informatievoorziening en bestaan uit een beschrijving van de informatiefuncties, de functionele gegevensdefinities, de gebruikersinterfaces en de interfaces met andere informatiefuncties. Bovendien worden ook de acceptatietest-sets, gericht op het testen van de functionaliteit, tot de functionele specificaties gerekend.
Daarnaast zijn er ook nog functionele specificaties voor algemene software en systeemsoftware. Tenslotte zijn er ook nog specificaties in de vorm van standaards en richtlijnen die verband houden met het kunnen onderhouden van de automatiseringsmiddelen. Een voorbeeld van deze standaards en richtlijnen is ondermeer het gebruik van een bepaalde ontwikkelmethode. Het Specificatiebeheer voor het functioneel applicatiebeheer omvat de volgende processen:

• valideren;
• onderhouden van acceptatietest-sets;
• beoordelen van de resultaten van uitgevoerde acceptatietests.

3.1 Valideren

Beoordelen:
Nagaan of de aangepaste functionele specificaties of standaards voldoen aan de bedoelingen van de gebruiker of onderhouder, zoals die geformuleerd zijn in de wijzigingsvoorstellen.

Controleren:
Vaststellen of de aangepaste specificaties compleet zijn, consistent met andere specificaties of dat ze consequenties hebben voor het serviceplan.

3.2 Het onderhouden van acceptatietest-sets

 
Initiëren van aanpassingen:
Aan de hand van afwijkingen of van wijzigingsopdrachten nagaan of het noodzakelijk is dat de acceptatietest-sets aangepast worden.
 
Beoordelen van de resultaten van de acceptatietest-sets:
Nagaan of de acceptatietest-sets in overeenstemming zijn met de functionaliteiten, standaards en afwijkingen die getest moeten worden.

3.3 Beoordelen resultaten acceptatietests

 
Beoordelen van resultaten:
In principe dienen er na iedere wijziging acceptatietests te worden uitgevoerd. Specificatiebeheer beoordeelt of de juiste acceptatietests zijn uitgevoerd en beoordeelt het resultaat van de uitgevoerde acceptatietests.

4. Configuratiebeheer

Binnen de Gebruiksfunctie is voor het Configuratiebeheer de configuratie-identificatie als proces te onderscheiden. Dit proces bestaat uit:

• het bijhouden van configuratie-items;
• het bijhouden van gerelateerde gegevens;
• configuratietoetsing.

4.1 Onderhouden van configuratie-items

De Gebruiksfunctie kent haar eigen configuratie-items die beheerd moeten worden. Van belang is dat de registratie overeenkomstig de werkelijkheid is. Configuratie-items kunnen zijn:

• hardware, zoals stand-alone PC’s, randapparatuur, netwerkterminals, netwerkkaarten, harde schijven;
• software, zoals systeemsoftware en standaardtoepassingspakketten;
• testsets, zoals acceptatietests;
• databases en bestanden, waarbij indeling, omvang en groei geregistreerd worden;
• documentatie, zoals specificaties, handleidingen, procedures en gebruiksrichtlijnen;
• contracten, zoals gebruikslicenties, onderhoudsafspraken in verband met huur, koop of lease van middelen;
• personen, zoals leveranciers, gebruikers waarbij het gebruik van informatiesystemen en beveiligingsaspecten vastgelegd worden en exploitatie/onderhoudspersoneel.

4.2 Onderhouden gerelateerde gegevens

Aan ieder configuratie-item is een aantal gegevens verbonden. Deze gegevens dienen up to date gehouden te worden.

4.3 Configuratietoetsing

Het is zinvol om periodiek of op verzoek de werkelijkheid aan de registratie te toetsen, verschillen te analyseren en bij te werken.

5. Probleembeheer

Het probleembeheer is verantwoordelijk voor de afhandeling van incidenten en problemen en moet zorgdragen voor het voorkomen van problemen.
De hierna volgende processen zijn binnen het Probleembeheer van de Gebruiksfunctie te onderkennen:

• aannemen en registreren van een incident of probleem;
• geven van directe ondersteuning inzake het verhelpen van een incident;
• opsporen van een probleem en initiëren van het afhandelen ervan ;
• bewaken van de voortgang van het afhandelen van een incident, probleem of afwijking;
• proactief bezig zijn om problemen te voorkomen.

5.1 Aannemen en registreren van een incident of probleem

Registratie:
Bij aanname wordt het incident of het probleem geïdentificeerd en geregistreerd. Daarbij worden allerlei gegevens vastgelegd, zoals aanmelder, aanmeldtijdstip, tijdstip waarop incident of probleem zich voordeed, plus alle relevante gegevens om het incident of het probleem adequaat te kunnen verhelpen of op te lossen. Deze registratie kan ook door de Helpdesk verzorgd worden.

Classificatie:
Nadat een probleem geregistreerd is, dient men te bepalen of en hoeveel aandacht besteed dient te worden aan dit probleem teneinde het foutieve configuratie-item binnen de automatiseringsmiddelen te ontdekken en te herstellen. Hiervoor is het noodzakelijk inzicht te hebben in de gevolgen van de fout voor het Direct Gebruik.
Voor classificatie van problemen dienen de volgende stappen genomen te worden: categoriseren, impactbepaling, urgentiebepaling en prioriteitbepaling.
Onder categoriseren wordt verstaan het indelen van de totale verzameling problemen in bruikbare groepen zoals bijvoorbeeld: apparatuur en basisprogrammatuur, netwerk en datacommunicatie, werkstations en terminals, toepassingsprogrammatuur, functionaliteit en organisatie en procedures.
Impactbepaling houdt in de uitwerking die een probleem op de overige delen van de automatiseringsmiddelen kan hebben en de gevolgen daarvan voor het Direct Gebruik. Bij het vaststellen van de impact 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 van het configuratie-item waar het probleem op van toepassing is, daarvan deel uitmaken van of er identiek aan zijn.
De urgentie waarmee een probleem afgehandeld moet worden, wordt bepaald door de mate waarin het wegnemen van de fout uitstel kan verdragen. Een probleem met betrekking tot een applicatie die slechts éénmaal aan het eind van een kwartaal gebruikt wordt kan een hoge impact hebben voor het Direct Gebruik op het moment dat het incident optreedt. Aan het begin van het kwartaal is de urgentie voor het wegnemen van de fout echter beperkt.
Prioriteitbepaling tracht de relatieve belangrijkheid van een probleem ten opzichte van andere problemen aan te geven. Het bepalen van de prioriteit heeft dus ook alleen zin wanneer er een verzameling problemen onder de loep genomen wordt. Het belang van een probleem wordt beïnvloed door de impact en urgentie van het probleem. Naarmate de gevolgen voor het Direct Gebruik en de urgentie tot herstel toenemen, wordt ook het relatieve belang groter.

5.2 Geven van directe ondersteuning

 
Ondersteuning:
Allereerst wordt getracht, op grond van de aanwezige kennis en informatie, aanwijzingen te geven waardoor het incident verholpen kan worden en de Informatievoorziening weer voortgang kan vinden.
 
Inroepen assistentie:
Indien noodzakelijk kan er assistentie ingeroepen worden van specialisten om het incident te verhelpen, of om te kunnen constateren dat er zich inderdaad een storing of fout voordoet. Hierbij zal ook getracht worden om een tijdelijke oplossing aan te dragen, waarmee het incident of probleem te verhelpen of te omzeilen is.

5.3 Opsporen en initiëren van het afhandelen van een probleem

 
Opsporen van problemen:
Door het analyseren van incidentenrapportages en statistische gegevens worden mogelijke problemen onderkend. Een mogelijk probleem wordt beschreven in een probleemrapport.
 
Een probleemrapport registreren:
Het probleem wordt registreerd voor verdere voortgangsbewaking.
 
Prioriteit toekennen:
Vervolgens wordt het probleem een prioriteit toegekend (zie ook paragraaf 3.4.1).

Toewijzingen:
Daarna wordt het probleem toegewezen aan een specialist, een team van specialisten of de leverancier, die voor verdere analyse van het probleem zorg draagt.
 
Herziening van de toewijzing:
Indien nodig vindt er een herziening plaats. Dit kan nodig zijn als blijkt dat het verkeerde specialisme ingeschakeld is.

5.4 Bewaken voortgang afhandeling incident, probleem of afwijking

 
Voortgangsbewaking:
Periodiek gaat Probleembeheer na of de voortgang van het probleem in overeenstemming is met de gestelde prioriteit. Zo nodig wordt bij degene die met de afhandeling van een incident, probleem of afwijking bezig is, aangedrongen op een versnelling van de afhandeling.

5.5 Preventief onderhoud

 
Escalatie:
In sommige gevallen zal Probleembeheer, aan de hand van de normen die afhankelijk zijn van de prioriteiten, het probleem moeten escaleren.

Afsluiten:
Tenslotte wordt met de aanmelder afgestemd of het incident of het probleem naar tevredenheid is  verholpen en opgelost. Zodra de aanmelder tevreden is met de oplossing van het incident of het probleem, kan het incident of het probleem worden afgesloten.

Analyse van rapportages:
Periodiek worden rapportages van incidenten en problemen geanalyseerd op trends en nog niet onderkende problemen. Naar aanleiding van de analyse kunnen acties opgestart worden. Deze acties kunnen bestaan uit het beschrijven van mogelijke handelingen die uitgevoerd kunnen worden als zich een bepaald incident of probleem voordoet of het formeel initiëren van een wijzigingsvoorstel voor preventief of correctief onderhoud.

Voorkomen van herhaling:
Zodra een probleem zich voordoet, dient nagegaan te worden of het zelfde probleem zich ook bij andere gelijkwaardige middelen van de Informatievoorziening kan voordoen. Correcties dienen dan ook op die middelen uitgevoerd te worden. Ook kan het nodig zijn om acties op te starten om te voorkomen dat een probleem zich ook op andere middelen gaat voordoen.

5.6 Organisatie rond de processen van probleembeheer

Organisatorisch zijn er vele oplossingen denkbaar om de processen van het Probleembeheer bij functionarissen (bijvoorbeeld de functioneel applicatiebeheerder) onder te brengen. Zo kunnen het aannemen van incidenten, problemen en afwijkingen en het bewaken van de voortgang ervan, ook belegd zijn bij een Helpdesk terwijl het functioneel applicatiebeheer de andere taken van Probleembeheer behartigt. Een dergelijke Helpdesk kan centraal binnen de organisatie geplaatst zijn, maar er kunnen ook bedrijfssituaties zijn waarbij er meerdere gespecialiseerde Helpdesks geïnstalleerd zijn.
Het afhandelen van problemen en afwijkingen en het pro-actief bezig zijn met problemen kunnen binnen de Gebruiksfunctie ook toegekend zijn aan een Probleemmanager of een Probleemmanagementteam. In het eerste geval kan het functioneel applicatiebeheer dan intermediair zijn tussen gebruikers en Probleemmanager. In het tweede geval kan een functioneel applicatiebeheerder deel uit maken van het Probleemmanagementteam.

6. Wijzigingsbeheer

Het Wijzigingsbeheer is verantwoordelijk voor het afhandelen van aangemelde wijzigingen aan de automatiseringsmiddelen op een zodanige wijze dat de dienstverlening aan de gebruiker daar zo weinig mogelijk hinder van ondervindt.
Het afhandelen van een wijziging houdt in: het laten autoriseren, het coördineren van de realisatie, het laten accepteren en het coördineren van de invoering van een wijziging.
Binnen de Bedrijfsvoeringsfunctie Gebruiken zijn met betrekking tot het Wijzigingsbeheer de volgende processen te onderkennen:

• aannemen, registreren en laten accorderen van een voorstel tot wijziging;
• laten uitvoeren van een impactanalyse en besluiten over een verzoek tot wijziging;
• in bedrijf nemen van een gerealiseerde wijziging.

6.1 Aannemen, registreren en accorderen wijzigingsvoorstel

 
Aanname en registratie:
Alle voorstellen tot wijziging worden door het Wijzigingsbeheer aangenomen en geregistreerd.
Daarbij wordt iedere wijziging direct gecategoriseerd naar de vorm van onderhoud (correctief, adaptief, perfectief of functioneel).
 
Accorderen van voorstellen tot wijziging:
Het Wijzigingsbeheer regelt dat het voorstel binnen de Bedrijfsvoeringsfunctie besproken wordt. Zodra Wijzigingsbeheer een akkoord heeft gekregen op het voorstel, wordt het verder als een concreet verzoek tot wijziging in behandeling genomen.

6.2 Laten uitvoeren van een impactanalyse

 
Uitvoeren van een impactanalyse:
Wijzigingsbeheer draagt er zorg voor dat er binnen de Onderhoudsfunctie een impactanalyse wordt uitgevoerd naar aanleiding van het verzoek tot wijziging. Het resultaat van de impactanalyse is een overzicht van de consequenties van de wijziging.

Beoordelen van een verzoek tot wijziging:
Wijzigingsbeheer regelt dat het verzoek tot wijziging, voorzien van de impactanalyse, door de daartoe bevoegde functionarissen beoordeeld wordt. Deze beoordeling kan resulteren in: het afwijzen, het uitstellen of het accorderen van het verzoek. Bij het accorderen kan aangegeven worden in welke release of onderhoudsronde de wijziging verwerkt wordt. Ook kunnen meerdere afwijkingen en/of wijzigingsvoorstellen tot één wijzigingsverzoek gecombineerd worden. Afhankelijk van de aard en impact van de wijziging en de configuratie-items waarop de wijziging betrekking heeft, kunnen ook andere functionarissen betrokken zijn bij deze beoordeling. Na de autorisatie wordt de wijziging door het Wijzigingsbeheer als een opdracht tot wijziging afgehandeld.

6.3 In bedrijf nemen van een gerealiseerde wijziging

 
Het laten accepteren:
Alvorens een wijziging in gebruik genomen kan worden, dient deze eerst door de betrokken instanties geaccepteerd te worden. De coördinatie van deze acceptatie is in handen van het Wijzigingsbeheer.

Het coördineren van de implementatie en in gebruik name van de wijziging:
Alle werkzaamheden die verband houden met de implementatie en in gebruik name worden door het Wijzigingsbeheer gecoördineerd. Deze werkzaamheden kunnen verband houden met de voorbereiding, invoering en afronding van de in-bedrijfname. Met betrekking tot de voorbereiding mag niet vergeten worden een ‘fallbackplan’ beschikbaar te hebben voor de situatie dat zich tijdens het invoeren problemen voordoen.

6.4 Organisatie rond de processen van het wijzigingsbeheer

Organisatorisch zijn er ook hier vele oplossingen denkbaar om de taken van het Wijzigingsbeheer bij functionarissen (bijvoorbeeld de functioneel applicatiebeheerder) onder te brengen. Zo kan het aannemen, registreren en laten accorderen van voorstellen tot wijziging belegd worden bij een functioneel applicatiebeheerder of bij een Helpdesk. Ook hier geldt dat een dergelijke Helpdesk centraal binnen de organisatie geplaatst kan zijn, maar er kunnen ook bedrijfssituaties voorkomen waarbij er meerdere gespecialiseerde Helpdesks geïnstalleerd zijn.
Ook komt het veelvuldig voor dat het zorgdragen voor de impactanalyse, het laten autoriseren en het invoeren van een wijziging toegekend is aan een Wijzigingsmanager of aan een Wijzigingsmanagementteam.

De coördinatie van het Wijzigingsbeheer wordt in vele gevallen uitgevoerd door een Wijzigingscommissie (Change Advisory Board). Een dergelijke commissie is vaak samengesteld uit vertegenwoordigers van de Gebruiks- Onderhouds- en Exploitatiefunctie. De Gebruiksfunctie wordt dan vertegenwoordigd door het functioneel applicatiebeheer. Deze commissie komt periodiek bijeen, afhankelijk van het aantal wijzigingsverzoeken, voor de besluitvorming over deze wijzigingsverzoeken. Dit wordt het zogenaamde wijzigingsoverleg genoemd. In de periodes tussen de periodieke bijeenkomsten wordt de dagelijkse coördinatie van het Wijzigingsbeheer uitgevoerd door de secretaris van de Wijzigingscommissie.
Een geschikte samenstelling van de wijzigingscommissie voor een grote informatievoorziening kan er als volgt uitzien:

• Namens de Gebruiksfunctie:
  • management van de Gebruiksfunctie (voorzitter);
  • secretaris (meestal de centrale functioneel beheerder); 
  • enkele decentrale functioneel beheerders, namens de belanghebbende gebruikers.
• Namens de Onderhoudsfunctie:
  • management van de Onderhoudsfunctie;
  • systeemleiders, als deskundigen.
• Namens de Exploitatiefunctie:
  • vertegenwoordiger van het Management van de Exploitatiefunctie;
  • een productieanalist.

De sleutelrollen van voorzitter en secretaris zijn toebedeeld aan de Gebruiksfunctie, als vertegenwoordigers van de eigenaar van de informatievoorziening.

7. Prestatiebeheer

Prestatiebeheer is verantwoordelijk voor het waarborgen en bewaken van de te leveren prestaties. Het Prestatiebeheer bestaat voor de Gebruiksfunctie uit de volgende onderdelen:

Evalueren van de prestatieafspraken:
Aan de hand van opmerkingen van gebruikers en tevredenheidsvragenlijsten kan beoordeeld worden in hoeverre de gebruikers tevreden zijn over de geboden prestaties. Afwijkingen op de geleverde prestaties dienen door de gebruikers als incident gemeld te worden, waardoor registratie en herstel geregeld kunnen worden.
 
Initiëren van aanpassingen van de prestaties:
Aan de hand van de beoordeling en op basis van informatie van gebruikers worden voorstellen geïnitieerd met betrekking tot afspraken of maatregelen inzake de te leveren prestaties.

8. Beveiligingsbeheer

Het beveiligingsbeheer is verantwoordelijk voor het waarborgen van de betrouwbaarheid van de Informatievoorziening. Een van de processen binnen het beveiligingsbeheer is het toegangsbeheer. Dit proces vindt zowel binnen de Gebruiksfunctie als binnen de Exploitatiefunctie plaats. Binnen de Gebruiksfunctie richt het toegangsbeheer zich op de toegang tot applicaties en gegevens. Binnen de Exploitatiefunctie is het toegangsbeheer gericht op de toegang tot netwerken, systemen en ruimtes. Met betrekking tot de Gebruiksfunctie bestaat het toegangsbeheer uit:

• het registreren van gebruikers;
• het aanpassen/resetten van wachtwoorden;
• het autoriseren van gebruikers;
• het afvoeren van gebruikers uit de registratie.

8.1 Het registreren van gebruikers

Aan de hand van geautoriseerde aanvragen worden gebruikers geregistreerd, voorzien van een gebruikersidentificatie en wordt, al dan niet automatisch, een wachtwoord toegekend.

8.2 Het aanpassen/resetten van wachtwoorden

Gebruikers die hun wachtwoord kwijt zijn worden voorzien van een nieuw wachtwoord.

8.3 Het autoriseren van gebruikers

Op basis van gestelde richtlijnen en aan de hand van geautoriseerde aanvragen worden geregistreerde gebruikers geautoriseerd tot toegang en/of gebruik van bepaalde applicaties en/of gegevens.

8.4 Het afvoeren van gebruikers uit de registratie

Op basis van gestelde richtlijnen en aan de hand van geautoriseerde aanvragen worden gebruikers uit de registratie verwijderd. Daarbij kan het noodzakelijk zijn het wachtwoord te resetten.
Tegenwoordig zijn de eisen, die gesteld moeten worden aan de beveiliging natuurlijk hoger. (Zie ook ‘ISO 27002 ‘lean en mean’ implementeren als security management systeem’.) Het is dus verbazingwekkend dat veel bedrijven juist deze basics niet op orde hebben en dat het aantal accounts vaak veel te ruim is genomen of accounts onterecht zijn.

9. Operations beheer

Voor het optimaliseren van de te verrichten gebruiks- en verwerkingshandelingen en de correcte afhandeling van incidentele verzoeken (de serviceverzoeken) is het Operationsbeheer verantwoordelijk.
Vanuit de Gebruiksfunctie is de aandacht hier gericht op het optimaliseren van de gebruikshandelingen.
De Gebruiksfunctie onderscheidt binnen het Operationsbeheer de optimalisatie van te verrichten handelingen als een proces. Dit proces bestaat uit:

• beoordelen van gebruikshandleidingen;
• evalueren van de werkwijze bij Direct Gebruik;
• Initiëren van verbeteringen.

9.1 Beoordelen van gebruikshandleidingen

Nieuwe en gewijzigde handleidingen worden beoordeeld op de aansluiting met de werkwijze en op kennis en ervaring van de personen die de handelingen uitvoeren.

9.2 Evalueren van de werkwijze bij direct gebruik

Periodiek worden de werkwijze en het gebruik van de handleidingen geëvalueerd.

9.3 Initiëren van verbeteringen

Aan de hand van de bevindingen, welke resulteren uit de beoordeling en evaluatie, worden voorstellen voor wijziging geïnitieerd.

10. Slotopmerking

In dit artikel wordt een theoretisch kader geschetst, dat bedoeld is om bij te dragen aan de beeldvorming en om u in staat te stellen om eventuele knelpunten in uw organisatie op te sporen. Volledige implementatie van dit gedachtegoed zal echter meestal leiden tot een permanente stiptheidsactie. Resultaatgerichte acties om een probleem te tackelen leveren vaak sneller en goedkoper verbeteringen op. Dat laat echter onverlet, dat men zich bewust moet zijn van deze theorie om te voorkomen dat ‘kort door de bocht’ leidt tot het nemen van de verkeerde afslag.
Voorbeelden van een gerichte aanpak vindt u onder andere in:

• Casestudy Training functioneel beheer website
• Casestudy Training Outsourcing werkplekbeheer

De training hierbij is geen doel, maar startpunt voor de verandering, waarbij u zelf de regie houdt.

Download: