nld

"IT'S BACK": Het dilemma van een terugkerend probleem

Nachtmerrie scenario: De telefoon gaat en u hoort met afschuw dat het probleem waarvan u een maand geleden dacht af te zijn, terug is en groter dan ooit. Je maag zakt ineen en je hartslag versnelt, terwijl je probeert uit te zoeken wat er precies aan de hand is. EN u weet dat het slechts een kwestie van tijd is voordat het management van de fabriek aan uw deur verschijnt voor een "serieus" gesprek.

Dit gebeurt maar al te vaak en neemt kostbare tijd weg van datgene waarvoor we beloond worden - producten de deur uit krijgen. Erger nog, het verplaatst ons naar waar we voor gestraft worden - repareren, weer, wat ons verteld was, voorgoed was opgelost.

Voordat we ingaan op wat we nu moeten doen, kijken we eerst even naar wat er gebeurde toen we dachten dat we het goed hadden en wat er in feite fout ging.

De meeste dagelijkse oorzakenanalyses (RCA) volgen één of een combinatie van de hieronder vermelde stappen:

-  "Ik weet de oorzaak." (RCA Actie-Brainstorming) Los het op en denk, hopelijk, na over wat er stroomopwaarts/stroomafwaarts mis kan gaan als gevolg van de oplossing (Denk verder dan de oplossing).

-  "Ik denk dat ik de oorzaak weet." (RCA Actie-Vijf Waaroms) Verifieer, los het op en "denk verder dan de oplossing."

-  "Ik heb wat ideeën over oorzaken." (RCA Action-Fishbone) Gebruik oorzaak(en) uit een Fishbone-diagram, los het op en "denk verder dan de oplossing."

Dus wat gebeurt er in dit proces als ze het niet goed doen? Het begint meestal met de probleemstelling. In veel gevallen hebben Operators de neiging om naar de oorzaak te springen en het probleem in zulke vage bewoordingen op te schrijven dat alleen zij weten wat ze bedoelen. Wanneer u probeert hen enige structuur te geven, d.w.z. het Vijf Waarom-proces te gebruiken, gaat het ongeveer als volgt:

Vraag: "Waarom is de productie op lijn drie traag?" ....
Antwoord: "De nieuwe buizen passen niet"

Vraag: "Waarom passen de nieuwe buizen niet?"...
Antwoord: "Het gat is te klein om er gemakkelijk in te kunnen steken"

Vraag: "Waarom is het gat te klein?"...
Antwoord: "Ik weet het niet, het was goed voor ons gisteren"

Vraag: "Wat is er sinds gisteren gebeurd?...
Antwoord: "Ik weet het niet.

Gewoonlijk praat de operator op dit punt met anderen om hem heen en met de ploegleider en komen ze met een aantal "oplossingen" waarbij ze gebruik maken van een verbale visgraatdiscussie voor ideeën. Dan voeren ze de veranderingen door, documenteren wat ze hebben gedaan - hopelijk - en gaan verder.

Wanneer Bevestiging Brainstormen moet vervangen

Dus wat ging er mis?  Ten eerste, vijf is geen magisch getal in het Vijf Waarom-proces. Soms zijn er aanvullende vragen nodig om tot een geldige mogelijke oorzaak te komen. Eindigen met "Ik weet het niet" levert geen geldige gegevens op om een oorzaak te definiëren. Het geeft alleen aan dat er meer informatie nodig is. Het is belangrijk bij het gebruik van de "Waarom-vijf" om de antwoorden die uit de vorige vraag voortvloeien te isoleren en zich te concentreren op het bevestigen ervan - niet alleen op het brainstormen. Brainstormen, in plaats van gerichte, gerichte vragen stellen, impliceert dat alle antwoorden geldig zijn, wat Operators aanmoedigt om veel "fixes" toe te passen om alle antwoorden aan te pakken. Dit maskeert alleen maar de echte hoofdoorzaak en maakt de gegevens onoverzichtelijk voor toekomstige analyse als het probleem zich weer voordoet.

Ga door: Vind de oorzaak van de oorzaak

En hier is nog iets dat fout kan gaan. Het is net zo belangrijk om niet een tussenliggende oorzaak te definiëren als de "hoofdoorzaak" zonder EERST te testen, op basis van de feiten en gegevens, of het de echte oorzaak is. De valkuil van het niet eerst toetsen van de mogelijke oorzaak aan de feiten is dat het ertoe kan leiden dat operators hun probleemoplossing richten op "bekende oorzaak"-oplossingen, die in veel gevallen geen verband houden met het oorspronkelijke probleem.

Uiteindelijk krijgt u betere resultaten als uw Operators dieper gaan in hun RCA-vragen en op zoek gaan naar de oorzaak van de oorzaak zoals dit:

Vraag: "Waarom is de productie op lijn drie traag?" ....
Antwoord: "De nieuwe buizen passen niet"

Vraag: "Waarom passen de nieuwe buizen niet?"...
Antwoord: "Het gat is te klein om er gemakkelijk in te kunnen steken"

Vraag: "Waarom is het gat te klein?"...
Antwoord: "Ik weet het niet, het was goed voor ons gisteren"

Vraag: "Wat is er sinds gisteren gebeurd?...
Antwoord: "Ik weet het niet.

Vraag: "Wat is er gespecificeerd voor het gat?"...
Antwoord: "Het is gespecificeerd in de gereedschap setup"

Vraag: "Wat is er gespecificeerd in de gereedschapsetup"? .....
Antwoord: "Wat staat er in de tooling setup SOP"

Vraag: "Hebben we gecontroleerd wat er was ingesteld voor het gereedschap?" ....
Antwoord: "Nee, we namen aan dat het goed was om te gaan."

Vraag: "Laten we eens kijken." ......
Antwoord: "Het lijkt erop dat er een fout zit in het invoeren van de gegevens tijdens het programmeren."

Door gerichte vragen te stellen om gegevens te isoleren die specifiek zijn voor het probleem, kunt u uw wicked problemen tot een minimum te beperken en dat nachtmerriescenario te vermijden... "HET IS TERUG"!

Gerelateerd

Blog afbeelding 1
Probleem opgelost! Aanpak van een terugkerend defect
Blog afbeelding 1
Toezicht op terugkerende problemen: Een Kritisch Aspect Van Effectieve Operaties

Neem contact met ons op

Voor vragen, details, of een voorstel!