Pk-laitevalmistajan tuotekehityksessä ei yleensä ole pulaa ideoista. Kehitysehdotuksia syntyy asiakaskeskusteluissa, tarjouspyynnöissä, huoltokäynneillä, reklamaatioissa, tuotannon poikkeamissa ja tuotteiden päivittäisessä käytössä.
Vaikeampi kysymys on, mitkä havainnot kertovat todellisesta asiakastarpeesta ja mitkä ratkaisut kannattaa toteuttaa.
Yhden asiakkaan äänekäs toive ei välttämättä edusta laajempaa tarvetta. Teknologisesti kiinnostava ominaisuus ei puolestaan automaattisesti tuota asiakkaalle arvoa tai valmistajalle kannattavaa liiketoimintaa.
Asiakaslähtöinen tuotekehitys tarvitsee siksi muutakin kuin teknistä suunnitteluosaamista. Se edellyttää järjestelmällistä tapaa kerätä tietoa, tunnistaa todellinen tarve, määrittää vaatimukset, vertailla ratkaisuja ja viedä valittu tuote hallitusti tuotantoon.
Asiakaslähtöisen tuotekehityksen tehtävänä on muuttaa hajallaan olevat havainnot asiakkaalle arvokkaiksi ja yritykselle kannattaviksi tuotteiksi.
Mitä asiakaslähtöinen tuotekehitys tarkoittaa?
Asiakaslähtöisyys ei tarkoita kaikkien asiakkaiden esittämien toiveiden toteuttamista. Se tarkoittaa asiakkaan toiminnan, ongelmien ja tavoitteleman hyödyn ymmärtämistä ennen ratkaisun valitsemista.
Asiakkaan esittämä toive on usein jo valmiiksi muotoiltu ratkaisu:
- tarvitaan tehokkaampi moottori
- ohjauspaneeliin halutaan uusi painike
- laitteesta pitäisi tehdä suurempi
- mobiilisovellukseen tarvitaan uusi ominaisuus
- yksi työvaihe pitäisi automatisoida
- tuotteeseen tarvitaan uusi asiakaskohtainen varuste.
Tuotekehityksen tehtävänä on selvittää, mikä varsinainen ongelma ehdotuksen taustalla on.
Tehokkaamman moottorin sijasta ratkaisu voi löytyä välityksestä, ohjauksesta tai käyttötavasta. Uuden painikkeen sijasta koko käyttöliittymän toimintalogiikkaa voidaan ehkä selkeyttää. Asiakaskohtaisen varusteen sijasta voidaan tunnistaa laajemmin tarvittava tuoteoptio.
Asiakaslähtöisyys on hyvä erottaa muutamista sitä muistuttavista lähtökohdista.
| Lähtökohta | Käytännön merkitys |
|---|---|
| Asiakaslähtöisyys | Selvitetään asiakkaan todellinen ongelma ja tavoiteltu hyöty |
| Asiakasohjautuvuus | Toteutetaan asiakkaan ehdottama ratkaisu sellaisenaan |
| Teknologialähtöisyys | Kehittäminen alkaa uuden teknologian mahdollisuuksista |
| Tuotantolähtöisyys | Kehittämisessä painotetaan valmistettavuutta ja tehokkuutta |
| Datalähtöisyys | Päätöksiä perustellaan palautteella, käyttödatalla ja toteutuneilla tuloksilla |
Hyvä tuotekehitys yhdistää nämä näkökulmat. Asiakkaan tarve antaa kehittämiselle suunnan, mutta ratkaisun pitää olla myös teknisesti toteuttamiskelpoinen, turvallinen, valmistettava ja liiketaloudellisesti perusteltu.
Tuotekehitys on enemmän kuin teknistä suunnittelua
Tuotekehitys ja tuotesuunnittelu eivät tarkoita aivan samaa asiaa.
Tuotekehityksessä ratkaistaan, mitä kehitetään, kenelle, miksi ja millaiseksi kokonaisuudeksi. Siihen kuuluvat asiakastarpeiden lisäksi kaupalliset tavoitteet, tuotestrategia, kustannukset, riskit ja tuotteen elinkaaren hallinta.
Tuotesuunnittelussa määritetään, miten valittu ratkaisu toteutetaan teknisesti. Siihen voivat kuulua mekaniikka, automaatio, elektroniikka, ohjelmisto, materiaalit ja teollinen muotoilu.
Tuotannollistamisessa varmistetaan, että tuote voidaan valmistaa, hankkia, koota, testata, dokumentoida ja toimittaa hallitusti.
Elinkaaren hallinnassa huolehditaan tuotemuutoksista, ohjelmistoversioista, varaosista, huollosta, dokumentaatiosta ja tuotteen hallitusta poistamisesta.
Tuotekehitys ei siten ole vain suunnitteluosaston tehtävä. Siihen tarvitaan myynnin, tuotannon, hankinnan, laadun, huollon ja johdon tietoa.
Asiakastietoa on paljon, mutta se on hajallaan
Pk-laitevalmistajan tuotekehityksessä tarvittavaa tietoa voi olla:
- CRM-järjestelmän asiakastiedoissa
- myyjien sähköposteissa ja muistiinpanoissa
- tarjouspyynnöissä
- voitetuissa ja hävityissä tarjouksissa
- reklamaatioissa
- huoltoraporteissa
- varaosatilauksissa
- tuotannon poikkeamissa
- ERP-järjestelmän toimitus- ja kustannustiedoissa
- PDM- tai PLM-järjestelmän piirustuksissa ja tuoterakenteissa
- käyttöohjeissa ja teknisissä dokumenteissa
- jälleenmyyjien ja kumppanien palautteessa
- laitteiden käyttö- ja sensoritiedoissa
- työntekijöiden kokemuksessa ja hiljaisessa tiedossa.
Ongelma ei välttämättä ole tiedon puute. Ongelma on usein se, ettei eri lähteistä muodostu yhteistä näkymää.
Myynti tuntee asiakkaiden esittämät toiveet. Huolto tietää, mitkä rakenteet vikaantuvat tai ovat vaikeita ylläpitää. Tuotanto tunnistaa valmistuksen hankalat työvaiheet. Hankinta näkee komponenttien saatavuuteen liittyvät riskit. Talous ja ERP-järjestelmä kertovat toteutuneista kustannuksista.
Jos nämä havainnot jäävät erilleen, sama ongelma voi esiintyä pitkään ilman, että sitä tunnistetaan tuotekehityksen kannalta merkittäväksi.
Toiminnanohjauksen kehittäminen alkaa siitä, että yrityksen työnkulut, vastuut ja tieto tehdään näkyviksi.
Tämä koskee myös tuotekehitystä. Yrityksen pitää määrittää, missä kehityshavainnot kirjataan, kuka niitä käsittelee ja miten tärkeät havainnot siirtyvät päätettäviksi.
Mistä asiakkaan todellinen tarve löydetään?
Asiakastarpeen selvittämisessä kannattaa edetä ratkaisuehdotuksesta ongelmaan ja ongelmasta tavoiteltavaan hyötyyn.
Hyviä kysymyksiä ovat:
- Mitä asiakas yrittää saada aikaan?
- Missä tilanteessa ongelma esiintyy?
- Ketä ongelma koskee?
- Kuinka usein se toistuu?
- Mitä kustannuksia, viivettä tai muuta haittaa siitä syntyy?
- Millainen parannus tuottaisi asiakkaalle todellista arvoa?
- Voidaanko tavoiteltava hyöty tai vaatimus mitata?
- Esiintyykö sama tarve myös muilla asiakkailla?
- Onko asiakas valmis maksamaan ratkaisusta?
- Sopiiko ratkaisu yrityksen tuotestrategiaan?
Asiakasta ei tarvitse ottaa mukaan jokaiseen tekniseen yksityiskohtaan. Asiakasyhteistyö on arvokkainta, kun:
- selvitetään ongelmaa ja käyttötilannetta
- tarkennetaan vaatimuksia
- arvioidaan vaihtoehtoisia konsepteja
- testataan prototyyppiä tai pilottia
- varmistetaan käytettävyys ja saavutettava hyöty
- kerätään kokemuksia tuotteen käytöstä.
Asiakkaan kuuleminen ei myöskään tarkoita vain kysymistä, mitä ominaisuuksia tuotteeseen halutaan. Usein arvokkaampaa on seurata, miten tuotetta käytetään ja missä työ todellisuudessa vaikeutuu, viivästyy tai aiheuttaa virheitä.
Asiakashavainnosta mitattavaksi vaatimukseksi
Asiakashavainto ei vielä ole tuotevaatimus. Se pitää tulkita, rajata ja muuttaa tavoitteeksi, jonka toteutuminen voidaan todentaa.
Hyvä etenemisketju on:
Asiakashavainto → todellinen tarve → mitattava vaatimus → ratkaisuvaihtoehdot → testaus → päätös
Esimerkiksi asiakkaan toive ”laitteen pitäisi olla nopeampi” on liian epätarkka suunnittelun lähtökohdaksi.
Ensin pitää selvittää:
- mikä työvaihe on liian hidas
- kuinka paljon aikaa siihen nyt kuluu
- mistä viive syntyy
- kuinka suuri nopeutuminen tuottaisi asiakkaalle hyötyä
- vaikuttaako muutos laatuun, turvallisuuteen tai energiankulutukseen
- missä olosuhteissa vaatimus pitää täyttää.
Tämän jälkeen vaatimus voidaan muotoilla mitattavaksi. Samalla määritetään, miten sen toteutuminen testataan.
| Vaihe | Keskeinen kysymys | Vastuu |
|---|---|---|
| Asiakashavainto | Mitä asiakas tai käyttäjä on havainnut? | Myynti, huolto tai asiakaspalvelu kirjaa havainnon |
| Todellinen tarve | Mikä ongelma pitää ratkaista? | Tuotekehitys varmistaa käyttötilanteen ja merkityksen |
| Vaatimus | Mitä ratkaisun pitää mitattavasti saavuttaa? | Tuotekehitys määrittää ja hyväksyttää vaatimuksen |
| Ratkaisuvaihtoehdot | Millä eri tavoilla vaatimus voidaan täyttää? | Suunnitteluryhmä muodostaa ja arvioi vaihtoehdot |
| Testaus | Miten toimivuus ja turvallisuus osoitetaan? | Suunnittelu, laatu ja tarvittaessa asiakas |
| Päätös | Toteutetaanko ratkaisu ja missä laajuudessa? | Nimetty päätöksentekijä tai ohjausryhmä |
Kun tämä ketju dokumentoidaan, myöhemmin voidaan nähdä, miksi ratkaisu valittiin ja mihin asiakkaan tarpeeseen se perustui.
Kaikkia kehitysideoita ei kannata toteuttaa
Pitkä kehitysideoiden luettelo ei vielä ole tuotekehitysstrategia. Yrityksen pitää pystyä vertailemaan kehityskohteita samoilla perusteilla.
Tuoteidean arvioinnissa kannattaa kysyä:
- Kuinka monelle asiakkaalle ratkaisusta on hyötyä?
- Kuinka suuri ja mitattava asiakkaan saama hyöty on?
- Ovatko asiakkaat valmiita maksamaan siitä?
- Parantaako ratkaisu myyntiä, hintaa tai asiakaspysyvyyttä?
- Sopiiko se yrityksen tuotestrategiaan ja osaamiseen?
- Kuinka vaikea ja kallis se on toteuttaa?
- Mitä turvallisuus-, laatu- ja vaatimustenmukaisuusriskejä siihen liittyy?
- Miten ratkaisu vaikuttaa valmistettavuuteen?
- Miten se vaikuttaa huollettavuuteen ja varaosiin?
- Mitä jatkuvia kustannuksia se aiheuttaa?
- Lisääkö se tuotevalikoiman monimutkaisuutta?
Yksinkertainen pisteytysmalli voi auttaa vaihtoehtojen vertailussa. Kriteereiksi voidaan valita esimerkiksi asiakasarvo, markkinapotentiaali, strateginen sopivuus, toteutuskustannus, tekninen riski ja elinkaarivaikutus.
Pisteytys ei tee päätöstä yrityksen puolesta. Se tekee valintaperusteet näkyviksi ja auttaa keskustelemaan siitä, miksi jokin kehityskohde asetetaan toisen edelle.
Vakioitu tuote, tuoteoptio vai asiakaskohtainen ratkaisu?
Yhden asiakkaan tarpeeseen tehty muutos voi näyttää hyvältä kaupalta. Se voi kuitenkin synnyttää vuosiksi uusia nimikkeitä, piirustuksia, varaosia, ohjelmistoversioita, työohjeita ja virhemahdollisuuksia.
Pk-laitevalmistajan tuoterakenne voidaan jakaa kolmeen tasoon:
- Vakioitu ydin, joka pidetään mahdollisimman yhtenäisenä.
- Ennalta suunnitellut vaihtoehdot ja moduulit, kuten koko-, teho-, varustelu- ja ohjelmistovaihtoehdot.
- Aidosti asiakaskohtaiset ratkaisut, jotka arvioidaan, hinnoitellaan ja hallitaan erillisinä.
Asiakaskohtaisista ratkaisuista ei tarvitse luopua. Niiden vaikutukset pitää kuitenkin tunnistaa ennen tarjouksen tekemistä.
Arvioitavia asioita ovat esimerkiksi:
- suunnittelutyön määrä
- uudet nimikkeet ja tuoterakenteet
- komponenttien saatavuus
- valmistuksen erityisjärjestelyt
- testaus ja dokumentointi
- varaosien hallinta
- huollon osaamistarve
- ohjelmistoversiot
- takuuseen ja vastuisiin liittyvät vaikutukset
- ratkaisun ylläpito koko elinkaaren ajan.
Jos sama asiakaskohtainen ratkaisu alkaa toistua, siitä voi olla perusteltua muodostaa hallittu tuoteoptio tai moduuli. Näin yksittäisistä toimituksista saatava oppi palautuu vakioidun tuotevalikoiman kehittämiseen.
Teollinen muotoilu, käyttökokemus ja brändi
Asiakaslähtöinen tuote ei ole vain teknisesti toimiva. Sen pitää olla myös ymmärrettävä, käytettävä, turvallinen, huollettava ja käyttökohteeseensa sopiva.
Teollinen muotoilu vaikuttaa muun muassa:
- tuotteen käytettävyyteen ja ergonomiaan
- toimintojen ymmärrettävyyteen
- turvallisuuden kokemukseen
- puhdistettavuuteen ja huollettavuuteen
- materiaalien ja rakenteiden valintaan
- valmistettavuuteen
- tuotteen tunnistettavuuteen
- yrityksen brändiin ja laatumielikuvaan.
Muotoilu kannattaa ottaa mukaan ennen kuin tekniset ratkaisut ovat täysin lukittuja. Jos sitä käsitellään vasta tuotteen ulkonäön viimeistelynä, monet käytettävyyteen, ergonomiaan ja valmistettavuuteen vaikuttavat valinnat on jo tehty.
Muotoilun, mekaniikan, käyttöliittymän, turvallisuuden ja yrityksen brändin pitää kehittyä yhtenä kokonaisuutena.
Prototyypit, simulointi ja asiakaspilotit
Ratkaisun testaaminen kannattaa aloittaa ennen kuin kaikki yksityiskohdat on viimeistelty.
Testattavana voi olla:
- luonnos
- käyttöliittymämalli
- tekninen laskelma
- simulaatio
- 3D-malli
- osaprototyyppi
- toiminnallinen prototyyppi
- rajattu asiakaspilotti.
Prototyypin tarkoituksena ei aina ole esitellä lähes valmista tuotetta. Sen avulla voidaan testata yhtä kriittistä oletusta mahdollisimman varhain ja pienin kustannuksin.
Testaukselle pitää määrittää etukäteen:
- mitä halutaan selvittää
- millä mittarilla onnistumista arvioidaan
- millaisissa olosuhteissa testi tehdään
- kuka hyväksyy tuloksen
- mitä tapahtuu, jos tavoite ei täyty.
Ilman ennalta määriteltyjä hyväksymisperusteita onnistuneen näköinen testi voi johtaa liian aikaiseen tuotantopäätökseen.
Tuotannollistaminen alkaa jo suunnitteluvaiheessa
Tuotannollistamista ei kannata jättää tuotekehitysprojektin loppuun. Tuotannon, hankinnan, laadun ja huollon näkökulmat pitää ottaa huomioon jo ratkaisuvaihtoehtoja arvioitaessa.
Tuotannollistamisessa varmistetaan muun muassa:
- materiaalien ja komponenttien saatavuus
- toimittajien toimituskyky
- tuoterakenteet ja nimikkeet
- valmistusmenetelmät
- työvaiheet ja työohjeet
- tarvittavat työkalut ja testauslaitteet
- laatuvaatimukset
- tarkastukset ja testaukset
- kapasiteetti ja läpimenoaika
- kustannuslaskenta
- käyttö- ja huolto-ohjeet
- varaosat
- henkilöstön koulutus.
Tuotannollistamisen puutteet näkyvät usein vasta ensimmäisissä toimituksissa: ylimääräisinä työtunteina, materiaalipuutteina, epäselvinä työohjeina, virheinä ja toimitusviiveinä.
Siksi tuotteen hyväksyminen teknisesti toimivaksi ei vielä tarkoita, että se olisi valmis hallittuun sarjatuotantoon.
Tuotekehityksen tieto eri järjestelmissä
Tuotekehityksen tarvitsema tieto ulottuu useisiin järjestelmiin:
- CRM kertoo, mitä asiakkaat kysyvät, millaisia tarpeita eri asiakasryhmillä on ja miksi tarjouksia voitetaan tai menetetään.
- ERP näyttää materiaalit, kustannukset, työvaiheet, toimitukset ja toteutuneet poikkeamat.
- PDM tai PLM hallitsee piirustukset, tuoterakenteet, versiot ja suunnittelumuutokset.
- Laatujärjestelmä kokoaa poikkeamia, reklamaatioita ja korjaavia toimenpiteitä.
- Huoltojärjestelmä kertoo vikakohteista, varaosista ja ylläpidon tarpeista.
- Projektinhallinta tekee tehtävät, vastuut, aikataulut ja päätökset näkyviksi.
- Laitteiden käyttötiedot kertovat, miten tuotteita todellisuudessa käytetään.
Kaikkea tietoa ei tarvitse tallentaa samaan järjestelmään. Yrityksen pitää kuitenkin tietää:
- mikä järjestelmä on minkäkin tiedon ensisijainen lähde
- kuka vastaa tiedon oikeellisuudesta
- miten eri järjestelmien tiedot yhdistetään samaan tuotteeseen
- miten muutokset hyväksytään
- miten uusin hyväksytty versio tunnistetaan.
Tuotetunnusten, nimikkeiden, asiakastietojen, laiteversioiden ja dokumenttien pitää olla riittävän yhdenmukaisia. Muuten asiakkaan palaute, huoltohistoria ja valmistustiedot eivät yhdisty oikeaan tuotteeseen tai toimitukseen.
Tuotekehitys ylittää organisaatiorajat
Tuotekehitys ei ole vain suunnitteluosaston tehtävä. Asiakasarvo voi kadota, jos tieto katkeaa myynnin, suunnittelun, tuotannon ja huollon välillä.
| Toimija | Tuotekehitykseen tuoma tieto |
|---|---|
| Asiakas ja käyttäjä | Käyttötilanne, ongelma ja odotettu hyöty |
| Myynti | Kysyntä, kilpailutilanne ja maksuhalukkuus |
| Suunnittelu | Tekninen toteutettavuus ja riskit |
| Teollinen muotoilu | Käytettävyys, ergonomia, ilme ja brändin jatkuvuus |
| Tuotanto | Valmistettavuus, laatu ja työmenetelmät |
| Hankinta | Saatavuus, kustannukset ja toimittajariskit |
| Huolto | Vikakohteet, ylläpidettävyys ja elinkaaren tarpeet |
| Laatu | Poikkeamat, testaus ja vaatimustenmukaisuus |
| Johto | Strateginen sopivuus ja resurssien kohdentaminen |
Yhteistyö ei synny vain lisäämällä ihmisiä kokouskutsuun. Yrityksen pitää määrittää, missä vaiheessa kutakin asiantuntijaa tarvitaan ja millaisista asioista hänen odotetaan antavan näkemyksensä.
Myös päätösvalta pitää tehdä näkyväksi. Jokaisessa tuotekehitysprojektissa pitäisi olla selvää:
- kuka omistaa tuotteen tai projektin
- kuka hyväksyy vaatimukset
- kuka päättää teknisestä ratkaisusta
- kuka hyväksyy kustannukset
- kuka vastaa tuoteturvallisuudesta
- kuka antaa luvan siirtyä tuotantoon
- kuka vastaa tuotteen elinkaaren aikaisista muutoksista.
Käytännön etenemismalli pk-laitevalmistajalle
1. Kokoa asiakas-, huolto- ja käyttöhavainnot
Määritä yhteinen tapa, jolla myynnin, huollon, tuotannon ja asiakkaiden havainnot kirjataan. Kaikkea ei tarvitse siirtää heti yhteen järjestelmään, mutta lähteet, vastuut ja käsittelytapa pitää tunnistaa.
2. Ryhmittele ja arvioi havainnot
Etsi toistuvia ongelmia ja vertaile eri asiakkaiden, tuotteiden ja käyttötilanteiden kokemuksia. Tarkista, perustuuko kehitysidea yksittäiseen mielipiteeseen vai laajempaan tarpeeseen.
3. Selvitä todellinen ongelma
Älä siirrä asiakkaan esittämää ratkaisua suoraan suunnittelutehtäväksi. Selvitä käyttötilanne, ongelman syy, yleisyys ja asiakkaalle syntyvä haitta.
4. Muunna tarve mitattaviksi vaatimuksiksi
Määritä tekniset, toiminnalliset, kaupalliset ja turvallisuuteen liittyvät vaatimukset. Kirjaa myös, miten niiden toteutuminen testataan.
5. Arvioi asiakasarvo ja liiketoiminta-arvo
Vertaa asiakkaan saamaa hyötyä, markkinapotentiaalia, kustannuksia, strategista sopivuutta ja tuotteen elinkaarivaikutuksia.
6. Suunnittele ja vertaile vaihtoehtoja
Älä lukkiudu ensimmäiseen ratkaisuun. Ota tuotanto, hankinta, huolto, laatu ja muotoilu mukaan ennen keskeisten ratkaisujen lukitsemista.
7. Testaa ja varmista turvallisuus
Käytä prototyyppejä, simulointia ja asiakaspilotteja. Määritä hyväksymisperusteet ennen testaamista ja dokumentoi tulokset.
8. Tuotannollista hallitusti
Varmista tuoterakenteet, materiaalit, työvaiheet, kustannukset, laadunvarmistus, dokumentaatio, huolto ja hankintaketju ennen laajempaa käyttöönottoa.
9. Seuraa tuotetta käytössä
Kerää käyttökokemukset, poikkeamat, reklamaatiot, huoltotiedot ja toteutuneet kustannukset. Vertaa tuloksia alkuperäisiin tavoitteisiin.
10. Palauta opit seuraavaan kehityskierrokseen
Käsittele käytöstä saatu tieto säännöllisesti. Siirrä toistuvat havainnot uusiksi kehitystarpeiksi, tuoteoptioiksi, työohjeiksi tai olemassa olevien tuotteiden parannuksiksi.
Prosessin voi tiivistää näin:
Kerää havainto → selvitä todellinen tarve → määritä vaatimus → vertaile ratkaisuja → testaa → tuotannollista → seuraa käyttöä → opi
Tuotekehityksen yleisimmät ongelmat
Asiakaslähtöisessä tuotekehityksessä kannattaa varoa erityisesti seuraavia tilanteita:
- yksittäinen äänekäs asiakas määrittää kehityksen suunnan
- myynti lupaa muutoksen ennen teknistä ja kaupallista arviointia
- asiakastoive kirjataan ratkaisuna eikä ratkaistavana ongelmana
- suunnittelu optimoi tekniikkaa ilman asiakashyödyn mittaria
- vaihtoehtoja ei vertailla, vaan ensimmäinen idea valitaan
- tuotanto, hankinta, huolto tai muotoilu otetaan mukaan liian myöhään
- projektikustannukset arvioidaan, mutta elinkaarikustannuksia ei
- tuoteversioita ja asiakaskohtaisia muutoksia kertyy hallitsemattomasti
- vastuut ja hyväksymispäätökset jäävät epäselviksi
- pilotista siirrytään tuotantoon ilman hyväksymisperusteita
- dokumentaatio ei vastaa tuotteen viimeisintä versiota
- tuotteen todellisesta käytöstä ei kerätä järjestelmällisesti tietoa
- huollon ja reklamaatioiden havainnot eivät palaudu tuotekehitykseen.
Tuotekehityksen tarkistuslista
Ennen uuden tuotteen, ominaisuuden tai tuoteversion toteuttamista kannattaa tarkistaa ainakin seuraavat asiat.
Asiakastarve
- Onko asiakkaan todellinen ongelma selvitetty?
- Onko tarve tunnistettu useammalla kuin yhdellä asiakkaalla?
- Onko asiakkaan saama hyöty määritetty?
- Voidaanko hyöty mitata?
- Onko asiakas valmis maksamaan ratkaisusta?
Liiketoiminta
- Sopiiko ratkaisu yrityksen strategiaan?
- Onko markkinapotentiaali arvioitu?
- Onko tavoitekustannus määritetty?
- Onko koko elinkaaren kustannukset huomioitu?
- Lisääkö ratkaisu kannattavasti myyntiä tai asiakaspysyvyyttä?
Tekniikka ja turvallisuus
- Ovatko vaatimukset mitattavia?
- Onko vaihtoehtoisia ratkaisuja vertailtu?
- Onko tekniset riskit tunnistettu?
- Onko tuoteturvallisuus ja vaatimustenmukaisuus huomioitu?
- Onko testaus- ja hyväksymissuunnitelma laadittu?
Tuotanto ja hankinta
- Voidaanko tuote valmistaa nykyisillä menetelmillä?
- Ovatko materiaalit ja komponentit saatavissa?
- Ovatko toimittajariskit tiedossa?
- Ovatko tuoterakenteet, nimikkeet ja työohjeet valmiit?
- Ovatko kapasiteetti ja läpimenoaika riittäviä?
Huolto ja elinkaari
- Voidaanko tuote huoltaa turvallisesti?
- Ovatko varaosat määritetty?
- Onko dokumentaatio kunnossa?
- Miten tuotemuutokset ja versiot hallitaan?
- Miten käyttökokemukset ja huoltotiedot palautuvat tuotekehitykseen?
Päätöksenteko
- Onko tuotteen tai projektin omistaja nimetty?
- Ovatko vastuut ja päätösvalta selvät?
- Onko keskeiset valinnat ja niiden perustelut dokumentoitu?
- Onko tuotantoon siirtymiselle annettu muodollinen hyväksyntä?
Miten pk-yritys pääsee alkuun?
Tuotekehityksen kehittäminen ei välttämättä edellytä uuden järjestelmän hankkimista tai raskaan prosessimallin rakentamista.
Hyvä ensimmäinen vaihe voi olla yhden olemassa olevan tuotteen tarkastelu:
- Kokoa tuotetta koskevat reklamaatiot, huoltoraportit ja asiakaspalautteet.
- Selvitä, mitkä ongelmat toistuvat.
- Vertaa havaintoja tuotannon poikkeamiin ja toteutuneisiin kustannuksiin.
- Valitse yksi asiakkaalle ja yritykselle merkittävä kehityskohde.
- Muotoile havainto todelliseksi tarpeeksi ja mitattavaksi vaatimukseksi.
- Laadi vähintään kaksi ratkaisuvaihtoehtoa.
- Arvioi asiakasarvo, kustannukset, riskit ja elinkaarivaikutukset.
- Testaa valittu ratkaisu rajatusti.
- Dokumentoi päätös ja sen perustelut.
- Seuraa, toteutuiko tavoiteltu hyöty käytännössä.
Tavoitteena ei ole tehdä tuotekehityksestä tarpeettoman raskasta. Tavoitteena on estää tärkeän tiedon katoaminen ja varmistaa, että kehittämiseen käytettävät voimavarat kohdistuvat oikeisiin asioihin.
Tekoäly tuotekehityksen tukena
Tekoäly voi tulevaisuudessa auttaa yritystä esimerkiksi asiakaspalautteen jäsentämisessä, toistuvien ongelmien tunnistamisessa, ratkaisuvaihtoehtojen ideoinnissa ja testitulosten käsittelyssä.
Sen käyttö ei kuitenkaan poista tarvetta toimivalle tuotekehitysprosessille. Asiakastarpeet, vastuut, hyväksymisperusteet ja tuotetiedon hallinta pitää määrittää riippumatta siitä, millaisia teknisiä työkaluja yritys käyttää.
Tekoälyn mahdollisuuksia asiakaslähtöisen tuotekehityksen eri vaiheissa käsitellään tarkemmin Polaris AI Ecosystem sivuston ai.toiminnanohjaus.fi :n artikkelissa:
Tekoäly asiakaslähtöisessä tuotekehityksessä – käytännön malli pk-laitevalmistajalle
Lopuksi: tuotekehitys on jatkuvaa oppimista
Asiakaslähtöinen tuotekehitys ei ole yksittäinen asiakashaastattelu projektin alussa. Se on jatkuva toimintamalli, jossa asiakashavainnot muutetaan vaatimuksiksi, vaatimukset hallituiksi ratkaisuiksi ja tuotteiden käytöstä saatava tieto seuraavan kehityskierroksen lähtökohdaksi.
Parhaimmillaan yritys oppii jokaisesta tarjouspyynnöstä, toimituksesta, huoltokäynnistä, reklamaatiosta ja käytössä olevasta tuotteesta.
Kun tiedonkulku, vastuut ja päätöksenteko on järjestetty, yksittäiset havainnot eivät jää ihmisten muistiin tai erillisiin dokumentteihin. Ne muuttuvat yhteiseksi tiedoksi, jonka avulla yritys voi kehittää tuotteitaan määrätietoisesti.
Hyvä tuotekehitys yhdistää asiakkaan todellisen tarpeen, yrityksen osaamisen ja tuotteiden käytöstä syntyvän tiedon kannattaviksi ja hallittaviksi ratkaisuiksi.