tuotekehityksen abc

– 68 – © TKK Koneensuunnittelu, 2006

prosessikeskeinen tuote tuote, jonka tuotantoprosessi määrittää tuotteen ominaisuudet; tuotteen suunnittelu on suurelta osin myös tuotantoprosessin suunnittelua

Pugh-menetelmä /-matriisi Professori Stuart Pughin mukaan nimetty menetelmä konseptien seulomiseksi, ks. seulontamatriisi

QFD QUALITY FUNCTION DEPLOYMENT; menetelmä, jonka avulla asiakastarpeet yhdistetään mitattaviin teknisiin vaatimuksiin ja muunnetaan suunnittelutavoitteiksi.

road-map tuotesuunnittelun koordinointiin tarkoitettu suunnitelma, jossa kartoitetaan esim. eri tuotteisiin soveltuvia, jo käytössä olevia sekä tulevia teknologisia ratkaisuja

seulontamatriisi konseptien arviointiin tarkoitettu menetelmä, jossa konseptit luokitellaan vertaamalla niiden ominaisuuksia referenssituotteeseen

speksi, spesifikaatio tuotetta koskeva määre; sisältää mittasuureen ja arvon

storyboard kuvakäsikirjoitus; kuvallinen esitys tuotteen toiminnasta

trade-off tuotteen jonkin ominaisuuden vahvistaminen toisen ominaisuuden kustannuksella

tuotealusta samaan tuoteperheeseen kuuluville tuotteille yhteinen teknologinen ratkaisumalli, jonka varaan yksittäisiä tuotteita kehitetään

tuotekehitys yrityksen tarjoaman tuotteen tai palvelun kehittämistä

tuotesuunnittelu tuotekehitysprojektia edeltävä vaihe, jossa yritys arvioi tuotekehitystarpeita ja määrittää toteutettavia projekteja oman strategiansa mukaisesti

tuotteen suunnittelu yksittäisen tuotteen tai sen osan (tekninen) suunnittelu

tuotearkkitehtuuri tuotteen fyysisten osien määrittely funktionaalisten elementtien perusteella

VOC VOICE OF CUSTOMER; asiakastarpeiden huomioiminen

väylämodulaarinen tuotearkkitehtuuri, jossa moduulit liitetään yhteiseen väylään, jonka kaikki liitännät ovat samanlaisia

WBS WORK BREAKDOWN STRUCTURE, työn ositus; hierarkkinen projektin kuvaus, jossa määritellään projektin toteuttamiseksi tarvittavat työt

yhdistelmäanalyysi kyselytutkimus, jolla pyritään selvittämään asiakkaan kannalta paras yhdistelmä suunniteltavaan tuotteeseen sisällytettäviä ominaisuuksia

Tuotekehityksen ABC-kirjanen

Honkala Sauli Hämäläinen Matti Koisaari Tapio Reinikainen Mikko Sipilä Pekka Vanhamaa Miikka

– 2 – © TKK Koneensuunnittelu, 2006 – 67 – © TKK Koneensuunnittelu, 2006

konseptien yhdistelytaulukko taulukko, jossa osaongelmien mahdolliset osaratkaisut on listattu potentiaalisten kokonaisratkaisujen hahmottamiseksi

kriittinen polku projektin ajallisesti pisin tehtäväketju, joka määrittää koko projektin keston

laatutalo ks. HOQ

lead user edelläkävijäkäyttäjä; henkilö (tai toimiala), 1) jolla on tarpeita, jotka eivät ole vielä tunnistettavissa massan tarpeista ja 2) joka hyötyy erityisesti tämän tarpeen tyydyttämisestä

liitäntämodulaarinen tuotearkkitehtuuri, jossa jokaisen moduulin liitäntä on erilainen, joten moduuleja ei voi vaihtaa keskenään

linjaorganisaatio organisaatio, jossa työntekijät on ryhmitelty pysyviin osastoihin toimenkuviensa perusteella

lohkomodulaarinen tuotearkkitehtuuri, jossa moduulit liitetään suoraan toisiinsa ja niiden liitännät ovat kaikki samanlaisia

matriisiorganisaatio funktionaalisen ja projektiorganisaation yhdistelmä; työtekijöillä on sekä jatkuva työnkuva, että projekteja

MFD MODULAR FUNCTION DEPLOYMENT; menetelmä tuotearkkitehtuurin määrittämiseen

milestone virstanpylväs, merkkipaalu; projektin osatavoitteita, joiden avulla projektin etenemistä voidaan seurata

mission statement toiminta-ajatus, tehtävän kuvaus; ”tavoite ja kuinka sitä lähdetään saavuttamaan”

NPV NET PRESENT VALUE, nettonykyarvo; tuotteen koko elinkaaren aikainen tuotto suhteutettuna nykyhetkeen

ohjausdokumentaatio sisältää osien geometriapiirustukset, valmistustyö-kalut, spesifikaatiot ostettaville komponenteille sekä prosessisuunnitelman valmistukselle ja kokoonpanolle

PERT PROGRAM EVALUATION AND REVIEW TECHNIQUE;menetelmä projektin aikataulun ja kulujen arvioimiseksi ja seuraamiseksi; kehitelty 1950-luvulla

pisteytysmatriisi konseptien arviointiin tarkoitettu menetelmä, jossa konseptit pisteytetään käyttäen painokertoimia eri ominaisuuksille

POC-malli PROOF OF CONCEPT -malli; yksinkertainen malli, jolla todistetaan konseptin toteutettavuus ja toimivuus

projektiorganisaatio organisaatio, jossa työntekijät ryhmitellään projektien mukaisesti


Tähän on kerätty sellaisia keskeisiä tuotekehityksen käsitteitä ja lyhenteitä, jotka ovat vakiinnuttaneet asemansa tuotekehityksen yleiskielessä. Sanasto on suunnattu TKK:n Tuotekehitys- ja Tuotekehitysprojekti-kurssien opiskelijoille. AHP ANALYTIC HIERARCHY PROCESS; päätöksentekoa

tukeva työkalu, jossa määritetään eri vaihtoehtojen paremmuusjärjestys keskenään vertailemalla

alkuvaiheen prosessi yleisnimitys tuotekehityksen alkupäähän sijoittuville toiminnoille, jotka edeltävät varsinaisen teknisen suunnittelun aloittamista

alpha-proto prototyyppimalli (yleensä ensimmäinen), joka on luotu konseptin toimivuuden testaamiseksi

arkkitehtuuri ks. tuotearkkitehtuuri

benchmarking markkinoilla olevien, kilpailevien tuotteiden vertailu

beta-proto toisen sukupolven prototyyppimalli, joka yleensä on valmistettu tulevaa tuotantoa vastaavin menetelmin

BOM BILL OF MATERIALS, tuoterakenne; kertoo tuotteen

DFA DESIGN FOR ASSEMBLY; DFM:n osa; suunnittelutapa, jossa pyritään minimoimaan kokoonpanokustannukset Voidaan käyttää myös tarkoittamaan DFA:ta ja DFM:ää yleisesti

DFM DESIGN FOR MANUFACTURING; suunnittelutapa, jossa valmistuskustannukset pyritään minimoimaan suun-nittelemalla tuote helposti valmistettavaksi. Voidaan käyttää myös tarkoittamaan DFA/DFM:ää yleisesti

DFX DESIGN FOR X; yleinen nimitys eri suunnittelutavoille, joissa pyritään ottamaan huomioon esim. ympäristö-, valmistus- tai elinkaarinäkökulma

DSM DESIGN STRUCTURE MATRIX; käytetään suunniteltaessa tuotteen arkkitehtuuria sekä projektin toteutusta ja tehtävien jakoa

Gantt-kaavio Henry L. Ganttin mukaan nimetty aikajanakaavio, jossa esitetään projektin ajallinen eteneminen vaiheittain sekä epäsuorasti myös projektin osien riippuvaisuudet toisistaan

HOQ HOUSE OF QUALITY; QFD-menetelmään kuuluva matriisi, jossa asiakastarpeita ja vaatimuksia verrataan tuotannon suorituskykyyn

kilpailijakartta kuvaaja, jossa vertaillaan kilpailevien tuotteiden heikkouksia ja vahvuuksia

konseptien luokittelupuu kaavio, jossa konseptit on ryhmitelty yhteisten ominaisuuksien perusteella


Lukijalle ...........................................................................................................................5

I Tuotekehitys ........................................................................................................6Yleinen tuotekehitysprosessi.................................................................................6

Suunnitteluvaihe....................................................................................................8

Tuotesuunnittelu – ideasta suunnitelmaksi ...............................................8

Projektisuunnittelu – suunnitelmasta projektiksi ......................................9

Konseptin kehitys................................................................................................10

5eyes™ Ideasta tuoteikoniksi -prosessimalli ......................................................12

II Resurssien hallinta ja tunnistaminen ..............................................................14Henkilöstöresurssit..............................................................................................14

Taloudelliset resurssit .........................................................................................14

Ajankäytön hallinta .............................................................................................15

Hiljainen tieto......................................................................................................16

III Kommunikointi projektissa .............................................................................17Kommunikaatiotyypit .........................................................................................18

Kommunikaatio tuotekehitysorganisaatiossa......................................................19

Onnistuneen kommunikaation varmistaminen....................................................19

IV Työkaluja tuotekehitysprosessin eri vaiheisiin...............................................21Tuoteidea.............................................................................................................21

Tuotekonsepti......................................................................................................21

Asiakastarpeet .....................................................................................................24

Asiakastarpeiden tunnistaminen..............................................................24

Menetelmät käyttäjätiedon kokoamiseen................................................30

Tuotekonseptien luominen..................................................................................35

Konseptien kehittäminen.........................................................................35

Konseptin kehitys- ja valintamalleja.......................................................36

Ideointi ................................................................................................................37

Ideointimenetelmiä..................................................................................38

Ajatusten organisointia ja ongelman kartoittamista................................38

Metodit määrän tuottamiseksi .................................................................40

Menetelmät ideoiden ryhmittelemiseen ..................................................41

Ideointisession kulku...............................................................................42

Konseptin valinta ................................................................................................44


Testaus ................................................................................................................ 51

Hyvän testin tunnusmerkkejä.................................................................. 52

Tavoite .................................................................................................... 52

Testisuunnitelma ..................................................................................... 52

Testin suorittaminen................................................................................ 53

Dokumentaatio ........................................................................................ 53

Case: SuperAbsorbent-projekti (räjähdesuoja) ....................................... 54

Tuotearkkitehtuuri............................................................................................... 56

Prototyypin valmistus ......................................................................................... 59

Mikä on prototyyppi?.............................................................................. 59

Paper prototyping.................................................................................... 59

Naurumalli / räkämalli ............................................................................ 60

Velhoprototyyppi .................................................................................... 60

POC-malli ............................................................................................... 60

Koerakentaminen .................................................................................... 61

V Käytännön vinkit .............................................................................................. 63Keinoja kommunikoinnin tehostamiseksi........................................................... 63

Työn tekeminen................................................................................................... 63

Ideointi ................................................................................................................ 63

Tuotekehityksen sanastoa ja keskeisiä käsitteitä ....................................................... 64


latent piilevä

market-pull markkinavetoinen, -lähtöinen; tuotteen kehittäminen tiettyyn markkinarakoon, vrt. technology-push

matrix organization matriisiorganisaatio

metric mittasuure, mitattava ominaisuus

mission statement toiminta-ajatus, tehtävän kuvaus, tavoite; kertoo usein myös kuinka tavoitetta lähdetään saavuttamaan

overhead cost, overheads yleiskustannus, juoksevat kulut

pipelining putkitus, liukuhihna; prosessin jakaminen peräkkäin suoritettaviin vaiheisiin

platform (tuote-)alusta

process-intensive prosessikeskeinen

product portfolio yrityksen tuotevalikoima tietyllä ajanhetkellä

quantifiable määrällinen, määrällisesti ilmaistava

ramp-up ylösajo, käynnistysvaihe

redundancy (rinnakkais-)varmennus, redundanssi

robust kestävä, vankka, robusti

robust design tuotteen suunnittelu siten, että sen toiminta on mahdollisimman riippumatonta häiriöistä

screening seulonta

sectional-modular lohkomodulaarinen

slot-modular liitäntämodulaarinen

specification määrite, speksi

stakeholder osapuoli, sidosryhmä

storyboard kuvakäsikirjoitus; kuvallinen esitys tuotteen toiminnasta

technology-intensive teknologiakeskeinen

technology-push teknologialähtöinen; uuden teknologian pohjalta kehitettävä tuote

trade-off vaihtokauppa, kompromissi; tuotteen jonkin ominaisuuden vahvistaminen toisen ominaisuuden kustannuksella


Tuotekehityksen sanastoa ja keskeisiä käsitteitä Tämä sanasto on laadittu tuotekehityksen opiskelijoiden tarpeita silmällä pitäen ja se pitää sisällään joukon keskeisiä, tuotekehitykseen liittyviä englanninkielisiä termejä lyhyine suomennoksineen.aggregate planning kokonaissuunnittelu

benchmark kiintopiste, vertailupiste, mittapuu

benchmarking vertailututkimus, esikuva-analyysi; oman tuotteen vertailu kilpailijoiden tuotteisiin

budget allocation budjetin kohdentaminen tai jakautuminen

bulk irtotavara, massatuote

bus-modular väylämodulaarinen

caveat vaara, varoitus; ”sudenkuoppa”

competitive map kilpailijakartta; kuvaaja, jossa vertaillaan kilpailevien tuotteiden heikkouksia ja vahvuuksia

concept generation konseptien luominen

conjoint analysis yhdistelmäanalyysi

contextual inquiry toimintaympäristökartoitus

control documentation ohjausdokumentaatio

cost driver kustannusajuri; kustannuksiin vaikuttava ominaisuus

customer attributes asiakasvaatimukset

decomposition ongelman jakaminen pienempiin osiin

deliverable tuotos; projektiin sisältyvä kokonaisuus, joka luovutetaan yleensä projektin tilaajalle

derivative johdannainen, johdannais-

downstream development tuotteistus

economics of scale suuruuden ekonomia; kappalekohtaiset tuotantokus-tannukset laskevat tuotantomäärän kasvaessa

feasibility toteutettavuus

focus group kohderyhmä

front-end process alkuvaiheen prosessi

functional organization linjaorganisaatio, toiminnon mukainen organisaatio

funnel suppilo

incentive heräte, kannustin

iteration iteraatio, toisto; peräkkäisten vaiheiden toistaminen silmukassa, kunnes ratkaisu löydetään


Lukijalle

Tämä teos on tarkoitettu suomalaisen tuotekehityksen perusteokseksi. Tavoitteena on ollut mahdollisimman selkeästi ja yksinkertaisesti esitellä yleinen tuotekehitysprosessin rakenne, sekä lyhyesti kuvata yleisimmät tuotekehityksen piiriin kuuluvat menetelmät ja käsitteet. Perusmenetelmien lisäksi teoksessa kuvataan yksityiskohtaisesti joitain tuotekehitysprosessin alkupäähän kuuluvia vaiheita, kuten ideointia ja konseptien vertailua, sekä esitetään näihin vaiheisiin soveltuvia työkaluja ja toimintamalleja.

Teos on kirjoitettu suomen kielellä ja se on kohdennettu aloitteleville tuotekehityksen opiskelijoille sekä suomalaisille, tuotekehitystoimintaa harjoittaville pienyrityksille. Vakaa uskomuksemme on, että teoksessa kuvatuilla tai niitä mukailevilla menetelmillä voidaan suomalaista innovatiivisuutta hyödyntää tulevaisuudessa entistäkin paremmin.

Tuotekehityksen ABC-kirjanen on vielä kehitysasteella, mistä johtuen toivomme saavamme avointa palautetta kirjan hyvistä ja huonoista puolista. Tällä tavoin voimme jatkossa kehittää teoksen sisältöä vastaamaan kohderyhmän tarpeita. Palautetta voi lähettää sähköpostitse osoitteeseen:

[email protected]

tai postitse osoitteeseen:

Koneensuunnittelun laboratorio ”Tuotekehityksen ABC-kirja” PL 4100 02015 TKK

Nautinnollisia lukuhetkiä!

Espoossa, 21.9.2006 Tekijät


I Tuotekehitys Tässä kirjasessa esitetään kaksi erilaista mallia tuotekehitysprosessille. Ensimmäisenä käsitellään Ulrich & Eppingerin kuvaama systemaattinen yleinen tuotekehitysmalli (generic product development process) ja jäljempänä vaihtoehtoinen 5eyes-malli (s. 12). Kumpaakaan mallia ei pidä noudattaa orjallisesti eikä käsittää yksiselitteiseksi totuudeksi, vaan niiden tarkoituksena on todellisen prosessin jaksottaminen selkeiksi, toisistaan erottuviksi kokonaisuuksiksi, joiden perusteella projektin kulkua voidaan ennakoida ja suunnitella.

Kirjallisuudessa on todettu yleisesti, että työmäärä ja panostus tuotekehityksen alkupään toimintoihin maksavat itsensä takaisin projektin myöhemmissä vaiheissa säästyneen ajan, pienentyneiden kulujen sekä parantuneen laadun muodossa. Tästä johtuen tässä kirjasessa keskitytään pääosin tuotekehitysprojektin alkupäähän. Projektin myöhemmille vaiheille löytyy kuitenkin muusta kirjallisuudesta runsaasti yksityiskohtaisempaa materiaalia.

Projektin alkupään tärkeyttä voidaan havainnollistaa kuvan 1 mukaisella esityksellä. Kuvan vaaka-akselilla on esitetty tuotteen valmiusaste ja pystyakselilla kustannukset. Kuvasta nähdään, että mahdollisuus vaikuttaa tuotteen kustannuksiin laskee projektin edetessä ja samalla tuotteen muutoksista aiheutuvat kustannukset kasvavat.

Kuva 1. Projektin edetessä mahdollisuus vaikuttaa tuotteen kustannuksiin laskee [Römer01]

Yleinen tuotekehitysprosessi Yleinen tuotekehitysprosessi jakautuu Ulrich & Eppingerin mukaan kuudesta vaiheesta, kuvan 2 mukaisesti. Prosessin ensimmäinen vaihe on suunnittelu (planning).Tuotekehitysprosessin suunnitteluvaihe on prosessissa linkki yrityksen pitkäjänteisimpiin tutkimus- ja kehityshankkeisiin. Suunnitteluvaiheen lopputuloksena

Mat

alat

Suunnitteluunkäytettytyömäärä

Kustannukset

Kor

keat

Tehtävän selventäminen

Konsepti-suunnittelu

Rakennemuotoilu Yksityiskohtainen suunnittelu

Mahdollisuusvaikuttaa

kustannuksiin

Mahdollisuus arvioida

kustannuksia

Muutos-kustannukset

Mat

alat

Suunnitteluunkäytettytyömäärä

Kustannukset

Kor

keat

Tehtävän selventäminen

Konsepti-suunnittelu

Rakennemuotoilu Yksityiskohtainen suunnittelu

Mahdollisuusvaikuttaa

kustannuksiin

Mahdollisuus arvioida

kustannuksia

Muutos-kustannukset


V Käytännön vinkit Keinoja kommunikoinnin tehostamiseksi

Sopikaa pelisäännöt kommunikaatioon, esim. jokainen lukee mailit joka toinen päivä min. Keskusteluforum on helppo tapa seurata aktiivisuutta

Pidä pöytäkirjaa kaikista kokouksista

o Kaikki päätökset ja olennaisten keskustelujen aiheet kirjataan

o Pöytäkirja yleiseen jakeluun, jolloin myös poissaolijat pysyvät ajan tasalla

Kannusta epäviralliseen kommunikointiin, esim. säännölliset perjantaikahvit

Valmistaudu huolella virallisiin tilaisuuksiin

o Saavu paikalle hyvissä ajoin – myöhästyminen on epäkunnioittavaa muita kohtaan ja vie kallisarvoista aikaa

o Puhu lyhyesti ja pysy aiheessa – säästät muiden aikaa (1h vs 20h) ja varmistat olennaisten viestien perillemenon

o Varaa aikaa myös epäviralliselle keskustelulle – kaikki palaute on tärkeää viestin oikean tulkinnan varmistamiseksi

Kannusta kaikkia läsnäolijoita osallistumaan keskusteluun

o Esim: Jokainen on velvollinen käyttämään puheenvuoron

Kuittauskäytäntö: jokainen on velvollinen vastaamaan saamaansa viestiin tietyn ajan kuluessa

o Jos mailiin ei vastata sovitussa ajassa, soita perään!!!

Työn tekeminen Se minkä voit tehdä tänään, tee se – huomenna tulee kuitenkin jotain uutta ja yllättävää.

Jonkun työ on ei kenenkään työ, jaa vastuuta ja valvo tehtävien toteutumista.

Jos sinulla on osia jotka aiot valmistuttaa konsultoi labran henkilökuntaa, niin vältyt monelta turhalta kömmähdykseltä.

Apua saa, mutta sitä ei tyrkytetä.

IdeointiIDEOIKAA IDEOIKAA !!!

Kaikki ongelmat voidaan purkaa osaongelmiin (dekomposointi) ja hakemaan ratkaisua niihin


Kuva 38. Balsapuusta tehtyjä hahmomalleja. [http://www.canon.com/camera-museum/design/kikaku/]

Kuva 39. Ideon esimerkkejä erilaisista prototyypeistä. [@issue Journal, “Beyond Techno Gadget” http://www.cdf.org/journal/0602_palm.php]


syntyy mission statement -lauseke, joka on vaatimuksena konseptin kehitysvaiheen (concept development) aloittamiseen ja joka toimii ohjenuorana läpi koko loppuprojektin. Muut tuotekehitysprosessin vaiheet ovat systeemitason suunnittelu (system-level design), yksityiskohtainen suunnittelu (detail design), testaus ja viimeistely (testing and refinement), sekä tuotannon ylösajo (production ramp-up).Tuotekehitysprojekti päättyy tuotteen julkaisuun markkinoille (product launch).

Vaihe 0 Vaihe 1 Vaihe 2 Vaihe 3 Vaihe 4 Vaihe 5

Suunnittelu Konseptinkehitys

Systeemitasonsuunnittelu

Yksityis-kohtainen

suunnittelu

Testaus ja viimeistely

Tuotannonylösajo

Vaihe 0 Vaihe 1 Vaihe 2 Vaihe 3 Vaihe 4 Vaihe 5

Suunnittelu Konseptinkehitys

Systeemitasonsuunnittelu

Yksityis-kohtainen

suunnittelu

Testaus ja viimeistely

Tuotannonylösajo

Kuva 2. Yleinen tuotekehitysprosessi [U&E] Vaikka tuotekehitysprosessi on kuvassa 2 esitetty suoraviivaisena prosessina, sisältää prosessi usein myös iterointia eli toistoa. Varsinkin yksittäisten vaiheiden sisällä iteraatiosilmukat ovat yleisiä, kun taas iterointi varsinaisten projektin vaiheiden välillä on usein estetty tai tehty hyvin hankalaksi. Myös projektin laajuus, tuotteen ja käytettävien teknologioiden uutuus, sekä projektin hajauttaminen eri suunnitteluryhmille saattavat vaikuttaa prosessimalliin.

VAIHE 0. SUUNNITTELU

Varsinaisen tuotekehitysprojektin hyväksyntää ja käynnistystä edeltää suunnitteluvaihe, jota usein kutsutaan nollavaiheeksi. Nollavaihe pitää sisällään teknologia- ja markkina-arvioinnin, jotka tehdään yrityksen strategian mukaisesta näkökulmasta. Suunnitteluvaiheen lopputuloksena syntyy projektin toiminta-ajatuksen kiteyttävä mission statement, jossa määritetään mm. tuotteen tavoitemarkkinat, liiketoimintatavoite, avainolettamukset, sekä rajaukset. Lopuksi tehdään päätös varsinaisen tuotekehitysprojektin käynnistämisestä.

VAIHE 1. KONSEPTIN KEHITYS

Konseptin kehitysvaiheessa tunnistetaan tavoitemarkkinoiden asiakastarpeet, sekä niiden pohjalta luodaan ja arvioidaan vaihtoehtoisia tuotekonsepteja. Vaiheen lopputuloksena valitaan yksi tai useampi tuotekonsepti jatkokehitykseen ja testaukseen, sekä määritetään tuotteen spesifikaatiot.

Konseptin kehitysprosessia on esitelty tarkemmin kappaleissa ”Konseptin kehitys”(s. 10) ja ”5eyes™ Ideasta tuoteikoniksi -prosessimalli” (s. 12). Konseptin määritelmästä on tässä kirjasessa lisää tietoa sivulla 21.

VAIHE 2. SYSTEEMITASON SUUNNITTELU

Systeemitason suunnitteluvaiheessa määritellään tuotteen tuotearkkitehtuuri ja jaetaan tuote alijärjestelmiin sekä komponentteihin. Usein myös tuotteen lopullinen kokoonpanosuunnitelma tehdään tässä vaiheessa. Tämän vaiheen lopputuloksena syntyy geometrinen pohjapiirros tuotteelle (geometric layout), toimintomäärittely jokaiselle tuotteen alijärjestelmällä, sekä alustava tuotteen loppukokoonpanoprosessia kuvaava virtauskaavio (process flow diagram).


VAIHE 3. YKSITYISKOHTAINEN SUUNNITTELU

Yksityiskohtaisessa suunnittelussa määritetään kaikkien komponenttien lopulliset geometriat, käytettävät materiaalit ja toleranssit, sekä tunnistetaan valmiina tilattavat standardiosat. Tässä vaiheessa laaditaan myös prosessisuunnitelma ja suunnitellaan valmistustyökalut itse valmistettaville komponenteille. Yksityiskohtaisen suunnittelun lopputuloksena syntyy ohjausdokumentaatio (control documentation), joka pitää sisällään osien geometriapiirustukset, valmistustyökalut, spesifikaatiot ostettavillekomponenteille, sekä prosessisuunnitelman tuotteen valmistukselle ja kokoonpanolle.

VAIHE 4. TESTAUS JA VIIMEISTELY

Testaus- ja parannusvaihe pitää sisällään useiden esituotantomallien rakentamisen ja testauksen. Aikaisilla, alpha-prototyypeillä testataan tuotteen toimivuutta sekä selvitetään täyttääkö tuote keskeiset asiakasvaatimukset. Myöhemmillä beta-prototyypeillä testataan tuotteen suorituskykyä ja luotettavuutta, jotta nähdään tarvitseeko lopulliseen tuotteeseen tai valmistusprosessiin tehdä vielä muutoksia.

VAIHE 5. TUOTANNON YLÖSAJO

Tuotannon käynnistysvaiheessa tuotetta valmistetaan lopullisilla tuotantomenetelmillä todellisessa tuotantojärjestelmässä. Tuotannon käynnistysvaiheen tarkoituksena on harjoittaa työvoimaa ja selvittää jäljelle jääneet ongelmat tuotantoprosessissa. Joskus tuotannon käynnistysvaiheessa syntyvillä tuotteilla vielä etsitään piileviä vikoja tuotteesta käyttäen hyväksi tarkoin valittua asiakasryhmää. Siirtymä käynnistysvaiheesta varsinaiseen tuotantovaiheeseen tapahtuu usein portaittain. Käynnistysvaiheen edetessä tuote julkaistaan ja se tulee yleisesti saataville.

SuunnitteluvaiheTuotekehitysprosessin nollavaihetta eli suunnittelua käsitellään tässä kirjasessa hyvin suppeasti, koska suunnittelun katsotaan olevan lähempänä yrityksen hallinnointia ja strategiaa, kuin varsinaista tuotekehitystyötä. Kirjasessa tuodaan kuitenkin esille joitain suunnitteluvaiheeseen kuuluvia asioita, kuten tuoteidean ja tuotekonseptin käsitteet (s. 21), tuotesuunnittelu ja projektisuunnittelu (s. 8), resurssien hallinta (s. 14), sekä usein liian vähälle huomiolle jäävä kommunikointi tuotekehitysprojektissa (s. 17). Varsinaista projektisuunnittelua ja projektinhallintaa käsittelevää kirjallisuutta on saatavilla runsaasti ja myös suomenkielistä opastusta projektisuunnitteluun löytyy esimerkiksi teoksista Projektiliiketoiminta (Artto, Martinsuo, Kujala; WSOY 2006) ja Tuotantotalous (Lehtonen; WSOY 2004).

Suunnitteluvaiheeseen katsotaan kuuluvan kaikkien niiden toimintojen, jotka edeltävät tuotekehitysprojektin käynnistämistä. Karkeasti suunnitteluvaihe voidaan jakaa kahteen osaan: tuotesuunnitteluun, joka toteutetaan yritysjohdon toimesta, sekä projektisuunnitteluun, joka toteutetaan projektin johdon toimesta.

Tuotesuunnittelu – ideasta suunnitelmaksi Tuotesuunnittelu on yrityksen johdon käynnistämä prosessi, jonka päämääränä on yri-tyksen tuotevalikoiman kehittäminen yrityksen strategian mukaiseen suuntaan. Tuote-suunnittelun tavoitteena on potentiaalisten tuotekehitysprojektien kartoittaminen vertai-lemalla omaa tuotesalkkua kilpailijoiden tuotteisiin ja markkinoiden kysyntään. Tuote-suunnittelulla pyritään tunnistamaan lupaavat mahdollisuudet tuotekehitysprojekteiksi, suunnittelemaan projektien ajoitus markkinoiden kannalta oikeaksi, sekä priorisoimaan valitut projektit ja jakamaan resurssit niiden kesken yrityksen strategian mukaisesti.


Koerakentaminen Miksi mock-up malleja yleensä tehdään:

• Tuotteen muodon kehittäminen/löytäminen

• Tuotteen tuntuman ja toimivuuden arvioimiseen

• Koon ja muodon arviointi

• Muiden ihmisten mielipiteiden keräämiseen

• Käyttöliittymän testaamiseen • Värien testaus ja valinta

Kuva 35. Käyttöliittymän prototyypin testaus. [http://www.canon.com/camera-museum/design/kikaku/]

Kuva 36. Erityyppisiä muotomalleja. [BMW Group, DesignworksUSA: Example of different modelling techniques]

Kuva 37. Materiaali- ja värivalintamalleja. [BMW Group, DesignworksUSA: Example of different modelling techniques]


Naurumalli / räkämalli Naurumallissa (Quick and Dirty prototyping) käytetään mitä tahansa saatavilla olevaa materiaalia, joka soveltuu tarpeeseen. Esim. pahvilaatikosta voi leikkaa–liimaa -toiminnoilla tehdä erinomaisia tuotteen ulkomuotoa imitoivia malleja.. Naurumallin avulla tuotetta voi arvioida ja siitä voi keskustella paremmin kuin mitä paperilla olevasta piirroksesta tai tekstistä.

VelhoprototyyppiVelhoprototyypeissä (Wizard of Oz prototype) avustaja toimii tuotteen toiminnallisuutena, vaihtaa sivuja tai ikkunoita, sytyttää merkkivaloja jne.

POC-malliPOC- eli Proof Of Concept -mallin tarkoituksena on testata ja osoittaa jonkin idean toimivuus todellisessa, fyysisessä laitteessa. POC-malli valmistetaan usein nopeasti ja yksinkertaisesti ilman tarkkoja piirustuksia, eikä sen ulkonäön tai koon tarvitse vastata lopullista tuotetta. Testattava idea voi olla esim. uudentyyppinen mekanismi tai rakenne. Kuvassa 33 on esitetty POC-malli kuusenjalalle, joka sisältää erillisen vesisäiliön sekä mekanismin, jolla kuusi voidaan nopeasti asentaa paikalleen. Kuten kuvan 34 CAD-mallista ja Alpha-prototyypistä nähdään, ei POC-malli tässä tapauksessa juurikaan muistuta ulkonäöltään todellista mallia.

Kuva 33. POC-malli kuusenjalan pikakiinnitysmekanismista ja vesitankista.

Kuva 34. CAD-malli (vasemmalla) ja Alpha-prototyyppi (oikealle) kuusenjalasta.


Projektisuunnittelu – suunnitelmasta projektiksi Projektisuunnittelu on projektin toteutusta edeltävä prosessi, jonka tavoitteena on luoda edellytykset tehokkaalle ja toimivalle projektin hallinnalle. Suunnittelun aluksi selvitetään projektin lähtökohdat, minkä jälkeen asetetaan projektille tavoitteet (yleensä tekniset ja kustannustavoitteet) sekä aikataulu. Tavoiteasettelun tulokset kiteytetään mission statement -ilmoitukseen, joka tiivistetysti kertoo projektin tavoitteen sekä keinot, joilla tavoitteeseen tullaan pääsemään. Mission statement ei kuitenkaan saa liikaa rajoittaa projektin toteutusta, vaan sen tulee ainoastaan kertoa suuntaviivat, joiden mukaan projektia lähdetään viemään eteenpäin.

Projektisuunnitelmassa tyypillisesti käsiteltäviä asioita ovat: lähtökohta, tavoite, projektiorganisaatio, vaiheet (ositus), toteutus, aikataulu, resursointi, dokumentointi ja raportointi, sekä riskinhallinta.

Esimerkki mission statement -ilmoituksesta:

PROJEKTIN TAVOITTEENA ON KEHITTÄÄ KOHTUUHINTAINEN NELJÄNNEN SUKUPOLVEN INTERAKTIIVINEN PÖYTÄKORISTE ELÄMÄÄNSÄ KYLLÄSTYNEIDEN TOIMISTOVIRKAILIJOIDEN TYÖPÄIVÄN PIRISTÄMISEKSI. PROJEKTI TOTEUTETAAN NELJÄN HENGEN VOIMIN JA SEN KESTO ON KUUSI KUUKAUTTA.

Mission Statement “Interaktiivinen pöytäkoriste”

Tuotteen kuvaus Yksinkertainen, innovatiivinen ja interaktiivinen koriste-esine.

Markkinatavoitteet Markkinoilla kesälomien päättyessä 10–15 % markkinaosuus 1. vuotena 5–10 % markkinaosuus 2. vuotena

Ensisijainen kohderyhmä Elämäänsä kyllästyneet toimistovirkailijat

Toissijainen kohderyhmä Muut, elämäänsä kyllästyneet työntekijät

Oletukset KohtuuhintainenHauskaInteraktiivinen Kestävä

Sidosryhmät Käyttäjä – toimistovirkailija Ostaja – toimistovirkailijan työkaverit Vähittäismyyjä Tukkumyyjä KokoonpanijaValmistaja Mainostoimisto

Tavoiteasettelun jälkeen projekti ositetaan ja organisoidaan. Ositus tapahtuu jakamalla projekti selkeisiin osaprojekteihin, vaiheisiin ja tehtäviin, sekä määrittämällä kullekin osiolle selkeät rajapinnat, joilla osion tulokset ovat liitettävissä muuhun projektiin. Organisoinnissa määritetään projektiorganisaatio ja täsmälliset toimenkuvat, joilla jokainen projektin osa saadaan toteutettua. Samalla eriytetään itse toteutettavat ja alihankintana tilattavat osiot toisistaan.


Osittelun ja organisoinnin pohjalta laaditaan projektille aikataulu ja suunnitellaan resurssien käyttö. Aikataulua suunniteltaessa joudutaan usein arvioimaan sellaisten tehtävien kestoa, joiden tarkka sisältö ei ole vielä tiedossa tai joita ei koskaan aikaisemmin ole toteutettu. Tarkan ja yksityiskohtaisen aikataulun laatimisen sijaan onkin tärkeää nimetä projektin eri vaiheisiin selkeitä virstanpylväitä (milestones), joiden avulla projektin etenemistä voidaan seurata ja aikataulun pitävyyttä ennustaa. Resurssien käytön suunnittelussa huomioidaan niin henkilöstö- ja materiaaliresurssit, kuin tilojen, laitteiden ja rahavarojen käyttö.

Projektissa mukana olevilla sidosryhmillä on usein omia tavoitteitaan projektin suhteen. Varsinkin projektia rahoittavat osapuolet saattavat vaatia lisäselvityksiä tai muita ylimääräisiä tuotoksia, ellei projektin sisällöstä ole etukäteen tarkasti sovittu. Tästä syystä on tärkeää täsmentää projektin raportointikäytäntö ja kaikki projektiin kuuluvat tuotokset (deliverables) jo suunnitteluvaiheessa, jotta vältyttäisiin kiistatilanteilta tai ylimääräiseltä työltä projektin edetessä. Raportointi- tai dokumentointisuunnitelman lisäksi kannattaa projektisuunnitelmaan sisällyttää myös kokoussuunnitelma, joka on helppo muodostaa projektin tärkeimpien virstanpylväiden ympärille.

Konseptin kehitys Ulrich & Eppingerin tuotekehitysmallissa konseptin kehitysprosessi jakaantuu seitsemään vaiheeseen kuvan 3 mukaisesti. Huomattavaa on, että taloudellinen analyysi, kilpailijavertailu sekä prototyyppien rakentaminen ja testaus toimivat jatkuvasti konseptin kehitysprosessin taustalla. Kuvassa taaksepäin (vasemmalle) osoittavat nuolet kuvaavat mahdollisuutta palata edelliseen vaiheeseen, jos havaitaan, että käynnissä olevaa vaihetta ei voida nykyisillä tiedoilla saada päätökseen tai lopputulos ei ole riittävä. Prosessi on siis luonteeltaan iteratiivinen.

Tunnista asiakkaiden

tarpeet

Valitse tuote-konsepteja

Luo tuote-konsepteja

Muodosta tavoite-

spesifikaatio

Testaa tuote-konsepteja

Aseta lopullinen

spesifikaatio

Tuotteistus-suunnittelu

Mission statement

Tuotteistus-suunnitelma

Suorita taloudellinen analyysi

Vertaile kilpailijoiden tuotteita

Rakenna ja testaa malleja ja prototyyppejä


tarpeet



Muodosta tavoite-

spesifikaatio


Aseta lopullinen

spesifikaatio


Mission statement






tarpeet



Muodosta tavoite-

spesifikaatio


Aseta lopullinen

spesifikaatio


Mission statement



tarpeet



Muodosta tavoite-

spesifikaatio


Aseta lopullinen

spesifikaatio



tarpeet


tarpeet



Luo tuote-konseptejaLuo tuote-konsepteja

Muodosta tavoite-

spesifikaatio

Muodosta tavoite-

spesifikaatio



Aseta lopullinen

spesifikaatio

Aseta lopullinen

spesifikaatio

Tuotteistus-suunnitteluTuotteistus-suunnittelu

Mission statement





Suorita taloudellinen analyysiSuorita taloudellinen analyysi

Vertaile kilpailijoiden tuotteitaVertaile kilpailijoiden tuotteita

Rakenna ja testaa malleja ja prototyyppejäRakenna ja testaa malleja ja prototyyppejä

Kuva 3. Konseptin kehitysprosessi [U&E] Seuraavaksi on kuvattu konseptin kehitysvaiheen toiminnot pääpiirteittäin. Toimintojen toteuttamiseen on tämän kirjan myöhemmissä vaiheissa esitetty useita työkaluja.

TUNNISTA ASIAKKAIDEN TARPEET

Tuotekonseptointi lähtee käyntiin yleensä asiakastarpeiden kartoittamisella. Tuotekehityksessä suunnittelijan ensimmäinen haaste on ymmärtää, mitä käyttäjät tarvitsevat, haluavat ja miten he tekevät työtään. Asiakastarpeiden kartoituksen tuloksena saadaan suuri joukko porrastettuja tarvelausuntoja, joita voidaan käyttää tukena konseptien ideointiin.


Prototyypin valmistus Mikä on prototyyppi? Prototypoinnissa tehdään kehitysvaiheessa olevasta tuotteesta malli, joka pääasiallisena funktiona on toimia testauksen, ajattelun tai kommunikoinnin apuvälineenä. Prototypoinnin tarkoituksena on testata tuotteen eri ominaisuuksia mahdollisimman aikaisessa vaihessa jolloin tarvittavien korjausten tai muutosten tekeminen on vielä helppoa ja edullista.

Prototyyyppejä on erilaisia, ne voivat olla varhaisia luonnosmaisia hahmomalleja tai melkein valmiita tuotteita, joissa on osa tai kaikki lopullisessa tuotteessa olevasta tekniikasta tai toiminnallisuudesta jo mukana. Muoto (mittasuhteet, design, ergonomia, väri, jne.) ja valmistettavuus on myös seikkoja joita varten on tehtävä prototyyppejä. Protoilu on tärkeä osa tuotekehityksen resurssien ja oikean suunnan kohdentamisessa.

Prototyypit voidaan luokitella käyttöasteen ja testaamisen mukaan kahteen ulottuvuuteen. Ensimmäinen on fyysinen versus analyyttinen prototyyppi. Fyysinen prototyyppi ovat kouraantuntuva artefakti, joka on tehty tuotteen ulkonäön, haptisuuden tai jonkin toiminnan arvioimiseksi. Analyyttisessä prototyypissä tuote kuvataan usein matemaattisella tavalla ja haluttuja ominaisuuksia testataan ja analysoidaan esimerkiksi simuloinnin tai kolmiulotteisten mallien avulla. Toinen ulottuvuus liittyy siihen missä vaiheessa tuotteen kehittelyssä mennään eli onko prototyyppi jo lähes valmis tuote jossa tehdään viimeisiä käyttötestejä versus keskitytäänkö prototyypissä vielä tiettyjen toimintojen tai osa-alueiden testaamiseen. Eri osa-alueiden prototyyppien kehitysvaiheet saattavat olla eriaikaisia, joten yhdestä ja samasta tuotteesta voi olla samanaikaisesti käsittelyssä prototyyppeja sekä ulkonäkömalleja kuin toimintamalleja, jotka loppuvaihessa yhdistetään.

Tuotekehityksessä prototyyppejä käytetään neljään eri tarkoitukseen:

17. Oppiminen eli testataan toimiiko idea käytännössä tai vastaako tuote kuluttajien tarpeisiin.

18. Kommunikointi: fyysisen prototyypin avulla tuotteesta on huomattavasti helpompi keskustella verrattuna verbaaliseen tai piirrettyyn tuotteen kuvaukseen.

19. Integrointi: prototyypeillä testataan eri komponenttien ja alisysteemien yhteensopivuutta ja kokoonpantavuutta.

20. Milestones: prototyypeillä voidaan osoittaa, että on saavutettu tiettyjä kehitysaskeleita tai toiminnallisuus tasoja.

Paper prototypingPaperiprototyyppeja on paljon käytetty käyttöliittymäsuunnittelussa ja ensimmäisenä evaluointi työkaluna. Yksinkertaisesti piirretään luonnoksia käyttöliittymä ja ohjelmistoarkkitehtuuri paperille ja pyritään käyttämään ohjelmaa halutulla tavalla. Erittäin nopea tapa testata käyttöliittymän interaktioita.


VesiMuunna

verkkovirrantaajuus

Pyöritä pumpun akselia

Muunna akselin pyörintänopeus

Pumppaa vettä

Ohjaapumppua

Vesi

Käyttäjä

Sähkö

Sähkö

Sähkö

Ohjaus-signaali

Rotaatio Rotaatio

Pumppaa vettä

Vesi

VesiKäyttäjä

Sähkö

EnergiaInformaatioMateria

Sulje vesi suljettuun tilaan

Vesipumppu

VesiMuunna

verkkovirrantaajuus



Pumppaa vettä

Ohjaapumppua

Vesi

Käyttäjä

Sähkö

Sähkö

Sähkö

Ohjaus-signaali

Rotaatio Rotaatio

VesiMuunna

verkkovirrantaajuus



Pumppaa vettä

Ohjaapumppua

Vesi

Käyttäjä

Sähkö

Sähkö

Sähkö

Ohjaus-signaali

Rotaatio Rotaatio

Pumppaa vettä

Vesi

VesiKäyttäjä

Sähkö

Pumppaa vettä

Vesi

VesiKäyttäjä

Sähkö



Sulje vesi suljettuun tilaan

Vesipumppu

Kuva 32. Esimerkki vesipumpun toiminnallisista elementeistä tuotearkkitehtuurin määrittelyn tueksi


MUODOSTA TAVOITESPESIFIKAATIOT

Spesifikaatiot ovat tarkka kuvaus tuotteen toiminnasta. Spesifikaatioissa on teknisin termein määritetty asiakkaantarpeet. Tavoitespesifikaatiot asetetaan aikaisin prosessissa ja ne kuvastavat tuotekehitysryhmän odotuksia tuotteelta. Myöhemmin näitä spesifikaatioita muutetaan vastaamaan ryhmän valitseman tuotekonseptin rajoituksia. Tämän vaiheen lopputuloksena syntyvät tavoitespesifikaatiot, joista jokainen sisältää mittasuureen, sekä raja-arvon ja ideaaliarvon kyseiselle suureelle.

LUO TUOTEKONSEPTEJA

Konseptin luomisvaiheen tarkoituksena on tutkia läpikotaisin ne konsepti-mahdollisuudet, jotka vastaavat asiakkaiden tarpeisiin. Konseptin luomisvaihe koostuu sekä systemaattisesta, että luovasta ratkaisujen etsinnästä. Tämän vaiheen tuloksena on yleensä noin 10–20 konseptia esitettynä luonnoksin ja selventävin tekstein.

VALITSE TUOTEKONSEPTEJA

Konseptien valinta on toimintaa, jossa konseptivaihtoehdot analysoidaan ja osa konsepteista eliminoidaan perättäisissä arviointivaiheissa. Vaiheen tarkoituksena on tunnistaa kaikista lupaavin konsepti tai lupaavimmat konseptit.

Tämä prosessivaihe saattaa vaatia useita iteraatiokierroksia. Jos sopivia konsepteja ei löydetä muutaman iteraatiokierroksen kuluessa, on vaiheissa palattava taaksepäin tuotekonseptien luomiseen tai jopa asiakasvaatimusten uudelleen tarkasteluun asti.

TESTAA TUOTEKONSEPTEJA

Konsepteja on syytä testata ennen tuotannon aloittamista, koska tuotannon jo alettua on muutosten tekeminen malliin yleensä työlästä ja erittäin kallista. Testaus voidaan toteuttaa erilaisilla malleilla ja prototyypeillä. CAD-mallien pohjalta voidaan suorittaa simulointia, jolla esimerkiksi mekanismien toimivuutta voidaan testata. Fyysisen mallin testaamiseksi voidaan rakentaa yksinkertaistettuja Proof Of Concept -malleja (s. 60) tai lopullista tuotetta jäljitteleviä prototyyppejä. Alpha-protoiksi kutsutaan ensimmäisiä prototyyppejä, joilla testataan yleensä järjestelmän toimintaa. Beta-protoiksi kutsutaan viimeisteltyjä prototyyppejä, jotka on valmistettu todellista tuotantoa vastaavin menetelmin ja jotka usein lähtevät valikoidulle asiakasryhmälle käyttötestiin luotettavuuden ja käytettävyyden varmistamiseksi. Lisää testauksesta on kerrottu kappaleessa Testaus (s. 51).

ASETA LOPULLISET SPESIFIKAATIOT

Tässä vaiheessa käydään läpi aiemmin laaditut tuotteen tavoitespesifikaatiot ja verrataan niitä konseptin testauksesta saatuihin tuloksiin. Testeihin perustuen vaatimuksia tarkennetaan ja asetetaan kehitettävällä tuotteelle lopulliset spesifikaatiot, jotka tuotteen tulee toteuttaa. Tässä vaiheessa tehdään myös vaihtokauppoja (trade-offs) tuotteen tulevien ominaisuuksien, suorituskyvyn sekä kustannusten välillä.

TUOTTEISTUKSEN SUUNNITTELU

Tässä konseptin kehityksen viimeisessä vaiheessa ryhmä luo yksityiskohtaisen aika-taulun tekniselle suunnittelulle, suunnittelee strategian tuotekehitysajan minimoimiseksi, ja tunnistaa resurssit projektin läpiviemiseksi. Tuotekehityksen alkupään toiminnot on nyt suoritettu ja ainakin mission statement, asiakkaan tarpeet, valitun tuotekonseptin yksityiskohdat, tuotespesifikaatiot, tuotteen kannattavuus-laskelma, projektiaikataulu, tarvittava projektihenkilöstö ja projektin budjetti tulisi olla dokumentoitu.


5eyes™ Ideasta tuoteikoniksi -prosessimalliEdellä esitetyn, Ulrich & Eppingerin yleisen tuotekehitysprosessimallin lisäksi on olemassa muitakin prosessimalleja. Tässä esiteltävän vaihtoehtoisen 5eyes™ -mallin kantavana ajatuksena on haastaa perinteiset, jäykkiin standardeihin pohjautuvat prosessimallit keskusteluun asiakastarpeiden ja innostuksen tärkeydestä tuotekehityshankkeissa.

Tuotteiden elinkaaret ovat lyhentyneet ja kilpailu markkinoista on kiristynyt, mistä johtuen tuotekehityksen jatkuva toimivuus ja laatu ovat tulleet yhä tärkeämmiksi asioiksi. Tuotekehityksestä on tullut prosessi, jossa vaiheet erottuvat selkeästi ja eteneminen on systemaattista.

Tuotekehitysprosessin vaiheina voidaan pitää seuraavia:

Tuoteidea ja asiakastarpeen kartoitusEsitutkimus LuonnosteluvaiheSuunnitteluvaihe Viimeistelyvaihe

Usein hanketta ohjaa vain ja ainoastaan tarve – ”valmis ratkaisuehdotus”. Ongelman ymmärrys ja ilmiöt sen taustalla jäävät usein liian vähälle huomiolle. ”Nollavaihe” on kuitenkin se oleellisin vaihe, koska tämän vaiheen aikana syntyneet mielikuvat ja ideat ohjaavat alitajuisesti kehityshanketta koko sen keston ajan.

Kuva 4. 5eyes™ -prosessimallin päävaiheet ja tavoitteet. Eräänä esimerkkinä tästä voidaan mainita erään täysin uuteen teknologiaan pohjautuvan suojaratkaisun tuotekehitysprojekti. Kaikki suunnittelua ohjanneet kriittiset piirteet ratkaisulle ovat löydettävissä ensimmäisen kuukauden aikana hahmotelluista luonnoksista. Luonnokset tehtiin asiantuntijoiden ja työn tilaajan määritelmien pohjalta. Asiantuntijat eivät kuitenkaan kyenneet tai osanneet määritellä niin sanottuja oikeita motivaatioita ja tavoitteita. Tästä johtuen suoja ei mahtunut kuljetuskalustoon, jossa sitä oli tarkoitus kuljettaa. Suunnittelijoille annetut määritelmät olivat olleet niin väljät, että vaikka tuote alitti annetut dimensiot, niin asiakkaan todellinen tarve oli lopulta eri, kuin suunnittelijoille ilmoitettu tarve. Tuotekehittäjät uskoivat sokeasti asiakkaan tarpeisiin, jotka olivat jälkikäteen arvioituna jo ratkaisuja sinänsä, eivätkä informaatiota ja motiiveja ratkaisujen takana. Tuote sinänsä ratkaisi asiakkaan asettamat ongelmat kilpailevia tuotteita paremmin, mutta niin sanottujen nollasarjan lastenvikojen korjauksilta olisi vältytty, jos ideasta informaatioksi -vaiheen määrittely olisi osattu tehdä tehokkaammin ja asiakas olisi saanut paremman tuotteen. Vaiheen kesto muuhun testaamiseen ja kehitystyöhön verrattuna oli lyhyt, eikä useidenkaan viikkojen pidentynyt määrittelyvaihe olisi hidastanut tuotteen markkinoille tuloa.


Tuotearkkitehtuurilla pyritään vaikuttamaan tuotteen muunneltavuuteen, tuotteen suorituskykyyn sekä tuotevariaatioiden lukumäärään. Kuvassa 31 on esitettynä lisää eri arkkitehtuuri ratkaisujen tuomia etuja ja haittapuolia.

Integraalinen Modulaarinen

+ suorituskyky+ vaikea kopioida+ vähemmän rajapinta ongelmia+ alhaisemmat yksittäisten komponenttien

kustannukset

- suunnittelun hallinta- hitaammin markkinoille- hitaampi vaste markkinoille- vähemmän variaatioita- vaikea tehdä muutoksia

+ jaettu suunnittelu ja kehitys+ nopeammin markkinoille+ nopeampi kehitysaika+ uusien versioiden nopeampi kehitys+ helppo tehdä muutoksia+ enemmän variaatioita+ helpompi vaihtaa ja huoltaa

- helpompi kopioida- samalta näyttäviä tuotteita- heikompi suorituskyky ja tehokkuus- enemmän rajapinta ongelmia- korkeammat kustannukset pienillä

volyymeillä

Integraalinen ModulaarinenIntegraalinen ModulaarinenIntegraalinen Modulaarinen

+ suorituskyky+ vaikea kopioida+ vähemmän rajapinta ongelmia+ alhaisemmat yksittäisten komponenttien

kustannukset

- suunnittelun hallinta- hitaammin markkinoille- hitaampi vaste markkinoille- vähemmän variaatioita- vaikea tehdä muutoksia

+ jaettu suunnittelu ja kehitys+ nopeammin markkinoille+ nopeampi kehitysaika+ uusien versioiden nopeampi kehitys+ helppo tehdä muutoksia+ enemmän variaatioita+ helpompi vaihtaa ja huoltaa

- helpompi kopioida- samalta näyttäviä tuotteita- heikompi suorituskyky ja tehokkuus- enemmän rajapinta ongelmia- korkeammat kustannukset pienillä

volyymeillä

Kuva 31. Integraalisen ja modulaarisen tuotteen edut Tuotearkkitehtuuri muodostetaan pääpiirteittäin seuraavasti: Ensimmäiseksi on tunnistettava ne oleelliset elementit, jotka muodostavat tuotteen toiminnan. Tuotteen elementtien ja näiden elementtien välisten vuorovaikutusten mallinnus on lähtökohta tuotearkkitehtuurin määrittelemiselle. On olemassa useita erityyppisiä malleja esittää tuotearkkitehtuuria ja näillä eri malleilla on omat ominaispiirteensä. On myös olemassa eri menetelmiä joita voidaan käyttää tukemaan moduulien ryhmittelyä. Tällaisia menetelmiä ovat esimerkiksi Design Structure Matrix (DSM), Modular Function Deployment (MFD) ja Function Structure Heurestics.

On tärkeää, että tuotearkkitehtuuri korreloi yritys- ja tuotestrategioiden kanssa, sekä vielä tuotteen teknistenominaisuuksien kanssa. Valitun arkkitehtuurin tulee olla myös tasapainossa kaikkien tuotteen elinkaaren vaiheiden suhteen, jotka ovat kehitys, valmistus, käyttö, hävittäminen.

Kuvassa 32 ja on esimerkki tuotteen toiminnallisten elementtien määrittämisestä. Ylinnä kuvassa on vesipumpun päätoiminto sekä laitteen toimintaan liittyvät energia-, informaatio- ja materiavirrat.. Kuvassa on esitettynä myös päätoiminnon jaottelu tarkemmin eri alitoimintoihin, joiden avulla tuotearkkitehtuurin määrittely on aloitettavissa.


Kuva 29. Valmis proto.

TuotearkkitehtuuriTuotteen arkkitehtuuri on suunnitelma, jonka mukaan tuotteen toiminnalliset elementit järjestetään fyysisiksi osasiksi (chunks) sekä jonka mukaan osaset ovat vuorovaikutuksessa keskenään.

Tuotteen voidaan ajatella koostuvan joko toiminnallisista elementeistä tai fyysisistä elementeistä. Toiminnalliset elementit ovat yksittäisiä toimintoja tai muutoksia, jotka yhdessä muodostavat tuotteen toiminnan. Fyysisiä elementtejä ovat tuotteen osat, komponentit sekä alikokoonpanot, jotka toteuttavat tuotteen toiminnot.

Integraalisuus sekä modulaarisuus ovat kaksi tuotearkkitehtuuriin liittyvää tärkeää käsitettä. Kuvassa 30 on selvennettynä näiden kahden käsitteen ero.


Function AFunction B

Function C Function D

Function A

Function D

B C






Function A

Function D

B CFunction A

Function D

B C

Kuva 30. Integraalisuus ja modulaarisuus [K. Höttä-Otto 2005] Integraalisen arkkitehtuurin ominaisuuksiin kuuluu, että yksittäinen tuotteen osa pitää sisällään useita toiminnallisia elementtejä ja / tai vuorovaikutukset tuotteen osien välillä ovat heikosti määriteltyjä. Modulaarisen arkkitehtuurin ominaisuus on, että jokainen fyysinen osa toteuttaa tietyn joukon toiminnallisia elementtejä sekä modulaarisessa arkkitehtuurissa vuorovaikutukset ovat selvästi määritelty osien välillä.

Valmiissa protossa kaikki vaatimukset saatiin toteutettua. Ilman jatkuvaa käytännön testaamista protoa ei koskaan olisi saatu aikaiseksi. Jokainen testi dokumentoitiin huolella, testit valokuvattiin, videoitiin ja sen aikana esitetyt kommentit ja parannusehdotukset dokumentoitiin ja ne pyrittiin ottamaan huomioon seuraavissa kehitysversioissa.


Tämä vaihe ikävä kyllä koetaan vaiheeksi, jossa mitään ei tapahdu ja hanke tuntuu polkevan paikoillaan. Mahdolliselle tilaajalle ei ole esitellä konkreettisia tuloksia ja vaiheesta halutaan päästä mahdollisimman pian eroon ja siirtyä näkyviä tuloksia tuoviin vaiheisiin, kuten työkuvia tuottavaan suunnitteluun ja fyysisiä malleja tuottaviin testaamiseen ja prototypointiin.

5eyes™-prosessimallissa pyritään toteuttamaan prosessin Ideaksi- ja Informaatioksi-vaiheet mahdollisimman kattavasti. Tarkasteltaessa esimerkiksi Teknillisen korkea-koulun Tuotekehitysprojekti-kurssin menestyneimpiä projekteja, nousee vahvimmiksi menestystekijöiksi tuotemahdollisuuksien ja asiakkaan motiivien tunnistamisen lisäksi innostus ja sitoutuminen kehitystyöhön. 5eyes™-prosessimalli pyrkiikin muuttamaan asiakastarpeista syntyneet tuotemäärittelyt ja tarpeet suunnittelijoiden innostukseksi, minkä myötä asiakas pyritään sitouttamaan ja osallistumaan kehitystyöhön kaveri-hengessä. Tavoitteena on luoda ilmapiiri, jossa pienistä ideanmurusista pyritään kas-vattamaan ideavyöryjä. Päävaiheet ja tavoitteet ovat sinänsä samoja, kuin tuotekehitys-prosessimallien vaiheissa yleensä, mutta prosessi pyritään asiakkaan tarpeiden syvälliseen tunnistamiseen ja työinnokkuuden korostamiseen. 5eyes™-prosessimallin tavoitteena on haastaa perinteiset, jäykkiin standardeihin pohjautuvat prosessimallit keskusteluun asiakastarpeiden ja innostuksen tärkeydestä tuotekehityshankkeissa.

Kuva 5. 5eyes™-prosessimalli ja sen vaiheet, tavoitteet ja painopisteet. Tuotteilta, jotka ovat nousseet niin sanotuiksi tuoteikoneiksi, kuten Sony:n Walkman-korvalappustereot, edellytetään, että kaikki menestyksen tekijät ovat olleet tasapainossa, tuotteelle on ollut olemassa tarve ja suunnittelijat ovat onnistuneet luomaan juuri tarpeita vastaavan tuotteen. Vuonna 1979 markkinoille tuodun tuotteen ratkaisuja ja mielikuvia käytetään yhä nykyisissä mp3-soittimissa lähes kolme vuosikymmentä myöhemmin.


II Resurssien hallinta ja tunnistaminen Laajuudeltaan määrätty projekti suunnitellaan joko aikataulun tai käytettävien resurssien mukaan. Ensinnä mainitussa resursseja hankitaan niin paljon, että aikataulu saavutetaan ja jälkimmäisessä aikataulu sovitetaan resursseihin.

Resurssit korreloivat väistämättä lopputuloksen kanssa. Useassa projektissa resursseja muutetaan kesken toteutuksen – useimmiten niitä karsitaan. Tällöin projektipäällikön pitää suhteuttaa myös lopputulos tehtyihin muutoksiin: ”vitosella ei saa kympin leluja”.

Projektilla on aina tavoite. Projektista riippuen tavoitteen selkeys vaihtelee, mikä heijastuu suoraan resurssien arvioinnin tarkkuuteen: vrt. kehitä uusi silitysrautamalli vs. kehitä uusi talousjärjestelmä markkinatalouden tilalle. Jälkimmäisen projektin kustannusten arviointi pilkun tarkasti ei ole mahdollista.

Pieni pessimismi resursoinnissa on projektipäällikölle hyväksi. Iloisen itsepetoksen sijaan päällikkö voi jo lähtökohtaisesti olettaa, että rahat loppuvat, aikaraja umpeutuu ja henkilöstösotkuja kehkeytyy. Riskien myöntämisen jälkeen suunnittelussa voidaan keskittyä niiden hallitsemiseen.

HenkilöstöresurssitProjektia aloitettaessa projektiin osallistuvat henkilöt on koottu listalle ja pahimmassa tapauksessa osa heistä myös jää ”nimeksi listalle”. Mikäli osallistuminen projektin aloituskokoukseen on heikkoa, tulevaisuus ei voi olla paljoa valoisampi.

Kokemattoman projektivetäjän ei kuitenkaan pitäisi laskea Kallea mukaan 15 % * 40 h / viikko, sillä Kalle joutuu väistämättä priorisoimaan töitään ja toisaalta 15 % viikoittaisella työpanoksella ei juuri ihmeitä tehdä.

Tilanne ei välttämättä ole sen valoisampi, vaikka henkilön resursseista osoitettaisiin 50 % projektille. Nykyisessä tasapäistävässä järjestelmässä kieltäydytään sanomaan ääneen, että ihmisten kyvyissä on huikeita eroja.

Tylystä alkupuheesta huolimatta projektipäällikön ei kannata heittäytyä skeptiseksi ja tuomitsevaksi. Suurin osa työntekijöistä tekee työnsä hyvin. Ihmiset ovat erilaisia ”työkaluja”. Pulttia ei kannata yrittää avata ruuvimeisselillä – tutustu työntekijöihisi. Yksi hengenluoja saattaa motivoida loput tiimistä ylittämään itsensä.

Kaikkea ei tarvitse tehdä itse. Pidä projektiryhmä toiminnan ytimessä ja osta projektin erikoisosaaminen ulkoa.

Taloudelliset resurssit Rahallisten resurssien hahmottaminen on kaikkein helpointa – rahamäärä voidaan kuvata yhdellä luvulla. Oleellinen kysymys onkin: paljonko on riittävästi?

Projektin taustalla on tyypillisesti selvitys, joka ottaa kantaa myös kustannuksiin. Mikäli tällainen selvitys on tehty, päällikön tehtävänä on tarkistaa, miten tarkka selvitys on. Omaa budjettiarviota ei kannata perustaa esiselvityksen mielivaltaiseen arvioon.

Projektipäällikön päämäärä budjettia laadittaessa tulisi olla suuruusluokkien hahmottaminen ja suurimpien kulutekijöiden nostaminen esiin. Panostaminen suurten tekijöiden tarkkaan kustannusarviointiin takaa myös riittävän tarkkuuden kokonaisbudjetille. Pienet kulutekijät saavat kaksinkertaistua budjetti pysyessä edelleen ruodussa.


Niin sanottu tonttulakki-ilmiö ilmeni 1:1 prototyypin testeissä vasta kolmannella testikerralla. Ajatukseen, että vesi virtaa ”itsestään” suojan ylempiin osiin ennekuin suojan alempiosa on täynnä, ei osattu varautua ollenkaan.

Kuva 26. Geeliytymisongelman ratkaiseminen.

Kuva 27. Täysikokoinen prototyyppi.

Kuva 28. Tonttulakki-ilmiö.

Geeliytymisen havaittiin olevan erittäin epätasaista ja ongelmat olivat juuri päinvastaiset hypoteesiin verrattuna. Tämän ongelman tutkimiseksi rakennettiin yksinkertainen lokerotorni jonka avulla pystyttiin havaitsemaan, mitätäytön aikana oikeasti tapahtuu. Osatoimintoa simuloiva,muutamia euroja maksanut rakennelma antoi vastauksia sekoittumis- ja geeliytymisongelmiin.

Ilmiöt ja rakenneratkaisut olivat valmistusteknisesti ja kustannussyistä järkeviä tehdä mittakaavassa olleilla prototyypeillä ja siirtää siinä toimineet ratkaisut lopulliseen prototyyppiin. Ensimmäisessä 1:1 prototyypissä ilmeni kuitenkin useita muita ongelmia, jotka eivät tulleet esiin aikaisemmissa prototyypeissä.Esimerkiksi matala veden syöttöno-peus ja paine aiheuttivat suuria ongelmia geeliytymiselle ja suojan pystyyn nousemiselle


Ensimmäinen geelillä tehty täyttö osoitti, ettei geeli tule ulos suojasta kovinkaan helposti. Kuvan suojan tyhjentäminen kesti yli kaksi tuntia, kun nykyisen version jonka tilavuus on yli kaksi kertaa suurempi saa tyhjennettyä muutamissa minuuteissa. Testissä kokeiltiin myös kemikaalia joka nesteytti geelin. Kemikaalilla oli tarkoitus saada geeli huuhdottua pois kadulta, mutta sen toimivuus yhdistettynä tyhjennysvaikeuk-siin synnyttivät ajatuksen tehok-kaammasta tyhjennysratkaisusta.

Pelkkä tietokoneella tehty suunnittelutyö on tylsää, johon yksinkertaisinkin käytännön puuhastelu ja askartelu tuo suunnittelijan usein kaipaamaa vaihtelua. Eihän kukaan halua tehdä lomamatkaa siten, että katselee oppaan tekemää esittelyvideota kotona. Suunnittelun tulokset täytyy voida jotenkin kokea.

Case: SuperAbsorbent-projekti (räjähdesuoja) Seuraavassa käydään esimerkkiprojektin avulla läpi, miten täysin uutta ballistista suojaratkaisua testattiin ja mitä testeistä opittiin. Suojaratkaisu perustui polymeerijauheeseen, joka kykenee imemään itseensä huomattavan määrän vettä. Veden ja jauheen muodostama seos muistuttavat sammakonkutua. Geelin toimivuudesta ballistisena suojana oli projektin alkaessa lähinnä arveluja, mutta testeistä ei ollut minkäänlaista dokumentaatiota.

Seuraavassa on esitelty SuperAbsorbent-projektin runsasta protoilua ja sen avulla saavutettuja hyötyjä ja oppeja.

Kuva 24. Fyysinen kohde jota voi osoittaa sormella.

Kuva 25. Geelitäytteisen suojan tyhjennys.

Eräs testaamisen tärkein piirre on havaita esimerkiksi valmistus-menetelmien rajoitukset uusille konstruktioille. Kuvan 24 prototyyppi opetti miten löysä vedellä täytetty PVC-kankainen suoja saatiin pysymään pystyssä ja miten täyttöyhteet tulisi sijoitella.


Projektiluontoisessa työskentelyssä budjetti kannattaa laatia aikataulussa näkyvän tehtävälistan mukaan. Eli kustannusten muodostuminen on listattu ajallisessa järjestyksessä, jolloin budjettia voidaan helposti seurata ja mahdolliset ylitykset havaitaan riittävän ajoissa.

Projektin käynnistyttyä aletaan seurata laaditun budjetin toteutumista - todellisuudessa käytetyn rahan tai työtuntien määrää verrataan suunniteltuun rahan tai työtuntien käyttöön. Seurannassa on jälleen oleellista nostaa ylitykset esiin ja etsiä niille syy: Pelkosen vetämä markkinatutkimus on kuluttanut 70 % budjetistaan jo alkuvaiheessa. Tutkimusta tehdään paljon aiottua laajemmalle kohderyhmälle.

Liian väljästi laadittu budjetti ei palvele ketään – budjetti voidaan tällöin jättää yhtä hyvin tekemättä.

Ajankäytön hallinta Aineellisten resurssien tunnistamisen lisäksi tiedon jakamisessa on puutteita. Yrityksissä on tietysti eroja, mutta uusien työntekijöiden perehdytys on (itse aiheutetun) kiireen takia nykyisellään lähellä nollaa. Tällöin myös tieto yrityksen resursseista jää tulokkaalta pimentoon, vaikka yksinkertaisimmillaan kyse on yhden tiedoston luovuttamisesta. Lähteminen aivan perusteista saattaa puuduttaa lukijaa, mutta toisaalta suurimmat virheet tehdään, kun projektin perustuksissa on mätää. Jos työtä tehdään projektina, projektilla on olemassa selvä aloitus- ja lopetuspäivämäärä. Työ tehdään näiden päivien välisenä aikana.

Työaikaa ei kannata katsoa kalenterissa näkyvänä aikavälinä, vaan työpäivinä. Kun viikonloput, lomapäivät ja muut pakolliset menot poistetaan, kalenteriin jäävä työpäivämäärä saattaa yllättää. Työpäivästä jää juoruamisen, tupakanpolton ja joutavien rutiinien jälkeen n. 70 % jäljelle, joten tehollisten tuntien määrä on kalenteriaikaan verrattuna kohtalaisen pieni. Aikataulun suhteen ei kannata olla optimistinen.

Todellisten työpäivien ollessa selvillä voidaan aloittaa aikataulun suunnittelu. Projektisuunnitelmassa hahmotettu tehtävälista kirjoitetaan auki aikajanalle siten, että kukin työ laitetaan alkamaan heti, kun se vain on edellisten tehtävien puolesta mahdollista – munakasta ei voi tehdä ennen kuin munat on ostettu.

Auki kirjoitetusta aikataulusta käy ilmi ns. kriittinen polku – niiden tehtävien ketju, joiden kesto määrää projektin lyhimmän valmistumisajan. Ketjun tunnistaminen on tärkeää, sillä yhdenkin tehtävän viivästyminen tässä ketjussa viivästyttää koko projektin valmistumista saman verran. Luonnollisesti juuri kriittisen polun tehtäviin kannattaa panostaa resursseja, sillä muilla tehtävillä on pelivaraa.

Projektin aikataulussa tulisi olla puskureita, jotka ovat vain projektin vetäjän ja ylemmän johdon tiedossa. Puskurit kannattaa mitoittaa erikseen sen sijaan, että ylimääräistä aikaa lisätään hitunen jokaiseen työvaiheeseen.

Aikataulu on pelkkä paperi, jos siihen ei sitouduta. Sen takia tehty aikataulusuunnitelma pitää käydä työtä tekevän projektiryhmän kanssa läpi. Ylhäältä annetun suunnitelman torjuminen on yksilölle varsin luonnollinen reaktio.

Sitouttamisen lisäksi aikataulua pitää valvoa. Mikäli aikataulusta livetään, asiaan täytyy puuttua. Käytännössä puuttuminen tarkoittaa asian nostamista esiin ja syyn selvittämistä: Möttösen koordinoima alihankintasuunnittelu on viikon myöhässä. Alihankkijalle ei ole toimitettu tarvittavia dokumentteja.


Projektin jaksoista tärkein on alku. Tärkeintä on aloittaa työ heti ja raivolla. Tärkeää on huomata, että tämä ei tarkoita, että projektin lopputuote alkaisi hahmottua samalla raivolla. Alkuvaiheessa kuluu kosolti aikaa nollaruudussa pyörimiseen, eli varsinainen tuote ei hahmotu, mutta työtä tehdään sitäkin enemmän.

Lorviminen on erityisen helppoa projektin alussa, sillä työ on vielä abstraktilla tasolla ja työ on vaativaa - lisäksi useilta tiimeiltä puuttuvat työkalut tehokkaaseen ideointiin ja konseptointiin. Niinpä projektin alku kuluu odotellessa kiirettä ja kun kiire alkaa, valitaan sokeasti yksi konsepti ja aletaan kehittää sitä.

Koulutus on lääke ongelmaan. Ensihätään kannattaa tutustua tämän oppaan ideointi- ja konseptointityökaluihin.

Hiljainen tieto Mitä suurempi yksikkö, sitä enemmän päällekkäistä ja turhaa työtä tehdään. Sama pätee päällekkäisiin laitehankintoihin. Nykyisessä runsaudenpulassa harva enää tietää, mitä kaikkea yrityksen olemassa oleviin resursseihin kuuluu ja miten niihin pääsee käsiksi.

Hyvä esimerkki on vaikkapa alihankinta. Harvemmin tarvittavat alihankintapalvelut teetetään tyypillisesti ilman sitovampaa alihankintasopimusta ja yrityksen eri osastoilla saattaa olla samalle palvelulle useita eri alihankkijoita.

Tieto alihankkijoiden pätevyydestä on kuitenkin ns. hiljaista tietoa, jota ei dokumentoida. Niinpä osa yksiköistä tuskailee alihankkijoiden turhien lupausten ja toimitusvaikeuksien kanssa, vaikka viereisellä osastolla on halvempi ja luotettavampi alihankkija samaan tehtävään.

Vaikka yrityksen resurssien kirjaaminen ja luettelon ylläpito vie perustamisvaiheessa aikaa, työ maksaa itsensä helposti takaisin. Luettelon ei pidä olla viimeiseen piirtoon muodollinen, kunhan se sisältää riittävän informaation.


testisuunnitelmassa, jotta testit eivät epäonnistu huonon kommunikaation vuoksi. Testiympäristön vaatimukset ja rajoitukset tulee myös selvittää testisuunnitelmassa. Testimenetelmien yksiselitteinen kuvaaminen ja ennaltasuunnittelu ovat testin tehokkuuden kannalta oleellisia.

Testin suorittaminen Testin ennaltaharjoittelun tärkeys korostuu testeissä, joissa paikalla on esimerkiksi tuotteesta kiinnostuneita potentiaalisia asiakkaita. Jos testit suoritetaan ulkona niin sanotuissa kenttäolosuhteissa, eivät sisällä lämpimässä tehdyt harjoitukset vielä anna minkäänlaista kuvaa testien todellisuudesta. Testit voivat venyä useiden tuntien mittaisiksi, jolloin muun muassa oikea vaatetus on avainasemassa.

Dokumentaatio Pääsääntönä voisi sanoa, että kaikki mahdollinen kannatta testaushetkellä dokumentoida. Epäoleellisen voi helposti karsia pois testiraportista, mutta jälkikäteen testeistä on mahdoton saada puuttuvia tietoja. Tyypillisiä puutteita, jotka testeissä jäävät usein dokumentoimatta:

12. Puuttunut valokuva, testeissä on unohdettu kuvata jokin vaihe, joka osoittautuu raportin kirjoitushetkellä kriittiseksi puutteeksi.

Vinkki: Kuvaa kaikki mahdollinen, nimeä kuvauksen vastuuhenkilö, laadi ennalta suunnitelma seikoista, jotka on kuvattava.

13. Puuttunut tapahtumakirjaus, esimerkiksi ajanotto epäonnistuu tai unohtuu.

Vinkki: Videoi tapahtuma alusta loppuun, digikamerat ovat yleisiä ja nauhat halpoja. Nauhalta näet muutenkin testin suorittamisen ja voit tehdä lisähavaintoja.

14. Testeihin osallistujia ja yhteystietoja ei kirjata, testeissä on usein paikalla ”asiakkaan asiakkaita”, joilla saattaa olla hyviä ehdotuksia tuotteeseen liittyen, mutta heihin ei saa yhteyttä testien jälkeen.

Vinkki: Kirjaa ylös kaikkien osallistujien nimet, yhteystiedot (sähköposti, puhelinnumero).

15. Olosuhteiden kuvaaminen, usein testien aikainen lämpötila, ilmankosteus tai muu tulokseen mahdollisesti vaikuttava seikka jää kirjaamatta.

Vinkki: Varaa paikat tiedoille testisuunnitelmaan tai pöytäkirjaan johon tulokset kirjataan.

16. Jotakin jää tekemättä, koska testeihin varaudutaan riittämättömin resurssein, jolloin tulosten kirjaaja tai testin johtaja joutuu itse osallistumaan tekemiseen ja jokin testin osuus jää kiireen vuoksi tekemättä. Tosin testeihin osallistuvilla henkilöillä tulee olla selkeä rooli ja syy testeihin osallistumiseen, liika väkimäärä usein vain sotkee testin kulun.

Vinkki: Hyvä testisuunnitelma paljastaa mahdolliset vajavuudet, nyrkkisääntönä voisi pitää, että yhden henkilön aika kuluu testien johtamiseen ja mahdollisten asiakasosallistujien kysymyksiin vastaamiseen ja yhden henkilön vastuulle kannattaa jättää tulosten kirjaaminen ja ajanotto.

Hyvä testi on myös opettavainen. Se ei pelkästään kerro ”kyllä–ei-tyyppisesti” onnistuiko testi vai ei, vaan toimii ideoiden herättäjänä ja motivaation kasvattajana.


(CAD, CAE, CAM), prototyypeillä, pikamalleilla, jne. Menetelmästä riippumatta testaamisella tulisi aina olla jokin tarkoitus johon pyritään. Tyypillisesti suunnittelijoilla ja testihenkilökunnalla on taipumus suunnitella ja toteuttaa testit liian yksityiskohtaisilla malleilla. Esimerkiksi uutta katamaraanirunko ideaa hahmoteltaessa on täysin turhaa mallintaa alustavasti valittuja komponentteja tietokoneella työkuvatasolle, kun tieto komponenttien tilantarpeesta ja sopivuudesta toimintaympäristöön voidaan saada selville yksinkertaisilla maksimimittoihin perustuvalla yksinkertaisella tilavuusmallilla.

Testin onnistumista ei tulisi mitata vain tuloksena kuinka lähelle suunnitelmat osuivat yksiin testituloksen kanssa vaan useimmiten opettavaisimpia testejä ovat pieleen menneet testit. Ne pakottavat suunnittelijan pohtimaan perusteista lähtien mikä meni pieleen. Epäonnistumisia tapahtuu tyypillisesti sellaisissa hankkeissa, jossa kehitetään jotakin täysin uutta. Suunnittelija tyypillisesti mielellään suunnittelee kaiken mahdollisimman pitkälle valmiiksi ennen käytännön testeihin siirtymistä. Suunnittelupöydällä tapahtunut suunnittelu on toki järkevä viedä mahdollisimman pitkälle, ennen käytännön testaamista. Tällöin suunnittelijan tulee kuitenkin olla varma siitä, että oletukset, joihin suunnittelu perustuu, ovat oikeita.

Monessa yrityksessä on luovuttu niin sanotuista protopajoista, jossa suunnittelijat voivat yksinkertaisia rakennustarvikkeita ja työkaluja hyväksikäyttäen rakennella fyysisiksi malleiksi ideat ja suunnitelmat. Trendinä suunnittelussa on ollut siirtyminen kalliiksi koetusta ja vanhanaikaisesta kokeellisesta suunnittelusta tietokoneavusteiseen suunnitteluun ja simulointiin, jotka koetaan kehittyneiksi ja tehokkaiksi työkaluiksi. Kukaan ei varmaankaan kiistä menetelmien tehokkuutta, mutta usein tietokone muuttuu rengistä isännäksi. Erityisesti suunnitteluhankkeiden alkuvaiheessa muutamissa minuuteissa tehdyt testit kertovat sen minkä kokeiluun tietokoneella saattaa kulua useita tunteja, jopa viikkoja.

Hyvän testin tunnusmerkkejä Hyvän testin järjestäminen on haastava työ. Testit maksavat usein paljon niin käytetyn työajan kuin materiaalien aiheuttamien kustannusten vuoksi. Oleellista onkin, kuinka testi voitaisiin suorittaa siten, että se kertoo halutut seikat, mutta antaisi mahdollisesti vihjeitä muista edullisista ja kenties uusista paremmin toimivista ratkaisuista. Hyvä testi edellyttää huolellista valmistautumista. Testit tehdään usein muualla kuin itse suunnittelutyö ja esimerkiksi videonauhan loppuminen kriittisellä hetkellä voi tehdä koko testistä arvottoman. Testimenetelmien kuvaaminen sanallisesti ja kuvallisesti testisuunnitelmaan auttavat testin järjestäjiä ja avustavaa henkilöstöä ymmärtämään tavoitteet ja vaatimukset. Jos mahdollista, tulisi testaus tehdä aina jonkin standardin mukaisesti tai sitä jäljitellen. Tällöin tulokset ovat yleisempiä ja niiden vertaaminen muihin tuloksiin on mahdollista.

TavoiteTestille tulee asettaa selkeä tavoite, mitä ilmiötä testillä tutkitaan ja mitä tietoa testin odotetaan tuottavan. Kaikkien testiin osallistuvien henkilöiden tulee olla selvillä tavoitteesta. Hyvä tapa on lähettää testisuunnitelma kommentoitavaksi tekniselle henkilökunnalle tutkimuslaitokseen. Testin sujumisen ja luotettavuuden kannalta on myös hyvä tapa koota testeihin osallistuva henkilöstö yhteiseen neuvonpitoon ennen testiä.

TestisuunnitelmaTestisuunnitelmasta tulee käydä yksiselitteisesti ilmi testin suorittamisen vaiheet, testin kulku tehtäväkuvauksineen ja vastuuhenkilöineen. Terminologia kannattaa usein sopia


III Kommunikointi projektissa Tuotekehityksen piirissä kommunikaatio on lähes kaikkeen työhön olennaisesti liittyvä osa-alue, joka kuitenkin jää usein hyvin pienelle huomiolle ja nostetaan esille vasta silloin, kun huomataan tilanteen olevan jo pahasti pielessä. Ongelmat ovat samanlaisia niin pienissä, kuin suurissakin organisaatioissa ja niiden taustalta löytyy yksi yhteinen tekijä: ei tiedosteta toimivan kommunikaation merkitystä oman työn onnistumiselle.

Ajatusten saaminen konkreettiseen muotoon on edellytys niiden onnistuneelle kommunikoinnille toisille ihmisille. On myös helpompi palata aikaisempiin pohdiskeluihin, kun edelliset tulokset on asianmukaisesti dokumentoitu. Ajatuksista tulee konkreettisia silloin, kun ne puhutaan, kirjoitetaan paperille tai syötetään tietokoneelle. Ajatus voidaan esittää myös kaavion, kuvan tai erilaisten mallien avulla, jolloin viestin sisältö on helpompi ymmärtää ja väärinymmärryksen vaara pienenee. Kommunikointia varten luodun mallin ei tarvitse olla lähelläkään täydellistä – riittää, että se on tarpeeksi hyvä keskustelun pohjaksi ja välittää olennaisen asian henkilöltä toiselle.

Kuva 6. Keinu – Erilaisia näkemyksiä samasta asiasta. [tuntematon]

Alkuperäinen ehdotus

Taloushallinnon malli

Suunnittelijan malli

Tuotannon malli Ylläpidon & huollon malli

Dokumentoitu malli

Markkinoinnin malli

Karvanoppa-malli

Laskutus-malli

Asiakkaan tarve


Kommunikaatiotyypit Kommunikaatiota on muodollisuudeltaan kahdenlaista – virallista ja epävirallista. Virallisena kommunikaationa voidaan pitää dokumentteja, tietokantoja ja erilaisia kokouksia. Kaikkea muuta voidaan pitää epävirallisena. Monesti organisaatiot suhtautuvat epäviralliseen kommunikaatioon ikään kuin sitä ei olisikaan, vaikka käytännön työssä epävirallisella kommunikaatiolla on erittäin keskeinen rooli.

Muodollista eli virallista kommunikaatiota tarvitaan erityisesti tapauksissa, joissa asianomaisten välille ei itsestään synny riittävää kanssakäymistä. He eivät ole fyysisesti tarpeeksi lähellä toisiaan tai he työskentelevät eri tiimeissä tai edustavat eri toimintoja (esim. markkinointi ja tuotekehitys). Muodollisella kommunikaatiolla varmistetaan, että toiminnan kannalta riittävä määrä informaatiota liikkuu organisaatiossa. Useimmi-ten myös kaikki päätöksenteko tapahtuu virallisen, dokumentoidun tiedon pohjalta.

Viralliseen kommunikaatioon liittyy muutamia perusongelmia. Ensinnäkin tulee tietää etukäteen, kuka tarvitsee mitäkin tietoa ja milloin. Koska tämä ei ole käytännössä aina mahdollista, voidaan päätyä tilanteeseen, jossa palaverit ja dokumenttien lukeminen vievät kaiken ajan varsinaiselta työltä. Toisaalta voi käydä myös niin, että oman työn kannalta keskeistä tietoa jää saamatta. Toisekseen virallinen kommunikaatio tuo mukanaan hitautta prosessiin, sillä käytössä voi olla aikaan sidottu raportointisykli tai dokumentit toimitetaan eteenpäin vasta siinä vaiheessa, kun ne ovat viimeisteltyjä ja valmiita. Ajallinen etäisyys tiedon tuottamisen ja sen tarvitsemisen välillä on yhtä merkittävä kommunikaatioeste, kuin fyysinen etäisyyskin.

Projektin edetessä tiedon tarve muuttuu jatkuvasti tilanteiden mukana ja näin ollen periaatteessa koska tahansa voidaan tarvita mitä tahansa tietoa. Silloin on turvauduttava epäviralliseen kommunikaatioon ja etsittävä henkilö, joka tietää asiasta ja esitettävä kysymys hänelle. Epävirallinen tieto on nopeasti saatavilla, mutta ei valmiiksi jäsenneltyä, eikä välttämättä sellaisenaan tarkoitukseensa soveltuvaa.

Kommunikaation muodollisuuden lisäksi kommunikaation toimivuuteen vaikuttaa tapa, jolla viesti toimitetaan henkilöltä toiselle. Suullisella ja kirjallisella kommunikaatiolla, samoin kuin erilaisilla kommunikaatiomedioilla, on toisistaan eroavia ominaisuuksia. Ei voida sanoa, että jokin niistä olisi muita parempi, vaan erilaisiin tilanteisiin tarvitaan erilaisia kommunikaatiotapoja.

Jos kommunikaatio on tiedotusluonteista, on kommunikaation kohteena oleva tieto yksiselitteistä ja muuttumatonta. Tällöin informaatio halutaan siirtää yksisuuntaisesti kohderyhmän tietoon mahdollisimman tehokkaalla tavalla. Tiedotusluonteisessa kommunikaatiossa esimerkiksi puhelinneuvottelu, sähköpostijakelu ja dokumentteihin pohjautuva viestintä ovat käyttökelpoisia.

Usein kommunikaatio kuitenkin tähtää uuden tiedon luomiseen, esimerkiksi ongelmanratkaisuun tai päätöksentekoon. Silloin on olennaista osallistujien tiedon ja kokemusten yhdistäminen uudella tavalla, joka on kokonaisuutena suurempi kuin osiensa summa. Tällöin tarvitaan myös tehokkaampia kommunikaatiomenetelmiä. Kasvokkain tapahtuva keskustelu antaa mahdollisuuden välittömään palautteeseen ja kysymysten esittämiseen. Mukana on myös paljon sanatonta viestintää, joka jää pois puhelin- ja videoneuvotteluissa. Kun ihmiset ovat fyysisesti samassa huoneessa fläppitaulun ääressä, he näin ollen ideoivat paljon tehokkaammin, kuin esimerkiksi puhelinpalaverissa.


Analytical Hierarchy Process (AHP)

1 Equal importance3 Moderate importance of one over another5 Essential or stong importance7 Very strong importance9 Extreme importance2,4,6,8 Intermediate values

Number of Concepts: 3Number of Criteria: 4

C1: Size and appearance A B C ScoreA 1,00 5,00 6,00 3,11 0,717B 0,20 1,00 3,00 0,84 0,195C 0,17 0,33 1,00 0,38 0,088

C2: Manufacturing and Assembly A B C ScoreA 1,00 0,33 0,20 0,41 0,105B 3,00 1,00 0,33 1,00 0,258C 5,00 3,00 1,00 2,47 0,637

C3: Installation and Use A B C ScoreA 1,00 1,00 0,33 0,69 0,200B 1,00 1,00 0,33 0,69 0,200C 3,00 3,00 1,00 2,08 0,600

C4: Service A B C ScoreA 1,00 3,00 5,00 2,47 0,637B 0,33 1,00 3,00 1,00 0,258C 0,20 0,33 1,00 0,41 0,105

Criteria C1 C2 C3 C4 WeightC1 1,00 4,00 1,00 0,25 1,00 0,183C2 0,25 1,00 0,25 0,17 0,32 0,059C3 1,00 4,00 1,00 0,25 1,00 0,183C4 4,00 6,00 4,00 1,00 3,13 0,574

Decision matrix Weight A B CC1 0,183 0,717 0,195 0,088C2 0,059 0,105 0,258 0,637C3 0,183 0,200 0,200 0,600C4 0,574 0,637 0,258 0,105

Final Priority 0,540 0,236 0,224Rank I II III

IirznJ

jiji ,...,2,1

1

1

Iiz

zw I

ii

ii ,...,2,1

1

Kuva 23. AHP menetelmän käyttö konseptin valintaan Konseptien valintaan käytetään myös asiantuntijalausuntoja sekä katselmuspalavereita ja usein myös konsepteja arvioidaan käyttäen tarkistuslistoja. Tärkeää konseptia valittaessa on huomioida, että valinta suoritetaan pohjautuen useiden eri menetelmien käyttöön sekä arvioinnissa huomioidaan riittävästi eri näkökulmia tuotteeseen.

TestausTunnistaasiakkaan

tarpeet

Aseta tavoite

spesifikaatiot

Luokonsepteja

Valitsetuote-

konseptit

Testaa tuote-

konsepteja

Aseta lopulliset

spesifikaatiot


Tunnistaasiakkaan

tarpeet

Aseta tavoite

spesifikaatiot

Luokonsepteja

Valitsetuote-

konseptit

Testaa tuote-

konsepteja

Aseta lopulliset

spesifikaatiot


Tässä yhteydessä termillä testi tarkoitetaan tapaa tuottaa tietoa tutkittavasta ilmiöstä kehitystyön tueksi. Testi voi olla massiivinen koko tuotteen ominaisuuksia simuloiva testi tai pienimuotoinen kokeilu, jonkin piirteen havainnollistamiseksi. Testaaminen voi tapahtua monella eri tasolla, testejä voi tehdä paperilla (luonnokset), tietokoneella


Ulrich's Concept Screening

Criteria A B CSize and appearance + - - Worse than datum conceptManufacturing and assembly - D + S As good as datum conceptInstallation and use S A + + Better than datum conceptService + T -

2 U 21 M 2

S 1 0Sum 1 0 0Rank I II II

Kuva 21. Ulrich&Eppingerin esittelemä konseptien seulontamenetelmä Kuvassa 22 on esitettynä konseptien pisteytysmenetelmä. Myös tässä menetelmässä käytetään referenssiä jota vasten konsepteja verrataan. Referenssiksi voidaan valita jokin tietty konsepti, jokin vanha tai kilpailijan tuote tai referenssiksi voidaan asettaa jokin tietty suoritusarvo kullekin kriteerille. Arviointi tapahtuu yleisesti käyttäen arviointiskaalaa 1–5. Menetelmässä on myös mahdollista käyttää painotusta kriteerien välillä. Kunkin konseptin saama pistesumma saadaan laskettua kuvassa 22 esitetyn kaavan perusteella. Vertailun jälkeen lasketaan kunkin konseptin saama pistesumma sekä asetetaan konseptit arvojärjestykseen. Lopuksi kannattaa tehdä tulokselle herkkyysanalyysi siten, että muutetaan joitakin epävarmoja arvosanoja ja painotuksia ja tutkitaan tuloksen herkkyyttä näillä muutoksille.Ulrich's Concept Scoring

Criteria Weight A B (Datum) C 1 Much worse than referenceSize and appearance 0,25 5 3 2 2 Worse than referenceManufacturing and assembly 0,15 2 3 4 3 Same as referenceInstallation and use 0,25 3 3 4 4 Better than referenceService 0,35 4 3 2 5 Much better than referenceSum 3,70 3,00 2,80Rank I II III

IirwrJ

jijji ,...,2,1

1

Kuva 22. Konseptien pisteytysmenetelmä Analytical hierarchy process (AHP) -menetelmä on esitettynä kuvassa 23. Menetelmää on tähän asti käytetty harvoin konseptin valinnassa, mutta siitä voi olla hyötyä kun halutaan käyttää laajaa arviointiskaalaa. Vastakkainasetteluun perustuva painotus- ja pisteytysmenetelmä voi myös tuoda lisää ymmärrystä konseptin valintaan. Menetelmän käyttämisestä tulee hyvin raskasta jos vertailtavia konsepteja on useita tai jos käytetään monia arviointikriteereitä. Kuvassa 23 olevassa esimerkissä on käytetty Saatyn-menetelmää kunkin matriisin pisteiden laskemiseksi.


Kommunikaatio tuotekehitysorganisaatiossa Prosessin tehokkuuteen vaikuttaa merkittävästi se, kuinka hyvin siihen osallistuvat henkilöt pystyvät koordinoimaan töitä keskenään ja kuinka hyvin he kommunikoivat keskenään prosessin tehokkaan suorittamisen kannalta keskeisiä tietoja. Kun prosessi on monimutkainen, esimerkiksi iteratiivinen tuotekehitysprosessi, voivat huonosta kommunikaatiosta ja koordinaatiosta aiheutuvat tehokkuushäviöt jarruttaa työn etenemistä merkittävästi.

Pienissä projekteissa kommunikaation toimivuuden varmistamiseksi riittävät usein sellaiset järjestelyt, joiden myötä epävirallinen kommunikaatio huolehtii suurelta osin tiedon välittämisestä. Tämä voi toimistoympäristössä tarkoittaa työtilojen järjestelyä siten, että samaan ryhmään kuuluvat henkilöt työskentelevät samassa tilassa ja pystyvät näin helposti kommunikoimaan keskenään. Tällaisissa tapauksissa pääasiallinen kommunikointitapa on kasvokkain tapahtuva keskustelu, jolloin kommunikaatiosta ei aiheudu viiveitä ja toisaalta tarjoutuu mahdollisuus asioiden tarkentamiseen ja suoran palautteen antamiseen.

Hajautetussa ryhmätyössä epävirallisen kommunikoinnin tason vakiinnuttamiseksi saattaa riittää ryhmän yhteinen lounas- tai kahvihetki projektille sopivin välein, esim. joka perjantaiksi sovittu iltapäiväkahvi. Tällaisen epävirallisen tapaamisen yhteyteen kannattaa mahdollisuuksien mukaan ajoittaa myös viralliset kokoontumiset, jotta vältyttäisiin ylimääräiseltä matkustelulta. Virallisen ja epävirallisen tapaamisen tulisi kuitenkin tapahtua selkeästi eri paikoissa ja omilla aikatauluillaan tilaisuuksien erilaisen luonteen korostamiseksi.

Isoissa projekteissa ei pelkällä epävirallisella kommunikaatiolla voida taata kaikkien osapuolten informoimista. Erityisesti tilanteissa, joissa projektiin osallistuu osapuolia eri organisaatioista, tämä on otettava huomioon. Yhtenä ratkaisuna on projektin jakaminen ryhmiin, joiden sisällä kommunikaatio on luonteeltaan epävirallista, mutta joiden väliseen kommunikointiin ja koordinointiin käytetään muodollisempia ja virallisempia menetelmiä. Tällöin työ tulisi jakaa eri ryhmien kesken siten, että kukin osapuoli voi tehdä omaa työtänsä mahdollisimman itsenäisesti ja kaikkien osapuolten vastuualueet ja rajapinnat muihin ryhmiin on määritelty selkeästi. Ryhmien tavoitteiden tulee olla keskenään yhdenmukaisia ja toisiaan tukevia, jolloin ryhmien välillä voi tapahtua myös paljon epävirallista kommunikaatiota.

Onnistuneen kommunikaation varmistaminen Kommunikaation tehokkuus vaikuttaa koko organisaation tuloksellisuuteen. Onnistunut kommunikaatio tarkoittaa sitä, että jokainen lähetetty viesti saavuttaa vastaanottajansa ajallaan, minkä lisäksi vastaanottaja tulkitsee kaikki viestit juuri lähettäjän tarkoittamalla tavalla. Todellisuudessa näin ei kuitenkaan ole, vaan kommunikaatiossa on erilaisia häiriöitä ja esteitä, jotka vaikeuttavat viestin perillemenoa ja aiheuttavat viestin sisällön vääristymistä. Esimerkiksi ikä, sukupuoli ja kulttuuritausta vaikuttavat vastaanotetun viestin tulkintaan, minkä lisäksi vastaanottajan ennakkoasenteet viestin lähettäjää kohtaan voivat omalta osaltaan sävyttää viestin sisältöä perusteettomasti. Yksilön viestintätapoihin vaikuttavista taustatekijöistä johtuen etenkin toisilleen


tuntemattomien henkilöiden välisessä kommunikoinnissa on syytä pyrkiä mahdollisimman neutraaliin viestintään, jotta väärinymmärryksiltä voitaisiin välttyä.

Tehokkaan ja toimivan kommunikaation varmistamiseksi jokaisen viestin perillemenosta ja oikeasta tulkinnasta tulee varmistua. Perillemenon varmistamiseksi riittää yksinkertainen vastaanottokuittaus, esim. ”Sain viestisi ja ehdin kommentoida sitä huomenna iltapäivällä”, ”Hyvältä näyttää!” tai vain pelkkä ”Kuitti”. Oman organisaation sisällä on hyvä sopia yhteinen kuittauskäytäntö viestien perillemenon varmistamiseksi.

Viestin vastaanottamisen lisäksi on tärkeää varmistua myös viestin oikeasta tulkinnasta, sillä väärin tulkitulla viestillä voi pahimmassa tapauksessa olla päinvastainen vaikutus, kuin mihin alun perin pyrittiin. Oikean tulkinnan varmistaminen on kuitenkin erittäin hankala toteuttaa käytännössä, sillä se edellyttää suurta huolellisuutta niin vietin laatimisen, kuin tulkitsemisenkin kohdalla. Esimerkiksi sopimusneuvotteluissa molemminpuolinen, yhtäläinen tulkinta on välttämättömyys, mistä johtuen jokainen laadittu viesti luetaan ja varmistetaan moneen kertaan ennen viestin eteenpäin toimittamista. Tällainen toiminta tekee kommunikoinnista kuitenkin erittäin hidasta, joten siihen ei normaalissa kommunikoinnissa voida turvautua.

Toimivin tapa viestien oikean tulkinnan tehostamiseen on tutustuminen toiseen osapuoleen. Organisaatioiden välisessä viestinnässä käytetään ilmaisua giving faces(”annetaan naamat”) kuvastamaan vaihetta, jossa tutustutaan aiemmin pelkkinä niminä tunnettuihin osapuoliin. Tämän vaiheen katsotaan tehostavan viestintää merkittävästi.

Virheraportointia (squawks) käytetään lentoliikenteessä havaittujen vikojen kommunikointiin. Lennon jälkeen koneen kapteeni ilmoittaa virheraportissa koneessa havaitsemansa viat ja puutteet. Virheraporttien perusteella mekaanikot huoltavat koneen ja kirjaavat raporttiin korjaustoimenpiteensä.

Tässä muutamia esimerkkejä lentäjien ja mekaanikkojen välisestä raportoinnista: O= Lentäjän ilmoittama ongelma. V= Mekaanikon vastaus.

O: Vasen sisäpyörä lähes vaihdon tarpeessa. V: Vasen sisäpyörä lähes vaihdettu.

O: Koelento OK, mutta automaattilaskeutuminen oli melko raju. V: Automaattilaskeutumisjärjestelmää ei ole asennettu tähän koneeseen.

O: Potkurin nro 2 voitelujärjestelmässä vuoto. V: Potkurissa nro 2 normaalia vuotoa, potkureista 1, 3 ja 4 se puuttuu.

O: Jotain löysällä ohjaamossa. V: Jotain kiristetty ohjaamossa.

O: Kuolleita hyönteisiä tuulilasissa. V: Eläviä hyönteisiä vain tilauksesta.

O: Oikeassa laskeutumistelineessä merkkejä vuodosta. V: Merkit poistettu.

O: Radiolaitteiston ääni uskomattoman kovalla. V: Ääni säädetty uskottavammalle tasolle.

O: Kitkalukko jumiuttaa kaasukahvan paikalleen. V: Siihenhän se on tarkoitettu.

O: Arvelen, että tuulilasissa on särö. V: Arvelen, että saatat olla oikeassa.

O: Moottori numero 3 puuttuu. V: Moottori löydetty oikealta siiveltä lyhyen etsiskelyn päätteeksi.

O: Lentokone käyttäytyy hassusti. V: Lentokonetta käsketty ryhdistäytymään ja käyttäytymään asiallisesti.


Konseptin valintamenetelmiä Tällä hetkellä systemaattisten valintamenetelmien käyttö on suhteellisen harvinaista Suomessa. Kuitenkin systemaattisuudella on mahdollista saavuttaa selvää etua epäformaaleihin prosesseihin verrattuna. Tämänlaisia etuja on esitetty olevan: Käyttäjälähtöiset kriteerit korostavat asiakasnäkökulmaa tuotteen suunnittelussa, kilpailukykyisempi design, lyhyempi suunnitteluaika, ryhmän laajan osaamisen parempi hyödyntäminen päätöksenteossa, sekä päätöksenteko prosessin parempi dokumentointi. Tutkimuksen mukaan suomalaiset yritykset, jotka käyttävät systemaattisia menetelmiä ovat tyytyväisempiä konseptin valintaan, kuin ne yritykset joilla ei ole käytössä systemaattisia menetelmiä. Alla kuvassa 20 on esitettynä muutaman käytetyn valintamenettelyt käyttökohteet.

Kuva 20. Yleisiä konseptinvalintamenetelmiä.Kuvassa 21 on esitettynä konseptien seulontamenetelmän toimintaperiaate. Ensimmäiseksi menetelmässä asetetaan jokin konsepti referenssikonseptiksi, jota vasten muita konsepteja verrataan. Referenssiksi voidaan valita joku keskinkertainen konsepti tai siksi voidaan valita mahdollisesti myös joku vanha tai kilpailijan tuote. Referenssi voi myös vaihdella eri kriteerien kohdalla, jos ei löydetä keskinkertaista vaihtoehtoa referenssiksi. Tällä toimenpiteellä pyritään välttämään arvosteluskaalan suppeneminen. Arviointi toteutetaan vertaamalla kutakin konseptia referenssiin nähden ja arvostelemalla konseptit kriteereittäin käyttäen arvosanoja +/S/-. Lopuksi lasketaan yhteen kunkin konseptin saamat arvosanat kuten kuvassa 21. Arvosanat voidaan muuttaa vielä pisteiksi valituilla kertoimilla.

Yleisiä konseptinvalintamenetelmiä

Konseptien seulonta

o Tunnista lupaavat ja potentiaaliset konseptit

o Tunnista hyvät ja halutut ominaisuudet konsepteista

o Käytä vähentämään konseptien lukumäärää

o Käytä herättämään keskustelua

Konseptien pisteytys

o Käytä tunnistaaksesi lupaavia konsepteja

o Käytä asettaaksesi konsepteja paremmuusjärjestykseen

o Käytä suhteellisen tarkkaan analyysiin

AHP (Analytical Hierarchy Process)

o Käytä asettaaksesi konsepteja paremmuusjärjestykseen

o Käytä kun tarvitset hyvin laajaa arviointiskaalaa


Kriteerin tärkeys

Arv

osan

a

keskiarvo 3,6Painotettu 4,1keskiarvo

Kriteerin tärkeys

Arv

osan

a

keskiarvo 3,6Painotettu 4,1keskiarvo

Kuva 18. Konseptin saamat arvosanat graafisesti esitettynäOn ehdotettu, että vertailuun otettaisiin mukaan kilpailijoiden tuotteita sekä yrityksen mahdollinen oma vanha tuote. Näiden jo olemassa olevien tuotteiden esitysten tulisi kuitenkin noudattaa samaa detaljitasoa kuin kehitettyjen konseptien vertailussa.

Konseptin valinta voi päättyä kolmeen eri lopputulokseen. Jos ryhmän jäsenten välillä vallitsee yhteisymmärrys ylivoimaisesta konseptista, voidaan siirtyä prosessin seuraavaan vaiheeseen. Jos ryhmässä ei synny selvää yhteisymmärrystä parhaasta konseptista on avain kriteerien taustalle etsittävä lisää tietoa ja / tai tietoa markkinoista tai teknologioista on tarkennettava. Jos ryhmä päätyy epäsopuun konsepteista, on palattava takaisin tarpeiden tunnistamiseen ja tutkittava tarkemmin valintakriteerien sisältöä.

Oleellista konseptista on vielä löytää mikä valitussa konseptissa on hyvää sekä parempaa verrattuna mahdolliseen yritykseen vanhaan tuotteeseen tai kilpailijoin. Konseptista pitäisi myös pystyä tunnistamaan sen myyntiargumentti.

Huomioi konseptia valittaessa myös kuvassa 19 lueteltuja asioita:

Kuva 19. Huomioitavaa konseptin valinnassa

Varo parasta keskivertotuotetta

Mikä valitussa konseptissa on parempaa kuin kilpailijoiden tai vanhoissa tuotteissa?

Mikä tulee olemaan uuden tuotteen myyntiargumentti?

Suorita konseptin vertailua jokaisen asiakasryhmän näkökulmasta ja vertaile tuloksia

Tarkista valinnan herkkyys kriteerien painotusten ja arvioiden muutoksille

Lopullisen konseptin valinnassa saattaa joutua käyttämään hyvinkin laajoja ja tarkkoja vaatimuksia

Huomioi konseptien ominaisuudet joita voidaan hyödyntää muissakin konsepteissa


IV Työkaluja tuotekehitysprosessin eri vaiheisiin TuoteideaHansen & Andreasen esittävät kuvan 7 mukaista mallia tuoteideointiin sekä tuoteideoiden kehittämiseen. Mallissa on kuvattuna kahdeksan näkökulmaa tuoteideaan ympyrän sektorein. Jokaiseen sektoriin on mallissa esitettynä sektorin otsikko sekä tähän liittyvät alemman tason otsikot.

Kuva 7. Tuoteidea [Hansen&Andreasen05, On the Content of a Product Idea, International Conference on Design Engineering, ICED05, Melbourne, August 15-18,

2005] Hansen & Andreasenin esittävät, että tuoteideamallia voidaan hyödyntää tuoteideoiden testaamiseen ja jatkojalostamiseen. Jos tuoteidea sisältää elementtejä useasta ympyrän sektorista niin idea on selvästi vahvempi kuin vain yhteen tai kahteen tuoteidea sektoriin perustuva idea [Hansen&Andreasen05]. Näin ollen, tuoteidea on kehitettävissä ja suuntaa-antavasti arvioitavissa hyödyntäen tuoteidean mallia.

TuotekonseptiKäsitteelle konsepti on kirjallisuudesta löydettävissä useita määrittelyjä, joista muutamia on esitettynä jäljempänä. Kirjallisuudessa on myös ristiriitojen välttämiseksi esitetty, että ”konsepti”-sanan edessä tulisi aina käyttää sitä kuvaavaa määrettä, esimerkiksi tuote-, markkina-, kehitys- tai valmistuskonsepti.

StrategiaMissionVision

Tuoteidea

TeknologiaTuotteen pääperiaateValmistus-menetelmät

TuoteToiminta periaateMuoto, ulkonäköTekninen toteutus

TehtäväOngelmaSopimus

Tavoite spesifikaatiot piirteet, kustannus tavoiteToiminnallisuusOminaisuudet, suorituskyky

Käyttäjä, asiakasKäyttäytyminenVastaus, reaktioArvot

TarveAsiakkaatTuotteen ominaisuudetKäyttäjän ongelma

BusinessTavoite markkinatLiiketoiminta tavoiteKysyntäMarkkinapotentiaali

StrategiaMissionVision

Tuoteidea

TeknologiaTuotteen pääperiaateValmistus-menetelmät

TuoteToiminta periaateMuoto, ulkonäköTekninen toteutus

TehtäväOngelmaSopimus

Tavoite spesifikaatiot piirteet, kustannus tavoiteToiminnallisuusOminaisuudet, suorituskyky

Käyttäjä, asiakasKäyttäytyminenVastaus, reaktioArvot

TarveAsiakkaatTuotteen ominaisuudetKäyttäjän ongelma

BusinessTavoite markkinatLiiketoiminta tavoiteKysyntäMarkkinapotentiaali


Tuotekonseptille on kirjallisuudesta löydettävistä useita eri määrittelyjä kirjallisuudesta. Näistä kaksi on esitettynä alla:

”Tuotekonsepti on likimääräinen kuvaus käytettävästä teknologiasta, toimintaperiaatteesta, sekä tuotteen muodosta. Se on ytimekäs kuvaus kuinka tuote täyttää asiakkaiden tarpeet.” [Eppinger&Ulrich00]

“Tuotekonseptilla on selkeästi määritelty ulkoasu, pitäen sisällään kirjoitetun ja visuaalisen kuvauksen, joka käsittää tuotteen pääpiirteet ja asiakkaan kokemat hyödyt sekä laajan näkemyksen toteuttamiseen tarvittavasta teknologiasta.” [Koen&al02]

Hansen & Andreasen ovat kehittäneet selkeän kuvauksen tuotekonseptista, joka on nähtävissä alla. Tuotekonsepti on esityksessä jaettu käyttötarkoitukseen (idea-with) ja fyysiseen toteutukseen (idea-in). Käyttötarkoitus selventää asiakkaan näkökulmaa tuotteen käyttöön sekä käyttöympäristöön. Fyysinen toteutus selventää tuotteen toimintaperiaatetta, materiaaleja ja valmistusta. Tämän ajattelumallin vahvuutena on, että käyttäjänäkökulma tuotetta suunniteltaessa tulee paremmin otettua huomioon. Tämä on tärkeää, koska insinöörivetoisissa projekteissa voi helposti keskittyminen uuden teknologian mahdollisuuksiin saada paljon huomiota, mutta samalla unohdetaan asiakas ja asiakkaan tuotteesta tai palvelusta saavuttama hyöty.

Kuva 8. Konsepti [Hansen&Andreasen02, The Content adn Nature of a Design Concept, NordDesign 2002, August 14-16, Trondheim, Norway, 2002.

Tuotekonseptien lisäksi tuotekehityksessä voidaan käsitellä myös muita konsepteja. Näiden konseptien huomioiminen sekä niiden muuttaminen totutusta voi avata uusia mahdollisuuksia. Näiden eri konseptien käyttö sijoittuu myös ajallisesti prosessin eri vaiheisiin. Kuvassa 10 on esitetty useita erityyppisiä konsepteja.

Fyysinen toteutus

(The Idea in..)

Käyttö-tarkoitus

(The Ideawith..)

Tuotekonsepti

Fyysinen toteutus

(The Idea in..)

Käyttö-tarkoitus

(The Ideawith..)

Tuotekonsepti


Kuva 17. Systemaattinen konseptien valintaprosessi Konseptin arvioinnin tuloksien tarkastelussa kannattaa käyttää myös graafista esitystä. Eräs hyvin havainnollinen tapa selventää konseptien ominaisuuksia on käyttää kuvaajaa, jossa kriteerien painoarvot ovat x-akselilla ja konseptin ominaisuuksien arviot ovat nähtävissä kullekin kriteerille y-akselille, kuten kuvassa 18. Tällaisesta esityksestä on helppo havaita poikkeamia ominaisuuksien keskiarvosta sekä tunnistaa sellaiset puutteet konseptissa, jotka estävät kyseisen konseptin valinnan.

Systemaattinen konseptin valintaprosessi

Valmistele vertailumatriisi

o Kehitä ja valitse valintakriteerit

o Valitse referenssikonsepti tai päätä vertailuperusteet

o Aseta kriteerien väliset painotukset

Arvostele konseptit

o Käytä tarkoituksenmukaista arviointiskaalaa

o Vertaa joko referenssi konseptiin tai tavoitearvoihin

o Summaa painotetut tulokset

o Aseta konseptit arvojärjestykseen

Yhdistele ja jalosta

o Poista huonot ominaisuudet

o Yhdistele hyviä ominaisuuksia

Valitse paras konsepti

o Näitä saattaa olla useampi kuin yksi

o Käytä graafisia kuvaajia selventämään arviointia

o Varo keskiarvoisia konsepteja

Kehitä valintaprosessia

o Paranna prosessia jatkuvasti

o Tallenna konseptit, käytetyt kriteerit sekä arvioinnit tietokantaan

o Tarkastele ennusteiden ja arvioiden toteutuneisuutta projektin edetessä

o Tarkastele kriteerien käyttökelpoisuutta ja tehokkuutta


Taulukko 2. Konseptien vertailukriteereitä [Fabricius03]

Kustannukset Suorat kustannukset

Yleiskustannukset

Laatu Tuotespesifikaatio

Laaduntarkkailu

Korjaus

Hylky

Joustavuus Muutokset valmistusmäärissä

Muutokset designissä

Riski

Läpimenoaika

Tehokkuus Henkilöstön käytön tehokkuus

Pääoman käytön tehokkuus

Ympäristövaikutukset

Systemaattinen konseptin valintaprosessi etenee pääpiirteittäin seuraavien vaiheiden mukaisesti: Valmistele vertailumatriisi, arvostele konseptit, yhdistele ja jalosta konsepteja, valitse paras konsepti ja lopulta kehitä prosessia tallentamalla konseptit, arviot ja käytetyt kriteerit sekä esiintyneet ongelmat. Kuvassa 17 on esitettynä systemaattinen konseptin valintaprosessi tarkemmin.


Kuva 9. Tuotekonseptien käyttötarkoituksia.[mukautettu Keinonen&Jääskö03]

Kuva 10. Tuotekehitykseen liittyviä konsepteja sijoitettuna aikajanalle [Hansen&Andreasen02]

Tuotekonsepteja voidaan käyttää myös seuraavanlaisiin tarkoituksiin:

Riskien vähentäminen: Hyvin määritellyt tuotekonseptit helpottavat tuotekehitysprojektin suunnittelua ja riskien hallinta on helpompaa jos ideoita on testattu (useissa) tuotekonsepteissa

Tuotekonsepti portfolion laajentaminen: On mahdollista löytää radikaalisti uusia tuotteita kehittämällä tuotekonsepteja Hallinnon tukena: Valmistaudu tulevaisuuteen konkretisoimalla eri mahdollisuuksia – tuotekonseptit voivat auttaa tuotekehityksen strategista hallintaaUusien ominaisuuksien lähde: Joitakin uusia ominaisuuksia voidaan poimia futuristista tuotekonsepteista ja siirtää nämä ominaisuudet nykyiseen tuotteeseenUlkoinen markkinointi materiaali: Tuotekonsepteja voidaan käyttää esimerkiksi totuttamaan asiakkaat uusiin innovaatioihin tai trendeihin sekä uuden tyyppisiin tuotteisiin Testaus materiaali: Esittelemällä tuotekonsepteja asiakkaille voidaan kartoittaa asiakkaiden reaktioita jo ennen päätöstä tuotekehitysprojektin käynnistämisestä Idea varanto: Dokumentoituja tuotekonsepteja sekä ideoita voidaan käyttää esimerkiksi tukemaan muita kehitys toimintoja Maine (PR): Huipputason konseptit pitävät yrityksen kehityksen kärjessä – jos konsepteja esitellään julkisuudessa niin yritys antaa itsestään kuvan ennemmin tiennäyttäjä kuin perässäseurajana Työskentelymenetelmien kehittäminen: Konseptien kehittäminen opettaa työntekijöille luovuutta.

Tuotekonsepti- Toiminta- Käyttö, hyöty- Design

Osakonsepti- Muoto, materiaali and prosessi konseptit

Arkkitehtuurikonsepti- Tuotteen rakenne- Kokoonpano rakenne- Toimitusmalli- Valmistussuunnitelma

ValmistusJakelukonseptiMyyntikonseptiKäyttökonseptiHuoltokonseptiKäytöstäpoistokonsepti

Liiketoimintakonsepti- Markkina- Tuote- Tuotanto- Kehitys- Rahoitus- Design- …

Tuotekonsepti- Toiminta- Käyttö, hyöty- Design

Osakonsepti- Muoto, materiaali and prosessi konseptit

Arkkitehtuurikonsepti- Tuotteen rakenne- Kokoonpano rakenne- Toimitusmalli- Valmistussuunnitelma

ValmistusJakelukonseptiMyyntikonseptiKäyttökonseptiHuoltokonseptiKäytöstäpoistokonsepti

Liiketoimintakonsepti- Markkina- Tuote- Tuotanto- Kehitys- Rahoitus- Design- …


Asiakastarpeet Tunnistaasiakkaan

tarpeet

Aseta tavoite

spesifikaatiot

Luokonsepteja

Valitsetuote-

konseptit

Testaa tuote-

konsepteja

Aseta lopulliset

spesifikaatiot


Tunnistaasiakkaan

tarpeet

Aseta tavoite

spesifikaatiot

Luokonsepteja

Valitsetuote-

konseptit

Testaa tuote-

konsepteja

Aseta lopulliset

spesifikaatiot


Asiakastarpeiden tunnistaminen Tuotekonseptointi lähtee käyntiin yleensä asiakastarpeiden kartoittamisella. Tuotekehityksessä suunnittelijan ensimmäinen haaste on ymmärtää, mitä käyttäjät tarvitsevat, haluavat ja miten he tekevät työtään. Ulrichin ja Eppingerin tuotekehitysmallissa asiakastarpeiden tunnistaminen liittyy lähimmin konseptinkehittäminen vaiheeseen (Ulrich & Eppinger 2003). Seuraavassa tekstissä esitellään, mitä tarpeet ovat, lähestymistapoja asiakastarpeiden keräämiseen, asiakastarpeiden keräämisen prosessia, sekä joitakin menetelmiä liittyen asiakastarpeiden selvittämiseen.

Mitä tarpeet ovat? Ulrichin ja Eppingerin (2003) mukaan tarpeet ovat suurissa osin riippumattomia mistään erinäisestä tuotteesta, mitä saatetaan kehittää. Ne eivät myöskään kuulu tietylle konseptille, mikä viimein valitaan tavoiteltavaksi. Lisäksi he painottavat, että ryhmän tulee lähteä tunnistamaan asiakastarpeita välittämättä onko tietoa siitä, kuinka ryhmä tulee viimein osoittamaan nämä tarpeet. Ulrich ja Eppinger käyttävät sanaa tarve, jolla nimetään kaikkia potentiaalisen tuotteen ominaisuuksia joita asiakas haluaa. He eivät tee eroa halulle ja tarpeelle.Griffinin ja Hauserin (1993) mukaan asiakastarve on asiakkaan omin sanoin tekemä määritelmä hyödyistä, mitä tuotteen tai palvelun kautta voidaan täydentää. Heidän mukaansa asiakastarpeet sisältävät perustarpeet (esim. mitä asiakas olettaa tietokoneen näytön tekevän), selvästi itseään ilmaisevat tarpeet (esim. asiakas kertoo sinulle, mitä hän haluaa tietokoneen näytön tekevän) ja herättävät tarpeet (näiden tarpeiden täyttyessä asiakas ilahtuisi tai yllättyisi).

Kotler ja Armstrong (2004) jakavat inhimillisen tarpeen kolmeen tasoon. Heidän mukaansa inhimilliset tarpeet ovat koetun puutteen tiloja. Nämä sisältävät;

perus fyysiset tarpeet ruokaan, vaatetukseen, lämpöön ja turvallisuuteen,

sosiaaliset tarpeet yhteenkuuluvuuteen ja mieltymyksiin sekä

yksilölliset tarpeet tietoon ja itseilmaisuun

Kotlerin ja Armstrongin (2004) mukaan halut (wants) ovat inhimillisen tarpeen muoto, joka on muodostunut kulttuurista ja yksilön persoonallisuudesta. Esimerkiksi amerikkalaiset tarvitsevat ruokaa, mutta haluavat Big Macin, ranskalaiset ja virvoitusjuoman (ibid.). Halut saavat muotonsa yhteisössä ja ne on selitetty sen suhteen, mikä tyydyttää tarpeet. Kun halut nojautuvat ostovoimaan, tulee niistä vaatimuksia.Omien halujen ja resurssien pohjalta ihmiset vaativat tuotteita, josta he saavat maksimaalisen arvon ja tyydytyksen (ibid.).

Näiden lisäksi tuotekehityksen yhteydessä puhutaan myös toivomuksista (wish), mistä ihmiset jollain tasolla unelmoivat, mutta usein näitä hyvin kauaskantoisia tarpeita on vaikeata täyttää (esim. ei ole olemassa sopivaa teknologiaa). Tarpeita käsiteltäessä on tyypillistä, että ne muodostavat keskenään ristiriitaisuuksia. Tällöin on luonnollisesti selvää, ettei kaikkia tarpeita voida kompromissitta kohdistaa yhteen kehitettävään konseptiin. Käyttäjätietoa voidaan siis rakentaa hierarkiaan, jossa vaatimukset ovat ehkä tärkeimpiä, kun tavoitellaan merkittäviä tuoteparannuksia. Toisinaan osa tuotteen


Taulukko 1. Konseptien vertailukriteereitä [Takala&Ekman]

Tuote(Product)

Tuotteen oleelliset ominaisuudet

Käytettävyys

Luotettavuus

Ympäristö- ja turvallisuusnäkökohdat

Tuotearkkitehtuuri

Myyntiargumentit

Teollinen muotoilu

Distinguishing factors

Usability

Reliability

Environment & Safety

Product architecture

Sales cycle

Industrial design

Tekniikka(Technology)

Tekninen toteutettavuus Technical feasibility

Asiakas(Customer)

Käyttäjän tarpeet, joihin vastataan

Piilevät käyttäjän tarpeet, joihin vastataan

Tuotteen kompleksisuus

User need

Latent customer need

Complexity

Markkinat(Market)

Asiakasmääritys

Markkinapotentiaali

Kehitysaika

Toimituskanavat

Kilpailijat

Tuotteen laajuusrajaus

Customer

Market potential

Time to market

Distribution channels

Competition

Product scope

Kannattavuus(Financial)

Asiakaskohtainen tuotto

Aika kannattavuuteen

Tuotteen kustannusrakenne

Revenue per customer

Time to profit

Product cost structure

Organisaationkyvykkyys(Organizational)

Organisaation toteuttamiskyky

Olemassa oleva osaaminen

Ulkoistuslaajuus

Projektin vetäjä

Execution capability

Existing in-house competence

Outsourcing

Champion

Strategia(Strategy)

Tuotteen strateginen sopivuus

Tuotteen riskit

Taaksepäin yhteensopivuus

Strategic fit

Risks

Carry-on

Säädökset(Regulation)

Tuotealueen patenttitilanne

Tuotteeseen liittyvät säädökset

Tuotteeseen liittyvät standardit

Intellectual property rights

Legal issues

Standardization issues


Konseptin valinta Tunnistaasiakkaan

tarpeet

Aseta tavoite

spesifikaatiot

Luokonsepteja

Valitsetuote-

konseptit

Testaa tuote-

konsepteja

Aseta lopulliset

spesifikaatiot


Tunnistaasiakkaan

tarpeet

Aseta tavoite

spesifikaatiot

Luokonsepteja

Valitsetuote-

konseptit

Testaa tuote-

konsepteja

Aseta lopulliset

spesifikaatiot


Konseptin valintavaihe seuraa konseptien luontivaihetta ja voidaankin sanoa, että konseptien valinta on olennainen osa konseptin kehitysprosessia. Tärkeää konseptin valinnassa on ymmärtää valinnan päämäärä, joka on keskustelun, yhdistelyn sekä jalostamisen kautta kehittää paras konsepti.

Kuva 16. Konseptin valinnan muistilista Jo ennen konseptien valinnan aloittamista tulisi valinnassa käytettävät kriteerit ja näiden kriteerien väliset painotukset olla selvillä. Mahdollisia valinnassa käytettäviä kriteerejä on esitettynä taulukoissa 1 ja 2. Luetteloa valinnassa käytettävistä kriteereistä on syytä ylläpitää ja projektien edetessä on hyödyllistä arvioida käytössä olevien kriteerien toimivuutta. Valintakriteerien määrä tulisi kuitenkin pitää rajallisena. Yhdessä arvioinnissa ei ole järkevää käyttää yli 30 kriteeriä. On myös mahdollista, että konseptin kehitysprosessin edetessä ja konseptien tarkentuessa myös käytettävien arviointikriteerien lista muuttuu.

Hyvänä ohjeena yleisesti kannattaa pitää, että konsepteja arvioidaan useassa eri vaiheessa. Tällöin saadaan optimoitua sekä riskiä, että konseptien kehittämiseen käytettävää työmäärää. Kuitenkin konseptin valintaan liittyy aina jonkinasteinen epävarmuus, joka on hyväksyttävä. Konseptien valintaan liittyy myös iteratiivisuus.

Huomioi, että kaikki taulukoissa 1 ja 2 esitetyt valintakriteerit eivät ole käyttökelpoisia konseptien eri tarkkuustasoilla.

Muista konsepteja valitessasi…

Konseptin valinnan tarkoitus… …ei ole valita parasta konseptia

Konseptin valinnan tarkoitus… …on kehittää paras konsepti

Joten muista… …yhdistele ja paranna konsepteja luodaksesi parempia konsepteja


ominaisuuksista koetaan niin ajankohtaisiksi, että ne tulisi lisätä tuotteeseen. Kuitenkin pyrittäessä kehittää menestyvää tuotetta, myös perustarpeet tulee täyttää.

Herättävät tarpeet

(Exciting needs)

Asiakas ilahtuisi tai yllättyisi näiden tarpeiden täyttyessä.

Vaatimus

(Demand)

Kun halut nojautuvat ostovoimaan, tulee niistä vaatimuksia.

Selvästi itseään ilmaisevat terpeet

(Articulated needs)

Tarpeet, mitä asiakas / käyttäjä selkeäsi ilmaisee tarvitsevansa

Halut

(Wants)

Inhimillinen tarpeen muoto, mikä on muodostunut kulttuurista ja yksilön persoonallisuudesta.

Perustarpeet

(Basic needs)

Perusolettamukseen perustuvat tarpeet

Tarpeet

(Needs)

Fyysiset, sosiaaliset ja yksilölliset tarpeet

Kaavio 1: Vasemmalla puolella Griffinin ja Hauserin näkemys tarpeiden jakamisesta hierarkiaan. Oikealla puolella näkyy Kotlerin ja Armstrongin tarpeet asetettuna hierarkiaan. Näitä hierarkioita voidaan myöhemmin käyttää apuna, kun pyritään porrastamaan tarpeita suhteelliseen tärkeysjärjestykseen. Lähestymistapoja asiakastarpeiden keräämiseen Tuotekehityksen kannalta on erittäin tärkeää tunnistaa sidosryhmien tarpeet ja tavoittelemat hyödyt. Sidosryhmillä tarkoitetaan tässä yhteydessä hyvin laajaa joukkoa eri yksilöitä tuotteen tai palvelun elinkaaren eri vaiheissa. Tämän jälkeen on harkinnallinen asia, minkä osapuolen tarpeita priorisoidaan; asiakkaan, jälleenmyyjien tai loppukäyttäjien. Asiakastarpeiden kokoamiseksi on olemassa monia kanavia; asiakaspalaute, markkinatutkimukset, ja tuotekehityksen aikaiset tutkimukset. Myös lainsäädäntö ja standardit määrittävät ehtoja ja vaatimustasoja, jotka voidaan tulkita asiakastarpeiksi.

Kuinka monta asiakasta tulisi käydä läpi, jotta pystyttäisiin identifioimaan riittävän kattava määrä asiakastarpeita? Asiakkaiden tutkimiseen kuluu luonnollisesti tuotekehitysryhmältä rahaa. Vaikkakin kenttätutkimus on suhteellisen edullista, kustannukset syntyvät tiedon litteroinnista ja analysoinnista. Griffin ja Abbien (1993) kirjoittivat kahta menetelmää, yksilö- ja kohderyhmähaastattelua, vertailevan artikkelin, jossa käsiteltävänä tuotekategoriana oli monimutkainen toimistoväline. Tutkimuksessa yksi haastattelu kesti tunnin ja ryhmähaastattelu kaksi tuntia. Koko haastattelumateriaalin analysoi kuusi ammattilaista ja he tuottivat yhteensä 230 asiakastarvetta. Tämän tutkimuksen mukaan kaksi haastattelua ovat yhdessä yhtä tehokkaita kuin yksi kohderyhmä (51 % vs. 50 %). Saman tutkimuksen mukaan 20–30 haastattelua on tarpeen, mikäli halutaan selvittää 90–95 % asiakastarpeista. (Griffin & Hauser 1993)

Asiakastietoja kartoittaessa tulee myös harkita, ovatko valitut asiakassegmentit riittävän samankaltaisia esimerkiksi maittain. Mikäli ne erottuvat merkittävästi esimerkiksi kulttuurillisista tai säädännöllisistä syistä, tulee asiakastietoa koota laajemmin myös paikallisesti.


Tunnistettujen tarpeiden prosentuaalinen osuus

0

0,2

0,4

0,6

0,8

1

0 1 2 3 4 5 6 7 8 9 10Vastaaj ien tai ryhmien lukumäärä

One-to-ones

FocusGroups

Kaavio 2: Kaaviossa vertaillaan havaittujen asiakastarpeiden prosentuaalisia osuuksia haastattattelu- ja kohderyhmämenetelmän välillä (lähde: Griffin & Hauser, 1993). Käyttäjätiedon kokoaminen ei kuitenkaan ole aina vaivatonta. Esimerkiksi investointihyödykkeitä suunniteltaessa ketju loppukäyttäjään voi muodostua suhteellisen pitkäksi ja liiketoiminnan kannalta väliportaiden tarpeet saattavat olla jopa merkityksellisempiä ja tuotekehitykselle paremmin selvillä, kuin loppukäyttäjien tarpeet (esimerkiksi moottorin loppukäyttäjä voi olla huoltomies). Von Hippelin mukaan tuotteen potentiaalisimmilta käyttäjiltä ei saada lähtökohtaisesti kaivettua kokemustietoa, kun keskustellaan täysin uusista tuotteista tai tuotekategorioista, kuten korkean teknologian tuotteesta (von Hippel 1986). Von Hippel käyttää termiä edelläkävijäkäyttäjä (lead users) asiakkaista, joiden nykyiset vahvat tarpeet tulevat yleisesti markkinoille kuukausien tai vuosien päästä. Edelläkävijäkäyttäjät hyötyvät asemassaan merkittävästi, mikäli saavuttavat ratkaisut ongelmiinsa (von Hippel 1986). Koska edelläkävijäkäyttäjät ovat perillä tulevaisuuden tilasta, joka koskee suurinta osaa muita, voidaan heitä käyttää tarpeiden ennustuslaboratoriona markkinatutkimuksessa (ibid.). Miten sitten edelläkävijäkäyttäjät voidaan tunnistaa? Mitkä ovat heidän ominaispiirteensä? Von Hippel (1986) ehdottaa tehtäväksi seuraavia vaiheita vastaamaan edellisiin kysymyksiin.

1. Identifioidaan tärkeä markkina- tai teknologiatrendi

2. Identifioidaan edelläkävijäkäyttäjät, jotka johtavat trendiä, joko a) kokemuksellaan tai b) trendin voimakkuudella

3. Analysoidaan edelläkävijäkäyttäjätietoa

4. Projisoidaan tieto yleisten markkinoiden kiinnostukseen.

Koottu asiakastieto tyypillisesti käsitellään ja analysoidaan helpommin ja nopeammin luettavaan muotoon. Seuraavassa osassa käsitetään tarkemmin toimintamallia asiakastiedon käsittelyyn.


2. Ensimmäinen ideointi (esim. 20–30 min.) Suoritetaan ideointia pienryhmissä noudattaen aivoriihen sääntöjä esim. 20–30 min ajan. Jokainen idea kirjataan tai piirretään yhdelle erilliselle paperille (idealuonnokset). Tukena voidaan käyttää erilaisia muistilistoja.

3. Ideoiden ryhmittely ja yhdistely (esim. 15 min.) Ensin kaikki ideat kootaan taululle tai seinällä. Ideoille pyritään löytämään ryhmiä, joille keksitään kuvaava nimi, ja papereita siirretään ryhmiksi. Kun idearyhmät alkavat näyttää järkevältä, päätetään mitä ideoita lähdetään tarkentamaan. Päätös voi perustua esim. session vetäjän näkemykseen tai äänestyksen tulokseen. Äänestyksen voi suorittaa niin, että jokaisella on esimerkiksi kolme ääntä (=pistettä) ja omille ideoille ei mielellään saa antaa pisteitä. Eniten pisteitä keränneet siirretään jatkokehittelyyn.

4. Ideoiden jalostaminen (esim. 20 min.) Ideointi-session vetäjä jakaa jalostukseen valitut ideat ryhmille. Tämä voi tapahtua siten, että kukin ryhmä saa yhden idearyhmän. Tavoitteena on miettiä ja kehittää uusia ideoita aikaisemman idearyhmän pohjalta. Ideoinnissa voidaan miettiä mm. erilaisia ratkaisumalleja perustuen erilaisiin teknisiin ratkaisuihin tai teknologioihin. Ideoinnin jalostamisen parantamiseksi voidaan tässäkin hyödyntää muistilistoja.

5. Ideoinnin yhteenveto (esim. 0,5–1 h) Ryhmät esittelevät lyhyesti (esim. 5 min) oman ideoinnin tulokset muille ryhmille, kukin vuorollaan. Ideoita voidaan arvioida antamalla niille plussia ja miinuksia sekä parannusehdotuksia. Kun kaikki ideat on esitelty, voidaan päättää seuraavista toimenpiteistä. Ideointisession järjestäjä dokumentoi kaikki ideat talteen.

Lähteet:Benami, O. and Jin, Y., Creative stimulation in conceptual design, in Proceedings of the ASME Design Engineering Technical & Computers in Engineering Conferences, CD-ROM, 2002 (New York: American Society of Mechanical Engineers). Beyer, H. & Holtzblatt, K. 1999. Contextual design. Interactions. 6, 1, 32–42. ISSN 1072-5520. Brown, V., Tumeo, M., Larey, T. and Paulus, P.B., 1998, “Modeling cognitive actions during group brainstorming”, Small Groups Research, 29(4): 495-526. Buzan T. and Buzan B., 2003, The Mind Map Book: How to Use Radiant Thinking to Maximize Your Brain's Untapped Potential Cagan, J. & Vogel, C.M. 2003. “Kehitä kärkituote: ideasta innovaatioksi.” Talentum. Ishikawa K., 1985, What Is Total Quality Control?: The Japanese Way Lumsdaine, E. & Lumsdaine, M. 1995. Creative Problem Solving: Thinking Skills for a Changing World. McGraw-HillOsborn, A.F., 1957, Applied Imagination: Principles and procedures of creative thinking, revised edition, Charles Scribner’s Sons, New York. Oulasvirta, A., Kurvinen, & E., Kankainen, T.: Understanding Context by Being There: Case Studies in Bodystorming, Personal and Ubiquitous Computing, 2003, no. 7, pp. 125-134 Simsarian K.: Take it to the next stage: Tho roles of role playing in the design process, CHI 2003, pp. 1012-1013. Smith, G. F. 1998 ”Idea-Generation Techniques: A Formulary of Active Ingredients”. Journal of Creative Behavior, Vol. 32, Number 2. Spreenberg, P., Salomon, G. & Phillip, J. 1995. Interaction Design at IDEO Product Development. Proceedings of CHI ’95. VanGundy, A. B., 1988, Techniques of Structured Problem Solving, 2nd Ed., Van Nostrand Reinhold, NY.


ominaisuuksiin, mutta se tuo selvästi esiin tilanteen vaikeudet ja tuotemahdollisuudet, jotka voisivat vaikuttaa käyttäjän elämään.

Toisinaan skenaarioista tehdään visuaalisia tarinoita (sisältää tekstiä ja kuvia), joissa ongelma, teknologinen ratkaisu ja sen käyttäjä kuvaillaan mahdollisissa käyttötilanteissa ja -konteksteissa. Tällöin skenaariolla pyritään tekemään varhaista tuotekonseptia ymmärrettävämmäksi.

Affinity Method, Affinity Diagram Affinity diagram -menetelmä tukee ideoiden generointia ryhmittämällä ideoita ja tietoa yhteenkuuluvuudentunteen tai toisiinsa liittyvyyden mukaan.

Affinity (samankaltaisuus) -menetelmää käytetään suurten tietomäärien esimerkiksi käyttäjätutkimustiedon luokitteluun. Samankaltaisuus-metodin avulla aiemmat huomiot tai ideat järjestyvät hierarkkiseksi kokonaisuudeksi ja saadaan yleiskuva kohteesta.

1. Käytä post-it -lappuja joihin kirjoitat yhden idean tai huomion per lappu. Niiden paikkoja on helppo vaihdella.

2. Kerää aluksi sellaiset ideat, jotka näyttävät kuuluvan yhteen. Tässä vaiheessa ei ole tärkeää määrittää, miksi ne kuuluvat ryhmään.

3. Tarkenna ideoita, jos tarve vaatii.

4. Jos jokin idea kuuluu kahteen ryhmään, kopio se ja laita se molempiin ryhmiin.

5. Tarkista ryhmien kokoa: pitäisikö pienet ryhmät liittää isoihin tai pitäisikö isot jakaa tarkempiin ja pienempiin osiin.

6. Kun ideat on järjestetty, voidaan ryhmille alkaa antamaan otsikkonimiä.

Ideointisession kulku Ideoinnin aloittamisessa on hyödyllistä käyttää materiaalia, joka aktiivisesti katalysoi ideointia. Ulkopuoliset stimulaatiot (remote stimuli) ovat objekteja ideoiden generoinnissa, jotka eivät ole suhteessa ongelmaan. Ideoinnissa voidaan käyttää myös konkreettisia virikkeitä (concrete stimuli), virikeobjekteja, jotka ovat fyysisesti esillä ideoiden generoinnin yhteydessä. Tutkimuksen mukaan on parempi tuoda esille epäsovinnaisia ratkaisuja ja erilaisia esimerkkejä, koska ne stimuloivat ideointia tavanomaisia esimerkkejä tehokkaammin.

0. Ideointisession järjestäminen Ideointisession järjestäjä huolehtii siitä, että ideointiin on tarvittava materiaali valmiina; kyniä, paperia, post-it -lappuja, tauluja tai seiniä, mihin papereita voidaan kiinnittää ja välineet ideoiden dokumentointiin. Lisäksi järjestäjä valmistautuu keräämällä aineistoa, joka katalysoi keskustelua. Tämä voi esimerkiksi sisältää epäsovinnaisia ja vaihtoehtoisia ratkaisuesimerkkejä.

1. Ideointisession käynnistäminen (esim. 30–45 min.) Ideointisession järjestäjä esittelee ideoinnin kohteen ja tarjoaa vaihtoehtoisia teemoja lähestyä käsiteltävää aihetta. Järjestäjän vastuuna on myös tarvittaessa rajata ideoinnin kohdetta. Järjestäjä jakaa ideoijat ryhmiin.

Vaihtoehtoisesti kaikki ovat miettineet aiemmin määriteltyä ongelmaa yksikseen muutaman päivän ajan: ideoiden esittelyllä, ryhmittelyllä ja jatkokehittelyyn valinnalla. Tässä tapauksessa voidaan siirtyä suoraan kohtaan kolme.


Kaavio 3: Rogerin teoreettiseen levinneisyyskäyrään on lisätty von Hippelin teorian mukaiset edelläkävijäkäyttäjät, jotka sijoittuvat kaaviossa vaalennettuun innovoija-ryhmään. Kaavio perustuu Rogerssin ja von Hippelin näkemykseen. Toimintamalli asiakastarpeiden identifioimiseen Nojaten Ulrichin ja Eppingerin tuotekehitysmalliin, konseptin kehittämisen vaihetta tuotekehityksessä edeltää suunnitteluvaihe, jonka aikana selvitetään markkina- ja tuotemahdollisuuksia. Tällöin yritys myös tyypillisesti määrittää laajoja rajoitteita ja tavoitteita projektille. Tämä informaatio on vähitellen muodostettu tehtävän kuvaus (tästä käytetään toisinaan myös nimitystä charter tai design brief). Tällä määrityksellä pyritään viitoittamaan kehitysprojektin suuntaa, mutta tehtävän kuvaus ei kerro tarkkaa määränpäätä tai tapaa edetä (ibid.). Seuraavaksi esiteltävä asiakastarpeiden identifioinnin toimintamalli perustuu siihen, että suunnitteluprojektista tiedetään ainakin projektin kuvaus, liiketoiminnan avaintavoitteet, ensisijaismarkkinat, toissijaismarkkinat, olettamuksia projektin kohteesta ja sidosryhmät.

1. Vaihe: Sidosryhmien kartoittaminen

Usein mission statement -dokumentissa on jo listattu sidosryhmät (stakeholders), mutta näitä on silti syytä pohtia tarkemmin konseptin kehittämisen vaiheen alkupuolella. Tarkoituksena on identifioida kaikki oleelliset suunniteltavaan tuotteeseen tai prosessiin kuuluvat sidosryhmät sekä puntaroida niiden välisiä suhteita. Tähän tarkoitukseen voidaan soveltaa Customer Chain -menetelmää.

Menetelmän kulku on melko yksinkertainen. Ensin määritellään kaikki oleelliset sidosryhmät ja tämän jälkeen kartoitetaan asiakkaiden vuorovaikutussuhteet. Kaaviossa 4 näkyy esimerkki Customer Chain -menetelmän käytöstä. Eri osapuolia yhdistävät nuolet esittävät ehdotettuja vuorovaikutuksia lähtökohtaisessa liiketoimintamallissa: myyntiautomaatin valmistaja myy myyntiautomaatteja automaattien välittäjälle, joka sijoittaa niitä marketteihin. Analysointimenetelmän avulla suunnitteluryhmällä on mahdollisuus identifioida tärkeitä asiakkaita ja tällöin voidaan synnyttää yksityiskohtainen lista asiakastarpeista.


Kaavio 4: Esimerkki Customer Chain -kaaviosta, missä esitetään kolikkokäyttöisenjuoma-automaatin mallia [Donaldson et al. 2006]. Sidosryhmien välisiä suhteita voidaan analysoida hieman syvemmin Customer Value Chain Analysis -menetelmällä, jossa tutkitaan arvosuhteita tai arvoteoreemia useiden asiakkaiden välillä ja siten arvioidaan asiakastarpeiden suhdetta suunnitteluryhmän yritysstrategiaan (Donaldson et al. 2006). Sekä Customer Chain ja Customer Value Chain Analysis voidaan suorittaa myös suunnitteluvaiheessa.

2. Vaihe: Kootaan käsittelemätöntä käyttäjätietoa

Käyttäjätiedonkeruun pyrkimyksenä on saada mahdollisimman korkeatasoista tietoa suoraan asiakkailta. Yleisesti käytettyjä menetelmiä ovat haastattelut, kohderyhmät,havainnointi ja contextual inquiry. Lyhyet kuvaukset näistä menetelmistä löytyvät tämän luvun lopusta. Käyttäjätietoa voidaan koota seuraavien vaiheiden kautta.

I ASIAKKAIDEN VALINTA

Vaiheen ensimmäisenä tehtävänä on valita sopiva otos sidosryhmän jäseniä tai asiakkaita mukaan käsittelyyn.

Esimerkiksi, mikäli projekti suuntautuu käyttäjävetoiseen tuotteeseen, on tällöin valittava tutkittavaksi loppukäyttäjiä tavoite markkinasegmentistä.

Uusia tuotteita tai teknologioita kehitettäessä kannattaa pyrkiä tutkimaan myös edelläkävijäkäyttäjiä.

II ASIAKASTARPEIDEN TUONTI PÄIVÄNVALOON

Ulrich ja Eppinger (2003) ehdottavat seuraavia vinkkejä, jotka ovat tehokkaita oltaessa vuorovaikutuksessa asiakkaiden kanssa (esim. haastattelu).

Seuraa virtausta: Jos asiakkaalla on tarjota hyödyllistä tietoa, tällöin ei ole syytä noudattaa -tiukasti haastattelun ennalta määrättyä kaavaa. Tavoitteena on kerätä tärkeätä tietoa asiakastarpeista, ei suorittaa haastattelu tietyssä varatussa ajassa.

Käytä visuaalista stimulaatiota ja rekvisiittaa: Tuo mukanasi kokoelma olemassa olevista ja kilpailijan tuotteista tai jopa tuotteista, jotka ovat sivuavasti yhteydessä suunniteltavaan tuotteeseen.

Supista ennakko-olettamuksia teknologiasta: Ajoittain asiakkaat tekevät olettamuksia tuotekonseptista, jotka he luulevat täyttävän heidän tarpeensa. Tällaisissa tilanteissa haastattelijan tulisi välttää poikkeamasta keskustelua olettamuksiin, kuinka tuote tullaan aikanaan suunnittelemaan tai tuottamaan. Kun asiakas mainitsee erityisen teknologian tai tuoteominaisuuden,

Myyntiautomaatti Automaattien välittäjä Marketti

Limonadin pullottaja

Limonadin kuluttaja


Menetelmät ideoiden ryhmittelemiseen StoryboardStory Boards -tekniikan kehittäminen katsotaan usein Walt Disneyn ansioksi siitä huolimatta, että sen alkuperä todennäköisesti sijoittuu paljon aikaisempaan ajankohtaan. Esimerkiksi DaVinci piirsi nähtävästi karkeita luonnoksia seinille ennen kuin painoi ne muistiin kankaalle. Walt Disney alkoi käyttää Story Board välttääkseen tapaamisia, jossa piti keskustella tuhansista animaatioon vaadittavista piirustuksista. Ratkaisuksi tähän ongelmaan hän pisti kuvataiteilijansa asettamaan nuppineuloilla piirustukset (järjestykseen) seinille. Tämän seurauksena prosessi kulki paljon tasaisemmin eteenpäin.

Story Board on matriisi, joka visuaalisesti esittää ideoita useissa kategorioissa. Menetelmä soveltuu aivoriiheen, suunnitteluun tai idean arviointiin. Otsikkokortteja (headers) tehdään tärkeistä tekijöistä, jotka koskevat ongelmaa. Nämä otsikot asetetaan suurelle ilmoitustaululle siten, että looginen suhde säilyy kategorioiden välillä, mikä johtaa ongelman ratkaisuun. Ensimmäinen kategoria on aina tarkoitus (purpose). Tämän jälkeen jokainen kategoria käydään läpi aivoriihellä ja ideat asetetaan kortistopaperille sopivan otsikon alle. Tämän visuaalisen ideoiden asettelun kautta luovat ideat ja ratkaisut voivat saada alkusysäyksensä, koska esineet eri kategoriasarakkeissa voidaan yhdistää eri tavalla, yllätyksellisesti. Aivoriihen jälkeen ryhmä suorittaa kriittisen ajattelusession, jossa eliminoidaan ideakortit, jotka eivät kohtaa tavoitteita. Tämän jälkeen jäljellä olevia ideoita parannetaan luovasti. Monet organisaatiot, kuten markkinointi ja elokuvateollisuus käyttävät Story Board -menetelmää suunnitteluun, kommunikointiin, toteuttamiseen ja aiheen laajempaan käsittelyyn. Sen lisäksi, että ideat ovat asetettuna isolle taululle, ideat myös kirjataan pienemmälle kannettavalle taululle.

CharactersCharacters esittävät suunniteltavan tuotteen potentiaalisia käyttäjiä, jotka on identifioitu ja selitetty; jokaiselle annetaan nimi ja identifioiva persoonallisuus. Nämä stereotyypit saattavat muistuttaa observoitujen käyttäjien sekoitusta. Käyttöskenaario (usagescenario) on rakennettu jokaiselle persoonalle, kuvaamaan ja ennustamaan, kuinka lopputuotetta käytetään, sen käyttökontekstia ja sen tarjoamia toimintoja. Näitä käyttöskenaarioita kuvitetaan usein käyttämällä havainnoinnin aikana kerättyä kuvamateriaalia. Lopputuloksena syntyneitä storyboardeja voidaan käyttää virikkeenä aivoriihissä.

SkenaariotSkenaarioiden laadinta tuotekehitysprosessissa lähtee usein liikkeelle sen tarpeen havaitsemisesta, jossa piilee tuotemahdollisuus. Skenaariolla voidaan kuvata kohteena olevan tuotteen tyypillistä käyttäjää ja sitä, miten tuotteen tai palvelun puuttuminen vaikeuttaa käyttäjän tehtäviä.

Varhainen skenaario on usein lyhyt sanallinen kuvaus. Siinä kuvataan tuotemahdollisuuden peruselementtejä: kuka on asiakas, mikä hänen tarpeensa on, miksi hänellä on kyseinen tarve, miten tehtävä tehdään nyt ja milloin se tehdään.

Skenaariota voidaan myöhemmin täydentää tarkemmaksi laadullisista tutkimuksesta saaduilla havainnoilla. Tällöin myös tuotteen käyttöympäristö ja käyttöyhteydet tarkentuvat. Skenaariota voidaan käyttää tuotekehityksen eräänlaisena kiinnekohtana. Skenaariolla ei vieläkään viitata mihinkään yksittäiseen tuotteeseen eikä sen


Metodit määrän tuottamiseksi Brainstorming - Aivoriihi Brainstorming on luovan ideageneroinnin ryhmämenetelmä, jonka alun perin kehitti Alex Osborn vuonna 1939. Havaintojen perusteella sopivin määrä osallistujia aivoriiheen on 3–9 henkilöä. Pelkkä keskustelu ei vielä synnytä aivoriihtä. Menetelmä vaatii henkistä valmistautumista, ongelman esittelyä ja luovan ajattelun lämmittelyä (ibid.). Siitä huolimatta, että menetelmä on luova ja rento, seuraavia ehdottomia sääntöjä ja menettelytapoja tulee noudattaa (ibid.). Osbornin (1957) brainstorm-ohjeet:

8. Generoi niin monta ratkaisua, kuin mahdollista – määrä lasketaan.

9. Rohkaistaan villeihin ideoihin.

10. Kriittisyys ei ole sallittua – arviointi on siirretty myöhemmäksi.

11. Parantele muiden ideoita tai käytä niitä omien ideoiden rakennusaineena.

Aivoriihi aloitetaan ongelman esittelyn jälkeen yksilötyöskentelyllä (esim. 20–30 min.), jonka jälkeen aivoriihisession vetäjä pyytää jäseniä aloittamaan ideoiden jakamisen. Aivoriihi on tiimityöskentelyä, jossa kaikki ovat samassa veneessä. Kaikki ideat tulee jakaa, jotta joku muu voi käyttää niitä ponnahduslautana johonkin toiseen ideaan. Aivoriihi perustuu kognitiiviseen stimulaatioon, jossa nimenomaan muiden esittämät ideat stimuloivat ja helpottavat omien ideoiden kehittelyä. Ilmapiiriä voidaan keventää huumorilla ja taustamusiikilla. Ideointi lopetetaan hiljalleen antaen 3 minuutin varoitus. Osa parhaista ideoista syntyy lisäajalla.

BodystormingBodystorming-menetelmän tarkoitus on kaksijakoinen. Ensiksi pyritään saamaan osallistujat eläytymään kokonaisvaltaisesti ideointihetkeen (i.e. ideointitilanne muuttuu mentaalisesta fyysiseksi). Toiseksi roolin omaksuminen ja eri esittämistekniikat tekevät ideoinnista kokeellisemman. Käytännössä ideointi suoritetaan tekemällä piennäytelmä tai roolipeli valitusta ongelmatilanteesta.

Lyhyesti menetelmän kulku on seuraavanlainen: Ennen bodystorming-sessiota alustava observointi ja sen dokumentointi on suoritettu. Dokumenteissa mielenkiintoiset ilmiöt ovat valittu ja muokattu helposti luettaviksi muotoilukysymyksiksi (design question).Design question esittää ilmiötä, kuten ongelmaa tilanteessa, kokemuksessa tai käyttäjän käytännöissä. Tämä voidaan kirjoittaa esimerkiksi lyhyenä 5–10 rivin tekstinä ja sen päätteeksi esitetään suunnittelukysymys. Suunnittelykysymyksen pohjalta suoritetaan roolijako, joka voi sisältää melkein mitä vain: henkilöitä, emotioita, asioita, esineitä tms.

Osallistujat menevät edustavaan ympäristöön esimerkiksi, jos tutkitaan kauppakeskuksia, suunnittelijat menevät kauppakeskukseen. Suunnittelijoille annetaan yksi suunnittelukysymys kerrallaan (ibid.). Pyrkimyksenä on ratkaista ongelma, joka tapahtuu paikassa, jossa ilmiö (tai niiden osa) on suoraan observoitavissa (ibid.). Tämä on suoraan kontrastina perinteiselle aivoriihelle, joka suoritetaan toimistoympäristössä, joka ei edusta tutkittavaa ympäristöä (ibid.). Joissain tapauksissa osallistujia rohkaistaan lisäämään vielä voimaa sessioon. Osallistujat eivät ole bodystorming-sessiossa passiivisia observoijia, vaan heitä pyydetään näyttelemään toimintoja (ibid.). Generoidut ideat nauhoitetaan paikanpäällä ja keskustellaan ja valmistellaan myöhemmin ryhmissä (ibid.). Videon käyttäminen ei ole ainoastaan dokumentointia varten. On huomattu, että se lisää asennetta esiintymiseen.


haastattelijan tulisi tällöin luodata taustalla piilevää tarvetta, jonka asiakas uskoo ehdotetun ratkaisun tyydyttävän.

Anna asiakkaan demonstroida tuotetta ja/tai tyypillisiä tehtäviä liittyen tuotteeseen: Jos haastattelu suoritetaan käyttöympäristössä, demonstrointi on usein tarkoituksenmukainen ja poikkeuksetta paljastaa uutta tietoa.

Ole valmiina yllätyksille ja piilevien tarpeiden ilmaantumiselle: Jos asiakas mainitsee jotain yllättävää, jatka johtolankaa jatkokysymyksillä. Ajoittain kysymyksen yllätyksellisyys paljastaa piileviä tarpeita. Nämä ovat asiakastarpeiden tärkeä ulottuvuus. Piilevät tarpeet ovat tarpeita, joita ei ole täytetty eikä yleisesti selvästi ilmaistu ja ymmärretty.

Seuraa sanatonta tietoa: Sanat eivät aina ole paras tapa kommunikoida tarpeita liittyen fyysiseen maailmaan. Tämä on erityisesti totta tarpeiden kohdalla, jotka vaativat tuotteelle inhimillisiä ulottuvuuksia, kuten mukavuus, imago tai tyyli. Kehitysryhmän tulee olla jatkuvasti hereillä asiakkaiden tarjoamista sanattomista viesteistä. Mitkä ovat heidän ilmeet kasvoilla? Miten he tarttuvat kilpailijoiden tuotteisiin?

III ASIAKASVUOROVAIKUTUSTEN DOKUMENTOINTI

Asiakkailta koottava tieto tulee dokumentoida myöhempää käsittelyä varten. Yleisesti käytettyjä menetelmiä ovat ääninauhoitus, muistiinpanot, videokuvaus ja valokuvaus.

Prosessin tiedonkeruuvaiheen lopputuloksena on joukko käsittelemätöntä tietoa, joka yleensä on customer statement –muodossa, mutta jota ajoittain täydennetään videotallenteilla ja valokuvilla (Ulrich & Eppinger 2003).

Vaiheen viimeisenä tehtävänä on kirjoittaa kiitoskirjeet prosessissa mukana olleille asiakkaille (Ulrich & Eppinger 2003).

3. Vaihe: Tulkitaan käsittelemätöntä käyttäjätietoa asiakastarpeiden suhteen

Asiakastarpeita ilmaistaan kirjallisina lausuntoina ja ne ovat asiakkailta kerätyn käsittelemättömän tiedon taustalla olevien tarpeiden tulkinnan tulosta. Jokainen lausunto tai havainto voidaan tulkita vaihtelevaksi määräksi asiakastarpeita. (Ulrich & Eppinger 2003)

4. Vaihe: Tarpeiden järjestäminen hierarkiaan

Vaiheiden 2–3 kautta tulisi listata 50–300 tarvelausuntoa (need statement). Suuri määrä edellyttää, että asiakastarpeet saadaan järkevään tärkeysjärjestykseen. Yleensä ne jaetaan kolmeen tasoon: primaarisiin, sekundäärisiin ja tertiäärisiin (Griffin & Hauser 1993). Tuotekehitysryhmä käyttää primaarisia tarpeita asettamaan strategisen suunnan tuotteelle tai palvelulle (ibid.). Porrastukseen voidaan käyttää myös muita tarvejakoja.

Jokaiselle primaariselle tarpeelle laaditaan 3–10 sekundääristä (taktista) tarvetta (ibid.). Sekundääriset tarpeet indikoivat erityisemmin, mitä ryhmän täytyy tehdä tyydyttääkseen primääriset (strategiset) tarpeet (ibid.).

Tertiääriset tarpeet tunnetaan myös operatiivisinä tarpeina (operational needs) (ibid.). Nämä tarjoavat yksityiskohtia, jotta insinöörit ja tuotekehitys voivat kehittää teknisiä ratkaisuja, jotka tyydyttävät sekundääriset tarpeet (ibid.).


5. Vaihe: Laaditaan tarpeiden suhteellinen tärkeys

Hierarkinen lista ei yksin tarjoa mitään tietoa asiakkaiden asettamasta suhteellisesta tärkeydestä eri tarpeille. Tässä vaiheessa kehitysryhmän tulee tehdä vaihtokauppaa (trade-offs) ja kohdentaa resursseja tuotteen suunnitteluun ja toteutukseen. Tuntuma lukuisten tarpeiden suhteelliseen tärkeyteen on oleellista, jotta pystytään tekemään vaihtokaupat oikein. Tässä kohtaa todetaan vaiheissa 1–4 havaittujen asiakastarpeiden suhteellinen tärkeys. Lopputuloksena tästä vaiheesta on numeerinen tärkeys, jolla painotetaan tarpeiden osajoukkoa. Tähän tehtävään on kaksi peruslähestymistapaa: a) luotetaan ryhmän yhteisymmärrykseen, joka perustuu heidän kokemukseensa asiakkaista tai b) perustetaan tarpeiden tärkeyden arviointi myöhempiin asiakastutkimuksiin. Ilmeinen vaihtokauppa näiden kahden lähestymistavan välillä on kustannukset ja nopeus vastaan paikkansapitävyys. Ryhmä voi tehdä tarpeiden suhteellisesta tärkeydestä oppineen arvioinnin yhdellä tapaamisella, kun taas asiakastutkimus yleisesti vie minimissään kaksi viikkoa. Muut kehitystehtävät, kuten konseptin kehittäminen ja kilpailevien tuotteiden analysointi voidaan aloittaa ennen kuin tarpeiden suhteellisen tärkeyden tutkiminen on suoritettu loppuun.

Menetelmät käyttäjätiedon kokoamiseen Laadullisen tiedon keräämismenetelmät Laadullisen tiedon kerääminen vaatii suoraa kanavaa asiakkaisiin. Tutkimusaineisto kerätään todellisessa kontekstissa ja tilanteissa. Laadullisilla tutkimusmenetelmillä saavutetaan ilmiöiden prosessiluonne. Käyttäjätiedon keräämiseen on olemassa suuri valikoima erilaisia menetelmiä. Ehkä yleisimpiä menetelmiä ovat erilaiset kyselyt ja haastattelut. Seuraavaksi käydään läpi lyhyesti muutamia menetelmiä, jotka soveltuvat hyvin tuotekehitystoimintaan.

Haastattelu Haastattelu voidaan toteuttaa yksilö- tai ryhmähaastatteluna. Yksilöhaastattelu on eniten käytetty haastattelumenetelmä. Haastattelussa tutkija käy läpi sarjan kysymyksiä, jotka ovat suunnattu suoraan osallistujalle. Haastattelut suoritetaan yleensä kasvotusten, mutta toisinaan myös puhelimitse. Haastatteluista on olemassa kolme laajaa kategoriaa – avoin haastattelu, puolistrukturoitu ja strukturoitu. (Jordan 2000)

Haastattelutyyppejä:

1. Strukturoitu haastattelu (lomakehaastattelu)

- Kysymysten muotoilu ja järjestys kaikille sama

- Valmiit vastausvaihtoehdot

2. Puolistrukturoitu haastattelu (teemahaastattelu)

- Kysymykset kaikille samat, mutta ei valmiita vastausvaihtoehtoja

3. Avoin haastattelu (unstructured)

- Haastattelija ja haastateltava keskustelevat tietystä aiheesta, mutta kaikkien haastateltavien kanssa ei käydä läpi kaikkia teema-alueita (Hirsijärvi & Hurme 1995)

Haastattelutilanne kannattaa suunnitella tarkkaan etukäteen. Hyvin suunniteltu kysymysrunko helpottaa analysointivaihetta ja laadukkaan aineiston saantia. Suunniteltaessa on otettava huomioon myös käytännön järjestelyihin liittyviä seikkoja,


kuvin. Mind Map -kaaviot soveltuvat yksilötyöskentelyyn, mutta esimerkiksi brainstorming-session yhteydessä kaavioiden avulla voidaan suhteellisen nopeasti rakentaa yhteinen kuva käsiteltävistä aiheista ryhmän sisällä.

Kuva 14. Miellekartta. [Wikipedia] Fishbone Diagrams Kaoru Ishikawa kehitti syy–seuraus-diagrammin vuonna. Fishbone-diagrammin tekemisen prosessi on samankaltainen, kuin Mind Map -kaavion tekeminen paitsi, että parantelua tarvitseva pääominaisuus asetetaan vaakatasoiseen nuoleen (tai ”kalan selkänikamaan”) sen sijaan, että se asetettaisiin keskiympyrään (ibid.). Päätekijät, jotka saattavat aiheuttaa ongelman on määritetty ja asetettu diagrammissa pääruotoihin. ”Miksi?” -kysymysten avulla kalan rungon jokaiseen haaraan kerätään yksityiskohtaisia tekijöitä, joita saatetaan pitää mahdollisina syinä, ja ne asetetaan ruodon jatkoksi. Kaikkia kohtia kannattaa tarkentaa mahdollisimman pitkälle. Tätä kautta saatetaan löytää ongelmia, jotka eivät muuten olisi tulleet mieleen. Kalanruotodiagrammi helpottaa eri ongelmankohtien havainnollistamista ja niiden rakenteiden arvioimista.

Kuva 15. Kalanruotodiagrammi.


ensisijaisen tärkeää, sillä luova ongelmanratkaisu ei tapahdu itsekseen, vaan sen eteen on tehtävä töitä. Ideoinnille voidaan antaa määrällisiä tavoitteita, kuten esimerkiksi tänään tehdään 30 vaihtoehtoista ratkaisuehdotusta, joista viisi valitaan tarkempaan kehittelyyn. Toisaalta joissakin ideointimenetelmissä (kuten Synectics) muutamat hyvät ideat syntyvät ja kehittyvät monen aikaisemman idean ympärille ja määrä ei sinänsä ole itse tarkoitus.

Suoritus taas vaatii niin sisäistä kuin ulkoista motivaatiota. Täytyy olla halua etsiä ratkaisua ongelmaan ja viedä asioita eteenpäin. Pelkkä näennäinen puuhastelu tuhlaa kaikkien aikaa. Parhaimmillaan sisäisen motivaation voi kokea ns. flow-kokemuksena, jolloin yksilö tai ryhmä uppoutuu täysin itse suoritukseen.

Aivan alkuvaiheessa ideointi on visioiden luomista, myöhemmin siihen liittyy myös ideoiden arviointia, jatkokehittelyä ja valintaa. Itsenäisen tai ryhmässä tapahtuvan luovan ajattelun tai ideointiprosessin perusedellytyksenä on myönteisen ja rohkaisevan ilmapiirin luominen. Luottamus ja kommunikaatio ovat ryhmätyöskentelyn onnistumisen peruselementtejä. Yksilötasolla se taas tarkoittaa lähinnä avoimen asenteen omaksumista ja liiallisen itsekritiikin poistamista.

Ideoinnin tarkoituksena ei ole kerralla saada valmista, vaan asteittain iteroivan divergentin ja konvergentin ajattelumallien kautta kristallisoidaan ideat lopulliseen muotoonsa. Hyvä lähtökohta aloitettaessa niin itsenäistä kuin ryhmätyöskentelyä on noudattaa alkuperäisiä myöhemmin esiteltäviä brainstorming-sääntöjä.

Ideointimetodien ja menetelmien avulla ideointiprosessia pystyy hallitsemaan, tehostamaan, vahvistamaan ja vaihtelemaan. Tällöin prosessin ohjaus paranee, prosessi nopeutuu, pystytään tuottamaan monipuolisia sekä vaihtoehtoisia ratkaisuvaihtoehtoja, saadaan uusia näkökantoja ja pattitilanteissa päästään nopeammin liikkeelle.

Ei ole merkitystä, mitä metodia käytetään, vaan luonnollisesti kaiken perustana on mielikuvitus ja se että aivoja pyritään käyttämään luovasti ilman ennakko-olettamuksia. Metodit itsessään eivät tee mitään, mutta ne antavat vaihtoehtoisia menettelyohjeita, joita voi tarvittaessa soveltaa omiin tilanteisiin. Nyrkkisääntönä voi pitää, että monta lyhyttä ideointisessiota tarkkaan rajatuista ongelmista on parempi kuin yksi laaja ja pitkäkestoinen sessio. Kun jokin metodi on todettu toimivaksi, sopiva ideointisession pituus voi olla noin 40–50 minuuttia.

Seuraavaksi esitellään muutamia yleisiä ideointimenetelmiä. Luvun lopuksi esitellään esimerkki mahdollisesta ideointisession kulusta.

Ideointimenetelmiä Ajatusten organisointia ja ongelman kartoittamista Mind-MapMind Map -kartta on helppokäyttöinen työkalu arvioinnin tai ideoinnin apuvälineenä. Mind Map -työskentelyssä pyritään strukturoimaan ajatuksia. Ensin määritellään ja rajataan käsiteltävä aihe ja kirjoitetaan se paperin keskelle. Tämän jälkeen ideoidaan vapaasti, mitä kyseinen sana tai ongelma tuo mieleen. Kaikki mielleyhtymät ja assosiaatiot ryhmitellään ongelman ympärille hierarkiaan ja kategorioihin. Täten metodi tuottaa hetkessä helposti hahmotettavan kuvan aiheeseen liittyvistä tekijöistä. (Buzan & Buzan 2003)

Mind Map -työskentelyä voidaan tehostaa asettamalla kaavion keskustaan kuva sanan sijaan. Tehokkaimmillaan Mind Map -työskentelyssä yhdistetään ajatuksia sanoin ja


esimerkiksi haastattelun toteutusympäristön valinta tai tallennusvälineiden testaaminen ennen varsinaista haastattelua.

Haastattelulla on aina päämäärä eli sillä pyritään saamaan informaatiota. Haastattelu on vuorovaikutusta, jossa molemmat osapuolet vaikuttavat toisiinsa. Haastattelijan on kuitenkin vältettävä johdattelua. Haastattelu on itsessään usein lyhyt ja helppo toteuttaa, mutta aineiston purkaminen vie aikaa. (Hirsijärvi & Hurme 1995)

Aineisto on hyvä purkaa mahdollisimman nopeasti haastattelun jälkeen. Aineisto voidaan litteroida kokonaan eli sanallisesti puhtaaksikirjoittaa tai purkaminen voidaan tehdä valikoiden vain tietystä teemasta. Yksi vaihtoehto on korostaa vain johtopäätöksiä ja päätelmiä.

Haastattelumenetelmien vertailua (Hirsijärvi ja Hurme, 1995)

Lomakehaastattelu Teemahaastattelu Avoin haastattelu

Kysymysten muotoilu Kiinteä Vapaa Vapaa

Kysymysalue Tarkkaan määritelty Pääpiirteittäin määrittely Vapaa

Koehenkilömäärä Suuri Melko pieni Pieni

Työmäärä kokonaisuudessaan (valmistelu, toteutus ja analyysi)

Kohtalainen Suuri Suuri

Saatu tieto Etukäteen rajattu Laaja Laaja

Kaavio 5: Esimerkki Customer Chain -kaaviosta, missä esitetään kolikkokäyttöisenjuoma-automaatin mallia (Donaldson et al. 2006). KohderyhmähaastatteluKohderyhmähaastattelu (focus group interview) on ryhmähaastattelumenetelmä. Siinä luodaan yhteinen haastattelutilanne useiden henkilöiden kanssa, joilla on joko samankaltaisia arvoja tai yhteisiä kokemuksia kyseessä olevasta asiasta. Vaihtoehtoisena lähestymistapana on valita ristikkäisiä mielipiteitä, arvoja tai käsityksiä omaavia samaan ryhmään. Täsmähaastattelu perustuu ryhmädynamiikan hyödyntämiseen, sillä ryhmässä keskustelu voi olla runsaampaa kuin yksilöhaastattelussa. Lisäksi tieto saadaan nopeasti usealta henkilöltä. (Jordan 2000)

Ryhmähaastattelun toteutus Valitaan osallistujat tuotteen aiemmasta käyttäjäryhmästä tai uusien asiakkaiden kohderyhmästä, jotka pystyvät keskustelemaan uudelle tuotteelle asettavista odotuksista ja vaatimuksista (eli lähtökohtana on mielellään tuotteen aiempi käyttökokemus). Tyypillisesti yhteen kohderyhmäsessioon osallistuu 8–12 osallistujaa. Markkina-analysoija asettaa keskustelun teeman, joka voi olla suhteellisen kapea (esim. 35 mm amatöörikamerat) tai jokseenkin laaja (esim. valokuvauskokemus, kuten sinä näet sen). Keskustelu voi esimerkiksi sisältää käyttäjien kokemuksia tuotteesta ja käyttäjien asenteista tuotteen estetiikasta tai toiminnallisuudesta.


Yleensä kohderyhmäkeskustelut nauhoitetaan, litteroidaan ja myöhemmin tarkastetaan. Tästä aineistosta sitten identifioidaan tärkeitä tuoteominaisuuksia, joita käydään implisiittisesti (epäsuorasti) tai peittelemättömästi lävitse keskustelun aikana.

Hyvä vinkki on valita ”miniryhmähaastatteluun” esimerkiksi kolme 15-vuotiasta kaverusta, jotka keskustelevat Playstation-laitteen käytöstä. Kaverit paljastavat aika helposti ystävän, jos hän kertoo muunneltua totuutta käyttötavoistaan.

Havainnointi, Observointi Riippumatta tieteenalasta, inspiraatio syntyy usein lähellä toimintaa. Uudet ideat seuraavat näkemisestä, haistamisesta ja kuulemisesta – läsnäolosta. Observointi (observation) on menetelmä, jonka avulla pyritään pääsemään asioiden ymmärtämisessä syvemmälle tasolle (omakohtainen kokemus) kuin se on haastatteluissa yleensä mahdollista. Observoinnissa havainnoidaan ihmisiä heidän tehdessä työtehtäviä luonnollisessa ympäristössä. Observoidessa ei vain seurata ihmisen käyttäytymisen sävyjä, mutta myös pyritään tekemään johtopäätöksiä heidän motivaatiostaan ja tunnetiloistaan (ibid.). Hyvä tarkkanäköinen observointi yhdistää huolellisen seuraamisen ajoittaisiin hyvin valittuihin ”miksi?” -kysymyksiin, jotta saadaan alusta henkilön vuorovaikutuksen psykologialle tuotteiden ja palveluiden välillä (ibid.).

Kun suoritetaan kenttäarviointia, on tärkeää, että tutkija varmistaa, että hänen mukanaolo on minimaalista. Observoinnin aikana työntekijät helposti tekevät asioita erilailla kuin normaalisti tai teeskentelevät. Observoinnin heikko lenkki on uusia tuotteita suunniteltaessa siinä, että käyttäjältä puuttuvat uuden tuotteen osat. Tätä voidaan lieventää tekemällä ensin joitain prototyyppejä ja vasta sen jälkeen suorittaa observointia.

Observoitiin ja keskusteluun voidaan valita useita kiinnostavia käyttäjiä. Observoitavaksi on hyvä valita ihmisiä, jotka rikkovat tuotteen tai palvelun käytön perussääntöjä, löytävät toimintoihin oikopolkuja tai tekevät tuotteella asioita, joita ei ohjekirjoissa mainita.

Observointi-sessiot yleensä videoidaan, jolloin niiden arviointi myöhemmin tuotekehitysryhmän sisällä helpottuu ja tällöin yksittäisen havainnoijan subjektiivisen tulkinnan merkitys vähenee.

Toimintaympäristökartoitus (Contextual inquiry, CI) CI perustuu etnografisen alueen menetelmiin (Keinonen et al. 1998). Menetelmää voi soveltaa sekä käyttöliittymien tutkimiseen tai yleensä työskentelyn tarkkaan seurantaan. CI on haastattelun ja havainnoinnin yhdistelmä, jonka lähtökohtana on kerätä tietoa todellisista käyttötilanteista ja todellisista käyttökonteksteista. Sillä pyritään ymmärtämään käyttäjän toimintoja, miten he ne suorittavat, lisäämään ymmärrystä todellisista käyttäjistä ja todellisista tehtävistä todellisissa konteksteissa (ibid.). Menetelmässä korostuu seuraava roolijako – käyttäjä on asiantuntija omassa työtehtävässään ja suunnittelija on oppilas tai käyttäjän kumppani.

Koska tuotekehityksen aikataulut ovat yleensä kireitä, CI pyritään suorittamaan yleensä mahdollisimman pienellä otoksella ja mahdollisimman erilaisilla käyttäjillä, jotta saataisiin tyhjentävä kuva käyttäjien työstä. Yksi CI kestää n. 2–3 tuntia. Sessiot yleensä kuvataan ja nauhoitetaan tai niistä tehdään muistiinpanoja haastattelijasta riippuen myöhempää analysointia varten. Ennen kenttätutkimusten aloittamista on syytä hakea vastauksia seuraaviin kysymyksiin:


a) Excessive expansion b) Balanced search c) Unreasonable restrictiona) Excessive expansion b) Balanced search c) Unreasonable restriction

Kuva 12. Vaihtoehtoisia konseptin kehitysstrategioita [Fricke96] Kuvassa 13 on esitetty konseptin kehitystä kuvaava toimintamalli. Kuvan esitystapa pyrkii korostamaan konseptin kehityksen vuorovaikutuksia. Mallin ensimmäisessä vaiheessa markkinoiden tarpeita ja markkinasegmenttejä verrataan yrityksen tuotevalikoimaan. Seuraavassa vaiheessa kartoitetaan käyttäjien tarpeita ja verrataan sekä varmennetaan käyttäjiä hyväksikäyttäen kehitettyjä tuotekonsepteja. Kolmannessa vaiheessa yritysten sisäisten sidosryhmien, kuten valmistuksen tarpeita ja mahdollisuuksia verrataan edellisissä vaiheissa kehitettyihin tuotekonsepteihin. Viimeisessä vaiheessa arvioidaan kehitettyjen tuotekonseptien ominaisuuksia sekä tarkennetaan niitä.

Markkinoidentarpeet

Käyttäjientarpeet

Yrityksen sisäisetsidosryhmät

Ominaisuuksienarviointi

Yrityksen tuotteet/

Tuoteportfolio Konseptien luonti

Konseptien valinta

Konseptienjatkokehittely

Markkinoidentarpeet

Käyttäjientarpeet

Yrityksen sisäisetsidosryhmät

Ominaisuuksienarviointi

Yrityksen tuotteet/

Tuoteportfolio Konseptien luonti

Konseptien valinta

Konseptienjatkokehittely

Kuva 13. Iteratiivinen konseptin kehitysprosessi [Hansen&Andreasen]

IdeointiIdeointia voidaan pitää prosessina, johon olennaisena osana kuuluu ongelman tunnistaminen ja siihen liittyvien tosiasioiden ja olettamusten käsittelyä. Ideointiin liittyy luovuutta, joka ilmenee ongelman ratkaisemisena usein odottamattomalla tai uudella tavalla. Ideointiprosessin onnistumisen kannalta tavoitteenasettelu on


• Selvennä ongelmao Pura ongelma osiin

• Ulkoinen kartoituso Keihäänkärkikäyttäjäto Asiantuntijato Patentito Kirjallisuuso Kilpailijavertailut

• Sisäinen kartoituso Yksilömenetelmäto Ryhmämenetelmäto Palaute nykyisestä tuotteesta

• Systemaattinen kartoituso Luokitteleo Yhdistele

• Kehitä prosessiao Jatkuva parantaminen

Selvennäongelma

Ulkoinenkartoitus

Sisäinenkartoitus

Systemaattinen kartoitus

Kehitäprosessia

Aliongelmat

Olemassa olevia konsepteja

Uusia konsepteja

Integroidut ratkaisut

• Selvennä ongelmao Pura ongelma osiin

• Ulkoinen kartoituso Keihäänkärkikäyttäjäto Asiantuntijato Patentito Kirjallisuuso Kilpailijavertailut

• Sisäinen kartoituso Yksilömenetelmäto Ryhmämenetelmäto Palaute nykyisestä tuotteesta

• Systemaattinen kartoituso Luokitteleo Yhdistele

• Kehitä prosessiao Jatkuva parantaminen

SelvennäongelmaSelvennäongelma

UlkoinenkartoitusUlkoinenkartoitus

SisäinenkartoitusSisäinenkartoitus



Kehitäprosessia

Kehitäprosessia

Aliongelmat

Olemassa olevia konsepteja

Uusia konsepteja

Integroidut ratkaisut

Kuva 11. Systemaattinen konseptin kehitys [U&E] Uusien konseptien luomiseen löytyy tietoa kirjasen kohdasta Ideointi (s. 37). Ideointimenetelmiä käytettäessä on syytä muistaa seuraavat perussäännöt: vältä arviointia, luo paljon ideoita, mahdottomat ideat ovat tervetulleita, käytä visualisointeja ja fyysisiä esineitä. Usein ideoinnissa on myös hyödyllistä asettaa tavoite ideoiden lukumäärälle.

Pääsääntöisesti ulkoinen kartoitus keskittyy etsimään tietoa edelläkävijäkäyttäjiltä, vertailututkimuksella, asiantuntijoilta, patenteista sekä alaan liittyvästä kirjallisuudesta.Jokaisesta näistä yksittäisistä osa-alueista on saatavilla kirjallisuutta, joiden perusteella voi kehittää oman yrityksensä toimintaa.

Konseptin kehitys- ja valintamalleja Konsepteja voidaan valita ja kehittää pääsääntöisesti nojautuen kolmeen eri toimintastrategiaan. Nämä kolme strategiaa on esitetty alla olevassa kuvassa 12. Kuvan kohdassa a) on esitetty ylenmääräinen ratkaisuavaruuden laajennus (excessive expansion) strategia. Laajan strategian etuna on, että konsepteja kehitetään hyvin laajasti ja valintaa tehtäessä on käytettävissä kaikki kehitetyt ratkaisut. Kohdassa c) on ylenmääräisen rajoitettu (unreasonable restriction) ongelmanratkaisustrategia. Tässä toimintamallissa kehitetään ja testataan konseptit yksittäin. Tämän toimintatavan heikkoutena on mahdollinen riskien ja kehitysajan kasvu, jos useat kehitetyt konseptit osoittautuvat heikoiksi. Näiden kahden ääriesimerkin väliltä on tasapainotettu malli (balanced search), kodassa b). Tässä mallissa kehitetään ja testataan aluksi konseptin perusratkaisu. Valitun perusratkaisun pohjalta kehitetään uusissa ratkaisuissa pidemmälle meneviä vaihtoehtoja, joista valitaan tai muodostetaan taas yksi perusratkaisu. Näin konseptia tarkennetaan, kunnes on kehitetty vaatimukset täyttävä konsepti. Tällä konseptinkehitysmallilla pyritään saavuttamaan molempien a) ja c) mallien hyödyt. Fricke esittää tämän tasapainotetun strategian johtavan kaikista varmimmin konseptin valinnan onnistumiseen [Fricke96].


1. Ketkä ovat käyttäjiä?

2. Mihin tuotetta käytetään?

3. Mikä on ympäristö?

4. Minkä tyyppistä tietoa kerätään?

5. Millä tavoin tätä tietoa tullaan keräämään ja esittämään?

6. Kuinka paljon aikaa voidaan käyttää observointiin?

7. Mitä menetelmiä voidaan käyttää? (Keinonen et al. 1998)

Menetelmän kulku on yleensä seuraava: haastattelija tekee oma-aloitteisesti kysymyksiä. Haastattelija myös seuraa, mitkä systeemin tekijät tukevat tai häiritsevät työskentelyä ja kuinka systeemi käy vuoropuhelua koko työkontekstissa. Käyttäjä yleensä kommunikoi kaikista luontevimmin esittäen käsittelyjärjestykset (work flow) ja toiminnat oikeassa kontekstissa. Yleensä on ensin parempi seurata toimintoja ja sen jälkeen haastatella (ibid.). On tärkeää havaita, mitä käyttäjä tekee, mutta myös tekojen motivaatio ja strategia.

Haasteena on, että kysymykset saattavat tuottaa lisää tietoa, mutta ne saattavat myös muuntaa ja häiritä käyttäjän suorittamista. Kysymykset ovat yleensä hyvin konkreettisia liittyen työskentelyyn: Mitä sinä teet? Mitä tapahtuu jos? Mitä tämä tarkoittaa? Miksi? Miksi ei? Teetkö aina näin? (ibid.)

CI:n tuloksena saadaan objektiivista tietoa asiankäsittelyn suorittamisesta, jolla voidaan ruokkia suunnitteluprosessia. Materiaali voidaan analysoida suhteellisen nopeasti määrittäen kriittiset työvaiheet. Yleisesti on ajallisesti tehokkaampaa luoda uusia ideoita ja arvioita niitä käyttäjän kanssa, esimerkiksi iteroiden, kuin pyrkiä löytämään kaikki tieto havainnoista (ibid.).


Menetelmä Pyrkimys Resurssit Tulokset Haasteet/riskit Tiedon jakokä-sittely/tulkinta

Käyttäjä-haastattelut

(User Interviews)

-Haastattelun tarkoitus on syventää jo omattua tietoa.

-Haastattelun avulla voidaan selvittää muuten vaikeasti havaitavia seikkoja esim. haastateltavien motiiveja.

-Haastattelun käyttö on perusteltua silloin kun on kyseessä vähän tutkittu ja tuntematon alue. (Hirsjärvi & Hurme)

-Yksi haastattelu vie aikaa n. 1-2 h.

-Haastattelun purkuun ja tiedon käsittelyyn kuluu enemmän aikaa.

-Kysymysten suunnittelu ja asettelu vie yllättävän paljon aikaa.

-Materiaalia syntyy paljon ja niiden tulkinta voi olla haasteellista, koska haastattelija voi tulkita asiat haluamallaan tavalla tai muuten vaan väärin.

-Haastattelijan on oltava kaikissa tilanteissa mahdollisimman neutraali eikä omia mielipiteitä saisi tuoda esille.

-Haastateltava ei tule ajatelleeksi, että tietystä asiasta kertominen olisi tärkeää, ja jättää asian mainitsematta.

-Haastateltava häpeää joitain omia työtapoja (ja salailee tai muuntelee niitä kertomuksessaan).

-Haastattelija ymmärtää käyttäjien kertomuksia väärin.

Kohderyhmä-haastattelut

(Focus groups)

-Ryhmähaastattelussa käytetään hyväksi ryhmädynamiikkaa.

-Etuna yksilöhaastatte-luun verratessa on nopeampi tiedon saanti useammalta henkilöltä. Lisäksi keskustelu voi olla runsaampaa kuin yksilöhaastattelussa.

-Yksi ryhmähaastattelu voi viedä n. 2 h.

Ks. ed. -Hyödyllisen tiedon erottuminen on riippuvainen hyvin paljon analysoijan kyvyistä erottaa oleellinen tieto, joita käyttäjät pitävät tärkeinä tuotteessa.

-Osa haastateltavista ei tuo esiin omaa näkemystään.

Havainnointi

(Observation)

-Pyritään saamaan käyttäjästä esille tietoa, jota he itse eivät välttämättä osaa kertoa suunnittelijoille.

-Tavoitteena on koota tietoa käyttäjän oikeassa toimintaympäristöstä.

-Havainnointiin voi osallistua useitakin henkilöitä, mutta toisaalta suuri määrä voi häiritä kohderyhmän edustajaa

-Kaikkiin tässä esiteltyihin menetelmiin liittyy materiaalin runsas määrä. Näiden muokkaaminen laadukkaaksi tulokseksi vaatii paljon työtä (jäsentelyä, käsittelyä ja luokittelua).

-Käyttäjä ryhtyy usein ylisuorittamaan tai esittämään observoinnin aikana ja tällöin eivät todelliset ongelmakohdat tule välttämättä esille

-Flow model

-Sequence model

-Cultural model

-Physical model

-Artifact model

Varjostaminen

(Shadowing)

-Menetelmä on hyvin samanlainen kuin aktiivinen havainnointi.

-Varjostamisen aikana käyttäjän toimenpiteisiin ei juuri puututa.

-Varjostusta tehdään yleensä kokonainen päivä tai jopa pidempään.

-Passiivinen havainnointi tehdään siten, että kohderyhmän edustaja ei tiedä olevansa tarkkailun kohteena.

-Varjostamalla käyttäjiä suunnittelija löytää oivalluksia, jotka juontavat juurensa tapahtumiin osallistumisesta ja niihin samaistumisesta.

-Vaarana on, että loukataan seurattavan yksityisyyttä.

Toimintaympäristökartoitus

(Contextual Inquiry)

-Menetelmän periaatteena on mennä sinne, missä tieto on eli todelliseen käyttötilanteisiin ja –ympäristöihin.

-Käyttäjä on omassa tekemisessään ekspertti.

-Tutkija on oppilas.

-Tarvitaan haastattelija ja kirjuri.

-Johtuen tuotekehityksen tiukoista aikataulutuk-sista otetaan kartoituk-siin mukaan vain pieni otos käyttäjiä (4-6).

-Mikäli tavoitteena on pyrkimys löytää uusia tuotemahdollisuuksia haastatteluja on syytä tehdä 15-20.

-Yksi CI kestää n. 2-3 tuntia.

-Menetelmällä saadaan selville käyttäjän tapoja käyttää tuotetta, ongelmakohtia ja parannusehdotuksia olemassa olevasta tuotteesta.

-Suunnittelutyössä on vaikeaa päästä eroon ennokko-oletuksista – siitä millainen käyttäjä ja järjestelmä on ja miten järjestelmän tulisi toimia.

-Suunnittelijan malli ei välttämättä ole käyttäjän malli.

-Tulkintaa voidaan testata käyttäjän kanssa.

-Tulkinta voidaan muokata skenaarioksi.

Kaavio 6: Käyttäjätarpeiden kokoamismenetelmien vertailutaulu. Lähteet:Beyer, H. & Holtzblatt, K. 1999. Contextual Design. Interactions Jan.+ Feb. Donaldson, K.M., Ishii, K., & Sheppard, S.D. 2006. ”Customer Value Chain Analysis”. Research in Engineering Design 16: 174-183. Griffin, A. & Hauser, J. R. 1993. "The Voice of Customer", Marketing Science, Vol. 12, No. 1., Winter 1993. Hirsijärvi, S. ja Hurme, H., 1995, Teemahaastattelu. Yliopistopaino. Helsinki


Jordan, P.W. 2000. ”Designing Pleasurable Products”. Taylor & Francis Inc., Philadelphia, PA, USA Keinonen, T., Mattelmäki, T., Soosalu, M. & Säde, S. 1998. User interface design tools. Working papers, UIAH, Helsinki. Kelley, T. & Littman, J. 2001. ”The Art of Innovation”. Doubleday, New York. Kotler. P. & Armstrong, G. 2004. “Priciples of Marketing”, Tenth Edition, Pearson Prentice Hall Rogers, E. M., 1995. “Diffusion of Innovations”, 5th ed. New York: The Free Press. Ulrich, K. & Eppinger, S. 2003. “Product Design and Development”, Third Edition McGraw-Hill Companies, Inc.. von Hippel, E., 1986. Lead users: a source of novel product concepts. Management Science 32, no. 7: 791-805. Wixon, D., Holtzblatt, K., & Knox, S. 1990. Contextual Design: an Emergent View of System Design. Proceedings of CHI ’90.

Tuotekonseptien luominen Tunnistaasiakkaan

tarpeet

Aseta tavoite

spesifikaatiot

Luokonsepteja

Valitsetuote-

konseptit

Testaa tuote-

konsepteja

Aseta lopulliset

spesifikaatiot


Tunnistaasiakkaan

tarpeet

Aseta tavoite

spesifikaatiot

Luokonsepteja

Valitsetuote-

konseptit

Testaa tuote-

konsepteja

Aseta lopulliset

spesifikaatiot


Tuotekonseptien luominen sijoittuu tuotekehitysprosessissa konseptien kehitysvaiheeseen ja siinä tarkemmin tuotteen tavoitespesifikaation asettamisen jälkeiseen ajankohtaan. Tällöin tuotekonseptien luomisen pohjana voidaan käyttää tuotteen tavoitespesifikaatioita.

Konseptien kehittäminen Tuotekonsepteja kehitettäessä tulisi olla selvillä tuotteen kohderyhmä, asiakasvaatimukset ja tavoitespesifikaatiot tuotteelle. Tämän lisäksi tuotekehittäjillä tulisi olla hyvä kuva tuotteen käyttötavasta sekä käyttöympäristöstä. Myös näistä muodostetut konseptien valintakriteerit voivat toimia innoittajana konseptien kehittämiseen.

Konseptien kehittäminen voidaan jakaa kuvan 11 mukaisiin vaiheisiin. Ensimmäiseksi konsepteja kehitettäessä on syytä pyrkiä pilkkomaan ongelma pienempiin osiin. Seuraavaksi näihin osaongelmiin etsitään ratkaisuja yrityksen sisältä tai ulkopuolelta. Lopulta konseptit pyritään ryhmittelemään eri luokkiin, mikä saattaa vielä synnyttää uusia konsepteja tai olemassa olevien konseptien risteytyksiä.

tuotekehityksen abc

Documents