(Oorspronkelijk verschenen in Computable 30-5-2011: Luister niet naar de gebruiker)
Regelmatig hoor je het weer. Automatiseerders zijn techneuten. Ze kijken niet wat de gebruiker wil. Ze komen met technische oplossingen waar niemand om vraagt, en daarom mislukken al die projecten. Om een IT project tot een succes te maken, moet je niet van de techniek uitgaan, maar eerst eens gaan vragen wat de gebruiker nu eigenlijk wil.
Het oude, vertrouwde model. We gaan de gebruiker vragen wat die wil, en schrijven dat heel precies op, in User Requirements, of Eisen en Wensen of zoiets. Dan laten we daar een partij informatie-analisten op los, die dat informatie-analyseren, en zo nog een paar stappen verder komen we met een functioneel ontwerp, en dat laten we ondertekenen door de gebruiker met diens eigen bloed, zwerend op al wat voorhanden is, dat dit toch écht (maar dan ook écht) is wat hij of zij wil. En dat bouwen we dan (wat altijd veel en veel duurder is dan verwacht, en veel en veel langer duurt, want waar in dit verhaal komt nu voor wat de techniek wel kan en niet kan, en wat makkelijk gemaakt kan worden en wat niet).
En als het dan af is, is het niet wat de gebruiker wil. Niet vreemd, want dit gaat uit van twee veronderstellingen:
- De gebruiker weet wat hij of zij wil.
- De consultant kan dat vertalen naar een oplossing.
Beide veronderstellingen zijn onjuist.
Een gebruiker weet niet wat hij wil. Wanneer je een gebruiker vraagt wat hij wil van een informatiesysteem, dan krijg je te horen wat het huidige informatiesysteem kan, en waar de gebruiker niet tevreden over is. Wanneer je dat als uitgangspunt neemt krijg je dus op zijn hoogst een opgepluste versie van het huidige systeem. Dat is niet gek. De gebruiker is zelf iemand met een vak, een specialist op zijn eigen gebied. De verzekeraar loopt warm voor sterftekansentabellen, de internist weet alles van poliepen en de bakker houdt van rijzen en kneden. Innovatie door inzet van ICT middelen hoort daar normaliter niet bij. Vraag de gebruiker dus niet wat hij wil: dat leidt tot middelmatige systemen, gebaseerd op achterhaalde technologie, en zonder gebruik van de mogelijkheden die nieuwere technologie (Internet, mobiel, social media etc.) biedt.
In een enkel geval loopt het anders. Soms tref je een witte raaf. Een vakmens die in staat is een stap terug te doen, te kijken naar het hele proces, en op waarlijk innovatieve wijze te kijken naar wat mogelijk is. Wat anders kan. Wat met nieuwe technieken opeens wél kan. Dat is een mazzeltje, want witte raven zijn zeldzaam. Maar zelfs dan is het verstandig niet al te lang naar de witte raaf te luisteren.
Want het tweede probleem blijft. Natuurlijk kan de consultant (automatiseerder, informatie-architect, organisatiekundige, business consultant, nieuwste-rage-goeroe, vul maar in…) dat niet. Die is namelijk zelf vakmens in het eigen vak, dus snapt in principe maar net-an waar die gebruiker het over heeft. Laat staan dat dat vakmens, die toch tijd en energie in het verwerven van het eigen metier heeft gestoken, echt inziet hoe het vak van de gebruiker werkt, en hoe dat beter kan. Dus gaat de consultant, bij gebrek aan echt inzicht, dat al snel opvullen met datgene waar hij of zij wel verstand van heeft, namelijk techniek. De consultants die het best in het eigen vak zijn, zijn geeks. Mensen die alles weten van iets. Van Internet, of mobiel, of social media. Die daarmee kunnen toveren. Maar dan zonder te begrijpen wat die gebruiker er écht mee kan of wil.
Soms gaat het iets beter. Soms tref je een bruggenbouwer. Een consultant, die zich in een vak (niet alleen het eigen!) verdiept heeft en wél iets weet van het vak van de gebruiker. Er misschien zelfs enige passie voor voelt. Of vroeger gebruiker was, en uit passie voor de techniek de ICT in is gedreven. Maar zelfs dan is het verstandig niet al te lang naar de bruggenbouwer te luisteren. Want ondanks de passie: de kennis voor het vak van de gebruiker gaat niet zo diep. Of bij de omgeschoolde bruggenbouwer: de kennis van het gebruikersvak is inmidels toch minimaal wat roestig en verouderd geworden.
Hoe het dan wel moet? Ten eerste moeten we het gebrek aan kennis als uitgangspunt nemen. Noch de gebruiker, noch de consultant weet precies wat er gebouwd moet worden. En dat gebrek aan kennis moet opgevangen worden met een surplus aan praktijk. Dus eerst met een lampje zoeken naar alle witte raven en bruggenbouwers die je kunt vinden. (Want die hebben we wel nodig.) Laat die, met een paar geeks erbij (want die heb je ook nodig), een schets maken. Liefst iets geks, wat helemaal niet realiseerbaar of wenselijk is, omdat het veel te gedroomd is en helemaal niet lijkt op wat de gebruiker wil.
En maak dan een eerste systeempje, snel en krakkemikkig en niet te groot, en ga dat in de praktijk testen. Kijken wat het doet als er mee gewerkt wordt. Dan valt er vanzelf wel af wat écht niet realiseerbaar of wenselijk is, dan blijkt wel wat droom moet blijven, en wat de gebruiker écht nodig heeft en wat er dus tóch nog bij moet komt ook wel bovendrijven. En zo ga je verder, nog een stap, en nog een stap, en dan komt er wel een systeem. Een waarvan de gebruiker nooit gedacht had dat hij dat wilde. Maar innovatie begint niet met luisteren naar wat de gebruiker wil. Innovatie begint met een droom.