Tuotekehityksen ohjaus ja tuotteen spesifikaatiot
Jälleen kyseessä on laaja, monta kymmentä sivua käsittävä aihealue. Tiivistän minkä pystyn:
Saatuanne tuotteen asiakastarpeista riittävän kuvan on paras mielestäni mallintaa parhaat ideat joko puolittain toimiviksi prototyypeiksi tai jossain määrien käyttäen designerin laatimia mallinnusvaihtoehtoja. Seuraavassa vaiheessa kannattaa nimittäin esitellä ajatellut konseptit valikoidulle asiantuntijaryhmälle, joka koostuu myös avainasiakkaista. Tilaisuus antaa mielenkiintoisella tavalla vahvistuksia olettamuksille tai luo uutta näkökulmaa joihinkin yksityiskohtiin. Uskon kuitenkin, hyvällä pohjatyöllä ja mielikuvitusrikkailla tuotekehittäjillä on esittää hyviä vaihtoehtoja. Prototyyppi on siinä mielessä hyvä vaihtoehto, että useimmat ihmiset eivät osaa kommentoida ennen kuin he saavat koskettaa ja käännellä tuotetta. Designer tuo mukanaan jo aidon tuotteen tuntua ja laadukkaan ulottuvuuden tuotteeseen. Palvelut eivät ole lopputulokseen verrattuna kalliita, ellette lähde kaikkein nimekkäimpien teollisten muotoilijoiden matkaan.
Tuoteominaisuuksien analyysi
Voitte käyttää vielä QFD-analyysiä suunnitelmanne tueksi. Kyseinen menetelmä antaa tarkan hintalapun kullekin valitulle ominaisuudelle sekä suhteuttaa ne myös kilpailijoiden tuotteisiin. QFD-taulukon teko vaatii aikaa ja pohdiskelua, mutta jos tuotteellanne on jatkuvaa kehitystarvetta tuottaa tehty panostus itsensä moninkertaisesti takaisin. On tutkittu, että tekninen suunnitteluvirhe nostaa tuotteen kehityskuluja noin 28%, mutta väärän ominaisuuden kehittäminen tuotteeseen nostaa kuluja jopa 72%. Lisää tietoja QFD:n käytöstä ja “laadun talon” rakentamisesta esimerkiksi internetistä:
http://fi.wikipedia.org/wiki/QFD
Tuotespesifikaatiot
Tavoitteena on siis kehittää tuotteen ominaisuuksia kuvaava luettelo ja tietenkin nämä ominaisuudet täyttävä tuote. Ohessa erään tuotteen ominaisuuksien otsikkotason lista:
| Headline | Including items like: |
| Performance | Speed, capacity, accuracy |
| Features | Standard and optional functions |
| Reliability | Mean time between a stop (MTBS) |
| Durability | Mean time between a failure (MTBF) |
| Serviceability | Maximum time of changing a module |
| Appearance | Design, colours |
Table: Headlines of the product specification
Muunna kaikki lukuarvoiksi
Kaikille määrityksille on annettava selkeitä lukuarvoja, sillä insinööri ei pysty tekemään tuotetta vaatimuksella että “sen on oltava nopea”. Hän kysyy kuitenkin mihin verrattuna, tai pyytää lukuarvoja. Tehkäämme siis kokeita ja mittauksia vaikkapa kilpailijan tuotteella ja annetaan selkeitä vastauksia. Tuotekehitys onkin tämän jälkeen normaalia projektin hallintaa, eikä mainittavia takapakkeja pitäisi syntyä. Kunhan vain pidämme suunnitelmastamme kiinni ja aika-ajoin katselmoimme saavutukset kunnolla. Katselmointi on vielä eräs tärkeimmistä vaiheista kun varmistetaan, että valitut ratkaisut täyttävät asiakastarpeet. Korjaamista voidaan tehdä yleensä vielä varatun projektiajan puitteissa mutta väärillä ominaisuuksilla varustettu tuote joutaa romukoppaan.
Tässä pikaesityksenä hallitun tuotekehityksen vaiheet elävästä elämästä poimittuna. Tuotekehitykseen liittyvät myös Projektihallintatyökalut hyvin läheisesti. Mielelläni esittelisin vielä vaikkapa Kone Oy:n menetelmiä mutta tästä tulisi aivan liian pitkä teos.