• Vergroot lettergrootte
  • Standaard lettergrootte
  • Verklein lettergrootte
Home Bluff Your Way Into... Probleemoplossing volgens Charles H. Kepner & Benjamin B. Tregoe
Probleemoplossing volgens Charles H. Kepner & Benjamin B. Tregoe

structuur probleem tregoe kepner

In het boek De nieuwe rationele manager beschrijven Charles H. Kepner & Benjamin B. Tregoe hun aanpak voor probleemanalyse:

probleem oplossing problemen probleemoplossing kepner tregoe

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
(...)
Het probleem vaststellen
Voordat we een probleem kunnen beschrijven, analyseren en verklaren, moeten we het eerst definiëren. We doen dit met behulp van de probleemstelling of de naam van het probleem. Het is belangrijk dat het probleem een accurate naam krijgt, zodat al het hieruit voortvloeiende werk - de beschrijvingen, analyses en verklaringen die we zullen geven - gericht zullen zijn op hetzelfde probleem.
(...)
Vage of te algemene probleemstellingen die beginnen met "Lage productiviteit bij ...", of "Ondermaatse prestatie door ...", moeten opnieuw geformuleerd worden, zodat we een specifieke probleemstelling krijgen, waarin een object of type object en een storing of type storing genoemd worden, waarvoor we een oorzaak willen vinden en ophelderen. We moeten precies beschrijven wat we zien, voelen, horen, ruiken of proeven, dat ons waarschuwt dat er een afwijking is.
Het is verleidelijk om twee of meer afwijkingen in een poging tot oplossing van het probleem te combineren of een groep ogenschijnlijk aan elkaar gerelateerde probemen in een algemeen probleem samen te bundelen. Bijna iedereen heeft wel eens een vergadering bijgewoond waarin twee of meer afzonderlijke problemen aan elkaar verbonden werden als twee benen in een hardloopwedstrijd. Deze handelswijze is bijna altijd inefficiënt en onproductief.
(...)
Het probleem specificeren
Als we eenmaal een precieze probleemstelling hebben, wordt de volgende stap van probleemanalyse gevormd door het in de volgende vier dimensies gedetailleerd te beschrijven:
  • 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
Specificatievragen
WAT
  • WAT is het specifieke object dat de afwijking vertoont?
  • WAT is de specifieke afwijking?
WAAR
  • WAAR is het object wanneer de afwijking gesignaleerd wordt (plaats)?
  • WAAR doet zich de afwijking op het object voor?
WANNEER
  • 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?
OMVANG
  • 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

Laatst aangepast op maandag, 23 december 2019 16:42  

People with different skills have to work together to deliver product features. Don’t build features that nobody needs right now. Don’t write more specs than you can code. Don’t write more code than you can test. Don’t test more code than you can deploy. (…) Pretty simple to describe in theory. Some subtlety in practice. A kanban is a tool, and like any tool, it is meant to solve a problem. I think kanban solves this problem more efficiently than the known alternatives.

Corey Ladas

Banner

Archief

Lean boeken top 5

(maart 2016)
Banner
Banner
Banner
Banner
Banner

We hebben 85 gasten online
Artikelen

inspection ingebouwde kwaliteit edwards deming inspect quality into product

Bewaren

Banner
Banner

huh?! berthold gunster omdenken

Huh?!
De techniek van het omdenken
Berthold Gunster

Bij Managementboek

Lean boekentips

Banner