One system, but multiple descriptions, multiple names: that's normal!
Quadruple (these are just the main four! There are many, many more!), a "non-united" perception of a holistic system is normal and should be so! Unity in the minds of different project roles with different interests can only be non-thinking alike. Real unity of all these descriptions is only provided by a Cartesian understanding, that the constructive part/product/item/module (what it is made of) occupies the same place in space-time as do the functional parts, whose roles are played by the constructive part and the place itself --- this is placement, and the system also has value (preferably less than the irrevocable benefit it brings). This is the realization relation of the constructive parts to the functional/role parts. All these are descriptions of the same physical object in space-time. No identifications by categorizing into certain types, as in logic or mathematics! All identifications are solely by the path to physical reality, to a physical object in a specific location in space-time!
The four main ways of extracting parts of the same system provide four main ways of organizing attention, emphasizing the main and discarding the secondary. Next, project roles must agree that all four descriptions do not contradict each other, describing the same system.
German electrical engineers took a trick from the IEC 81346 standard creators of system descriptions: to immediately indicate what type of parts of the system is being referred to, they name them using special prefixes: functional/role prefix "=", modular/product prefix "-", placement prefix "+". Names are provided at each level of system breakdown, so they become hierarchical in a part-whole relationship, but this relationship is built based on a specific type of objects in the breakdown.
For example, =S12 =16 means that it refers to functional part 16 which is part of (relation composition/is_part_of) functional part S12. Design is of course carried out in classes: these are the names of the parts of the system, not specific parts of a particular physical system at a specific moment in time (instances of a class embodiment). The number of levels in such a name is not limited. Engineers often refer to such functional/role names as tags.
If the name is -M87-K5, then it refers to product/module/constructive/item K5, which is part of module M87. This also does not denote a specific physical object with a serial number, but rather a class of objects, a class of products of a particular brand.
The standard IEC 81346 established such naming to provide short codes instead of "normal" long names. Indeed, if a Boeing 787 aircraft has 6 million individual parts (a part -- here an indivisible constructive part of a system), that immediately implies that each part will have several names, including functional names and location names. It is hence better to keep these names short, making it clear to which type of parts and to which whole within the aircraft they belong. The standard establishes a modern engineering consensus regarding the three main types of system breakdown, but also adds that there may be other types of descriptions. These are the primary ones and are mandatory! Looking at current projects, naming (we will not delve into the subtle differences between identification and designation here) parts of the system and the system as a whole proceeds in this manner, with additional characteristics such as voltage or pressure, standard size, and even price (though the price is not a complete substitute for the total cost of ownership, it is not a name or code, but without this description discussion of the system's cost is incomplete).
We have already encountered situations where Prince Hamlet and Vasily Pupkin can be the same person but called differently depending on what we need from him: to understand which line will follow in his play (this is about functionality, i.e. about Prince Hamlet), when he plans to learn a new role in a new performance (this is about constructiveness, i.e. about Vasily Pupkin), or to find out if he has children (this is about constructiveness, i.e. about Vasily Pupkin, if not referring to "children from the play"). The same can be said for an inanimate system: "pressure gauge in the fifth cooling circuit" (role/functional object), "manometer KLM-23 of the plant "PressureAssemblyAutomation" (constructive object/product/module), and "sensor in the fifth box on the third shelf of warehouse number 4" (sensor in an allocation object), and "$300" can very well refer to the same device. Different names indicate that we are planning completely different actions with this device, so the same device serves different purposes and therefore has different names. This is normal, unavoidable! Forcing all project roles to use the same name (including the same classifier that helps assign a unique code), the same system part division is impossible and unproductive. Acknowledging role-based thinking, driven by role interest, requires multiple names for objects, multiple classifiers for parts of the system. But you must give these names meaningfully; it is not just naming freedom where everyone writes as they see fit because "I am an artist, that's how I see it".
The name "Prince Hamlet -- Vasily Pupkin" makes perfect sense, although it uses two names representing separate facets of the actor: the character and the role player. Similarly, system names in industry often consist of names of multiple facets, for example, "=S12=16 --M87-K5 $300" (a name made up of three names listed with spaces, and we arbitrarily included price as a name, even though that's not entirely accurate, intuitively indicating financial factors alongside the name does not feel unusual, highlighting the finance characteristic). Usually, such a system name/designator can only be used in one specific project, just as "Prince Hamlet -- Vasily Pupkin" can only be used in one play; in another play, roles will be distributed differently. All these names indicate a place in space so that understanding can always be achieved by clarifying the situation in the physical world. It is futile to demand definitions and then try to fit different objects in the project to a predefined notion!
You are warned: disputes about definitions/terms are meaningless; system thinking is not mathematics! It is pointless to refine definitions "like in mathematics," "like in a dictionary," "like in science" for a hot system (functional), something bought yesterday (product/constructive), or for a future system (placement), an expensive or inexpensive (cost) system, one needs to understand the situation solely through realizing where these systems are located in physical space-time: if in different places-times, then they are different objects; if in the same place-time, then they are differently described variations of the same object, the same system. Having multiple descriptions, not just one, multiple names, not just one, is normal in system thinking!
The essence of the systemic approach is to never forget about the system as a whole at any given time -- the system embodiment, which is simply represented differently by different project roles split into parts. The agility of retaining simultaneous different representations from different roles to satisfy their different interests in the same object, agility in working with numerous descriptions of one system, including various ways of dividing the system into parts, requires some time to learn, although the idea itself is understood from the first presentation. But understanding is one thing -- being able to freely wield such multifaceted thinking, maintaining the attention of different role representations to meet their varied interests in the same object, is another. Making notes of these objects of attention helps tremendously: no need to keep this systemic multiplicity in mind, write it down! In system thinking, usually "all moves are recorded," greatly simplifying things. Computers do not forget, records in them are accessible to many people playing various roles in the project; therefore, system breakdowns are always documented, it is not customary to agree on system breakdowns "by word of mouth." Document your breakdowns!