Одна система, но множество описаний, множество имён: это нормально!

Четверное (это только основные четыре! Их много, много больше!), многократное по разным аспектам восприятие целостной системы нормально, так и должно быть! Один раз рассмотрели систему как состоящую из функциональных частей с их поведением во время использования, другой раз рассмотрели систему как конструктивную с поведением заготовок-конструктивов в ходе их изготовления и сборки, третий раз посмотрели на систему как состоящую из компоновочных мест, далее поглядели, что там с совокупной стоимостью владения, что там за методы работы, а затем и сами работы, и сколько они займут чьего времени, и так далее — и ещё удерживать все эти рассмотрения одновременно, чтобы они были согласованы друг с другом.

Единым в мыслях у разных проектных ролей**, имеющих разные интересы,** может быть только единонемыслие, поэтому единства разбиения на части, единства рассмотрения системы в проекте не будет.

Реальное единство всех этих описаний даёт только 4D экстенсионализм: «конструктивные части»/конструктивы/продукты/изделия/модули/аффордансы (из чего собрано) занимают в пространстве-времени то же самое место, что занимают «функциональные части»/роли, которые конструктивы реализуют/воплощают. Само это «занимаемое место» — это и есть «размещение», а ещё система что-то стоит (желательно меньше, чем внешние роли, например, заказчик, оценивают наносимую ей непоправимую пользу).

Отношение между ролью и конструктивом — реализация/realization/воплощение. В речи это отношение часто выражается как «играть роль», то есть выполнять метод/функцию как поведение роли.И конструктивное описание, и функциональное описание**—** это всё описания одно****й и то****й же системы как одного и того же физического объекта в пространстве-времени.Никаких отождествлений конструктивного и функционального описаний через отнесение к каким-то типам, через «определения», как в логике или математике**! Все отождествления****—** только через ход к физической реальности, к физическому объекту в конкретном месте пространства-времени!

Четыре основных способа выделения частей одной и той же системы дают четыре основных способа организации внимания, выделения главного и отбрасывания второстепенного, и это только основные способы — их ведь обычно больше! Далее проектные роли должны договориться о том, что все четыре****основных описания**, а также остальные (не относимые к основным, но нужные для работы)** не противоречат друг другу, описывают одну и ту же систему**.**

У немецких инженеров-электротехников авторами стандарта системных описаний IEC 81346 был подсмотрен приём: чтобы сразу было видно, о каком виде частей системы говорится, их именуют с использованием специальных префиксов:

• функциональный/ролевой префикс “=”,
• модульный/продуктовый префикс “-”,
• префикс размещения “+”.

А имена объектов какого-то разбиения по какому-то одному отношению даются на каждом уровне иерархии этого разбиения (помним: разбиение — это иерархия по отношению часть-целое). Но в каждом разбиении отношение «часть-целое» строится по одному какому-то типу объектов в разбиении.

Например, =S12=16 означает, что речь идёт о функциональной части 16, входящей в состав (отношение composition/is_part_of) функциональной части S12. Число уровней разбиения в имени не ограничено. Функциональное/ролевое имя инженеры часто называют тег****ом (tag). Проектирование, конечно, ведётся в типах/классах: это имя типов/классов частей системы, а не конкретных частей конкретной воплощённой/реализованной физической системы в конкретный момент времени (экземпляров материального воплощения объектов того типа/класса, который был в проекте/design).

Если имя -M87-K5, то речь идёт о продукте/модуле/конструктиве/изделии К5, который входит в состав надконструктива М87. Это тоже не конкретный физический объект с серийным номером, а тип/класс этих объектов, вид продуктов определённой марки.

Стандарт IEC 81346 закрепил такое именование, чтобы давать короткие коды вместо «нормальных» длинных имён. Действительно, если в каком-нибудь Boeing 787 есть 6 миллионов индивидуальных деталей (деталь — конструктив, который не собирается из его подконструктивов), то это сразу означает, что у них будет сразу по нескольку имён, добавятся функциональные имена и имена мест. И тогда лучше бы держать эти имена короткими, и каждое имя чтобы было понятно, к какому типу частей из какого разбиения, и к какому целому для этих частей из какого разбиения в составе самолёта относится.

Стандарт IEC 81346-1:2022 закрепляет современный инженерный консенсус про три основных вида разбиения системы на части. Всего там вводится пять разбиений, кроме функционального, продуктового и размещения даётся ещё «тип» как произвольная группировка по какому-то свойству и «другое», куда входит всё остальное — логистика, стоимостное деление, административное подчинение. Наше стоимостное разбиение по этому стандарту будет в этом «другом» разбиении, other aspects.

Если поглядеть в сегодняшние инженерные проекты, то именование::метод (тонких различий между именованием/naming::метод, идентификацией/identification::метод и десигнацией/означкованием/designation::метод с немного разными предметами всех этих методов мы не будем тут рассматривать) частей системы и всей системы целиком именно так и проходит, а ещё к таким именам и кодам добавляют и другие характеристики: напряжение или давление, типовой размер и даже цену (хотя цена — это не полная замена совокупной стоимости владения, и она не имя, и не код, но без этого описания про систему уже говорить не принято).

Мы уже знакомились с ситуацией, когда Принц Гамлет и Василий Пупкин могут быть одним агентом-человеком, но называться по-разному в зависимости от того, что нам от него нужно: понять, какая реплика будет следующая в его пьесе (это нужно понимать про роль/функционал, т.е. про Принца Гамлета), когда он планирует выучить новую роль в новом спектакле (это нужно понимать про конструктив, т.е. Василия Пупкина), или выяснить, есть ли у него дети (это нужно понимать про конструктив, т.е. Василия Пупкина, если речь не идёт о «детях из пьесы»). То же можно сказать и о неодушевлённой системе, например, так по-разному названные системы могут оказаться одним и тем же прибором:

• «измеритель давления в пятом контуре охлаждения»::«ролевой/функциональный объект»,
• «манометр KLM-23 завода “Давижмимонтажавтоматика”»::«конструктивный объект»/продукт/модуль,
• датчик в «пятом ящике на третьей полке склада номер 4»::размещение,
• «$300»::стоимость.

В жизни вы вряд ли увидите около таких имён указание на тип объекта из мета-мета-модели, а тут мы указали типы для того, чтобы пояснить разность типов объектов, которые обозначены такими именами, в жизни придётся каждый раз понимать, какой тип объекта назван тем или иным именем.

Разные имена, указывающие на самые разные типы объектов, свидетельствуют о том, что мы будем задействовать самые разные методы работы с этим предметом метода, поэтому для нас один и тот же прибор выступает в разных ипостасях, так что удобно для разных методов работы называть его разными именами. Это нормально, этого в проектах не избежать!

Заставить все роли в проекте использовать одно и то же имя (в том числе один и тот же классификатор, который помогает дать уникальный код), одно и тоже разбиение системы на части— невозможно, непродуктивно**,** это ошибка**. Признание ролевого мышления, ведомого ролевым интересом** к предметам метода роли**, требует множества имён для объектов****, множества классификаторов для частей системы****.**

Но вы должны давать эти имена осмысленно, это не просто свобода именования, когда каждый пишет, как он дышит, ибо «я художник, я так вижу». Это всё культурно-обусловленные имена, «культурно» тут надо читать как культуру из длинного синонимического ряда: метод/способ/культура/стиль/практика работы. Вид труда, инженерии, занятий, а также стратегия и даже сервис — это тоже отсылка к методам, знаниям/теориям/объяснениям/алгоритмам этих методов и инструментарию этих методов. Выбор «культуры» из этого синонимического ряда означает лишь, что метод разделяется довольно большим числом людей, он общепризнан. Так что имена надо не выдумывать произвольно, а давать с опорой на уже накопленное цивилизацией знание об похожих предметах метода. Но поскольку к одной системе можно применить как предмету методов работы много разных методов, то и типов у системы будет много и соответствующих этим типам имён.

Имя «Принц Гамлет — Василий Пупкин» вполне культурно (то есть будет понятно многим людям без дополнительных разъяснений), хотя в нём использовано сразу два имени отдельных ипостасей актёра: действующего лица и исполнителя роли. Так и имена систем в промышленности часто могут состоять из имён нескольких ипостасей, например, «=S12=16 –M87-K5 $300» (составное имя одной системы, состоящее из трёх частных имён этой системы). Такие имена служат для удовлетворения интересов разных проектных ролей, частные имена перечисляются через пробел. Мы условно цену посчитали тоже именем, хотя это и не совсем так, но интуитивно указание финансовой характеристики около имени не вызывает ощущения чего-то необычного, хотим именно это подчеркнуть.

Обычно такое составное «системное имя»/«systemdesignator**»** можно использовать только в одном конкретном проекте так же, как составное имя «Принц Гамлет — Василий Пупкин» можно использовать только в одном спектакле, в другом спектакле распределение ролей будет другое. Все эти составные имена говорят о каком-то определённом месте в пространстве каждое, так что всегда можно разобраться о том, какая же система названа таким составным именем, конкретизируя ситуацию в физическом мире. Тут бесполезно разбираться, требуя определений для всех составляющих имени, а потом разные объекты в проекте «подводить под определение»! Нет, надо сразу конкретизировать/заземлять, от типов/классов и определений переходить к объектам в физическом мире (или хотя бы примерам объектов в физическом мире).

Вы предупреждены**😗* споры об определениях (часто называются «спор о терминах**»)** бессмысленны, а системное мышление**—** не математика**, задаётся не «строгими определениями» и «однозначными именами»****!**Бесполезно уточнять определения «как в математике», «как в словаре», «как в науке» и требовать одинаковых имён для

• горячей системы (функциональное имя),
• вчера купленной (продуктовое/конструктивное имя) системы
• дальней системы (пространственное имя),
• дорогой или дешёвой (стоимостное имя) системы.

Ситуацию всегда нужно уточнять, но не через определения, а только через понимание, где расположены эти системы в физическом пространстве-времени: если в разных местах-временах, то это разные объекты, если в одном месте-времени, то это по-разному описанный один и тот же объект, одна и та же система. Иметь много описаний, а не одно, много имён, а не одно — норма в системном мышлении, но системное мышление также предлагает 4D экстенсионализм и заземление/grounding как методы борьбы с путаницей во множественности имён одной системы.

Суть системного подхода в том, чтобы ни в один момент времени не забывать про систему в целом — воплощение/realization системы, которое просто по-разному представляется разными проектными ролями разбитым на части того или иного типа, в зависимости от методов, которыми будут действовать эти проектные роли.

Беглости такого одновременного удержания во внимании разных представлений разных ролей для удовлетворения их разных интересов в одном и том же объекте, беглости работы со множеством описаний одной системы, в том числе и множеством вариантов деления системы на части, нужно некоторое время учиться, хотя сама идея множественности имён для множественности типов (классификацией во множестве классификаторов, удобных для разных методов работы разных ролей) понимается обычно с первого предъявления. Но одно дело — понять, другое дело — самому свободно владеть таким мышлением, удерживающим внимание на одних и тех же объектах как предметах разных методов работы и поэтому имеющих ещё и разные имена.

Хорошо тут помогает записывать эти объекты внимания: никто не требует удерживать эту системную множественность в голове, записывайте! В системном мышлении обычно «все ходы записаны», это сильно упрощает жизнь. Компьютер не забывчив, записи в нём доступны многим агентам (не только людям!), выполняющим самыми разными методами работы с самыми разными предметами этих методов самые разные роли в проекте, поэтому системные разбиения всегда документируют, не принято договариваться про системные разбиения «с голоса». Пишите ваши разбиения!