Klant is koning, of toch niet?

We kennen allemaal het principe de Klant Is Koning. Dat hebben we op school geleerd en vooral vroeger kwam je dat in reclames tegen. Het gaat tegenwoordig nog steeds op als je googelt. Er zijn bedrijven die dit heel letterlijk kunnen nemen, zoals Volvo met blauwe auto’s waarvan het nummerbord met een A begint…

De letterlijke betekenis is: Men moet de klanten in alle omstandigheden met respect behandelen. Daar zal niemand het mee oneens zijn. Dit is echter geen blog over respect, alhoewel wel zijdelings.
In ons staatsbestel heeft de Koning daarnaast vrij weinig te zeggen. In de IT praktijk werkt dat gelukkig helemaal anders. De klant geeft ons namelijk een opdracht.

Ik kijk in deze blog graag naar de figuurlijke betekenis. Maar wat betekent dat eigenlijk? Betekent het dat ik mijzelf moet wegcijferen omwille van de klant? Dat lijkt me niet. Het roept gelijk beelden bij me op over soldaten die domweg orders van boven moeten opvolgen. Ik heb zelf gelukkig nog nooit een klant meegemaakt die mij oplegt wat ik moet doen. Ik zou daar heel veel (misschien wel te veel) moeite mee hebben. Denkend vanuit de kernwaarden van QoppoConsult denk ik dat mijn BUM’s het niet waarderen als ik mezelf helemaal wegcijfer. Wij sturen mensen naar klanten en geen robots.

De andere kant op geredeneerd betekent het ook: U vraagt wij draaien. En als we zien dat een klant niet in staat is iets concreets of iets goeds te vragen, dan laten wij de urenmachine draaien? Als we dit doen, krijgen we dure, mislukte trajecten zoals gebeurd is met de basisregistratie van de overheid. Dit lijkt heel leuk maar op de lange termijn blijven alleen verliezers over.

Hoe werkt het wel of hoe zou het moeten werken?

Klanten hebben een vraag en kunnen deze gedetailleerd of op hoog niveau omschrijven. Het is aan elke consultant, ongeacht de rol die je vervult, de inschatting te maken of je de vraag begrijpt en kunt voldoen aan de vraag. Die inschatting maak je op basis van je persoonlijkheid, waarden en kennis. Bij enige vorm van twijfel treedt in overleg met je opdrachtgever. Voorkom dat je een schommelscenario krijgt. Denk volgens Scrum, maak de vraag concreet en behapbaar. Stel samen een Definition of Ready op. Hiermee voorkom je dat je iets produceert waar niemand behoefte aan heeft. Gebruik moderne technieken om de problemen van alledag op te lossen. Het lijkt allemaal heel makkelijk en logisch, maar ik maak nog elke dag het tegengestelde mee. Samenvattend: bezint eer ge begint.

Alles beschouwend klinkt de gulden middenweg niet zo verkeerd. Maar ja, dat neigt wel heel erg naar polderen. Overigens was Aristoteles hier 2300 jaar geleden ook een voorstander van. Dan zal het wel goed zijn toch?