Fouten zoeken in detectivestijl

april 2010

Ze kunnen knap vervelend zijn, fouten in de productie die zich slechts af en toe en schijnbaar onverklaarbaar voordoen. Een weinig gekende methode om oorzaken op te sporen en een oplossing te zoeken, is die van Shainin.

Shainin is genoemd naar de Amerikaanse ingenieur, professor en consultant die een soort roadmap ontwikkelde om aan de hand van eenvoudige statistische tools tot de kern van een probleem door te dringen.

Wie heeft er al gehoord van Shainin? Het was een van de eerste vragen begin december op een druk bijgewoond seminarie dat Amelior en B-Enbis organiseerden over de methodologie. Shainin blijkt helemaal niet zo bekend te zijn, wat eigenlijk ook niet verwonderlijk is aangezien er nauwelijks publicaties over te vinden zijn. Dat is dan weer een gevolg van de strikte controle die het consultancybedrijf van oprichter Dorian Shainin voert op de intellectuele eigendom. De meeste termen van de methode, de beschrijvingen van de tools en de roadmap die gebruikt wordt om stapsgewijs op zoek te gaan naar de oorzaak van een kwaliteitsprobleem, zijn auteursrechtelijk beschermd. Het ziet er dan ook niet naar uit dat de Shainin-methode op korte termijn een grote bekendheid zal verwerven en bijvoorbeeld Six Sigma van de troon zal stoten. Toch is het voor kwaliteitsverantwoordelijken interessant om zich enigszins in Shainin te verdiepen. De methode gaat uit van een aantal basisprincipes die kunnen helpen om een probleem duidelijk in kaart te brengen en snel en efficiënt op te lossen. En er zijn een aantal eenvoudige tools die met een beperkte inspanning zeer waardevolle informatie kunnen opleveren bij de zoektocht naar de oorzaak van een probleem.

De Shainin-methode in enkele woorden samenvatten, is niet zo eenvoudig. Per slot van rekening gaat het om een hele verzameling aan tools die Dorian Shainin gedurende zijn carrière verzamelde en ontwikkelde. Sommigen maken de vergelijking met een kookboek, omdat in opeenvolgende, duidelijke stappen naar de oplossing van een probleem toegewerkt wordt. Anderen verwijzen naar een handboek voor detectives, omdat de gebruiker van de methode, gewapend met een reeks tools, aan de hand van observaties de oorzaak van een probleem moet weten te vinden. Het seminarie van Amelior en B-Enbis gaf alvast een goed beeld van wat de methode inhoudt en wat ze voor kwaliteitsverantwoordelijken kan betekenen. Sprekers waren Willy Vandenbrande van QS-Consult die een introductie gaf op de methodologie, Ko Dousma van Philips Applied Technology, die als problem solver binnen zijn bedrijf al succesvolle ervaringen opdeed met Shainin en professor Stefan Steiner van de Canadese University of Waterloo, die voor het seminarie een vergelijking maakte tussen Shainin en Six Sigma. Onder leiding van Jan Libbrecht en Patrick Canoot van Amelior en Willy Vandenbrande konden de deelnemers ten slotte in workshops praktische ervaring opdoen met enkele Shainin-tools.

Eén enkele oorzaak

Voor alle duidelijkheid: de methode van Shainin is bedoeld voor productieomgevingen om op zoek te gaan naar fouten die zich soms wel en soms niet voordoen. Vertaald voor statistici: het gaat om een proces waarbij er een zekere spreiding zit op een bepaalde outputparameter, waardoor een aantal exemplaren niet aan de vooropgestelde specificaties voldoen. De Shainin- methode gaat ervan uit dat er één enkele oorzaak is voor dat probleem (of tenminste dat één bepaalde oorzaak de doorslag geeft) en heeft als doel om die oorzaak te vinden. Daarin zit een cruciale factor die de pragmatische aanpak van Shainin illustreert: het is niet de bedoeling om het proces in zijn geheel zodanig te verbeteren dat de spreiding op het resultaat kleiner wordt (wat uiteraard ook helpt om binnen de specificaties te blijven, maar wat al snel een omvangrijk project zou worden), het gaat enkel om het vinden van de oorzaak van ontoelaatbare afwijkingen om daar dan heel concreet te kunnen kijken wat er moet gebeuren om ervoor te zorgen dat alle eindproducten wel binnen de specificaties blijven. In de meeste gevallen zal de spreiding op het resultaat ook wel kleiner worden wanneer de belangrijkste oorzaak van het probleem weggenomen wordt. De parameter die in hoofdzaak verantwoordelijk is voor de fout in het eindresultaat, noemt Shainin de Red X.

Misschien iets te vanzelfsprekend als uitgangspunt, maar toch: de methode gaat er van uit dat een meerderheid van producten wel aan de specificaties voldoet. Als dat niet het geval is, werken zijn eenvoudige statistische tools niet meer en moet men het design van het product of het proces herbekijken.

Let the parts talk

Typerend voor de Shainin-methode is dat het zoeken naar de oorzaak gebeurt door middel van eliminatie. Ander uitgangspunt: let the parts talk. Met andere woorden, ga naar de productievloer, neem een product dat niet voldoet en onderzoek het. Dat leert vaak meer dan de overvloed aan data en statistieken die de kwaliteitsmanager dagelijks op zijn bureau krijgt. Bij een product dat ontstaat uit de assemblage van een aantal componenten, is het een goede start om een afwijkend product uit elkaar te halen en weer in elkaar te zetten. Als je dat een aantal keren herhaalt en de fout blijft bestaan, is er allicht een probleem met een van de componenten. Als het probleem na wedersamenstelling van het product verdwenen is, kun je de componenten als oorzaak elimineren en naar de assemblagestappen zelf kijken. Een andere eenvoudige tool bestaat erin om een goed en een slecht product te nemen en de componenten ervan een na een onderling te verwisselen. Zodra het slechte product goed wordt en het goede product slecht, ligt het probleem bij de component die net verwisseld is. Een gelijkaardige tool in het Shainin-arsenaal is het vergelijken van BOB en WOW-producten. BOB staat voor Best of Best, een product dat perfect beantwoordt aan alle specificaties. WOW betekent Worst of Worse, een product dat overduidelijk verkeerd is. De onderliggende gedachte is dat verschillen duidelijker zichtbaar worden wanneer men naar de uitersten kijkt. Zonder te overdrijven weliswaar, want de allerslechtste producten wijken allicht zo sterk af dat ze niet meer representatief zijn voor de statistische fout die men wil opsporen.

Inzicht in variatie

Hoewel niet bedacht door Shainin zelf, maakt ook het gebruik van Multi-vari charts deel uit van de Shainin-methodologie. De tool past perfect in het opzet van Shainin: met een beperkt aantal stalen, zonder te moeten ingrijpen in het proces (enkel door te observeren, zoals een detective) op een visuele manier de feiten blootleggen. Wat men in Multi-vari charts doet, is drie grafieken maken van de waarde die men wil onderzoeken, waarbij telkens een ander soort variatie in kaart gebracht wordt. De eerste is “single piece” variatie, de tweede cyclische variatie en de derde “time-to-time” variatie. Neem als voorbeeld een bepaalde maat van een spuitgietstuk waarvan er telkens verschillende tegelijk in een mal met verschillende cavitaties gemaakt worden. De eerste grafiek zal dan de meetwaarde weergeven voor de verschillende stukken zoals ze na een productierun uit de mal komen. Indien daar een variatie op zit, die men op een analoge manier ook in volgende productieruns terugvindt, zit het probleem in de nauwkeurigheid van de cavitaties in de mal. De tweede grafiek zal stalen uit opeenvolgende productieruns weergeven en voor de derde grafiek zal bijvoorbeeld om het uur een staal genomen worden. Hieruit kan men bijvoorbeeld afleiden of een probleem zich alleen in bepaalde shifts voordoet, waardoor het te wijten zou kunnen zijn aan het gedrag van een operator.

Eenvoudige statistische tools

Twee statistische methodes die op het seminarie in workshops geïllustreerd werden, zijn B vs C (een door Shainin geregistreerde handelsnaam) en Scatter Plots. Ter illustratie van de tools werd de deelnemers gevraagd om helikoptertjes te maken uit papier die men vanaf een vastgelegde hoogte naar beneden laat dwarrelen. Bepalende waarde voor de “kwaliteit” is in deze oefening de tijd die de helikopter erover doet om naar beneden te dwarrelen. De parameters die daarop een invloed kunnen hebben zijn de lengte van de vleugels en van de “body” van de helikopter.

De B vs C-tool is een zeer eenvoudige statistische tool om de doeltreffendheid van een wijziging aan een proces na te gaan. In de Shainin-methode vormt dit het sluitstuk op het detectivewerk. Eens men de oorzaak van een variatie gevonden heeft, moet men immers kunnen verifiëren of een aanpassing daar een verbetering oplevert van het eindresultaat. C staat daarbij voor de “Current Situation”, B voor de voorgestelde aanpassing die de “Better Situation” zou moeten zijn. Of dat ook echt zo is, leert de B vs C-tool door de meetwaarden van een aantal B-stalen en die van een aantal C-stalen volgens grootte te rangschikken. Als men bijvoorbeeld drie B-stalen en drie C-stalen neemt, en de 3 B-stalen komen in de rangschikking voor de 3 C-stalen, kan men concluderen dat B effectief een verbetering is tegenover C. De kans dat die volgorde toevallig verkregen zou worden, is immers slechts 1 op 20. Met de helikopters werd onderzocht of het inkorten van de body een verlenging van de vliegtijd oplevert. Daarvoor maakte elk groepje 3 helikopters met een lange (C) en 3 helikopters met een korte (B) body. Slechts een van de deelnemers verkreeg in de lijst van vliegtijden een BBBCCC resultaat en kon concluderen dat een inkorting effectief een verlenging van de vliegtijd oplevert. De anderen hadden blijkbaar te veel last van variatie in de meting zelf, iets waar het BBBCCC groepje veel aandacht aan besteed had door vooraf met slechts 1 helikoptertje te oefenen tot een stabiele meting ontstond. Dat is een belangrijke Shainin-les: eenvoudige tools werken enkel als men absoluut zeker is van de betrouwbaarheid van de meting.

Een tweede tool die getest werd, is het gebruik van Scatter plots. Geen uitvinding van Shainin zelf, maar wel geschikt bevonden om, eens men de Red X gevonden heeft, te bepalen hoe groot de variatie op die parameter mag zijn om te kunnen garanderen dat het eindresultaat binnen zijn specificaties blijft. Wat een scatter plot doet, is gewoon input (Red X) en output (het eindresultaat) van een aantal stalen uitzetten in twee dimensies zodat een puntenwolk ontstaat. Deze wolk maakt zichtbaar hoe groot het verband is tussen beide parameters (in dat opzicht kan men de methode ook gebruiken om mogelijke oorzaken te evalueren) en hoe de spreiding op beide parameters zich tot elkaar verhouden. In helikoptertermen kan men bijvoorbeeld nagaan welke variatie er op de vleugellengte mag zitten om de vliegtijd toch binnen bepaalde specificaties te houden.

Shainin in de praktijk

Een voorbeeld uit de praktijk, waar Ko Dousma van Philips Applied Technology de methode van Shainin toepaste, was de “Sonicare toothbrush”, een vroeger model van elektrische tandenborstel. Het werkingsprincipe was gebaseerd op resonantie. Om de juiste trilling te bekomen, moest voor elke tandenborstel een veer in het toestel nagemeten en op de juiste lengte afgesneden worden zodat de gewenste resonantiefrequentie verkregen werd. Het proces had echter een te lage Cpk (process capability) voor wat de bekomen frequentie en amplitude van de trilling betrof, wat betekent dat de uitval te groot was. Toepassing van Multi-vari charts leerde dat de variatie zich van stuk tot stuk voordeed. “Component Search”, het verwisselen van componenten tussen een WOW en BOB-product, toonde aan dat het probleem in de veer zat, niet in de andere componenten of de assemblage ervan. Een zoektocht naar correlatie tussen parameters legde een verband bloot tussen de berekende afsnijdiepte voor de veer en de verkregen amplitude. Met andere woorden: de variatie in de amplitude was terug te brengen tot een te grote spreiding op de berekende afsnijdiepte. Die spreiding was dan weer terug te brengen tot een variatie in het meetsysteem, al leerde men ook dat de kalibratie, de formule waarmee de afsnijdiepte berekend werd op basis van de meting van de amplitude, beter kon. Een analyse van het meetsysteem leerde ten slotte dat de aanwezigheid van andere elektronische apparaten te veel ruis veroorzaakte, wat vrij eenvoudig opgelost kon worden.

Dit voorbeeld illustreert de stapsgewijze benadering van Shainin, waarbij elke stap een eliminatie van oorzaken inhoudt en de gebruiker zo dichter bij de feitelijke oorzaak brengt. Voorwaarde is dan wel dat men bij elke stap de meest aangewezen tool selecteert en die ook juist gebruikt. Anderzijds is het onvermijdelijk dat tools soms ook geen uitsluitsel geven. Het is dan ook zaak om een goed evenwicht te vinden in de selectie van de tools en het aantal stalen, zodat elke observatie met een beperkte inspanning uitgevoerd kan worden en toch een grote kans heeft om waardevolle conclusies op te leveren. Om daarmee te experimenteren ontwikkelde prof. Stefan Steiner op zijn website een oefening waarbij 1 van 30 inputparameters verantwoordelijk is voor een te grote spreiding op een outputparameter in een productieproces dat uit drie bewerkingsstappen bestaat. De oefening bestaat erin om met een aantal beschikbare tools zo efficiënt mogelijk de verantwoordelijke inputparameter op te sporen. U kan dit zelf proberen op www.student.math.uwaterloo.ca/~stat435/login.htm

Shainin of Six Sigma

Wie vertrouwd is met Six Sigma zal in het Shainin-verhaal veel vertrouwde elementen terugvinden. Een aantal tools zijn hetzelfde of sterk vergelijkbaar en ook de roadmap is analoog: Shainin spreekt over de “diagnostic phase” (met als belangrijke stap de “clue generation”) en de “remedial phase”; bij Six Sigma heet dat Define, Measure, Analyse, Improve, Control (DMAIC). Toch is er een verschil in opzet tussen beide methodes. Six Sigma start met een brainstorming waarna een aantal experimenten opgezet worden om de ideeën uit de brainstorming te toetsen aan de realiteit. Bij Shainin start men direct met de observatie en eliminatie van mogelijke oorzaken. Het cruciale verschil is dat men bij Six Sigma zoekt naar een oplossing, terwijl Shainin zoekt naar de oorzaak van de afwijking. Dat maakt de Shainin-methode zo praktisch en doelgericht, want het houdt per definitie in dat Shainin zich beperkt tot inputparameters waar variatie op zit. Vaste parameters, zoals de instellingen van een machine, kunnen immers niet de oorzaak zijn van variatie in het eindresultaat. Nadeel van Shainin is dan weer dat men niet over het hoofd mag zien dat die vaste parameters zoals de instellingen van een machine toch een mogelijke oplossing kunnen zijn. Met andere woorden, eens men met Shainin de oorzaak van een onaanvaardbare afwijking gevonden heeft, is het nog niet zeker dat er ook een oplossing gevonden wordt.

Statistici zullen ook opmerken dat de eenvoudige tools van Shainin soms wel erg kort door de bocht gaan en weinig wetenschappelijke zekerheid bieden. In de Shainin-filosofie is dat echter geen bezwaar omdat hij met zijn tools niet wil bewijzen dat een bepaalde hypothese klopt, maar ze enkel gebruikt om mogelijke oorzaken te kunnen elimineren. Een goed inzicht in de tools is daarom nodig om geen verkeerde conclusies te trekken. En als een tool in een bepaald geval geen conclusie oplevert, stapt men gewoon over naar de volgende.

Uit De Kwaliteitskrant n° 1, februari 2010, blz. 25, 26, 27