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 ook 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. Maar het is toch zeker niet uitzonderlijk dat 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 ook nimmer gaan gebruiken. Dit taakgebied heeft dus naast een reactieve ook een proactieve component en ook een duidelijke link net het taakgebied Educatie. DEFINITIES Binnen het taakgebied Gebruikersondersteuning worden enige definities gebruikt. Degene die nog niet eerder ter sprake is gekomen, wordt hier genoemd. Definitie issue Een issue is een situatie waardoor bestaande computertechnologie in een productieomgeving niet conform afspraken kan worden gebruikt. Het kan hierbij gaan om een fout (functioneel of technisch van aard) of een vraag ("Hoe kan ik..."). Toelichting: Een issue kan worden geïnitieerd door een gebruiker, manager, een medewerker van functioneel support zelf, medewerkers van infra- en applicatie support, een externe leverancier of bijvoorbeeld een monitoring systeem. De bronnen van issues zijn dus divers, dat maakt voor de verdere afhandeling ervan geen verschil. Het betreft degradatie van functionaliteit. 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 control. Definitie Service Request Een Service Request is een aanvraag voor het 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 infra en applicatiesupport groep of de leverancier ingevuld, maar ook aan functioneel support kan meer 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 V1.0 Pagina 1
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 er toe 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 uitgevoerd via taakcluster Change control) om in het vervolg soortgelijke fouten te voorkomen. HOE WEET JE DAT HET DOEL IS BEREIKT? De volgende globale indicatoren zijn te benoemen om te weten of bovenstaande doel wordt bereikt: Alle issues zijn conform afspraken afgehandeld 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 Een aantal specifieke indicatoren die hiervoor als basis kunnen dienen: Aantal vragen / fouten (nieuw, opgelost, openstaand) per periode, per gebruikersgroep, per systeem 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 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: V1.0 Pagina 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. 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 loslaten. Issues kunnen binnenkomen via telefoon, fax, e-mail, 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 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 V1.0 Pagina 3
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 control. Uitgangspunt bij het beantwoorden van vragen is "Help me het zelf te kunnen". De vraag wordt dus beantwoord, maar zodanig dat de gebruiker in een eventueel volgend geval het ook zelf kan. 4. Eventueel aanvullen FAQ, wiki etc. Deze stap vormt samen met de volgende stap 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. Ook 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 wijzer 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 key-users en Functioneel specialisten hun kennis delen, moet worden bijgewerkt. 5. Educatie nodig / Educatie 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 modderen 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). 6. 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 wordt gevormd door de beantwoorde functionele vragen. Daarnaast komt er informatie beschikbaar over veel voorkomende vragen, zodat deze in taakcluster Change control kan worden geanalyseerd en eventueel via wijziging kan worden weggenomen. 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. V1.0 Pagina 4
2. Afhandelen van fouten: 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) anderzijds. In de hierna beschreven flow ligt de nadruk niet op het voorkomen van fouten, maar uitsluitend 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 Change control 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. V1.0 Pagina 5
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. 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 loslaten. In de intake wordt de fout verhelderd en compleet gemaakt. 2. Zelf afhandelen / Toewijzen aan collega / Toewijzen aan 2e lijns Afhankelijk van de fout wordt deze afgehandeld door degene die de intake heeft gedaan, of doorgezet naar een collega van functioneel, infra of applicatie support met meer specifieke kennis van zaken. Biedt dat ook geen soelaas, dan kan worden doorgezet naar de 2e lijns. Doorgaans zal de 2e lijns bestaan uit leveranciers. 3. 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 toch goed hier altijd meerdere oplossingen op een rij te zetten. Ook 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. 4. 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 infra of applicatie support of leveranciers wordt de besluitvorming beïnvloed vanwege effecten die onzichtbaar zijn voor de gebruiker: nadelen voor bijvoorbeeld de stabiliteit of onderhoudbaarheid van systemen op langere termijn. 5. 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 dat de oplossing toch niet het gewenste resultaat heeft gegeven (en teruggegaan moet worden naar stap 4 om een andere oplossing te kiezen). 6. Afsluiting Laatste check: zijn alle activiteiten voltooid, zijn de gebruikers tevreden? Het issue wordt vervolgens gesloten. Output De output wordt gevormd door de opgeloste fouten. Daarnaast komt er informatie beschikbaar over veel voorkomende fouten, die in taakcluster Change control kunnen worden geanalyseerd en eventueel via wijziging kunnen worden weggenomen. V1.0 Pagina 6
3. Afhandelen van Service Requests: 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 lokale contactpunt binnen de gebruikersgroep functioneert. Allereerst vindt ook hier registratie plaats, om later een en ander te kunnen nazoeken, een controle op de uitvoering te kunnen doen (voortgangsbewaking) en achteraf analyses te kunnen doen. 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. Met name wordt gekeken naar de relevante afspraken in contracten indien ook externe partijen betrokken zijn. Ook vanuit de infra 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 pasend 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. V1.0 Pagina 7
4. Uitvoeren Service Requests waarover positief is besloten worden uitgevoerd. Vanuit functioneel support zorgen 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 ook 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. OPMERKINGEN Over dit taakcluster, dat vrij bekend is en in de praktijk ook al veel 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 ook 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 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 ook 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 ook weer uitzonderingen op. Om maar een voorbeeld te geven: een baliemedewerker van een bank zal V1.0 Pagina 8
hopelijk maar zeer weinig te maken hebben met overvallen, fraude, agressieve klanten en dergelijke. En toch is het zinvol actuele kennis hiervan bij dergelijke functies te hebben en te 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 ook een proactieve taak: hoe kan het zo worden afhandelt 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 ook 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 ook 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 ook 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 bij de beantwoording van vragen ook iets moet worden geregistreerd. Deze kwestie wordt ingegeven door het feit dat veel vragen slechts weinig inspanning vereisen om te beantwoorden 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 blijven er veel komen en de registratie ervan blijft logischerwijs dan ook 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. V1.0 Pagina 9
4. ATTITUDE KEY-USERS 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. Hulpvaardigheid. De wil om te helpen is onmisbaar in deze rol. 2. Toegankelijkheid. Een key-user moet letterlijk eenvoudig benaderbaar zijn. Daarom is aanwezigheid op de afdeling het meest wenselijk. 3. 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. 4. Fingerspitzengefühl: Is hier niet meer aan de hand? 5. 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. 6. Prettig in de omgang, aardig. Een vraag of andere kwestie 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 ook vaak acuut actie op worden genomen. Met andere woorden: degene die naast het gewone werk ook key-user is, moet indien nodig meteen het gewone werk kunnen onderbreken om een gebruiker te helpen. Dat 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. 5. KLIK-CALL-FACE V1.0 Pagina 10
Bij het klik-call-face principe wordt er van gebruikers verwacht dat ze eerst zelf trachten oplossingen te vinden ( klik ). 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. En zijn ook daar de mogelijkheden uitgeput, dan wordt het tijd voor een face-to-face afspraak ( face ). Op zichzelf is het principe van zelfredzaamheid niet gek; er zijn genoeg kleinere issues die een gebruiker met een klein beetje moeite zelf kan oplossen. Het klik-call-face principe kan dus in principe de efficiency verhogen en ook het serviceniveau; een goed ingericht intranet doet het altijd, terwijl een Service Desk er doorgaans niet 24/7 is. Maar het klik-call-face verword helaas ook wel eens 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. Klik-call-face kan dus zeker een goed werkend principe zijn, maar het blijft oppassen. V1.0 Pagina 11