System approach: for all types of systems, not just for the system of interest. ​

System thinking has the property of recursion in its application: it unfolds similarly for each of the systems in extensive and deep system breakdowns. It is necessary to specifically highlight the target system among the numerous system levels of some system breakdown primarily due to the need to remember what is the collective goal, i.e., for working in team projects. This is an innovation of the second generation of the system approach, the activity-driven (subjective/post-positivist, i.e., defined by the intention of some agent to change something in the physical world) introduction of the system-of-interest. The target system is always distinguished by someone for something, and not "objectively" and "correct/true."

Nevertheless, the concepts of system thinking are applicable to all systems, not just the target one.

Thus, there are suprasystems and subsystems for both the target system, the suprasystem, the subsystems, and for any other systems in the environment and even in creating systems in their long chains. Distinguishing between descriptions and system documentation, as well as system realization, is necessary for all systems. All systems are primarily named by their primary purpose/role in the environment. In all systems, subsystems interact to manifest emergence/system effect.

There can be multiple systems of a certain kind in a project, not necessarily just one. For example, there can be many suprasystems for one target system. The target system may well be part of a multitude of suprasystems, each having its own group of stakeholder roles occupied with their own projects, concerned about their different needs for each of the numerous suprasystems. And there can also be a multitude of creating systems for one target system **(for example, one company designs a building, another constructs it, a third operates it, and this same third demolishes it--each company will be a separate creating system/life cycle management system.) Of course, it is always possible to emphasize the emergence/system effect resulting from the fact that all these companies work together in a sense (and often this collaboration is specified in contracts between these companies), and to say that all these are not separate creating systems, but subsystems of the same creating system, but this is not usually done. Therefore, we more often speak of a "chain of creating systems"/"chain of creators" or even "chains of creating systems"/"chains of creators". This is a creation graph, not just a linear sequence: one creator can create and develop several different systems, including several different creators, and one system, including different creators. Even in the biological world, the creation of most organisms involves not only the female, but a population of two organisms: the male and the female. But for simplicity, we will call this "creation chain" to emphasize the fact that it is not one all-encompassing creation system, but many, including creators of creators.

Managers often make another mistake: trying to identify a typical target system that they work on in very different projects that are not alike at all. This leads to serious complications: since the suprasystems for these systems turn out to be completely different, it is impossible to generalize different needs of very different external project roles for one target system. Projects for different systems need to be separated in these cases, not artificially combined. If there is no emergence, then there is no need to combine some parts into an artificially created "system". If a manager has come across ten projects by different means, there is no need to pretend that it is one big project and there is a system effect of merging these ten projects into one, these ten target systems into one: we have already discussed many times, that "relations of ownership" are not "part-whole" relations.

The presence of several different system breakdowns (at least, including in the consideration for allegedly one target system various suprasystems with their various external project roles) should raise concern: most likely the issue is not one project, but several. It is not about them being different types of breakdowns: functional, constructive, spatial, by sources of financing, etc. The point is that multiple versions of different functional or constructive breakdowns of the same type arise. For example, you are involved in coloring seashells and installing decorations. Do not try to combine these projects, define a "shell-decoration system." You will have to deal separately with coloring seashells, understand their suprasystems, have specialists for the necessary shell coloring target systems creating/projects/organizational units/enterprises. And separately deal with decorations and their installation, understand their suprasystems, have a separate project with separate installation specialists. If these projects have the same manager, or even the same team, the systems in these projects will be different.

Do not mix these systems, do not mix these projects. Work with them separately. Most likely, these projects have very different situations, they require different engineering, managerial, creative solutions, different modeling, interaction with different external project roles. Every time generalization or combining of projects and systems occurs, one should ask the question: which questions will become easier to solve with this generalization or combination? It is possible that none--and it is better to develop system thinking individually in different projects, not try to turn them into a "super project."

In summary: to find your target system among others in a systematic breakdown, you need to ask questions not only about it but also answer many related questions:

• What is your target system personally?
• What is the client's target system?
• What is your team's target system?
• What can you change with your decision, and what can you only influence?
• What can your client change with their decision (there are different sub-roles! And they may have different views on the decision!), and what can they only influence?
• Which system do you call a target system for yourself when you think? Your* clients? Your team?
• When you (who is included in this "you"? where are the boundaries of this "you"?) communicate jointly with the client, the team, what system will you call a target system--your own, the client's, the team's? Keep in mind the saying of theater people: "as it was at the rehearsal, it will be at the performance". It is better that in different conversations you call the same systems the same.
• Whose team is it--yours or your client's? Is your team within the company "against all and the client" or is the entire company as a team "against the client," and there is no "your team against the company"?
• When different people in a project say "we"--who is included in the boundaries of this "we"? Who in this "we" ultimately determines (has no authority to assert someone's choice, but actually thinks and determines!) the choice of the target system, defines its boundaries with the environment? Who is concerned with the suprasystem, namely whose needs are satisfied?

There are no prescribed answers here, no thinking algorithms on these topics, but system thinking suggests thinking about answers to these questions and somehow making a decision. At the same time, it is essential to act actively, communicate a lot: not just sit in one place "just thinking," but also conduct negotiations with various external and internal project roles, with team members and external people, each of whom may have some special interest. System thinking is about agreements. You need to reach agreements in the project, and system thinking suggests which questions are important to achieve these agreements. The first of them is to agree on the target system, define its boundaries, its functions in the suprasystem.

Only after examining the organizational situation can you make a decision: what to consider as the target system**, and what to consider as** your system (these systems may not necessarily coincide!).

Last but not least, portraying oneself as an "objective" system thinker on a white horse "above the fray" is not the case here. No, you must clearly realize--what is your own project role, or set of project roles, how professionally you can play your role, how likely you are to make rookie mistakes in this role. System thinking will help here, but it does not contain "objective answers." System thinking will only help in spending more time contemplating the important aspects, not letting you forget about them: it will help in managing attention in a large project. And this, perhaps (but not guaranteed!), will save you from mistakes in complex situations, will not let you get stuck in unimportant details, will help unite efforts in conditions of deep division of labor among very different project roles dispersed among very different performers of these roles.

Your system among others in a systematic breakdown is defined as an instance in terms of function/purpose, while considering it first as a black box (the usage concept), always posing the question about the suprasystem and the needs of external project roles that will be satisfied if the target system starts operating as part of the suprasystem. Examining from the boundary of the target system upwards in the system breakdown (viewing the target system as a "black box") is primary, examining downwards in the system breakdown (viewing the "white box," the composition of the target system, the system concept) is secondary. The system is always first considered as a part (its suprasystem), and only then as a whole (with subsystems included in it).