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...

Posted in: geneerinen tuoterakenne,modulaarisuus,moduuli,tuotteen tietomalli