Frequent mistakes in identifying the system of interest ​

Signs of the target system are not so many, but people still make mistakes: the problem is that systems thinking does not suggest what constitutes the right choice of a target system. However, its value is that systems thinking compels you to choose, does not let you get away from that choice!

We have already written about these mistakes, but let's repeat once again, so that there is a small checklist at hand of what causes students to fail in essay writing and in work projects leading to project resubmissions, even whole teams resubmitting, and even very large teams:

• Describing the system as the target system. Programmers consider their system to be the source code, not the program at the moment of execution (when all program variables hold the state of the program!). Designers and constructors consider it to be the project and design documentation (regardless of whether in electronic or paper form). A scriptwriter considers it to be the script of a play or film, not the play or film at the moment it is being watched by the audience. A choreographer considers it to be his carefully thought-out set of movements which he shows to the dancers, not the performance/dance composition that the dancer artists will perform. A data modeler thinks it is the data model, not data structured according to the model (for example, a database), and even here the final step is not taken: the target system is usually described by this data, it is not the data itself! We need to carry the thought through to changes in reality, to embodiments, not just to the description of the change in reality! Describing something is not doing, not changing the world! It is not enough to even employ "design for manufacturing," although that is also necessary and important. Design should primarily be concerned with operation; manufacturing is just an intermediate stage. Describing something convenient for manufacturing is not the same as having the manufactured thing that provides its utility during operation!
• Creation/system service provider as the target system. This is a typical mistake made by managers. The mistake leads to an organization prospering in the short term until the investor's money runs out. If you were to assign a manager like this to build an aircraft factory, they would build a factory that works extremely well and all the workers there would be well-fed and taken care of - but the airplanes produced by the factory will not fly because the factory is being built as the target system, with the factory itself being the center of attention, and the airplanes produced are not the focus of that manager's attention, and resources are not allocated sufficiently to produce high-quality airplanes but instead to provide quality working conditions at the factory. A typical and common result of this approach is that more money is allocated for servers for financial services than on servers for engineering calculations for the target system. In fairness, it should be noted that engineers often make the opposite mistake: they do not notice the systems that create the target system - an aspect we will discuss later in the course.
• Same names for the target system and its parts (or the target system and supersystems), it is likely necessary to clarify one of the names used, naming the incomplete system differently (for example, you can say that "a house is made up of a box/building component, utilities, and finishes," but you cannot say "a house is made up of a house, utilities, and finishes").
• Over-generalizations (breaking the postman principle, sending "to the village to grandpa Konstantin Makarych"): this is a common engineering mistake: ignoring the immediate supersystem when defining the target system. It is masked by phrases like "used everywhere" or completely unaddressed. "-- Where is your drilling machine used? - In mechanical engineering!", "-- What dances will you accept for the performance? - Any!" Names of industries, ministries, countries – be wary of such supersystems. Beware of words with universal quantifiers and loss of specificity in the subject area ("any", "every", "universal", "multi-purpose", etc.)
• Relativism - this is an error of all those who are unsure of belonging to a specific team. With relativism, anything can be defined as the "target system," ignoring the presence of one's team, one's own organization, which may have its own "system", not necessarily a target one. In this case, systems thinking ceases to serve the goals of coordinating collective group activity.
• Ignoring the primacy of the main purpose/function in the system. That is, the system is identified not by its intended behavior/function as part of a supersystem at the moment of operation but by other considerations (for example, based on ownership of a group of physical objects/assets by one owner: the part-whole relationship seems to exist, "an asset as part of a group of assets," but there are no interactions in such a group, nor with the system's environment, no new properties arise from combining the assets in a group, meaning it is not a system, there is no system effect). For instance, the "enterprise information system" is very often defined through the relationship of belonging to the enterprise, not based on the main function of this information system, which is a mistake. To say that the "enterprise information system informs" - says nothing about its role/function/purpose in the supersystem (most likely, in this case, the entire enterprise will be that system!). The postman principle indicates this is too general. The example with a dog is usually understood when it comes to adhering to this principle: you should say "guard dog," not "Vasiliy's pet" (relationship to ownership) or "yard animal" (over-generalization and absence of a role in the supersystem). However, for some infrastructure or software systems, this necessary prioritization of examining the functionality of the target system is often omitted, neglecting the redirection of thought to the operational time, not the system creation time, or even to "timeless" ownership relations.
• Missed system. The department working with people with disabilities prepares an educational program for them, this educational program is passed to the educational part of the university; the educational part of the university sends teachers to teach the disabled students based on the specialized program (because they are often unable to follow the general program). The target system here, it seems, is the educated functional part of the disabled person's brain (let's call it "proficiency"), which will be activated in the situations they are taught for. But who teaches the disabled person, which system creates their proficiency? The group of teachers sent to the disabled person by the educational part! This organizational unit is the training provider as the service for creating proficiency, and the educational part is the organizer for this provider, its creating system in the chain of creating proficiency. Understanding that a group of teachers is practically indistinguishable from a group of programmers developing some application - is very difficult since the teachers sent individually by the educational part from the general pool of university teachers are not perceived as an organizational unit. And mistakenly so.
• ... many other errors that manifest in many other situations. Let us reiterate that systems thinking simply defines objects of attention for you, but it is not step-by-step/algorithmic itself. There is no strict sequence of actions that will give a "correct" answer. There are no right answers at all, there are useful and useless (or even harmful) answers to systems thinking questions. These useless and harmful answers to questions are the errors. What questions? The very first question of systems thinking: what is your target system? You cannot avoid answering this question! And it is best not to make frequent mistakes.

Do not be discouraged if you constantly make these mistakes at the outset, even knowing that they are errors. Proficiency and error-free performance in systems thinking (in writing, modeling, simple reasoning), as well as in any other activity (playing musical instruments, speaking a foreign language, etc.), is acquired only through long hours of practice, gaining experience. Throughout the course, you will fill in many tables - and you will already gain some experience in systems thinking. Just keep creating tables like the ones in our course tasks, modify them, fill them out based on your work projects - and soon you will not understand why it was so difficult at the beginning. This is metanoia, when you cannot understand why everything seemed complex and difficult before, and now you systematically think - without even realizing it! Neural networks in the biological brain learn slowly but still learn.