bislfoundation


 

Gebruikersondersteuning

Dit proces maakt onderdeel uit van het operationele procescluster Gebruiksbeheer. De naam van het proces geeft goed aan wat de inhoud van het proces omvat. Voor sommigen kan de naam toch verwarrend zijn door een gelijkende procesnaam in ASL: Gebruiksondersteuning. Toch is er uiteraard een verschil in ondersteuning van gebruikers en ondersteuning van het gebruik. Bovendien is dit proces aan de gebruikerszijde gepositioneerd, en het ASL-proces logischerwijs aan de IT-zijde.

Opmerking: Hieronder worden doel, activiteiten, resultaten en relaties van dit proces kort samengevat. Deze zijn uitgebreider te vinden in boeken die reeds op dit terrein zijn verschenen. Zie hiervoor de pagina boeken op deze website. Wat u in die boeken niet vindt en hieronder wel, zijn de KPI's, proces- en procedure schema's en ervaringen c.q. opmerkingen uit de praktijk.


Doel proces Gebruikersondersteuning

Het proces Gebruikersondersteuning heeft als doelstelling (eind)gebruikers optimaal met de bestaande informatievoorziening te laten werken.

In dit proces wordt binnen de klantorganisatie een aanspreekpunt gerealiseerd voor de (eind)gebruikers. Via dit aanspreekpunt (doorgaans key-users en/of functioneel beheerders) kunnen gebruikers alles wat hen belemmerd in het werk melden. Andersom kunnen vanuit Functioneel beheer oplossingen worden aangereikt, maar ook informatie over bijv. aankomende wijzigingen worden gecommuniceerd.


Activiteiten proces Gebruikersondersteuning

De activiteiten van het proces Gebruikersondersteuning vallen uiteen in de volgende drie:

1. Call-afhandeling
Alle calls, of het nu vragen, fouten, opdrachten of wensen zijn, komen hier binnen en worden hier geregistreerd. Vervolgens wordt gekeken naar de aard van de call en waar deze verder moet worden opgepakt (functioneel, technisch of applicatiebeheer). Een aantal calls zal dus door functioneel beheer geheel zelf worden afgehandeld. Tot slot wordt bij deze activiteit ook gezorgd voor terugkoppeling van de status van de call naar de gebruiker. Uiteindelijk wordt de call gesloten.

2. Communicatie
Behalve communicatie rondom calls, die onder eerstgenoemde activiteit vallen, is ook communicatie in de vorm van het informeren van gebruikers rondom wijzigingen in informatiesystemen nodig. Dat kan uiteraard op allerlei manieren: in een afdelingsoverleg, via een nieuwsbrief, een intranetpagina etc.

3. Call-rapportage
Van alle calls wordt een rapportage gemaakt om het proces goed te kunnen sturen. In de rapportage kan bijvoorbeeld onderscheid worden gemaakt naar aard en frequenties van calls, aantal calls dat intern is opgelost versus calls die zijn doorgestuurd naar IT, tijd en kosten etc.


Resultaten proces Gebruikersondersteuning

De resultaten van dit proces zijn dat gebruikers goed kunnen werken met het bestaande informatiesysteem, dat eventuele issues (calls) die ontstaan netjes worden afgehandeld en dat indien nodig informatie wordt verstrekt over komende aanpassingen. Bij elkaar zijn dit feitelijk geen bijzondere resultaten, en eigenlijk zou dit "heel gewoon" moeten zijn. De dagelijkse praktijk leert echter anders: het aantal gebruikers dat de bestaande systemen onvoldoende nuttig gebruikt, bij issues in de kou blijft staan en al lang de draad is kwijt geraakt van alle opeenvolgende wijzigingen is helaas vaak groot.

KPI's / rapportage items proces Gebruikersondersteuning

Voorbeelden van Key Performance Indicatoren (KPI's) voor het proces Gebruikersondersteuning zijn:
- Aantal nieuwe calls in periode (onderverdeeld in klantgroep/aard/ernst)
- Aantal afgehandelde calls in periode (onderverdeeld in klantgroep/aard/ernst)
- Aantal openstaande calls ultimo rapportageperiode
- Aantal naar IT doorgestuurde calls versus binnen Functioneel beheer afgehandelde calls
- Aantal calls met functionele vragen nadat een informatiesysteem is gewijzigd (meet kwaliteit van communicatie / informatievoorziening)

Deze KPI's kunnen uiteraard dienen als input voor een rapportage.


Relaties met andere processen / bedrijfsonderdelen

De andere twee processen binnen het cluster Gebruiksbeheer spelen uiteraard ook een rol bij de afhandeling van incidenten en communicatie over veranderingen in de werking van het informatiesysteem (bijv. door het aanpassen van parameters in het proces Beheer bedrijfsinformatie).

Soms kunnen calls leiden tot een wijziging waarmee direct de relatie met het proces Wijzigingenbeheer is gelegd. Andersom is ook hier weer de informatievoorziening richting eindgebruikers voor, tijdens en na uitvoering van een wijziging.

Voorbeelden van bedrijfsonderdelen/afdelingen waar belangrijke relaties zijn, zijn uiteraard de eigen gebruikersorganisatie en aan de andere kant de interne / externe IT-organisatie.


In de praktijk - Call afhandeling

Een voorbeeld van call-handeling is in dit schema te vinden:

Schema Call afhandeling

(klik op het plaatje om het te vergroten)


In de praktijk - Informatie en communicatie

Een voorbeeld van informatie en communicatie is in dit schema te vinden:

Schema Informatie en communicatie

(klik op het plaatje om het te vergroten)


In de praktijk - Call rapportage

Een voorbeeld van call rapportage is in dit schema te vinden:

Schema Call rapportage

(klik op het plaatje om het te vergroten)


Opmerkingen / bijzonderheden

In de praktijk kan verschil van inzicht bestaan in de positie en rol van key-users / super users versus de Service Desk die veelal aan de IT-zijde is ingericht. Natuurlijk kan het zo worden geregeld dat eindgebruikers altijd als eerste de (IT) Service Desk bellen. Deze filtert dan de vragen en de vragen van functionele aard die niet door de Service Desk zelf worden opgelost worden dan teruggelegd naar de key-user / superuser of de functioneel beheerder. In deze constructie fungeren de key-user / superuser c.q. functioneel beheerder feitelijk als een (2e lijns) oplosteam. Groot voordeel van deze constructie is dat de bereikbaarheid van de Service Desk vaak goed is geregeld, en de routering van de calls heel helder is.

Toch is de constructie waarbij eindgebruikers eerst contact opnemen met de key-user / super user ook zeker geen slechte. Daarbij worden door deze persoon de vragen gefilterd en omdat de key-user / super user letterlijk dicht bij de eindgebruikers staat wordt dit vaak als heel plezierig ervaren. De (continue) beschikbaarheid van key-users / super users op elke eindgebruikersafdeling is hier echter nogal eens een groot probleem.

Een derde optie, die in de praktijk ook succesvol wordt toegepast, is dat gebruikers zelf mogen bepalen of ze direct met de IT Service Desk contact opnemen of op de eigen afdeling bij de key-user of functioneel beheerder langs gaan. Het vereist uiteraard wel dat eindgebruikers kunnen inschatten wat de aard van de fout/vraag/etc. is, anders komen ze te vaak bij het "verkeerde loket" terecht en dat is dan juist weer niet zo efficiŽnt. Deze optie komt vaker voor bij bedrijven met goed opgeleide medewerkers met tevens een behoorlijke affiniteit met computerapparatuur.






Cursus BiSL Foundation



 

Cursus BiSL Foundation

BiSL workshops

Cursus BiSL Foundation

Cursus BiSL Foundation

 © 2007-2017 Tot Z Diensten BV   | Postbus 50 - 8120 JS Olst | 0570 - 560 404 | contact(@)totz.nl
 

 
Bron voor bepaalde inhoudelijke beschrijvingen: ASL BiSL Foundation en het boek Functioneel beheer volgens BiSL (Peter Janssen).
 
Aangezien Tot Z Diensten BV groot voorstander is van de Public Domain gedachte achter BiSL is toepassing voor eigen gebruik van alles wat u op deze site vindt altijd toegestaan zonder verdere toestemming of betaling.