MUST - multilevel universal system thinking - note

These notes about MUST (Multilevel Universal System Thinking) are not written in English but in the language that is ironically called “Ruglish.”
Of course, I could have asked an AI to clean up these fifteen;year;old notes and translate them into proper English, but I decided to leave everything exactly as it was originally written.


What is MUST?
MUST is multilevel universal system thinking
MUST is intended to analyze, evaluate and define change level of any artificial systems (including methods and techniques)
The key-difference of MUST approach from other system approaches in usage of CONSUMING levels instead of HIERARCHY ones.
These consuming levels are:
-result (satisfied need)
-method
-technology
-means
-parameters
Maybe the word " consuming " isn't correct. I meant that you satisfy a customer's need (level 1 of consuming) by a method (level 2 of consuming) with a technology (level 3 of consuming) by a means (level 4 of consuming) that have a set of parameters (level 5 of consuming) Levels 'customize" the previous levels and "customized" by the next levels.

-Every system is intended to gain a result to satisfy some need – the first level.
-Result may be gained by a number of ways or/and methods – the second level.
-Each way/method may be based on one of a number of different technologies (scientific - physical, chemical, biological, geometrical, psychological, economic etc.,- effects and phenomena) – the third level.
-Technology may be supported by one of different sets of (technical) means - the fourth level
 -Each (technical) mean has its set of parameters – the fifth level

For example, let’s take refrigerator:
-It is intended to prevent food from spoiling – result
-Result is received by food cooling - method/way. But there are other methods/ways to gain the same result.
-Method is supported by, for example, technology based on adiabatic expansion/ compression and phases transition effects – technology. But there are other technologies that are able support the cooling method, for example, thermoelectricity.
-There are a lot of different refrigerator designs that each of them realizes the adiabatic expansion/compression and phases’ transition effects technology – technical means
-Technical means has its own set of parameters.

MUST and Innovation
In my opinion, innovation is an implemented change.
According to MUST (multilevel universal system thinking) approach the change might be implemented on different levels (I call them consuming levels):
* A new result (new satisfied need of a customer –“need” solution))

* A new method of gaining the same result (“principle” solution)

* A new technology the same method is based on (“scientific” solution)

* Means the same technology is supported by (“technical” solution)

* A new set of parameters of the same technical solution (“parametric” solution)

Belonging a change to one of the described above consuming levels determine its “innovation scope”. Of course, the consuming levels might be related to different stages of the product life: manufacturing, installation, day-day usage, emergency usage, maintenance, repair etc. Simply “customers” of each stage might differ…

MUST and IP
In order to provide maximum defense the "tree" of patent claims should be written according to the five consuming levels:
-Result (s): the first claim(s), where the results are defended.
For example, you describe a stent behavior under different conditions (stent's properties)
-Method: the claim(s) with reference to the first claim, where are described methods to gain the result.
For example, you describe methods you provide the stent's properties.
-Technology: the claim(s) with reference to the method claims, where are described technologies the methods are based on.
-Means: the claim(s) with reference to the technology claims, where are described means that support the technologies
-Parameters: the claim(s) with reference to the means claims, where the means parameters are described.
Such a system of claims gives so called "umbrella" that protects IP, but it has additional advantages.
It directs you, for example, to think about possible alternative methods, technologies etc and protect them.
It also hints you to think about possibilities to provide, for example, different results with the same (or modified a little) method and so on.
Thus the "umbrella" protection turns into some kind of the "net" protection

MUST Application to IP Protection and Expansion
In order to provide maximum defense the "tree" of patent claims should be written according to the five MUST levels.
What the MUST levels are?
• Every system is intended to gain a result to satisfy some need – the first level
• The result might be gained by a number of ways or/and methods – the second level
• Each way or method might be based on one of a number of different technologies (scientific - physical, chemical, biological, geometrical, psychological, economic etc.,- effects and phenomena) – the third level
• Every technology may be supported by one of different sets of (technical) means - the fourth level
• And each (technical) mean has its set of parameters – the fifth level

Refrigerator example
• It is intended to prevent food from spoiling – result
• This result is received by food cooling - method/way.
Note: There are other methods/ways to gain the same result – to prevent food from spoiling
• The method is supported by, for example, technology based on adiabatic expansion/compression and phases transition effects – technology.
Note: There are other technologies that are able support the cooling method, for example, thermoelectricity
• There are a lot of different refrigerator designs that realize the adiabatic expansion/compression and phase’s transition effects technology – technical means
• Each technical means has its own set of parameters.

System of claims according to the MUST levels
• Result (s): The first claim(s), where the results are defended.
For example: Describe a stent behavior under different conditions (stent's properties)
• Method: The claim(s) with reference to the first claim, where are described methods to gain the result
For example: Describe methods you provide the stent's properties
• Technology: The claim(s) with reference to the method claims, where technologies that support the methods are described
• Means: The claim(s) with reference to the technology claims, where means that realize the technologies are described
• Parameters: The optional claim(s) with reference to the means claims, where parameters are described.

Such a system of claims creates so called "umbrella" that protects IP, but it has additional advantages. It directs you, for example, to think about possible alternative methods, technologies etc and protect them in order to expand your IP.
It also hints you to think about possibilities to provide, for example, different results with the same (or modified a little) method and so on - some kind of the "net" protection and expansion of IP.

MUST Analysis of Problem Solving Methods
Description of problem solving methods on the consuming levels enables us to compare them.
Such a comparison allows:
•Defining directions of further development of methods themselves
•Correct feature transfer from one method to another
•Correct combining of methods in order to get their synergy
For example, TOC (theory of constraints) and TRIZ were compared, and then the synergetic method (that has not its own name yet) was built and tested.
For now we call it “TOC+TRIZ” although this name does not express synergy of the methods.

MUST and Synergy of TRIZ and TOC TP
Let's perform MUST analysis of TOC TP and TRIZ
Result (a need to be satisfied):
Both TRIZ and TOC TP are intended to get the same result - improvement of a system.
Method:
TRIZ gains the result by using of so called "patterns" that were revealed on base of the world patent fond analysis.
TOC TP gains the result by identifying and elimination of the system constraint (key-problem).
Technology:
TRIZ - method is based on the technical system development lows and regularities
TOC - method is based on releasing (during discussion) and applying existing (but hidden) team knowledge and intuitions.
Means:
TRIZ tools that are applied to analyze problem situation, define the problem, choose problem solving direction, find and evaluate the solution concept.
TOC TP tools that are applied to consolidate a team, identify key-problem (constraint), analyze the problem, resolve it and evaluate the solution concept.
Parameters:
Both TRIZ and TOC TP have well-described tools and work procedures.
In order to check "synergy" possibilities let's write down drawbacks of TRIZ and TOC TP beginning from the level "method":
TRIZ isn't intended to find key-problem (constraint) and TOC TP does not use "patterns".
Drawback at the level "technology":
TRIZ isn't built to release hidden team knowledge and intuitions and TOC TP does not use system development "regularities".
Drawback at the level "means":
TRIZ tools are not enough visual and TOC TP tools do not allow "smooth" transition between the tools.
A "synergy" of TRIZ and TOC TP should overcome the mentioned above drawbacks of the two methods.
The “synergetic” process in my opinion should look as follows:
CRT (current reality tree - to identify key-problem/constraint) ->PSM (problem situation mapping) and defining a set of contradictions -> presenting the contradictions (each one) in form of clouds (TOC TP tool that visualizes conflicts and reveals hidden assumptions) -> applying "patterns" to columns of each cloud in order to generate solution concepts -> concepts evaluation


MUST/I-MUST and Mission, Vision etc
According to the MUST approach, mission, vision etc also might be described on the five consuming levels.
Result (satisfied “mankind” or society need): What the activity of the company is for? Mission.
Method: What is the activity of the company? In other words how the company is going to get the result?
Technology: What is the “scientific base” the activity is based on? How does the activity applied?
It is close to the company values but not the same
Means: What does support the technology? This means the company itself, its stuff, policies etc
Parameters: What are the “numbers” that “wrap” all mentioned above?
Notes:
-According to I-MUST, change might be applied on every of the mentioned above levels
-The higher the level the more meaningful the change is
-The levels below the change level then should be revised and rebuilt if necessary
-There are tools that are associated with each level and “suggest” possible changes

MUST and Specification Writing
According to MUST (multilevel universal system thinking) approach before writing a specification we have to make a table.
As names of the table columns we write life cycle stages of the specified system: preparation and installation, normal functioning, emergency functioning, maintenance & repair, development, utilization. There might be other life stages according to your choice, for example, transportation, storage, manufacturing etc.
As names of the table rows we write so called consuming levels of the specified system: a result to be gained, a method to gain the result, a technology the method is based on, means that support the technology and parameters of the means.
Then you start to fill in the table beginning from the top of each column.
You will not be able to fill in all the cells of the table.
For some columns you will fill in the cell “result” only, for other columns you will be able to fill in sells “method”, “technology” and even “means”.
Unfilled parts of the columns define the “decision freedom” you transfer to your subcontractor.
Now you are ready to write a correct specification.
After receiving your specification your subcontractor will send you back his/her one.
Attention, subcontractors prefer defining means and means parameters instead of results and methods.
You will “meet” each other near “technology” level +/-
Correct the specification.
Now it is full and ready

MUST and MPV Determination
Before discussion with A.Efimov here http://www.metodolog.ru/node/1220 (it is in Russian) I did not think about implementation of MUST for MPV determination.
I can say now that the MUST approach for specification writing can be implemented nearly without changes for revealing and mapping hidden MPVs.
The only change is that we have to fill each cell in the table.
It is possible because in this case we work with an existing system.
The advantage of such an approach (MUST based) for MPV determination is that we receive a map of MPVs according to their consuming levels and position on the life cycle line.

MUST and Art
Let’s take a painting instead of a technical system.
One of the results (satisfied needs): live-like feeling while looking at the painting
Method: to show movement (micro-movement) on the painting
Technology (set of scientific phenomena connected to each other): usage of the eye “scanning” phenomenon to get full image.

(Google images search for “optical illusions” will bring you more)
Means: objects on the painting, light and shadows are shifted a little bit from their correct place to create illusion of micro-movement
Parameters: an exact composition - a shift distances, for example

MUST and Determination of Subsequent Problems
Additional or subsequent problems might appear after resolving a "primary problem".
Sometimes it is clear what are additional (subsequent) problems that should be resolved in order to realize solution of a "primary problem". Sometimes they (problems) are partly (or fully) hidden and should be revealed. This is one more (MUST based) tool to those tools that are already used (like extra-effect determination, or subversive prognosis, for example) for revealing subsequent problems.
According to MUST (multilevel universal system thinking) approach before determination of possible subsequent problem we have to make a table.
As names of the table columns we write life cycle stages of the changed (according to our solution) system:
Preparation and installation
Normal functioning
Emergency functioning
Maintenance & repair
Development
Utilization.
There might be other life stages according to your choice, for example, transportation, storage, manufacturing etc.
As names of the table rows we write so called consuming levels of the specified system:
The result to be gained
The method to gain the result
The technology the method is based on
The means that support the technology
The parameters of the means
Such a table is actually is a preparation for mapping of possible subsequent problems.
Then you might start to fill in the table with possible subsequent problems.
You will not be able to fill in all the cells of the table (one or two filled cells in each column are considered as a good result)
In order to make the process of subsequent problems' determination (and filling the table) easier take into account this short list of possible problem sources (at each life cycle stage):
Changed system itself and its activity
Super-system and its activity
Neighbor systems and their activities
Human factor and its activity
Environment
After mapping of possible subsequent problems they might be ranked for further analysis (with help of PSM, for example) and resolving.
By the way, the list of subsequent problems can be then used in order to build FRT (future reality tree) that is used in TOC (theory of constraints). Mapping of subsequent problems using MUST provides a tool that enables us to build FRT easier.
The same approach provides also a good tool to create list of UDEs (undesired effects) to build CRT (current reality tree) easier. Simply instead of looking for possible subsequent problems we look for possible UDEs Of course there are some nuances...
Thus MUST mapping of subsequent problems turns in one more tool that enables synergy between TRIZ and TOC.

MUST and KPIs
According to the MUST (multilevel universal system thinking) approach you have to divide your KPIs into five levels:
1. KPIs that are connected to results you strive to gain;
2. KPIs that relate to a method  you use to gain the results;
3. KPIs that are connected to technologies (set of effects and phenomena – physical, chemical, psychological, economic etc.) the method is based on;
4. KPIs that relate to means (technical, organizational, political etc.) that support the technologies;
5. KPIs that are connected with specific realization of the means;
What is useful in such an approach - dividing KPIs in to levels? First, such an approach enables you to define KPIs for your system more completely, accurately and easy. Second, changing something in your system you can easily define the change level and redefine KPIs on this level and the levels below accordingly. There are also third, fourth, fifth, etc.

As far as you write rather about KPI groups than KPI themselves I would prefer a more structured approach to classification of KPIs. According to the MUST (multilevel universal system thinking) approach you have to divide your KPIs into five levels: KPIs that are connected to results (satisfying an unmet need) you strive to gain; KPIs that relate to a method  you use to gain the results; KPIs that are connected to technologies (set of effects and phenomena – physical, chemical, psychological, economic etc.) the method is based on; KPIs that relate to means (technical, organizational, political etc.) that support the technologies; KPIs that relate to specific realization of the means; What is useful in such an approach - dividing KPIs in to levels? First, such an approach enables you to define KPIs for your system more completely, accurately and easy. Second, changing something in your system you can easily define the change level and redefine KPIs on this level and the levels below accordingly. There are also third, fourth, fifth, etc.

What is I-MUST?
The letter “I” means “innovation”.
According to MUST, innovation is a multilevel thing that might be applied on five levels.
See here:
I-MUST is an application of MUST approach to the innovation problem solving.
It is built in form of algorithm that has different tool sets for each of five levels: result, method, technology, means and parameters.
I-MUST might be applied to the whole system or to its part that is connected to so called undesirable effect (UDE)
This part is revealed during the problem formulation stage when we define: UDE, UDE connected element, element’s action, action object and environment.
The five change levels are then defined for this element.
In addition to “conventional” tools that usually connected to drastic change of the action object or environment on the level “result” (satisfied need) might be used so called problem situation mapping (PSM).
PSM is actually the problem re-formulation stage when are defined additional UDEs: UDE – cause, UDE-effect, UDE that appears if a common method is applied and UDE that appears in case that the element that is connected with the “original” UDE is removed and its function isn’t performed.
The tool sets in majority are the TRIZ tools that were re-classified and divided according to the mentioned above five change levels.

I-MUST and Functioning Levels
When we solve real problems with help of MUST it is easier to use the functioning levels instead of so called consuming levels.
What are the functioning levels?
•UDE – undesirable effect
•Means - subject
•Action of the means
•Action object
•Environment
There is a strong relationship between the consuming and functioning levels but they are not the same.
Such a transfer (from the consuming levels to the functioning ones) enables us to connect classic TRIZ tools to the change levels.
For example, let’s take the 40 principles and connect them to functioning levels.
•UDE: 8,9,11,13,21,22,25,27,30,34,39
•Means:
•Action: 5,9,10,12,13,14,15,16,17,18,19,20,21,24,28,32,36,37,38
•Action object:
•Environment: 3, 8,13,15,30,32,35,39
As you could see some principles appear in a few levels. That occurs because they consist of sub-principles or “suggest” change, for example, UDE and Action, like principle # 9.
Such an approach will enable us to re-arrange this old but still effective TRIZ tool.
The principles’ grouping that is presented above might be changed and improved
For those that don’t want to “waste their time” passing through inventive principles I would suggest to build a table.
Write the functioning levels as names of the table rows:
•UDE – undesirable effect
•Means - subject
•Action of the means
•Action object
•Environment
Write possible change types as names of the table columns:
•Time
•Place
•Structure
•Conditions or parameters
•Insertion of extra-elements (from resources, of course)
Then fill in each table intersection cell change procedures.
For example, changing of the environment before, during or after or changing of structure of the action object by its segmentation or changing the means by insertion of an extra-object.

I-MUST and Problem Situation Mapping (PSM)
Let’s map the following problem situation:
We cannot increase the speed of an aircraft because of the air resistance to the wings.
Let’s first perform the Initial Problem Definition for this problem:
•The UDE: air resistance to the wings
•The element connected with this UDE: the wings
•The function of this element: to support the aircraft body
•The object of the function: the aircraft body.
•The environment: the air around the wings
Now we can proceed with the Problem Situation Mapping.
•The “south” UDE is the UDE which appears when the original problem (original UDE) is solved with known methods.
For example: The original UDE is air resistance to the wings. If we decrease the area of the wings, another UDE will appear: we have to increase the take-off speed of our aircraft... The element connected with this UDE is the airport runway, which will have to be too long...
•The “north” UDE is the UDE, which appears if we remove the element connected with the original UDE.
For example: When we remove the wings, there is no air resistance to the wings, but now we have a new UDE connected with the non-performance of the function of the wings...
•The “west” UDE is the UDE which is the reason for our original UDE.
For example: Maybe the reason for air resistance to wings is the vortex motion of air which is caused by the wing surface... The element, which is connected with this UDE, is part of the surface of the wings...
•The “east” UDE is the UDE which is the result if the original UDE is not eliminated.
For example: The loss of time because of the low speed of our aircraft.
For each UDE (original, north, south, west and east) we can now choose which problem we are going to solve:
•UDE elimination
•UDE measurement or detection
For example: Tool wear is measured by measuring the motor current. Then the adaptive system machinery center changes the parameters of the cutting process. However, overheating of the bearings causes wrong measurement of the tool wear.
•In case of UDE elimination we might, for example, prevent the over-heating of the bearings.
•In case of UDE measurement we might measure (or detect) the over-heating of the bearings.
We choose the problem to solve, based on the resources which we have.

What is D-MUST?
The letter “D” means “Diagnostic”.
D-MUST is an application of MUST approach to the diagnostic problem solving.
The diagnostic problems are connected with discovering (exposing, finding out) causes (reasons) of different phenomena.
Simply speaking while solving the diagnostic problems, we have to answer the questions: "Why does such a thing occur?”
According to D-MUST (like in the TRIZ based methods), instead of asking: "Why does such a thing occur and what has caused such a result?" we ask: "How can we achieve this result?"
The last question enables us to use MUST in order to build “explanation” models
Implementing MUST to build the models, we describe:
-Possible methods of gaining the result
-Technologies the methods are based on
-Means that support the technologies
-Parameters/conditions of the means
The only limitation is to use exclusively resources (ready, combined or derived) of the system or its environment.
Then each explanation model should be verified.

MUST and Prisms
There are different "prisms": management, R&D, engineering, manufacture, QS.
Each of these "prisms" can dominate in a company culture.
Each approach fits better to its "prism"
Management "prism" - TOC (theory of constraints)
R&D "prism" - Product/service VE (value engineering)
Engineering "prism" - Process VE
Manufacture "prism" - Lean
QS "prism" - Six Sigma
Actually all these methodologies are intended to bring the same result by different ways:
TOC - by removing system constraints
VE- by Increasing product or process value/cost ratio
Lean - by reducing value flow waste
Sis Sigma - by reducing process variation
TRIZ differs from the mentioned above approaches - it fits better to inventor's "prism".
TRIZ (let's return to the source) is intended to get the ideal solution by resolving contradiction.
That's why in the real world TRIZ (in order not to bring... troubles to inventor:)) should get married with one of the mentioned above methods (or with all of them:))
Actually all more or less successful attempts to use TRIZ are connected with such "marriages" in spite of sometimes they are presented as parts of TRIZ.

P.S. By the way, MUST is a good "matchmaker":)

MUST and Information
According to one of the definitions, information is intended to decrease uncertainty.
According to MUST approach, we have to divide “uncertainty” into levels:
Uncertainty of a result (a need to be satisfied)
Uncertainty of a method
Uncertainty of a technology
Uncertainty of means
Uncertainty of parameters
We have to admit that tools decreasing uncertainty on the “result” level differ from tools that intended to work on the “parameters” level.
Such an approach gives us a key to classify and rank DATA processing tools.
In this context it’s very interesting to look how religious texts were analyzed during centuries by the best minds of the mankind, using the multilevel approach: fact parameters (DATA), facts themselves, hints, allegories, secrets (codes)
See, for example, the story about those four that came into PARDES (the world of Torah)

MUST and Chain Analysis
The last element of the MUST approach that was not presented yet is analysis of objects chain.
It isn't intended to deal with "simple" objects like technical systems when in order to resolve a problem sometimes enough to describe a system on different consuming levels and then apply I-MUST.
Chain analysis is intended for complex objects.
For example, a company produces a product (provide a service) for a group of customers.
It isn't a simple object - it is a chain of objects.
Thus we have to describe consuming levels for each of the chain objects: company, product, group of customers.
These descriptions differ a lot each other because the objects and regularities of their changing belong to different fields of human life.
Moreover, dominance of every "next" object of the chain relatively to “previous" one increases.
This element (chain analysis) of MUST is used mostly for evaluation and development of problem solving methods.

MUST and Story Telling
According to MUST (multilevel universal system thinking) approach good stories reduce uncertainty on a number of levels: Uncertainty of a result to be gained (a need to be satisfied); Uncertainty of a method (to gain the result); Uncertainty of a technology (the method is based on); Uncertainty of means (that support the technology); Uncertainty of parameters (specific realization of the means); The best stories reduce uncertainty and cover all the mentioned above levels. Moreover the best stories work on a number of information levels like: DATA, facts, hints, allegories, secrets (codes). That's why we can read them over and over again, finding each times something new. Religious texts (Torah, for instance) look in this context like an excellent example. These texts were analyzed during centuries by the best minds of the mankind are analyzed nowadays and for sure will be analyzed in the future. By the way, these best minds used multilevel approach to analyze that we (unfortunately) have not fully adopted yet for building information systems.

I-MUST and Altshuller’s Matrix Usage
We start from an “original” UDE that determines a problem. According to PSM (problem situation mapping) that is a part of I-MUST, we have to define additional UDEs:
•UDE(a) that appears if we use a known (regular) method to eliminate the original UDE
•UDE(b) that appears if we mentally remove the element connected with the original UDE - in this case the element connected with original UDE is the “known” (regular) method
We also should define two more UDEs:
•UDE(c) that is the cause of the original UDE
•UDE(d) that is an effect of the original UDE
Each of them should be treated as the original UDE.
•UDE (e) that appears if we use a known (regular) method to eliminate UDE(c)
•UDE(f) that appears if we mentally remove the element connected with UDE(c)
•UDE (g) that appears if we use a known (regular) method to eliminate UDE(d)
•UDE (h) that appears if we mentally remove the element connected with UDE(d)
Thus we have 6 contradictions:
•original UDE -> known method->UDE (a) => contradiction 1
•UDE (b) -> known method -> original UDE => contradiction 2
•Cause UDE (c)-> known method->UDE (e) => contradiction 3
•UDE (f) -> known method -> cause UDE (c)=> contradiction 4
•Effect UDE(d) -> known method->UDE (g) => contradiction 5
•UDE (h)-> known method -> Effect UDE(d) => contradiction 6
Now we can mach UDEs in each contradiction to parameters (to be improved and get worse) of Altshuller’s matrix.
For more see here:
http://www.bmgi.com/sites/bmgi.com/files/Effective.pdf
By the way usage of Altshuller's matrix to resolve contradictions isn't "must":) I in person prefer other tools...
I prefer I-MUST problem definition procedure and then:
Inventive principles that are grouped according to functional levels (they are re-formulated a little bit)
Resources and separation principles (five instead of the accepted four)
Standards that are grouped according to function/UDE types (they are also re-formulated)
In case it does not work I use PSM (problem situation mapping) in order to change problem.
Nevertheless, in my opinion, usage of the contradiction matrix is useful because when we try to find a match between "generalized" and "real" parameters we understand a problem better.
Thus the worst match will give the best results :)

MUST and TRIZ Tools etc
Implementing the MUST analysis to different TRIZ tools enables us to change point of view on them.
40 principles: For example, there are principles that “suggest” change on the level “result” and there are principles that work on levels “method”, “technology” and “means”.
Some principles consist of sub-principles that suggest changes on number of levels.
Thus implementation of the MUST approach to principles will enable us to re-organize them according to the “consuming” levels (see “What is MUST?”)
The same might be said about the TRIZ standards.
The most interesting is implementation of the MUST analysis to the TRIZ regularities.
Using the MUST approach we can build their “hierarchy” basing on consuming levels: result, methods, technology, means and parameters.
Some of regularities work on all levels and some mostly on specific ones.
Effects: Using the MUST approach, we can re-build collection of technical effects and phenomena according to consuming levels also.
Actually it will not be collections of separate effects and phenomena, but … I even don’t know how to name it – it is turned to be closer rather to Design Thinking than to TRIZ.
The MUST analysis of the “main” TRIZ tools allowed to reveal that they (TRIZ tools) do not fit well for working on the level “result”(satisfied need)
The “secondary” TRIZ tools and games that are used for creative imagination development are suited better, but not enough.
In order to widen the set of such tools we have to look for them in other fields of human life like semiotics or NLP (neuro-linguistic programming) , for example, but it is another story…
In order to show how the MUST analysis changes point of view on TRIZ regularities, for example, let’s take the regularity of transition into super-system.
What are the systems that are joined into super-system from the MUST point of view? They are as follows:
* Systems that gain different results (satisfy different needs) - there might be joined systems that perform different stages of the process or those acting at the same place.
* Systems that use different methods to gain the same result
* Systems that support use different technologies the same method is based on
* Systems that are different means that support the same technology
* Systems that are the same means but have different set of parameters
* The same systems (the same result, method, technology, means and parameters)

Try do the same for other regularities (principles, standards) – you will be surprised.

MUST, Feature Transfer and Transition into Super-System Digression
MUST has appeared after trials of TRIZ feature transfer into other fields of human life.
But some ideas from “other fields”( semiotics, for example) also might be transferred into TRIZ.
For example, I see parallel between the regularity of transition into super-system and this semiotic line: text -> text with inserted text -> hypertext.
Actually we can relate to technological systems as to… texts.
“Transition into super-system” In this case matches to “text with inserted text”.
And what does matches to “hypertext”?
Systems with so called “fuzzy (flexible, floating) hierarchy”
Once we have verbalized this we can see some such systems (hypertexts) around us.

For example:
The lock is part of the door, but there are doors that are closed by moving the door into the wall.
Thus in this case the door is part of the lock.
Or painting on the room wall (that is part of the room), when the room (furniture, for example) is designed to look like a part of the painting.
Some software systems are actually systems with “fuzzy (flexible, floating) hierarchy”

The more “advanced” system type - the more systems with “fuzzy (flexible, floating) hierarchy” we can see.
“Hierarchy” in such systems is changed “upon condition”
Thus we can correct a little bit the line of transition into super-system: system-> super-system -> system with fuzzy (upon condition) hierarchy.
In my opinion this line has a good prognostic power and deserves a separate research.

Let’s apply MUST to this line.
We will receive as follows:
Transition to system with fuzzy (upon condition) hierarchy of results
Transition to system with fuzzy (upon condition) hierarchy of methods
Transition to system with fuzzy (upon condition) hierarchy of technologies
Transition to system with fuzzy (upon condition) hierarchy of means
Transition to system with fuzzy (upon condition) hierarchy of parameters

I want to remind you that according to MUST the systems that are joined into super-system as follows:
Systems that gain different results (satisfy different needs) - there might be joined systems that perform different stages of the process or those acting at the same place.
Systems that use different methods to gain the same result
Systems that support use different technologies the same method is based on
Systems that are different means that support the same technology
Systems that are the same means but have different set of parameters
The same systems (the same result, method, technology, means and parameters)

As you could see (with help of feature transfer from semiotic to TRIZ and MUST) we have got interesting and deserving, in my opinion, further development ideas about transition into super-system.

I-MUST and Operator of the Numeric Axis
As majority of you know the DTC (dimensions, time, cost) operator is intended for breaking of the psychological inertia.
The Numeric Axis (NA) operator is the next step in development of the DTC operator.
According to the NA operator we can change from usual to zero or from usual to infinite any our system parameters.
How could we improve usage of the NA operator?
According to I-MUST we define a problem on the five functional levels:
1. UDE (undesired effect)
2. Subject (means - the element connected with UDE)
3 Action (of the element)
4. Object (of the action)
5. Environment
I think you have guessed already that as the parameters we will change with help of the NA operator are parameters of:
1. UDE (from usual to zero or from usual to infinite)
2. Subject (from usual to zero or from usual to infinite)
3 Action (from usual to zero or from usual to infinite)
4. Object (from usual to zero or from usual to infinite)
5. Environment (from usual to zero or from usual to infinite)
Moreover we can enhance usage of the NA operator with help of the system operator and/or PSM (problem situation mapping)
 

MUST and Resources
Resources of any system can be divided according to “consuming levels":
• Resources that are connected with results from the system (satisfied needs)
• Resources that are connected with methods to gain the results
• Resources that are connected with technologies the methods are based on
• Resources that are connected with means which support the technologies
• Resources that are connected to parameters (of the means)

Actually such an approach to resources enables us to not only reveal obvious or latent resources of the system, but also show us possible alternative changes on different levels of the system that will "bring" a new set of resources
By the way, the same approach to all TRIZ basics (system, contradiction, ideality, resource and pattern) brings very interesting results.
For example, contradiction:
We should get and should not get (or should get an opposite) result and so on...
Or ideality:
What is ideality on the level "result" (method, technology etc)?

MUST and Usability Test Mistakes
From MUST (multilevel universal system thinking) point of view there are five levels of mistakes:
-Usability needs were defined wrong
-Usability needs were defined correctly, but methods of their testing were defined wrong
-Usability needs and methods of their testing were defined correctly, but technology of testing was defined wrong
-Usability needs, methods of their testing and testing technologies were defined correctly, but means of testing were defined wrong
-Usability needs, methods of their testing, testing technologies and testing means were defined correctly but testing parameters were defined wrong
Testing protocol(s) should cover all mentioned above in order to avoid and/or help to reveal mistakes.

MUST and Sustainability
According to MUST, sustainability demands to any design also might be described with the five consuming levels:
-result(satisfied need)
-method
-technology
-means
-parameters
For example:
Result: sack that does not cause harm to nature (or causes less harm)
Method: biodegradable suck or sack that is destroyed by animals or plants
Technology(one of possible technologies):set of connected phenomena the method is based on (chemical, physical or biological if you produce your sack from something that bacteria eat)
Means: technical solution that supports the technology (pores or pockets that keep water to dissolve the sack quickly)
Parameters: pores dimensions, time to dissolve etc.
Library of sustainability demands/results that are classified according to such a " consuming key" would be very helpful for the sustainable design process.
In case you have a sustainability non-conformance you can present it as UDE and use I-MUST approach to find a solution concept

Usage of MUST as a Matching-Mismatching Diagnostic Tool
When we deal with a technical system it is obvious that there should be match between its so called “consuming levels”: result, method, technology, means and parameters.
Otherwise the system simply will not work properly.
Imagine yourself that a method does not enable to get a result or isn’t supported by a technology,
or the technology is not supported by means…
When we deal with a human personality or with a company vision, mission etc. the issue stops to be obvious…
Mismatching between human personality’s levels such as identity, believes, abilities etc. or between a company’s vision, mission values etc. sometimes isn’t so “visible”.
In this case MUST approach might be used as a “health” diagnostic tool.
Actually such an approach is a transfer of so called matching-mismatching regularity to a new level.
I would like to point that actually MUST will take in this case nearly the same form, but one has to define so called " consuming levels" for the specific non-technical field.
What are results (satisfied needs) for the field?
What are methods to gain results that are used in the field?
What are technologies (a set of connected each other scientific phenomena) that are used in the field to support methods?
What are means that are used in the field to implement technologies?
What are parameters?
This will help accommodate I-MUST procedures to the chosen non-technical field.

MUST and Techno-Gene Hypothesis
“In his book The Selfish Gene (1976), the evolutionary biologist Richard Dawkins used the term meme to describe a unit of human cultural transmission analogous to the gene, arguing that replication also happens in culture, albeit in a different sense"
See more here:
http://en.wikipedia.org/wiki/Memetics
What is about techno-genes? What are they? There is so called "gene pool" and "meme pool". What is a techno-gene pool?
Look at this excellent serial:

Does it show us "techno-genes"?
MUST usage for improvement of methods and/or generations of patterns deserves a separate discussion, in my opinion.
Some of such patterns are "techno-genes", in my opinion.
Technical (and non technical) effects collections might be built in form of such patterns
TRIZ standards, for example, might be presented in this manner etc.
I think it is a possible but time consuming work.
The main point is in correct classifying of "results".
In other words one has to develop a "key" to classify properties.
It will be a complex "key", in my opinion.

In my opinion, techno-genes are "information pieces" that describe properties that enable technical systems to perform their functions (action, process activity).
These properties are not the functions themselves.
I suggested the MUST based classification key, where a property itself is a "result" that might be gained by different methods, that might be based on different technologies, that might be supported by different means, that might have different sets of parameters.
Systems are related to the same kind (group, family, class, type) according to their level matches.
A "techno-genetic information" is kept and transferred by so called technological infrastructure.
The dominance issues are more interesting.
In my opinion, they are influenced by  the technical systems' development regularities

"Library" of techno-genes could help us to build technical systems with previously defined properties. But such a library (or pool of techno-genes) needs a good classification in order to find an "appropriate" techno-gene. It also needs "rules" to join various techno-genes together. We also would like to have some regularities of inheritance and changeability, dominance and recessiveness etc. for techno-genes.

Techno-gene classification "key" with refrigerator example.
1. The result – one (or set) of external properties of the technical system
for example: cooling the internal volume
2. The method of gaining this set of properties (could be a number of different methods)
for example: cooling the internal volume by the circulation of the refrigerant
3. Technology the method is based on (might be several different technologies)
for example: cooling of the refrigerant that is based on adiabatic expansion/compression
4. Means (technical solution), supporting this technology might be different means that support the same technology) for example: a technical solution realizing the adiabatic expansion/compression
5. Parameters (the same technical solution might have different sets of parameters)
for example : design and parameters of a specific compressor, radiator, cooling chamber and so on.
Techno-genes related to the first level determine qualities defining the type of the technical system
for example : the idea of cooling the internal volume
Techno-genes related to the second level determine qualities defining the class of the technical system
for example : the idea of cooling by circulation of the refrigerant
Techno-genes related to the third level determine qualities defining the group of the technical system
for example : the idea to use adiabatic expansion/compression to cool the refrigerant
Techno-genes related to the fourth level determine qualities defining the family of the technical system
for example : the idea (technical solutions), used to implement the adiabatic expansion / compression
Techno-genes related to the fifth level determine qualities defining the kind of the technical system
For example : the smallest ideas associated with design of the refrigerator

MUST and Case Studies
As you know, good case studies rarely (I would say "never") involve usage of only one problem solving tool.
We can come to the same solution by different ways using inventive principle, separation principles inventive standards etc.
We also can describe each of the ways by the five consuming levels:
-result (satisfied need)
-method
-technology
-means
-parameters
In case of the separation principles (method) the "result" will be a property that enables to resolve a contradiction.
In case of the inventive principles (method) the "result" will be a property that enables to change:
-UDE (undesirable effect)
-element connected with the UDE
-function (action, activity, process) of the element
-object of the function
-environment
In case of the inventive standards (method) the "result" will be a property that enables:
-to perform a function (change or measurement/detection)
-to eliminate UDE (low efficiency or harmful interaction)
Each solution way (of the case study) should be also described on levels “technology”, “means” and “parameters”.
Such a description (problem solving tools – consuming level) allows better organizing of a base where diverse case studies are connected each other.
Thus to describe a case study we will fill a table.
As names of the table columns we write problem solving tools.
As names of the table rows we write consuming levels.

MUST and Feature Transfer
There are two feature transfer sides:
The first one is connected with a knowledge transfer into your activity field.
You have a problem and you resolve it by means that are out of your realm.
For more see here:
http://www.triz-journal.com/archives/2005/08/04.pdf
Here are more search results:

The second one is connected with transfer of your knowledge into other fields.
You have a solution and look for problems that are out of your realm in order to resolve them.
It is sometimes connected with finding a so called “unmet need”.
One of the methods in such a case is to perform a multi-level analysis in order to widen field of your potential “customers”:
• Your specific system with specific set of parameters (parameters' level) -> your nowadays customers (and your initial point)
• Technical solution that your specific system is based on (means level) -> what are the customers that need the same technical solution, but with a different set of parameters?
• Scientific (physical chemical, biological etc.) solution your specific system is based on (technology level) -> who are the customers that need the same technology (but a different technical solution) and what are the functions (different from your system functions) that your specific technology is able to support?
• Functions of your specific system (method level) -> who are the customers that need the same (or a little different) functions?
• Result of your specific system (result level) -> who are the customers that need the same (in other environment for example) result?

Functional Blocks and their Connection to MUST
Every function (action, process, activity) changes a specific parameter(s) of an object of the function.
Thus when we join together function and anti-function we can receive an additional property (quality) that is connected with stabilization of this specific parameter.
If we take into account dynamism of the joined function and anti-function we also receive possibility to change this stabilization point.
Thus when we join a function and its anti-function we get two additional properties (qualities):
•stabilization of the specific parameter;
•possibility to change this stabilization point;
For example, joining together of the air-heater and refrigerator enables us: to increase temperature, to decrease temperature, to stabilize temperature and to change the point of stabilization.
These four functions (changing, anti-changing, stabilization and change of the stabilization point) together are called "functional block".
Type of energy for functions performance is called “performance level".
Place in hierarchy (system, sub-system super-system) where they are performed is called “hierarchy level”.
Though if you want to increase the efficiency of your system - transit to functional block with the same performance and hierarchy levels of its functions.
Functional block is very controllable.
That’s why such a transition sometimes enables us easily resolve very hard problems by dividing the contrary demands in time, space, and structure and upon condition.
Let's take the real problem
How can one get the gold coating only on specific areas of the surfaces of the micro-scheme shell.
The use of masks takes a lot of time to place and then remove them.
The screens without contact (currently in use) give partial protection - the coating at unwanted areas is thinner.
Let's transform gold coating process into a "functional block"
Gold coating - the parameter is thickness of the coating
Gold discoating (gold removal) - the opposite process
Stabilization of the gold coating parameters (thickness and place of the coating) Change of the stabilization point (thickness and place of the coating)
As you can see now we are able now to resolve the problem by separating (in time for example) elements of the "functional block".
We perform electrolytic coating with screens and then remove screens and perform dis-coating (also electrolytic - the same performance level, because it is possible in this case).
The screens have provided thinner coating at unwanted areas.
That's why discoating (without screens) will remove this thin layer of gold first.
According to MUST we can join together:
• Result and anti-result
• Method and anti-method
• Technology and anti-technology
• Means and anti-means
• Parameters and anti-parameters
Thus with help of MUST we widen meaning of the functional block,

It (block) becomes something more than simply "functional"

I-MUST and Correct Problem Statement
There are two types of problems:
a) Absence of a system to perform a function in order to obtain a specific result
b) Undesirable effect (UDE) in an existing system
In case a) we define:
•Action
•Action object
•More or less suitable system to perform the action (means)
•UDE which appears when we use this suitable system
•Environment
In case b) we define:
•UDE
•Element of the system connected with this UDE (means)
•Action of this element
•Action object
•Environment
As you could see, in order to state a problem correctly, we actually define the functioning levels for each of the types.
What one has to do with the “correctly stated problem”?
First - he/she can apply the 40 inventive principles or typical changes that were suggested here:
Second – he/she can continue the analysis…
There are two problem solving directions:
a) Performance of action of the element (system) that is connected with UDE without the element itself – in this case there is no UDE, but we have to find something that will perform function of the removed element.
b) UDE  removal
Then she/he can try to find a solution for each direction by mobilizing resources and resolving contradictions in case they appear with five separation principles:
• In time
• In space
• In structure
• Upon condition
• By extra-element (from resources) incorporation
Or she/he can continue the analysis (mainly for technological problems).
For a) we define if the action to be performed is connected with producing or detection/measurement.
For b) we define if the UDE is connected with a harmful interaction (action) or inefficiency.
These four opportunities point us groups of the classic TRIZ standards to be used in order to find a solution concept.
I describe how the classic TRIZ tools might be connected to the I-MUST procedures, because it enables us to use them immediately.
 But (as it was mentioned in other discussions) better if TRIZ tools will be re-arranged using the MUST approach for more efficient usage.