Tervetuloa tuotetiedon koottuihin selityksiin!

Ohessa kokoelma matkan varrelta mukaan tarttuneista tarinoista ja ajatuksista tuotetiedon ja tuotealustan hallintaan, modulaarisuuteen, verkostoihin, geneerisiin tuoterakenteisiin ja tiedonhallinnalla johtamiseen liittyen massaräätälöinti ja lean filosifioita hyödyntäen.

Tietoyhteiskunnassa eläessämme ymmärtämällä luomme innovaatiomme.

Työntämällä tehottomuuteen


Lumi tuli - vihdoin. Ja siinä samassa tietenkin lumityötkin. Kolalla pihaa putsatessa, ajatukset ajautuivat jostain kumman syystä erilaisten prosessiohjausmenetelmien kummasteluun. Varsinkin imu- ja työntöohjauksen sovittaminen ja haasteet tuntuvat välillä mietityttävän allekirjoittanutta, joten seuraavassa lyhyt ajatuksenjuoksu asian tiimoilta...


Ehdin jo aikaisemmin väittämään, että:
Perinteinen vesiputousmallinen tuoteperhelähtökohtainen tuotekehitysprosessi on pahinta työntöohjausta, jossa alussa hetkellisten asiakastarpeiden perusteella pyritään ennustamaan projektien tuotosten istuvuutta muuttuviin markkinoihin.
Vastaavaa tehokkuuteen tähtäävää pakinointia olen ehtinyt jo sivuamaan ainakin pohtiessa, miksi pelkkä tehostaminen ei riitä (50 prosenttia paremmin) tai miksi prosesseissa tiedon hallinnan tasolla on suuri merkitys (Kaksin aina kaunihimpi). Tällä kertaa vedetään välistä, haukutaan työntöohjausta ja perustellaan miksi imuohjaukseen siirtyminen kannattaa aloittaa tiedon hallinnan eksperttien pöydältä.

Työntöohjaaminen on helppoa. Se on tehotonta, mutta helppoa. Täytyy olla prosessi. Karkeakin riittää, kunhan virtaus aloituspisteestä lopetuspisteeseen on tiedossa. Sen lisäksi pitää tietää mitä halutaan kuljettaa ja sitten vaan hommiin. Annetaan pallo ensimmäisellä ja käsketään siirtää eteenpäin kun oma homma on valmis ja näin meillä on työntöohjattu prosessi valmiina.

Vähän kuin tämä oma kolan työntäminen. Tehtävä on selvillä. Lumi pitäisi saada pihasta pois tuonne penkalle. Ei siinä vielä mitään, mutta kun tuo aurinko ei tunnu hoitavan omaa tehtäväänsä sulattaa kasaa sopivaa vauhtia, että saisin uutta tilalle. Kasat senkun kasvavat, puhumattakaan keväästä kun tämä piha pitäisi saada nopeasti kuivaksi ja kasvamaan...


 


Mutta takaisin asiaan... Jos siis prosessi on tehoton, on sen tehostamiseksi kaksi vaihtoehtoa: käsketään ihmisten tehdä asioita nopeammin, tai yritetään muuttaa reittiä alusta loppuun. Yleensä näistä saadaan jotain tehokkuutta irti revittyäkin, jos ei muuta niin työntekijöiden selkänahasta... Paikallaan oleva työntekijähän tekee pelkkää tappiota, vai miten se nyt olikaan...

Työntöohjauksessa vaan on yksi suuri ongelma - ajoitus. Juuri oikeaan aikaan. Työntöohjaus toimii silloin kuin kaikki prosessin vaiheet, ja vaiheiden välit, toteutuvat juuri siinä ajassa kun on suunniteltu - toistuvasti. Yksinkertainen, lyhyt prosessi tai sen vaihe. Silloin voidaan työntää. Valitettavasti vain harva prosessi nykypäivänä pystyy olemaan niin stabiili.
Työntöohjaus on täydellinen vaihtoehto silloin kuin aloittaminen on tärkeämpää kuin maaliin pääseminen.
Mutta kun mietitään, miksi itse asiassa töitä tehdään. Siksi että ne saadaan aloittaa vai siksi että asiakas saa mitä haluaa? Aivan. Meidän pitää siis pystyä ohjaamaan tekemistämme maalista päin. Tehdä asioita juuri oikeaan tarpeeseen. Nähdä mitä minun pitää tehdä prosessin alkupäässä, jotta tarpeen tullessa asiakas saa nopeasti juuri sen mitä halusi.

Väliin varoittava sana. Nyt ei puhuta ennustamisesta vaan siitä, että tiedetään mitä pitää tehdä. Ennustaminen kuuluu työntöohjaukseen, tietäminen imuohjaukseen.

No miten sitten tehdään asioita maalista lähtien? Mikä on työntävän ja imevän prosessin suurin ero? Mitä tarvitsemme, jotta pääsemme pois työntämisestä?
Tiedon hallinta
Kuten jo mainitsin, työntöohjaus on siinä mielessä helppoa, että siinä voi keskittyä vain omaan tekemiseen. Saan pallon tuolta, teen mitä osaan ja annan pallon eteenpäin. Tiedon osalta, minun pitää osata "vain" oma homma ja tietää mihin tulokseni tallennan.

Imuohjaus on huomattavasti haasteellisempaa. Ei siksi, että prosessi olisi haasteellisempi. Se itse asiassa voi olla ihan sama. Ainoa ero on, että nyt minun pitää tietää, ennakoida mutta ei ennustaa, mitä ja koska itse asiassa seuraavassa työvaiheessa tarvitaan minun tuottamaa tulosta. Kyse ei siis sinällään ole yksittäisen prosessin vaiheen tai henkilön tekemisestä tai osaamisesta, vaan vain siitä, että tuolle vaiheelle tuotetaan läpinäkyvästi tieto siitä mitä pitää tehdä, jotta seuraava vaihe voi hoitaa tehtävänsä parhaalla mahdollisella tavalla. Tämän takia imuohjaukseen, massaräätälöintiin, Leaniin siirtyminen tulee aloittaa aina tiedon hallinnan ammattilaisen pöydältä, miettimällä ja muuttamalla tapaa hallita tietoa prosessissa.

_________________________________________________________________________________

ps. Mikä on yrityksen kannalta huonoin työntekijä? - Tyhmä ja ahkera. Tekee paljon, mutta vääriä asioita. Siispä jos teidän kaikki työntekijät ovat ahkeria, mutta laitatte ne tekemään tyhmiä asioita, eikö se tarkoita, että asiat voisi mennä paremminkin...

Mistä on pienet moduulit tehty (osa 3)

Tähän mennessä tapahtunut: On heitetty ilmoille väite moduulikäsitteen ymmärtämättömyydestä, yritetty avata moduulikäsitteen kuvausta (osa 1) sekä haastettu modulaarisuutta kolmella lisäsäännöllä (osa 2). Tällä kertaa yritetään esimerkin turvin perustella miksi liian iso moduuli on huono asia ja mitä väärinymmärryksellä tarkoitetaan.

Siis asiaan... Itseäni on pitkään häirinnyt kysymys: Jos ja kun modulaarisuuden hyödyt ovat niin selvästi kuvattu ja jopa todistettu, niin miksi silti modulaarisuuden toteutukset ovat vielä edelleen puutteellisia ja väärällä tasolla olevia? Itse en halua uskoa osaamattomuuteen, joten syy täytyy löytyä ymmärtämättömyydestä tai ehkä lähinnä väärinymmärryksestä. Yritetään avata asiaa yhden esimerkin kautta.

Eli katsotaan tarkemmin "perinteistä", mielestäni väärin ymmärrettyä moduulia, (jota itse kutsun moduulipalikaksi). Yleensä moduulipalikka on tuotteesta helpohkosti erotettava isohko kokonaisuus, kuten esimerkiksi tämän esimerkin mukainen tehoyksikkö. Koteloon pakattu kokonaisuus, jonka tarkoituksena on tuottaa tuotteen teho-ominaisuus. Oletetaan esimerkin moduulipalikan koostuvan vajaasta parista kymmenestä nimikkeestä. Asiakkaalla olevan mahdollisuus valita neljästä eri teho vaihtoehdosta, minkä lisäksi moduulipalikasta pitäisi löytyä neljää eri kokoa. Toisin sanoen pikaisesti katsottuna hallittavan kokoinen kokonaisuus, rajapinnat löytyvät, variantteja hallittavana 16 kappaletta (4 x 4). Ei paha.

Mutta, mutta... Tarkistellaanpa moduulipalikkaa tarkemmin. Koteloon pakattu kokonaisuus. Voidaan olettaa, että sen valmistuksessa ensin kootaan komponenttilevy, kiinnitetään se ja tehoyksikkö pohjalevyyn sekä viimeiseksi kiinnitetään kansi päälle. Eli moduulipalikan nimikerakenteeksi muodostuu neljä tasoa kuvan mukaisesti. (Kuvassa: SC = stadardikomponentti (kaikissa varianteissa olevat samat osat), SA = alikokoonpano)

Onko tämäkään vielä mikään ongelma? Pari kymmentä nimikettä, neljä rakennetasoa, 16 varianttia, joista neljä asiakkaalle merkittävää ominaisuutta...


Joudutaan vielä vilkaisemaan moduulipalikkaa uudelleen tarkastelemalla tarkemmin varioituvuuden osatekijöitä:
  • Ominaisuuslähtöistä varioituvuutta,
  • Tuotelähtöistä varioituvuutta ja
  • Teknislähtöistä varioituvuutta.
Näistä ensimmäiset kaksi ovat yleensä ainakin osittain läpinäkyviä, kuten esimerkissäkin. Katsotaan...

Ominaisuuslähtöinen varioituvuus eli varioituvuus, jonka kautta asiakkaalle tuotetaan haluttu arvo - ominaisuus. Hinnasto-, valinta ja myyntikonfigurointiasiaa. Kyseisessä esimerkissa siis asiakkaalle tuotettiin neljä valittavaa teho-ominaisuutta. Oletetaan osan D olevan tehoyksikkö, minkä vaikutuksesta komponenttilevyyn liitettävästä osasta A tarvitaan kaksi eri vaihtoehtoa.

Tuotelähtöinen varioituvuus eli varioituvuus, joka suoranaisesti ei tuota asiakkaalle lisäarvoa, mutta on tuotteessa näkyvää kohdistuen kyseiseen moduuliin tai moduulipalikkaan. Usein esimerkiksi kokoon, väriin tai liitettävyyteen liittyvää varioituvuutta. Kyseisessä esimerkissä siis tehoyksikkö / tuote muuten vaikutti kotelon kokoon muodostaen neljä varianttia. Oletetaan osan E olevan kotelo, minkä vaikutuksesta osa C eli aluslevy varioituu kahdeksi vaihtoehdoksi.

Teknislähtöiseksi varioituvuudeksi voidaan katsoa varioituvuus, joka ei suoraan ole kytkettävissä asiakkaaseen, vaan liittyy tuotteen tekniseen tekijöihin. Teknislähtöisen varioituvuuden tekee astetta haastellisemmaksi se, että se juontaa juurensa yleensä toisesta moduulista ja on näin ollen vaikeasti havaittavissa. Kyseisessä esimerkissä oletetaan osan B varioituvan kolmeksi vaihtoehdoksi toisesta moduulista tulevasta tekijästä johtuen.

Eli siis...
Miksi modulaarisuuden väärinymmärrys on merkittävin yksittäinen tekijä, joka estää tällä hetkellä tehokkaiden tuotekehitys- ja toimitusprosessien saavuttamisen?
Syy löytyy oletuksen ja todellisuuden erosta. Eli oletimme, että meillä on modulaarinen tuote, jossa kyseinen teho-ominaisuus (4 varianttia) tuotetaan moduulin avulla, josta löytyy 16 varianttia.

Totuus. Kyseisen moduulista joudutaan tekemään 192 varianttia, sisältäen 54 alikokoonpanoa. Toisin sanoen, jos tämän moduulipalikan alimmalle tasolle tulee muutostarve (esimerkiksi osaan A tai B), tarkoittaa se kyseisen muutoksen lisäksi 246 nimikkeen päivittämistä. Mitä ei tietenkään kukaan ehdi tehdä. Mikä johtaa, ettei tieto välttämättä olekaan aina oikein. Mikä johtaa, että koko verkoston pitää tietää, ettei tieto olekaan aina oikein. Mikä johtaa, että tarvitaan prosesseihin useampaan kohtaa lisätyövaiheita selvittämään ja selventämään mikä on oikein ja mikä ei.

Toiseksi modulaarisuuteen pitäisi liittyä uudelleenkäytettävyys kaikilla tasoilla. Uskallan kuitenkin väittää, että vastaavanlaisen moduulipalikan, johon liittyy mainittuja eritasoisia varioituvuustekijöitä, uudelleenkäytettävyys toisessa tuotteessa on nolla. Samoin hankinnan kannalta moduulipalikan rakennetasoihin liittyvä uudelleenkäytettävyys ei varmasti päätä huimaa, vaikka ehkä teoriassa olisikin mahdollista, jos kyseinen tieto on piilotettu 192 nimikkeen liitosviidakkoon. Ja jos toinen taho olettaa uudelleenkäyttöä modulaarisuuden nimissä ja toinen tuuppaa uutta nimikettä kehiin, ei se voi olla kovin tehokasta.

Ja tällä erää kolmanneksi. Esimerkissä osa B varioitui tuotteessa toisessa kohtaa sijaitsevan ominaisuuden kautta. Oletetaan, että tuohon ominaisuuteen tulee uusi variantti. Kuinka moni yritys osaa väärinymmärretyssä moduuliviidakossa huomioida toisessa kohtaa tehtävän muutoksen vaativan toiseen moduuliin liittyen 83 nimikkeen perustamista?

Tämä tällä erää. Vielä jäi muutama syy-seuraus mainitsematta, kuten miksi tuoteperhekohtainen modulaarisuus on yritystä haittaava tekijä, mutta niistä tuonnempana.

ps. "Oikeaan" modulaariseen ratkaisuun verrattuna, kuinka monta nimikettä kyseisessä esimerkissä on turhaa? ...... 243.

Tuotetiedon Kootut Selitykset 2011

Tervehdys kaikille tänne asti eksyneille.

Joulut, lomat ja vuodenvaihteet on vietetty, joten olisi aika palata bloggailemaan tuotetiedon menoa. Sen verran syksyltä tuli tähän blogiin liittyen positiivista palautetta, että uskaltaudun tarinointeja edelleen jatkamaan. Tarkoitus olisi siis jatkossakin tuupata joku pätkä sunnuntai-iltaisin maailmalle, jos ei muuta niin ainakin omaksi iloksi ja opiksi.

Mutta tätä odotellessa tässä vielä yhteenveto blogin ensimmäisestä neljästä kuukaudesta:
  • Juttuja tuli kirjoiteltua 19. Ainakin itselleni yllättävänkin laajasta skaalasta. Oli modulaarisuutta, tuotteen tietomallia, prosesseja, master dataa, content managementtia, Leania, asiakasasiaa... ainakin...
  • Yksilöityjä kävijöitä neljän kuukauden aikana sivuilla kävi reilut 250, käyntejä oli vajaat 550 ja sivuja katseltiin melkein 1400 kertaa.
  • Muutaman kommentikin sivuille jätettiin. Kiitos niistä. Kuten myös kaikista naamatusten tulleista palautteista.
  • Kaupunkikohtaisesti käyntitilaston voitti Helsinki, Espoon ollessa toinen ja Porin kolmas. Tampere jäi näköjään palkintopallista yhden käynnin päähän.

Artikkelien osalta Top3 oli:

1. Tuotealustaisen tietomallin käsitteet

2. Massaräätälöinti strategisena valintana
 
 
Vastaava Top5 bloggausten osalta näytti olevan:

Lean tuotekehitys
Kärpäsestä härkänen
Asiakas on meille tärkeä...vai onko
50 prosenttia paremmin
Kaksin aina kaunihimpi
(linkki)
 
 
 
 
 
 
 
 
 
 
 
Omaksi iloksi, asiaa hämmentäen...

LinkedIn Facebook Twitter Email Favorites More