Kano-analyse

Doel

Beter begrijpen welke waarde de demandorganisatie geeft aan de kenmerken van de IT-service. Dit kan het risico verminderen dat IT-services worden geleverd die kenmerken bevatten die van weinig belang zijn of die cruciale kwaliteitskenmerken/-attributen (critical to quality (CtQ)  missen.

Beschrijving

  • Basis- of ‘must have’-attributen. Deze worden door de klant verwacht. De IT-service kan worden afgewezen indien deze niet een aanvaardbaar niveau van dit kenmerk heeft. Klanten noemen dit zelden wanneer wordt gevraagd wat voor hen belangrijk is. Vaak gaat het hierbij om ‘vanzelfsprekendheden’. Dissatisfiers: basisbehoeften.
  • Onderscheidende of ‘lineaire’ attributen. Worden door de klant als gelijkwaardig beschouwd maar verhogen de klanttevredenheid vaak wel. Beoordeling is vaak gebaseerd op aspecten als kosten/prijs, gebruiksgemak, snelheid enzovoort. Satisfiers: zorgen voor de normale kwaliteit
  • Opvallende of ‘opwindende’ attributen. Worden door de klant vaak niet verwacht (zijn zeker niet vereist) en maken vaak het verschil bij het maken van een keuze. Het gaat vaak om innovatieve aspecten. Delighters: zorgen voor buitengewone kwaliteit.

Gebruik

  • Verzamel VoC (en VoB) gegevens op zo veel mogelijk verschillende manieren.
    Alle behoeften van de klant- c.q. gebruikersorganisatie kunnen niet door middel van een enkele methode worden geïdentificeerd.
  • Identificeer bekende of vermoedelijke behoeften/eisen van de demandorganisatie.
  • Voor iedere potentiële behoefte/eis wordt de demandorganisatie gevraagd om het volgende te beoordelen:
    • Hoe zouden ze zich voelen als de behoefte/eis waardevol is? (Positief).
    • Hoe zouden ze zich voelen als de behoefte/eis niet waardevol is? (Negatief).
    • De klant heeft op elke vraag vier mogelijkheden om te antwoorden:
      1. Ik vind het leuk (like).
      2. Het is normaal, de functie wordt verwacht (normal).
      3. Het maakt me niet uit (don’t care).
      4. Ik zou het niet leuk vinden (don’t like).
    • Op basis van de antwoorden op de ‘positieve’ en ‘negatieve’ vragen, wordt de typering tot noodzaak bepaald.
  • Op basis van reacties van demandorganisatie wordt iedere behoefte/eis geclassificeerd als een dissatisfier, satisfier of delighter.
  • De informatie wordt verwerkt in de ontwikkelingsinspanningen voor de IT-service.
    • De basisbehoeften/-eisen (dissatisfiers) MOETEN worden behandeld, als deze nog geen onderdeel is van de IT-service. Als hier geen aandacht aan wordt besteedt, maakt het niet uit hoe goed de andere functies of opties worden geleverd. Geëvalueerd dient te worden hoeveel satisfiers´ acceptabel zijn binnen de IT-service. Als er al ‘delighters’ in de IT-service zitten, versterk de steun hiervan. Als deze er niet zijn, dient samen met het management gekeken te worden naar inspanningen voor een (her-)ontwerp, om de nieuwe functies op te nemen die zijn geïdentificeerd (nadat de ‘dissatisfiers’ en ‘satisfiers’ zijn behandeld).
    • De basisbehoeften/-eisen (dissatisfiers) MOETEN worden behandeld, als deze nog geen onderdeel zijn van de IT-service. Als hier geen aandacht aan wordt besteed, maakt het niet uit hoe goed de andere functies of opties worden geleverd. Geëvalueerd dient te worden hoeveel `satisfiers´ acceptabel zijn binnen de IT-service. Als er al ‘delighters’ in de IT-service zitten, versterk de steun hiervan. Als er geen ‘delighters’ zijn, dient samen met het management gekeken te worden of er een (her)ontwerp nodig is, om de nieuwe functies die zijn geïdentificeerd (nadat de ‘dissatisfiers’ en ‘satisfiers’ zijn behandeld) alsnog op te nemen.


Reageren niet meer mogelijk.

Supported by