Ловушка совместимости

Почему PLM‑системы не понимают ЕСКД: от проблемы совместимости к проектированию собственной модели данных

Часть 1 Проблема совместимости ЕСКД и западных PLM‑систем

Когда внедрение закончено, но работа только начинается

Представим, что крупная производственная компания внедрили PLM‑систему тяжелого класса. Пользователи прошли обучение, данные перенесли, интеграционные потоки настроили, сотрудники начали пользоваться. И тут проявляется самое интересное: чтобы внести изменение в КД, вдруг надо выполнить ряд манипуляций, не свойственных тому, как это было бы, будь процесс в привычном ПО (Автокад) или на бумаге. Или, чтобы сформировать структуру изделия, нужно сделать сборку в CAD, составить спецификацию, загрузить всё на сервер, а потом повторить манипуляции уже с объектами в системе. Вместо упрощения работы пользователя (проектанта, конструктора, технолога и так далее), происходит ровно наоборот — появляются дополнительные трудозатраты. Естественно, это вызывает множество вопросов, на которые лишь один ответ: «в системе нельзя по‑другому».

Типичный пример из практики

В западной PLM‑системе есть все инструменты для работы с изменениями: статусы, маршруты согласования, роли. Но чтобы выпустить обычное извещение об изменении инженер вынужден:

• создать Change Request (CR);

• запрос на изменение;

• затем Engineering Change Order (CO);

• распоряжение на изменение;

• затем вручную связать его с объектами;

• при этом всё равно часть данных продублировать в документе (в худшем случае — приложить PDF файл с бланком извещения об изменении).

Иначе данные просто не попадут туда, где они должны быть согласно требованиям ЕСКД. Если упростить, то CR/CO отвечают на вопрос нужно ли менять, что именно, почему, как и с какого момента и полностью работают в системе западных стандартов. Формализованный процесс управления изменениями, функционально эквивалентный ГОСТовскому извещению об изменении, но разделенный на этапы, то есть грубо говоря: ГОСТ ИИ = CR + CO или ГОСТ ПИ (предложение об изменении) + ИИ = CR + CO.

То есть, вместо естественного процесса работы в системе ЕСКД, где внесение изменений происходит в рамках регламентируемых ГОСТ процедур, конструктор вынужден адаптировать свою работу под западные стандарты, а в лучшем случае интегратор глубоко кастомизирует PLM‑систему. Однако, кастомизация касается лишь внешнего слоя системы: форм, отчётов и шаблонов. Фундаментальная логика, заложенная в ядре, остаётся западной. Например, объект «изменение» там неизбежно распадается на CR и CO, как требует Configuration Management, а не на единое ГОСТовское извещение. В результате привычные регламентные процедуры, отработанные десятилетиями, не встраиваются в систему естественно. Они либо навешиваются «сбоку», либо дублируются вручную.

Самое парадоксальное в таких ситуациях — формально система действительно умеет почти всё и даже больше.

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

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

Системный конфликт

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

В российской практике (а в широком смысле и практике СНГ), сформированной в рамках ЕСКД, есть устойчивый набор понятий, через которые описывается изделие и всё, что с ним происходит. За ними стоит многолетняя инженерная практика, в которой каждое понятие привязано к реальным процессам разработки, производства и сопровождения. В западных PLM‑системах используется другой набор базовых понятий. Они выглядят знакомо и почти совпадают по смыслу и это приводит к ошибочному выводу, что различий не существует. Однако, это не так.

Например, в системе ЕСКД есть следующие понятия:

• изделие;

• состав изделия;

• спецификация;

• изменение;

• извещение об изменении.

Они формировались десятилетиями и напрямую связаны с тем, как работает система постановки продукции на производство в отечественной практике, регламентируемой стандартами категории ГОСТ, ГОСТ Р и ГОСТ РВ.

В западных PLM‑системах используются свои базовые понятия:

• Item;

• Part;

• Document;

• Parts List (Перечень составных частей, ISO 7573);

• Change Request и Change Order.

На первый взгляд кажется, что это одно и то же.

Но при прямом сопоставлении их друг с другом и возникают те самые «идеологические» проблемы, о которых пойдет речь дальше.

Изделие не совпадает с Part по смыслу, спецификация в ЕСКД не является полным аналогом Parts List, а извещение об изменении не укладывается в стандартные механизмы управления изменениями в системе PLM, такие как Change Request и Change Order. Именно в этом и заключается причина системного конфликта.

И в дополнение, одной из последних тенденций становится практика внесения изменений в ЕСКД с целью внедрить в них принципы из западных стандартов. И те, кто это делает, не всегда осознают последствия для отечественной инженерной школы.

Пример. Версия электронного КД

В ГОСТ Р 2.104–2023 введена графа 35 в основной надписи, в которой указывают номер версии электронного документа. Это нововведение обязано своим появлением исключительно западному подходу к формированию комплекта КД, а это, в свою очередь, приводит к тому, что появляется соблазн одновременно иметь несколько действующих версий одного и того же конструкторского документа, которые зачастую нарушают принцип взаимозаменяемости, что приводит к ошибкам и браку на производстве. После того, как ввели версии, понадобилась западная «применяемость», чтобы эти невзаимозаменяемые изделия, существующие в комплекте КД за одним и тем же обозначением, распихать по разным сборочным единицам. В итоге нарушение лишь одного принципа отечественной ЕСКД привело к лавинообразному разрушению и других. Как в этой ситуации работать производству — непонятно.

Пример. Спецификация

В ЕСКД спецификация — это самостоятельный конструкторский документ, который определяет состав сборочной единицы, комплекса или комплекта. Согласно ГОСТ Р 2.005–2023 (п. 5.1), она является основным конструкторским документом, то есть в отдельности или в совокупности с другими документами полностью и однозначно определяет изделие и его состав. При этом в спецификацию вносятся не только составные части изделия, но и конструкторские документы, относящиеся как к самому изделию, так и к его неспецифицируемым составным частям (ГОСТ Р 2.106–2019, п. 4.2.2).

В PLM аналогичную роль формально выполняет BOM (Bill of Materials). Но, по существу, это не документ, а структура данных (product structure) или, другими словами, иерархия вложенности. BOM не является самостоятельным конструкторским документом в том смысле, в каком это понятие работает в ЕСКД.

На первый взгляд, преодолеть этот разрыв должен отечественный стандарт ГОСТ Р 2.053–2023, который вводит понятие ЭСК (электронная структура изделия конструктивная) и определяет её как электронный конструкторский документ. Однако внутри самого стандарта заложено противоречие, не позволяющее чётко сопоставить ЭСК ни со спецификацией, ни с BOM.

Согласно ГОСТ, ЭСК — это электронный КД, определяющий состав изделия. При этом в стандарте различают два вида:

• Основная ЭСК включает сведения о составных частях (СЧ), непосредственно входящих в изделие, и не включает ЭСК этих СЧ. По сути, это одноуровневый перечень позиций, функционально близкий к спецификации, но в электронном виде.

• Полная ЭСК включает сведения о СЧ, непосредственно входящих в изделие, и их структуры (ЭСК СЧ), за исключением покупных изделий.

Вот здесь и возникает логический разрыв. Полная ЭСК «включает в себя» ЭСК входящих изделий, то есть поглощает документы других СЧ. В результате полная ЭСК перестаёт быть документом одного изделия и превращается в развёрнутую иерархическую модель всей сборки, по сути, в цифровую базу данных или дерево вложенных документов. Это уже не КД в привычном понимании, а структура, близкая к западному BOM.

Таким образом, ГОСТ Р 2.053–2023 называет одним термином «ЭСК» два принципиально разных объекта:

• Основную ЭСК — это плоский одноуровневый перечень (по сути, электронный аналог спецификации).

• Полную ЭСК — это рекурсивная иерархическая модель (по сути, цифровая структура, аналогичная BOM).

Противоречие в том, что если основная ЭСК — это документ, аналог спецификации в электронном виде, при этом полная ЭСК — документ, который содержит или, другими словами, поглощает другие документы — основные ЭСК, то полная ЭСК уже не документ, а модель.

В результате инженер оказывается между двумя нестыкуемыми моделями:

• в PLM он работает с иерархией (BOM), которая не является документом;

• по ГОСТ он должен получить спецификацию как документ, но стандарт предлагает ему ЭСК, которая то ли дублирует спецификацию (основная), то ли превращается в многоуровневую базу данных (полная), теряя статус документа конкретного изделия.

Поэтому адаптация западной PLM под ЕСКД это не просто вопрос перевода терминов или добавления полей. Это столкновение разных архитектур данных: западная система не знает документа‑спецификации, а отечественный стандарт не решил, является ли ЭСК документом или структурой.

Пример. Применяемость

Еще более показательным примером является применяемость, о которой уже упоминалось выше.

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

ГОСТ Р 2.005–2023, п.92

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

ГОСТ Р 2.503— 2023

Приложение А «Форма и правила заполнения извещения об изменении». Графа 14 в бланке Извещения об изменении «Применяемость»

Вопрос применяемости в отечественной инженерной школе решается посредством других механизмов. Вместо опций и вариантов — исполнения изделия, вместо 150% BOM — групповая спецификация, принцип построения которой очень хорошо укладывается в возможности отображения структуры изделия с помощью инструментов PLM, если в основе объектов системы и их связей заложены принципы, описанные стандартами ЕСКД/ЕСТД.

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

Построенная по западным стандартам система предлагает другой способ смотреть на структуру изделия, и этот способ не всегда совпадает с тем, который требуется в отечественной практике, где конструкторские бюро при тесном взаимодействии с производством встроены в единый конструкторско‑технологический процесс подготовки производства, в котором заключительное звено — условный завод — существует исключительно в регламентных рамках отечественных стандартов и зачастую не «понимает», что такое конфигурации, ревизии, версии и другие подобные термины.

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

Как пользователи начинают адаптироваться

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

Отсюда появляются типичные паттерны:

• Excel рядом;

• Дополнительные справочники;

• Неформальные правила внутри команды.

И без них система перестаёт сходиться с практикой.

Почему появляются обходные процессы

Как следствие, вокруг системы постепенно начинает формироваться параллельная инфраструктура. Появляются таблицы, вспомогательные файлы, противоречащие ГОСТ записи в спецификации и в ТТ чертежа/3D‑модели (ЭМД или ЭМСЕ), которые компенсируют то, чего не хватает в основной системе. Это неизбежный процесс, и его можно наблюдать практически в любом крупном внедрении.

Самое интересное, что такие «временные» решения становятся постоянными и начинают играть критическую роль в работе. В итоге, часть информации о продукте живёт вне PLM‑системы, хотя изначально предполагалось, что именно она станет единым источником правды.

Пример. Версии и ревизии

Очень типичная ситуация на практике выглядит следующим образом. У конструктора есть изделие, для которого в системе заведены версии А1, А2, А3 и так далее. Формально это одна и та же сущность, просто находящаяся в разных состояниях — сборочная единица или деталь, версия которой указана в основной надписи в графе 35 (регламентированной в ГОСТ Р 2.104–2023).

Чтобы не запутаться, конструктор заводит отдельную таблицу — чаще всего в Excel, в которой вручную фиксирует смысл этих версий. В этой таблице появляется простая, но критически важная информация: версия А1 — это макет для испытаний, например, только корпус без внутреннего наполнения; версия А2 — это уже опытный образец с полным функционалом; версия А3 — доработанный вариант после испытаний, пригодный для ограниченного производства.

И здесь возникает показательный разрыв — следите внимательно! С точки зрения системы все эти версии/ревизии — это просто итерации одного и того же объекта. С точки зрения инженера — это принципиально разные изделия с разным назначением, составом и областью применения.

Система этого различия не видит. Поэтому конструктор вынужден держать эту логику у себя снаружи — в таблице, в голове, в договорённостях с коллегами.

Вот именно в этот момент PLM‑система перестает быть единственным источником правды. Она превращается в хранилище данных, смысл которых приходится восстанавливать вручную.

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

Почему настройки не решают проблему

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

Где на самом деле заложена проблема

В итоге мы приходим к выводу, что проблема заключается в том, что система изначально спроектирована под другую модель предметной области. Внутри любой PLM‑системы есть представление о том, какие объекты существуют, какие между ними допустимы связи и какие ограничения накладываются на их использование, которое редко обсуждается. Но именно оно определяет, что в системе можно сделать естественным образом, а что всегда будет требовать обходных решений. Когда модель данных не совпадает с реальной отечественной инженерной практикой, система начинает незаметно и постепенно искажать процессы, под которые она внедрялась. То есть, ограничения лежат не на уровне настройки, а на уровне самой модели данных.

Пример. Исполнение (изделия)

В отечественной практике есть ещё одно понятие, которое кажется очевидным, пока не пытаешься реализовать его в системе. Это понятие исполнение изделия.

В ЕСКД это не версия изделия. Версия (ревизия) фиксирует эволюцию одного и того же объекта во времени. Исполнение — это параллельный, заранее предусмотренный вариант изделия, конструкция которого отличается от базовой (составом, параметрами или конструктивными элементами), но описывается в том же групповом конструкторском документе. В ЕСКД нет понятия «конфигурация»; вместо этого групповой чертёж или спецификация содержит таблицу исполнений, а каждое исполнение — это самостоятельное изделие со своим обозначением.

В рамках ЕСКД это естественная конструкция. Исполнения закладываются на этапе разработки и отражаются в спецификации (сборочном чертеже). Производство понимает их однозначно, без дополнительных интерпретаций.

В большинстве западных PLM такого понятия в явном виде нет. Да, формально, существуют аналоги — варианты, опции, конфигурации. Но их модель и способ использования отличаются. Западная система не знает объекта «исполнение» как самостоятельной позиции номенклатуры; она оперирует «вариантами» внутри одной детали или сборки, тогда как в ЕСКД каждое исполнение — это отдельная единица учёта.

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

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

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

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

Выводы

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

Если принять это как отправную точку, возникает следующий вопрос. Где именно заложено это расхождение и почему его так сложно устранить? Чтобы ответить на него, нужно перейти на уровень глубже и посмотреть, как устроена модель данных внутри PLM и каким образом она определяет поведение всей системы. Именно об этом пойдёт речь в следующих частях статьи.

Часть 2 Модель данных PLM как главный фактор успеха и провала

Введение

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

Для большинства инженеров этот термин звучит как что‑то из области IT, часть программного кода, которое никак не должно влиять на повседневную работу конструктора. Ведь инженер работает с изделиями, конструкторской документацией и изменениями, а не с таблицами, классами или связями между объектами.

Именно поэтому словосочетание «модель данных» редко вызывает интерес у конечных пользователей и для них это скорее техническая деталь, о которой должны думать разработчики.

Однако, всё оказывается ровно наоборот. Модель данных определяет не только то, как информация хранится внутри системы, но и:

• как система понимает предметную область;

• какие объекты существуют;

• какие связи между ними допустимы;

• какие операции допускаются и считаются естественными;

• какие невозможны в принципе.

В качестве примера рассмотрим электронную таблицу. Пока в ней нет заранее определенных столбцов, пользователь может записать в ячейках любую информацию. Но как только задать структуру с колонками «Фамилия», «Имя» и «Дата рождения», записать туда, что угодно уже не получится. И это не потому, что программа плохая, а потому что сама модель данных описывает совершенно определенную предметную область, в данном случае — данные о человеке.

С PLM происходит то же самое, только в большем масштабе — система заранее содержит представление о том, что такое изделие, документ, изменение, каким образом они связаны между собой и какие ограничения действуют для каждого объекта. По сути, это и является моделью данных.

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

Если сравнить PLM‑систему со зданием, то все визуальное (интерфейс, формы, workflow‑процессы и так далее) — это отделка, а модель данных — фундамент и несущие стены. Можно сколько угодно переставлять шкафы и перекрашивать двери, каркас (основа здания) не измениться. А как только мы захотим перенести несущую стенку, то поймем, что это сделать невозможно или чревато фатальными последствиями.

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

Как раз‑таки если речь идет о втором случае, то чаще всего мы услышим фразу, что система так не умеет. То есть, пользователь просит внести такие изменения, которые противоречат ее модели данных и никакие дополнительные настройки тут уже не помогут.

Что такое модель данных

Вопрос о модели данных нельзя считать вопросом исключительно разработчиков программного обеспечения. Если мы говорим о модели данных PLM системы, то он относиться к инженерной логике, так как еще до начала написания программного кода разработчик (программист) должен понимать, как он собирается описывать изделие и всё, что с ним происходит на протяжении всего жизненного цикла. И от этого на самом деле зависит все остальное.

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

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

И я еще раз подчеркиваю, когда этот программный код существует, когда система работает в своей определенной логике, как в случае с западными PLM‑системами, то какие бы манипуляции не производились бы в системе, если они не касаются ядра, настроить работу в логике системы ЕСКД не представляется возможным.

Из чего состоит любая PLM: объекты, связи и ограничения

Если упростить, то можно сказать, что модель данных PLM‑системы состоит, по сути, из трех сущностей: объекты, связи (по факту тоже объекты) и ограничения.

Объектами в PLM‑системе являются (неполный перечень): изделия и документы, отличающиеся между собой атрибутами, которые определяют их вид; пользователи; организации; проекты и тому подобное. Каждый из них обладает собственными свойствами, жизненным циклом и правилами поведения.

Но сами по себе объекты практически ничего не значат. Если в системе существует миллион изделий и миллион документов, но между ними отсутствуют какие‑либо отношения, такая PLM окажется бесполезной. Она превратится в обычное файловое хранилище, где информация существует сама по себе и никак не связана между собой.

Поэтому вторым важным элементом модели данных становятся связи, которые превращают отдельные объекты в единую инженерную модель. Документ связан с изделием, деталь входит в состав, изменение затрагивает определенный комплект КД (например, ЭКД, включая 3D‑модели и так далее). И это не функции системы, а заранее определенная логика отношений между объектами.

И немаловажной особенностью связи является не только ее наличие, но и ее вид. Связь «входит в состав» принципиально отличается от связи «входит в комплект», как собственно, отличается сам состав изделия, который состоит из изделий всех видов, входящих в спецификацию или ЭСК и комплект КД, который в состав изделия не входит, а является набором документации, описывающей изделие с таким составом. Для инженера эти различия очевидны, а для PLM каждое из них должно быть явно описано в модели данных.

Третьей по очереди и равной по значимости с предыдущими двумя сущностями является такой элемент модели данных, как ограничения.

Ограничения можно представить как набор правил, которым обязана подчиняться вся система. Например, объект «Документ» может иметь только одного владельца — автора. Или связь разрешена только между конкретными видами объектов. Подобные правила как бы незаметны, но они определяют, что система позволит сделать, а что нет, вне зависимости от количества настроек.

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

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

Другими словами, именно модель данных определяет функциональность всей системы. В подтверждение моих слов можно вернуться к примерам из первой части статьи.

Пример. Изменение

В отечественной практике есть устойчивое понятия «Утвержденный комплект конструкторской документации». Это понятие очень важно с той точки зрения, что в соответствии с ним осуществляется как изготовление изделия, так и его приемка. Например, в процессе проектирования и разработки, а также во время производства первого опытного образца возникает необходимость внести корректировки в КД. В системе ЕСКД четко определен порядок действий в таких случаях, который наиболее наглядно можно продемонстрировать на примере корректировки «бумажного» КД.

Внесение изменений в «бумаге» осуществляется с помощью выпуска извещения об изменении, в котором указывается как причина, так и содержание этих самых изменений, в подлинник «руками» вносятся соответствующие корректировки, вплоть до зачеркивания значений размеров и написание новых. При этом, в основной надписи в соответствующей графе указывается номер изменения, например, «Изм.1», подпись лица, выполнившего эти изменения, дата и номер извещения. Затем производится изъятие из всех архивов копий изменяемого КД и заменой на копии этого же КД с «Изм.1». То есть, фактически произошел пересмотр ранее утвержденных конструкторских данных об изделии, направленный на внесение изменений и их обязательную фиксацию для сохранения истории актуализации документа, что называется ревизия (западный термин) или версия (отечественный). Но это понятие относится именно к документации, а не к изделию. В западных же PLM системах объект изделия и объект документация «склеены», в результате чего ревизия «прилипла» и к понятию изделия.

И теперь на российских предприятиях используют «импортную» функциональность ревизий для решения вопроса «применяемости» одного и того же изделия, версии которого нарушают принцип взаимозаменяемости — пример из первой части «Версии и ревизии».

Таким образом, имея очень широкий функционал, западные системы PLM мало того, что очень трудно поддаются «адаптации» под отечественные стандарты ЕСКД, так этот функционал еще используется не по назначению.

Одинаковая функциональность не равно одинаковые системы

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

Да, обладая широким набором инструментов по формированию структуры изделия, шаблонов электронных текстовых и конструкторских документов, включая 3D модели, workflow процессов, предполагается, что такая система будет удобной в применении. Но реальность оказывается куда как более сложной. Поведение PLM определяется не количеством возможностей и не качеством интерфейса. Его определяет модель данных, которую пользователь почти никогда не видит, но которая незаметно сопровождает каждое его действие.

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

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

Хорошая модель данных является отражением объективной реальности, в которой работают инженеры. Чем точнее это отражение, тем естественнее ведёт себя система.

Можно ли спроектировать PLM с нуля

Итак, мы определились, что из себя представляет модель данных в общем случае. Но не затрагивали, какие принципы должны быть в ее основе, если речь идет о PLM системе.

Казалось бы, достаточно взять отечественные стандарты, описать их в виде объектов и связей, после чего реализовать всё это в программном коде. Но такой подход не работает. Стандарты описывают инженерную деятельность, а не устройство информационной системы. Между регламентами нормативного документа и архитектурой системы лежит работа по анализу предметной области.

Необходимо прежде всего понять, как я и писал выше, какие сущности существуют в инженерной практике, какие из них являются самостоятельными объектами, а какие производными. Какие связи являются фундаментальными, а какие возникают вследствие других отношений и так далее

За многие годы участия в проектах по интеграции западных PLM систем на отечественных предприятиях и выстраивании сквозных процессов КТПП, приходило постепенное осознание, что наша система ЕСКД не «ложится» на западную модель данных, заложенную в их информационных системах, которую до конца не исправить и не подогнать под наши стандарты никакими настройками. Вместе с тем, российские решения в части автоматизированных систему управления данными об изделии, на мой взгляд, также требуют значительных затрат на адаптацию, делая процесс внедрения дорогим и трудоемким.

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

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

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

В третьей части статьи мы разберём, какими принципами должна руководствоваться модель данных современной PLM, если проектировать её не как универсальную систему «для всех», а как инструмент, изначально ориентированный на отечественную инженерную практику и требования ЕСКД. Речь пойдёт не о конкретной реализации и не о сравнении продуктов, а о тех архитектурных принципах, без которых, как мне кажется, невозможно построить действительно естественную для инженера PLM‑систему.

Часть 3 Проектирование «лёгкой» PLM на примере Constructum

Введение

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

Большинство современных PLM изначально проектировались как универсальные платформы, пригодные для различных отраслей промышленности. С одной стороны, такой подход является преимуществом: одна и та же система может использоваться в автомобилестроении, авиастроении, приборостроении или машиностроении. С другой стороны, чем шире круг решаемых задач, тем более абстрактной становится модель данных.

При разработке модели данных Constructum мы сознательно отказались от универсальности в пользу максимально точного соответствия требованиям ЕСКД в части формирования структуры изделия и управления его определениями (описание изделия с точки зрения конструкции, технологии, производства и так далее) на протяжении всего жизненного цикла.

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

Конструктор не должен задумываться, соответствует ли оформляемая спецификация требованиям ГОСТ, правильно ли выбраны объекты для внесения изменений или где должна храниться технологическая документация. Эти решения должна принимать сама система. Если действие противоречит требованиям ЕСКД или логике жизненного цикла изделия, оно должно быть невозможно.

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

В третьей части статьи мы рассмотрим внутреннее устройство модели данных Constructum: от глобальной идентификации объектов до реализации исполнений по ГОСТ 2.113.

Спойлер: ради этого нам пришлось отказаться от классической схемы Part → Revision → BOM, которая лежит в основе большинства современных западных PLM.

Понятие «Изделие»

Рассмотрим понятие «Изделие» на примере автомобиля. Любой человек понимает, что автомобиль состоит из двигателя, кузова, подвески, трансмиссии, колес и множества других деталей. Более того, можно начать проектирование автомобиля, еще не имея ни одного чертежа или документа. Для человека автомобиль существует как самостоятельный объект реального мира. Но система работает иначе.

Для компьютера не существует понятий «автомобиль», «насос» или «редуктор», пока они не представлены в виде объектов модели данных. То есть, если информационной системе сообщить, что это «автомобиль», то вместе с этим необходимо сообщить и «что такое автомобиль».

Объект реального мира и его описание

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

Однако большинство информационных систем начинают моделирование именно с описания изделия.

Для человека последовательность выглядит так:

Для информационной системы обычно наоборот:

И это не философское различие. Именно из‑за этого возникают многие архитектурные ограничения современных PLM.

Логика классической модели PLM

Несмотря на различия между PLM‑системами, такими, как Teamcenter, Windchill, ENOVIA и другими, большинство из них используют похожий принцип: построение модели данных вокруг некоего объекта, называемого в разных системах Part, Item, WTPart, который условно можно назвать элементом.

Упрощенно она выглядит следующим образом:

При таком построении модели данных объект Item одновременно выполняет две различные функции:

1. Идентифицирует изделие;

2. Является контейнером его изменяемого инженерного описания.

Именно поэтому практически вся работа инженера в подобных системах ведется уже не с самим Item, а с его Revision. Другими словами, инженер работает не с автомобилем как таковым, а с автомобилем в состоянии Revision B.

Подобная модель исторически хорошо зарекомендовала себя при реализации процессов управления изменениями и конфигурациями. Однако она объединяет два разных понятия: объект реального мира и его инженерное описание.

Пока изменения затрагивают исключительно документацию, никаких проблем не возникает. Но при построении модели, строго соответствующей требованиям ЕСКД, это объединение начинает создавать неоднозначности.

Почему Revision не является версией изделия

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

Например, на изделие «Вал» первоначально был разработан комплект конструкторской документации. Позже, при обнаружении ошибки в чертеже, исправили размер фаски, добавили уточнение шероховатости, изменили оформление технических требований. В результате появилась новая ревизия документации. При этом сам вал не изменился. То есть, объект реального мира остался тем же самым. Изменилась лишь информация, которая его описывает.

Следовательно, Revision является версией инженерного описания изделия, а не версией самого изделия.

И вот здесь проявляться одна из наиболее спорных особенностей классических PLM.

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

С точки зрения требований взаимозаменяемости (Form, Fit, Function) это уже другое изделие. А как мы прекрасно знаем, с инженерной точки зрения, если нарушена взаимозаменяемость, должно появиться новое изделие.

Именно этого требует как отечественная инженерная практика, так и международные подходы к управлению изделиями.

Однако в большинстве современных PLM оба случая реализуются одним и тем же механизмом — созданием новой Revision, в результате чего внутри одной последовательности ревизий могут оказаться изменения совершенно разной природы.

Например:

При этом, Revision B может отличаться от Revision A исключительно исправлением оформления документации, а Revision C может содержать конструктивные изменения, приводящие к потере взаимозаменяемости.

С точки зрения модели данных оба изменения выглядят одинаково. Хотя с инженерной точки зрения это совершенно разные события.

Именно здесь появляется необходимость в дополнительных механизмах:

• effectivity;

• applicability;

• replacement;

• superseded;

• configuration rules.

Другими словами, сама модель данных уже не позволяет однозначно определить, остаётся ли это тем же изделием или речь уже идёт о новом. Поэтому это приходится устанавливать с помощью дополнительных процессов, статусов и правил.

Подход Constructum

Объект «Изделие»

При проектировании Constructum мы решили разделить эти понятия на уровне самой модели данных. В системе появился самостоятельный объект KProduct, который представляет собой не комплект документации и не очередную ревизию изделия, а само изделие, как объект реального мира.

При этом, KProduct практически ничего не знает о себе — он:

• не содержит структуру изделия;

• не содержит документацию;

• не содержит технологию изготовления;

• не содержит производственные данные.

Он лишь утверждает: Я — ИЗДЕЛИЕ. Все остальные знания об изделии появляются позже в его определениях.

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

В итоге, если очень кратко:

Constructum моделирует не данные об изделии, а само изделие и его жизненный цикл.

Объект «Определение»

После того, как мы выделили KProduct в отдельный объект, независимый от его документации, то логичным является и появление объекта, который будет содержать всю информацию об изделии. Этим объектом стал Definition.

Но не все так просто. Как известно, на протяжении всего жизненного цикла одно и то же изделие одновременно описывается различными специалистами.

Конструктор определяет геометрию изделия, его состав, требования к материалам и оформляет комплект конструкторской документации.

Технолог описывает способы изготовления этого же изделия, последовательность операций, оснастку и применяемое оборудование.

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

Позже могут появиться эксплуатационные, логистические, сервисные и другие описания. И все они относятся к одному и тому же изделию, но описывают его с разных точек зрения. Именно поэтому в Constructum вместо единственного определения изделия несколько независимых, например:

Каждое определение представляет собой самостоятельный объект модели данных.

Это принципиально отличается от классического подхода, где существуют различные представления (Views) одной Revision. Например, в Teamcenter можно встретить Engineering View, Manufacturing View, Plant View. В Windchill используются аналогичные механизмы представлений и связанных объектов. И все эти представления относятся к одному состоянию объекта — Revision.

В Constructum каждое из определений является независимым объектом, имеет собственный жизненный цикл, историю изменений, собственные документы, ревизии и процессы согласования. Но важно подчеркнуть, что при этом все определения относятся к одному изделию.

Еще раз — получается следующая схема:

Именно изделие объединяет все определения.

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

• необходимо использовать уже закупленные материалы;

• требуется изготовить ранее размещенный заказ;

• оборудование еще не перенастроено;

• изменение еще не прошло производственную подготовку.

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

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

В Constructum такая возможность заложена непосредственно в модель данных — документы больше не принадлежат изделию, вследствие чего и изменилась роль документа.

Во многих PLM документ практически неотделим от Revision изделия:

В Constructum эта связь отсутствует и документ относится не к изделию, а к определению изделия:

Таким образом, документ становится лишь одним из способов описания определения, что принципиально меняет классический подход к архитектуре PLM.

Например, конструкторское определение может существовать еще до появления первого чертежа.

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

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

Constructum повторяет именно эту последовательность.

Ревизия

Возвращаясь к утверждению одного из предыдущих разделов третьей части «Почему Revision не является версией изделия», становится очевидным еще одно следствие разделения объектов изделия KProduct и определения Definition.

Если изменяется конструкторская документация, изменяется не изделие, изменяется конструкторское определение. Следовательно, именно определение должно иметь ревизии.

В Constructum модель выглядит следующим образом:

Здесь важно обратить внимание на одно принципиальное обстоятельство.

Пока изменение не нарушает взаимозаменяемость изделия, изменяется только определение.

Например:

• исправлена ошибка оформления;

• уточнены технические требования;

• скорректирована документация;

• добавлены дополнительные сведения.

Во всех этих случаях изделие остается тем же самым. Изменяется лишь его описание. Совершенно иначе выглядит ситуация, когда изменение нарушает требования взаимозаменяемости или FFF (Form, Fit, Function).

Например:

• изменились присоединительные размеры;

• изменился принцип работы изделия;

• изменились функциональные характеристики.

С точки зрения инженерной практики это уже другое изделие. Следовательно, в Constructum создается новый объект KProduct.

Получается следующая схема:

Изменение FFF:

Обратите внимание. Изменение определения приводит к созданию новой Revision. Изменение самого изделия приводит к созданию нового KProduct. Эти два события больше невозможно перепутать.

Именно здесь, на наш взгляд, проходит одно из главных отличий Constructum от большинства современных PLM.

В классических системах задача отличия нового изделия или новой ревизии существующего во многом определяется процессами управления изменениями.

В Constructum ответ содержится непосредственно в модели данных. Если изменилось определение, то появляется новая Revision, а если изменился объект реального мира — появляется новый KProduct.

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

Именно поэтому при разработке Constructum мы стремились не к максимальной гибкости модели, а к ее однозначности.

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

Исполнение как самостоятельное изделие

Еще одним следствием выбранной модели данных стало переосмысление понятия исполнения.

На протяжении многих лет в большинстве западных PLM исполнение изделия рассматривается как вариант некоторой базовой конструкции.

Хотя стоит отметить, что в западной практике также существует понятие исполнение, аналогичное отечественному.

Упрощенно такая модель выглядит следующим образом:

Другими словами, существует одно изделие, а различные исполнения представляют собой различные «конфигурации» этого изделия.

Подобный подход хорошо подходит для автомобильной промышленности, где один и тот же автомобиль может иметь десятки или даже сотни комбинаций двигателей, коробок передач, комплектаций и дополнительного оборудования.

Изменяется конфигурация изделия, а само изделие продолжает существовать как единая сущность.

В отечественной инженерной практике мы оперируем понятием «Исполнение». Согласно ГОСТ 2.113 каждое исполнение представляет собой самостоятельное изделие. Оно имеет собственное обозначение, самостоятельно учитывается, самостоятельно изготавливается, самостоятельно проходит через процессы производства, эксплуатации и ремонта.

Другими словами, исполнение — это уже не вариант, а изделие.

Именно поэтому в Constructum исполнение реализовано не как разновидность конфигурации, а является обычным объектом KProduct. Получается следующая модель.

Каждое исполнение обладает собственной структурой, собственными определениями, собственной документацией и собственной историей изменений, что полностью соответствует логике ЕСКД.

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

В Constructum для этого существует отдельный объект KExecutionGroup, который не определяет варианты изделия, а представляет группу изделий, между которыми существуют отношения, определенные требованиями ГОСТ 2.113. Именно этот объект становится владельцем общей информации.

Получается следующая схема:

Таким образом, становится возможным автоматически формировать как основные документы исполнения, так и групповые документы, предусмотренные ГОСТ без дополнительных соглашений, специальных типов спецификаций и без искусственного объединения различных изделий в один объект.

Применяемость

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

Во многих современных PLM‑системах управление применимостью (Effectivity) является частью управления конфигурациями.

Например:

То есть система определяет с помощью инструмента Effectivity какая ревизия детали должна использоваться при изготовлении изделия с определенным серийным номером.

В Constructum это реализовано иначе: для каждого экземпляра изделия фиксируется конкретное определение, по которому он был изготовлен.

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

Именно поэтому управление применимостью переносится на уровень производственного определения.

Получается следующая модель:

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

Таким образом Effectivity перестает быть способом выбора ревизии изделия, а становится способом описания конкретного изготовленного экземпляра.

На наш взгляд именно такая модель значительно ближе к реальному производству.

Почему модель данных становится проще

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

Рассмотрим цепочку объектов Constructum.

Каждый объект отвечает только за одну задачу.

• KProduct идентифицирует изделие;

• Definition описывает изделие на определенном этапе жизненного цикла;

• Revision хранит историю изменения определения.

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

Единая модель объектов

До этого момента мы рассматривали исключительно инженерные сущности, однако в основе модели данных Constructum заложен более фундаментальный объект — единый базовый объект KObject.

KObject — это не весь объект и не все знания о нём. Это общий базовый фундамент, на котором строятся конкретные типы объектов и всё остальное знание системы об этих объектах.

Практически всё, что существует в системе, является объектом: изделие, документ, изменение, проект, пользователь, группа, организация, определение изделия.

Все они имеют общую природу. Каждый объект обладает глобальным идентификатором, типом, жизненным циклом, владельцем, историей существования. Благодаря этому любые сервисы платформы работают с единым набором базовых понятий.

Им не требуется заново реализовывать механизмы идентификации объектов, управление жизненным циклом или контроль доступа.

При реализации базы данных Constructum используется методология Anchor Modeling.

Причина выбора достаточно проста. На протяжении жизненного цикла изделия информация непрерывно изменяется. Изменяются свойства изделия, документы, определения, связи между объектами.

При этом для PLM принципиально важно не только текущее состояние объекта, но и возможность восстановить его состояние на любой момент времени.

Anchor Modeling естественным образом позволяет разделить:

• сам объект;

• его изменяемые свойства;

• связи между объектами.

Такой подход хорошо соответствует самой архитектуре Constructum: объект существует независимо от своих атрибутов, определение существует независимо от документов, а последние в свою очередь существуют независимо от истории изменений.

Именно поэтому модель данных практически полностью повторяет структуру предметной области.

Еще одной целью при проектировании Constructum была возможность естественного разделения системы на независимые сервисы.

Поскольку изделие отделено от своих определений, различные сервисы могут независимо управлять собственными областями ответственности:

• конструкторский сервис работает только с KDesignDefinition;

• технологический — только с KTechnologyDefinition;

• производственный — только с KManufacturingDefinition.

При этом все они работают с одним и тем же объектом KProduct. Вследствие чего отсутствует необходимость дублирования изделия между сервисами, где каждый сервис отвечает только за собственное определение, что позволяет независимо масштабировать различные части системы без нарушения целостности модели данных.

Заключение

Большинство современных PLM используют зрелые технические решения для хранения структуры изделия, управления документами, изменениями и конфигурациями. Поэтому основное отличие Constructum заключается не в способе хранения BOM, не в реализации Workflow и не в поддержке Revision. Оно заключается в самой модели предметной области.

В Constructum первичными являются не документы и не их ревизии, а объекты реального мира. Очевидно, что изделие существует независимо от своей документации, различные знания — определения существуют независимо друг от друга. В свою очередь, документы принадлежат этим определениям.

При этом, исполнение является самостоятельным изделием со всеми вытекающими отсюда свойствами: история изменений, процессы согласования, и прочее.

Изменение определения, то есть корректировка КД/ТД, не приводит к изменению изделия.

А вот изменение изделия приводит к появлению нового изделия.

Именно такое разделение понятий позволило построить модель данных, которая естественным образом соответствует требованиям ЕСКД и при этом остается удобной для реализации в современной микросервисной архитектуре.

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

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