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.
Näytetään tekstit, joissa on tunniste modulaarisuus. Näytä kaikki tekstit
Näytetään tekstit, joissa on tunniste modulaarisuus. Näytä kaikki tekstit

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.

Mistä on pienet moduulit tehty (osa 2)

Pahoittelut. Viimeisestä kirjoituksesta on ehtinyt vierähtää tovi, mutta taas mennään...

Palataan takaisin lupaamaani modulaarisuuden maailmaan. Edellisellä kerralla (Mistä on pienet moduulit tehty) heitin kehiin haasteen väittämällä että:
Tehokkaan tuotetiedon hallinnan saavuttamisen suurin este on yritysten moduulikäsitteen ymmärtämättömyys.
Itse moduulaarisuudesta ja moduuleista päästiin perkaamaan tilanteeseen, jossa moduulin pitäisi siis olla:
Standardi rajapinnallinen osakokonaisuus, joka toteuttaa niin teknisesti kuin ominaisuuslähtöisesti yhden erilaisen toiminnon.
Tähän väliin ennen itse asiaa välikommentti. Keskustelin nimittäin muutama viikko sitten eräässä konferenssissa Vaasassa arvostamani konsultin ja PLM ammattilaisen Uutun Ollin kanssa modulaarisuudesta. Olli puhisi samaan ääneen kanssani siitä miten vaikeaa tuntuu olevan ymmärtää, että moduuli voi ja pitää olla muutakin kuin pelkkä tekninen käikäle. Muistakaa ne ominaisuudet...

Ja sitten takaisin. Eli koska mielestäni modulaarisuuden ja moduulin käsitteet antavat liian suuren tulkinnanvaran eivätkä haasta käyttäjäänsä tarpeeksi, olen itse modulaarisuudesta puhuessani korostanut seuraavaa kolmea lisäsääntöä:

1. Moduulin on pyrittävä olemaan mahdollisimman pieni kokonaisuus
Tämä on sinällään helppo ja yksinkertainen sääntö ja tulee jo aikaisemmasta moduulin määrittelystä. Jos ja kun moduulin on toteutettava yksi toiminnallisuus, ei se hirveän iso kokonaisuus tuotteessa voikkaan olla. Pari kommenttia kuitenkin:

Ainakin niissä keskusteluissa, jotka omalle kohdalleni ovat osuneet, tuntuu olevan yllättävän vaikeaa hahmottaa, mikä on yksi toiminnallisuus tuotteessa. Olen enemmän kuin yhden kerran joutunut keskusteluun, jossa joku on aivan tosissaan väittänyt, että traktorin koottu hytti on moduuli ja toteuttaa yhden toiminnallisuuden olemalla hytti. Itse taasen uskaltaisin väittää, että hytti, jossa on kiinni useampi erilainen lisävaruste sekä x määrä erilaisia ohjauslaitteita eri tarkoituksiin + muuta sälää, voi ja toteuttaa asiakkaalle useammankin ominaisuuden...

Ja toiseksi. Väite, että isompia moduuleita on tehtävä helpottaakseen yrityksen tiedonhallintaa, on yksinkertaisesti täyttä puppua. Viittasin tähän lyhyesti aikaisemmassa tarinassa, Liikaa tiedostoja, mutta jos jollain on eriävä mielipide niin mielelläni kuuntelen...

2. Moduulin alla ei voi olla toista moduulia

Tähän tuntuu moni tarttuvan. Miksi ei? Kaksi perustelua:

a) Jos moduuli toteuttaa yhden toiminnallisuuden niin miten moduuleista koostuva moduuli voi tehdä saman? Miksi moduulin yläpuolella pitäisi edes olla toista moduulia?

b) Teoriassa yritys voisi määritellä, että sen moduulien A ja B yläpuolelle "kokonaisuuden helpottamiseksi" tehtäisiin moduuli AB, jolloin moduulin alla olisi toisia moduuleja. Ongelmaksi kuitenkin muodostuu, että yrityksessä tietoa hallitaan määrätyllä tasolla. Useampi tasoinen hallinta (kuten tässä) vaatii tuplamäärän ymmärrystä organisaatiolta. Pitää tietää, että tässä tapauksessa tämän käsiteltävän tason alla onkin lisää moduuleita, lisää rajapintoja, lisää sääntöä, joihin yksittäisessä suunnittelutapauksessa ei modulaarisuuden nimissä saa koskea. Lisäksi moduulipalikka AB on jo todennäköisesti sen verran iso, ettei se suoraan istu toiseen tuotteeseen. Vaaditaan uusi kopio, uusi variantti, johon moduulit A ja B hautautuvat ja alkavat elää omaa elämää. Teoriassa voitaisiin käyttää samoja moduuleita, mutta käytännössä meillä on "same same but different" -moduuleja varasto pullollaan. Tuttuako?

3. Moduulia suuremmat kokonaisuudet pitää pystyä kuvaamaan ”yhdellä nimikkeellä”

Tämä on ensisijaisesti haaste tuotetiedonhallinnan parissa toimiville. Luoda työkalut ja järjestälmä, jotta tämä on mahdollista. Ennen sitä ei kannata liikaa geneerisestä tuoterakenteesta mainostaa. Sinällään yksinkertaista, jos moduulit ja rajapinnat ovat kunnossa, on moduulia suuremmat kokonaisuudet kokoonpanoja. Riittää siis kun on kokoonpano-ohje ja konfiguraattori, joka sylkäisee tiedon, mikä palikka milläkin kertaa kohtaan A laitetaan, jotta asiakas saa mitä haluaa. Uskallankin väittää, ettei tämä itse asiassa vaadi edes suuria investointeja. Palikat teillä jo on, kuhan niitä uskaltaa katsoa vain uusin silmin.

Itse asiassa tässä kohtaa piilee myös modulaarisuuden business case. Vai miltä kuulostaisi, jos jatkossa 200 kokoonpanon sijaan riittäisi tehdä vaikkapa kaksi, tai jos tuotteeseen tulevan muutoksen tekemiseksi riittäisi pelkän moduulin muuttaminen, tai jos moduulit olisivat organisaatiolle oikeasti läpinäkyviä ja uudelleen käytettävissä...


Loppuun vielä. Miten sitten saavutamme modulaarisuuden? Koska tuoteperhettä voidaan sen suhteen sanoa valmiiksi? Ei koskaan. Modulaarisuus on tapa toteuttaa asiakastarpeita. Asiakastarpeet muuttuvat koko ajan. Modulaarisuuden eli kyvyn sekoittaa ja yhdistää tuotteen itsenäisiä ja vaihdettavia osakokonaisuuksia on kyettävä muuttumaan koko ajan. Älä keskity tämän päivän tuotteeseen, huomenna se on jo vanhentunut.

Ai niin, unohdin.
Tuoteperhekohtainen modulaarisuus on yritystä haittaava tekijä.
Tästä tuonnempana...

Mistä on pienet moduulit tehty

Tämän blogin tarkoituksen mukaisesti aloitetaan heittämällä haaste kehiin yhdestä lempiaiheistani, nimittäin modulaarisuuden metsästyksestä...
Tehokkaan tuotetiedon hallinnan saavuttamisen suurin este on yritysten moduulikäsitteen ymmärtämättömyys.
Toisin sanoen, jos mietitään tuotetiedon parissa toimivaa joukkoa, ei moduuli ja modulaarisuus ole enää mikään uusi asia. Päin vastoin, jos omaa tuotettaan ei pidä modulaarisena on mukamas ulkona kuvioista kuin lumiukko. Kyseinen tilanne on vääntänyt yritykset yhtä tehottomaan solmuun kuin JIT/JOT -käsitteen väärät tulkinnat amerikkalaisessa ja eurooppalaisessa tuotannossa.

Näitä "meidän modulaarinen" -tuote keskusteluja on tullut viimeisten muutaman vuoden aikana käytyä useampia ja aina niissä ihmetyttää miten yritykset voivat kuvitella toteuttavansa nykypäivän asiakaskohtaisia tuotteita 10-15 moduulin avulla? Samoin kenen idea on ollut nostaa asiakkaalle esille ihan mainostusta myöten, että osta meiltä sinulle räätälöity tuote, joka meille on standardipalikoista koostuva. Tätä toki itse yrityksenä haluamme näin, mutta kannattaako sitä mainostaa maksavalle taholla? No se on toinen tarina, joka jätettäneen seuraavaan kertaan...

Tällä kertaa oli tarkoitus kirjoitella aivan perusteista, eli mikä on moduuli ja miksi uskallan yllä olevan väitteen kehiin heittää. Eli mikä moduuli siis on? Kirjallisuusmielessä moduuli- ja modulaarisuuskäsitteistä löytyy versioita laidasta laitaan. Näistä voit lukea lisää täältä. Itse olen käyttänyt seuraavia:

Moduuli:
Itsenäinen ja vaihdettava osakokonaisuus, joka toteuttaa tuotteessa tai prosessissa erillisen toiminnon ja jolla on tarkasti määritellyt rajapinnat, joiden kautta luodaan yksilölliset tuotevariantit.
Modulaarisuus:
Tuotteen tai prosessin ominaisuus, joka määrittelee kyvyn sekoittaa ja yhdistää tuotteen itsenäisiä ja vaihdettavia osakokonaisuuksia eli moduuleita.
Näistä mielenkiintoisempi on ilman muuta tuo ensimmäinen eli moduuli, koska sen kun pistää oikeasti määrittelyn mukaiseksi niin jälkimmäinen ominaisuutena tulee kuin varkain mukana. Siis "jolla on tarkasti määritellyt rajapinnat, joiden kautta luodaan yksilölliset tuotevariantit". Tämä on vielä ymmärryksen ja eri yritysten toteutusten suhteen suhteellisen hyvin ymmärretty. Tarvitaan selkeät rajapinnat. OK. Sitten alku: "Itsenäinen ja vaihdettava osakokonaisuus". Vielä OK. "Joka toteuttaa tuotteessa tai prosessissa erillisen toiminnon". Siinä mielenkiintoisimmat sanat: "Erillinen toiminto". Moduulin on siis oltava standardi rajapinnallinen osakokonaisuus, joka toteuttaa niin teknisesti kuin ominaisuuslähtöisesti yhden erilaisen toiminnon. Nyt on ollaan ongelmissa...

Ketään osoittamatta, jääköön esimerkit jokaisen mietittäväksi, mutta suosittelen ensi kerralla kun törmäät oman tai naapuriyrityksen keskusteluissa moduuliin, käyttämään toisenkin hetken ajatukseen: toteuttaako mainittu moduuli oikeasti yllä olevan määrittelyn vai liikutaanko vesillä, jossa tuotetta kutsutaan modulaariseksi vain koska se on trendikästä?

Toki ajatuksen voi kelata myös toisin päin: Meillä on modulaarinen tuote, joka koostuu 15 moduulista. Onko meidän tuotteessa siis oikeasti vain 15 erilaista toiminnallisuutta myynnin ja suunnittelun näkökulmista? Niinpä...

Tämä alkuun. Tarina jatkuu. Pari tarkentavaa määrittelyä vielä mielessä, minkä lisäksi pitäisi varmaan vielä todistaa, miksi väärin ymmärretty moduuli on pahan alku ja juuri. Tulossa on...

Palataan asiaan...

Tuotealustaisen tietomallin käsitteet

Löydät uusimman julkaistun artikkelini "Tuotealustaisen tietomallin käsitteet" täältä.

Tuotealustapohjaisen tiedonhallinnan ja massaräätälöinnin tehokkuuden näkökulmasta katsottuna, on tärkeää määrittää ja ymmärtää vaadittavien prosessien ja toimintatasojen taustalla olevien käsitteiden sisällöt ja olemus ennen kaikkea tuotteen tietomallille kohdistuvan tiedon vaatimusten suhteen...

LinkedIn Facebook Twitter Email Favorites More