Klantgericht werken (in een grote organisatie), hoe doe je dat?
In de media lees je met enige regelmaat over wat er niet goed gaat bij dienstverlening van grote overheidsinstanties zoals de Belastingdienst. Vanuit mijn rol als Digitaal Strateeg richt ik me op de dienstverlening richting burgers en bedrijven, en de digitale producten die daarbij komen kijken.
Het klantgericht werken of centraal zetten (sorry, beroepsdeformatie) van de eindgebruiker kan en moet beter. Dat laatste komt voort uit mijn eigen ervaring en blijf ik me voor in zetten. Waarvoor precies? Het ontwerpen en leveren van betere diensten en producten waar eindgebruikers makkelijk en met vertrouwen hun zaken met de Belastingdienst kunnen regelen. Die dus.
Mijn ervaring
Als Digitaal Strateeg werk ik vanuit Luminis op dit moment voor de Belastingdienst. De omschrijving van de opdracht: heeft het voor IV (Informatie Voorziening, het ICT bedrijf van de Belastingdienst) waarde als we Design Thinking in ons proces toepassen? Bij Design Thinking werk je met een multidisciplinair team aan innovaties waarbij de eindgebruiker centraal staat. Geen dikke documenten vanuit een ivoren toren maar echt een eindgebruiker betrekken en samen met deze eindgebruiker, business en IV oplossingen bedenken. Creatief oplossen van uitdagingen met nadruk op prototypen en zo snel mogelijk testen.
3 pijlers van SAFe
Naast het aanbieden van een cursus Design Thinking wordt inmiddels ook SAFe binnen de organisatie uitgerold. Dit framework stelt je in staat om op grote schaal agile te werken. SAFe richt zich op 3 belangrijk pijlers: voorspelbaar, wendbaar èn klantgericht. Top! Customer Centricity en Design Thinking hebben een plek binnen het framework en – hoewel SAFe naar mijn mening snel neigt naar de ‘release’ kant – ben ik met de uitspraak zeker blij. Het centraal zetten van een eindgebruiker en empathie wordt gezien, en daarmee ook het belang om te kijken naar deze eindgebruiker en zijn uitdagingen. Ik gebruik bewust het woord “uitdagingen” omdat ik in allerlei projecten (ook bij Luminis en haar opdrachtgevers) te vaak meemaak dat de oplossing al bedacht is en er gebouwd wordt zonder eerst goed te kijken wat en voor wie er iets opgelost moet worden. Daar hebben we binnen onze Agile Release Train (ART in SAFe: een groep van Agile-teams dat stapsgewijs een of meer oplossingen in een waarde stroom ontwikkelt, levert en exploiteert) ervaring mee opgedaan. Ook steeds meer buiten deze ART trouwens. Er is dus beweging, ik zie dat we de goede kant op gaan. In deze blog deel ik de belangrijkste ervaringen die ik de afgelopen jaren (bij de Belastingdienst) op heb gedaan.
In vogelvlucht
Maar eerst even terugkijken… Tot zo’n 15 jaar geleden bedachten digitaal productontwerpers, na een briefing door opdrachtgevens, wat een eindgebruiker voor product wilt hebben. Ik hoorde vaak:
“Jij bent de creatieveling, ik heb een idee maar ik kan dat niet ‘vertalen’, verzin jij het maar!” Waarbij ik dan altijd voelde: “ga aan de slag ontwerper, bedenk iets slims en kom je hok uit als je het doordacht en ontworpen hebt. Ps. Zorg wel dat het te maken is…”.
Hoewel met deze methode ook vandaag de dag nog steeds prima producten ontworpen worden, werkt het voor mij tegenwoordig gelukkig anders. Daar probeer ik ook altijd op te sturen. Waarom? Omdat ik denk dat je samen betere producten kunt maken. Eindgebruikers en opdrachtgevers betrekken waardoor de producten in mijn ogen beter en dus succesvoller zijn.
De designcyclus
Met de ontwikkeling en toepassing van Design Thinking (sinds 1970, en in 1990 bij een grotere groep bekend) en Service Design staan eindgebruiker en samenwerken met opdrachtgevers steeds centraler. Empathie (inleven in de eindgebruiker en zijn behoeftes) is iets wat in deze beide methodes in verschillende vormen terugkomt. Een designcyclus start met Empathy en eindigt via Define, Ideate en Prototype bij Test. Voor elke fase hebben zijn er dan weer allerlei werkvormen die je kunt gebruiken om tot inzichten te komen. Op basis van een uitdaging kijk je bij een designcyclus eerst in de breedte (divergeren) om vast te leggen waarvoor je gaat ontwerpen (convergeren) om vervolgens hetzelfde te doen bij het bedenken van ideeën en het maken en testen van een prototype.
* Divergeren en convergeren in de ‘double diamond’ die gebruikt wordt om het design thinking proces te visualiseren.
** Empathy heb ik begrijpen genoemd. Wat mij betreft gaat het in deze fase om behoeftes, beperkingen en data.
Veel opdrachtgevers verwachten inmiddels dat er een proces gebruikt wordt waarin omschreven staat hoe en wanneer eindgebruikers gesproken worden en wie (van de opdrachtgever) we hierbij betrekken. Dat had ik 15 jaar geleden niet kunnen bedenken. Want op dat moment gaf ik zelf aan dat ik graag eindgebruikers wilde interviewen en via een (usability) test feedback over het product op wilde halen. Daarbij heb ik meerdere keren het volgende te horen gekregen:
“Jij bent toch de ontwerper en dan weet je wat goed is, daar huur ik je toch voor in? Hoezo dan nog testen met eindgebruikers? Daarbij, dat is ook duur en verstoort/vertraagt het voortbrengingsproces. We willen nu gaan bouwen!”
Mijn argument “maar wat nou als ik mis zit en we iets opnieuw moeten bouwen, dat kost toch meer tijd en geld?!” veranderde helaas weinig aan de mening van opdrachtgevers. In die zin is niet de hele wereld veranderd, we werken namelijk nog steeds voor opdrachtgevers die het lastig en spannend vinden om eindgebruikers te betrekken en onderzoek duur vinden. In mijn ogen klopt mijn argument overigens nog steeds, misschien eens onderbouwen met cijfers?
Waarom eindgebruikers betrekken?
De pitch (een gedeelte van) die we bij Luminis gebruiken om ons verhaal uit te leggen…
Digitale producten die er toe doen!
Luminis maakt voor haar opdrachtgevers en eindgebruikers digitale producten die er toe doen. We ontwerpen en maken digitale producten waar eindgebruikers blij van worden en onze opdrachtgevers succesvol. Hierbij willen we vanuit business, gebruikers en technologie de volgende vragen beantwoorden in ons werk om de juiste digitale producten te kunnen maken:
-
- Wat is wenselijk vanuit het perspectief van de gebruikers?
- Wat is waardevol vanuit het perspectief van de opdrachtgever?
- Wat is mogelijk vanuit het perspectief van technologie?
*3 perspectieven op productontwikkeling om succesvolle producten te maken.Begin bij de eindgebruiker
Als je een product wilt maken waar eindgebruikers blij van worden, zul je bij hen moeten beginnen. Vandaar de volgorde wenselijk, waardevol en mogelijk. Over blij valt in de context van een overheidsinstantie nog wel wat te zeggen. Vaak heeft de eindgebruiker het maar te doen met dit ene product en is er geen keuze. Daarom is een eindgebruiker wellicht eerder tevreden door soepel en makkelijk proces. Zonder gedoe en lang wachten aan de telefoon… dat je weet waar je aan toe bent en wat je moet doen om compliant te zijn.
En dan die eindgebruiker, wat wil die (echt)? Door je in te leven kom je daar achter, dit is eerder benoemd als empathie. Een collega schreef:
“Als professionele ontwerpers weten we dat het essentieel is om in de schoenen van onze doelgroep te kruipen om de wereld te kunnen beleven zoals zij het ervaren.”
Helemaal mee eens. En ik weet heus wel dat er meer nodig is dan alleen het resultaat uit een gebruikersonderzoek (waar op wordt gehint) om een overtuigend keuze te kunnen maken om een uitspraak te kunnen doen over de impact en het (verwachte) effect van een concept. Het aspect “mogelijk” bepaalt natuurlijk veel, maar realiseer je: als je weet wat een gebruiker wilt, hoef je dat niet persé (in 1 keer) te maken. Het maken van een ontwerp zie ik dan ook als richtinggevend en in gesprek aan te passen. Maar wel met een eindgebruiker in gedachte.
Een antwoord geven op de vraag “Wat wilt een eindgebruiker echt?” is voor onze opdrachtgevers vaak lastig. Ook voor mij als ontwerper trouwens. Dat heeft meerdere redenen want een eindgebruiker:
- zal je al snel willen ‘pleasen’ en wenselijke antwoorden geven;
- weet vaak niet precies wat hij wil;
- zegt wat hij wil maar wat hij wil zal niet helemaal overeenkomen met de doelen die je (stiekem) al in je achterhoofd hebt.
Naast het feit dat het voor opdrachtgevers daarmee maar de vraag is hoe betrouwbaar zo’n gesprek met een eindgebruiker is ontstaat er ook vaak weerstand om met een eindgebruiker in gesprek te gaan want opdrachtgevers:
- weten niet hoe en wanneer ze klanten kunnen betrekken om inzicht te krijgen;
- denken dat het lang duurt en duur is om met eindgebruikers onderzoek te doen;
- denken dat het hun eigen doelen schaadt als ze (te)veel naar eindgebruikers luisteren.
Hoe vind je een eindgebruiker?
Voor het geval je niet weet hoe je een eindgebruiker kunt betrekken, de simpelste stap is rondvragen. Vrienden, familie etc. zijn in mijn ervaring snel bereid te helpen. Door een paar vragen te stellen krijg je snel reactie op je idee. Ook bestaande klanten kun je benaderen en er is niks leerzamer (en leuker) dan naar ze toe te gaan. Gewoon bellen, bijna iedereen zegt ‘ja’. De leukste en meest leerzame gesprekken en testen heb ik in de steenfabriek, de garage of op de boot uitgevoerd.
Je kunt het werven van respondenten ook uitbesteden, dan gaat het je misschien meer kosten maar vaak heb je dan wel eerder een meer diverse groep waar je mee kunt testen. En het is natuurlijk gemakkelijk iemand te laten werven op basis van een opgesteld profiel. De test wordt serieuzer en – hoewel het een veel gehoorde opmerking dat je niet uit kunt gaan van een enkele testen – 5 tot 6 respondenten is echt genoeg voor de eerste inzichten die je op wilt halen. Gebruik kwalitatief onderzoek als je iets wilt begrijpen (concepten, gedachten of ervaringen).
Over punt 2 kan ik zeggen: je kunt het zo klein en zo groot maken als je wilt (van 1 uur tot meerdere weken) maar als je door 1 uur te besteden de inzichten ophaalt dat het anders, moet heb je snel je geld verdiend. Over punt 3, ach – je bent er zelf bij, je hoeft heus niet (alles) te maken wat een klant wil.
Als je kijkt naar de verschillende frameworks, waar SAFe er eentje van is, zou je kunnen zeggen dat het mooi is dat Customer Centricity en Design Thinking genoemd wordt maar in mijn ervaring ben je er dan nog niet. Ook omdat deze frameworks niet beschrijven hoe je dit soort, voor de meeste mensen, ongrijpbare dingen toe kunt passen. Een veelgehoorde opmerking in dit verband: ”
Ik doe dat al, ik denk toch al vanuit de klant?!” Stel dan de tegenvraag: wanneer heb je die voor het laatst gesproken? Het antwoord? “Ja nee, dat niet maar ik weet het wel wat goed voor ze is…”
Dat is niet wat ik met klantgericht werken bedoel.
In mijn ervaring kun je nog zoveel over de theorie vertellen maar is het vooral een kwestie van doen. Bijvoorbeeld deelnemers van workshops laten ervaren wat dat klantgericht werken is. Bij het uitleggen van Design Thinking heb ik een aantal keer meegemaakt dat ik het licht in de ogen van mensen zag doven. Terwijl als je een workshop doet en daar eindklanten bij betrekt (zonder precies je beweegredenen uit te leggen) worden medewerkers enthousiast en geven ze aan dat ‘we’ ‘dit’ vaker zouden moeten doen. Ha, een stapje gemaakt! Dan nog steeds, hoe pas je dat nou in de praktijk toe?
Klantgericht werken (in een grote organisatie), hoe doe je dat?
In deze blog is het al subtiel aangestipt: dat is best lastig. De belangrijkste oorzaak hiervan is dat het een organisatie niet zomaar lukt om van de ene op de andere dag om anders te gaan werken en er medewerkers met weerstand overtuigd moeten worden. Een werkwijze aanpassen lukt niet van de ene op de andere dag, daarvoor heb je een lange adem nodig. Als je klantgericht wilt gaan werken, realiseer je dan dat je hier zomaar eens langer dan twee jaar mee bezig kunt zijn voordat je op een niveau bent gekomen dat je klantgericht(er) werkt.
Als je klantgericht wilt gaan werken is het handig een aantal manieren of methodes te hebben waar klantgericht werken in zit. De belangrijkste workshopvormen die (met multidisciplinaire teams) in mijn ervaring werken:
- 1-daagse workshop
- Design sprints (zie de whitepaper Design Sprints die ik geschreven heb)
- Service design trajecten
- Klantreis trajecten
In mijn ogen betekent een klant centraal stellen dat je op verschillende momenten met die klant moet gaan praten. In alle bovenstaande werkvormen zit het ingebakken dat je dit doet. Het zit dus in de werkwijze met als voordeel dat iedereen het na verloop van tijd normaal gaat vinden. Dan kun je wanneer je bijvoorbeeld een bestaand product wilt verbeteren de volgende (open) vragen aan een eindgebruiker stellen:
- Welk onderzoek heb je voordat je het product ging gebruiken gedaan?
- Wat kun je me over dit formulier vertellen? Hoe heb je dit formulier ingevuld?
- Waar liep je tegenaan tijdens het invullen?
- Wat wordt er met deze regeling gevraagd?
- Hoe heb je dat opgelost?
Bij de projecten waar we interviews afnemen proberen we zoveel mogelijk stakeholders mee te laten luisteren. Omdat het voor een businessowner, domeinexpert, architect, etc. net zo goed is om te weten wat er bij een klant speelt. Dit is geen ontwerp feestje. Scheelt voor de designer ook weer tijd om anderen van het juiste product of dienst te overtuigen.
De genoemde werkvormen kun je inzetten om een oplossing voor kleine en grote uitdagingen uit te werken. In het geval van SAFe: als je elk increment (5 tot 6 sprints van twee weken binnen een kwartaal) een design sprint rond een belangrijke (klantgerichte) feature doet, ben je al klantgericht met je team aan het werk. In een design sprint praat je aan de start met eindgebruikers en test je aan het eind ook met eindgebruikers. En meteen realiseren zodat je kunt meten en naar klantwaarde kunt kijken. Het is wellicht eng om succes te meten (heb ik wel de juiste investering gedaan?) maar hoe eerder je test des te eerder je je product aan kunt gaan passen en meer (klant)waarde kunt leveren.
Tot slot
Ik denk dat klantgericht werken voor elke organisatie iets anders betekent. De markt, tijd, budget, teamsamenstelling, mindset, etc. allemaal factoren die van invloed zijn. Een vastomlijnd plan ligt er dus niet maar denk aan de volgende takeaways:
Als je meer klantgericht wilt gaan werken, denk dan aan:- het betrekken van eindgebruikers;
- het gebruiken van (design thinking) werkvormen waarmee je multidisciplinair werkt en teamleden zich in de gebruiker in kunnen leveren;
- het testen met eindgebruikers.
zodat:
- het juiste probleem op wordt gelost;
- het voor eindgebruikers makkelijker wordt om in 1 keer goed hun zaken kunnen regelen (met als bijkomend voordeel minder belasting van supportmedewerkers);
- rework achteraf voorkomen wordt (1st time right);
- je blije gebruikers hebt, klantwaarde levert en succesvoller met je product bent!
