Skip to content
Create an account for full access.

Manufacturing systems as constructs in their potential roles

Even highly intellectual system creators usually do not appoint arbitrary functions to themselves, they take functions "borrowed" from culture--- these are behavior patterns, so repeatability is important (the pattern is observed in a series of behaviors, this is the "template"). So the method/way/practice/function reflects in some way "sameness"/patternness/similarity, following one style/culture/method of behaviors. And after that, you can talk about roughly the same when it comes to a role. And then either there is already a term in the language for a function like behavior (heating---heater), or there isn't, then it needs to be invented (sepulement---septum).

The hammer did not appoint itself the role of a nail driver, the hammer does not have the function of driving nails. We can take a microscope and appoint it a "hammer" --- to drive nails with it. "Hammer" in this case is nothing more than a role term for the microscope::constructive (or stone::constructive, or even hammer::constructive), the name should not confuse. The behavior of the microscope in the so-named role, its function, "role-playing as a nail driver"---driving nails. If "driving nails" does not apply to the microscope but to Vasya-with-a-microscope, "driving nails" will often be referred to not as a "function", but as a "method/practice/way/cultural practice", "work type"/activity/"engineering method". Different "almost synonyms" are possible with functions/methods and the roles performing them, even in the names of the types, you might have noticed them already, we tried to use many synonymous series for culture/style/"work type"/method of work (but not the work itself! In the course "Methodology" the difference will be explained: work implies a resource consideration "who is working on what", while methods/ways of working imply a substantive consideration" how to do it all, regardless of when and with which particular object instances").

You can say "the culture of nail driving", why not---although people do not speak of nail driving this way, they will discuss the "work method". But something like "tango dancing" could easily be called a culture or style of dancing, but not a "work method" or even a "type of work". The main thing to understand is that "tango dancing" and "nail driving"--- are objects of the same kind: function/method/culture of work behavior of a dancer and function/method/culture of work behavior of a carpenter. The synonymy of nail driving functions for a carpenter-with-a-tool and a hammer-or-microscope-without-a-carpenter (the tool and the agent-with-a-tool seem to perform the same function, but in fact, their roles and functions differ)---such synonymy will also have to be somehow resolved. In large projects with thousands and thousands of role and function/method names, there can be great confusion, especially now that a hammer or microscope could have artificial intelligence, which further complicates understanding others' terms and choosing your own terms.

Why is it important to use culturally conditioned terms rather than inventing them yourself? For example, calling Vasya in the role of an engineer an engineer, not a "life enhancer" or "creator of successful systems"? First of all, it's a question of understanding: you won't have to explain in detail what Vasya does as an engineer, you can refer people to the culture (that is, suggest to "google it" or ask an AI assistant). Interestingly, in this process, you may come across some textbooks (or regulations, instructions, international and industry standards) on work methods that you were not familiar with. Read them, our students were surprised to find that many of their work problems were described in textbooks, as well as ways to solve these problems---they just didn't realize that their work was not unique, many people on the planet were and are doing this work, so there are patterns (methods/practices/cultures/styles) of work to follow in order to work in a role with fewer problems. Solving tasks (when you know what to do, and just need to gather resources and do the work following a known method) is much easier than overcoming problems (when it's not clear what's going on and what to do---but then work doesn't seem to progress).

So try not to invent terminological bicycles, or invent work methods yourself, or redefine culturally conditioned roles. Of course, everything in textbooks/instructions/standards needs to be adapted to work situations, but it's better to arrive at real problems on the rails of explanations already provided for different work methods used by existing roles, before adapting them. Or be prepared to reap the fruits of rookie mistakes. You can, of course, spend a huge amount of time learning how to play on a DJ console through trial and error, but going to a DJ school or at least taking a DJ course through self-study---is a much shorter path. This reasoning also applies to management methods and managerial roles, although it is somehow understood less clear. "Can you play the violin? No, but I think I can"---this joke somehow turns out not to be a joke in management, but the main argument. A qualified agent with the skills of a heat engineering engineer or even a human resources engineer goes into operational management---not knowing anything about this culture, although there are many textbooks on this topic. Well, and the result---a large number of management mistakes, "inventing crooked bicycles". So remember: behind everymethod/practice/culture of work, activity/typework/engineering there is a textbook (often in the form of a regulation, instruction, corporate standard, online course, etc.), and when signing up for a role in a project--- you should at least browse through such a textbook for your method (unless you are working on such a frontier where this method needs to be created, then you will be the one writing such a textbook for those who follow in your footsteps, such as your employees).

If the terminology with "function" is chosen, then the function is performed by a role/"functional object"/"physical object as a role". Or, in other words, simply put: role behavior is carried out by an activity role (method/way/practice---it's "role behavior", you must be able to see mentioning the method/way/practice/culture/style/method of work in the "role behavior"). Or the functional "object" might suddenly be called the functional "element", while ignoring the fact that the "element" implies something indivisible and further divided into parts. Or in the organization, they will not use terms from the textbook/method "configuration management for manufacturing plants", but instead they will talk about the assembly working process for their products---and it turns out to be the same as "configuration management"::method, only some problems from the "configuration management" textbook turn out to be unnoticed, and the terminology is completely invented on the spot, not taken from the literature. Of course, with this kind of approach, problems can be expected: it would be good to understand where the inconsistencies with the method from the textbook come from and what to do with problems that have not been noticed yet, but which will certainly soon manifest themselves---and it would be better to prevent them.

Words-terms are important and unimportant! Simply try to understand every time what type of concept the term denotes---and from which discipline/theory/knowledge which method this concept is, which version/type of the general method is denoted by this term.

Knowledge/explanations are passed from one situation to another in the form of descriptions in textbooks, corporate regulations, industrial standards "normative work methods"/"norm culture"/"norm behavior":: "preconceived behavior patterns" for systems::roles/"functional objects" (system working time in its role), not behavior norms for different constructive/material objects chosen as affordances to perform a role (system creation time and system developers working time).

But if you are a producer of constructives and expect that they will be somehow engaged (that is, they will be used as affordances for some systems::role), what to call these objects? For example, if you produce a pump. And the customer chooses from different affordances for changing the water pressure: to buy your pump or to use a water tower and pipes (and then the pump to the tower will be completely different)?

In the case of the production of "potential affordances", you can use a technique where target systems are named according to the role by their primary method of work, if it is an "animated agent", or the main function, if it is something not overly sensible (for the pump---the name by the function "suction", compressor---by the function "compression/compressing gas", etc.). Systems are primarily considered role/functional objects at the moment when they perform their role, that is when they are ready and working/functioning/used, providing benefits, changing their work/operation environment in the process.

To the customer, your "pump"::"main expected role" can easily be called a "coolant pump in the second cooling circuit"::role, if its role purpose/function--- is to pump coolant in the second circuit. The pump factory will sell the "pump", but the engineer who buys the pump (who can also be a company! "engineer"---this is a role that a whole company can play!)---will rename it to "suction device", and that's normal. Systems are usually named according to their roles, determined by their primary purpose, that is, according to their most frequently performed function of what they do in the world around them. Imagine if the target system did not exist---what important thing will not happen as a result if this system is removed from the world, if it does not work? Which roles in the current culture usually perform this "important action, which is impossible without the system removed from the world"? That's how you name the system.

When we name a microscope, we primarily mean that it allows you to "see small" at the moment when it is fully manufactured and works. If we considered that a microscope is mainly for hammering things (for example, cracking nuts), we would call it a "nutcracker".

As always in language, the most ancient names have unclear origins and often do not indicate a role/function, but rather a form (hammer, a small hammer---but the hammer itself is derived from the method of beating, fundamentally from the verb "to beat") or something else. But when we develop systems, or want to understand something about systems, it is correct to look for not a constructive/material object representing the system in the name, but the role---and an indication of the function/actions of that role.

Finally, if suddenly the system is a human or an AI agent, or even an organization of people, AI agents, and various equipment, little can be said readily about the purpose/function of such a system in its environment, because with intellectual agents as universal creators, everything is usually complex. And the role behavior/functions of people and universal AI agents will always have to be examined separately and specifically. But thinking about people-or-AI-in-a-role and some microscope-in-a-role will be organized similarly!