Mark G. Barkan
Principal, Concept Catalysts, Inc.
mark@concept-catalysts.com
The thoughts in this paper are the result of many years of
attempts at solving various problems, technical and “soft”. These thoughts
have been discussed with my fellow TRIZ practitioners around the world. Over the
years I recorded many conversations. However, I did not always remember who said
what and when. Thus, the references to written or verbal information that
accompanied my thought process can be found in the body of the paper only. Those
who believe they are omitted, please stake your claim in a letter to the Editor
of the TRIZ Journal.
The need to solve problems is as old as the human
civilization. From the earliest years of the history to the present times we are
faced with a number of issues, which require resolution, on a daily basis. The
two main reasons for problem solving emerged: 1) something around us is not to
our liking, thus we need to do something to improve this situation to conform to
our beliefs; 2) something potentially useful exists independent of our
observations and perception, thus we need to discover this phenomenon and put it
to use. The issues of the first kind are as simple as itching back that needs
scratching, or so we think. The issues of the second kind could be as complex as
differential equations, which, once discovered, can help describe a vast number
of natural events.
The itching back, however, may be a result of some
malfunction of our body, which may lead to a worse problem than simply itching.
Here we face the first question - did we, or did we not, solve the problem. The
answer, of course, is yes and no. Yes on the level of the symptom - itching, and
no on the level of the real reason for itching. So, what is required to assure a
problem solving process addresses the right issue?
Usually, a project process involves the following steps:
1. Recognition of a need - to me it means that the
functional requirements have been clearly defined and stated;
2. Generate ideas on how to fulfill the need;
3. Develop viable concepts based on generated ideas;
4. Perform design based on the concepts;
5. Implement the design.
A need can present itself in many forms and shapes. It could
be a particular manufacturing or performance issue, or it could be as general as
- find the way to improve product/process. What is the normal response to a
problem? In many instances, people, responsible for problem solving, start
generating ideas immediately. Quite often, for various reasons, these very
people have limited knowledge about the system, which houses the problem in
hand.
Over the years many different methodologies were developed to
aid the problem solving process. Most of those methodologies concentrate on
generating as many ideas as possible in a short period of time. The main issue
here is the time required to sort and select the best ideas. The idea generation
sessions are usually facilitated by an expert in this or other methodology. The
most used methodology in team environment is Brainstorming.
Some 6 months ago I facilitated TRIZ supported problem
solving process for a team made up of 15 people from 15 different organizations
providing various services in the same field. The team just ended a two-week
Brainstorming session, which resulted in some 17 pages of ideas. We were invited
to help with some promising ideas, which did not have clear path to
implementation. In other words, there were some technical issues/problems that
had to be resolved in order to implement those ideas. After 45 minutes of
questioning we discovered that the members of the team did not agree on the goal
of the exercise, nor did they develop any criteria for evaluation of generated
ideas. In my practice this is not an isolated case.
Here I would like to compare a problem solving process to a
legal case. The US justice system requires withholding judgment until all the
facts are known, until all the biases and preconceived notions of guilt or
innocence are set aside. We all should display similar discipline when we are
faced with a problem. In my opinion, the best way to acquire the knowledge
sufficient to engage in a problem solving process is to perform an in-depth
functional analysis of the system/situation. The model I prefer to use when I am
in a problem solving process is as follows:
1. Organize the knowledge about the system/situation;
2. Develop a functional model of the system/situation;
3. Analyze the model for problem solving ideas
1. Organize the knowledge about the system/situation
Miles recognized the need for functional analysis in the
1940s. He also recognized the difference between the intent of the design, “what
it must do”, and “how it does it”. This is a very important distinction.
Many a times I was present in a meeting for a discussion of “what to do”,
which quickly degenerated into a discussion on “how we will do it”. Miles
has developed a list of questions enabling the understanding of intended
function.
Since Miles started his work, a number of questionnaires,
which address various aspects of the system/situation, were developed. Some are
more effective than the others. Boris Zlotin and Ideation team developed the
Innovation Situation Questionnaire (ISQ). Zlotin, one of the most prolific
problem solvers, once described to me his experience a long time ago when the
management of the company he worked for recognized his problem solving skills
and appointed him an in-house problem solving consultant. Thus, his job was to
solve problems. He was soon dismayed by his inability to solve a single problem.
The reason was quite simple - in his new position he did not have anybody
bringing any problems to him. He quickly recognized the fact that in order to
solve a problem he had to find it first. That's when Zlotin started
development of what is known today as the ISQ. The ISQ is amply described in the
“Step-by-Step TRIZ” by Terninko, Zusman, and Zlotin. The power of the
questionnaire was demonstrated in many instances. The most recent I observed at
NC State University School of Textiles where Drs. Clapp and Slocum teach a
semester long TRIZ course. A graduate student, who did not have a chance to join
the class, was advised by Dr. Slocum to read the “Step-by-Step TRIZ”. That
student applied the ISQ to his research project. He followed the ISQ with a
functional model of the system. This process resulted in 7 ideas on how to
proceed with the project. 4 of those ideas were accepted by student's advisor
for immediate implementation.
A simple functional analysis of a ballpoint pen we did with
Drs. Clapp and Slocum's class revealed a few additional, unintended,
functional capabilities. For one, a ballpoint pen can be used as a weapon. When
I described this experience to Len Kaplan, he quickly recalled that a plant in
Kishinev, Moldova, produced a batch of ballpoint pens, which housings were made
from wound wire. The entire production run was purchased by a battalion of local
paratroopers. With this knowledge we may then follow with either designing a
ballpoint pen, which can't be used as a weapon or offer a special design,
enhancing weapon functionality. In short, the value of the process/product can
be improved significantly when we have good understanding of functional
requirements and capabilities.
There is no hard format for a questionnaire. However, it is
important to collect information, essential to problem solving process. Some of
the most important questions we deal with are the nature of the problem/issue,
why it is a problem/issue, who/what will benefit from successful resolution of
the problem issue. The next level of questioning should address the structure of
the system, its functionality, existing resources, all of the
restrictions/limitations placed on the system and their history, the history of
the attempted solution is important in that it may illuminate the reason this or
other suggestion did not work. Here we need to remember that volumes are written
about successful undertakings, and a single sentence about a failure. Yet, the
information about failed attempts normally provides very good basis for problem
solving.
One important note: There is no single questionnaire that can
satisfy every situation. A person facilitating a problem solving process should
be skilled enough in the process so he/she can come up with additional
questions, unique to the particular situation.
2. Develop a functional model of the system/situation
The next step in the process is a functional diagram of the
system/situation. In the early 1970s Bytheway developed Function Analysis System
Technique or FAST process. The FAST process supports development of a graphical
model that provides means of communication between the members of
cross-functional team. Here, the system is described on a functional level in
such a way that it ties together every component of the system. There are a
number of different modeling techniques in existence today. Among them is the
Su-Field model developed by Altshuller and his students. In 1980 Dr. Y.B.
Karasik discussed the dual nature of most objects and functions and expressed
potential interrelations between the objects in a functional diagram.
Ideation International Inc. has expanded on those ideas by
developing its own functional modeling tool - Problem Formulator, PF. PF is a
step forward, compared to FAST diagram, as it registers harmful in addition to
useful functions. Further, the algorithm of the software enables automatic
formulation of questions, answers to which provide potential pathway to
solution. Problem Formulator, in my opinion, is not an accurate name for the
tool. First and foremost, it is a functional model of the system/situation.
Let's take a look at “Itching back” diagram:
A simple analsis of the above diagram reveals some
information, which is known, yet is not normally considered. For example, the
fact that scratching, along with elimination of itching, may cause spread of
rash is not usually in person's mind when itching is irresistible. This
information may be utilized for solving the problem as well as for in-depth
failure analysis process.
How best to transition from a questionnaire to a model? To
start with, we need to remember the system approach, which identifies the
system, sub-system, and super-system. One may ask - what does the system
approach have to do with building a functional model of the system? The answer
to this question is quite simple - we need to have a very clear picture in our
head of where we need to start and where we need to finish. On what level we
want to enter the system for best results of model analysis? When we are looking
at the itching issue, discussed above, what is the system we want to model? Is
it the itching? Or, is it the itching spot? Or is it the entire back? Or is it
the entire body? There is no uniform answer to these questions. Each situation
will dictate the most fruitful approach. However, there are few rules that may
help in building a model.
First, we need to be at least one level above the level of
the perceived problem. For example, when discussing a cooling system in the deep
mine what is the system? Is it the cooling system? Or is it the mine? I
recommend the mine for a simple reason - entering the system on the problem
level may cause addressing the symptom rather than the real issue. On the other
hand, when looking to develop a new material we need to start on the bottom,
physical, level of required functionality. That's where we address the
fundamental properties and atomic interactions. At times, we are forced to ask
additional questions to clarify the issues, which arose in the process of
building a diagram. This step of the problem solving process requires, like the
first step, participation of the experts in the field of application.
3. Analyze the model for problem solving ideas
Once the model is ready, it provides a very good basis for
problem solving in a team environment. The functional model is an excellent
generator of questions, answers to which will help idea generation on
system/situation improvement. Since it's a functional model it captures
useful, intended, functions and harmful, unintended, functions. Thus, the
contradictions are easily recognized as a conflict between useful and harmful
functionality of the system's segment or component. We can clearly see useful
functionality we can attempt to enhance, as well as harmful functionality we can
attempt to eliminate or diminish. We can now make a well-supported decision
concerning the area of the system, which, once addressed, will provide the best
return on invested time and other resources.
The “Itching back” diagram provides such questions:
·
There are two contradictions: one is “Food
intake”, which provides “Nourishment”, yet may cause “Internal
disorder”. Therefore, the question here is how to avoid “Internal
disorder” resulting from “Food intake”. The other contradiction we
discussed earlier, it concerns “Scratching”.
·
Clearly, food intake alone is not the cause of
internal disorder. It will cause internal disorder if the food is spoiled.
Therefore, the question here is how to prevent “Spoiled food”.
·
Another question is how to intensify “Proper
nutrition” to better eliminate/prevent “Internal disorder”.
The functional model provides specific questions and tasks,
which can be solved by one or other TRIZ tools. Again, we use functional
characteristics to derive analogy by comparing our situation to many examples,
which guide application of TRIZ tools.
Conclusion:
Although it is conceivable to improve the system/situation
without an in-depth functional analysis, it is much easier task after we gained
good understanding of the benefits and ills of the system/situation.
References:
1. Bytheway, Charles W. “The Creative Aspects of FAST
Diagramming”, SAVE Proceedings, Vol. VI, 1979, pp. 301-312.
2. Miles, Lawrence D. “Techniques of Value Analysis and
Engineering”, Second edition. McGraw Hill, Inc., 1972
3. Terninko, John; Zusman, Alla; Zlotin, Boris. “Step-by-Step
TRIZ: Creating Innovative Solution Concepts”, Responsible Management,
Inc., New Hampshire, 1996.
Mark G. Barkan holds a Ph.D. in Mechanical Engineering and an
MBA. He has over 30 years of experience in engineering and engineering
management. He holds a number of patents in different fields of technology. He
began practicing and teaching TRIZ in 1991.
