In het boek De nieuwe rationele manager beschrijven Charles H. Kepner & Benjamin B. Tregoe hun aanpak voor probleemanalyse:
Probleemanalyse voorziet in de vaardigheden die nodig zijn om een verklaring te vinden voor alle situaties waarin een verwacht prestatieniveau niet bereikt wordt en de oorzaak van het onaanvaardbaar presteren onbekend is. Als "alle situaties" te sterk uitgedrukt lijkt, realiseert u zich dan dat het ons gaat om de manier waarop informatie gebruikt wordt bij het aanpakken van afwijkingen in prestaties. Deze afwijkingen kunnen zich voordoen in prestaties van mensen of systemen, beleid of gereedschap, met andere woorden: iets in de werkomgeving dat om onbekende redenen van de verwachte prestatie afwijkt. Zolang deze structuur van toepassing is, zijn ook de technieken voor probleemanalyse van toepassing.
(...)
Oorzaak en gevolg
Het oplossen van problemen vereist oorzaak-en-gevolg-denken ... . Een probleem is het zichtbare gevolg van een oorzaak die ergens in het verleden ligt. We moeten het gevolg dat we waarnemen in verband brengen met de precieze onderliggende oorzaak. Alleen dan kunnen we er zeker van zijn dat we de juiste correctieve maatregel treffen; een maatregel die het probleem kan verhelpen en kan voorkomen dat het zich opnieuw voordoet.
(...)
De structuur van een probleem
Een prestatienorm wordt gehaald wanneer alle voorwaarden die voor een aanvaardbare prestatie nodig zijn, naar behoren werken. Dit geldt voor de gehele werkomgeving: mensen, systemen, afdelingen en gereedschap. Wanneer er iets in een of meer voorwaarden gewijzigd wordt - dat wil zeggen, er doet zich een verandering voor - dan is het waarschijnlijjk dat de prestatie ook zal veranderen. Die verandering kan gunstig of ongunstig zijn. Soms worden de voorwaarden beter en vinden er positieve veranderingen plaats en dingen gaan beter dan verwacht. Maar een onverwachte verbetering in prestaties roept maar zelden dezelfde dringende reactie op als een onverwachte verslechtering. Hoe ernstiger het effect van de verslechtering, des te groter de druk om de oorzaak te vinden en er iets aan te doen.
We kunnen de structuur van een probleem visualiseren zoals in de bovenstaande figuur.
Als de prestaties aanvankelijk aan de norm voldeden, maar dat niet langer doen, heeft er een verandering plaatsgevonden. Wanneer we pas beginnen een probleem op te lossen weten we nog niet precies waaruit die verandering bestond of wanneer deze plaatsvond.
De speurtocht naar de oorzaak brengt gewoonlijk een speurtocht naar een specifieke verandering met zich mee die de oorzaak is van de achteruitgang in prestatie. Soms is er al vanaf het begin een negatieve afwijking van de prestatie geweest, een zogenaamd 'eerstedagsprobleem'.
Bijvoorbeeld een stuk gereedschap dat 'nooit ergens voor deugde vanaf de dag dat het in gebruik genomen werd...' In dit geval, in onze terminologie, valt de werkelijke prestatie altijd onder de norm.
Het probleemanalyse-proces
Beide soorten problemen, zowel een huidige afwijking van een aanvankelijke aanvaardbare prestatie, als een prestatie die nooit aan de verwachting heeft voldaan, kunnen met behulp van de technieken van probleemaanalyse aangepakt worden.
De technieken van probleemanalyse kunnen verdeeld worden in de volgende stappen:
- Het probleem vaststellen
- Het probleem specificeren
- Mogelijke oorzaken uitwerken op basis van kennis en ervaring of op basis van kenmerkende verschillen en veranderingen
- Mogelijke oorzaken tegen de specificatie toetsen
- De meest waarschijnlijke oorzaak bepalen
- Veronderstellingen verifiëren, observeren, experimenteren of een oplossing proberen en controleren
- WAT: de identiteit van het probleem waarvoor we een verklaring proberen te vinden.
- WAAR: de plaats waar het probleem zich voordoet.
- WANNEER: het tijdstip waarop het probleem zich voordoet.
- OMVANG: de afmeting van het probleem
- WAT is het specifieke object dat de afwijking vertoont?
- WAT is de specifieke afwijking?
- WAAR is het object wanneer de afwijking gesignaleerd wordt (plaats)?
- WAAR doet zich de afwijking op het object voor?
- WANNEER werd de afwijking voor het eerst waargenomen (dag en tijdstip)?
- WANNEER werd de afwijking sindsdien waargenomen? Zit er enig patroon in?
- WANNEER werd de afwijking in de levensloop of het proces van het object, het eerst gesignaleerd?
- HOEVEEL objecten vertonen de afwijking?
- WAT is de omvang van de afwijking?
- HOEVEEL afwijkingen heeft ieder object?
- WAT is de trend (... in het object?) (... in het aantal keren dat de afwijking optreedt?) (... in de grootte van de afwijking?)
Informatie betreffende de gevolgen van een afwijking zal binnen een van deze vier dimensies vallen. Binnen iedere dimensie stellen we specificatievragen die onze beschrijving van hoe de afwijking zich aan onze zintuigen voordoet, vlees en bloed geven. De antwoorden op de vragen geven ons precies het soort informatie dat we nodig hebben voor de analyse.
(...)
Wanneer we ons probleem eenmaal beschreven hebben in termen van de vier dimensies WAT, WAAR, WANNEER en OMVANG, beschikken we over de eerste helft van de uiteindelijke complete beschrijving. De tweede helft maakt het tot een bruikbaar hulpmiddel voor analyse.
Mogelijke oorzaken ontwikkelen op basis van kennis en ervaring of op basis van kenmerken en veranderingen
We hebben gewoonlijk wel ideeën over de mogelijke oorzaken van een probleem, maar wanneer we het IS met het NIET IS vergelijken kunnen ons nieuwe ideeën te binnen schieten, terwijl andere minder aannemelijk worden. Deskundigen en degenen die nauw bij het probleem betrokken zijn, kunnen hun eigen ideeën over de mogelijke oorzaken hebben, maar zullen de gegevens in de specificatie toch bruikbaar vinden. Brainstormen is een doelmatige techniek om vlug een aantal ideeën te inventariseren zonder ze te evalueren of te bespreken. Het doel hiervan is om een groot net uit te werpen waarmee de werkelijke oorzaak gevangen kan worden.
Toetsen van mogelijke oorzaken tegen de specificaties
Door alle mogelijke oorzaken in aanmerking te nemen, verliezen we niets, blijven we objectief en verminderen we de kans op conflict en onenigheid bij de verklaring van een probleem. In de toetsfase van de probleemanalyse laten we de feiten in de specificatie de relatieve waarschijnlijkheid van de mogelijke oorzaken uitmaken.
We vragen ons bij elke mogelijke oorzaak af: "Als dit de werkelijke oorzaak is, hoe wordt hierdoor elke dimensie in de specificatie verklaard?' De werkelijke oorzaak moet ieder aspect van de afwijking verklaren, aangezien de werkelijke oorzaak precies het effect had dat we hebben omschreven. Effecten zijn specifiek, niet algemeen. Toetsen van de oorzaak is een proces waarin de details van een veronderstelde oorzaak tegen de details van een waargenomen effect worden afgewogen om te zien of die oorzaak werkelijk dat effect kan hebben.
(...)
De meest waarschijnlijke oorzaak bepalen
Op dit punt in de analyse hebben we de meest waarschijnlijke mogelijke oorzaak gevonden die de afwijking beter verklaart dan elk van de andere mogelijke oorzaken. Er bestaat weinig twijfel over dat deze meest waarschijnlijke oorzaak de ware oorzaak is.
(...)
Veronderstellingen verifiëren, observeren, experimenteren of een oplossing proberen en controleren
Bewijzen is een aparte stap die wordt genomen om het verband tussen oorzaak en gevolg aan te tonen. Het vereist het verzamelen van meer informatie en het verrichten van meer handelingen. Een waarschijnlijke oorzaak bewijzen betekent aantonen dat het de waargenomen gevolgen had.
(...)
Soms is er geen direct bewijs mogelijk en moeten we vertrouwen op onze veronderstellingen. Een draagraket ontploft tijdens de vlucht. Het grootste deel van het tastbare bewijsmateriaal is vernietigd. We willen zeker niet dat dit nog eens gebeurt. het enige dat gedaan kan worden, is de veronderstellingen verifiëren die naar voren kwamen bij het toetsen tegen de specificatie. "Als dit gebeurden, dan zou dat kloppen...". Vind manieren om de veronderstellingen te verifiëren. De veronderstellingen moeten waar zijn om de oorzaak waar te maken.
Bron: De nieuwe rationele manager, Charles H. Kepner & Benjamin B. Tregoe