One of the goals of production project activity is improving of the problem production situation. Regular problem situation can be improved using ordinary engineering methods. But some situations could not be improved by traditional ways. Such situations are induced by the complex problems, which can be solved only on the inventive level.

And the project becomes inventive project.

When we worked on the inventive projects (first of all for Samsung company) we tried a number of the well-known problem solving algorithms, methods and tools. Each one was suitable for certain goal. But full methodical supporting of the project could be organized only by the set of the all methods. Correct sequence of them using is also important.

TRIZ-expert work on the inventive project together with production team. Team stuff has to understand what we do on each stage and step of the project; what kind of information we need; which evaluation we need and so on.

We needed common algorithm of inventive project process, which has to be universal for different project types, which shows sequence of using necessary methods and which is understandable for both TRIZ-experts and customer specialists.

After finishing first ten projects we started to see some sequence of actions, draft of the common algorithm. We did first try of algorithm building, when SAIT Samsung starts systematic and mass TRIZ-learning. Paper authors (with the assistance of Vassily Lenyashin) developed algorithm of work on production inventive projects named Christmas Tree Diagram (because graphical view). The algorithm becomes the base of the e-learning system TRIZ-trainer.

First algorithm version has resources for improving. Algorithm describes detail how to solve the problem, which is separated from the situation. But analysis of the situation was not formalized enough. Therefore we continued to polish up the algorithm.

The article of Genrich Altshuller “Process of inventive problem solving: main stages and mechanisms” inestimable helped us. The article describes the systematic approach: how to move from a situation to a problem; how to get common solution; how to move from the common solution to technical and calculated ones.

We propose improved variant of algorithm of work on production inventive projects. This version describes the process of situation analysis. Stage of problem solving is upgraded.

 

Algorithm is illustrated by scheme (Fig. 1). It has two parts. Lower part illustrates work with situation. Upper part illustrates work with separated problem.The scheme peak is crowned with IFR (ideal final result). IFR is the main criteria for estimation obtained solutions.

Each key action of inventive project can be performed by various innovation methods, mini-algorithm and tools. Proposed algorithm organizes them into united structure, shows place and goal of each tool. Algorithm forms peculiar “control system” of thinking process.

 

 

Stage 1. Problem Situation Analysis

Problem situation is a situation with undesirable effect. Undesirable effect is visual consequence of some conflict between system parts. It is necessary to find the place, time and causes of effect appearance. We need to eliminate or weaken the conflict to improving situation. In other words we need to change system via solving inventive problem.

 

Step 1.1. Define key system

Input: Situation with undesirable effect in a situation.

Action: Research the problem situation.

Tools: Multi-screen scheme (3S-analysis), component analysis, structural analysis, functional analysis, flow analysis, value-engineering analysis.

Output: Defined a system with conflict.

Comment:

Situation with undesirable effect usually is filled with some objects: people, equipment, processes etc. Exactly that situation “participants” (components) generates the occurrences, which show as an undesirable effect. We learn which components can influent to the undesirable effect appearance. Then we separate system with those components and analyze it.

To define system composition and structure and to research functioning of it components we build technical system model and analyze it using 3S-analysis.

Also we apply the component analysis, the structural analysis, the functional analysis and the flow analysis if necessary.

The complex method of system analysis is value-engineering analysis.

 

Step 1.2. Reveal conflict

Input: Defined a system with conflict.

Action: Research the key system.

Tools: Root-cause analysis, "sabotage analysis”, “harmful system, laws of technology evolution, engineering experience, analogues.

Outputs:

System has not a significant conflict > transition to an improved situation.

System has conflict demanding elimination > transition to a step 1.3 (Find hypotheses of conflict elimination).

Comment:

Undesirable effect in situation is the consequence of true conflict inside system. We find the place and the time, define the disposition of the key conflict. The well-known and effective tool for those purposes is root-cause analysis.

Sometimes conflict has very deep causes, and it is difficult to find them. In this case we apply more powerful tools like “sabotage analysis” and “harmful system”.

Search of conflict becomes easily if we consider  typical places of occurrence of conflicts

After conflict defined we analyze:

Is undesirable effect real, or we see impressive but not dangerous occurrence?

Is undesirable effect significant to spend sources to eliminate conflict, or we can ignore it?

In simple cases the common sense is enough for estimation. If a situation is difficult, we use laws of technology evolution (specially low of ideality increasing) for estimation.

We build model of a desirable situation without undesirable effect or with very weak undesirable effect. Then using engineering experience and analogues we estimate costs of sources, time and work and to make decision about necessity of them spending.

 

Step 1.3. Find hypotheses of conflict elimination and formulate problems

Input: System has conflict demanding elimination.

Action: Formulate hypotheses how to eliminate the conflict.

Tools: Multi-screen scheme (BCA-analysis), engineering experience, analogues, methods of creative thinking activation, rules of formulating and ranging of the problems.

Output: Formulated problem (problems).

Comment:

Hypotheses can be formulated on the base of the engineering experience and analogous problems. Effective tool for formulation is multi-screen scheme.

Also we can use any methods of activation of creative thinking, like brainstorming, “Size-Time-Cost” technique, “Gold fish” method and so on. Skills of overcoming of mental inertia are very important here.

When we have set of hypotheses, we formulate problems on basis of them.

If there is a lot of problems, we define order of solving, in other words we range problems by special criteria.

 

 

Stage 2. Solving of separated problem.

Hill-like scheme is the most appropriate illustraton of the problem solving process. (Fig. 2). The scheme main idea is transformation real problem into a model, changing the model on the generalized level and then obtaining real solution.

 

The simple problems can be solved with applying only one model. If the problem is complex and difficult, it is necessary to apply several different models.

As a result, the scheme has a view like on Fig. 3. Several “hills” stuck up. Moving from problem to solution is repeated several times with growing of the model generalizations.

Proposed algorithm has four iterations of the work with four different problem models.

 

Step 2.1. Construct formalized problem model

Input: Formulated problem.

Action: Single out significant information from a condition of the problem.

Tools: Main useful function, operative zone, operative time, resources, ideal final result.

Output: Formalized problem model.

Comment:

Formalized problem description helps to know we have all necessary information or not and to delete unnecessary details.

On this step we define main useful function of improved system. We define which parameters of system components can be changed and limits of the changes. In other words we formulate restrictions of solving ways.

We define components of conflict zone and interactions between them (operational zone and time). Also we list available resources.

We make a main aim, IFR (ideal final result).

 

Step 2.1.1. Transform formalized problem model to abstract solution model

Input: Formalized problem model.

Action: Transform problem model to the solution model.

Tools: Problems-analogues, engineering experience, methods of creative thinking activation.

Output: Abstract solution model.

Comment:

We can use different ways to move from problem model to solution model on this iteration. The most obvious methods are problems-analogues and engineering experience with applying the methods of activation of creative thinking.

 

Step 2.1.2. Construct resource “portrait”

Input: Abstract solution model.

Action: Define requirements to a resource.

Tools: Rules of constructing the list of requirements to a resource.

Output: List of requirements to a resource.

Comment:

The list of requirements to a resource is detail description, “portrait” of the resource. The list of requirements to a resource is built on the first iteration and then added on other iterations.

 

Step 2.1.3. Find resource and generate solution ideas

Input: Abstract solution model + List of requirements to a resource.

Action: Generate the ideas.

Tools: Rules of search in accessible resources and the knowledge base, Effects, methods of creative thinking activation, methods of struggle against mental inertia.

Output:

There is a good concept (concepts) of the preliminary solution > transition to a step 2.6 (Construct final solution);

There is not good concept of the preliminary solution > transition to a step 2.2 (Construct parametrical problem model).

Comment:

Model of solution describes system components transformation very general. On this step abstract model of solution is filled by object content. Selected resources are added to a model description. To analyze and select resource we use resource “portrait”. If resource cannot be applied in the initial state we use different physical, chemical and other effects to modify it.

 

Step 2.2. Construct parametrical problem model

Input: Concepts of the preliminary solution of the first iteration + formalized problem model.

Action: Reveal the contradiction between parameters of system.

Tools: Rules of construction of the technical contradiction.

Output: Parametrical problem model (the technical contradiction).

Comment:

If the solutions obtained on the first iteration are not fully satisfactory, we move to the next problem model. It is parametrical model (or technical contradiction model).

 

Step 2.2.1. Transform parametrical problem model to abstract solution model

Input: Parametrical problem model.

Action: Transform problem model to the solution model.

Tools: 40 principles of elimination of technical contradictions, Altshuller's matrix and similar tools.

Output: Abstract solution model.

Comment:

To transform problem model into solution model we use 40 principles of elimination of technical contradictions, developed in TRIZ. For principle choice it is suitable to use Altshuller's matrix or table developed by D. Mann.

 

Step 2.2.2. Construct resource “portrait”

Similarly first iteration (in view of the information which have been already saved up in the list of requirements to a resource)

 

Step 2.2.3. Find resource and generate ideas of the solution

Similarly first iteration, except for an output

Output:

There is a good concept (concepts) of the preliminary solution > transition to a step 2.6 (Construct final solution);

There is not good concept of the preliminary solution > transition to a step 2.3.1 (Construct structural problem model).

 

Step 2.3. Construct structural problem model

Input: Concepts of the preliminary solution of the previous iterations + formalized problem model.

Action: Schematize an operative zone.

Tools: Su-Field model, SAO-model, “smart little people” model, component model.

Output: Structural problem model.

Comment:

On this step we try to describe the operational zone very exactly. There are several ways, like Su-Field model, SAO model, model of “smart little people” and component model.

 

Step 2.3.1. Transform structural problem model to abstract solution model

Input: Structural problem model.

Action: Transform problem model to the solution model.

Tools: 76 standard solutions, system of SAO-model transformations, rules of transforming “smart little people” model, structural analogy.

Output: Abstract solution model.

Comment:

Each type of structural model has own tool of transforming. 76 standard solutions are for transforming Su-Field model. Evolution lines are for SAO model. Model of “smart little people” is transformed by special rules. Component model can be transformed using structural analogy method.

 

Step 2.3.2. Construct resource “portrait”

Similarly first iteration (in view of the information which have been already saved up in the list of requirements to a resource)

 

Step 2.3.3. Find resource and generate ideas of the solution

Similarly first iteration, except for an output

Output:

There is a good concept (concepts) of the preliminary solution > transition to a step 2.6 (Construct final solution);

There is not good concept of the preliminary solution > transition to a step 2.4 (Construct “Physical contradiction” model problem).

 

Step 2.4. Construct “Physical contradiction” model problem

Input: Concepts of the preliminary solution of the previous iterations + formalized problem model.

Action: Reveal and formulate physical contradiction.

The tool: Rules of physical contradiction constructing.

Output: Problem model in the form of a physical contradiction.

Comment:

Physical contradiction is built when we precise define the conflict zone. The main point of the physical contradiction is alternative requirements are made to the one component of the system or even to the component part.

 

Step 2.4.1. Transform “Physical contradiction” problem model to abstract solution model

Input: Problem model in the form of a physical contradiction.

Action: Transform problem model to the solution model.

Tool: Principles of physical contradictions eliminating.

Output: Abstract solution model.

Comment:

To obtain solution model of the physical contradiction we apply principles of elimination of physical contradictions developed by TRIZ.

 

Step 2.4.2. Construct resource “portrait”

Similarly first iteration (in view of the information which have been already saved up in the list of requirements to a resource)

 

Step 2.4.3. Find resource and generate ideas of the solution

Similarly first iteration, except for an output

Output:

There is a good concept (concepts) of the preliminary solution > transition to a step 2.6 (Construct final solution);

There is not good concept of the preliminary solutions > transition to a step 2.5 (Find missing concepts of preliminary solutions).

 

Step 2.5. Find missing concepts of preliminary solutions

Input: Concepts of preliminary solutions received on iterations 1-4.

Action: Expansion of a spectrum of the preliminary solutions.

The tool: Evolution patterns, trees of evolution.

Output:

There is a good concept (concepts) of the preliminary solutions > transition to a step 2.6 (Construct final solution);

There is not good concept of the preliminary solution > transition to a step 1.3 (Find hypotheses of conflict elimination).

Comment:

If we pass through all iterations, we have a lot of preliminary solutions. It is useful to analyze them for widening search field and generating new ideas. For that purposes we use on patterns and trees of evolution.

 

Step 2.6. Construct final solution

Input: All concepts of preliminary solutions.

Action: Construct the final solution.

Tools: Methods of concepts estimation, merging of alternative systems.

Output: Final solution.

Comment:

The concepts of preliminary solutions are raw material for final solution building. First of all we select the most perspective concepts. Then we combine concepts or some parts or useful features into a single whole. Merging of alternative systems method can be applied for that purpose.

 

 

Stage 3. Analysis of changed situation

Algorithm is concluded with check-up stage. We have to understand

·         Is problem situation changed?

·         Is a change positive enough?

On this stage final solution has to be converted into the concrete technical proposal. Then we check

·         Is conflict eliminated?

·         Is situation improved?

 

Step 3.1. Make technical proposal

Input: Final solution.

Action: Describe the transformed system in technical terms.

Tools: Design of experiment, planning of experiments, Taguchi method, computer simulation.

Output: Technical proposal.

Comment:

We formulate a technical proposal on the basis of final solution. Technical proposal is concrete description of the changed system, which participates in the situation.

When we formulate the technical proposals, we conduct mental and real experiments and make expert estimation of the solution. There is a lot of method for that purpose, like design of experiment, planning of experiments, Taguchi method, computer simulation etc.

 

Step 3.2. Estimate conflict elimination in system

Input: Technical proposal.

Action: Estimate whether the offered solution eliminates the conflict in system.

Tools: Expert estimation, «sabotage analysis», laws of technology evolution, methods of creative thinking activation, engineering experience, analogues.

Outputs:

Conflict is eliminated > transition to an improved situation

Conflict is not eliminated > transition to a step 1.3 (Find hypotheses of conflict elimination)

Comment:

On this step we check whether proposed change eliminates bad interaction between system components?

Engineering experience and expert estimation help us. In the complex and very important cases we use “sabotage analysis” and “harmful system” to checking solution reliability.

Then we check situation improvement. Actions of this step are similar with actions of the step 1.2.

We build model of a desirable situation using laws of technology evolution and estimate delta between real and desirable situations.

If delta is small, conflict is eliminated and we obtain improved situation. Inventive project is completed.

Is delta is big, conflict is not eliminated. It may have four causes:

– We selected incorrect key problem.

- We solved the problem not very well. - We made mistake when formulated problems from hypothesis. - We formulated incorrect hypothesis.

In this case we select new problem which is formulated on the basis of other hypothesis or we find new hypotheses. Then we recycle.

 

 

Summaries

• The proposed algorithm describes whole process of the inventive project of problem situation improving.
• The algorithm shows sequence of using the main innovation methods.
• New methods can be included to the algorithm structure easily.
• The algorithm is universal, because included methods are various. Algorithm can be adapted to special problems or to solver preferences.

 

References:

1. Genrich Altshuller. The innovation algorithm. Worchester, Massachusetts: Technical Innovation Center. 1999, ISBN 0964074044. www.amazon.com

N.Shpakovsky. Using the tools of classical TRIZ in the “Christmas Tree” diagram.

www.gnrtr.com/tools/en/a06.html

3. N.Shpakovsky, V.Lenyashin, Hyo June Kim, E.Novitskaya. On-Line Training System “TRIZ-trainer”.  www.gnrtr.com/tools/en/a02.html

4. Genrich Altshuller.  Process of Solving an Inventive Problem: Fundamental Stages and Mechanisms. April 6, 1975. www.altshuller.ru/triz1.asp (on Russian)

5. Yu.Salamatov “TRIZ: The Right Solution at the Right Time”. Insytec, 1999

6. Darrell Mann. System Operator Tutorial 1) 9-Windows on the World.

www.triz-journal.com/archives/2001/09/c/index.html

7. James F. Kowalick. Tutorial: Use OF Functional Analysis and Pruning, with TRIZ and ARIZ, to Solve “Impossible – To – Solve” Problems.

www.triz-journal.com/archives/1996/12/d/index.html

8. Value Engineering (VE). Ministry of transportation. Ontario. 2004.  www.mto.gov.on.ca/english/transtek/ve/

9.  Root Cause Analysis.  SOLUTION systems, 2005. www.rootcause.com/ArticleManagementInsights.htm

10. Altshuller, G., B. Zlotin, A.Zusman, and V.Filatov. Search for New Ideas: from Insight to Technology. Kishenev, Kartia Moldavenayska, 1989.

11. V. Leniashin. Hyo June Kim. “Harmful system”. Using the concept in modern TRIZ. www.metodolog.ru/00859/00859.html

12. Yu.Salamatov, P. System of Technology Evolution Laws (Foundations of the Theory of Technical Systems Evolution). INSTITUTE OF INNOVATIVE DESIGN. Krasnoyarsk, 1996г. www.trizminsk.org/e/21101000.htm

13. Val Kraev . Overcoming Mental Inertia. www.triz-journal.com/archives/2007/08/05/

14. N. Khomenko. OTSM: introduction. Electronics, Learning Center. Pyuangtek, 1999.

15. Z. Roizen. Specifics of using of the resources for problem solving and solutions developing. (paper for 4-th seminar in Petrozavodsk-87).

16. Gregory Frenklach Classifying the Technical Effects. www.triz-journal.com/archives/1998/03/a/index.htm

17. G.Altshuller: 1997, 40 PRINCIPLES: TRIZ Keys to Technical Innovation. Worchester, Massachusetts: Technical Innovation Center. ISBN 0964074036/ www.amazon.com

18. Mann, D.L., Dewulf, S., Zlotin, B., Zusman, A., ‘Matrix 2003: Updating the TRIZ Contradiction Matrix,’ CREAX Press, 2003.

19.  John Terninko, Ellen Domb & Joe Miller.  The Seventy six Standard Solutions, with Examples Section One. www.triz-journal.com/archives/2000/02/g/index.htm

20. Component Analysis. triz-world.wetpaint.com/page/Component+Analysis?t=anon

21. Victor R. Fey, Eugene I. Rivin. Guided Technology Evolution (TRIZ Technology Forecasting).  www.triz-journal.com/archives/1999/01/c/index.htm

22. Elena Novitskaya. Transformation of structurally similar elements of technical system. gnrtr.com/tools/en/a09.html

23. Semyon D. Savransky . Lesson 4 Contradictions. www.trizexperts.net/Lessons3Examples.htm

24. N. Shpakovsky. Evolution Trees.  Analysis of technical information and generation of new ideas.  Puls. Moscow. 2006.

25.  S.Litvin, V.Gerasimov. “Development of alternative technical systems by incorporating them into supersystem”. Proc. ICED 91 Zurich, Vol. 1, 1991, pp 42-45.

26. John Hsing. Conflict Resolution Using TRIZ and Design of Experiment (DOE). www.triz-journal.com/archives/2001/05/b/index.htm

27. Taguchi methods. Wikipedia, the free encyclopedia. en.wikipedia.org/wiki/Taguchi_methods