[영어- 기타] 글게활성!!♡ GapTheory

[아낙수나문]

Introduction

The point in the title of this paper is not meant to support the notion that solutions should run around in search of problems.  Rather, it is to draw attention to the obvious, namely, that to solve a problem you must take action, you must intervene.  The search is always for a solution, a course of action that will produce the desired results. This is true regardless of the cause of the problem, if a cause can even be said to exist.   Moreover, the gaps in results that define the problems we attempt to solve come about in various ways — five to be specific.  In many cases we are not able to do anything about the origins of the problem and must content ourselves with bringing about the desired results through some avenue or agency other than that originally used.   In short, as a purely practical matter, we should generally forget about causes and focus on solutions.  But, before examining the ways in which problems come about and the general form of their solution, let us first spend a little time examining the basic notion of a gap as the basis for defining a problem.

The Murky Origins of Gap Theory

It is not clear who originated the concept of a problem as a discrepancy between actual conditions or what is and desired conditions or what should be.

Charles Kepner and Benjamin Tregoe lay claim to it in their 1965 book, The Rational Manager. In its annotated bibliography, they credit Herbert Simon with independently developing the same concept at about the same time.

The reference to Simon leads to research that Allen Newell, J.C. Shaw, and Simon were conducting at the Rand Corporation in the 1950s. Newell, Shaw and Simon were bent on developing a "general problem solver," a computerized problem-solving program. Their research culminated in Newell and Simon's 1972 book, Human Problem Solving.

John Dewey, the great educator, alluded to discrepancies as an element in the definition of a problem in his 1910 book, How We Think. Dewey's formulation of the problem-solving process was so sound that psychologist J. P. Guilford once observed that, with minor modifications, Dewey's steps have been rather persistent over the years.

Roger Kaufman, a noted authority on needs assessment, has been writing about needs as discrepancies in results for at least 35 years. Kaufman's view differs from most in that he uses a discrepancy in results to define a need and he defines a problem as a need that has been selected for resolution.

It seems impossible, then, to give credit to a single party for creating the concept of a problem as a discrepancy between what is and what should be. So, with credit given where credit is due, we can turn our attention to a much more important matter; namely, the ways in which gaps in results come about and what these origins say about the general form of the solution.

Five Gaps

Discrepancies between what is and what should be come about in four different ways, two of which can combine to form a fifth. These are briefly discussed and illustrated below.

Gap # 1: Something's Gone Wrong

This gap in results happens when things are going along just fine, what is and what should be are aligned, and then - Wham! - something changes and performance deteriorates, usually in a hurry. Blown fuses and tripped circuit breakers offer examples close to home. So do flat tires. "The computer just went down," is a phrase that should be familiar to many readers. This something's-gone-wrong problem is the kind on which Kepner and Tregoe lavished most of their attention. It exemplifies the category Harvey Brightman labels "operating problems." An important characteristic of this kind of problem is that the deviation in performance is from a previously attained level or standard of performance.

The search for a solution in this case is to first attempt to identify the change or changes that account for the fall off in results.  If it can be corrected, it makes eminent good sense to do so.  If it can't, some other means of closing the gap will have to be employed.

Not all discrepancies come about because of equipment, component or personnel failure, or other unwanted or unforeseen changes, and not all performance standards have been previously attained. There are other classes of problems to be considered.

Gap # 2: Raised Expectations

As the diagram above illustrates, a discrepancy in results also occurs when expectations are raised. Suppose a firm has been enjoying a steady but unspectacular rate of return on investment (ROI) of seven percent. Suppose a new CEO takes the helm and commands a doubling of this figure. A discrepancy in results exists. There is definitely a problem to be solved. But it owes to raised requirements, not because something's gone wrong. Any search for cause will be futile unless someone is willing to point the finger at the new CEO yet, the task of achieving the new goal remains.

This class of problem is neatly captured in Rajat Gupta's response to questions regarding the kinds of changes he planned on making when he became the new managing director of McKinsey & Company: "Nothing is broken," he said, "But our aspirations are higher."

An interesting and challenging variation on this class of problem occurs when expectations or standards are in a state of flux. In such circumstances, the goal is a moving target.

The search for a solution in this case amounts to a quest for new ways of operating or doing business.  There is nothing wrong with the old ways or old system; indeed, everything is (or was) working just fine.  But the old system and the old ways won't produce the new results.  Change, innovation, invention, redesign and perhaps reengineering are called for.

Sometimes, results deteriorate and expectations are raised at the same time.  This produces the next category of gap.

Gap # 3: The Double Whammy

Cost center and division managers are intimately familiar with this class of problem. It is referred to in some circles as "a double whammy" and in others as "caught between a rock and a hard place." Other terms for this class of problem include "between the Devil and the deep blue sea," "between the hammer and the anvil," "between the sword and the stone," and "between Scylla and Charybdis (the man-eater and the whirlpool). We have so many terms for this class of problem because such problems are so commonplace. A new system is rolled out, it doesn't work, and service delivery suffers as a result. At the same time, budgets are cut, and demands for improved service are made. On a grand scale, new competitors gobble up market share, eroding revenues and profits, and casting doubt on the value of the existing product line. Meanwhile, shareholders and analysts press for improved financial performance. (It is tempting to say that managers and executives who haven't faced and surmounted this class of problem haven't been adequately inducted into the mysteries of management.)

Just as this gap is created by a combination of circumstances, it is possible that the general form of the solution will entail a combination of measures, some amount of correction or remedying of things gone wrong coupled with some amount of innovation and invention.  Then again, it is also possible that it is not worth the time and trouble to try and fix things and so the general form of the solution will be that of redesigning and reengineering the system in question.

The first three cases we have examined all involve the creation of a gap as a consequence of some kind of change in the system.  In other words, up to a certain point, conditions have been acceptable.  In the next instance, this is not the case.

Gap # 4: It Never Did Work Right  (A "Day One" Problem)

More than one new system has failed to perform to expectations or requirements. The same can be said for many new products or procedures. Many problems can be cited as examples of what Kepner and Tregoe call a "Day One" problem, a gap in results that has existed since the system, product, or procedure was first introduced. Perhaps the best-known example of this kind of problem is "the lemon," a brand-new automobile plagued by one problem after another. The process called "systems development" has produced its share of computer-based processing systems deserving of the label "lemon." Some of these are now known as "legacy" systems. Poor specification, poor design, and poor execution are generally the culprits here.

Here is a situation in which the root cause analysis so favored by TQM devotees can play an important role.  Clearly, there is something wrong with the system, be it design or execution.  One avenue of attack is to take it apart, a piece at a time, and find and fix whatever is not functioning properly.  However, another approach is to simply scrap it and start over, to redesign and rebuild the system.

The four classes of problems presented so far have two qualities in common: (1) a history and (2) an existing system. The next and last kind has neither of these qualities.

Gap # 5: The Basic Engineering Problem

A distinguishing feature of this class of problem is its lack of history. In addition, there is no existing system to troubleshoot or diagnose. Results have been specified for the very first time. The goal is to design, build, install, operate, and maintain a new system that will produce the desired results. Any solution to this class of problem must be engineered C in every sense of the word.

According to Brightman, this situation calls for "strategic problem solving." Clearly, solving this kind of problem is not a matter of figuring out what went wrong or of figuring out how to cope with changed expectations. It most certainly is not a combination of the two. There are no "root" causes to be unearthed. It is this class of problem that most clearly calls for the first-time creation or engineering of a solution.  It is this class of problem that also most clearly calls into question the concept of cause.

The Concept of Cause

For many managers, executives, consultants, and academics, the concept of cause is defined in two basic ways. First, we will examine the Kepner-Tregoe view, then the Total Quality Management (TQM) view.

In the first edition of The Rational Manager, Charles Kepner and Benjamin Tregoe defined the cause of a problem as an "unwanted change." In so doing, they confined their problem-solving method to the "something's-gone-wrong" kind of problem represented by Gap 1 above. Sixteen years later, in The New Rational Manager, Kepner and Tregoe maintained their original definition of cause, but acknowledged circumstances in which the should be condition has never been attained. Kepner and Tregoe termed this a "Day One" problem. It corresponds to Gap 4, the "It-never-did-work-right" class of problem.

Under the precepts of TQM, the "root" cause of a problem must satisfy three criteria. First, it can be shown logically to explain the problem, that is, a cause-and-effect sequence can be traced. Second, it is directly controllable. Third, the effects of correcting it can be determined.

Root causes are not necessarily causes in the Kepner-Tregoe sense of unwanted changes, they are factors that contribute to the current state of affairs. In complex situations, the number of contributing factors is enormous. To isolate those few factors that can be said to "drive" a situation is the essence of effective analysis.  That is what makes this approach so useful in addressing a Day One problem or in wringing continuous improvements out of systems that are essentially performing to specification.

As an area of professional practice, TQM is blessed with numerous tools and techniques for eliciting and organizing knowledge of the factors affecting results. The Ishikawa or "fishbone diagram," tree charts, flowcharts, process charts, and various means of displaying statistical data come immediately to mind. But, whether or not the TQM tool kit contains the kinds of tools needed to engineer solutions to business problems from scratch is debatable. In general, in this writer's opinion, TQM tools support refining and improving upon existing business processes, but not engineering or reengineering new ones.

Most important, root cause analysis simply does not apply to problems created by new requirements or to novel situations. It is clearly most relevant when something’s gone wrong and to the Day One class of problem.

The Goal

Regardless of the origin or cause of the gap in the figures above, the goal with respect to all problems, regardless of how they originate, is to close the gap, to get from where one is to where one wants to be. This means all problems can be approached from the perspective of engineering a solution. But not all problems can be treated successfully by searching for, finding, and fixing causes, because not all problems have causes. Moreover, not all causes are controllable or correctable. When the stock market crashed in October of 1987, there were doubtless many people who would have liked to put things back the way they were the week before. That was clearly impossible.

There is an important point to keep in mind here. Pointing to causes beyond one's control is not an acceptable response. That things go wrong is understood. That these things very often cannot be corrected is also understood - and irrelevant. The task of the effective manager and executive is to innovate, to invent new ways of achieving improved results at lower costs. Pleading causes beyond one's control is to beg two tasks that are ever at hand: figuring out how to achieve the results desired and then achieving them. There are no excuses. Solutions must be engineered even if causes can't be found or aren't fixable.

Solution Engineering

A problem exists when there is a requirement for action coupled with uncertainty regarding the action to take. The requirement for action is generally rooted in a discrepancy between what is and what should be. This discrepancy alone is not sufficient to launch a problem-solving or solution-engineering effort. Not all discrepancies in results are reason for concern and not all are worth remedying. So, in addition to the discrepancy, there must also be dissatisfaction coupled with determination to do something about it.

To solve a problem, something must be changed. In complex systems, change is typically indirect. Results are achieved as a consequence of intervening at points that are often far removed from those where results are measured. Revenue, for example, is not increased directly, but is increased as the result of actions such as price increases (or price reductions), sales promotions, better-targeted advertising and so on.

When engineering a solution, the search is not for the cause of the problem but for those factors that, if changed in certain ways, would produce the result desired. This search is made more efficient and effective if it is carried out by systematically examining the structure of the situation in which the problem may be said to be "embedded."

Searching systematically through the structure of a problem for the factors to change to achieve some desired result is the essence of a goal-oriented approach to problem solving called "solution engineering." Solution engineering is marked by its intense focus on the solved state, on achieving what should be without worrying a great deal about why what is exists.  In short, with the exception of the first gap above, Solution Engineers generally forget about causes and focus on solutions.

[아낙수나문]

shut up man YO~

[어쿠스틱]

what's the point of this theory(of course i didn't read it)

[아낙수나문]

Me too.^.^ㅗ