Альтернативные варианты основных видов разбиения системы на части

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

Исторически в разных школах мысли части системы выделялись очень по-разному:

  • ISO 15926 --- два основных вида частей: функциональные объекты, физические объекты. Остальные могут вводиться по потребности.
  • IEC 81346-1:2022 --- «по меньшей мере» пять (функция, продукт и компонент как заказной продукт, место, тип как произвольная группировка по каким-то свойствам, и «другое» --- куда можно включить всё, что душе угодно). В нашем курсе мы опираемся главным образом на этот вариант, добавляя к нему недавно появившуюся стоимость/cost как «другое» и не выделяя особо «группировку по типу» --- она по факту неотличима от «другого» (и стандарт предлагает делать для «типа» и «другого» соглашение, чтобы команда понимала, что было выбрано).
  • Книга Косякова, Свита, Сеймура «Системная инженерия. Принципы и практика»[1] --- функциональный элемент, компонента в значении «модуль».
  • СМД-методология --- пять (процессы, элементы и связи, внешние функции, морфология, материал)[2]
  • ... и так далее[3], в среднем 3-7 основных ипостасей (впрочем, «ипостаси» тоже называются везде по-разному: структурные аспекты, типы/виды разбиений) в разных школах системного мышления. И везде указывается, что это «по меньшей мере», то есть признаётся, что речь идёт только об основных вариантах, которые нельзя не рассмотреть. А разбиений может быть много, они делаются по потребности, разные в разных проектах. Но основные разбиения делаются во всех проектах.

В нашем курсе мы примем вслед за IEC 81346-1:2022, что системы имеют три ипостаси/аспекта --- функциональную, конструктивную и размещения, добавляем четвёртую ипостась/аспект: стоимостную, как это принято в стремительно набирающем силу подходе цифровых двойников/digitaltwins[4], и дальше продолжаем «и эти четыре --- минимальное число аспектов/ипостасей/критериев разбиения». В проекте можно разбивать/группировать объекты ещё по произвольным характеристикам как «аспектам типа», а ещё стандарт вводит аспект «другое», куда можно давать административные, логистические и прочие разбиения, которые могут понадобиться в проекте.

Также помним, что кандидат на следующее «обязательное» разбиение, которое ещё не попало в стандарты как «обязательное», но всё чаще и чаще встречается в реальных проектах --- это work breakdown structure из проектного управления. Оно нужно, чтобы было легко потом соединить разбиение продуктов и разбиение работ и проверять: каждая работа выполняется с каким-то продуктом, и нет продуктов без работ и работ без продуктов.

В презентации 8D digital twin experience от SNC-Lavalin с июньской конференции 2020 года по digital twins приводится 8 аспектов[5], D там --- это dimension, «измерение» (ещё одно слово для аспекта/ипостаси, подчёркивается тот факт, что система существует как объект во многих измерениях/dimensions). Всё тут ровно то же самое, что было ещё десяток лет назад в работах по управлению жизненным циклом продуктов (PLM), но сегодня уже разговор про digital twins, а не PLM, ибо акцент уже не только на создании системы, но и на её эксплуатации, и поэтому данные инженерии/engineering data дополняются данными по эксплуатирующимся активам/asset data, а конечная цель --- автономная (без человека, где-нибудь в абсолютно безлюдной местности) эксплуатация на основе «единственного источника правды», single source of truth, то есть цифрового двойника как модели системы, поддерживающей согласованные между собой различные описания как целевой системы в её операционном/рабочем окружении, так и создающей системы:

  • 1D метаданные, документация (тексты)
  • 2D чертежи (там, где «обычные двумерные чертежи» ещё есть, «родные файлы» из CAD/САПР)
  • 3D информационные модели (это представление физической формы/геометрии/компоновки системы с указанием материалов и многих других характеристик)
  • 4D «видеоролик» стройки/сборки в развёртке во времени, то есть к 3D добавляется план/schedule сооружения (стройки и монтажа) или сборки
  • 5D это ресурсы, material status/cost, то есть добавляется стоимость
  • 6D вот тут появляется operation, real time data (и мы перешли из enabling realm/времени создания в operation realm/время эксплуатации, и с этого места принято говорить, что речь идёт не о системе поддержки жизненного цикла/PLM, а цифровом двойнике/digital twin уже созданной физической системы)
  • 7D это live streaming, передача видеопотока работающей целевой системы и её окружения (с видеокамер, со спутника --- отдельно от real time data с датчиков, ибо это огромные объемы данных).
  • 8D это уже аналитика, предсказания систем машинного обучения (ML predictive data)

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

Часто гибрид появляется из-за того, что какое-нибудь продуктное разбиение на очередном системном уровне делают вдруг функциональным, «перескакивая между временами» --- разбиение в development-time вдруг продолжают как разбиение в operations-time. Это нужно отслеживать. Или разбиение размещения (например, разбивку дома по этажам) вдруг превращают на следующем уровне в продуктное/конструктивное разбиение (разбивка по единицам оборудования на этаже). Или инженерный документ вдруг превращается в сводно-заказную спецификацию по закупке, и на первое место выходят закупочные цены. Можно ли такое делать? Можно всё, если вы понимаете, что вы делаете. Если не очень понимаете, то такое лучше не делать.

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


  1. https://www.ozon.ru/context/detail/id/28160736/ ↩︎

  2. http://webcache.googleusercontent.com/search?q=cache:CLJYHzTDPj0J:www.mmk-documentum.ru/glossary/6 ↩︎

  3. https://en.wikipedia.org/wiki/View_model --- тут примеры разных вариантов для системной архитектуры предприятия ↩︎

  4. https://ailev.livejournal.com/1570630.html ↩︎

  5. https://www.youtube.com/watch?v=OjH1OPezfak ↩︎