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

Lue lisää

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.

Lue lisää

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

3. Tuotteen tietomallin rakenne

 
 
Vastaava Top5 bloggausten osalta näytti olevan:

Lean tuotekehitys

(linkki)

Kärpäsestä härkänen

(linkki)

Asiakas on meille tärkeä...vai onko

(linkki)

50 prosenttia paremmin

(linkki)

Kaksin aina kaunihimpi

(linkki)
 
 
 
 
 
 
 
 
 
 
 
Omaksi iloksi, asiaa hämmentäen...

Lue lisää

Tulevaisuuden haasteita

Maalataan hetki isolla siveltimellä... Missä ollaan? Minne ollaan menossa? - Tässä oma näkemykseni. Tämän takia tiedon hallintaa ei kannata unohtaa menestykseen pyrittäessä...

Kun mietitään Suomen tulevaisuuden menestystekijöitä vallitsevassa globaalissa verkostoyhteiskunnassa, voidaan esille nostaa kaksi merkittävää rakenteellista perustaa: Yritysten kyky innovaatiopohjaiseen kilpailuun sekä kasvavaan verkostomaiseen toimintamuotoon.

Toisin sanoen globaalissa kilpailussa kilpailuetu riippuu nyt ja tulevaisuudessa kyvystä tuottavuuden kasvattamiseen - paremman jalostusarvon saavuttamiseen. Tämä osaltaan voi perustua vain:

1. Yritysten kykyyn alhaisempiin työn ja/tai tuotteiden kustannuksiin,
2. Liiketoimintaprosessien tehokkuuden parantamiseen tai
3. Korkeamman lisäarvon tuottamiseen eli innovaatiopohjaiseen työn tuottavuuden parantumiseen.

Kyseisen tuottavuuden kasvattamisen rinnalla, tai jopa sen takia,  on merkittävää huomioida myös niin tuotekehitystoiminnan kuin tuotannon modularisoituminen yhä hienojakoisempiin eri puolilla maailmaa sijaitseviin elementteihin, jotka ovat tehokkaasti ja joustavasti kyettävä yhdistämään kilpailukyvyn takaamiseksi ja/tai saavuttamiseksi. Kyseisen tehokkaan ja joustavan yhdistämisen onnistumisen perustana ei voida pitää mitään muuta kuin korkealaatuista tiedon hallintaa.

Toisaalta on huomioitava tulevaisuuden kilpailukyvyn riippuvan yhä enemmän siitä, kuinka yritys kykenee kytkeytymään, löytämään ja toteuttamaan asiakaslähtöisiä tuoteinnovaatioita. Tämä osaltaan riippuu yritysten vuorovaikutusprosessien ja tuotekehitysprosessien kyvystä vastaanottamaan ja integroimaan asiakkaiden tuotevalikoimalle kohdistamia tarpeita ja toiveita mahdollisimman nopeasti, tehokkaasti ja joustavasti.

Kyseisiin tulevaisuuden haasteisiin yhdistettynä voidaankin todeta yritysten ja yritysverkostojen tulevan jatkossa kohtaamaan enenevissä määrin painetta liiketoimintaprosessiensa tehostamiseen suhteessa vallitseviin dynaamisiin markkinoihin. Tällöin uusia toimintatapoja mietittäessä esille nousevat ennen kaikkea massaräätälöinnin, Leanin ja Tuotteen tietomallin perusajatukset kyvystä joustavasti hallita ja tuottaa innovatiivisia, yksilöllisiä tuotteita ja palveluja lähes massatuotannon tehokkuudella, kustannuksia nostamatta, kokonaisvaltaisena tuotantoverkostona.

Tulevaisuuden suhteen voidaan pitää liiketoimintaprosessien tehostamisen pääkysymyksenä mahdollisuutta selvitä pienemmällä työmäärällä kuitenkin niin että tuotelaatu, asiakastarpeista tuleva varioituvuus sekä tuoteinnovatiivisuus kyetään säilyttämään ja jopa kasvattamaan.

Miettikääpä kuinka paljon pävittäiseen työhönne liittyy tiedon siirtämistä, tuottamista tai jalostamista. Mitä voisimme tehdä ilman nykypäivän tietotyökaluja? Miettikää miten kyseiset työkalut ovat muuttuneet -90-luvulta. Miksi silti tiedon hallinnan perusteemme ovat edelleen vuosien takaa ja niihin panostaminen lähinnä pakkopullaa ilman ymmärrystä käsillä olevista mahdollisuuksista?

Tämän takia tiedon hallinnalla on merkittävä rooli. Tämän takia siitä kannattaa yrittää saada keskustelua aikaiseksi...

Lue lisää

Arvon tuottamisen vaikeus

Ostaako vai eikö osta? siinä pulma. Nimittäin IPad. Reilu kolmikymppisenä, työn ja arjen puolesta liikkuvana, sosiaalista mediaa hyödyntävänä insinöörinä taidan kuulua kyseisen laitteen kuumimpaan käyttäjäkuntaan. Silti ostopäätös mietityttää. Hyötyjä löytyy, mutta hintakin vähän ahdistaa... Mitenköhän olisi, saisinko rahoilleni vastinetta... Minkälaisen arvon IPad minulle toisi?

Arvo. Yritykset tuottavat tällä hetkellä arvoa asiakkailleen. Ei tuotteita tai palvelua, vaan arvoa. Mutta mitä itseasiassa kyseisen arvon taakse piiloutuu? Miten voimme vaikuttaa arvon muodostumiseen? Entä tiedonhallinta. Miten tiedon hallinta lisää arvoa asiakkaalle vai lisääkö? Miten perustelisin tuotteen tietomallin rahasta ymmärtävälle johtajalle? Mistä siis on kyse...

Siis arvo. Oma näkymekseni on, että arvo vaihtaa onnistuneesti omistajaa silloin, kun myyjän ja ostajan välinen motivaatio arvon siirtymiseksi on tasapainossa. Toisin sanoen asiakkaan ostopäätökselle asettamat tavoitteet kohtaavat myyjän tavoitteet. Lähdetään siis purkamaan kyseistä vaakaa... Miten vaikutamme tasapainoon?

Kun katsotaan vaaan vasenta puolta, voidaan se jakaa kolmeen kokonaisuuteen:

1. Arvo - Mitä asiakas saa? Mitä myyjä saa? -> Mitä toiminnallisuuksia saan, jos ostan IPadin?
2. Erottautuminen - Sen lisäksi, että tuotteella tai palvelulla pitää olla arvoa annettavana, tulee arvon lisäksi vielä erottua muista vaastaavaa tarjoavista tuotteista tai palveluista. Ja tietenkin mielellään positiivisessa mielessä. Harvoin missään tuotteessa tai palvelussa on kaikkea mahdollista arvoa tarjolla. Kyse lienee siis arvon ja erottautumisen funktiosta. -> Miksi IPad eikä Android? Miten nämä eroavat toisistaan minun näkökulmastani?
3. Luottamus - Kolmas ns. positiivisen puolen palikka. Vain parhaana oleminen ei aina riitä, arvon vaihtumiseen vaikuttaa myös ostajan ja myyjän välinen suhde. Jos olisin "Omenamies" valinta olisi varmasti IPad, nyt kenttä on enemmän auki. Luottamus pitää ansaita ja sitä pitää vaalia. Kysykää vaikka Nokialta.

Jos vasen puoli piti sisällään lähtökohtaisesti positiiviset asiat, on vaaan toinen puoli koottu lähtökohtaisesti negatiivisista kolmesta kokonaisuudesta:

1. Hinta - Sinällään hyvinkin selvä asia. Kuka nyt haluaisi itselleen kustannuksia...
2. Panos - Jotta arvoa saadaan luotua vaatii sen tekeminen tai hankkiminen työtä. Myyjällä tuotteen tai palvelun aikaansaaminen vaatii panostuksia ja sama pätee myös ostajaan. Ostajan kannalta on kuitenkin tässä kohtaa huomioitava myös jatkumoa ja luottamusta luotaessa, ettei ostajalta vaadittava panostus ole pelkästään ennen arvon hankintaa tapahtuvaa työtä vaan myös hankittavan arvon todentamiseen kuluva/vaadittava panos kannattanee huomioida.
3. Riski - Kaikkeen liittyy aina omat riskinsä. Toiset ovat valmiita ottamaan suurempia riskejä, toiset haluavat riskinsä minimoitua.

Ja jotta vaaka saadaan tasapainoon pitää tietää kenen suhteen sitä tasapainotetaan. Jokaisella asiakkaalla on omat näkymyksensä, mieltymyksensä ja odotuksensa, joiden ymmärtäminen on tietenkin vaaan tasapainotuksen kannalta kriittistä. Siinä missä toinen näkee kustannukset ja toinen toiminnallisuudet on kolmas enemmänkin tunteen kautta uuden hankkimista lähestyvä asiakas.

Toisin sanoen, haluamme lisäarvoa panostuksella, joka ei ylitä meidän asettamaa tasoa. Lisäarvo on arvoa, erottautumista ja luottamusta. Mutta edelleen lisäarvo hämmentää. Kurkataan toisesta suunnasta. Miten lisäarvo voidaan toiselta kantilta muodostaa? Katsotaan lisäarvoa ostopäätöksen jälkeisestä näkökulmasta...

 

 

Jos mietitään miten IPadin lisäarvo minulle muodostuu sen jälkeen, kun olen sille hetken aikaa saanut leikkiä, voidaan kokonaisuus muodostaa kahdesta palikasta:

1. Arvon takuusta
2. Saadusta hyödystä

Näistä ensimmäinen eli arvon takuu voidaan katsoa olevan myös tuotteen tai palvelun laadukkuutta. Sainko / saako asiakas sitä mitä osti, silloin kuin sen halusi? Toimitustäsmällisyyttä ja laatua. Yrityksen kannalta nyt puhutaan prosessien tehokkuudesta. Tiedämme tilauksen saatuamme mitä pitää toimittaa, kysymys onkin kykenemmekö siihen, toistuvasti?

Toinen osa onkin muuttuvampi. Mitä hyötyjä ostos minulle toi? Nuo voidaan jakaa kolmeen osaan: a) On perusodotukset, mitkä asiakas olettaa, jopa vaatii toteutuvan, b) On aikaisemmin vaaassakin määritelty arvo. Lisä minkä perusteella ostokseen on lähdetty ja on c) Extra-arvo minkä asiakas kokee vasta tuotteen tai palvelun saamisen jälkeen. Ylimääräinen lisä mitä myyntitilanteessa ei osattu ottaa huomioon.

Toisin sanoen, jotta saamme yrityksenä asiakkaan Arvo -palikan korkealle, täytyy meidän kyetä takaaman antamamme arvolupaus sekä samalla tuottaa asiakkaalle hyötyä. No miten tämä kaikki sitten liittyy tiedon hallintaan? Mitä tiedon hallinnalta vaaditaan ympäristössä, jonka strategiana on tuottaa arvoa?

Seuraavassa oma näkymykseni... Korkeatasoiselta tiedon hallinnalta vaaditaan kolmea ominaisuutta onnistuneen arvon tuottamisen kannalta:

1. Oikean arvomäärän tuottaminen juuri oikealle asiakkaalle, vaatii yrityksiltä suurta kyvykkyyttä, suurta ymmärrystä. Pitää kyetä tunnistamaan kaikki asiakkaan arvon tuottamiseen liityvät palaset: Mitä asiakas haluaa? Millä hinnalla? Millä panostuksella? Miten hän kokee riskit? Miten luottamuksen? Miten tuotamme sen mitä asiakas haluaa, muttemme yhtään enempää? Tarvitaa kyvykkyyttä, mutta tarvitaan myös tapa tallentaa kyvykkyyden kautta luotava tieto kaikkien käyttöön juuri oikeamääräisenä informaationa. Harvemmin kun kyseistä arvon tuottamisen kokonaisuutta voidaan yhdessä päässäkään tehdä.

Toisesta suunnasta katsottuna, edelliseen liittyvää dataa taasen on maailma pullollaan. Jo pelkästään yksittäinen yrityskin pullollaan. Datasta vaan ei voi luoda suoraan ymmärrystä. Tarvitaan korkeatasoista tiedon hallintaa tallentamaan dataa juuri oikeaksi määräksi informaatiota tietämyksen kartoittamiseksi ja jakamiseksi koko verkoston käyttöön.

2. Toisaalta kyse on kommunikaatiosta. Täytyy muistaa, että ostamisen helpottaminen on myymistä tehokkaampaa. Arvon tasapaino vaatii selkeää ja suorasanaista kommunikointia asiakkaan ja myyjän välillä. Jos asiakas ei tiedä mitä on ostamassa, jää ostos joko tekemättä tai maksimaalinen arvo yrityksen kannalta saamatta.

Sama pätee myös yrityksen sisällä. Jotta organisaatiosta saadaan kaikki osaaminen irti, on ihmisten saatava puhua "omaa kieltään" ilman rikkinäistä puhelinefektiä. Älä pakota myyjää keksimään asiakkaan tarpeesta muodostuvan arvon teknistä ratkaisua. Kommunikoi tarve oikeana informaationa. Anna suunnittelijan tuottaa tekninen informaatio. Anna asiakkaan tietää, mitä on saamassa rahojensa vastikkeeksi. Se on tiedon hallintaa.

3. Tiedon tuottaminen vaatii resursseja. Resurssit aiheuttavat kustannuksia. Kustannukset vaikeuttavat arvon tasapainoa. Korkeatasoisen tiedon hallinnan tehtävä on poistaa kaikki turha tietotyö. Tästä kirjoittelinkin jo aikaisemmin.

Summa summarum. Arvon tuottamisen tasapaino on mielenkiintoinen kokonaisuus, jonka hallinta on erittäin vaativaa. Se vaatii kyvykkyyttä, osaavia resursseja ja tehokkaita prosesseja, mutta ennen kaikkea se vaatii korkeatasoista tiedon hallintaa päätöksien tueksi.

Tietoa pitää olla juuri oikea määrä. Se pitää olla kommunikoitu juuri oikeassa muodossa. Eikä sen tuottamiseen saa mennä liikaa resursseja.

Lue lisää

Lean tuotekehitys

Lean tuotekehitys - Lean Product Development - LPD - siitä tällä kertaa...

Puhuttaessa Leanin tulemisesta tuotekehitykseen, esille pitänee nostaa kaksi pääaaltoa. Näistä ensimmäisessä aallossa tuotekehitystä käsiteltiin Leanin osaprosessina, eli osana tuotannon Lean filosofiaa. Hiljakseen tuon perinteisen Leanin / TPS:n rinnalle ja päälle on noussut / nousemassa varsinainen Lean tuotekehitys. Edelleen muotojaan hakevassa LPD:ssä pyritään soveltamaan Lean-periaatteita ja Toyotan tuotekehityksen erityispiirteitä omaan tuotekehitykseen ja samalla syrjäyttää perinteistä tuotekehityksen porttimallia ja tuoteperhekohtaista portfolioajatusta.

Itse Lean Product Development:n taustalla voidaan pitää mainittua Lean ajattelua (Lean thinking), joka taasen perustuu tunnetusti tuttuun Toyotan tuotantomalliin (Toyota Production System, TPS). Lean ajattelun on katsottu soveltuvan erityisesti tasaisen kysynnän suurivolyymiseen tuotantoon, mikä osaltaan tuotekehitysmaailmassa luo Leanin soveltamiselle omat haasteensa. Siinä missä tuotannossa varioituvuudesta huolimatta olemassa olevat lähtöpalikat ovat yleisesti ottaen selvillä, kysymyksen kohdistuessa ennen kaikkea laadukkaaseen ja tehokkaaseen toistamiseen, on tuotekehityksen Leanissä huomattavasti enemmän muuttuvia elementtejä. Ehkä tästä syystä vain hyvin harvat yritykset ovat oikeasti onnistuneet Lean tuotekehityksen tuomisessa organisaatioon.

Mentäessä Lean ajatteluun, voidaan se tiivistää:

tuhlauksen ja tarpeettomien tehtävien eliminoimiseksi sekä arvoa tuottavien vaiheiden linkittämiseksi jatkumoksi.

Leanin viisi perusperiaatetta ovat:

1. Arvon määrittäminen - Määritä, mikä lisää ja mikä ei lisää tuotteen ja/tai palvelun arvoa asiakkaan näkökulmasta.
2. Arvovirran määrittäminen - Tunnista kaikki vaiheet tuotteen suunnittelemiseksi, tilaamiseksi ja tuottamiseksi koko arvovirrassa sekä kyseenalaista ja poista kaikki turhat vaiheet.
3. Arvovirran luominen - Varmista arvoa tuottavien toimintojen virtaaminen keskeytyksettä.
4. Asiakasvetoinen prosessi - Tee vain se, mitä asiakas tahtoo, imuohjatusti. (lue lisää)
5. Jatkuva kehittäminen - Pyri täydellisyyteen eliminoimalla jatkuvasti tuhlausta ja kehittymällä.

Mikä Lean tuotekehitys sitten on? Miten sinne päästään? Miten LPD voidaan määritellä? Seuraavassa lyhyesti kaksi alkuaskelmaa matkalle...

Jotta Lean tuotekehitykseen päästään, on alkuun ymmärrettävä LPD:n erilaiset lähestymismahdollisuudet ja niiden erot sekä osattava valita oma lähestymissuunta. LPD:n lähestymismahdollisuudet ovat:

1. Lean Engineering - Lähtökohtana Lean periaatteet, tekniikat ja työkalut. Pyritään tasaiseen virtaukseen, imuohjaukseen, vakioituihin työvaiheísiin ja sykliaikoihin ja niin edelleen. Etuna periaatteessa aloittamisen ja tekemisen helppous, sillä kyseiset tekniikat ja työkalut on useaan otteeseen kuvattu (varsinkin tuotannon osalta) ja ne on suhteellisen helppo oppia ja ottaa käyttöön. Ongelmana kuitenkin ennen kaikkea yrityksissä vallitsevat olosuhteet. Lean Engineering vaatii perustan olemista kunnossa, ja näin ollen soveltuu useimmiten vasta toiseksi tai kolmanneksi askelmaksi kohti LPD:tä.
2. Lean Design - Kokonaisvaltaisin muutos, jossa kyseenalaistetaan ja uusitaan koko tuotekehityksen toimintatapa perusteista alkaen hyödyntäen Leanin ja Toyta Product Development System:n parhaita ja sopivimpia paloja omaan toimintaan. Haasteellisin ja vaikein toteuttaa, koska vaatii korkeatasoisen ymmärryksen ja tahdon muutoksen toteuttamiseksi. Onnistuessaan pohja todella merkittävien liiketoiminnallisten hyötyjen saavuttamiseksi. Menestyksen avain.
3. Lean Development - Lähtökohtana ensisijaisesti tukea toimitusprosessin Leaniä. Keskittyy Lean tekniikoiden ja työkalujen avulla tuottamaan Leaninpiä tuotteita toimitusketjuun. Soveltuu tuotantolähtöisiin Lean lähestymisiin yrityksille, joissa tuotekehityksen rooli on pieni tai joissa itse LPD:n tuleminen on vasta tulevaisuudessa.

Eli alkuun valitse polkusi, mutta muista, ettei oikotietä onneen ole. Jos haluat räjäyttää pankin ja olet valmis siihen, Lean Design on valintasi. Jos tuotannon tekemiset on 1. askel, on syytä lähteä rakentamaan pohjaa Lean Development:n kautta. Jos töitä on jo ehditty tehdä ja olet modulaarisuuden edelläkävijä, tuo Lean Engineering sinulle lisää tehoa ja voimaa.

Toinen aloittamisen edellytys on rakentaa itselle oma LPD-talo. Ymmärtää sen sisältö, nykytila sekä tulevaisuuden kehityspolku. Norsua ei kannata syödä kerralla, mutta kokonaisuus on ymmärrettävä, ennen kuin sen voi paloitella. Ohessa oma talo ja lyhyet kuvaukset rakennuspalikoista.

Jokainen talo pitää rakentaa kunnon perustuksille, niin tämäkin. Jotta ensimmäiset askeleet saadaan tukeviksi tarvitaan pohjalle LPD-taloa tukeva tuotekehityksen filosofia sisältäen ymmärryksen asiakkaasta, korkean vaatimustason sekä johdon tuen tukevan tuotepolitiikan kautta. Tämän päälle luodaan kokonaisvaltainen läpinäkyvyys tukemaan tuotekehityksen toimintaa ja innovatiivisuutta sekä toisaalta korkeatasoinen informaatio ja prosessit pohjan tueksi. Viimeisenä kerroksena perustaan lisätään heijunka - tasoitetaan ja paloitellaan tekeminen samankokoisiksi palaisiksi - moduloidaaan tuote.

Perustuksien päälle voidaan nostaa seinät. Toisena Just-in-time - saatetaan oikeat ihmiset tekemään, oikeita asioita, oikeaan aikaan. Toteutetaan tasainen virtaus heijunkan avulla sekä käännetään perinteinen työntävä tiedon tuottaminen läpinäkyvyyden avulla seuraavaa vaihetta tukevaksi imuohjatuksi prosessiksi. Toiseksi seinäksi taasen Jikado - tehdään kerralla korkeaa laatua, ongelmat ratkoen. Kontrolloidaan tekemistä (Andon) sekä uskalletaan puuttua haasteisiin heti juurisyyt selvittäen ja ongelmat ratkoen. Toteutetaan korkean vaatimustason tavoitteita. Käytetään korkeaa osaamistasoa.

Seinien väliin voidaan luoda sisus. Kaizen - muuta hyvää. Jatkuvana prosessina toisaalta poistetaan seitsemää hukkaa sekä kehitetään prosessia jalkautumalla lattialle (Genchi Genbutsu). Ja toisaalta kasvatetaan osaamista, tietämystä ja joukkuehenkeä.

Ja kuin pisteeksi iin päälle, voidaan nostaa talolle katto. Visio, stretegia ja tavoite. Asiat, joita tavoitella ja joihin halutaan tähdätä. Se mihin sitoudumme ja mihin haluamme yhdessä päästä.

Tästä itse lähtisin Lean tuotekehitystä rakentamaan. Miten sinä tekisit...

Lue lisää

Kaksin aina kaunihimpi

Olen näillä sivuilla ehtinyt jo hämmästelemään ja kummastelemaan erinäisiä asioita, mutta ainakin yksi pitää vielä lisätä joukkoon, nimimittäin prosessien ja tiedon hallinnan omat kuppikuntansa. En tiedä onko syynä yritysten organisaatiorakenteet vai ihmisten osaamiskyky, mutta olen aina ihmetellyt sitä, miten yritykset sisältävät omat joukkonsa liiketoimintaprosessien kehittämiselle ja tiedon (yleensä työkalulähtöisen) hallinnan kehittämiselle. Pahimmassa tapauksessa kyseiset kuppikunnat on vielä jaettu organisaatiolähtöisestikin. On tuotannon ja tuotekehityksen omat prosessikehitystiiminsä. On ERP-tiimi, PDM-tiimi, myyntityökalujen tiimi ja niin edelleen. Ja kuin pisteeksi iin päälle, saman kaksiajaon voi haistaa myös useimmissa seminaareissa, joissa kyseisten tiimien ammattilaiset iskevät päänsä yhteen.

Suurin ongelma yritysten kehityshankkeiden onnistumisen kannalta on niiden käynnistäminen organisaatiolähtöisesti, organisaatiokohtaisten hyötytavoitteiden siivittäminä, ilman yhteyttä kokonaiskehitystavoitteisiin.

Yleensä noissa tiimeissä olevat henkilötkin ovat tiimeytyneitä. Prosessikehitystiimi sisältää joukon prosessilähtöisiä osaajia, joille prosessi on se "juttu" ja data vain tarpeellinen prosessin sivutuote. Prosessimiehelle tiedon hallinta ei ole kiinnostava asia, sillä kaikki tiedot ovat peräisin prosessista. Joten jos prosessi on hyvä, on tuotettu tietokin hyvää.

Vastaavasti datamiehen silmissä loistaa ikuinen liekki puhuttaessa tiedon tuottamisesta, keräämisestä, eheydestä tai laadusta. Datamiehelle tieto on niin kriittistä, että on täysin hyväksyttävää sisällyttää turhia vaiheita prosessiin, jotta saavutetaan haluttu tiedon taso.

Se mikä tekee kyseisen asetelman vielä haasteellisemmaksi, on johdon näkökulma. Halutaan tehdä asioita, prosesseja, nopeammin, tehokkaammin ja laadukkaammin. Mikä on ihan ymmärrettävää, mutta... Nyt kaikki prosessien kehittäjät huomio: Ilman korkeatasoista informaatiota, korkeatasoisten prosessien luominen on mahdotonta. Laadukas informaatio on edyllytys laadukkaille liiketoimintaprosesseille. Ja tietenkin sama teille tiedonhallinnan ammattilaiset: Huipputulokseen pyrittäessä, korkeatasoisella informaatiolla ei yksinään tee mitään, jos ei yrityksen prosessit kykene kyseistä informaatiota hyödyntämään.

No se mitä korkeatasoisella informaatiolla sitten tarkoitetaan tai miten sinne päästään, on toinen tarina. Ehkä näiltä sivuilta voit jonkun vinkin matkaan löytää...

Kokonaisvaltaisen liiketoiminnallisen tehokkuuden saavuttamiseksi:
1. Tiedon laadun on oltava korkeatasoista
2. Prosessien on kyettävä hyödyntämään tietoa tehokkaasti

Pari tosielämän esimerkkiä, johon ehkä itsekin olet törmännyt:

• Tuotannossa tehtiin mittava tuotantotapauudistus. Valitettavasti kukaan vaan ei kehityksessä huomioinut myynnin ja tuotekehityksen tuottamaa dataa. Kehitetty prosessi oli hieno, ongelmana vaan oli, että tuotantoon tullut input esti prosessin tehokkaan käytön.
• Yritys otti käyttöön uuden PDM-järjestelmän. Käyttöönoton yhteydessä olemassa oleva data ja datamalli muokattiin uusiksi. Valitettavasti uusittua datamallia ei kuitenkaan yhdistetty olemassa oleviin prosesseihin, mikä ryvetti tiedon ja jätti uuden työkalun vähällä käytölle.

No miten se sitten pitäisi tehdä... Seuraavassa askeleet onneen:

1. Määritä tarvelähtöisesti toimintatapojen kautta juurisyyt. Mihin haluamme? Mitä sinne pääseminen vaatii? Mitä meidän tulee muuttaa?

2. Kaivamalla juurisyyt esille törmäät informaatioon ja sen laatuun. Input:hin ja output:hin. Määritä, uudista tiedon hallinta. Luo pohja tuotteen tietomallille datan masteruuden, modulaarisuuden ja tuotealustan kautta. Informaation laatu on päätöksien pohjana olevan tiedon oikeellisuutta, ajankohtaisuutta ja täydellisyyttä. Vaadi ja muutu.

3. Optimoi työympäristö uuden tiedon hallinnan vaatimusten mukaiseksi. Laita työkalut kuntoon.

4. Siirrä uudistettu ympäristö toimintamalleihin ja prosesseihin. Muista jos teemme niin kuin olemme aina tehneet, mikään ei muutu. Prosessien tehokkuus on kykyä reagoida asioihin nopeasti ja täsmällisesti. Ymmärrä kokonaisuus. Luo tuotteen tietomalli.

Tämä tältä erää... Ja joo... On toki olemassa myös joukko ihmisiä, jotka eivät ​​usko "dataan" tai "prosessiehin" alkuunkaan. Luultavasti suurin osa meistä. Mutta jos olet päässyt näin pitkälle tässä tarinassa, et ole yksi heistä.

terveisin,
prosesseihin hurahtanut tiedonhallintanörtti

Lue lisää

Sisällön verran asiaa

Toissa viikkoisen onnistuneen ECM & Document Management konferenssin innostamana aloin tarkemmin miettimään monimuotoisen sisällön hallinnan roolia tai roolittomuutta niin yritysten prosessikehityksen kuin PLM arkkitehtuurin kannalta. Näistä bloggauksia tuonnempana, mutta jotta niihin päästään piti pää laittaa ensin järjestykseen itse Enterprise Content Management -termin osalta. Seuraavassa siis sisällön verran ECM:n pohdintaa PLM / PDM / tiedon hallinta / konepajamiehen saappaista...

Enterprise Content Management (ECM) is the strategies, methods and tools used to capture, manage, store, preserve, and deliver content and documents related to organizational processes.
ECM tools and strategies allow the management of an organization's unstructured as well as structured information, wherever that information exists.

Mikä ero sitten on IM:llä ja ECM:llä? Oma mielipide... Siinä missä Information Management:ia (IM) voitaneen pitää toimintatapana, joka keskittyy tehostamaan organisaation kykyä ylläpitää, kehittää, jakaa, tallentaa, soveltaa ja hyödyntää tietoa niin, että oikeat tiedot saavuttavat oikeat ihmiset oikeaan aikaan, lähestyy ECM samaa asiaa enemmän sisältölähtöisestä näkulmasta. Toisin sanoen siinä missä IM keskittyy tietoon toimintatapa ja prosessilähtöisesti, on ECM enemmän liikkeellä organisaatiossa olevan tietokokonaisuuden, sen olemassa olon sekä sen hallitsemiseen tarvittavien työkalujen näkökulmasta.

No mitä ECM sitten sisältää tai tulisi sisältää?

Document Management (DM). Perinteisin, isoin kokonaisuus, joka sisältää niin kuin nimikin sanoo... no... dokumentit. Wordien, Excelien ja PowerPointien rinnalla tässä mainittakoon CAD-data mallineen ja piirustuksineen. Dokumenttien hallinasta puhuttaessa mukaan pitänee ottaa ainakin dokumenttien tallennus, versiointi, metadata, workflow, käyttöoikeus ja haku kysymykset.

Records Management (RM). Historiatieto. Arkistointi. Tiedon elinkaareen liittyvät kysymykset vastaten ennen kaikkea sisällön säilyttämiseen ja hävittämiseen liittyviin menettelytapoihin ja käytäntöihin. Yhtenä mielenkiintoisena kokonaisuutena esille nostettakoon sarjanumeroihin liittyvän kokonaisuuden hallinta.

Knowledge Management (KM). ECM kokonaisuuden abstraktein palikka, johon liittyy paljon myös hiljaisen tiedon hallintaa (mikä sinälleen menee mielestäni ohi ECM kokonaisuuden). Knowledge Management -termiä ehkä käytetään nykypäivänä vähän joka asiassa, mutta ECM:ään sen yhdistäessä liittäisin mukaan sisällön kautta tavoiteltavan oppimisen, suorituskyvyn, kilpailuedun ja innovatiivisuuden parantamiseen liittyvät sisällön hallinnat, jotka eivät muuten istu muihin kategorioihin. Yhtenä mielenkiintoisena kokonaisuutena tähän kategoriaan liitettäköön tuotepolitiikkaan liittyvien ja lähtevien sisältökysymysten hallinta. (tuotepolitiikka)

Modular Content Management (MCM). Itselleni rakkain kokonaisuus. Dokumenttien hallinnan pohja, jonka olisi syytä alkaa kovaa vauhtia ottamaan valtaa pois kokonaisilta dokumenteilta. Käytännössä vastaa pilkottujen dokumenttiosien hallintaan liittyviin kysymyksiin. Parina esimerkkinä mainittakoon: TactonWorks:n kaltaisten piirtokonfiguraattorien hyödyntäminen suunnittelussa sekä moduuleista koottavien tarjousdokumenttien luonti. Käytännössä siis pilkotaan perinteiset dokumentit modulaarisuussääntöjen mukaisiin osiin sekä luodaan koonta ja hallinta säännöt ja menetelmät. Paljon potentiaalia ilmassa...

Digital Asset Management (DAM). Document Management:iin verrattava kokonaisuus, joka sisällön erityispiirteiden eroavaisuuksista johtuen kannattaa hallita omana kokonaisuutena. Sisältää kuvien, videoiden ja äänen kaltaisen sisällön hallinnan. Mainittakoon kaksi tähän kategoriaan liittyvää erittäin mielenkiintoista osakokonaisuutta:

• Tuotevisualisointi. Kasvava tarve hyödyntää 3D dataa asiakassuuntaan videoiden ja kuvien muodossa.
• Videoiden modulaarisuus. Liikkuvan kuvan rooli esimerkiksi käyttöohjeistuksessa on kasvamassa, mikä jo kielikäännösten hallinnan kannalta luo (kuten dokumenteissa aikoinaan) suurta painetta Modular Content Management:n suuntaa.

Social Content Management (Social Media). Uuden polven kasvava sisällön hallinnan kokonaisuus. Teille, jotka vielä kyseenalaistavat... Kaksi syytä, miksi suosittelen opettelemaan:

• Sähköpostin väärinkäyttö aiheuttaa suurta tehottomuutta sisällön hallintaan. Jotta tuo Hukka saadaan taklattua tarvitaan uusia työkaluja, jotka käytännössä tulevat sosiaalisen median seasta.
• Seuraavaksi työelämään ponnistava sukupolvi ei enää tunne perinteistä dokumenttia tiedonvälityksen työkaluna. Facebook-sukupolvi tulee, oletko valmis.

Web Content Management (WCM). Itselleni tuntemattomin kokonaisuus, joka vastaa Webin sisällön vaatimiin kysymyksiin ylläpidosta, kontrolloinnista ja sisällön muutoshallinnasta. Tiedon jakamiseen liittyvissä kysymyksissä nykypäivänä erittäin merkittävässä roolissa.

Tämä tällä kertaa... Niin kuin tuli mainittua, blogin verran löytyisi vielä raapustettavaa liittyen ECM:n rooliin prosesseissa ja arkkitehtuurissa, mutta niihin palattakoon myöhemmin. Loppuun kuitenkin vielä kaksi pähkinää purtavaksi...

Nimikkeen rooli sisällön hallinnassa. Onko nimike oma sisältökokonaisuutensa, joka puuttuu ympyrästä vai miten nimike tulisi nähdä osana sisällön hallintaa? Puhutaan nimikkeistämisestä... Puhutaanko siis tämän ympyrän yläpuolella, alapuolella vai mahdollisesti vain yhdistävänä metadatan osana? Onko nimike tuotetiedon ydin vai työkalu? Tähänkin palattakoon myöhemmin... Ja se toinen... Pistäkää ylös...

Sisällön hallinnan Top3 trendiä vuodelle 2012

1. Tuotevisualisointi. 3D-mallien laajempi hyödyntäminen niin asiakasdokumentaatiossa, tuotannossa kuin toimittajayhteistyössä.
2. Sosiaalinen media. Tuotekehitystä huoneessa, jonka seinään pääsee kirjaamaan omat kommentit. Ja kaikki siis virtuaalisena...
3. Knowledge Management. Paljon puhetta, vähän tuloksia...

Lue lisää

50 prosenttia paremmin

Nyt kun kuluva vuosi alkaa olla kohta taputeltu, on aika siirtää katseet ensi vuoteen, uusien budjetti-, strategia- ja tavoitekeskusteluja myötä. Sinällään keskustelujen sisältö on jälleen se sama tuttu: kaikki pitää tehdä vuonna 2012 vähän paremmin, kustannuksia säästäen ja tehokkuutta nostaen.

Sinällään tehokkuuden nostamisessa ei ole mitään pahaa. Suomalaisen teollisuuden pelastamiseksi parannusta onkin saatava aikaan (ja pian), mutta se mikä asiassa on meikäläistä viime vuodet kummastuttanut, on se miten tehokkuusvaatimuksia kohti hyökätään läpät silmillä kuin ravihevoset konsanaan. Tuntuu, ettemme näe kuin olemassa olevat, ne tutut ja turvalliset, prosessit, joiden tehostamiseksi yritämme viilata viimeisetkin voit pois leivän päältä.

Many shall receive advice, but only the wise will profit by it.

Toki välillä prosessien tehostamiseen löydämme uusia ismeja, sellaisia kuten tällä hetkellä kuumana pyörivä Lean tuotekehitys (Lean Product Development (LPD)), mikä itsessään on jälleen erittäin hyvä asia. Se vaan mikä mielestäni näissä uusien tuulien tuomisessa yrityksiin menee metsään, on mainitsemani prosessien ja oman tekemisen kriittinen arviointi. Lean filosofia sisältää joukon loistavia, suhteellisen helppotajuisia työkaluja, joiden kautta menestykseen on mahdollista pyrkiä ja päästä. Ongelma vaan on se, että matkasta unohtuu liian helposti se tärkein ja samalla myös vaikein, eli kyky nähdä omat tekemiset tarpeeksi kriittisesti.

Siinä missä uutta kehittäessämme on uuteen siirtyminen kyettävä perustelemaan, on vanhassa pysymiseen oltava kaksinkertaisesti perusteltu.

Otetaan esimerkiksi Leanin yksi peruspilari Hukan poisto. Loistava, helppo työkalu / toimintatapa, jonka tuominen nykyisiin tuotekehitysprosesseihin, joissa ennemminkin hukutaan hukkaan kuin painetaan hukatta eteenpäin, on helppoa ja antaa helposti ensimmäisen tason tuloksia. Noita "matalalla roikkuvia hedelmiä", jotka toki kyllä antavat tehostusbuustin prosesseihin energiajuoman tavoin, lyhyeksi aikaan. Mutta... Jos hukasta siivottava prosessi ei alun perinkään tue optimaalisesti toimintaamme, onko sen tekemisestä nopeammin meille oikeasti se hyöty mitä todellisuudessa haemme?

Tärkeämpää on saattaa oikeat ihmiset tekemään, oikeita asioita, oikeaan aikaan, kuin tehdä joku nykyinen prosessin vaihe nopeammin.

Niinpä... Kriittisyyden löytäminen omaan tekemiseen ei aina ole helppoa. Miten siis löydämme oikean vaatimustason? Miten kykenemme nostamaan prosessimme uudelle tasolle?

Itse olen käyttänyt, olisiko ollut aurinkokuninkaalta Ylen kisastudiossa aikanaan kuultua fraasia muokaten: 90% keskittyminen (vaatimustaso) antaa 50% tuloksen. Toisin sanoen prosessien tehostamiseksi on kehitys jäsenneltävä kahteen ryhmään:

• perinteiseen jatkuvaan olemassa olevan parantamiseen sekä
• isompaan askeleen ottoon (100% vaatimukseen), jonka tavoiteasetannassa ollaan oikealla tasolla silloin kuin tavoitteen ensimmäinen reaktio on: Ei onnistu.

Silloin asetamme itsemme vaatimustilaan, jossa jo asetanta vaatii meiltä uutta näkökantaa. Ja.. Kyllä. Prosessien isot askeleet eivät ole demokratiaa, vaan vaativat omat pioneerinsa.

Loppuun muutama tavoite ensi vuodelle:

• Suunnittelemme markkinoille. Jatkossa tuotekehitysprojekteissa myyntihinnasto on valmis ennen suunnitteluvaiheen alkamista.
• Haluamme olla esillä. Tuotamme jatkossa kaksi kertaa enemmän tuotelanseerauksia vuodessa.
• Tilausten muutokset maksavat liikaa. Tilauksen iskupiste / freezing point siirretään lähemmäs toimitushetkeä niin, että pisteen jälkeiset muutostarpeet vähenevät 75%.
• Aika on rahaa. Tilauksen todellinen toimitusaikaa pudotetaan neljännekseen nykyisestä.
• Alle 25 varaston kiertonopeus ei ole tavoite vaan selittelyä. Ylitämme sen.

Emme pärjää tekemällä asioita niin kuin muutkin. Suomalainen edelläkävijyys on osaamisessa. Osaaminen ei elä paikallaan. Nostetaan vaatimustasoa. Etsitään uutta. Pidetään teollisuus Suomessa.

__________________________________________________________________________________

ps. Ai mitä mieltä olen Lean -sanan liittämisestä kaikkeen mahdolliseen... No, ei kai nimi asiaa pahenna, jos vaan ymmärretään, ettei myöskään itse sana tuo onnea.

Lue lisää

Asiakas on meille tärkeä...vai onko

Olemmeko tottuneet ajattelemaan markkinoita tai asiakkaita oikeasti tarpeeksi kurinalaisella tavalla? Tiedämme joidenkin tuotekehitysprojektien onnistuvan ja toisten epäonnistuvan, mutta todellisten syiden kaivaminen esille tuntuu olevan liian monimutkaista ​​ja syyt meille arvaamattomia. Tyydymme helposti tilaan, jossa meidän mukamas tarvitsee vain tuottaa tuoteet ja asiakkaat tulevat niitä ostamaan. Ja jos eivät osta, niin sehän on vaan asiakkaiden ymmärräksen puutetta...

Yritykset keskittyvät tyydyttämään omia tavoitteitaan ennemmin kuin asiakkaidensa todellisia näkökulmia.

Asiakaskohtaisuus. Asiakkaan huomioiminen. Asiakaslähtöiset varioivat tuotteet. - Tuttuja sanoja, jotka on helppo lisätä esityksiin ja osavuosikatsauksiin, mutta joiden toteuttaminen "aikuisten oikeasti" ei aina olekaan niin helppoa kuin pensselillä maalattu ylätason tavoite. Mitä siis asiakaslähtöisellä kehityksellä tarkoitetaan? Mitä sen toteuttamiselta vaaditaan? Mitä asiakaslähtöinen kehittäminen onkaan syönyt sisäänsä?

Ennen kuin päästään itse teeman saloihin, pitää ottaa askel taaksepäin ja heittää kehiin päivän haaste:

Perinteinen vesiputousmallinen tuoteperhelähtökohtainen tuotekehitysprosessi on pahinta työntöohjausta, jossa alussa hetkellisten asiakastarpeiden perusteella pyritään ennustamaan projektien tuotosten istuvuutta muuttuviin markkinoihin.

Toisin sanoan tehdään pitkiä, isoja tuotekehitysprojekteja, joissa projektien alussa määriteltyjä, sen hetken asiakaskyselyiden vastauksia, pyritään viemään ja viestimään osajoukolta toiselle kuin rikkinäisessä puhelimessa konsanaan. Ei hyvä.

Nykypäivän asiakas- ja tehokkuusvaatimuksiin päästäkseen varioivia tuotteita valmistavien yritysten onkin pyrittävä suoraviivaisesti siirtymään kohti tuotteen tietomalliin pohjautuvaa tiedon hallintaa ja Lean / massaräätälöinti filosofiaan pohjautuvaa tuotekehitystä (Lean Product Development (LPD)). Yksi osa kyseiseen tasoon pääsemiseksi onkin todellisen asiakaslähtöisen kehittämisen liittäminen osaksi kokonaisvaltaista tuotekehitysprosessia.

Tutkimusten mukaan todennäköisempi syy tuotekehitysprojektien epäonnistumiselle on tuotteiden kohdistuksessa tapahtuvat virheet kuin tuotteen tekniset epäonnistumiset. Tähän liittyen onkin kummallista, miten jokaiselta yritykselta löytyy kyllä tuotteen teknisen suunnittelun prosessit kuvattuna, mutta vain harvalta tuotteen tarvevaatimusten hallintaan suunnatut prosessit.

Täytyy kuitenkin muistaa, että uuteen tähdättäessä motivaattorina voi toimia:

• teknologia-lähtöinen uudistaminen,
• asiakaslähtöinen uudistaminen tai
• tilaisuuteen tarttuminen.

Kuinkakohan monta noista voidaan nykypäivän nopeusvaatimusten mukaisesti tunnistaa ja toteuttaa ilman asikaslähtöisen kehityksen hallintaa?

Lopettakaa myyminen, aloittakaa kuunteleminen.

Myykää ominaisuuksia, ei teknisiä ratkaisuja.

Mitä asiakaslähtöiseen kehitysprosessiin sitten sisältyy? Mitä minun tulee huomioida? Ohessa neljä seikkaa, jotka itse nostaisin esille ja joiden huomioiminen jokapäiväisenä prosessina on erittäin tärkeää, jotta asiakas saadaan oikeasti osaksi tuotekehitysprosessia.

1. Mene ulos
a) Asiakastarpeet löytyvät vain ymmärtämällä asiakasta, ei firman seinien sisältä. Lähesty asiakasta, keskustele, haista ja ymmärrä.
b) Muista, että asiakastarpeet voidaan jakaa kahteen ryhmään: subjektiivisiin ja objektiivisiin. Näistä subjektiiviset vaatimukset ovat asiakkaiden esittämiä toiveita, kun taas objektiivisia voidaan pitää asiakkaiden todellisina tarpeina. Pelkkä kuunteleminen ja kysyminen ei siis riitä.
c) Vältä "rikkinäistä puhelinta". Mitä hyötyä on, jos projektipäällikkö kuuntelee asiakasta, mutta itse toteuttaja ei moista ole koskaan nähnyt? Pyri lähentämään suunnittelijaa ja asiakasta lähemmäksi toisiaan ymmärryksen kasvattamiseksi.

2. Määrässä ei ole voimaa

Asiakaslähtöisen kehityksen tavoitteena ei ole tuottaa suurta määrää valintoja, vaan modulaarisuuden kautta oikeat asiat oikealle kohderyhmälle. Luokittele, ryhmittele, kohdista. Tätä kutsuttaneen tuoteportfolion hallinaksi.

3. Reagoi oikeisiin asioihin
Asiakaslähtöinen kehitys vaatii koko organisaation osaamisen tuomista esille. Kyse ei ole myynnin prosesseista tai tuotekehityksen konseptointivaiheesta. Onnistuneeseen asiakaslähtöiseen kehittämiseen pitää eri tahojen pystyä tuomaan esille oman osaamisalueensa tiedot. Näiden kautta asiakaslähtöisen kehitysprosessin tehtävänä onkin nostaa yrityksessä oleva informaatio ymmärrykseksi, oikeiksi valinnoiksi. Osaamiseksi. Reagoinniksi oikeaan aikaan, oikeaan asiaan.

4. Opi jatkuvasti

Asiakastarpeiden hallinta on jatkuva prosessi siinä missä tuotteen tekninen jatkuva parantaminenkin. Oma JP / ECM prossessi tulee olla olemassa.

Näin tällä kertaa. Itse keinoihin ja tekoihin tuonnempana, mutta sitä ennen...

Asiakaslähtöisellä kehittämiselle, ja ennen kaikkea sen osaamiselle, on tilaisuus päällä. Mielestäni sen hallinta voi oikeasti nostaa yrityksen edelläkävijäksi. Toisaalta asia ei ole niin helppoa kuin kuvitellaan. Pelkkä asiakaslähtöisyyden maininta tai satunnainen myynnin palaute ei vielä tuo asiakasta todelliseen prosessiin. Asiakaslähtöinen kehittäminen vaatii omistautumisen ja ammattilaisensa, mutta se voi palkita paremmin kuin arvaattekaan.

Toiseksi. Olen merkinnöissäni tullut korostaneeksi, ettei tärkeintä ole liike, vaan ymmärrys suunnasta. Niin nytkin. Pahempaa kuin olla huomioimatta asiakasta on kuvitella ymmärtävänsä sitä.

Lue lisää

Kärpäsestä härkänen

En ymmärrä. Taas meni pieni pää ihan sekaisin... Olen tämän viikkoista bloggausta varten yrittänyt selvittää mitä tarkoittaa Master Data Management? Paljon puhutaan, mutta miten olla tai päästä MDM:n edelläkävijäksi? Mitä itseasiassa termillä tarkoitetaan? Mitä pitää tehdä, jotta kolmikirjaiminen lyhenne tuottaa oikeasti menestystä? Ja ennen kaikkea mikä ei ole Master Data Managementia? Jouduin suohon...

Jo lyhyt googlauksen hakutulosten tarkastelu todisti, että Master Data Managementilla voidaan tarkoittaa ihan mitä tahansa tiedon hallintaan liittyvää perusasiaa, kuhan siihen vaan lisätään mukaan sana "laadukas". "Yrityksemme tarjoaa teille laadukkaaseen master datan hallintaan tähtääviä palvelua" löytyy aika monelta sivulta. Tällöin puhutaan: datan haltuunotosta, jalostamisesta, muokkaamisesta tai laadun varmistuksesta. Data voi olla myyntidataa, tuotantodataa, asiakasdataa, sisäistä dataa, ulkoista dataa, sitä dataa tai tätä dataa. Mutta tämän jälkeen se on laadukasta ja sillä saavuttaa merkittäviä liiketoiminnallisia hyötyjä. Tiesittehän, että nykypäivänä tiedolla on suuri merkitys yrityksenne tehokkuuteen... Ai jaa, ihan tosissaanko!!!

Ja sitten löytyy artikkeleita ja blogikirjoituksia, joissa kaikissa kerrotaan asiantuntevasti, mitä Master Data Management on. Ja paljon näyttää löytyvänkin. Ongelma vaan tuntuu olevan samaa sarjaa kuin modulaarisuuden ja Lean määritysten kanssa. Asiasta on niin monta ympäripyöreää kirjoitusta, että on mahdoton tietää / löytää kirjoitusta, joka oikeasti haaastaisi miettimään ja toisi esille ne tekijät, joiden avulla MDM:llä saavutettaisiin todellista kilpailuetua. Vai mitä mieltä olette? Ymmärrän sen, että jos yrityksessä on tiedon hallinta täysin retuperällä, on perusteista lähdettävä liikkeelle, jotta päästään mukaan keskinkertaisuuden massaan, mutta miten sieltä nousta muiden yläpuolelle? Voiko MDM:ssä edes olla muita parempi? Miten MDM istuu muiden kolmikirjaimisten tiedon hallinnan lyhenteiden soppaan? Tarvitseeko se oman järjestelmänsä voi voiko se olla osa esimerkiksi PDM:ää? Pitääkö sen olla osa PDM:ää?

Eipä siis tullut vastauksia lyhyen tutkimisen pohjalta, joten käännyin tutun tahon puoleen ja aloin selailemaan Modultekin blogin kirjoituksia. Itseasiassa juuri Modultekin kautta olen ensimmäistä kertaa törmännyt Master Data Management -käsitteeseen, joskus 2006-2007.

Päädyin lueskelemaan Maijasen Jannen MDM-blogikirjoituksia. Janne listaa kolme MDM-järjestelmän perusvaatimusta, joihin on helppo yhtyä:

Integrointi. Ilman muuta. On kai järjetöntä kuvitella, että olisi yksi paikka, jota kaikki käyttäisivät tiedon lukemiseen ja käsittelyyn. MDM-järjestelmän täytyy olla integroitu käyttäjien "työpöydälle". Sen pitää olla käyttäjän taustalla oleva musta möykky, joka omii ja jakaa kaiken tiedon, silloinhan se on datan master paikka. Tätä varten tarvitaan myös standardien hyödyntämistä ja ymmärrästy, jotta data saadaan integraatioissa kulkemaan työkalujen ja käyttöliittymien välillä.

Laadunvarmistus. Ilman muuta. Huonolla tiedolla ei tee yhtään mitään. Tiedon pitää olla laadukasta. Pitää tietää kuka sen omistaa, millä prosessilla sitä käsitellään ja mitä siltä vaaditaan. mistä data tulee ja mihin se menee. Prosessit pitää olla kunnossa (ja tiedossa). Niiden avulla datasta luodaan informaatiota.

Tähän väliin välikommentti: Yksi asia, jota en ole Master Data Managementistä ikinä on ymmärtänyt on puheet omista, erillisistä MDM-organisaatioista, joiden tehtävä on vahtia, valvoa ja käsitellä dataa, jotta siitä saataisiin master dataa. Sallitaan siis organisaation muuten tuottaa roskaa, jota sitten erikseen muokataan kuntoon. Kyllä nykypäivänä master datan laatuvaatimukset pitää pystyä leipomaan prosessien sisään esimerkiksi SixSigman avulla. ja takaisin...

Informaatiomalli. Jee! Ilman muuta. Jotta master data voidaan pitää master data kokonaisuutena, pitää olla kattava yhteinen näkemys, rakenne, tietomalli siitä mitä data itseasiassa on. Mitä dataa haluamme koota. Mitä dataa tarvitsemme, jotta siitä voimme prosessien kautta tuottaa informaatiota. Informaatiota, jonka avulla voimme tuottaa tulosta, palvella asiakkaitamme.

Vielä kun lisätään, ettei Master Data Management itseasiassa taidakaan olla ytimeltään datan laadun parannusta, vaan informaation tehokasta hyödyntämistä ja tuottamista tiedon hallinta prosessien kautta, alan ehkä päästä kärryille. Tuota omaa MDM-järjestelmän viittausta nyt en heti osta. Maailmassa, jossa pilvien kautta ollaan menossa ja pyrkimässä kevyempiin ratkaisuihin, pitäisikin nyt olla oma MDM-järjestelmänsä PDM:n päälle, koska PDM ei kykene MDM:ää hoitamaan. Master Data Management ei siis kuitenkaan ole Product Data Managementia...kö?

Jaa...

Mitä mieltä siis itse olen... Yksinkertainen on kaunista. Datasta on luotava yritykselle informaatiota. Informaatiota tulee hallita. Pitää tietää mitä tarvitaan. Pitää olla prosessi mitä tehdään. Ja sen mitä tehdään pitää olla laadukasta. Ei kai se sen vaikeampaa ole. Se onko tämä nyt sitten sitä Master Data Managementia, johon tarvitaan omat järjestelmät, tiimit, projektit ja konsultit... en tiedä. Ehkä kärpäsestä ollaan tekemässä härkästä ja unohtamassa mitä oikeasti pitikään tehdä.

__________________________________________________________________________________

Asiasta toiseen... Onkohan Modultek tuotteistamassa tuotteen tietomallia? Pragmaattinen nimikelaatu... Tietomalliajattelua... Nimikeinformaation kokonaislaatuajattelu ja nimikeinformaation subjektiivinen laadun hallinta... Kuulostaapa tutulta... Joku tosin voisi olla sitä mieltä, että viisas tiedon hallinta, jossa tiedetään kuka tarvitsee ja mitä, olisi ihan perusolettamus yleiselle tiedon hallinnalle ja ehkäpä myös Master Data Managementille...

pragmaattinen = perehtynyt, viisas, kokenut

Lue lisää

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

Lue lisää