Benchmarking
Benchmarking…
…or how to turn comparison into innovation
Not all the tools we use in TRIZ were born within TRIZ itself. On one hand, we have tools that form the core identity of the methodology – such as the trends of engineering system evolution, inventive principles, and the system of standard inventive solutions. On the other hand, TRIZ also relies heavily on tools that were brought in and adapted for its needs, especially problem-identification tools like function-cost analysis, CECA (cause–effect chain analysis), or feature transfer.
Benchmarking is closely tied to the last of these – and, in fact, it is also a borrowed tool. We turn to it whenever we plan to apply feature transfer, whether the goal is to create a new hybrid-system or use hybridization to eliminate a key disadvantage.
In TRIZ, this approach is often referred to as innovative benchmarking or TRIZ benchmarking. The purpose of this article is to take a closer look at it. Although it originates from a widely used business tool, it differs in important ways from its classical form. After all, its role here is to provide the kind of information we need specifically for TRIZ projects.
But before we get to the core, let’s briefly clarify
what benchmarking actually is
The term probably sounds familiar to many managers. In its simplest form, benchmarking is a deliberate and structured way of observing those who achieve better results – and extracting what we can learn from them. Not to copy their solutions one-to-one, but to understand why they perform better and what can be transferred into our own context. In other words, benchmarking taps into a very human instinct – to compare ourselves and learn from those who do it better.
The story of benchmarking begins the moment people first noticed that someone else could do something faster, cheaper, or smarter. As a formal management method, it took shape in the second half of the 20th century, with its real boom in the 1970s and 1980s. The method is most often associated with Xerox. When Japanese competitors began offering similar products at much lower prices, the company faced an uncomfortable question How are they doing it? Instead of avoiding comparisons, Xerox chose to embrace them. They started systematically analyzing competitors’ processes – not only within their own industry, but also beyond it.
Before long, benchmarking became a permanent part of the toolbox of any organization that aims to grow and learn in a conscious way. Today, it is used by both global corporations and small companies that want to grow faster, smarter, and with less risk. Let’s take a look
how classical benchmarking works
Classical benchmarking is a highly structured process. At its core, it can be reduced to four key steps:
1. Select the area for improvement
The process starts by choosing the area that “hurts” the most – a function, process, or parameter that either performs poorly or plays a critical role in competitiveness. Is it delivery time? Production cost? Error rate? Customer service time?
This area must be clearly defined and measured. The goal is to describe our current state as precisely as possible. This is the moment when a vague “it’s too expensive” turns into a concrete metric: unit cost = X.
2. Identify benchmarks (reference values)
Next comes the search for benchmarks – reference values achieved by others: competitors, market leaders, or even organizations outside the industry. This is where the real hunt for best practices begins.
Who does this better – and where? Specific companies, processes, or solutions that achieve superior performance are identified.
3. Understand the gap
Finding “the best” is only half the job. Now we need to understand the gap between our performance and the benchmark – and, more importantly, where it comes from.
What exactly allows others to perform better? Is it technology? Process organization? Resource use? A different operating model? Their solutions are broken down into elements. Only with this level of understanding can we move forward.
4. Adapt and implement
The final step is to transfer selected solutions into our own system. Not by copying, but through thoughtful adaptation to our specific conditions.
Once implemented, the changes are verified – we check whether they actually move us closer to the benchmark. If not, the cycle starts again.
Feels familiar, doesn’t it? 😉
At a high level, the logic of classical benchmarking strongly resembles the way we approach problems in TRIZ. So let’s take the next step and see how benchmarking has been adapted for TRIZ. Let’s first clarify
what is benchmarking used for in a TRIZ project
Let’s start with a simple point: we need benchmarking every time we plan to perform feature transfer. In TRIZ projects, feature transfer is typically used in two main scenarios:
- at the beginning of the project – when the goal is to create a new system by hybridizing it with another system, or
- after completing CECA (cause–effect chain analysis) – when the goal is to eliminate key disadvantages – often as an alternative to trimming.
Figure 1. Applying feature transfer in a project [1].
In feature transfer, benchmarking is used to identify “local leaders” – systems that are strong candidates for hybridization. On one hand, it helps us select the best available technical solution. On the other, it allows us to position the base system against other systems and understand where it stands.
Benchmarking in TRIZ comes with its own procedure and set of requirements. Both are described in detail in a study published in 2007 by GEN3 Partners and Algorithm [2]. A large portion of this material can also be found in the Level 5 (TRIZ Master) dissertation by Oleg Gerasimov (2010) [3], which is available in our Academy.
We will focus on the parts most relevant to our discussion. But first, let’s look at
how to identify areas for improvement
In classical benchmarking, the first step is to identify the area for improvement. In our case, this step is already defined by the purpose of the feature transfer itself. If the goal is to create a completely new hybrid system, we usually start with a project goal and assumptions where the requirements are already specified. If feature transfer is used to eliminate a key disadvantage, then that very disadvantage points us directly to the area that needs improvement.
So we already know where it “hurts.” But to begin searching for benchmarks, we need clear criteria to guide us. In TRIZ, this requires two key inputs:
- the main function of the system, which helps us identify a pool of systems or technologies (in this context, referred to as competing systems), and
- the parameters for comparison, which allow us to evaluate these systems and select the most promising alternatives.
Let’s take a closer look at both. We’ll begin with
how to formulate the main function for search
When defining the main function for feature transfer, two approaches can be used: a restricted one and an extended one [2] [3].
In the case of the restricted approach, we only search for systems that perform the same main function and are actually available on the market. As a result, the benchmarks we identify and use may lead to a lower level of innovation in the final solution.
The advantages of this approach are a relatively low effort thanks to a limited number of systems included in the comparison, clear selection criteria, easy comparison between systems, and fairly high reliability of the results.
The disadvantages? There is a significant risk of missing the most promising system. For example, if a solution is still under development and not yet available on the market – or if it was originally designed to perform a slightly different main function – it simply won’t make it into our comparison table.
When using the extended approach, the things start to get far more interesting – and far less obvious. In this approach, we include systems with similar (not necessarily identical) main functions, and they don’t have to be commercially available. This means we also consider solutions that are still under development, described in patents or scientific papers, found in literature – even in fairy tales and legends.
The similarity of the main function can be defined in several ways:
- by the object of the function
For example, a screw conveyor in a grain elevator moves grain, while a vacuum powder feeder in a pharmaceutical plant transports production mixtures. Both “grain” and “mixture” can be generalized as bulk material. So, we expand our search to systems that “move bulk materials.” - by the action
A laboratory dryer removes water from samples by heating and evaporation, while a towel removes it mechanically using capillary forces. Different mechanisms – but the same generalized function: removing moisture. - by the circumstances
A toothbrush removes plaque from teeth, while tools used by archaeologists clean delicate artifacts. The action is similar (removal), the objects are comparable (thin-layer contaminants), and – most importantly – the conditions are alike: in all cases, contaminants must be removed from hard, complex surfaces without causing damage.
In this approach, we can go even further and include systems with completely different main functions – as long as they share a common goal. Take an eraser and a correction fluid. Their main functions are entirely different in terms of both action and object: an eraser removes graphite particles, while the fluid reflects light. In both cases, the action is applied to paper, and all activities take place in an everyday, home setting. Despite their differences, both systems share the same goal: to turn a marked area of paper into a clean surface that can be used again.
The extended approach greatly increases the chances of identifying the most promising system and often leads to more innovative solutions. But it also comes with trade-offs. First, it can be significantly more time-consuming, simply because the number of systems to analyze grows quickly. Second, the selection criteria may become less clear. For example, if we are analyzing a toothbrush, should we also include technologies used to remove deposits from pipes or to clean casting sand from metal parts?
Another challenge is that not all evaluation criteria apply equally across different systems. For a correction fluid, an important parameter might be the thickness of the layer needed to fully block the underlying text. For an eraser, what matters is how effectively it removes graphite. How to compare “covering” versus “removing”?
As a side note, the ability to unify comparison criteria can itself serve as a selection filter. Different parameters can often be translated into a higher-level metric. In the case of the eraser and paint, both can be compared in terms of the uniformity of light reflection – in other words, how close the processed paper is, visually, to a clean sheet.
Finally, there is the issue of data reliability. For systems that are not available on the market, technical data may be difficult – or even impossible – to obtain, and sometimes not very reliable. Quantitative comparison becomes especially challenging when a system is known only from a patent description – or even from a fairy tale [2].
how to identify parameters for comparison
The parameters we use to compare systems are generally referred to as main parameters of value (MPV). For our purposes, the most important are the main function parameters of value (MFPV), which are selected based on an analysis of the main strategic parameters of value (MSPV).
What is the difference? Here are the definitions:
Main strategic parameter of value (MSPV) is a product characteristic that justifies its creation and use – that is, a parameter defining the product’s attractiveness to the customer and used by the market to evaluate it.
Main function parameter of value (MFPV) is a measurable physical parameter that defines the level of a given strategic parameter.
Let’s use an example from the text. A strategic parameter important to a car user (MSPV) is “driver safety.” However, this is not precise enough to serve as a value we can directly improve. In a project, we need a measurable parameter (MFPV) behind driver safety. One such parameter could be “the time during which the driver is forced to look away from the road.” This is the parameter we need to improve – and at the same time, it becomes the criterion for evaluating competing systems and identifying the “better” ones.
MFPVs can be divided into three types:
- function – describing the level of performance of useful functions, primarily the main function,
- cost-related – describing the cost level of performing useful functions as well as the extent of harmful functions (by “costs” we mean all inputs and losses associated with the system’s operation, not only financial ones), and
- relative – describing the level of useful function performance in relation to the costs of achieving it or to the level of harmful functions.
Relative parameters are considered the most informative – they allow for the clearest and most compact comparison of engineering systems. However, they should be used with caution, keeping in mind potential scaling issues (for example, the ratio of carried load to body weight is much higher for an ant than for a modern truck, yet in absolute terms, trucks are far superior in the amount of load they can carry). That said, there is nothing preventing us from using both relative and absolute parameters within the same project.
In all cases, it is recommended to use parameters that can be expressed as a defined value (a number or at least a range). In exceptional situations, purely qualitative parameters may be used (e.g., aesthetic–non-aesthetic, comfortable–uncomfortable). For such parameters, an appropriate scoring system should be defined [2][3].
Identifying benchmarking parameters and assessing their relative importance is a complex task. I will cover this in the second part of the article. For now, we will stop here and move to the next stage. In classical benchmarking, this is the search for benchmarks – in a TRIZ project, we move on to
identifying competing systems
The search query is formulated based on the main function, with the selected MFPV parameters taken into account, according to the following model:
Figure 2. Search query model in TRIZ benchmarking.
Where do we search? Wherever we can.
Modern AI tools certainly make this task much easier. Many of them can be trained to handle a large part of the work for us. Our role is to verify the reliability of the information and, if needed, refine the search with additional prompts. If we are using the extended approach, we should also remember to explore patent databases and the literature (where AI can also be extremely helpful).
The identified technical solutions are then entered into a table. How we structure it is up to us. It is always worth including the source (a link) and an illustration, which helps quickly understand what the system is and, if needed, makes it easier to find additional information online. It is also useful to briefly describe the key characteristics of each system in two or three sentences.
Keep in mind that the purpose of searching for competing systems is to identify how well they perform against the parameters we care about. The table should reflect this. Whenever possible, we should look for this data directly in system descriptions. No matter how the data is presented, it should be recorded in the table.
Figure 3. Example of a benchmarking table.
With the collected data, we can calculate the values achieved by each system for every parameter. These results provide recommendations for selecting an alternative system – the best candidate for feature transfer. How to calculate these parameter values, however, will be covered in the second part of this article.
*
In classical benchmarking, identifying the “better” solutions completes the second step, after which we move on to understanding the differences between our “pain point” and the methods and solutions used by others. In our case, it is quite similar; however, benchmarking officially ends here. We have reviewed competing systems and selected an alternative one. Now CECA enters the scene. Using cause–effect chain analysis – or more precisely, its “reversed” form (focused on advantages) – we identify the features responsible for the strong parameter performance of the alternative system.
And so we’ve reached the end – but let’s take a moment for a short
conclusion
When you take a closer look at the feature transfer algorithm as it is used today in the MATRIZ methodology, you’ll notice that benchmarking is, in a way, built into it. It should not be treated as a separate tool, but rather as a kind of underlying logic. In fact, this logic is not limited to feature transfer. If you look closely at function-oriented search, you will notice many similarities. There, too, we generalize and search – but the focus is on functions rather than systems.
Properly selecting MPVs and evaluating them correctly is perhaps the key challenge. This topic will be covered in the next part of this article. So, I kindly invite you to join me there.
References
- https://wiki.matriz.org/
- GEN3 Partners and Algorithm (2007) Методика выполнения типового консультационного проекта “Product and process improvement Functionality / Performance (Methodology for a standard consulting project “Product and process improvement Functionality / Performance”). Методические рекомендации, Draft. Saint Petersburg.
- Gerasimov, O.M. (2010) Технология выбора инструментов инновационного проектирования на основе ТРИЗ – ФСА (Technology of selection of innovative design tools based on TRIZ – FCA). TRIZ Master dissertation. Saint Petersburg. Available at: https://matriz.org/academia/#triz-master-theses
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, managing a team and actively involved in search and TRIZ activities in R&D projects. Scientific Secretary of The International TRIZ Association (MATRIZ).