Structured Problem Solving

By: Brent Borgerson

June 16, 2011

There are times when informal or experienced-based problem solving alone may prove inadequate, a “band-aid” approach to a more complicated issue. Informal solutions that ignore the root cause of the problem are not likely to prevent it from rearing its ugly head again later.

Structured or formal problem solving methods and tools allow us to get to the root cause of the problem and solve it permanently. The myriad of analytical tools and structured methods available can befuddle even a trained statistician. A structured problem solving method can enable a molder to choose which problem solving tools best apply to a particular project. Many structured problem solving tools are also process improving tools. (I have always considered process improvement to be problem solving on a grander scale, but I will examine process improvement tools more specifically in a future blog entry.)

Almost all structured problem solving methods hark back to Drs. Deming’s and Shewhart’s PDCA (Plan – Do – Check – Act) Cycle, which can be traced back further to early 1600’s England and Francis Bacon’s Scientific Method. Today’s DMAIC (Define, Measure, Analyze, Improve, Control) from Six Sigma, and the various numbered (5-, 6- 7-) step methods of problem solving, all stem from Deming’s and Shewhart’s methods.

Before a problem can be solved, we must define and get to the root cause of the problem. A technique called The 5 Whys can be used. This technique was gleaned from the 1970’s Toyota Production System (TPS), and can be useful for quickly getting to the root of a problem.

For example, assume that a late delivery on a project has resulted in an unhappy customer.

Apply the 5 Why method:

1. Why is the customer unhappy? = Because the project didn’t get delivered as promised.

2. Why didn’t project get delivered as promised? = Because the job took longer than anticipated.

3. Why did it take longer than anticipated? = Because the complexity of project was underestimated.

4. Why was the complexity of the project underestimated? = Because we made a rough estimate, ignoring the complexity of separate stages of the project.

5. Why did we do this? = Because we were running late on other projects.

It is now apparent that we need to revise our time estimation methods.

We can also apply The 5 Whys to a more typical molding problem; say a reject from a good customer:

1. Why did the customer reject the shipment? = Because of short shots and small dimensions.

2. Why did we get small parts and shorts? = Because not enough plastic got packed into the mold cavities.

3. Why didn’t enough plastic get packed into the cavities? = Because the molding machine wasn’t capable of doing this.

4. Why wasn’t the machine capable of doing this? = Because the melt index of the resin lot in question was too low and the machine became pressure limited.

5. Why didn’t we know this? = Because we didn’t do incoming resin inspection and/or set process alarms on the molding machine.

Conclusion: We clearly need to revamp our incoming resin inspection procedures and assure that our process/machine is robust enough to avoid this mistake in the future.

(To be continued next month)