1. De droom van de functioneel beheerder
2. BiSL in de praktijk
3. Inrichting operationeel niveau volgens BiSL
4. BiSL begrippenkader is bruikbaar

1. De droom van de functioneel beheerder

Op papier lijkt het zo gemakkelijk en aantrekkelijk: functioneel beheer als middelpunt van het heelal, ingericht volgens BiSL, zodat zowel gebruikers als ICT’ers zich kunnen laven aan alle zegeningen van de ICT, onder de bezielende regie van de functioneel beheerder. Deze droom verandert echter dikwijls in een nachtmerrie. De ICT’ers hebben hun processen al ingericht volgens ITIL en dat sluit allerminst aan op BiSL. Het met elkaar in balans brengen van de methoden krijgt vaak geen prioriteit en het geld ervoor ontbreekt meestal ook; BiSL wordt er maar wat tussen gefrommeld en dan alleen nog op operationeel niveau. (Zie ook ‘Integratie ITIL, ASL en BiSL is noodzaak of niet doen deel 1′.) De baan van functioneel beheerder blijkt dan een hondenbaan te zijn, een baan zonder instrumenten en bevoegdheden om bij te sturen. De functioneel beheerder is als een leeuwentemmer zonder zweep; hij moet de leeuwen vriendelijk vragen om netjes hun kunstjes te doen. Als dan blijkt, dat de leeuwen in het verleden een grote aversie tegen elkaar hebben opgebouwd, dan wordt zijn hoofdtaak al gauw het uit elkaar houden van de vechtende partijen door vanaf twee kanten de klappen op te vangen. En daar de functioneel beheerders in de meeste organisaties toegewezen zijn aan afdelingen waar ze eigenlijk niet thuishoren, is escalatie van de problematiek ook zinloos; het management heeft tenslotte wel meer aan het hoofd. (Zie ook ‘Afbakening taken functioneel beheer baseren op behoefte’.)  

2. BiSL in de praktijk

De naam functioneel beheer blijkt in de praktijk vaak voor verwarring te zorgen. Functioneel beheer zou de rol van bestuurder van de informatievoorziening moeten vervullen, de functie die bepaalt hoe de informatievoorziening in een organisatie eruit ziet en eruit komt te zien.
Vaak echter wordt deze regie-rol niet door de gebruikers overgedragen. Zij willen zelf de touwtjes in handen houden. Macht wordt hoger gewaardeerd dan deskundigheid. De term functioneel beheer wordt dan alleen nog geassocieerd met met name de uitvoerende activiteiten in het werkgebied, terwijl de term informatiemanagement voornamelijk wordt gebruikt als het gaat om de richtinggevende activiteiten die belegd zijn bij de business.
Wanneer we het werkterrein van functioneel beheer onderbrengen in het traditionele negenvlaksmodel als referentiekader op het gebied van business-ICT alignment, dan is functioneel beheer dus te positioneren als het onderste vlak in de middelste kolom:  

Figuur 1: Negenvlaksmodel

 Een aantal wellicht bekende deelgebieden of activiteiten die de interactie van dit vlak met de uitvoerende vlakken van de business-en ICT-kolom beschrijven, zijn:  

• Requirements- of specificatiemanagement (van business naar communicatie/informatie: het goed en leesbaar specificeren van gewenste functionele aanpassingen);
• Changemanagement of wijzigingenbeheer (van communicatie/ informatie naar ICT: het gestructureerd aanbrengen van wijzigingen in het informatiesysteem);
• Releasemanagement (van ICT naar communicatie/informatie: het gestructureerd opleveren van aanpassingen aan het informatiesysteem);
• Transitie- of implementatiemanagement (van communicatie/ informatie naar business: het goed en tijdig doorvoeren van gewijzigde informatievoorziening en bijbehorende documentatie).

Het lijkt heel logisch, maar het is niet meer van deze tijd. Er zijn tenslotte maar weinig bedrijven voor wie ICT een core competence is van strategisch belang. ICT is meestal niet meer dan een duur bedrijfsmiddel, waarbij de effectiviteit van de ICT zelf niet van belang is, maar slechts de effectiviteit van de bedrijfsprocessen die al dan niet ICT gebruiken. Er is nauwelijks  sprake van adequaat aansturen. Het gaat om zorgvuldig en slim inkopen (Zie ook ‘Functioneel beheer en inkoop vaak bottlenecks in de ICT-leveringsketens’.) En dat is zeker geen specialiteit van de business. Juist BiSL onderkent ook deze processen. Daarom toch weer terug naar BiSL.  

3. Inrichting operationeel niveau volgens BiSL

Als voor het uitvoerende niveau het BiSL-model als referentiekader wordt gebruikt voor het functioneel beheer (zie ook ‘Begrippen en structuur van BiSL’), dan houden we in feite het volgende model over:  

Figuur 2: Functioneel Beheer

De concrete taken die onder het aandachtsgebied van het uitvoerende functioneel beheer vallen, zijn grofweg onder te verdelen in:  

• taken op het gebied van gebruiksbeheer;
• taken met betrekking tot functionaliteitenbeheer en
• taken in de verbinding tussen deze twee domeinen.

3.1 Taken cluster gebruiksbeheer

De taken die worden uitgevoerd binnen het cluster gebruiksbeheer moeten ertoe leiden dat de informatievoorziening goed gebruikt wordt. Hier worden dus de processen beschreven, die er voor zorgen dat er een continue en optimale ondersteuning plaatsvindt bij het dagelijks gebruik van de informatievoorziening door de eindgebruikers met de volgende processen:  

• Gebruiksondersteuning heeft als doel het ondersteunen, faciliteren en bijsturen van de gebruikers bij het gebruik van de informatievoorziening in de dagelijkse praktijk, zodat de gebruikers optimaal kunnen werken met de bestaande informatievoorziening.
• Beheer bedrijfsinformatie richt zich op een correcte opzet en inhoud van de gegevens in de informatievoorziening. Het gaat daarbij onder andere om het beheer van centrale tabellen, bewaking op een juiste hantering van het bedrijfsinformatiemodel, het treffen van maatregelen om de gegevenskwaliteit te garanderen en het verstrekken van ad hoc gegevens en managementinformatie.
• Operationele ICT-aansturing vormt de operationele aansturing van de ICT-leverancier. Op basis van eisen vanuit de bedrijfsprocessen op de aspecten beschikbaarheid, capaciteit en continuïteit worden opdrachten verstrekt en wordt de dienstverlening van de ICT-leverancier bewaakt.

3.2 Taken in cluster functionaliteitenbeheer

De activiteiten die onder functionaliteitenbeheer vallen, houden zich bezig met het continue verbeterproces met betrekking tot de vormgeving en de inrichting van de informatievoorziening. Er kunnen talloze redenen zijn die leiden tot een verandering in de informatievoorziening: het bedrijfsproces verandert, de ondersteuning van de bedrijfsprocessen kan beter, enzovoort. In dat kader zijn binnen functionaliteitenbeheer de volgende processen gedefinieerd:  

• Specificeren heeft als doel het vertalen van de gewenste veranderingen in functionaliteit, naar inhoudelijke en niet-inhoudelijke oplossingsrichtingen en het vastleggen hiervan ten behoeve van verdere realisatie van de geautomatiseerde informatievoorziening.
• Vormgeven van niet-geautomatiseerde informatievoorziening is gericht op het opzetten en onderhouden van de relevante documentatie voor het gebruik en het functioneel beheer van het informatiesysteem (procedures, werkinstructies, handleidingen, en dergelijke).
• Toetsen en testen heeft als doel ervoor te zorgen dat de gewenste verandering vlekkeloos in de organisatie wordt doorgevoerd en dat de gebruikte instrumenten, hulpmiddelen en andere ondersteuningsvormen correct zijn en correct werken.
• Voorbereiden transitie moet zorgen voor een probleemloze ingebruikname van de nieuwe en/of gewijzigde functionaliteit door alle benodigde randvoorwaarden zodanig in te vullen, dat de gewenste verandering hierna probleemloos geëffectueerd kan worden.

3.3 Taken in de verbinding tussen gebruiks-en functionaliteitenbeheer

Tussen de aandachtsgebieden gebruiksbeheer en functionaliteitenbeheer bevinden zich activiteiten die zich bezig houden met enerzijds het onderkennen van welke veranderingen noodzakelijk zijn (Wijzigingenbeheer) en anderzijds het feitelijke doorvoeren in de organisatie van de veranderde informatievoorziening (Transitie). Hoe de informatievoorziening wordt veranderd, ligt binnen functionaliteitenbeheer, en wat er verandert en de feitelijke doorvoering van de verandering in de gebruikersorganisatie liggen binnen deze verbindende activiteiten:  

• Wijzigingenbeheer heeft tot doel te komen tot de juiste besluiten over het aanbrengen van wijzigingen of vernieuwingen in de informatievoorziening. Hiertoe bevat wijzigingenbeheer een mechanisme voor het inventariseren, evalueren, prioriteren en ten uitvoer brengen van wijzigingen in de informatievoorziening.
• Transitie is gericht op de effectuering van de verandering voor de eindgebruikers, die is voorbereid in de processen van functionaliteitenbeheer en de achterliggende activiteiten van de ICT-leverancier. Transitie vormt het regiemechanisme op het in gebruik nemen van aangebrachte wijzigingen of vernieuwingen.

De valkuil van BiSL is dus, dat de inkoop als tactisch proces toch bij de business komt te liggen en niet bij het functioneel beheer. Dit leidt meestal tot ellenlange waslijsten van eisen en wensen van de gebruikers, waarvan een beetje functioneel beheerder sowieso 90% kan schrappen, omdat die 90% ofwel geen toegevoegde waarde heeft ofwel door iedere leverancier geleverd kan worden. Het gaat tenslotte om de knock-out criteria. (Zie ter illustratie hiervan bijvoorbeeld ook de artikelen ‘Selectie leverancier voor outsourcing werkplekbeheer’ of ‘ERP selectie en implementatie: eerst van een muis een olifant maken en daarna omgekeerd’.)
Het horror-scenario voor de functioneel beheerders is, dat zij worden opgescheept met de implementatie van ICT-middelen waarvan ze al bij voorbaat weten, dat ze niet passen bij de behoefte van de organisatie. En natuurlijk krijgen zij de schuld van de mislukte implementatie.  

4. BiSL begrippenkader is bruikbaar

Net als ITIL geldt echter ook voor BiSL, dat het begrippenkader goed bruikbaar is, ook voor middelgrote en kleinere organisaties, mits ook de tactische processen, zoals bijvoorbeeld de inkoop, belegd worden bij het functioneel beheer. (Zie ook ‘BiSL maakt functioneel beheer wel erg ingewikkeld’.) Implementatie van allerlei procedures van BiSL is echter niet aan te raden. Net als ITIL gaat BiSL uit van een vrijwel oneindige beschikbaarheid van resources en het zijn slechts de grote informatieverwerkende industrieën, die daarvoor voldoende ruim in hun resources zitten. Gelukkig is implementatie van al die procedures voor kleinere organisaties ook niet nodig. Zij hebben behoefte aan het met een minimale capaciteit beheren van de ICT-infrastructuur en dus aan zoveel mogelijk gestandaardiseerde hard- en software. Functioneel beheer is dan primair een logistiek probleem ofwel functioneel beheer draagt er zorg voor dat de juiste informatie op het goede moment op de goede plaats met minimale inspanningen tegen acceptabele kosten in de goede vorm beschikbaar is. (Zie ook ‘ICT en functioneel beheer steeds meer logistieke processen’.) En ondanks alle tekst die rondom BiSL is verzameld, is dit in grond van de zaak wel de essentie van BiSL. Maar dat zal natuurlijk geen consultant u vertellen. (Zie ook ‘ICT-productleveranciers en detacheerders verliezen concurrentieslag met ICT-dienstverleners’.) 

Herziene versie: 10 maart 2010

Download:         

Gerelateerde artikelen:

1. BiSL maakt functioneel beheer wel erg ingewikkeld
2. Afbakening taken functioneel beheer baseren op behoefte
3. Functioneel beheer en inkoop vaak bottlenecks in de ICT-leveringsketens

1. De taak van de functioneel beheerder
2. BiSL: de methode doet het niet
3. Het herdefiniëren van functioneel beheer
4. Bezoekt u ook wel eens een ICT-vakbeurs?
5. Hoezo standaardisatie?

1. De taak van de functioneel beheerder

De functioneel beheerder heeft als belangrijkste taken:

• de gebruikers van applicaties ondersteunen bij het specificeren van hun behoefte en het accepteren van de geleverde software;
• zorg dragen voor een juiste informatievoorziening naar de organisatie.

Het klinkt zo simpel. Toch is juist deze taakinvulling in veel organisaties de oorzaak van verhitte discussies. Functioneel beheerders vormen in de praktijk vaak de buffer tussen de gebruikers en de ICT’ers, die hun stinkende best doen om elkaar vooral niet te begrijpen.

Vanuit de business klaagt men:

• ‘Ik vraag aan onze ICT’ers: “Maak dit voor mij” en ik krijg niet opgeleverd waar ik eigenlijk naar op zoek was.’
• ‘Als ik een voorstel doe voor extra functionaliteit lijkt dit altijd ondergeschikt te zijn aan het oplossen van de dagelijkse problemen, waardoor er niets verandert.’
• ‘De ICT-medewerkers praten te veel in technische termen in plaats van in (business)functionaliteit en bijbehorende ICT-ondersteuning.’

Vanuit de ICT-organisatie wordt verzucht:

• ‘Ik hoor alleen een paar kreten en de gebruikers verwachten dat ik daarmee een complete en goed functionerende applicatie kan bouwen.’ 
• ‘Het lijkt wel of de ICT-afdeling is opgezet om op inhoudelijk niveau ondersteuning te leveren aan de gebruikers. Volgens mij begrijpen ze hun eigen bedrijfsprocessen niet.’
• ‘De gebruikersorganisatie is onvoldoende professioneel ingericht, zeker in relatie tot ons eigen professionaliteitsniveau.’

De arme functioneel beheerder moet begrip hebben voor beide standpunten en moet ervoor zorgen dat beide partijen toch tot een oplossing komen. Zolang dit niet het geval is, krijgt de functioneel beheerder uiteraard de schuld van de mis-communicatie.

2. BiSL: de methode doet het niet

Theoretici trekken nu waarschijnlijk onmiddellijk een aantal boeken uit de kast over beheermethodieken, met imponerende titels als BiSL of ITIL. Reeds begin jaren tachtig schreef Jaap van Rees het artikel ‘De methode doet het niet’. Het artikel gaat over het gebruik van methoden. De conclusie die wordt getrokken is dat het niet de methode is die het wel of niet doet, het is de persoon die de methode gebruikt, die het wel of niet doet. (Zie ook ‘Valkuilen functioneel beheer volgens BiSL’.)
Nu, bijna 30 jaar later, is er nog weinig veranderd. Iedere methodiek (zelfs de slechtste) werkt, als de gebruikers van deze methodiek deze willen laten werken. En omgekeerd faalt zelfs de beste methodiek, als niet alle partijen willen, dat deze gaat werken.
Het simpele statement dat BiSL of ITIL gebaseerd zijn op een hoop ‘best practices’, is niet het argument waarmee ik me zou laten overtuigen om de methodiek in de armen te sluiten. (Zie ook ‘Begrafenis ITIL is begin van herstel ICT-imago’.) Het gaat immers al lang niet meer over het vraagstuk van gelijk hebben. De ICT heeft zich door de hautaine houding van met name grote leveranciers dusdanig in diskrediet gebracht, dat buitenstaanders er al op voorhand van overtuigd zijn, dat communicatie met ICT’ers zinloos is. En als functioneel beheerders niet uitkijken en het standpunt van ICT’ers verdedigen, dan worden ze vaak gemakshalve maar op één hoop gegooid met deze ICT’ers.

3. Het herdefiniëren van functioneel beheer

In veel gevallen is de conclusie duidelijk: het stapsgewijs verbeteren van de communicatie leidt niet tot een oplossing. Ook hier is van toepassing het motto: ‘Eerst de goede dingen doen en pas dan de dingen goed doen’.
Het is goed los te komen van de ‘hoe’-vraag van de taken en u te richten op de ‘wat’-vraag. Het kernissue is:

• De business wil applicaties opgeleverd krijgen, die beantwoorden aan de gestelde eisen en wensen.
• De ICT-afdeling wil graag een complete en goed functionerende applicatie bouwen en onderhouden.

Juist in deze probleemstelling wordt het dubbele misverstand duidelijk. De business wil nog steeds naar de kleermaker om zich een pak te laten aanmeten en weigert naar een kledingzaak te gaan. De business wil nog steeds een Rolls Royce, terwijl de autoboulevard om de hoek is. Maar diezelfde business is ontevreden, omdat het maatwerk nog kinderziekten heeft en duur is. Als ICT geen core business is, dan zullen de meeste confectieoplossingen echter uitstekend voldoen.
De ICT’ers willen nog steeds graag bouwen. Maar daarvoor zitten ze op de verkeerde plek. Ze moeten daarvoor naar een organisatie gaan, die nog behoort tot de informatieverwerkende industrieën, naar een organisatie waar investeringen in de verbetering van de software daadwerkelijk terugverdiend kunnen worden.
En daar zit de functioneel beheerder tussenin. Zowel voor wat de business wil, als voor wat de ICT wil, geldt, dat het in elk geval niet in het bedrijfsbelang is. Kortom, het wordt tijd dat de functioneel beheerders eens komen uit hun ‘hoekje waar de klappen vallen’ Ze zijn niet een naar twee kanten service verlenende instantie. Ze zijn de partij die vraag en aanbod bij elkaar brengt. Functioneel beheerders moeten ervoor zorgen, dat met standaard ICT-oplossingen voor de gebruiker informatie

• op het juiste moment,
• in de goede vorm,
• op de juiste plaats,
• in de goede hoeveelheid,
• tegen acceptabele kosten
• beschikbaar is.

Het is dus niet zo zeer sprake van een technisch probleem of een beheerprobleem, maar primair van een logistiek probleem, van een kwestie van slim inkopen. (Zie ook ‘ICT en functioneel beheer steeds meer logistieke processen’.)

4. Bezoekt u ook wel eens een ICT-vakbeurs?

Ongetwijfeld heeft ook u wel eens een ICT-vakbeurs bezocht. Vanochtend zat er nog een uitnodiging in mijn e-mail box voor het bezoeken van de beurs ‘Zorg en ICT’. Een snelle blik leerde mij, dat er 150 bedrijven als standhouder aanwezig zullen zijn.

Figuur 1: De ICT-vakbeurs

Er kwamen onmiddellijk beelden bij mij boven van eerdere bezoeken aan een dergelijke beurs en gedachten die ik toen had. Ik wil ze u niet onthouden.
Verloren kwam ik binnen in de immense jaarbeurshallen, waar vele aanbieders met holle kreten mijn aandacht probeerden te vangen voor producten, waarvan ik meestal eigenlijk geen flauw idee had, dat ik ze mogelijk nodig zou kunnen hebben. Waarschijnlijk was dat toch wel het geval. Anders zouden toch niet al die aanwezige leveranciers er duizenden euro’s tegenaan gegooid hebben om zich hier te kunnen presenteren aan de  bezoekers?
Een beetje verlegen bespiedde ik van een afstandje de eerste stand en probeerde ik de uitbundige affiches te begrijpen. Tevergeefs. Bij de volgende stands herhaalde zich dit. Gelijk weer weggaan, wilde ik niet. Daarvoor had ik mijn treinreis niet gemaakt. Daarom sprak ik in een rustige stand maar een verveeld kijkende verkoper aan en legde hem mijn probleem voor. Toen ik aangaf dat ik functioneel beheerder was, kreeg de verkoper een wat glazige blik in zijn ogen en begon hij me te vertellen wat voor schitterende oplossing ik wel kon kopen in zijn stand. Het had iets te maken met beveiliging. Dat, terwijl ik altijd heb gedacht, dat beveiliging niets anders is dan een vanzelfsprekende producteigenschap. Dit toneelstukje herhaalde zich nog een aantal malen bij andere stands. Ik besloot daarop maar om niets meer te vragen en slechts in allerlei stands folders te ruilen tegen mijn visitekaartje.
De verkopers gelukkig. Ik iets minder gelukkig, want ik was toch van plan om de verzamelde buit nog eens verder te bekijken. Wel bedacht ik op de terugweg in de trein, dat deze beurs nog veel van een supermarkt zou kunnen leren. Daar staan de schappen vol met producten die ik tenminste kan begrijpen. En als ik toch zo slim niet ben, dan is er vaak nog wel een vakkenvuller die me in Jip-en-Janneke-taal wijzer kan maken.

5. Hoezo standaardisatie?

Ongetwijfeld zullen alle producten die ik heb gezien op de beurs, voldoen aan de standaards van de leverancier. Ik ben echter niet geïnteresseerd in puzzelstukjes die elk aan hun eigen standaard voldoen. Ik wil de complete puzzel hebben en dat de puzzelstukjes moeten passen, beschouw ik niet als mijn probleem, maar als het probleem van de leverancier.
Kortom, ik wil een proactieve dienstverlener, die de verantwoordelijkheid neemt voor het passen van de puzzelstukjes. Niet eentje die eerst mijn werk gaat doen en de behoeften van de gebruikers inventariseert en dan met een waslijst van eisen en wensen komt. Nee, ik wil een proactieve dienstverlener die mij een aantal geïntegreerde oplossingen voorlegt, waaruit ik kan kiezen.
Het gaat me tenslotte niet om de computer, de software, de printer, het netwerk of de kabels. Ik moet ervoor zorgen dat de gebruikers een ICT-infrastructuur krijgen, waarmee zij kunnen voorzien in hun informatiebehoefte. Mijn auto hoef ik toch ook niet zelf in elkaar te schroeven en mijn elektriciteit hoef ik ook niet zelf op te wekken. Ik wil als functioneel beheerder namens de gebruikers als opdrachtgever kunnen optreden naar een hoofdaannemer, die er uiteraard zelf voor moet zorgen, dat zijn onderaannemers datgene leveren wat ik nodig heb. (Zie ook ‘Functioneel beheer en inkoop vaak bottlenecks in de ICT-leveringsketens’.) En of de geleerden dit nu insourcen of outsourcen noemen, vind ik niet spannend. Wel weet ik, dat ik als functioneel beheerder namens de gebruikers de behoeftesteller ben. Dus moet ik weten welke eisen ik moet stellen aan zo’n proactieve dienstverlener. Hij is mijn ’single point of contact’. Dat is belangrijker dan de eisen en wensen die ik wil stellen aan de producten. Want aan die dienstverlener zit ik jaren vast, terwijl ik de eisen aan het product kan bijstellen. Daar is tenslotte die wijzigingsprocedure voor. (Zie ook ‘Selectie leverancier voor outsourcing werkplekbeheer’.)

Download:         

Gerelateerde artikelen:

1. BiSL maakt functioneel beheer wel erg ingewikkeld
2. Service Level Management en Service Management functioneel beheer
3. ICT en functioneel beheer steeds meer logistieke processen

1. Meer aandacht voor functioneel beheer
2. Oplossingen die niet werken
3. Functioneel beheer is wel de oplossing
4. Houdt functioneel beheer simpel

1. Meer aandacht voor functioneel beheer

De aandacht voor functioneel beheer groeit in veel organisaties aanzienlijk, en terecht. Voor consultants een belangrijke reden om een volledige methodiek met alles erop en eraan te verzinnen, zodat zij in elk geval kunnen inspelen op (of was het meeprofiteren van?) de behoefte van organisaties. En dus zag als snel BiSL het licht. Met verbijstering vragen veel functioneel beheerders zich nu af, hoe zij in het verleden ooit hun taak hebben kunnen vervullen. Maar in feite is er niets nieuws onder de zon. In dit artikel willen we weer teruggaan naar de essentie van functioneel beheer. Ook nu is daar nog steeds geen ingewikkelde methodiek voor nodig.
Twintig jaar geleden hanteerden we al modellen van de ontwikkeling van de business alignment van ICT met een drietal fasen, te weten het creëren van:   

1. Technisch hoogwaardige ICT-oplossingen;
2. ICT oplossingen die gebruikers vragen;
3. ICT oplossingen die gebruikers nodig hebben.

1.1 Fase 1: Technisch

Onderstaand plaatje geeft fase1 weer, de fase waarin technisch hoogwaardige ICT-oplossingen worden gecreëerd:   

Figuur1: Technisch hoogwaardige ICT-oplossingen

Er staat tussen de gebruikers en de automatiseerders prominent een muur. Over die muur gooien de gebruikers eisen, wensen en problemen, waarna de automatiseerders gaan nadenken en een technisch perfecte oplossing proberen te maken. Helaas moeten vervolgens de gebruikers verzuchten: ‘Het is misschien wel een schitterende oplossing, maar helaas niet voor ons probleem’.
Uiteraard vond het management dit niet acceptabel. Het verordonneerde, dat de zeggenschap bij de gebruikers kwam te liggen. Dan zouden deze misverstanden niet meer kunnen optreden. Kortom, de organisatie migreerde naar fase 2.   

1.2 Fase 2: ICT-oplossingen die gebruikers vragen

Ook fase 2, de fase waarin ICT-oplossingen werden gecreëerd die gebruikers vragen, kunnen we weer in een plaatje weergeven:   

Figuur2: ICT-oplossingen die gebruikers vragen

De gebruikers denken na, verzinnen een schitterende oplossing en gooien vervolgens hun ideeën over de muur. De automatiseerders worden in de rol van ober gedwongen en serveren dat wat de klant wil. Dat het technisch niet meer kan kloppen, dat kan de gebruikers moeilijk worden verweten. De meest draconische systemen zagen het licht en de onderhoudsinspanningen namen exponentieel toe, om er maar voor te zorgen, dat de gecreëerde wangedrochten bleven werken. Kortom, het was volstrekt helder, dat dit ook niet de oplossing was. Het echte probleem was natuurlijk de muur. Tijd voor fase 3.   

Fase 3: ICT-oplossingen die gebruikers nodig hebben

Fase 3 kunnen we als volgt in een plaatje weergeven:   

Figuur3: ICT-oplossingen die gebruikers nodig hebben

De muur is afgebroken. De gebruikers communiceren met de automatiseerders om samen tot een oplossing te komen, die voor de business functioneel ideaal is en technisch gezien perfect. Helaas wordt dit ideaalbeeld zelden bereikt. Ook nu is er nog vaak niet sprake van een goede communicatie tussen beide partijen. Dit wordt meestal veroorzaakt door allerlei waanideeën, waardoor een echte samenwerking, zeker bij de planvorming, wordt verstoord.   

2. Oplossingen die niet werken

2.1 Door aanbesteden blijft de muur bestaan

Tegenwoordig is de trend, dat ICT-werkzaamheden moeten worden aanbesteed. In feite gaan we daarmee terug naar fase 2, de fase waarin oplossingen gemaakt worden, die gebruikers vragen en geen oplossingen die gebruikers nodig hebben. Dat is de belangrijkste reden, dat zoveel overheidsprojecten ook nu nog de mist in gaan (minder functionaliteit, hogere kosten dan was afgesproken en uitloop). (Zie ook ‘Europees aanbesteden leidt vaak tot minder marktwerking en hogere prijzen’.) Het is dus geen kwestie van onkunde van één van beide partijen. Het is een kwestie van een afgesproken oplossing, waarvan tijdens het project vaak duidelijk wordt, dat die een functioneel of technisch wangedrocht is.   

2.2 Een SLA is niet zaligmakend

Om een goede samenwerking mogelijk te maken, moeten er natuurlijk overeenkomsten gesloten worden tussen klanten en leveranciers. Maar wanneer u denkt, dat in een SLA staat wat u precies voor elkaar moet doen, gaat het goed fout. Want dat is de functie van een SLA helemaal niet. Als u een meerjarenovereenkomst sluit, dan mag u ervan uitgaan, dat de samenwerking steeds beter gaat verlopen en dat er een verbetercyclus ontstaat. De SLA regelt deze samenwerking en niet de prestatie. Het is een vangnet voor als er een situatie ontstaat, waarin u er in overleg niet meer uitkomt. (Zie ook ‘ICT-service management: contact is belangrijker dan contract’.) Het letterlijk nemen van een SLA betekent terugvallen naar fase 2 of zelfs naar fase 1. Dat wilt u uiteraard niet.   

2.3 Gebruik van standaardpakketten

Tegenwoordig worden binnen organisaties steeds meer pakketten geïmplementeerd. Oppervlakkig gezien lijkt dit een goed idee. In de praktijk leidt het echter tot allerlei ongewenste bijwerkingen:   

• Leveranciers creëren een lock-in voor hun diensten, zodat een steeds grotere afhankelijkheid ontstaat van één of enkele ICT-leveranciers.
• Marktleiders houden zich nauwelijks aan gedefinieerde open standaards. Hierdoor houden ze de lock-in in stand. (Zie ook ‘Bedrijfstype, en niet functionaliteit, bepalend bij ERP-selectie’.)
• Open Source Software is vaak nog onvoldoende professioneel om een serieus alternatief te vormen. Maar moeten we blij zijn met Google als de opvolger voor Microsoft en SAP?

Daarnaast worden pakketselecties vaak op een verkeerde manier uitgevoerd. Een ieder wordt gevraagd of hij nog aanvullende eisen en/of wensen heeft. Op grond daarvan wordt een waslijst opgesteld voor de Request for Proposal (RfP). De winnaar is dan vanzelfsprekend het pakket met de meeste functionaliteit. Dat is echter vaak niet het pakket dat een organisatie echt nodig heeft. (Zie ook ‘ERP-selectie en -implementatie: eerst van een muis een olifant maken en daarna omgekeerd’.) Het gaat dus om goed demand management. Met de in dit hoofdstuk genoemde maatregelen wordt dat niet afgedekt.   

3. Functioneel beheer is wel de oplossing

Als een organisatie op een effectieve wijze wil samenwerken met haar ICT-leveranciers, dan is het dus nodig, dat de muur gesloopt wordt en blijft. Dat betekent dat er mensen beschikbaar moeten zijn, die zowel de bedrijfsprocessen als de ICT begrijpen. Vaak zijn dit de functioneel beheerders. Zij vormen de ‘gaten’ in de muur, waardoor communicatie mogelijk is. Met een gat wordt niet een veredeld doorgeefluik bedoeld. De functioneel beheerders moeten naar beide kanten het demand management kunnen invullen en naar beide kanten namens de andere partij kunnen onderhandelen. In feite zijn de functioneel beheerders de vleesgeworden SLA tussen de business en de ICT.
BiSL identificeert in deze zin grotendeels de processen die van belang zijn voor deze rol van functioneel beheer. De uitwerking van die processen maakt BiSL echter wel heel ingewikkeld.
De basis van functioneel beheer vormen de onderlinge afspraken voor samenwerking, waarbij beide partijen erop kunnen rekenen, dat deze nagekomen worden. Dit wordt op tactisch niveau beschreven. Deze stabiele toestand kan op twee manieren worden verstoord, namelijk door:   

• een incident, waardoor één van beide partijen afspraken niet nakomt.
  Dit incident moet verholpen worden, waarbij het uitgangspunt moet zijn:’de vervuiler betaalt’. Deze incidentafhandeling wordt door BiSL marginaal besproken.
• een wijzigingsvoorstel ingediend door één van de partijen,
  dat wil zeggen één van de partijen wil een aanpassing van de afspraken.
  De impact van de wijziging moet worden bepaald en na goedkeuring door beide partijen worden afspraken aangepast en wordt de wijziging gerealiseerd en geaccepteerd. In feite gaat het hele operationele beheer van BiSL (wijzigingenbeheer) inclusief alle subprocessen over dit issue.

Een uitvloeisel van het wijzigingenbeheer is de inkoopfunctie die het functioneel beheer moet invullen. Dit niet in de betekenis van inkoper (afsluiten van transacties). Het functioneel beheer moet de behoefte specificeren en vervolgens regelen, dat er ingekocht wordt, ongeveer zoals de afdeling P&O verantwoordelijk is voor het aantrekken, het begeleiden en het evalueren van het functioneren van medewerkers. De harde kant van het inkopen ligt vaak bij de ICT-afdeling of eventueel bij een externe partij. (Zie ook ‘Functioneel beheer en inkoop vaak bottlenecks in de ICT-leveringsketens’.)
Tenslotte moet de dienstverlening (wederzijds) geëvalueerd worden. In feite gaat het hier om de interne control functie, waarin bekeken wordt of de procesafspraken ook inderdaad nageleefd zijn. Binnen ITIL vinden we deze functie grotendeels binnen het proces problem management. Maar ook aan de kant van het functioneel beheer zou dit proces ingericht moeten zijn, waarbij functioneel beheer niet als uitvoerder maar als bewaker van de ICT-dienstverlening en alles wat hier mee samenhangt rapporteert aan het gebruikersmanagement, dat uiteraard eindverantwoordelijke blijft.   

4. Houdt functioneel beheer simpel

De hoofdtaak van functioneel beheer is het in stand houden van de alignment tussen de business en ICT, niet als inkoper, jurist, techneut of controleur, maar vooral als procesbegeleider van de samenwerking en het onderlinge begrip. De functioneel beheerders voorkomen dagelijks, dat de muur tussen gebruikers en ICT weer opgeworpen wordt. Functioneel beheer is niet de buffer tussen twee strijdende partijen, maar zorgt ervoor, dat beide partijen hun gezonde verstand blijven gebruiken. (Zie ook ‘Valkuilen functioneel beheer volgens BiSL’.) Miscommunicatie mag niet leiden tot regeldrift, juridisch geneuzel en toezichthouders. ICT-dienstverlening is mensenwerk en dit kan alleen verbeteren door tweezijdig processen beter op elkaar af te stemmen. Hiervoor zijn eenzijdige methodes als BiSL of ITIL meestal niet de oplossing. (Zie ook ‘Integratie ITIL, ASL en BiSL is noodzaak of niet doen deel 1′.) Vaak is het voldoende om een duidelijk communicatiemodel te hebben voor de koppelvlakken, zoals in het artikel ‘Blauwdruk processen IT-organisatie’ wordt uitgelegd aan de hand van het volgende plaatje:   

Figuur4: Communicatiemodel voor de koppelvlakken

 Het is vooral van belang goede afspraken te maken over deze koppelvlakken. Niet op basis van wat de methode voorschrijft, maar op basis van wat handig is voor de samenwerking en wat aansluit op de aanwezige competenties. Daarnaast is het noodzakelijk het volgende model, waarin de processen wijzigingsbeheer, incidentbeheer en probleembeheer zijn ingevuld, in te vullen voor het geheel aan ICT-dienstverlening. Van belang is om in overleg te bepalen wie welke rol invult.
Vaak kan de uitleg over en het invullen van deze samenwerkingsmodellen en bijbehorende procedures in enkele dagen plaatsvinden (zie ook ‘Groepstraining on the job: integratie functioneel en technisch beheer en applicatiebeheer’) en zijn complexe trajecten, die vaak het gevolg zijn van de implementatie van BiSL of ITIL, niet nodig. Ook voor alle betrokkenen die wel bekend zijn met ITIL of BiSL is het een uitstekende werkwijze. De aanpak is tenslotte gebaseerd op beide methodieken.
Laat u zich dus niet verleiden tot de invoering van methodieken of het optuigen van veranderingstrajecten die niet zijn afgestemd op de huidige werkwijze. Neem uw huidige werkwijze als uitgangspunt en versterk hierin de rol van het functioneel beheer. In de volgende casestudies kunt u lezen hoe u zo’n traject kunt opzetten met minimale inspanningen en kosten:  

• Casestudy Training functioneel beheer website;
• Casestudy Training Outsourcing werkplekbeheer.

Op deze wijze kunt u wellicht de oplossing vinden voor de spagaat waarin u gedwongen wordt: enerzijds besparen op uw kosten en anderzijds het leveren van meer service.  

Herziene versie 18 maart 2010

Download:         

Gerelateerde artikelen:

1. Afbakening taken functioneel beheer baseren op behoefte
2. Valkuilen functioneel beheer volgens BiSL
3. Samenwerking tussen gebruikers en de ICT-afdeling door functioneel beheer

1. Wat is BiSL?
2. De structuur van BiSL
3. Uitvoerende processen binnen BiSL
4. Sturende processen binnen BiSL
5. Richtinggevende processen binnen BiSL
6. Gebruik van dit begrippenkader

1. Wat is BiSL?

Business Information Services Library (BiSL; spreek uit biesél), voorheen Business Information Service Management Library, is een raamwerk voor het uitvoeren van functioneel beheer en informatiemanagement. Anders dan frameworks als ASL en ITIL richt BiSL zich niet op ICT-organisaties (supply), maar juist op de gebruikersorganisatie (demand). In dit framework staat beschreven:

1. hoe een gebruikersorganisatie ervoor kan zorgen dat informatievoorziening adequaat werkt;
2. hoe men behoeften in het bedrijfsproces vertaalt naar ICT-oplossingen en niet-ICT-oplossingen;
3. hoe men de informatievoorziening en ICT-dienstverlening vanuit een gebruiksoptiek stuurt;
4. hoe men de informatievoorziening op lange termijn vormgeeft.

Het is derhalve voor alle organisaties bestemd, die voldoende ervaring hebben met het organisatiebreed specificeren van een uniforme informatie behoefte en het bewaken van de geleverde ICT-dienstverlening. (Zie ook ‘BiSL voor een professioneel informatiemanagement en functioneel beheer’.)
BiSL is een vrij nieuwe standaard, publiek domein geworden in 2005. Dit raamwerk wordt ondersteund door een aantal best practices, waarmee men invulling kan geven aan functioneel beheer en informatiemanagement in een organisatie. Het raamwerk wordt al door diverse grote Nederlandse organisaties gebruikt en toegepast.

2. De structuur van BiSL

BiSL onderkent processen op drie niveaus:

• uitvoerend niveau
  De uitvoerende of operationele processen houden zich bezig met het dagelijks gebruik van de informatievoorziening en met het vormgeven en realiseren van veranderingen in de informatievoorziening.
• sturend niveau
  De sturende processen houden zich bezig met kosten en opbrengsten, planningen, kwaliteit van de informatievoorziening en afspraken met de ICT-leverancier.
• richtinggevend niveau
  Binnen de processen op richtinggevend niveau wordt bepaald hoe de informatievoorziening er op lange termijn uit moet zien en hoe de sturing op de informatievoorziening moet worden georganiseerd.

Binnen deze drie niveaus zijn de verschillende processen geclusterd in zeven procesclusters, zoals weergegeven in de volgende afbeelding. Drie clusters van processen op uitvoerend niveau, één cluster op sturend niveau en drie procesclusters op richtinggevend niveau.

Figuur 1: De structuur van BiSL

2.1 Clusters van processen op uitvoerend niveau

Op uitvoerend niveau zijn er drie clusters van processen:

• Gebruiksbeheer
• Functionaliteitenbeheer
• Verbindende processen

Gebruiksbeheer
De processen in het cluster gebruiksbeheer hebben een optimale en continue ondersteuning van de bedrijfsprocessen tot doel. De processen in gebruiksbeheer richten zich op ondersteuning van de gebruikers in het gebruik van de informatievoorziening, op operationele aansturing van de ICT-leverancier en op bewaking van de operationele gegevenshuishouding. Centrale vraag bij gebruiksbeheer: wordt de operationele informatievoorziening goed gebruikt en goed aangestuurd?

Functionaliteitenbeheer
De processen in het cluster functionaliteitenbeheer hebben tot doel om wijzigingen in de informatievoorziening vorm te geven en te (laten) realiseren. Centrale vraag bij functionaliteitenbeheer: hoe gaat de gewijzigde informatievoorziening eruit zien?

Verbindende processen op uitvoerend niveau
Het doel van de processen in het cluster verbindende processen op uitvoerend niveau is besluitvorming over welke veranderingen in de informatievoorziening moeten worden aangebracht en het feitelijk doorvoeren van die veranderingen in de informatievoorziening in de gebruikersorganisatie. Centrale vraag bij de verbindende processen op uitvoerend niveau: waarom en hoe veranderen we de informatievoorziening?

2.2 Cluster van processen op sturend niveau

Overkoepelend – boven de uitvoerende processen – bevinden zich de sturende processen. Deze vormen de brug tussen het richtinggevende niveau en de uitvoerende processen.
De processen op sturend niveau verzorgen een integrale sturing van de uitvoering van de informatievoorziening. Vanuit het oogpunt van planning, kosteneffectiviteit, behoeften, contracten en service levels vindt aansturing plaats op de beheerwerkzaamheden, op onderhouds- en vernieuwingsprocessen en op de verbindende processen. Centrale vraag bij de sturende processen: hoe sturen we de informatievoorziening?

2.3 Clusters van processen op richtinggevend niveau

Op richtinggevend niveau zijn er ook drie procesclusters. Deze procesclusters houden zich bezig met de vormgeving van het beleid ten aanzien van de informatievoorziening en met de organisaties die daarbij betrokken zijn.

Opstellen informatiestrategie
Het doel van de processen in het cluster opstellen informatiestrategie is het vertalen van ontwikkelingen in de bedrijfsprocessen en de omgeving van de organisatie en de technologie, naar een visie op de inhoud van de informatievoorziening in de toekomst. Centrale vraag bij de processen opstellen informatiestrategie: hoe gaat de informatievoorziening er op (middel)lange termijn uitzien?

Opstellen IV-organisatiestrategie
De processen in het cluster opstellen IV-organisatiestrategie richten zich op het afstemmen van communicatie, sturing, structurering en werkwijze van alle partijen die betrokken zijn bij de besluitvorming over de informatievoorziening. Centrale vraag bij de processen opstellen IV-organisatiestrategie: hoe wordt de sturing van de informatievoorziening georganiseerd?

Verbindende processen op richtinggevend niveau
Het doel van de verbindende processen op richtinggevend niveau is het realiseren van afstemming tussen alle partijen en alle plannen op de diverse deelgebieden van de informatievoorziening. Centrale vraag bij dit procescluster: hoe acteren we gezamenlijk?

3. Uitvoerende processen binnen BiSL

3.1 Cluster gebruiksbeheer

In het cluster gebruiksbeheer worden drie processen onderkend die gericht zijn op het ondersteunen en het operationeel houden van de dagelijkse gang van zaken in de informatievoorziening. Deze processen zijn geclusterd naar de begrippen gebruikers, informatie en inhoud van het informatiesysteem.

Gebruikersondersteuning
De doelstelling van gebruikersondersteuning is het ondersteunen, faciliteren en bijsturen van de gebruikers bij het gebruik van de informatievoorziening in de dagelijkse praktijk, zodat de gebruikers optimaal kunnen werken met de bestaande informatievoorziening. Enerzijds worden daarbij informatievragen, klachten, wensen, opdrachten en dergelijke vanuit de gebruikers ontvangen en afgehandeld. Anderzijds worden gebruikers met nieuwsbrieven, gebruikersoverleggen, opleidingen en instructies op de hoogte gebracht van ontwikkelingen in de informatievoorziening en worden zij ondersteund bij het gebruik van de informatievoorziening.

Beheer bedrijfsinformatie
Het proces beheer bedrijfsinformatie richt zich op een correcte opzet en inhoud van de gegevens in de informatievoorziening (en dus ook in de informatiesystemen). Het gaat daarbij onder andere om het beheer van centrale tabellen, om bewaking op een juiste hantering van het bedrijfsinformatiemodel, om het treffen van maatregelen om de gegevenskwaliteit te garanderen en om het verstrekken van ad hoc gegevens en managementinformatie.

Operationele ICT-aansturing
Het proces operationele ICT-aansturing vormt de operationele aansturing van de ICT-leverancier. Deze aansturing vindt plaats binnen de kaders zoals die vanuit processen op richtinggevend (mantelovereenkomsten) en sturend (contracten en SLA’s) niveau worden gedefinieerd. Op basis van eisen vanuit de bedrijfsprocessen ten aanzien van de aspecten beschikbaarheid, capaciteit en continuïteit worden opdrachten verstrekt en wordt de dienstverlening van de ICT-leverancier bewaakt. Functioneel beheer stelt eisen, bewaakt, meet en rapporteert hierbij in termen van de gebruikersorganisatie.

3.2 Cluster functionaliteitenbeheer

De processen in functionaliteitenbeheer hebben betrekking op een tweetal aandachtsgebieden:

• het vormgeven
  Functionaliteitenbeheer richt zich op het vormgeven van de gewenste verandering van functionaliteit. Deze processen zijn inhoudelijk van aard.
• het overdragen
  Functionaliteitenbeheer houdt zich bezig met het initiëren en voorbereiden van de gewenste transitie en de doorvoering van de gewenste verandering.

Specificeren
De doelstelling van het proces specificeren is het vertalen van de door wijzigingenbeheer aangegeven gewenste veranderingen in functionaliteit, naar inhoudelijke en niet-inhoudelijke oplossingsrichtingen en het vastleggen hiervan ten behoeve van verdere realisatie van de geautomatiseerde informatievoorziening. Dit dient te geschieden op een dusdanige wijze, dat een eenduidige acceptatie van eventuele dienstverlening door ICT-leveranciers mogelijk is. Het proces specificeren is één van de belangrijkste processen van functioneel beheer, omdat juist hier de vertaling gemaakt wordt van behoefte naar oplossing. Dit proces heeft dus in hoge mate invloed op de kosten en de kwaliteit van de informatievoorziening.

Vormgeven niet-geautomatiseerde informatievoorziening
Het proces vormgeven niet-geautomatiseerde informatievoorziening is gericht op het opzetten en onderhouden van de relevante documentatie voor het gebruik en het functioneel beheer van het informatiesysteem (procedures, werkinstructies, handleidingen, en dergelijke). Deze organisatorische kant heeft natuurlijk een sterke afhankelijkheid met het geautomatiseerde systeem.

Toetsen en testen
De doelstelling van het proces toetsen en testen is om ervoor te zorgen dat de gewenste verandering vlekkeloos in de organisatie wordt doorgevoerd en dat de gebruikte instrumenten, hulpmiddelen en andere ondersteuningsvormen correct zijn en correct werken. Het meest bekende onderdeel in dit proces is de acceptatietest.

Voorbereiden transitie (implementeren)
Het proces voorbereiden transitie (implementeren) moet zorgen voor een probleemloze ingebruikname van de nieuwe en/of gewijzigde functionaliteit door alle benodigde randvoorwaarden zodanig in te vullen, dat de gewenste verandering hierna probleemloos geëffectueerd kan worden.

3.3 Verbindende processen

Door de processen van gebruiksbeheer wordt de dagelijkse ondersteuning van de informatievoorziening verzorgd. De processen van functionaliteitenbeheer zorgen voor het realiseren van wijzigingen in de informatievoorziening. De synchronisatie en de communicatie tussen deze twee verschillende aandachtsgebieden verlopen via de verbindende processen. De verbindende processen zijn wijzigingenbeheer en transitie.

Wijzigingenbeheer
Het proces wijzigingenbeheer heeft tot doel te komen tot de juiste besluiten over het aanbrengen van wijzigingen of vernieuwingen in de informatievoorziening. Hiertoe bevat wijzigingenbeheer een mechanisme voor het inventariseren, evalueren, prioriteren en ten uitvoer brengen van wijzigingen in de informatievoorziening. Bij wijzigingenbeheer worden de besluiten genomen over uit te voeren wijzigingen waarna deze als opdrachten voor uitvoering worden geïnitieerd. In dit proces vindt nauw overleg plaats tussen opdrachtgever en opdrachtnemer. De opdrachtgever komt daarbij uiteindelijk -mede op basis van de resultaten van een impactanalyse van de opdrachtnemer- tot besluiten over doorvoering van de wijzigingen.

Transitie
Het proces transitie is gericht op de effectuering van de verandering voor de eindgebruikers, die is voorbereid in de processen van functionaliteitenbeheer en de achterliggende activiteiten van de ICT-leverancier. Transitie vormt het regiemechanisme op het in gebruik nemen van aangebrachte wijzigingen of vernieuwingen. Na de formele acceptatie van de wijziging en de voorbereiding op de ingebruikname vindt tijdens het transitieproces de feitelijke ingebruikname plaats.

4. Sturende processen binnen BiSL

Bij de sturing op de informatievoorziening in een organisatie gaat het om de sturing op de inhoud / functionaliteit (wat), de kosten (hoeveel), de planning (wie, wanneer) en de supply (hoe, waarmee). Deze vier soorten van sturing leiden tot een viertal te onderscheiden processen.

Financieel management
Financieel management heeft tot doel het maken, het onderhouden en het bewaken van een -vanuit financieel en bedrijfsmatig perspectief- kosteneffectieve informatievoorziening en een kosteneffectieve inzet van (geautomatiseerde) ICT-middelen voor ondersteuning en uitvoering van de bedrijfsprocessen van de organisatie. De kosteneffectiviteit wordt niet alleen bepaald door de kosten maar ook door de baten. De business case vindt men dus terug in dit proces.

Planning & Control
Het proces planning & control heeft tot doel het plannen, het bewaken en het bijsturen van de activiteiten van de organisatie die te maken hebben met het verzorgen van de informatievoorziening, zodat de noodzakelijke inzet van de informatievoorziening in de organisatie op tijd gerealiseerd wordt met een optimale inzet van capaciteit. Essentieel hierbij is dat de planning & control over verschillende domeinen plaatsvindt: niet alleen voor de functioneel-beheerinspanningen, maar ook voor de inspanningen die in de gebruikersorganisatie worden verricht in het kader van het inrichten en op peil houden van de informatievoorziening. Bovendien moeten de planningen afgestemd zijn op, en in lijn zijn met, de ICT-dienstverlening.

Behoeftemanagement
Behoeftemanagement heeft tot doel ervoor te zorgen dat de bedrijfsprocessen van een organisatie ondersteund of ingevuld worden door een goede informatievoorziening en een goede functioneel beheerorganisatie. Behoeftemanagement is ervoor verantwoordelijk dat bestaande en nieuwe behoeften van het bedrijfsproces worden onderkend en dat hierover besluitvorming plaatsvindt. Een synoniem, dat in sommige organisaties wordt gebruikt is kwaliteitsmanagement.

Contractmanagement
Contractmanagement is verantwoordelijk voor het maken van goede en adequate afspraken over de geautomatiseerde informatievoorziening en de dienstverlening door de ICT-leverancier. Daarnaast is het contractmanagement verantwoordelijk voor het bewaken van deze afspraken en zo nodig het verbeteren van die afspraken. Belangrijke ‘producten’ van dit proces zijn bijvoorbeeld het ICT-servicecontract, de Service Level Agreement (SLA) of andere vormen van contracten en afspraken zoals Underpinning Contracts (UC’s), Operational Level Agreements(OLA’s), et cetera.

5. Richtinggevende processen binnen BiSL

5.1 Opstellen informatiestrategie

Het cluster opstellen informatiestrategie is gericht op het opstellen van beleid voor de inhoud van de informatievoorziening op (middel)lange termijn. In dit beleid wordt ingespeeld op veranderingen in de eigen organisatie, op de omgeving en op de technologie, om ook op termijn aansluiting te borgen tussen de informatievoorziening en de bedrijfsprocessen. Dit cluster bestaat uit vijf processen.

Bepalen bedrijfsprocesontwikkelingen
Het proces bepalen bedrijfsprocesontwikkelingen brengt de ontwikkelingen in kaart die zich op langere termijn voordoen in de organisatie en de bedrijfsprocessen. Hierbij moet gedacht worden aan wijzigingen op het gebied van financiën, producten die gebruikt worden, procesinrichting, personele invulling en dergelijke. De in kaart gebrachte ontwikkelingen worden geanalyseerd en vertaald naar gevolgen voor de informatievoorziening. De onderkende gevolgen voor de informatievoorziening op langere termijn dienen als input voor het uiteindelijk opstellen van het informatiebeleid.

Bepalen ketenontwikkelingen
Bij het proces bepalen ketenontwikkelingen is de focus gericht op informatievoorziening over meerdere organisaties heen en op de informatie-uitwisseling met andere organisaties. Beoordeeld wordt wat de consequenties zijn voor de eigen informatievoorziening als gevolg van de uitwisseling met andere organisaties en wijzigingen in de informatievoorziening bij de ketenpartners. Het doel van dit proces is om op langere termijn de eigen bedrijfsprocessen blijvend aan te laten
sluiten op de omgeving, door een effectieve en efficiënte uitwisseling van de informatievoorziening met de ketenpartners.

Bepalen technologieontwikkelingen
Het proces bepalen technologieontwikkelingen bepaalt of er technologische ontwikkelingen plaatsvinden, die vanuit het bedrijfsperspectief impact kunnen hebben op de organisatie en de informatievoorziening. Hoewel de focus van functioneel beheer ligt op de behoeften vanuit het bedrijfsproces (vraagkant) is het toch ook belangrijk om inzicht te hebben in technologische ontwikkelingen (aanbodkant). Nieuwe mogelijkheden die geboden worden door nieuwe technologie, uitfasering door de leverancier van in de organisatie gebruikte technologie of hoge kosten van een bepaalde technologie kunnen grote gevolgen hebben voor de informatievoorziening.

Informatie lifecycle management
Doelstelling van het proces informatie lifecycle management is het opstellen van een strategie voor de informatievoorziening. Voor de onderkende informatiedomeinen (vaak zijn deze gekoppeld aan bedrijfsprocessen) wordt vastgesteld wat in de toekomst de mogelijkheden zijn voor beheer, onderhoud en vernieuwing en waaraan behoefte bestaat. Bij de behoeftebepaling wordt aan de ene kant rekening gehouden met de ontwikkelingen op langere termijn op het vlak van de bedrijfsprocessen, met de omgeving van de organisatie en met de technologie. Aan de andere kant wordt rekening gehouden met de huidige staat van de informatievoorziening en de daarbinnen bestaande structurele knelpunten en problemen.

Informatie portfoliomanagement
Het proces informatie portfoliomanagement zorgt voor overkoepelende afstemming van, en uniformiteit over het geheel van de informatievoorziening in de gehele organisatie. Een belangrijk onderwerp is de structuur van de informatievoorziening. Hierbij wordt aangegeven op welke wijze de informatievoorziening wordt opgedeeld en wat de samenhang is tussen de verschillende onderdelen. Verder wordt aandacht besteed aan het totaal van alle gewenste en voorgenomen veranderingen en oplossingsmogelijkheden voor de gehele informatievoorziening. Op een overkoepelend niveau worden alle veranderingen afgestemd en wordt in de toekomst een optimale aansluiting tussen de bedrijfsprocessen en de informatievoorziening gerealiseerd. Tenslotte wordt bij informatie portfoliomanagement gedefinieerd welke afspraken gemaakt worden over de inzet van ICT-hulpmiddelen. Het gaat dan over het opstellen van een infrastructuurarchitectuur en een ontwikkelarchitectuur.

5.2 Opstellen IV-organisatiestrategie

Het procescluster opstellen IV-organisatiestrategie bestaat uit vier processen die gericht zijn op het definiëren van de wijze waarop de besturing van en de besluitvorming over de informatievoorziening worden georganiseerd.

Ketenpartnermanagement
Informatie-uitwisseling tussen organisaties is vaak een absolute voorwaarde voor die organisaties. Ketenpartnermanagement  maakt het mogelijk dat tussen verschillende organisaties informatie-uitwisseling plaatsvindt. Hiertoe worden samenwerkingen op het gebied van informatievoorziening gedefinieerd en onderhouden. Vaak ontbreekt in een dergelijke keten waarin informatie-uitwisseling plaatsvindt, een overkoepelende hiërarchische partij. Centrale sturing op de keten ontbreekt daardoor en het succes van de keten is daarmee afhankelijk van de wil tot samenwerking bij iedere autonome partij. Er zijn daarom goede afspraken nodig tussen de verschillende partijen binnen de uitwisselingsketen om de verschillende invloeden op de informatieketen beheerst te laten verlopen.
Een speciale vorm van een keten is informatie-uitwisseling met instanties die door wet- en regelgeving wordt opgelegd. Hierbij is geen sprake van het op de uitwisseling aan gewezen zijn voor het kunnen uitvoeren van de bedrijfsprocessen. Er is dan ook geen keten op basis van vrijwilligheid, maar er is gedwongen ketenvorming. Toch is het ook in een dergelijke situatie nuttig om beleid te hebben, dat aangeeft hoe de organisatie met dergelijke uitwisseling om wil gaan.

Relatiemanagement gebruikersorganisatie
Het doel van het proces relatiemanagement gebruikersorganisatie is het vormgeven en bewaken van de consistentie, de samenhang en de communicatie tussen de IV-functie en de gebruikersorganisatie. Ontwikkelingen in de besturingsvorm van de gebruikersorganisatie worden gevolgd en vertaald naar een passende inrichting van en verantwoordelijkheden in de sturing van de informatievoorziening. Daarnaast worden de communicatiekanalen tussen gebruikersorganisatie en functioneel-beheerorganisatie vormgegeven in het proces relatiemanagement gebruikersorganisatie. Belangrijke aspecten waaraan aandacht wordt besteed zijn de formele structuur van de gebruikersorganisatie en de -al dan niet formele- beslissingsbevoegdheden van de gebruikersorganisatie. De structuur en beslissingsbevoegdheden bij het functioneel beheer zullen hierop afgestemd moeten zijn. Afgezien van de gewijzigde naam (voorheen gebruikersorganisatie ontwikkelingen) zijn er geen veranderingen in dit proces ten opzichte van het voorgaande model.

Leveranciersmanagement
In het proces leveranciersmanagement wordt bepaald welke ICT-leveranciers het meest geschikt zijn om de voor de informatievoorziening benodigde middelen en kennis in te brengen. Daarnaast wordt in dit proces bepaald welke rol en verantwoordelijkheden de gekozen ICT-leveranciers moeten hebben. Afspraken hierover met de leveranciers worden gemaakt en bewaakt in het proces leveranciersmanagement. Deze afspraken over leveranciersgerelateerde onderwerpen vormen de kaders voor de afspraken over dienstgerelateerde onderwerpen die worden gemanaged in het proces contractmanagement. Voorbeelden van afspraken in dit proces zijn mantelovereenkomsten en outsourcingscontracten.

Strategie inrichting IV-functie
Het doel van het proces strategie inrichting IV-functie is het vormgeven van de gewenste inrichting van de functie die de informatievoorziening regelt in de organisatie. Bij het vormgeven wordt aandacht besteed aan de organisatievorm, aan verantwoordelijkheden, aan uitvoering en aan samenwerking tussen de verschillende organisatieonderdelen die betrokken zijn bij functioneel beheer. Functioneel beheer wordt doorgaans op meerdere plaatsen en ook op verschillende niveaus in een organisatie uitgevoerd. In het proces strategie inrichting IV-functie wordt een consistente, eenduidige en coherente manier van werken binnen het totale functioneel-beheerdomein geborgd.

5.3 Verbindende processen op richtinggevend niveau: informatiecoördinatie

Binnen de verschillende niveaus van functioneel beheer en ook op verschillende niveaus in de businessorganisatie worden allerlei plannen gemaakt, die direct betrekking hebben op de informatievoorziening of die raakvlakken hebben met de informatievoorziening. In dit procescluster, kortweg informatiecoördinatie genoemd, worden deze plannen op elkaar afgestemd.
Op verschillende niveaus binnen functioneel beheer en de businessorganisatie worden allerlei plannen opgesteld die direct of indirect de informatievoorziening raken. Bijvoorbeeld de portfolioplannen op corporate niveau, de verschillende plannen van systeemeigenaren voor de toekomst van hun informatiesystemen, de plannen voor de inrichting van de IV-organisatie en ook de plannen voor de inrichting van de bedrijfsprocessen. Alle partijen hebben  verschillende en onderling uiteenlopende belangen die voor een effectieve informatievoorziening op elkaar afgestemd moeten worden.

6.  Gebruik van dit begrippenkader

Net als dat bij ITIL in het begin het geval was, is BiSL voornamelijk een eenduidig begrippenkader. Dit begrippenkader is dekkend voor het werkveld van functioneel beheer en informatie management. Processen kunnen er eenduidig mee worden benoemd.
De meeste organisaties hebben nog niet het stadium van maturity bereikt, dat het nodig maakt om alle drie niveaus volledig in te richten. Zolang een organisatie nog niet doet aan business process outsourcing (BPO) of werkt met een verzelfstandigd shared service center (SSC) kan zij meestal volstaan met het inrichten van de uitvoerende processen en het beleggen van de verantwoordelijkheid voor de tactische processen. Als de levering van ICT-diensten grotendeels wordt uitbesteed, dan pas zal er een volwassen tegenspeler klaar moeten staan om zeker te stellen dat de automatisering geen ongeleid projectiel wordt.
In het artikel ‘Van ITIL 1 naar ITIL 3: wat bereik je daar als organisatie mee?’ worden de ontwikkelingsstadia van een organisatie besproken en worden ITIL 1, 2 en 3 gepositioneerd.

Figuur 2: Ontwikkelingsstadia

BiSL kan in dit model op dezelfde plek worden gepositioneerd als ITIL 3. Een complete implementatie is dus voor de meeste organisaties nog niet nodig.

Bron: Frank van Outvorst, Ralph Donatz, Remko van der Pols, ‘Introductie BiSL, Een framework voor functioneel beheer en informatiemanagement’. ASL BiSL Foundation. 2005.

Download:         

Gerelateerde artikelen:

1. Integratie ITIL, ASL en BiSL is noodzaak of niet doen deel 2
2. Integratie ITIL, ASL en BiSL is noodzaak of niet doen deel 1
3. BiSL maakt functioneel beheer wel erg ingewikkeld

1. Bedrijfscontinuïteit is meer dan ICT
2. Business Continuity Management
3. Verschuivingen
4. Spanningsvelden
5. Eisen Business Continuity Management
6. Imagoschade
7. Bedrijfscontinuïteit in de praktijk 

1. Bedrijfscontinuïteit is meer dan ICT

Bedrijfscontinuïteit wordt  vaak gekoppeld aan ICT en daarmee aan de ICT-dienstverlening. Er is echter vrijwel nog nooit een bedrijf kapot gegaan door moeilijkheden met zijn ICT. (Zie ook ‘Business continuity steeds meer aandachtspunt voor controllers’.) ICT’ers overschatten vaak het belang van de ICT.
Alleen omdat het issue bedrijfscontinuïteit voorkomt in de methodiek ITIL voor ICT-beheer, voelen veel ICT-managers zich geroepen om dit op te pakken. Meestal doet niemand anders dit en daarom is het op zich een goede zaak. Het moet echter wel duidelijk zijn dat de ICT in veel bedrijven niet het verschil uitmaakt tussen het al dan niet overleven van calamiteiten. (Zie ook ‘Business continuity in de industrie, groothandel en distributie’.) Soms richt de ICT-afdeling meer schade aan met haar bestrijding van calamiteiten dan dat ze goed doet. Niet de ICT-manager moet de belangrijkste stem hebben bij een calamiteit, maar de directie.
Laten we eerst een paar zaken op een rijtje zetten. Een calamiteit is niets meer en niets minder dan een incident dat de bedrijfsvoering dreigt te belemmeren. Als het gaat om een uitslaande brand, om een vliegtuig dat op uw pand landt, om een terroristische aanslag of om een overstroming, dan is het evident dat er sprake is van een calamiteit. Als het echter gaat om gevelplaten die van uw pand vallen of van dat van uw buurman, dan moet u maar afwachten waar de politie de bekende rood-witte linten spant en of er nog iemand uw pand in of uit kan, dus of uw bedrijfsvoering wordt belemmerd. En als het gaat om bijvoorbeeld een stroomstoring, een bommelding of een uitbraak van de menselijke variant van vogelgriep, dan zult u zelf moeten bepalen of er alleen maar sprake is van een incident of dat u getroffen wordt door een calamiteit.
In veel gevallen treedt eerst het BHV-plan in werking. Als iedereen na een kwartier op veilige afstand staat, dan wordt doorgaans overgegaan op het Business Continuity Plan (BCP). Die overgang kan soms heel groot zijn. Het BHV-plan en de BHV’ers zijn namelijk mensgericht en het BCP en de ICT’ers veel meer zaakgericht. Daarbij komt dat een BCP binnen de ICT vaak wordt gezien als onderdeel van de informatiebeveiliging, wat uiteraard geen goede afbakening is. Een goed crisisteam, dat zijn verantwoordelijkheden neemt, is cruciaal. (Zie ook ‘Inpassing business continuity BCP in BHV-plan, ICT en algemeen beleid veiligheid’.) 

2. Business Continuity Management

Business Continuity Management zet de werkzaamheden van IT-managers onder druk. We zien dat het businessmanagement zich actiever gaat bezighouden met de continuïteit van de IT-systemen. De verantwoordelijkheden verschuiven. De IT-manager wordt steeds vaker opdrachtnemer voor het uitvoeren van bedrijfscontinuïteitsmaatregelen.
Het businessmanagement stelt ook steeds hogere eisen aan de continuïteit van de operationele bedrijfsprocessen. Hierbij gaat het aan de ene kant om het nemen van preventieve maatregelen om een calamiteit te voorkomen en aan de andere kant om correctieve maatregelen, inclusief het bijbehorende crisismanagement, om het effect van een calamiteit te minimaliseren. Met name bij grotere organisaties pakt het businessmanagement deze verantwoordelijkheid vaak ook daadwerkelijk op en gaat het de operationele continuïteit directer aansturen.
Als de ICT-manager hierbij opdrachtnemer is, is dat een risico. Hij is al verantwoordelijk voor de ICT-service Deze nieuwe verantwoordelijkheid krijgt hij er dan maar even bij, terwijl hij doorgaans maar een deel van de puzzel kan overzien. Als we een aantal hoofdzaken op een rijtje zetten wordt dat duidelijk:

• De meeste calamiteiten zullen zelden of nooit voorkomen. In veel gevallen zijn preventieve maatregelen dan ook weggegooid geld. (Zie ook ‘Business continuity los je niet op met preventie’.)
• Er moet een draaiboek zijn voor het geval er een calamiteit optreedt. Er moet tevens een implementatieplan zijn, waarin de condities beschreven staan, opdat het draaiboek ook daadwerkelijk gaat werken. (Zie ook ‘Keuzes en aanpak voor uw Business Continuity Plan BCP of calamiteitenplan’.)
• Voor veel bedrijven is imagoschade een groot risico. Imagoschade echter is veel meer de verantwoordelijkheid van de afdeling communicatie dan van de ICT-afdeling. (Zie ook ‘Imagoschade bij calamiteiten veroorzaak je meestal zelf’.)
• Vanwege de wildgroei van preventieve acties door de politie en allerlei toezichthouders en door terreurdreigingen neemt het risico, dat een bedrijfspand voor klanten en medewerkers wordt afgesloten steeds meer toe. De oplossing voor dit probleem is echter niet het specialisme van de ICT-manager. (Zie ook ‘Casestudies Business Continuity Plan’.)

We kunnen stellen dat de klant steeds meer en beter wil, dat de media steeds meer aandacht hebben voor calamiteiten en crises, dat imagoschade steeds eerder optreedt, dat de concurrentie toeneemt, dat de toezichthouder kritischer wordt, dat interne en externe risico’s toenemen en tot slot dat al deze factoren leiden tot een toenemend bewustzijn van de noodzaak van BCM in het algemeen en van crisismanagement in het bijzonder.
Traditioneel is de verantwoordelijkheid voor het herstel van de door ICT ondersteunde bedrijfsprocessen neergelegd bij de IT-manager, met de daaruit voortvloeiende focus op: hoe herstellen we onze informatiesystemen op systeemniveau? Tegenwoordig ligt dit minder voor de hand, want de drivers komen niet alleen meer vanuit het ICT-domein, maar uit meerdere hoeken tegelijk.
Organisaties die hun eigen operationele processen beter willen waarborgen vragen om hogere continuïteitsgaranties van hun leveranciers. Wet- en regelgeving dwingen tot het verkleinen van de operationele risico’s. Toezichthouders eisen dat er een bedrijfscontinuïteitsplan komt, omdat men vreest voor imagoschade met alle gevolgen van dien voor het voortbestaan van de organisatie. Bovendien nemen de dreigingen op zich toe en daarmee de continuïteitsrisico’s. Denk aan terreurdreigingen en toenemende digitale aanvallen op systemen en netwerken. Als laatste is ook het businessmanagement zelf zich bewust geworden van het feit dat het leveren van kwaliteit gepaard moet gaan met continuïteitsgaranties.
Om overzicht te houden, zullen we in de volgende hoofdstukken de verschillende aspecten van een BCP bekijken vanuit de optiek van de ICT-manager. We gaan daarbij tevens in op de risico’s die een organisatie loopt dat bij de inrichting van het continuïteitsmanagement niet wordt voldaan aan de eisen van het businessmanagement, als de ICT-manager de eerst verantwoordelijke is. 

3. Verschuivingen

In het verleden heeft de ICT-manager zich vaak alleen op technisch niveau beziggehouden met continuïteit, waarbij we kunnen denken aan back-up, recovery en systeemuitwijk. Nu gaat het businessmanagement een actieve rol spelen in de aansturing van de operationele continuïteit, inclusief de ICT-componenten daarin. De focus verschuift daarmee van systeemuitwijk en -herstel naar procesuitwijk en -herstel. Dit betekent ook verschuivingen van verantwoordelijkheden en rollen tussen de businessmanager en de ICT-manager. Bij een calamiteit is voortaan de verantwoordelijke businessmanager leidend in de afhandeling. De uitwijk- en herstelwerkzaamheden bij een calamiteit worden vanuit de business gestuurd. Voorbeelden hiervan zijn dat het herstel van het afhandelen van orders, de afhandeling van klantvragen of het herstel van lijnafdelingen de hoofdprioriteit krijgt. Herstel van ICT-middelen staat in dienst van het herstel van de bedrijfprocessen.
ICT-uitwijk is niet meer leidend maar volgend. De IT-manager wordt opdrachtnemer voor het uitvoeren van bedrijfscontinuïteitsmaatregelen. Met de leidende rol van de businessmanagers wordt de IT-manager ook opdrachtnemer om te zorgen voor de noodzakelijke redundante ICT-voorzieningen en ICT-noodvoorzieningen, inclusief het beheer hiervan. Het behoeft geen betoog dat hiermee spanningsvelden voor de IT-manager worden gecreëerd. Voor de IT-manager zijn de volgende zes spanningsvelden te onderkennen. 

4. Spanningsvelden

Ten eerste zijn de ICT-systemen slechts een onderdeel van de totale uitwijk, naast bijvoorbeeld mensen, gebouwen, overige apparatuur, werkplekken, organisatie en informatie. De mate waarin de operationele processen afhankelijk zijn van de ICT-systemen versus de afhankelijkheid van de andere bedrijfsmiddelen is bepalend voor de rol van de IT-manager in het uitwijk- en herstelproces. Deze rol zal in veel gevallen ertoe leiden dat het door de IT-manager opgezette uitwijk- en herstelplan (ICT Services Continuity) op een aantal punten strijdig zal zijn met het vanuit de business opgestelde uitwijk- en herstelplan (Business Continuity Plan). Een voorbeeld is dat binnen ICT Services Continuity datacommunicatie als verantwoordelijkheidsgebied is uitgewerkt en in het Business Continuity Plan het call-center (spraakcommunicatie). Er ontbreekt een geïntegreerde calamiteitenaanpak.
In de tweede plaats moeten architecturen en onderliggende systemen en infrastructuren resilient (veerkrachtig) worden ingericht. Dat wil zeggen: zowel bestand tegen relevante bedreigingen (robuust) als flexibel om aan de verscheidenheid aan continuïteitseisen vanuit de business te kunnen voldoen. Businessmanagers kunnen voor hun systemen bijvoorbeeld kiezen tussen drie verschillende infrastructuren, die ieder een eigen niveau van continuïteit bieden maar natuurlijk ook een eigen prijskaartje hebben. De IT-manager heeft natuurlijk de kennis om alternatieven te vergelijken, maar als daar geen gebruik van wordt gemaakt door de businessmanagers is een tweede spanningsveld geschapen. Daarnaast krijgt de IT-manager van verschillende businessmanagers verschillende continuïteitseisen aangeleverd. De IT-manager wordt dan geconfronteerd met het probleem: voor welke continuïteitseisen ga ik standaardvoorzieningen treffen en waar liggen de specials.
Ten derde moet de IT-manager middelen beschikbaar hebben om te sturen op crisismanagement en het zo veel mogelijk beperken van schade. Concreet betekent dit dat er bijvoorbeeld redundante netwerkvoorzieningen (preventie) en no-breakinstallaties moeten worden ingericht, maar ook extra werkplekken beschikbaar moeten zijn op verschillende gescheiden locaties. Hierdoor wordt een situatie van ‘overal werken’ geschapen, waarmee de basis aanwezig is om bij uitvallen van reguliere werkplekken de werkzaamheden elders te kunnen continueren. Een spanningsveld ontstaat, als men vanuit de operationele processen denkt, dat hiermee tegelijk uitwijkwerkplekken beschikbaar zijn, inclusief toegang tot de centrale systemen. Deze toegang is echter niet per definitie verzekerd en vereist ook continuïteitsmaatregelen voor de informatiesystemen met specifieke eisen aan gebruikersprofielen en autorisaties.
In de vierde plaats is het ook de taak van de IT-manager om afspraken met systeem- en telecommunicatieleveranciers te maken voor het geval er bijvoorbeeld verbindingen uitvallen en er herrouteringsafspraken moeten worden gemaakt. Een spanningsveld is aanwezig als de IT-manager dit te veel op eigen houtje doet zonder afstemming met de proceseigenaar.
Beide vorige punten betekenen dat de bij ICT berustende continuïteitsmaatregelen op gespannen voet kunnen komen te staan met ICT-activiteiten gericht op het verbeteren van de functionaliteit van de ICT-dienstverlening.
In de vijfde plaats zullen sommige businessmanagers aan de IT-manager de opdracht geven tot kwaliteitsverbeteringen van systemen (meer of betere functionaliteit), terwijl andere businessmanagers de betrouwbaarheid of continuïteit van de systemen willen laten verbeteren. Als niet van hogerhand prioriteiten worden gesteld komt de IT-manager tussen twee vuren te zitten, omdat zijn middelen beperkt zijn. De relevante vraag is dus: kies je voor extra continuïteit of voor extra functionaliteit en op basis waarvan bepaal je de juiste keuze?
De integrale aanpak die grotere organisaties nu kiezen voor het beheersen van hun operationele continuïteit leidt tot de noodzaak van een scherpere afbakening van de verantwoordelijkheidsgebieden van alle toeleveranciers van de operationele bedrijfsprocessen: interne ICT, externe ICT, facilitair bedrijf, externe toeleveranciers.
Het zesde en laatste spanningsveld voor de IT-manager is dat hij zorg moet dragen voor de juiste afspraken met alle partijen. De eisen vanuit de bedrijfsprocessen moeten worden opgelijnd met de mogelijkheden die interne en externe leveranciers van diensten bieden. Alle afspraken moeten vooraf zijn gemaakt zodat in geval van een calamiteit geen tijd wordt verspild met wachten op elkaar of tijdrovende overleggen. 

5. Eisen Business Continuity Management

De zes spanningsvelden kunnen ervoor zorgen, dat de inrichting van het continuïteitsmanagement binnen een organisatie niet aan de eisen voldoet die het businessmanagement hieraan stelt. De IT-manager zal dus maatregelen moeten treffen om ervoor te zorgen dat hij kan (blijven) voldoen aan de continuïteitseisen die aan zijn systemen en processen worden gesteld.
In de eerste plaats zal de IT-manager zich meer de opdrachtnemersrol moeten toemeten dan de opdrachtgeversrol. Hij zal businessmanagers moeten begeleiden in het op zich nemen van de opdrachtgeversrol door hen bijvoorbeeld te begeleiden bij het vaststellen van de continuïteitsnormen van de bedrijfprocessen en het definiëren van de hieruit volgende continuïteitstrategieën. In dergelijke strategieën definieert het
businessmanagement de maximale tijd dat informatiesystemen niet beschikbaar mogen zijn, het maximaal toelaatbare gegevensverlies en de volgorde waarin informatiesystemen moeten worden hersteld na het optreden van een calamiteit. Dit soort normen kunnen alleen door de eigenaren van de bedrijfsprocessen, oftewel het businessmanagement, worden gesteld omdat zij het beste de impact kunnen inschatten van het niet beschikbaar zijn van informatiesystemen. Wanneer continuïteitstrategieën eenmaal zijn vastgesteld zal de IT-manager er samen met het businessmanagement voor moeten zorgen dat de strategieën worden vertaald in concrete afspraken die in SLA’s worden vastgelegd. Afspraken over beschikbaarheid worden standaard in SLA’s vastgelegd. Deze afspraken moeten worden uitgebreid met afspraken met betrekking tot continuïteit.
Om de implementatie van alle verschillende continuïteitseisen beheersbaar te houden zal de IT-manager een aantal standaardcontinuïteitsoplossingen bieden, waaruit businessmanagers kunnen kiezen en die in de SLA’s kunnen worden opgenomen. De diverse oplossingen kunnen worden ontwikkeld in de vorm van verschillende flexibele architecturen die bestand zijn tegen verstoringen (robuust) en die zowel procedureel als technisch meerdere niveaus van continuïteit kunnen bieden. Op procedureel niveau kan worden gedacht aan verschillende niveaus van reactietijden, verschillende niveaus van menselijke of geautomatiseerde monitoring en alarmering en verschillen in eisen aan piketdiensten. Op technisch niveau kunnen infrastructuren robuust worden gemaakt door bijvoorbeeld het inbouwen van redundantie in netwerkverbindingen of in servers. Ook kan gebruik worden gemaakt van technologieën zoals geautomatiseerde fall-back, clustering en server based computing. 

6. Imagoschade

In principe is de eigenaar van een bedrijfproces, de businessmanager, verantwoordelijk voor de continuïteit van dit proces. Deze continuïteit is afhankelijk van vele factoren zoals medewerkers, gebouwen en werkplekken. Ook de ICT-middelen zijn bij veel organisaties essentieel voor de continuïteit van de bedrijfsprocessen.
Van oudsher valt continuïteit vaak onder de verantwoordelijkheid van de ICT-afdeling, terwijl de laatste jaren steeds vaker de CEO hiervoor direct verantwoordelijk wordt gesteld. Vanwege het toenemende belang van de operationele continuïteit van organisaties wordt de CEO vaak expliciet als verantwoordelijke voor de continuïteit aangewezen. Een belangrijke oorzaak hiervan is ook het feit dat imagoschade steeds belangrijker wordt, en dat overstijgt het domein van de IT-manager, het betreft de organisatie als geheel.
Om de continuïteit van de bedrijfsprocessen te waarborgen zal de IT-manager moeten leren integraal te denken. Hij moet de betekenis en het belang van de ICT-dienstverlening voor de operationele bedrijfprocessen herkennen en businessmanagers adviseren bij het inschatten van hun continuïteitsrisico’s en over de continuïteitsmaatregelen die zij moeten treffen. Wanneer hij vervolgens ook de juiste architecturen invoert en de afspraken met de business goed beheert is de organisatie een heel eind op weg naar continuïteit. Het is evident dat hiermee de taak van de ICT-manager aanzienlijk complexer is geworden en dat zijn werkzaamheden behoorlijk onder druk zijn komen te staan. 

7. Bedrijfscontinuïteit in de praktijk

In de praktijk komt Business Continuity Management (BCM) samengevat neer op het volgende:

• De doelstelling van Business Continuity Management (BCM) is, het voorkomen van ernstige onderbrekingen in de bedrijfsvoering en het beschermen van kritieke bedrijfsprocessen tegen gevolgen van omvangrijke (ver)storingen of calamiteiten.
• Het definiëren van de continuïteitsnormen voor bedrijfsprocessen en informatiesystemen is de verantwoordelijkheid van het businessmanagement.
• Het ligt niet langer voor de hand Business Continuity te beleggen bij de ICT-afdeling en de ICT-manager de eerst verantwoordelijke te maken.
• Van oudsher werd dit wel gedaan. Gezien echter enerzijds de betrouwbaarheid van de ICT-infrastructuur en anderzijds de opkomende andere risico’s, is dit niet meer een voor de hand liggende keuze. De enige reden is vaak nog, dat de ICT-afdeling voldoende ervaring heeft met projectmatig werken, zodat zij gemakkelijk in staat is zo’n project, dat uitbesteed wordt, aan te sturen namens de organisatie.
• Als u als organisatie goed om wilt gaan met bedrijfscontinuïteit, zult u projectmatig moeten komen tot een Business Continuity Plan (BCP), maar zal het beheer hiervan zodanig in de organisatie belegd moeten worden, dat het draaiboek ook werkt in geval van een calamiteit.
• Uit onderzoek blijkt dat drie op de vier organisaties die aandacht besteden aan BCM, hiervoor een directe aanleiding (incident of druk van een toezichthouder) nodig hebben gehad. Slechts één op de drie ondernemingen heeft een beheerproces ingericht voor haar continuïteitsplannen. En de meeste ondernemingen ten slotte voeren geen enkele controle uit op de afspraken die zij maken met derde partijen op het gebied van continuïteit.
• Cruciaal is de rol van het crisisteam; in veel gevallen geldt, dat een calamiteit pas een calamiteit is als het crisisteam hier het stempel van calamiteit op zet. Zo geldt voor de meeste echecs in de afgelopen jaren met een voor een bedrijf dodelijke afloop, dat de belangrijkste oorzaak was dat niet tijdig werd onderkend dat een incident een calamiteit was. Zorgt u er daarom vooral ook voor dat, onafhankelijk van waar leden van het crisisteam zich bevinden, crisisberaad altijd kan plaatsvinden. (Zie ook ‘Het virtuele crisiscentrum voor uw crisisteam’.)
• Wees bedacht op calamiteiten die u niet hebt voorzien, maar die uw bedrijf wel te gronde helpen richten. Het gaat daarbij meestal niet om directe schade, maar om indirecte schade. (Zie ook ‘Informatiebeveiliging: geen verantwoordelijkheid maar aansprakelijkheid!’.)
   

Delen van dit artikel zijn overgenomen uit: Steven Debets en Dick Leegwater,’Continuïteitseisen veranderen verantwoordelijkheid IT-manager’. In: Automatisering Gids. 31 maart 2006.

Download:         

Gerelateerde artikelen:

1. Plan bedrijfscontinuïteit MKB: wat, waarom en hoe
2. Inpassing Business Continuity BCP in BHV-plan, ICT en algemeen beleid veiligheid
3. Keuzes en aanpak voor uw Business Continuity Plan BCP of calamiteitenplan

1. Besturing Service Level Management 
2. Strategisch niveau: het Service Level Management
3. Tactisch niveau: het Service Level Management
4. Operationeel niveau: het Service Level Management
5. Voordelen van deze structuur

1. Besturing Service Level Management

Zoals in het artikel ‘Blauwdruk processen IT-organisatie’ beschreven wordt, gaat het bij Service Level Agreements om twee partijen die een overeenkomst sluiten. Omdat ITIL gericht is op de ICT-organisatie, wordt het proces Service Level Management belegd in de ICT-organisatie. Dat het niet meer van deze tijd is, dat de leverancier leading is in dit proces, spreekt vanzelf.  (Zie ook ‘Functioneel beheer en inkoop vaak bottlenecks in de ICT-leveringsketens’.) Het gaat erom dat in het Service Level Agreement overeengekomen wordt wat de klant wil.
Daarom maken we in dit artikel conform Looijen onderscheid tussen het proces Service Level Management, dat we beschouwen als onderdeel van het functioneel beheer, en het proces Service Management aan de kant van de ICT, dat verantwoordelijk is voor de levering van de diensten.
 
Het Service Level Management en het Service Management kennen drie niveaus van besturing, namelijk het strategisch, tactisch en operationeel niveau.

2. Strategisch niveau: het Service Level Management

Op strategisch niveau formuleren de drie Bedrijfsvoeringsfuncties (zie ‘Organisatie en inrichting functioneel applicatiebeheer’) Gebruiken, Onderhouden en Exploiteren tezamen met de opdrachtgever of eigenaar de algemene uitgangspunten voor de Bedrijfsvoering van de Informatievoorziening. Tevens vindt op dit besturingsniveau de afstemming op de langere termijn plaats tussen de evolutie van de bedrijfsprocessen en de daarvoor benodigde Informatievoorziening in het kader van het informatiebeleid. 
De hiervoor geschetste interactie op strategisch niveau leidt tot vaststellen van zogenaamde servicecontracten. Deze servicecontracten worden geëvalueerd aan de hand van opgeleverde contractrapporten. Dit gehele proces wordt ook wel contractmanagement genoemd.

2.1 Strategisch niveau: Servicecontract

In het servicecontract zijn door het Service Level Management de strategische afspraken vastgelegd. Dit zijn lange termijn afspraken. In een servicecontract zijn de kaders afgetekend waarbinnen de SLA’s voor de concrete dienstverlening dienen te passen. Een servicecontract is bindend voor alle partijen. Het taalgebruik zal daarom veelal juridisch van aard zijn.

2.2 Strategisch niveau: het Service Management

Het Service Management verzorgt op strategisch niveau het inrichtingsbeleid van de Gebruiksfunctie. Als uitgangspunt dienen hiervoor de afgesloten servicecontracten. Bij het inrichten van de Gebruiksfunctie komen de aspecten Organisatie, Personeel, Administratieve procedures, Financiën, Informatiebehoefte en Technische hulpmiddelen (OPAFIT) aan de orde. Regelmatig rapporteert het Service Management over de inrichting aan het Service Level Management middels beleidsrapportages.

2.2.1 Organisatie

De organisatie geeft weer hoe de Gebruiksfunctie georganiseerd is, welke functies er onderkend worden, hoe de communicatie verloopt en welke overlegstructuren er zijn. (Zie ook ‘Afbakening taken functioneel beheer baseren op behoefte’.)

2.2.2 Personeel

Ten aanzien van het personeel wordt aangegeven welke functionarissen er binnen de Gebruiksfunctie werkzaam zijn. Vervolgens wordt aangegeven welke taken, verantwoordelijkheden en bevoegdheden aan deze functionarissen worden toegewezen.
Tenslotte worden de functie-eisen geformuleerd, zoals ervaring, bekwaamheden en opleidingsniveau.

2.2.3 Administratieve procedures

Door middel van administratieve procedures wordt vastgesteld hoe activiteiten dienen te verlopen. Te denken valt dan bijvoorbeeld aan een wijzigingsprocedures, probleemafhandelingsprocedures, etc.

2.2.4 Financiën

Het aspect financiën beschrijft zaken als begrotingen, budgetten en de beschikbaarheid van financiële middelen voor de Gebruiksfunctie.

2.2.5 Informatiebehoefte

Voor het uitvoeren van de Gebruiksfunctie is informatie benodigd en komt er informatie beschikbaar. Binnen dit aspect wordt ingegaan op de structuur van deze informatie en de wijze waarop deze verwerkt wordt.

2.2.6 Technische hulpmiddelen

Het uitvoeren van processen binnen de Gebruiksfunctie vereist de beschikbaarheid van diverse hulpmiddelen. Hierbij dient gedacht te worden aan huisvesting, kantoormiddelen, communicatiemiddelen en automatiseringsmiddelen voor gebruik binnen de Bedrijfsfunctie. Daarnaast worden binnen dit aspect ook de hulpmiddelen en voorzieningen beschreven die nodig zijn om de functionaliteit en kwaliteit van de Informatievoorziening te waarborgen.

2.2.7 Overige aspecten

Naast de hiervoor genoemde aspecten kunnen hier, in het kader van het inrichtingsbeleid van de Gebruiksfunctie, ook nog andere aspecten beschreven worden, die voor de inrichting van belang geacht worden. Te denken valt bijvoorbeeld aan het aspect Public Relations. (Zie ook ‘Voor onvolwassen organisaties is een SLA een samenlevingscontract; de liefde regel je daar buiten’.)

2.2.8 Beleidsrapportage

De beleidsrapportage komt tot stand naar aanleiding van de evaluatie van het beleid. In deze rapportages dient tot uitdrukking te komen hoe de inrichting van de Gebruiksfunctie voldoet, de consequenties die deze inrichting heeft voor de totale Bedrijfsvoering en aanpassingen van het beleid die wenselijk geacht worden. In de rapportages zal aandacht besteed worden aan de OPAFIT aspecten:

• Organisatie: er wordt gerapporteerd over functies, overlegstructuren en communicatielijnen.
• Personeel: hier wordt gerapporteerd over aantallen en de wijze waarop kennis, ervaring en bekwaamheden van het personeel aansluiten op de uit te voeren activiteiten. 
• Administratieve organisatie: hier wordt gerapporteerd over hoe bepaalde procedures en besturingsactiviteiten aansluiten op andere Bedrijfsvoeringsfuncties en hoe efficiënt en effectief de gehanteerde procedures werken in de dagelijkse praktijk. 
• Financiën: hierbij wordt ingegaan op de bestedingen van de beschikbare financiële middelen. 
• Informatiebehoefte: er wordt aangegeven in hoeverre de gewenste informatie tijdig en op de juiste wijze voor de doelgroepen beschikbaar is.
• Technische hulpmiddelen: hier wordt vermeld hoe de huisvesting, gereedschappen en andere hulpmiddelen aansluiten bij de te verrichten werkzaamheden.
• Overige aspecten: hier kan gerapporteerd worden hoe deze inrichtingsaspecten ondersteunend zijn aan de te verrichten activiteiten.

3. Tactisch niveau: het Service Level Management

Het Service Level Management op tactisch niveau binnen de Gebruiksfunctie legt zich toe op het maken van afspraken met de andere Bedrijfsvoeringsfuncties. Deze afspraken hebben dan betrekking op de concrete dienstverlening. Uit het oogpunt van kwaliteitsbeheersing dient bij het maken van afspraken zoveel mogelijk gewerkt te worden met meetbare resultaten. De gewenste resultaten worden zoveel mogelijk gekwantificeerd in termen van aantallen, antwoordtijden, doorlooptijden, reactietijden, etc.
Voor de overeengekomen dienstverlening wordt bepaald welke activiteiten door de Gebruiksfunctie en welke door de Onderhouds- en Exploitatiefunctie moeten worden uitgevoerd. Deze activiteiten worden vastgelegd in een Service Level Agreement in combinatie met de op te leveren resultaten. 
Op tactisch niveau vindt eveneens de terugkoppeling plaats en worden de resultaten beoordeeld aan de hand van de gemaakte afspraken. Als invoer hiervoor dienen de Service Level Agreements (SLA’s) en de Service Level Reports (SLR’s). Deze evaluatie heeft tot doel dat de Gebruiksfunctie nagaat hoe de dienstverlening ervaren wordt. (Zie ook ‘ICT-service management: contact is belangrijker dan contract’.)
Tenslotte worden er op tactisch niveau afspraken gemaakt over belangrijke wijzigingen in de automatiseringsmiddelen en/of diensten.

3.1 Tactisch niveau: de Service Level Agreements

De Service Level Agreements beschrijven de gewenste dienstverlening en worden door het Service Management gebruikt voor het realiseren en toetsen van de daadwerkelijke dienstverlening. Het Service Management (SRM) zet de SLA’s om in serviceplannen, welke gehanteerd worden bij het bewaken en bijsturen van de daadwerkelijke uitvoering van de dienstverlening. Op grond van servicerapportages rapporteert het Service Management, middels Service Level Reports (SLR’s), over de resultaten aan het Service Level Management. Een Service Level Agreement omvat de volgende onderwerpen:

• inleiding met doel van het SLA, SLA-periode, ondertekenaars, beschrijving van de dienstverlening, achtergrond- en referentiedocumenten;
• verantwoordelijkheden en procedures met betrekking tot wijzigen, goedkeuren en verspreiden van het SLA, periodiek overleg en specifieke verantwoordelijkheden;
• configuratie: beschrijving van faciliteiten en ondersteuning met betrekking tot hardware, software en netwerk;
• beschrijving van het gebruik: onder dit onderwerp zal ook de omvang tot uitdrukking moeten komen;
• probleem- en wijzigingscoördinatie: locatie, openingstijden, procedures, afspraken en tevredenheidscriteria;
• detaillering van de serviceniveaus en de evaluatie ervan (meten en rapporteren): kwaliteitsattributen, zoals bijvoorbeeld betrouwbaarheid, continuïteit, snelheid en beschikbaarheid, worden verder gedetailleerd vastgelegd (zie ook ‘Testen volgens TMap, een korte introductie’);
• specifieke eisen: kritische applicatieonderdelen en -faciliteiten, piektijden en kritische tijdslijnen;
• beveiliging: vertrouwelijkheid, kopieerrechten, gegevensbeveiliging, softwarerechten, toegankelijkheid en virusdetectie en –preventie;
• afspraken inzake calamiteiten: veiligstellen van applicaties en gegevens, herstel na calamiteiten (zie ook ‘Keuzes en aanpak voor uw Business Continuity Plan BCP of calamiteitenplan’);
• contactpersonen;
• kwaliteitsverklaring;
• bijlagen.

De Service Level Agreements dienen te passen binnen het Servicecontract. De SLA’s zijn een verfijning en detaillering van het Servicecontract.

3.2 Tactisch niveau: het Service Management

Op tactisch niveau vertaalt het Service Management de Service Level Agreements in Serviceplannen. Het Serviceplan beschrijft altijd een afgebakende dienstverlening.
Deze beschrijving betreft dan de informatie, eisen, normen, grenswaarden en richtlijnen die voor de uitvoering van de verschillende processen binnen de Gebruiksfunctie noodzakelijk zijn.
Ook zal het Service Management, zodra er een wijziging of uitbreiding van een van de SLA’s plaats vindt, nagaan voor welke processen binnen de Gebruiksfunctie dit consequenties heeft.
Tenslotte worden door het Service Management aanvullende richtlijnen en normen vastgesteld, die niet direct afleidbaar zijn van afspraken in de SLA’s. Een voorbeeld hiervan zijn de richtlijnen welke vanuit de ARBO-wet worden vastgelegd.

3.3 Tactisch niveau: de Service Level Reports

In de Service Level Reports (SLR’s) wordt gerapporteerd over de wijze waarop aan de Service Level Agreements voldaan wordt. In de Service Level Reports kunnen de volgende onderwerpen aan de orde komen:

• overzicht van de uitvoering van de dienstverlening in relatie tot de SLA-afspraken; in de SLA’s staan metrieken en doelen vermeld; 
• in de SLR’s dient aangegeven te worden in hoeverre hieraan wel of niet voldaan is, wat er gedaan wordt om weer te voldoen aan de gestelde criteria of welke acties ondernomen worden om te blijven voldoen aan deze criteria;
• analyse van opgetreden incidenten en problemen, met vermelding van wat er gedaan wordt om deze incidenten en/of problemen te voorkomen, dan wel sneller te verhelpen;
• analyse van de doorgevoerde wijzigingen, waarbij in gegaan kan worden op de reden van de wijziging, ondervonden moeilijkheden tijdens het invoeringstraject en het uiteindelijke resultaat;
• een overzicht van extra (niet door te belasten) werkzaamheden;
• een overzicht van extra dienstverleningsactiviteiten die wel in rekening gebracht zullen gaan worden, maar waarover wel in principe overeenstemming is bereikt.

4. Operationeel niveau: het Service Level Management

Op operationeel niveau worden binnen de Gebruiksfunctie werkafspraken gemaakt en werkprocedures vastgesteld. De afspraken op operationeel niveau kunnen bijvoorbeeld vastgelegd worden in een dossier Afspraken en Procedures. Werkafspraken zijn afspraken voor de dagelijkse werkzaamheden .

4.1 Operationeel niveau: het Service Management

Het Service Management draagt op operationeel niveau zorg voor de dagelijkse besturing. De werkafspraken vanuit het operationeel Service Level Management worden omgezet in planningen, procedures en richtlijnen voor de dagelijkse gang van zaken.
Aan de hand van de uitvoeringsrapportages toetst het Service Management deze planningen, procedures en richtlijnen aan de werkafspraken en stuurt bij daar waar dat nodig blijkt.
Het Service Management rapporteert over de dagelijkse gang van zaken aan het Service Level Management door middel van werkrapportages.
In deze werkrapportages dient tot uitdrukking te komen hoe aan de werkafspraken voldaan is en welke moeilijkheden daarbij ondervonden werden.
Op deze wijze kan het Service Level Management daaruit lering trekken voor de toekomstige werkafspraken.

4.2 Afspraken met andere bedrijfsvoeringsfuncties

De Gebruiksfunctie maakt afspraken met de Onderhouds- en de Exploitatiefunctie. De afspraken die gemaakt worden hebben betrekking op servicecontracten, SLA’s en de werkafspraken. De afspraken die met derden gemaakt worden, zijn meestal in de vorm van onderhouds- en/of leveringscontracten.
Het tot stand brengen van alle afspraken en het rapporteren daarover op de verschillende besturingsniveaus is een ingewikkeld proces, want de taakgebieden van de Bedrijfsvoeringsfuncties worden in organisaties vaak bij diverse functionarissen en organisatie-eenheden belegd. 
Zo kan de Gebruiksfunctie meerdere gebruikersgroepen omvatten, die ieder een of meerdere delen van de Informatievoorziening gebruiken en waarbij de wensen van de gebruikersgroepen met betrekking tot de gewenste dienstverlening verschillend kunnen zijn. Een extra complicatie doet zich voor wanneer deze gebruikersgroepen zich ook nog op geografisch verschillende locaties bevinden.
Ook de Onderhoudsfunctie kan verdeeld zijn over meerdere organisatorische onderhoudseenheden, bijvoorbeeld een Afdeling Systeemontwikkeling, Systeem- of netwerkprogrammeurs of een onderhoudsdienst van een leverancier.
De Exploitatiefunctie kent ook een diversiteit aan verschijningsvormen. Zo kunnen er meerdere Exploitatie-eenheden of organisaties binnen (of buiten) een bedrijf voorkomen.
Bijvoorbeeld: een centraal Reken-, Communicatie- en Servicecentrum, een Afdeling LAN-beheer, een Technische Dienst, etc. Elke Exploitatie-eenheid of -organisatie kan voor een specifiek deel van een bedrijf de Exploitatie verzorgen. Hoe groter de diversiteit aan organieke eenheden is, hoe moeilijker en complexer de communicatiestructuur tussen deze eenheden wordt.

5. Voordelen van deze structuur

Bovenstaand model zal in de praktijk natuurlijk een invulling moeten krijgen. Met name de invulling van de operationele processen wordt vaak uitbesteed aan de ICT-afdeling en daar is op zich ook niet op tegen, mits de ICT-afdeling zich dan realiseert dat zij in dat geval moet optreden als het Project Management of Service Management voor de operatie, waarbij mogelijk diverse interne en/of externe uitvoerders ingeschakeld kunnen worden.
Voordeel van deze structuur is dat op tactisch niveau verantwoordelijkheden helder belegd kunnen worden bij de partijen die daar het meest geëquipeerd voor zijn. Op deze wijze valt ook outsourcing goed te beheersen en aan te sturen. (Zie ‘ICT en functioneel beheer steeds meer logistieke processen’.)
Doel van Service Level Management is tenslotte het verhogen van de kwaliteit van de dienstverlening, waarvoor gezien de steeds sneller veranderende business eisen en technologische mogelijkheden de nodige flexibiliteit vereist is.
Als het SLA slechts tot doel heeft om paaltjes te slaan en elkaar de schuld te kunnen geven, dan ontstaat een starheid, die de dienstverlening niet ten goede komt en waardoor de samenwerking verslechtert.
Juist doordat ITIL Service Level Management als een tactisch proces aanduidt en de koppeling met andere processen vaak te zwak is, zien we dit echter in de praktijk vaak wel optreden bij organisaties die ITIL gebruiken.

Herziene versie 7 maart 2010

Download:         

Gerelateerde artikelen:

1. Assessment ICT Service Level Management
2. BiSL maakt functioneel beheer wel erg ingewikkeld
3. Afbakening taken functioneel beheer baseren op behoefte

1. Communicatie met de ICT-afdeling?
2. Is de ICT-afdeling eigenlijk wel schuldig?
3. Moeten gebruikers verstand van ICT krijgen?
4. Samenwerking gebruikers en ICT-afdeling
5. Het gif dat ITIL en SLA heet 
6. Samenwerken door ook functioneel beheer

1. Communicatie met de ICT-afdeling?

Ongetwijfeld kunt u zich vinden in de stelling, dat er geen bedrijfsmiddel op aarde is, dat zoveel ergernis oproept als uw PC.
Net als u bezig bent met uw werkzaamheden, loopt u weer aan tegen een vastloper of tegen foutmeldingen van uw PC of printer die u niet begrijpt, of krijgt u de melding van de ICT-afdeling, dat u vanwege onderhoud de ICT-voorzieningen een tijd niet kunt gebruiken. De tijd dat u in zo’n geval de helpdesk belde, ligt al ver achter u; niet alleen dat deze slecht bereikbaar was, meestal snapte u alleen de vraag, ‘wat is uw naam’ en op de overige vragen die aan u gesteld werden, wist u doorgaans het antwoord niet en u wilde het ook niet weten. Communicatie met ICT’ers is vaak een groot probleem. Eind van het liedje was in veel gevallen dat u het advies kreeg om uw PC uit te zetten en vervolgens weer aan en dat dan het probleem verholpen zou zijn. Deze boodschap heeft u intussen ongetwijfeld opgepikt en voor u de helpdesk belt, zet u nu al standaard uw PC uit en weer aan en zuchtend voert u opnieuw de gegevens in, die u hierdoor bent kwijt geraakt. Hier hebt u de helpdesk tenslotte niet voor nodig, maar het kost u wel tijd en uw baas dus geld.
En ondanks dat u weet dat u niet meer zonder ICT kunt, baalt u van uw ICT-afdeling met haar slechte service.

2. Is de ICT-afdeling eigenlijk wel schuldig?

Misschien is het goed om eens te kijken naar de rol, die uw ICT-afdeling tegenwoordig speelt.
Ze bouwt geen hardware, maar koop die in bij fabrikanten. In tegenstelling tot vroeger bouwt ze geen software maar koopt die in bij Microsoft, SAP, Exact etc.  En als uw ICT-medewerkers hulp inroepen bij de helpdesk van deze bedrijven, dan krijgen ze meestal niet de antwoorden die u wilt hebben, omdat ze onvoldoende uw probleem kennen. Bovendien worden zij ook van het kastje naar de muur gestuurd door de leveranciers van de hardware en de software.
Het is zelfs onwaarschijnlijk dat de aanschaf van de software die u gebruikt een besluit is van uw ICT-afdeling.

Kortom, om ervoor te zorgen dat ICT-oplossingen voor u gaan werken, zult u na moeten denken over uw relatie met de ICT-afdeling. De ICT-afdeling is de afgelopen jaren steeds meer opgeschoven naar de rol van intermediair tussen u als klant en externe leveranciers. Wil zij die intermediairrol naar al die externe partijen goed kunnen invullen, dan zullen uw ICT-medewerkers exact moeten weten wat u op bedrijfsniveau wilt.

3. Moeten gebruikers verstand van ICT krijgen?

Natuurlijk wilt u geen verstand van ICT krijgen, want daar hebt u niet voor doorgeleerd en bovendien staat het niet in uw functieomschrijving. Dat zou net zo onlogisch zijn, als dat u een monteursdiploma zou moeten hebben omdat u in een auto rijdt of een wasmachine gebruikt.
Maar als u met een monteur praat over de problemen met uw auto of met uw wasmachine, dan kunt u hem wel duidelijk maken wat u wilt, zodat hij er voor kan zorgen dat u weer tevreden bent over de auto of de wasmachine. En als u een nieuwe auto of wasmachine wilt hebben, dan bent u uitstekend in staat om uw eisen te formuleren aan de verkoper, zodat u de auto of wasmachine krijgt, die aan uw verwachtingen voldoet.
Toegegeven, bij ICT ligt dit vaak iets complexer, omdat de oplossing bestaat uit meerdere componenten. Voorts praten we hierover een minder volwassen bedrijfstak met nog veel softwareleveranciers, die juist graag afwijken van standaards om de klant afhankelijk te maken.
Natuurlijk is het voor u onmogelijk om in deze jungle succesvol te opereren en dat moet u ook niet willen. Juist de ICT-afdeling zou hierin uw partner moeten zijn, zodat u een goed gebruik kan maken van de rijkdommen die deze jungle biedt.

4. Samenwerking gebruikers en ICT afdeling

In het verleden heeft een wildgroei plaatsgevonden, die er toe geleid heeft, dat de communicatie tussen gebruikers en automatiseerders verstoord is en dat de partijen meer bedacht zijn op indekken dan op samenwerken.
Dat is begonnen toen de techniek nog zo complex was, dat je als gebruiker blij mocht zijn als de automatisering in elk geval ook dingen opleverde die functioneerden. Later kwamen methoden in zwang als SDM, Prince II en ITIL en in feite waren deze methoden meer gericht op het elkaar met recht de schuld kunnen geven als er iets fout liep, dan op een effectieve samenwerking.

Voor een effectieve samenwerking tussen de gebruiker als klant en de ICT-afdeling als intermediair is het nodig dat beide partijen hun verantwoordelijkheid nemen. (Zie ‘Blauwdruk processen IT-organisatie’.) Dat betekent niet dat de uitvoering niet kan worden uitbesteed, maar wel dat helder moet zijn, dat de gebruikersorganisatie verantwoordelijk is voor haar rol als opdrachtgever en voor het functioneel beheer. En een zeer belangrijke rol voor de ICT-afdeling is het adviseren van de gebruikers en de vertaling van hun functionele eisen naar technische specificaties, die zij vervolgens ook namens de gebruikers technisch kunnen beheren. Niet de gebruikers moeten de vragen stellen, maar de ICT-afdeling, want zij is de intermediair. En uiteraard moeten dat geen technische vragen, zijn maar vraagstellingen naar de behoefte van de gebruikersorganisatie. Want juist die behoefte van de gebruikersorganisatie moet het uitgangspunt zijn voor het inkopen en beheren van oplossingen bij externe leveranciers. En om te voorkomen dat uw ICT-afdeling gek gemaakt wordt met individuele gebruikerseisen, is de inrichting van functioneel beheer voor de aansturing van de ICT-afdeling als intermediair, van groot belang.  Zij moet tenslotte de infrastructuur beheren voor alle gebruikers binnen uw organisatie. Daarom is het eveneens van groot belang dat zij ook een regulier aanspreekpunt heeft in de gebruikersorganisatie, om te voorkomen dat de ICT-afdeling beslissingen moet nemen over gebruikerswensen die mogelijk infrastructurele gevolgen hebben.
Als de ICT-afdeling moet inspelen op wensen van individuele gebruikers, dan is het risico groot dat zij acties gaat ondernemen, die veel andere gebruikers gaan schaden en waar ze vervolgens dan ook nog eens de schuld van krijgt.

5. Het gif dat ITIL en SLA heet

Het grote probleem dat de communicatie tussen gebruikers en de ICT-afdeling blokkeert, is de ITIL-methodiek, die ruim 20 jaar geleden is opgesteld en nog uitgaat van een aanbodgedreven ICT-service. (Zie ‘Begrafenis ITIL is begin van herstel ICT-imago’.)
Vooral voor het proces service level management en de op te stellen service level agreements gaat ITIL ervan uit dat de ICT-afdeling een dienstencatalogus aanbiedt aan de gebruikers. Hiermee wordt dienstverlening in feite gedegradeerd tot een product dat je kunt kopen en hiermee wordt zeker niet tegemoet gekomen aan de behoeften van gebruikers enerzijds en aan de professionaliteit en flexibiliteit die de meeste ICT afdelingen kunnen bieden, anderszijds. Uitgangspunt moet dus niet zijn de dienstencatalogus, maar de behoeften van de klant, samengebracht in een goed georganiseerd functioneel applicatie beheer. (Zie ‘Service Level Management en Service Management functioneel beheer’.) Dit functioneel beheer zal ook de budgetten moeten beheren voor investeringsvoorstellen en wijzigingsvoorstellen. Zolang deze bewaakt moeten worden door de ICT-afdeling, zal de ICT-afdeling in veel gevallen als rechter moeten optreden en ontstaat er dus een voor alle partijen onhoudbare situatie, die per definitie tot problemen leidt.

Helaas is de praktijk in veel organisaties nog, dat het proces service level management wordt ingevuld door de ICT-afdeling en niet door de functioneel beheerders, die de behoeftestellers zijn in service level agreements en die uiteindelijk als klant moeten beslissen welke service en dienstverlening ze willen afnemen.
Hetzelfde geldt voor het proces wijzigingsbeheer. Per definitie is het de beslissing van de klant en dus van het functioneel beheer of een wijziging al dan niet moet plaatsvinden, waarbij het niet uitmaakt wie de initiator is van dit wijzigingsvoorstel. En dit betreft niet alleen technische wijzigingen, het kan zelfs het SLA beïnvloeden, waarbij de aanbieder, ofwel de ICT-afdeling, kan aangeven wat de impact en de kosten van dit wijzigingsvoorstel zijn. (Zie ook ‘Inrichtingsmodel IT-beheer’.)

6. Samenwerken door ook functioneel beheer

Dat de beslissingsvoorbereiding en de uitvoering van veel activiteiten, voortvloeiend uit de verantwoordelijkheid voor het functioneel beheer liggen bij de ICT-afdeling, hoeft geen enkel probleem te geven. Wel is het cruciaal dat de gebruikersorganisatie zijn verantwoordelijkheid neemt voor het functioneel applicatie beheer. (Zie ‘Organisatie en inrichting functioneel applicatiebeheer’.)
Dan kan de samenwerking tussen twee gelijksoortig ingerichte organisaties met duidelijke verantwoordelijkheden en aanspreekpunten gestalte krijgen.

Download:         

Gerelateerde artikelen:

1. Support samenwerking gebruikers en ICT-afdeling
2. Functioneel beheer van ICT-gebruik en gebruikers
3. BiSL maakt functioneel beheer wel erg ingewikkeld

1. Inleiding
2. Bedrijfsvoering van informatievoorziening
3. Organisatiemodellen van het functioneel applicatiebeheer
4. Slotopmerking

1. Inleiding

Het functioneel applicatie beheer 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 moet worden wie wat uitvoert. Aandacht voor het beleggen van verantwoordelijkheden is echter wel van belang. (Zie ook ‘Blauwdruk processen IT-organisatie’.)

Wij hopen dat deze artikelen u als functioneel beheerder, business manager of gebruiker handvatten bieden om de communicatie en samenwerking met de ICT-afdeling te verbeteren en om structuur aan te brengen in uw behoeften.

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 applicatie beheer’.

Dit artikel schetst de organisatie van de inrichting van het functioneel beheer volgens Looijen.

2. Bedrijfsvoering van informatievoorziening

Het beheer van informatievoorziening is in veel organisaties nog steeds een onderontwikkeld gebied; in het algemeen krijgt het niet de aandacht die het zou moeten krijgen. Naarmate de automatiseringsgraad in een organisatie groter wordt, neemt de noodzaak van een goed geregeld beheer van informatievoorziening toe. Voor vele bedrijven en organisaties wordt het dan ook hoog tijd om ernst te maken met het systematisch regelen van het beheer van informatievoorziening. De risico’s die men loopt als dit niet goed geregeld is, worden steeds groter. Zo groeit bijvoorbeeld de kans dat medewerkers op grote schaal langs elkaar heen zullen werken. Contacten met leveranciers en automatiseringsdeskundigen zullen niet duidelijk gekanaliseerd zijn, met als gevolg dat nergens een goede opbouw van het kennisbeheer gerealiseerd kan worden. In vele gevallen zal zelfs het overzicht over de aanwezige apparatuur, programmatuur, gebruikers en overige middelen verloren gaan. Het invoeren en naleven van standaards voor producten zal dan ook erg moeilijk blijken te zijn. En tenslotte wordt het verhogen van de beveiligingsgraad van informatiesystemen een bijna onmogelijk zaak. Als men deze zaken goed wil aanpakken, zullen alle betrokkenen precies moeten weten wat de beheerprocessen en de hieraan verbonden taken en verantwoordelijkheden zijn. Het goed organiseren van het beheer van informatievoorziening is een complex proces met een lange doorlooptijd.

2.1 Bedrijfsvoering

Voor vele bedrijven en organisaties is het planmatig werken een algemeen geaccepteerd uitgangspunt. Elk bedrijf kent wel een vorm van beleid en formuleert bedrijfsdoelen op grond waarvan de feitelijke bedrijfsvoering plaats vindt. Binnen de bedrijfsvoering zijn besturende, ondersteunende en uitvoerende processen herkenbaar. Binnen de besturende processen worden plannen gemaakt op basis van het geformuleerde bedrijfsbeleid en de vastgelegde bedrijfsdoelen. De ondersteunende processen omvatten het beheer van de bedrijfsmiddelen, zoals bijvoorbeeld personeel en kapitaal.

Daarnaast worden ook de algemene bedrijfsondersteunende processen, zoals een juridische dienst of een bedrijfskantine, hiertoe gerekend. Binnen de uitvoerende processen vinden de bedrijfsactiviteiten plaats die de gestelde bedrijfsdoelen en opgestelde plannen trachten te realiseren.

Deze algemene opdeling in besturende, ondersteunende en uitvoerende processen wordt ook in het beheer van informatievoorziening toegepast. Wanneer we echter spreken over ‘het beheer van informatievoorziening’, dan valt dat daaruit niet direct af te leiden.
Daarom is het ook veel beter te spreken over de ‘Bedrijfsvoering van informatievoorziening’. Dit begrip zal in het vervolg van dit artikel dan ook veelvuldig gehanteerd worden. Wanneer in dit artikel gesproken wordt over het onderwerp ‘Bedrijfsvoering’, dan wordt hier ‘Bedrijfsvoering van Informatievoorziening’ bedoeld.

2.2 De besturingscyclus: PUC-cyclus

Om de uitvoerende processen binnen de Bedrijfsvoering gecontroleerd en beheerst te doen laten verlopen, wordt de PUC-cyclus gehanteerd. In deze cyclus wordt binnen de besturende processen een onderscheid gemaakt tussen planning en control.

De planning omvat:

• het vaststellen van de te verrichten activiteiten met hun onderlinge prioriteitsstelling;
• het vaststellen van cruciale succesfactoren en de prestatie-indicatoren die een succesvolle realisatie van doelstellingen en plannen bewerkstelligen;
• het vaststellen van de voor de te verrichten activiteiten benodigde tijd (doorlooptijden, normtijden, inzettijden) en andere normen;
• het vaststellen van de voor de activiteiten benodigde middelen.

De uitvoering omvat:

• het realiseren van de binnen de planning opgenomen plannen.

De control omvat:

• het kennisnemen van het vastgestelde beleid en de doelstellingen en het bewaken van de realisatie daarvan;
• het meten van de plannen en van het verloop van de uitvoering;
• het analyseren van de afwijkingen in de uitvoering ten opzichte van de plannen;
• het afgeven van basisinformatie en stuursignalen voor het bijsturen in de uitvoering en het eventueel bijstellen van de plannen.

Binnen de Bedrijfsvoering van Informatievoorziening is het planmatig werken nog niet een algemeen geaccepteerd uitgangspunt. Dat geldt met name voor het functioneel applicatiebeheer. Werkt men op het gebied van Bedrijfsvoering van Informatievoorziening niet planmatig, dan betekent dit dat men niet over ijkpunten beschikt waarmee de efficiëntie en effectiviteit van de ondersteunende en uitvoerende processen gemeten kunnen worden. Een gerichte (bij)sturing is dan ook niet goed mogelijk. De Bedrijfsvoering van Informatievoorziening wordt dan een zwalkend schip dat nimmer zijn beoogde doel bereikt.

2.3 Plaats van functioneel applicatiebeheer binnen bedrijfsvoering

Naast de besturende, ondersteunende en uitvoerende processen kunnen we ook drie Bedrijfsvoeringsfuncties onderscheiden, namelijk Gebruiken, Onderhouden en Exploiteren.
De besturende processen van de Bedrijfsvoering zijn Service Level Management (SLM) en Service Management (SRM). Het Service Level Management omvat het afstemmen en vastleggen van afspraken, het doen realiseren van de Informatievoorziening volgens die afspraken (Service Management) en het zorgdragen voor het nakomen van deze afspraken. Service Level Management en Service Management verzorgen dus de planning en control van de Bedrijfsvoering voor het Gebruiken, het Onderhouden en het Exploiteren.
Binnen de ondersteunende processen wordt het Beheer van Middelen genoemd. Daarnaast kunnen ook Algemene Bedrijfsondersteuningsprocessen, zoals juridische zaken, personeelszaken e.d., hiertoe gerekend worden. Beheer is, in het kader van kwaliteitsbeheersing, essentieel. Daarom is het Beheer van Middelen in iedere bedrijfsvoeringsfunctie terug te vinden. Binnen Gebruiken heet het Gebruiksbeheer, binnen Onderhouden wordt het Onderhoudsbeheer genoemd en binnen Exploiteren heeft het de benaming Exploitatiebeheer verkregen.
De uitvoerende processen bestaan uit het onderhoud van middelen, het beschikbaar houden van middelen, het verrichten van handelingen en het begeleiden.
Het functioneel applicatiebeheer kan gepositioneerd worden onder de bedrijfsvoeringsfunctie Gebruiken.

2.4 Opdeling procesvelden voor het functioneel applicatiebeheer

Allereerst zien we dat het Service Level Management en het Service Management de besturende processen zijn van het functioneel applicatiebeheer. Binnen het Service Level Management worden ook afspraken gemaakt en overeenstemmingen gesloten met de andere Bedrijfsvoeringsfuncties.

Om een duidelijk beeld te kunnen vormen van de overige processen binnen het functioneel applicatiebeheer, dienen we het allereerst het ondersteunende proces Gebruiksbeheer verder uit te werken.
Het Gebruiksbeheer omvat het Beheer van Middelen. Dit zijn de middelen welke een rol spelen bij de bedrijfsvoeringsfunctie Gebruiken. Welke middelen worden er dan bedoeld en wat dient er dan zoal beheerd te worden? Met middelen worden de (automatiserings)middelen ten behoeve van de Informatievoorziening bedoeld. Dit zijn (handmatige delen van) informatiesystemen, gegevensinfrastructuren, technische infrastructuren en fysieke voorzieningen. Deze middelen worden gebruikt, zijn aan veranderingen onderhevig, dienen zoveel mogelijk continue en storingvrij beschikbaar te zijn, moeten beveiligd worden tegen misbruik en behoren zo optimaal als mogelijk aan te sluiten bij (steeds veranderende) behoeften, eisen en wensen van gebruikers. Vanzelfsprekend dient dit alles op een financieel verantwoorde wijze te geschieden.
Tenslotte onderkennen we binnen het uitvoerende proces Direct Gebruik nog twee procesvelden, namelijk: gebruikshandelingen en gebruiksbegeleiding. Deze procesvelden worden in onderstaand schema beschreven.

 Dit schema wordt verder uitgewerkt in het artikel ‘Operationele processen functioneel applicatiebeheer’.

3. Organisatiemodellen van het functioneel applicatiebeheer

De Bedrijfsvoeringsfunctie Gebruiken kan het Onderhoudsbeheer uitbesteden aan de Bedrijfsvoeringsfunctie Onderhouden en het Exploitatiebeheer uitbesteden aan het Exploiteren.
Het Gebruiksbeheer (functioneel applicatiebeheer) moet de processen binnen het Gebruiken echter altijd zelf blijven uitvoeren. Dit vanwege de verantwoordelijkheid, de materiekennis en de kennis van de eigen gebruikersorganisatie die ermee gemoeid zijn.

Een eerste voorwaarde voor een effectief management van het functioneel applicatiebeheer is een herkenbare organisatiestructuur. Deze organisatiestructuur ontstaat in de meeste gevallen geleidelijk met het toenemen van de automatiseringsgraad van de Gebruiksfunctie.
In het eerste stadium zien we dat oorspronkelijk de beheerprocessen belegd zijn op een aantal plaatsen in de bestaande organisatie dicht bij de gebruikers, of bij de gebruikers zelf.
In het tweede stadium nemen vervolgens de omvang van die beheerprocessen en de automatiseringsgraad van de Gebruiksfunctie toe. Men ziet dan dat de beheerprocessen worden geclusterd en leiden tot aparte organieke eenheden voor het functioneel applicatiebeheer binnen elke afdeling die informatiesystemen gebruikt.
Het derde stadium in dit groeiproces is dat men de decentrale organieke beheereenheden in de verschillende afdelingen gaat coördineren op bedrijfsniveau. Dan ontstaan ook centrale eenheden voor het beheer van de bedrijfsgegevens en het functioneel applicatiebeheer. Daarnaast zijn er ook andere instanties op bedrijfsniveau die, vanuit hun eigen verantwoordelijkheid, bepaalde beheerprocessen verrichten. Te denken valt bijvoorbeeld aan een interne accountantsdienst met betrekking tot het Kostenbeheer of een organisatieafdeling die zich bemoeit met de handmatige procedures van het informatiesysteem.
De coördinatie van al deze beheereenheden hoort thuis op directieniveau. Het NGI noemt het directielid dat verantwoordelijk is voor het strategisch management van de totale informatievoorziening de ‘Informatiemanager’.

In hoofdlijnen zijn er drie organisatievormen van het functioneel applicatiebeheer binnen de gebruikers organisatie te onderscheiden:

• de kleine, of beginnende, beheerorganisatie;
• de sterk gespreide, decentrale beheerorganisatie;
• de beheerorganisatie met centrale staf.

3.1 De kleine, of beginnende, beheerorganisatie

In een kleine, of beginnende, beheerorganisatie zien we vaak dat de afdelingsmanager het Service Level Management en het Service Management op operationeel niveau uitvoert.
Van SLM en SRM op strategisch en tactisch niveau is haast geen sprake.
In de meeste gevallen is er één functioneel applicatiebeheerder die een deel van de processen van Gebruiksbeheer en Direct Gebruik, naast het gewone werk, voor zijn of haar rekening neemt. Welke processen dat zijn verschilt per organisatie. Vaak worden de uit te voeren processen bepaald door de problemen en werkzaamheden die het meest urgent aangepakt moeten worden, zoals bijvoorbeeld Gebruiksbegeleiding, Wijzigingsbeheer of Probleembeheer.

3.2 De sterk gespreide, decentrale beheerorganisatie

Bij een sterk gespreide beheerorganisatie ligt het zwaartepunt op de decentrale beheereenheden binnen de afdelingen. Er kunnen wel centrale beheerfuncties voor komen, maar de communicatie en coördinatie zijn niet strak geregeld.
Mogelijke centrale beheerfuncties zijn: de informatiemanager, de gegevensdefinitiebeheerder en een interne accountant. Het Service Level Management en Service Management op strategisch niveau zijn dan belegd bij de informatiemanager.
Decentrale beheerfuncties zijn: de afdelingsmanager en de functioneel applicatiebeheerder. De afdelingsmanagers verzorgen het Service Level Management en het Service Management op tactisch niveau.
In een gespreide beheerorganisatie zitten alle functioneel applicatiebeheerders op de afdelingen. Hun werkzaamheden bestaan ondermeer uit enkele processen welke binnen de Algemene Bedrijfsondersteuning geplaatst kunnen worden, zoals bijvoorbeeld het administratief beheer of kwaliteitsbewaking, en processen binnen het Gebruiksbeheer en het Direct Gebruik. Voorts verzorgen de functioneel applicatiebeheerders het Service Level Management en Service Management op operationeel niveau.
Deze functioneel applicatiebeheerders vormen de kern van de gespreide beheerorganisatie, te meer daar zij ook de inhoud van alle gegevensverzamelingen beheren. Omdat zo’n allround functioneel applicatiebeheerder minder gespecialiseerd is, zal er een sterke neiging bestaan om zoveel mogelijk functioneel onderhoud uit te besteden aan de Onderhoudsfunctie.

3.3 De beheerorganisatie met centrale staf

Bij een beheerorganisatie met een centrale staf worden binnen de Gebruiksfunctie de volgende beheereenheden onderkend:

• de informatiemanager:
  het directielid wat verantwoordelijk is voor het totale informatiebeleid: hier is het Service Level Management en Service Management op strategisch niveau belegd.
• centraal functioneel gegevensbeheer:
  de groep centraal functioneel gegevensbeheer verricht een deel van de processen binnen het Specificatiebeheer op bedrijfsniveau, namelijk het inhoudelijk beheer van de bedrijfsgegevens en het gegevensdefinitiebeheer: besturende processen die zich op dit niveau bevinden spelen zich af binnen het Service Level Management en Service Management op tactisch niveau.
• centraal functioneel applicatiebeheer:
  deze groep coördineert de samenwerking tussen de decentrale eenheden, zoals het decentraal functioneel beheer, de Onderhoudsfunctie, de Exploitatiefunctie en het centraal functioneel gegevensbeheer: besturende processen die zich op niveau bevinden spelen zich af binnen het Service Level Management en Service Management op tactisch niveau.
• overige stafafdelingen verantwoordelijk voor bepaalde beheerprocessen:
  dit zijn centrale instanties die, in het verlengde van hun eigen taak, ook bepaalde beheerprocessen uitvoeren: met name de interne accountant, een eventuele organisatieafdeling en het opleidingsaspect binnen personeelszorg spelen hier een duidelijk rol.
• Decentraal functioneel beheer:
  de groepen decentraal functioneel beheer zijn verantwoordelijk voor de processen binnen het Gebruiksbeheer en Direct Gebruik.: besturende processen die zich op niveau bevinden spelen zich af binnen het Service Level Management en Service Management op operationeel niveau.

4. Slotopmerking

In de artikelen 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 leiden tot een permanente stiptheidsactie.

Via het reactieformulier kunt u zich opgeven voor het bijwonen van een gratis webseminar over dit onderwerp, vragen stellen of ons verzoeken u een telefonisch advies te geven.

Download:         

Gerelateerde artikelen:

1. Operationele processen functioneel applicatiebeheer
2. Documentatie functioneel applicatiebeheer
3. Groepstraining on the job: integratie functioneel en technisch beheer en applicatiebeheer

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 moet 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 e.d. Wij hanteren in de artikelen consequent het begrip ‘functioneel applicatie beheer’.

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 haar 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 die wijziging die noodzakelijk is naar aanleiding van de afwijking of 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 kan belegd zijn bij het (centraal) functioneel applicatiebeheer.

2.4 Afhandelen van wijzigingsverzoeken

Het wijzigingsverzoek gaat naar het Wijzigingsbeheer van de Onderhoudsfunctie. Deze 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 de 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. De Helpdesk kan daarnaast uitgebreid worden met het aannemen en coördineren van wijzigingsvoorstellen. 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 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 denken we met betrekking tot het functioneel applicatiebeheer in de eerste plaats 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 en systeemsoftware. Tenslotte zijn er ook nog specificaties in 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 moeten 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 dienen te worden. Van belang is dat de registratie overeenkomstig met 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 zijn 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 dient tevens zorg te dragen dat het optreden van problemen voorkomen wordt.
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 en initiëren van het afhandelen van een probleem;
• 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 probleem geïdentificeerd en geregistreerd. Daarbij worden allerlei gegevens vastgelegd, zoals aanmelder, aanmeldtijdstip, tijdstip dat het incident of probleem zich voordeed, plus alle relevante gegevens om het incident of 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.

Met impactbepaling wordt bedoeld 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, deel uitmaken van of identiek zijn aan het configuratie-item waar het probleem op van toepassing is.

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 voortgang vindt.
 
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 onderkennen van mogelijke problemen. Een mogelijk probleem wordt beschreven in een probleemrapport.
 
Een probleemrapport registreren:
Het probleemrapport registreren voor verdere voortgangsbewaking.
 
Prioriteit toekennen:
Vervolgens wordt het probleem een prioriteit toegekend (zie ook paragraaf 3.4.1).

Toewijzingen:
Vervolgens wordt het probleem toegewezen aan een specialist, een team van specialisten of aan de leverancier, die voor verdere analyse van het probleem zorg draagt.
 
Herziening van de toewijzing:
Indien nodig vindt er een herzien 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 probleem naar tevredenheid verholpen en opgelost is. Zodra de aanmelder tevreden is met de oplossing van het incident of probleem, kan het betrokken incident of probleem afgesloten worden.

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.
Anderzijds kan het ook 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 kan het aannemen en bewaken van voortgang van incidenten, problemen en afwijkingen 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 kan 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 inzake 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 mochten 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 het 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, 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.

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 onderscheid 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, kennis en ervaring van de personen die de handelingen uitvoeren.

9.2 Evalueren van de werkwijze bij direct gebruik

Periodiek wordt 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 leiden tot een permanente stiptheidsactie.

Via het reactieformulier kunt u vragen stellen of ons verzoeken u een telefonisch advies te geven. Via het aanmeldingsformulier kunt u zich opgeven voor het bijwonen van een gratis webseminar over dit onderwerp.

Download:         

Gerelateerde artikelen:

1. Organisatie en inrichting functioneel applicatiebeheer
2. Documentatie functioneel applicatiebeheer
3. ICT en functioneel beheer steeds meer logistieke processen

1. Inleiding
2. Waarom documenteren?
3. De organisatie van het beheren van documentatie
4. Documentatiebeleid
5. Het documentatieplan
6. Overzicht van te beheren documentatie
7. Nawoord

1. Inleiding

Een informatiesysteem kent vele aspecten en vormt hierdoor een complex geheel. Deze mate van complexiteit betekent dat niemand dit geheel in zijn totaliteit nog kan overzien. Meerdere mensen bezitten kennis van bepaalde onderdelen van een informatiesysteem, doordat zij betrokken waren bij het verstrekken van de opdracht die leidde tot de systeemontwikkeling. Anderen hebben deze kennis omdat zij betrokken zijn (geweest) bij de systeembouw, invoering en/of het gebruik en beheer van dit informatiesysteem. Bepaalde kennis over het informatiesysteem neemt af naarmate de tijd voortschrijdt. Ook gaat kennis over het informatiesysteem verloren omdat mensen de organisatie verlaten.
Teneinde een informatiesysteem optimaal te gebruiken en beheren is het noodzakelijk dit informatiesysteem van haver tot gort te kennen. Daarom moet dus vanaf het prille begin alle kennis gestructureerd worden vastgelegd, zodat deze niet verloren gaat. Het meest gebruikte hulpmiddel om deze kennis gestructureerd vast te leggen en gedoseerd te verspreiden is documentatie. (Zie ook ‘Operationele processen functioneel applicatiebeheer’.)
In dit artikel meer over het gestructureerd opzetten van de documentatie van een informatiesysteem. Wij trachten hierin volledig te zijn, zodat u alleen hoeft te schrappen. Uitgangspunt is het maatwerksysteem. Als het gaat om een standaardpakket, dan kunt u hierin fors schrappen.

1.1 De functie van documentatie

Documentatie is het informatiesysteem ten behoeve van de informatievoorziening. Zonder documentatie is een efficiënte en effectieve bedrijfsvoering niet realiseerbaar. Alleen een goede documentatie kan continuïteit en overdraagbaarheid inzake het informatiesysteem garanderen. Hierbij is het van belang onderscheid te maken naar documentatiesoorten. Het doel waarvoor de documentatie wordt aangewend (hardware onderhoud, softwareonderhoud) speelt hierbij een essentiële rol. Risico’s bij het documenteren zijn ongewenste overlap, verschillende documentatiestandaards en inconsistentie in de afzonderlijk documentatieonderdelen.
Fouten in de documentatie zijn destructief voor de bedrijfsvoering. Daarom moet ervoor gezorgd worden dat de documentatie aan bepaalde kwaliteitseisen voldoet, zowel ten aanzien van de structuur en als ten aanzien van de inhoud. Ten aanzien van de structuur kunnen de volgende eisen gesteld worden:

• Toegankelijkheid
  De documentatie moet overzichtelijk en logisch zijn opgebouwd.
• Lokaliseerbaarheid
  Het moet duidelijk zijn waar welk onderwerp te vinden is.
• Consistentie
  De documentatie mag geen innerlijke tegenstrijdigheden bevatten.
• Onderhoudbaarheid
  De documentatie moeten op economisch verantwoorde wijze te onderhouden zijn.

Ten aanzien van de inhoud gelden de volgende eisen:

• Juistheid
  De documentatie moet correct zijn.
• Actualiteit
  De status van de documentatie moet parallel lopen met de status van het informatiesysteem.
• Volledigheid
  In de documentatie mogen geen `witte vlekken` aanwezig zijn.
• Nauwkeurigheid
  De documentatie moet over een op het gebruiksdoel afgestemde nauwkeurigheid bezitten.
• Controleerbaarheid
  De documentatie moet met gemak op juistheid en volledigheid te controleren zijn.

Om aan al deze kwaliteitseisen te kunnen voldoen, moet documentatie beheerd worden. Daarom valt documentatie als configuratie-item binnen het configuratiebeheer.
Het beheren van de documentatie als configuratie-item houdt een scala van activiteiten in, die er zorg voor dragen dat de kennis omtrent een informatiesysteem gestructureerd wordt vastgelegd en voor iedereen toegankelijk is.

2. Waarom documenteren?

Het op gestandaardiseerde wijze documenteren geschiedt om een aantal redenen, waarvan de voornaamste hier genoemd worden. De documentatie is:

• een hulpmiddel bij het informeren van het management over de bedrijfsvoering;
• een hulpmiddel ten behoeve van de communicatie; management, eigenaars, gebruikers, ontwikkelaars, accountants, beheerders enzovoort dienen elkaar geïnformeerd te houden.
• een ondersteuning voor specialistische taken; bij het hier bedoelde type document gaat het om aspecten als:
  • beschrijving van het informatiesysteem;
  • beschrijving van de werking van het informatiesysteem;
  • beschrijving van de samenhang tussen de systemen en systeemonderdelen;
  • de specificaties van de kwaliteitsnormen;
  • beschrijving van de beveiliging;
  • beschrijving van de gebruikte handmatige routines.
• een leermiddel bij het opleiden van eindgebruikers (gebruikershandleiding en/of bedieningshandleiding);
• een hulpmiddel voor het afleggen van verantwoording (verificatie tegen de normen) en het meten van de voortgang (documentatie is meetbaar en controleerbaar).

Door de documentatie up-to-date te houden, wordt voorkomen dat een applicatie op de duur uitgroeit tot een onbeheersbaar en ongeleid projectiel voor de organisatie. (Zie ook ‘Organisatie en inrichting functioneel applicatiebeheer’.)

3. De organisatie van het beheren van documentatie

De organisatie rondom het deelgebied documentatie kan grofweg in twee vormen worden opgezet, te weten:

• centraal,
• decentraal.

Bij centralisatie worden alle activiteiten ten behoeve van het documenteren door één persoon (de documentalist) gecoördineerd.
Bij decentralisatie worden de activiteiten ten aanzien van documentatie ondergebracht bij diverse personen (met hun diverse taken) binnen de organisatie. Voor beide vormen geldt als eerste vereiste dat de eigenaars van de producten bekend moeten zijn. Dit is nodig in verband met het toewijzen van het wijzigingsrecht. Vervolgens moeten taken worden toegewezen, zoals wie controleert of wie verifieert. Ten behoeve van de documentatie moeten ook de communicatiestructuur en de rapportagelijnen vastgesteld worden. Bovendien moeten er procedures ontworpen worden ten behoeve van de updating en verstrekking van de documentatie.

3.1 Centraal georganiseerd documentatiebeheer

Deze organisatievorm verdient de voorkeur boven de decentrale vorm. Er is dan één instantie (één team of één persoon) die verantwoordelijk is voor alle documentatie van een (deel van een) informatiesysteem. Dit team of deze persoon vormt dan een stafafdeling of staffunctionaris die ten dienste staat van alle betrokkenen bij de informatievoorziening, zoals gebruikers, beheerders en managers.
De taken van deze stafafdeling of functionaris ressorteren onder het taakgebied configuratiebeheer. Deze centrale documentatiebeheerders dienen een bibliothecaire opleiding gevolgd te hebben met als specialisatie documentalist. Pas in tweede instantie is een automatiseringsopleiding gewenst. Door met deze specialisten te werken kan de kwaliteit van de documentatie, alsmede de kwaliteit van het beheren van de documentatie, beter gewaarborgd worden. Ten eerste omdat namelijk dan voor iedereen in de organisatie duidelijk is hoe men iets over documentatie te weten moet komen en bij welke contactfunctionaris men moet zijn om, met honderd procent zekerheid, de meest recentelijk bijgewerkte documentatie te verkrijgen. Ten tweede is het eenvoudiger in deze organisatiestructuur te controleren of de documentatie aan de gestelde normen en criteria voldoet. De documentalisten zijn uiteraard niet direct voor de inhoud van de documentatie verantwoordelijk. Deze verantwoordelijkheid blijft bij de deskundigen, die aan de bron van een (documentatie)product staan. Wel zal de documentalist periodiek opdrachten moeten verstrekken aan andere deskundigen dan de opsteller van een document om de inhoud te beoordelen.
De documentalisten werken aan de hand van het door het service management geformuleerde documentatiebeleid een documentatieplan uit. In dit documentatieplan staan onder andere de projectplannen van de projecten die noodzakelijk zijn om de documentatie toegankelijk, lokaliseerbaar, consistent, onderhoudbaar, juist, volledig, actueel, nauwkeurig en controleerbaar te houden of te krijgen.

3.2 Decentraal georganiseerd documentatiebeheer

Deze organisatievorm van het documentatiebeheer vinden we in de meeste organisaties terug. Althans bij onderzoek hiernaar geven de meeste organisaties op dat het beheer van documentatie op deze wijze georganiseerd is. In weinig gevallen echter bleek bij deze organisaties een concreet documentatieplan aanwezig, of documentatiebeleid geformuleerd te zijn. Wat we zien is dat sommige beheerders de beschikking hebben over, vaak verouderde, projectdocumentatie. De overige documentatie is vaak opgesteld door en ten dienste van een beheerder van een deelgebied van het informatiesysteem. Zo heeft een netwerkbeheerder vaak de situatie wel op papier staan, maar of dit toegankelijk is voor andere medewerkers in de organisatie is nog maar de vraag.
Hetzelfde geldt in het algemeen voor de onderhoudprogrammeurs, systeemprogrammeurs, functioneel applicatiebeheerders en vele andere functionarissen. De kennis zit voornamelijk in het hoofd met op papier wat reminders. Van een gestructureerd kennis/documentatiebeheer is slechts in weinig bedrijven sprake!

4. Documentatiebeleid

Documentatiebeleid dient, als integraal bestanddeel van het kwaliteitsbeleid, gebaseerd te zijn op de volgende uitgangspunten.Het moet:

• kunnen resulteren in een gedetailleerd documentatieplan;
• expliciete vermelding geven van de toe te passen documentatietechnieken en te gebruiken standaards;
• aansluiten op de gestelde kwaliteitseisen.

De bovengenoemde criteria spreken voor zich. Documentatiekwaliteit kan immers alleen worden verkregen als de validiteit van de informatievoorziening te allen tijden kan worden gegarandeerd. Voor de vereiste kwaliteit van documentatie kunnen vier niveaus worden onderscheiden:

• minimale documentatie (voor slechts een bepaald gebruiksdoel, met daarin een korte beschrijving van het systeem of programma, sourceprogrammalistings en  testgegevens);
• interne documentatie (behalve voor een specifiek doel ook voor een specifieke gebruiker, zodat naast de inhoud van de minimale documentatie bij deze documentatie veel commentaar in de programmalistings is opgenomen, om de gebruiker behulpzaam te zijn bij de invoering en het gebruik van de programma’s);
• werkdocument (te gebruiken door verschillende personen in dezelfde organisatie en tevens te gebruiken in andere organisaties);
• formele publicatie (voor grote en complexe organisaties, die voor algemeen gebruik zijn bestemd en waaraan redactioneel dus hoge eisen worden gesteld vanwege de ’status’)

Bij de implementatie van het documentatiebeleid worden ten aanzien van de kwaliteit standaardeisen gesteld, die in de vorm van voorschriften of richtlijnen moeten worden vastgelegd.

5. Het documentatieplan

Het documentatieplan stelt ons in staat de activiteiten ten behoeve van het documenteren planmatig uit te voeren. Hierdoor zal het documenteren efficiënter en effectiever verlopen. Het documentatieplan kan bestaan uit:

• standaards en richtlijnen ten behoeve van het documenteren;
• de kwaliteitseisen van de documenten;
• de formele documentatieactiviteiten;
• de beschikbare of benodigde middelen (budget, personeel en tijd);
• een lijst met bestaande producten;
• een lijst met eigenaars van producten;
• een lijst met producten in ontwikkeling;
• een lijst met aanvragen voor producten;
• een lijst met verzoeken tot wijzigingen;
• een verzendlijst per product;
• een planning voor het vervaardigen en onderhouden van producten;
• projectplannen ten behoeve van de documentatie.

5.1 Projecten ten behoeve van documentatiebeheer

Projecten die ten behoeve van het documentatiebeheer ingericht kunnen worden zijn projecten ter controle van de juistheid, volledigheid, actualiteit, nauwkeurigheid, controleerbaarheid, toegankelijkheid, consistentie, lokaliseerbaarheid en onderhoudbaarheid van de documentatie. Tenslotte bestaat ook de mogelijkheid projecten te organiseren ter wijziging en verspreiding van en ter informatie over documentatie.

5.2 Stappenplan ten behoeve van documentatie

Teneinde de documentatie te laten voldoen aan de kwaliteitseisen ten aanzien van de structuur en de inhoud is hier een stappenplan aan activiteiten opgesomd:

• Stel een documentatieplan op.
• Inventariseer welke producten beschikbaar zouden moeten zijn.
• Inventariseer welke producten beschikbaar zijn.
• Geef opdracht om de niet aanwezige benodigde documentatie te vervaardigen.
• Controleer de documentatie op geformuleerde kwaliteitseisen.
• Draag zorg voor het configuratiebeheer.
• Verzamel en analyseer verzoeken tot wijziging.
• Geef opdracht om de documentatie bij te werken (wijzigen).

6. Overzicht van te beheren documentatie

Om enig overzicht te verkrijgen over de te beheren documentatie en deze op een werkbare wijze te structureren, kan men gebruik maken van de indeling naar documentatiesoorten gecombineerd met een meersporenmodel voor het groeperen van activiteiten van systeemontwikkeling (figuur 1).
De motivatie voor het hanteren van een dergelijk model komt voort uit het feit dat de meeste documentatie ontstaat als product van systeemontwikkeling. De gehanteerde figuur kan opgevat worden als een ontwikkelmodel en dient per project nader verbijzonderd te worden, waarbij eventuele extra afhankelijkheden (zoals interacties tussen de sporen) worden aangebracht. De figuur laat zien dat informatiesystemen ontwikkeld behoren te worden vanuit een informatiebeleid. Op dit informatiebeleid wordt de informatieplanning gebaseerd. Deze informatieplanning houdt het opstellen van een aantal samenhangende plannen in (met verschillende horizonten) ten behoeve van de ontwikkeling van de informatievoorziening De feitelijke ontwikkeling van een informatiesysteem loopt van een definitiestudie tot en met de invoering. Na het basisontwerp worden verschillende werkzaamheden naast elkaar uitgevoerd. Uiterst rechts in het meersporenmodel staat de bouw van de (geautomatiseerde) applicatie afgebeeld.

Figuur 1: Verdeling projectverantwoordelijkheden

Deze kan eventueel per deelsysteem worden uitgevoerd. Dit spoor bestaat uit het detailontwerp van de applicatie, de bouw en de systeem(integratie)test. Indien een gegevensconversie moet worden uitgevoerd, dient de voorbereiding van de conversie vroegtijdig plaatst te vinden. Uiterst links staan de activiteiten die dienen te worden uitgevoerd door organisatiedeskundigen. Als eerste wordt hier de organisatorische inrichting uitgevoerd. Vervolgens worden de handmatige onderdelen van het informatiesysteem vastgelegd in handmatige procedures. Tevens wordt er voor gezorgd dat de programmatuur op de organisatie aansluit. Tenslotte volgt de voorbereiding op de invoering van het gehele (geautomatiseerde plus handmatige)informatiesysteem. Ten behoeve van de opleiding van toekomstig uitvoerend personeel en andere betrokkenen wordt een opleidingsplan opgesteld. Daarna worden cursussen gerealiseerd en worden de betrokkenen opgeleid.
Het middelste spoor geeft de voorbereiding van de acceptatietest aan. Deze activiteiten houden niet alleen het opzetten van de acceptatietest in, maar ook andere algemene zaken zoals voorlichting en overleg met de ondernemingsraad.
De parallel lopende sporen komen tenslotte weer samen voor de feitelijke invoering, die pas kan volgen na een proefconversie en acceptatie, en na de ‘echte’ conversie van de oude gegevens. Het meersporenmodel legt vervolgens de basis voor een indeling van de te beheren documentatie
Het beeld wordt volledig als de producten van projectdocumentatie en de beheerdocumentatie toegevoegd worden aan de groepen van producten van systeemontwikkeling. Nu er groeperingen van producten zijn ontstaan, kan bepaald worden uit welke concrete producten deze groepen bestaan.

6.1 Producten van projectdocumentatie

Plannen:

• plan van aanpak basisontwerp;
• bijgewerkt systeemontwikkelingsplan;
• plan van aanpak detailontwerp;
• testplannen;
• plan voor realisatie en invoering;
• plan van aanpak voor realisatie.

Rapporten:

• rapport basisontwerp;
• functioneel ontwerprapport;
• technisch ontwerprapport;
• rapport detailontwerp;
• rapport over realisatie, conversie en invoering;
• eindrapport invoering en overdracht.

6.2 Producten van bedrijfsanalyse en informatieanalyse

• dossier informatiebeleid;
• informatieplan;
• rapport definitiestudie.

6.3 Producten van het ontwerp van informatiesystemen

Dossiers:

• ontwerp van informatiefuncties;
• functionele gegevensdefinities;
• extern interface;
• gebruikersinterface;
• technisch applicatieontwerp;
• technische gegevensdefinities;
• implementatieanalyse;
• technische infrastructuur.

6.4 Producten van het bouwen van applicaties

• definitie van fysieke opslagstructuur;
• definitie van fysieke schermafbeeldingen;
• programmadossier;
• dossier systeem(integratie)test;
• testset systeem(integratie)test;
• geteste programma’s;
• verwerkingsgang voor productie.

6.5 Producten in verband met gegevensconversie

• rapport gegevensconversie;
• geconverteerde gegevens.

6.6 Producten in verband met organisatorische inrichting

• dossier ontwerp van de organisatorische inrichting;
• (re)organisatieplan;
• dossier handmatige procedures.

6.7 Producten in verband met acceptatie

• dossier acceptatietest gebruiksfunctie;
• testset acceptatietest gebruiksfunctie;
• rapport acceptatietest exploitatiefunctie;
• rapport acceptatietest onderhoudsfunctie.

6.8 Producten in verband met opleiding

• opleidingsplan;
• cursussen;
• dossier opgeleide medewerkers.

6.9 Producten in verband met invoering c.q. migratie

• invoeringsplan of een migratieplan.

6.10 Producten in verband met bedrijfsvoering

• handleidingen voor gebruikers;
• handleiding voor het applicatieonderhoud;
• gebruikersregistratie;
• apparatuurregistratie;
• documentatieregistratie;
• storingsmeldingen;
• probleemrapportendossier;
• testresultaten;
• analyse rapporten;
• Handleiding voor productie;
• onderhoudsplan;
• gebruiksregistratie;
• softwareregistratie;
• gegevensregistratie;
• wijzigingsdossier;
• beheerprocedures;
• evaluatierapporten;
• logboeken;
• financiële en urenregistratie.

 7. Nawoord

Het lijkt natuurlijk enorm veel, maar omdat de meeste software tegenwoordig hoofdzakelijk bestaat uit reeds bestaande software, ligt een groot deel van deze belasting bij de ICT-leverancier en zal dit via SLA’s geregeld moeten worden. (Zie ook ‘Service Level Management en Service Management functioneel beheer’.) Wel is het zaak om deze leveranciersdocumentatie ook daadwerkelijk te testen op gebruikswaarde en hiervoor normen af te spreken in het SLA.

Download:         

Gerelateerde artikelen:

1. Organisatie en inrichting functioneel applicatiebeheer
2. Operationele processen functioneel applicatiebeheer
3. Groepstraining on the job: integratie functioneel en technisch beheer en applicatiebeheer