Tampere
29 Mar, Friday
3° C

Proakatemian esseepankki

Tuotekehitystä tukeva organisaatio



Kirjoittanut: Juho Vähätalo - tiimistä Hurma.

Esseen tyyppi: / esseepistettä.

KIRJALÄHTEET
KIRJA KIRJAILIJA
Esseen arvioitu lukuaika on 6 minuuttia.

Soluesseen kirjoittajat: Aaro, Emilia & Juho

Johdanto

Millainen organisaatiorakenne tukisi parhaiten oman tarjoaman kehittämistä Proakatemian tiimiyrityksessä? Olemme Hurmassa uudistaneet organisaatiorakennetta ensi keväälle palvelemaan paremmin meidän yhteisen tarjoaman kehittämistä ja sen eri vaiheita. Tämä ei kuitenkaan ole helppoa. Kuinka luoda sellainen organisaatio, jossa jokainen on tärkeä ja jokaisen työpanosta tarvitaan? Kuinka saadaan sidottua 16 ihmistä yhteisen tarjoaman kehittämisen ympärille ja kuinka sitä voidaan johtaa hyvin? Mikä voisi olla se paras tapa kehittää ja luoda yhteistä tarjoamaa?

Lähdimme tämän hetkisestä Hurman johtoryhmästä kolmen hengen voimin lukemaan erilaista kirjallisuutta tähän aiheeseen. Suoria sellaisenaan käytäntöön vietäviä vinkkejä on todella vaikea löytää. Joitain Hurmaan soveltamiskelpoisia vinkkejä kuitenkin löytyi ja niitä haluamme avata tässä esseessä. Siihen millä menetelmällä haluamme Hurmassa projekteja kehittää löytyi kuitenkin selkeä vastaus.

 

Mitä Hurma on tehnyt yhteisen tarjoaman eteen

Hurmalla on ollut huikea taival tähän asti ja viime keväänä jo kylvettiin yhteisen palvelun tai tuotteen siemenet. Siemenet eivät kuitenkaan alkaneet itää kevään eikä kesän aikana. Ajatus jäi kuitenkin hautumaan ja syksyn ensimmäisten kouluviikkojen aikana tiimin kehityspäivillä Kroatian paahtavan auringon alla lyötiin viisaat päämme yhteen ja asetimme syksyn tavoitteeksi kehittää yhteistä palvelua. Syksyn aikana yhteisen palvelun eteen on tehty töitä koko tiimin voimin valitettavan harvoin ja asiat eivät ole edenneet niin nopeasti, kuin olisimme halunneet. Käytimme tämän palvelun kehittämiseen keskimäärin yhden päivän kolmen viikon välein, joten etenemishitaus ei tullut yllätyksenä.

Hitaan alun jälkeen tiimissä vallitsee kova palo lähteä työstämään yhteistä palvelua, joten lähes itsestään kaikkien huulille nousi ajatus organisaatiorakenteen kehittämisestä kohti ketterämpää ja yhteistä tarjoamaa paremmin palvelevaa organisaatiorakennetta. Huomattiin tiimissä niin keväällä kuin syksylläkin, että ideat vaativat aikaa kypsyäkseen, joten siemenet pitää kylvää ajoissa, ja täytyy malttaa odottaa rauhassa niiden itämistä.

 

Hurman vanhaan rakenteeseen kuului pikkutiimit, koska pitäähän akatemialla pikkutiimit olla. Osittain ne kuuluvat meidän toimintaan edelleen, sillä esimerkiksi taloushallintoa on vain yksinkertaisesti pakko tehdä. Meille valittiin myös kolme henkilöä, jotka vastaavat tiimin johtamisesta eri näkökulmista. Niitä ollaan totuttu kutsumaan BL ja HR nimikkeillä.

Toisin kuin ennen, nyt yhteisestä tarjoamasta puhutaan projektina ja projektille valittiin projektijohtaja ja koko loppu tiimi on yhtä isoa pikkutiimiä. Yhden ison pikkutiimin päätoimenkuvana on ”tehdä sitä mitä pitää”.  Koko tiimillä ja erityisesti projektipäälliköllä on suuri vastuu pitää huolta, että toiminta pysyy ihmiskeskeisenä ja ketteränä. Olennaisena tehtävänä projektipäällikölle on saada koko tiimi ajattelemaan projektia samoista lähtökohdista eli toisinsanoen puhumaan samaa kieltä. (Heuer, 3.luku)

Tällä tavalla uskomme, että saamme vauhditettua yhteistä projektiamme ja pystymme tarttumaan mihin tahansa tehtävään entistä ketterämmin. Tehtävien vaihtuvuus ja ihmisten liikkuminen tehtävästä toiseen pitää ajatukset raikkaina ja se myös toivottavasti näkyy tuloksissa.

Pelkästään muuttamalla tiimin rakenteita, ei päästä parempiin tuloksiin, vaan meidän pitää ajatella raikkaammin myös itse projektin tuotekehitysprosessia ja käyttää mahdollisimman monipuolisesti erilaisia työkaluja. Niistä ajatuksia seuraavissa kappaleissa lisää!

 

Ei ole oikotietä onneen

Tuotekehityksessä on alettu entistä enemmän painottamaan tuotekehityksen ensimmäisen vaiheen eli ideoiden etsimisen tärkeyttä. Tärkeintä tässä on kuitenkin asiakaslähtöisen tutkimuksen tekeminen, asiakkaiden tarkkailu, skenaariotyöt ja organisaation sisäisten ideointiin tarkoitettujen tilaisuuksien pitäminen (Martinsuo & al. 2003: 38). Ilman hyvää esiselvitystä ei tule hyvää tuotetta. Oikotietä menestyksekkäisiin tuotteisiin ei ole. Tuotteen alkuvaiheessa taustatutkimukseen täytyy siis panostaa ja se onkin syytä huomioida organisaation muodostuksessa ja työtehtävissä. Meillä tuli ensimmäisenä mieleen, voisiko tiimin sisällä muodostettujen tuotteenkehittämisen ympärille luotujen pienempien tiimien tehtäviä vaihtaa kesken kauden. Hurmassa aiemmat kaudet tietyllä organisaatiomallilla ovat kestäneet puolivuotta kerrallaan. Tiimit aloittaisivat yllä mainituilla tehtävillä ja loppukeväästä keskittyisivät sitten enemmän muihin osa-alueisiin.

 

Projekti yhtenä tuotekehityksen organisointitapana

Projektiluontoinen tuotekehityksen toteuttaminen on koettu hyväksi, koska siinä toteutuu rajattu kesto, selkeä alku, tavoitteet ja loppu. Nämä ominaisuudet helpottavat tuotekehityksen seuraamista ja johtamista sekä antavat hyvän pohjan muun muassa palkitsemiselle.

Projektin päätavoitteet muodostuvat yleensä kolmesta tekijästä eli kustannuksista, aikatauluista ja sisällöllisestä laajuudesta, jotka ovat myös projektien etenemisen kannalta tärkeimmät (Martinsuo & al. 2003: 45). Mielestämme projektiluontoinen tuotekehitysmalli sopii myös Hurmalle, sillä olemme jo tottuneet projektiluontoiseen työskentelyyn. Meillä erona tulisi kuitenkin luultavasti olemaan ihmisten roolien vaihtuvuus projektin aikana.

Tuotekehitysprojektien menestystekijät liittyvät usein juuri asiakasnäkökulman ja kysynnän huomioonottamiseen (Loch 2000). Kirjassa painotetaan, että projektia toteuttaessa tulisi ymmärtää projektin lähtökohtien ja lopputuloksen merkitys asiakkaan arvoketjussa. Asiakasnäkökulma edellyttää, että vaihtoehtoiset projekti-ideat ja projektin tulosten käyttöympäristö ymmärretään projektin myynnin, suunnittelun ja toteuttamisen lisäksi.

 

Projektin hallinta

Kirjassa kerrottiin myös projektin hallinnasta ja siitä, että usein yrityksissä on oma pieni tiimi, joka on vastuusta projektin hallinnasta ja apuna projektipäällikölle ja toimitusjohtajalle. Projektin hallinta tarkoittaa siis projektin suunnittelua, aikataulutusta ja ohjausta kohti projektille asetettuja tavoitteita. Projektin hallinta voi tarjota tuotekehityksen johdolle, eli meidän tapauksessa projektipäällikölle tai business leaderille, työkaluja ja hyviä käytäntöjä toiminnan ohjaamiseen tehokkaasti. Sen tehtävänä on huolehtia, että rajalliset resurssit käytetään tehokkaasti, ja että tavoitteet saavutetaan. Heti tämän luettuamme mieleemme tuli ajatus, että miksi Hurmassa vain yhden ihmisen pitäisi olla vastuussa projektin hallinasta ja erilaisten työkalujen löytämisestä onnistumiseen, sillä siihen voitaisiin muodostaa oma hallintatiimi.

 

Projektin haasteet tuotekehityksessä

Elonen (2000) jakaa haasteet kuuteen ryhmään: riittämättömät projektitason aktiviteetit, resurssien, kompetenssien ja käytäntöjen puute, alhainen sitoutuminen ja epäselvät roolit ja vastuut, riittämättömät projektisalkkutason toiminnot, riittämätön informaation hallinta ja projektiorganisaation hallinta. Avaamme näistä hieman tarkemmin sellaisia mitkä mielestämme voivat olla myös Hurman tulevan yhteisen projektin kompastuskiviä ja joihin kannattaa varautua ja joita täytyy pyrkiä ehkäisemään.

Resurssien, kompetenssien ja käytäntöjen puutteella tarkoitetaan Elosen mukaan riittämättömiä käytäntöjä ja ohjeita projektin suunnitteluun ja johtamiseen, liian laajaa projektitiimiä ja sitoutumispulaa projektiin. Riittämättömiä projektitason aktiviteetteja puolestaan ovat riittämätön esiselvitys ennen projektin aloittamista ja epäsäännöllinen projektin seuranta.

Johdannossa viitattiin haasteeseen, jonka olemme huomanneet Hurmassa ja jonka tiedostamme jo ennen organisaatiorakenteen muutoksien aloittamista. Nämä ongelmat ovat kuitenkin selvästi samat myös isommilla yrityksillä. Eli kuinka sitouttaa kaikki ja löytää kaikille rooli yhteisen tarjoaman kehittämisen ympärille? Haluaisimme uskoa, että täydellinen sitoutuminen olisi mahdollista ilman rooleja. Tällä hetkellä emme kuitenkaan koe sitä mahdolliseksi Hurmassa.

 

Käytännön työkalu tuotekehityksen etenemiseksi

Projektien toteutumista helpottamaan on suunniteltu ns. PC-martiisi (PC= Product Creation), joka kertoo kaikkien päätöksentekopisteiden vaatimukset eri toimintojen suuntaan. Projektin eteneminen kaikissa päätöspisteissä edellyttää muiden funktioiden hyväksynnän ja sovittujen tehtävien valmistumisen ajallaan. PC-martiisia on käytetty esimerkiksi KONE Oyj:n tuotekehitykseen. Se on selkeyttänyt projektien läpivientiä, helpottanut kommunikointia, ja samalla helpottanut projektipäälliköiden tehtäviä toimimalla tarkistuslistana vaadittavista töissä kussakin projektin vaiheessa. (Martinsuo & al. 2003: 64) Uskon, että tämän kaltainen työkalu sopisi myös meille käytäntöön vietäväksi jossain mittakaavassa. Selkeät hyvin johdetut ja seuratut työvaiheet ovat varmasti yksi tekijä onnistuneessa tuotekehityksessä.

 

Suunnittelu vs. kokeileminen

Yhdeksi kirjaksi esseetä varten valikoitui, Kehitä kokeillen: Organisaation käsikirja. Kirjan nimikin jo vihjaa, että malli voisi sopia hyvin Proakatemian ajattelutapaan ja oppimistyyliin. Proakatemialla oppinen tapahtuu useasti juurikin kokeilemisen ja tekemisen kautta.

Me suomalaiset olemme yhdessä asiassa ainakin hyviä, ja se on asioiden suunnittelu. Kulunut sanonta kuuluukin, että hyvin suunniteltu on puoliksi tehty. Suomessa vallitsee suunnittelukulttuuri. (Hassi & Paju & Maila, luku 2.) Myös Proakatemialla usein kuulee, kuinka asioita suunnitellaan, mutta harvemmin lähdetään toteuttamaan. Lähdimme mielenkiinnolla tutkimaan miten teoriassa nämä termit määritellään, ja voisiko kokeilemalla kehittäminen olla se paras tapa Hurman yhteisen tarjoaman kehittämisessä.

 

Suunnitelmalla kehittäminen

Kokeilemalla kehittämisen ymmärtää helposti vertaamalla sitä suunnitelmalla kehittämiseen.

Suunnitteluun perustuva kehittäminen on toimiva lähestymistapa seuraavissa tilanteissa:

  • Projektin alussa tiedetään, mitä tehdään ja mitä projektista seuraa.
  • Projektin alussa nähdään vaiheet ja toimenpiteet, jotka tarvitaan projektin onnistuneen lopputuloksen saavuttamiseksi. Tästä muodostuu projektisuunnitelma. Korostettaessa suunnitelman noudattamisen tärkeyttä, projektin kannalta keskeisimmät päätökset tehdään jo projektin alussa.
  • Projektiin liittyvät epävarmuudet voidaan sisällyttää projektisuunnitelmaan, kunhan suunnittelutyö vain tehdään huolella projektin alkuvaiheessa. Yksi huolellisen suunnittelun toivottu seuraus on, että alkuvaiheen jälkeen tiedetään, mitä ei tiedetä, jotta näihin asioihin voidaan varautua, kun suunnitelmaa lähdetään toteuttamaan. Suunnitteluun liittyy vahva oletus siitä, että toteutuksen aikana ei enää tule esiin sellaisia asioita, jotka pakottavat suunnitelman radikaalin muuttamisen tai sen hylkäämisen.
  • Yllätyksiin voidaan varautua tekemällä varmuussuunnitelmia. Tämä tarkoittaa riskien tunnistamisen lisäksi sitä, että riskien vaikutukset pystytään arvioimaan oikein.

Yhteenvetona voisi todeta, että voimme suunnitella kaiken sen minkä tiedämme. Suunnittelu sopii erinomaisesti tilanteisiin, joissa pyrimme saamaan tuttuja lopputuloksia tutuissa ympäristöissä, esimerkiksi, kun olet jo rakentanut useamman samanlaisen talon. (Hassi ym. luku 2.)

Näiden määritelmien perusteella on helppo todeta, että suunnitelmalla kehittäminen ei ole se paras tapa lähteä suunnittelemaan Hurman yhteistä tarjoamaa. Emme varmasti osaa vielä nähdä mitä ne toimenpiteet ovat, jotka vievät meidät onnistuneeseen lopputulokseen. Myös alalla vallitsevat epävarmuudet ovat vielä hyvin epäselviä. Marraskuussa Hurman yhteisessä innovointipäivässä kirjasimme ylös tulevan tarjoamamme epävarmuuksia, mutta emme varmasti osanneet ottaa kaikkea mahdollista vielä huomioon. Rehellisesti sanottuna emme tiedä ollenkaan mihin olemme ryhtymässä.

 

Kokeilemalla kehittäminen

Epävarmuus on välttämätöntä innovatiiselle toiminnalle. On vaikeaa luoda jotakin aidosti uutta ympäristössä, missä tiedetään tasan tarkkaan, mitkä toimenpiteet johtavat mihinkin lopputulokseen. Innovatiivisia hankkeita yritetään usein saada mahtumaan perinteiseen projektihallinnan muottiin, ja näin epävarmuudelle ei jätetä sijaa.  Kokeilemalla kehittämisen metodi perustuukin siihen, että projekti ja sen lopputulema ovat epävarmuuden peitossa. (Hassi ym. luku 2.)

 

Kokeilemalla kehittäessä prosessille on ominaista:

  • Projektin lopputuleman avoimuus: ennalta ei pystytä näkemään, millaiseksi lopputulema muodostuu ja miten se voidaan saavuttaa.
  • Pyrkimys synnyttää jatkuvasti puuttuvaa, merkityksellistä tietoa. Mitä nopeammin ja pienemmillä resursseilla tähän päästään, sitä paremmin projekti etenee. Projektin lopputulos riippuu siitä, miten hyvin projektissa opitaan ja opittua sovelletaan käytäntöön.
  • Elävä prosessi (iteratiivinen): koska lopputulemaa ei voida ennalta määrittää tarkasti eikä sen saavuttamiseksi voida tehdä yksityiskohtaista suunnitelmaa, ei ole muuta vaihtoehtoa kuin edetä askel kerrallaan. Kokeilut synnyttävät uutta tietoa, joka auttaa näkemään, mitä seuraavaksi pitäisi tehdä, mutta tämä näkyvyys kantaa vain lyhyen matkaa tulevaisuuteen.
  • Reagoiminen projektin aikana syntyneisiin yllätyksiin sitä mukaa, kun yllätyksiä ilmenee. Yllätykset voivat olla sekä positiivisia että negatiivisia, mutta kun ei ole lukkoon lyötyä suunnitelmaa, niihin voidaan reagoida joustavasti. Ratkaisevia päätöksiä tehdään siis sitä mukaa, kun yllätyksiä ilmenee ja niihin tarvittava tieto on saatavilla.

Yhteenvetona voisi todeta, että käytännössä kokeileminen on jatkuvaa, nopeaa ja tarkoituksenmukaista oppimista. Projektin suunta määräytyy sen mukaan mitä on opittu ja kuinka hyvin opittuun tietoon on reagoitu. Avoimuus uusille ideoille ja joustavuus ovat välttämättömiä projektin onnistumisen edellytyksiä. (Hassi ym. luku 2.)

Tämä vahvistaa myös sen mitä jo aiemmin tässä esseessä pohdittiin. Oikotietä onneen ei ole. Ideoita tulee kerätä, tehdä asiakaslähtöisiä tutkimuksia, innovoida yhdessä, ja näin synnyttää koko ajan uutta tietoa. Välillä suuntaa pitää muuttaa. Meidän tulee elää mukana prosessissa, jolla luomme Hurman yhteistä tarjoamaa.  Hurman marraskuisessa innovaatiopäivässä pääsimme todella konkreettisesti kokemaan, kuinka Lego serious play -menetelmän avulla loimme uutta tietoa. Ilmassa oli todellakin epävarmuutta ja päivän aluksi kukaan ei tiennyt mitä tuleman pitää. Päivän lopuksi olimme kuitenkin paljon viisaampia taas sen suhteen, mihin suuntaan Hurman yhteistä tarjoamaa haluamme viedä.

Tämän aiheen loppuun on helppo todeta, että myös teorian tasolla kokeilemalla kehittäminen on ainakin Hurmalle se paras tapa lähteä luomaan omaa tarjoamaa. Lopputulema on vielä pitkään hämärän peitossa. Aika, kokemukset ja se kuinka hyvin yhdessä opimme tulee näyttämään mihin suuntaan Hurma tulevaisuudessa menee.

 

 

 

Lähteet:

 

Martinsuo, Aalto, Artto 2003. Projektisalkun johtaminen – Tuotekehitysprojektien valinta ja strateginen ohjaus. Tampere: Tammer-Paino Oy.

Hassi, Lotta& Maila, Reetta& Paju, Sami(2015). Kehitä kokeillen – organisaation käsikirja (ePub-versio). Helsinki: Talentum pro.

Heuer, Florian 2015. Desingn Thinking in Business and It: Overview, Techniques and Example Workshop.

 

Kommentoi

Add Comment
Loading...

Cancel
Viewing Highlight
Loading...
Highlight
Close