Система управления жизненным циклом — различия между версиями

м
 
(не показано 19 промежуточных версий этого же участника)
Строка 1: Строка 1:
'''«Управление жизненным циклом»''' — это термин, которым люди пытаются обозначить практику обеспечения связности всех состояний системы, как в прямом направлении (например, передача рабочей документации на стадию сооружения), так и в обратном направлении (например, учет данных по надёжности аналогичных эксплуатируемых уже систем на стадии проектирования новых). Эту практику трудно выделить из традиционных практик системной инженерии – управления требованиями, создания системной архитектуры, системной интеграции, верификации и валидации и т.д.. При внимательном разбирательстве оказывается, что суть разговоров про «управление жизненным циклом» сводится к необходимости освоения привычных для системной инженерии практик управления информацией («нужная информация должна быть у нужных заинтересованных сторон вовремя, и в доступной для её использования форме»), управления конфигурацией («проектная информация должна соответствовать требованиям, информация «как построено» должна соответствовать проекту, в том числе проектным обоснованиям, физическая система должна соответствовать информации «как построено», а разные части проекта при этом должны соответствовать друг другу», иногда часть этой практики назвают «управление изменениями»).  
+
'''«Управление [[Жизненный цикл|жизненным циклом]]»''' — это термин, которым люди пытаются обозначить [[:Категория:Практики|практику]] обеспечения связности всех состояний [[система|системы]], как в прямом направлении (например, передача [[Рабочая документация|рабочей документации]] на стадию сооружения), так и в обратном направлении (например, учет данных по [[Надежность|надёжности]] аналогичных эксплуатируемых уже систем на стадии проектирования новых). Эту практику трудно выделить из традиционных практик системной инженерии – [[Управление требованиями|управления требованиями]], [[Инженерия системной архитектуры|создания системной архитектуры]], [[Системная интеграция|системной интеграции]], [[Проверки и приемки|верификации и валидации]] и т.д..
  
 +
«Управление жизненным циклом» сводится к необходимости освоения привычных для системной инженерии практик:
 +
* '''управление информацией''' («нужная информация должна быть у нужных заинтересованных сторон вовремя, и в доступной для её использования форме»),
 +
* '''[[управление конфигурацией]]''' («проектная информация должна соответствовать требованиям, информация «как построено» должна соответствовать проекту, в том числе проектным обоснованиям, физическая система должна соответствовать информации «как построено», а разные части проекта при этом должны соответствовать друг другу», иногда часть этой практики назвают «[[управление изменениями]]»).
  
 
== СУЖЦ vs PLM ==
 
== СУЖЦ vs PLM ==
Системная инженерия редко использует понятие «управление жизненным циклом», но это понятие часто используется поставщиками программных систем [[PLM-система|PLM]] (Product Life cycle Management).
+
[[Системная инженерия]] редко использует понятие «управление жизненным циклом», но это понятие часто используется поставщиками программных систем [[PLM-система|PLM]] (Product Life cycle Management).
  
В России сейчас провоходит серия межотраслевых и международных мероприятий (совещаний, конференций и т.д.), где активно используется название "система управления жизненным циклом" (СУЖЦ), вводимое взамен PLM (product lifecycle management). Эта замена термина требует некоторой расшифровки.
+
В России сейчас проходит серия межотраслевых и международных мероприятий (совещаний, конференций и т.д.), где активно используется название "система управления жизненным циклом" (СУЖЦ), вводимое взамен PLM (product lifecycle management). Эта замена термина требует некоторой расшифровки.
  
Слово "продукт" из PLM в СУЖЦ пропало не случайно, ибо речь идет о сложных иненерных объектах – если вертолёт еще можно с натяжкой назвать «продуктом» в силу его серийности, то атомная станция «продуктом» обычно уже не называется. Поэтому "жизненным циклом" какой именно системы тут «управляется», нужно уточнять в каждом конкретном случае. «Система УЖЦ системы» немного запутывает, но именно это и имеется ввиду. Чтобы не слишком путаться, в название этой статьи я вынес «СУЖЦ управления сложным инженерным объектом», но «сложный инженерный объект» —  это просто расшифровка слова «система».
+
Слово "продукт" из PLM в СУЖЦ пропало не случайно, ибо речь идет о сложных инженерных объектах – если вертолёт еще можно с натяжкой назвать «продуктом» в силу его серийности, то атомная станция «продуктом» обычно уже не называется. Поэтому "жизненным циклом" какой именно системы тут «управляется», нужно уточнять в каждом конкретном случае. «Система УЖЦ системы» немного запутывает, но именно это и имеется ввиду.
  
'''«Система УЖЦ»''' —  это прежде всего социотехническая система, т.е. она включает не только программные средства PLM, но и организацию людей (практики работы, профессиональные роли, необходимый инструментарий для поддержки этих профессиональных ролей, утвержденные виды жизненного цикла каких-то конкретных рабочих продуктов и т.д.). Поэтому специалисты в слове "система" слышат одно ("информационная система", прежде всего PLM), а менеджеры —  совсем другое ("система менеджмента", способ организации работ). Тут еще нужно отметить западную традицию произвольного добавления слова management в сочетаниях «чего-нибудь менеджмент».
+
'''«Система УЖЦ»''' —  это прежде всего социотехническая система, т.е. она включает не только программные средства PLM, но и организацию людей ([[:Категория:Практики|практики]] работы, профессиональные роли, необходимый инструментарий для поддержки этих профессиональных ролей, утвержденные виды жизненного цикла каких-то конкретных [[рабочий продукт|рабочих продуктов]] и т.д.). Поэтому специалисты в слове "система" слышат одно ("информационная система", прежде всего PLM), а менеджеры —  совсем другое ("система менеджмента", способ организации работ). Тут еще нужно отметить западную традицию произвольного добавления слова management в сочетаниях «чего-нибудь [[менеджмент]]».
  
По-новому сформулированная СУЖЦ не использует PLM как обязательный класс программных средств, вокруг которого такая система строится. В крупных инженерных проектах обычно используется сразу несколько (чаще всего существенно "недоосвоенных") PLM разных вендоров, и при создании СУЖЦ речь идёт обычно уже об их межорганизационной интеграции. Конечно, при этом решаются и вопросы, как интегрировать в СУЖЦ информацию и тех систем, которые еще не имеют связи с какой-то из PLM систем расширенного предприятия. Термином «расширенное предприятие» (extended enterprise) обычно называют созданную посредством системы контрактов организацию из ресурсов (людей, инструментов, материалов) участвующих в конкретном инженерном проекте различных юридических лиц. В расширенных предприятиях ответ на вопрос, в какую именно PLM интегрируются данные какой именно из систем CAD/CAM/ERP/EAM/CRM/и т.д.. становится нетривиальным: владельцам разных предприятий не предпишешь использовать программные средства одного поставщика.  
+
По-новому сформулированная СУЖЦ не использует PLM как обязательный класс программных средств, вокруг которого такая система строится. В крупных инженерных проектах обычно используется сразу несколько (чаще всего существенно "недоосвоенных") PLM разных вендоров, и при создании СУЖЦ речь идёт обычно уже об их межорганизационной интеграции. Конечно, при этом решаются и вопросы, как интегрировать в СУЖЦ информацию и тех систем, которые еще не имеют связи с какой-то из PLM систем расширенного предприятия. Термином «расширенное предприятие» (extended enterprise) обычно называют созданную посредством системы контрактов организацию из ресурсов (людей, инструментов, материалов) участвующих в конкретном инженерном проекте различных юридических лиц. В расширенных предприятиях ответ на вопрос, в какую именно PLM интегрируются данные какой именно из систем [[CAD]]/[[CAM-система|CAM]]/[[ERP]]/[[EAM-система|EAM]]/[[CRM-система|CRM]]/и т.д.. становится нетривиальным: владельцам разных предприятий не предпишешь использовать программные средства одного поставщика.  
  
 
А поскольку PLM-система всё-таки являтся программными средствами, а "система управления" из СУЖЦ явно понимается в том числе как "система менеджмента", то термин СУЖЦ подразумевает явно и организационный аспект, а не только аспект информационных технологий. Тем самым фраза "использование PLM для поддержки системы управления жизненным циклом" вполне осмыслена, хотя может запутывать при дословном переводе в ней “PLM” на русский.
 
А поскольку PLM-система всё-таки являтся программными средствами, а "система управления" из СУЖЦ явно понимается в том числе как "система менеджмента", то термин СУЖЦ подразумевает явно и организационный аспект, а не только аспект информационных технологий. Тем самым фраза "использование PLM для поддержки системы управления жизненным циклом" вполне осмыслена, хотя может запутывать при дословном переводе в ней “PLM” на русский.
Строка 19: Строка 22:
 
* «система документооборота» (workflow engine) для поддержки «управления»,
 
* «система документооборота» (workflow engine) для поддержки «управления»,
 
* «портал» для просмотра содержимого репозитория и состояния документооборота.
 
* «портал» для просмотра содержимого репозитория и состояния документооборота.
 
  
 
== Назначение СУЖЦ ==
 
== Назначение СУЖЦ ==
Главное назначение: СУЖЦ обнаруживают и предотвращают [[коллизии]], неизбежные при коллаборативной разработке. Все остальные функции СУЖЦ являются производными, поддерживающими эту главную функцию.
+
'''Главное назначение:''' СУЖЦ обнаруживают и предотвращают [[коллизии]], неизбежные при коллаборативной разработке. Все остальные функции СУЖЦ являются производными, поддерживающими эту главную функцию.
  
Главная идея любой современной СУЖЦ -- это использование аккуратного и непротиворечивого представления системы и окружающего её мира в неизбежно разнородных и изначально несовместимых между собой компьютерных системах расширенной организации. Использование виртуальных макетов, информационных моделей, датацентрических репозиториев проектной информации обеспечивает выявление коллизий при "сооружении в компьютере", "виртуальной сборке", а не при выносе чертежей и других моделей проекта в материальную реальность в ходе действительного сооружения «в металле и бетоне» и пуска в эксплуатацию.
+
'''Главная идея любой современной СУЖЦ''' - это использование аккуратного и непротиворечивого представления системы и окружающего её мира в неизбежно разнородных и изначально несовместимых между собой компьютерных системах расширенной организации. Использование виртуальных макетов, информационных моделей, датацентрических репозиториев проектной информации обеспечивает выявление коллизий при "сооружении в компьютере", "виртуальной сборке", а не при выносе чертежей и других моделей проекта в материальную реальность в ходе действительного сооружения «в металле и бетоне» и пуска в эксплуатацию.
  
Нужно отметить, что идея СУЖЦ не имеет тем самым отношения к разнообразным «автоматизациям проектирования», прежде всего – к «[[Порождающее проектирование|порождающему проектированию]]» (generative design) и «[[Порождающее производство|порождающему производству]]» (generative manufacturing), при которых букве «А» в слове «САПР» придаётся первоначальный смысл – компьютеру поручается самому выполнить операции синтеза по проектированию конструкции (design synthesis) и планированию работ по сооружению.
+
Идея СУЖЦ не имеет тем самым отношения к разнообразным «автоматизациям проектирования», прежде всего – к «[[Порождающее проектирование|порождающему проектированию]]» (generative design) и «[[Порождающее производство|порождающему производству]]» (generative manufacturing). СУЖЦ озабочена более не синтезом, а анализом: обнаруживает и/или предотвращает коллизии в результатах проектирования отдельных подсистем, когда их будут собирать вместе по самым разным технологиям:
 
+
СУЖЦ озабочена более не синтезом, а анализом: обнаруживает и/или предотвращает коллизии в результатах проектирования отдельных подсистем, когда их будут собирать вместе по самым разным технологиям
+
 
* сливая данные проекта вместе в один репозиторий,
 
* сливая данные проекта вместе в один репозиторий,
 
* запуская алгоритм проверки целостности для распределенных в нескольких репозиториях инженерных данных,
 
* запуская алгоритм проверки целостности для распределенных в нескольких репозиториях инженерных данных,
* проводя актуальную "виртуальную сборку" и имитационное моделирование для специально отобранного подмножества проектных данных.  
+
* проводя актуальную "виртуальную сборку" и [[имитационное моделирование]] для специально отобранного подмножества проектных данных.
  
В частности, использование СУЖЦ подразумевает '''отказ не только от бумаги в проектировании, но и от "электронной бумаги"''' (.tiff или других растровых форматов) и переход к датацентрическому представлению информации. Сравнить две модели, существующие на бумаге в каких-то нотациях и найти в них несоответствия много сложнее и дольше, нежели предотвращать коллизии в структурированных электронных документах, использующих не растровую графику, а инженерные модели данных. Две диаграммы-описания, даже если они хранятся в электронной растровой форме, много сложнее сравнить и проанализировать совместно, ежели они не придерживаются каких-то соглашений о кодировании реальности, какой-то модели данных жизненного цикла. Имеется ввиду модель, разработанная в соответствии с каким-то языком (в терминах стандарта описания метода разработки [[ISO 24744]]), или метамоделью (в терминах консорциума стандартизации [[OMG]]), или моделью данных/справочными данными (в терминах стандарта интеграции данных жизненного цикла [[ISO 15926]]). Именно такой переход к структурно представляемым моделям, существующим уже на ранних стадиях проектирования и называется «[[Моделеориентированная системная инженерия|моделеориентированной системной инженерией]]» (MBSE, model-based systems engineering). Снимать коллизии при помощи компьютерной обработки данных становится возможным уже на самых ранних стадиях жизненного цикла, еще до появления полноценных 3D моделей конструкции.
+
== Моделеориентированный подход ==
 +
Использование СУЖЦ подразумевает '''отказ не только от бумаги в проектировании, но и от "электронной бумаги"''' (.tiff или других растровых форматов) и переход к датацентрическому представлению информации. Сравнить две модели, существующие на бумаге в каких-то нотациях и найти в них несоответствия много сложнее и дольше, нежели предотвращать коллизии в структурированных электронных документах, использующих не растровую графику, а инженерные модели данных.
  
Связь моделей и реальности через использование штрих-кодов или RFID позволяет легче снимать коллизии между описаниями системы и самой системой. СУЖЦ поэтому должна включать средства для снятия коллизий между тем, что запроектировано, что существует в реальности, и что мы думаем о том, что существует в реальности (описания as build).
+
Модель данных может быть разработана в соответствии с каким-то языком, например:
 +
* в терминах стандарта описания метода разработки [[ISO 24744]]),
 +
* метамодель (в терминах консорциума стандартизации [[OMG]]),
 +
* модель данных/[[справочные данные]] (в терминах стандарта интеграции данных жизненного цикла [[ISO 15926]]).
  
СУЖЦ прежде всего поддерживает принцип "одно значение вводится в компьютер руками один раз": всё остальное делается копированием данных из приложения в приложение. При любом "перевводе руками" (или «распознаванием текста/изображений», которые были уже выведены из других информационных систем на бумагу или в растровые форматы) информация может исказиться. Более того, если используется "ручной переввод", то в силу естественной склонности экономить человеческие усилия из исходных бумажных или неструктурированных электронных документов перевбивается отнюдь не вся нужная для контроля коллизий контекстная информация. СУЖЦ должна обеспечивать механизм передачи данных из одного приложения CAD/CAM/ERP/PM/EAM/и т.д. в другое – причем в электронном структурированном виде, а не в виде «пачки электронной бумаги». Передача данных из одной инженерной информационной системы (с четким пониманием откуда, куда, когда, что, зачем, как) -- это часть обеспечиваемой СУЖЦ функциональности. Тем самым СУЖЦ должна поддерживать workflow (ход работ, который частично выполняется людьми, а частично компьютерными системами).
+
Именно такой переход к структурно представляемым моделям, существующим уже на ранних стадиях проектирования и называется «[[MBSE|Системной инженерией на основе моделей]]» (MBSE, model-based systems engineering). Снимать коллизии при помощи компьютерной обработки данных становится возможным уже на самых ранних стадиях жизненного цикла, еще до появления полноценных 3D моделей конструкции.
 
+
СУЖЦ должна также следить за "одной версией правды", то есть предоставлять функцию управления конфигурацией -- как моделей, так и физических частей системы. Управление конфигурацией -- это прежде всего отслеживание и согласование изменений в версиях отдельных требованиях и проектных решений, т.е. отслеживание действий проектировщиков и уведомление их о том, что что-то изменилось либо в требованиях, либо в реальной системе. СУЖЦ поддерживает таксономию требований разного уровня и предоставляет средства для проверки коллизии разноуровневых проектных решений и их обоснований с этими требованиями. В ходе инженерной разработки любое описание системы, любая её модель изменяются и дополняются многократно, и существуют поэтому во множестве альтернативных версий разной степени правильности, и в разной мере соответствующих друг другу. СУЖЦ должна гарантировать, что для текущей работы используется только правильное сочетание этих версий.
+
  
 +
СУЖЦ должна:
 +
* '''обеспечивать механизм передачи данных из одного приложения CAD/CAM/ERP/PM/EAM/и т.д. в другое''' – причем в электронном структурированном виде, а не в виде «пачки электронной бумаги». Передача данных из одной инженерной информационной системы (с четким пониманием откуда, куда, когда, что, зачем, как) - это часть обеспечиваемой СУЖЦ функциональности. Тем самым СУЖЦ должна поддерживать workflow (ход работ, который частично выполняется людьми, а частично компьютерными системами).
 +
* '''контролировать версии''', то есть предоставлять функцию [[управление конфигурацией|управления конфигурацией]] - как моделей, так и физических частей системы. СУЖЦ поддерживает таксономию требований разного уровня и предоставляет средства для проверки коллизии разноуровневых проектных решений и их обоснований с этими требованиями. В ходе инженерной разработки любое описание системы, любая её модель изменяются и дополняются многократно, и существуют поэтому во множестве альтернативных версий разной степени правильности, и в разной мере соответствующих друг другу. СУЖЦ должна гарантировать, что для текущей работы используется только правильное сочетание этих версий.
  
 
== Архитектура СУЖЦ ==
 
== Архитектура СУЖЦ ==
Архитектурных решений для СУЖЦ может быть множество, одна и та же функция может быть поддержана различными конструкциями и механизмами работы.
+
Архитектурных решений для СУЖЦ может быть множество, одна и та же функция может быть поддержана различными конструкциями и механизмами работы. Можно выделить три вида архитектуры:
Традиционные попытки создать СУЖЦ – это обеспечить важнейшие передачи данных по принципу "точка-точка" между разными приложениями. При этом может быть использована какая-нибудь специализированная система поддержки workflow (BPM engine, «движок управления бизнес-процессами»), или система обработки событий (complex event processing engine). К сожалению, объем работы по обеспечению обменов «точка-точка» оказывается просто грандиозным: каждый раз требуются специалисты, разобравшиеся в обоих связываемых системах и методе передаче информации.
+
# '''Традиционные попытки создать СУЖЦ''' – это обеспечить важнейшие передачи данных по принципу "точка-точка" между разными приложениями. При этом может быть использована какая-нибудь специализированная система поддержки workflow ([[BPM]] engine, «движок управления бизнес-процессами»), или система обработки событий (complex event processing engine). К сожалению, объем работы по обеспечению обменов «точка-точка» оказывается просто грандиозным: каждый раз требуются специалисты, разобравшиеся в обоих связываемых системах и методе передаче информации.
 +
# '''Использование стандарта интеграции данных ЖЦ''' [[ISO 15926]] по методу «ISO 15926 outside», когда для каждого инженерного приложения разрабатывается адаптор в нейтральное представление, соответствующее стандарту. Тем самым, все данные получают возможность встретиться в каком-то приложении и коллизия между ними может быть обнаружена – но для приложения требуется разработать лишь один адаптер передачи данных, а не несколько таких адаптеров (по числу других приложений, с которыми нужно обеспечить связь).
 +
# '''[[PLM]]''' (Teamcenter, ENOVIA, SPF, NET Platform и т.д.) - используется стандартизованная архитектура, за тем лишь исключением, что используемая в каждой из этих PLM модель данных менее универсальна в плане отражения любой предметной области инжиниринга, а также не является нейтральным и доступным всем форматом. Так что использование ISO 15926 в качестве базового представления при передаче данных в СУЖЦ можно считать дальнейшим развитием идей, по факту реализованных в современных PLM.
  
Одним из решений тут является переход к использованию стандарта интеграции данных жизненного цикла ISO 15926 по методу «ISO 15926 outside», когда для каждого инженерного приложения разрабатывается адаптор в нейтральное представление, соответствующее стандарту. Тем самым, все данные получают возможность встретиться в каком-то приложении и коллизия между ними может быть обнаружена – но для приложения требуется разработать лишь один адаптер передачи данных, а не несколько таких адаптеров (по числу других приложений, с которыми нужно обеспечить связь).
+
По архитектуре [[Управление конфигурацией|управления конфигурацией]], СУЖЦ можно разделить на три вида:
 +
* '''«репозиторий»''' (актуальное хранение всех данных проекта в одном репозитории СУЖЦ, куда копируются данные оттуда, где они были разработаны),
 +
* '''«регистр»''' (СУЖЦ поддерживает список адресов данных жизненного цикла в многочисленных репозиториях других [[САПР]], систем инженерного моделирования, [[PLM]], [[ERP]] и т.д.),
 +
* '''«гибридная архитектура»''' -- когда часть данных копируется в центральный репозиторий СУЖЦ, а часть данных доступна из других мест по ссылкам.
  
В принципе, точно такая же архитектура используется во всех современных PLM (Teamcenter, ENOVIA, SPF, NET Platform и т.д.), за тем лишь исключением, что используемая в каждой из этих PLM модель данных менее универсальна в плане отражения любой предметной области инжиниринга, а также не является нейтральным и доступным всем форматом. Так что использование ISO 15926 в качестве базового представления при передаче данных в СУЖЦ можно считать дальнейшим развитием идей, по факту реализованных в современных PLM.
+
Архитектора СУЖЦ должна также описывать:
Тем не менее, есть вариант реализации СУЖЦ на базе конкретной PLM одного из ведущих поставщиков программного обеспечения – что не снимает обязанности ответить на огромное число других вопросов, например о единственности репозитория для базиса (requirements and design baselines) проекта, или синхронизации различных репозиториев.  
+
* '''«портал»''' (в том числе «веб-портал»), его функциях и способ реализации. Само наличие портала позволяет успокоить топ-менеджеров демонстрируя отсутствие коллизий. К архитектурным решениям по «порталу СУЖЦ» предъявляются специфические требования.
 +
* '''алгоритмы проверки целостности/непротиворечивости данных''' жизненного цикла, а также описание работы этих алгоритмов:
 +
** стандартный модуль в отдельном приложении, работающий над данными в репозитории этого приложения – будь это [[САПР]] или [[PLM]];
 +
** специально разработанное для СУЖЦ программное средство проверки коллизий, имеющее доступ к данным разных приложений, находящихся в центральном репозитории СУЖЦ;
 +
** специально разработанное программное средство, обращающееся через интернет по защищенному каналу к разным [[Хранилище данных|хранилищам данных]], находящимся в разных организациях;
 +
** специально запрограммированные проверки с контролем коллизий при загрузке разных инженерных наборов данных в центральный репозиторий СУЖЦ;
 +
** комбинация из всех перечисленных методов – разных для разных типов коллизий; и т.д.
 +
* '''способ взаимодействия пользователей СУЖЦ''' (инженеров-проектантов, закупщиков, монтажников, менеджеров проекта сооружения и т.д.), и как именно программное обеспечение СУЖЦ поддерживает это взаимодействие способом, предотвращающим появление коллизий. Стандарты системной инженерии (в частности, стандарт практик системной инженерии [[ISO 15288]]) требуют выбора вида жизненного цикла для инженерии сложных объектов и указания того, какие варианты [[Практика|практик]] системной инженерии будут использованы. Модель жизненного цикла является одним из основных артефактов, которые служат для организационных договоренностей по координации работ расширенной организации инженерного проекта. Скоординированные работы в ходе [[Коллаборативная инженерия|коллаборативной разработки]] (collaborative engineering) – это залог малого числа проектных коллизий. Как именно поддержит модель жизненного цикла СУЖЦ? Так, системы PLM обычно не находят место моделям жизненного цикла, и уж тем более моделям организации. Поэтому для СУЖЦ нужно искать другие решения по программной поддержке этих моделей.
 +
* '''Организационный аспект перехода к использованию СУЖЦ'''. Переход к использованию СУЖЦ может вызвать существенное изменение в структуре и даже кадровом составе инжиниринговой компании: не всех землекопов берут в экскаваторщики, не всех извозчиков берут в таксисты.
  
Опять же, архитектура управления конфигурацией может быть либо «репозиторий» (актуальное хранение всех данных проекта в одном репозитории СУЖЦ, куда копируются данные оттуда, где они были разработаны), либо «регистр» (СУЖЦ поддерживает список адресов данных жизненного цикла в многочисленных репозиториях других САПР, систем инженерного моделирования, PLM, ERP и т.д.), либо «гибридная архитектура» -- когда часть данных копируется в центральный репозиторий СУЖЦ, а часть данных доступна из других мест по ссылкам.
+
Главное для СУЖЦ – насколько предлагаемое решение способствует раннему обнаружению, а то и предотвращению коллизий. Ежели речь заходит о чём-то другом (содержательный выбор вида жизненного цикла в соответствии с профилем риска проекта, управление старением, управление стоимостью и реформа сметной системы, освоение [[Аксиоматическое Проектирование|axiomatic design]], сооружение с поставками «[[JIT|точно вовремя]]», [[порождающее проектирование]] и сооружение, а также многое-многое другое, также крайне полезное-современное-интересное), то это вопрос других систем, других проектов, других методов, других подходов. СУЖЦ должна хорошо делать своё дело, а не плохо решать огромный набор произвольно выбираемых чужих задач.
Архитекторы СУЖЦ также должны ответить на вопрос о «портале» (в том числе «веб-портале»), его функциях и способах реализации. Это не такой простой вопрос, если отвечать строго, как именно портал позволяет избежать коллизий. Обычно много легче отвечать на вопрос, как само наличие портала позволяет успокоить топ-менеджеров, но СУЖЦ должна успокаивать менеджеров специфическим образом: демонстрируя отсутствие коллизий. Поэтому к архитектурным решениям по «порталу СУЖЦ» предъявляются специфические требования.
+
 
+
Архитекторы СУЖЦ должны показать, предусматривают ли они работу каких-то отдельных алгоритмов проверки целостности/непротиворечивости данных жизненного цикла, и как будет устроена работа этих алгоритмов: стандартный модуль в отдельном приложении, работающий над данными в репозитории этого приложения – будь это САПР или PLM; специально разработанное для СУЖЦ программное средство проверки коллизий, имеющее доступ к данным разных приложений, находящихся в центральном репозитории СУЖЦ; специально разработанное программное средство, обращающееся через интернет по защищенному каналу к разным хранилищам данных, находящимся в разных организациях; специально запрограммированные проверки с контролем коллизий при загрузке разных инженерных наборов данных в центральный репозиторий СУЖЦ; комбинация из всех перечисленных методов – разных для разных типов коллизий; и т.д.
+
 
+
Архитекторы СУЖЦ как социотехнической системы должны также ответить на вопрос, как будет устроено взаимодействие инженеров-проектантов, закупщиков, монтажников, менеджеров проекта сооружения и т.д., и как именно программное обеспечение СУЖЦ поддерживает это взаимодействие способом, предотвращающим появление коллизий. Стандарты системной инженерии (в частности, стандарт практик системной инженерии ISO 15288) требуют выбора вида жизненного цикла для инженерии сложных объектов и указания того, какие варианты практик системной инженерии будут использованы. Модель жизненного цикла является одним из основных артефактов, которые служат для организационных договоренностей по координации работ расширенной организации инженерного проекта. Скоординированные работы в ходе коллаборативной разработки (collaborative engineering) – это залог малого числа проектных коллизий. Как именно поддержит модель жизненного цикла СУЖЦ? Так, системы PLM обычно не находят место моделям жизненного цикла, и уж тем более моделям организации. Поэтому для СУЖЦ нужно искать другие решения по программной поддержке этих моделей.
+
 
+
Организационный аспект перехода к использованию СУЖЦ нельзя недооценивать. Так, переход с лопат на экскаваторы, или с телег на грузовики может быть для организации чуть бОльшим шоком, чем об этом думают менеджеры, в глаза не видевшие ни одной лопаты или экскаватора, телеги или грузовика. Так и переход к использованию СУЖЦ может вызвать существенное изменение в структуре и даже кадровом составе инжиниринговой компании: не всех землекопов берут в экскаваторщики, не всех извозчиков берут в таксисты.
+
 
+
На все эти сложные вопросы выбора архитектуры нужно искать ответы, помня про главное для СУЖЦ – насколько предлагаемое решение способствует раннему обнаружению, а то и предотвращению коллизий. Ежели речь заходит о чём-то другом (содержательный выбор вида жизненного цикла в соответствии с профилем риска проекта, управление старением, управление стоимостью и реформа сметной системы, освоение axiomatic design, сооружение с поставками «точно вовремя», порождающее проектирование и сооружение, а также многое-многое другое, также крайне полезное-современное-интересное), то это вопрос других систем, других проектов, других методов, других подходов. СУЖЦ должна хорошо делать своё дело, а не плохо решать огромный набор произвольно выбираемых чужих задач.
+
  
 
У архитектора СУЖЦ тем самым две основные задачи:
 
У архитектора СУЖЦ тем самым две основные задачи:
 
* породить некоторое количество лучших архитектур-кандидатов и их гибридов
 
* породить некоторое количество лучших архитектур-кандидатов и их гибридов
 
* совершить многокритериальный выбор из этих архитектур.
 
* совершить многокритериальный выбор из этих архитектур.
 
+
** содержательное рассмотрение (содержательность критериев выбора)
Выбор также поделим на две части: содержательное рассмотрение и оформление результата (обоснование). Я лично не верю в процедуры с "коэффициентами критериев" или расчётом ROI как в механизмы содержательного рассмотрения архитектурных альтернатив, хотя я верю в то, что они хорошо позволяют оформить результат и представить этот выбор топ-менеджерам – ведь всегда можно подогнать коэффициенты в какой-то модели, а затем представить красивую табличку выбора на одном понятном для всех слайде.
+
** оформление результата (обоснование).
 
+
Задача содержательного многокритериального выбора из разных архитектурных вариатов для СУЖЦ, тем не менее, остаётся -- и главным для успеха в решении этой задачи является содержательность критериев выбора.
+
 
+
  
 
== Критерии выбора архитектурного решения для СУЖЦ ==
 
== Критерии выбора архитектурного решения для СУЖЦ ==
=== 1. Качество выполнения СУЖЦ своего основного предназначения: обнаружения и предотвращения коллизий ===
+
# '''Качество выполнения СУЖЦ своего основного предназначения: обнаружения и предотвращения коллизий'''
Рано или поздно, все коллизии будут обнаружены жизнью – наша надежда на СУЖЦ в том, что это будет рано, а не поздно. Если скорость обнаружения коллизий не увеличится, то это означает бесполезность СУЖЦ. Это главный критерий: насколько может быть ускорен ход инженерных работ за счёт ускорения обнаружения или предотвращения коллизий при использовании предлагаемой архитектуры СУЖЦ? А если время работ не может быть сокращено, то насколько за то же время можно увеличить объем работ при использовании тех же ресурсов?
+
#: Главный критерий: насколько может быть ускорен ход инженерных работ за счёт ускорения обнаружения или предотвращения коллизий при использовании предлагаемой архитектуры СУЖЦ? А если время работ не может быть сокращено, то насколько за то же время можно увеличить объем работ при использовании тех же ресурсов? Рекоммендуются следующие методологии:
 
+
#:* '''[[Теория ограничений]] Голдратта''' (TOC, theory of constraints) – архитектура должна указывать, какие системные ограничения она снимает на критическом ресурсном пути инженерного проекта (не путать с критическим путём).
Я бы рекомендовал использовать теорию ограничений Голдратта (TOC, theory of constraints) – архитектура должна указывать, какие системные ограничения она снимает на критическом ресурсном пути инженерного проекта (не путать с критическим путём).
+
#:* '''[[ROI]]''' (return on investments) для инвестиций в СУЖЦ на стадии оформления результата содержательного рассмотрения архитектур-кандидатов.
Обратите внимание, ROI (return on investments) не является главным критерием, ибо никто не знает, как содержательно рассмотреть ROI для информационных систем: тут «два эксперта, три мнения». Поэтому оставим оценку ROI для инвестиций в СУЖЦ для стадии оформления результата содержательного рассмотрения архитектур-кандидатов.
+
#: Важно выбрать границы рассмотрения: общая скорость выполнения инжинирингового проекта может быть замерена только на границе рассматриваемой организационной системы. Границы какого-то одного юрлица могут не совпадать с границами расширенного предприятия, осуществляющего масштабный инженерный проект, а участвующее лишь на одной стадии жизненного цикла предприятие может неправильно оценить свою полезность и критичность для полного жизненного цикла системы и неправильно выбрать способ своей интеграции в СУЖЦ. Тогда может выясниться, что создание СУЖЦ не влияет на общие сроки и бюджеты проекта, ибо самые неприятные коллизии продолжат себя являть неадресованные новой СУЖЦ.
 
+
# '''Возможность принятия инкрементального жизненного цикла разработки СУЖЦ'''
Тут важно выбрать границы рассмотрения: общая скорость выполнения инжинирингового проекта ведь может быть замерена только на границе рассматриваемой организационной системы. Границы какого-то одного юрлица тут точно не будут совпадать с границами расширенного предприятия, осуществляющего масштабный инженрный проект, а участвующее лишь на одной стадии жизненного цикла предприятие может неправильно оценить свою полезность и критичность для полного жизненного цикла системы и неправильно выбрать способ своей интеграции в СУЦЖ. Тогда может выясниться, что создание СУЖЦ не влияет на общие сроки и бюджеты проекта, ибо самые неприятные коллизии продолжат себя являть неадресованные новой СУЖЦ. Так что при создании СУЖЦ нужно обязательно разбираться с полным жизненным циклом целевой системы поддерживаемой деятельности и задавать вопрос: кому выгодно устранение тех или иных коллизий? Наверняка ответы будут обескураживающими и потребуют каких-то организационных решений: затраты на создание СУЖЦ будут нести одни участники расширенной организации, а выгоды от исчезновения коллизий будут получать другие.
+
#: Инкрементальным в [[ISO 15288]] называется такой жизненный цикл, при котором функциональность пользователю выдаётся не сразу вся, а постадийно - но и вложения в разработку также происходят не одномоментно, а постадийно. Конечно, при этом нужно учитывать закон убывающей полезности: каждый инкремент СУЖЦ (каждый новый тип обнаруживаемых заранее коллизий) обходится дороже, а пользы от него всё меньше, пока продолжающаяся много лет разработка СУЖЦ не затухнет сама собой. Если выясняется, что для какой-то из предложенных архитектур нужно одномоментно вложить в создание СУЖЦ много денег, но пользу можно будет получить сразу в размере 100% и только через пять лет "под ключ", то это плохая архитектура. Если выясняется, что можно разработать и ввести в эксплуатацию какое-то компактное ядро СУЖЦ, и далее много-много однотипных модулей для разных типов коллизий с понятным механизмом их разработки (например, основанным на использовании [[ISO 15926]]), то это очень хорошо.  
 
+
#: Речь не столько о том, чтобы применять «гибкую разработку» ([[agile]] methodologies), сколько предусмотреть модульную архитектуру СУЖЦ и предложить план реализации приоретизированного списка модулей – сначала самых насущных, затем менее насущных, и т.д.
 
+
#: Не путать с ICM (incremental commitment model), хотя смысл тут такой же: лучше та архитектура, при которой можно получить какую-то рассрочку платежей за систему, а нужную функциональность получать как можно раньше – чтобы пользу получить (хотя бы маленькую) пораньше, а платить за позднюю пользу попозже.
=== 2. Возможность принятия инкрементального жизненного цикла разработки СУЖЦ ===
+
# '''Принципиальная финансовая и интеллектуальная возможность освоить и поддерживать технологию'''
Инкрементальным в ISO 15288 называется такой жизненный цикл, при котором функциональность пользователю выдаётся не сразу вся, а постадийно -- но и вложения в разработку также происходят не одномоментно, а постадийно. Конечно, при этом нужно учитывать закон убывающей полезности: каждый инкремент СУЖЦ (каждый новый тип обнаруживаемых заранее коллизий) обходится всё дороже и дороже, а пользы от него всё меньше и меньше, пока продолжающаяся много лет разработка СУЖЦ не затухнет сама собой. Если выясняется, что для какой-то из предложенных архитектур нужно одномоментно вложить в создание СУЖЦ много денег, но пользу можно будет получить сразу в размере 100% и только через пять лет "под ключ", то это плохая архитектура. Если выясняется, что можно разработать и ввести в эксплуатацию какое-то компактное ядро СУЖЦ, и далее много-много однотипных модулей для разных типов коллизий с понятным механизмом их разработки (например, основанным на использовании ISO 15926), то это очень хорошо.  
+
#: Если посчитать траты не только на собственно СУЖЦ, но и на всю потребную для осуществления проекта кадровую и иную инфраструктуру, то нужно понять, сколько этих вложений в образование, компьютеры и организационные усилия останется плательщику и собственнику СУЖЦ, а сколько осядет вовне – у многочисленных контракторов, которые, конечно, будут благодарны сначала за получение ими «стипендии» на освоение новой технологии, а затем за сопровождение созданной ими системы.
 
+
#: Новое обычно крайне затратно, и не потому что оно само дорого стоит, а потому что вызывает лавину вызываемых им изменений. Именно этот пункт у меня учитывает полную стоимость владения СУЖЦ, и этот же пункт включает рассмотрение полного жизненного цикла уже не инженерной системы с её предотвращаемыми коллизиями, но самой СУЖЦ.
Речь не столько о том, чтобы применять «гибкую разработку» ([[agile]] methodologies), сколько предусмотреть модульную архитектуру СУЖЦ и предложить план реализации приоретизированного списка модулей – сначала самых насущных, затем менее насущных, и т.д.
+
# '''Масштабируемость архитектуры СУЖЦ'''
 
+
#: Этот критерий актуален для крупных инженерных проектов. Поскольку вы хотите, чтобы системой пользовались все тысячи сотрудников расширенной организации, она должна будет быстро расти до этих масштабов. Насколько "пилот" или "полигон" СУЖЦ смогут быстро вырасти без принципиальных архитектурных изменений? Скорее всего, они вырасти не смогут. Поэтому архитектурно нужен не "пилот" или "полигон", а сразу "первая очередь". Требование критерия масштабирования тесно пересекается с требованием критерия инкрементальности, но затрагивает чуть-чуть другой аспект - не столько растяжка создания СУЖЦ по времени, сколько возможность растяжки по накрываемому объему.  
Думайте при этом о том, насколько легче получить небольшой денежный поток для ежедневной закупки новых сот для телефонного оператора, или ежедневной закупки полусотни компьютерных модулей для поискового движка, нежели договориться о высокорисковом вложении во всю инфраструктуру "под ключ" для непонятного объема будущих операций.
+
#: Опыт показывает, что на тестовых объемах проектных данных справляются все системы, а вот на промышленных - не справляются. Как нелинейно будет расти стоимость аппаратуры и программных средств при росте объемов/скорости? Как долго будут отрабатывать регламенты, когда выяснится, что через какое-то рабочее место проходит бОльшее число данных, чем может быть осмысленно просмотрено одним человеком?
 
+
#: Плохая масштабируемость может подстерегать не только с технической стороны архитектуры программно-аппаратного решения, но и со стороны финансовой его архитектуры. Так, небольшая цена на лицензию на каждое рабочее место СУЖЦ, или даже небольшая цена на каждое новое соединение на сервере-репозитарии могут превратить более-менее симпатичное решение для десяти рабочих мест в абсолютно финансово неподъемное для целевой тысячи рабочих мест.
Я тут также не имею ввиду ICM (incremental commitment model), хотя смысл тут такой же: лучше та архитектура, при которой можно получить какую-то рассрочку платежей за систему, а нужную функциональность получать как можно раньше – чтобы пользу получить (хотя бы маленькую) пораньше, а платить за позднюю пользу попозже.
+
# '''Возможность учитывать неизбежные организационные проблемы'''
 
+
#: в том числе отношение к любимым унаследованным (legacy) системам в расширенной организации. Как много предлагаемая централизованная или распределенная архитектура потребует "отдавать функций другим подразделениям", "отдавать наших данных" и вообще чего-то "отдавать" по сравнению с текущей ситуацией без СУЖЦ? Мейнфреймы массово проиграли соревнование мини-компьютерам, а те - персональным. Назад (к централизованным системам, каковой неизбежно представляется СУЖЦ) пути почти нет, ибо все данные лежат в отдельных приложениях, и вытащить эти данные в новые системы представляется сложнейшей организационной задачей. Как устроена архитектура СУЖЦ: она замещает текущие унаследованные инженерные приложения, она надстраивается над текущей IT-инфраструктурой, она устанавливается "задарма" разным службам? Сколько организационных/менеджерских/консультационных усилий потребуется для того, чтобы "пропихнуть" новую технологию? Сколько людей уволить, сколько найти и принять новых специалистов?
Это та же модель "патефона и пластинок", только в ее обратном приложении: дорогущие пластинки лучше покупать по штучке в неделю, чем через год задёшево комплектом в 50 заказанных предварительно штук, и без возможности подкорректировать что-то под стремительно изменяющийся в ходе прослушивания начальных пластинок музыкальный вкус. Приносимая польза тут увеличивается за счёт того, что пластинки начинаем по одной слушать сразу после покупки патефона. Ежели ориентироваться на "сразу полный комплект через год после заказа – иначе технологически мы не можем гарантировать совместимость патефона и всех пластинок", то такой пакет будет прослушан еще только через год после выполнения заказа -- и груда оплаченных пластинок будет долго лежать непрослушанной-неосвоенной и ждать своей очереди (и, скорее всего, так и останется непрослушанной навсегда -- жизнь-то поменяется!).
+
#: Этот критерий организационной приемлемости тесно связан не только с централизацией/децентрализацией, но и с рассмотрением системы мотивации в расширенном предприятии, т.е. оценка архитектуры СУЖЦ по этому критерию далеко выходит за рамки узкого рассмотрения только СУЖЦ, но требует тщательного анализа принципов построения расширенной организации – вплоть до пересмотра принципов, лежащих в основе контрактов, по которым она создана.
 
+
#: Но это и есть суть системного подхода: любая целевая система (в данном случае - СУЖЦ) рассматривается прежде всего не "вглубь, из каких частей", а "наружу, часть чего" - не ее конструкция и механизм работы интересны прежде всего, а поддерживаемая СУЖЦ функция предотвращения коллизий во внешней надсистеме - и цена, которую внешняя надсистема готова платить за эту новую функцию. Поэтому возможные архитектуры СУЖЦ и рассматриваются прежде всего не с точки зрения "приличных используемых технологий, например от поставщика программных средств XYZ" (это по умолчанию: все предлагаемые варианты архитектуры обычно приличны технологически, иначе они не варианты!), а с точки зрения вышеописанных пяти критериев.
 
+
=== 3. Принципиальная финансовая и интеллектуальная возможность освоить и поддерживать технологию ===
+
Думайте об этом как о попытках покупки лимузина для сельской местности -- для поездок от дома до фермы. В стоимость лимузина неожиданно может войти и стоимость строительства (а потом и поддержания) дороги, включая мосты через все местные речки. А если купить для этих же целей самолёт, то нужно будет где-то раздобыть пилотов, механиков и т.д., и затем платить им за жизнь в сельской местности. Хотя я и встречал специалистов по искусственному интеллекту, которые работали в отделе главного сварщика одного завода, но это было давно -- и стоило это заводу не только зарплаты этому специалисту, но и выделения квартиры.
+
 
+
Но если аккуратно посчитать траты не только на собственно СУЖЦ, но и на всю потребную для осуществления проекта кадровую и иную инфраструктуру, то нужно понять, сколько этих вложений в образование, компьютеры и организационные усилия останется плательщику и собственнику СУЖЦ, а сколько осядет вовне – у многочисленных контракторов, которые, конечно, будут благодарны сначала за получение ими «стипендии» на освоение новой технологии, а затем за бесконечно вкусный апельсин многолетнего сопровождения созданной ими системы.
+
Критерий, учитывающий необходимость адекватных затрат, очень коварный. Если его хорошенько раздуть "коэффициентами важности", то экскаватор в отдел землекопов, а также автомобиль в отдел гужевого транспорта никогда не будут заказаны. Новое обычно крайне затратно, и не потому что оно само дорого стоит, а потому что вызывает лавину вызываемых им изменений. Именно этот пункт у меня учитывает полную стоимость владения СУЖЦ, и этот же пункт включает рассмотрение полного жизненного цикла уже не инженерной системы с её предотвращаемыми коллизиями, но самой СУЖЦ.
+
 
+
 
+
=== 4. Масштабируемость архитектуры СУЖЦ ===
+
Этот критерий актуален для крупных инженерных проектов. Поскольку вы хотите, чтобы системой пользовались все тысячи сотруднико расширенной организации, она должна будет быстро расти до этих масштабов. Насколько "пилот" или "полигон" СУЖЦ смогут быстро вырасти без принципиальных архитектурных изменений? Скорее всего, они вырасти не смогут. Поэтому архитектурно нужен не "пилот" или "полигон", а сразу "первая очередь". Требование критерия масштабирования тесно пересекается с требованием критерия инкрементальности, но затрагивает чуть-чуть другой аспект -- не столько растяжка создания СУЖЦ по времени, сколько возможность растяжки по накрываемому объему.  
+
 
+
Опыт показывает, что на тестовых объемах проектных данных справляются все системы, а вот на промышленных -- не справляются. Как нелинейно будет расти стоимость аппаратуры и программных средств при росте объемов/скорости? Как долго будут отрабатывать регламенты, когда выяснится, что через какое-то рабочее место проходит бОльшее число данных, чем может быть осмысленно просмотрено одним человеком?
+
Плохая масштабируемость может подстерегать не только с технической стороны архитектуры программно-аппаратного решения, но и со стороны финансовой его архитектуры. Так, небольшая цена на лицензию на каждое рабочее место СУЖЦ, или даже небольшая цена на каждое новое соединение на сервере-репозитарии могут превратить более-менее симпатичное решение для десяти рабочих мест в абсолютно финансово неподъемное для целевой тысячи рабочих мест.
+
 
+
 
+
=== 5. Возможность учитывать неизбежные организационные проблемы ===
+
в том числе отношение к любимым унаследованным (legacy) системам в расширенной организации. Как много предлагаемая централизованная или распределенная архитектура потребует "отдавать функций другим подразделениям", "отдавать наших данных" и вообще чего-то "отдавать" по сравнению с текущей ситуацией без СУЖЦ? Мейнфреймы, как мы помним, массово проиграли соревнование мини-компьютерам, а те -- персоналкам. Колхозы повсеместно проигрывают личным хозяйствам. Назад (к централизованным системам, каковой неизбежно представляется СУЖЦ) пути почти нет, ибо все данные лежат в отдельных приложениях, и вытащить эти данные в новые системы представляется сложнейшей организационной задачей. Как устроена архитектура СУЖЦ: она замещает текущие унаследованные инженерные приложения, она надстраивается над текущей IT-инфраструктурой, она устанавливается "задарма" разным службам? Сколько организационных/менеджерских/консультационных усилий потребуется для того, чтобы "пропихнуть" новую технологию? Сколько людей уволить, сколько найти и принять новых специалистов?
+
 
+
Этот критерий организационной приемлемости тесно связан не только с централизацией/децентрализацией, но и с рассмотрением системы мотивации в расширенном предприятии, т.е. оценка архитектуры СУЖЦ по этому критерию далеко выходит за рамки узкого рассмотрения только СУЖЦ, но требует тщательного анализа принципов построения расширенной организации – вплоть до пересмотра принципов, лежащих в основе контрактов, по которым она создана.
+
 
+
Но это и есть суть системного подхода: любая целевая система (в данном случае -- СУЖЦ) рассматривается прежде всего не "вглубь, из каких частей", а "наружу, часть чего" -- не ее конструкция и механизм работы интересны прежде всего, а поддерживаемая СУЖЦ функция предотвращения коллизий во внешней надсистеме -- и цена, которую внешняя надсистема готова платить за эту новую функцию. Поэтому возможные архитектуры СУЖЦ и рассматриваются прежде всего не с точки зрения "приличных используемых технологий, например от поставщика программных средств XYZ" (это по умолчанию: все предлагаемые варианты архитектуры обычно приличны технологически, иначе они не варианты!), а с точки зрения описанных вышеописанных пяти критериев.
+
 
+
 
+
== Ссылки ==
+
* [http://ailev.livejournal.com/939303.html функции систем управления жизненным циклом];
+
  
 +
== Функции СУЖЦ ==
 +
# '''Предотвращение коллизий'''
 +
## [[Управление конфигурацией]]
 +
### Идентификация (классификации, кодировки)
 +
### Учёт конфигурации (все возможные baseline - ConOp, Architecture, design, as built), в том числе передача данных в репозиторий СУЖЦ, в том числе поддержка workflow изменений, в том числе поддержка параллельного инжиниринга (работа в условиях неполных baseline)
 +
### Версионирование (включая forks)
 +
## Отсутствие ручного переввода данных (передача входных и выходных данных между уже имеющимися островками автоматизации, включая передачу данных из островков "подъема в цифру" старых проектных наработок)
 +
## Конфигурация НСИ
 +
## Система поддержки коллаборативного инжиниринга (видео-конференции, удаленные проектные сессии и т.д. - возможно, не та, которая используется для создания самой системы СУЖЦ)
 +
# '''Выявление коллизий'''
 +
## Поддержка регистра проверяемых видов коллизий и соответствующих регистру технологий проверки
 +
## Передача данных для проверки коллизий между островками автоматизации (без сборки в репозитории СУЖЦ, но средствами интеграционной технологии СУЖЦ)
 +
## Прогон workflow проверки разных видов коллизий
 +
### в репозитории СУЖЦ
 +
### не в репозитории, но средствами интеграционной технологии СУЖЦ
 +
## Запуск прогона workflow устранения найденной коллизии (рассылка уведомлений о коллизиях, ибо прогон workflow устранения – не забота СУЖЦ)
 +
## Поддержка актуального списка неустранённых коллизий
 +
# '''Развиваемость''' (тут СУЖЦ рассматривается как автопоэтическая система, ибо «инкрементальность реализации» входит в число важнейших свойств самой СУЖЦ -- так что это функция самой СУЖЦ, а не функция обеспечивающей системы для СУЖЦ)
 +
## Обеспечение коммуникации по поводу развития СУЖЦ
 +
### Планирование работ развития СУЖЦ ([[Дорожная карта|roadmap]], разработка плана мероприятий)
 +
### Функционирование проектного офиса СУЖЦ,
 +
### Ведение регистра видов проверок коллизий (сам регистр "хотелок" и [[Дорожная карта|roadmap]] реализации проверок)
 +
### Орг-техническое моделирование ([[EA|Enterprise Architecture]]) для СУЖЦ
 +
### Инфраструктура коммуникации разработчиков СУЖЦ (интернет-конференции, видеосвязь, управление знаниями и т.д. -- возможно, не та, которая используется в ходе коллаборативного инжиниринга с использованием СУЖЦ)
 +
## Единообразность технологии интеграции данных (например, технология [[ISO 15926]])
 +
### Использование нейтральной модели данных
 +
#### Поддержка библиотеки справочных данных
 +
#### Разработка справочных данных
 +
### Технология поддержки адаптеров к нейтральной модели данных
 +
## Единообразность технологии интеграции workflow/[[BPM]] (в масштабах расширенного предприятия)
 +
# '''Безопасность данных''' (в масштабах информационных систем, работающих в рамках СУЖЦ)
 +
## Обеспечение единства доступа (один логин и пароль ко всем информационным системам, участвующим в workflow)
 +
## Управление правами доступа к элементам данных
 +
## Резервное копирование
  
 
[[Категория:Технологии]]
 
[[Категория:Технологии]]
[[Категория:Незавершенные статьи]]
 

Текущая версия на 20:14, 11 февраля 2018

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

«Управление жизненным циклом» сводится к необходимости освоения привычных для системной инженерии практик:

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

СУЖЦ vs PLM

Системная инженерия редко использует понятие «управление жизненным циклом», но это понятие часто используется поставщиками программных систем PLM (Product Life cycle Management).

В России сейчас проходит серия межотраслевых и международных мероприятий (совещаний, конференций и т.д.), где активно используется название "система управления жизненным циклом" (СУЖЦ), вводимое взамен PLM (product lifecycle management). Эта замена термина требует некоторой расшифровки.

Слово "продукт" из PLM в СУЖЦ пропало не случайно, ибо речь идет о сложных инженерных объектах – если вертолёт еще можно с натяжкой назвать «продуктом» в силу его серийности, то атомная станция «продуктом» обычно уже не называется. Поэтому "жизненным циклом" какой именно системы тут «управляется», нужно уточнять в каждом конкретном случае. «Система УЖЦ системы» немного запутывает, но именно это и имеется ввиду.

«Система УЖЦ» — это прежде всего социотехническая система, т.е. она включает не только программные средства PLM, но и организацию людей (практики работы, профессиональные роли, необходимый инструментарий для поддержки этих профессиональных ролей, утвержденные виды жизненного цикла каких-то конкретных рабочих продуктов и т.д.). Поэтому специалисты в слове "система" слышат одно ("информационная система", прежде всего PLM), а менеджеры — совсем другое ("система менеджмента", способ организации работ). Тут еще нужно отметить западную традицию произвольного добавления слова management в сочетаниях «чего-нибудь менеджмент».

По-новому сформулированная СУЖЦ не использует PLM как обязательный класс программных средств, вокруг которого такая система строится. В крупных инженерных проектах обычно используется сразу несколько (чаще всего существенно "недоосвоенных") PLM разных вендоров, и при создании СУЖЦ речь идёт обычно уже об их межорганизационной интеграции. Конечно, при этом решаются и вопросы, как интегрировать в СУЖЦ информацию и тех систем, которые еще не имеют связи с какой-то из PLM систем расширенного предприятия. Термином «расширенное предприятие» (extended enterprise) обычно называют созданную посредством системы контрактов организацию из ресурсов (людей, инструментов, материалов) участвующих в конкретном инженерном проекте различных юридических лиц. В расширенных предприятиях ответ на вопрос, в какую именно PLM интегрируются данные какой именно из систем CAD/CAM/ERP/EAM/CRM/и т.д.. становится нетривиальным: владельцам разных предприятий не предпишешь использовать программные средства одного поставщика.

А поскольку PLM-система всё-таки являтся программными средствами, а "система управления" из СУЖЦ явно понимается в том числе как "система менеджмента", то термин СУЖЦ подразумевает явно и организационный аспект, а не только аспект информационных технологий. Тем самым фраза "использование PLM для поддержки системы управления жизненным циклом" вполне осмыслена, хотя может запутывать при дословном переводе в ней “PLM” на русский.

Тем не менее, понимание "системы управления жизненным циклом", когда ею занимаются специалисты из IT-служб, немедленно нивелируется назад к "только софту", подозрительно напоминающему программные средства PLM. И после этого переупрощения начинаются трудности: «коробочная» система PLM от какого-то поставщика программных средств автоматизации проектирования обычно сразу представляется конструктивно, как набор программных модулей из каталога этого поставщика, вне связи с поддерживаемыми инженерными и менеджмерскими функциями, и рассматривается как тройка из следующих компонент:

  • датацентрический репозиторий данных жизненного цикла,
  • «система документооборота» (workflow engine) для поддержки «управления»,
  • «портал» для просмотра содержимого репозитория и состояния документооборота.

Назначение СУЖЦ

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

Главная идея любой современной СУЖЦ - это использование аккуратного и непротиворечивого представления системы и окружающего её мира в неизбежно разнородных и изначально несовместимых между собой компьютерных системах расширенной организации. Использование виртуальных макетов, информационных моделей, датацентрических репозиториев проектной информации обеспечивает выявление коллизий при "сооружении в компьютере", "виртуальной сборке", а не при выносе чертежей и других моделей проекта в материальную реальность в ходе действительного сооружения «в металле и бетоне» и пуска в эксплуатацию.

Идея СУЖЦ не имеет тем самым отношения к разнообразным «автоматизациям проектирования», прежде всего – к «порождающему проектированию» (generative design) и «порождающему производству» (generative manufacturing). СУЖЦ озабочена более не синтезом, а анализом: обнаруживает и/или предотвращает коллизии в результатах проектирования отдельных подсистем, когда их будут собирать вместе по самым разным технологиям:

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

Моделеориентированный подход

Использование СУЖЦ подразумевает отказ не только от бумаги в проектировании, но и от "электронной бумаги" (.tiff или других растровых форматов) и переход к датацентрическому представлению информации. Сравнить две модели, существующие на бумаге в каких-то нотациях и найти в них несоответствия много сложнее и дольше, нежели предотвращать коллизии в структурированных электронных документах, использующих не растровую графику, а инженерные модели данных.

Модель данных может быть разработана в соответствии с каким-то языком, например:

  • в терминах стандарта описания метода разработки ISO 24744),
  • метамодель (в терминах консорциума стандартизации OMG),
  • модель данных/справочные данные (в терминах стандарта интеграции данных жизненного цикла ISO 15926).

Именно такой переход к структурно представляемым моделям, существующим уже на ранних стадиях проектирования и называется «Системной инженерией на основе моделей» (MBSE, model-based systems engineering). Снимать коллизии при помощи компьютерной обработки данных становится возможным уже на самых ранних стадиях жизненного цикла, еще до появления полноценных 3D моделей конструкции.

СУЖЦ должна:

  • обеспечивать механизм передачи данных из одного приложения CAD/CAM/ERP/PM/EAM/и т.д. в другое – причем в электронном структурированном виде, а не в виде «пачки электронной бумаги». Передача данных из одной инженерной информационной системы (с четким пониманием откуда, куда, когда, что, зачем, как) - это часть обеспечиваемой СУЖЦ функциональности. Тем самым СУЖЦ должна поддерживать workflow (ход работ, который частично выполняется людьми, а частично компьютерными системами).
  • контролировать версии, то есть предоставлять функцию управления конфигурацией - как моделей, так и физических частей системы. СУЖЦ поддерживает таксономию требований разного уровня и предоставляет средства для проверки коллизии разноуровневых проектных решений и их обоснований с этими требованиями. В ходе инженерной разработки любое описание системы, любая её модель изменяются и дополняются многократно, и существуют поэтому во множестве альтернативных версий разной степени правильности, и в разной мере соответствующих друг другу. СУЖЦ должна гарантировать, что для текущей работы используется только правильное сочетание этих версий.

Архитектура СУЖЦ

Архитектурных решений для СУЖЦ может быть множество, одна и та же функция может быть поддержана различными конструкциями и механизмами работы. Можно выделить три вида архитектуры:

  1. Традиционные попытки создать СУЖЦ – это обеспечить важнейшие передачи данных по принципу "точка-точка" между разными приложениями. При этом может быть использована какая-нибудь специализированная система поддержки workflow (BPM engine, «движок управления бизнес-процессами»), или система обработки событий (complex event processing engine). К сожалению, объем работы по обеспечению обменов «точка-точка» оказывается просто грандиозным: каждый раз требуются специалисты, разобравшиеся в обоих связываемых системах и методе передаче информации.
  2. Использование стандарта интеграции данных ЖЦ ISO 15926 по методу «ISO 15926 outside», когда для каждого инженерного приложения разрабатывается адаптор в нейтральное представление, соответствующее стандарту. Тем самым, все данные получают возможность встретиться в каком-то приложении и коллизия между ними может быть обнаружена – но для приложения требуется разработать лишь один адаптер передачи данных, а не несколько таких адаптеров (по числу других приложений, с которыми нужно обеспечить связь).
  3. PLM (Teamcenter, ENOVIA, SPF, NET Platform и т.д.) - используется стандартизованная архитектура, за тем лишь исключением, что используемая в каждой из этих PLM модель данных менее универсальна в плане отражения любой предметной области инжиниринга, а также не является нейтральным и доступным всем форматом. Так что использование ISO 15926 в качестве базового представления при передаче данных в СУЖЦ можно считать дальнейшим развитием идей, по факту реализованных в современных PLM.

По архитектуре управления конфигурацией, СУЖЦ можно разделить на три вида:

  • «репозиторий» (актуальное хранение всех данных проекта в одном репозитории СУЖЦ, куда копируются данные оттуда, где они были разработаны),
  • «регистр» (СУЖЦ поддерживает список адресов данных жизненного цикла в многочисленных репозиториях других САПР, систем инженерного моделирования, PLM, ERP и т.д.),
  • «гибридная архитектура» -- когда часть данных копируется в центральный репозиторий СУЖЦ, а часть данных доступна из других мест по ссылкам.

Архитектора СУЖЦ должна также описывать:

  • «портал» (в том числе «веб-портал»), его функциях и способ реализации. Само наличие портала позволяет успокоить топ-менеджеров демонстрируя отсутствие коллизий. К архитектурным решениям по «порталу СУЖЦ» предъявляются специфические требования.
  • алгоритмы проверки целостности/непротиворечивости данных жизненного цикла, а также описание работы этих алгоритмов:
    • стандартный модуль в отдельном приложении, работающий над данными в репозитории этого приложения – будь это САПР или PLM;
    • специально разработанное для СУЖЦ программное средство проверки коллизий, имеющее доступ к данным разных приложений, находящихся в центральном репозитории СУЖЦ;
    • специально разработанное программное средство, обращающееся через интернет по защищенному каналу к разным хранилищам данных, находящимся в разных организациях;
    • специально запрограммированные проверки с контролем коллизий при загрузке разных инженерных наборов данных в центральный репозиторий СУЖЦ;
    • комбинация из всех перечисленных методов – разных для разных типов коллизий; и т.д.
  • способ взаимодействия пользователей СУЖЦ (инженеров-проектантов, закупщиков, монтажников, менеджеров проекта сооружения и т.д.), и как именно программное обеспечение СУЖЦ поддерживает это взаимодействие способом, предотвращающим появление коллизий. Стандарты системной инженерии (в частности, стандарт практик системной инженерии ISO 15288) требуют выбора вида жизненного цикла для инженерии сложных объектов и указания того, какие варианты практик системной инженерии будут использованы. Модель жизненного цикла является одним из основных артефактов, которые служат для организационных договоренностей по координации работ расширенной организации инженерного проекта. Скоординированные работы в ходе коллаборативной разработки (collaborative engineering) – это залог малого числа проектных коллизий. Как именно поддержит модель жизненного цикла СУЖЦ? Так, системы PLM обычно не находят место моделям жизненного цикла, и уж тем более моделям организации. Поэтому для СУЖЦ нужно искать другие решения по программной поддержке этих моделей.
  • Организационный аспект перехода к использованию СУЖЦ. Переход к использованию СУЖЦ может вызвать существенное изменение в структуре и даже кадровом составе инжиниринговой компании: не всех землекопов берут в экскаваторщики, не всех извозчиков берут в таксисты.

Главное для СУЖЦ – насколько предлагаемое решение способствует раннему обнаружению, а то и предотвращению коллизий. Ежели речь заходит о чём-то другом (содержательный выбор вида жизненного цикла в соответствии с профилем риска проекта, управление старением, управление стоимостью и реформа сметной системы, освоение axiomatic design, сооружение с поставками «точно вовремя», порождающее проектирование и сооружение, а также многое-многое другое, также крайне полезное-современное-интересное), то это вопрос других систем, других проектов, других методов, других подходов. СУЖЦ должна хорошо делать своё дело, а не плохо решать огромный набор произвольно выбираемых чужих задач.

У архитектора СУЖЦ тем самым две основные задачи:

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

Критерии выбора архитектурного решения для СУЖЦ

  1. Качество выполнения СУЖЦ своего основного предназначения: обнаружения и предотвращения коллизий
    Главный критерий: насколько может быть ускорен ход инженерных работ за счёт ускорения обнаружения или предотвращения коллизий при использовании предлагаемой архитектуры СУЖЦ? А если время работ не может быть сокращено, то насколько за то же время можно увеличить объем работ при использовании тех же ресурсов? Рекоммендуются следующие методологии:
    • Теория ограничений Голдратта (TOC, theory of constraints) – архитектура должна указывать, какие системные ограничения она снимает на критическом ресурсном пути инженерного проекта (не путать с критическим путём).
    • ROI (return on investments) для инвестиций в СУЖЦ на стадии оформления результата содержательного рассмотрения архитектур-кандидатов.
    Важно выбрать границы рассмотрения: общая скорость выполнения инжинирингового проекта может быть замерена только на границе рассматриваемой организационной системы. Границы какого-то одного юрлица могут не совпадать с границами расширенного предприятия, осуществляющего масштабный инженерный проект, а участвующее лишь на одной стадии жизненного цикла предприятие может неправильно оценить свою полезность и критичность для полного жизненного цикла системы и неправильно выбрать способ своей интеграции в СУЖЦ. Тогда может выясниться, что создание СУЖЦ не влияет на общие сроки и бюджеты проекта, ибо самые неприятные коллизии продолжат себя являть неадресованные новой СУЖЦ.
  2. Возможность принятия инкрементального жизненного цикла разработки СУЖЦ
    Инкрементальным в ISO 15288 называется такой жизненный цикл, при котором функциональность пользователю выдаётся не сразу вся, а постадийно - но и вложения в разработку также происходят не одномоментно, а постадийно. Конечно, при этом нужно учитывать закон убывающей полезности: каждый инкремент СУЖЦ (каждый новый тип обнаруживаемых заранее коллизий) обходится дороже, а пользы от него всё меньше, пока продолжающаяся много лет разработка СУЖЦ не затухнет сама собой. Если выясняется, что для какой-то из предложенных архитектур нужно одномоментно вложить в создание СУЖЦ много денег, но пользу можно будет получить сразу в размере 100% и только через пять лет "под ключ", то это плохая архитектура. Если выясняется, что можно разработать и ввести в эксплуатацию какое-то компактное ядро СУЖЦ, и далее много-много однотипных модулей для разных типов коллизий с понятным механизмом их разработки (например, основанным на использовании ISO 15926), то это очень хорошо.
    Речь не столько о том, чтобы применять «гибкую разработку» (agile methodologies), сколько предусмотреть модульную архитектуру СУЖЦ и предложить план реализации приоретизированного списка модулей – сначала самых насущных, затем менее насущных, и т.д.
    Не путать с ICM (incremental commitment model), хотя смысл тут такой же: лучше та архитектура, при которой можно получить какую-то рассрочку платежей за систему, а нужную функциональность получать как можно раньше – чтобы пользу получить (хотя бы маленькую) пораньше, а платить за позднюю пользу попозже.
  3. Принципиальная финансовая и интеллектуальная возможность освоить и поддерживать технологию
    Если посчитать траты не только на собственно СУЖЦ, но и на всю потребную для осуществления проекта кадровую и иную инфраструктуру, то нужно понять, сколько этих вложений в образование, компьютеры и организационные усилия останется плательщику и собственнику СУЖЦ, а сколько осядет вовне – у многочисленных контракторов, которые, конечно, будут благодарны сначала за получение ими «стипендии» на освоение новой технологии, а затем за сопровождение созданной ими системы.
    Новое обычно крайне затратно, и не потому что оно само дорого стоит, а потому что вызывает лавину вызываемых им изменений. Именно этот пункт у меня учитывает полную стоимость владения СУЖЦ, и этот же пункт включает рассмотрение полного жизненного цикла уже не инженерной системы с её предотвращаемыми коллизиями, но самой СУЖЦ.
  4. Масштабируемость архитектуры СУЖЦ
    Этот критерий актуален для крупных инженерных проектов. Поскольку вы хотите, чтобы системой пользовались все тысячи сотрудников расширенной организации, она должна будет быстро расти до этих масштабов. Насколько "пилот" или "полигон" СУЖЦ смогут быстро вырасти без принципиальных архитектурных изменений? Скорее всего, они вырасти не смогут. Поэтому архитектурно нужен не "пилот" или "полигон", а сразу "первая очередь". Требование критерия масштабирования тесно пересекается с требованием критерия инкрементальности, но затрагивает чуть-чуть другой аспект - не столько растяжка создания СУЖЦ по времени, сколько возможность растяжки по накрываемому объему.
    Опыт показывает, что на тестовых объемах проектных данных справляются все системы, а вот на промышленных - не справляются. Как нелинейно будет расти стоимость аппаратуры и программных средств при росте объемов/скорости? Как долго будут отрабатывать регламенты, когда выяснится, что через какое-то рабочее место проходит бОльшее число данных, чем может быть осмысленно просмотрено одним человеком?
    Плохая масштабируемость может подстерегать не только с технической стороны архитектуры программно-аппаратного решения, но и со стороны финансовой его архитектуры. Так, небольшая цена на лицензию на каждое рабочее место СУЖЦ, или даже небольшая цена на каждое новое соединение на сервере-репозитарии могут превратить более-менее симпатичное решение для десяти рабочих мест в абсолютно финансово неподъемное для целевой тысячи рабочих мест.
  5. Возможность учитывать неизбежные организационные проблемы
    в том числе отношение к любимым унаследованным (legacy) системам в расширенной организации. Как много предлагаемая централизованная или распределенная архитектура потребует "отдавать функций другим подразделениям", "отдавать наших данных" и вообще чего-то "отдавать" по сравнению с текущей ситуацией без СУЖЦ? Мейнфреймы массово проиграли соревнование мини-компьютерам, а те - персональным. Назад (к централизованным системам, каковой неизбежно представляется СУЖЦ) пути почти нет, ибо все данные лежат в отдельных приложениях, и вытащить эти данные в новые системы представляется сложнейшей организационной задачей. Как устроена архитектура СУЖЦ: она замещает текущие унаследованные инженерные приложения, она надстраивается над текущей IT-инфраструктурой, она устанавливается "задарма" разным службам? Сколько организационных/менеджерских/консультационных усилий потребуется для того, чтобы "пропихнуть" новую технологию? Сколько людей уволить, сколько найти и принять новых специалистов?
    Этот критерий организационной приемлемости тесно связан не только с централизацией/децентрализацией, но и с рассмотрением системы мотивации в расширенном предприятии, т.е. оценка архитектуры СУЖЦ по этому критерию далеко выходит за рамки узкого рассмотрения только СУЖЦ, но требует тщательного анализа принципов построения расширенной организации – вплоть до пересмотра принципов, лежащих в основе контрактов, по которым она создана.
    Но это и есть суть системного подхода: любая целевая система (в данном случае - СУЖЦ) рассматривается прежде всего не "вглубь, из каких частей", а "наружу, часть чего" - не ее конструкция и механизм работы интересны прежде всего, а поддерживаемая СУЖЦ функция предотвращения коллизий во внешней надсистеме - и цена, которую внешняя надсистема готова платить за эту новую функцию. Поэтому возможные архитектуры СУЖЦ и рассматриваются прежде всего не с точки зрения "приличных используемых технологий, например от поставщика программных средств XYZ" (это по умолчанию: все предлагаемые варианты архитектуры обычно приличны технологически, иначе они не варианты!), а с точки зрения вышеописанных пяти критериев.

Функции СУЖЦ

  1. Предотвращение коллизий
    1. Управление конфигурацией
      1. Идентификация (классификации, кодировки)
      2. Учёт конфигурации (все возможные baseline - ConOp, Architecture, design, as built), в том числе передача данных в репозиторий СУЖЦ, в том числе поддержка workflow изменений, в том числе поддержка параллельного инжиниринга (работа в условиях неполных baseline)
      3. Версионирование (включая forks)
    2. Отсутствие ручного переввода данных (передача входных и выходных данных между уже имеющимися островками автоматизации, включая передачу данных из островков "подъема в цифру" старых проектных наработок)
    3. Конфигурация НСИ
    4. Система поддержки коллаборативного инжиниринга (видео-конференции, удаленные проектные сессии и т.д. - возможно, не та, которая используется для создания самой системы СУЖЦ)
  2. Выявление коллизий
    1. Поддержка регистра проверяемых видов коллизий и соответствующих регистру технологий проверки
    2. Передача данных для проверки коллизий между островками автоматизации (без сборки в репозитории СУЖЦ, но средствами интеграционной технологии СУЖЦ)
    3. Прогон workflow проверки разных видов коллизий
      1. в репозитории СУЖЦ
      2. не в репозитории, но средствами интеграционной технологии СУЖЦ
    4. Запуск прогона workflow устранения найденной коллизии (рассылка уведомлений о коллизиях, ибо прогон workflow устранения – не забота СУЖЦ)
    5. Поддержка актуального списка неустранённых коллизий
  3. Развиваемость (тут СУЖЦ рассматривается как автопоэтическая система, ибо «инкрементальность реализации» входит в число важнейших свойств самой СУЖЦ -- так что это функция самой СУЖЦ, а не функция обеспечивающей системы для СУЖЦ)
    1. Обеспечение коммуникации по поводу развития СУЖЦ
      1. Планирование работ развития СУЖЦ (roadmap, разработка плана мероприятий)
      2. Функционирование проектного офиса СУЖЦ,
      3. Ведение регистра видов проверок коллизий (сам регистр "хотелок" и roadmap реализации проверок)
      4. Орг-техническое моделирование (Enterprise Architecture) для СУЖЦ
      5. Инфраструктура коммуникации разработчиков СУЖЦ (интернет-конференции, видеосвязь, управление знаниями и т.д. -- возможно, не та, которая используется в ходе коллаборативного инжиниринга с использованием СУЖЦ)
    2. Единообразность технологии интеграции данных (например, технология ISO 15926)
      1. Использование нейтральной модели данных
        1. Поддержка библиотеки справочных данных
        2. Разработка справочных данных
      2. Технология поддержки адаптеров к нейтральной модели данных
    3. Единообразность технологии интеграции workflow/BPM (в масштабах расширенного предприятия)
  4. Безопасность данных (в масштабах информационных систем, работающих в рамках СУЖЦ)
    1. Обеспечение единства доступа (один логин и пароль ко всем информационным системам, участвующим в workflow)
    2. Управление правами доступа к элементам данных
    3. Резервное копирование