logo search

Многерица холархий

Системные холархии для разных стейкхолдеров оказываются тоже разными, ибо «система в глазах смотрящего»: каждая холархия удобна для ответа на вопросы какой-то одной деятельности, а не всех сразу.

Целевая система отличается тем, что для неё компонента, модуль и место совпадают, это одно и тот же экстент в пространстве.

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

ТРИЗ задачу своих изобретений видит в том, чтобы несколько разных функций выполнялись небольшим числом конструктивных элементов — в идеальной системе много функций выполняются нулевым числом элементов, нужно стремиться к этому. Так что гарантировать, что холархии функциональных элементов, конструктивных элементов, размещений совпадают нельзя.

Нельзя путать компоненты и модули. Нельзя путать Принца Гамлета и Василия Пупкина, даже если во время спектакля это одно и то же. Если вы будете за кулисами говорить Василию Пупкину «Ваше Высочество», а на сцене говорить Принцу Гамлету «как там твои жена и дети?», то окружающие на вас будут смотреть странно, а Василий Пупкин сильно озадачится.

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

Если менеджеры будут воспринимать ножницы состоящими из компонент, то они попытаются заказать работы по изготовлению ручек и ножевого блока раздельно: ручки фирме, понимающей в эргономике, а режущий блок заводу, который умеет делать ножи («ножницы» как раз происходят от слова «нож»! ).

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

Заказать можно только модули, а ручка и ножевой блок у ножниц компоненты, а не модули. Модулями в ножницах будут только две половинки ножниц (а ещё винтик).

Если делать ручки и ножевой блок отдельно как модули, а потом их как-то скреплять, то это будет плохое и ненадёжное инженерное решение.

Менеджеры же сначала внимают доводам инженеров, но потом… смотрят на ножницы в сборе, видят в действии (эксплуатации, operations) ручку и ножевой блок — и опять пытаются с ними сделать что-то по отдельности не в момент «спектакля» (когда ножницы в сборе и работают — режут), а в момент изготовления. Например, разделить работы по сборке ручки и ножевого блока, хотя при соединении половинок ножниц винтиком разделить работы по ручке и ножевому блоку принципиально невозможно. Или сделать каталог ручек и каталог ножевых блоков и потом пытаться заставить инженеров выпускать эти якобы «детали ножниц» в виде запчастей. Список ошибок и заблуждений тут бесконечен, и эти ошибки не прекратятся: менеджеры постоянно находят «ножевой блок» и «ручки» в инженерной документации и пытаются поступать с ними как со сборочными единицами.

Правда в том, что в ножницах разные стейкхолдеры усматривают две разные холархии: одна функциональной декомпозиции («аналитическая»), а вторая модульной сборки («синтетическая»):

Целевая система едина как компонента и модуль, но вот дальше структура компонент (функциональная структура, системное разбиение) и модулей (модульная структура, конструктивное разбиение) могут существенно различаться.

В инженерных языках моделирования «железной» архитектуры, равно как и в языках моделирования предприятия, компоненты и модули имеют различные значки.

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

Главное при этом — это решения создателей системы, какие элементы конструкции реализуют какие необходимые для работы системы поведения/функции, так что требуются обычно описывать и компоненты, и модули.