Editor | On 25, Apr 2000

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.