Taakgebied Gebruikersondersteuning

Transcriptie

1 Gebruikers vormen een lastige onderbreking van een verder best wel aardige werkdag (Bron: onbekend) Hoofdstuk 6 Taakgebied Gebruikersondersteuning V1.2 / 01 februari 2016

2 MCTL 6. v1.2 Geen copyright! MCTL is in licentie gegeven volgens een Creative Commons Naamsvermelding 3.0 Nederland licentie. Gebaseerd op een werk van MCTL is geheel Public Domain, er rusten dus geen copyright of auteursrechten op. U mag MCTL (ook commercieel) gebruiken, verwerken, bewerken.wat u maar wilt. Echter, indien iets eenmaal Public Domain is, blijft het Public Domain. Wat u dus niet mag doen is over (delen van) MCTL copyright of auteursrechten claimen, u maakt zich dan schuldig aan copyfraud. Tegen gevallen van copyfraud wordt daadwerkelijk opgetreden. Indien u zelf overtredingen constateert, vragen wij u dit via aan ons te melden. Wat wij van u vragen is om bij elk gebruik een verwijzing naar de bron: op te nemen. De reden hiervan is dat op deze wijze iedereen de oorspronkelijke versie(s) kan vinden. V Pagina 6-2

3 MCTL 6. v1.2 Hoofdstuk Plaats in het MCTL-framework... 4 Definities... 4 Doel van dit taakgebied... 5 Hoe weet je dat het doel is bereikt?... 5 Intermezzo: Waarom gestructureerd werken aan vraag- en foutvermindering... 6 Input, activiteiten, output... 8 Relaties met andere onderdelen van MCTL Opmerkingen Achtergrond functionele vragen Afhandelen functionele vragen: reactief en proactief Afhandelen vragen: alles registreren of niet Attitude key-users Organisatie eigen werk key-users Click-Call-Face Nuttige websites en boeken V Pagina 6-3

4 MCTL 6. v1.2 HOOFDSTUK 6 TAAKGEBIED GEBRUIKERSONDERSTEUNING Gebruikersondersteuning omvat precies wat de term aangeeft: ondersteuning van gebruikers bij het juist toepassen van computertechnologie tijdens de uitvoering van hun werk. Gebruikers zijn hierbij alle personen die computertechnologie gebruiken, dus over het algemeen zijn managers hier gewone gebruikers. Hoewel heel veel mensen computertechnologie tijdens hun werk gebruiken, verloopt dat helaas niet altijd even soepel. Om allerlei redenen kunnen er obstakels zijn waardoor gebruikers hulp nodig hebben. Van gebruikers mag worden verwacht dat zij, wanneer nodig, zelf hulp inroepen. Het is echter zeker geen uitzondering dat weliswaar geen hulp wordt gevraagd, maar toch kan worden geconstateerd dat verbeteringen in de uitvoering van het werk mogelijk zijn. Op het moment dat een gebruiker bepaalde functionaliteiten eenvoudigweg niet kent, zal deze gebruiker ze nimmer gaan gebruiken. Dit taakgebied heeft dus naast een reactieve ook een proactieve component en een duidelijke link met het taakgebied Educatie. PLAATS IN HET MCTL-FRAMEWORK Het taakgebied Gebruikersondersteuning maakt onderdeel uit van het taakcluster Operationeel support: DEFINITIES V Pagina 6-4

5 MCTL 6. v1.2 Binnen het taakgebied Gebruikersondersteuning worden enige definities gebruikt. Degenen die nog niet eerder ter sprake zijn gekomen, worden hier genoemd. Definitie issue Een issue is een situatie in een bedrijfsproces waardoor het juiste verloop van werkzaamheden wordt bedreigd. Het kan hierbij gaan om een fout (functioneel of technisch van aard), een vraag ("hoe kan ik...") of een service request ( er is tijdelijk iets anders nodig ). Een issue kan ook een wijziging betreffen, maar dat wordt in Change support verder opgepakt. Binnen Gebruikersondersteuning hebben we het over bestaande bedrijfsprocessen en bestaande systemen. Een issue kan worden geïnitieerd door een gebruiker, manager, een medewerker van functioneel support zelf, medewerkers van infrasupport en applicatie support, een externe leverancier of bijvoorbeeld een monitoring systeem. De bronnen van issues zijn dus divers, maar dat maakt voor de verdere afhandeling ervan geen verschil. Definitie vraag Indien een gebruiker belemmerd wordt in het werk doordat deze gebruiker iets niet weet / kan, dan spreken we van een vraag. Een vraag heeft vaak de vorm van Hoe kan ik... Een vraag is vanuit het bedrijfsproces gezien net zo belemmerend als een fout! Definitie fout Een fout is een degradatie van functionaliteit; iets werkt niet zoals is afgesproken. Een fout kan zowel technisch als functioneel van aard zijn. Indien een systeem wel conform afspraken werkt, maar er is behoefte aan aanpassing, dan spreken we van een wijziging. Wijzigingen worden behandeld in het taakcluster Change support. Definitie Service Request Een Service Request is een aanvraag voor het uitvoeren van extra werkzaamheden, het ter beschikking stellen van extra spullen, etc. Bijvoorbeeld kan een school in de examenperiode tijdelijk behoefte hebben aan extra faciliteiten. Deze worden deels door de infrasupport en applicatie support groep of de leverancier ingevuld, maar ook aan functioneel support kunnen meer diensten worden gevraagd zoals bijvoorbeeld tijdelijk meer of betere ondersteuning. DOEL VAN DIT TAAKGEBIED Het doel van gebruikersondersteuning is het conform afspraken afhandelen van issues. Met andere woorden: binnen afgesproken termijnen, kwaliteitsnormen en kosten zorgen dat fouten zijn hersteld en vragen zijn beantwoord. De operationele computertechnologie functioneert binnen het bedrijfsproces op voldoende goed niveau of andersom geredeneerd: het aantal fouten en de gevolgen daarvan liggen op een acceptabel niveau. Het juist afhandelen van functionele vragen leidt ertoe dat gebruikers op de juiste manier kunnen werken met het bestaande systeem. Het conform afspraken afhandelen van fouten in computersystemen (hard- en software) leidt tot het minimaliseren van schade. Indien nodig worden vervolgacties geïnitieerd (en evt. uitgevoerd in andere taakgebieden) om in het vervolg soortgelijke fouten te voorkomen. HOE WEET JE DAT HET DOEL IS BEREIKT? V Pagina 6-5

6 MCTL 6. v1.2 De volgende indicatoren zijn te benoemen om te weten of bovenstaande doel wordt bereikt: Alle issues zijn conform afspraken afgehandeld Het aantal herhaald opgetreden issues (die feitelijk voorkomen hadden kunnen worden) is < 5% van het totaal aantal opgetreden issues Vergeleken met voorgaande periode is het aantal issues gedaald (in het kader van voortdurende verbetering), tenzij er bijzondere redenen zijn zoals de invoering van een nieuwe functionaliteit of het optimum is bereikt, zie volgend punt De kosten van het afhandelen van issues, samen met de kosten van productiviteitsverlies aan de gebruikerszijde, zijn niet verder te verminderen door middel van zorgvuldiger uitvoeren wijzigingen of het verhogen van het kennisniveau / de zelfredzaamheid aan de gebruikerszijde (= er is sprake van een optimum) Aantal vragen die hebben geleid tot verbetering van bedrijfsproces / systeem / zelfredzaamheid gebruikers vergeleken met voorgaande periode Input die hiervoor als basis kan dienen: Aantal vragen / fouten (nieuw, opgelost, openstaand) per periode, per gebruikersgroep, per systeem Aantal herhaald opgetreden issues Aantal issues afgehandeld binnen afspraken, geëscaleerd, met gewijzigde afspraken Directe en indirecte kosten veroorzaakt door vragen en fouten Bestede uren / kosten voor oplossing van vragen / fouten Kosten die zijn voorkomen doordat fouten structureel zijn opgelost Aantal fouten / vragen first time solved Aantal vragen / fouten met oplossing die nieuwe vragen / fouten veroorzaakt Aantal vragen dat eerder is voorgekomen maar opnieuw wordt gesteld Aantal herhalende fouten INTERMEZZO: WAAROM GESTRUCTUREERD WERKEN AAN VRAAG- EN FOUTVERMINDERING De activiteiten in dit taakgebied zijn heel bekend en ook op talloze andere plaatsen terug te vinden. Belangrijkste verschil dat MCTL kent ten opzichte van de andere plaatsen waar deze activiteiten zijn te vinden is de grote nadruk op preventie; hoe kan worden voorkomen dat een vraag of fout nog eens optreedt? Deze preventieve insteek veroorzaakt in de afhandeling van vragen en fouten in eerste instantie meer werk. Het zal duidelijk zijn dat dit slechts een investering in de toekomst is, die ruimschoots wordt terugverdiend. Het is echter niet alleen een kwestie van investering versus kostenbesparing, maar indien niet structureel wordt gewerkt aan vraag- en foutvermindering ontstaat het volgende effect: V Pagina 6-6

7 MCTL 6. v1.2 In de loop der tijd zal steeds meer capaciteit besteed moeten worden aan het afhandelen van vragen en fouten. De grootste valkuil hierbij is nog wel dat op een zeker moment daar zoveel capaciteit mee gemoeid is, dat dan vanzelf de neiging zal ontstaan daar iets aan te gaan doen. Helaas de ruimte in capaciteit om op dat moment hieraan te gaan werken is dan juist heel klein geworden. De managementverzuchting. Toen we omkwamen in de fouten en dus hard moesten werken aan het structureel terugbrengen ervan, hadden we geen tijd. En nu we wel tijd hebben, is het niet meer nodig. Eenmaal beland in de neergaande spiraal van veel fouten, en daardoor snel oplossen met nog meer fouten tot gevolg, was het bijna onmogelijk dat ten goede te keren. Bij het structureel werken aan vraag- en foutvermindering zou in theorie dit plaatje ontstaan: In de praktijk zal, ook met het gestructureerd werken aan vraag- en foutvermindering, toch een zaagtandplaatje ontstaan. Dat wordt met name veroorzaakt door het introduceren van nieuwe systemen en het aanpassen van bestaande systemen. Als volgt: V Pagina 6-7

8 MCTL 6. v1.2 Conclusie: zelfs met structureel werken aan vraag- en foutvermindering zal de hoeveelheid hiermee gemoeide capaciteit waarschijnlijk niet structureel afnemen maar zich op een bepaald niveau stabiliseren. INPUT, ACTIVITEITEN, OUTPUT De activiteiten in dit taakgebied zijn te splitsen in het afhandelen van functionele vragen, het afhandelen van fouten en het afhandelen van service requests. 1. Afhandelen van vragen: V Pagina 6-8

9 MCTL 6. v1.2 Input De input is een issue van het type vraag vanuit de gebruiker. Activiteiten De activiteiten vallen uiteen in de navolgende: 1. Registratie en intake Een issue komt in principe altijd bij de key-user terecht, die als lokaal aanspreekpunt fungeert voor alle kwesties rondom inzet van computertechnologie op de afdeling. Er kan voor worden gekozen het eerste contact via de Service Desk te laten lopen. Er moet echter wel worden bedacht dat het hier functionele, inhoudelijke kwesties betreft waar een lokaal steunpunt in het algemeen zeer wordt gewaardeerd. Allereerst wordt het issue geregistreerd, om later een en ander te kunnen nazoeken, een controle op de uitvoering te kunnen doen (voortgangsbewaking) en achteraf analyses op alle gestelde vragen te kunnen doen. Issues kunnen binnenkomen via telefoon, fax, , webformulier, social media of mondeling contact, afhankelijk van de geboden mogelijkheden van de organisatie. Het verdient aanbeveling het aantal mogelijkheden niet al te zeer te beperken. In de intake wordt de vraag verhelderd en compleet gemaakt. 2. Zelf afhandelen / Toewijzen aan collega Afhankelijk van de vraag wordt deze afgehandeld door degene die de intake heeft gedaan of doorgezet naar een collega binnen functioneel support (of indien echt noodzakelijk bij infrasupport of applicatiesupport) met meer specifieke kennis van zaken. 3. Beantwoorden vraag De vraag wordt beantwoord en uiteraard wordt gecheckt of de beantwoording naar wens is. Eventueel kan hier een nieuw issue worden ingeschoten, bijvoorbeeld omdat de vraag wel is beantwoord maar meteen een volgende, andere kwestie naar boven komt. Het kan voorkomen dat een vraag wordt afgehandeld met een "functionele work-around", waardoor een gebruiker door kan met het werk. Achteraf moet dan een definitieve oplossing worden gedefinieerd, die vrijwel altijd een change tot gevolg heeft, veelal in het bedrijfsproces. Dit wordt dan opgepakt in het taakcluster Change support. Uitgangspunt bij het beantwoorden van vragen is "Help me het zelf te kunnen". De vraag wordt dus beantwoord, maar zodanig dat de gebruiker het in een eventueel volgend geval ook zelf kan (verhoging zelfredzaamheid). 4. Kans op herhaling? Hier wordt ingeschat of er een kans is op herhaling van de vraag. Zoals hierboven al geschetst bij stap 3 moet elke vraag zo worden beantwoord dat de betreffende gebruiker een eventueel volgende keer zichzelf kan helpen. Het kan echter een vraag betreffen die in de toekomst mogelijkerwijs ook bij andere gebruikers gaat spelen. Is dat niet het geval, dan wordt vervolgd met stap 7 (afsluiting), anders met stap Hoe te voorkomen? In deze stap wordt bepaald op welke wijze wordt voorkomen dat de betreffende vraag nog eens moet worden behandeld. Er zijn verschillende opties, zie stap 6, en welke daarvan zijn bij dit issue van toepassing? Aan het eind moet grote zekerheid bestaan dat met de gemaakte keuze inderdaad het beoogde doel wordt bereikt. V Pagina 6-9

10 MCTL 6. v Aanvullen FAQ, wiki, educatie en / of wijziging initiëren Deze stap vormt de kern van het proactieve onderdeel van dit proces. Hier wordt bekeken of de vraag aanleiding is om te zorgen dat niet alleen de vraagsteller nu is geholpen, maar in de toekomst ook andere gebruikers direct, snel en efficiënt kunnen worden geholpen. Te denken valt aan het bijwerken van een FAQ of wiki op een intranet. Er kan worden gestimuleerd dat gebruikers zelf hun kennis en ervaring delen zodat ze elkaar helpen. Overigens zijn er oplossingen / antwoorden die zoveel inspanning of basiskennis vragen van een gemiddelde gebruiker, dat het verstandiger is om ook een eventueel volgende keer een key-user of functioneel specialist in te schakelen om de oplossing te implementeren. Daarnaast komt het voor dat een key-user en functioneel specialist als enige iets wel kunnen oplossen omdat ze bijvoorbeeld meer autorisaties hebben. In dit soort situaties kan worden bezien of de besloten wiki (o.i.d.), waarin keyusers en functioneel specialisten hun kennis delen, moet worden bijgewerkt. Er vindt een check plaats of met de losse beantwoording van de vraag de gebruiker uit de voeten kan. Het komt voor dat gebruikers een vraag stellen waaruit blijkt dat ze eigenlijk te weinig basiskennis bezitten en al snel de volgende vraag zal ontstaan (of erger nog, ze durven uiteindelijk geen contact meer op te nemen en gaan zelfstandig rommelen met het systeem). Het is de taak van degene die de vraag afhandelt om de juiste vervolgactie te initiëren richting aanvullende educatie (zie taakgebied Educatie). Tot slot kan het voorkomen dat vragen ontstaan omdat (een onderdeel) van een systeem onlogisch is opgebouwd, verwarrende termen bevat, te complex is, etc. Met andere woorden: het systeem op zichzelf zorgt voor een voortdurende stroom vragen. In dat geval ligt het voor de hand als proactieve actie een wijziging van het systeem te initiëren. Omdat dergelijke aanpassingen een lange doorlooptijd kunnen hebben, kan het in dit soort gevallen heel nuttig zijn tegelijkertijd voor de korte termijn in een FAQ de nodige hulp op te nemen zodat het huidige systeem beter bruikbaar wordt. Structurele verbetering naar aanleiding van afhandeling functionele vragen. Voorbeeld: Stel dat 60% van de vragen gaat over twee invoerschermen of over een bepaalde berekening. Dan is dat een mooie aanleiding om de vormgeving van de schermen te verbeteren, de termen te veranderen, etc. of, in het tweede geval, om de berekening met tussenstappen meer inzichtelijk te maken. 7. Afsluiting Een laatste check vindt plaats: Alles in orde, gebruiker tevreden, activiteiten allemaal voltooid, geen losse eindjes meer? Het issue wordt gesloten. Output De output bestaat uit beantwoorde functionele vragen, waar mogelijk structurele verbeteringen in de ondersteuning naar gebruikers en wijzigingsvoorstellen voor structurele aanpassing van systemen ter voorkoming van vragen. 2. Afhandelen van fouten: V Pagina 6-10

11 MCTL 6. v1.2 Gevoelsmatig vinden veel mensen dat computertechnologie foutloos moet functioneren. Rationeel moet echter altijd een afweging worden gemaakt tussen de kans op fouten en de kosten voor foutreductie enerzijds en de kosten voor het systeemherstel + gevolgkosten (bijv. kosten van stilstand van het bedrijfsproces, imagoschade) anderzijds. In de hierna beschreven flow ligt de nadruk in eerste instantie op het reactief herstel van geconstateerde fouten en het beperken van de gevolgen. Voor zover proactieve acties (verbeteringen) nuttig zijn, worden deze hier wel geïnitieerd maar in Educatie en Change support verder afgehandeld. De waarde van onderstaande flow is dat vanuit het bedrijfsproces zekerheid bestaat dat er een geoliede, juiste set activiteiten kan worden opgestart indien een fout aan het voetlicht treedt. Natuurlijk moet bij elke fout een bedrijfseconomische afweging worden gemaakt en zal uiteindelijk niet elke fout worden opgelost. De oplossing is dan feitelijk: niets doen. Input De input is een issue van het type fout vanuit de gebruiker. Activiteiten De activiteiten vallen uiteen in de navolgende: 1. Registratie en intake Een issue komt standaard als eerste bij de key-user terecht, die als lokaal contactpunt fungeert binnen de gebruikersgroep. Evenals bij de afhandeling van vragen, kan worden gekozen voor een Service Desk als eerste contactpunt. Zie aldaar voor meer informatie over de rol van de Service Desk op dit V Pagina 6-11

12 MCTL 6. v1.2 vlak. Allereerst wordt het issue geregistreerd, om later een en ander te kunnen nazoeken, een controle op de uitvoering te kunnen doen (voortgangsbewaking) en achteraf analyses op alle gemelde fouten te kunnen doen. In de intake wordt de fout verhelderd en compleet gemaakt. 2. Zelf afhandelen / Toewijzen aan collega Afhankelijk van de fout wordt deze afgehandeld door degene die de intake heeft gedaan of doorgezet naar een collega van infrasupport, functioneel of applicatie support met meer specifieke kennis van zaken. Biedt dat geen soelaas, dan kan worden doorgezet naar de 2e lijns, zie punt 3 hierna. 3. Zelf afhandelen / Toewijzen aan 2e lijns Indien het intern met de groep medewerkers infrasupport, functioneel of applicatie support niet lukt de fout af te handelen kan de 2 e lijns worden ingeschakeld. Doorgaans zal de 2e lijns bestaan uit leveranciers. Deze leveranciers kunnen als het goed is natuurlijk technisch van dienst zijn, maar steeds vaker ook functioneel. Ze vormen hiermee het vangnet voor het interne functionele support, zoals ze dat al veel langer op technisch gebied doen. Leveranciers hebben meer klanten, vaak in dezelfde branche. Functioneel komen, net als in de techniek, diverse vragen en fouten vaker voor en door hun kennis van de hele klantgroep is het voor leveranciers mogelijk sommige fouten eenvoudiger op te lossen ( Dit hebben we al bij X meegemaakt en opgelost, deze oplossing kan ook bij Y werken ). 4. Inventariseren oplossingen Er wordt bezien welke oplossingen mogelijk zijn. Vrijwel altijd zijn er meerdere oplossingen te vinden. Hoewel het kan voorkomen dat één van de oplossingen ten opzichte van de andere erg aantrekkelijk is of de sterke persoonlijke voorkeur van de oplosser heeft, is het hier altijd de bedoeling alle oplossingen objectief te beoordelen. Het is het aan te bevelen om de gebruiker te betrekken bij de keuze van de oplossing, omdat hierdoor de noodzaak ontstaat alle consequenties van de verschillende oplossingen scherp te hebben. Soms is een tijdelijke oplossing mogelijk (work-around), zodat een gebruiker kan doorwerken zonder dat de fout structureel is opgelost. Er dient dan een nieuw issue te worden ingeschoten om een definitieve oplossing te (laten) creëren. 5. Keuze oplossing De keuze van de oplossing wordt vooral bepaald door de consequenties van de oplossing voor het bedrijfsproces. Hoe eerder een gebruiker weer aan de slag kan en / of hoe minder negatieve effecten een oplossing heeft op het verdere verloop van het bedrijfsproces, hoe beter. Vanuit de collega s van infrasupport, applicatie support of leveranciers wordt de besluitvorming beïnvloed vanwege effecten die onzichtbaar zijn voor de gebruiker maar toch wel van belang: nadelen voor bijvoorbeeld de stabiliteit of onderhoudbaarheid van systemen op langere termijn. 6. Toepassen oplossing De gekozen oplossing wordt toegepast en het resultaat gecontroleerd. Indien het resultaat niet naar verwachting is, dan wordt beoordeeld of de oplossing onjuist is aangebracht (en dus alsnog goed moet worden uitgevoerd) ofwel toch niet het gewenste resultaat heeft gegeven (en teruggegaan moet worden naar stap 4 om een andere oplossing te kiezen). 7. Kans op herhaling? In deze stap wordt bepaald of de fout zich kan herhalen. Veel oplossingen die in de voorgaande stap worden toegepast zijn zodanig dat de gemelde fout eenvoudigweg niet meer voor kán komen. Is dat het geval, dan wordt hierna via stap 10 het issue afgesloten. Het kan echter voorkomen dat er een oplossing is gekozen die er wel voor zorgt dat de gebruiker weer kan werken maar dat de fout feitelijk niet definitief is opgelost. Er worden dan hier meteen vervolgstappen genomen om wel tot een definitieve oplossing te komen. V Pagina 6-12

13 MCTL 6. v Onderzoek In deze stap wordt bepaald op welke wijze wordt voorkomen dat de betreffende fout nog eens moet worden behandeld. Er zijn verschillende opties, zie stap 6, en welke daarvan zijn bij dit issue van toepassing? Aan het eind moet grote zekerheid bestaan dat met de gemaakte keuze inderdaad het beoogde doel wordt bereikt. 9. Keuze definitieve oplossing In deze stap wordt de definitieve oplossing bepaald. De opties zijn terug te vinden in stap 10. De gemaakte keuze moet grote zekerheid bieden dat de fout zich inderdaad in de toekomst niet meer voor kan doen. 10. Educatie en / of wijziging initiëren Deze stap vormt de kern van het proactieve onderdeel van dit proces. De definitieve oplossing, waardoor een fout niet meer zal optreden, is hier doorgaans een aanpassing van het systeem. Deze aanpassing wordt dan hier uitgewerkt en passende acties richting het taakcluster Change support worden geïnitieerd. Het kan echter ook voorkomen dat fouten worden veroorzaakt door kennisgebrek, te weinig of onjuiste documentatie, etc. In dat geval moet de definitieve oplossing in het taakgebied Educatie plaatsvinden waarbij in deze stap de initiatie van de benodigde acties plaatsvindt. De daadwerkelijke uitvoering wordt dan logischerwijs binnen taakgebied Educatie gedaan. 11. Afsluiting Het uitvoeren van een laatste check: zijn alle activiteiten voltooid, zijn de gebruikers tevreden? Het issue wordt vervolgens gesloten. Output De output wordt gevormd door de opgeloste fouten, waar nodig het initiëren van (aanvullende) educatie richting gebruikers en wijzigingsvoorstellen voor structurele aanpassing van systemen ter voorkoming van fouten. 3. Afhandelen van Service Requests: V Pagina 6-13

14 MCTL 6. v1.2 Input De input is een Service Request vanuit de gebruiker. Activiteiten De activiteiten vallen uiteen in de navolgende: 1. Registratie Een Service Request komt standaard binnen bij de key-user, die immers als lokaal contactpunt binnen de gebruikersgroep functioneert. Zoals bij de afhandeling van vragen en fouten al beschreven kan ervoor worden gekozen de Service Desk als eerste contactpunt te laten functioneren. Allereerst vindt hier registratie plaats om later een en ander te kunnen nazoeken, de uitvoering te kunnen bewaken en achteraf analyses te kunnen doen voor verdere verbetering. In de intake wordt het Service Request voor zover nodig verhelderd en compleet gemaakt. 2. Controle Er vindt een controle plaats op de juistheid en haalbaarheid van het Service Request. Indien externe partijen betrokken zijn wordt gekeken naar de relevante afspraken in contracten. Vanuit de infrasupport en applicatie support kan worden gekeken naar de haalbaarheid en worden meegedacht in de optimale uitvoering van het Service Request. 3. Akkoord ja / nee? Over een Service Request, evt. voorzien van een preadvies en passend in de afspraken (of zijn er eventueel aanvullende afspraken te maken), moet een beslissing worden genomen. De indiener van het Service Request is daartoe in eerste instantie gerechtigd. Wordt het Service Request hier afgewezen, dan wordt dat geregistreerd en daarna wordt de aanvraag afgesloten. 4. Uitvoeren Service Requests waarover positief is besloten worden uitgevoerd. Vanuit functioneel support zorgen V Pagina 6-14

15 MCTL 6. v1.2 de key-user en / of functioneel specialist ervoor dat de activiteiten worden uitgevoerd, voor zover ze dat niet zelf moeten doen. 5. Controle op uitvoering De controle op de uitvoering wordt doorgaans gedaan door de key-user of functioneel specialist (beheerder). Eventueel wordt de uitvoering bijgestuurd, of in het uiterste geval teruggegaan naar stap 3 en het besluit heroverwogen. 6. Afsluiten Laatste check: zijn alle activiteiten voltooid, zijn de gebruikers tevreden? Het Service Request wordt vervolgens gesloten. Output De output wordt gevormd door afgehandelde Service Requests. Dit kan input vormen voor de processen Capaciteitsmanagement en Financieel management zodat voor het afhandelen van Service Requests voldoende tijd en geld beschikbaar wordt gesteld. RELATIES MET ANDERE ONDERDELEN VAN MCTL Dit taakgebied kent de volgende belangrijke relaties: Ten eerste is er een duidelijke relatie met Security, Managementinformatie, Databeheer en Educatie. Aanvragen voor accounts, niet-standaard data-overzichten, aanpassingen van productiedata alsmede educatie zullen bij Gebruikersondersteuning binnenkomen. Deze aanvragen worden in de respectievelijke taakgebieden afgehandeld. V Pagina 6-15

16 MCTL 6. v1.2 Daarnaast is er een belangrijke relatie met het taakcluster Change support. Dit taakgebied komt in beeld voor het oplossen van sommige fouten, maar vooral in het proactieve gedeelte waar acties worden uitgezet om vragen en fouten in de toekomst te voorkomen. Er bestaat een relatie met het bovenliggende taakgebied Behoeftemanagement omdat voor het komend jaar de behoefte zal blijven bestaan om vragen, fouten en service requests af te handelen. Stel dat komend jaar veel aanpassingen (vernieuwing, uitbreiding) op het programma staan, dan zullen er hoogstwaarschijnlijk meer vragen zijn en een piek in het aantal foutmeldingen ontstaan. Zeker bij systemen die al wat langere tijd bestaan is er een vrij contant vraag- en foutniveau, dat, hoe proactief er ook wordt gewerkt, uiteindelijk niet meer substantieel omlaag kan worden gebracht. Het is zeker mogelijk om in een komend jaar in Behoeftemanagement bewust de focus op andere werkzaamheden te richten. Dit gaat dan ten koste van Gebruikersondersteuning, wat zich vaak uit in langere doorlooptijden, nog meer overlaten aan de klant (vragen die opzoekbaar zijn worden niet meer in behandeling genomen), of het simpelweg niet meer uitvoeren van werkzaamheden (bijv. het systeem wordt bevroren en service requests worden niet uitgevoerd tenzij absoluut noodzakelijk, omdat anders de continuïteit van de organisatie in het geding komt). Tot slot zijn er relaties met de taakgebieden uit taakcluster Management support. Voor de operationele uitvoering van het taakgebied Gebruikersondersteuning is geld en (mens)capaciteit benodigd, en kwaliteitsnormen bepalen het te halen niveau van de werkzaamheden. Hier kan en moet uiteraard op worden gestuurd en eventueel bijgestuurd. OPMERKINGEN Over dit taakgebied, dat vrij bekend is en in de praktijk in allerlei vormen wordt toegepast, zijn nog de volgende opmerkingen te maken. 1. ACHTERGROND FUNCTIONELE VRAGEN Functionele vragen zijn vaak van het type "Hoe kan ik". Uitgangspunt is dat een gebruiker precies de kennis heeft om het eigen werk geheel zelfstandig te kunnen uitvoeren (zie taakgebied Educatie). Toch kan het om allerlei redenen zo zijn dat een gebruiker even iets niet weet. Doordat bijvoorbeeld de functie heel breed is en heel veel kennis vergt of het de gebruiker simpelweg is ontschoten, of dat werkzaamheden moeten worden gedaan die slechts sporadisch voorkomen. Dan kan het zelfs efficiënt zijn om die kennis niet permanent bij elke gebruiker actueel te hebben, maar om die kennis te concentreren bij senior medewerkers of zelfs bij een ondersteunende externe partij. Zij kunnen deze kennis dan vaker bij meerdere gebruikers inzetten waardoor ze het veel beter "in de vingers" hebben en de totale benodigde kosten voor opbouw en bijhouden van de kennis zo laag mogelijk zijn. Een dergelijke werkwijze wordt in de praktijk wel geregeld via een Business support desk. Die vormt in het geval van grote homogene groepen gebruikers feitelijk de 2e lijn op kennisgebied in de gebruikersorganisatie. Een uitzondering bestaat op alles... Een strategie om kennis van weinig voorkomende werkzaamheden te concentreren bij slechts enkele (senior) medewerkers kan heel efficiënt zijn. Toch zijn hier vanzelfsprekend uitzonderingen op. Om maar een voorbeeld te geven: een baliemedewerker van een bank zal hopelijk maar zeer weinig te maken hebben met overvallen, fraude, agressieve klanten en V Pagina 6-16

17 MCTL 6. v1.2 dergelijke. En toch is het logisch dat elke baliemedewerker hiervan actuele kennis heeft en dat die kennis ook wordt onderhouden. 2. AFHANDELEN FUNCTIONELE VRAGEN: REACTIEF EN PROACTIEF In eerste instantie is het afhandelen van functionele vragen reactief: een vraag moet eerst ontstaan bij gebruikers voordat actie wordt ondernomen. In tweede instantie heeft het taakgebied Gebruikersondersteuning op het vlak van functionele vragen een proactieve taak: hoe kan het zo worden afgehandeld dat de vraag niet nog eens voorkomt? Indien het een vraag is gerelateerd aan sporadisch voorkomende taken, dan is dit veelal een zinloze exercitie: tegen de tijd dat de taak nog eens wordt uitgevoerd, is de kennis alweer weggezakt. Maar in andere gevallen zou de insteek richting gebruikers moeten zijn: "Help me het zelf te doen". Dit kan als volgt worden opgepakt: 1. Ten eerste richting vraagsteller: hoe kan de vraag zo worden beantwoord dat de vraagsteller nooit meer dezelfde vraag zal stellen? 2. Ten tweede richting overige gebruikers: hoe kan worden voorkomen dat anderen dezelfde vraag stellen? --> Informatie op FAQ, wiki, etc. aanvullen. Daarbij moet het gebruik van dergelijke bronnen worden bevorderd, bijvoorbeeld door er voortdurend naar te verwijzen of door een systematiek te bedenken dat gebruikers op natuurlijke wijze eerst langs deze bronnen worden geleid voordat ze een beroep kunnen doen op de key-users en functioneel specialisten. 3. Ten derde richting structurele verbetering: kan ergens een verbetering in het systeem worden aangebracht zodat deze vraag en gerelateerde vragen niet meer worden gesteld? Systemen, ook zeer complexe, kunnen zo worden gebouwd dat ze zonder grote hoeveelheden kennis en ervaring kunnen worden gebruikt. Webshops en boekingssystemen op internet zijn daarvan fraaie voorbeelden: complexe technologie is voor internetgebruikers bruikbaar zonder dat ze zelfs maar één regel handleiding hoeven te lezen. 3. AFHANDELEN VRAGEN: ALLES REGISTREREN OF NIET Een punt dat in de praktijk tot veel discussie leidt, is of in het geval van het stellen en direct beantwoorden van vragen iets moet worden geregistreerd. Deze kwestie wordt ingegeven door het feit dat afhandeling van de meeste vragen slechts weinig inspanning vereist en registratie dan een substantieel deel van de bestede tijd gaat vergen. MCTL neemt hierover een uitgesproken standpunt in: alle vragen worden geregistreerd. Belangrijke reden is dat dit de basis vormt om het aantal vragen effectief terug te dringen. Bovendien ontstaat er op natuurlijke wijze "druk" op het proactieve gedeelte van dit proces, het voorkomen van vragen. Wordt immers te weinig gedaan aan het voorkomen van vragen, dan blijft de instroom hoog en de registratie ervan blijft logischerwijs veel tijd vergen. Tot slot kan de registratie worden gebruikt voor het afleggen van verantwoording: het inzichtelijk maken van de aan deze activiteit bestede tijd. 4. ATTITUDE KEY-USERS V Pagina 6-17

18 MCTL 6. v1.2 Key-users zijn over het algemeen senior medewerkers die op een afdeling een aantal uren per week de gebruikers van die afdeling ondersteunen. Een juiste attitude is daarbij essentieel. Daaronder worden de volgende elementen verstaan: 1. Doel- en gebruikersgerichtheid; bedrijfsprocessen draaien mede om mensen. Om bedrijfsdoelen te bereiken moeten gebruikers dus hun werk goed kunnen doen en als keyuser ben je daarin de achtervang. 2. Hulpvaardigheid. De wil om te helpen is onmisbaar in deze rol. 3. Toegankelijkheid. Een key-user moet letterlijk eenvoudig benaderbaar zijn. Daarom is aanwezigheid op de afdeling het meest wenselijk. 4. Didactische vaardigheden. In verband met het overbrengen van stukjes kennis zijn enige didactische vaardigheden een vereiste. Het to-the-point een gebruiker op het juiste spoor zetten en gemaakte fouten corrigeren vergt het een en ander van de key-user. 5. Fingerspitzengefühl: Is hier niet meer aan de hand? Het wordt wel het niet pluis gevoel genoemd. Hoewel subjectief, zijn er mensen die dit van nature in sterke mate bezitten. Er moet in ieder geval ruimte zijn voor dit soort in eerste instantie soms moeilijk grijpbare gedachten. 6. Geduld: Soms lukt het niet om in één keer iets uitgelegd te krijgen. In dat geval moet de "zender" (key-user) een andere manier vinden om toch de juiste info bij de "ontvanger" (gebruiker) te laten landen. Ook bij overleg met infra en applicatie support, andere key-users, functioneel specialisten en management i.v.m. bijvoorbeeld fouten of wijzigingen, is geduld nog wel eens nodig. 7. Prettig in de omgang, aardig. Een issue moet zodanig worden afgehandeld dat een gebruiker zonder aarzeling de key-user nog eens zal benaderen voor een andere kwestie. 5. ORGANISATIE EIGEN WERK KEY-USERS Key -users zijn over het algemeen senior medewerkers op een afdeling die "gewoon" meewerken op een afdeling en daarnaast een aantal uren per week het key-userschap vervullen. Omdat ze al langer op de afdeling werken, zijn ze al vaker betrokken geweest bij zaken die de computertechnologie raken en hebben ze op natuurlijke wijze een kennisvoorsprong opgebouwd ten opzichte van collega's. Deze kennisvoorsprong kan goed worden benut. Echter, het juist invullen van het key-userschap vergt enige aanpassingen in de organisatie van het werk van de betreffende senior medewerkers. Functionele vragen, maar ook fouten, treden immers zonder vooraankondiging op. En daar moet vaak acuut actie op worden genomen. Met andere woorden: degene die naast het dagelijkse werk ook key-user is, moet indien nodig meteen dat dagelijkse werk kunnen onderbreken om een gebruiker te helpen. Het is eenvoudigweg een kwestie van organiseren. Een hele dag volplannen met niet te verschuiven / onderbreken activiteiten is niet te combineren met de rol van key-user. Tenzij een andere key-user die dag kan bijspringen... Behalve key-users zelf moet ook het management van de afdeling zich van deze consequentie van het keyuserschap bewust zijn. Dit aspect is vergelijkbaar met de situatie dat een werknemer naast het gewone werk ook bedrijfshulpverlener is (BHV er) is, of lid van de vrijwillige brandweer in zijn woonplaats. Ook daar moet toch totaal onverwacht tijd voor vrij worden gemaakt: het gewone werk moet letterlijk van de een op de andere seconde terzijde worden geschoven. V Pagina 6-18

19 MCTL 6. v CLICK-CALL-FACE Bij het click-call-face principe wordt er van gebruikers verwacht dat ze eerst zelf trachten oplossingen te vinden ( click ). Bijvoorbeeld via een intranet waar een heel kennissysteem is opgetuigd met veel voorkomende vragen en bijbehorende antwoorden en dergelijke. Helpt dat niet, dan kan een gebruiker bellen met een Service desk ( call ), die dan zal assisteren. Zijn ook daar de mogelijkheden uitgeput, dan wordt het tijd voor een face-to-face afspraak ( face ). Op zichzelf is het principe van zelfredzaamheid aanbevelenswaardig; er zijn genoeg kleinere issues die een gebruiker met een klein beetje moeite zelf kan oplossen. Het click-call-face principe kan dus in principe de efficiency en het serviceniveau verhogen; een goed ingericht intranet doet het altijd, terwijl een Service Desk er doorgaans niet 24/7 is. Maar het click-call-face verwordt helaas weleens tot ordinaire bezuiniging. Waarbij de zichtbare bezuiniging (minder Service Desk medewerkers) wel wordt ingeboekt, maar de onzichtbare kosten van medewerkers die veel langer bezig zijn bij het oplossen van de issues die zij hebben, natuurlijk buiten beeld blijven. Een betere benaming is dan click-call-face-lost. Click-call-face kan dus zeker een goed werkend principe zijn, de toepassing ervan kent de nodige valkuilen. NUTTIGE WEBSITES EN BOEKEN De volgende websites zijn voor taakgebied Gebruikersondersteuning (vanuit functioneel oogpunt gezien) interessant: MCTL.nl Website met alle informatie over MCTL; de achtergrond, een beschrijving van het model, video s, artikelen, etc. etc. Alle documenten, waaronder dit document, zijn vanaf deze website te downloaden. BiSL.nl Website met alle informatie over BiSL. BiSL is, als voorganger van MCTL, interessant vanwege de verzameling Best Practices, whitepapers en artikelen die op deze website zijn te vinden. FSM Website met alle informatie over FSM. FSM is een compacte out-of-the-box versie van BiSL. De praktische vertaling in dit model is absoluut de moeite waard. V Pagina 6-19