Non-matching of functional and modular breakdowns of the system
System breakdowns for different project roles also turn out to be different because it's all about the "system in the eyes of the viewer": each breakdown with its way of extracting objects of attention from the world is convenient for discussing some objects of interest, but inconvenient for discussing others.
In projects, system boundaries are usually chosen in such a way that they occupy the same place in space-time as the functional/role part, the product/constructive part, and the allocation, as shown in the image with a cube. However, if one starts to understand how such a system works (its functional parts), what it is made of (modules, product/constructive parts), how it is composed (locations/allocation), and how much all of this will cost, it may turn out that sometimes functional parts, product parts, and locations in it all completely coincide (and they will be called "subsystems" - after all, subsystems are also systems), but sometimes there will be no such coincidence - and that's intentional, that's normal!
For instance, TRIZ (theory of inventive problem solving) increases the ideality of systems invented in it by ensuring that several different functions (remember: a function is the behavior of a functional/role part of the system during the operation of the supersystem) are performed with fewer constructive parts - in an ideal system, all functions are performed with zero construction parts (there is no construction at all, only the functions are performed!), and TRIZ strives for this. So, it cannot be guaranteed that the system/functional breakdown, as well as the product/constructive breakdown and spatial breakdown, coincide. In 9 cases out of 10, they might coincide, but you will have huge problems in the project with the remaining one case if you do not take it into account!
Functional parts and products/modules should not be confused. The role of Hamlet and the constructive character Vasily Pupkin should not be confused, even if during the performance they may be the same, they coincide 1:1. If you address Vasily Pupkin as "Your Highness" behind the scenes and ask Hamlet about his wife and children on stage, people will look at you strangely, and Vasily Pupkin will be deeply puzzled in both cases.
We have already considered a tea kettle in which there are only two products/modules (body and lid) and quite a few functional parts (capacity, spout, filling hole in the capacity, handle of the capacity, lid, handle of the lid, steam release hole).
It may seem difficult to confuse functional and constructive parts in a teapot, right? Unfortunately, it is easy!
Let's consider the example of scissors to see what happens when people confuse functional parts (role parts during operation time, interacting with the environment as intended) and constructive/product/module parts (during creation time, on which creation systems work for their design and manufacturing).
For scissors, engineers come up with different shapes for the handle and the blade, thinking of the handle and the blade as functional parts. They discuss the handle and the blade as physically existing objects (they hold the handle, consider its size and smoothness, cut with the blade - considering its strength and sharpness, the opening angle). If the procurement department managers perceive scissors as consisting of such functional parts as products/items/modules, they will try to order works for the production of handles and blades separately: handles to a company specializing in ergonomics, and the cutting blade to a factory that knows how to make knives (after all, the word "scissors" comes from the word "knife"!). Engineers will be shocked by this since for manufacturing and assembly purposes, they begin to think about scissors as consisting of modules/work products: two solid pieces of metal of a special shape joined by a screw. Only products can be ordered, and the handle and the blade of the scissors are only role/functional elements - their role is not played by anyone if there are no items/products/modules assigned to these roles! There will be only two halves of the scissors (and a screw) as modules within scissors. If the handles and the blade are made separately as modules and then somehow connected, it will be a poor and unreliable engineering solution. Here is the scissors at the moment of "how to make it" (modular breakdown):
Managers initially listen to the arguments of engineers, but then... they look at the assembled scissors, see them in action (during operations), the handle and the blade - and again, they try to do something with them separately not during the "performance" (when the scissors are assembled and in use - cutting), but during manufacturing. For example, separating the assembly works of the handle and the blade, even though it is fundamentally impossible to separate the works of the handle and the blade when joining the scissor halves with a screw. Or to create catalogs of handles and blade blocks and then try to make engineers produce these supposedly "scissor parts" as spare parts. The list of mistakes and misconceptions here is endless, and these mistakes will not stop: managers constantly find the "blade" and "handles" in the engineering documentation and try to treat them as assembly units.
The truth is, in scissors, different project roles see two different breakdowns: one with a functional decomposition ("analytical") and the other with a modular assembly ("synthetic"):
The target system is unified as a functional part and as a constructive whole (they are completely coincidental), but then the "functional structure"/"system breakdown" and the "modular structure"/"product decomposition"/"constructive breakdown" can significantly differ.
In engineering modeling languages, the "iron" concepts of the system (previously called "architectures," before architecture had its own subject of work to optimize the connections of modules to obtain acceptable architectural characteristics of the system), as well as in enterprise modeling languages, functional and constructive parts have different symbols denoting the different types of these objects. If the difference between them is not understood, the use of these languages becomes erroneous.
If in project management you create charts for the implementation of modules (for example, finalizing the descriptions of module containers in software engineering) and the implementation of functional parts (in programming, they might be called "features") - they will be completely different, but both can be meaningful! The most important thing at that moment is the decisions of the system creators, which construction elements realize which functions required for the system to operate. Usually, to do this, it is necessary to describe both the functions (behavior) and the functional parts (role parts that perform the behavior/function), and the constructive parts/modules/products/items, and where all this is located (composition), and the cost components (how the total cost ownership is distributed, and also the cost of creation). In complex cases, functions (behavior) and functional parts (role objects with certain behaviors) are modeled separately. In simpler cases, you either deal with functions/behavior or with functional/role parts - but never only with constructive parts/products/modules because the subject of interest of "how it works" must be discussed, it cannot be skipped. "How it works," functionality as the area of interest - this is the main area/zone of interest in modern system thinking, the main subject of interest, the most important characteristic of the system!
The importance of functional breakdown is emphasized in the most modern research, where system thinking is used to explain phenomena such as evolution and life. The functional aspect is introduced through the term affordance, implying the unity of the agent and a constructive object in the surrounding environment that the agent can use for its purposes (performing a certain function). The term affordance emphasizes the "non-objectivity" of functionality; its definition depends on the agent, who attributes to a functionally-neutral physical/constructive environmental object some necessary function in the target system; the agent thereby "invents," demonstrating thinking.