Informatie Analyse is het ontwerpen van klanttevredenheid

Author: Marcel van den Bosch Date: 09-nov-2013

Als business-/informatieanalist ben je verantwoordelijk voor het in kaart brengen van de benodigdheden voor een softwareproduct. Dit softwareproduct wil een organisatie wil gaan ontwikkelen om een bepaald probleem op te lossen of om in te springen op een nieuwe kans.

Nu zal een grondig uitgevoerde Requirements Analyse een set met eisen en wensen opleveren, waarna een functioneel ontwerp van een softwaresysteem gemaakt kan worden. Echter, van welke functionaliteit wordt de opdrachtgever nu echt blij? En welke functionaliteit dient er minimaal aanwezig te zijn, om teleurstelling te voorkomen?

Kortom, de rol van business-/informatieanalist heeft een directe invloed op – en is zeer belangrijk voor – de tevredenheid van de opdrachtgever.

De ‘revolutionaire’ point-and-click interface

“Vroeger” (dat zeg ik als eind-twintiger) heb ik als softwareontwikkelaar een opdracht uitgevoerd voor een klant waarbij er een simpel administratief systeem gebouwd diende te worden. Dit was in de tijd dat functietoetsen (je weet wel, de knoppen met F1, F2, etc. op het toetsenbord) nog standaard onderdeel waren van de bediening van de software.

Nadat alle eisen en wensen in kaart waren gebracht en ik een ontwerp had gemaakt op basis van een tekstuele interface, zoals dat in die tijd nog gebruikelijke was, had ik op zich een ontwerp van een systeem wat prima aan de basiswensen van mijn klant voldeed.

Echter, er waren toen de nieuwe ontwikkelingen van Windows en het gebruik van de muis in dialoogschermen. De zogenaamde ‘point en click’ interface. Met dit in gedachte, heb ik het ontwerp van de applicatie gebaseerd op deze vorm van gebruikersinterface.

De klant waarvoor ik de uiteindelijke applicatie heb ontwikkeld was bijzonder tevreden over het bedieningsgemak en de snelle manier waarmee hij zijn software kon gebruiken. 

Tevredenheid versus een mislukt softwareproduct

Wat ik als jonge programmeur al ontdekte, was dat de tevredenheid van opdrachtgevers over de functionaliteit van software erg kon verschillen. Het bovengenoemde voorbeeld beschrijft een situatie waarbij de klant zich niet bewust was van bepaalde wensen. Het toch vervullen van deze wens, heeft een bijzonder groot gevoel van tevredenheid gebracht.

Een omgekeerde situatie komt ook nog wel eens voor. Soms is er een bepaalde eis niet helemaal goed ‘op de radar’ gekomen is tijdens de requirements analyse. Het ontbreken van een bepaalde basis eis kan tot een bijzonder groot gevoel van ontevredenheid leiden bij de opdrachtgever.

Ook kan het enthousiasme van bepaalde wensen gedurende de tijd veranderen. Iets wat vroeger erg gaaf en boven de verwachting was (een point-and-click interface bijvoorbeeld), is iets wat hedendaags ondenkbaar is om niet te doen in desktop applicaties.

Het KANO-Model voor productontwikkeling en klanttevredenheid.

Het analyseren van klanttevredenheid is onderzocht door Prof. Noriaki Kano (http://www.walden-family.com/public/cqm-journal/2-4-Whole-Issue.pdf ) , die hier een model voor heeft ontwikkeld. De onderstaande afbeelding geeft dit model schematisch weer.

Het KANO model maakt een classificatie van de eisen en wensen van een klant in drie categorieën. 
•  Basis factoren
•  Opwindingsfactoren
•  Prestatiefactoren

Het KANO-model en bijbehorende aanpak gebruikt men vaak bij projectselecties, product-/service ontwikkeling, of bij het bepalen van marktstrategieën. 
De oorspronkelijke aanpak van KANO beschrijft een set aan vragenlijsten en matrices die kunnen worden gebruikt voor het indelen van requirements – ook wel: Critical to Quality Characteristics (CTQs) genoemd - in deze categorieën. 

Basis factoren (dissatisfiers)

Dit zijn eigenschappen die het softwareproduct moet bezitten, waarvan er eigenlijk onbewust van uit wordt gegaan dat deze aanwezig zijn – het moet er gewoon in zitten. Wanneer deze eigenschappen niet aanwezig zijn, zal dit tot grote ontevredenheid en teleurstelling leiden bij de stakeholders.

Opwindingsfactoren (satisfiers)

Dit zijn door de opdrachtgever specifiek gevraagde eigenschappen. Zeer bewuste eisen en wensen dus. Wanneer er teveel van deze eigenschappen niet in het softwareproduct zitten, zal de opdrachtgever uiteindelijk het niet accepteren. De tevredenheid van het softwareproduct is afhankelijk van het aantal van deze gerealiseerde eigenschappen.

Prestatiefactoren (delighters)

Onder deze categorie vallen eigenschappen waarvan de opdrachtgever zich nog niet bewust was en de waarde ervan pas inziet bij het gebruik van het systeem. Dit zal bij de opdrachtgever tot onverwachts enthousiasme en hoge klanttevredenheid leiden.

Invloed van tijd

Zoals in mijn voorbeeld van de point-and-click interface al blijkt, zal naar verloop van tijd de waardering van requirements in deze categorieën veranderen. Zo zullen prestatiefactoren langzaam opwindingsfactoren worden en zullen opwindingsfactoren naar verloop van tijd – wanneer de klant eenmaal hieraan gewend is – basisfactoren worden. 

Van de positieve kant bekeken: Op die manier zijn er bij elk nieuw te ontwikkelen softwareproduct altijd manieren om de klant steeds opnieuw aangenaam te verassen!