Ik krijg veel vragen over Taguchi, Taguchi Methodieken en I@E Taguchi’s Concept.
Oók de vraag om het beknopter, simpeler én in het Nederlands aan te geven. Op deze pagina zal ik dit doen en zonodig verwijzen naar de pagina’s op deze site. Een soort van FAQ dus. Ik heb de vragen chronologisch gerubriceerd.
Komt er een vervolgvraag bij je op? Gewoon even bellen (06-22496503) of mailen (frans.balemans@taguchi.eu).
Taguchi, Is dat een persoon?
Genichi Taguchi was een electronisch engineer die zich ingezet heeft om voor de ‘engineer’ bruikbare testmethodieken te ontwikkelen die begrijpbaar zijn. Het doel van de testen is om het product/proces te verbeteren! I@E heeft deze methode in een 7 staps model voor implementatie gegoten.
Wat zit er achter I@E?
I@E is een jong éénmansbedrijf en de afkorting staat voor Innovation at Engineering. I@E noemt zich ‘The Taguchi Specialist”. Frans Balemans richt zich enkele alleen op dit tool. Taguchi Methods leveren incrementele én innovatieve verbeteringen op het gebied van cultuur, groepsprocessen, duurzame kennis, betere systemen, processen of producten tegen lagere kosten (welke andere methodiek kan dat???) en een kortere Time to Market.
Door het enthousiasme van mijn klanten aangaande Taguchi-cases, is mijn drive ontstaan om bedrijven te helpen hun engineering écht te innoveren. Een flinke stap vooruit te helpen. Dusdanig dat ze het zelf kunnen. Geen vis geven maar leren vissen.
Ik help je graag. Waarom? Omdat ik geniet van groeps-verbeterprocessen met een innovatieve touch! Zie ook mijn Linkedin-profiel.
Waarom is de site Engelstalig?
I@E, Innovation at Engineering, richt zich op de top-250 OEM-ers in West-Europa die een R&D afdeling hebben. Engels vormt een generiek communicatiemiddel.
Ik heb gegoogeld naar ‘Taguchi’ maar kan toch weinig informatie vinden!
Als je zoekt op de trefwoorden ‘taguchi methods’ krijg je de beste informatie in het wikipedia.org domein. De onbekendheid van de methodiek komt vooral door de Japanse achtergrond. Japanse taal én de Japanse verbetercultuur werden in de 70er en 80er jaren van de vorige eeuw niet echt Westers ondersteund. Xerox was het eerste westerse bedrijf dat de waarde inzag en vandaaruit heeft er een bewustmakingsgolf gevolgd naar de USA en het UK.
De economisch bloeiperiode in de 90er jaren verdrong het kwaliteitsdenken wederom. In India en de USA zien we nu veel research-achtige cases die gepubliceerd worden. Beter dan niks, maar de echte kracht ligt in Engineering! Gelukkig zien we ook weer een opleving vanuit het 6-Sigma denken. De Black-belts vinden in Taguchi een dankbaar tool.
Als je een case zoekt uit jouw vakgebied wil ik je graag helpen om deze te vinden. Ze zijn er echt! Van ‘automotive’ tot ‘chemie’ en van ‘spuitgieten’ tot ‘scheepsrompen’.
‘Taguchi’? Is dat niet een methode om met weinig testen effectiever te testen? Hetzelfde resultaat bereiken als met veel testen?
Kort door de bocht: Ja, dat klopt. Door een orthogonaal array te gebruiken kan ik met een slim beperkt aantal testen informatie krijgen over ‘hoe een optimum te vinden’. Veel effectiever dan met trial and error, efficiënter dan met full factorial.
Niet zo kort door de bocht: welke testen wil je doen? Confirmatietesten, onderzoek naar invloed van parameters? Of optimalisatie van je product/proces naar target? Of optimalisatie van je product/proces naar robuustheid én waarbij de Time to Market heel belangrijk is? Als je de laatste twee vragen positief beantwoord, dan is het antwoord voluit “ja”.
Ons bedrijf ‘engineert’ nu met ‘GBV’ (Gezond Boeren Verstand). Met deze Taguchi methods moet ik een bepaalde structuur volgen. Daar houden we niet zo van. Wat voegt een structuur toe?
Als bedrijven hun engineeringsafdeling zouden afrekenen op resultaat (kortere Time to Market met behoud van Robuustheid, Het vinden van Hogere Kwaliteit tegen lagere kosten) zouden ze op zoek gaan naar verschillende methodieken én dan zou deze vraag al niet meer opportuun zijn.
Stel dat we ‘Taguchi” gaan gebruiken; wat voegt deze structuur dan toe?
Het opzetten van de test alsmede het interpreteren van de testresultaten worden transparant voor alle gebruikers door de gevolgde structuur. In een groepsproces komt daar nog de hele groepskennis bij! Subjectiviteit in beslissing wordt vervangen door objectieve groepsbeslissingen. Het product/proces wordt in kaart gebracht en objectief verbeterd. Parameters worden dusdanig ingesteld dat het product robuuster wordt: hogere kwaliteit tegen lagere kosten! Wij zijn opgegroeid in een cultuur waarbij een hogere kwaliteit impliciet betekent dat de kosten hoger zijn! Waarom? Omdat we enkel tolerantie-verkleiningen toepassen en niet weten hoe we een ander optimum kunnen vinden voor ons systeem, proces, product. Een ander, maar stabieler optimum!
Last but not least: Een kortere TTM gepaard aan duurzame engineeringskennis.
Dat voegt deze structuur toe!
Wanneer kun je de methodiek het beste gebruiken?
In welke fase van het ontwikkel/maak-proces? (Research, development, engineering, pre-productie, productie, service) De methodiek komt het meest tot zijn recht binnen engineering! Wat is immers het doel van Engineering? Het product/proces zo immuun mogelijk maken voor invloeden van buitenaf: omgevingsfactoren, onderdelen-toleranties en veroudering en slijtage.
Trial and error wordt nu gebruikt. (Onafhankelijk van CAE-tools) Maar als je een structuur zoekt om dit te bereiken is de 7-staps methodiek van I@E de beste mogelijkheid!
Een 7-staps methodiek? Is dat hip? Net als Covey’s 7 stappen?
Het hele verbeterproces zoals door Taguchi gepropageerd kent eigenlijk 10 stappen. Ik heb het teruggebracht naar 7 essentiële stappen in een groepsproces. Klik op de figuur voor verduidelijking. Mijn doel is om een bedrijf of kerngroep in een bedrijf de methodiek in korte tijd (ik heb zelf 2 weken cursus gehad en ik ben ervan overtuigd dat ik deze kennis ook in 1,5 dag kan overdragen plús begeleiding per mail!) te leren toepassen én aan de hand van een case al resultaten te boeken! “Learning by Doing” is mijn adagium. Maar ook al rendement halen tijdens de training. Mijn training kent daarom een theoretische (groeps)deel, een zelfstandige case, een case-bespreking en case-begeleiding.
De eerste vier stappen lijken zo triviaal, voor de hand liggend.
Mijn leerstramien kent 7 stappen en is gebaseerd op kennis delen, snel leren en slim implementeren. Deze 7 stappen kun je hier vinden. Ik zal de eerste stappen hier uitgebreider toelichten omdat ze zo triviaal lijken, maar het helemaal niet zijn. Hier is groepsintellect nodig!
- Wat wil ik verbeteren? Triviaal? Wat is Kwaliteit? Wat is de functie? Bijvoorbeeld van een ‘bezem’? Wat is de functie van het product “bezem”? Schoonmaken? Of “stof verplaatsen”?
- Hoe meet ik de Kwaliteit? Hoe meet ik de kwaliteit van de bezem? Triviaal? Al mijn gecoachte cases tot nog toe besteedden 40% van de hele trajecttijd aan deze 2 stappen! Toch vreemd om dan te zeggen dat GBV ook werkt bij complexe producten/processen!
- Hoe kan ik de Kwaliteit verbeteren? Welke parameters zijn relevant? Ik stimuleer de groep in de brainstorm ook externe kennis te gebruiken. Inventarisatie naar doelstelling! Geen inventarisatie naar “onderzoek naar parameters” of nog erger “onderzoek naar afhankelijkheden”. Dit laatste in combinatie met een slechte kwaliteits-definitie (stap 1) geeft enorm veel engineerings-capaciteits-verbranding!
- Brainstorm. U doet nu ook met GBV inventarisatie van parameters en brainstormen? Mooi! Dan komt nu de volgende stap: welke parameters kan/wil ik beïnvloeden en welke niet? Hoe test ik dit op dit moment? Hier komt de effectiviteit van signaal-ruis-verhouding denken ( analoog elektronisch kwaliteitsbegrip) om de hoek kijken (stap 4). Onmogelijk om met GBV te voorspellen wat de instelling van een parameter moet zijn om de invloed van de tolerantie op de output zo klein mogelijk te maken. Uitgedaagd?
De laatste drie stappen lijken mij het meest met Taguchi te maken te hebben? Klop dat?
Eigenlijk benodigen stap 4 en 5 de meeste test-techniek kennis. Echter deze is goed over te brengen tijdens een case. Keuze van de testmatrix. Kiezen voor de kleinst mogelijke testmatrix, want testen kost tijd en geld en verhogen het afbreukrisico in de eigen organisatie. Stap 6 en 7 (test uitvoeren en optimaliseren op basis van de testresultaten door middel van synthese) is een objectief interactief groepsproces! Het verankeren van de kennis in een rapportage! Is eigenlijk ook niet des Taguchi’s maar soms wordt het in de praktijk van fire-fighting vaak vergeten. Daarom heb ik deze stap expliciet meegenomen.
Wat is S/N verhouding?
De bedoeling van Taguchi is om een zo robuust mogelijk systeem te ontwerpen. Een systeem dat tegen een stootje kan.De S/N verhouding is door Taguchi uitgevonden (Hij ontving hiervoor de Deming Kwaliteitsprijs) om de robuustheid van systemen te meten en testresultaten van verbeter-testen met elkaar te kunnen vergelijken om een optimum te vinden.
Je zegt dat het een Engineering-tool is. Kan ik de methodiek ook binnen Development/Ontwikkeling gebruiken…of Productie.
Ja, dat kan! Ik zie mogelijkheden als er specificatie-problemen zijn (het product/proces werkt niet, het geloof in het huidige systeem/proces/product komt aan het wankelen en men zoekt een laatste redmiddel) of indien men het product/proces verder ‘im Griff’ wil krijgen, dwz de product/proces-parameters die invloed hebben op de kwaliteit zo goed mogelijk in kaart wil krijgen. Dit kan in het ontwikkelstadium, engineeringstadium en productiestadium van een systeem/product/proces het geval zijn. Waarom dan toch het meest optimaal voor Engineering? Omdat deze afdeling opgericht is voor robuustheid, voor meeting to specifications onder alle omstandigheden. In Taguchi-taal: Omdat ik dan de efficiency van een signaal-matrix én een ruismatrix kan combineren en de S/N verhouding kan gebruiken bij de testen. Binnen Development zal ik me beperken tot de signaal-matrix om het probleem-punt (de missende parameter vinden) te vinden! Voor de black-belts: een alternatieve methodiek om de Red X van Shainin te vinden.
En binnen research? Nee, daar zie ik geen optimalisatiemogelijkheden. Research is gebaseerd op onderzoek, haalbaarheid, creativiteit en uitvinden. Niet op optimalisatie.
Is dr. Taguchi een kwaliteitsgoeroe?
Ja, ik schaar hem onder de groten der aarde in Kwaliteitsland. Deming, Juran, Shainin, Ishikawa en Taguchi. Naast de slim testen heet hij ook nog een relatie gelegd met kwaliteitskosten. De Verlies-functie. Wanneer moet ik een verbetering doorvoeren? Waar ligt de grens?
Maar ik houd van modellen en pas dus ook de methodieken van de heren Altshuller (brainstormen kan veel slimmer!) en Kano (de klantbehoefte vs klantloyaliteit) graag toe tijdens mijn trainingen.
Wat is jouw elevator pitch?
Ik leer bedrijven in één dag wat Taguchi is en hoe het kan werken in hun omgeving. Ik sta de pioniers bij met raad en daad; zowel in een groepsproces en individueel. Ik ben tevreden als het bedrijf tevreden is door te ervaren dat hogere kwaliteit ook tegen lagere kosten kan.
Zijn er goede boeken te vinden betreffende Taguchi?
Er is veel literatuur in de handel. En er zijn veel cases beschreven door Universiteiten. Maar ik kan je de volgende boeken wel aanbevelen:
“Probabilistic Design for Optimization and Robustness for Engineers” geschreven door o.a. Rene Klerx, master black belt bij SKF. Zie http://eu.wiley.com/WileyCDA/WileyTitle/productCd-1118796195.html
“A primer on Taguchi Methods” geschreven door Ranjit Roy. Zie https://www.amazon.com/Primer-Taguchi-Method-Ranjit-Roy/dp/087263468X