1 LAPPEENRANNAN TEKNILLINEN YLIOPISTO LUT School

Transcription

1 LAPPEENRANNAN TEKNILLINEN YLIOPISTO LUT School
1
LAPPEENRANNAN TEKNILLINEN YLIOPISTO
LUT School of Business and Management
Tuotantotalouden koulutusohjelma
Virve Piiroinen
TUOTEKEHITYSPROSESSIN SUORITUSKYVYN PARANTAMINEN PIENIKOKOISESSA TUOTEKEHITYSORGANISAATIOSSA
Tarkastaja:
Professori Hannu Rantanen
2
TIIVISTELMÄ
Tekijä: Virve Piiroinen
Työn nimi: Tuotekehitysprosessin suorituskyvyn parantaminen pienikokoisessa tuotekehitysorganisaatiossa
Vuosi: 2015
Paikka: Lahti
Diplomityö. Lappeenrannan teknillinen yliopisto, tuotantotalous.
98 sivua, 9 kuvaa
Tarkastaja(t): Professori Hannu Rantanen
Hakusanat: Tuotekehitysprosessi, suorituskyvyn parantaminen, menestystekijät
Tutkimuksen tavoite on selvittää tuotekehitysprosessin vaiheet ja niihin vaikuttavia tekijöitä sekä löytää keinoja, joilla parantaa pienikokoisen tuotekehitysorganisaation tuotekehitysprosessia ja tuotekehitystoimintaa. Tutkimuksessa selvitettiin, miten hyvin kohdeorganisaation tuotekehitysprosessi vastaa teoriamääritelmiä dokumenttitarkasteluna. Lisäksi kartoitettiin kohdeorganisaation tuotekehitystoiminnan nykytilaa ja haastattelemalla
henkilökuntaa. Tutkimusote on toiminta-analyyttinen.
Kohdeorganisaatiolla on dokumentoitu tuotekehitysprosessi, josta käy ilmi vaiheet, kriteerit ja vastuut. Prosessi vastaa teoriamääritelmiä sitä paremmin, mitä lähemmäksi prosessin loppua siirrytään. Haastatteluista tuli ilmi, että kohdeorganisaation vahvuudet ovat
työntekijöiden osaamisessa ja asenteessa sekä työilmapiirissä. Suurimpia kehityskohtia
ovat resurssitilanne ja tuotemäärittelyjen taso. Kohdeorganisaatiossa on liian vähän tekijöitä tehtävämäärään nähden ja tuotemäärittelyt muuttuvat usein prosessin aikana. Seurauksena on mm. aikataulujen venyminen ja suunnittelun laadun heikkeneminen. Tuotekehitystoiminta nähtiin pääasiassa tuotteiden tuotteistamisessa, ei tuoteideoiden kehittämisessä. Tuotekehitysprosessin tuntemus vaihtelee ja asiakastarpeet eivät ole tuotekehitykselle selvät. Lisäksi henkilökunta ei tunne täysin suorituskyvyn mittareita ja menossa
olevia kehityshankkeita.
Prosessin kriteerien päivitys ja painotus etupään tehtäviin parantaisi prosessia etenkin
prosessin loppupään toiminnoissa. Toiminnan parantamiseksi resursointitilannetta pitää
parantaa ja tuotemäärittelyjen analysointiin tulee panostaa enemmän. Lisäksi koulutus
prosessista, asiakastarpeista, mittaamisesta ja kehityshankkeista parantaisi kokonaiskuvan ymmärtämistä ja näin ollen toiminnan taso parantuisi. Innovaatiotoiminnan ja ideoinnin lisäämiseksi tulisi tutkia, mitä mahdollisuuksia toiminnan lisäämiseksi on.
3
ABSTRACT
Author: Virve Piiroinen
Subject: Improving product development process performance in small-sized product development organization
Year: 2015
Place: Lahti
Master’s thesis. Lappeenranta University of technology, industrial engineering.
98 pages, 9 pictures
Examier(s): Professor Hannu Rantanen
Keywords: Product development process, performance improvement, success factor
The goals of this study are to clarify the product development process stages and factors
affecting them together with finding ways to improve product development process and
activities in a small-sized product development organization. The study examined how well
the target organization’s product development process matches theory as document review. Also the current state of R&D activities and improvement ideas were surveyed by
interviewing staff. The research approach is action analytical.
Based on results the case organization has a documented product development process
where stages, criteria and responsibilities are defined. Process corresponds to theory definitions best at the end of process. According to interviews case organization’s strengths
are the know-how and attitudes of employees and atmosphere. The biggest development
areas are resource situation and product definition quality. There are too few employees
for workload and product definitions change often during process. Consequences are eg.
schedule prolonging and decrease in design quality. Employees feel that their product development activities are mainly in preparing designs for manufacturing, not in brainstorming new product ideas. The knowledge of product development process varies within employees and customer needs are unknown. Employees are not fully aware what performance indicators are used. Also ongoing development projects, that will be integrated to
function, are unknown.
Updating process criteria and emphasizing the front end of the process could improve
functions at end part of the process. Improving product development functions, resource
situation should be improved and more emphasizing for analyzing the product definitions
should be done. Also training on process, customer needs, performance measures and
development projects can be expected to improve activities. For increasing innovation and
brainstorming activities, one could study what possibilities are available.
4
ALKUSANAT
Opiskeluni Lappeenrannan teknillisen yliopiston tuotantotalouden koulutusohjelmassa
päättyy tähän diplomityöhön. Opiskeluaika oli samaan aikaan sekä vaativaa että antoisaa.
Vaativaksi opiskelun teki koko päivä työn ja opintojen yhteensovittaminen, antoisaksi
opiskelukaverit ja ilmapiiri.
Työn aiheeksi valikoitui tuotekehitystoiminta ja sen parantaminen. Aihepiiri valikoitui pitkälti taustani takia. Koko työhistoriani olen työskennellyt tuotekehitystoimintojen parissa, joten diplomityöni tekeminen tuotekehitystoiminnasta oli luonnollinen valinta.
Diplomityön tekeminen ei mennyt alkuperäisten suunnitelmien mukaan. Elämää ei aina
voi suunnitella ja välistä tulee odottamattomia tilanteita, jotka laittavat tehdyt suunnitelmat
uusiksi. Näin kävi myös minulle ja työ pääsi kunnolla alkamaan vasta silloin, kun se alun
perin oli tarkoitus palauttaa. Odottamattomien käänteiden jälkeen ja suurimpien myllerrysten tasaannuttua, aloitin työn tekemisen ja nyt olen tässä pisteessä.
Tutkimuksen valmistumisesta haluan kiittää kaikkia tutkimukseen osallistuneita henkilöitä,
ilman heidän panosta olisi työ hyvin toisenlainen. Kiitos myös esimiehelleni ymmärryksestä, että tarvitsin vapaata ansiotyöstä osallistuakseni kursseille sekä diplomityön loppuunsaattamiseksi. Lisäksi haluan kiittää kurssikavereitani ja ohjaajaani neuvoista ja kannustuksesta, joita sain diplomityöhöni liittyen.
Joensuu 23.2.2015
Virve Piiroinen
5
SISÄLLYSLUETTELO
symboli ja lyhenneluettelo
7
1. JOHDANTO
8
1.1 Tausta
8
1.2 Tutkimuksen tavoitteet ja rajaukset
9
1.3 Tutkimuksen metodologia
10
1.4 Tutkimuksen rakenne
12
2. TUOTEKEHITYSPROSESSI
13
2.1 Tuotekehitysprosessin vaiheet
15
2.1.1 Prosessin alkupää
16
2.1.2 Prosessin loppupää
19
2.1.3 Katselmoinnit
21
2.2 Tuotekehitysprosessin hyödyt
22
3. TUOTEKEHITYSTOIMINNAN MENESTYSTEKIJÄT
25
3.1 Oikeiden asioiden tekemiseen vaikuttavat tekijät
26
3.2 Tuotekehitystoimintaan vaikuttavat tekijät
31
4. TUOTEKEHITYKSEN SUORITUSKYVYN MITTAAMINEN
4.1 Tuotekehityksen suorituskyvyn osa-alueet
37
37
4.1.1 Taustatekijät
38
4.1.2 Mittaamisen tavoite
40
4.1.3 Mittausjärjestelmä
40
4.1.4 Mittausjärjestelmän implementointi
46
4.2 Suorituskyvyn mittaamisen haasteet
47
4.3 Suorituskyvyn johtaminen
48
5. TUTKIMUKSEN TOTEUTUS
51
5.1 Kohdeorganisaatio
51
5.1.1 Kohdeorganisaation tuotekehitysprosessi
52
5.1.2 Suorituskyvyn mittarit
58
5.1.3 Kehityshankkeet
58
5.2 Tutkimuksen rakenne
61
6. TUTKIMUSTULOKSET
63
6.1 Dokumenttitarkastelun tulokset
63
6.2 Henkilökunnan haastatteluiden tulokset
66
6.2.1 Tuotekehitystoiminnan nykytila
66
6.2.2 Toiminnan mittaaminen
73
6
6.2.3 Kehityshankkeet
75
6.3 Yhteistyöorganisaatioiden palaute
76
6.4 Toiminnan parannusehdotukset
78
7. JOHTOPÄÄTÖKSET
82
7.1 Tutkimustulosten arviointi
82
7.1.1 Tuotekehitysprosessi
82
7.1.2 Tuotekehitystoiminta
82
7.2 Jatkotoimenpiteet ja suositukset
87
8. YHTEENVETO
89
LÄHTEET
91
7
SYMBOLI JA LYHENNELUETTELO
BSC
Balanced Scorecard: vuonna 1992 kehitetty toiminnanohjauksen suorituskykymittaristo
CAD
Computer-Aided Design: tietokoneen käyttöä apuvälineenä
suunnittelutyössä
DFA
Design for Assembly: prosessi, jossa tuotteet suunnitellaan
kokoonpanon helppouden näkökulmasta
DFM
Design for Manufacturing: prosessi, jossa tuotteet suunnitellaan
valmistettavuuden näkökulmasta
DFSS
Design for Six Sigma: suunnittelumetodi, jossa hyödynnetään
tilastollista ajattelua ja menetelmiä tavoitteena vaihtelun vähentäminen tuotteissa
FMEA
Failure Mode and Effects Analysis: vika- ja vaikutusanalyysi,
käytetään riskien tunnistamiseen ja niiden vähentämiseen
IP
Intellectual property: immateriaalioikeudet, yleisimmin immateriaalioikeudet jaetaan tekijäoikeuksiin ja teollisoikeuksiin.
VA/VE
Value Analysis/Value Engineering: systemaattinen prosessi,
jolla luodaan vaihtoehtoja, joissa päätoiminnallisuus pysyy,
mutta kustannukset alenevat.
8
1. JOHDANTO
Tämä tutkimus käsittelee tuotekehitysprosessia ja tuotekehitystoimintaa. Park (2007,
s.103) toteaa tutkimuksessaan, että tuotekehitystoiminta on yritykselle suuri investointi ja
tuotekehityksen tulee tuottaa investointi takaisin kehittämällä menestyviä tuotteita. Yritysten elinehto on tuottaa asiakastarpeita vastaavia tuotteita markkinoille. Tehokkaasta tuotekehityksestä ja uuden teknologian suunnittelusta tulee koko ajan tärkeämpää menestymisen kannalta, koska tuotteiden elinkaaret lyhenevät ja teknologiat kehittyvät nopeasti.
nopean kehittymisen myötä tuotteiden kehitykseen käytettävissä oleva aika lyhenee. Tehokkaasta tuotekehityksestä ja uuden teknologian suunnittelusta tulee koko ajan tärkeämpää menestymisen kannalta.
1.1 Tausta
Toimintaympäristö, jossa yritykset toimivat, on muuttunut yrityksille haastavammaksi viime
vuosikymmenten aikana. Syitä muutokseen ovat mm. markkinoiden globalisaatio, teknologioiden nopea kehittyminen, asiakasvaatimusten nopea muuttuminen ja lisääntynyt kilpailu asiakkaista. Markkinoilla olevien kilpailijoiden määrän lisääntyessä asiakkailla on
enemmän vaihtoehtoja, joista valita. Asiakasvaatimukset yritysten tuotteita kohtaan ovat
nousseet ja ne muuttuvat nopeasti. Uusien tuotteiden määrä markkinoilla on lisääntynyt ja
tuotteiden elinkaaret ovat lyhentyneet. Menestyäkseen yritysten on pysyttävä tuomaan
markkinoille asiakastarpeita tyydyttäviä tuotteita oikeaan aikaan. Mikäli yritys ei kykene
vastaamaan haasteeseen, asiakkaat siirtyvät ostamaan kilpailijan tuotteita. (Cooper 2000,
s.54-55; Kerssens-van Drongelen et al. 2000, s.112)
Tuotekehitysprosessin tavoite on maksimoida kehitettävän tuotteen menestys tunnistamalla, ymmärtämällä ja yhdistämällä eri asioita toisiinsa. Tuotekehitystoiminnassa on sille
ominaisia piirteitä, jotka tekevät siitä haastavan. Tuotekehityksen toimintaympäristö ei ole
stabiili, se muuttuu koko ajan, ja se luo tuotekehitystoimintaan epävarmuutta. Tuotekehityksen päätöksenteon pitää pysyä toimintaympäristön muutosten mukana. Toimintaympäristön luomiin haasteisiin tuotekehitys voi vaikuttaa sisäisillä tekijöillä, kuten esim. matalilla
tuotekehityskustannuksilla, investoinneilla, oikeiden asioiden tekemisellä, markkinoille
tulon oikea-aikaisuudella ja kehittämällä tuotteita, joissa on asiakkaiden haluamat ominaisuudet. (Park 2007, s.103; Ulrich & Eppinger 2003, s.6)
Menestyäkseen tuotekehityksen tulee tehdä oikeita asioita, tehdä asioita oikein ja tuloksia
tulee mitata. Oikeiden asioiden tekemiseen kuuluu kaikki, mikä vaikuttaa sopivimpien tuot-
9
teiden valitsemiseen. Tuotekehityksen toiminnan arvioimiseksi on tuotekehitystoiminnan
mittaaminen välttämätöntä. Tuotekehitystoiminnan mittaamisella mm. demonstroidaan
tuotekehitysinvestoinnin tuotto, määritellään tuotekehityksen suorituskyky sekä haetaan
kehityskohteita. (Andersson 2008, s.554-555)
1.2 Tutkimuksen tavoitteet ja rajaukset
Tässä tutkimuksessa tutkitaan tuotekehitysprosessia ja tuotekehitystoiminnan suorituskykyyn vaikuttavia tekijöitä. Tutkimuksessa pyritään selvittämään tuotekehitysprosessiin
kuuluvat vaiheet ja niihin liittyviä tekijöitä. Tuotekehitystoiminnan suorituskyvyn parantamiseksi haetaan tekijöitä, jotka ovat ominaisia menestyville tuotekehitysorganisaatioille.
Lisäksi tutkitaan, mitä asioita tulee ottaa huomioon tuotekehityksen suorituskykyä arvioidessa. Tutkimuksen tavoitteita ovat:
-
Selvittää tuotekehitysprosessin vaiheet ja niihin vaikuttavia tekijöitä.
-
Löytää keinoja, joilla parantaa pienikokoisen tuotekehitysorganisaation tuotekehitysprosessia ja tuotekehitystoimintaa.
Tutkimuksessa pyritään löytämään vastauksia seuraaviin tutkimuskysymyksiin:
-
Mitkä ovat tuotekehitysprosessin vaiheet ja niihin vaikuttavat suorituskyvyn tekijät?
-
Mikä on pienikokoisen tuotekehitysorganisaation tuotekehitysprosessin ja toiminnan nykytila työntekijöiden näkökulmasta?
-
Miten pienikokoisen tuotekehitysorganisaation tuotekehitysprosessia ja -toimintaa
voi parantaa?
Tutkimuksen kohdeorganisaatio on osa yritystä, joka koostuu monesta eri liiketoimintayksiköstä. Kohdeorganisaatio on yhden liiketoimintayksikön tuotekehitysorganisaatio. Kohdeorganisaation koko on alle kymmenen henkeä ja se toimii elektromekaanisia tuotteita
valmistavassa teollisuudessa. Kohdeorganisaation tuotekehitystoiminta keskittyy pääosin
uusien tuotteiden tuomiseen markkinoille. Näin ollen tutkimus rajataan koskemaan pieniä
tuotekehitysorganisaatiota ja toimiala koskemaan elektromekaanisia tuotteita valmistavaan teollisuuteen. Suuret tuotekehitysorganisaatiot ja julkiset, ei-voittoa tavoittelevat organisaatiot rajataan tutkimuksen ulkopuolelle. Tuotekehitystoiminnassa keskitytään uuden
tuotteen kehittämiseen.
10
1.3 Tutkimuksen metodologia
Laaksovirta (1985, s.41) määrittelee tutkimuksen metodologian tavaksi analysoida tutkimusongelmaa. Erilaiset tutkimusongelmat vaativat omanlaisia tutkimustapoja ja -keinoja.
Tutkimuksen suunnittelun ja toteutuksen lähtökohtana on se, mihin tutkija pyrkii tutkimuksellaan. Metodologisiin valintoihin kuuluu tutkimusotteen valinta. Neilimo & Näsi (1981, s.
28) ovat jakaneet tutkimusotteet neljään eri kategoriaan, joita ovat käsiteanalyyttinen, päätöksentekometodologinen, nomoottinen ja toiminta-analyyttinen. Kasanen et al. (1991,
s.317) lisäävät viidenneksi tutkimusotteeksi konstruktiivisen tutkimusotteen. Kuvassa 1 on
eri tutkimusotteet jaoteltu niiden tutkimustyypin ja tutkimusmenetelmän mukaan.
Kuva 1. Tutkimusotteiden väliset suhteet (Kasanen et al. 1991, s.317)
Neilimo & Näsi (1980, s.31-32) määrittelevät käsiteanalyyttisen tutkimuksen tavoitteeksi
uusien käsitteiden luomisen analyysien avulla. Käsiteanalyyttisen tutkimuksen lähtökohtana ovat pääosin aiemmat käsiteanalyysit, mutta myös empiriapainotteisia kokemuksia ja
tutkimustuloksia on mahdollista käyttää lähtökohtana. Käsiteanalyyttisessa tutkimuksessa
ei verifioida käsitteitä vaan niitä lähinnä perustellaan. Tutkimuksen kohteena voi olla tosiasiat, arvot tai normit ja tulokset voivat olla toteavia tai suosittelevia.
Päätöksentekometodologisessa tutkimuksessa keskitytään sellaisen menetelmän etsintään, jonka käyttö tuottaa ratkaisun määrättyyn tilanteeseen. Päätöksentekometodologisen tutkimusotteen tutkimusongelman osatekijöitä ovat usein selkeästi määritellyt olettamukset päätöksentekijästä ja päätöksentekotilanteesta. Tässä tutkimusotteessa ratkaisun
toimivuuden todentaminen on lähinnä todistelevaa ja empiirinen osio on pääasiassa sovellusesimerkin muodossa. (Neilimo & Näsi 1980, s. 33-34)
Nomoottisessa tutkimusotteessa hahmotellaan tekijöiden välisiä syy- ja seuraussuhteita
tilastollisten yleistysten kautta ja pyritään vastaamaan kysymykseen ”miksi”. Nomootti-
11
seen tutkimukseen sisältyy käsitteellinen vaihe, jossa joko johdetaan viitekehys tai rakennetaan malliluonnos. Nomoottiseen tutkimukseen liittyy aina empiirinen vaihe, jonka tulosten merkitys tutkimukselle olennainen. Empiirisen vaiheen jälkeen asetetaan käsitteellinen
ja empiirinen tieto vastakkain. (Neilimo & Näsi 1980, s.39-40)
Toiminta-analyyttisen tutkimusotteen tavoite on pääasiassa tarkoituksen ymmärtäminen.
Toiminta-analyyttisen tutkimusotteen taustalla on teleologia ja hermeneutiikka. Teleologialla selitetään jonkin tapahtuman tai prosessin olemassaoloa ja luonnetta viittaamalla sen
päämäärään. Hermeneutiikka korostaa kokonaisuuksien ymmärtämistä ja tulkintaa. Toiminta-analyyttisessä tutkimuksessa empiria on mukana tavallisesti harvojen kohdeyksiköiden kautta. Toiminta-analyyttisen tutkimuksen tuloksena on usein eri tasojen käsitejärjestelmiä, joilla maailmaa pyritään jäsentämään ja suunnittelemaan. (Neilimo & Näsi 1980,
s.35)
Kasanen et al. (1991, s.305-308) toteavat, että konstruktiivisen tutkimuksen lähtökohdat
käytännön ongelmalliseksi koetussa tilanteessa ja lopputulosta voidaan käyttää ongelman
ratkaisemiseen. Konstruktiiviseen tutkimukseen kuuluu osana ongelman sitominen aiempaan tietämykseen sekä ratkaisun toimivuuden osoittaminen empiirisesti. Konstruktiivinen
tutkimusote sisältää samoja tekijöitä kuin päätöksentekometodologinen ja toimintaanalyyttinen tutkimusote. Konstruktiivisen ja päätöksentekometodologisen tutkimusotteen
yhteinen tekijä on teoreettinen analyysi, minkä tuloksena muodostuu ratkaisu tiettyyn ongelmaan. Em. tutkimusotteiden selkein ero on, että konstruktiivisen tutkimuksen osana on
aina tuloksen toimivuuden todentaminen käytännössä. Konstruktiiviselle ja toimintaanalyyttiselle tutkimusotteelle yhtenäistä on empiirinen tutkimusvaihe ja molemmat tutkimusotteet vaativat tutkittavan kohteen syvällistä ymmärtämistä. Tärkein ero tutkimusotteiden välillä on se, että toiminta-analyyttinen tutkimus on painopisteeltään empiirinen tutkimustapa ja konstruktiivisessa tutkimuksessa uuden konstruktion kehittäminen on koko
prosessin päätavoite.
Tässä tutkimuksessa tutkitaan yhden kohdeorganisaation tuotekehitysprosessia, kartoitetaan kohdeorganisaation tuotekehitystoiminnan nykytilaa ja haetaan parannusehdotuksia.
Kohdeorganisaation työntekijöiden pienen lukumäärän vuoksi, alle 10 henkeä, tutkimuksen empiirisessä osiossa haetaan tietoa toiminnan nykytilasta ja toiminnan parannusehdotuksia haastattelemalla työntekijöitä. Lisäksi tutustutaan kohdeorganisaation tuotekehitysprosessiin dokumenttitarkasteluna ja haetaan tapoja, jolla prosessia voi parantaa. Tutkimuksen tuloksena on suosituksia toiminnan parantamiseksi, mutta niiden toimivuutta
käytännössä ei tutkita.
12
Koska tutkimuksen tuloksena on suosituksia toiminnan parantamiseksi, mutta niiden toimivuutta ei tutkita, konstruktiivinen tutkimusote ei ole sopiva. Tutkimuksessa ei haeta yhtä
menetelmää, jolla ratkaistaan määrätty ongelma, joten päätöksentekometodologinen tutkimusote ei ole sopiva. Tutkittavien kohteiden pienen määrän vuoksi tilastollisten tulosten
saaminen on epätodennäköistä, joten nomoottinen tutkimusote ei ole sopiva. Tutkimuksen
tavoite ei ole myöskään uusien käsitteiden kehittäminen, joten käsiteanalyyttinen tutkimusote ei ole sopiva. Tutkimuksessa pyritään ymmärtämään tuotekehitystoimintaan liittyviä käsitteitä ja kokonaisuutta sekä haetaan parannusehdotuksia nykyiseen tilanteeseen.
Tutkimukselle sopiva tutkimusote on toiminta-analyyttinen tutkimusote.
1.4 Tutkimuksen rakenne
Tutkimus koostuu kolmesta teorialuvusta, tutkimuksen pohjustuksesta, tutkimuksen tuloksista, johtopäätöksistä ja yhteenvedosta. Kuvassa 2 on tutkimuksen rakenne esitetty syöte-tuloskaaviona.
Kuva 2. Tutkimuksen rakenne syöte-tulos kaaviona
13
2. TUOTEKEHITYSPROSESSI
Tuotekehitysprosessia on määritelty useilla eri tavoilla. Kirjassaan Ulrich & Eppinger
(2003, s.13) kuvaavat tuotekehitysprosessin ryhmäksi toimintoja, joka alkaa markkinamahdollisuuden havaitsemisella ja loppuu tuotannon ja myynnin aloitukseen sekä tuotteiden toimittamiseen. Unger & Eppinger (2011, s.689) määrittelevät tuotekehitysprosessin
käsittelyjärjestykseksi ja menetelmäksi, jolla yritykset kehittävät uusia tuotteita ja tuovat ne
markkinoille. Cooper (2000, s.58) puolestaan määrittelee tuotekehitysprosessin toisiaan
seuraavista vaiheista koostuvaksi ketjuksi. Vaiheiden aikana tuotekehitysprosessiin osallistuvat henkilöt suorittavat erilaisia toimintoja, joiden tavoite on kerätä prosessin etenemisen kannalta tarpeellista tietoa. Jokaisessa vaiheessa tavoitellaan kehiteltävän tuotteen
teknisten ja kaupallisten riskien pienenemistä.
Oppenheim (2004, s.355) toteaa, että tuotekehitystyö alkaa tuotteen arvon määrittelyllä.
Arvon määrittelyssä tunnistetaan tuotteen arvoon vaikuttavat eri sidosryhmät. Tuotekehitystyö loppuu, kun tuote on valmis virheettömään valmistukseen, ts. kun valmistuksen
sidosryhmät tietävät, mitä valmistaa, miten ja millä resursseilla. Driva et al. (2000, s.147)
toteavat, että tuotekehitystoiminnoilla tavoitellaan tehokkuutta. Toimintoihin vaikuttaa tekijöitä, jotka vaihtelevat projektikohtaisesti. Tuotekehityksen toimintoihin vaikuttavia tekijöitä
ovat mm. kustannusrajoitteet, tuotteen markkinoille tulon ajoitus, laadun parantaminen ja
joustavuus.
Tuotekehitysprosessimalleja on olemassa monia. Unger & Eppinger (2011, s.691) ovat
määrittäneet kaksi ääripäätä prosessimalleille. Toisessa ääripäässä on ns. vaiheittainen
prosessi. Vaiheittainen prosessi koostuu toisiaan seuraavista vaiheista ja vaiheiden välissä pidettävistä katselmoinneista. Katselmoinneissa arvioidaan edellisen vaiheen tuloksia
ja päätetään, jatketaanko prosessia seuraavaan vaiheeseen. Vaiheittainen prosessimalli
on perinteisin tuotekehitysprosessimalli.
Vaiheittainen prosessi on yksisuuntainen ja palaaminen edellisiin vaiheisiin on kallista.
Suunnitelmien ja toiminnan iterointi on mahdollista tehdä vaiheen sisällä, mutta iterointi
vaiheiden välillä indikoi ongelmista. Vaiheittainen prosessi jäädyttää suunnitelmat prosessin aikaisessa vaiheessa. Edellä mainitun syyn vuoksi vaiheittainen prosessi ei välttämättä sovi dynaamisessa ympäristössä toimiville yrityksille, jossa vaaditaan lyhyitä kehitysaikoja, muutoksia suunnitelmiin ja vaatimuksiin prosessin aikana. Vaiheittainen prosessi
maksimoi johdon valvonnan ja siinä keskitytään teknisten riskien hallintaan. Vaiheittainen
prosessimalli on kuvattu kuvassa 3. (Unger & Eppinger 2011, s.691)
14
Kuva 3. Vaiheittainen prosessimalli (Unger & Eppinger 2011, s.691)
Vaiheittaisen prosessin vastakohdaksi ovat Unger & Eppinger (2011, s.692) määritelleet
ns. spiraaliprosessimallin. Spiraaliprosessi on varsin uusi prosessimalli, jota esim. ohjelmistoalan yritykset käyttävät. Spiraaliprosessi toistaa jatkuvasti prosessin eri vaiheita kuten konseptien kehitys, järjestelmätason suunnittelu, yksityiskohtainen suunnittelu, integraatio ja testaus. Prosessi on joustava, toistokierrosten, ts. silmukoiden, määrä ja laajuus
muuttuvat vaatimusten mukaan.
Spiraaliprosessi vaatii johtoa arvioimaan riskejä prosessin aikaisessa vaiheessa. Spiraaliprosessin haittapuoli on sen monimutkaisuus. Se vaatii johdolta paljon ja tarkkojen määrittelyiden puute voi johtaa myöhästymisiin. Mikäli projektiin ei kohdistu suuria epävarmuuksia ja toistokierroksia ei ole odotettavissa kuin yksi, prosessi muistuttaa paljolti vaiheittaista prosessia. Spiraaliprosessi maksimoi joustavuuden ja keskittyy markkinariskin pienentämiseen. Spiraaliprosessimalli on kuvattu kuvassa 4. (Unger & Eppinger 2011, s.692)
Kuva 4. Spiraaliprosessimalli (Unger & Eppinger 2011, s.692)
Kahden ääripään välissä on erilaisia tuotekehitysprosessimalleja. Näitä ovat esim. talousarvion mukainen suunnittelu ja evolutäärinen prototyypitys. Talousarvion mukainen suunnittelu alkaa kuten vaiheittainen prosessi, mutta kehitys ja testausvaiheita toistetaan tuotteen parantamiseksi niin monta kertaa kuin budjetti sallii. Talousarvioon perustuvalla
suunnittelulla kontrolloidaan kustannuksia, mutta sen riskinä ovat markkinavaatimukset ja
15
laatu. Evolutäärisessä prototyypityksessä nopean palautteen saaminen valmistetuista
prototyypeistä on keskeistä. Tämä prosessimalli toimiva, jos alustava tuotemääritys ei ole
tarkka ja sitä voidaan parantaa testaamalla. Evolutäärisen prosessin käytössä ei prosessin alkuvaiheissa voi määrittää selkeää lopputulosta. (Unger & Eppinger 2011, s.692)
Tuotekehitysprosessimallivaihtoehtoja on paljon ja jokainen malli soveltuu tiettyyn toimintaympäristöön. Unger & Eppringer (2011, s. 694-695) painottavat, että käyttöön otettava
tuotekehitysprosessi tulee räätälöidä yritykselle ja projektille sopivaksi. Mikä toimii yhdessä tilanteessa ei välttämättä toimi kaikissa tilanteissa. Prosessin suunnittelun lähtökohtana
tulisi olla toimintaympäristön epävarmuudet, riskit ja prosessin integraatiomahdollisuudet.
Toimintaympäristöstä riippuvat epävarmuudet ja riskit tulee tunnistaa ja niiden minimoiminen tulisi toteutua prosessin aikana. Kahn et al. (2006, s.114) toteavat tutkimuksessaan,
että pohjimmiltaan tuotekehityksen menestyminen ja tehokas toiminta riippuu suuresti
siitä, miten hyvin yritys kykenee sopeutumaan toimintaympäristöönsä.
2.1 Tuotekehitysprosessin vaiheet
Tuotekehitysprosessi koostuu eri vaiheista riippumatta siitä, onko kyseessä perinteinen
vaiheittainen prosessi tai spiraaliprosessi. Robert G. Cooper (1988, s.251-254) tutki, miksi
toiset tuotteet menestyvät markkinoilla ja toiset eivät. Tutkimus tulosten pohjalta Cooper
loi Stage-Gate prosessin, joka koostuu eri vaiheista ja vaiheiden välisistä katselmointipisteistä. Myöhemmin Cooper (2000, s.58) päivitti alkuperäisen stage-gate prosessin vastaamaan kuvan 5 mallia.
Kuva 5. Stage-Gate prosessi (Cooper 2000, s. 58)
Ulrich & Eppinger (2003, s.13-14) ovat määritelleen ns. yleisen tuotekehitysprosessikuvauksen, joka koostuu kuudesta eri vaiheesta. Vaiheet ovat suunnittelu, konseptien kehitys,
järjestelmätason suunnittelu, kehitys, testaus ja tuotannon ylösajo. Vaiheiden välissä on
katselmointipisteitä, joissa arvioidaan edellisen vaiheen tulokset ja päätetään jatketaanko
prosessia eteenpäin. Yleinen tuotekehitysprosessi on kuvattuna kuvassa 6.
16
Kuva 6. Yleinen tuotekehitysprosessi (Ulrich & Eppinger 2003, s.23)
Ulrich & Eppinger (2003, s.13-14) määrittelemän yleisen prosessimallin vaiheet on löydettävissä muista prosessimalleista, joko sellaisenaan tai vaiheita on yhdistetty. Esim. Park
(2007, s.105) on määritellyt tuotekehitysprosessin sisältämään viisi vaihetta kuuden sijaan. Prosessi alkaa vaiheella, jossa luodaan yrityksen strategian mukaisia ideoita. Seuraavassa vaiheessa keskitytään tutkimaan ideoiden toteutettavuutta ja rajoitteita. Tässä
vaiheessa Park (2007, s.105) on yhdistänyt konseptien kehitysvaiheen ja järjestelmätason
suunnittelun. Kolmas vaihe on projektin suunnitteluvaihe, joka vastaa yleisen prosessimallin kehitysvaihetta. Neljäs vaihe vastaa testausvaihetta, jossa tuote valmistetaan ja testaamalla varmistetaan, että tuote vastaa odotuksia. Viimeisessä vaiheessa projekti siirretään tuotannolle, aloitetaan valmistus, tuote lanseerataan ja projektista saadaan palaute.
Pillai et al. (2002, s.166) puolestaan määrittelevät tuotekehitysprosessin vaiheiksi projektiehdotusten luomisen, projektien valintavaiheen, projektien toimeenpanovaiheen ja täytäntöönpanovaiheen. Luotujen projektiehdotusten tulisi perustua koettuun asiakastarpeeseen. Projektien valintavaiheessa pääpaino tulee olla realistisessa arvioinnissa ja suunnittelussa. Tässä vaiheessa on yhdistetty konseptien kehitysvaihe, jossa projektiehdotuksia
tutkitaan ja analysoidaan. Toimeenpanovaiheessa pääpaino on tehokkaalla resurssien
johtamisella, jolla saavutetaan projektin tavoitteet sovituilla aikataululla ja kustannuksilla.
Tässä vaiheessa yhdistyy järjestelmätason suunnitteluvaihe ja yksityiskohtainen suunnitteluvaihe. Täytäntöönpanovaiheessa pääpaino on asiakkaan reagoinnissa ja investoinnin
tuotossa. Täytäntöönpanovaihe sisältää tuotteen kehittämisen testaamisen ja tuotannon
aloituksen. Prosessin lopputuloksena tulisi olla tuotteita, jotka tuovat asiakkaalle arvoa.
2.1.1 Prosessin alkupää
Eri tuotekehitysprosessimallit alkavat pääsääntöisesti yrityksen strategian ja tavoitteiden
analysoinnilla, markkinamahdollisuuksien havaitsemisella sekä strategian mukaisten ideoiden synnyttämisellä. Cagan & Vogel (2002, s.41-42) toteavat, että yrityksen tuotekehityksen tärkein liikkeelle paneva voima on tuotemahdollisuuksien havaitseminen. Se vaatii
tietoa ja taitoa. Mahdollisuuksien havainnoinnissa on seurattava kolmea eri tekijää: sosiaalisia suuntauksia, teknisiä edistysaskelia ja taloudellisia tekijöitä. Sosiaalisia tekijöitä
17
ovat erilaiset trendit ja taustavoimat. Teknisissä edistysaskelissa yrityksen tulee seurata
uusia ja kehitteillä olevia tekniikoita ja arvioida nykytekniikan käyttö uudelleen. Taloudellisissa tekijöissä tulee arvioida taloudellista tilaa, rahankäytönmuutoksia ja käytettävissä
olevia tuloja.
Yrityksen tuotekehitysstrategian kuuluu sisältää päätökset yrityksen tavoitemarkkinoista,
tuotteista, projektien priorisoinnista, resurssien allokoinnista ja teknologian valinnasta,
toteavat Chen et al. (2006, s.176) tutkimuksessaan. Park (2007, s. 105) painottaa, että
ideoiden synnyttämisessä tulee pyrkiä luomaan mahdollisimman monta strategian ja tavoitteiden mukaista ideaa. Yhden menestyvän idean löytämiseksi tarvitaan monta ideaa.
Lupaavimpia ideoita tutkitaan tarkemmin, niiden riskit arvioidaan ja niille tehdään hyötyhaitta-analyysit. Bhuiyan (2011, s. 754) painottaa, että ideoita voidaan hakea monesta eri
lähteestä, mutta asiakas- ja markkinalähtöiset ideat ovat suhteellisesti menestyneempiä
kuin muista lähteistä syntyneet ideat.
Projekti-ideoiden alustavassa arvioinnissa sitoutetaan resurssit ideoiden tutkimiseen ja
halutuille tuotteille määritellään sekä pakollisia että toivottavia vaatimuksia. Jokaiselle idealle tulee tehdä alustavia markkina-, teknisiä, taloudellisia - ja liiketoiminta-analyysejä.
Alustavan arvioinnin lopputulos on projektimääritelmä, jonka tulisi sisältää tuotteen tavoitemarkkinat, liiketoimintatavoitteet, avainolettamukset ja rajoitteet. (Cooperin 1988, s.251254; Ulrich & Eppinger 2003, s.13-14)
Ideoiden alustavien arviointien jälkeen lupaavimpia ideoita tutkitaan ja kehitetään tarkemmin. Ulrich & Eppinger (2003, s.16) nimeävät tämän vaiheen konseptien kehitysvaiheeksi.
Konseptien kehitysvaihe on tuotekehitysprosessin menestyksen kannalta kriittisin vaihe,
koska tämän vaiheen lopputuloksena on ne konseptit, joiden pohjalta syntyvät yrityksen
myytävät tuotteet. Konseptien kehitysvaihe voidaan jakaa alivaiheisiin, joita Ulrich & Eppinger (2003, s.16) kutsuvat etupään prosessiksi (front end process), joka on kuvattuna
kuvassa 7.
Kuva 7. Konseptien kehitysvaiheen prosessi (Ulrich & Eppinger 2003, s. 16)
18
Oliveira & Rozenfeld (2010, s.1342) määrittelevät etupään prosessin kolmesta pääkomponentista koostuvaksi prosessiksi. Pääkomponentteja ovat tuotteen mahdollisuuksien
tunnistaminen, konseptien luonti, niiden arviointi ja projektien valinta kehitysvaiheeseen.
Konseptien kehitysvaihe alkaa asiakastarpeiden tunnistamisella. Tuotekehityksen menestymisen kannalta on kriittistä, että tuotekehitys tekee sellaisia tuotteita, joita asiakkaat haluavat ostaa. Tuotekehityksessä työskentelevien tulee ymmärtää asiakastarpeet ja tarpeiden väliset riippuvuudet ja tarpeiden luomat trade off. Trade off on tilanne, jossa menetetään yhden näkökulman laatua saavuttamalla lisäetua toisesta näkökulmasta. Asiakasvaatimusten ymmärtäminen ja niiden muuttaminen teknisiksi vaatimuksiksi on ensiarvoisen tärkeää tuotekehityksen menestymisen kannalta. (Shen et al. 2000, s. 93; Wang et al.
2012, s.20; Hines et al. 2005, s.875).
Ulrich & Eppinger (2003, s.16) toteavat, että asiakastarpeista tulee pyrkiä luomaan lista ja
tarpeet tulee priorisoida. Asiakastarpeiden pohjalta määritellään tuotteelle sen toiminnalliset tavoitteet. Jokaisen määritelmän tulisi sisältää mittari ja tavoitetulos. Seuraava vaihe
on kehittää erilaisia konsepteja asiakastarpeiden ja toiminnallisten tavoitteiden pohjalta.
Erilaisia konsepteja tulee luoda monta, yleensä yli 10, joista jokainen sisältää alustavan
kuvauksen tuotteesta ja sen toiminnasta.
Ulrich & Eppinger (2003, s.17) painottavat kehiteltyjen konseptien markkinapotentiaalin
tutkimista testaamalla. Konsepteista valmistetaan prototyyppejä, joiden avulla varmistetaan, että konsepti täyttää sille asetetut ominaisuudet ja toiminnallisuuden. Testaamalla
tunnistetaan myös konseptien puutteet ja riskit. Testaamisesta saadun palautteen myötä
konsepti voidaan hylätä tai muokata vastaamaan paremmin asiakastarpeita. Testaamisen
jälkeen määritellään tuotteelle lopulliset vaatimukset.
Konseptien kehityksen viimeisessä vaiheessa tuotekehitysryhmä sitoutuu tuotteen tavoitteisiin sekä tuotteen, kustannusten ja toiminnallisuuden rajoituksiin. Tuotekehitysryhmä
luo yksityiskohtaisen projektisuunnitelman ja suunnitteluajan minimoivan strategian sekä
tunnistaa tarvittavat resurssit ja projektiin kohdistuvat riskit. Konseptien kehitysvaiheen
tärkein tuotos on tuotemääritelmä. Tuotemääritelmän tulee sisältää tuotteen tavoitteet,
määritelmät, asiakastarpeet, valitun konseptin yksityiskohdat, tuotevaatimukset, taloudellisen analyysin, kehitysaikataulun, resurssit ja budjetin. (Ulrich & Eppinger 2003, s. 17)
Sekä Ulrich & Eppinger (2003, s.17) että Bhuiyan (2011, s.756) painottavat, että konseptien kehitysvaiheessa konsepteille tulee tehdä jatkuvia taloudellisia, markkina-, teknisiä ja
19
liiketoiminta- analyysejä, jotka oikeuttavat konseptin tarkemman tutkimisen. Konseptia
kehiteltäessä sille tulee tehdä kustannusarvio ja arvioida tuotteen potentiaalinen tuotto.
Lisäksi Ulrich & Eppinger (2003, s.17) painottavat kilpailijatuotteiden seurantaa koko prosessin ajan. Kilpailijatuotteiden toiminnan ymmärtämisestä voi saada ideoita omiin ratkaisuihin. Mikäli konseptien tutkiminen, analysointi ja arviointi on tehty huonosti konseptien
kehitysvaiheessa, heikkenee tuotekehityksen toiminnan suorituskyky prosessin loppupään
vaiheissa. Bhuiyan (2011, s. 757) määrittelee konseptien kehittämisvaiheen menestystekijöiksi taloudellisen analyysin, markkina- ja kilpailija-analyysit, asiakastutkimuksen, konseptien testauksen ja teknisen toteutettavuuden analysoinnin.
Oliveira & Rozenfeld (2010, s.1344-1347) toteavat, että testatut konseptit tulee arvioida
teknisen hyödyn, resurssien käytön ja ajoituksen mukaan. Konseptit priorisoidaan taloudellisten tekijöiden, menestysmahdollisuuden ja strategia suuntautuneisuuden mukaan.
Konseptien arvioinnin jälkeen aloitetaan toteutukseen lähtevien projektien valinta. Cooper
(2000, s.60) määrittelee neljä tavoitetta tuotekehitysprojektien valinnalle. Valituilla projekteilla tulee pyrkiä arvon maksimointiin. Kehityksessä olevien tuotteiden yritykselle tuoman
arvon tulisi olla maksimaalinen. Valittujen projektien tulee olla tasapainossa toisiinsa nähden. Työn alla tulee olla samaan aikaan korkean ja matalan riskin projekteja, lyhyen ja
pitkän aikavälin projekteja, uusia tuoteideoita ja tuoteparannuksia yms. Valittujen projektien pitää olla yrityksen strategian mukaisia ja valituille projekteille tulee olla resurssit käytettävissä. Usein kuitenkin valitaan liikaa projekteja työn alle ja lopputuloksen toimeenpanon laatu kärsii ja projektit myöhästyvät.
2.1.2 Prosessin loppupää
Konseptien kehitysvaiheen jälkeen valituille potentiaalisimmille projekteille määritellään
tuotteen arkkitehtuurit järjestelmätason suunnitteluvaiheessa. Vaiheessa tuote jaotellaan
alikokoonpanoihin ja komponentteihin, jotka määrittelevät tuotteen lopullisen kokoonpanon. Vaiheen tuloksena on tuotteen tekninen layout, tuotteen osien toiminnalliset määritykset ja alustava loppukokoonpanoprosessin järjestys. Mikäli järjestelmätason suunnittelun jälkeen arvioidaan, että tuotteella on yhä potentiaalia täyttää sille asetetut tavoitteet,
projekti jatkaa yksityiskohtaiseen kehitysvaiheeseen. (Ulrich & Eppinger 2003, s.13-14)
Ulrich & Eppinger (2003, s.14) ovat määritelleet yksityiskohtaisen kehitysvaiheen sisältämään niitä toimintoja, joilla määritetään tuotteen muoto. Jokaiselle tuotteeseen kuuluvalle
osalle valitaan materiaalit ja rakenne tulee analysoida mm. toleranssianalyysilla. Vaiheen
aikana luodaan myös projektisuunnitelma ja tehdään työkalusuunnittelu valmistettaville
20
osille. Kehitysvaiheen tuotos on tuotedokumentaatio, jolla tuote valmistetaan. Vaiheen
kaksi kriittistä tekijää ovat tuotantokustannukset ja toteutettavuus. Bhuiyan (2011, s.759760) määrittelee kehitysvaiheen kriittisimmäksi tekijäksi suunnittelutyön nopeuden, koska
liiketoimintaympäristö tai asiakasvaatimukset voivat muuttua suunnitteluprosessin aikana.
Markkinoinnin ja tuotekehityksen tulee tehdä yhteistyötä, koska markkinointi tuntee asiakkaan tarpeet ja tuotekehitys voi muuntaa ne konkreettisiksi tuotoksiksi. Asiakkaalta saatu
palaute tai tieto on kriittistä kehityksen aikana, koska sillä varmistetaan, että tuote on oikea ja se ohjautuu kohti oikeita tavoitteita.
Antony (2002, s. 6-7) toteaa, että kustannustehokkaiden tuotteiden kehittämiseen, jotka
täyttävät asiakastarpeet ja alentavat laatukustannuksia, Design for six sigma (DFSS) on
tehokas työkalu. Sen käyttö perustuu tilastollisten analyysien käyttöön, joilla ennustetaan
ja parannetaan laatua ennen prototyyppien tekemistä. Oikein käytettynä DFSS hyötyjä
ovat markkinoille tulon ajoituksen paraneminen, elinkaarikustannusten aleneminen, lisääntynyt ymmärrys asiakastarpeista, ja –prioriteeteista, uudelleen suunnittelun väheneminen, parantunut laatu ja luotettavuus, parantunut kyky hallita riskejä ja alentuneet takuukustannukset. Tilastollisten analyysien luotettava käyttö vaatii paljon dataa analyysien
pohjaksi. DFSS sopii myös pienelle tuotekehitysorganisaatiolle, mikäli organisaatiolla on
käytössä dataa pitkältä aikaväliltä tai organisaatiolla on käytössä muiden vastaavien organisaatioiden dataa.
Antony (2002, s.7-8) painottaa, että DFSS analyysien pohjaksi tarvitaan tuotemäärittely,
asiakastarpeiden priorisointi, toimintojen suunnittelu ja tavoitteiden määrittely. Asiakasmääritysten tunnistamisen jälkeen analysoidaan tarvittavat suunnitteluvaatimukset ja
avainparametrit. Vaatimusten ja parametrien määrittelyn jälkeen, tunnistetaan eri vaihtoehdot, riskit ja tyypilliset vikaantumistavat. Seuraavassa vaiheessa optimoidaan designia.
Pyritään tunnistamaan vaihtelun lähteet ja minimoimaan niiden vaikutus, esim. toleranssisuunnittelulla.
DFSS käytössä tulee ymmärtää, että se ei ole vastaus kaikkiin liiketoimintaongelmiin. Sen
integroiminen osaksi toimintaa on pitkän aikavälin strateginen valinta ja sen käyttö muuttaa työn luonnetta. DFSS on tilastollinen lähestymistapa laatuun ja se vaatii teknisen tiedon lisäksi tukea organisaatiolta. Sen käyttö perustuu datan keräämiseen, analysointiin ja
useiden tilastollisten työkalujen käyttöön. Työkalut ovat monimutkaisia ja kehittyneitä.
Työkalujen käyttö vaatii koulutusta ja koulutus on avainasemassa järjestelmä implementoinnin onnistumisessa. Jos yrityksellä ei ole resursseja DFSS:n implementointiin ja käyt-
21
töön, ei sitä tulisi implementoida osaksi prosessia. (Byrne 2003, s.43-44; Gremer & Fouguet 2012, s. 45-48; Kwak & Anbari 2006, s.713)
Kehitysvaiheen jälkeen pannaan kehitysvaiheessa luotu projektisuunnitelma täytäntöön.
Ulrich & Eppinger (2003, s. 14) toteavat yleisessä tuotekehitysprosessimallissaan, että
tässä vaiheessa valmistetaan prototyyppejä, joilla varmistetaan tuotteen toiminta ja tuotannollisuus. Ensimmäisillä prototyypeillä varmistetaan, että tuote toimii ja asiakastarpeet
täyttyvät. Tarvittaessa tuotteeseen tehdään parannuksia prototyyppien testitulosten pohjalta. Tuotantoprosessien mukaan rakennetuilla prototyypeillä varmistetaan tuotteen suorituskyky, tuotannollisuus ja luotettavuus. Tuotantoprosessin mukaan valmistettuja prototyyppejä tulee testata sekä sisäisesti että asiakkaan ympäristössä. Bhuiyan (2011, s. 763764) toteaa, että testausvaiheessa kriittinen menestystekijä on tuotteen toimivuuden varmistaminen. Vaiheen aikana pyritään varmistamaan, että tuote vastaa vaatimuksia. Mikäli
tuotteen toimivuuden tavoitteet eivät täyty, syy tavoitteesta jäämiseen tulee löytää. Asiakkaan ympäristössä suoritettu testaus on kriittistä ja vaikuttaa suoraan tuotteen menestykseen. Asiakassuuntautuneella testauksella mitataan asiakastyytyväisyys ennen lanseerausta.
Testausvaiheen jälkeen päätetään tuotannon aloituksesta ja tuotteen lanseerauksesta.
Ulrich & Eppinger (2003, s.14) toteavat, että tuotannon ylösajovaiheessa tuote valmistetaan tuotannon prosessien mukaisesti. Vaiheen tarkoitus on kouluttaa valmistuksen henkilökuntaa ja selvittää tuotantoprosessista löytyvät ongelmat. Tuotannon ylösajovaiheen
aikana tuote lanseerataan markkinoille. Park (2007, s.105) muistuttaa, että tuotekehityksen lopullista suorituskykyä voidaan arvioida vasta, kun prosessin viimeinen vaihe on ohi
ja tuote on ollut markkinoilla jonkin aikaa.
2.1.3 Katselmoinnit
Tuotekehitysprosessin vaiheiden väleihin on määritelty tuotekehitysprosessimalleissa katselmointipisteitä. Cooper (2000, s.59) on määritellyt katselmoinneille kaksi tarkoitusta.
Ensiksi niissä päätetään, jatketaanko projektia seuraavaan vaiheeseen vai ei. Katselmointien toinen tavoite on arvioida, miten projektia on viety eteenpäin. Mikäli projekti jatkaa
seuraavaan vaiheeseen, katselmoinnissa päätetään resurssit seuraavaan vaiheeseen.
Katselmointi koostuu edellisen vaiheen tuotoksista, etukäteen määritellyistä kriteereistä ja
katselmoinnin tuloksista. Kriteereillä arvioidaan projektin tuloksia ja edistymistä. Katselmoinnin päätösten tulee perustua objektiivisiin arvioihin edellisen vaiheen tuotoksista ja
tosiasioihin. Katselmoinnin tuloksia ovat katselmoinneissa tehdyt päätökset. Kyky tehdä
22
päätöksiä on yksi katselmointien kriteereistä, kuten Cooper & Edgett (2012, s.50-53) toteavat. Katselmoinneissa tulee pystyä päättämään projekti, jos sen menestyminen ei näytä todennäköisellä. Katselmoinneissa tehtyihin päätöksiin pitää myös sitoutua.
Cooper & Edgett (2012, s.50-53) toteavat, että katselmointipisteissä tarkastellaan projektin kehittymistä ja varmistetaan, että tehdään oikeita projekteja ja että projektit tehdään
oikein. Katselmointien laadun varmistamiseksi, katselmoinneille pitää olla määritelty katselmointien pitäjät, joilla on tärkeä rooli prosessissa. Pitäjä tekee päätöksiä projektin jatkosta, aikatauluttavat projektia, osallistuvat kokouksiin ja päätöksentekoprosessiin. Katselmointien pitäjät voivat vaihtua päätökseen liittyvien riskin mukaan. Katselmointien pitäjien toiminnan laadun varmistamiseksi tulevat kriteerit projektin lopettamisen tai jatkamisen puolesta sekä haluttu tulos olla selkeästi kirjattu ja määritelty ennen projektin alkua.
Kriteerit, joilla projekteja arvioidaan, tulee olla näkyvillä projektin aikana. Katselmoinnin
tulokset tulee olla määritelty ja ne indikoivat mitä tietoa pitää olla saatavilla.
2.2 Tuotekehitysprosessin hyödyt
Hyvin määritetyn tuotekehitysprosessin tehokkaasta käytöstä on organisaatiolle hyötyä.
Bassani et al. (2010, s.482-483) toteavat tutkimuksessaan, että tuotekehitysprosessi on
kriittinen tekijä kilpailuedun saavuttamisessa. Prosessia käyttämällä voidaan lyhentää
markkinoille tuloaikaa, parantaa tuotteen suorituskykyä, kehittää uusia liiketoimintaalueita, muuttaa kilpailua ja tyydyttää uusia asiakasvaatimuksia. Cooper (2000, s.28) lisää
tuotekehitysprosessin käytön hyödyiksi eri toimintojen välisen yhteistyön lisääntymisen,
uudelleen suunnittelun vähenemisen, parantuneen onnistumisasteen, epäonnistumisten
aikaisen huomaamisen ja lanseerauksen paranemisen. Atkinson (1999, s.337) toteaa,
että hyvin määritetyn tuotekehitysprosessin tehokkaalla käytöllä voidaan varmistaa, että
kaikkia tarvittavat asiat tehdään ja ne tehdään oikein.
Ulrich & Eppinger (2003, s.12-13) ja Reid & Brady (2012, s. 240) toteavat, että hyvin määritellyssä prosessissa vastuut ovat selkeästi määritelty jokaiselle prosessiin osallistuvalle
tekijälle. Määritelty prosessi luo aikataulun tuotekehitysprojekteille ja se toimii toimintasuunnitelmana. Käyttämällä prosessia voidaan varmistaa projektin tuotoksen laatu, arvioida suorituskykyä ja hakea potentiaalisia kehityskohteita.
Shepherd & Pervaiz (2000, s.167-169) puolestaan toteavat, että toimiva ja tehokas prosessi vaikuttaa positiivisesti tuotekehityskustannuksiin, tuotteiden oikea-aikaiseen markkinoille tuloon ja uudesta tuotteesta saatuihin hyötyihin. Tuotekehityskustannusten alenemi-
23
nen on seurausta siitä, että projektit, joiden menestyminen vaikuttaa epätodennäköiseltä,
lopetetaan mahdollisimman aikaisessa vaiheessa. Tuotekehityskustannukset nousevat
sitä mukaa mitä lähemmäksi lanseerausta ja myynnin aloitusta siirrytään. Tuotekehitysprosessissa jokainen vaihe on edellistä vaihetta kalliimpi. Tehokas projektin hallinta prosessin aikana alentaa osaltaan myös tuotekehityskustannuksia.
Tuotekehitysprosessin käyttö parantaa projektien suunnittelua ja päätöksentekoa. Prosessin toimintojen kautta eri prosessin vaiheissa kerätään tietoa projektiin vaikuttavista
tekijöistä. Katselmoinneissa tehty toiminnan arviointi pakottaa projektit keskittymään toimeenpanon laatuun, jonka seurauksena tuotekehityksen tehokkuus nousee. Tehokkuuden kasvu näkyy lyhyempinä läpimenoaikoina ja tarpeettoman toiminnan vähenemisenä.
Lyhyemmät läpimenoajat ovat tärkeä tekijä markkinoille tulon ajoituksessa, tuotteen on
oltava valmis, kun markkinat ovat sille valmiita. Uusien tuotteiden hyötyihin kuuluu parantunut tuottavuus, kilpailuasetelma, kyky päästä uusille markkinoille ja puolustus kilpailijoita
vastaan. (Shepherd & Pervaiz 2000, s.169-171)
Cooper & Kleinschmidt (2007, s.57-59) ovat määritelleet tutkimuksessaan tekijöitä, jotka
liittyvät laadukkaaseen tuotekehitysprosessiin. Laadukkaassa prosessissa panostetaan
etupään toimintoihin, kuten markkina-, kilpailija ja teknisiin arviointeihin sekä projektien
valintaan. Prosessiin kuuluu selkeä ja varhaisessa vaiheessa tehty tuotemäärittely, joka
sisältää tavoitemarkkinat, konseptin, tuotteen edut, vaatimukset ja määrittelyt. Kahn et al.
(2006, s. 110) painottavat, että tuotemäärittelyjen tulee perustua markkinatutkimuksiin,
jotka ovat osa tuotekehitystoimintaa. Lisäksi prosessiin määritellyt tehtävät tulee suorittaa
kokonaisuudessaan. Prosessin tulee kuitenkin olla joustava ja skaalautuva projektin luonteen ja riskien mukaan. Vaiheiden välissä olevia katselmointeja on voitava tarvittaessa
jättää väliin tai yhdistää. Sopeutuvalla ja joustavalla prosessilla pystytään vastaamaan
jokaisen projektin tarpeisiin ja riskitasoihin.
Viime vuosina on Lean periaatteita implementoitu osaksi tuotekehitystoimintaa. Gremer &
Fouguet (2012,s. 45-48) määrittelevät, että Lean on tapa toimia ja sen pyrkimys on nopeuttaa prosessia eliminoimalla turha toiminta ja siten parantaa aikataulua, tehokkuutta,
joustavuutta ja kustannuksia. Lean tuotekehitystoiminta ei suoraan paranna tuotteen laatua ja luotettavuutta. Oppenheim (2004, s.355) toteaa, että Lean tuotekehitys pyrkii vähentämään kaiken turhan toiminnan, joka vie resursseja lisäämättä arvoa. Turhaksi toiminnaksi on määritelty kaikki muu toiminta paitsi se toiminta, jolla saavutetaan minimivaatimus. Lean tuotekehityksen menestyminen riippuu kyvystä tunnistaa ja vähentää tuotekehityksen ylimääräistä toimintaa.
24
Lean prosessi alkaa tuotteen määrittelyllä, joka tyydyttää kaikkien sidosryhmien tarpeet
lyhyellä aikataululla, minimikustannuksilla ja turhan toiminnan poistamisella (Hines et al.
2004 s.995 - 997; Oppenheim 2004, s.359; Wang et al. 2012, s.5). Hines et al. (2004
s.995 - 997) toteavat, että arvoa voi lisätä joko sisäisesti tai ulkoisesti. Sisäisessä arvon
nousussa kaikki turha toiminto tuotekehitystoiminnoissa eliminoidaan ja arvon lisääntyminen näkyy kustannusten laskuna. Toinen tapa lisätä arvoa on lisätä toimintoja tuotteeseen, joita asiakas arvostaa.
Tuotteen arvon määrityksen jälkeen, määritellään arvoketju. Arvoketjun määrityksessä
määritellään eri vaiheiden kestot, tehdään sekä nykytilanteen että tulevan tilanteen kuvaukset, sovitetaan ne yhteen ja määritellään Lean tuotekehitystiimi. Arvoketjun määrittämisen jälkeen keskitytään työn virran luontiin. Tavoite on vakaa edistyminen määritetyissä
jaksoissa maksimaalisella koordinaatiolla ja kaiken turhan työn minimoimisella. Virta alkaa
arvoketjun kartoituksesta ja päättyy kun tuotos on sidosryhmien tarpeiden mukainen, aikataulussa ja budjetissa. (Oppenheim 2004, s.361;365)
Wang et al. (2012, s.13-16) toteaa, että tuotekehitystoiminnassa on havaittavissa asioita,
jotka johtavat turhaan toimintaan. Odottaminen on sitä, kun tieto ei liiku prosessista toiseen tai panokset ja resurssit eivät kohtaa. Siirtoaika käsittää kuljetuksen ja panoksen tai
tuotoksen uudelleen määrittelyn. Ylituotanto tarkoittaa tuotosten luontia, joita ei vaadita.
Virheet ovat niitä, jotka huomataan vasta seuraavassa vaiheessa ja ne korjataan. Tarpeettoman innovaation loppuun vienti on resurssien turhaa kuluttamista. Yliprosessoinnissa asiakasvaatimukset ja toiminnot laajenevat liikaa. Turhia toimintoja voi eliminoida erilaisilla työkaluilla, kuten markkinatutkimukset, analyysityökalutut, protot, alihankkijan integroiminen prosessiin yms.
Lean tuotekehityksen tavoite on tehdä oikea työ oikein Kaikki turha työ, jota ei tarvita, minimoidaan tai eliminoidaan. Tehtäviä otetaan työn alle vain, jos niitä tarvitaan myöhäisemmissä vaiheissa. Työntekijän tulee olla tietoisia asiakkaan tarpeista pystyäkseen arvioimaan oikeita tehtäviä. Lean toiminnan tavoite on tehdä ensimmäisellä kerralla oikein,
johon liittyy tasokas suunnittelu ja toimeenpano. Suunnitteluun ja toteuttamiseen liittyy
osaava projektin vetäjä ja johto. Tiimin jäsenten tulee ymmärtää arvoketju ja kurinalainen
toiminta vaiheiden aikana. (Oppenheim 2004, s. 367-368)
25
3. TUOTEKEHITYSTOIMINNAN MENESTYSTEKIJÄT
Näkyvillä oleva, hyvin toimiva ja dokumentoitu tuotekehitysprosessi, jota oikeasti käytetään, on yksi tuotekehityksen toimintaan positiivisesti vaikuttava tekijä, kuten Cooper &
Edgett (2012, s.48) tutkimuksessaan toteavat. Kahn et al. (2006, s. 110) lisäävät, että
tuotekehitysprosessilla on suora vaikutus tuoteprojektin menestymiseen ja sitä kautta koko yrityksen suorituskykyyn. Mutta vaikka yrityksillä olisi käytössä hyvin toimiva ja dokumentoitu tuotekehitysprosessi, ei se takaa automaattisesti menestyvää tuotetta. Tuotekehityksen menestymiseen vaikuttaa moni muukin tekijä. Jos niitä ei ole otettu huomioon
toimintaa suunnitellessa, ei tuotekehitysprosessi ja sen käyttö takaa menestymistä.
Tuotekehitysprojektit epäonnistuvat erilaisista syistä. Mm. Andersson (2008, s.560) ja
Cooper (1999, s.119-120) ovat todenneet, että suurin syy epäonnistumisiin on vääriin projekteihin keskittyminen. Yrityksillä voi olla käytössä hyvät prosessit ja projektin johto toimii
tehokkaasti, mutta yritys keskittyy vääriin projekteihin. Tuotekehityksen menestyminen
mitataan yleensä markkinamenestyksenä. Jos keskitytään projekteihin, jotka eivät myy,
tuotekehitystä ei voida pitää menestyksekkäänä.
Toinen suuri syy epäonnistumisiin on resurssien allokoinnin huono taso, kuten sekä Ulrich
& Eppinger (2003, s.8) että Cooper (1999, s.119-120) ovat tutkimuksissaan todenneet.
Yritykset yrittävät tehdä samanaikaisesti liian montaa projektia liian vähillä resursseilla.
Yrityksen resursseja ovat mm. työntekijät, raha, työkalut ja työntekijöiden kyvykkyydet.
Huonosti hoidetun resurssien allokoinnin lopputuloksena on myöhästymisiä ja toimeenpanon laadun heikkenemistä.
Andersson (2008, s.559-560) lisää, että yritykset epäonnistuvat myös ilmapiirin luomisessa. Positiivinen ilmapiiri ja kulttuuri luovat kestävän pohjan jatkuvalle innovoinnille, joka on
yksi tuotekehitystoiminnan jatkuvan menestyksen avaintekijä. Jatkuva innovaatio vaatii
sille suotuisaa ympäristöä, ilmapiiriä ja kulttuuria. Innovaatiolle suotuisa ilmapiiri perustuu
ihmisten välisiin suhteisiin, hierarkian rakenteeseen, työn luonteeseen, tukeen ja palkitsemiseen. Suotuisalle ilmapiirille on tyypillistä henkilöstön keskeiset suhteet, päätöksen
teon rakenne, työn luonne ja pääpaino on tuella ja palkitsemisella.
Menestyvä tuotekehitys tekee oikeita asioita (Andersson 2008, s.554; Cooper 1999,
s.115). Oikeiden asioiden tekemiseen liittyy kaikki, mikä vaikuttaa projektien valintaan.
Andersson (2008, s.554-555) on jaotellut projektien valintaan vaikuttaviksi tekijöiksi valittujen projektien strategiasuuntautuneisuuden varmistaminen, tuotekehityksen kyvykkyydet
26
vielä projekteja läpi, portfoliokäytännöt sekä päätöksentekokäytännöt ja päätöksenteon
laadun. Oikeiden asioiden tekemisen lisäksi tuotekehityksen tulee tehdä asioita oikein
(Andersson 2008, s.554; Cooper 1999, s.115; Atkinson 1999, s.337). Asioiden oikein tekemiseen liittyy mm. tuotekehitysprosessit, resurssien saatavuus ja allokointi, suhde
markkinointiin ja muihin sidosryhmiin, projektiryhmät, projektien priorisointi, käytäntöön
panon laatu, ja tuotemääritelmät. Ilmapiiri, kulttuuri, arvot ja ylemmän johdon tuki liittyy
molempiin näkökulmiin.
Szarkonyi (1994, s.27-28) on määritellyt tuotekehityksen tehokkuuden osatekijöiksi hyvän
tuotekehityksen suunnittelun, markkinoiden tarpeiden tunnistamisen, pätevän johdon, tehokkaan tekniikan siirron valmistukselle, sopivien taloudellisten mittareiden käytön tuotekehitystä arvioidessa ja hyvän yhteistyön eri toimintojen kesken. Cooper & Kleinschmidt
(2007, s.57) ovat määritelleet tuotekehityksen menestystekijöiksi laadukkaan tuotekehitysprosessin, määritellyn tuotestrategian, tarvittavat resurssit, tuotekehityskustannukset,
laadukkaat projektiryhmät, ylemmän johdon sitoutumisen, innovatiivisen kulttuurin ja ilmapiirin, ns. cross funktionaalisten projektiryhmien käytön ja ylemmän johdon vastuun tuotekehityksen tuloksista.
3.1 Oikeiden asioiden tekemiseen vaikuttavat tekijät
Tuotekehityksen tulee tehdä oikeita asioita, eli keskittyä niiden projektien toteuttamiseen,
joita asiakkaat ovat valmiita ostamaan. Tuotekehitysprosessi ja toiminta pohjautuvat yrityksen tuotekehitysstrategiaan, joka on tuotekehityksen suorituskykyyn vaikuttava kriittinen menestystekijä. Davila (2000, s.392) jaottelee eri strategiamalleja, joista yritykset voivat valita toiminnalleen sopivimman. Strategia voi olla esim. asiakas- tai teknologiasuuntautunut, markkinoille tulon ajoitukseen liittyvä (time-to-market) tai alhaisiin kustannuksiin
tähtäävä. Eri strategiat ohjaavat tuotekehityksen toimintaa eri suuntiin ja asettavat toiminnalle erilaisia tavoitteita.
Loch & Tapper (2002, s.186) toteaa, että yrityksen valitsema strategia vaikuttaa koko yrityksen toimintaan. Yrityksen liiketoimintastrategiaa voidaan kuvata viidellä kysymyksellä:
mitä myymme, kenelle, miten, miksi ja mitkä ovat ympäristön suurimmat uhat. Vastaamalla kysymykseen ”miten”, saadaan selville, mitä ydinosaamista yritys tarvitsee ja millaisia
valittujen prosessien tulee olla. Vastaus ”miksi” kysymykseen selvittää, mitä arvoa yritys
luo asiakkaalle. Lisäksi yrityksen teknologiastrategian pitää olla johdettu liiketoimintastrategiasta ja sen pitää kuvata liiketoimintastrategian näkökulmia. Teknologiastrategian tulee
ilmaista, mitä teknologioita tuotekehityksen pitää hallita, millaisia tuotteita kehitetään ja
27
mille segmenteille toiminnat kohdistetaan, miten toimenpiteet vaikuttavat kilpailuetuun ja
miten suojaudutaan ympäristön uhilta.
Valitusta tuotekehitysstrategiasta riippumatta on strategialle kriteerejä, joita sen tulee täyttää. Strategiasta tulee käydä ilmi uusien tuotteiden tavoitteet, miten uusi tuote auttaa yrityksen tavoitteiden saavuttamisessa ja se ottaa kantaa tuotteisiin, markkinoihin ja teknologioihin. Strategiassa tulee olla luotuna suuntalinjat ja strategian tulee olla selkeästi
kommunikoitu työntekijöille. Yrityksen tulee olla sitoutunut pitkän aikavälin toimintaan ja
yrityksillä tulee olla sekä lyhyt aikaisia että pitkäaikaisia kehitysprojekteja samanaikaisesti
menossa. (Bhuiyan 2011, s.751-752; Cooper & Kleinschmidt 1995, s.384; Cooper &
Kleinschmidt 2007, s.61-62)
Park (2007, s. 108-109) määrittelee strategian asettamien tavoitteille kriteerejä. Niiden
tulee olla realistisia, mitattavia ja tuotekehitysryhmän jäsenten on hyväksyttävä ne. Suomala & Jokioinen (2003, s.225) painottavat tuotekehitysprojektien strategian mukaisuutta.
Ilman strategialiitosta projekti ei saa sen tarvitsemia resursseja ja tukea ollakseen menestyksekäs. Strategiasidonnaisuus ei välttämättä riitä varmistamaan projektin menestystä,
jos muut tärkeät kohdat, kuten asiakashyväksyntä, oikea ajoitus tai kustannukset, on laiminlyöty. Kahn et al. (2006, s.109) muistuttavat, että yritysten tulee muokata strategiaa
jatkuvasti vastaamaan markkinoiden tarvetta ja markkinatilaisuuksia tulee havainnoida
tauotta. Lisäksi yritysten tulee varmistaa, että sillä tarvittavat resurssit saatavilla valitun
strategian toteuttamiseen.
Reid & Brady (2012, s.240) osoittavat tutkimuksensa tuloksissa, että markkinasuuntautuneisuudella on positiivinen vaikutus uuden tuotteen kehittämisprosessiin ja tuotteen menestymiseen. Tutkimuksen tulosten mukaan asiakkaan panos strategian kehittämiseen
ohjaa tuotekehitysprosessia ja prosessin etupään toimintoja. Markkinasuuntautuneisuuden myötä tuotekehitysryhmän kommunikointi muiden toimintojen kanssa ja koordinaatio
lisääntyy. Työntekijät ymmärtävät panostaa asiakkaalle suunnatun arvon luomiseen ja
samalla ymmärrys kilpailijoista ja kilpailueduista lisääntyy. Asiakkaan osallistuminen tuotekehitysprosessiin nopeuttaa tuotteen markkinamahdollisuuksien määrittelyä ja asiakasarvon ymmärrystä. Prosessin aikana tulee varmistaa, että ideointi- ja konseptien kehittämisvaiheissa markkinat ja asiakas ovat niiden keskiössä.
Fuchs & Schreier (2010 s.28) toteavat, että asiakkaiden mukaan ottaminen tuoteideoinnissa ja projektien valitsemisessa vaikuttaa positiivisesti yrityskuvaan ja täten parantaa
tuotteiden myyntiä. Asiakkaan osallistuminen prosessiin vaikutti positiivisesti myös yrityk-
28
sen toimintaan, mm. henkilökunta sitoutui paremmin ylläpitämään laatua. Buganza et al.
(2010, s.73) toteavat tutkimuksensa tuloksena, että mikäli yritys toimii nopeasti muuttuvassa toimintaympäristössä, asiakkaan osallistuminen sekä prototyyppien tekeminen ja
kokeileminen on erityisen tärkeää menestymisen kannalta.
Suomala & Jokioinen (2003, s.225) suosittelevat, että asiakastarpeiden ymmärtämisen
parantamiseksi tulisi konsultoida asiakkaita tuotekehitysprosessin jokaisessa vaiheissa.
Kahn et al. (2006, s. 111) määrittelevät asiakkaan osaksi prosessia ja konsepti-, tuote- ja
markkinatestauksen tulisi olla jatkuvaa. Testaamisen tavoitteena tulisi olla tulevien asiakastarpeiden tunnistaminen. Wang et al. (2012, s.20) toteavat, että asiakastarpeiden ymmärtäminen ja niiden muuttaminen teknisiksi vaatimuksiksi on tuotekehitystoiminnan erityisen tärkeää.
Matzler & Hinterhuber (1998, s.26) painottavat, että yritysten tulee panostaa asiakastarpeiden analysointiin ja niitä tyydyttävien tuotteiden kehittämiseen markkinoille. Asiakastyytyväisyys takaa yrityksille kilpailuetua ja korkeaa asiakastyytyväisyyttä pidetään parhaimpana menestymisen mittarina. Asiakastyytyväisyys johtaa asiakasuskollisuuteen, joka
puolestaan johtaa vakaaseen tulovirtaan. Tyytyväiset asiakkaat ostavat enemmän ja useammin ja ovat valmiita maksamaan enemmän tuotteista.
Cooper (2000, s.55) on määritellyt yrityksen kriittiseksi menestystekijäksi erilaiset ja ylivertaiset tuotteet, joita asiakas haluaa. Cooper toteaa tutkimuksessaan, että yrityksillä on
yleensä kaksi tuotteisiin liittyvää ongelmaa. Ensimmäinen ongelma on, että tuotteet eivät
erotu kilpailijoiden joukosta. Yritysten tulisi kehittää asiakastarpeita vastaavia tuotteita ja
kilpailijoiden tuotteista tulisi hakea heikkouksia. Toinen ratkaistava ongelma on, että kehitetyt tuotteet ovat liian monimutkaisia käytettäväksi ja ne voivat sisältää ominaisuuksia,
joista asiakas ei ole valmis maksamaan. Thomke & Reinertsen (2012, s.91) toteavat, että
tuotteisiin liittyvä yleinen uskomus on, että mitä enemmän tuotteessa on ominaisuuksia,
sitä tyytyväisempi asiakas on. Tämä johtaa monimutkaisiin ja vaikeasti käytettäviin tuotteisiin. Tuotekehityksen pitää osata valita ne piirteet, mitkä tuotteessa pitää olla ja mitkä jätetään pois. Resurssit tulee keskittää toivottujen ominaisuuksien kehittämiseen.
Tuotekehitysprosessissa sen etupään toimintoja tulee painottaa. Ennen projektien valintaa
tuotekonseptien testausta tulisi tehdä paljon. Yritysten tulisi tehdä myös enemmän analyysejä, kuten markkina- ja kilpailija-analyysi, joilla arvioida tuotteen toimivuutta, ennen
kehitysvaihetta. Tosiasioihin perustuvat markkina-, teknologia- ja liiketoiminta-analyysit
29
maksaa itsensä takaisin prosessin myöhäisemmissä vaiheissa. (Cooper 2006, s.20; Cooper 2000, s.55)
Toiminnan suunnittelun perustaksi tuotekehitys tarvitsee selkeät tuotemääritelmät. Laadullisesti heikot tuotemääritelmät ovat suuri syy aikataulumyöhästymisiin. Tuotemäärittelyt
tulisi pohjautua konseptien testausvaiheissa tehtyjen tosiasioihin perustuviin analyyseihin.
Tuotemäärittelyn kuuluu sisältää mm. tavoitemarkkinat, tuotekonsepti ja sen hyödyt, miten
tuote toteuttaa valittua strategiaa, tavoitehinta, tuoteominaisuudet ja -vaatimukset sekä eri
määritykset. Tuotekehitysryhmän tulee hyväksyä määritelmä. (Cooper 2000, s.55)
Konseptien testaamisen jälkeen valintaan projektit, joita lähdetään toteuttamaan. Kahn et
al. (2006, s.109-110) toetavat, että menestyvillä yrityksillä on käytössä virallinen ja järjestelmällinen portfolio, jonka käytöstä seuraa parantunut resurssien allokointi. Verbano &
Nosella (2010, s.363-364) määrittelevät portfolion projektien ryhmäksi, jossa jokaisella
projektilla on omat ominaisuudet ja innovaatiotasonsa. Shepherd & Pervaiz (2000, s.167169 ) määrittelevät portfolion projektinhallinnan työkaluksi, jossa määritellään eri projektien tehtävät ja projekteista halutut tulokset.
Wang et al. (2012, s.14) toteavat, että portfolion käytöllä on kolme tavoitetta: portfolioon
tulee valita oikeat projektit, joista kehitetään tuotteet, kehitettävillä tuotteilla tulee olla tehokkaat elinkaaret ja valituilla projekteilla tulisi voida käyttää prosessia tehokkaasti. Verbano & Nosella (2010, s.363-364) määrittävät portfolion kriteereiksi, että portfoliossa olevien projektien välillä tulee olla tasapaino tuoteparannusten ja uusien tuotteiden välillä.
Portfoliossa olevat projektit tulee olla tasapainossa ja yrityksellä tulee olla projektien vaatimat resurssit saatavilla. Lisäksi valittujen projektien tulee olla strategian mukaisia.
Shepherd & Pervaiz (2000, s.169) toteavat, että portfolion käytöstä seuraa paremmat projektisuunnitelmat ja resurssien allokointi projekteille. Paremmat suunnitelmat ja resurssien
allokoinnin paraneminen alentavat tuotekehityskustannuksia.
Cooper (2006, s.20-21) toteaa, että portfolio johtaminen parantaa tuottavuutta. Portfoliossa projekteja tulee arvioida ja ne pitää priorisoida. Kehitettävien projektien toteutukseen
tulee taata riittävät resurssit ja sitouttaa ne projektiin. Projektin suunnittelussa tulee ottaa
huomioon resurssivaatimukset, projektin kesto ja etenemissuunnitelma. Verbano & Nosella (2010, s.364-365) määrittelevät portfolio johtamisen päätöksenteoksi, johon liittyy projektien arviointi, valinta ja priorisointi. Johtamisen tavoite on yrityksen strategisten tavoitteiden saavuttaminen. Portfolionjohtamiseen liittyy asioita, jotka tekevät siitä haastavan,
kuten epävarmuuksien korkea taso, tiedon jatkuva muuttuminen, dynaamiset mahdolli-
30
suudet, monet usein ristiriitaiset laadulliset tavoitteet, strategia näkökohdat, valittujen projektien tasapainon tarve, projektien keskinäinen riippuvuus ja useat eri päätöksentekijätahot. Adams et al. (2006, s.35) määrittelevät portfolio johtamisen haasteiksi mm. resurssien
allokoinnin ja tuoton maksimoinnin.
Chen et al. (2006, s.177) toteavat, että oikeiden projektien valitsemisessa tulee ottaa
huomioon monia eri tekijöitä. Näitä ovat mm. tuotekehityksen kyvykkyydet viedä projekteja
läpi, tuotteen markkinapotentiaali ja sen sijoittuminen markkinoilla, tuotteen arvioitu vaikutus tuloihin, kilpailijat, tuotantokokemukset, tuotteen tekniset ominaisuudet, tuotteen kilpailuedut sekä tuotteessa käytetty teknologia. Verbano & Nosella (2010, s.363-364) lisäävät
projektien valintaan liittyväksi avaintekijäksi riskien arvioinnin, joka pitää tehdä jokaiselle
projektille.
Park (2007, s. 106-111) toteaa, että arvioituja riskejä ja epävarmuuksia tulee johtaa systemaattisesta. Riskien johtamisen tavoite on varmistaa tuotekehitysprojektin toteutettavuus rajoitusten sisällä. Riski voi realisoitua missä kohtaa projektia tahansa ja ne ovat
yhteydessä epävarmuuksiin. Epävarmuuksia ovat markkina-, teknologia-, prosessi- ja
taloudellinen epävarmuus. Markkinaepävarmuuksia ovat mm. asiakas, markkinat ja kilpailijat. Teknologiaepävarmuuksiin liittyy mm. testaamaton teknologia, työntekijöiden taidot ja
oppimiskyvyt. Prosessiepävarmuudet sisältävät mm. luotettavuuden, tuotantohinnan, laadun ja ajoituksen. Taloudelliseen epävarmuuteen liittyy mm. pääoman saatavuus ja odotettu investoinnin tuotto. Epävarmuus ja riskit pienenevät, jos niitä johdetaan tehokkaasti.
Riskien vähentämisessä on tärkeää tunnistaa projektiin liittyvät riskit ja epävarmuudet.
Tunnistamisen jälkeen ne arvioidaan ja tehdään suunnitelma niiden vaikutusten minimoinnista
Park (2007, s.109) painottaa myös projektien valinnassa reaalimaailman luomia rajoitteita
tuotteelle ja sen kehittämiselle. Rajoitteet tulee ottaa huomioon projekteja valittaessa ja ne
tulee pystyä tunnistamaan etukäteen ja niiden pohjalta tulee arvioida, onko tuote toteutettavissa halutulla tavalla. Tyypillisiä rajoitteita tuotekehitysprojekteille ovat tekninen kyvykkyys, rahoitus ja ihmiset.
Suomala & Jokioisen (2003, s.225) toteavat, että ilman ylemmän johdon tukea ei toteutukseen siirtyvät tuotekehitysprojektit voi menestyä, koska ylempi johto on vastuussa resurssien allokoinnista ja resurssien riittävyyden varmistamisesta. Cooper (2000, s.55-57)
toteaa, että ylemmän johdon tulee olla sitoutunut tuotekehitykseen, koska on ylemmän
johdon vastuulla luoda visio, tavoitteet ja strategia tuotekehitystoiminnalle. Resurssien
31
allokoinnin lisäksi on ylemmän johdon vastuulla, että resursseilla on myös aikaa tehdä
määrätyt tehtävät. Usein yritetään tehdä liian montaa projektia liian pienillä resursseilla.
Yleisesti oletetaan, että resurssien korkea käyttöaste parantaa suorituskykyä. Tuotekehitystoiminnan vaihtelevissa prosesseissa kaikki lähtökohdat ja tehtävät eivät ole ennustettavissa ja toistettavissa kuten esim. valmistuksessa. Vaihtelevissa prosesseissa 5%
enemmän tehtäviä voi viedä 100% kauemmin suorittaa ne ja tämä tulee ottaa huomion
resurssien allokoinnissa. Toinen uskomus on, että mitä aikaisemmin projekti alkaa, sitä
aiemmin se myös päättyy. Projekteja ei tulisi kuitenkaan aloittaa ennen kuin resursseja on
vapaana. Mikäli projektit aloitetaan ilman, että sen vaatimia resursseja on käytettävissä,
seurauksena on myöhästymisiä. Teknologian kehitys ja muuttuvat markkinat voivat tehdä
projektista turhan tai projektin vaatimuksia on muutettava, jos projekti myöhästyy liikaa.
(Thomke & Reinertsen 2012, s.86-89)
Organisaationkulttuuriin ja rakenteeseen liittyy, miten henkilökunta on ryhmitetty ja ilmapiiri, jossa työskennellään. Organisaation pitää antaa vapautta luoviin toimenpiteisiin, mutta
siitä huolimatta johtaa innovaatioita tehokkaasti. Henkilöstönhallintaan ja ilmapiirin luomiseen kuuluu neljä osaa, joita ovat osallistuminen päätöksentekoon, innovaation tukeminen, visio ja tehtäväsuuntautuneisuus. Ryhmän autonomia on tärkeää ja siihen kuuluu
vapaus kokeilla. Mitä jaetumpi visio on, sitä selkeämpi visio ja sitä enemmän uusia ideoita. Riskien sietokyky riippuu kulttuurista. (Adams et al. 2006, s.32- 34)
3.2 Tuotekehitystoimintaan vaikuttavat tekijät
Kun on varmistettu, että tehdään oikeita asioita valitsemalla oikeita projekteja toteutukseen, seuraava askel on varmistaa, että asioita tehdään oikein. Asioiden oikein tekemiseen liittyy mm. tuotekehitysprosessit, resurssien saatavuus ja allokointi, suhde markkinointiin ja muihin sidosryhmiin, projektiryhmät, projektien priorisointi, käytäntöön panon
laatu ja tuotemääritelmät. (Andersson 2008, s.554-555)
Tuotekehitystoiminnan ei tulisi perustua oletukseen, että toiminta on menestyksekästä, jos
tuote kehitetään valmiiksi heti ensimmäisellä yrityksellä. Tämä lähtökohta aiheuttaa tuotekehitystoiminnassa sen, että valitaan vähiten riskejä sisältäviä ratkaisuja, vaikka asiakas
ei niitä juuri arvosta. Tuotekehityksessä ”tehdä virhe ensin” on parempi lähtökohta sillä
edellytyksellä, että parannukset tehdään nopeasti ja virheistä opitaan. (Thomke & Reinertsen 2012, s.92-93)
32
Reid & Brady (2012, s. 240) toteavat tutkimuksessaan, että menestyvälle tuotekehitysprosessille on ominaista vahva eri toimintojen välinen yhteistyö, ns. cross funktionaalisuus.
Eri toimintojen välinen yhteistyö prosessin aikana parantaa esisuunnittelua ja kehitysvaiheiden tulosten laatua ja näin ollen myös suorituskykyä. Ayers et al. (2011, s.134-135) ja
Brettel et al. (2011, s.262) painottavat erityisesti tuotekehityksen ja markkinoinnin välisen
yhteistyön tärkeyttä, koska sillä varmistetaan, että markkinaodotukset ovat osa teknologiakehitystä. Tuotekehityksen ja markkinoinnin välisellä integraatiolla on positiivinen vaikutus suorituskykyyn, koska kun projekti saa tietoa asiakkaasta ja sen tarpeista, voi projekti keskittyä suorituskyvyn parantamiseen ja tekemään oikeita projekteja. Brettel et al.
(2011, s.262) painottavat markkinointiyhteistyön lisäksi tuotekehityksen integraatio valmistuksen kanssa. Tuotekehityksen ja valmistuksen välinen yhteistyö vaikuttaa tehokkuuteen
positiivisesti, koska jos tuotekehitys saa tietoa valmistusrajoitteista ja se voi näin välttää
korjauskierrokset.
Tuotekehityksen ja markkinoinnin välistä yhteistyötä suunnitellessa tulee muistaa, että
tuotekehityksen ja markkinoinnin välisen kommunikaation määrä ei välttämättä vastaa
laatua. Viikoittaiset palaverit eivät välttämättä nosta yhteistyönlaatua, vaan henkilökohtaiset suhteet ja asenteet toimivat paremmin. Suhteisiin ja asenteisiin voi vaikuttaa jakamalla
päätöksentekovastuut projektin alkuvaiheeseen. On ylemmän johdon vastuulla selventää
roolit ja vastuut päätöksentekoprosessissa. Suhteiden on todettu lähenevän, jos on yhdessä vastuussa päätöksistä. Yhteisten tavoitteiden määrittelyssä auttaa, jos kaikkia päätöksentekoprosessiin osallistujat ymmärtävät tuotekehityksen ja markkinoinnin yhteistyön
tärkeyden. Liian läheiset suhteet eivät kuitenkaan ole hyvästä, koska silloin ei välttämättä
tuoda ongelmia johdon käsiteltäväksi. (Ayers et al. 2011, s.146)
Cooper (1999, s. 119-120) toteaa, että tuotekehitysprojektissa toimivien eri toimintojen
välisen yhteistyön ja kommunikaation heikko taso vaikuttaa negatiivisesti prosessissa tehtäviin päätöksiin. Tuotekehitykseen liittyvät eri toiminnot voivat vaikuttaa päätöksiin heille
parhaiten sopivilla tavoilla projektin kokonaishyödyn kustannuksella. Tämä on mahdollista,
jos projektin johtamisen taso on heikkoa. Cooper (2000, s.55) kuitenkin toteaa, että menestyvä tuotekehitystoiminta vaatii cross funktionaaliset projektiryhmät, jotka ovat vastuullisia tuloksistaan.
Sekä Park (2007, s.110) että Kahn et al. (2006, s.112) suosittelevat cross funktionaalisen
ryhmän muodostamista ideoiden luomisvaiheessa ja ryhmän tulisi pysyä yhdessä aina
kaupallistamisvaiheeseen asti. Slotegraaf & Atuahene-Gima (2011, s. 103) toteavat projektiryhmän pysyvyydellä olevan positiivinen vaikutus projektin suorituskykyyn. Ryhmän
33
koossa pysyminen vaikuttaa päätöksentekoprosessiin ja tiedon jakamiseen. Ns. hiljaisen
tiedon jakaminen on helpompaa, jos ryhmä pysyy yhdessä koko projektin ajan ja ryhmän
jäsenet tulevat toisilleen läheisimmiksi. Päätöksentekoprosessiin kuuluu osana väittely.
Väittelyssä prosessiin osallistujat jakavat tietoa ja päätösten laatu paranee. Mitä tutummat
jäsenet, sitä helpompaa on esittää eriäviä mielipiteitä ja nostaa esille riskejä.
Slotegraaf & Atuahene-Gima (2011, s. 103) muistuttavat, että ryhmä ei saa olla liian stabiili vaan ryhmä tarvitsee myös ulkopuolisia vaikutteita. Liian stabiili ryhmä vaikuttaa päätöksentekoprosessiin kuuluvan väittelyn laatuun negatiivisesti. Eräs syy tähän tutkijoiden
mukaan on, että jos jäsenet ovat liian tutuissa väleissä, ryhmän jäsenistä tulee ystäviä ja
väittelyjä pyritään välttämään. Tässä tilanteessa tulee hakea aktiivisesti vaikutteita ulkopuolisista lähteistä.
Projektiryhmän laatu vaikuttaa tuotekehityksen suoritukseen. Laadukkaan projektiryhmän
tulisi keskittyä vain kehitystyöhön. Muodostetun ryhmän tulisi kommunikoida avoimesti ja
jakaa tietoa keskenään säännöllisin väliajoin. Tehokkaalla kommunikaatiolla voidaan lyhentää kehitysaikaa, vähentää tuotteen epäonnistumista ja tarvittavaa rahallista investointia sekä parantaa resurssien allokointia projekteille. Kommunikaatio tulisi keskittää projektin kehittymisen arviointiin, mahdollisiin ongelmiin ja ongelmien ratkaisemiseen, siihen,
mitä opittiin ja onko jotain, mitä ei ole osattu ottaa huomioon. Ryhmän tulisi käsitellä tehdyt päätökset nopeasti ja tehokkaasti. (Cooper & Kleinschmidt 2007, s.63-64; Kahn et al.
2006, s.112; Park 2007, s.110)
Ancona & Caldwell (2007, s.41-42) tutkivat hyvin ja huonosti menestyneitä ryhmiä. Tutkimuksen mukaan hyvin toimivilla ryhmillä on enemmän kanssakäymistä valmistuksen,
markkinoinnin ja ylemmän johdon kanssa. Ne ovat yleensä aktiivisia kommunikaation
aloittamisessa ja niillä on enemmän ulkoisia kontakteja kuin heikommin menestyvillä ryhmillä. Hyvin ja heikommin menestyvien ryhmien tavoitteissa ja sisäisissä toiminnoissa ei
välttämättä juurikaan ole eroa.
Cooper & Kleinschmidt (2007, s.63-64) toteavat, että projektiryhmällä tulisi olla vetäjä,
joka on vastuussa ryhmän toiminnasta. Vetäjällä tulisi olla yksi projekti menossa kerrallaan, koska liian moneen projektiin keskittyminen samanaikaisesti heikentää tehokasta
johtamista. Park (2007, s. 106-111) toteaa, että tehokas projektinjohto johtaa nopeampaan kommunikaatioon projektin aikana. Projektijohdon tulee myös jakaa vastuut selkeästi ryhmän jäsenille. Buganza et al. (2010, s.73) mukaan projektin johtamistavoilla on myös
34
positiivinen vaikutus lopputulokseen. Johtamistapoihin kuuluu virallinen prosessi, toimintojen suunnittelu, resursointi ja resurssien aikainen allokaatio.
Chen et al. (2006, s.176) määrittelevät projektien johtamisen osaksi päätöksenteon. Projektin johdon tulee tehdä päätöksiä tavoitteiden tärkeysjärjestyksestä, suunnitellusta ajoituksesta, toimintojen jaksotuksesta, tärkeistä projektin tarkastuspisteistä ja prototyypeistä.
Adams et al. (2006, s.36-37) toteavat, että projektin johtaminen liittyy prosessiin, jossa
panoksista muokataan myytävä tuote. Projektin johtamisessa tulee ottaa huomioon kommunikaation tärkeys. Sisäisellä kommunikaatiolla on positiivinen vaikutus innovaatioihin ja
innovointiin. Sisäisellä kommunikaatiolla vaikutetaan myös ilmapiirin luomiseen positiivisesti.
Andersson (2008, s. 554) toteaa, että suotuisa yrityskulttuuri ja –ilmapiiri luo paremmin
jatkuvan innovaatiotoiminnan, kuin johtamistekniikat, prosessit ja käytännöt. Menestynyt
innovatiivinen ilmapiiri rakentuu ihmisten välisiin suhteisiin, hierarkian luonteeseen, työn
luonteeseen, tukeen ja palkkioihin. Cooper & Kleinschmidt (2004, s.38-39) määrittelevät
positiivisen ilmapiirin koostuvan 12 tekijästä, jotka jakautuvat kahteen eri kategoriaan,
yleiseen ja toimintoihin. Yleisiin tekijöihin kuuluu yrittäjyyttä ja innovaatiota tukeva ilmapiiri,
mestareiden palkitseminen, projektiryhmien palkitseminen, yrityksen tuotekehitysprosessin ymmärtäminen, avoin kommunikaatio, matalan riskin hakeminen ja epäonnistumisten
rankaisematta jättäminen. Toiminnallisiin tekijöihin kuuluu resurssien saatavuus luovaan
työhön, epävirallisiin projekteihin kannustaminen, aikaa etsiä uusia ideoita, uusien ideoiden palkitseminen ja uusien tuotteiden ideoiden järjestelmä.
Riittävät resurssit ja rahoitus liittyvät keskeisesti tuotekehityksen menestykseen. Hyvin
tehdyt suunnitelmat ja strategiat eivät toimi, jos tekijöitä ei ole tai tekijöillä ei ole aikaa tehdä asioita kunnolla, koska heillä on liian monta projektia menossa samanaikaisesti.
Ylemmän johdon tulee allokoida tarvittavat resurssit oikein uuden tuotteen tavoitteiden
saavuttamiseksi. Lisäksi ylemmän johdon tulee varmistaa riittävät tuotekehitysbudjetit
tavoitteiden saavuttamiseen. Ylemmän johdon sitoutuminen ja osallistuminen tuotekehitykseen vaikuttaa positiivisesti tuotekehityksen menestymiseen. (Cooper & Kleinschmidt
2007, s.62)
Ylemmän johdon ei tulisi kuitenkaan olla osallisena tuotekehitysryhmän jokapäiväisessä
toiminnassa. Cooper (1999, s.119-120) toteaa, että ylempi johto ei välttämättä aina anna
tuotekehitysryhmälle vastuuta ja sekaantuvat yksityiskohtiin ymmärtämättä kokonaisuudessa ryhmän tekemiä päätöksiä. Cooper & Kleinschmidt (2007, s.63-64) suosittelevat,
35
että ylemmän johdon tulisi osallistua projektiryhmän toimintaan projektien katselmointipisteissä. Ylemmän johdon tulee olla osa päätöksentekoprosessia projektin jatkosta ja tuotekehitysprosessin toiminnan arvioinnissa. Lisäksi ylemmän johdon tulisi olla vastuussa tuotekehityksen toiminnasta. Tuotekehityksen mittarit tulisi olla osa ylemmän johdon mittareita, jotka ovat johdon palkitsemisen välineitä. Tärkeää on myös, että vastuu tuotekehityksen suoritusta mittaamisesta on määritelty ja mittaaminen oikeasti tapahtuu.
Edellä mainittujen tekijöiden lisäksi tuotekehityskustannukset ovat indikaattori tuotekehitystoiminnan laadusta. Suomala & Jokioinen (2003, s.225) painottavat, että tuotekehitysprojektien kustannustehokkuuden tulisi aina olla hyväksyttävällä tasolla vaikka päätavoite
ei olisi kustannustehokkuus. Teknisesti hyvä tuote, jolla on väärä hintalappu, ei ole houkutteleva tuote. Cooper & Kleinschmidt (2007, s.57, 63) toteavat tuotekehityskustannuksia
mitataan yleensä uusien tuotteiden osuudesta myynnistä. Kyseinen mittari on vahva
merkki tuotekehitystoimintojen vaikutuksesta yrityksen tulokseen. Tuotekehityskustannukset eivät kerro tuotteen suorituskyvystä vaan toiminnan tuottavuudesta.
Teknisesti hyvä tuote on riippuvainen siinä käytetystä teknologiasta. Suomala & Jokioinen
(2003, s.225) suosittelevat, että tuotteissa käytettävien teknologioiden toiminta tulisi olla
hyvin testattu loppukäyttäjien ympäristössä ennen käyttöönottoa. Mahdollisesti tulisi harkita olemassa olevan teknologian potentiaalin hyödyntämistä loppuun asti ennen uuden
teknologian käyttöönottoa. Uuden teknologian suunnittelu tulisi erottaa tuotteen suunnitteluprosessista. Uuden teknologian tuominen tuotteeseen lisää tuotteen teknologiariskiä.
Buganza et al. (2010, s.73) toteavat, että avoimen, modulaarisen ja skaalautuvan teknologian käyttö vaikuttaa positiivisesti tuotekehityksen suorituskykyyn. Avoimen teknologian
avulla yritys voi hyötyä muiden innovaatioista ja sen käyttö vähentää resurssien tarvetta.
Modulaarisuus parantaa joustavuutta ja alentaa kustannuksia tuotekehityksen loppuvaiheessa. Skaalautuvuuden avulla yritys pystyy sopeutumaan muutoksiin paremmin. Patentoidun teknologian käytöllä on negatiivinen vaikutus menestymiseen, koska patentoidun
teknologian käyttö vaatii enemmän resursseja kuin avoimen teknologian käyttö.
Teknisiä tavoitteita määrittäessä alihankkija tulisi ottaa mukaan prosessiin. Alihankkijoiden
integroiminen osaksi tuotekehitysprosessia voi vaikuttaa positiivisesti tuotekehityksen lopputulokseen. Alihankkijan mukaan ottaminen teknisten tavoitteiden määrittelyyn on tärkeää etenkin teknisesti haastavissa projekteissa. Tiedon jakaminen käytettävän teknologian
mahdollisuuksista lisääntyy ja projektille voidaan luoda realistiset tavoitteet. Alihankkijan
mukaan ottamisen kautta tuotteen laatu paranee. Tuotteen tuotekustannukset alenevat,
36
tuotteen valmistus helpottuu yhteisten komponenttien käytön ja suunnittelun myötä. Alihankkijan mukaan ottamisesta seuraa taloudellista hyötyä yritykselle. (Handfield & Lawson 2007, s.49)
Onnistuneen alihankkijan integroiminen osaksi tuotekehitystä vaatii sopivaa yrityskulttuuria. Valitun alihankkijan yrityskulttuurin olisi hyvä olla lähellä asiakasyrityksen vastaavaa.
Yhteistyösuhde vaatii tukea kaikilta liiketoimintaihmisiltä, ei pelkästään osto-osaston henkilökunnalta. Ylemmän johdon tuki on kriittistä implementoinnissa. Yhteistyöstrategia ja
yrityksen kyvykkyydet tulee muodostaa markkinatarpeiden lähtökohdasta ja tavoite on
tehokas ja menestynyt tuote. Johdon tulee myös arvioida, miten alihankkijan integroiminen prosessiin vaikuttaa osallistujiin. Osallistujat voivat tarvita koulutusta tiimityöskentelystä, ongelmanratkaisusta, neuvottelutaidoista ja konfliktin hallinnasta. Alihankkijan integroinnin kriittiset tekijät ovat komponentit, alihankkijat ja cross funktionaalisten ryhmien
luominen. (Cadden & Downes 2013, s.733; Handfield & Lawson 2007, s.48-49)
37
4. TUOTEKEHITYKSEN SUORITUSKYVYN MITTAAMINEN
Kahn et al. (2006, s. 113-114) määrittelevät mittaamisen osaksi menestyvää tuotekehitystä. Cooper (2006, s.21) toteaa, että tuotekehityksen toimintaa ei voi arvioida, kehittää eikä
tuotekehitysryhmää voi pitää vastuullisena tuloksista ilman mittaamista. Mittaamisella arvioidaan, miten hyvin projektiryhmä saavuttaa sille asetetut tavoitteet. Tuotekehitystoimintaa tulee mitata lanseerauksen jälkeen ja katselmoinneissa. Oppimisen ja jatkuvan parantamisen kannalta tulee selvittää syyt tavoitteista jäämiseen ja kehittää korjaavat toimenpiteet tavoitteen saavuttamiseksi tulevaisuudessa.
Kahn et al. (2006, s. 113-114) suosittelevat, että aloitettaville projekteille määritetään arviointikriteerit, joita vastaan tuotekehitystoimintaa ja tuloksia arvioidaan. Suorituskyvyn arvioijat tulee olla määritelty ja pitää huolehtia, että haluttua dataa kerätään. Dataa tulee
seurata säännöllisesti ja data tulee olla saatavilla analyyseja varten. Käytössä oleva mittaristo määrää, miten suorituskykyä mitataan, jäljitetään, raportoidaan ja talletetaan.
4.1 Tuotekehityksen suorituskyvyn osa-alueet
Tuotekehityksen suorituskyvyn mittaamiseen vaikutta kolme osatekijää, jotka ovat toimintaympäristötekijät, tavoite ja mittausjärjestelmä. Toimintaympäristön taustatekijät vaikuttavat sekä mittausjärjestelmään ja tavoitteeseen ja tavoite vaikutta mittausjärjestelmään
(katso esim. Kerssens-van Drongelen & Bilderbeek 1999, s.36-37; Chiesa et al 2009a,
s.491). Em. tekijöiden lisäksi Chiesa & Frattini (2007a, s.285-286) toteavat, että mittausjärjestelmän toimivuuteen vaikuttaa mittausjärjestelmän implementointi. Mittaukseen osallistuvien ihmisten tulisi osallistua järjestelmän suunnitteluun, tiedon keräämiseen ja tulosten analyysiin. Kuvassa 8 on kuvattu kirjallisuudessa esitetyt tuotekehityksen suorituskykyyn vaikuttavat tekijät ja niiden väliset yhteydet.
Kuva 8. Tuotekehityksen suorituskyvyn osa-alueet (Chiesa et al. 2009, s.31; Chiesa 2009a, s.491)
38
4.1.1 Taustatekijät
Tuotekehityksen taustatekijöihin sisältyy ulkoisia tekijöitä, joihin tuotekehitys ei voi vaikuttaa, mutta jotka vaikuttavat tuotekehityksen toimintaan. Menestyäkseen tuotekehityksen
tulee pysytä sopeutumaan ulkoisiin tekijöihin. Ulkoisia tekijöitä ovat mm. markkinoiden
ennustettavuus, kilpailutilanne ja markkina-alueiden lukumäärä. Ulkoisiin tekijöihin yritys
voi vaikuttaa sisäisillä tekijöillä, jotka muodostuvat omien valintojen pohjalta. Sisäisiä tekijöitä ovat mm. strategia ja strategiset tavoitteet, tuotekehityksen tyyppi ja sen ominaisuudet, organisaatiorakenne ja organisaatiotasot sekä käytettävissä olevat resurssit. (Bassani
et al. 2010, s.488; Chiesa et al 2009a, s.491; Chiesa et al. 2009, s.26-28; Kerssens-van
Drongelen & Bilderbeek 1999, s.38-39; Kerssens- van Drongelen & Cook 1997, s.350).
Yritysten toimiala ja toimintaympäristö eivät ole samanlaisia. Toimintaympäristö voi olla
nopeasti muuttuva tai melko stabiili. Kerssens-van Drongelen & Cook (1997, s. 350) ovat
määritelleet toimialan tekijöitä, jotka vaikuttavat tuotekehityksen suorituskykyyn ja toimintaan. Toimialatekijöitä ovat esim. markkinoiden ennustettavuus, kilpailutilanne ja markkina-alueiden lukumäärä. Toimialatekijät vaikuttavat yrityksen strategiaan ja sitä kautta koko
yrityksen toimintaan.
Yrityksen strategia on yksi osatekijä menestyvässä tuotekehitystoiminnassa. Mm. Loch &
Tapper (2002, s.186) toteavat, että strategia ja strategiset valinnat ohjaavat koko yrityksen
toimintaa ja näin ollen ne myös vaikuttavat tuotekehitykseen. Strategian tulee olla selkeä
ja hyvin kommunikoitu työntekijöille. Jyoti et al. (2006, s.879) toteaa, että etenkin hyvin
kilpailluilla markkinoilla tuotekehityksen menestyksen osatekijä on selkeä visio, missio ja
organisaation strategia.
Tuotekehityksen toiminnan tyyppi vaikuttaa tuotekehityksen toimintaan, mittausjärjestelmän kehittämiseen ja mittauksen tavoitteeseen. Tuotekehityksen kolme päätyyppiä ovat
perustutkimus, soveltava tutkimus ja uuden tuotteen kehittäminen. Jokainen tyyppi eroaa
toisistaan toiminnaltaan ja tavoitteiltaan. Perustutkimuksen lopputulos on vaikea arvioida
tutkimuksen alussa. Koska ei ole selkeää kuvaa, mitä tutkimuksen aikana selviää, aikataulut ovat epävarmoja ja riskitasot korkeat. Perustutkimuksen tulosta on vaikea arvioida
markkinamahdollisuuksien ja taloudellisen hyödyn näkökulmasta. (Kerssen- van Drongelen & Cook 1997, s. 350)
Soveltavassa tutkimuksessa pyritään kehittämään perustustutkimuksen tuloksista ydinteknologioita, joita käyttää hyväksi uusien tuotteiden kehittämisessä. Soveltavat tutkimuk-
39
sen riskitaso on matalampi kuin perustutkimuksen ja ajallisesti sen odotetaan olevan perustutkimusta lyhyempi. Uuden tuotteen kehittämisessä lopputulos on helpommin määriteltävissä ja riskitasot ovat matalammat kuin perus- tai soveltavassa tutkimuksessa. Uuden tuotteen kehittämisessä taloudelliset ja markkinalähtöiset tulokset ovat erittäin relevantteja ja siinä keskitytään tuotteistamiseen. Uuden tuotteen kehittämisprojekteissa menestys mitataan markkinamenestyksenä. Ajallisesti uuden tuotteen kehittämisprojektit
pyritään viemään läpi mahdollisimman nopeasti. (Kerssen- van Drongelen & Cook 1997,
s. 350–351; Oh & Bowon 2002, s.22)
Davila (2000, s.392) ja Lettice et al. (2005, s.224-225) toteavat, että organisaatiorakenteella on merkitystä tuotekehityksen suorituskykyyn. Organisaatio rakenne voi olla ns.
cross funktionaalinen, jossa eri toimintojen, kuten esim. suunnittelun, kehityksen, oston ja
markkinoinnin, edustajat työskentelevät yhdessä halutun lopputuloksen saavuttamiseksi.
Toisaalta organisaatio voi koostua vain insinööreistä. Mm. Reid & Brady (2012, s.240)
ovat todenneet, että cross funktionaalinen toimintatapa auttaa tuotekehitystä saavuttamaan sille asetetut tavoitteet paremmin ja näin ollen se on yksi tuotekehityksen menestystekijöistä.
Lisäksi organisaation tasojen lukumäärällä on vaikutusta mittaamiseen. Mittaamista voi
tehdä eri tasoilla eri lähtökohdista. Miten mitataan ja millä tasolla vaikuttaa saatuihin tuloksiin ja sitä kautta suorituskyvyn arviointiin. Organisaatiorakenteeseen kuuluu osana
työntekijöiden kierto eri osastoissa. Työn kierrolla voidaan vaikuttaa cross funktionaalisen
toiminnan paranemiseen. (Davila 2000, s.392; Lettice et al. 2005, s. 224-225)
Organisaation resursseilla on merkitystä tuotekehityksen suorituskykyyn. Mm. Cooper
(2000, s. 55-57) painottaa, että riittävät resurssit tulee olla olemassa toiminnan turvaamiseksi ja resurssien osaamisen ja kyvykkyyksien tulee vastata strategisia tavoitteita. Kerssen- van Drongelen & Cook (1997, s. 351) toteavat, että suorituskyvyn mittaamisen ja
arvioimisen näkökulmasta, käytettävissä olevat resurssit määrittävät sen, mikä on mahdollista mitata. Mittaamiseen liittyviä resursseja ovat mm. yrityksessä käytettävän tietotekniikan taso, mittaamisen kustannukset, työntekijöiden kuormitus ja tietotaso.
Yrityksen toimiala, toimintaympäristö ja yrityksen valinnat vaikuttavat suoraan tuotekehityksen suorituskyvyn mittaamisen tavoitteeseen ja sitä kautta suorituskyvyn arviointiin.
Taustatekijät vaikuttavat myös mittausjärjestelmän toimintaan ja rakenteeseen. (Kerssens- van Drongelen & Cook 1997, s.350-351)
40
4.1.2 Mittaamisen tavoite
Mittaamisen tavoite on tuotekehityksen suorituskyvyn mittaamisessa ja arvioinnissa kriittisin tekijä. Kerssens- van Drongelen & Cook (1997, s.349) ovat jaotelleet mittaamisen tavoitteet kahteen pääkategoriaan: diagnostisiin tavoitteisiin ja henkilökunnan motivoimiseen. Diagnostisella tavoitteella seurataan projektien etenemistä ja arvioidaan projektin
kannattavuutta. Park (2007, s.111) toteaa, että diagnosointitarkoituksia käytetään, jos
toiminnasta on odotettavissa epävarmuuksista johtuvia riskejä. Arviointia käytetään, kun
toiminnan tulos on realisoitunut. Diagnostisen tavoitteen ja motivoimisen lisäksi muita mittaamisen tavoitteita ovat koordinaation ja kommunikaation vahvistaminen, oppiminen ja
sen kautta parempi suunnittelu, tuotekehitysriskin ja epävarmuuden vähentäminen, tuotekehityksen suorituskyvyn parantaminen, tuotekehitystoimintojen tuottavuuden arviointi,
projektien valinnan ja päätöksenteon tukeminen (katso esim. Bigliardi & Dormio 2010,
s.279; Chiesa et al. 2009a, s.495; Chiesa & Frattini 2007a, s.285 – 286; Loch & Tapper
2002, s.195: Szarkonyi 1995, s. 31).
Chiesa & Frattini. (2007, s.198-199) jaottelevat mittauksen tavoitteet koviin ja pehmeisiin.
Kovat ja pehmeät tavoitteet asettavat erilaiset vaatimukset mittausjärjestelmälle. Toiminnan arviointi, epävarmuuden vähentäminen ja suorituskyvyn parantaminen nähdään kovina tavoitteina, kun kommunikaation ja koordinaation parantaminen, oppiminen ja henkilökunnan motivointi määriteltiin pehmeiksi tavoitteiksi. Koville tavoitteille on tyypillistä mittauksen tiukka valvonta, tarkkuus ja ajantasaisuus. Kovien tavoitteiden mittausjärjestelmissä
mittarit ovat kapealla alueella, käytettävät mittarit määritellään kriittisten menestystekijöiden mukaan ja mittausväli on lyhyt. Kovien tavoitteiden mittausjärjestelmässä tavoitteet
asettaa ylempi johto ja tavoitteet perustuvat pääsääntöisesti menneisyyden suorituskykyyn. Kovien tavoitteiden mukainen mittausjärjestelmä sopii tuotekehitysyksikön ja projektitason mittauksiin. Pehmeiden tavoitteiden mittausjärjestelmässä on monia mittareita leveällä alueella. Mittareista suurin osa on subjektiivisia ja laadullisia. Mittausväli on pitempi
kuin kovissa mittareissa. Pehmeiden tavoitteiden mittausjärjestelmässä tavoitteet asettaa
yleensä yhteisö. Pehmeiden tavoitteiden mittausjärjestelmä sopii työntekijä tasolle.
4.1.3 Mittausjärjestelmä
Mittausjärjestelmän suunnittelua ei voi aloittaa ennen kuin tavoite on määritetty. Mittaamisen tavoite määrittää miten, mitä, milloin ja missä tietoa kerätään, analysoidaan ja raportoidaan. Chiesa et al. (2007, s.46) ja Driva et al. (2000, s.158) toteavat, että ei ole realistista odottaa, että tuotekehitykselle pystyisi kehittämään yhden yleisen mittariston, joka
41
sopisi kaikkiin tilanteisiin. Optimaalinen mittausjärjestelmä on aina tilannekohtainen ja sen
pitää olla selkeä ja mittareiden ylläpitoa pitää tukea. Pillai et al. (2005, s.168-169) toteavat, että mittaamisen tulee heijastaa sidosryhmien tarpeita ja odotuksia. Menneisyydessä
tehtyjä olettamuksia tulee arvioida jatkuvasti jälkikäteen saadun tiedon valossa ja saadulla
tiedolla tulee arvioida projektin menestystä. Jyoti et al. (2006, s.879) määrittelevät suorituskyvyn mittausjärjestelmälle neljä päätavoitetta, joita ovat mittareiden strategian mukaisuus, arviointi ja palkitseminen, operatiivinen valvonta sekä oppiminen ja parantaminen.
Kerssens-van Drongelen & Cook (1997 s.351-352) ovat määritelleet mittausjärjestelmälle
kriteereitä. Mittausjärjestelmällä mittaamalla tulee saada oikea tieto, oikeaan aikaan kerättynä luotettavasti ja taloudellisesti. Mittausjärjestelmän tulisi olla kokonaisvaltainen, jossa
kaikki suorituskykyyn vaikuttavat tekijät on otettu huomioon. Kerätyn tiedon tulee olla relevanttia ja se on pystyttävä vahvistamaan. Järjestelmän tulee olla hyväksytty mittauskohteena olevien ihmisten keskuudessa ja sen pitää olla kustannustehokas.
Tuotekehitystoiminta ja tuotekehitysosasto kannattaa erottaa toisistaan mittauksessa.
Tuotekehitystoiminnon tavoite on menestyksekkäästi aloittaa, koordinoida ja toimeenpanna prosessia yrityksen sisällä. Toimintojen suorituskykyä mitattaessa arvioidaan projektin
etenemistä ja mitataan tuotekehitysryhmän toimintaa. Tuotekehitysosaston tavoite on luoda, ylläpitää ja käyttää yrityksen tarvitsemaa teknologiaa. Osastoa mitattaessa tarvitaan
mittatietoa, jonka avulla osaston olemassa olo voidaan perustella. (Kerssens-Van Drongelen & Bilderbeek 1999, s.36-37)
Brown & Svenson (1988, s. 14) painottavat, että tehokas mittausjärjestelmä sisältää sekä
sisäisiä että ulkoisia mittareita. Järjestelmän tulisi keskittyä mittaamaan tuotoksia ja tuloksia, ei käyttäytymistä. Käyttäytymisen mittaus on tärkeää, jos mitataan yksittäistä henkilöä. Tuotekehitystä mitattaessa tulokset ja tuotokset indikoivat suorituskyvystä, jos mitataan sitä, mikä tuo arvoa yritykselle. Tehokas mittausjärjestelmä on yksinkertainen ja mittareiksi riittää 6-8 avainmittaria. Mittausjärjestelmän tulee olla objektiivinen, subjektiivisten
mittareiden määrä tulisi minimoida.
Kehiteltävän järjestelmän pitäisi olla sopiva eri prosessin vaiheiden kanssa. Projektin alkupäässä teknologiatekijät painottuvat enemmän ja alkupään toiminnoilla on vaikutusta
tuotekehityksen kustannuksiin ja loppupään toimintoihin. Projektin loppupäässä tuotantoja taloustekijät vaikuttavat enemmän. Prosessin eri vaiheita ei tulisi mitata yksittäisinä ja
erillään muista, koska näin toimimalla ei saada selville kokonaisvaltaista suorituskykyä.
Tuotekehityshenkilökunta tulisi ottaa mukaan luomaan järjestelmää, etenkin, jos tuloksia
42
käytetään palkitsemisessa ja ylennyksissä. Mittaamisen tulisi vastata mitattavan henkilön
roolia ja vastuita projektissa. Mittareiden tulisi mitata vain sitä, mihin mitattava henkilö
pystyy vaikuttamaan. (Cho & Lee 2005, s.511; Ojanen & Vuola 2006, s. 282; Pillai et al.
2002, s.165-166)
Mittausjärjestelmän peruselementit ovat mitattavat näkökulmat ja niihin suhteessa olevat
mittarit, mitattavan kohteen taso, mittausprosessi (Chiesa & Frattini 2007, s.188; Kerssens– van Drongelen & Cook 1997 s.349). Chiesa & al. (2008, s.4-5) toteavat, että määritelty tavoite ohjaa näkökulmien valintaa. Valituilla näkökulmilla määritetään, mitä mitataan.
Näkökulmien valintaan vaikuttaa tuotekehitystoiminnan epävarmuus, aineettomat tekijät,
projektin monimutkaisuus ja tuotekehitystoimintojen standardoinnin matala taso. Näkökulmia valittaessa tulisi ottaa huomioon panoksen määrä ja sen laatu, prosessi ja tuotos,
ts. mitä oikeasti saavutettiin.
Vuolle et al. (2009, s.25) toetavat, että johtajat tarvitsevat tietoa tuotekehitysprojektista eri
näkökulmista pystyäkseen arvioimaan uuden projektin potentiaalin ja päättyneen projektin
tuloksen. Saadakseen kokonaiskuvan tuotekehitysprojektista, pitää mitata myös projektin
aineettomia näkökulmia. Jyoti et al. (2006, s.879-880) suosittelevat, että tuotekehityksen
toimintaa pitäisi mitata neljästä Balanced scorecard (BSC) näkökulmasta, joita ovat asiakas, talous, organisaation oppiminen ja kasvu sekä sisäiset prosessit. BSC on toiminnanohjauksen suorituskykymittaristo, jonka Kaplan & Norton (1992, s. 71-72) ovat kehittäneet. Joyti et al. toteavat tutkimuksessaan, että yritykset mittaavat yleisimmin talouden
näkökulmaan, jossa mitataan pelkästään tuloksia, ei prosessia. Taloudellisia asioita voidaan mitata helposti, yksinkertaisesti ja kustannustehokkaasti. Taloudelliseen näkökulmaan keskittyminen tuo lyhyen aikavälin hyötyä pitkän aikavälin kustannuksella.
Garcia-Valderrama et al. (2008, s.243-244) toteavat taloudellisen näkökulman liittyvän
markkinaosuuden parantamiseen ja tuottavuuden kasvuun. Asiakasnäkökulmaan liittyy
niiden asiakassegmenttien tunnistaminen, joita yritys pyrkii palvelemaan. Asiakastyytyväisyys johtaa asiakasuskollisuuteen ja markkina-alueen levenemiseen, mikä taas johtaa
parempaan taloudelliseen tulokseen. Sisäisillä prosesseilla toteutetaan strategian toimeenpanoa. Prosesseihin liittyy sisäinen arvon luonti, johon liittyy etenkin tuotekehitysprosessi ja tuotekehityksen toiminnot. Yrityksen menestys riippuu sen kyvystä oppia, sopeutua ja kasvaa. Oppimisen ja kasvun avulla sisäiset prosessit paranevat.
Näkökulmia ei voi mitata, jollei jokaiselle näkökulmalle ole määritelty mittareita. Ojanen &
Vuola (2003, s.3) toteavat, että eri näkökulmien mittarit tulee perustua strategiasta johdet-
43
tuihin kriittisiin menestystekijöihin. Loch & Tapper (2002, s.186) puolestaan toteavat, että
suorituskyvyn mittareiden perimmäinen tarkoitus on kohdentaa huomio organisaation tavoitteisiin ja niiden priorisointiin. Työntekijöille kommunikoidut tavoitteet määrittävät millaisia toimintoja tehdä, ja mittareiden avulla toimintoja arvioidaan, valvotaan ja opitaan.
Suomala et al. (2012, s.27-28) muistuttavat, että mitattavia asioita määriteltäessä mittaamisen helppous ei saisi olla määräävä tekijä. Esim. tulevan rahavirran ennustaminen on
tärkeä mittari takaisin maksuaikaa mitattaessa, mutta sitä on vaikea mitata. Mittaamisessa
tulee ottaa huomioon myös aineettomat elementit. Kerssens-van Drongelen & Cook (1997
s.352-356) painottavat, että valituilla mittareilla tulee mitata haluttuja asioita ja niiden pitää
olla linjassa mittauksen strategian, tavoitteen ja ympäristön kanssa. Mittareiden pitää heijastaa tavoitetta ja mitattavan ihmisen vastuuta.
Mm. Driva et al. (2000, s.158) ja Lettice et al. (2005, s. 227) toteavat tutkimuksissaan, että
yleisimmin tuotekehityksen mittareina käytetään aikaa, kustannusta ja laatua. Bassani et
al. (2010, s.488) painottavat, että ajan, kustannusten ja laadun mittaamisella saadaan
lyhyen aikavälin suorituskykyä. Tuotekehityksen kokonaisvaltaisen suorituskyvyn arviointiin tarvitaan myös pitkän aikavälin mittareita, jotka liittyvät mm. oppimiseen, jatkuvaan
parantamiseen ja asiakastyytyväisyyteen. Kerssens- van Drongelen & Cook (1997 s. 352–
353) on kategorisoinut käytetyt mittarit kustannuksiin, laatuun, aikaan, innovatiivisuuteen
ja osuuteen tuloksesta. Laatu liittyy asiakkaaseen, aika ja tehokkuus sisäisiin prosesseihin, innovatiivisuus innovatiivisuuden ja oppimisen näkökulmaan, kustannukset ja osuus
tuloksesta ovat osa talouden näkökulmaa.
Bremser & Barsky (2004, s.235-236) toteavat, että talousnäkökulmassa mitataan tulojen
kasvua ja tuottavuutta. Jyoti et al. (2006 s.882) ovat määritelleet taloudellisiksi mittareiksi
mm. tuotekehityksen kustannustehokkuuden parannuksen, vaikutuksen tuotteiden myyntiin, sidosryhmien hyödyn maksimoinnin, pääoman saamisen ajoissa, pääoman kustannusten minimoinnin, sisäisen pääoman luomisen, pääoman järjestämisen ulkoisista lähteistä, tuoton parannuksen ja jatkuvan pääoman virran. Bigliardi & Dormio (2010, s.287)
toteavat, että taloudelliset mittarit mittaavat aineellisia asioita ja kertovat yrityksen varallisuudesta.
Bremser & Barsky (2004, s.235-236) toteavat, että oppimisen ja kasvun mittarit takaavat
motivoituneet tekijät. Oppimisen ja kasvun mittarit ovat pitkän aikavälin menestyksen perusta. Jyoti et al. (2006 s.882) määrittelevät innovaation ja oppimisen mittareiksi innovoinnin, yrityksen tuotteiden kilpailukyvyn parannuksen, yhteistyön lujittamisen, tiedon lisäämisen, oppimisen sekä valmistusprosessien parantamisen.
44
Stainer & Nixon (1997, s.490) toteavat, että sisäisten prosessien mittaamisella haetaan
mahdollisia ongelmia projektin etenemisessä ja tehdään parannuksia toimintaan. Prosessin mittareihin liittyy suunnittelun laatu, teknisten tavoitteiden selkeys, seurantatekniikoiden tehokkuus, katselmointien ajantasaisuus. Lisäksi sisäisiin prosesseihin liittyy, miten
hyvin tavoitteet saavutettiin, onko tuotteella odottamattomia ominaisuuksia, ovatko tavoitekustannukset ja aikataulu saavutettu. Näiltä mittareilla saadaan palautetta, miten parantaa tulevaisuudessa. Jyoti et al. (2006 s.882) määrittelevät sisäisten prosessien mittareiksi
mm. projektin aikataulun ja lyhyemmät läpimenoajat, toimittajaverkon kustannustehokkuuden parantamisen, toimittajaverkon vaatimusten tunnistamisen, resurssien tehokkaan
käytön, yhteistyön laajentamisen ja tehokkuuden
Bremser & Barsky (2004, s.235-236) toteavat, että asiakasnäkökulmasta tulee mitata operatiivista tasoa, asiakasläheisyyttä ja tuote-eroja, ts. miten tuote erottuu muista. Asiakaspalaute toimii tuotekehityksen menossa olevissa ja uusissa tuoteprojekteissa lähtötietona.
Jyoti et al. (2006 s.882) määrittelevät asiakasnäkökulman mittaamisen tavoitteiksi asiakastarpeiden täyttämisen, kysynnän luomisen, asiakasarvon luonnin, asiakastyytyväisyyden parantamisen sekä tuotteen laadun ja ominaispiirteiden parantumisen.
Brown & Svenson (1988, s.12) painottavat myös tuloksen mittaamista. Vain tuloksia mittaamalla saadaan selville tuotekehityksen vaikutus yrityksen arvoon.
Stainer & Nixon
(1997, s.490) määrittelevät tuloksiksi kustannusten alenemisen, myynnin lisäyksen, tuottavuuden kasvun, ylläpidon, organisaation pitkän aikavälin markkinoinnin ja taloustavoitteet. Tuotekehityksen tuloksia voidaan mitata eri mittareilla. Ulrich & Eppinger (2003, s.23) toteavat, että tuotteen laatu vaikuttaa markkinaosuuteen ja siihen, miten paljon asiakas
on halukas maksamaan tuotteesta. Tuotteen kustannukset määrittelevät, miten yritys saa
voittoa tietyllä myyntimäärällä ja myyntihinnalla. Tuotekehitysajalla mitataan, miten hyvin
yritys reagoi asiakastarpeisiin sekä miten nopeasti yritys alkaa saada tuottoa investoinnista. Kehityskustannukset ovat merkittävä osa investoinnista, jolla haetaan tuottoa. Tuotekehityksen kyvykkyydellä mitataan yrityksen kykyä kehittää tuotteita tehokkaammin ja
taloudellisemmin. Cooper & Kleinschmidt (2004, s. 32-33) ovat lisänneet tuotekehityksen
suorituskyvyn mittareiksi edellä mainittujen lisäksi uusien tuotteiden osuuden tuloista.
Mittareista tulee saada tietoa projektin suunnasta, aikataulusta, budjetista ja edistymisestä. Operatiivisen mittareiden tieto pitää olla saatavilla heti projektin lopussa. Oppimista ei
tapahdu, jos palaute tulee liian myöhään. Strategiasuuntautuneisuuden varmistamiseksi
mittareiden pitää kommunikoida alemmille tasoille yrityksen tavoitteista. Henkilökohtaisen
45
arvioinnin ja palkitsemisen osalta tulee mitata työn laatua ja tarkkuutta. (Loch & Tapper
2002, s.188)
Pappas (1985, s. 15-17) suosittelee, että tuotekehitysympäristössä tulisi käyttää sekä
määrällisiä että laadullisia mittareita. Pelkästään määrällisillä mittareilla ei voida kokonaisvaltaisesti mitata epävarmaa ja aineetonta tuotosta. Arviointitekniikkaa valittaessa tuotekehitykselle tulee muistaa, että projektit eivät ole samanlaisia, tulosten ja toimintojen välillä on aikaeroa ja tuotekehityksessä tehtävää työtä on vaikea määritellä määrällisesti, koska työ ei ole samanlaisena toistuvaa. Ojanen et al. (2002, s.123-124) toteavat, että tuotekehityksen prosessin jokaista vaihetta tulee mitata ja jokaiselle vaiheelle tulisi olla määriteltynä johtavia ja takautuvia mittareita. Johtavat mittarit antavat tietoa ja signaaleja projektin menestyksestä. Takautuvat mittarit, joilla mitataan tuotosta, paljastavat projektin
laadun ja kokonaissuorituskyvyn.
Chiesa & Frattini (2007a, s.285-286) toteavat, että mittausjärjestelmän rakenteessa tulee
tunnistaa mitattavat kohteet, joiden suorituskykyä monitoroidaan ja joista mittarit ovat vastuussa. Tuotekehityksen suorituskykyä voidaan mitata monella eri tasolla. Kerssens- van
Drongelen & Cook (1999, s.40) ovat määritelleet päämittaustasoiksi yritystason, tuotekehitysyksikkötason, tuotekehitysryhmätason ja yksittäisen työntekijän. Godener & Södequist
(2004, s.200) ovat lisänneet mittaustasoksi projektitason. Lisäksi Ojanen & Vuola (2006,
s.282) määrittelevät liiketoimintayksikön mahdolliseksi mittauksen tasoksi.
Eri mittaustasoilla mittaamisen tavoitteet vaihtelevat. Yritys- ja yksikkötasolla mittaamisella
tavoitellaan tietoa resurssien allokointiin, päätösten tekoon ja kehitystoimenpiteiden tueksi. Ryhmätasolla mittaamisella tavoitellaan edistymisen ohjausta, tietoa päätöksenteon ja
jatkuvan parantamisen tueksi. Työntekijätasolla tavoitellaan tietoa päätöksenteon, palkitsemisen ja kehitystoimien tueksi. Projektitasolla mittaamisella voidaan diagnosoida toimintaa ja tunnistaa pullonkaulat, jotka vaikuttavat projektin tehokkuuteen (Kerssen- van
Drongelen & Bilderbeek 1999, s. 41; Ojanen et al. 2002, s.123-124)
Mittausjärjestelmän osa on mittausprosessi, joka koostuu mittausvälistä ja normistosta.
Chiesa et al. (2008, s.4) toteavat, että mittausväliä ei voi standardoida joka tilanteeseen
sopivaksi. Mittausväli pitää johtaa tavoitteesta, näkökulmista, mittareista ja mittauskohteesta. Kerssens-van Drongelen & Cook (1997 s.352) määrittelevät mittaustiheydelle kaksi päävaihtoehtoa, joita ovat mittaus projektien katselmointipisteissä ja säännöllisin väliajoin. Cooper (2006, s.21) ja Kerssens-van Drongelen & Cook (1997 s.356) eivät suosit-
46
tele tuotekehitystoiminnan jatkuvaa mittaamista. Mittaamisen tulisi tapahtua avainkohdissa, kuten esim. katselmointipisteissä ja lanseerauksen jälkeen.
Mittauksessa käytettävä normisto on määritelmä, millainen toiminnan tai lopputuloksen
tulisi olla ja johon tuotekehityksen tulosta verrataan. Normiston määrittäminen on haastavaa, koska tuotekehityksessä epävarmuuksien taso on korkea. Tuotekehitystoimintaa
arvioidessa tulee käyttää sekä sisäisiä että ulkoisia normeja. Sisäiset normistot ovat yleisiä ja ne ovat joko yrityksen kilpailustrategiaan perustuvia tai ne perustuvat aikaisempaan
tuotekehityksen suorituskykyyn. Ulkoisten normiston käyttö on harvinaisempaa, koska
yrityksillä ei ole aina tarvittavaa kilpailijatietoa saatavilla. Yleisin ulkoinen normisto on
benchmarking. (Chiesa et al. 2009, s.29-30; Kerssens- van Drongelen & Cook 1997,
s.354)
Benchmarking on systemaattista suorituskyvyn vertailua valittuihin kohteisiin ja sen tavoite
on parantaa suorituskykyä. Kahn et al. (2006, s.108) määrittelevät, että benchmarking on
tapa toimia, jossa tunnistetaan erot oman toiminnan ja kilpailijan välillä. Siinä tutkitaan,
miten johtavien tuotteiden tekijät tekevät asioita. Vertailulla pyritään motivoimaan henkilökuntaa tavoitteiden saavuttamiseen ja strategian toteuttamiseen
4.1.4 Mittausjärjestelmän implementointi
Järjestelmän kehittämisen jälkeen mittausjärjestelmä implementoidaan käytäntöön. Implementoinnissa tulee ottaa huomioon suorituskyvyn piirteiden selkeys, eli piirteet ymmärretään käyttövaiheessa samalla tavalla kuin suunnittelu vaiheessa. Uusi järjestelmä tulisi
ottaa käyttöön asteittain. Uuden järjestelmän tulisi olla yksinkertainen ja sen tulisi keskittyä
datan keräämiseen. Mittausjärjestelmän käyttö vaatii ylemmän johdon tukea, johtamiskulttuuria, muutoksen johtamista, valvontaa ja jatkuvaa parantamista. (Chiesa et al. 2007,
s.48-49)
Bassani et al.( 2010, s.501-502) sekä Ojanen & Vuola (2003, s.6) painottavat kommunikaation tärkeyttä. Suorituskyvyn mittaamisen käyttöönotto tulee kommunikointi henkilökunnalle selkeästi. Kommunikointi auttaa henkilökuntaa ymmärtämään, miksi mitataan.
Ymmärrys lisää mittauksen luotettavuutta, jolloin mitataan asioita oikein, tiedon keruu tapahtuu luotettavasti ja tuloksia tulkitaan oikein.
Bremser & Barsky (2004, s.230-231) toteavat, että toimintaan integroitu suorituskyvyn
mittausjärjestelmä laittaa tuotekehityksen, valmistuksen, markkinoinnin ja muiden toimintojen toiminnot linjaan toistensa ja strategian kanssa mittareita käyttämällä. Mittareilla mi-
47
tataan suorituskyvyn tekijöitä, kuten tulevaisuuden indikaattoreita ja tuotosta eli menneisyyden mittareita, joiden avulla opitaan. Bourne et al. (2000, s. 757-758) puolestaan toteavat, että implementointi vaiheessa tietoa tulisi kerätä säännöllisesti. Käyttövaihe mittaa
strategian menestymistä ja mittauksesta saatu tieto haastaa oletuksia ja strategiaa. Viimeisen vaiheen tuloksilla katselmoidaan tavoitteita, kehitetään mittareita ja katselmoidaan
mittareita. Mittausjärjestelmää tulee kehittää ja katselmoida monella eri tasolla, kun tilanteet muuttuvat.
4.2 Suorituskyvyn mittaamisen haasteet
Tuotekehityksen suorituskyvyn mittaaminen on haasteellista. Kerssens– van Drongelen et
al. (2000, s.119–120) ovat määritelleet tuotekehityksen suorituskyvyn mittaamisen haasteiksi seuraavia asioita:
-
miten erottaa tuotekehityksen vaikutus koko yrityksen suorituskyvystä?
-
miten mitata tuotekehityksen tuotoksia määrällisesti?
-
miten kohdistaa tuotekehityksen lähtötiedot välittömiin tuotoksiin ja tuloksiin?
-
miten huomioida tuotekehityksen toimintojen ja tulosten välinen aikaviive?
-
miten valita sopiva mittaristo?
-
miten saada tuotekehitys hyväksymään mittaaminen?
-
miten verrata eri projektien tuloksia toisiinsa?
Mittaamisen haasteet ovat seurausta tuotekehitystoiminnan luonteesta. Tuotekehitystoiminnassa tyypillistä on epävarmuuksien ja riskien korkea aste, lopullinen tuotos on projektin alussa epäselvä eikä sitä voi selkeästi määritellä etukäteen ja lisäksi lopullinen tulos
voidaan arvioida vasta tietyn ajan kuluttua. Lisäksi aineettomien näkökulmien merkitys on
suuri tuotekehitystoiminnassa ja niiden mittaaminen on hankalaa. Projektien ainutlaatuisuus tekee mittausnormiston määrittelyn haastavaksi. Jokainen tuotekehitysprojekti on
ainutlaatuinen, koska eri projektit koostuvat erilaisista ongelmista ja epävarmuuksista.
(Bassani et al. 2010, s.482-483; Chiesa & Masella 1996, s.49)
Tuotekehityksen suorituskyvyn mittaaminen epäonnistuu monesta eri syystä. Usein mittaamisessa painotetaan liikaa sisäisiä mittareita, joilla mitataan laatua ja toimintaa aikataulun ja budjetin näkökulmista, eikä mitata arvoa. Seurauksena voi olla hyvät mittaustulokset, vaikka tulokset eivät lisää yrityksen arvoa, ts. tuote ei menesty markkinoilla. Lisäksi
usein keskitytään mittaamaan käyttäytymistä tulosten sijaan. Käyttäytymistä mittaamalla
voidaan tehdä oikeita asioita ilman, että tuotetaan arvoa. Lisäksi liian monimutkainen mit-
48
tausjärjestelmä voi aiheuttaa ongelmia. Mittaamista pitää johtaa, ja usein kukaan ei sitä
tee. Myös mittausjärjestelmästä voi tulla liikaa informaatiota. (Brown & Svenson 1988, s.
12-13; Ojanen & Vuola 2006, s.281-282; Stainer & Nixon 1997, s. 490)
Stainer & Nixon (1997, s.487) toteavat, että tuotekehityksen ominaispiirteitä on pitkäkestoinen vaikutus ja se tuo usein subjektiivista ja aineetonta arvoa organisaatiolle. Tämän
vuoksi suorituskyvyn mittaaminen perinteisillä tavoilla ei ole järkevää. Thomke & Reinertsen (2012, s.85) suosittelevat, että tuotekehitystä ei arvioitaisi samoilla kriteereillä kuin
valmistusta. Mikäli tuotekehitystä mitataan samoilla kriteereillä, seuraa siitä tuotekehityksessä suunnittelun ja toimeenpanon huonoa laatua. Valmistusprosesseissa tehtävät toistuivat, toiminnot ovat melko ennustettavissa ja tuotettavat tuotteet voivat olla vain yhdessä
paikassa kerrallaan. Tuotekehityksessä tehtävät ovat ainutlaatuisia, projektivaatimukset
muuttavat jatkuvasti ja tuotos on informaatiota, jota olla käytössä monessa eri paikassa
samaan aikaan.
Mittaamisen haasteista huolimatta tuotekehityksen tulee pystyä todistamaan, että se toimii
oikeiden asioiden parissa oikealla tavalla. Tuotekehityksen suorituskyvyn mittaamisen
onnistumista on mahdollista parantaa. Mittaamisen hyväksyminen on helpompaa, jos on
ollut mukana suunnittelemassa järjestelmää, eli työntekijät tulisi ottaa mukaan järjestelmän suunnitteluun. Ennen mittausjärjestelmän suunnittelua, kaksi kriittistä asiaa tulee olla
määritettynä: mikä on mittaamisen tarkoitus ja mitkä ovat mahdollisuudet mitata. Lisäksi
mittausnormisto tulee määrittää. Normiston määrittelemiseen on erilaisia lähestymistapoja: tavoitteet määritellään menneiden saavutusten mukaan, tavoitteet perustuvat strategiaan tai ulkoinen normiston, esim. benchmarking. Kun em. asiat on määritelty, kehitetään
mittausjärjestelmä ja implementoidaan se osaksi toimintaa. Tuotekehityksen kriteerien
määrittelyssä tulee parantaa tiedon saantia rakentamalla tietojärjestelmä. Toiminnan arvioinnissa tulee mitata niitä asioita, joihin mitattava ihminen voi vaikuttaa. (Kerssens-van
Drongelen & Cook 1997, s.348-350)
4.3 Suorituskyvyn johtaminen
Jyoti et al. (2006, s.879) toteavat, että jokaisen tuotekehitysorganisaation tulee panostaa
jatkuvaan parantamiseen. Jatkuva parantaminen vaatii suorituskyvyn arviointia. Suorituskyvyn arvioinnilla tarkkaillaan, missä ollaan ja arvioinnilla pitää saada palautetta, jonka
avulla tunnistaa, missä pitää parantaa. Park (2007, s.111) toteaa, että mittaamisella saadaan tietoa tuotekehityksen toiminnasta, jonka pohjalta voi tehdä päätöksiä toiminnan
kehittämiseksi.
49
Lönnqvist et al. (2006, s.147-148) painottavat, että mittaaminen on turhaa, jos tulosten
pohjalta ei tehdä päätöksiä toiminnan parantamiseksi. Mittareiden avulla johto ohjaa henkilöstöä tekemään haluttuja asioita, valvoo toimintaa ja palkitsee henkilöstöä. Mittaamisella pyritään arvioimaan toiminnan tasoa ja mittaamisen tulokset toimivat varoituksena, jos
jokin on vialla. Mittaamisen avulla voidaan ennustaa tulevia tuloksia ja tilanteita sekä viestiä yrityksen tavoitteista henkilöstölle. Mittaaminen voi aiheuttaa positiivista kilpailua ja sillä
pyritään motivoimaan henkilökuntaan. Mittaaminen on henkilöstön opetusväline ja tuloksista pyritään oppimaan. Mittaamisella tuotetaan informaatiota päätöksenteon tueksi
Kerssens- van Drongelen & Cook (1999 s. 44) toteavat, että mittaustuloksia käytetään
projektiryhmän toiminnan korjaamiseen sekä strategian käyttöön oton ja parantamisen
tueksi. Godener & Söderqvist (2004, s.194-197) puolestaan toteavat, että yritykset käyttävät mittauksen tuloksia tavoitteiden kommunikoinnissa, mittaamisessa löydettyjen ongelmien korjaavien toimenpiteiden määrittämisessä, resurssien allokoinnissa, ylennysten,
palkankorotusten yms. päätösten pohjana sekä oppimiseen. Heidän mukaan mittaaminen
vaikuttaa suorituskykyyn parantavasti, se kohottaa henkilökunnan motivaatiota sekä edistää tuotekehityksen ja johdon välistä kommunikaatiota.
Kaplan & Norton (1996, s.20-22) määrittelevät mittaamisen tulosten käytölle monia käyttökohteita. Tulosten avulla alempi johto ja henkilökunta voivat korjata toimintaansa. Suorituskyvyn mittaamisella tulisi kyseenalaistaa oletukset ja testata niiden toimivuus käytännössä, eli toimiiko strategia käytännössä ja onko käytössä oikea strategia. Strategian arviointi, tiedon keruu, analysointi ja kehittäminen ovat ylemmän johdon vastuulla. Johto voi
kehittää toimintaan palautejärjestelmän, jolla testata, vahvistaa ja muokata strategiaa.
Brudan (2010, s.111-113) toteaa, että suorituskyvyn johtaminen sisältää aliprosesseja,
kuten esim. strategian määrittely, strategian käyttöönotto, koulutus ja mittaus. Mittauksen
tuloksia tunnistetaan, analysoidaan, jäljitetään ja tuloksia kommunikoidaan osallisille. Suorituskyvyn johtaminen keskittyy tulosten pohjalta tehtäviin toimenpiteisiin ja varmistamaan,
että tavoitteet saavutetaan. Suorituskyvyn johtaminen on jaoteltu kolmeen eri tasoon: strategiseen, operatiiviseen ja henkilökohtaiseen suorituskykyyn. Henkilökohtainen taso on
perinteisin ja eniten käytetty taso, jolla suorituskykyä on mitattu. Operatiivisen tason suorituskyky on yhteydessä operatiiviseen johtoon ja se keskittyy ryhmän tai osaston tavoitteiden saavuttamiseen. Strategiatasolla keskitytään organisaation tavoitteiden saavuttamiseen. Tälle tasolle kuuluu strategian luominen ja sen käyttöönotto. Strategiatason suorituskyvyn johtaminen liittyy läheisesti strategian johtamiseen.
50
Kerssens-van Drongelen & Bilderbeek (1999, s.36) määrittelevät suorituskyvyn johtamisen informaation hankkimiseksi, sen analysoinniksi ja tulkitsemiseksi. Kerättyä ja analysoitua tietoa käytetään päätettäessä, mitä tehdä ja miten. Suorituskyvyn arvioinnissa on
hyvä käsitellä sekä tulevaisuuteen vaikuttavia tekijöitä että menneisyyttä. Tulevaisuuden
suorituskykyä arvioitaessa tulee kehittää tarvittavat olosuhteet suorituskyvyn saavuttamiselle. Menetelmiä ovat esim. organisaation auditoinnit, benchmarking ja parhaat käytännöt. Suorituskyvyn johtamisessa tulee arvioida myös mennyttä. Menneisyyden analysoinnilla voi päätellä, miten parantaa suoritusta tulevaisuudessa.
Tuotekehitystoimintaa mitataan mittareilla ja saavutettua verrataan suunniteltuun suorituskykyyn. Tavoitteiden saavuttaminen kertoo siitä, miten suunnitelmat on toteutunut. Se
kertoo työntekijän vahvuuksista ja kehitysalueista. Suorituskyvyn johtamisessa johtaja on
vastuussa siitä, että työntekijän tavoitteet ovat linjassa yrityksen tavoitteiden kanssa. Päätöksenteon tulee pohjautua mittareista saatuihin tietoihin. Valituilla mittareilla pyritään vaikuttaa ihmisiin ja heidän käyttäytymiseen suhteessa tavoitteisiin ja suunnitelmiin. (Kerssens-van Drongelen & Bilderbeek 1999, s.36; Aguinis et al. 2011, s.505)
Aguinis et al. (2011, s. 505) määrittelevät suorituskyvyn johtamisen on jatkuvaksi toiminnaksi, johon kuuluu osana tavoitteiden asettaminen, suorituskyvyn seuranta, jatkuva oppiminen ja parantaminen sekä palaute. Suorituskyvyn johtamisen ”omistaa” järjestelmään
osallistuvat henkilöt ja se hyödyttää kaikkia osallisia. Suorituskyvyn johtamisen hyötyjä
ovat se, että suorituskyvyn järjestelmästä saadaan palautetta työntekijöille ja näin he saavat enemmän ymmärrystä vahvuuksistaan ja heikkouksistaan sekä ymmärtävät kehityssuunnitelmia. Suorituskyvynjohtamisjärjestelmä auttaa johtajia kehittämään alaisten kyvykkyyksiä, joka on seurausta jatkuvasta tavoitteiden asettamisesta ja kehitystoimista.
Suorituskyvyn johtamisjärjestelmä myös auttaa organisaatiota tiedostamaan tarvittavia
muutoksia.
51
5. TUTKIMUKSEN TOTEUTUS
Tutkimuksen kohteena on yksi pienikokoinen tuotekehitysorganisaatio, joka toimii elektromekaanisten tuotteiden valmistuksen piirissä. Luvussa 5.1 käydään läpi kohdeorganisaatiota tarkemmin. Luvussa 5.2 käydään läpi tutkimuksen rakenne, toteutus ja miten tuloksia käsitellään.
5.1 Kohdeorganisaatio
Tutkimuksen kohteena oleva tuotekehitysorganisaatio toimii yrityksessä, joka koostuu
monesta liiketoimintayksiköstä. Yritys on osa kansainvälistä konsernia, jolla on toimintaa
ympäri maailmaa. Liiketoimintayksiköillä on omat tuotekehitysosastonsa ja liiketoimintayksiköt huolehtivat, että heidän tuotekehitystoimintansa on linjassa yrityksen johdon asettamien tavoitteiden kanssa. Tutkimuksen kohteena oleva organisaation on yhden liiketoimintayksikön tuotekehitysorganisaatio, joka toimii elektromekaanisten tuotteiden valmistuksen parissa.
Kohdeorganisaatiossa on erilaisia tuotekehitysprojekteja. Osa projekteista on konsernituotteita, joiden tuotesuunnittelu tehdään konsernin muussa yksiköissä. Kohdeorganisaation tehtävänä on muokata tuotteista pohjoisen leveysasteiden olosuhteisiin sopivia. Toinen tapa kehittää tuotteita on tuotekehitys, jossa konserni tuottaa perusteknologian ja
kohdeorganisaatio kehittää perusteknologiaan pohjautuvat tuotteet. Lisäksi on oma tuotesuunnittelu, jossa tuotekehitys alkaa ideoinnista ja päättyy tuotteen markkinoille saattamiseen.
Kohdeorganisaation tuotekehitystoiminta voidaan jakaa kolmeen luokkaan. Suuret tuotekehitysprojektit, joita ovat mm. uuden tuoteperheen peruskehitys. Suurissa tuotekehitysprojekteissa noudatetaan organisaation tuotekehitysprosessia alusta loppuun määritelmien mukaisesti. Pienet tuotekehitysprojektit ovat mm. olemassa olevan perusteknologian
sovittamista uuteen ympäristöön. Näissä projekteissa katselmoidaan vähintään tuotteen
lähtötiedot sekä tulokset. Lisäksi tuotekehityksellä on ylläpitotehtäviä, joihin kuuluu osana
tuotemuutokset ja tekniset katselmukset. Tuotemuutoksissa valmistusdokumenttien muutokset hyväksytään normaalin toimintatavan mukaisesti, mutta muuten ei tuotekehitysprosessia käytetä.
Tuotekehitysryhmä on pienikokoinen, se koostuu 8 työntekijästä ja tuotekehityspäälliköstä. Ryhmässä on kaksi mekaniikkasuunnittelijaa, neljä elektroniikkasuunnittelijaa ja kaksi
52
testauspuolen asiantuntijaa. Tuotekehitysryhmä tekee yhteistyötä muiden toimintojen,
kuten tuotanto, tuotehallinta, hankinta sekä ohjelmistokehitys kanssa. Lisäksi tuotekehitysryhmällä on yhteistyötä konsernin muiden yksiköiden kanssa.
Kohdeorganisaatiossa tuotekehitystarpeet syntyvät markkinoiden muuttumisesta. Organisaatio voi itse vaikuttaa markkinoihin kehittämällä uusia innovatiivisia tuotteita, joita markkinoilla ei vielä ole. Tuotteiden tavoitteet, perustuvat asiakasvaatimuksiin, jotka pohjautuvat käyttäjien tarpeisiin. Myös valmistusmenetelmien ja –prosessien kehittyminen luo
myös omia vaatimuksia tuotekehitykselle. Tuotekehitysprosessin tavoite on säilyttää mielikuva luotettavasta tuotteesta, joka saavutetaan hyvällä laadulla ja toimintavarmuudella
sekä teknisesti poikkeavilla ratkaisuilla. Tuotteilla on yhtenäinen muotokieli ja tuotteista ei
saa syntyä keskinkertaista mielikuvaa. Uusilla ja innovatiivisilla tuotteilla pyritään antamaan käyttäjälleen tunne voittajan valinnasta ja nämä tuotteet ovat strategisesti tärkeitä.
5.1.1 Kohdeorganisaation tuotekehitysprosessi
Kohdeorganisaatiolla on dokumentoitu tuotekehitysprosessi. Tuotekehitysprosessin läpivienti noudattaa kuusi vaiheista prosessimallia, jonka vaiheet on nimetty konsepti-, tuotekuvaus-, suunnittelu-, tuotesuunnittelu-, tuotannon ylösajo- ja lanseerausvaiheiksi. Pienimuotoisissa tuotekehitysprojekteissa ja tuotemuutoksissa ei välttämättä käytetä kuusivaiheista prosessia, vaan projekti alkaa lähtötietojen katselmoinnilla ja prosessi jatkuu tuotesuunnitteluvaiheesta. Kohdeorganisaation tuotekehitysprosessi on kuvattu kuvassa 9.
Kuva 9. Kohdeorganisaation tuotekehitysprosessimalli
Kohdeorganisaation prosessi alkaa konseptinvaiheella. Ensimmäisessä vaiheessa luodaan tuoteidean pohjalta alustava liiketoimintamalli, projektiehdotus, riski ja resurssitarkastelu sekä haetaan projektinumero tiedonhallintajärjestelmästä. Tämän vaiheen sisältämät toiminnot ovat projektinumeron hakua lukuun ottamatta tuotehallinnan vastuulla.
Projektinumeron haku on tuotekehityksen vastuulla.
Liiketoimintamalli sisältää alustavat markkinavaatimukset ja tuoteidean kuvauksen. Liiketoimintamallissa varmistetaan idean strategian mukaisuus ja sen soveltuvuus konsernin
politiikkaan sekä arvioidaan tarvittava tuotekehitysprojektipanostus. Taloudelliselta kannalta arvioidaan tuotteen valmistuskustannukset, tuleva myyntihinta ja myyntivolyymi. Li-
53
säksi tunnistetaan, mistä ja miten haetaan tarkempaa markkinatietoa tulevien vaiheiden
aikana ja suunnitellaan alustavasti jakelukanavat. Tuoteideaa verrataan kilpailijoihin ja
määritellään alustava kohdeasiakas. Alustavassa liiketoimintamallissa tuoteideaa verrataan konsernin tuotteisiin ja varmistetaan, että ei kopioida olemassa olevaa tuotetta.
Projektiehdotuksessa määritellään tuotteelle alustavasti toiminnalliset vaatimukset, jotka
priorisoidaan. Lisäksi tunnistetaan ne standardit ja viranomaisvaatimukset, joita tuotteen
tulee täyttää. Tuoteidean muotoiluntarve arvioidaan. Projektille luodaan alustava aikataulu, määritellään alustavasti projektiorganisaatio sekä arvioidaan projektin vaikeusaste.
Lisäksi arvioidaan rahoituksen saantimahdollisuus.
Konseptivaiheessa tehdään riski- ja resurssitarkastelu seuraavaa vaihetta varten. Tarkastelu perustuu alustavan liiketoimintamallin ja projektiehdotuksen tietoihin ja arvioihin. Tarkastelussa arvioidaan riskit sekä projektin resurssivaatimukset. Resurssien saatavuus
selvitetään ja osaaminen arvioidaan. Lisäksi tarkastetaan opit aikaisempien vastaavien
tuotteiden osalta.
Konseptivaiheen jälkeen prosessi jatkuu tuotekuvausvaiheella. Vaiheen tuloksia ovat tuotekuvaus ja riski- ja resurssitarkastelun seuraavaa vaihetta varten. Tuotehallinta vastaa
tuotekuvauksen luomisesta ja sen sisällöstä. Tuotekehitys osallistuu vaiheeseen tekemällä riski- ja resurssitarkastelun tuotekuvauksen pohjalta.
Tuotekuvaus sisältää tarkennetun liiketoimintamallin. Liiketoimintamallista tulee käydä
ilmi, mitkä ovat tuotteen markkinavaatimukset, myyntivolyymi- ja hintatavoite sekä tuotteen valmistuskustannustavoite. Lisäksi liiketoimintamallin tulee sisältää tuotteen myyntiargumentit ja markkinatutkimusten tulokset. Myös tuotteen vertailu muihin konsernin tuotteisiin nähden tulee sisällyttää liiketoimintamalliin. Tuotekuvauksen markkinavaatimuksista
tulee käydä ilmi tuotteen käyttöympäristö, jossa tuotetta käytetään. Tuotteelle asetetut
ulkonäkövaatimukset, kuten pintakäsittelyt, värit, koko ja paino, määritellään liiketoimintamalliin. Tuotteen jakelukanavat ja loppukäyttäjä täytyy tunnistaa tuotekuvauksesta. Tuotekuvauksen tulee sisältää myös tuotteen markkina- ja kilpailija-analyysit.
Tuotekuvauksen tulee sisältää myös tuotteen vaatimukset. Tuotevaatimuksista pitää selvitä, miten tuotteen tulee toimia. Mikäli tuotteessa on tarvetta muotoiluun, tulee tuotekuvauksen sisältää eri muotoilukonseptien arvioinnin ja valinnan. Tuotevaatimuksissa arvioidaan tuotteen vaikutus tuotemallistoon, eli minkä tuotteen uusi tuote korvaa ja mikä on
tuotteen vaikutus konsernitasolla. Lisäksi tehdään patenttitarkastelu ja määritetään, mitkä
54
standardit tuotteen tulee täyttää ja mitkä viranomaisvaatimukset tulee ottaa huomioon
tuotetta suunniteltaessa. Tuotteen erityiset suorituskykyvaatimukset tulee olla määritettynä ja lisäksi tehdään kompromissitarkastelu tuotteen vaatimusten osalta. Viimeinen vaatimus tuotekuvaukselle on alihankintamahdollisuuksien tarkastelu. Tarkastelussa arvioidaan, valmistetaanko tuote itse vai ostetaanko se valmiina.
Tuotekehityksen vastuualue tuotekuvausvaiheessa on tehdä riski- ja resurssitarkastelu
tuotekuvauksen pohjalta. Tarkastelussa tehdään riskianalyysi ja arvioidaan tuotteen resurssivaatimukset sekä resurssien saatavuus. Lisäksi tarkastelussa arvioidaan, mitä
osaamista tuotteen kehittäminen vaatii. Tuotekehitys vastaa myös projektisuunnitelmaluonnoksen tekemisestä, jossa arvioidaan aikataulua, projektikustannuksia, resursseja,
tuotteen valmistuskustannuksia yms.
Tuotekuvausvaiheen jälkeen kohdeorganisaation tuotekehitysprosessi jatkuu suunnitelmavaiheella, jossa tutkitaan tuotteen toteutettavuutta. Suunnitelmavaiheen vaatimuksia
ovat tuotteen tekninen spesifikaatio, alustavat testaus–, lanseeraus- ja valmistussuunnitelmat, projektisuunnitelma, vertaistarkastelu ja riski- ja resurssitarkastelu seuraavaa vaihetta varten. Tässä vaiheessa tuotekehityksen vastuut lisääntyvät. Tuotekehitys vastaa
tuotteen teknisen spesifikaation, projektisuunnitelman, vertaistarkastelun sekä riski- ja
resurssitarkastelun tekemisestä. Valmistuksen vastuulla on tehdä alusta valmistussuunnitelma ja tuotehallinta on vastuussa alustavan testaus- ja lanseeraussuunnitelman tekemisestä.
Teknisessä spesifikaatiossa luodaan tuotteen toiminta- ja konstruktiokuvaus. Suunnittelun
lähtötiedot, tuotteen suorituskykyvaatimukset ja laatuvaatimukset määritellään. Lisäksi
arvioidaan tuotteen vaikutukset ohjelmistotuotteisiin. Teknisestä spesifikaatiosta tulee
käydä ilmi ne viranomaisvaatimukset ja standardit, joita tuotteen tulee täyttää. Tuotteen
muotoilu määritetään tekniseen spesifikaatioon.
Projektisuunnitelmassa luodaan tuoteprojektille aikataulu, määritellään projektikustannukset ja tunnistetaan resurssit tuoteprojektiin. Lisäksi projektisuunnitelmaan määritetään
tavoitteet tuotteen myyntivolyymista, myyntihinnasta ja tuotteen valmistuskustannuksista.
Projektisuunnitelmaan kuuluu osana projektin kannattavuusanalyysi. Tuotekehityksen
tulee myös huolehtia vertaistarkastelun teettämisestä. Tarkastelussa tuotekuvaus, tekninen spesifikaatio, projektisuunnitelma ja riski- ja resurssitarkastelut lähetetään projektiin
kuulumattoman ulkopuolisen henkilön tarkastettavaksi. Tarkastaja on yleensä toinen pro-
55
jektipäällikkö tai tuotekehityspäällikkö ja tarkastajia voi olla enemmän kuin yksi. Tarkastajien kommenttien pohjalta suunnitelmia muokataan tarvittaessa.
Riski- ja resurssitarkastelussa tehdään teknisen spesifikaation ja projektisuunnitelman
pohjalta riskianalyysi, jossa pyritään tunnistamaan toteutukseen liittyviä riskejä ja epävarmuuksia. Lisäksi tarkennetaan resurssivaatimuksia, varmistetaan resurssien saatavuus ja
osaaminen. Tarkastelussa selvitetään aiempien projektien opit ja tutkitaan eri toteuttamisvaihtoehtoja projektille.
Tuotehallinta vastaa alustavien testaus- ja lanseeraussuunnitelmien tekemisestä. Testaussuunnitelmassa tulee olla määritettynä testit alfa ja beta vaiheen prototyypeille sekä
viralliset testit, jotka suorittaa ulkopuolinen testaaja. Valmistus luo alustavan valmistussuunnitelman tuotekuvauksen ja teknisen spesifikaation pohjalta. Valmistussuunnitelman
tulee sisältää alustavat valmistus- ja kapasiteettisuunnitelmat, ostosuunnitelmat ja mahdolliset investoinnit. Valmistussuunnitelmaan kuuluu osana tuotteen tilaus-toimitus prosessiin soveltuvuuden arviointi.
Suunnitelmavaiheen jälkeen prosessi siirtyy tuotesuunnitteluvaiheeseen. Tuotesuunnitteluvaiheessa kehitetään ideasta tuote. Vaiheen lopputulos on määrityksiä vastaava tuote
myyntiin. Tuotesuunnitteluvaiheeseen kuuluu tuote, IP asiat, testiraportti, valmistussuunnitelma, asiakasdokumentaation tekeminen ulkoisiin testeihin, investointihakemus, riskianalyysi ja projektiraportti. Tässä vaiheessa tuotekehitys vastaa tuotteesta, IP asioita, riskianalyysistä ja projektiraportin tekemisestä. Valmistuksen vastuulla on valmistussuunnitelman tekeminen sekä investointihakemuksesta ja tuotehallinta vastaa testiraportista ja
asiakasdokumentaation valmistumisesta.
Tuotesuunnitteluvaiheessa tuotteen osalta varmistetaan tuotevaatimukset. Tuotteelle luodaan osaluettelo komponenteista, joista tuote koostuu. Tuotteelle määritetään valmistuskustannus ja luodaan tarvittavat valmistus- ja työkaludokumentit. Dokumenttien valmistuttua tuotteen komponenteille määritetään hankintaspesifikaatiot ja valmistetaan protosarjat.
Tuotteen ominaisuuksista tehdään riskianalyysi ja tuotteelle tehdään VA/VE analyysi.
VA/VE analyysissä haetaan vaihtoehtoisia tapoja toteuttaa tuote ilman, että päätoiminnot
muuttava, mutta kustannukset olisivat mahdollisimmat matalat. Tuotteen valmistettavuus
arvioidaan DFM ja DFA analyyseilla. Lisäksi päätetään tuotteen pakkauksesta ja prototyyppien valmistumisen jälkeen arvioidaan, tarvitaanko muotoiluun muutoksia. Tuotteen
suunnittelun ja prototyyppien valmistamisen lisäksi tuotekehityksen vastuulla IP asiat.
Niissä tuotekehitys varmistaa tuotemerkkirekisteröintiasiat ja tekee mahdolliset patenttiha-
56
kemukset. Tuotesuunnitteluvaiheessa tuotekehitys päivittää riskianalyysin ja projektiraportin.
Testiraportti ja asiakasdokumentaatio kuuluvat tuotehallinnan vastuulle. Testiraportti sisältää valmistettujen prototyyppien testaukset ja niiden tulokset sekä mahdolliset muut testiraportit. Lisäksi raporttiin kuuluu osana asiantuntijapalaute prototyypeistä ja testituloksista.
Asiakasdokumentaatioon kuuluu käyttö- ja asennusohjeiden sekä teknisen dokumentaation luominen.
Valmistuksen vastuulla tuotesuunnitteluvaiheessa on tehdä valmistussuunnitelma. Valmistussuunnitelmaan kuuluu osana tuotteen laadunvarmistus ja valmistusprosessin määrittäminen. Valmistus vastaa menetelmäsuunnittelun toteutuksesta tuotannossa ja mahdollisista investointivalmisteluista. Tuotteelle tehdään valmistusprosessin mukainen FMEA
analyysi. Lisäksi valmistus arvioi tuotteen valmistamisen työturvallisuuden ja tuotantoympäristön. Valmistus vastaa toimittaja-arvioinneista ja –sopimusten tekemisestä. Tuotesuunnitteluvaiheessa arvioidaan myös tuotteen tuotannon aloitusta ja korvattavan tuotteen
alasajoa.
Tuotesuunnitteluvaiheen jälkeen siirrytään tuotannon ylösajovaiheeseen. Tuotannon
ylösajovaiheessa valmistaudutaan tuotteen myynnin aloitukseen ja toteutetaan tuotantoinvestoinnit. Vaiheessa viimeistellään tuote, aloittaan tuotanto ja tehdään valmistusraportti
sekä laatusuunnitelma. Lisäksi tuotetta testataan asiakkaan ympäristössä. Vaiheeseen
kuuluu osana tuote, valmistusraportti, laatusuunnitelma, testiraportti, asiakasdokumentaatio, lanseeraussuunnitelma, koulutukset, projektiraportti ja lanseerauspäätös. Tuotekehitys
vastaa tuotteesta ja projektiraportin tekemisestä. Valmistuksen vastuulla on valmistusraportti ja laatusuunnitelma. Tuotehallinta vastaa testiraportista, asiakasdokumentaatiosta,
lanseeraussuunnitelmasta, koulutuksista ja lanseerauspäätöksestä.
Tuotannon ylösajovaiheessa tuotteelle määritellään lopullinen tuotespesifikaatio, valmistusdokumentit ja kokoonpanokuvat. Tuotteen valmistusarvo määräytyy spesifikaatioiden
valmistumisen myötä. Tuotteen pakkaus vahvistetaan. Tuotteen rakenne, hinnat, ohjausarvot ja myyntinimikkeet luodaan toiminnan ohjausjärjestelmään. Lisäksi varmistetaan,
että tuotteeseen liittyvät ympäristöasiat on otettu huomioon. Tuotekehitys luo myös vaiheen aikana projektiraportin, johon on lisätty projektimittarit ja analyysit.
Valmistusraporttiin kuuluu osana työkalujen koeajot ja niiden luovutus tuotantoon. Valmistusprosessi ja menetelmäsuunnittelun oikeellisuus varmistetaan ja investoinnit otetaan
57
käyttöön. Tuotteen tuotanto aloitetaan ja korvattavan tuotteen tuotanto ajetaan alas. Valmistus päivittää valmistusprosessiin pohjautuvan FMEA analyysin. Valmistusraportin lisäksi valmistus vastaa laatusuunnitelman teosta.
Tuotehallinnan vastuulla on testausraportin päivitys. Testausraportista tulee käydä ilmi,
että tuote on validoitu spesifikaatioita vastaan. Raportista tulee ilmetä Beta sarjan asiakkaan tiloissa tehtyjen testien tulokset sekä virallisten sertifiointitestien tulokset ja sertifikaatit. Asiakasdokumentaatio viimeistellään tässä vaiheessa. Lanseeraussuunnitelmaan pitää
määrittää myyntiehdot sekä tuotetiedot tilaus-toimitus järjestelmiin. Lisäksi myyntimateriaalit ja asiakaspalvelutoiminnot tulee määrittää. Tuotteelle tuotetaan markkinointimateriaalit ja tehdään yksityiskohtainen markkinointisuunnitelma. Markkinointisuunnitelma käsittää
aikataulun, kustannukset, resurssit, riskit ja mahdollisen takaisin vetosuunnitelman sekä
ennusteen. Lisäksi tuotehallinta vastaa koulutuksista. Ulkopuoliset ja sisäiset jakelijat,
tuotanto sekä myynti tulee kouluttaa tuotteen ominaisuuksista ja mahdollisuuksista. Vaiheen tärkein päätös on lanseerataanko tuote vai ei. Päätöksen tekeminen on tuotehallinnan vastuulla.
Prosessin viimeinen vaihe on lanseerausvaihe. Lanseerausvaiheessa projekti siirretään
tuotekehitykseltä valmistuksen vastuulle ja tuotekehitysprojekti päättyy. Lanseerausvaiheessa arvioidaan tuotteen lanseeraus markkinoille ja päivitetään liiketoimintamalli. Tuotehallinta vastaa lanseerauksen arvioinnista ja liiketoimintamallin päivityksestä. Liiketoimintamallin päivityksessä päivitetään kannattavuusanalyysi ja kirjataan ylös markkinapalaute.
Lanseerausvaiheessa valmistus luo luovutussuunnitelman ja tekee ylläpitosuunnitelman.
Tuotekehitys viimeistelee oman osuutensa tekemällä loppuraportin. Loppuraporttiin kirjataan, mitä opittiin sekä standardit ja viranomaisvaatimukset, jotka tuote täyttää. Loppuraporttiin kirjataan myös projektin mittarit, joita ovat tuotteen valmistuskustannus, kannattavuus ja laatu. Lisäksi loppuraporttiin arvioidaan toimittajien ja tuotannon tehokkuus.
Kohdeorganisaation tuotekehitysprosessiin on määritelty katselmoinnit jokaisen vaiheen
jälkeen. Katselmoinneissa käydään läpi edellisen vaiheen vaatimukset. Katselmointeihin
on etukäteen määritelty tarkastuslistoja, joilla varmistetaan, että kaikki tarvittavat tehtävät
on tehty. Tarkastuslistoihin on myös määritetty, minkä toiminnon vastuulla vaatimusten
täyttäminen on. Selkeitä kriteereitä, milloin projekti tulee lakkauttaa, ei tarkastuslistoihin
ole merkattu. Katselmoinneissa arvioidaan edellisen vaiheen toimintojen tuloksia ja päätetään, jatketaanko projektia seuraavaan vaiheeseen samalla vahvistaen edellisen vaiheen
58
tulokset. Katselmoinneista tehdään muistio, johon päätökset kirjataan. Muistio tallennetaan tietojärjestelmään ja se on kaikkien projektiin osallistuvien nähtävillä.
Katselmointeihin osallistuu projektin alussa määritelty projektin ohjausryhmä. Ryhmään
kuuluu projektipäällikkö, tuotepäällikkö, valmistuksen edustaja, tuotekehityspäällikkö ja
liiketoimintayksikön vetäjä. Mikäli projektipäällikkö ei ole tuotekehityksen jäsen, ohjausryhmään kuuluu tuotekehitysryhmän edustaja. Katselmoinnin pitäjä vaihtelee tuotehallinnan ja tuotekehityksen välillä, riippuen siitä, missä vaiheessa prosessia katselmointi pidetään. Tuotehallinta vastaa prosessin etupään toiminnoista, joten yleensä tuotehallinnan
edustaja kutsuu prosessin alkupään katselmoinnit koolle. Suunnitelmavaiheen jälkeen
tuotekehityksen toiminnot lisääntyvät ja katselmointien pito siirtyy tuotekehitykselle.
5.1.2 Suorituskyvyn mittarit
Kohdeorganisaatio on määritellyt mittareita, joilla mitataan tuotekehityksen suorituskykyä.
Käytävälle on asetettu taulu, josta käy ilmi mittarit, niiden tavoitearvot ja nykytilat. Kohdeorganisaation tuotekehitysprosessia mitataan säännöllisesti. Mittareina ovat asiakastyytyväisyys, virheettömyys, läpimenoaika, kustannustehokkuus ja valmistuskustannusten taso.
Asiakastyytyväisyyttä mitataan asiakastyytyväisyyskyselyllä, jossa otetaan kantaa tuotteiden tekniseen laatuun, asennettavuuteen, asiakkaiden vaikutusmahdollisuuksiin tuotekehityksessä ja ympäristöasioiden huomioimiseen tuotteissa. Virheettömyydessä keskitytään virheistä johtuneisiin kustannuksiin, joiden kokonaismäärää verrataan liikevaihtoon.
Läpimenoaika on kalenteriaika lähtötietokatselmuksesta myynnin aloitukseen tai tuotantovalmiuden saavuttaminen. Toteutunutta läpimenoaikaa verrataan suunniteltuun. Kustannustehokkuudessa projektikustannusten toteutumaa verrataan suunniteltuun ja em. kustannusten välistä suhdetta verrataan edellisvuoden vastaavaan suhdelukuun. Projektikustannuksiin kuuluu työpanos, materiaali, alihankinnat ja työkalut. Valmistuskustannuksissa
verrataan toteutuneita kustannuksia suunniteltuihin ja kustannusten välistä suhdelukua
verrataan edellisen vuoden vastaavaan suhdelukuun.
5.1.3 Kehityshankkeet
Yrityksessä ja kohdeorganisaatiossa on menossa kehityshankkeita, joilla tähdätään toiminnan laadun parantamiseen. Kehityshankkeita ovat Lean tuotekehitysprosessin ja tuotanto-osien hyväksyntäprosessin implementointi osaksi tuotekehitystoimintaa, design for
59
six sigman integrointi osaksi tuotesuunnittelua, uuden toiminnanohjausjärjestelmän käyttöönotto ja uusi tuote- ja suunnittelutiedon hallintajärjestelmä.
Lean tuotekehitysprosessia otetaan toimintaan mukaan vähitellen. Kaikkia alkavat uudet
tuotekehitysprojektit, jotka seuraavat kuusi vaiheista tuotekehitysprosessia, viedään läpi
Lean prosessilla. Lean projekteissa tehdään tuotemäärittely, josta käy ilmi tuotteen vaatimukset, ominaisuudet ja odotettu tuotto. Tuotemäärittelyn jälkeen luodaan aikataulu, jonka tekemiseen osallistuu projektin sidosryhmät, kuten tuotekehitystiimi, valmistus, osto ja
tuotehallinta. Aikataulun tekoon osallistuvat määrittelevät tehtäviä, joita tulee olla valmiina
projektin eteenpäin viemiseksi. Tehtävien viemä aika arvioidaan ja vaadittavat tehtävät
järjestetään kronologisesti. Näin saadaan projektille aikataulu ja kriittinen polku, joka määrittää projektin keston. Vaadittavien tehtävien väliin määritellään katselmointipisteitä, joissa arvioidaan toimintaa. Katselmointipisteiden välillä otetaan tehtäviä työn alle ja tehtäville
määritellään toimintoja, joilla tehtävät saadaan suoritetuksi.
Jokaisella projektiin osallistujalla on mahdollisuus nostaa esille riskejä ja ne käsitellään
projektipalavereissa ensimmäisenä. Riskeillä haetaan ratkaisuehdotuksia ja ehdotukset
äänestetään paremmuusjärjestykseen. Riskien vähentämisestä luodut tehtävät priorisoidaan kiireellisimmiksi. Jokaisella projektilla on oma Lean taulunsa, jonka avulla käydään
projektia läpi ja jonka avulla voi seurata menossa olevia toimenpiteitä. Lisäksi projektin
aikataulu on asetettu Lean taululle näkyville.
Yritys on määritellyt alihankkijoita, joihin se haluaa panostaa ja joiden kanssa tehdä yhteistyötä syvällisemmin. Yritys on määritellyt tuotanto-osien hyväksyntäprosessin, joka on
tarkoitus integroida osaksi toimintaa. Integroinnin tavoite on varmistaa, että osakohtaiset
suunnitelmat ja vaatimukset on ymmärretty ja täytetty alihankkijalla. Lisäksi hyväksyntäprosessilla pyritään todentamaan, että valmistusprosessit ovat kyvykkäitä valmistamaan
tasaista laatua, laajentamaan suunniteltuja toleranssi-alueita, parantamaan kokoonpanon
tehokkuutta ja säästämään kustannuksissa. Prosessin implementointi alihankkijan toimintaan on oston vastuulla, mutta prosessi vaikuttaa tuotekehityksen toimintaan. Prosessin
jokainen kohta on käytävä läpi uusien osien kanssa.
Kohdeorganisaatio on implementoimassa design for six sigma (DFSS) periaatteita suunnitteluun. Design for six sigma periaatteiden käytöllä tuotesuunnittelussa pyritään vaihtelun vähentämiseen suunniteltavissa osissa käyttämällä hyväksi tilastollista lähestymistapaa suunnittelussa. DFSS käyttöön liittyy erilaisia työkaluja, joiden käyttöön henkilökuntaa
tulee kouluttaa. Osa tuotekehitysryhmän jäsenistä on jo käynyt toleranssisuunnittelun pe-
60
rusteet kurssin. Toleranssisuunnittelun perusteet on pohjavaatimus vaativimpien tilastollisten toleranssisuunnitteluohjelmien kursseille. Toleranssien optimoinnilla pystytään vaikuttamaan tuotteen valmistuskustannuksiin, suorituskykyyn sekä laatuun. Toleranssien ja
niiden variaatioiden ymmärtäminen mahdollisimman aikaisessa vaiheessa tuotesuunnittelussa auttaa minimoimaan kalliit ja aikaa vievät muutoskierrokset.
Toleranssisuunnittelun peruskurssilla henkilökuntaan koulutettiin käyttämään Minitabohjelmaa vaihteluiden tutkimiseksi. Minitab-ohjelmaan on integroitu tilastollisia työkaluja,
joilla voi analysoida muuttujien välisiä suhteita, prosessimuutoksia ja parannuksia. Mekaniikkasuunnittelijat ovat käyneet myös CETOL- toleranssianalyysiohjelman kurssin. CETOL- ohjelmalla pyritään tuotteen optimointiin valmistuskustannusten, laadun ja suorituskyvyn suhteen ja se auttaa kriittisten parametrien määrittelemisessä, mikäli ne eivät ole
tiedossa. Analyysien ja työkalujen käytön lopullisena tavoitteena on optimoida tuote valittujen ominaisuuksien mukaan.
Tulevaisuudessa on tarkoitus jatkaa tuotekehitysryhmän jäsenten kouluttamista laadun
parantamiseksi erilaisilla koulutuksilla, kuten vikaantumisanalyysi, eli FMEA. FMEA- analyyseja tehdään sekä tuotteelle että valmistusprosessille. FMEA on riskien hallintakonsepti
ja niissä haetaan potentiaalisia vikatiloja. Riskejä arvioidaan kolmesta näkökulmasta, vakavuus, esiintyminen ja havaittavuus.
Yritys, jossa kohdeorganisaatio toimii, on ottanut käyttöön uuden toiminnanohjausjärjestelmän. Toiminnanohjausjärjestelmällä pyritään parantamaan yrityksen sekä toiminnallista
että taloudellista tehokkuutta tallentamalla eri osastojen tietoa samaan tietokantaan, jolloin
reaaliaikainen tiedon jakaminen on helppoa. Reaaliaikaisella tiedonjakamisella pyritään
vähentämään päällekkäistä työtä ja nopeuttamaan asioiden käsittelyä. Myös päätöksenteko nopeutuu, jos käytössä on ajankohtaista tietoa. Myynti-tilaus-valmistus-toimituslaskutus prosessi toimii uuden järjestelmän mukaisesti. Myös ostotoiminnot ja alihankintatilaukset hoidetaan uuden järjestelmän kautta. Tuotetietojen tulee olla ajan tasalla uudessa järjestelmässä. Tuotetietojen ylläpito on tuotekehityksen vastuulla.
Tulevaisuudessa nykyinen tuote- ja suunnittelutiedon hallintajärjestelmä tullaan korvaamaan uudella, joka tulee olemaan yhteydessä uuteen käyttöön otettuun toiminnanohjausjärjestelmään. Uudella tuote- ja suunnittelutiedon hallintajärjestelmällä hallitaan kaikki syntyvä tuotetieto aina tuotekehityksen aikaisesta informaatiosta tarkastus- ja hyväksymisvaiheisiin asti. Ohjelmiston ominaisuuksiin kuuluvat muun muassa nimikkeiden, tuoterakenteen, yksilörakenteiden, työnkulun, muutosten ja dokumenttien hallinta.
61
Suunnitteluprosessin aikana uusi tuote- ja suunnittelutiedon hallintajärjestelmä poistaa
tyypilliset tuoterakenteiden ja nimikkeiden määrittelyyn liittyvät ongelmat integroitumalla
käytettyyn CAD järjestelmään. Uusi järjestelmä tarjoaa samalla CAD riippumattoman tarkasteluympäristön kehittyvälle tuotemallille. Uusi tuote- ja suunnittelutiedon hallintajärjestelmä tukee myös erilaisten rakenne-esitysten määrittelyä ja ylläpitoa eri sidosryhmien
tarpeisiin. Monimutkaiset tekniset julkaisut ja muu tuotteeseen liittyvä dokumentaatio voidaan hallita nimikkeistön ja tuoterakenteiden rinnalla. Uudella tuote- ja suunnittelutiedon
hallintajärjestelmällä pyritään maksimoimaan tuottavuus ja operatiivinen tehokkuus.
5.2 Tutkimuksen rakenne
Tutkimus jaetaan kolmeen osaan. Ensimmäisessä osassa tutkitaan kohdeorganisaation
tuotekehitysprosessin dokumentteja ja verrataan kohdeorganisaation tuotekehitysprosessia teoriassa esitettyihin määritelmiin. Vertailun pohjalta haetaan erot ja mahdolliset parannusehdotukset.
Tutkimuksen toisessa osassa tutkitaan kohdeorganisaation tuotekehitystoiminnan toimivuuden nykytilaa ja sen suurimpia kehityskohtia työntekijöiden näkökulmasta. Tutkimuksessa pyritään hakemaan myös parannusehdotuksia toiminnan parantamiseksi. Tuotekehitysorganisaation pienen koon vuoksi tutkimus suoritettiin haastattelututkimuksena. Tutkimukseen haastateltiin 7 tuotekehitysorganisaatiossa työskentelevää henkilöä. Lisäksi
haastateltiin yhtä tuotekehitysorganisaatiossa määräaikaisella sopimuksella työskentelevää projektipäällikköä. Hän on työskennellyt organisaatiossa keväästä 2014 lähtien. Hänen työsopimus jatkuu kesään 2015 asti. Nykytilanteen kartoittamiseksi haastattelussa
kysyttiin:
-
Mikä on hyvää tuotekehitystoiminnassa?
-
Mitkä ovat suurimmat ongelmat?
-
Miten em. ongelmia voisi parantaa?
Teoriaosien mukaan tuotekehitystä ei voi pitää vastuullisena toiminnastaan ja toimintaa ei
voi kehittää ilman mittaamista. Suorituskyvyn johtaminen on päätöksentekoa ja strategian
muuttamista mittaustulosten perusteella. Mittaamisen onnistumisen kannalta on tärkeää,
että henkilökunta ymmärtää, mitä mitataan, miksi ja miten itse voi tuloksiin vaikuttaa. Mittaamiseen liittyvässä haastatteluosiossa haastateltiin 7 tuotekehityshenkilökunnan jäsentä. Määräaikaista projektipäällikköä ei haastateltu mittaamisesta, koska hänen tavoitteet
62
koskevat vain yhtä ja tiettyä projektia määräajan verran ja tavoitteet on määritelty erillisessä sopimuksessa. Tutkimuksessa kysyttiin seuraavia kysymyksiä mittaamisesta:
-
Mitä asioita mitataan kun mitataan tuotekehityksen suorituskykyä?
-
Miksi ym. asioita mitataan, ts. mitä tavoitellaan, kun mitataan ym. asioita?
-
Miten voi vaikuttaa omalla toiminnalla tuloksiin?
Kohdeorganisaatiossa aiotaan integroida tai on jo integroitu erilaisia kehityshankkeita,
joilla pyritään parantamaan sekä tuotekehityksen että koko yrityksen toimintaa. Teorian
mukana implementoinnin onnistumisessa on tärkeää kommunikoida henkilökunnalle, miksi eri järjestelmiä implementoidaan osaksi toimintaa ja mitä niillä tavoitellaan. Haastattelun
viimeisessä osiossa selvitetään, miten hyvin henkilökunta on sisäistänyt eri kehityshankkeet. Määräaikaista projektipäällikköä ei haastatella kehityshankkeiden osalta määräaikaisuuden takia. Osiossa kysyttiin:
-
Miksi kehityshanke implementoidaan osaksi toimintaa?
-
Mitä kehityshankkeella tavoitellaan?
Tutkimuksen kolmannessa osassa haastateltiin kohdeorganisaation työntekijöiden yhteistyötahojen edustajia, joiden kanssa on ollut eniten yhteistyötä. Yhteistyöorganisaatioiden
edustajien kautta pyrittiin saamaan palautetta kohdeorganisaation toiminnan tasosta ja
parannusehdotuksia, miten toimintaa parantaisi. Pääyhteistyötahot henkilökunnan haastatteluiden tulosten mukaan ovat osto, tuotehallinta ja valmistus. Oston puolelta haasteltiin
kolmea edustajaa, joiden kanssa tuotekehityksellä on ollut kanssakäymistä. Valmistuksen
puolelta haastateltiin valmistuksen toimihenkilöitä ja tuotehallinnan puolelta tutkimukseen
osallistui tuotepäälliköt. Yhteistyötahojen edustajilta kysyttiin:
-
Mitä hyvää on tuotekehitystoiminnassa?
-
Mitä asioita tulisi kehittää toiminnan parantamiseksi?
Tutkimuksen ensimmäinen osa suoritettiin dokumenttitarkasteluna ja siihen ei sisälly empiiristä osaa. Haastattelut pidettiin yksilöhaastatteluina. Aikaa haastatteluihin varattiin tunti
jokaista haastateltavaa kohden. Haastattelut pidettiin erillisessä neuvottelutilassa häiriötekijöiden eliminoimiseksi ja keskittymisen takaamiseksi. Haastattelut nauhoitettiin ja tulokset kirjoitettiin puhtaaksi jälkikäteen. Luvussa 6 käydään läpi dokumenttitarkastelun ja
haastatteluiden tulokset. Luvussa 7 tuloksia analysoidaan suhteessa kirjallisuustutkimuksen pohjalta tehtyihin havaintoihin tuotekehitysprosessista ja tuotekehityksen menestystekijöistä.
63
6. TUTKIMUSTULOKSET
Tässä luvussa käydään läpi tutkimuksen tulokset. Luvussa 6.1 verrataan kohdeorganisaation dokumentoitua tuotekehitysprosessia teorian määritelmiin ja haetaan eroja. Luvussa
6.2 käsitellään tuotekehityshenkilökunnan haastatteluiden tulokset. Luvussa 6.3 käydään
läpi yhteistyötahojen haastatteluiden tulokset ja luvussa 6.4 käydään läpi haastatteluissa
esiin tulleita toiminnan parannusehdotuksia.
6.1 Dokumenttitarkastelun tulokset
Kirjallisuudessa määritellyt eri tuotekehitysprosessimallit alkavat ideoiden luomisella. Prosessin ensimmäisessä vaiheessa tavoitellaan mahdollisimman monen strategian ja tavoitteiden mukaisia idean luomista, joille vaiheen aikana tehdään alustavia arviointeja. Vaiheen tavoite on projektimääritelmä, joka sisältää tuotteen tavoitemarkkinat, liiketoimintatavoitteet, avainolettamukset ja rajoitteet. (katso esim. Ulrich & Eppringer 2003, s.16; Park
2007, s.105; Cooper 1988, s.251-254)
Kohdeorganisaation prosessin alkaa konseptivaiheella, jossa arvioidaan ideaa ja tutkitaan
sen potentiaali. Kohdeorganisaation ensimmäisen vaiheen dokumenteista käy ilmi alustavat tavoitemarkkinat, liiketoimintatavoitteet, rajoitteet yms. Kohdeorganisaation ensimmäisen vaiheet dokumentit vastaat teorian määritelmiä. Kohdeorganisaation dokumentoidun
tuotekehitysprosessin suurin ero ensimmäisessä vaiheessa prosessimalleihin on se, että
tuoteideoiden luominen ei ole dokumentoitu osa tuotekehitysprosessia.
Kirjallisuuden mukaan lupaavimpia ideoita tutkitaan tarkemmin ja prosessin seuraavassa
vaiheessa niistä kehitetään konsepteja, joita testataan. Testaamisen valitaan ne konseptit,
joista kehitetään myytävät tuotteet, joten tämä on tuotekehitysprosessin menestymisen
kannalta kriittisin vaihe. Tässä vaiheessa tulisi olla yhteistyötä eri toimintojen välillä. Tuotemääritelmä on vaiheen tärkein tuotos ja sillä on suuri vaikutus prosessin myöhempien
vaiheiden menestymiseen. (katso esim. Ulrich & Eppinger 2003, s. 16-17; Bhyiyan 2011,
s.756; Cooper 2000, s.60)
Kohdeorganisaatiossa tuotekuvaus vastaa tuotemääritelmää. Tuotekuvauksen vaatimuksista käy ilmi tuotteen vaatimukset, taloudelliset tekijät ja tuotteen sijoittuminen markkinoille. Tuotekuvaus on koko tuotteen kehittämisen perusta ja sen tekeminen on tuotehallinnan vastuulla. Kohdeorganisaation tuotekehitysprosessidokumentaatio määrittelee kaikki
tarvittavat toiminnot, joita tuotekuvaukseen tulee tehdä, mutta ei ota kantaa, miten ko.
analyysit tulisi tehdä. Toisin sanoen, dokumentaatiosta ei käy ilmi, miten esim. markkina-
64
analyysi tulisi tehdä, että analyysin tuloksista saa hyvin määritetyt arvot tuotekuvaukseen,
jotka eivät muutu kesken prosessin ja aiheuta toimeenpanon laadun heikkenemistä.
Lisäksi kohdeorganisaation dokumentoitu prosessi ei ota kantaa tuotekuvaukseen osallistuvien henkilöiden määrään tai heidän taustaan. Prosessidokumentaation mukaan tuotekuvauksen voi tehdä kuka vain. Prosessiin on ainoastaan määritelty, että tuotehallinta
vastaa siitä, että tuotekuvaus on valmis vaiheen lopussa. Kohdeorganisaatio voi miettiä,
pitäisikö tuotekehitysprosessiin kehittää aliprosessi tuotekuvausvaiheeseen, jossa konsepteja testataan ja jonka pohjalta tuotekuvaus valmistuu. Lisäksi konseptien testausvaiheeseen tulisi ottaa mukaan eri taustan omaavia henkilöitä. Näin varmistettaisiin, että tuotekuvaus tehdään laadukkaasti ja kaikki kohdat on huomioitu
Konseptien kehitysvaiheen jälkeen kirjallisuuden mukaan prosessi jatkuu järjestelmätason
suunnitteluvaiheeseen, jossa tuotteelle määritetään tekninen layout, tuotteen toiminnalliset määritykset ja alustava valmistettavuus suunnitelma. Tuotekehitysprosessikirjallisuudessa painotetaan asiakastarpeiden ymmärtämistä ja niiden muuntaminen teknisiksi vaatimuksiksi, mikä nähdään ensiarvoisen tärkeänä tuotteen menestymisen kannalta. Tässä
vaiheessa määritetään tuotteen tekniset vaatimukset, joiden pohjalta tuote suunnitellaan.
(Ulrich & Eppinger 2003, s.13-14; Shen et al. 2000, s.93, Wang et al. 2012, s.20; Hines et
al. 2005 s.875)
Kohdeorganisaation suunnitelmavaiheessa tutkitaan tuotteen valmistettavuutta ja tekninen
toteutus mietitään. Tuotteelle luodaan tekninen spesifikaatio, jossa tuotteelle asetetut vaatimukset ja suunnittelun lähtötiedot on määritetty. Tältä osin kohdeorganisaation prosessi
vastaa teoriamääritelmiä. Kohdeorganisaation tuotekehitysprosessin dokumentaatiossa ei
kuitenkaan oteta kantaa, kuinka ja miten hyvin tuotteelle määritetyt tekniset vaatimukset
vastaavat tuotteen markkinavaatimuksia. Prosessin osalta tähän voisi miettiä järjestelmällisiä keinoja, joilla muuttaa asiakasvaatimukset teknisiksi vaatimuksiksi.
Järjestelmätason vaiheen jälkeen seuraa yksityiskohtainen suunnitteluvaihe. Yksityiskohtaisessa suunnitteluvaiheessa painotetaan tuotantokustannuksia ja toteutettavuutta. Rakenteille tulisi tehdä toleranssianalyysejä ja asiakaspalautteen tai -tarpeen saamista pitäisi
tässä vaiheessa edistää, koska se ohjaa suunnittelua oikeaan suuntaan. Testausvaiheessa valmistetaan prototyyppejä, joilla varmistetaan tuotteen toiminta ja tuotannollisuus (Ulrich & Eppinger 2003, s.14)
65
Tuotesuunnitteluvaiheessa kohdeorganisaatio on yhdistänyt kehitys- ja testausvaiheen.
Kohdeorganisaation tuotesuunnitteluvaiheen kriteerit eivät vaadi toleranssianalyysien tuoterakenteelle, eikä ota kantaa tuotedokumenttien laadun varmistukseen. Asiakaspalaute
tai – tieto tuotekehitykselle ei ole dokumentoitu prosessivaiheeseen. Kohdeorganisaatiossa tuotesuunnitteluvaiheeseen kuuluu osana tuotteen toiminnan varmistaminen testaamalla teorian mukaan. Tämän vaiheen osalta voi miettiä, pitäisikö vaiheen kriteerejä päivittää.
Tuotannon ylösajovaiheessa aloitetaan tuotteen valmistus tuotantoprosessien mukaan.
Vaiheen aikana päätetään lanseerataanko tuote (Ulrich & Eppinger 2003, s.14). Kohdeorganisaatiossa tuotannon ylösajovaiheessa aloitetaan tuotteen valmistus tuotannon prosessin mukaisesti ja varmistetaan, että tuote on valmistettavissa suunniteltujen prosessien
mukaisesti. Tuote spesifikaatiot jäädytetään ja koulutetaan henkilökuntaa sekä aloitetaan
valmistautuminen lanseeraukseen ja myyntiin. Vaiheen aikana tehdään päätös tuotteen
lanseerauksesta ja markkinoille menemisestä. Kohdeorganisaation dokumentoidun tuotekehitysprosessin tuotannon ylösajovaihe vastaa hyvin tuotekehitysprojektikirjallisuuden
kriteerejä.
Kirjallisuudessa esitetyt tuotekehitysprosessimallit loppuvat pääsääntöisesti tuotannon
ylösajovaiheeseen. Lanseerausvaihetta ei ole määritelty. Kirjallisuudessa kuitenkin mainitaan, että on hyvä arvioida tuotteen menestyminen ja projektin aikaisten päätösten oikeellisuus lanseerauksen jälkeen (Park 2007, s.105). Kohdeorganisaation lanseerausvaiheeseen kuuluu osana markkinapalaute, katsaus tehtyyn projektiin ja siihen, saavuttiko projekti sen mitä alkupäässä asetettiin tavoitteiksi. Kohdeorganisaation tuotekehitysprosessin
kuuluu siis teorian mukainen toiminta lanseerauksen jälkeen.
Kohdeorganisaation katselmointikäytännöt ovat melko hyvin linjassa kirjallisuudessa esitettyjen katselmointikriteerien kanssa (katso esim. Cooper 2000,s.59; Cooper & Edgett
2012, s.50-53). Kohdeorganisaatiossa on katselmoinneille kehitetty tarkastuslistat, joiden
avulla varmistetaan, että kaikki tarvittavat tehtävät on suoritettu. Katselmoinneissa arvioidaan edellisen vaiheen toimintaa ja päätetään jatkosta. Katselmointeihin osallistuvat projektin alussa määritetty ohjausryhmä. Eroja teoriamääritelmiin ovat, ettei kohdeorganisaation dokumentteihin ole määritelty selkeitä kriteerejä, milloin projekti lopetetaan. Myöskään
kriteerejä vaiheiden tulosten arvioimiseksi ei ole määritelty. Dokumentaation mukaan riittää, kunhan tarkastuslistassa olevat tehtävät on suoritettu.
66
Dokumenttitarkastelun pohjalta voi päätellä, että kohdeorganisaation dokumentoitu tuotekehitysprosessi vastaa sitä paremmin kirjallisuudessa esitettyjä määritelmiä, mitä lähemmäksi prosessin loppupäätä mennään. Teoria painottaa enemmän prosessin etupään
toimintoja ja niiden merkitystä koko prosessin lopputuloksen kannalta. Kohdeorganisaatio
voi miettiä, pitäisikö prosessin alkupään kriteerejä miettiä uudestaan ja/tai päivittä, esimerkiksi tuotesuunnitteluvaiheessa. Lisäksi voi harkita aliprosessin kehittämistä, jolla luodaan järjestelmällisesti tuotekuvaukset.
6.2 Henkilökunnan haastatteluiden tulokset
Tässä luvussa käydään läpi tuotekehitysorganisaation työntekijöiden haastatteluiden tulokset. Ensin käsitellään, miten tuotekehityshenkilökunta kokee tuotekehitystoiminnan
nykytilan, sen vahvuudet ja kehityskohteet. Luvussa 6.2.2 käsitellään tuotekehitystoiminnan mittaamista tuotekehityshenkilökunnan näkökulmasta ja luvussa 6.2.3 käsitellään,
miten hyvin henkilö tuntee organisaatiossa menossa olevat ja tulossa olevat toiminnan
kehityshankkeet.
6.2.1 Tuotekehitystoiminnan nykytila
Haastattelut aloitettiin kysymällä henkilöiltä, mitä hyvää tuotekehityshenkilökunnan mielestä tuotekehitystoiminnassa ja –organisaatiossa on. Kaikki mainitsivat työilmapiirin ja ryhmän yhteishengen positiiviseksi asiaksi. Ryhmän jäsenet nähtiin avoimina, toisiaan auttavina ja tietoa jakavina. Yleinen mielipide oli, että ryhmän jäsenillä oli oman alansa osaaminen ja tietämys hallussa, toisin sanoen jäsenet ovat ammattitaitoisia omilla teknologiaaloillaan. Ryhmän jäsenillä on motivaatiota parantaa toimintaa ja tuotteita sekä tehdä asioita hyvällä laatutasolla. Tuotekehitysryhmän jäsenillä on laaja-alainen osaaminen omalta
erikoisalueeltaan. Ryhmän jäsenet ovat osallisena tuoteprojekteissa aina tuotemäärittelystä tuotannon ylösajoon asti ja osallistuvat ylläpitotoimintoihin. Laaja-alainen toimenkuva
auttaa näkemään asioita monesta eri näkökulmasta. Kokonaisuudessaan ryhmän kokoonpanossa nähtiin potentiaalia haastavampiinkin kehitysprojekteihin.
Tuotekehitystoiminnan tasosta mainittiin, että toiminta on viime aikoina parantunut. Toimintaa ja ryhmän jäsenten ajankäyttöä on aloitettu suunnittelemaan etukäteen ja tehtäviä
priorisoimaan. Em. asiat koettiin parannuksina. Lisäksi Lean tyylisen tuotekehitystoiminnan mukanaan tuomat visuaaliset ohjaukset nähtiin hyvänä asiana. Projektin kokonaisuus
hahmottuu paremmin ja sen seurauksena toiminnan taso paranee. Aikaisemmin projektin
kokonaiskuva ei ollut kaikille selvä. Tuotesuunnittelussa elektroniikan katselmointikäytän-
67
nöt tuotesuunnitelmille, jotka menevät tuotantoon tai alihankkijalle, nähtiin toiminnan laatua parantavana tekijänä.
Positiivisten asioiden jälkeen haastattelussa käytiin läpi tuotekehitystoiminnan kehityskohteita. Ensimmäiseksi haastatteluissa tuli esille projektien aikataulut ja niiden venyminen.
Syitä aikataulujen venymiseen tuli monia. Koettiin, että aikataulut määritetään ylioptimistisina ja määriteltäessä ei oteta huomioon tarpeeksi epävarmuustekijöitä ja projektiin osallistuvien tarvitsemaa oppimisaikaa. Lisäksi odotetaan, että kaikki projektiin liittyvät toiminnot, kuten testaus, alihankinta, konserniyhteistyö, mukautuvat aikatauluun. Käytännössä
näin ei tapahdu. Lisäksi koettiin, että ylempi johto painostaa hyväksymään ylioptimistiset
aikataulut.
Ryhmän jäsenten kokivat, että projektien aikataulut tehdään oletuksella, että kaikki projektiin osallistuvat henkilöt pystyvät tekemään projektia täydellä teholla heti alusta lähtien.
Uusia projekteja kuitenkin aloitetaan ennen kuin vanhoja saadaan valmiiksi ja projekteihin
osallistuvat joutuvat jakamaan aikansa uuden ja vanhan projektin väillä. Ylempi johto ei
ole aina valmis odottamaan, että saadaan vanhoja projekteja valmiiksi ennen kuin uusia
aloitetaan. Uuteen projektiin keskittyminen vähentää vanhaan projektiin panostettavaa
aikaa ja vanhojen projektien läpivieminen venyy.
Viime aikoina trendi on aloittaa uusia projekteja suppeina, eli pidetään lähtötietojen katselmointi ja prosessi alkaa tuotesuunnitteluvaiheesta. Tällä toimintatavalla oletetaan tavoiteltavan työmäärän vähenemistä prosessin alkupäässä. Jälkikäteen on kuitenkin huomattu, että suppeana aloitettu projekti olisi kannattanut tehdä isompana projektina. Suppeissa
projekteissa tuotemäärittely on isoa projektia rajatumpi ja yleisesti koetaan, että suppeiden projektien tuotemäärittelyt ovat liian epämääräisiä tuotesuunnittelun lähtökohdaksi.
Suppeiden projektien määrittelyt tehdään nopeasti ja määrittelyjen taustalla ei ole analyysiä siitä, mitä tehdään ja mihin päätökset vaikuttavat. Heikosti tehdyt analyysit lähtötiedoissa kostautuvat prosessin myöhäisemmissä vaiheissa ja lopputuloksena aikataulut
venyvät. Lisäksi tuotemäärittelyissä volyymit arvioidaan usein isommiksi, mitä ne myynnissä ovat.
Tuotekuvauksen tekoon ja lähtötietojen määrittelyyn ei tuotekehitysryhmän jäsenet juurikaan osallistu. Tuotekuvaukset luodaan tuotekuvausvaiheessa tuotehallinnan toimesta.
Tuotekuvaukseen osallistuminen riippuu tuotepäälliköstä, ottaako hän tuotekehityksen
mukaan pohtimaan määrittelyjä. Tuotekuvausten laatu vaihtelee, mutta yleensä tuotekuvauksen määritelmät ovat minimaaliset. Määritelmien tulisi olla tarkempia ja kuvauksista
68
puuttuvat täsmälliset luvut. Tuotekehitystoiminnan pohjaksi etenkin tekniset määritelmät
pitäisi olla paremmat. Erityisesti suppeiden projektien osalta määrittelyt lisääntyvät tai
muuttuvat prosessin aikana, mutta niitä ei kirjata ylös. Lisääntyneet määritelmät vaikuttavat aikatauluun, mutta aikataulua ei mukauteta uusiin vaatimuksiin sopivaksi. Tuotekuvauksessa on määritetty volyymit ja kohdemarkkinat. Tuntuma on, että jälkikäteen ei tutkita,
myikö tuote niin kuin oli suunniteltu.
Tuotekuvauksen
tekemiseen
pitäisi
käyttää
enemmän
aikaa.
Asioiden
syy-
seuraussuhteita tulisi miettiä tarkemmin ja tavoitteet tulisi olla laadukkaammat ja tarkemmat. Tuotekuvaus- ja suunnitteluvaiheeseen lisätty aika parantaisi prosessin loppupään
toimintojen laatua ja aikataulussa pysymistä. Viime aikoina on kuitenkin pantu merkille,
että tuotekuvauksien taso on parantunut. Tuotekuvauksen tekoon osallistuu isompi joukko
ihmisiä kuin vain tuotepäällikkö.
Ryhmän jäsenillä on haastattelun tulosten mukaan liikaa tehtäviä työn alla samaan aikaan. Tuotekehityksen jäsenillä kaikilla on monia projekteja menossa samanaikaisesti.
Seurauksena on kiire ja keskittyminen yhteen projektiin kerrallaan on hankalaa. Kiireen ja
keskittymisen mahdollisuuden puutteen vuoksi, tehdään päätöksiä ilman, että tunnetaan
päätöksen vaikutuksia kunnolla. Heikkojen analyysien pohjalta tehdyt päätökset luovat
uusia ratkottavia ongelmia, mikä lisää tehtäviä ja kiirettä. Lisäksi kiireen koettiin aiheuttavan sen, että joutuu kommentoimaan jotain asiaa ilman, että voi perehtyä asioihin kunnolla. Tehtävien liiallinen määrä per henkikö näkyy aikataulujen venymisenä. Jos yhdellä
tekijällä olisi kaksi projektia työn alle, pystyisi keskittymään paremmin ja tuotteet olisi laadukkaampi.
Ryhmän jäsenten mielestä oman osuuden arvioiminen aikataulun teossa on hankalaa,
koska ei pysty sanomaan, miten paljon voi käyttää aikaa viikossa. Koska tehtäviä on liian
monta päällekkäin, tarvitaan tehtävien priorisointia. Kaikkea ei voi tehdä samanaikaisesti.
Tehtävien priorisointi on alkanut, mutta esille tuli, onko omalla porukalla priorisointi oikea
tapa priorisoida tehtäviä. Priorisoinnin tulisi tulla tuotekehityspäälliköltä, työntekijän itse ei
pitäisi olla vastuussa priorisoinnista.
Lisäksi haastatteluissa nousi esille kysymys, kuuluvatko kaikki tehtävät, joita nyt tehdään,
tuotekehitykselle. Esimerkiksi kuuluuko tuotannon ohjeiden tekeminen ja päivitys tuotekehitykselle? Lisäksi nostettiin esille työntekijöiden toimenkuvat. Nyt suunnittelija osallistuu
projektiin projektin alusta tuotantoon vientiin asti. Ei voi keskittyä yhteen osa-alueeseen,
vaan vaaditaan paljon laaja-alaista osaamista.
69
Haastateltavien mukaan ylempi johto ei välttämättä tiedä, mikä tilanne tuotekehityksen
jokapäiväisessä toiminnassa on. Koettiin, että ei ymmärretä, jos juoksevia asioita on 50%
ajasta, ei voi tehdä 70% ajasta projekteja. Tuotekehityspäällikön uskottiin ymmärtävän
tuotekehityshenkilökunnan kuormituksen, mutta ylemmän johdon suhteen oltiin epäileviä.
Haasteltavat kokivat, että johto toivoo työntekijöiltä itseohjautuvuutta. Itseohjautuvuuteen
tarvitaan kokonaiskuvan tuntemusta toiminnasta, tuotteista yms., joiden tuntemuksen tason koetaan olevan heikko työntekijöiden keskuudessa. Työntekijöille ei ole näkymää tulevaan, vaan he tekevät projekteja sitä mukaa, kun niitä aloitetaan. Elektroniikan osalta
tulevaisuuden näkymät ovat selvemmät kuin muussa toiminnassa, koska uusi teknologia
tulee konsernista.
Kohdeorganisaation prosessin vaiheiden ja kriteerien tunteminen vaihtelee. Jos on toiminut projektin vetäjänä, prosessi tunnettiin paremmin. Katselmoinneista tiedettiin, että niitä
pidetään, mutta kriteereitä ei tunneta. Koettiin, että jos prosessin ja kriteereiden tuntemus
olisi parempi, voisi ehkä ottaa asioita huomioon etukäteen ja suunnitella omaa toimintaa
paremmin. Tekniset vaatimukset ja omat tehtävät tunnetaan, mutta projektin kokonaiskuva epäselvä. Projektidokumentaatio, suunnitelmat ja tekniset dokumentit, ei ole ryhmälle
näkyvissä, joten aikataulu ei välttämättä hyvin tiedossa kaikilla tiimin jäsenillä. Jos kokonaiskuva ei ole selvillä, odotetaan projektipäälliköltä ohjausta, mitä tehdä ja milloin. Tästä
seuraa, että asioita tehdään vasta, kun ne ovat prosessin mukaan pakko tehdä. Prosessin
käytöstä sanottiin, että prosessia käytetään jollain tasolla, mutta sitä sovelletaan paljon.
Koettiin, että kiireessä prosessivaatimuksia oiotaan ja prosessia jatketaan, vaikka kriteerit
eivät täyttyisi. Tuotannon ylösajovaiheessa prosessia ei aina noudateta. Esim. myynti alkaa ennen kuin tuotantovalmius on olemassa.
Lisäksi projektipäällikköjen ei koettua aina olevan ajan tasalla aikataulun suhteen. Projektipäälliköillä on liikaa projekteja vastuulla tai he toimivat myös suunnittelijoina, joten projektipäälliköt eivät voi keskittyä yhteen projektiin kerralla. Yleisesti koettiin, että projektipäälliköstä, joka voi keskittyä vain yhteen projektiin, on hyötyä asioiden järjestelyssä, tiedon tuottamisessa ja projektin seurannassa.
Tuotekehitysprojektien lisäksi ryhmän jäsenillä on tuotannossa olevien tuotteiden ylläpitovastuita. Ylläpitovastuut vievät oman aikansa ja se aika on pois tuotekehitysprojekteista.
Mikäli tuotannossa on ongelmia tuotteen osalta, tuotekehitystoiminta lopetetaan ja keskitytään tuotannon ongelman ratkaisemiseen. Projekteista pois otettua aikaa yritetään myöhemmin saada kiinni, joka osaltaan lisää kiirettä.
70
Koettiin, että tuotannossa on tuotteita, jotka eivät toimi kunnolla valmistettavuuden näkökulmasta. Jälkikäteen tehdään korjauksia tuotteeseen. Korjausten suunnittelu ja organisointi vie aikaa ja se on pois uusilta tuoteprojekteilta. Tuotteiden pitäisi tuotannon aloituksessa olla siinä kunnossa, että ei menisi seuraavaa kahta vuotta tuotannon aikana tuotteita korjatessa. Osasyyksi tähän tilanteeseen nähtiin se, että tuotekehityksessä testataan
nopeasti. Päätöksiä tuotantoon viemisestä tehdään liian nopeasti ja tuloksia analysoimatta. Lisäksi nähtiin haasteellisena se, että tuotteen myynti aloitetaan ennen kuin tuote on
tuotantovalmis, mikä lisää painetta tuotannon aloitukseen. Myös alihankkijan toimittamien
osien laadun koettiin aiheuttavan ongelmia tuotannossa. Tuotanto reagoi alihankkijan virheisiin, kun on myöhäistä reklamoida. Usein ei pyydetä alihankkijaa korjaamaan tilanne, ja
lopputuloksena on, että ongelma ei poistu. Jatkuvaa seurantaa toimitusten laatuun tarvitaan, koska koettiin, että alihankkijat testaavat rajojaan. Nämä ongelmat näkyvät ylläpitovastuiden lisääntymisenä.
Koettiin, että myös suunnittelun laatua pitäisi parantaa lisäämällä analysointia. Analyysien
tekeminen vie kuitenkin aikaa ja se on pois muusta toiminnasta. Organisaatiossa panostetaan suunnittelun laadun parantamiseen tähtäävään koulutukseen, joka koettiin hyvänä
asiana. Mutta yleisesti epäiltiin, annetaanko myös mahdollisuus käyttää oppeja käytännössä. Johdon tulisi antaa aikaa koulutuksen jälkeen opetella soveltamaan oppeja käytännössä. Tuotekehityksen jäsenillä ei ole halua lähteä tekemään monimutkaisia analyysejä, jollei ole aikaa tehdä kunnolla.
Suunnittelutoiminnassa koettiin, ettei ole aikaa ideoinnille ja käytännössä uusien tuoteideoiden ideointia ei tapahdu. Kohdeorganisaatiolla ei ole tutkimustoimintaa ja tuotteissa käytettävä teknologia tulee konsernista valmiina. Tuotteessa ei ole paljoa ideoitavaa siinä
vaiheessa, kun se tulee tuotekehitykseen tuotteistettavaksi. Koska kohdeorganisaation
tuotekehitystoiminnan pääpaino nähtiin muiden suunnittelemien tuotteiden tuotantoon
viemisenä, tuoteparannusten ja asiakasversioiden tekemisenä, kyseenalaistettiin tuoteideoinnin tarve. Ideointi nähtiin pääasiassa tuotteen valmistettavuuden ja tuoteparannusten ideointina. Harvoin kehitetään kohdeorganisaatiossa täysin uusia tuotetta, mikä
alkaa ideoinnista. Haasteltavilla olisi kiinnostusta ideointiin ja ideoita on paljon, mutta ideoiden analysointiin ei aikaa ole. Jos tuoteidea tai tuoteparannus tulee mieleen, osa menee
suunnittelijan luo mieluummin kuin tekee aloitteen asiasta. Aloitteen tekeminen vie aikaa.
Osa haastateltavissa ottaa ideasta yhteyttä esimieheensä, tuotekehityspäällikköön. Muutama pitää idean omana tietona, koska ideoiden läpi saaminen on vaikeaa.
71
Tuoteideointi nähtiin tuotehallinnan vastuulle. Tarvittaessa annetaan teknistä tukea, mutta
itse ideointiin ei juurikaan osallistuta. Tuoteideoinnin tulisi pohjautua strategiaan. Kysyttäessä kohdeorganisaation strategiaa tuli esille, että tuotekehitysstrategia on useille epäselvä. Muutama epäili, onko sellaista edes olemassa. Strategian osalta parhaiten tunnetaan
konsernitason strategia, mutta miten se näkyy tuotekehitystoiminnassa, sitä ei osata sanoa. Moni muisti, että strategiaa on läpikäyty, mutta sen sisältöä ei muisteta.
Lisäksi tuoteideoinnissa ja tuotesuunnittelussa pitäisi olla asiakastarpeet selvillä. Projekteihin liittyvistä asiakastarpeista ei tuotekehitysryhmällä ole tietoa. Projektin alussa saadaan tietoa teknisistä vaatimuksista, mutta oikea asiakastarve vaatimuksen taustalla jää
epäselväksi. Annetuista teknisistä vaatimuksista ei käy ilmi, mitä kentällä odotetaan tai
tarvitaan. Miten asiakastarpeet ja niistä johdetut tekniset vaatimukset on määritelty, on
heikosti tiedossa tuotekehitysryhmällä. Tuotehallinta koettiin pääasiallisena asiakastarpeen lähteenä. Lisäksi tuotekehityspäällikkö koettiin asiakastarpeen lähteenä. Tuotekehitys ei saa usein tietoa, miten tuotteet vastaanotetaan markkinoilla, kun tuote lanseerataan.
Hyvin menneistä asioista saa harvoin mitään palautetta, huonosti menneistä asioista sitäkin enemmän.
Muutamissa haastatteluissa tuli esille kysymys, mikä on tuotekehityksen tarkoitus, jos ei
kehitetä omia tuotteita? Jos halutaan, että viimeisin tieto ja taito olisivat organisaatiossa,
pitäisi olla omaa tuotekehitystä ja tutkimusta. Haastateltavien keskuudessa oli toive päästä kehittämään tuote ideasta valmiiksi tuotteeksi. Tämä kuitenkin vaatisi resursseja, aikaa
ja rahaa johdolta.
Kilpailijoihin verrattuna kohdeorganisaation tuotteet nähtiin kalliimpina, mutta vaatimustasoltaan parempina. Teknologia mielessä osa kilpailijoista on edellä. Koettiin, että kehitysprojekteja aloitetaan, kun asiakas vaatii samanlaista tuotetta, jonka kilpailija jo tuonut
markkinoille. Haastatteluissa tuli esille, että jos tuoteidea tulee myynniltä, ts. asiakkaalta,
silloin ollaan myöhässä tuoteideoiden kanssa. Koettiin, että pitäisi osata tunnistaa asiakastarpeet etukäteen ja tuotteen tulisi olla valmiina, kun asiakas osaa sitä vaatia. Nyt
asiakasvaatimuksen pohjalta kehitetään uusi vastaava tuote, mutta jossa enemmän ominaisuuksia kuin kilpailijalla. Tilanne koetaan sellaiseksi, että kopioidaan kilpailijoita, eikä
olla eturintamassa. Pitäisi panostaa enemmän omaan kehittämiseen ja olla se, jota kopioidaan.
Nyt kehitteillä olevissa ja tulossa olevissa tuotteissa on paljon radiotuotteita, joiden osaaminen on heikolla tasolla. Organisaatiolla ei myöskään ole mittauslaitteita radiotuotteiden
72
testaamiseen. Tuotteiden tutkiminen ei ole mahdollista ilman ulkopuolista resurssia. Muuten työkalut ja testitilat koettiin hyvinä. Tuotekehityksen tiloissa nähtiin kehityskohteita.
Ympäristön yleinen hälinä ja meluisuus koettiin huonona tekijänä. Meluisuuden osalta on
tilanne huonontunut toimiston layout muutoksen jälkeen. Lisäksi työpäivän aikana työ
keskeytyy usein eri tahojen, kuten esim. tuotanto, ylläpito, projektipäälliköt, yhteydenoton
vuoksi. Keskeytykset heikentävät keskittymistä tehtäviin.
Yllä mainittujen asioiden lisäksi, määräaikaista projektipäällikön haastattelussa tuli esille
muutama uusi asia. Haastattelussa projektipäällikkö perään kuulutti ihmisten omaaloitteisuutta lisää. Nyt odotetaan, että projektin vetäjä sanoo, mitä pitää tehdä ja otetaan
vastuu vain omasta tekemisestä kokonaiskuvasta välittämättä. Lisäksi aikataulun ja projektisuunnitelman tekoon osallistuminen on heikolla tasolla. Nyt projektin vetäjä tekee ehdotuksen, jota ei kommentoida tai aktiivisesti prosessoida. Riskien pienentämisessä omaaloitteisuutta pitäisi saada lisää. Pelkkä palaverikäytäntö ja kirjaukset ei riitä, vaan riskien
pienentäminen pitäisi integroida osaksi jokapäiväistä toimintaa. Laadukkaan toiminnan
kannalta ei riitä, että yksi ohjaa toimintaa, vaan tarvitaan osallistuvampi ote toimintaan
kaikilta projektiin osallistuvilta ihmisiltä.
Ulkopuolisen silmiin kohdeorganisaation ja muiden liiketoimintayksiköiden tuotekehitysten
toiminta on lokeroitunutta. Yhteistyö muiden tuotekehitysyksiköiden kanssa on olematonta, resursseja ei lainata ja tietoa ei vaihdeta. Sama asia tuli esille tuotekehityshenkilöiden
haastatteluissa. Jokainen tuotekehitysyksikkö tekee omia projektejaan ja tieto ei kulje yksiköiden välillä. Muiden yksiköiden tuotteiden, asiantuntevuuden ja suunnitelmien hyväksikäyttöä ei tapahdu. Tieto kulkee hyvin tuotekehityksen sisällä, mutta niin juuri liiketoimintayksiköiden välillä.
Tuotekehityshenkilökunnan haastatteluiden mukaan tuotekehityksellä on kanssa käymistä
eniten tuotehallinnan, oston ja valmistuksen kanssa. Projektin aikana tuotehallinnan edustaja, tuotepäällikkö, edustaa asiakasta ja on vastuussa tuotekuvauksen tekemisestä. Tuotehallinnan kanssa toivottaisiin enemmänkin yhteistyötä. Toivottiin lisää tietoa siitä, mitä
toimintoja tuotteisiin tulee ja miksi.
Tuotekehityksen kanssa käyminen oston edustajien kanssa on parantunut. Tuotekehitys
kokee olevan tietoinen alihankkijan kyvykkyyksistä ja pyrkii mukauttamaan suunnitelmat
niihin. Lisäksi pyritään käyttämään hyväksi alihankkijan ammattitaitoa suunnittelun aikana.
Ongelmaksi koettiin, että alihankkijat tulevat mukaan myöhäisessä vaiheessa, jossa vai-
73
kutusmahdollisuudet suunnitelmiin on pienet. Etenkin uuden tuotteen osalta, alihankkija
tulisi ottaa mukaan miettimään ratkaisua, miten valmistetaan, tehdään paremmaksi yms.
Valmistuksen kanssa tuotekehitysryhmä koki, että yhteistyö on hyvällä tasolla ja palautettakin saa, mutta sitä pitää kysyä. Valmistus ottaa yhteyttä tuotekehitykseen ylläpitomielessä, jos eteen tulee ongelma, jota itse eivät osaa ratkaista. Ylläpitotehtävissä tuotekehityshenkilökunta on yhteydessä suoraan henkilöiden kanssa, jotka tekevät tuotantotyötä.
Valmistushenkilökunnan kanssa ei ole sovittua toimintatapaa, miten ongelmista kommunikoidaan tai raportoidaan. Kun uusien tuotteiden valmistus aloitetaan, tuotekehityksen tulisi
järjestää koulutus tuotteesta valmistuksen henkilökunnalle. Valmistukseen jalkautumista
pidettiin suositeltavana ja oma-aloitteisuudella saa valmistukselta palautetta muistakin
kuin ongelmista.
Muiden toimintojen kanssa, kuten esim. markkinointi, myynti, ei koettu olevan mitään yhteistyötä. Lisäksi konserniyhteistyö koettiin enemmän sanelupolitiikkana kuin yhteistyönä.
Konsernille voi esittää toiveita, mutta ei ole mitään takeita mikä on konsernin tarjoama
lopputulos.
6.2.2 Toiminnan mittaaminen
Tuotekehitystoiminnan mittaamisella arvioidaan tuotekehityksen toimintaa. Tutkimuksessa
selvitettiin, miten hyvin henkilökunta tuntee arviointiperusteet ja miten he voivat niihin vaikuttaa. Kohdeorganisaatio on määritellyt mittareita, joilla mitataan tuotekehityksen suorituskykyä. Käytävälle on asetettu taulu, josta käy ilmi mittarit, niiden tavoitearvot ja nykytilat.
Suorituskykymittarit eivät olleet kenellekään täysin selvät, vaikka mittarit ovat esillä käytävällä. Kaikki eivät osanneet linkittää käytävällä olevaa taulua suorituskykymittareiksi. Tuotekehityksen suoristuskykymittareita kysyttäessä yksikään työntekijä ei osannut nimetä
kaikkia mittareita. Eräs haastateltava ei osannut nimetä yhtäkään suorituskykymittaria.
Parhaiten mittareista tunnettiin projektien läpimenoaika, projektikustannukset ja reklamaatiot. Tuotteen valmistuskustannusmittari ja tuotekehityksen kustannukset olivat harvojen
tiedossa. Yksikään haastatelluista ei osannut mainita VA/VE kustannussäästöjä tai uusien
tuotteiden osuutta myynnistä.
Mittaamisella uskottiin tavoiteltavan pääasiassa maksimaalista tuottoa sijoittajille. Läpimenoaikojen mittaamisella uskottiin arvioivan projektin suunnittelun onnistumista. Reklamaatioilla haetaan, miten hyvin tuotesuunnittelu on onnistunut. VA/VE mittarin osalta
74
kommentointiin mm. ettei sitä tehdä, menetelmiä ei käytetä ja ei tiedetä, miten VA/VE tuote määritellään. Koska kaikki mittarit eivät olleet selvillä, ei paljon saanut palautetta, siihen, miksi jotain mittaria mitataan.
Haastatteluissa tuli esille mielipide, että työntekijän ei välttämättä tarvitse tietää, mitä mitataan. Esimiehen tehtävä on ohjata tuotekehityksen toimintaa oikeaan suuntaan. Mittaamista ja toiminnan ohjauksen välistä kytköstä ei nähty. Toisaalta sanottiin myös, että itseohjautuvuus tuotekehitystoiminnassa kasvaisi, jos ymmärtäisi, mitä mitataan ja miten voi
tuloksiin voi vaikuttaa.
Yksittäisen työntekijän ei koettu voivan vaikuttaa kaikkiin tuloksiin. Projektitasolla tuloksiin
uskottiin voivan vaikuttaa. Yleisesti uskottiin, että mittaamisen tuloksiin pystyi vaikuttamaan tekemällä parempia suunnitelmia ja panostaa suunnitelmien seurantaan. Lisäksi
tekemällä annetut tehtävät mahdollisimman hyvin, parhaaksi katsotulla priorisoinnilla,
saavutetaan parempia tuloksia. Myös resursoinnin parantamisella tulokset paranisivat.
Tuotteen valmistuskustannuksiin voi vaikuttaa tarjouskyselyillä ja teknisillä ratkaisuilla.
Tekniset ratkaisut ovat usein annettu valmiina ja niihin ei aina voi vaikutta. Reklamaatiomittariin voi vaikuttaa suunnittelun laadulla, testaamalla tuotetta riittävästi ja tekemällä
oikeat testit. Suunnittelun laatuun voi vaikuttaa uusilla analysointityökaluilla ja sopivan
alihankkijan valitsemisella.
Yleisesti ei uskota, että tuotteiden määrittelyyn tuotekehitys voi vaikuttaa. Tuotekehitys voi
osallistua teknisen ratkaisun kehittämiseen, mutta tuoteidean luomiseen ja idean markkinamenestyksen arviointiin ei tuotekehityksellä koettu olevan mitään vaikutusmahdollisuutta. Tuotekehityshenkilökunnan mielestä tuotekehitys ei voi vaikuttaa siihen, ovatko kehiteltävät tuotteet sellaisia kuin asiakkaat haluavat. Tuoteidean luominen ja sen testaaminen
on tuotehallinnan vastuulla.
Suorituskyvyn mittaamisesta kohdeorganisaatiossa voi todeta, että henkilökunta ei ole
täysin ymmärtänyt, mitä mitataan. Joitain mittareita ei ymmärretä, mitä ne tarkoittavat.
Koska ei tiedetä, mitä mitataan tai mitä mittari tarkoittaa, ei ymmärretä, miksi ko. mittari
käytetään. Lisäksi, miten tuloksiin voi vaikuttaa, on epäselvää. Kohdeorganisaation johdon
tulisi avata mittareita, niiden tarkoituksia ja vaikutusmahdollisuuksia henkilökunnalle.
75
6.2.3 Kehityshankkeet
Haastattelussa käsiteltiin kohdeorganisaatiossa jo integroituja ja tulossa olevia kehityshankkeita. Kysyttiin, tiedetäänkö, miksi kehityshanke on päätetty implementoida ja miten
niillä pyritään parantamaan toimintaa. Kehityshankkeiden käyttöönoton uskotaan paranevan, jos henkilökunta ymmärtää, mitä hankkeilla tavoitellaan.
Uusi toiminnan ohjausjärjestelmä on otettu käyttöön. Syyksi vanhan järjestelmän korvaamiseksi sanottiin, että vanha järjestelmä oli tullut tiensä päässä. Uuden järjestelmän tavoitteita nimettiin monia. Mainittiin, että uuden järjestelmän perimmäinen tarkoitus on yhtenäistää toimintatavat konsernin eri yhtiöiden välillä. Eniten nimetyksi tavoitteeksi tuli
toiminnan nopeuttaminen ja parantaminen sekä toiminnan tehokkuuden lisääminen. Uskotaan, että järjestelmällä tavoitellaan ongelmatonta tuotantoa ja sen uskotaan mahdollistavan varaston hallinnan. Järjestelmällä hävikin ja toteutuman seuranta paranee. Tiedon
jakaminen helpottuu kun kaikki tieto on yhdessä paikassa. Yleisesti sanottiin, että tietous
kyseisestä järjestelmästä, sen mahdollisuuksista ja toiminnasta, on vähäistä.
Uusi tuotetietojen hallintajärjestelmä oli monella aika tuntematon käsite. Järjestelmän nimi
oli kuultu, mutta ei tiedetty, miksi järjestelmä vaihdetaan. Muutama nimesi syyksi, että uusi
järjestelmä voidaan yhdistää toiminnan ohjausjärjestelmään ja sitä kautta käyttöön tulee
konsernitason järjestelmä, jolla tiedon jakaminen helpottuu ja toimintatavat yhtenäistyvät.
Uuden järjestelmän tavoitteeksi nimettiin pääasiassa yhteistyön paranemisen.
Tuotanto-osien hyväksyntäprosessi ei ollut kovinkaan tunnettu. Muutama henkilö nimesi
tavoitteeksi tuotekehityksen laadun parantamisen ja laadun varmistuksen käymällä asioita
läpi alihankkijan kanssa. Muuten käsite ei ollut tuttu.
Design for six sigma nimenä tunnistettiin. Se osattiin liittää laatuun, mutta pääsääntöisesti
odotettiin tulevia koulutuksia. Muutama osasi liittää DFSS toleranssien suunnitteluun ja
suunnittelun laadun parantamiseen vähentämällä virheitä tuotannossa. Tuleva koulutus
koettiin hyvänä asiana, mutta huolta aiheutti se, onko koulutuksen jälkeen aikaa perehtyä
työkalujen käyttöön.
Lean tuotekehitysprosessin käyttöönottoa pidettiin konsernin tahtotilana. Kaikilla ei ole
selkeää kuvaa, mitä Lean toiminnalla haetaan. Lean nähtiin toimintatapana, joka konkretisoi ja visualisoi projektia. Tehtävät, aikataulut ja tavoitteet ovat näkyvillä, jokainen tietää,
mitä tehdä ja missä vaiheessa. Näin toiminta tehostuu. Lean tuotekehitysprosessin tavoitteeksi osattiin nimetä läpimenoaikojen lyhenemisen, joka saavutetaan turhan työn ja odo-
76
tusajan poistamisella. Lean koulutuksen käyneet mainitsivat, että kohdeorganisaatiossa
Lean toiminnan reunaehto, max. 3 projektia henkilöllä, ei täyty. Lean on implementoitu
toimintaan, mutta ei ole mahdollisuutta käyttää sitä niin kuin on tarkoitus.
Yleisesti ottaen henkilökunnan ymmärrys uusista kehityshankkeista, niiden potentiaalista
ja miten ne vaikuttavat toimintaan, on heikolla tasolla. Järjestelmistä annettava koulutus
olisi avainasemassa järjestelmän implementoinnissa. Jo implementoitujen järjestelmien
osalta koulutus oli rajallista ja sen kautta tietämys järjestelmistä on heikkoa. Uusia järjestelmiä ei osata käyttää kunnolla ja ei tiedetä järjestelmien potentiaalia. Uusien järjestelmien osalta tulee panostaa koulutukseen ennen järjestelmän käyttöönottoa.
6.3 Yhteistyöorganisaatioiden palaute
Tuotekehityshenkilökunnan haastatteluiden tuloksista voi todeta, että tuotekehityksen
pääyhteistyötahot ovat osto, tuotehallinta ja valmistus. Saadakseen parannusehdotuksia
ja tietoa kehityskohteista haastateltiin yhteistyöorganisaatioiden edustajia tuotekehityksen
toiminnasta. Heiltä kysyttiin, mikä on hyvää tuotekehitystoiminnassa ja mitä tulisi parantaa.
Oston edustajista haastateltiin kolmea henkilöä, joiden kanssa on ollut yhteistyötä. Heidän
mukaan tuotekehitystoiminta on parantunut viime aikoina. Lean toimintatapa, jossa kaikki
sidosryhmät pääsevät osallistumaan aikatauluun, selkiyttää toimintaa. Nykyään oston
näkökulmasta aikataulut joustavat, jos reunaehdot muuttuvat. Aiemmin näin ei tapahtunut
ja seurauksena tehtiin paljon teknisiä kompromisseja ja pakkoratkaisuja. Tuotekehityksen
projektiorganisaatio ja projektipalaverit nähtiin hyvinä asioina. Toiminta koettiin järjestelmällisenä ja täsmällisenä. Koettiin, että tuotekehityspäällikkö tietää, mitä johtamallaan
osastolla tapahtuu.
Kehityskohteena oston edustajat kokivat sen, että tuotetta suunniteltaessa ei mietitä asioita tarpeeksi, etenkin tuotteen valmistettavuuden näkökulmasta. Valmistettavuutta ja valmistusta ei oteta huomioon suunnittelun aikana. Tuotteille pitäisi tehdä valmistettavuuskatselmus alihankkijan kanssa ennen valmistuksen aloitusta, eikä myöskään alihankkijan
prosessit ei täysin tuotekehityksen jäsenten tiedossa. Oston edustajat toivoivat, että alihankkija sitoutettaisiin projektiin vaiheessa, jossa tuotteelle tai osalle on vain pakolliset
rajoitukset määritelty. Tuotteen suunnittelua tehtäisiin yhdessä alihankkijan kanssa ja alihankkija pystyisi ehdottamaan valmistettavuuden kannalta sopivia ratkaisuja.
77
Oston edustajat kommentoivat, että usein projektien aikataulun näkyvyys huono ja se vaikeuttaa ennakointia alihankkijan suuntaan. Alihankkijan tarvitsemat investoinnit voivat
viivästyttää projektia, jos niitä ei ole otettu huomioon aikataula tehdessä. Lisäksi toivottiin
enemmän tietoa projektisuunnitelmasta, proto- ja tuotantomääristä. Käytettävissä oleva
budjetti vaikuttaa alihankkijan valintaan. Tuotannon ylösajovaiheessa tulisi saada selkeämpi käsitys siitä, mitä tilataan ja milloin.
Oston edustajien mukaan nyt muutoskierrosten lukumäärä työkalun tekijällä on korkea.
Tuotteen toiminnalliset välykset haetaan kokeilemalla. Muutospäätösten taustalle tarvitaan
enemmän analyysia, miksi muutetaan ja mihin vaikuttaa yms. Lisäksi alihankkijan kanssa
toimiessa turha hätäily tulisi lopettaa. Alihankkija tarvitsee aikaa tehdä asioita ja ajantarve
pitää ottaa huomioon aikataulutuksessa.
Tuotehallinnasta haastateltiin neljää tuotepäällikköä. Heidän mielestä yhteistyön taso tuotekehityksen kanssa on hyvä ja tuotekehitykseltä saa hyvin ja riittävästi tietoa. Tuotekehityksen osaamisen koettiin olevan hyvällä tasolla. Teknisesti projektien läpiviennin koettiin
olevan niin hyvällä tasolla kuin voi olla. Tuotepäälliköt ymmärsivät tuotekehityksen resurssitilanteen vaikutuksen aikatauluihin. Projektien vetäminen on parantunut, nyt toiminnassa
on enemmän suunnitelmallisuutta. Ennen keskityttiin reagoimaan tapahtuneeseen. Tuotepäälliköt kokivat tuotekehityksen dokumenttien tason hyväksi. Tuotteet koettiin laadullisesti hyviksi ja testaus on hyvällä tasolla. Lean toimintatavan lyhyet projektipalaverit nähtiin
hyvänä asiana. Ne ovat lyhyitä ja ytimekkäitä.
Tuotepäälliköt nimesivät tuotekehityksen kehityskohteeksi resursoinnin. Nyt yhdellä ihmisellä on liikaa projekteja työn alla samanaikaisesti. Jos yksi ihminen sairastuu, ei ole korvaajaa. Lisäksi uudet järjestelmät vievät resurssia projekteilta. Seurauksena projektien
aikataulut venyvät, minkä tuotepäälliköt näkivät kriittisimmäksi ongelmaksi. Aikatauluja
muodostaessa ollaan liian optimistisia ja seurauksena on venyminen. Venymisen myötä
myynnin aloituksen ennustaminen on vaikeaa. Tuotehallinta mainitsee tuotemäärittelyjen
muuttumisen vaikuttavan negatiivisesti aikatauluissa pysymiseen. Projektien seurantaa
tulisi lisätä ja syyt myöhästymisiin tulisi kirjata, että niistä tulisi näkyviä.
Osa tuotepäälliköistä toivoi tuotekehitykseltä lisää innovaatiotoimintaa. Nyt tuotekehitystoiminta keskittyy viemään tuoteprojektit tuotantoon, ei innovoimaan uutta. Tuotehallinnan
tehtäviin kuuluu liiketoiminnan kehitys 5-10v päähän, jonka pohjalta luodaan visio. Visiosta johdetaan uudet ratkaisut ja tuotteet yhdessä konsernin kanssa, joita kehittää projekteina tulevaisuudessa. Tuotekehitys voisi innovoida uusia ratkaisuja, joista tuotehallinta saisi
78
uusia näkökantoja uusien tuotteiden ideoimiseen. Innovoinnin lisäämiseen tarvitaan johdon tukea, koska innovaatiotoiminta on pois muulta työltä.
Valmistuksen puolelta haastateltiin valmistuksen toimihenkilöitä tuotekehitystoiminnasta.
Valmistus mainitsee tuotekehityksen hyviksi ominaisuuksiksi ryhmän. Ihmiset ovat iloisia
ja yhteistyö toimii. Ryhmän jäsenillä on myös motivaatiota parantaa toimintaa. Tuotantotestauksen ja ohjelmoinnin osalta tuotanto toimii hyvin ja tukea on saatavilla tarvittaessa.
Osto-osille on alettu määrittelemään laatuvaatimuksia ja määritykset on dokumentoitu.
Osto-osien laatu on myös parantunut. Aikataulujen suunnittelussa on tapahtunut parannusta ja oman valmistuksen kanssa lisääntyneen vuoropuhelun myötä suunnitelmat ottavat paremmin huomioon oman valmistuksen valmistusprosessin. Tuotekehityksen jäsenille on tulossa hyviä koulutuksia, joilla toimintaa ja toiminnan tuloksia on tarkoitus parantaa.
Mutta niitä tulee myös käyttää toiminnassa.
Valmistuksen edustajat mainitsevat tuotekehityksen kehityskohteiksi tuotteiden suunnittelun laadun. Tuotteiden käytännön toteutettavuus ei ole hyvällä tasolla. Puutteita on toleranssien suunnittelussa ja valmistusprosessien tietämyksessä. Lisäksi tuotteita tulisi testata enemmän toteutettavuuden varmistamiseksi. Tuotannon ylösajovaiheessa löytyy aina
jotain odottamatonta, mikä ei näy testeissä. Suunnittelutoiminnasta puuttuu systemaattisuus ja osat tulisi suunnitella valmistusta silmällä pitäen. Lisäksi valmistus painottaa valmistusprosessin riskianalyysin tekoa ja sen aikaista ajoitusta. Tuotantodokumenttien taso,
seuranta ja päivitys ovat heikolla tasolla.
Valmistuksen edustaja nostaa yhdeksi ongelmaksi sen, että tuotekehitysprosessiin on
määritelty pääasiassa laadullisia hyväksyntäkriteereitä, joita on helppo kiertää ja niin myös
tapahtuu käytännössä. Esimerkkinä käytettiin myynnin aloitusta ennen tuotantovalmiutta.
Myynnin aloituksen osalta ymmärretään, että se on ylemmän johdon päätös, ei tuotekehityksen. Prosessin alkupäässä pitäisi muuttaa asiakasvaatimukset teknisiksi spesifikaatioiksi. Enemmän aikaa tulisi käyttää vaatimusten analysointiin, mistä vaatimukset tulevat ja
mitä tehdään asiakkaan kannalta. Lisäksi todetaan, että tuotemääritelmät muuttuvat kesken kehitysvaiheen, mutta aikataulua ei päivitetä. Tuoteprojektien taustalle tulisi saada
paremmat tuotekuvaukset. Näin kehitysvaiheessa olisi vähemmän viivästyksiä.
6.4 Toiminnan parannusehdotukset
Sekä työntekijöiden että yhteistyötahojen edustajien haastatteluissa tuli esille ehdotuksia,
miten toimintaa parantaa. Suureksi ongelmaksi koettiin liiallinen tehtävien lukumäärä hen-
79
kilö kohden. Parannusehdotuksina esitettiin eniten projektien määrän vähentämistä ja
resurssien lisäämistä. Muita parannusehdotuksia tilanteeseen mainittiin ns. aikalisä, esim.
kaksi kuukautta, jonka aikana ei aloiteta uusia projekteja vaan keskitytään pelkästään
hoitamaan olemassa olevia projekteja loppuun.
Projekteille tulisi olla projektipäälliköt, jotka keskittyisivät yhteen projektiin kerrallaan tai
jotka keskittyisivät vain projektien vetämiseen. Näin projektin vetäjällä olisi aikaa analysoida tuotemäärityksiä ja tutkia syy-seuraussuhteita. Nyt projekteja on liikaa tai projektin vedon rinnalla on suunnittelutehtäviä. Liiallisten tehtävien vuoksi, ei ole mahdollisuutta keskittyä projektiin, sen suunnitteluun ja seurantaan. Haastatteluista tuli esille, että hyvä ja
osaava projektipäällikkö voi kompensoida projektia, jossa on tiukka aikataulu ja resurssit
vähäiset. Projektin vetäjiä tulisi myös kouluttaa rooliinsa.
Koska tuotekehityksen työntekijöillä on liian monta projektia menossa päällekkäin, tarvitaan priorisointia. Priorisointi on kohdeorganisaatiossa jo alkanut, mutta sitä pitää kehittää
lisää. Tehtävien priorisointi pitäisi tehdä tuotekehityspäällikön ja projektinvetäjien kesken.
Työntekijä ei ole oikea henkilö priorisoimaan tehtäviään. Priorisoinnissa tulee muistaa,
että tehtäviä ei voi olla liikaa kerralla, pitää keskittyä harvempiin tehtäviin. Priorisoinnissa
tulisi laittaa tehtävät jonoon.
Ylläpitotehtäviin tulisi olla määriteltynä henkilöt, joiden vastuulle kuuluvat alihankkijoiden
toimittaman laadun seuranta ja tuotannossa olevien tuotteiden ylläpito. Mikäli ylläpitohenkilö olisi olemassa, tuotekehitys pystyisi keskittymään projektitöihin. Mekaniikan osalta
tilanteen uskotaan paranevan tulevaisuudessa, koska mekaniikan ylläpitohenkilö on nimitetty. Elektroniikka puoli tarvitsisi oman ylläpitoon erikoistuneen henkilön.
Koettiin, että tuotekehityksen jäsenten toimenkuvia tulisi päivittää. Toimenkuvista pitäisi
selvitä, mitkä tehtävät kuuluvat tuotekehitykselle. Nyt koetaan, että tuotekehitys tekee
asioita, jotka eivät välttämättä kuulu tuotekehityksen vastuulle. Selkeät toimenkuvat auttaisivat ymmärtämään, mitkä tehtävät kuuluvat kohdeorganisaation henkilökunnalle ja
mitkä eivät.
Projektin suunnittelun pohjana on tuotekuvausdokumentti, jossa määritetään vaatimukset
tuotteelle. Tuotevaatimuksien tasoa pitää parantaa. Projektia aloitettaessa pitäisi analysoida tarkemmin, onko projekti oikeasti suppea ja vaatimuksille pitäisi tehdä enemmän
syy-seurausanalyysiä. Asiakasvaatimusten muuttamista teknisiksi vaatimuksiksi pitää
parantaa. Tuotekehityksen tulisi vaatia parempia tuotekuvauksia tuotehallinnalta ja analy-
80
soida itse tuotemääritelmiä, ovatko ne kohdillaan vai ei. Lisäksi tuotekehityksen pitäisi
osallistua tuotekuvauksen luomiseen yhdessä tuotehallinnan kanssa.
Aikataulujen osalta, isoissa projekteissa, jotka alkavat konseptivaiheesta, aikataulu tulisi
päivittää suunnitelmavaiheen jälkeen. Ei ole realistista olettaa, että aikataulu voidaan lyödä lukkoon konseptivaiheessa, jossa ei vielä osata sanoa tarkkaan, millainen tuote lopulta
on. Aikatauluja tulee myös päivittää, jos tuotemäärittelyt muuttuvat kesken prosessin tai
mukaan tulee uusia määrityksiä. Projekteissa tulee pitää seurantapalavereja ja mahdolliset syyt aikatauluviiveille tulee selvittää ja kirjata ylös. Lisäksi kaikkien sidosryhmien tulisi
osallistua aikataulujen tekemiseen. Projektin aikana aikataulu ja projektisuunnitelmat tulisi
olla näkyvillä kaikille projektiin osallistuville. Aikataulujen luomisessa tulee ottaa huomioon
alihankkijan toimintaan ja testauksen tarvitsema aika.
Haastatteluissa toivottiin omia tuotekehitysprojekteja ja tutkimustoimintaa. Näiden myötä
ideointi ja innovointi lisääntyisivät organisaatiossa. Tuoteideoinnille olisi kiinnostusta ja
siihen toivottiin ns. innovointipäiviä. Silloin voisi keskittyä ideoimaan ja analysoimaan ideoita ilman keskeytyksiä.
Tuotekehityksen toimitilan heikkoudeksi mainittiin avokonttorin yleinen hälinä ja työpäivän
aikana keskeytyksiä tulee paljon. Hälinän poistamiseksi ehdotettiin tuotekehitykselle omaa
tilaa. Lisäksi ehdotettiin mahdollisuutta etätyön tekemiseen, etenkin kun tehtävänä on
isompi tehtävä, jonka suorittaminen vaatii täyttä keskittymistä ilman keskeytyksiä.
Suunnittelun laadun parantamiseksi design for six sigma järjestelmä ja siihen kuuluvien
työkalujen käyttöön odotetaan parantavan toimintaa. Johdon tulee pitää huolta siitä, että
työntekijöillä on mahdollisuus käyttää työkaluja suunnittelutoiminnassaan koulutuksen
jälkeen. Osien laadun parantamiseksi ja korjauskierrosten määrän vähentämiseksi tuotesuunnitelmia tulisi analysoida enemmän ja paremmin. Jos muutoksia tehdään, syyseuraussuhteet tulee analysoida kunnolla. Ennen työkalujen ja protojen tilaamista, tuotesuunnitelmia tulisi katselmoida sisäisesti vertaiskatselmoinneilla. Suunnitelmien valmistettavuuskatselmointiin, valmistettavuuden arvioimiseen ja tarvittavien muutosten tekemiseen pitää osallistua jonkun muunkin kuin itse suunnittelijan.
Kehitetyt suunnitelmat tulisi katselmoida myös valitun alihankkijan kanssa ja alihankkijalta
tulee vaatia DFM analyysi suunnitelmasta ennen työkalujen aloittamista. Alihankkija tulee
ottaa mukaan nykyistä aiemmassa vaiheessa, ei vasta siinä kohdassa kun tuotesuunnitelma on valmis. Tuotekehityshenkilökunnan tulisi tuntea sekä alihankkijan että oman tuo-
81
tannon valmistusprosessien kyvykkyydet paremmin. Alihankkijoilla vierailut edistäisivät
heidän valmistusprosessien tuntemusta. Oman tuotannon kyvykkyyksien tuntemisen suhteen tulisi olla enemmän yhteistyötä oma tuotannon edustajien kanssa. Alihankkijan laadun varmistamiseksi, tulisi tehdä koe-eriä ja niiden taso tulisi varmistaa ja seurata. Lisäksi
tuotannon aikaisen laadun seuranta ei tulisi olla tuotekehitysorganisaation tehtävä vaan
ylläpidon.
Kehitettäviä tuotteita tulisi testata enemmän ennen myynnin ja tuotannon aloitusta. Testaamiselle tulisi antaa sen tarvitsema aika. Etenkin pilottitestaukseen asiakkaalla tulisi
panostaa enemmän. Sillä saa lisätietoa tuotteen toiminnasta kentällä ja asiakaspalautetta
tuotteesta, jonka pohjalta päätetään lanseerataanko tuote vai ei.
Uusien tuotteiden osalta tulee panostaa tuotannon työntekijöiden koulutukseen, kun uusi
tuote on tulossa tuotantoon. Näin tuotanto oppii ymmärtämään tuotteen ominaisuuksia.
Lisäksi tuotteiden myynti aloitetaan liian aikaisin, tuotteet eivät ole tuotantovalmiita. Päätös myynnin aloituksessa ei pitäisi tehdä ennen tuotantovalmiutta.
Ihmisten oma-aloitteisuuden lisäämiseksi ja toiminnan kokonaiskuvan selkeyttämiseksi
projektin aikataulun ja projektisuunnitelman tekemiseen tulee ottaa mukaan kaikki, jotka
osallistuvat projektiin. Lisäksi prosessin vaiheiden, tehtävien ja kriteerien selventäminen
työntekijöille auttaa heitä ymmärtämään, missä vaiheessa mitäkin pitää olla tehty. Kertausta prosessin vaiheista ja kriteereistä sekä toiminnan arviointimenetelmistä toivottin.
Kohdeorganisaation ja muiden yrityksen tuotekehitysyhteistyötä tulisi kasvattaa. Pitäisi
pyrkiä käyttämään muiden tieto taitoa hyväksi tarvittaessa. Lisäksi yhteistyön lisäämisellä
saa tietoa, mitä muualla tapahtuu ja voi miettiä, muiden osastojen tietoa käyttää hyväksi
omassa toiminnassaan.
Mittaamisen ja kehityshankkeiden osalta ei haastatteluista tullut esille mitään parannusehdotuksia. Haastatteluista tuli ilmi, ettei henkilökunta tunne täysin mittareita ja miten
niihin voi vaikuttaa.
82
7. JOHTOPÄÄTÖKSET
Tässä luvussa arvioidaan tutkimuksessa saatuja tuloksia ja verrataan niitä teoriassa läpikäytyihin asioihin. Lisäksi pohditaan suosituksia ja mahdollisia jatkotoimenpiteitä, joita
tämän tutkimuksen pohjalta voi tehdä. Luvussa 7.1 käydään läpi tutkimuksen tulokset ja
niiden suhde teoriaan. Luvussa 7.2 suositellaan mahdollisia jatkotutkimuksia.
7.1 Tutkimustulosten arviointi
Tuloksia arvioidaan tutkimuksen mukaisesti järjestyksessä. Luvussa 7.1.1 arvioidaan,
miten hyvin kohdeorganisaation dokumentoitu tuotekehitysprosessi vastaa teoriassa luotua mallia. Luvussa 7.1.2 arvioidaan tuotekehitystoimintaan liittyvien tulosten suhdetta
teoriaan.
7.1.1 Tuotekehitysprosessi
Tutkimuksen ensimmäinen osio käsitteli tuotekehitysprosessin vaiheita ja niihin vaikuttavia
tekijöitä. Kirjallisuustutkimuksen tuloksena löytyivät tuotekehitysprosessin vaiheet ja vaiheisiin liittyviä menestystekijöitä. Kirjallisuuteen pohjautuva prosessi sisältää vaiheet ideoiden luominen ja niiden arviointi, konseptien kehitysvaihe, järjestelmätason suunnitteluvaihe, kehitysvaihe, testausvaihe ja tuotannon ylösajo. Kirjallisuudesta löytyy vaiheisiin
liittyviä kriittisiä tekijöitä. Vaiheiden väliin on määritelty katselmointipisteitä, joille on määritelty menestystekijöitä. (katso esim. Ulrich & Eppinger 2003, s. 23; Cooper 2000, s.59)
Kohdeorganisaation dokumenttien tarkastelun tuloksena voi todeta, että kohdeorganisaatiolla on dokumentoitu tuotekehitysprosessi. Prosessille on määritelty vaiheita ja vaiheille
tehtäviä, jotka pitää olla tehtynä. Vaiheiden väleihin on määritelty katselmointipisteitä ja
vastuut tehtävistä on dokumentoitu. Kohdeorganisaation dokumentoidun tuotekehitysprosessin osalta voi todeta, että mitä lähemmäksi lanseerausta dokumentoitu prosessi siirtyy,
sen paremmin dokumentoitu prosessi vastaa teorian määritelmiä. Kohdeorganisaation
vaiheiden kriteerit eivät täysin vastaa teoriamääritelmiä ja prosessin etupään vaiheiden
toimintoja tulisi painottaa enemmän.
7.1.2 Tuotekehitystoiminta
Tuotekehitystoimintaa tutkittiin työntekijänäkökulmasta ja pyrittiin kartoittamaan tuotekehitysprosessin ja toiminnan nykytilaa pienikokoisessa organisaatiossa. Lisäksi tavoite oli
löytää tapoja, joilla parantaa toimintaa. Kirjallisuustutkimuksessa löytyi tuotekehityspro-
83
sessin vaiheet ja vaiheille kriteereitä. Lisäksi selvisi, mitkä tekijät vaikuttavat tuotekehityksen suorituskykyyn. Haastatteluiden pohjalta saatiin selville, mitkä ovat kohdeorganisaation vahvuudet ja mitkä ovat sen kehityskohteet. Lisäksi esiin nousi parannusehdotuksia.
Kohdeorganisaatio tuotekehitystoiminnan vahvuuksia ja kehityskohteita tutkittiin haastattelemalla kohdeorganisaation henkilökuntaa. Tuotekehityksen suurimmaksi vahvuudeksi
nimettiin työntekijät, heidän osaaminen, asenne ja heidän motivaatio parantaa toimintaa.
Työilmapiiri ja yhteishenki koettiin hyväksi. Lisäksi on havaittu toimintatavoissa muutoksia,
jotka koettiin hyvänä asiana. Tuotekehityksen ja oston, tuotepäälliköiden ja valmistuksen
välisen yhteistyöntaso koetaan hyväksi kaikissa toiminnoissa.
Andersson (2008, s.554) toteaa, että yrityksen ilmapiiri luo paremman perustan jatkuvalle
innovaatiotoiminnalle kuin johtamistekniikat, prosessit ja käytännöt. Mm. Park (2007,
s.110) ja Slotegraaf & Atuahene-Gima (2011, s.103) toteavat, että projektiryhmien laatuun
liittyy tehokas kommunikointi ja tiedon jakaminen. Kohdeorganisaatiossa on ilmapiiri kunnossa, ihmiset viihtyvät hyvin toistensa kanssa ja yhteistyö sujuu hyvin niiden toimintojen
kanssa, joiden kanssa on kanssakäymistä. Tulosten perusteella voi sanoa, että kohdeorganisaatiolla on tuotekehitysmenestystekijöistä ilmapiiri ja laadukas projektiryhmä.
Tuotekehitystoiminnan suurimpana ongelmana nähtiin projektiaikataulujen venyminen.
Syitä tähän oli liian optimisten aikataulujen tekeminen, perustuen oletukseen, että resurssit ovat heti saatavilla ja ne voivat keskittyä täysin projektiin. Käytännössä näin ei ole. Uusia projekteja aloitetaan ennen kuin vanhat on valmiita. Tästä seuraa, että tuotekehitysryhmän jäsenillä on monia projekteja menossa samaan aikaan ja projektien päälle on vielä tuotannon ylläpitotehtävät. Cooper & Kleinschmidt (2007, s.62) ovat määritelleet yhdeksi tuotekehityksen menestystekijäksi riittävät resurssit ja sen, että projekteja ei tulisi aloittaa ennen kuin resurssit on saatavilla. Lisäksi tuotekehitysryhmän pitäisi keskittyä vain
kehitystyöhön. Resursoinnin osalta kohdeorganisaatiolla on parannettavaa. Toiminnan
parantamiseksi on jo aloitettu tehtävien priorisointi ja ylläpitotehtävien vähentämiseksi on
mekaniikan osalta tulossa ylläpitovastuussa oleva henkilö, joka ei työskentele projekteissa.
Kohdeorganisaatiolla on dokumentoitu tuotekehitysprosessi, mutta siinä on paljon laadullisia kriteereitä, joita usein kierretään, esim. myynti aloitetaan liian aikaisin. Tuotekehityshenkilökunnan prosessin tuntemus vaihtelee. Osa osaa järjestää toimintansa prosessin
mukaan ja tietää, mitä heiltä odotetaan. Osa tarvitsee ohjausta, mitä tehdä ja milloin. Ihmisten vastuuttamiseksi omasta toiminnasta ja oma-aloitteisuuden lisääntymiseksi pro-
84
sessitietoutta tulisi nostaa, esim. kertauksella ja koulutuksella. Toimintaan mukaan tuodussa Lean toimintatavassa aikataulu on näkyvillä ja siihen merkitty prosessivaiheet. Mm.
Cooper (2000, s.28), Bassani et al. (2010, s.482-483) ja Shepherd & Pervaiz (2000, s.
167-168) toteavat, että hyvin dokumentoidulla ja tehokkaasti käytetyllä prosessilla saadaan etua. Kohdeorganisaatiossa prosessin tehokasta käyttöä vaikeuttaa vaihteleva tietämys prosessin vaiheista ja niihin liittyvistä kriteereistä.
Park (2007, s.105) mainitsee tutkimuksessaan, että kehiteltävät tuotteet tulisi olla tuotekehitysstrategian mukaisia ja prosessin alkuvaiheessa tulisi olla paljon ideoita, joita tutkitaan
tarkemmin. Kohdeorganisaatiossa työntekijät eivät tunne tuotekehitysstrategiaa, joten
tuotteiden strategiamukaisuuden arvioiminen ei ole mahdollista. Strategian kertauksella
voi avata henkilökunnalle enemmän, mitä toiminnalla tavoitellaan ja mitä henkilökunnalta
odotetaan.
Kohdeorganisaation työntekijät kokevat, että tuotekehitystoiminta käsittää pääasiassa
muiden suunnittelemien tuotteiden tuotantoon viemistä ja tuoteparannuksia. Haastatteluissa pohdittiin myös tuotekehitysfunktion tarvetta, jos ei ole omaa kehitystoimintaa. Kiinnostusta ideointiin, innovointiin ja kehitystyöhön olisi, jos siihen annetaan mahdollisuus.
Lisäksi tuotehallinnan toive olisi saada uusia ideoita tuotekehitykseltä pitkän aikavälin vision luomiseen. Andersson (2008, s.559-560) mainitsee, että jatkuva innovointi, joka on
yksi tuotekehitystoiminnan jatkuvan menestyksen avaintekijä. Kohdeorganisaatiossa innovointitaso on tulosten mukaan heikolla tasolla. Innovoinnin ja ideoiden lisäämiseksi
kohdeorganisaation tulisi järjestää mahdollisuus ideointiin ja kartoittaa mahdollisuudet
oman kehitystoiminnan tekemiseksi.
Mm. Matzler & Hinterhuber (1998, s.26), Cooper (2000, s.55), Suomala & Jokioinen
(2003, s. 225) toteavat, että asiakastarpeiden ymmärtäminen on tärkeää tuotekehityksessä. Se ohjaa päätöksentekoa ja auttaa oikeiden painottamaan oikeita tekijöitä tuotteessa.
Tuloksista käy ilmi, että kohdeorganisaation tuotekehityshenkilökunnalla ei ole tietoa asiakastarpeista tuotteita kehiteltäessä. Tuotepäällikkö nähtiin pääasiallisena tiedon lähteenä,
mutta perimmäinen asiakastarve, mihin tilanteeseen tuotetta tarvitaan, jää epäselväksi.
Markkinapalautetta, lukuun ottamatta reklamaatioita, valmiista projektista ei myöskään
saada. Asiakastarpeen tuntemus ja markkinatietous on kohdeorganisaatiossa heikolla
tasolla. Tilanteen korjaamiseksi kohdeorganisaatio voi pyytää tuotehallintaa avaamaan
asiakastarpeita ja esittelemään tehtyjä markkina-analyysejä.
85
Mm. Ulrich & Eppinger (2003, s.16) ja Cooper (2000, s.55) määrittelevät projektien valinnan ja tuotemääritelmät tuotekehitystoiminnan menestymisen kulmakiviksi. Kohdeorganisaation työntekijät eivät koe osallistuvana projektien valintaan. Tuotemääritelmiin tai tuotekuvauksiin ei myöskään osallistuta. Kohdeorganisaatiossa käytettävän tuotekehitysprosessin mukaan projektien valinta ja tuotemääritelmät ovat tuotehallinnan vastuualueita.
Tuotemääritelmät koetaan pääasiassa epämääräisiksi ja ne muuttuvat projektin aikana
venyttäen aikataulua. Kohdeorganisaatiossa tulisi alkaa analysoimaan määritelmiä ennen
projektin alkua ja tarvittaessa kyseenalaistaa määritelmät, ts. vaatia parempia määritelmiä
suunnittelun pohjaksi.
Tuotteet ja niissä käytetty teknologia on tuotekehityksen menestystekijöitä, kuten esim.
Suomala & Jokioinen (2003, s.225) toteavat. Kohdeorganisaation työntekijät kokevat, että
tuotteet ovat melko hyvällä tasolla kilpailijoihin nähden. Tulosten mukaan koettiin, että
teknologiamielessä osa kilpailijoista on edelle. Pitäisi panostaa enemmän asiakastarpeiden ennakointiin ja omaan kehitykseen. Kohdeorganisaatio voi omalla tuotekehitystoiminnallaan vaikuttaa tähän.
Cooper & Kleinschmidt (2007, s.63-64) ovat todenneet, että projektinvetäjä, joka voi keskittyä yhteen projektiin kerralla, on yksi tuotekehityksen menestystekijä. Kohdeorganisaatiossa projektinvetäjillä on monta projektia hoidettavana tai he toimivat myös suunnittelijoina. Yksi projekti vetäjää kohti ei nykyisellä resurssitilanteella kohdeorganisaatiossa välttämättä onnistu ja aina projektit eivät ole tarpeeksi suuria, että vetäjän keskittyminen yhteen projektiin olisi järkevää. Kohdeorganisaatio voi miettiä auttaisiko, jos valittaisiin projektin vetäjiä, jotka keskittyisivät vain projektien vetämiseen ja eivät keskittyisi tuotesuunnitteluun. Kohdeorganisaatiossa on jo projektin vetäjille tulossa koulutusta heidän osaamisen lisäämiseksi.
Ylemmän johdon tukea painotetaan menestyksen perustana (katso esim. Suomala & Jokioinen 2003, s.225; Cooper 200, s.55-57). Ylempi johto mm. allokoi resurssit projekteille.
Kohdeorganisaatiossa ei täysin uskota, että ylempi johto ymmärtää tuotekehityksen resurssitilanteen ja tehtävien määrän. Yksi peruste uskomukseen on se, että uusia projekteja aloitetaan ilman, että vanhoja on saatu valmiiksi. Kohdeorganisaatiossa ylempi johto
osallistuu projektien katselmointeihin ja päätöksiin projektin jatkosta. Ylemmän johdon
tukea tarvitaan resurssitilanteen parantamiseksi. Uusia projekteja ei tulisi aloittaa ennen
kuin vanhoja saadaan valmiiksi ja johdon tulisi osallistua jo aloitettuun tehtävien priorisointiin.
86
Mm. Ayers et al. (2011, s. 134-135) ja Brettel et al. (2011, s.262) painottavat tuotekehityksen menestymisen kannalta toimintojen välistä yhteistyötä, etenkin markkinoinnin ja tuotekehityksen välillä. Markkinointia pidetään yrityksen parhaimpana asiantuntijana yrityksen
asiakkaista. Kohdeorganisaation pääyhteistyötahot ovat osto, tuotehallinta ja valmistus,
joiden kanssa yhteistyön koetaan sujuvan hyvin. Osto edustajat toivovat parempaa tiedon
siirtoa projektiin liittyvistä tavoitteista tuotekehitykseltä ja tuotannon edustajat valmistettavuuden huomioimista suunnittelusta. Tuotehallinnan tuotepäälliköt edustavat asiakasta
projektissa. Muihin toimintoihin ja toisiin tuotekehitysorganisaatioihin on hyvin vähän
kanssakäymistä. Kohdeorganisaatio voi pohtia, olisi yhteistyöstä muiden tuotekehitysorganisaatioiden sekä muiden toimintojen, kuten esim. myynti, hyötyä omalle toiminnalle.
Toinen pohdittava asia olisi, millaista yhteistyö olisi.
Tuotanto ja osto toivovat tuotekehitykseltä tuotesuunnitelmia, joissa valmistettavuus on
paremmin otettu huomioon. Alihankkijan mukaan tuominen prosessin alkuvaiheissa parantaa tuotesuunnittelun laatua, kuten esim. Handfield & Lawson (2007, s.49) mainitsevat.
Kohdeorganisaatiossa alihankkija tulee mukaan yleensä siinä vaiheessa, suunnitelmat
ovat lähes valmiit. Sekä tuotekehitys että osto toivoisivat, että alihankkija otettaisiin mukaan aikaisemmassa vaiheessa tuotteen suunnitteluun. Miksi näin ei tapahdu, on kohdeorganisaation löydettävä vastaus tähän. Lisäksi kohdeorganisaatiossa on alettu panostamaan tuotesuunnittelun parantamiseen tuomalla mukaan analysointi yökaluja. Niiden
käyttö on toistaiseksi vähäistä ajan puutteen vuoksi.
Cooper (2006, s.21) on todennut, että tuotekehitystä ei voi pitää vastuullisena toiminnastaan, jos sen toimintaa ei mitata ja arvioida. Tuotekehityksen toiminnan taso arvioidaan
sen suorituskykyä mittaamalla. Chiesa & Frattini (2007a, s.258-286) ovat todenneet, että
mittaaminen onnistuu paremmin ja saadaan luotettavamaa tietoa, mittauksen kohteena
olevat ymmärtävät, mitä mitataan, miksi mitataan ja miten niihin voi vaikuttaa.
Kohdeorganisaatio on määritellyt mittareita, joilla mitataan tuotekehityksen suorituskykyä.
Käytävälle on asetettu taulu, josta käy ilmi mittarit, niiden tavoitearvot ja nykytilat, joten
mittarit ja niistä saatu tieto on kaikille näkyvillä. Haastatteluissa esille tulleiden asioiden
pohjalta voi todeta, että henkilökunta ei ole täysin ymmärtänyt, mitä mitataan. Tuotekehityksen suoristuskykymittareita kysyttäessä yksikään työntekijä ei osannut nimetä kaikkia
mittareita. Kaikki eivät osanneet linkittää käytävällä olevaa taulua suorituskykymittareiksi.
Joistain mittareista ei ymmärretä, mitä ne tarkoittavat. Koska ei tiedetä, mitä mitataan tai
mitä mittari tarkoittaa, ei ymmärretä, miksi ko. mittari käytetään. Lisäksi, miten tuloksiin voi
87
vaikuttaa, on epäselvää. Kohdeorganisaation johdon tulisi avata mittareita, niiden tarkoituksia ja vaikutusmahdollisuuksia henkilökunnalle.
7.2 Jatkotoimenpiteet ja suositukset
Kohdeorganisaatiossa on haasteita parantaa toimintaa. Dokumentoitua tuotekehitysprosessia voisi päivittää. Kriteerejä lisätä ja muuttaa laadullisia kriteerejä sellaisiksi, ettei niitä
olisi helppo kiertää. Lisäksi tarvitaan enemmän painoa prosessin etupään aktiviteetteihin,
etenkin tuotekuvauksen luomiseen. Tuotekuvausten tulee olla laadukkaita ja määritelmien
hyvin analysoitu. Erityisesti tulee panostaa analyysiin, jossa asiakasvaatimukset muutetaan teknisiksi vaatimuksiksi. Aliprosessin kehittämistä tuotekuvauksen tekoon voi miettiä.
Lisäksi tuotekehityksen tulisi aloittaa itse tuotekuvauksen analysointi.
Kohdeorganisaatiossa on alettu panostamaan tuotesuunnittelun laadun parantamiseen.
Toimintaan on tullut ja on tulossa erilaisia työkaluja, joiden avulla analysoida suunnitelmia
ja parantaa laatua ennen prototyyppien ja työkalujen tilaamista. Työkaluista ja niiden koulutuksesta ei ole hyötyä, jos niitä ei käytä. Organisaation tulisi panostaa, että työntekijöillä
on aikaa käyttää analysointityökaluja.
Lisäksi vertaistarkastukset suunnitelmille voi auttaa suunnitelmien laadun parantamista.
Myös alihankkijan mukaan ottaminen suunnitteluun ja heidän tekemät valmistusanalyysit
parantaisivat laatua. Suunnitelmien pohjalta valmistettaville prototyyppejä tulisi testata
enemmän ja analysoida tuloksia tarkemmin. Prosessiin tulisi lisätä analyysien tekeminen,
vertaistarkastukset ja valmistusanalyysit hyväksyntäkriteereiksi ja seurata projektin aikana, että em. tehdään.
Analyysien teko on aikaa vievää ja vaatii keskittymistä. Nyt työtila koettiin meluisana ja
työpäivän aikana työ keskeytyy usein. Analyysin teon vaatiman ympäristön saavuttamiseksi, etätyö mahdollisuutta tulisi harkita.
Tuotekehitystoiminnassa suurin haaste on resurssien määrä suhteessa työtehtävien määrään. Työntekijöillä on liikaa tehtäviä hoidettavana. Toiminnan parantamiseksi on aloitettu
jo tehtävien priorisointi, mutta priorisoinnissa on vielä tehtävää. Priorisointiin voi miettiä
järjestelmällisempää tapaa toimia ja priorisoinnista sopivan ryhmän kokoonpanoa. Lisäksi
voi miettiä ns. aika lisää, jonka aikana ei aloiteta uusia projekteja vaan keskitytään vanhojen läpiviemiseen.
88
Myös ihmisten oma-aloitteisuuden lisäämiseksi tulee pyrkiä selventämään projektien kokonaiskuvaa ja prosessin vaatimuksia työntekijöille. Prosessivaiheiden tuntemusta voi
lisätä läpikäynnillä ja projektin aloitusvaiheessa jäsenet tulisi ottaa mukaan määrittelemään projektisuunnitelmaa ja tuotemäärittelyjä sekä jäsenten tulisi saada tietoa asiakastarpeesta vaatimuksen takana. Lisäksi tuotekehitystoiminnan mittareiden tuntemuksen
lisäämiseksi kertaus mittareista ja mittaamisen syistä voi parantaa toimintaa. Työntekijöiden toimenkuvien päivitys voisi selventää, mitkä kaikki tehtävät kuuluvat työntekijän tehtäväksi.
Uusien tuotteiden osalta prosessiin tulisi lisätä tuotannon työntekijöiden koulutus uusista
tuotantoon tulevista osista. Koulutusta on tehty aikaisemmin ja se on koettu positiivisena
asiana. Koulutuksen sisällöstä, ajankohdasta ja osallistujista ei ole mitään ohjeistusta, sen
järjestäminen on projektien arvioinnin varassa. Ohjeistus yhtenäistäisi toimintaa.
Innovointi ja ideointi ovat heikolla tasolla kohdeorganisaatiossa. Työntekijöillä olisi kiinnostusta em. toimintaan. Innovoinnin ja ideoinnin lisäämiseksi tulisi tutkia mahdollisuuksia ja
keinoja, miten innovaatiotoimintaa kehittää organisaatiossa. Tässä olisi aihe toiseen tutkimukseen
89
8. YHTEENVETO
Yritykset toimiva nykyään kilpailluilla markkinoilla ja niiden elinehto on tuoda markkinoille
asiakastarpeita vastaavia tuotteita. Tuotteiden elinkaarien lyheneminen ja teknologioiden
nopea kehittyminen aiheuttavat sen, että tuotteiden kehittämiseen käytettävissä oleva aika
lyhenee. Lyhyemmät tuotekehitysajat vaativat tehokasta tuotekehitystä. Ollakseen menestyvä, tuotekehityksen tulee tehdä oikeita asioita ja tehdä asioita oikein. Lisäksi toiminnan
arvioimiseksi tuotekehitystoiminnan mittaaminen on välttämätöntä.
Tutkimuksen tavoite selvittää tuotekehitysprosessin vaiheet ja niihin vaikuttavia tekijöitä
sekä löytää keinoja, joilla parantaa pienikokoisen tuotekehitysorganisaation tuotekehitysprosessia ja tuotekehitystoimintaa. Tutkimusote on toiminta-analyyttinen. Tutkimuksen
kohdeorganisaatio on elektromekaanisten tuotteiden valmistukseen keskittynyt pienikokoinen tuotekehitysorganisaatio. Kohdeorganisaation tuotekehitystoiminta keskittyy pääasiassa uusien tuotteiden markkinoille tuomiseen.
Tutkimuksessa teoriaosiossa tutkittiin, mitä vaiheita tuotekehitysprosessiin kuuluu ja mitkä
tekijät vaikuttavat niihin. Lisäksi haettiin menestyvään tuotekehitykseen liittyviä menestystekijöitä. Suorituskyvyn mittaamisen osalta selvitettiin mittaamiseen vaikuttavia tekijöitä.
Empiirisen osan ensimmäisessä kohdassa tutkittiin kohdeorganisaation dokumentoitua
tuotekehitysprosessia, sen vaiheita ja kriteerejä. Kohdeorganisaation prosessia verrattiin
teoriatietoon ja haettiin eroavaisuudet. Prosessivertailu tehtiin dokumenttitarkasteluna.
Tuotekehitystoiminnan nykytilaa tutkittiin haastattelemalla organisaatiossa työskenteleviä
henkilöitä ja yhteistyötahojen edustajia. Haastattelut suoritettiin yksilöhaastatteluina.
Haastattelussa käsiteltiin tuotekehitysorganisaation ja –toiminnan vahvuuksia ja kehityskohteita sekä jo suunnitteilla olevia kehityshankkeita. Lisäksi kysyttiin toiminnan parannusehdotuksia sekä selvitettiin suorituskyvyn mittaamisen nykytila tuotekehityshenkilökunnan näkökulmasta.
Dokumenttitarkastelun tuloksena voi todeta, että kohdeorganisaatiolla on dokumentoitu
tuotekehitysprosessi, josta käy ilmi vaiheet, tehtävät ja tehtävien vastuut. Lisäksi prosessiin on määritelty katselmointipisteen vaiheiden väliin. Mitä lähemmäksi prosessin loppupäätä mennään, sen paremmin kohdeorganisaation prosessi vastaa teoriamääritelmiä.
Kohdeorganisaation prosessi poikkeaa eniten alkupään osalta. Teoria painottaa enemmän alkupään vaiheissa ideointia ja ideoiden pohjalta kehiteltävien konseptien analysointia. Kohdeorganisaation tuotekehitysprosessia tulisi päivittää ja kriteerejä selventää sekä
painottaa etupään toimintoja.
90
Haastattelujen tuloksista voidaan todeta, että kohdeorganisaation vahvuudet ovat laadukas projektiryhmä ja ilmapiiri. Projektiryhmä koostuu ihmisistä ja heidän vahvuuksiksi nähtiin osaaminen, asenne, motivaatio parantaa ja tiedon jakaminen. Suurimmaksi kehityskohteeksi koettiin resurssitilanne. Nyt työntekijöillä on liikaa tehtäviä työn alla samanaikaisesti. Seurauksena on mm. aikataulujen venyminen ja suunnittelun laadun heikkeneminen. Tuotemäärittelyn tason koettiin heikentävän toiminnan laatua, usein ne muuttuvat
prosessin aikana. Tuotemäärittelyjen taustalla oleva asiakastarve jää kohdeorganisaation
henkilökunnalta pimentoon. Dokumentoidun prosessin tuntemus vaihteli. Oma-aloitteisen
toiminnan lisäämiseksi tarvitaan kokonaiskuvan tuntemusta, johon liittyy prosessin kriteerien ja asiakastarpeiden tunteminen. Suunnittelutoimintaan toivottiin enemmän analyysia
ja testausta. Tuotekehitystoiminta nähtiin pääasiassa valmiiden suunnitelmien tuotteistamisena ja sen myötä innovatiivisuus ja ideointi ovat heikolla tasolla vaikka kiinnostusta
niihin onkin. Työskentelytila ei ole rauhallinen ja päivän mittaan keskeytyksiä tulee paljon,
mikä vaikeuttaa suunnittelutyötä.
Toiminnan mittaamisesta haastatteluissa selvisi, että henkilökunta ei täysin ymmärrä, miten toimintaa arvioidaan ja millä kriteereillä. Koska mittarit ja tavoitteet ovat epäselvät, ei
osata sanoa, miten tuloksiin voi vaikuttaa. Kohdeorganisaation kehityshankkeista ei juuri
tiedetty, mitä niillä tavoitellaan ja miksi ne implementoidaan toimintaan.
Parannusehdotuksissa ehdotettiin resurssitilanteen ratkaisemiseksi tehtävien priorisointia,
tehtävien vähentämistä ja resurssien lisäämistä. Muita toiminnan parannusehdotuksia
olivat analyysien lisääminen tuotemääritelmiin ja itse suunnittelutyössä. Kokonaiskuvan
hahmottamiseksi ja oma-aloitteisuuden parantamiseksi ehdotettiin kertausta ja koulutusta
prosessista, asiakastarpeista yms. Lisäksi toivottiin omaa tutkimus- ja kehitystoimintaa ja
sen myötä aikaa innovoinnille ja ideoinnille. Työrauhan saamiseksi ehdotettiin mahdollisuutta etätyöhön. Toimintaan on jo otettu toimintaa parantavia asioita, kuten tehtävien
priorisointi, mutta kehitettävää on vielä.
Tutkimuksessa saatiin selville tuotekehitysprosessin vaiheet ja vaiheisiin vaikuttavat tekijät
sekä sen, miten kohdeorganisaation prosessi eroaa teorian vastaavasta. Haastatteluilla
saatiin tietoa kohdeorganisaation tuotekehitystoiminnan nykytilasta ja parannusehdotuksia. Tutkimuksen tulosten pohjalta voi todeta, että tutkimuksen alussa määritellyt tavoitteet
saavutettiin.
91
LÄHTEET
Adams, R., Bessant, J. & Phelps, R. 2006. Innovation management measurement: a review. International journal of management reviews. Vol. 8, nro. 1, s. 21-47
Aguinis, H., Joo, H. & Gottfredson, R. K. 2011. Why we hate performance management –
and why we should love it. Business horizons. Vol. 54, s. 503-507
Ancona, D. G. & Caldwell, D. 2007. Improving the performance of new product teams.
Research Technology Management. September-October, s. 37-43
Anderson, A. M. 2008. A framework for NPD management: doing the right things, doing
them right and measuring results. Trends in Food science & technology. Vol. 19, s. 553561
Antony, J. 2002. Design for six sigma: a breakthrough business improvement strategy for
achieving competitive advantages. Work study. Vol. 51, nro. 1, s. 6-8
Atkinson, R. 1999. Project management: cost, time and quality, two best guesses and a
phenomenon, it’s time to accept other success criteria. International journal of project
management. Vol. 17, nro. 6, s. 337-342
Ayers, D. J., Gordon, G. L. & Schoenbachler, D. D. 2011. Integration and new product
development success: the role of formal and informal controls. The journal of applied
business research. Vol. 17, nro. 2, s. 133-148
Bassani, C., Lazzarotti, V., Manzini, R., Pellegrini, L. & Santomauro, S. 2010. Measuring
performance in R&NPD. European journal of Innovation management. Vol. 13, no. 4, s.
481-506
Bhuiyan, N. 2011. A framework for successful new product development. Journal of Industrial Engineering and Management. Vol. 4, nro. 4, s. 746-770
Bigliardi, B. & Dormio, A. I. 2010. A balanced scorecard approach for R&D: evidence from
a case study. Facilities. Vol. 28, nro. 5/6, s. 278-289
Bourne, M., Mills, J., Wilcox, M., Neely, A. & Platts, K. 2000. Designing, implementing an
updating performance measurement systems. International Journal of operations & production management. Vol. 20, nro.7, s. 754-771
92
Bremser, W. G. & Barsky, N. P. 2004. Utilizing the balanced scorecard for R&D performance measurement. R&D Management. Vol. 34, nro. 3, s. 229-238
Brettel, M., Heinemann, F., Engelen, A. & Neubauer, S. 2011. Cross-functional integration
of R&D, Marketing and Manufacturing in Radical and incremental product innovations and
its effects on project effectiveness and efficiency. Journal of product innovation management. Vol. 28, s. 251-269
Brown, M. G. & Svenson, R. A. 1988. Measuring R&D productivity. Research technology
management. Vol. 31, nro 4, s. 11-15
Brudan, A. 2010. Rediscovering performance management: systems, learning and integration. Measuring Business Excellence. Vol. 14, nro. 1, s. 109–123
Buganza, T., Gerst, M. & Verganti, R. 2010. Adoption of NPD flexibility practices in new
technology-based firms. European Journal of innovation management. Vol. 13, nro.1 s.
62-80
Byrne, G. 2003. Ensuring optimal success with six sigma implementation. Journal of organizational excellence. Spring 2003, s. 43-50
Cadden, T. & Downes, S.J. 2013. Developing a business process for product development. Business Process management journal. Vol. 19, nro 4, s. 715-736
Cagan, J. & Vogel, C.M. 2003. Kehitä kärki tuote. Helsinki, Talentum. 413 s. ISBN 952-140669-0
Chen, H. H., Lee, A.H.I & Tong, Y. 2006. New product mix selection for a high technology
company in a technology innovation network. Journal of Technology Management in China. Vol. 1, nro. 2, s. 174-189
Chiesa, V., Frattini, F., Lazzarotti, V. & Manzini, R. 2009. Performance measurement of
research and development activities. European Journal of Innovation Management. Vol.
12, nro. 1, s. 25-61
Chiesa, V., Frattini, F., Lazzarotti, V. & Manzini, R. 2009a. Performance measurement in
R&D: exploring the interplay between measurement dimensions of performance and contextual factors. R&D Management. Vol. 39, nro. 5, s. 488-519
93
Chiesa, V., Frattini, F., Lazzarotti, V., Manzini, R. & Troja, I. 2008. An exploratory study on
R&D performance measurement practices: a survey of Italian R&D intensive firms. Luic
Papers. Nro. 218, Serie Tecnologia 14, s. 1-36
Chiesa, V. & Frattini, F. 2007. How do measurement objectives influence the R&D performance system design? Management Research News. Vol. 30, nro. 3, s. 187-202
Chiesa, V. & Frattini, F. 2007a. Exploring the differences in performance measurement
between research and development: evidence from a multiple case study. R&D Management. Vol. 37, nro. 4, s. 283-301
Chiesa, V., Frattini, F., Lazzarotti, V. & Manzini, R. 2007. Measuring performance in new
product development projects: a case study in the aerospace industry. Project management journal. Vol. 38, nro. 4, s. 45-59
Chiesa, V. & Masella, C. 1996. Searching for an effective measure of R&D performance.
Management Decision. Vol. 34, nro. 7, s. 49-57
Cho, E & Lee, M. 2005. An exploratory study on contingency factors affecting R&D performance measurement. International Journal on Manpower. Vol. 26, nro. 6, s. 502-512
Cooper, R. G. & Edgett, S. J. 2012. Best Practices in the Idea-to-Launch Process and Its
governance. Research Technology management. Vol. 55, issue 2, s. 43-54
Cooper, R. G. & Kleinschmidt, E. J. 2007. Winning business in product development: the
critical success factors. Research Technology management. Vol.50, issue 3, s. 52-66
Cooper, R. G. 2006. Formula for success. Marketing Management. Vol. 15, issue 2, s. 1824
Cooper, R. G. & Kleinschmidt, E. 2004. Benchmarking best NPD practices I. Research
technology management. Vol. 47, nro. 1, s. 31-43
Cooper, R. G. 2000. Doing it Right: winning with new products. Ivey Business Journal.
Vol. 64, issue 6, s. 54-60
Cooper, R. G. 1999. From experience: The invisible success factors in product innovation.
Journal of product innovation management. Vol. 16, nro 2, s. 115-133
94
Cooper, R. G. & Kleinschmidt, E. J. 1995. Benchmarking the firm’s critical success factors
in new product development. Journal of product innovation management. Vol. 12, s. 374391
Cooper, R. G. 1988. The new product process: a decision guide for management. Journal
of Marketing Management. Vol. 3, nro 3, s. 238-255
Davila, T. 2000. An empirical study on the drivers of management control system’s design
in new product development. Accounting, Organizations and Society. Vol. 25, s. 383-409
Driva, H., Pawar, K.S. & Menon, U. 2000. Measuring product development performance in
manufacturing organizations. International journal of production economics. Nro. 6, s.174159
Fuchs, C. & Schreier, M. 2010. Customer empowerment in New product development.
Journal of product innovation management. Vol. 28, s. 17-32
Garcia-Valderrama, T., Mulero-Mendigorri, E. & Revuelta-Bordoy, D. 2008. A balanced
scorecard framework for R&D. European Journal of Innovation management. Vol.11, nro.
2, s. 241-281
Godener, A. & Söderquist, K. 2004. Use and impact of performance measurement results
in R&D and NPD: an exploratory study. R&D Management. Vol. 34, nro. 2, s. 191-219
Gremer, I. & Fouquet, J-B. 2012. Design for six sigma and lean product development. International Journal of lean six sigma. Vol. 3, nro. 1, s. 45-58
Handfield, R. B. & Lawson, B. 2007. Integrating suppliers into new product development.
Research Technology management. September-October, s. 44-51
Hines, P., Francis, M. & Found, P. 2005. Towards lean product lifecycle management.
Journal of manufacturing technology management. Vol. 17, nro.7, s. 866-887
Hines, P., Holweg, M. & Rich, N. 2004. Learning to evolve. International journal of operations and production management. Vol. 24, nro.10, s. 994-1011
Jyoti D., Banwet, K. & Deshmukh, S.G. 2006. Balanced scorecard for performance evaluation of R&D organization: A conceptual approach. Journal of scientific & industrial Research. Vol.65, November, s.879-886
95
Kaplan, R., S. & Norton D. P. 1996. Strategic learning & balanced scorecard. Strategy &
Leadership. Vol. 24, Issue 5, s. 18-24
Kaplan, R., S. & Norton D. P. 1992. The balanced scorecard – Measures that drive performance. Harvard Business review, Jan-Feb, s.71-79
Kasanen, E., Lukka, K. & Siitonen, A. 1991. Konstruktiivinen tutkimusote liiketaloustieteessä, Liiketaloudellinen aikakauskirja 40:3, s. 301-329
Kahn, K. B., Barczak, G. & Moss, R. 2006. Perspective: establishing an NPD Best practices framework. Journal of Product innovation management. Vol. 23, s.106-116
Kerssens-van Drongelen, I., Nixon, B. & Pearson, A. 2000. Performance measurement in
industrial R&D. International journal of management Reviews. Vol. 2, nro. 2, s. 111-143
Kerssens-van Drongelen, I. & Bilderbeek, J. 1999.
R&D performance measurement:
more than choosing a set of metrics. R&D Management. Vol. 29, nro. 1, s. 35-46
Kerssens- van Drongelen, I. & Cook, A. 1997. Design principles for the development of
measurement systems for research and development processes. R&D Management. Vol.
27, nro. 4, s. 345-357
Kwak, Y.H. & Anbari, F. T. 2006. Benefits, obstacles and future of six sigma approach.
Technovation. Vol. 26, s. 708-715
Laaksovirta, T. H. 1985. Tieteellinen metodi ja metodologia. Kirjastotiede ja informatiikka.
Vol. 4, nro 2, s. 35-44
Lettice, F., Roth, N. &Forstenlechner, I. 2005. Measuring knowledge in the new product
development process. International journal of productivity and performance management.
Vol. 55, nro. ¾, s. 217-241
Loch, C. & Tapper, S. 2002. Implementing a strategy-driven performance measurement
system for an applied research group. The Journal of Product Innovation Management.
Vol. 19, s. 185-198
Lönnqvist, A. Kujansivu, P. & Antikainen, R. 2006. Suorituskyvyn mittaaminen – tunnusluvut asiantuntijaorganisaation johtamisvälineenä. Helsinki, Edita Publishing Oy. 162 s.
ISBN 951-37-4748-9
96
Matsler, K. & Hinterhuber, H.H. 1998. How to make products development projects more
successful by integrating Kano’s model of customer satisfaction into quality function deployment. Technovation. Vol. 18, nro. 1 s. 25-38¨
Neilimo, K. & Näsi, K. 1980. Nomoottinen tutkimusote ja suomalainen yrityksen taloustiede: tutkimus positivismin soveltamisesta. Yrityksen taloustieteen ja yksityisoikeuden laitoksen julkaisuja, Tampereen yliopisto, A 2, Tutkielmia ja raportteja, 12
Oh, H. & Bowon, K. 2002. An effective R&D performance measurement system: survey of
Korean R&D researches. The international Journal of Management Science. Vol. 30, s.
19-31
Ojanen, V. & Vuola, O. 2006. Coping with the multiple dimensions of R&D performance
analysis. International Journal Technology Management. Vol. 33, nro. 2, s. 279 – 290
Ojanen, V. & Vuola, O. 2003, Categorizing the measures and evaluation methods of R&D
performance – A state of the heart review on R&D performance analysis. Lappeenranta,
Telecom Business Research center. 23 s. ISBN 951-764-752-2
Ojanen, V., Piippo, P. & Tuominen, M. 2002. Applying quality award criteria in R&D project assessment. International journal of production economics. Vol. 80, s.119-128
Oliveira, M. G. & Rozenfeld, H. 2010. Integrating technology roadmapping and portfolio
management at the front-end of new product development. Technology Forecasting &
Social Change. Vol. 77, s. 1339-1354
Oppenheim, B. W. 2004. Lean Product Development Flow. Systems engineering. Vol. 7,
nro. 4, s. 352-376
Pappas, R. & Remer, D. 1985. Measuring R&D Productivity. Research management.
May-June, s. 15-22
Park, Y. H. 2007. A study of R&D Investment framework and success factors. The Asian
journal on Quality. Vol. 9, nro. 1, s. 103-112
Pillai, A. S., Joshi, A. & Rao, K. S. 2002. Performance measurement of R&D projects in a
multi-project, concurrent engineering environment. International Journal of Project Management. Vol. 20, s.165-177
97
Reid, M. & Brady, E. 2012. Improving firm performance through NPD: The role of market
orientation, NPD orientation and the NPD process. Australasian Marketing Journal. Vol.
20, s. 235-241
Shen, X.X., Tan, K. C. & Xie, M. 2000. An integrated approach to innovative product development using Kano’s model and QFD. European journal of innovation management.
Vol. 3, nro. 2, s. 91-99
Shepherd, C. & Pervaiz, A. K. 2000. NPD frameworks: a holistic examination. European
Journal of Innovation Management. Vol. 3, nro. 3, s. 160-173
Slotegraaf, R. J. & Atuahene-Gima, K. 2011. Product development team stability and new
product advantage: The role of decision making processes. Journal of marketing. Vol. 75,
s.96-108
Stainer, A. & Nixon, B. 1997. Productivity and performance measurement in R&D. International journal of technology management. Vol. 13, no. 5/6, s. 486-496
Suomala, P., Kanniainen, J. & Lönnqvist, A. 2012. Managerial lessons on relevance and
measurability in R&D project valuation. Measuring business excellence. Vol. 16, nro.1 s.
21-30
Suomala, P. & Jokioinen, I. 2003. The patterns of success in product development: a case
study. European Journal of Innovation Management. Vol. 6, nro. 4, s. 213-227
Szarkonyi, R. 1994. Measuring R&D effectiveness – I. Research Technology Management. Vol. 37, nro. 2, s. 27-32
Thomke, S. & Reinertsen, D. 2012. Six Myths of product development, Harvard Business
Review. Vol. 90, nro. 5 s.84-94
Ulrich, K., T. & Eppinger, S., T. 2003. Product Design and Development. 3rd edition New
York, McGraw-Hill Companies. 366 s. ISBN 007-123273-7
Unger, D. & Eppinger, S. 2011. Improving product development process design: a method
for managing information flows, risks and iterations. Journal of Engineering Desig. Vol. 22,
nro 10, s.689-699
98
Verbano, C. & Nosella, A. 2010. Addressing R&D investment decisions: a cross analysis
of R&D project selection methods. European Journal of innovation management. Vol.13,
nro.3, s. 355-380
Vuolle, M., Lönnqvist, A. & van der Meer, J. 2009. Measuring the intangible aspects of an
R&D project. Measuring business excellence. Vol. 13, nro, 2, s. 25-33
Wang, L., Ming, X.G., Kong, F.B, Li, D. & Wang, P.P. 2012. Focus on implementation: a
framework for lean product development. Journal of manufacturing technology management. Vol. 23, nro. 1, s. 4-24