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