Альтернативные варианты основных видов разбиения системы на части
Функциональные объекты, конструктивные элементы, размещения, части совокупной стоимости владения — это не единственный способ увидеть в системе части. Этих способов огромное количество.
Исторически в разных школах мысли части системы выделялись очень по-разному:
- ISO 15926 — дв****а основных вида частей: функциональные объекты, физические объекты. Остальные могут вводиться по потребности.
- IEC 81346-1:2022 — «по меньшей мере» пять (функция, продукт и компонент как заказной продукт, место, тип как произвольная группировка по каким-то свойствам, и «другое» — куда можно включить всё, что душе угодно, например ход на описания создателей: административные, логистические аспекты, связанные с создателями в их графе, а не аспекты самой системы). В нашем руководстве мы опираемся главным образом на этот вариант, добавляя к нему недавно появившуюся стоимость/cost как «другое» и не выделяя особо «группировку по типу» — она по факту неотличима от «другого» (и стандарт предлагает делать для «типа» и «другого» соглашение, чтобы команда понимала, что было выбрано).
- Книга Косякова, Свита, Сеймура «Системная инженерия. Принципы и практика»[1] — два вида: функциональный элемент, компонента (конструктивный объект).
- СМД-методология — пять (процессы, элементы и связи, внешние функции, морфология, материал)[2]
- … и так далее[3], в среднем 3-7 основных видов частей, ипостасей системы. Впрочем, «ипостаси» тоже называются везде по-разному: структурные аспекты, типы/виды описаний, которые выполняются на заданном типе частей как предметы разных методов в разных школах системного мышления. И везде указывается, что это «по меньшей мере», то есть признаётся, что речь идёт только об основных вариантах, которые нельзя не рассмотреть. А разбиений может быть много, они делаются по потребности, разные в разных проектах. Но основные разбиения делаются во всех проектах.
В нашем руководстве мы принимаем вслед за IEC 81346-1:2022, что системы имеют три основные ипостаси/аспекта — функциональную, конструктивную и размещения, добавляем четвёртую ипостась/аспект: стоимостную, это уже де-факто основное описание в подходе цифровых двойников/digitaltwins[4], и дальше продолжаем «и эти четыре — минимальное число аспектов/ипостасей/«вариантов разбиения» как основа для разных вариантов описаний, базирующихся на разных вариантах разбиений.
Также помним, что кандидат на следующее, пятое, основное разбиение, которое ещё не попало в инженерные стандарты как «обязательное», но всё чаще и чаще встречается в реальных проектах — это work breakdown structure из проектного управления. Оно нужно, чтобы было легко потом соединить разбиение продуктов и разбиение работ и проверять: каждая работа выполняется с каким-то продуктом, и нет продуктов без работ и работ без продуктов. Трудности с его введением:
- Проектное управление очень популярно в инженерии, но оно основано на старой концепции «жизненного цикла» (проект подразумевает однократное прохождение жизненного цикла системы, сегодня это заменено на создание MVP и затем непрерывное развитие системы). Проектное управление требует upfront планирования, для большинства проектов это невозможно. Подробности — в руководствах по методологии и системной инженерии.
- Есть огромная путаница методов работ и самих работ. Методы работы в инженерии стали предметом методов ситуационной инженерии методов и были выпущены стандарты инженерии методов, которые посвящены были как раз «модели жизненного цикла». Развитие этого направления привело к тому, что работами стали кейсы, которые бьются на подкейсы, но главное — не требуется их планировать с самого начала. Это означает, что предъявить в какой-то момент WBS (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 метаданные, документация (тексты). Помним, что в машиностроении под 1D-моделированием понимают физическое моделирование функциональных характеристик системы, но в мире digital twins под 1D-ипостасью системы понимают совсем другое.
- 2D чертежи (там, где «обычные двумерные электронные чертежи» ещё есть, «родные файлы» из CAD/САПР — помним, что digital twins процветают на стройках, а там очень медленно развиваются методы проектирования/design и их инструментарий, 2D представления ещё встречаются повсеместно)
- 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)
Хорошо видно, что в основе тут не столько динамическое определение методов работы, а затем планирование, сколько сразу планирование работ по созданию системы — предполагается, что это планирование возможно. Всё это делается главным образом для стройки: «один раз спроектировал, один раз построил, модернизация проекта/design и модернизация здания находятся далеко за рамками проекта».
Но тренд очевиден даже в этом узком классе проектов: ипостасей/аспектов, задающих разное разбиение системы на части, всегда больше четырёх предложенных нами (в том числе произвольные группировки по типам и ещё «другое», если не хватило типов), да и сами эти четыре варианта разбиения могут быть сложно устроены внутри себя, это не «одна ипостась — одно описание — один документ». И сами эти ипостаси/аспекты в чистом виде обычно не встречаются, они часто тесно сплетены друг с другом («гибридны»). Системное мышление рекомендует распутывать гибридные описания, восстанавливать начальные предметы интереса/важные характеристики, определять предметы методов работы разных ролей проекта. И, конечно, использовать в этих гибридных описаниях множество имён для одних и тех же систем — как раз для того, чтобы не запутать, а распутать гибридные описания.
Часто гибрид появляется из-за того, что какое-нибудь продуктовое разбиение на очередном системном уровне делают вдруг функциональным, «перескакивая между временами» — разбиение в development-time вдруг продолжают как разбиение в operations-time. Это нужно отслеживать, ибо «автоматический перескок» может вести к ошибкам, мы их рассмотрим в нашем руководстве чуть позже.
Такого сорта «перескоков» с типа на тип частей системы множество, они ведут к разным вариантам ошибок: разбиение размещения (например, разбивку дома по этажам) вдруг превращают на следующем уровне в продуктовое/конструктивное разбиение (разбивка по единицам оборудования на этаже). Или инженерный документ вдруг превращается в сводно-заказную спецификацию по закупке, и на первое место выходят закупочные цены. Можно ли такое делать? Можно всё, если вы понимаете, что вы делаете. Если не очень понимаете, то такое лучше не делать**—** и в любом случае надо понимать, какую ипостась системы вы обсуждаете, какого типа рассматриваемый вами объект-система**: функциональный? конструктивный?** р****азмещения? с****тоимостной? иной?
Для разных ролей в проекте система будет представляться в своих разных аспектах-ипостасях частично, следуя методу того или иного варианта разбиения, но при этом в системном трансдисциплинарном мышлении она будет оставаться целостной/холистичной/целокупностью всех своих ипостасей/аспектов — в терминах типов объектов и отношений этих аспектов (роль и функция, конструктив, воплощение и композиция и т.д.). Части системы выделяются в физической системе вниманием**, внимание ведётся знанием о типах трансдисциплинарной мета-мета-модели и мета-модели предметной области (можно ещё выделить метаУ-модель как в учебниках и метаС-модель как в регламентах). Разность системных разбиений для одной системы—** это просто результат разны****х критери****ев выделения частей вниманием! А потом на базе удерживаемых вниманием частей системы мы строим различные аспектные и (даже чаще) гибридные описания системы.
http://webcache.googleusercontent.com/search?q=cache:CLJYHzTDPj0J:www.mmk-documentum.ru/glossary/6 ↩︎
https://en.wikipedia.org/wiki/View_model — тут примеры разных вариантов для системной архитектуры предприятия ↩︎