Назначение системы управления жизненным циклом
[UPDATE: переработанная и дополненная версия этого текста находится в http://ailev.livejournal.com/929655.html ]
Росатом сейчас проводит серию межотраслевых мероприятий (совещаний, конференций и т.д.), где насаждается название "система управления жизненным циклом" (СУЖЦ), вводимое взамен PLM (product lifecycle management). Это название требует некоторой расшифровки:
-- слово "продукт" пропало не случайно, ибо в головах у людей что-то очень большое (чаще всего -- "капитальные объекты", типа "объект атомной энергетики" или "оффшорной ледовой буровой платформы"), или даже сервисы. Поэтому "жизненным циклом" чего именно, нужно уточнять в каждом конкретном применении (особо заметим, что "система УЖЦ системы" -- это явный перебор, но именно это и имеется ввиду).
-- "система" тут становится социотехнической, т.е. включает не только софт a la PLM, но и организацию вокруг этого софта (практики работы, роли, разный инструментарий для этих ролей, виды жизненного цикла каких-то конкретных рабочих продуктов и т.д.). Поэтому айтишники в слове "система" слышат одно ("информационная система"), а менеджеры -- совсем другое ("система менеджмента").
-- выкидывание из формулировки PLM-как-класса-программных-средств намеренно, ибо в очень крупных проектах используется сразу несколько таких (чаще всего существенно "недоосвоенных") PLM разных вендоров, и речь идёт об их интеграции, плюс разбирательстве, в какие конкретно PLM-системы втыкать еще невоткнутые CAD/CAM/ERP/EAM/CRM/и т.д.. Ну, и PLM всё-таки софт, а "система управления" похожа на "систему менеджмента", то есть что-то про людей. Так что "PLM для поддержки системы управления жизненным циклом" -- фраза осмысленная (с точностью до понимания "управления" в словосочетаниях "чего-нибудь менеджмент", http://ailev.livejournal.com/632128.html), хотя и безумна при дословном переводе PLM на русский.
Тем не менее, "система управления жизненным циклом", когда ею занимаются айтишники, немедленно нивелируется назад к "только софту", подозрительно напоминающему софт PLM. Дальше начинаются трудности: PLM обычно сразу представляется конструктивно (вне связи с функциями, т.е. не архитектурно) как "репозиторий+workflow engine" (репозиторий для "жизненного цикла", а workflow engine, очевидно, для "управления" -- что бы под ним ни понималось). Дальше люди начинают сочинять, для чего бы им была нужна такая система: какие могли бы быть функции такой системы. И тут включаются менеджеры, разворачивая из слов "жизненный цикл" каждый свою хотелку: про важность заглядывания в конец жизненного цикла (предусмотреть стадию вывода из эксплуатации), управления старением (предусмотреть увеличение длительности стадии эксплуатации), обеспечение коллаборативного проектирования (collaborative design, но мало кто вообще это поминает сейчас: эта мода в Россию придёт только через пару лет), а изредка горячие головы говорят и об "управлении конфигурацией", подразумевая "управление изменениями", а некоторым важно только использование PLM при переходе от CAD к CAM (чтобы не через бумажный архив).
В результате за десятью функциональными зайцами сразу погнавшиеся менеджеры напрочь сбивают мушку айтишникам-спецам-по-CAD/CAM/PLM, а инженеры на этом празднике жизни остаются в стороне. И проекты с "внедрением PLM" загибаются от этого в количестве.
Я настаиваю, что на текущей стадии развития информационных технологий системы управления жизненным циклом вводятся только для одной главной цели, реализуют только одну главную функцию, поддерживают только один главный сценарий (use case), имеют одно главное назначение: СУЖЦ предотвращают коллизии, неизбежные при коллаборативной разработке.
Коллизии -- это противоречия (несоответствия) одних частей целевой системы другим. Противоречия неизбежно появляются при коллаборативной разработке, ибо разные участники разработки целевой системы действуют в ситуации неполной информации как о целевой системе и ее текущем (или прогнозируемом далее по жизненному циклу) состоянии, так и о действиях и целях друг друга, так и об ожиданиях пользователей и систем в операционном окружении уже развёрнутой для эксплуатации системы. Коллизии могут найтись на любой стадии жизненного цикла системы:
-- на стадии замысла оценки стоимости могут не соответствовать текущей предполагаемой конструкции, а реализуемые функции противоречить user needs
-- на стадии разработки проектируемая деталь может не соответствовать типам деталей из промышленного каталога, или даже быть пропущенной на части чертежей, или занимать то же самое место, что и какая-то другая деталь (ибо все эти детали размещаются на разных чертежах разными людьми, часто в разных организациях),
-- на стадии строительства деталь может оказаться не закуплена, или закуплена неправильная, или установлена на не своё место, или опора не выдержит нагрузки.
-- на стадии эксплуатации может оказаться, что забыли дверь (это не шутка: один из классических примеров -- это строительство почтамта, в котором въезд для грузовиков с почтой был невозможен: забыли узнать, какой высоты эти грузовики, и они просто не могли проехать для погрузки-разгрузки -- были слишком большие для оставленной им въездной дырочки в железобетонной конструкции).
Чем позже будет обнаружена коллизия, тем дороже её исправление -- проще всего исправить информацию в файле, чуть труднее исправить подписанную десятком человек бумагу, совсем трудно исправить пятисоттонную железобетонную конструкцию. Поэтому суть системной инженерии -- "сначала подумать, потом сделать". Ошибку в мыслях (если мысли представить в виде данных) легче исправить, чем ошибку в действиях с реальным материалом.
Главная идея СУЖЦ -- это использование аккуратного представления системы и окружающего её мира в компьютерных системах (виртуальные модели, информационные модели, виртуальные макеты и т.д.), чтобы противоречия были выявлены при "компьютерном строительстве", "виртуальной сборке", а не при выносе чертежей и других моделей в реальность при сооружении.
Нужно отметить, что СУЖЦ не имеет тем самым отношения к generative design (http://ailev.livejournal.com/834653.html), разве что позволяет находить коллизии результатов этого и разных других видов проектирований, когда их будут собирать вместе (что бы ни означало это слово "собирать" -- сливать данные вместе, запускать алгоритм проверки целостности для распределенных данных, проводить актуальную "виртуальную сборку" и имитационное моделирование для результата -- это всё нужно обсуждать отдельно, ибо это относится к "конструкции", а мы сейчас обсуждаем функцию, назначение СУЖЦ).
"Предотвращение коллизий" подразумевает, в частности:
1. Отказ не только от бумаги, но и от "электронной бумаги". Сравнить две модели, существующие на бумаге в каких-то нотациях и найти в них несоответствия много сложнее и дольше, нежели предотвращать коллизии в структурированных электронных документах, с моделями (моделеориентированность). Две диаграммы-описания, нарисованные "от руки" по неминуемо произвольным правилам (даже если они хранятся в электронной форме) много сложнее сравнить и проанализировать совместно, ежели они не придерживаются каких-то соглашений о кодировании реальности, какой-то модели данных жизненного цикла. Когда я пишу "модель", я имею ввиду чаще всего модель, разработанную в соответствии с каким-то языком (в терминах ISO 24744), или метамоделью (в терминах OMG), или моделью данных/справочными данными (в терминах ISO 15926). Это про моделеориентированность. Сюда же -- отказ от "железа и бетона" (например, штрих-коды или RFID позволяют работать не просто с каждой железякой или каменюкой в их физическом воплощении, но сразу переходить к её описаниям). СУЖЦ должна работать в настоящем моделеориентированном подходе.
2. Поддержание принципа "одно значение вводится руками один раз": всё остальное делается копированием данных из приложения в приложении. При любом "перевводе" информация может исказиться, кроме того при "перевводе" человеческие усилия экономятся и перевбивается не вся нужная информация, а только самая-самая необходимая -- и тем самым часто пропадает осмысленный контекст, в котором можно было бы легко обнаружить ошибки. СУЖЦ должна обеспечивать механизм передачи данных из одного приложения CAD/CAM/ERP/PM/EAM/и т.д. в другое в электронном структурированном виде. Передача данных (откуда, куда, когда, что) -- это часть обеспечиваемого СУЖЦ workflow.
3. Во время инженерии любое описание, любая модель изменяются многократно, и существуют поэтому во множестве альтернативных версий разной степени правильности, и в разной мере соответствующих друг другу. СУЖЦ должна следить за "одной версией правды", то есть предоставлять функцию управления конфигурацией -- как моделей, так и физических частей системы. Управление конфигурацией -- это прежде всего отслеживание изменений версий, т.е. отслеживание действий проектировщиков и уведомление их о том, что что-то изменилось -- то есть это тоже часть обеспечиваемого СУЖЦ workflow.
Обращу особое внимание, что мы тут никак не коснулись архитектуры (т.е. того, как "конструкция" СУЖЦ поддерживает заявленную функцию предотвращения коллизий):
-- реализуется ли она как обеспечение передач данных "точка-точка" между разными приложениями (например, какая-нибудь из BPM engine или complex event processing engine + ISO 15926 outside для множества САПР)
-- реализуется ли она как PLM какого-то конкретного поставщика (Teamcenter, ENOVIA, SPF, NET Platform и т.д.)
-- есть там какой-то "портал", обязательно ли это "веб-портал"
-- есть ли там репозиторий, или это "распределенный репозиторий", составленный из репозиториев отдельных приложений и registry (разница между repository и registry архитектурами: в первые копируются и там хранятся актуальные данные, а во вторых поддерживается набор ссылок в другие хранилища данных, и никакие данные не копируются в одно хранилище)
-- работают ли какие-то отдельные "проверки целостности/непротиворечивости", и как они устроены (отдельным алгоритмом в отдельном приложении над отдельными данными, отдельным алгоритмом над репозиторием, отдельным алгоритмом, обращающимся по сети к разным хранилищам данных, алгоритмом слияния разных моделей в одну с контролем ошибок и т.д.).
-- как же всё-таки связаны инженеры-проектировщики, монтажники, закупщики и т.д. и сотф СУЖЦ (ибо workflow по традиции определяется как проходящий через людей и компьютеры)
-- где там "модель жизненного цикла" (какой артефакт ей соответствует), о которой так любят поговорить.
-- переход к каким методам работы инжиниринговой компании подразумевает СУЖЦ (ибо переход с лопат на экскаваторы, или с телег на грузовики может быть для организации чуть бОльшим шоком, чем об этом думают менеджеры, в глаза не видевшие ни одной лопаты или экскаватора, телеги или грузовика).
Но на эти архитектурные вопросы можно как-то искать ответы, если помнить: главное для СУЖЦ -- это предотвращение коллизий. Ежели речь заходит о чём-то другом (выбор вида жизненного цикла, управление старением, управление стоимостью, освоение axiomatic design, сооружение с поставками just-in-time, generative design и generative manufacturing, и многое-многое другое, также крайне полезное-современное-интересное), то это вопрос других систем, других проектов, других методов, других подходов. Keep focus.
И только после того, как будут отвечены эти архитектурные вопросы, можно будет сказать, какого уровня интеллектуальности вы делаете софтовую часть СУЖЦ (http://ailev.livejournal.com/878210.html). Текущие варианты (в их PLM-инкарнациях) сводятся пока к уровню 1.
Росатом сейчас проводит серию межотраслевых мероприятий (совещаний, конференций и т.д.), где насаждается название "система управления жизненным циклом" (СУЖЦ), вводимое взамен PLM (product lifecycle management). Это название требует некоторой расшифровки:
-- слово "продукт" пропало не случайно, ибо в головах у людей что-то очень большое (чаще всего -- "капитальные объекты", типа "объект атомной энергетики" или "оффшорной ледовой буровой платформы"), или даже сервисы. Поэтому "жизненным циклом" чего именно, нужно уточнять в каждом конкретном применении (особо заметим, что "система УЖЦ системы" -- это явный перебор, но именно это и имеется ввиду).
-- "система" тут становится социотехнической, т.е. включает не только софт a la PLM, но и организацию вокруг этого софта (практики работы, роли, разный инструментарий для этих ролей, виды жизненного цикла каких-то конкретных рабочих продуктов и т.д.). Поэтому айтишники в слове "система" слышат одно ("информационная система"), а менеджеры -- совсем другое ("система менеджмента").
-- выкидывание из формулировки PLM-как-класса-программных-средств намеренно, ибо в очень крупных проектах используется сразу несколько таких (чаще всего существенно "недоосвоенных") PLM разных вендоров, и речь идёт об их интеграции, плюс разбирательстве, в какие конкретно PLM-системы втыкать еще невоткнутые CAD/CAM/ERP/EAM/CRM/и т.д.. Ну, и PLM всё-таки софт, а "система управления" похожа на "систему менеджмента", то есть что-то про людей. Так что "PLM для поддержки системы управления жизненным циклом" -- фраза осмысленная (с точностью до понимания "управления" в словосочетаниях "чего-нибудь менеджмент", http://ailev.livejournal.com/632128.html), хотя и безумна при дословном переводе PLM на русский.
Тем не менее, "система управления жизненным циклом", когда ею занимаются айтишники, немедленно нивелируется назад к "только софту", подозрительно напоминающему софт PLM. Дальше начинаются трудности: PLM обычно сразу представляется конструктивно (вне связи с функциями, т.е. не архитектурно) как "репозиторий+workflow engine" (репозиторий для "жизненного цикла", а workflow engine, очевидно, для "управления" -- что бы под ним ни понималось). Дальше люди начинают сочинять, для чего бы им была нужна такая система: какие могли бы быть функции такой системы. И тут включаются менеджеры, разворачивая из слов "жизненный цикл" каждый свою хотелку: про важность заглядывания в конец жизненного цикла (предусмотреть стадию вывода из эксплуатации), управления старением (предусмотреть увеличение длительности стадии эксплуатации), обеспечение коллаборативного проектирования (collaborative design, но мало кто вообще это поминает сейчас: эта мода в Россию придёт только через пару лет), а изредка горячие головы говорят и об "управлении конфигурацией", подразумевая "управление изменениями", а некоторым важно только использование PLM при переходе от CAD к CAM (чтобы не через бумажный архив).
В результате за десятью функциональными зайцами сразу погнавшиеся менеджеры напрочь сбивают мушку айтишникам-спецам-по-CAD/CAM/PLM, а инженеры на этом празднике жизни остаются в стороне. И проекты с "внедрением PLM" загибаются от этого в количестве.
Я настаиваю, что на текущей стадии развития информационных технологий системы управления жизненным циклом вводятся только для одной главной цели, реализуют только одну главную функцию, поддерживают только один главный сценарий (use case), имеют одно главное назначение: СУЖЦ предотвращают коллизии, неизбежные при коллаборативной разработке.
Коллизии -- это противоречия (несоответствия) одних частей целевой системы другим. Противоречия неизбежно появляются при коллаборативной разработке, ибо разные участники разработки целевой системы действуют в ситуации неполной информации как о целевой системе и ее текущем (или прогнозируемом далее по жизненному циклу) состоянии, так и о действиях и целях друг друга, так и об ожиданиях пользователей и систем в операционном окружении уже развёрнутой для эксплуатации системы. Коллизии могут найтись на любой стадии жизненного цикла системы:
-- на стадии замысла оценки стоимости могут не соответствовать текущей предполагаемой конструкции, а реализуемые функции противоречить user needs
-- на стадии разработки проектируемая деталь может не соответствовать типам деталей из промышленного каталога, или даже быть пропущенной на части чертежей, или занимать то же самое место, что и какая-то другая деталь (ибо все эти детали размещаются на разных чертежах разными людьми, часто в разных организациях),
-- на стадии строительства деталь может оказаться не закуплена, или закуплена неправильная, или установлена на не своё место, или опора не выдержит нагрузки.
-- на стадии эксплуатации может оказаться, что забыли дверь (это не шутка: один из классических примеров -- это строительство почтамта, в котором въезд для грузовиков с почтой был невозможен: забыли узнать, какой высоты эти грузовики, и они просто не могли проехать для погрузки-разгрузки -- были слишком большие для оставленной им въездной дырочки в железобетонной конструкции).
Чем позже будет обнаружена коллизия, тем дороже её исправление -- проще всего исправить информацию в файле, чуть труднее исправить подписанную десятком человек бумагу, совсем трудно исправить пятисоттонную железобетонную конструкцию. Поэтому суть системной инженерии -- "сначала подумать, потом сделать". Ошибку в мыслях (если мысли представить в виде данных) легче исправить, чем ошибку в действиях с реальным материалом.
Главная идея СУЖЦ -- это использование аккуратного представления системы и окружающего её мира в компьютерных системах (виртуальные модели, информационные модели, виртуальные макеты и т.д.), чтобы противоречия были выявлены при "компьютерном строительстве", "виртуальной сборке", а не при выносе чертежей и других моделей в реальность при сооружении.
Нужно отметить, что СУЖЦ не имеет тем самым отношения к generative design (http://ailev.livejournal.com/834653.html), разве что позволяет находить коллизии результатов этого и разных других видов проектирований, когда их будут собирать вместе (что бы ни означало это слово "собирать" -- сливать данные вместе, запускать алгоритм проверки целостности для распределенных данных, проводить актуальную "виртуальную сборку" и имитационное моделирование для результата -- это всё нужно обсуждать отдельно, ибо это относится к "конструкции", а мы сейчас обсуждаем функцию, назначение СУЖЦ).
"Предотвращение коллизий" подразумевает, в частности:
1. Отказ не только от бумаги, но и от "электронной бумаги". Сравнить две модели, существующие на бумаге в каких-то нотациях и найти в них несоответствия много сложнее и дольше, нежели предотвращать коллизии в структурированных электронных документах, с моделями (моделеориентированность). Две диаграммы-описания, нарисованные "от руки" по неминуемо произвольным правилам (даже если они хранятся в электронной форме) много сложнее сравнить и проанализировать совместно, ежели они не придерживаются каких-то соглашений о кодировании реальности, какой-то модели данных жизненного цикла. Когда я пишу "модель", я имею ввиду чаще всего модель, разработанную в соответствии с каким-то языком (в терминах ISO 24744), или метамоделью (в терминах OMG), или моделью данных/справочными данными (в терминах ISO 15926). Это про моделеориентированность. Сюда же -- отказ от "железа и бетона" (например, штрих-коды или RFID позволяют работать не просто с каждой железякой или каменюкой в их физическом воплощении, но сразу переходить к её описаниям). СУЖЦ должна работать в настоящем моделеориентированном подходе.
2. Поддержание принципа "одно значение вводится руками один раз": всё остальное делается копированием данных из приложения в приложении. При любом "перевводе" информация может исказиться, кроме того при "перевводе" человеческие усилия экономятся и перевбивается не вся нужная информация, а только самая-самая необходимая -- и тем самым часто пропадает осмысленный контекст, в котором можно было бы легко обнаружить ошибки. СУЖЦ должна обеспечивать механизм передачи данных из одного приложения CAD/CAM/ERP/PM/EAM/и т.д. в другое в электронном структурированном виде. Передача данных (откуда, куда, когда, что) -- это часть обеспечиваемого СУЖЦ workflow.
3. Во время инженерии любое описание, любая модель изменяются многократно, и существуют поэтому во множестве альтернативных версий разной степени правильности, и в разной мере соответствующих друг другу. СУЖЦ должна следить за "одной версией правды", то есть предоставлять функцию управления конфигурацией -- как моделей, так и физических частей системы. Управление конфигурацией -- это прежде всего отслеживание изменений версий, т.е. отслеживание действий проектировщиков и уведомление их о том, что что-то изменилось -- то есть это тоже часть обеспечиваемого СУЖЦ workflow.
Обращу особое внимание, что мы тут никак не коснулись архитектуры (т.е. того, как "конструкция" СУЖЦ поддерживает заявленную функцию предотвращения коллизий):
-- реализуется ли она как обеспечение передач данных "точка-точка" между разными приложениями (например, какая-нибудь из BPM engine или complex event processing engine + ISO 15926 outside для множества САПР)
-- реализуется ли она как PLM какого-то конкретного поставщика (Teamcenter, ENOVIA, SPF, NET Platform и т.д.)
-- есть там какой-то "портал", обязательно ли это "веб-портал"
-- есть ли там репозиторий, или это "распределенный репозиторий", составленный из репозиториев отдельных приложений и registry (разница между repository и registry архитектурами: в первые копируются и там хранятся актуальные данные, а во вторых поддерживается набор ссылок в другие хранилища данных, и никакие данные не копируются в одно хранилище)
-- работают ли какие-то отдельные "проверки целостности/непротиворечивости", и как они устроены (отдельным алгоритмом в отдельном приложении над отдельными данными, отдельным алгоритмом над репозиторием, отдельным алгоритмом, обращающимся по сети к разным хранилищам данных, алгоритмом слияния разных моделей в одну с контролем ошибок и т.д.).
-- как же всё-таки связаны инженеры-проектировщики, монтажники, закупщики и т.д. и сотф СУЖЦ (ибо workflow по традиции определяется как проходящий через людей и компьютеры)
-- где там "модель жизненного цикла" (какой артефакт ей соответствует), о которой так любят поговорить.
-- переход к каким методам работы инжиниринговой компании подразумевает СУЖЦ (ибо переход с лопат на экскаваторы, или с телег на грузовики может быть для организации чуть бОльшим шоком, чем об этом думают менеджеры, в глаза не видевшие ни одной лопаты или экскаватора, телеги или грузовика).
Но на эти архитектурные вопросы можно как-то искать ответы, если помнить: главное для СУЖЦ -- это предотвращение коллизий. Ежели речь заходит о чём-то другом (выбор вида жизненного цикла, управление старением, управление стоимостью, освоение axiomatic design, сооружение с поставками just-in-time, generative design и generative manufacturing, и многое-многое другое, также крайне полезное-современное-интересное), то это вопрос других систем, других проектов, других методов, других подходов. Keep focus.
И только после того, как будут отвечены эти архитектурные вопросы, можно будет сказать, какого уровня интеллектуальности вы делаете софтовую часть СУЖЦ (http://ailev.livejournal.com/878210.html). Текущие варианты (в их PLM-инкарнациях) сводятся пока к уровню 1.