Leidt jouw requirementsmodel ook tot ontevreden klanten?

Onvolledige requirements voorkomen


Veel intermediairs tussen Business en ICT, zoals functioneel beheerders en informatieanalisten, zullen dit herkennen.
Ze voeren gesprekken met belanghebbenden en schrijven al hun wensen en eisen op. Na afloop weten ze precies welke producten er nodig zijn en wat die producten moeten kunnen doen.

En toch blijkt keer op keer dat ze essentiele informatie hebben gemist, want de klant blijkt uiteindelijk niet tevreden te zijn met het geleverde product. De kans is dan groot dat het aan het requirementsmodel ligt dat wordt gebruikt, de manier waarop wensen en eisen worden ingedeeld, verzameld en beschreven.

In de praktijk zie je intermediairs vaak een onvolledig requirementsmodel gebruiken. Een model dat maar een gedeelte van alle benodigde wensen en eisen verzamelt. Er wordt vooral beschreven welke producten de klant nodig heeft en wat die producten moeten kunnen doen. De functies van het product.

Vaak wordt vergeten te vragen welke concrete resultaten de klant wil bereiken met de producten en met de specifieke functies ervan. En dat is eigenlijk merkwaardig, want het zijn juist die concrete resultaten die ervoor zorgen dat klanten juist wel of juist niet tevreden zijn. Klanten willen namelijk helemaal geen producten, ze willen resultaten! Of zoals Theodor Levitt ooit zei,

“Mensen willen geen 4mm boor. Mensen willen een 4mm gat.”

 

En zo kan het dus gebeuren dat er een product wordt opgeleverd dat voldoet aan alle functionele wensen en eisen, maar waar de klant toch niet tevreden mee is.

Dat kan ook anders. Hoe? Door tijdens gesprekken een requirementsmodel te gebruiken dat naast de producten en productfuncties ook vastlegt met welke concrete en meetbare resultaten de klant tevreden is.


Zo’n requirementsmodel bevat de volgende soorten wensen en eisen:

1. Behoeften
Behoeften geven antwoord op de vraag: Welk resultaat wil je uiteindelijk bereiken?

Voorbeeld: Aandeel in spaarmarkt verhogen van 25% naar 30%.

2. Benodigdheden
Benodigdheden geven antwoord op de vraag: Wat heb je nodig om dat eindresultaat te bereiken? Vaak zijn dat producten of diensten.

Voorbeeld: een nieuw spaarproduct, promotiemateriaal, helpdesk en softwaresysteem.

3. Functies
Functies geven antwoord op de vraag: Wat moet een product (vaak systeem) kunnen doen om het eindresultaat te bereiken?

Voorbeeld: registreren klant, overboeken geld, opvragen jaarrekening en bijschrijven rente.

4. Kwaliteiten
Kwaliteiten geven antwoord op de vraag: Hoe goed moet de functie worden uitgevoerd om het eindresultaat te bereiken? Hoe snel? Hoe accuraat? Hoe veilig? Et cetera…

Voorbeeld: Overboeking is na 0,2 seconde verwerkt, klant kan alleen na identificatie geld overboeken.

Er zijn ook kwaliteiten die antwoord geven op de vraag: Hoe goed moet het product als geheel zijn om het eindresultaat te bereiken? Wanneer beschikbaar? Welke uitstraling? Et cetera…

Voorbeeld: Alle functies zijn 24×7 beschikbaar voor de klant, alle schermen voldoen aan de huisstijl van de bank.

5. Randvoorwaarden
Randvoorwaarden geven antwoord op de vraag: Welke grenzen worden gesteld aan de oplossingsrichting? Aan welke regelgeving en standaarden moet worden voldaan?

Voorbeeld: voldoen aan wetgeving van De Nederlandse Bank (DNB), voldoen aan de regels van de Autoriteit Financiele Markten (AFM).


Zo ontstaat er als het ware een piramide aan wensen en eisen
, waarbij alle wensen en eisen moeten bijdragen om  het gewenste eindresultaat te behalen. Wensen en eisen die dat niet doen kosten veel tijd, energie en geld. Zorg ervoor dat deze een lage prioriteit krijgen, of nog beter, worden geschrapt.

Samengevat, het gebruik van een requirementspiramide waarin de concrete en meetbare resultaten die de klant wil behalen centraal staan, maakt een enorm verschil. Zo’n piramidemodel maakt het mogelijk om producten en functies te leveren waar de klant ook echt tevreden mee is.

Reacties zijn welkom!

No comments yet.

Leave a Reply