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

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