Hoe 5 waarom's en Visgraatdiagrammen zich verhouden tot KT Probleemanalyse

Door Michel Barna, Kepner-Tregoe

Als het gaat om het oplossen van problemen, twee veel voorkomende technieken die ik zie veel klanten gebruiken (of proberen te gebruiken) zijn "5 Waarom's" en "visgraatdiagrammen". Het is belangrijk op te merken dat deze hulpmiddelen een plaats en een doel hebben, maar wat ook belangrijk is, is ervoor te zorgen dat, als uw team ze gebruikt, ze dat doen op een manier die logisch is en waarde toevoegt. Beide methoden zijn symbiotisch met het Kepner-Tregoe Problem Analysis proces voor het vinden van de ware oorzaak en ik denk dat een belangrijk punt van elke KT workshop niet is hoe onze methode verschilt van andere veelgebruikte technieken, maar eerder hoe het synergetisch kan zijn.

KT's Probleemanalyse aanpak omvat vier fundamentele processtappen.

  • Stap 1 is om Beschrijf het probleemfeiten verzamelen om ervoor te zorgen dat het probleem duidelijk wordt begrepen.
  • Stap 2 is om Identificeer Mogelijke Oorzakenom theorieën af te bakenen die getoetst kunnen worden aan de bekende feiten.
  • Stap 3 is om Evalueer mogelijke oorzaken, om valse oorzaken uit te sluiten en de meest waarschijnlijke oorzaak aan te wijzen voor verdere tests.
  • Stap 4 is om Bevestig ware oorzaakom de oorzaak aan te tonen en eventuele leemtes in de kennis op te vullen.

Een kernonderdeel van stap 1 is het opstellen van een Probleemstelling die het op te lossen symptoom benoemt, waarbij de entiteit die het probleem ondervindt en het specifieke probleem dat zij heeft centraal staan. Het vaststellen van de Problem Statement blijkt soms het meest uitdagende aspect van Problem Analysis te zijn, omdat het hebben van de verkeerde Problem Statement de rest van de analyse volledig van het spoor kan brengen. In sommige gevallen is het onduidelijk welk probleem men aan het oplossen is, of is men het niet eens met de probleemstelling omdat men een tegenstrijdige perceptie heeft van het probleem. 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 Probleemanalyse te minimaliseren (en ervoor te zorgen dat een analyse van de onderliggende oorzaak zelfs maar een passend gebruik van onze tijd en middelen is) zijn er drie poortwachtervragen die we moeten stellen:

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

Vraag #2 is waar de 5 waarom's in beeld komen. Voor degenen die niet bekend zijn met dit concept: het is de ondervragingstechniek waarbij meerdere malen opnieuw wordt gevraagd "waarom" in een poging om door te dringen tot een systemische hoofdoorzaak van iets. Maar wat is de waarde van een analyse van de onderliggende oorzaak als de mensen de reden weten waarom iets gebeurt? Dit zou een enorme verspilling van bedrijfstijd kunnen zijn en de opportuniteitskosten van de energie-uitgaven zouden enorm kunnen zijn.

Om er zeker van te zijn dat mensen het juiste probleem aanpakken, en om te helpen valideren dat een Probleem Analyse zelfs een noodzakelijke volgende stap is, kan het gebruik van de 5 WAAROM techniek een productieve oefening zijn. In sommige gevallen zullen teams zich meer dan 5 keer moeten afvragen waarom; in andere gevallen kan het aantal "waaroms" dat nodig is om dieper te graven minder dan 5 iteraties zijn. Het doel hiervan is om het punt te bereiken waarop teams geen vooruitgang meer boeken en toegeven "we weten niet waarom," of het punt bereiken waar een logische volgende stap kan worden geïdentificeerd (zoals in het voorbeeld hieronder). Dit is effectief wanneer de taak van de 5 WAAROM techniek eindigt.

Als we deze 5 WAAROM beoordeling hebben gedaan en tot het punt zijn gekomen dat we het "waarom" niet helemaal begrijpen, dan zou KT een derde vervolgvraag stellen om de volgende stappen te bevestigen, namelijk: "Moeten we weten waarom om effectieve, zinvolle actie te ondernemen"? In sommige gevallen kan het antwoord op deze vraag een duidelijk "nee" zijn. Een IT-incident managementteam weet bijvoorbeeld misschien niet precies waarom de service van een gebruiker is verslechterd, maar om de service te herstellen hoeven ze misschien alleen maar een snelle workaround te implementeren en de gebruiker is weer tevreden. In andere situaties is dat misschien niet het geval en moeten we misschien systematisch troubleshooting toepassen om effectieve actie te kunnen ondernemen.

Samenvatting:

De 5 WAAROM-methode is een goede vraagtechniek die de vele oorzaken van een probleem onderzoekt totdat het punt van "oorzaak onbekend" is bereikt, of wordt vastgesteld dat "waarom iets is gebeurd" niet volledig kan worden bevestigd zonder verdere analyse. Op dat punt moet worden besproken of het op dit moment bedrijfskritisch is om te weten "waarom", of dat het de moeite waard is om middelen uit te geven om de vraag verder te onderzoeken.

Het resultaat van het grondig doorlopen van stap 1 in Probleemanalyse is een feitelijke beschrijving van het probleem. De volgende stap is het gebruiken van deze probleembeschrijving, die in de KT bekend staat als een "specificatie", om mogelijke oorzaken te identificeren en vervolgens te testen.

Hier zou logischerwijze het visgraatdiagram (of Ishikawa) in het spel moeten komen.

Een visgraatdiagram is een artefact dat een visuele voorstelling geeft van mogelijke oorzaken van een probleem. Het kan zeer nuttig zijn tijdens Probleemanalyse om mensen te helpen bij het bedenken van mogelijke oorzaken die logischerwijs het probleem zouden kunnen verklaren. Soms hebben zelfs onze kennis en ervaring een leidraad nodig om ons denken op het juiste spoor te houden, of om een materiedeskundige aan het denken te zetten.

Typisch, een visgraat splitst mogelijke oorzaken op in verschillende categorieën, waarvan sommige "materialen, personeel, methodes, machines, omgeving, maatregelen, enz." kunnen omvatten. Met behulp van de probleemspecificatie die uit stap 1 kwam, gecombineerd met de visgraat-logica, kunnen teams mogelijke oorzaken rond enkele van de hierboven genoemde categorieën onderzoeken. Het gebruik van de visgraat op dit punt kan mensen helpen om te brainstormen over mogelijke oorzaken die zinvoller lijken, gegeven wat ze weten over het probleem.

Maar welk percentage van uw root cause meetings beginnen doorgaans met een visgraatdiagram (Ishikawa), of een discussie over wat de mensen denken dat de oorzaak is? Hoe snel willen de mensen de vergadering verlaten om te gaan testen wat zij denken dat de oorzaak is? Wanneer heeft u meegemaakt dat personeel meerdere oorzaken tegelijk testte? Hoe gaat dat normaal?

Het is erg verleidelijk om aan het begin van een onderzoek meteen de oorzaken te gaan evalueren, maar dit werkt averechts als teams dit doen zonder een grondige beschrijving van hun probleem te hebben. Bovendien kan het gelijktijdig onderzoeken van een groot aantal oorzaken veel veranderingen in het proces brengen, waardoor mogelijk nieuwe symptomen ontstaan die de oorspronkelijke gebeurtenis kunnen vertroebelen.

De toegevoegde waarde van het combineren van een visgraat met KT Probleem Analyse is hoe snel we veel van de irrelevante botjes van het diagram kunnen elimineren die redelijkerwijs het probleem niet kunnen verklaren. Het voltooien van een visgraat kan resulteren in een dozijn of meer botjes die zich vertakken vanuit het diagram, waarbij elk een andere mogelijke oorzaak vertegenwoordigt. Het is echter verstandig dat er slechts één echte oorzaak uit de analyse naar voren komt. Om zo min mogelijk tijd te verspillen aan het testen van valse oorzaken en om te voorkomen dat het probleem mogelijk verergert, laat KT Probleemanalyse de teams elk afzonderlijk "botje" nemen en de theorie toetsen aan de probleemgegevens, met de vraag: "ALS dit de oorzaak is, hoe verklaart het dan de feiten"? Als een theorie uit het diagram er niet in slaagt de gegevens te verklaren, wordt ze uit de overweging geschrapt. In principe zou het "bot" met de meest logische veronderstellingen ten opzichte van de gegevens de Meest Waarschijnlijke Oorzaak zijn, dat wil zeggen de oorzaak die het meest logisch is voor teams om verder te gaan en het onderzoek als eerste voort te zetten.

Samenvatting:

Visgraatdiagrammen hebben een tijd en plaats bij het oplossen van problemen. Wees er echter voorzichtig mee om ze tot het hoogtepunt van de discussie te maken voordat een grondige probleemomschrijving is vastgesteld. Indien correct gebruikt, kunnen ze een waardevol hulpmiddel zijn bij het identificeren van logische oorzaken, en zelfs een visuele voorstelling geven van welke oorzaken kunnen worden geëlimineerd. Echter, om een visgraat te laten werken zonder onnodige stress te veroorzaken, moeten teams eerst de feiten van het probleem verzamelen zodat ze de informatie kunnen gebruiken om mogelijke oorzaken die geen steek houden te elimineren en de focus te verkleinen tot de weinige die dat wel doen.

Ondersteunende documenten:

http://www.educational-business-articles.com/5-whys/

https://en.wikipedia.org/wiki/Ishikawa_diagram

Neem contact met ons op

Voor vragen, details, of een voorstel!