Blog

Home Blog The tangled story of value analysis

The tangled story of value analysis

The tangled story of value analysis…

…or how function ranking evolved

Prologue

Something interesting happened to me recently. During one of the meetings with several TRIZ Masters, a lively discussion arose about function ranking. Soon, topics started to appear that completely surprised me. They were so new to me that I began to wonder whether we were still talking about my TRIZ.

For me, ranking has always been straightforward. We have two categories of functions – useful and harmful. The harmful ones don’t take part in the ranking; the useful ones are divided into basic, additional, and auxiliary. The only criterion for evaluation is the target of the function. If it’s directed at the system’s goal, we give it the maximum score; if it’s aimed at another component of the supersystem, we rate it a bit lower; and if it acts on another component of the system, we treat it rather modestly, giving it the lowest number of points.

We list all the functions a component performs, and the sum of the points gives us its function index. And that’s it – job done.

We were told that, in the past, the scoring was also verified by the level of performance. However, since it didn’t really work well in projects and added a lot of extra effort, that step was eventually abandoned. Today, we still look at the performance level – whether it’s adequate or not – but not to multiply the score we gave the function. Instead, we use it to identify a function disadvantage, which will later become the problem we need to address to reach the project’s goal.

And suddenly someone tells me that auxiliary functions are not that black and white after all. That the meaning for the system differs when the object of the function is a component performing a basic function, and when it performs an auxiliary one. And that those auxiliary ones may be either closer to the former or further away from it.

…Wait, what?

That caught my attention. I decided to dig a little deeper and understand it better. Once I asked questions, read, and listened, everything came together into a fascinating story that I’d like to share with you. This story intertwines several layers of how the methodology evolved. You’ll see names and brands, numbers and formulas – all tightly connected. And since they are so interlinked, I decided not to separate them. After all, I believe I’m not the only one who finds this story worth exploring.

How value analysis came to be

The story of function analysis begins far beyond the homeland of TRIZ – in the American industry of the 1940s. During World War II, Lawrence D. Miles, a purchasing manager at General Electric, faced a serious problem: chronic shortages of materials and components. Production had to continue, even though many parts were simply unavailable [2].

While searching for substitutes, Miles made an observation that became a turning point: many elements could be replaced with cheaper or simpler ones – if only you understood what function they actually performed in the system.

This is how Value Analysis (VA) was born – a method aimed at increasing a product’s value by maintaining or improving its functions while reducing costs. Miles suggested that engineers should look at each element not through its name, shape, or material, but through what it does.

The key step was to define each component’s function using a simple verb + noun structure, for example: maintain pressure, conduct electricity, seal connection. Then, the cost of performing these functions was analyzed to find ways to achieve the same effect at a lower cost.

This shift of focus – from what it is to what it does – opened a completely new perspective in technical design. Value Analysis soon evolved into Value Engineering (VE), a more systematic method for optimizing projects and processes. Before long, it began to influence other fields as well. Among those who drew inspiration from Miles’s work were the founders of TRIZ, who used it as a foundation to build one of the key tools of their methodology.

Genrich Altshuller and his colleagues were familiar with Lawrence D. Miles’s concept of value analysis, and its function-based thinking turned out to be highly inspiring. It allowed them to look at a system not as a collection of parts, but as a network of mutual function interactions – some useful, others harmful.

In TRIZ, value analysis was transformed from an economic tool into an analytical one. Its purpose was no longer to indicate what could be made cheaper, but to identify what in the system works poorly, what works insufficiently, and what is entirely unnecessary.

And that’s how function analysis was born. It became the foundation on which value analysis was later rebuilt – in the TRIZ way.

What value means in TRIZ according to the MATRIZ methodology

In TRIZ, value is defined as the ratio of the normalized sum of a component’s function points to the normalized sum of its costs. That’s the official definition adopted by MATRIZ today [1].

Figure 1. In state-of-the-art TRIZ, value of component is understood as the ratio of a normalized sum of its function points over the sum of its costs.

To calculate the normalized cost sum – the denominator of this ratio – you don’t need any TRIZ knowledge. The numerator, however, is a different story. The sum of functional performance, also known as the function index, is specific to our methodology. Still, even a first-level student of TRIZ education already knows how to calculate it.

Yet, the way value – and more precisely, the function index – is calculated has evolved along with the methodology itself. The echoes of this evolution can still be heard across the community, which is why you may encounter several different approaches. These differences can sometimes cause confusion, especially among those unfamiliar with the finer details.

The pre-digital beginnings

From the moment TRIZ borrowed the idea of value analysis from Larry Miles to the present day, the tool has come a very long way.

In 1982, the magazine Technology and Science published an article titled FCA in Action (ФСА в действии) by Vladimir Gerasimov and Boris Zlotin [3]. It described a project focused on performing a function-cost analysis for a popular household meat grinder. The article provides an invaluable historical insight into how, more than forty years ago, engineers evaluated the components of a system.

For each component, they prepared a diagnostic table containing:

a description of its functions,
a percentage indicating its contribution to the main function of the device,
economic data related to manufacturing difficulty, material consumption, etc. (also expressed in percentages), and
and a column with the rather mysterious heading “degree of concern”, showing a subjective assessment of how troublesome the component was for various stakeholder groups – designers, technologists, quality inspectors, users, and others.

This made it possible to compare the importance of each function with the cost of performing it and to detect elements with low functional efficiency (high cost – low usefulness). Notably, while the cost data came from economists, the assessment of functional importance – that is, the component’s contribution to the main function – was made by experts.

The evaluated functions were then entered into a function matrix, where the rows represented components, the columns represented functions, and each cell contained one of the following symbols:

B – basic function (основная)
A – auxiliary function (вспомогательная)
H – redundant or harmful function (ненужная / вредная)

The matrix helped identify components with the greatest improvement potential – those with high costs and low functional importance. It also made it possible to distinguish between functions that were essential and those that could be eliminated, simplified, or combined. Moreover, it helped indicate which functions required redesigning their implementation – for instance, excessive torque needed to tighten a nut, difficulty cleaning the grid, or an overly massive housing

The evaluation was carried out by a committee, working as a team. At that time, there were no mathematical models yet for calculating value, and the rating scales were mostly qualitative or percentage-based. Moreover, functions were analyzed in parallel with costs, not separately from them.

Compared with today’s version, the method looked rather primitive. But it worked – and it caused quite a sensation. Each new project brought fresh experience, and with it, the method became more structured and mature.

The digital revolution

In the late 1980s, a project called the Invention Machine (Изобретающая машина) was launched in Minsk – then part of the Soviet Union, today the capital of Belarus. The initiative and its driving force was Valeriy Tsurikov, who, together with his team, set an ambitious goal: to bring Altshuller’s TRIZ methodology into the digital environment. This is how the first Inventing Machine software was created.

At that time, a consulting group called Algorithm (Алгоритм) was operating in Saint Petersburg, bringing together TRIZ experts working on industrial projects. Algorithm did not provide training. The team’s experts developed their own tools and possessed deep knowledge – knowledge they did not share publicly but used exclusively in their consulting projects.

In the early 1990s, as Tsurikov’s program began to be sold across the CIS and in the United States, he invited Algorithm to collaborate. He needed advisors and professional solvers who could effectively demonstrate the software’s capabilities.

The joint effort of programmers and consultants led to the creation of TechOptimizer™, released in 1992. At first, the program offered a rather modest set of TRIZ tools – inventive principles, standard inventive solutions, and a library of scientific effects.

By the mid-1990s, the team had begun working intensively on developing the analytical module – specifically, on function analysis. At that time, value analysis was one of its key components. It guided the directions for component development and provided crucial recommendations for trimming.

The program incorporated a model that reflected the way Algorithm’s experts calculated value:

The formula essentially meant that a component was considered more “valuable” the more it contributed to the system’s performance, while costing less and causing fewer problems.

The cost of each component had to be entered into the formula manually. The function rank and problem rank were calculated automatically by the program, which also normalized all values to make them dimensionless. CALCULATED! These were no longer qualitative judgments made by a group of stakeholders, but a fully numerical model.

Let’s take a closer look at how these calculations worked.

Each function was assigned a rank, representing its importance in the system. The closer a function was to the basic function, the higher its rank.

Figure 2. Model of assigning ranks to system functions.

Model of assigning ranks to system functions:

If the object of the function was the target component, the function received the highest rank – basic (B).
If the object of the function was a component performing a basic function, the function received the rank auxiliary 1 (A1).
If the object of the function was a supersystem component other than the target component, the function also received the rank auxiliary 1 (A1).
If the object of the function was a component performing an A1 function, then the function received the rank auxiliary 2 (A2 = A1 + 1); if it acted on a component performing A2, its rank became A3 = A2 + 1, and so on.

The point values for each function were then assigned as follows:

the function farthest from the basic function (by i levels) received the rank Ai and 1 pt.
The function one level closer received the rank A(i–1) and (1 + 1) pts., the next closer one A(i–2) and (Ai + 1) pts.
The function whose object was the carrier of the basic function received the rank A1 and i pts.
The basic function itself was assigned A1 + 2 pts.

The figure below illustrates this with an example. Functions performed by components 3 and 4 are two levels away (i = 2) from the basic function, so they receive the rank A2 and 1 pt. The function performed by component 2 is one level closer to the basic one, so it receives the rank A1 and 2 pts. The basic function is assigned A1 + 2 pts., which equals 4 pts. The function performed by component 5 is directed at a supersystem component other than the target component, so it also receives the rank A1 and 2 pts.

Figure 3. Example of assigning ranks and points to individual functions [5].

Just like today, the highest value was given to the function directed straight at the target component. Functions acting on supersystem components and system components were rated lower, but the point values and ranks were distributed according to a slightly different system than the one used today.

That covers the function rank – the numerator in the formula for a component’s value (see Figure 1). The denominator contained the problem rank, which indicated how many difficulties a given component caused – for example, whether its functions performed insufficiently, excessively, or even harmfully. Each such deviation from the desired state increased the problem rank, thereby lowering the component’s overall value. But that wasn’t all. In addition, each parameter was assigned a weight reflecting its importance to the project’s goal – meaning that not all problems counted the same. As a result, the problem rank represented the overall scale and significance of the actual problems within the system, not just their number.

The formula implemented in the program to calculate it looked rather… scary:

Figure 4. Formula for calculating the problem rank in TechOptimizer™. Source: TechOptimizer Fundamentals [5].

Here h is the total number of functions (both harmful and useful) performed by a component; n_i is the total number of parameters that describe the i-th function of this component; the summation index p identifies a specific parameter that describes the ith Function; P_actualand P_desirable are the actual and the desirable parameter values, respectively (each can be a mean value of several measurements); Δ is the acceptable deviation between the actual and the desirable parameter values; and s_pi is the problem significance coefficient, which has a higher value if solving a particular problem will significantly influence the project objectives. When there is no discrepancy between the actual and the desired values of a function parameter, this parameter does not contribute to the problem rank of this function [5].

OMG… someone actually managed to remember all that?

Maybe so – but it didn’t really matter. The formula was buried deep within TechOptimizer™, known only to the Algorithm consultants. It was eventually published in the official TechOptimizer Fundamentals manual [5], but there was never a need to teach it during training sessions – the program did all the work for us. The training focused on using the software, not on explaining the math behind it.

What happened next

The model developed by Algorithm and implemented in TechOptimizer™ became a reference point for later versions of function analysis in TRIZ. For the first time, it was possible to quantitatively compare functions and their importance within a system’s structure. Although the algorithms used in Invention Machine were not free from simplifications and subjective judgments, they paved the way for modern methods of function evaluation – the kind we now use in state-of-the-art TRIZ.

As the methodology evolved and gained popularity, more and more projects appeared where the goal was not cost reduction. In fact, there were even projects where the client was willing to increase costs to achieve a significant improvement in a parameter that mattered most (main parameter of value, MPV).

And since the component’s value no longer depended on cost, the traditional function-cost analysis lost its original purpose. However, the calculation methods developed up to that point could still be applied – all it took was to remove cost from the denominator of the formula shown in Figure 1.

Over time, the way of calculating the problem rank was also simplified. The parameter weight was no longer considered. The denominator now included only the “penalty” points for function disadvantages. Still, a certain hierarchy of auxiliary function importance continued to be used. The calculation could be as follows.

In the numerator, we sum the “positive” points for useful functions performed at the normal level, for example:

B (basic) – 10 pts.
A1 (auxiliary) – 8 pts.
A2 (auxiliary) – 7 pts.
A3 (auxiliary) – 6 pts.
A4 (auxiliary) – 5 pts.

In the denominator, we include the “negative” points for function disadvantages, for example:

H (harmful) – 5 pts.
A_i (useful insufficient) – 3 pts.
A_e (useful excessive) – 1 pt.

The resulting comparison makes it possible to evaluate system components in terms of both their functionality and their problem level. These calculated ranks can then be used to create a diagnostic diagram:

Figure 5. Diagnostic diagram showing the function rank compared with the problem rank, used to develop strategies for handling system components.

Looks familiar, doesn’t it? 😊

It’s exactly the same type of diagram we know from Level 1 certification trainings – except this one doesn’t just compare functionality against cost. Instead, it enables a much more precise comparison between a component’s functionality and its problem level, resulting from its function disadvantages.

Just like in the case of the function–cost diagram, this chart can also be used to develop a strategy for individual components:

Section A: Components located here are quite perfect. They have high functional importance and a minimal sum of function disadvantages.
Section D: These components should be removed from the technical system (while preserving their functions), because they have low functional importance and cause many problems.
Section B: Components here have low functional importance but also generate very few problems. When improving them, they should be assigned more useful functions. They are the best candidates to take over the functions of components removed from the system.
Section C: Components in this area have high functional importance but also many problems. When improving them, the focus should be on eliminating their function disadvantages.

The end of the story

Why didn’t the model from the 1990s survive to this day?

Back in the 1990s, components for trimming were chosen almost exclusively based on their value. Around the mid-2000s, GEN-3 began its training activities, introducing the TRIZ world to a new and powerful analytical tool – the cause-effect chain analysis (CECA) – which quickly proved its effectiveness in real projects. CECA was quite labor-intensive, but its efficiency soon pushed the equally time-consuming value analysis into the background.

Today, we start by eliminating components indicated directly by the project goal: if the goal is to reduce weight, we remove the heaviest component; if it’s to cut costs, we target the most expensive one, and so on. CECA provides detailed guidance, helping us identify components connected to key function disadvantages – those at the root of the problem. Components with the lowest value are now only the third choice for elimination.

But thirty years ago, CECA had not yet been used in TRIZ, and value analysis played a completely different role in projects. Its results had very practical meaning: the analysis directly pointed to components with the lowest value – those that were unnecessary or functionally inefficient. For engineers, this meant an instant identification of trimming candidates.

Epilogue

The methods used in the past have not completely disappeared. The official MATRIZ methodology no longer differentiates between auxiliary functions, and the “faultiness” of a function is no longer considered in the ranking – so these distinctions are not part of the certification exams. Still, many TRIZ experts continue to apply them in their projects.So maybe it’s worth experimenting with them?They can yield intriguing results – and perhaps even inspire better solutions.

If you’d like to learn more about the details of function analysis and value analysis as defined in the official MATRIZ program, I invite you to explore our open knowledge base.

And finally, a few words of gratitude.

I would like to express my thanks above all to Dr. Yuri Fedosov, who not only inspired me to explore this topic further but also shared invaluable reference materials. It was from him that I first learned that not all auxiliary functions are equal. He also provided the description of how to create the diagnostic diagram showing the function rank against the problem rank.

Deep gratitude also goes to Dr. Sergey Ikovenko for countless hours of discussion on the methodology – and for his remarkable ability to explain even the most complex concepts with clarity and simplicity.

About the author:

Magda Krupinska

A certified TRIZ (Level 3) and DFP (Level 3) expert, co-author of four TRIZ and DFP textbooks translated into multiple languages, experienced in training and lecturing. On a daily basis, actively involved in search and TRIZ activities in R&D projects. Scientific Secretary of the International TRIZ Association (MATRIZ).

References

Ikovenko, S., et al.. State-of-the-Art TRIZ, Theory of Inventive Problem-Solving, A guide for Level 1 certification by the International TRIZ Association (MATRIZ), Edition II revised, Warsaw, Crido R&D, 2021, ISBN 9788395985119.
Ikovenko, S., Krupinska, M., Yatsunenko, S.. Design for Patentability. Fundamentals, Edition I, Warsaw, Crido R&D, 2021, ISBN 9788395985133.
Gerasimov, V., Zlotin, B.. Function-cost analysis in action (ФСА в действии), Техника и наука, No. 11 1982, pp. 10–12; No. 12, pp. 27–29. Retrieved from
http://www.trizminsk.org/e/20130528.htm
Litvin, S. Hysteresis of innovation consulting (Part 1) (Гистерезис инновационного консалтинга (часть 1)), Журнал «Методолог», 2008, February 14. Retrieved from
Arel, E. T., Verbitsky, M., Devoino, I., & Ikovenko, S.. TechOptimizer Fundamentals, Invention Machine Corporation, Boston 2002.