Wat versus hoe: de eerste valkuil bij transformatieprojecten

door Nicolas Henckes, oprichter en CEO

Er is een fout die ik regelmatig tegenkom bij product- of digitale transformatieprojecten, zowel bij kleine en middelgrote ondernemingen als bij grotere organisaties: het verwarren van functionele eisen met technische oplossingen.

Het is geen kwestie van bekwaamheid. Het is een kwestie van hoe je het benadert.

"Snellere paarden"

Henry Ford wordt vaak geciteerd met een uitspraak die bijna een managementcliché is geworden:„Als ik mijn klanten had gevraagd wat ze wilden, zouden ze hebben gezegd: snellere paarden.” Of deze uitspraak daadwerkelijk van hem afkomstig is, wordt betwist (er is nooit een geverifieerde primaire bron gevonden), maar het idee is blijven bestaan omdat het een kern van waarheid bevat.

Wat klanten verwoorden, wordt beperkt door wat ze al weten. Ze beschrijven de wereld zoals die is, niet zoals die zou kunnen zijn. Ze vragen om verbeteringen aan het vertrouwde in plaats van om alternatieven daarvoor.

Het belangrijkste is dat dit niet alleen voor klanten geldt.

Dit geldt ook voor de mensen binnen je organisatie.

Als je een team vraagt wat ze nodig hebben, zullen ze beschrijven wat er ontbreekt in de tools die ze al gebruiken. Ze zullen vragen om meer functies in het huidige systeem. Meer automatisering van de huidige workflow. Een betere versie van wat ze nu hebben.

Dat is niet verkeerd. Het is heel normaal. Maar het is niet hetzelfde als begrijpen wat ze nu eigenlijk moeten bereiken.

Waarom dit gebeurt – en waarom het structureel is

Teams beschrijven hun behoeften niet in het luchtledige. Ze beschrijven ze in relatie tot de realiteit waarin ze dagelijks werken: het systeem waarop ze elke ochtend inloggen, de tijdelijke oplossingen die ze in de loop der jaren hebben bedacht, de functies die hen vorige week frustreerden.

Vanuit die context is het bijna onmogelijk om aan dit denkkader te ontsnappen. Dat is geen gebrek aan verbeeldingskracht – het is het normale gevolg van het feit dat men verankerd is in een operationele context. Hoe dichter iemand bij de dagelijkse praktijk staat, hoe moeilijker het is om een scheiding aan te brengen tussen wat hij of zij probeert te bereiken en de manier waarop dat momenteel gebeurt.

Hier zit ook een organisatorische kant aan. In veel bedrijven zijn verzoeken om nieuwe functies niet alleen technische voorkeuren, maar ook politieke standpunten. Een team vraagt om een specifieke functionaliteit omdat die hun visie weerspiegelt op hoe de organisatie zou moeten werken, welke gegevens centraal zouden moeten staan en welke workflow de standaard zou moeten zijn. Het verzoek bevat aannames over macht en prioriteit die zelden expliciet worden gemaakt.

Daarom leidt het verzamelen van vereisten tijdens een workshop – onder de noemer ‘behoefteanalyse’ – vaak tot een gedetailleerd overzicht van de huidige situatie, in plaats van een echt beeld van wat er moet veranderen.

Het onderscheid dat alles verandert

Het ‘Wat versus Hoe’-raamwerk is geen methodologie. Het is een manier van denken.

• Wat: het functionele doel van de gebruiker, wat hij of zij probeert te bereiken, los van welk hulpmiddel of proces dan ook.

• Hoe: de manier waarop ze zich voorstellen dit te realiseren, de interface, de workflow, de technische logica.

Een eenvoudig voorbeeld uit de publieke sector: toen overheden begin jaren 2010 digitale diensten introduceerden, vroegen burgers in hun feedback steevast om „een eenvoudigere versie van het papieren formulier”. Wat mensen eigenlijk nodig hadden, was een taak kunnen uitvoeren, een vergunning kunnen verlengen of een uitkering kunnen aanvragen, zonder onnodige hindernissen. Het formulier was de „hoe”. Het formulier volledig afschaffen was vaak de juiste „wat”.

Nog een voorbeeld uit de wereld van bedrijfssoftware: teams die van verouderde ERP-systemen overstappen, vragen steevast om „de oude schermen na te bootsen“. Het „hoe“ weten ze wel. Het „wat“ – op het juiste moment toegang krijgen tot de juiste gegevens om een beslissing te nemen – kan vaak op radicaal verschillende manieren worden gerealiseerd.

Wanneer deze twee in specificaties door elkaar worden gehaald, bouw je complexe tools die weliswaar aan verzoeken voldoen, maar geen problemen oplossen.

Dit onderscheid is juist het belangrijkst op het moment dat het het moeilijkst toe te passen is: aan het begin van een project, wanneer iedereen op één lijn zit en enthousiast is, en het laatste wat iemand wil, is even pas op de plaats maken om zich af te vragen of het gedeelde begrip ook daadwerkelijk door iedereen wordt gedeeld.

Hoe dit er in de praktijk uitziet

Bij de projecten waaraan ik werk, streef ik ernaar om die twee niveaus vanaf het begin van elkaar te scheiden.

Het komt neer op een paar vragen die rechtstreeks aan de teams worden gesteld:

• "Als het huidige systeem niet zou bestaan, hoe zou je dan omschrijven wat je nodig hebt?"

• "Wat houdt je vandaag eigenlijk tegen, niet in de tool, maar in je werk?"

• "Als deze functie morgen zou verdwijnen, wat zou je dan niet meer kunnen doen?"

De laatste vraag is bijzonder nuttig. Ze doorbreekt de opeenstapeling van verzoeken en komt tot de kern van de afhankelijkheid.

Maar het stellen van vragen is slechts een deel van het werk. Het moeilijkste deel is het creëren van de omstandigheden waarin mensen eerlijk kunnen antwoorden. In veel organisaties is het proces van het in kaart brengen van behoeften ook een manier om zichtbaarheid te creëren: teams gebruiken het om hun relevantie aan te tonen, hun budget veilig te stellen en prioriteiten naar boven toe te signaleren. Een vraag als „wat heb je eigenlijk nodig?“ kan als een valstrik aanvoelen als de bedrijfscultuur geen ruimte heeft gecreëerd voor dat soort openhartigheid (zie ons artikel op Servant Leadership).

Dit betekent dat effectief ‘Wat versus Hoe’-werk niet alleen analytisch is. Het vereist vertrouwen, en het opbouwen van vertrouwen kost tijd. Bij een langdurige samenwerking kun je dit geleidelijk aan opbouwen. Bij een kortlopende opdracht moet je dat vertrouwen snel zien te winnen – en dat betekent vaak dat je moet beginnen bij de mensen die het verst afstaan van de politiek en het dichtst bij het echte werk staan.

Dit is geen theoretische oefening. Het is juist wat echte behoeften onderscheidt van organisatorische artefacten – functies die bestaan omdat ‘we het altijd al zo hebben gedaan’, en die bij opeenvolgende systeemmigraties in stand zijn gehouden zonder dat iemand zich afvroeg wat het nut ervan was.

De kosten van een verkeerde beslissing

Wanneer aan het begin van een project geen onderscheid wordt gemaakt tussen ‘wat’ en ‘hoe’, zie je doorgaans een van de volgende twee uitkomsten.

De eerste is ‘over-engineering’: een oplossing die technisch gezien compleet is, maar in de praktijk onbruikbaar. Aan alle eisen is voldaan. Het systeem doet wat ervan verwacht werd. Maar de mensen die het zouden moeten gebruiken, vinden het te complex, te star of gewoonweg niet afgestemd op de manier waarop ze daadwerkelijk werken. Het systeem wordt weinig gebruikt. De investering mislukt in stilte.

Het tweede probleem is scope creep zonder duidelijk principe voor het maken van keuzes. Zonder een gedegen begrip van het ‘wat’ is het onmogelijk om concurrerende functieverzoeken te beoordelen. Elk nieuw verzoek is in potentie geldig. Het project groeit oneindig door, of wordt willekeurig ingekort wanneer het budget opraakt – met als gevolg een onvolledige oplossing waar niemand tevreden mee is.

Beide uitkomsten zijn kostbaar. Beide zijn te voorkomen. En beide zijn doorgaans terug te voeren op dezelfde fout in het begin: niet de tijd nemen om je af te vragen waar het werk eigenlijk voor dient.

De managementdimensie

In overgangssituaties – of het nu gaat om een digitale transformatie, een reorganisatie of een systeemwisseling – wordt dit kaderwerk zelden vanuit de organisatie zelf uitgevoerd. Teams staan te dicht bij het onderwerp, hebben te veel te maken met operationele eisen en staan te veel bloot aan interne politieke druk om de nodige afstand te kunnen bewaren.

Dit is een van de concrete voordelen van een externe blik in deze fasen: niet alleen om het proces te ‘begeleiden’, maar ook om op het juiste moment de juiste vragen te stellen, voordat technische keuzes onomkeerbaar worden.

Een ervaren externe leider brengt iets mee dat in transformatieprocessen vaak onderschat wordt: de vrijheid om naïeve vragen te stellen. Niet omdat hij of zij het bedrijf niet begrijpt, maar omdat hij of zij niet gebonden is aan de geschiedenis ervan. Hij of zij kan zeggen: „Ik begrijp dat het altijd zo heeft gewerkt – maar waarom?”, zonder iemands positie in gevaar te brengen of oude organisatorische wonden weer open te halen.

Dit betekent niet dat de antwoorden van buitenaf komen. De mensen die het werk begrijpen, bevinden zich altijd binnen de organisatie. De rol van het externe perspectief is niet om die kennis te vervangen, maar om deze naar boven te halen – om vragen te stellen die interne stakeholders elkaar niet gemakkelijk kunnen stellen, en om voldoende afstand te creëren ten opzichte van de bestaande ‘hoe’-vraag, zodat de echte ‘wat’-vraag zichtbaar wordt.

Waar moet ik beginnen?

Als je aan een transformatieproject begint en je wilt deze werkwijze toepassen, is het allerbelangrijkste wat je vóór de eerste sessie voor het vaststellen van de vereisten kunt doen, dat je met je team één principe afspreekt: elk verzoek wordt in twee kolommen vastgelegd. Wat de gebruiker moet bereiken. Hoe hij of zij zich op dit moment voorstelt dit te doen.

De ruimte tussen die twee kolommen is waar het echte ontwerpwerk plaatsvindt.

Wat het team wil en wat de organisatie daadwerkelijk nodig heeft, zijn vaak twee verschillende dingen. De tijd nemen om hier aan het begin van een project onderscheid tussen te maken, is wat het verschil maakt tussen een oplevering en een transformatie.

---

Door Nicolas Henckes, oprichter en CEO van Kitsune Advisory. Kitsune Advisory biedt interim- en Parttime CEO -diensten aan bedrijven in Luxemburg, Frankrijk, België, Duitsland en Zwitserland.