Supra system: it also needs to be found! ​

The Supra system (sometimes referred to as the using system) must first and foremost be checked to ensure that the system-of-interest is, during its operation, an integral physical part of this system, meaning it literally is part of the composition of the supra system. Unfortunately, most mistakes occur due to neglect of this characteristic.

System breakdown structure is a hierarchy based on part-whole relationships and not on any other relationships. Errors in identifying the supra system and the system-of-interest are indicated by detecting relationships such as function invocation, classification, specialization, ownership of property parts, assignment to a role - besides the prescribed composition relationship for system breakdown.

For example, consider a man and a woman. What would be their supra system? They interact in some way, there is some functionality as part of the supra system. But what exactly is it? College students might spend minutes solving this puzzle, while more mature audiences take only fifteen seconds: the family is the supra system here (students often say "couple," emphasizing a potentially weaker connection), and the woman and man operate in each other's operational environment. The puzzle is solved by identifying the missing, unnamed, undiscovered system in the system breakdown. This is a typical situation: supra systems are usually poorly discernible, sometimes they do not have established names. These "missing" systems have to be identified/determined (that is, describe their roles, functions, boundaries) and somehow named. How to name them? The same way any other system is named, primarily (if there is no established historical name) based on the role of the supra system in its supra system, that is, based on its role in the supra-supra system in relation to the system-of-interest.

When identifying the supra system from the system-of-interest (which project teams usually have to deal with both systems), the team is not authorized to independently change the system itself or even its descriptions/models (usage concept, system concept, architecture). A decade ago, it was not assumed that the team could influence the supra system - it took it as a given and simply had to integrate its system-of-interest with the existing system environment. Today, the project team is not authorized to directly change the system environment, but it can influence the modification of this supra system for alignment with the characteristics of the system-of-interest - either by its owners or by the project team in agreement with the owners of the supra system. For this, the project team (internal project roles) actively works with external project roles/stakeholders, influencing them, and this takes time because "everything is continuous," system development lasts and is not a "make and forget" situation.

When identifying the supra system, it is important that it is at the closest system level (the postman principle: the address should be precise - you cannot refer to a too general object), where emergence/system effects are expected from the operation of the system-of-interest within it.

A reliable way to identify the supra system is to understand which people (remember, you are talking to roles!) you have to communicate with for the project to succeed. They are usually the owners of the supra system. For example, if you are developing a "system for airplane transport" used during airplane repairs, the supra system might be the country's aviation or the Ministry of Industry? No, the postman principle says this is "true but pointless information," you could equally talk about "humanity" as a supra system, or even the "entire universe"! In this case, it is pretty straightforward to find out that the "system for airplane transport" mainly interests people from the operating service of one of the aerospace companies.

The operating service of this aerospace company (and not the entire aerospace company!) is the supra system for the airplane transport system, and the system-of-interest there will be the airplane that needs to be transported. The airplane transport system is one of the system creators for the airplane, a transportation service. The team of the operating service of the aerospace company (external project roles concerning the airplane transport system) has needs - they need to repair airplanes that are not flying. Therefore, they have a conception of using the ground-based airplane transport system (for non-flying airplanes). From this point (the airplane transport system as part of the operating service of the aerospace company = the system as part of the supra system), you can start discussing the project to create the airplane transport system. Engaging with the owners of the supra system (unless it is a system of systems) is usually highly productive: you will need to communicate with these owners anyway, as they are key external roles in your project.

Another error is when the supra system and system-of-interest are named the same (we have already discussed this error, but it is repeated over and over, so let's repeat it in different words). Divisions like "A consists of A and B" are unacceptable, it should only be "A consists of B and C" - and most likely, this error is not that the division itself is incorrect, but simply the names chosen for the systems in it are wrong. For example, "cell consists of cell and gasket." A detailed discussion reveals that it is actually the cell that consists of the casing and gasket. "Living room consists of room and interior." A detailed discussion shows that the living room consists of the space (the structural part, the box without finishing) and the interior (including even the wallpaper stuck to the walls of the space).

System thinking also means that you must understand the structure of the supra system to understand the role of the system-of-interest in it. In the figure of this section, this is indicated as reverse engineering for the using system (and ontology - these are different descriptions of the supra system obtained through reverse engineering, dissecting the structure of the supra system). Whereas you will be deriving the system-of-interest with direct engineering or just engineering - you will develop descriptions of the system-of-interest so that the system-of-interest can fulfill its function in the supra system. How to do all this is detailed in systems engineering. System thinking merely points out that you must definitely understand the function of the system-of-interest in the supra system, you must definitely identify the supra system and somehow understand its structure. If you do not understand the supra system, if you do not understand the higher-level system, then you do not have system thinking. The approach of project attention from the system-of-interest to the supra system and dissecting the nearby system environment is what is essential in system thinking.