Kirjoittaja: Esa Hietikko
Vaikka Kano-luokittelu antaakin tuotekehitykselle erinomaista tietoa asiakkaiden tarpeista, ei sen käyttö ole ongelmatonta varsinkaan PK-yritysten kyseessä ollen. Suurimmat ongelmat liittyvät kyselyiden toteutukseen ja vastaajien määrään.
Jos luokiteltavia ominaisuuksia on paljon, kasvaa myös kyselyyn vastaamiseen käytettävä aika, koska jokaista tuoteominaisuutta kohden tulee kaksi vastattavaa kysymystä, joissa kummassakin on viisi valintavaihtoehtoa. Tämä voi johtaa siihen, että vastaajat eivät jaksa suorittaa kyselyä loppuun asti tai ainakin vastausten laatu huononee loppua kohden. Vastaajan on myös ymmärrettävä, mikä kysymyksen kohteena oleva tuotteen ominaisuus on ja miten se vaikuttaa tuotteen käyttöön.
Kysymysten muotoilu voi olla myös ongelmallista. Tästä onkin tehty erilaisia kokeiluja, mutta edelleenkään muita selkeästi parempaa toteutusta ei ole löydetty. Esimerkiksi kyselyn vastaukseen ”Like” (”Pitää”) voisi olla pelkän yhden sanan sijasta seuraavia, laajemmin avaavia vaihtoehtoja (MacDonald et al,2006):
- Pidän tästä ominaisuudesta
- Pidän siitä tuollaisena
- Olisin mielissäni, jos se olisi noin
- Paljon odotuksia parempi
Kano-kysely voi myös tuottaa epäloogisia tuloksia. Esimerkiksi, jos vastaaja valitsee toiminnalliseen kysymykseen ”Neutraali” ja toimimattomaan ”Pettynyt”, on tuloksena luokka M eli Must be. Mutta vastauspari on epälooginen: jos vastaajalla ei todella ole mitään tunteita silloin kun ominaisuus tuotteesta löytyy, miksi hän vastaisi olevansa pettynyt, jos se siitä puuttuu. Kano-malli ei myöskään kerro asiakastyytyväisyyden astetta, vaan paremminkin erilaisia tunnetiloja (”pitää”, ”on hyväksyttävissä”, ”neutraali”, ”must be”, ”ei pidä”, ”joku muu tunne”).
Yksi suurimmista Kanoon liittyvistä ongelmista on vastaajien lukumäärä. Mitä vähemmän vastaajia, sitä suurempi mahdollisuus on virheellisiin tulkintoihin. Ja virheelliset luokittelut voivat johtaa hyvin merkittäviin seurauksiin, jos esimerkiksi Performance-luokkaan kuuluva tuoteominaisuus tulkitaan Must-be -ominaisuudeksi.
Rashid ((Md Rashid, 2014) on selvittänyt simuloimalla, kuinka paljon vastaajia tarvitaan, että voidaan luotettavasti selvittää luokkaan Must-be kuuluvat ominaisuudet. Hänen mukaansa vastaajia tarvitaan vähintään 100 kpl, jotta tulosta voidaan pitää luotettavana.
Johtuen suuresta tuoteominaisuuksien määrästä ja pienestä vastaajien joukosta, laajamittaisen Kano-kyselyn toteuttaminen ei ole useinkaan mahdollista. Ratkaisuna voi olla kysely, jossa tuoteominaisuuksien luokittelu tehdään suoraan Kano-mallin mukaan. Tämä voi olla epävarmaa ja riskialtista, mutta saattaa silti useassa tapauksessa olla parempi kuin ei luokittelua ollenkaan. Vastaajien innokkuuteen vastaamiseen vaikuttaa myös kysymyksen asettelu. Esimerkiksi suoraan Kano-luokkiin M, O, A ja I/R luokitteleva kysymys ”Must-be”, ”Must-be very performing”, ”Nice option” ja ”No need” houkuttelee vastaamaan paljon paremmin kuin perinteinen Kano-kysymyspari jo senkin takia, että vastausvaihtoehtoja on vain neljä perinteisen Kano-kyselyn 10 vaihtoehdon sijasta.
Jos tuoteominaisuuksia on paljon, on ne hyvä ryhmitellä kyselyssä esimerkiksi käytön mukaan (aloitus, siirto, käyttö, huolto jne.).
Lähteet
- MacDonald, E., Backsell, M., Gonzalez, R., Papalambros, P., n.d. The Kano Method’s Imperfections, and Implications in Product Decision Theory. Presented at the 2006 International Design Research Symposium.
- Md Rashid, 2014. CUSTOMER NEEDS SIMULATION SYSTEM FOR INVESTIGATING MUST-BE ATTRIBUTE. J. Mech. Eng. 44. https://doi.org/10.3329/jme.v44i1.19500