Analyse van de oorzaak hacks voor eenvoudigere probleemoplossing

Door Michael Barna, Kepner-Tregoe

Waarom verzetten mensen zich tegen root cause analyse? "Te tijdrovend!" "Te duur!" "Te moeilijk!"

Soms volstaat het om er omheen te werken of te gissen, maar in een wereld van Operationele Uitmuntendheid, Six Sigma-precisie, Lean-workflows en snel veranderende, hoogtechnologische grenzen is expertise op het gebied van analyse van de hoofdoorzaak essentieel om concurrerend en winstgevend te blijven.

We komen vaak in organisaties waar mensen hebben geleerd om klassieke hulpmiddelen voor Root Cause Analysis (RCA) te gebruiken, met name De Vijf Waarom's en Visgraat (Ishikawa) Diagrammen, maar die ontoereikend zijn gebleken om de oorzaak van moeilijke problemen te vinden. KT Probleemanalyse biedt een proces dat effectief is gebleken bij het uitvoeren van RCA's voor complexe problemen. Vaak kunnen KT Probleemanalyse, Five Whys en Fishbone in wisselende combinaties worden gebruikt om het RCA proces te verbeteren. De sleutel is om de juiste RCA tools efficiënt te gebruiken om een accurate oplossing te versnellen.

Hier zijn twee hacks om RCA te verbeteren door methodologieën te combineren om dit proces te verbeteren.

1. Zorg ervoor dat er een probleem is dat opgelost moet worden

Voordat je een visgraatdiagram maakt (zie hieronder) heb je een probleemstelling nodig. Maar wat als je niet de juiste probleemstelling hebt of als je eigenlijk geen oorzaak hoeft te vinden? Een Probleemstelling benoemt het op te lossen symptoom, rond de entiteit die het probleem ervaart en het specifieke probleem dat het heeft. Het is niet ongewoon dat probleemoplossers tegenstrijdige percepties van het probleem hebben. In andere gevallen is de Probleemstelling te algemeen of is het een verklaring waarvan de oorzaak al bekend is.

Om de verwarring rond het begin van een oorzakenanalyse te minimaliseren en ervoor te zorgen dat dit een juist gebruik van tijd en middelen is, kunt u deze eenvoudige hack gebruiken.

Er zijn drie poortwachtervragen die je moet stellen:

  • Is er een afwijking? (d.w.z. een verandering in de verwachte, normale prestatie van iets)
  • Is oorzaak 100% onbekend?
  • Moeten we de oorzaak kennen om doeltreffende, zinvolle actie te ondernemen?

Als het antwoord op een van deze vragen nee is, is RCA niet de beste weg vooruit: er zijn betere manieren om tijd en middelen te besteden.

Veel situaties zijn geen afwijkingen en behoeven geen RCA. Een afwijkingsprobleem doet zich voor wanneer iets niet presteert zoals het in het verleden heeft gedaan. Er is een afwijking in de prestaties, en we moeten de oorzaak kennen om die op te lossen. Dit kan betrekking hebben op de prestaties van een ding, zoals een machine, een IT-systeem, of een persoon.

Het uitvoeren van RCA wordt gebruikt om de oorzaak van een afwijking te achterhalen. Door te begrijpen dat verschillende soorten problemen verschillende methoden en technieken gebruiken, kunt u uw middelen richten op afwijkingsproblemen, terwijl variatie-, efficiëntie- en innovatieproblemen beter kunnen worden aangepakt met andere instrumenten en methoden. (Zie: Wat is er gebeurd? Verschillende soorten problemen vereisen verschillende benaderingen)

Om snel te bepalen of de oorzaak onbekend is, kan de Five Whys helpen. De Five Whys is een iteratieve RCA techniek die wordt gebruikt om snel tot de oorzaak te komen. Alvorens een meer complexe RCA uit te voeren, is het de moeite waard om met behulp van de Five Whys te bepalen of de oorzaak inderdaad onbekend is. Door te vragen Waarom totdat het antwoord is: Ik weet het niet.kunnen we ervoor zorgen dat de oorzaak onbekend is, en kunnen we inzichten vergaren die de beschrijving van het probleem verbeteren.

We moeten ons ook afvragen of we de oorzaak moeten weten. Soms is een work-around voldoende. Een work-around kan een betere optie zijn dan de tijd nemen om de oorzaak te vinden, bijvoorbeeld wanneer een machine die binnenkort moet worden vervangen een probleem heeft.

De vragen aan de poort openen de deur voor RCA. Merk op hoe het stellen van: "Filter nummer één lekt olie" een verbetering is ten opzichte van het aanvankelijk geconstateerde probleem, "Er ligt olie op de vloer." We zouden tot "Nummer 1 filter lekt olie" kunnen komen door de 5 Waarom-vragen te gebruiken, beginnend met de aanvankelijke observatie: Er ligt olie op de vloer... waarom?... Omdat het nummer 1 filter olie lekt... waarom? ... Weet ik niet... Moeten we de oorzaak weten om dit op te lossen? ... Ja.

Hack #1: Gebruik KT's drie gateway-vragen alvorens RCA na te streven. Dit elimineert verspilde tijd en maakt het mogelijk om andere soorten problemen op efficiëntere manieren aan te pakken.

2. Beschrijf eerst het probleem

Te vaak zullen teams die samenwerken om oorzaken te vinden, zich baseren op theorieën die misschien niet geldig zijn. In plaats van alle mogelijke oorzaken op te sommen en te categoriseren in een Visgraatdiagram, waarom testen we niet gewoon de oorzaken die sommige teamleden verkiezen? Het antwoord is dat te vaak vooruit springen en testen op oorzaken voorbarig is en een enorme, dure tijdsverspiller wordt.

Om te voorkomen dat men op de oorzaak afgaat, is het beter een stap terug te doen en het probleem nauwkeurig te beschrijven eerste voordat u de Fishbone gebruikt om de oorzaak te identificeren. Door het echte probleem van te voren te beschrijven, kunt u een aantal troeteloorzaken elimineren en kunt u de oorzaken in een Visgraatdiagram beter richten. Een nauwkeurige probleem beschrijving helpt probleemoplossers evalueren de oorzaken verzameld in een Fishbone diagram door het logisch testen van hun geldigheid tegen de bekende feiten, die kan elimineren hele categorieën van theorieën die niet in slagen om de gegevens te verklaren.

Als we bijvoorbeeld weten dat het nummer één oliefilter olie lekt, maar het nummer twee dit probleem niet lijkt te hebben, kunnen we elke voorgestelde Fishbone-theorie nemen en die testen door de vraag te stellen: "Als dat de oorzaak is, hoe verklaart dat dan het feit dat alleen het #1 filter lekt, terwijl het #2 filter in orde is?" Als de logica dicteert dat het #2 filter ook aangetast zou moeten zijn, gegeven die bepaalde theorie, dan is het niet iets wat de moeite waard is om verder te onderzoeken en kunnen we dat "bot" van de lijst schrappen. Het vullen van een Fishbone kan een uitgebreid raadspel zijn. Een robuuste, goed georganiseerde probleembeschrijving minimaliseert het risico op het nemen van verkwistende maatregelen door de gissingen van mensen uit te dagen en te kijken wat wel en niet standhoudt in een rechtbank.

Hack #2: Voordat u begint met het vaststellen van oorzaken, of nog erger, voordat u naar de oorzaak springt en gaat testen, Beschrijf het probleem gebaseerd op relevante gegevens.

Troubleshooting teams met goede RCA-vaardigheden nemen de tijd om een probleem te begrijpen voordat ze het proberen op te lossen. Dit begint met hack #1: ervoor zorgen dat er een afwijkend probleem is dat moet worden opgelost voordat RCA wordt toegepast en hack #2: het probleem in specifieke termen beschrijven op basis van beschikbare gegevens.

Over Kepner-Tregoe

Al meer dan zes decennia geeft Kepner-Tregoe organisaties meer slagkracht door een bewezen, gestructureerde aanpak van probleemoplossing. Als leider in probleemoplossing heeft KT duizenden organisaties geholpen miljoenen problemen op te lossen door middel van effectievere analyse van de hoofdoorzaak en besluitvormingsvaardigheden. Door onze unieke mix van training en consulting, tonen onze klanten verbeterde efficiëntie, hogere kwaliteit en grotere klanttevredenheid terwijl ze hun kosten verlagen.

Neem contact met ons op

Voor vragen, details, of een voorstel!