Compumrsin&£ngn$VoL 31,No. 1/2,pp. 17- 20,1996
Copyd~O t996Elm,letScimceLtd
Pergamon
~ S0360.83S2(96) 0 0 0 6 8 - X
in GreetBdtlda. All riltlZ,leea,ved 0360. 8357.~s St5.oo + o.oo
TEACHING PROBLEM SOLVING SKILLS
Gary P. Maul
John S. Gillard
The Ohio State University Department Industrial Engineering Columbus OH 43210
Honda of America Manufacturing Senior Staff Engineer Marysville OH 43040
Recently, industrial managers have expressed concern over the problem solving skills of newly graduated engineers. In industry, not responding quickly to problems causes losses in income, profit, and market share. This suggests that there may be a need to teach these skills, but first several questions must be addressed. The first question is "What is a problem?" For an engineer, every task is often viewed as a "problem". By this definition; making a tough decision, having to plan an activity or having to make an analysis are all problems. But each of these is not how we will define the word "problem". Something is a problem when what has happened is significantly different from what you reasonably expect to happen.(1) Clearly, a problem represents a difference between what is expected and what occurs.
the question, "Can problem solving be taught or is it a talent some are born with?" Mr. Fujisawa, cofounder of Honda Motor Company, was concerned with this same question. He, Mr. Honda and the other founders of the company were very adept at solving problems, They skillfully used the Socratic method by asking questions until the root cause of a problem was found. They knew, however, the company was growing far beyond their individual reaches and that they could not expect the next generation of Honda management to have the same natural talents. Mr. Fujisawa's solution was a combination of the East's deep reverence for asking questions and the structured processes of KepnerTregoe, a Princeton, New Jersey firm. Mr. Fujisawa believed that the most important trait of a good manager was the ability to ask the right questions. Today, learning the Kepner-Tregoe process is required of all Honda management-level associates.(2)
This is best understood with a sports analogy. A 300 hitter, in a lengthy slump, now hitting only 150, very likely has a problem to solve. The word difference must be tempered by significance. Often small differences near artificial limits are the subject of unwarranted concern and "problem solving" study. Missing the goal of producing 1,000 cars per day, a normally achieved goal, by one or two units is significant only when thinking of a binary goal. This is time consuming at best and often counterproductive. Control charts are the surest method for determining if a change is significant. A problem and a "special Cause" are the same thing. Many problems arise in situations where charting is not done. In these cases, a simple line graphs can clearly indicate problems. By introducing charts it implies problem solving is a formal process needing mathematical formulae. This is not true. The vast majority of the time, problems can be solved using a few logic tools.
The success of this approach can be shown in two examples. The first used a case study in the Harvard Business review.(3) It was given to several small teams of Honda of America Manufacturing (HAM) associates. Some of these teams had associates who had taken one of Honda's Problem Solving classes, and some did not. The case concerned a Stamping supplier to a fictional automaker. The HAM teams who had been taught problem solving all found the root cause within one hour. Additionally, several of the teams separated the situation into two problems; a technical one and the human actions which lead to an unproductive environment. The solutions the HAM teams came up with were clearly better than those in the follow-up HBR issue.(4) The second example is not a classroom example. A problem appeared occasionally on the right side of Accords. The frequency of defects fluctuated, making it difficult to pinpoint the cause. Six workstations adjusted their procedures and added
Some people seem to have a natural talent for problem solving. Most of us are not so lucky, we lurch along the process from trial to trial. This begs 17
18
19th International Conference on Computers and Industrial Engineering
jobs to compensate for the problem. This problem was given to an Attack Team of associates trained in problem solving. By focusing on the differences between the left and right sides of the car, the team was able to find the most probable cause was a robotic welder that welded in the opposite direction on the right side than it did on the left side of the car. It took 15 minutes to reverse the direction of the welder, and the problem went away.(5) Both these examples demonstrate with anecdotal evidence that problem solving can be taught. There are many other examples available within Honda that show this.
The most productive portion of the class is having the associates apply the techniques to a problem in their work area. As a result the associates learn by doing. In a recent interview, Arno Penzias said it best, "I think we've tried acquiring knowledge too much to at school. What did you do most in school? I daydreamed a lot. It's only at the graduate level, when you're learning by doing, that you stop wasting time. "(8)
There are two points in an engineer's career that problem solving should be taught. The first is when engineers graduate and leave school to begin professional practice. They have been well educated in the individual tools of their profession, however, they have not been trained in the steps of problem solving or to put it another way, when to use these tools. It is very similar to teaching someone how to use a hammer and saw, calling them a carpenter and then asking them to go build a house. In school, the use of the tools was not focused toward the integrated activity of house building.
This ensures that classes and teams will include both theoretical knowledge and hands on experience. The diversity of these teams also helps to overcome two common problems; "Paralysis by Analysis" and "Extinction by Instinct." Engineers are often drawn to numbers, while those with expertise are drawn to intuitive styles. Both have their disadvantages. Formal analysis often has a bias toward negative responses and an inability to deal adequately with nonquantifiable values. Intuition is unduly influenced by recent or vivid events and often underestimates the role of variation.(9) As a result, teams of only the engineers find the root cause quickly, but are slow in finding a practical way to implement it. Teams of experienced associates tend to jump on what is familiar and worked in the past. Working together the teams quickly come to practical solutions. The secondary benefit is the respect that is gained for each other by working together.
The second point is when the logic and processes of problem solving can appear too simple and unsophisticated to the recent graduate as the power of these techniques may not be evident. It is only after being stuck with an unsolvable problem, that the engineer develops the need for this process. Dr. David Baltimore, a Nobel Laureate, in a recent commentary stated "Scientific knowledge is not just found in books and journals; hands-on training and the apprentice relationship is necessary".(6) The same holds true for teaching problem solving. Teaching problem solving is best done by a combination of classroom and on-site instruction. This is essential in order to change the process from an interesting brainteaser into a useful tool. Using examples from the workplace describes what the Marine Corps calls The Fog of War. "All actions in war take place in an atmosphere of uncertainty--- the fog of war. Uncertainty pervades battle in the form of unknowns about the enemy, about the environment, and even about the friendly situation. While we try to reduce these unknowns by gathering information, we must realize we cannot eliminate them." The pressure on an engineer is far less than the pressure on a Marine Officer in combat, but both must learn to work with incomplete, inaccurate, or even contradictory information.(7)
HAM specifically includes associates from diverse educational backgrounds when putting problem solving classes or teams together.
To summarize our experience, problem solving should be defined as a difference between what actually happens and what is expected to happen. We believe problem solving is a critical skill for engineers who work in manufacturing and that it can be taught. When to teach this skill is critical in the professional development of an engineer. We believe it needs to be taught immediately following graduation or when the engineer is confronted with what seems to be an unsolvable problem and may have forgotten the problem solving method. At this point the engineer has a definite need to know and probably a strong motivation to learn how to apply this skill. In teaching problem solving, class or team make up is critical to ensure a sound course of action and a balance between theory and pragmatism. This skill is most effective when learned by doing.
19th International Conference on Computers and Industrial Engineering
19
References 1.
2. 3.
4.
5.
Charles H. Kepner & Ben Tregoe, the New Rational Manager, Princeton NJ, Princeton Research Press 1981. Richard Pascale, Managing on the Edge, NYC Simon & Schuster, 1990. Perrin Stryker, "Can You Analyze This Problem," Harvard Business Review, MayJune 1965 pp. 73-82. Perrin Stryker, "How to Analyze That Problem," Harvard Business Review, JulyAugust 1965, pp. 99-110. Internal HAM Document.
6.
7. 8. 9.
Dr. David Baltimore, "America: The Land of Scientific Opportunity," New York Newsday August 15, 1995, pp. A15. US Marine Corps, Warfighting, NYC, Currency Press, 1994. Dr. Arno Penzias, Forbes 5/22/95 pp. 244. Ann Langley, "Between "Paralysis by Analysis" and "Extinction by Instinct" Sloan Management Review Spring 1995 pp. 63-76.