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:

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:

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. (Zie ook ‘Zeven tips voor het inkopen van ICT-projecten’.) 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. 

Oorspronkelijke versie: 16 augustus 2009
Herziene versie: 10 maart 2010

Download:       

No related posts.

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 strategische, het tactische en het operationele 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 het 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 nodig en komt informatie beschikbaar. Binnen het aspect  informatiebehoefte 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 moet gedacht 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 rapportage moeten tot uitdrukking 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 niets 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, als er iets misgaat, 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 dikwijls wel optreden bij organisaties die ITIL gebruiken. Daarom hebben we recent voor situaties met externe ICT-leveranciers een artikel opgenomen met best practices: ‘Tips voor een begrijpelijk SLA of ICT-contract’.

Oorspronkelijke versie: 16 november 2005. Herziene versie 7 maart 2010.

Download:       

No related posts.

1. Gebruikers zijn ongeleide projectielen
2. Gebruiksbegeleiding
3. Gebruikerstevredenheidmeting
4. Conclusie

1. Gebruikers zijn ongeleide projectielen

Voor ICT’ers zijn gebruikers vaak als een stuk zeep in een gevulde badkuip: elke keer als ze denken dat ze er vat op hebben, glipt het hen weer uit de vingers. Enerzijds moeten ICT’er beseffen dat ICT niet het middelpunt van het heelal is, maar omgekeerd zullen gebruikers ervan doordrongen moeten raken, dat zij voorspelbaar moeten zijn als ze een adequate ICT-dienstverlening willen. Dat impliceert dat er meer beperkingen gelden dan voor een PC thuis. Als daar wat fout gaat, is het vaak een kwestie van ‘Nou, jammer dan’. Maar binnen een bedrijf zou vrijheid voor elke individuele gebruiker aanzienlijke gevolgen hebben voor de risico’s en voor de beheerskosten.
In het artikel ‘Organisatie en inrichting functioneel applicatiebeheer’ is een framework neergelegd voor adequate dienstverlening, dat verder uitgewerkt is in het artikel ‘Operationele processen functioneel applicatiebeheer’.
In dit artikel gaan we dieper in op het beheer van het gebruik en de gebruikers.

Het uitvoerende proces Direct Gebruik kan binnen de Gebruiksfunctie opgedeeld worden in de procesgebieden Gebruikshandelingen en Gebruiksbegeleiding.

1.1 Verrichten van handelingen

Het procesgebied ’verrichten van handelingen’ omvat alle handelingen die te maken hebben met het verkrijgen, gebruiken en verwerken van informatie. Hiervoor zullen procedures en handleidingen beschikbaar moeten zijn, die aangeven op welke wijze en in welke volgorde handelingen verricht dienen te worden.

1.2 Begeleiden

Het procesgebied ‘begeleiden’omvat alle processen die nodig zijn om functioneel van de Informatievoorziening gebruik te kunnen maken. Een informatiesysteem kan immers nooit efficiënt of effectief zijn als er geen of foutief gebruik van wordt gemaakt.

De effectiviteit van een informatiesysteem is te meten aan de hand van de volgende berekening:

De kwaliteit van het informatiesysteem vermenigvuldigd met de acceptatiegraad van de gebruikers ( E = K * A ).
 
Deze formule geeft aan dat het belang van het procesgebied Direct Gebruik groot is voor de effectiviteit van een informatiesysteem. De moeilijkheidsgraad van de uitvoerende processen Gebruikshandelingen en Gebruiksbegeleiding is grotendeels afhankelijk van de situationele factoren waarin de Informatievoorziening zich bevindt. Zo is de uitvoering van de Gebruiksbegeleiding in een omgeving met weinig gebruikers en zonder geografische spreiding aanzienlijk eenvoudiger dan die in een omgeving die bestaat uit duizenden gebruikers die over meerdere locaties verspreid zijn.

2. Gebruiksbegeleiding

Het proces Gebruiksbegeleiding is niet eenvoudig. Vaak wordt er een dringend beroep gedaan op de communicatieve vaardigheden, het geduld, de tact en het inlevingsvermogen van de begeleider. Bovendien bestaat Gebruiksbegeleiding uit een grote verscheidenheid aan processen, zoals:

• het coördineren van gebruikerseisen;
• het accepteren en in bedrijf nemen van wijzigingen;
• het registreren van gebruikers en het autoriseren van het gebruik van informatiesystemen en (bedrijfs)gegevens;
• het instellen van parameters, eventueel apart voor verschillende (groepen) gebruikers;
• het vastleggen en voorschrijven van codestelsels;
• het up-to-date houden van algemene (bedrijfs)gegevens;
• het geven van instructie, voorlichting en het initiëren van opleidingen of cursussen; 
• het ad-hoc verstrekken van informatie.

2.1 Het coördineren van gebruikerseisen

De totale kosten van geautomatiseerde informatiesystemen bestaan voor meer dan de helft uit kosten die gemaakt worden gedurende de operationele fase. Er worden in die fase niet alleen kosten gemaakt voor het opsporen en verbeteren van fouten, maar ook voor aanpassingen ten behoeve van veranderende gebruikerseisen. Deze gebruikerseisen moeten worden gecoördineerd, want  als iedere gebruiker zijn wensen en eisen persoonlijk kenbaar zou maken aan de Onderhouds- of Exploitatiefunctie, zou een onwerkbare situatie ontstaan. Daarom moeten alle eisen vanuit de Gebruiksfunctie op een bekend aanmeldpunt aangeleverd worden. Dit aanmeldpunt is dan het functioneel applicatiebeheer.
Het functioneel applicatiebeheer beoordeelt de eisen onder andere op consistentie: de verschillende wijzigingen en uitbreidingen mogen niet in conflict zijn met elkaar. Daarna wordt een wijzigingsvoorstel samengesteld op grond waarvan uiteindelijk de wijzigingscommissie een beslissing neemt. Aandachtspunten voor het coördineren van gebruikerseisen zijn:

• inventarisatie en coördinatie van gebruikerseisen die gaan over wijzigingen en uitbreidingen;
• eventueel zelf initiëren van wijzigingen;
• beoordelen van wensen op uitvoerbaarheid en urgentie; 
• opstellen tijd- en kostenraming;
• wijzigingen uitwerken en toelichten voor beslissende instanties;
• zorgen voor aanpassingen in gebruikersdocumentatie en procedures;
• samenstellen testsets en beoordelen testresultaten;
• gebruikers instrueren in systeemwijzigingen.

2.2 Registratie van gebruikers

Om een goede begeleiding te kunnen geven is het noodzakelijk te weten wie de gebruikers van een informatiesysteem zijn. Uit onderzoeken is gebleken dat het in de meeste organisaties niet duidelijk is wie de eigenaars van de informatiesystemen zijn. Daardoor is het moeilijk, zo niet onmogelijk, om eenduidig vast te stellen wie van de informatiesystemen gebruik mogen maken. Meestal zal het organisatieonderdeel waarvoor het systeem ontwikkeld is, het ook daadwerkelijk gaan gebruiken. Maar zodra andere organisatieonderdelen er weet van krijgen dat er een informatiesysteem bestaat dat ook voor hen van belang kan zijn, zullen zij aansluiting zoeken. Op zich lijkt dit niet relevant. Maar in de praktijk is gebleken dat deze ‘verstekelingen’ tussen de gebruikers ook wensen kenbaar gaan maken. Bij het inwilligen van deze wensen is het zeker niet ondenkbaar dat er een verschuiving plaatsvindt van doelstellingen van het informatiesysteem. Het informatiesysteem kan zo steeds minder effectief worden voor de gebruikers waarvoor het in eerste instantie was ontwikkeld. Uiteindelijk kan het gebeuren dat de groep oorspronkelijke gebruikers, als enige groep binnen de organisatie, geen behoefte meer heeft het systeem te gebruiken.
Maar hoe dan ook, eens komt er voor iedere gebruiker een einde aan het gebruik van een systeem. Dit kan bijvoorbeeld zijn door de komst van nieuwe informatiesystemen of nieuwe werkwijzen. De beheerders moeten hiervan op de hoogte worden gebracht. Daarmee  wordt voorkomen dat er nog allerlei investeringen in het informatiesysteem worden gedaan, die niet meer zinvol zijn (efficiëntieverlies).
Verder zijn er verschillende soorten gebruikers te onderscheiden. Er zijn gebruikers die het informatiesysteem dagelijks gebruiken en gebruikers die dat slechts incidenteel doen(bijvoorbeeld het management). Ook toeleveranciers van gegevens zijn gebruikers, die niet noodzakelijk effectief van het informatiesysteem gebruik hoeven te maken. Daarnaast is er nog het onderscheid tussen ervaren (vaste medewerkers) en onervaren gebruikers (uitzendkrachten).
Door dit alles is het verstandig de gebruikers en het gebruik te registreren. Op basis van de geregistreerde gegevens kan men immers beter gefundeerde besluiten nemen over het informatiesysteem en de juiste gebruikers op de juiste wijze begeleiden.

2.3 Autorisatie van gebruikers

De uiteenlopende gegevensbestanden, gegevensgroepen of gegevenselementen mogen meestal alleen maar door daartoe geautoriseerde personen worden gebruikt (raadplegen, wijzigen, verwijderen, toevoegen). Dit is bij batchverwerking redelijk te waarborgen met behulp van een aantal eenvoudige organisatorische maatregelen binnen de Exploitatiefunctie. Deze maatregelen zijn onder meer:

• schriftelijk autoriseren van alle verwerkingsopdrachten;
• instellen van een afzonderlijke functie voor het beheer van gegevensbestanden;
• controle op de verslaglegging van het computergebruik.

Daarnaast kan men er in speciale gevallen nog voor zorgen dat de medewerkers van de Exploitatiefunctie geen kennis kunnen nemen van de uitvoer van het verwerkingsproces.
Vanzelfsprekend zijn de gebruikers verantwoordelijk voor een eventueel noodzakelijke geheimhouding, nadat de uitvoer de Exploitatiefunctie heeft verlaten.
Bij het on-line werken op terminals en/of personal computers die bij gebruikers staan, is het risico op ongeautoriseerd gebruik van gegevens groter. Daarom moet er een procedure worden ontworpen om degene die de terminal of personal computer gebruikt, te kunnen identificeren. Uit een dergelijke identificatie kan worden afgeleid of en in hoeverre deze gebruiker zijn geautoriseerd voor het gebruik van bepaalde applicaties en gegevens. Ook in dit geval is een controle achteraf van de verslaglegging van het computergebruik van grote waarde. Misbruik wordt hierdoor dan wel niet voorkomen, maar in ieder geval wel gesignaleerd.
Bescherming van de persoonlijk levenssfeer (privacy) maakt het noodzakelijk om waterdichte voorzieningen te treffen.
Voor gebruikesr is het vaak storend, dat ze niet kunnen beschikken over alle door hen gewenste gegevens. Zij zien een beperking van hun autorisaties vaak als een persoonlijke aanval. Maar het is desondanks niet aan te raden gebruikers zonder meer  te autoriseren. Als een gebruiker ontevreden is over de aan hem verleende autorisaties, is het verstandig om in een breed perspectief duidelijk te maken waarom het noodzakelijk is deze beperkingen op te leggen.

2.4 Het up-to-date houden van algemene (bedrijfs)gegevens

Om de algemene (bedrijfs)gegevens up-to-date te houden, moeten ze worden bewaakt op integriteit, betrouwbaarheid, (on)geautoriseerd gebruik en actualiteit. Verder moeten ze periodiek geschoond worden.

2.5 Het verzorgen van voorlichting

Er bestaat een Nederlands gezegde dat luidt: ‘Wat de boer niet kent, dat eet hij niet’. De essentie van dit gezegde gaat ook op voor de gebruikers van een informatiesysteem. Men kan rationeel gezien een kwalitatief nog zo goed systeem hebben ontwikkeld, als dit niet voldoende wordt geaccepteerd en de motivatie om het te gebruiken ontbreekt, dan zal het nooit goed functioneren.
Acceptatie en motivatie voor gebruik verbeteren door voldoende en tijdige voorlichting. De eerste voorlichting over het systeem moet al tijdens het haalbaarheidsonderzoek worden gegeven. Het is daarbij heel belangrijk dat verwachte problemen op een open en eerlijke manier behandeld worden. Onverwachte problemen verontrusten meer dan problemen waarop men is voorbereid. Verder moeten de positieve aspecten niet worden overdreven. Verwachtingen die niet waargemaakt kunnen worden, doen meer kwaad dan goed. In het algemeen worden systemen immers geëvalueerd overeenkomstig de verwachtingen die zijn gewekt.
Voorlichting kan op verschillende manieren worden gegeven, bijvoorbeekd door:

• bijeenkomsten en vergaderingen;
• het uitgeven van schriftelijke mededelingen of een gebruikersmagazine;
• persoonlijke gesprekken;
• exposities;
• een voorlichtingsmarkt;
• films, video-opnames en dergelijke.

Het is aan te bevelen de voorlichtingsactiviteiten te integreren met de overige voorlichtingsactiviteiten binnen de organisatie. Vaak is het verstandig om er professionele hulp bij  in te schakelen.

2.6 Opleiden van de gebruikers

Alle gebruikers die een opleiding nodig hebben, moeten deze kunnen krijgen, zodat:

• eventuele ongerustheid wordt weggenomen;
• voldoende kennis wordt bijgebracht;
• voldoende vaardigheden worden verkregen.

Het is altijd zaak om de opleidingen voor gebruikers tijdig te verzorgen. Als een nieuw informatiesysteem ingevoerd wordt binnen een organisatie, ontstaan nieuwe taken en/of worden reeds bestaande gewijzigd. Hiervoor moet nieuw personeel worden aangetrokken of het aanwezige worden omgeschoold.
Aan het opleiden van personeel moet dus aandacht worden geschonken tijdens de fase Invoering van een informatiesysteem. Opleidingen kunnen worden gegeven door interne en/of externe opleidingsfunctionarissen, eventueel ondersteund en geadviseerd door medewerkers van het projectteam. Leden van het projectteam kunnen ook zelf (een deel van) de opleidingen voor hun rekening nemen.
Het is belangrijk dat de opleiding praktisch is en erop gericht medewerkers efficiënt en effectief te laten functioneren. Dit betekent ondermeer dat men zoveel mogelijk gebruik moet maken van workshops waarbij medewerkers met behulp van prototypes of speciale opleidingsversies van het ontwikkelde systeem, praktische ervaring kunnen opdoen. Deze opleidingen kunnen daarbij ook als doel hebben te controleren of:

• het ontwikkelde systeem voldoende gebruiksvriendelijk is;
• de gebruikersdocumentatie compleet en leesbaar is;
• verwachte problemen op de juiste wijze worden opgelost.

Alle noodzakelijke verrichtingen voor (het verzorgen van) opleidingen moeten vooraf worden vastgelegd in een opleidingsplan. Dit opleidingsplan moet onderdeel zijn van een opleidingsplan op hoger niveau. Bij het opzetten van het plan moet rekening worden gehouden met de verschillende soorten doelgroepen binnen de gebruikersorganisatie. Er kan bijvoorbeeld onderscheid worden gemaak tussen invoerverzorgers, dagelijkse gebruikers, incidentele gebruikers en gebruikers die een aantal beheeractiviteiten verrichten. Er bestaat dus een grote verscheidenheid in gebruik. Dat betekent ook dat de vereiste kennis en gewenste opleidingen nogal verschillen. Een persoon kan daarbij in meerdere categorieën voorkomen.
In elk organisatiedeel moeten de medewerkers die opgeleid moeten worden, tijdig worden aangewezen en vrijgemaakt. De algemene oriëntatiecursussen kunnen meestal beter door externe opleiders gegeven worden, terwijl interne medewerkers bij voorkeur (indien mogelijk) de specifieke cursussen, gericht op het gebruik van het nieuwe informatiesysteem, verzorgen.
Men mag verder niet vergeten dat deze laatste soort opleidingen min of meer een continu proces zal vormen, omdat zowel de medewerkers als het nieuwe systeem van functie (kunnen) veranderen.

2.7 Ad hoc informatieverstrekking

Het ad hoc verstrekken van informatie betreft onder andere het verstrekken van kopieën of selecties van (bedrijfs)gegevens aan gebruikers die daartoe geautoriseerd zijn. Dit wordt ook wel ‘copy management’ genoemd. Daarnaast omvat het ook het samenstellen van éénmalige (adhoc) rapportages uit de (bedrijfs)gegevens.

2.8 Contact functionarissen

Een van de eisen die gesteld moeten worden om te komen tot een effectieve ondersteuning van gebruikers is een eenduidige communicatiestructuur. Niets is zo frustrerend voor een gebruiker als een ondoorzichtige communicatiestructuur en bureaucratie. De gebruikers hebben graag een aanspreekpunt dat altijd bereikbaar is op dezelfde plaats en via een vast telefoonnummer. Dit onderdeel van gebruiksbegeleiding is als een van de weinige in de praktijk vaak al goed georganiseerd. In veel bedrijven zijn hiervoor organisatorische eenheden zoals de Helpdesk en/of het informatiecentrum in het leven geroepen .

2.9 Gebruikersoverleg

Het is een goede zaak om de gebruikers van een informatiesysteem regelmatig met elkaar te confronteren. Dit heeft als voordeel dat zij elkaar kunnen stimuleren in het effectief gebruiken van het informatiesysteem. Hiertoe kunnen zowel intern als extern ‘user groups’en overlegorganen worden gevormd, die al dan niet beslissingsbevoegdheden hebben. Voor de overlegorganen moet exact worden vastgelegd wat het doel is en welke bevoegdheden zij krijgen.

2.10 Gebruikersdocumentatie

De gebruikersdocumentatie is nodig om gebruikers met het systeem vertrouwd te maken, ze er inzicht in te geven en ze te begeleiden in hun omgang ermee.
De gebruikersdocumentatie kan bestaan uit:

• een inleiding waarin de werkomgeving, het toepassingsgebied, het doel en de functies van het informatiesysteem toegelicht worden;
• een beschrijving van gebruiksprocessen (zowel interactief als batch), waarbij per gebruiksproces de invoer, de verwerking (eventueel inclusief te voeren dialoog) en de uitvoer worden beschreven, en de daarbij te gebruiken bestanden;
• een beschrijving van de relatie(s) met andere informatiesystemen;
• procedures ten aanzien van:
  • testen,
  • controles,
  • uitwijken,
  • aanleveren invoer,
  • aanvragen wijzigingen,
  • distributie en verwerking uitvoer; productieaanvragen,
• storingen;
• een beschrijving van de in het informatiesysteem belegde controles en beveiligingen;
• een beschrijving van de organisatie, de hierin belegde verantwoordelijkheden en taken voor zover ze het informatiesysteem en haar relaties betreffen;
• een opsomming van de contactpersonen;
• een beschrijving van de gegevensdefinities, indien er geen afzonderlijk gegevensbeheer wordt gevoerd.

2.11 Verschijningsvormen van gebruiksbegeleiding

Als de omgeving bestaat uit een kleine, sterk geconcentreerde groep gebruikers, dan kunnen (moeten) de beheerders de gebruikers veel individuele aandacht geven. Als er veel gebruikers zijn, die ook nog eens sterk verspreid zijn, dan is een individuele benadering bijna onmogelijk. In principe zijn er in dit laatste geval twee mogelijke alternatieven voor het begeleiden van gebruikers:

• mobiele gebruikersbegeleiding;
  alle gebruikers worden periodiek bezocht.
• linking-pin gebruikersbegeleiding;
  de gebruikers worden zelf ingeschakeld bij gebruikersbegeleiding, per regio kan men een gebruikersgroep initiëren onder leiding van een zogenaamde ‘Supergebruiker’; de supergebruikers coördineren hun regio en worden zelf periodiek uitgenodigd op een supergebruikersbijeenkomst.

2.12 Gebruiksondersteuningsplan

Er moeten allerlei processen plaatsvinden om gebruikers effectief te ondersteunen. Hiervoor zijn mensen en middelen nodig. De inzet van deze mensen en middelen moet gepland en achteraf beoordeeld kunnen worden. Met andere woorden: de gebruiksondersteuning moet bestuurd (gemanaged) kunnen worden.
Een belangrijk hulpmiddel bij het besturen van de gebruiksondersteuning is een gebruiksondersteuningsplan.

In een gebruiksondersteuningsplan moet het volgende eenduidig worden vastgelegd:

• de doelstellingen van de gebruiksondersteuning;
• de organisatie rondom de gebruiksondersteuning;
• de richtlijnen ten behoeve van de uit te voeren activiteiten;
• de normen en criteria waaraan de resultaten moeten voldoen; 
• de rapportagestructuur.

3. Gebruikerstevredenheidmeting

Gebruiksbegeleiding houdt ook in dat de begeleider op de hoogte blijft of komt van de meningen, ervaringen, tevredenheid en dergelijke van de gebruikers. Begeleiding is immers een tweerichtingsverkeer tussen gebruiker en begeleider. Het meten van de mate van tevredenheid van gebruikers is een complexe bezigheid, die meer te maken heeft met de wetenschap van de psychologie dan met bestuurlijke informatiekunde. Voor het verrichten van deze meting heeft de functioneel applicatiebeheerder maar een beperkt aantal mogelijkheden, zoals:

• interviews,
• enquêtes,
• gebruikersoverleg.

Wanneer men een tevredenheidsmeting verricht, moet men vooraf de werkwijze en normering vastleggen. Ook is een grondige voorbereiding noodzakelijk. Deze voorbereiding bestaat ondermeer uit het samenstellen van een checklist, die tijdens de interviews, enquêtes of het gebruikersoverleg als leidraad dient. Voor de checklist wordt bepaald welke onderwerpen tijdens de meting belicht moeten worden. Elk onderwerp wordt vervolgens opgedeeld in aspecten. Voor ieder aspect wordt tenslotte een aantal vragen geformuleerd.

3.1 Onderwerpen en aspecten van een gebruikerstevredenheidmeting

De checklist bestaat uit de volgende onderwerpen en de daarbij behorende aspecten:

3.2 Selectie van vragen

De omvang van de gebruikerstevredenheidmeting zal per systeem of portefeuille van systemen variëren. Daarom moeten, voordat met de evaluatie kan worden begonnen, onderwerpen en aspecten geselecteerd worden en moet hierover afstemming plaatsvinden.
In de eerste plaats moeten dus onderwerpen en aspecten geselecteerd worden. Afhankelijk van de situatie moeten voor het niet uitvoeren van een bepaald onderwerp of aspect redenen worden gegeven. Aspecten kunnen worden afgestemd op de specifieke situatie door selectie, toevoeging en verwijdering van vragen in de te gebruiken checklists.
In de tweede plaats is het nodig de structuur, alsmede de management- en beoordelingsstrategie van de meting vast te stellen. Bij een omvangrijke meting kan het nodig zijn om tijdens de uitvoering de voortgang en de mogelijke tussentijdse bevindingen te beoordelen. De laatste kunnen reden zijn voor een nader onderzoek, waardoor de omvang van de meting mogelijk aangepast moet worden.
De benodigde tijd en moeite om een gebruikerstevredenheidmeting uit te voeren hangen af van veel factoren. De volgende richtlijnen zijn bedoeld om een werkbare schatting mogelijk te maken. Deze inschatting moet eerst per checklist worden daan op aspectniveau, waarna vervolgens de totale inspanning per onderwerp ingeschat kan worden. Een gebruikerstevredenheidmeting omvat de volgende werkzaamheden:

• opstellen en aannemen van een beoordelingsstrategie, een opdracht en de plannen;
• voorbereiden van het regelen en vastleggen van interviews;
• invullen van de vragenlijsten;
• analysere van vragenlijsten en vervaardigen van scoringsrapporten.

Een halve dag per interview zou voldoende moeten zijn. Het interview zelf neemt ongeveer een uur in beslag, maar de rest van de tijd is nodig voor het schrijven van interviewverslagen, notities en commentaar. Er moet ook rekening worden gehouden met eventuele reistijd. De personen die geinterviewd worden, moeten de relevante vragenlijst(en) enkele dagen van te voren in hun bezit hebben. Voor analyse van de ingevulde checklist en het maken van de scoringsrapporten zou niet meer dan een of twee uur per systeem, per onderwerp uitgetrokken moeten worden.
Men moet er wel op voorbereid zijn, dat antwoorden op bepaalde vragen, die niet overeenstemmen met de indicatie en met eerder gesignaleerde problemen nader onderzoek noodzakelijk maken. Ook moet er rekening mee worden gehouden, dat de beoordeling van de resultaten, als zij geïncorporeerd worden, de nodige tijd vergt.

3.3 Invullen van checklists

De gebruikerstevredenheidmeting maakt gebruik van gedetailleerde checklists met vragen, om ieder gekozen aspect te kunnen beoordelen. De vragen worden beantwoord door middel van het toekennen van een satisfactiegraad:

 H = Hoog
 G = Gemiddeld
 L = Laag
 N = Niet van toepassing

De checklists kunnen gebruikt worden gedurende interviews met de betrokkenen.Uit de ingevulde vragenlijsten kunnen bepaalde succes- of probleemgebieden nara voren komen, die nader onderzocht moetenworden. Verder ontstaat er een algemeen beeld van de (on)tevredenheid met het systeem.

CHECKLIST:
 GEBRUIKERSTEVREDENHEID
 
Onderwerp:
 Boordeling gebruik van het systeem
 
 Aspect:
 Gebruik van het systeem

 
3.4 Rapportage

De indruk van de gebruikerstevredenheid kan samengevat worden met behulp van scoringsrapporten. Deze scoringsrapporten geven de satisfactiegraden H (Hoog) en L (Laag) schematisch weer. Zo wordt snel inzicht verkregen in succes- en probleemgevallen. In de eerste plaats kunnen Scoringsrapporten worden opgesteld van onderwerpen waarvan de scores zijn opgenomen in zowel de betreffende aspecten als in een totaalscore.
Als een totaalindruk gewenst is van de onderwerpen binnen een checklist, kan ook een scoringsrapport opgesteld worden waarin alleen de scores van die onderwerpen opgenomen zijn. Deze scoringsrapporten kunnen een rol spelen wanneer de gebruikerstevredenheid van meerdere systemen gemeten wordt. Voor ieder aspect wordt dan de score als volgt berekend:

Aantal vragen beantwoord met H                   : ______

Aantal vragen beantwoord met G                   : ______

Aantal vragen beantwoord met L                   : ______

                                                           Totaal:            +______

                        Aantal vragen beantwoord met H

% H     =          —————————————–        x          100      =

                                               Totaal

                         Aantal vragen beantwoord met L

% L     =          —————————————–        x          100      =

                                               Totaal

De vragen die niet beantwoord zijn, of beantwoord zijn met N (Niet van toepassing), worden in de procentuele berekening niet meegenomen. De berekende percentages worden afgerond op één decimaal en weergegeven in de kolommen %H en %L. Vervolgens worden deze percentages nog eens afgerond en in eenheden van 10% weergegeven in de vorm van een X-notatie op het scoringsrapport.

3.5 Follow-up

Nadat een meting heeft plaatsgevonden kan men verder gaan door succes- en probleemgebieden op te sommen en/of door een nadere audit.

3.6 Opsomming van succes- en probleemgebieden

Een toelichting op een scoringsrapport wordt gegeven in de vorm van een opsomming van succes- en probleemgebieden. Door middel van identificatie en omschrijving van succes- en probleemgebieden kan een organisatie herhalen en voortbouwen op wat goed verlopen is en zich concentreren op verbetering van die gebieden die problematisch bleken te zijn.

3.7 Nadere audit

Scoringsrapporten geven een snelle indruk van de aanwezige probleemgebieden. Op grond hiervan kan het management besluiten tot het uitvoeren van een audit op het betreffende onderwerp. Hoewel de gebruikerstevredenheidmeting niet direct gericht is op het verrichten van directe aanpassingen, kan daar waar mogelijk een set van bevindingen en conclusies worden samengesteld  en aanbevelingen worden gedaan op toekomstige te ondernemen acties.

4. Conclusie

Dit artikel beschreef een uitgebreide vorm van gebruiksbeheer. Natuurlijk kan dit in de praktijk ook informeler en/of korter. Essentieel is echter wel dat de verantwoordelijkheid en de uitvoering nadrukkelijk belegd worden buiten de ICT-afdeling. Als de gebruikers onvoldoende zin of tijd hebben om dit te organiseren en uit te voeren, dan ligt uitbesteding meer voor de hand dan uitvoering door de ICT-afdeling. Zodra er namelijk weer een incident plaatsvindt op ICT-gebied, zal het incident centraal staan en worden de uitkomsten van het klanttevredenheidsonderzoek onder het tapijt geveegd. Op dat moment zullen de samenwerking en de service gestuurd blijven worden door emoties en wordt een structureel verbeterproces onmogelijk. (Meer hierover in het artikel ‘Afbakening taken functioneel beheer baseren op behoefte’.)

Oorspronkelijke versie: 15 februari 2005

Download:       

No related posts.

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. De gebruikers lijken hun eigen bedrijfsprocessen niet te begrijpen.’
• ‘De gebruikersorganisatie is onvoldoende professioneel ingericht, zeker in relatie tot ons eigen professionaliteitsniveau.’

De arme functioneel beheerder moet voor het standpunt van beide partijene begrip hebben en moet ervoor zorgen dat die 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

Als het erover gaat of methodes het wel of niet doen, trekken theoretici al snel 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’ over het gebruik van methoden. De conclusie die hij trekt, is dat het niet de methode is, maar 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. Nog steeds werkt iedere methodiek (zelfs de slechtste), 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 is 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. (Zie ook ‘Wilt u een Smart, Golf, Mercedes of Rolls’.) 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 tusen in zit de functioneel beheerder. Zowel voor wat de business wil, als voor wat de ICT wil, geldt, dat het in elk geval niet in het bedrijfsbelang is. Kortom, functioneel beheerders zullen uit hun ‘hoekje waar de klappen vallen’ moeten komen.  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.

Er 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. Laatst 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.

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 bij de super 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 ‘Functioneel beheer wordt informatiemanagement’.)

Oorspronkelijke versie: 15 juli 2009

Download:       

No related posts.

De crisis heeft bedrijven gedwongen kostenbesparingen door te voeren. Op ICT-gebied zijn rationalisatie van het applicatielandschap, integratie van functionaliteit, maatwerk dat wordt vervangen door standaardpakketten en uitbesteding van ICT-activiteiten aan de orde van de dag. Het moet goedkoper, maar niet ten koste van de kwaliteit.
Van de spelers die verantwoordelijk zijn voor het borgen van die kwaliteit, is de functioneel beheerder één van de belangrijkste. Tot nu toe voerde hij vooral applicatiegerichte taken uit. Door de genoemde ontwikkelingen is zijn rol aan het veranderen. Hij krijgt te maken met een toenemend aantal interne en externe partijen die betrokken zijn bij het beheer en onderhoud van steeds meer bedrijfsoverstijgende informatiesystemen. De uitdaging waar de functioneel beheerder voor staat, is het borgen van de door de business gestelde kwaliteitseisen in de gehele ICT-leveringsketen; de functioneel beheerder wordt demandmanager. (Zie ook ‘Functioneel beheer en inkoop vaak bottlenecks in de ICT-leveringsketens’.)

De ICT-leveringsketen

Om de nieuwe rol van de functioneel beheerder als demandmanager duidelijk te krijgen, moeten we eerst kijken naar de omgeving waarin hij die rol uitvoert: de ICT-leveringsketen.

In deze keten is onderscheid gemaakt tussen partijen die ICT-diensten vragen (opdrachtgevers) en partijen die deze leveren (opdrachtnemers). ICT-diensten zorgen ervoor dat de informatievoorziening de functionaliteit biedt die de business dagelijks nodig heeft, en garanderen de continuïteit en beschikbaarheid daarvan. De partijen die daarin een rol spelen zijn:

• de business, die eisen stelt aan functionaliteit en kwaliteit van huidige en toekomstige informatiesystemen (het domein van de informatievoorziening, IV) en de daarbij noodzakelijke (ICT-)support;de business is eigenaar en opdrachtgever;
• het informatiemanagement, dat deze eisen vertaalt naar de kwaliteit van de benodigde informatiesystemen en te leveren ICT-diensten en dat gedelegeerd opdrachtgever van de business is;
• de regie, die de klantvraag kanaliseert, deze afstemt met het ICT-aanbod, zorgt voor de integratie van de diensten van meerdere externe ICT-leveranciers en erop toeziet dat conform contractafspraken wordt geleverd; de ICT service integrator;
• ICT-leveranciers, die applicatie- en infrastructuurservices leveren conform contractafspraken op onderdelen van informatiesystemen en daarmee opdrachtnemers zijn.

De business is leading

De partijen aan de klantkant staan voor de uitdaging ervoor te zorgen dat ICT-diensten worden geleverd volgens de verwachting van de business. (Zie ook ‘Valkuilen functioneel beheer volgens BiSL’.) Daarbij moeten zij rekening houden met de volgende ontwikkelingen:

• De business eist steeds hogere kwaliteit tegen lagere kosten en eist een kortere time-to-market: nieuwe producten en diensten die de business levert aan zijn klanten vergen steeds snellere aanpassingen in de informatievoorziening.
• Maatwerk wordt steeds vaker vervangen door geïntegreerde standaardpakketten die meerdere bedrijfsprocessen ondersteunen. Dat betekent dat meer businesseigenaren invloed (willen) hebben op de functionaliteit en kwaliteit.
• Beheer en onderhoud van een informatiesysteem zijn belegd bij meerdere externe leveranciers die specialist zijn op specifieke onderdelen van het totale informatiesysteem. De samenwerking tussen deze partijen vergt specifieke integrale aandacht, tenslotte bepalen zij gezamenlijk de dienstverlening aan de business.
• Steeds meer ICT-activiteiten worden uitbesteed aan partijen die zijn gevestigd in India of Oostbloklanden, Global sourcing. Dit stelt hoge eisen aan het specificatie- en acceptatieproces aan de kant van de opdrachtgever. Taken die voorheen vaak door de eigen ICT-afdeling werden uitgevoerd, worden nu teruggelegd bij de opdrachtgever.
• De business wordt steeds zelfstandiger. Applicaties en services zijn overal beschikbaar: in de cloud en in app stores. Het moet duidelijk zijn hoe je hiermee als bedrijf wilt omgaan. Het geformuleerde beleid geeft onder meer de kaders aan waarbinnen het (functioneel) beheer moet worden uitgevoerd.

Deze ontwikkelingen hebben invloed op de wijze waarop de partijen in de ICT-leveringsketen samenwerken en afspraken maken over de kwaliteit van de te leveren ICT-diensten. Hoe krijg je als opdrachtgever nu grip op de kosten en kwaliteit van je informatievoorziening als steeds meer partijen zijn betrokken bij het onderhoud en beheer ervan? En welke rol speelt de functioneel beheerder als demandmanager hierin?

Voldoen aan gespecificeerde en vanzelfsprekende behoefte

Om de geschetste ontwikkelingen het hoofd te kunnen bieden, zal elk bedrijf maatregelen moeten nemen om de gewenste kwaliteit te borgen in de keten. Toen men nog te maken had met alleen maar een eigen ICT-afdeling, was het een kwestie van even binnenlopen en elkaar recht in de ogen kijken om te begrijpen wat wederzijds de verwachtingen waren. In de huidige complexe omgeving met vele ICT-leveranciers en belanghebbenden is dat een stuk lastiger geworden.
Concrete afspraken tussen business en ICT en tussen ICT-leveranciers onderling zijn nodig om helder te krijgen wat de verwachtingen van de business zijn in aansluiting op wat de externe partijen moeten leveren en wanneer. Deels zijn die verwachtingen impliciet en horen ze bij de standaarddienstverlening.
Daarnaast moet de opdrachtgever grip hebben op de beheer-, onderhouds- en innovatieprocessen die ervoor zorgen dat ook daadwerkelijk volgens verwachting wordt geleverd en dat problemen adequaat worden afgehandeld. Deze processen beginnen en eindigen niet meer binnen het bedrijf. Het zijn ketenprocessen geworden die bedrijfsoverstijgend zijn en waarbinnen opdrachtgever en opdrachtnemer hun eigen verantwoordelijke taken hebben. (Zie ook ‘BiSL maakt functioneel beheer wel erg ingewikkeld’.) Die verantwoordelijkheden moeten voor iedereen helder zijn. Dat betekent dat er duidelijke eisen moeten worden gesteld aan de kwaliteit van de producten die in een proces van de ene partij naar de andere worden overgedragen, zogenaamde quality gates. In de uitvoering van de processen om ‘levering volgens verwachting’ te garanderen, dienen voor de overdrachts­momenten afspraken te worden gemaakt over de eisen die aan beide partijen worden gesteld ten aanzien van de geleverde en te leveren producten en diensten. Dat geldt zowel tussen partijen binnen de organisatie van de klant, als tussen de klant en ICT-leveranciers en tussen de leveranciers onderling. Onder meer deze kwaliteitseisen zijn richtinggevend voor de uitvoering van de ketenprocessen.

Nieuwe positionering en rol functioneel beheerder

Waar voorheen de functioneel beheerder applicatiegerichte taken uitvoerde, richt hij zich nu in de rol van demandmanager op het ‘managen’ van de kwaliteit van bedrijfsbrede informatiesystemen in de hele keten, op operationeel en tactisch niveau. Het informatiemanagement op strategisch niveau ten aanzien van de gehele IV-portfolio wordt nu ook op tactisch en operationeel niveau ingevuld. In bovenstaande figuur zijn de demandmanager en de informatiemanager gepositioneerd in de kolom ‘IV-management’. Vereenvoudigd is de positie van beide hieronder weergegeven. Zij zijn samen de behoeftesteller naar de hoofdaannemer van de leveringsketen. (Zie ook ‘Tips voor een begrijpelijk SLA of ICT-contract’.)

De demandmanager ondersteunt de informatiemanager bij het maken van praktische afspraken over de ontwikkeling, het beheer en de uitvoering van ICT. Hij zorgt ervoor dat de business de best mogelijke ICT-voorzieningen krijgt binnen het beschikbare ICT-budget. Dat betekent dat hij moet faciliteren in het maken van afgewogen keuzes bij het gebruik en de toepassing van informatiesystemen en de ICT-diensten die de continuïteit en beschikbaarheid garanderen, zowel op tactisch als op operationeel niveau. De informatiemanager heeft die rol op strategisch niveau voor de gehele IV-portfolio. In het uitvoeren van zijn rol stemt de demandmanager de belangen af met alle partijen die een rol hebben in de ICT-leveringsketen binnen zijn domein. In die rol vervult de demandmanager onder meer de volgende taken. Hij:

• is de spil tussen de vraag vanuit de business en het aanbod van, eventueel meerdere, ICT-leveranciers;
• bewaakt de kwaliteit van de ICT-dienstverlening conform de eisen van de business;
• bewaakt de uitvoering van de ketenprocessen op het gebied van beheer, onderhoud en innovatie in de hele ICT-leveringscyclus (‘van idee tot levering’) op basis van KPI’s, en maakt hierover afspraken met alle betrokken partijen;
• heeft periodiek overleg met ICT-leveranciers en business over de kwaliteit van de (levering van) ICT-diensten, afgestemde ketenprocessen en projecten;
• zorgt dat kwaliteitseisen zijn vastgelegd in SLA’s en dat externe ICT-contracten hierop aansluiten;
• stuurt operationele functioneel-beheerteams aan en coacht ze in hun rol, het volgens standaardprocedures uitvoeren van functioneel-beheerprocessen (als onderdeel van de keten);
• verkent de mogelijkheden om samen met andere businessunits vernieuwingen te realiseren binnen de kaders van de bestaande informatieplannen;
• stemt business- en projectplannen af met de betrokken partijen in de keten;
• adviseert in ICT-projecten en borgt de businesseisen gedurende het project;
• adviseert bij leveranciersselecties en beheert de relaties met de business en de ICT-leveranciers;
• adviseert de business over ontwikkelingen aan de kant van ICT, de gevolgen voor de informatiesystemen en de daaraan verbonden kosten.

Deze taken zijn, zoals eerder gezegd, niet gericht op het uitvoeren van operationele, applicatiegerichte functioneel-beheeractiviteiten, maar vooral op communicatie, het afwegen van businessbelangen en de afstemming met alle partijen die verantwoordelijk zijn voor ‘het leveren volgens verwachting’. (Zie ook ‘Afbakening taken functioneel beheer baseren op behoefte’.) Dat onderscheidt de functioneel beheerder van de demandmanager.

Inkopen ICT diensten is een vak

In veel bedrijven is uit bezuinigingsoverwegingen de inkoopfunctie van de ICT overgeheveld naar de afdeling inkoop. Gevolg is, dat er veel getenderd wordt en binnen de tender gekozen wordt voor de goedkoopste aanbieder. Afspraken worden vervolgens in beton gegoten. Op deze kostenbesparende constructie echter, lopen vervolgens iedere gebruikerswens en iedere innovatie schipbreuk. Er is immers sprake van een complexe keten en niet enkel van een klant-leverancier relatie. Verder zijn eisen zijn niet stabiel. Ze zullen daarom gemanaged moeten worden, zowel naar de leveranciers als naar de gebruikers, waarbij men moet voorkomen dat functioneel beheer weer een nieuw bolwerk wordt in de keten. De functioneel beheerder moet daarom naar beide kanten kunnen communiceren. Hij is vooral een operationeel en tactisch manager, die moet zorgen dat de klanttevredenheid ten aanzien van de gebruikte, bedrijfsbrede informatiesystemen in de hele ICT-leveringsketen geborgd is. Dat vergt afweging van businessbelangen, afstemming en communicatie met de ketenpartijen, het maken van afspraken en het managen van de processen die de kwaliteit, beschikbaarheid en continuïteit garanderen. Daarvoor zijn andere competenties nodig, dan waarover die functioneel beheerder beschikte, die acht uur per dag achter zijn pc zat. Graag geven we u hiervoor een aantal handvatten, zoals in het artikel ‘Zeven tips voor het inkopen van ICT-projecten’.

Bron:
Wilbert Teunissen, ‘Functioneel beheerder wordt demandmanager’. In: ICT-infra. maart 2011

Download:       

No related posts.

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

1. Inleiding

In veel organisaties is het functioneel applicatiebeheer nog steeds een ondergeschoven kindje. Vaak komt dit doordat methodieken als ITIL op de ICT-afdeling zijn gericht en de invalshoek van de gebruikers ontbreekt. Met een reeks artikelen over functioneel beheer op onze site willen we u als functioneel beheerder, business manager of gebruiker handvatten bieden om structuur aan te brengen in uw behoeften en om de communicatie en samenwerking met de ICT-afdeling te verbeteren.
Dit artikel schetst de organisatie van de inrichting van het functioneel applicatiebeheer. Als basis hebben we gekozen voor de benadering van Looijen, omdat die in zijn modellen ook 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’.)
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 onze artikelen consequent de term ‘functioneel applicatiebeheer’.

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 echter de noodzaak van een goed geregeld beheer van informatievoorziening toe. Voor veel bedrijven en organisaties is het zo langzamerhand dan ook de hoogste tijd geworden om ernst te maken met het systematisch regelen van dat beheer. De risico’s die men loopt als men dit niet doet, 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 veel 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 erg moeilijk blijken te zijn. En tenslotte wordt het verhogen van de beveiligingsgraad van informatiesystemen een bijna onmogelijk zaak. Als men genoemde zaken goed wil aanpakken, zullen alle betrokkenen op de hoogte moeten zijn van de beheerprocessen en de hieraan verbonden taken en verantwoordelijkheden. Het goed organiseren van het beheer is echter 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’. Deze benaming zal in het vervolg van dit artikel dan ook veelvuldig gebruikt worden. Ook wanneer over ‘Bedrijfsvoering’ wordt gesproken, wordt ‘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. Echter wanneer men niet planmatig werkt, 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

Service Level Management en Service Management zijn de besturende processen  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. 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

Gebruiken kan het Onderhoudsbeheer uitbesteden aan de Bedrijfsvoeringsfunctie Onderhouden en het Exploitatiebeheer 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 over functioneel applicatiebeheer 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. (Zie ook ‘BiSL maakt functioneel beheer wel erg ingewikkeld’.)
Een meer resultaatgerichte aanpak is veelal effectiever dan een procesgerichte aanpak, zeker bij ICT’ers waar functioneel beheerders steeds mee te maken hebben. Als bijproduct van deze resultaatgerichte aanpak kunnen dan processen ingericht worden. Niet theoretisch en bureaucratisch, maar pragmatisch en praktisch. ZBC kan u hierbij begeleiden, zowel in de vorm van coaching van het management als via workshops voor alle betrokkenen. Voorbeelden zijn o.a.:

• Casestudy Training functioneel beheer website
• Casestudy Training Outsourcing werkplekbeheer
• Groepstraining on the job: integratie functioneel en technisch beheer en applicatiebeheer

Oorspronkelijke versie: 15 oktober 2005

Download:       

No related posts.

Laten we het eens vergelijken met uw auto. Die is niet specifiek voor u gemaakt, maar u kunt wel zelf bepalen hoe hard u ermee rijdt en wat u in uw handschoenenkastje stopt. Hetzelfde geldt voor de CD-speler die u misschien in uw auto heeft. Welke CD’s en dus welke muziek u daarmee beluistert, kiest u ook zelf. Waarschijnlijk hebt u een standaardrouteplanner, maar uw bestemming bepaalt u zelf. Ook de spiegels zijn natuurlijk standaard, maar ze kunnen voor iedere bestuurder versteld worden. Tenslotte zijn er de motor en de carrosserie. Die zijn ook standaard, maar die moeten vooral degelijk en betrouwbaar en vooral niet flexibel zijn.

Wanneer wel en wanneer geen ERP?

Ook in uw organisatie zijn er onveranderlijke, stabiele processen en informatieverzamelingen die betrouwbaar en voorspelbaar moeten zijn. Meestal bevinden deze processen zich in de backoffice. Een voorbeeld is het financiële proces. Processen in de frontoffice moeten beweeglijker zijn. U bent immers klantgericht en u wilt uw klant graag bedienen. En natuurlijk wilt u ook efficiënt zijn. U biedt dus een standaardbasisproces aan, dat flexibel aangepast kan worden aan de behoeften van de klant. Vergelijk het met die spiegels, routeplanner enzovoort van uw auto, die steeds aan de bestuurder aangepast kunnen worden.
Veel bedrijven proberen echter ook flexibele processen en informatieverzamelingen in hun ERP te stoppen. Ze komen er dan achter dat het ERP-systeem toch echt van graniet is. Leveranciers en consultants denken misschien dat ze als een kunstenaar kunnen omgaan met graniet. Maar dat blijkt meestal een illusie. (Zie ook ‘ERP selectie en implementatie: eerst van een muis een olifant maken en daarna omgekeerd’.) Als u flexibiliteit in uw ERP wilt stoppen is het alsof u de buitenspiegel van uw auto, die toch flexibel moet zijn, in een stand dwingt die u zelf niet meer kunt veranderen zodra u eenmaal voor die stand heeft gekozen. Vanaf dan moet u met die bepaalde stand verder leven. De spiegel met veel kracht bijstellen leidt er toe, dat deze gewoon afbreekt. Gevolg: frustratie en nog meer extra kosten. Alleen de leverancier kan er nog voor zorgen dat uw buitenspiegel anders wordt ingesteld.

Bedrijfssoftware: geen ERP maar een platform

Veel ERP-leveranciers pretenderen een bedrijfsoplossing te bieden. Hoewel de functionaliteit van hun oplossing dan misschien wel toereikend is, is deze totaal onbruikbaar voor processen die flexibel moeten worden ingericht. Veel ERP-systemen hebben bijvoorbeeld een projectenmodule. Er is echter geen projectleider die er soepel mee kan omgaan. Zo’n module moet u dus niet willen.
Kies daarom niet voor een ERP-systeem, maar voor een platform waar verschillende soorten software moeiteloos geïntegreerd kunnen worden. En niet het ERP-systeem maar het platform dient centraal te staan. Voorbeelden van zulke platforms zijn Oracle, Microsoft en Google Apps. In het artikel ‘Architectuur rondom ERP-software’ wordt dit verder uitgewerkt. Binnen dit platform kiest u de specialistische tools die tegemoetkomen aan uw wensen en eisen, ook met betrekking tot flexibiliteit en aanpassingsgemak. ICT is er tenslotte voor de gebruikers en niet voor de ontwerpers en de beheerders. Die horen op de achtergrond te werken aan dit bedrijfsmiddel, dat gebruikers in staat moet stellen om topprestaties te leveren. (Zie ook ‘Wie verlost bedrijven van hun ICT-ers’.) Zo is het toch ook geregeld met bijvoorbeeld uw wagenpark?
ICT’ers moeten oplossingen brengen en niet specificaties halen. Zij zijn de specialisten in software en hardware en zij moeten weten, dat je geen bromfietsmotor in een vrachtauto moet stoppen en omgekeerd, als u dit mogelijk in uw onwetendheid zou vragen. U mag verwachten dat zij een standaardproduct zodanig assembleren, dat u het zelf flexibel kunt inregelen op uw behoeften. Net als die spiegels, die routeplanner en die CD-speler van uw auto.

Waarvoor gebruikt u uw ERP-systeem wel?

Laten we eens een redelijk doorsnee bedrijf in Nederland nemen met tussen de 5 en 200 medewerkers, dat produceert of engineert op order. Schrik niet, ik bedoel bouwbedrijven, ICT-bedrijven, overheden, veel zorginstellingen, zakelijke dienstverleners, notarissen, service-organisaties, cateringbedrijven, ingenieursbureaus, uitzendbureaus, badkamerwinkels, klusjesmannen. Hiervan kennen we vele duizenden in Nederland. Het primaire proces verloopt als volgt:

• maken van afspraken met de klant over prijs/prestatie (al dan niet vastgelegd in een formeel contract en al of niet voorafgegaan door een acquisitie- en offertetraject);
• uitvoeren planning en eventueel inkopen van materiaal/resources;
• verantwoorden bestedingen en eventueel bijsturen planning en hierover rapporteren aan de klant;
• consolidatie in de financiële administratie.

Strikt genomen zitten hier maar een paar punten in, die in graniet gebeiteld kunnen zijn:

• de klantorder; 
• de inkooporder;
• de financiële administratie;
• de debiteuren en crediteuren bewaking.

Voor deze punten kunt u heel goed een standaardoplossing gebruiken. Maar de rest van het proces moet eenvoudig aangepast kunnen worden onder meer aan de klant, aan de omvang en de aard van de opdracht, aan de benodigde materialen en aan het feit of er wel of niet projectmanagement uitgevoerd wordt. U moet dat niet proberen onder te brengen in het ERP-systeem. Dat past alleen met veel extra inspanningen en soms met trucs, waardoor het ERP-systeem nog minder doorzichtig wordt dan het al was. U kunt dan ook het aantal gebruikers beperken en dat is mooi, want ERP-systemen staan bepaald niet bekend om hun gebruikersgemak. Bovendien heeft u minder licenties nodig en de implementatiekosten zullen lager zijn.
De specialistische tools kunt u, zoals u verderop zult zien, onderbrengen in uw Sharepoint omgeving. De informatie uit deze tools deelt u eveneens via Sharepoint. Onderstaand wordt dit schematisch weergegeven:

Veel problemen met ERP-systemen zoals bijvoorbeeld bij overheden zijn terug te voeren tot de essentiële fout dat men flexibele processen in een ERP-systeem wil stoppen. Alleen een zuiver productiebedrijf zoals een bedrijf voor massaproductie of een pretpark kan zonder problemen meer zaken in zijn ERP-systeem stoppen.

Hoe omgaan met de processen buiten het ERP-systeem?

De processen die u niet in uw ERP-systeem stopt, wilt u natuurlijk ook ondersteunen met ICT. Bovendien wilt u ze aansluiten op het ERP-systeem. Om dit te realiseren is het nodig, dat u kiest voor een platform, waarbij gegarandeerd allerlei software behorend tot dat platform eenvoudig ingeplugd kan worden, zodat er geen functionaliteiten in het ERP-systeem gepropt hoeven worden.
Laten we voor het gemak uitgaan van Microsoft als platform. De meeste bedrijven in Nederland gebruiken dit toch al als belangrijk onderdeel van hun software architectuur. Uiteraard is onderstaande eenvoudig te vertalen naar andere platformen. Uitgaande van Microsoft wordt het ERP-systeem MS Dynamics AX dan wel NAV. Medewerkers in bedrijven die leveren op order hebben vaak behoefte aan informatie- en kennisuitwisseling, communicatie en afstemming, mogelijkheden tot eenvoudige registratie van gebeurtenissen en feiten. Denk hierbij aan commerciële medewerkers, baliemedewerkers, service medewerkers, projectleiders. MS office is hiervoor heel geschikt, maar dan is nog wel integratie nodig van het geheel. Binnen het Microsoftplatform is Sharepoint hiervoor het geschikte tool. Met Sharepoint kunnen informatie, processen en systemen geïntegreerd worden en u kunt er 7*24 en overal gebruik van maken. Ook biedt Sharepoint goede mogelijkheden om de data zelf te beveiligen. Meer hierover vindt u in het artikel ‘Architectuur rondom ERP-software’.
Sharepoint is op zich een lege doos waarin je verschrikkelijk veel spullen kunt stoppen. Dat is ook de belangrijkste valkuil. Het kan snel uitgroeien tot een Winkel van Sinkel. Daarom is het nodig om de processen die data uitwisselen met het ERP-systeem strak te trekken in Sharepoint door hiervoor een workflow in te richten. Dat betekent dat er inderdaad een klantorder wordt aangemaakt met een aantal verplichte velden, die ook in het ERP-systeem gebruikt worden. Voor zover beschikbaar worden deze velden door het ERP-systeem automatisch ingevuld. En de verplichte velden in Sharepoint worden na de noodzakelijke fiatteringen in de database van het ERP-systeem gezet (zonder dubbele invoer van gegevens). Alle niet verplichte documentatie rond de klantorder zoals de offerte aanvraag, de offerte, achtergrondinformatie en gesprekverslagen worden gewoon opgeslagen in Sharepoint en zijn altijd beschikbaar voor hergebruik. Ditzelfde geldt voor processen als inkooporders, urenverantwoording, verbruik van materialen en resources enzovoort.
Voor het snel en flexibel aanpassen van de workflows kan Nintex gebruikt worden, dat bovendien de status van iedere opdracht en iedere proces weergeeft en ervoor zorgt dat Sharepoint een notificatie stuurt naar de medewerker die de volgende stap in de workflow moet uitvoeren.

Wat betekent dit in de praktijk?

U ziet de bui natuurlijk al hangen. U heeft licenties nodig voor Dynamics, voor Sharepoint, voor Office, voor Nintex en vanzelfsprekend voor de laatste versies, omdat alleen die goed samenwerken. Dat gaat een vermogen kosten. Om nog maar te zwijgen over de kosten voor ICT-consultants, die dit geheel passend moeten maken voor uw organisatie. Vijf jaar geleden zou u gelijk gehad hebben. Maar de tijden zijn veranderd en ICT-diensten zijn meer volwassen geworden.
Laten we even terugkeren naar die auto. Met alles er-op-en-er-aan is die minstens zo complex als de hierboven beschreven oplossing. Toch laat u die auto niet specifiek voor uzelf bouwen. U gaat niet naar de fabriek om te kijken hoe de motor wordt gemaakt. U gaat gewoon naar de showroom en u zoekt een auto uit. U bepaalt eerst of u een vrachtauto, bestelbus, personenauto, boodschappenautootje of wat dan ook wilt hebben. U bekijkt merk en types en u kiest voor kleuren en accessoires. Dat alles in de auto samenwerkt, daar gaat u van uit. Als u de auto gekocht hebt, vult u uw handschoenenkastje met uw spullen, u stopt uw CD in de CD-speler, u zet uw bestemmingen in de routeplanner, u stelt de spiegel in op hoe u achter het stuur zit, u start de motor en rijdt weg met de door u gewenste snelheid.
Met een ICT-oplossing is het in feite net zo. Voor 95% of meer van uw bedrijfsprocessen geldt, dat deze in tig bedrijven voorkomen. Hiervoor zal dus ook vast een oplossing bestaan, zodat u proven technology kunt kopen. U kunt zelfs (deels) kiezen voor een lease-constructie via SaaS. Dan hoeft u zelfs niet te investeren en hoeft u zich niet druk te maken over allerlei facilitaire zaken. En als uw ‘auto’ een keer weigert, wordt snel ‘vervangend vervoer’ geregeld.
Het betekent wel dat uw ICT-inkoopproces totaal verandert. U koopt geen computers, software en allerlei andere spullen meer, die vervolgens specifiek voor u in elkaar gesleuteld moeten worden, maar u schaft gewoon een standaardoplossing met service aan, waarbij u leert om zelf de ‘routeplanner, de spiegels en de CD-speler’ te bedienen, zodat u die 5% die uw organisatie specifiek maakt, zelf kunt inregelen. (Zie ook ‘Functioneel beheer en inkoop vaak bottlenecks in de ICT-leveringsketens’.)
Het betekent dat u ook verlost bent van al die consultants, die bij u de specificaties komen halen. De auto die u wilt, koopt u ook op een beeld dat u in uw hoofd heeft. Daar gaat u geen specificatie van 30 kantjes voor schrijven. De aanbieder vertelt u de eigenschappen van zijn oplossing en licht toe waarom zijn oplossing de beste is voor u. Dat verkoopverhaal neemt u natuurlijk met een korreltje zout en u laat het ook nog eens vertellen door een aantal andere aanbieders met soortgelijke oplossingen. En dan kiest u voor de beste prijs/prestatie met uiteraard de garantie dat onvolkomenheden worden opgelost door en voor rekening van de aanbieder. Alles wat u zelf moet doen is een stukje onderhoud, benzine tanken en het wassen van de auto.

Inkopen van ICT en ERP wordt belangrijk

Er zijn vele duizenden ICT-bedrijven in Nederland. Een aantal zijn volwassen, maar de meeste nog niet. Ook kunnen veel ICT-dienstverleners geen complete auto’s leveren. Ze zijn gespecialiseerd in spiegels, bumpers of de motor. Ze zijn ook niet bereid om garanties te geven, die verder gaan dan tot de deur. En voor lease-constructies zijn ze helemaal niet in. Ze willen liefst dat u betaalt voordat u in het dagelijks gebruik merkt, dat de gewenste prestatie toch niet helemaal geleverd is.
Bij de inkoop zijn er dus een aantal zaken van belang:

• een duidelijk beeld van de gewenste functionaliteit  in doelstellingen;
• inzicht in de volwassenheid van aanbieders en weten hoe dit eenvoudig getoetst kan worden;
• in staat zijn om meerdere offertes te krijgen, die vergelijkbaar zijn;
• voldoende inzicht in de markt om volwassen dienstverleners te vinden; reputaties van ICT-bedrijven zeggen zelden iets over hun volwassenheid (zie ook ‘Waarom tarieven van grote ICT-dienstverleners hoger zijn’);
• de offerte verlagen door maatwerkcomponenten te vervangen door de assemblage van flexibele standaardcomponenten;
• kennis van hoe een contract met een ICT-leverancier opgebouwd moet zijn (zie ook ‘Tips voor een begrijpelijk SLA of ICT-contract’);
• toezicht houden op de leverancier, of u inderdaad krijgt wat u afgesproken hebt.

Meestal begint inkoop met het opstellen van een korte en duidelijke RfP, die doelstellingen en knock-out criteria aangeeft en die ervoor zorgt dat ICT-aanbieders niet alleen onderling te vergelijken prijs/prestatie offreren, maar ook moeten aangeven of ze ‘proven technology’ aanbieden en ervaring hebben met de assemblage hiervan en verder dat ze voldoen aan alle gestelde eisen en wensen. In het artikel ‘Zeven tips voor het inkopen van ICT-projecten’ geven we meer best practices voor dit inkoopproces.
Een ERP systeem is dus niet meer de totaaloplossing voor uw bedrijfsautomatisering, maar wel de betrouwbare motor in het geheel. En natuurlijk moet die motor zoveel mogelijk onzichtbaar blijven onder de motorkap.

Download:       

No related posts.

In die tijd was dit een goede, tijdelijke oplossing om de communicatiekloof te overbruggen. Vervolgens heeft de ICT zich verder ontwikkeld, maar wel in een wat verwrongen vorm. Waar men er in allerlei branches naar streefde om producten zo robuust en zo foutvrij te maken, dat onderhoud nagenoeg overbodig is en dus communicatie niet meer belangrijk, zagen we dat de ICT zich ging richten op het in stand houden van de kinderziekten. Bedrijven gingen zelf grote ICT-afdelingen optuigen en er werden zelfs methoden verzonnen om de processen van de tijdelijke noodoplossing, die functioneel beheer heet, in te richten. Het ergste van dit alles was, dat bestuurders van nogal wat grote, rationeel opererende bedrijven, deze methode ook nog gingen gebruiken. Kortom, een investering in het onvolwassen houden van een toch niet onbelangrijk bedrijfsmiddel als de ICT.

Functioneel beheer zou niet meer moeten bestaan

De ICT is intussen een steeds sneller en krachtiger bedrijfsmiddel geworden met steeds meer mogelijkheden. Hierdoor is echter ook de complexiteit van de ICT-oplossingen en dus van het beheer sterk toegenomen. Er zijn allerlei specialisaties ontstaan. Voor de ICT-infrastructuur en de bedrijfsapplicaties van een middelgrote organisatie zijn er al gauw enkele tientallen leveranciers, die in de vorm van producten en diensten elk één of enkele stukjes van de puzzel leveren. (Zie ook ‘ICT en functioneel beheer steeds meer logistieke processen’.) Dat is op zich logisch. Banken bijvoorbeeld kopen ook al lang geen goud meer in om hun eigen munten te slaan. Nu is de belangrijkste grondstof voor het vervaardigen van een bankbiljet het katoenafval van de kledingindustrie. Maar banken bemoeien zich hier niet mee. Er is een keten ontstaan voor het produceren van papiergeld en banken weten alleen, dat ze euro’s kunnen kopen bij de Europese Centrale bank. Ook in de ICT zou iets dergelijks voor de hand liggen. De werkelijkheid is echter anders. De arme functioneel beheerders worden nog steeds geacht te brug te slaan tussen ICT-specialisten en de business met zijn vragen, met daartussenin een woud van dienstverleners. En die dienstverleners proberen allemaal geld te verdienen in de vorm van uren, omdat er slechts weinigen zijn, die het gehele speelveld kunnen overzien. De weinigen die het kunnen, hebben er vaak een persoonlijk belang bij dom de huidige situatie in de ICT met al haar imperfecties in stand te houden.

Dus functioneel beheer bestaat nog wel

De werkelijkheid is dus dat functioneel beheer nog steeds bestaat en zelfs belangrijker is geworden dan ooit, omdat bedrijven wanhopig blijven proberen om hun ICT ‘in control’ te krijgen. In theorie lijkt het zo gemakkelijk en aantrekkelijk. Functioneel beheer ingericht volgens BiSL als ketenregisseur, 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. En de echte ICT-specialisten zitten vaak in een ver land, verstopt achter allerlei verkooporganisaties. De baan van functioneel beheerder blijkt dan ook 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’.)
Dit probleem oplossen via een verdere professionalisering is weggegooid geld. In feite kan het simpel. Vrijwel alle componenten van de ICT-infrastructuur zijn of standaard of er zijn standaards voor verkrijgbaar. Als ICT niet uw ‘core business’ is, is het daarom onverstandig te investeren in het onderscheidend vermogen van uw ICT. U ontwerpt toch ook niet uw eigen lease-auto of uw koffieautomaat? Dat maakt immers het onderhoud en het beheer onnodig complex en daardoor kostbaar. Leveranciers van standaardcomponenten zijn uitwisselbaar. Zij moeten dus zien te overleven in een zeer competitieve markt. Zij moeten continu presteren om hun marktpositie te behouden. Ze zullen een goede dienstverlening moeten bieden tegen lage kosten. Doen ze dat niet, dan staan degenen die dat wel doen in de rij om het van hen over te nemen. In organisaties waar ICT niet core business is, zal het beheer zich daarom moeten richten op standaardisatie. Dan kan er slim ingekocht worden. En dan gaat het niet om het inkopen van puzzelstukjes in de vorm van hard- en software, maar om het inkopen van een compleet gelegde ICT-puzzel, zoveel mogelijk beheerd door een partij voor wie ICT core business is. Het inkoopbeleid zal dus gericht moeten zijn op inkoopkracht, op het inkopen van schaalvoordelen, en op het inkopen van competenties met betrekking tot operationele producten en diensten zoals ICT-beheer, functioneel beheer, software, security en technische infrastructuur. En functioneel beheerders kunnen successen boeken als super-users. (Zie ook ‘Wie verlost bedrijven van hun ICT-ers’.) Want die hebben bedrijven hard nodig. Niet om eisen en wensen te communiceren naar de ICT’ers. Maar juist om gebruikers te helpen het maximum te halen uit de standaard beschikbare ICT-middelen.

Afstemming standaardservice aan de gebruikers

Van belang is, dat ontwikkelingen niet gestart worden met een uitgebreide inventarisatie van wensen en eisen van de gebruikers. Het risico is dan veel te groot, dat er een waslijst met eisen ontstaat, die het onmogelijk maakt om nog een standaarddienst in te kopen. Het gaat om doelstellingen met een aantal knock-out criteria. Dat is de basis voor de selectie van een leverancier of oplossing. Een sprekend voorbeeld hiervan is beschreven in ‘Architectuur rondom ERP-software’. Daarbij zullen vooral ook de bestaande applicaties tegen het licht gehouden moeten worden, om te bepalen of ze eigenlijk nog wel nodig zijn. Van veel software die men vijf jaar geleden nog moest aanschaffen, bestaan nu volledige webbased versies, waarvoor slechts een browser nodig is om ze te draaien. Vaak wordt die software ook nog als freeware aangeboden. Hierdoor ontstaan mogelijkheden om ‘fat clients’ te vervangen door ‘thin clients’ en dus om te standaardiseren.Vaak stuit vervangen wel op enige weerstand bij gebruikers. Maar het argument, dat er ooit een goede reden was om de software aan te schaffen, snijdt geen hout. Het tegenargument is, dat op basis van zulke argumenten ooit uw eigen rommelzolder is ontstaan. En dat argument is vaak wel overtuigend. Zeker als er ook nog een kostenplaatje kan worden getoond, waarbij geen investeringen meer nodig zijn en er alleen nog betaald wordt voor het gebruik. (Zie ook ‘SaaS is voor de gebruiker meer dan alleen stroom uit het stopcontact’.)
Bij het functioneel beheer en het informatie management worden de eisen en wensen van de gebruikersorganisatie vertaald in een standaarddienstverlening. Eenvoudig te standaardiseren zijn het technisch beheer, het werkplekbeheer en zaken als telecom, beveiliging en continuïteit. De menukaart voor de klant voor dit soort zaken hoeft niet zo uitgebreid te zijn. Ingewikkelder zijn veelal het functioneel en technisch applicatiebeheer. De hiervoor benodigde kennis is vaak nogal specifiek en voer voor specialisten. Uiteindelijk leidt dit meestal tot outsourcing van het totale functioneel en technisch beheer en van het applicatiebeheer. Aan de klantkant wordt daarbij het hele ICT-beheer vaak uitgekleed tot een facilitair beheer organisatie met dikwijls een aantal ’super-users’ die afstemmen met de demand-organisatie als ’single point of contact’, dat zelfs ondergebracht kan worden in een bestaande afdeling voor facilitaire zaken. Het inrichten van de nieuwe situatie kan het best projectmatig aangepakt worden. Valkuil is dat er een belangrijk tegengesteld belang gemanaged moet worden:

• het scherp inkopen van de gewenste ICT-diensten, met onderhandelingen op het scherp van de snede;
• het opbouwen van een goede samenwerkingsrelatie met de toekomstige outsourcingspartner.

Door het inzetten van een onafhankelijke partij die namens de gebruikersorganisatie de demand organisatie inregelt, kan vermeden worden dat er gepolderd wordt. (Zie ook ‘Een project is toch geen democratie’.) Deze derde partij heeft doorgaans meer ervaring met het inkopen van ICT-diensten en is een passant, voor wie de eigen relatie met de toekomstige partners van minder belang is. Zo iemand kan zorgen voor scherpe overeenkomsten zonder overhead. De relatie tussen de gebruikersorganisatie en de beoogde leverancier hoeft zo niet te worden verstoord. Tevens kan deze partij als breekijzer optreden naar partijen die in de toekomst mogelijk onderdeel van de leveringsketen worden. Nadat het project is afgerond, verdwijnt deze derde partij en wordt facility management aanspreekpunt voor de demand organisatie. De vraag is dan natuurlijk waar het facility management wordt belegd. Veel organisaties laten de ICT-afdeling het facilty management invullen. In veel gevallen pakt deze keuze slecht uit. Inkopen is immers een proces waarmee de meeste ICT’ers weinig affiniteit hebben. Zij kicken te veel op technische hoogstandjes en te weinig op bedrijfseconomisch nut. De afdeling inkoop of facility management zal niet in deze valkuil trappen. Maar de inkoop van diensten waarvan de specificaties vooraf nog niet vaststaan, is voor dergelijke afdelingen vaak een brug te ver. Daarom adviseren wij om de aansturing van de demand organisatie in het begin te beleggen bij het tactisch functioneel beheer. Hier zit de affiniteit met de ICT, samen met voldoende inzicht in de business om evenwichtig diensten in te kunnen kopen, ook zonder vastgestelde specificaties. En de kaasschaaf werkt ook in de ICT niet. (Zie ook ‘De crisis heeft de ICT niet genoeg pijn gedaan’.)

Download:       

No related posts.

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

In veel organisaties heeft functioneel beheer de laatste tijd in toenemende mate aandacht gekregen. Voor consultants een belangrijke reden om een volledige methodiek te verzinnen, met alles erop en eraan. Zo  kunnen zij in elk geval inspelen op (of was het meeprofiteren van?) de behoefte van organisaties. Als snel zag BiSL het licht. Veel functioneel beheerders vragen zich nu met verbijstering af, hoe zij in het verleden ooit hun taak hebben kunnen vervullen. In feite is er echter niets nieuws onder de zon. In dit artikel willen we weer teruggaan naar de essentie van functioneel beheer. Ook nu is voor functioneel beheer nog steeds geen ingewikkelde methodiek nodig.
Twintig jaar geleden al hanteerden we modellen voor de ontwikkeling van de business alignment van ICT waarin een drietal fasen werd onderkend, namelijk het creëren van:

• technisch hoogwaardige ICT-oplossingen;
• ICT-oplossingen die gebruikers vragen;
• 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: 

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:

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:

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 ‘Tips voor een begrijpelijk SLA of ICT-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 ‘One-stop-shopmodel bij ICT toe aan herziening’.)
• 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 ‘Zeven tips voor het inkopen van ICT-projecten’.) 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:

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 beheerwebsite;
• 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:       

No related posts.

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 staan 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 informatiebehoefte en het bewaken van de geleverde ICT-dienstverlening. (Zie ook ‘Functioneel beheer wordt informatiemanagement.’) BiSL is een vrij nieuwe standaard, publiek domein geworden in 2005. Het raamwerk wordt ondersteund door een aantal best practices, waarmee men invulling kan geven aan functioneel beheer en informatiemanagement in een organisatie en 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.

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 het proces 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 van de uitwisseling met andere organisaties en van 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.

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. (Zie ook ‘ITIL3 is het einde van een tijdperk ’.) Want niemand zit tenslotte te wachten op een permanente stiptheidsactie.

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

Download:       

No related posts.