Op Facebook zie ik regelmatig de Anglo-EU Translation Guide voorbij komen. Dit is een hilarisch lijstje met in de eerste kolom uitspraken van een Engelsman (bijvoorbeeld: 'That is very interesting'), in de tweede kolom wat hij eigenlijk bedoelt ('That is clearly nonsense') en in de derde kolom wat anderen horen ('They are impressed'). Voor mensen die veel zaken doen met Engelssprekenden, zullen de genoemde voorbeelden een feest der herkenning zijn.
Ook in de communicatie tussen aanbieders van it-diensten en hun klanten zien we vaak een vergelijkbare spraakverwarring ontstaan. De meeste klanten nemen de uitleg van een leverancier over de complexe it-werkzaamheden in hun backoffice misschien nog wel voor lief. Maar als het gaat om de frontoffice heeft iedereen er gelijk een mening over.
Niet dezelfde taal
Vraag een willekeurige klant maar eens naar zijn persoonlijke ervaring met de dienstverlening van een servicedesk. Je zult merken dat vooral de negatieve ervaringen breed worden uitgemeten. Het is dan ook niet verwonderlijk dat zowel klant als leverancier zoveel mogelijk harde, meetbare afspraken maken en daar maandelijks op rapporteren. Hier ontstaat naar mijn mening vaak de spraakverwarring. De partijen spreken namelijk niet dezelfde taal. Niet alleen wordt er in de it veelvuldig gebruikt gemaakt van Engelse terminologie en afkortingen, maar ook binnen de it zelf worden dezelfde begrippen vaak volledig verschillend uitgelegd.
Een typische voorbeeld hiervan is de average speed of answer. De leverancier zegt dat een telefoontje binnen dertig seconden wordt beantwoord. Wat hij bedoelt is dat hij een automated call distribution (acd)-systeem inricht, al dan niet in combinatie met een interactive voice response (ivr)-oplossing. De klant hoort echter dat zijn/haar telefoontje altijd direct wordt beantwoord door een servicedesk-medewerker. Nog los van het feit dat er vaak te gemakkelijk over het woordje ‘gemiddeld’ wordt heengestapt, ontstaat er spraakverwarring rond de acd/ivr. In veel gevallen is het prima te verantwoorden om een acd/ivr in te richten, maar dan is het wél zaak om helder af te stemmen vanaf welk moment de klok gaat lopen. Is dit vanaf het moment van verbinding maken met de acd/ivr, vanaf het moment dat de klant de keuze in het menu heeft gemaakt of daadwerkelijk vanaf het moment dat de klant een medewerker aan de telefoon krijgt?
Response time
Een ander goed voorbeeld is de response time. De leverancier zegt dat iedere e-mail of online vraag binnen vier uur een reactie krijgt. Wat hij bedoelt is dat er eerst een automatische e-mail met een ontvangstbevestiging wordt verstuurd en dat er pas in tweede instantie contact wordt gezocht met de klant. Wat de klant hoort is dat hij binnen vier uur een oplossing heeft voor zijn/haar gemelde incident. De praktijk op een servicedesk is echter dat incidenten die via e-mail of web worden aangemeld over het algemeen als minder urgent worden gezien en daarom vaak pas op een rustig moment worden bekeken. Wanneer de klant een reactie krijgt, hoeft dat vervolgens niet te betekenen dat er ook direct een oplossing voor het gemelde incident wordt geboden. Vaak is een wedervraag of aanvullende informatie nodig om het incident op te kunnen lossen.
Of wat te denken van de first time fix? De leverancier zegt dat een aangemeld incident in 85 procent van de gevallen door de servicedesk wordt opgelost. Wat hij bedoelt is dat het geregistreerde incident binnen de servicedesk-omgeving blijft, zonder dat het incident wordt doorgezet naar een tweedelijns oplosgroep. De klant zal denken dat zijn incident direct, telefonisch wordt opgelost. Ook hier geldt dat het goed te verantwoorden is wanneer een servicedesk-medewerker aanvullend uitzoekwerk doet op een rustiger tijdstip en vervolgens de klant terugbelt (afhankelijk van het gekozen servicedesk-model). Opnieuw is het dan wél belangrijk om hier heldere afspraken over te maken en deze vast te leggen.
Cruciaal om te toetsen
Bovenstaande praktijkvoorbeelden maken twee zaken duidelijk. Aan de ene kant twijfel ik of je moet proberen alle aspecten van de dienstverlening vast te leggen en meetbaar te maken. Ik zal de laatste zijn die het belang van een goede rapportage betwist, maar op welke aspecten van de dienstverlening zou je moeten rapporteren om een goed beeld te krijgen van de kwaliteit van de geleverde dienstverlening? Hier kom ik graag in een volgende blog op terug.
Aan de andere kant heb ik met deze voorbeelden willen benadrukken dat het cruciaal is om te toetsen of je wel dezelfde taal spreekt. Elke industrie kent zijn eigen jargon en ook binnen een industrietak worden soms verschillende betekenissen toegekend aan dezelfde begrippen. Veel spraakverwarring kan worden voorkomen door het vastleggen van heldere definities. Doe geen aannames, niet als klant en niet als leverancier. Vraag door! Alleen dan zal duidelijk worden of je elkaar echt verstaat.
Leuk stukje en treffende voorbeelden, het geeft duidelijk aan dat er een communicatie gat zit tussen de verschillende partijen… De basis ligt toch in dezelfde perceptie over dezelfde begrippen en die goed vastleggen en vooral interactief doorspreken.
Schitterend verhaal!
Dit zijn dan nog voorbeelden die voor ieder weldenkend mens te volgen zijn.
Echter het gebruik van ict-technisch termen gebruiken waarvan de juiste betekenis niet bekend is en er daarom maar (uit marketing overwegingen ?) een eigen betekenis aan gegeven wordt zorgt ook nogal eens voor totale verwarring. Het is haast alsof je een andere taal spreekt.
(Wie dacht toch dat Amerikanen werkelijk Engels spreken…of dat wij Nederlanders die taal beheersen… gezellig met een Engelse meneer keuvelen over je oldtimer…)
Respect voor dit artikel. Maar dan voor een ietwat andere invalshoek.
Kromme tenen
In het verlengde daarvan krijg ik hele kromme tenen. want wat hier word beschreven is namelijk de wijze waarop veel IT dienstenleveranciers met hun klanten om gaan. Ik mis namelijk dat ene zinnetje…… ‘.. Precies zoals de IT dienstenleverancier het heeft bedoeld…’
Wij meten is weten….
De IT diensten leverancier wil uiteraard graag in control blijven. Immers, zij hebben doorgaans ingeschreven op een ‘bid/tender’ en zoals we eigenlijk allemaal wel weten, moet de IT diensten verlener daar doorgaans op inleveren. Er moet geld bij om het rendabel te krijgen. en dat doe je dus door….. heel goed, dit soort zaken toe te passen.
Het is namelijk niet voor het eerst dat er telkens weer van dit soort discussies uitbreken tussen de IT dienstenleverancier en de klant. Beste lezeres, lezer, afnemer, deze discussie loopt inmiddels al weer vijftien jaar denk ik. Dus in al die tijd heeft een IT dienstenleverancier klaarblijkelijk het vermogen niet gehad dit gapende gat te overbruggen.
Klant is Koning?!?
Ehhhh op papier altijd. Nu de praktijk nog. Als je namelijk middels een tender aan een levernacier vast zit gekoppeld, lang leve de EU, dan zit je doorgaans voor jaren aan een leverancier vast. En die moet uiteraard ook winst maken en dus? Krijg je dit.
Dacht u dat een IT dienstenleverancier dat niet wist? Jazeker. Opzettelijk komen tal van zaken niet in het raamovereenkomst terecht. Hoe meer niet word benoemd, hoe meer onduidelijk, des te groter tussentijds billing. Dat is niets nieuws, dat gaat al jaren zo.
Advies van de auteur
Nogmaals met alle Respect mijn beste heer van Duivendijk, wanneer we het hebben over een oplossing van dit gapende probleem, dan hebben we het als IT professionals waarschijnlijk al over twee verschillende dingen.
Wanneer je namelijk als IT dienst verlener nu nog uit zou moeten gaan leggen aan je klant, hoe je iets bedoeld, dan ben je al vijftien jaar te laat. Ik noem maar even een getal want het is voor mij een heilig principe.
Klant en dienstverlening
Een klant, vanuit mijn beleving en perceptie, die moet je managen, al helemaal wanneer het zo is dat jij ze moet uitleggen wat je bedoeld en hoe je dat bedoeld. Het opzetten en uitleggen van een problem en incident proces is verre van moelijk namelijk. Ook niet hoe jij het als IT dienstverlener bedoeld.
Gecompliceerd is niet interessant.
Eén van de wetmatigheden in IT. eentje waar menig IT professional waarschijnlijk geen eens weet van heeft, zeker niet die zich in de laat staan de klant. In eenvoudige termen is het gewoon zo dat je een proces dusdanig kunt inregelen, dat er geen hiaten meer bestaan. Lineair procesvorming heet dat. Waarom dat zo heet? Omdat het IT proces een volkomen lineaire aangelegenheid betreft. Elke stap daarin ken een waarde. Heeft het geen waarde? Dan is het O. U weet wel, I/O.
Compliceer je zaken, kost het iemand geld
Heel eenvoudig gesteld binnen de lijnen van dit artikel. Een telefoontje naar de servicedesk wordt binnen 30 seconden beantwoord. Kan dat niet worden beantwoord binnen die 30 seconden, dan kan men een desnoods een boodschap achter laten. In dat geval word de klant binnen 15 minuten terug gebeld. Indien de klant niet beschikbaar blijkt, kan een email volgen.
Wij hebben systeem XYZ waar altijd historie in word bijgehouden van een gemeld incident. Het is te allen tijde mogelijk intrinsiek te kijken waarom een gemeld probleem niet binnen een voor afgesproken tremijn kon worden verholpen.
Waarom wij dit zo doen beste klant? Omdat IT als materie volkomen voorspelbaar is. Kijk, dat leggen wij u graag uit. En daarom kunnen wij heel goed zeggen waarom we dat zo kunnen doen.
Helder, meetbaar, voorspelbaar.
Dus waarom we hier nu nog een discussie zouden moeten voeren, tenminste van mijn beleving en perceptie uit, die zou dan eens danig naar de eigen organisatie en aanwezige of beschikbare expertise moeten gaan kijken. Ernstig!
Even kijken hoor…..
hallo beste klant, ik ben een dienstenleverancier en ik werk met een materie die alleen maar iets doet doordat aan elke stap binnen de processen van die materie, waarde aan stap en proces word toegekent. Als dat niet gebeurd, gebeurd er niets.(I/O) Maar ik kan u niet uitleggen welke voorspelbare stappen noodzakelijk zijn in een proces een aangemeld probleem op te lossen…..
ehmmmm
Mis ik iets?
Johan,
Een leuk en herkenbaar stuk waarbij ‘Engelssprekend’ natuurlijk zelf ook al geen helder requirement is zoals je prachtig aangeeft met verwijzing naar Anglo-EU Translation Guide. Na enige discussies tussen een Amerikaan en een Welsh, niet te verwarren met een Engelsman, gevolgd te hebben zit er in het Engels zelf ook nog wel enige spraakverwarring. De toon maakt tenslotte de muziek en juist hier heb ik de indruk dat de servicedesk steeds vaker bevolkt wordt door monotoon ‘Engelssprekende’ medewerkers. En doorvragen is trouwens iets dat nogal cultureel bepaald is en in sommige landen gewoon als brutaal gezien wordt.
Deze herkenbare voorbeelden zijn nu precies de dingen waarom ik, door schade en schande wijs geworden, weinig waarde meer hecht aan SLA’s
In de tijd dat ik met ITIL mocht werken hebben we hele discussies gehad over of een door de klant gerapporteerd iets nu een incident of een probleem is.
Vanuit de klant gezien is dit compleet irrelevant. De klant heeft een probleem (of incident) en wil geholpen worden. Door het introduceren van steeds vagere kreten die op meerdere manieren geïnterpreteerd en gemeten kunnen worden (zie ook het artikel) wordt er vooral veel aan proces- en managementbevrediging gedaan, maar niet aan klantbevrediging.
Ligt het aan mij of is het ironisch dat de schrijver de stempel ‘Solution Architect’ onder zijn foto heeft staan?
Krijg ik me daar toch een enorme Koot&Bie brainwave van zeg.
Overigens ontgaat mij de indruk niet dat NumoQuest wellicht lid is van het Simplistisch Verbond.
Overigens kan het helemaal geen kwaad om de specificaties en projectaanpak door een concurrent van de aanbesteder te laten nakijken.
Ik heb me altijd verbaasd over het zwaar toegepast anglosisme op plaatsen waar dat totaal niet nodig is. Het geeft dus inderdaad meer verwarring en is totaal niet ad valorum.
Nemen we even als voorbeeld het eerste verkoopspunt ‘average speed of answer’. Afgezien dat ik het onnatuurlijk vindt klinken, zit ik me ook af te vragen wat de waarde van deze metriek is?
Wat maakt de gemiddelde tijd binnen het IVR nou uit? Het gaat erom dat ik met mijn eerste belletje gelijk bij het juiste loket uitkom of geholpen wordt.
Het vertalingslijstje was trouwens wel een leuk nieuwtje voor mij. Had het nog niet eerder gezien, maar ik denk dat cultuurverschillen hier ook parten spelen. Engelsen zullen eerder erg beleefd blijven en zich wollig uitdrukken.
John,
Je verwacht ook niet dat een automonteur die in de garage achter de showroom werkt, de auto gaat verkopen! Daar heb je iemand anders voor die de taal van de klant spreekt.
In de dienstverlening en bij het opstellen van de SLA, moeten de klant en leverancier ook dezelfde taal spreken, daar heb je SL-managers voor.
Heb je weleens een acceptatiecriteria opgesteld? Zo niet, probeer het maar dan kom je erachter wat een heldere communicatie betekent en welke kennis en ervaring je daarvoor nodig hebt.
Kortom voor elke specifieke taak heb je de juiste persoon nodig, zo simpel is het en meer niet! Ik snap het punt en de boodschap van je artikel niet. Misschien wordt dit in het tweede deel duidelijker.
Dank jullie wel voor jullie kritische en opbouwende reacties op mijn eerste blog! Dat geeft stof tot nadenken én motivatie om meer te gaan schrijven. Door de veelheid en diversiteit is het lastig om op alle punten te reageren, maar ik zou wel graag een paar zaken willen benoemen.
In elke vorm van dienstverlening is er een spanningsveld tussen prijs en kwaliteit. Dat voel je bijna nergens zo nadrukkelijk als in aanbestedingstrajecten. Er zijn veel initiële wensen/eisen ten aanzien van de dienstverlening, maar uiteindelijk wordt toch vaak op prijs geselecteerd. Dan beland je, als je niet uitkijkt, in situaties die @NumoQuest zo treffend schetst.
Je ziet dan ook dat het de verkoper en de inkoper zijn, die weliswaar gesteund door specialisten op de achtergrond, de onderhandelingen voeren. Ik vind in dit opzicht het auto voorbeeld van @Reza Sarshar prachtig; als ik in de markt zou zijn voor een nieuwe auto, dan zou ik persoonlijk liever met de monteur dan met de verkoper praten. De monteur kan me namelijk op basis van zijn eigen ervaring en waarneming precies vertellen hoe goed een bepaalde auto echt is. Terug naar de IT; ik zou niets liever willen dan een kans om direct te praten met de Service Level manager van de klant! Die kans krijg je echter lang niet altijd.
Tenslotte, heb ik al een voorzetje willen geven voor een volgende discussie over de (on)zin van SLAs. @Pa Va Ke kopt hem alvast in: ik geloof namelijk ook niet in dikke rapportages. Terecht slaat ook @Technicus hier op aan met zijn reactie. Kom ik op terug, beloofd!