CC BY
244
УДК 658.5 ББК 65.050
КОНСТРУКТОР PLM - СИСТЕМ
Белов М. В.1, Савич А. В.2
(IBS, Москва) Гаричев С. Н.3, Кондратьев В. В.4, Лытов Д. А.5
(Московский физико-технический институт (ГУ), Долгопрудн ый)
Стандартные архитектуры предприятия, подкрепленные стандартными методологиями, обеспечивают опорные решения для организации и координации проектов инжиниринга предприятия в целом, а также инжиниринга частных сущностей и подсистем предприятия [11,17]. В [7] инжиниринг предприятия предложено проводить на основе подхода «Конструктор систем деятельности». Этот подход задает компактное опорное инжиниринговое представление устройства деятельности предприятия, а также может применяться с необходимой локализацией к разным сущностям и подсистемам деятельности предприятия. Так, в [5] рассматриваются инжиниринг «системы менеджмента предприятия» и, соответственно, «Конструктор систем менеджмента». В данной работе рассматривается инжиниринг «системы управления жизненным циклом продукта» и, соответственно, «Конструктор PLM-систем».
1 Михаил Владимирович Белов, зам. директора IBS, кандидат технических наук ([email protected]).
2 Александр Валентинович Савич, директор по консалтингу IBS, кандидат технических наук ([email protected]).
3 Сергей Николаевич Гаричев, декан ФРКТ МФТИ, доктор технических наук ([email protected]).
4 Вячеслав Владимирович Кондратьев, доктор технических наук, профессор МФТИ ([email protected], +79099935660).
5 Денис Александрович Лытов, магистр ФРТК МФТИ ([email protected], + 79654343116).
Ключевые слова: PLM-система, конструктор PLM-систем, онтологические и архитектурные модели, количественные модели, большие гибридные модели, центр PLM-превосходства.
1. Предпосылки проведения работ
Системы Product Lifecycle Management, или PLM-системы деятельности [1], реализуют жизненный цикл продуктов. Согласно [23], PLM -системы:
• охватывают полный жизненный цикл продукта - от концепции до утилизации или реконструкции;
• поддерживают совместное создание информации о продукте, а также ее управление, распространение и использование;
• поддерживают деятельность «расширенного предприятия полного цикла продукта» (клиенты, разработка и производство, партнеры-поставщики и т.д.);
• интегрируют людей, процессы, бизнес-системы и информацию по жизненному циклу продукта.
На российском рынке представлен ряд информационных продуктов, позиционируемых их производителями в качестве PLM-систем. Анализ продуктовых линеек производителей PLM-систем (Dassault Systems, Siemens, АСКОНА и др.) показывает, что они предлагают набор решений (системы CAD/CAE/CAM NX, ...), предназначенных для автоматизации отдельных стадий жизненного цикла продукта, в первую очередь таких как проектирование, технологическая подготовка производства, производство, техническое обслуживание и ремонты.
Наблюдаемое в российской практике расширение масштабов внедрения программного обеспечения для локальной автоматизации процессов жизненного цикла, безусловно, способствует повышению эффективности их реализации на конкретных предприятиях. Однако сегодня локальная автоматизация не в полной мере соответствует мировым тенденциям создания интегрированных решений, осложняет реализацию концепции «расширенного предприятия полного жизненного цикла» [12], порождает значительные дополнительные затраты на интегра-
цию разрозненных информационных систем для комплексной автоматизации процессов всех стадий жизненного цикла.
Необходима разработка и методологических вопросов построения PLM-систем и её компонент:
• комплексные модели устройства деятельности (требования, процессы, организация, управление, подсистемы);
• ролевые модели участников, дорожные карты;
• модель данных, формирующих полное информационное пространство, необходимое и достаточное для реализации всех процессов жизненного цикла продукта в заданные сроки с минимальными затратами ресурсов;
• компонентная модель интегрированной информационной системы (ИС), обеспечивающей автоматизацию процессов всех стадий жизненного цикла продукта;
• интеграция моделей;
• разработка рабочей документации и применение.
В зарубежной литературе присутствуют работы, достаточно полно описывающие создание PLM-системы для выбранного продукта [22, 24]. Но продукты могут меняться с каждой итерацией жизненного цикла, и со временем однажды разработанная PLM-система станет неактуальной. Поэтому важно также учитывать, что вновь созданная PLM-система сама по себе является продуктом, чьим жизненным циклом необходимо управлять в том числе.
Таким образом, задачи развития методологии, разработки, эффективного внедрения и применения PLM-систем остаются актуальными. Согласно отрытому докладу «Сколтех» в рамках подготовки проекта национальной технологической инициативы, внедрение перспективной системы управления жизненным циклом изделия даст повышение эффективности производства в целом не менее чем на 15-25% [12].
2. Системы для разработки PLM-систем
Объектом дальнейшего рассмотрения является система С, включающая (рис. 1):
• Систему 1 (С1) - разрабатываемый и применяемый экземпляр системы управления жизненным циклом продукта (экземпляр РЬМ-системы). С1 реализует управление этапами жизненного цикла продукта: разработка продукта, создание продукта, эксплуатация (в том числе техническое обслуживание и ремонты) продукта, модернизация продукта. Дальнейшее описание системы С1 базируется на работе [1], где были представлены все особенности рассматриваемой РЬМ-системы, и продолжает ее.
• Систему 2 (С2) - экземпляр системы управления жизненным циклом опорной системы С1. С2 реализует управление этапами жизненного цикла системы С1: разработка С1, применение С1 в ходе исполнения жизненного цикла продукта, мониторинг и аудит применения С1, улучшение С1. Само представление С относится к типу «система систем» С = С1 и С2 и через системы С1 и С2 реализует указанные выше этапы деятельности (рис. 1).
Рис 1. Этапы деятельности системы систем С = С1 и С2
3. Особенности Конструктора систем деятельности
Инжиниринг системы деятельности (предприятия, расширенного предприятия) - это деятельность по созданию, описанию, изменению или улучшению предприятия, основанная на использовании инженерного подхода, обеспечивающая согласованность различных компонентов предприятия (стратегий, требований, организации деятельности, процессов, механизмов управления, информационных систем) [8].
Конструктор является опорным решением для реализации инжиниринга систем деятельности, которое [7] (рис. 2):
• задаёт увязанную с международными практиками и стандартами типологию элементов и связей в представлениях систем деятельности;
• обеспечивает интеграцию и совместное применение методологий системного инжиниринга, менеджмента и кибернетики, управления активными мультиагентными системами;
• формирует и применяет большие гибридные модели представления функционирования и развития систем деятельности, последовательно объединяющие и гармонизирующие такие современные системные форматы моделирования как онтологические, архитектурные, количественные, оптимизационные, управленческие (кибернетические) и др.;
• представляет архитектуру интеграции системы деятельности и применяемых ИТ-сервисов;
• задает, на основе применения больших гибридных моделей и интеграции с ИТ-сервисами, способ разработки и документирования системы деятельности и системы управления её жизненным циклом;
• поддерживает реализацию всех стадий жизненного цикла системы деятельности: разработка - применение - мониторинг - улучшение и развитие;
• обеспечивает создание и применение сервисной модели обеспечения применения Конструктора с дистанционными учебными и консалтинговыми сервисами;
• обеспечивает возможность создания и применения специализированной инфраструктуры для разработки и сопровождения систем деятельности в формате Mission Control Room (MCR);
• обеспечивает возможность реализации сервисной модели в форме Центра превосходства (другие варианты названия, применяемые в международной практике - руководящей группе проекта, центр разработки и распространения передовых методов [13-15] и др.).
Рис 2. Особенности Конструктора систем деятельности
4. Конструктор РЬМ-систем
Вообще говоря, для каждого продукта г требуется свой экземпляр системы С1г-, а для разработки С1 г требуется своя система С2г-. Разнообразие продуктов порождает разнообразие си-
стем управления жизненным циклом продуктов, что, в свою очередь, порождает разнообразие систем управления их созданием и применением. Во многом эти системы подобны, но, конечно, есть и отличия в локализациях решений под разные продукты.
Значит, С1 и С2г- взаимно гармонизируются и их надо рассматривать в контексте системы систем Сг = С1г И С2г. Решение задачи гармонизированного построения Сг = С1 г И С2г может быть получено применением и локализацией в рамках следующего подхода:
• представления опорных систем (фреймворков) пары С1 и С2 как гармонизированного объединения С = С1 И С2;
• действий по локализации опорной системы С для каждого продукта г и разработке, в конечном итоге, системы С1 г;
• обеспечения возможности параллельной реализации жизненных циклов систем С1г и С2г для разных продуктов г заданного типа.
Соответственно, схема системы С становится несколько сложнее, чем представлено на рис. 1, - нужно учесть, что система С состоит из множества систем Сг (рис. 3).
Рис 3. Расширенная схема этапов деятельности системы
С = С1 и С2
Опорные представления (фреймворки) системы С1 управления жизненным циклом продукта и системы деятельности С2 по локализации опорной системы С1 к продукту г и разработке С1г понимаются как Конструктор РЬМ-систем для г множества продуктов заданного типа.
Устройство и представление опорной системы С обобщает имеющийся опыт и методологии, т.е. феноменологию построения подобных систем.
В данной работе в качестве основы построения опорного решения С1 взята феноменология PLM-систем, представленная в [1], а в качестве основы построения опорного решения С2 взята феноменология инжиниринга систем деятельности, представленная в [5, 7].
5. Инициация разработки системы управления жизненным циклом продукта
В дальнейшем для упрощения обозначений значком «* » будем помечать локализацию понятий для заданного продукта г (экземпляры понятий). Например, Сг = С*, С1г = С1* и т.д.
Деятельность С2* по созданию С1* инициируется постановкой задачи разработки и применения конкретной системы С1* для продукта «*». В рамках задачи выполняются действия по идентификации и принятию требований (общих и частных) к системе С1*, мобилизации ресурсов и подготовке дорожной карты работ. Результат - готовность к началу проведения работ по разработке и применению С1*.
5.1. Задание требований, границ и предназначения системы С1 для продуктов г заданного типа, знакомство с исходной информацией и постановкой задачи. Результат - определение объекта проектирования и применения, подготовка стартовой проектной декларации.
5.2. Определение участников разработки и применения С1г. Результат - команда участников в составе трех групп: группа 1 -разработчики С1 *, группа 2 - участники (пользователи) С1 *, группа 3 - специалисты С2*.
5.3. Изучение группой 1 методологий Конструктора систем деятельности и PLM -систем в целях локализации при разработ-
ке С1*. Результат - обученная к применению С группа 1, готовая к началу работ группа 3.
Дальнейшие действия (п.6-п.8) групп 1 и 3 направлены на локализацию и, при необходимости, дополнению методологии С (Конструктора PLM-систем) применительно к системе С1*. Для этого:
5.4. Исходя из конкретной ситуации в задаче построения системы управления жизненным циклом продукта 1 формируется и поддерживается в актуальном состоянии распределение ответственности сначала в разработке С1*, а потом в реализации всего жизненного цикла системы С1* (таблица 1). Результат -таблица распределения ответственности (ролей) участников.
5.5. Проводится доработка и локализация (при необходимости) Конструктора С в Конструктор С Результат - локализованный Конструктор PLM-системы С2*.
5.6. Формируется состав ожидаемых результатов, действий, итерационная схема и дорожная карта первого этапа жизненного цикла системы С1* (см. раздел 5). Результат - дорожная карта.
Таблица 1. Распределение ответственности / ролей участников
Участники Инициация Изучение С и анализ условий её применения. Локализация С в С* Раз-работка С1* Применение С1 * Мониторинг и аудит применения С1 * Улучшения С1 *
Инициаторы
Группа 1
Группа 2
Группа 3
Другие участники
6. Разработка системы управления жизненным циклом продукта
Построение системы С1* предполагает разворачивание и разработку, с наследованием состава и характеристик используемых сущностей, следующей итерационной схемы действий [7]:
• задание (на основе проведения онтологического инжиниринга) терминов и понятий рассматриваемой системы, её среды, элементов, подсистем, связей, словаря системы С1*;
• разработку архитектуры системы С1*- внешней среды, элементов, подсистем, связей - с применением выбранных (предпочтительно типовых) нотаций и идентифицированных данных;
• формирование прикладных количественных моделей и банка знаний*;
• задание ИТ-сервисов, используемых в системе С1*;
• задание состава и порядка подготовки документов и регламентов, представляющих порядок функционирования системы С1* ;
• подготовка документов и регламентов, представляющих порядок функционирования системы С1*.
Наследование состава и характеристик используемых сущностей обеспечивает связанность применяемых типов моделей и позволяет говорить об их совокупности как о большой гибридной модели. Изменения в какой-либо части этой модели приводят к изменениям в других её частях.
Порядок разработки является итерационным, рекурсивным, компоненты системы С1* нарабатываются по шагам, где ] - номер шага.
Входом на каждом шаге] процедуры являются:
• требования;
• наработанная к этому шагу версия системы;
• опорная версия системы, представляющая накопленный опыт.
Выходом является наработанная версия системы.
Так как модель рекурсивная, то необходимо задать начальные условия. В качестве первой версии системы и опорной си-
стемы берем PLM-систему, построенную в соответствии с описанием из [1].
Возвраты осуществляются при получении в новой версии решений, требующих изменений в текущей (входной для данного шага) версии. Изменения могут вноситься как в текущую версию, так и в опорную версию. Деятельность останавливается при достижении удовлетворительного решения.
Сама деятельность по разработке новой версии системы осуществляется человеко-машинной интеллектуальной системой. Группы 1 и 3 представляют первую часть, инфраструктура MCR - вторую.
Рис 4. Порядок разработки С1* в рамках С2*
Подробнее описанная схема представлена ниже в разделах 6.1-6.9.
6.1. Проведение онтологического инжиниринга С*.
Результат - словарь терминов.
Для смыслового описания системы и задания сущностных понятий и терминов С1 * проводится (с применением опорного словаря) онтологический инжиниринг С1 * . Результат - учитываемые при инжиниринге объектные и атрибутные элементы С1*, их взаимосвязи, словарь терминов.
Справочно. Онтология - это структурная спецификация некоторой предметной области, ее формализованное представление, которое включает словарь (или имена) указателей на термины предметной области и логические выражения, которые описывают, как они соотносятся друг с другом [2].
Онтологический инжиниринг - это процесс разработки он-тологий [3].
Пример 1. Термины опорного словаря С1. Продукт, жизненный цикл продукта, целеполагание в С1, требования к С1, ин-
формационная модель продукта, процессы жизненного цикла продукта, участники деятельности С1, расширенное предприятие полного жизненного цикла продукта и образующие его предприятия -управляющие, исполнительные, организация участников деятельности С1, ролевые модели участников деятельности С1, управление процессами и производственным поведением участников деятельности С1, модель управления проектами и программами С1, модели данных, ИТ-инфраструктура и ИТ-сервисы С1, информационные системы С1.
В состав понятийной базы С1 также включаются термины, определяющие наиболее значимые соответствия между понятиями. Например, приводится определение термина ответственности участников деятельности С1 за бизнес-процессы или функции С1.
Пример 2. Термины опорного словаря С2. Формируются путем локализации и дополнений (применительно к PLM-системам) приведенных в [5, 7] опорных сущностей и терминов Конструктора систем менеджмента. Как вариант, может быть построен следующий опорный список. Целеполагание в С2, требования к С2, информационная модель С1, процессы жизненного цикла С1, участники деятельности С2, Центр PLM-превосходства (центр обеспечивающий применение С2), организация участников деятельности С2, ролевые модели участников деятельности С2, управление процессами и производственным поведением участников деятельности С2, модель управления проектами и программами С2, модели данных, ИТ-инфраструктура и ИТ-сервисы С2, информационные системы С2.
В состав понятийной базы также включаются термины, определяющие наиболее значимые соответствия между понятиями. Например, ответственность участников деятельности С2 за бизнес-процессы, функции, программы и проекты С2.
6.2. Проведение системной декомпозиции системы С1* = С1* И С2* на подсистемы [7]. Результат: справочник подсистем, образующих С* = С1* И С2*.
Пример 3. Опорные подсистемы С.
С1 включает подсистемы ведения операционной деятельности по жизненному циклу продукта (рис. 5):
• Управление требованиями и соответствием требованиям.
• Управление взаимодействием участников деятельности.
• Управление расписанием.
• Управление рисками.
• Управление информационной моделью.
• Управление финансами и экономикой.
• Управление проектной программой.
• Управление конфигурацией и изменениями. С2 включает системы:
• Управление жизненным циклом системы С1 (в том числе управление разработкой С1 ).
• Сервисные подсистемы специалистов группы 1 и 2 в части применения С1 , такие как:
• Информационная поддержка.
• Поддержка развития компетенций.
• Шеф-инжиниринг (сопровождение) деятельности С1.
Рис 5. Пример состава подсистем С = С1 и С2
6.3. Разработка (гармонизированной с требованиями) архитектуры С1*. Результат - задание, с применением и
наследованием результатов п.6.1-п.6.2, состава, форматов представления (архитектурных нотаций) и самих данных об образующих С1* элементах, подсистемах, и их связях
(рис. 5).
Пример 4. Фреймворк опорной архитектуры С1.
• Требования к устройству деятельности.
• Процессы (корневая модель, функциональная и потоковая модели декомпозиции процессов, процедуры).
• Проекты.
• Организация участников деятельности (организационная структура, финансовая структура, модели ответственности, модель прав и ролей).
• Система управления операционной деятельностью (стандартная модель цикла управления; декомпозиция системы операционного управления по иерархическим уровням и стандартным горизонтам управления, а также типам управляемых ресурсов; до-кументограмма системы операционного управления).
• ИТ-сервисы.
• Связи компонент системы: «требования - процессы -организация участников деятельности - системы управления - ИТ сервисы».
Справочно. Фреймворк - в простейшем случае табличное представление опорных элементов системы и их связей. Понятие «опорная архитектура» является синоним понятия «референсная (референтная) архитектура».
Элементы архитектурного фреймворка С = С1 И С2 «сущности - подсистемы - связи (акцептированно выделены)» представлены в таблице 2.
Таблица 2. Фреймворк опорной архитектуры C = С1 и С2.
Учитываемые при архитектурном моделировании сущности С1 и способы их представления. Учитываемые при архитектурном моделировании подсистемы
• Продукт (паспорт продукта). • Жизненный цикл продукта (справочник). • Требования к С1 (справочник). • Целеполагание в С1 продукта (справочник). • Информационная модель продукта. • Процессы жизненного цикла продукта (справочник). • Участники деятельности (справочник). • Расширенное предприятие полного жизненного цикла продукта и образующие его предприятия - управляющие, исполнительные (справочник). • Организация участников деятельности (справочники и модели). • Ролевые модели участников деятельности. • Архитектуры систем и модели механизмов управления [20]: о Субъект-объектные схемы управления о Прямые и обратные Подсистемы С1 : • Управление требованиями и соответствием требованиям. • Управление взаимодействием участников деятельности. • Управление расписанием. • Управление рисками (С1.4). • Управление информационной моделью. • Управление финансами и экономикой. • Управление проектной программой. • Управление конфигурацией и изменениями.
Подсистемы С2: • Управление жизненным циклом системы С1 . • Управление сервисами поддержки участников деятельности С1: • Информационная поддержка. • Поддержка развития компетенций. • Шеф-инжиниринг.
Учитываемые при архитектурном моделировании сущности С1 и способы их представления. Учитываемые при архитектурном моделировании подсистемы
связи о Механизмы управления • Модели данных. • ИТ-инфраструктура и ИТ-сервисы С1 (справочник). • Информационные системы С1 (справочник). • Другие подсистемы (внешние для С1 и учитываемые при архитектурном моделировании в силу существенности для С1 связей с ними). • ...
Связи сущностей С1 (учитываемые при инжиниринге соответствия). Связи подсистем С1 (учитываемые при инжиниринге соответствия).
Учитываемые при инжиниринге связи сущностей и подсистем С1.
Учитываемые при инжиниринге уровни представления и моделирования систем деятельности.
6.4. Разработка количественных моделей С1* и методик их применения в целях реализации требований. Результат -наследующие результаты п.6.1-п.6.3, гармонизированные с требованиями к С1*, метрики и используемые количественные модели, обеспечивающие достижение поставленных требований.
6.5. Задание моделей управленческого учета (метрики, показатели, политика управленческого учета и другие обязательные атрибуты количественной модели деятельности); на этом этапе обеспечиваются количественные представления системы деятельности С1*. Результат - методология управленческого учета С1*.
6.6. Задание количественных моделей (балансы, сетевые модели, задачи оптимизации, субъект-объектные модели систем и механизмов управления, применяемые при разработке и функционировании С1 *. Результат - банк моделей и знаний о функционировании С1* [5, 20].
6.7. Полезное дополняющее моделирование и методики его применения С1*. Результат - дополняющие модели и методики к применению в С1*.
6.8. Системное моделирование, применение ИТ-сервисов и системная интеграция С1*. Результат - состав и профиль применяемых ИТ-сервисов С1*, интеграция С1* с применяемыми ИТ-сервисами, направленными на обеспечение достижения поставленных требований.
6.8.1. Представление используемых ИТ-сервисов С1*, проект развития ИТ-сервисов. Результат - гармонизированный с архитектурным фреймворком и акцептированный набор требований к ИТ-сервисам, справочники ИТ-сервисов, порядок и план внедрения ИТ-сервисов.
6.8.2. Разработка, внедрение и интеграция ИТ-сервисов
С1*.
6.9. Документационное описание С1*. Результат - состав документационного описания С1* и порядок его разработки.
6.9.1. Задание методики и порядка «сборки», «достройки и настройки», гармонизации элементов и подсистем системы С1* на основе компонент 4.1-4.8. Результат - способ построения, с учетом требований международных стандартов [17] и др., и применением результатов п.6.1-6.8, документационного описания С1 *.
6.9.2. Задание порядка разработки документационного описаний С1*. Результат - задание, с применением п.3.1.4-п.3.1.8, состава и последовательности действий и способов наделения участников ответственностью за разработку и применение необходимых описаний и документов (дорожная карта разработки и применения документационного представления).
6.9.3. Разработка в соответствии с п.4.9.2 нормативно-методической документации (НМД) и организационно-распорядительной документации (ОРД) С1*; результат -НМД и ОРД С1*.
В итоге исполнения п. 6.1-п. 6.9 формируются: последовательно раскрывающие и последовательно наследующие свойства ключевые представления системы деятельности С1 от состава используемых терминов и понятий С1* до принятых к применению ИТ-сервисов, НМД и ОРД. Тем самым разработана готовая к применению С1*.
7. Разработка сервисов поддержки участников
Построение системы С1* предполагает поддержку участников групп 1 и 3 на стадии разработки и группы 2 на стадии применения решений. Результатом является создание необходимых компетенций у участников деятельности. Эта деятельность, в частности, предусматривает:
7.1. Задание порядка идентификации компетенций участников, необходимых для разработки документационного описания и применения С1 и С2; результат - профиль необходимых компетенций участников С1 и С2.
7.2. Разработка, при необходимости, системы сервисов развития компетенций участников деятельности; результат - система сервисов развития компетенций участников С1 и С2.
7.2. Применение, при необходимости, сервисов развития компетенций участников С1 и С2; результат - наличие необходимых компетенций у участников С1 и С2.
7.3. Шеф-инжиниринг (сопровождение) С1 и С2.
8. Обеспечение исполнения всего жизненного цикла системы управления жизненным циклом продукта С1*
8.1. Разработка С1*. Результат - разработанная и документированная С1*, готовая к применению (см. п.6).
8.2. Применение НМД и ОРД, эксплуатация С1*. Результат - деятельность С1 * по разработанным НМД и ОРД.
8.2.1. Акцептация НМД и ОРД С1*. Результат - необходимые организационно-распорядительные решения.
8.2.2. Применение НМД и ОРД С1*. Результат - исполнение деятельности в соответствии с утвержденными ОРД и НМД, справочниками ИТ-сервисов С1.
8.3. Мониторинг деятельности в условиях применения С1.
8.3.1. Мониторинг, проверка соответствий порядков фактического исполнения деятельности С1* требованиям к С1*, выявление и по возможности оперативное устранение несоответствий; результат - записи о результатах мониторинга и устраненных несоответствиях.
8.3.2. Мониторинг, выявление и фиксации системных несоответствий в С1*; результат - записи о результатах мониторинга.
8.4. Аудит и улучшения С1*. Результат - список идей улучшения и инициация нового жизненного цикла С1*.
8.4.1. Аудит результатов применения С1*; результат - отчет об аудите.
8.4.2. Формирование банка идей улучшений; результат -банк идей улучшений С1 *.
8.4.3. Приоритезация идей улучшений С1*; результат -упорядоченный по приоритетам список идей улучшений С1 *.
8.4.4. Переход на начало жизненного цикла С1*; результат - инициация нового жизненного цикла С1 *.
Иллюстрация участников деятельности С1 и С2 с детализацией представления их действий в рамках С2 приведена на рис. 6.
Рис. 6. Участники и процессы системы С = С1 и С2 9. Выводы
9.1. Общие результаты.
• Методология «Конструктор систем деятельности» в соединении с применением современных международных архитектурных стандартов, системных и инжиниринговых методологий [4, 16, 19, 21] и др. позволила сформировать гармонизированный между собой состав моделей для разработки и примене-
ния PLM-систем. Модели последовательно разворачивают ключевые перспективы представления PLM-систем: сущностное (онтологическое), содержательное (архитектурное), количественное (управленческий учет и экономика), кибернетическое (системы и механизмы управления), информационное (данные и информационные модели), социально-экономическое (сервисы и инфраструктура поддержки, развитие компетенций, мотивация участников). В своей совокупности модели объединяются в большие гибридные модели, создают методическую основу для регулярного проектирования и применения PLM-систем (таблица 3).
• Большие гибридные модели, результаты их исследований обеспечивают формирование состава и систем документа-ционного описания и регламентации PLM-систем.
• Предложенная итерационная рекурсивная схема (раздел 6) разработки PLM-систем позволяет структурировать и типизировать систему деятельности по созданию PLM-систем, обеспечивать возможность её последовательного «саморазвития» в формате человеко-машинных интеллектуальных комплексов, представлять в качестве Конструктора с описанными элементами и правилами применения.
9.2. Mission Control Room.
Удобной и результативной формой человеко-машинного комплекса Конструктора PLM-систем является формат Mission Control Room (MCR), рис. 7. Это модульная инфраструктура для поддержки работ по созданию PLM-систем 5. В зависимости от решаемой задачи, условий и возможностей состав модулей MCR может меняться. Исходя из накопленной практики, в качестве составных инфраструктурных модулей MCR можно указать следующие инфраструктурные компоненты:
• Учебная доска для быстрых записей.
• Пробковая доска и простые инструменты для размещения и быстрого редактирования записей и представлений на бумажном носителе.
• Интерактивная цифровая доска для размещения и быстрого редактирования цифровых представлений.
• Видеокубы для параллельного размещения многих цифровых представлений.
• Специализированный софт для моделирования систем деятельности.
• Дизайн-студия для быстрого производства необходимого цифрового контента.
• Learn Management System (LMS) для обеспечения обучения и развития компетенций участников с дистанционной поддержкой;
• Инфокоммуникационные и интернет-сервисы.
• Дополняющие инфраструктурные компоненты ситуационных центров.
Инфо - »краны Пробковые доен и
Рис. 7. Эскиз МСЯ Центра РЬМ-превосходства
9.3. Центр РЬМ-превосходства.
Для организации параллельного ведения работ со многими объектами/ РЬМ-системами предлагается применение технологии «Центр РЬМ-превосходства».
Наличие «Центра РЬМ-превосходства» позволяет рационально и гибко создавать системы регулярного проектирования РЬМ-систем и сопровождения их жизненного цикла. Как пример, распределение компетенций и ответственности за разработку и сопровождение РЬМ-систем в одном из прорабатываемых проектов осуществляется между:
• специализированным системным и методологическим оператором, скажем, МФТИ http://mipt.ru/;
• межотраслевым или отраслевым оператором, скажем, Межотраслевым инновационным центром государственной корпорации Ростехнологии http://www.mic-rostec.ru/;
• специализированным подразделением или группой, поддерживающей работу PLM-системы, скажем в МКБ «Компас» Объединенной приборостроительной корпорации Ростехнологии http://mkb-kompas.ru.
9.4. Применение и реализация.
Все элементы представленного подхода в настоящее время проходят разработку и апробацию. Реализуются проекты, проводятся эксперименты [1, 6], осуществляется объединение решений в интегрированные системы Конструктора PLM-систем [7]. Изучение предложенной в работе системы С для продуктов инвестиционно-строительной деятельности является частью курса «MBA в строительстве», преподаваемого в МГСУ [18]. Кроме того, описание указанного подхода присутствует в курсе «Кибернетика 2.0», читаемого в ЦДПО МФТИ, ФРТК МФТИ с сентября 2015 года [9]. Также разработка экземпляра представленной системы, предложенной в заявке открытого акционерного общества «Московское конструкторское бюро «Компас»», одобрена Министерством промышленности и торговли Российской Федерации (подтверждение актуальности проблематики в рамках реализации мероприятий 1.4 и 1.3 федеральной целевой программы «Исследования и разработки по приоритетным направлениям развития научно-технологического комплекса России на 2014-2020 годы» [10] получено от автономной некоммерческой организации содействия развитию индустрии программного обеспечения «Национальная программная платформа»).
Литература
1. БЕЛОВ М.В. Системно-инженерные и экономические аспекты управления жизненным циклом. - [Электронный ресурс]. - URL: http://ubs.mtas.ru/bitrix/components/bitrix/
forum.interface/show_file.php?fid=12292 (дата обращения: 08.01.2016).
2. ГАВРИЛОВА Т.А. Онтологический инжиниринг // Труды конференции «КИИ». - М.: Физматлит, 2002. - С. 845-853.
3. ГАВРИЛОВА Т.А. Онтологический подход к управлению знаниями при разработке корпоративных систем автоматизации. - [Электронный ресурс]. - URL: http://bigc.ru/theory/km/ontol_podhod_to_uz.php (дата обращения: 28.01.2016).
4. ГОСТ 34.003-90 Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения
5. КОНДРАТЬЕВ ВВ., ЛЮБИМЦЕВ И.В., МЕРКУЛОВ А.В. И ДР. Инжиниринг и управление жизненным циклом объекта «Система менеджмента предприятия» // Сборник научных трудов 18-й Российской научно-практической конференции «Инжиниринг предприятия и управление знаниями». Том 1. - М.: Московский государственный университет экономики, статистики информатики, 2015. -С. 333 -338.
6. КОНДРАТЬЕВ В.В. Моделируем и анализируем бизнес-процессы. Учебное пособие. - М.: ИНФРА-М, 2014. -109 с.
7. КОНДРАТЬЕВ В.В. Управление архитектурой предприятия (Конструктор регулярного менеджмента): Учебное пособие. 2-е изд., перераб. и дополн. - М.: Инфра-М, 2015. -C. 357
8. КУДРЯВЦЕВ Д.В., АРЗУМАНЯН М.Ю., ГРИГОРЬЕВ Л.Ю.
Технологии бизнес-инжиниринга. - С.-Пб.: Изд-во Политехнического университета, 2014 - 427 с.
9. Курс Кибернетика 2.0. - [Электронный ресурс]. - URL: https://mipt.ru/cdpo/courses/cybernetics.php_ (дата обращения: 09.01.2016).
10. Постановление правительства России от 21 мая 2013 г. №426 «О федеральной целевой программе "Исследования и разработки по приоритетным направлениям развития научно-технологического комплекса России на 20142020 годы"». - [Электронный ресурс]. - URL:
http://xn--80abucjiibhv9a.xn--p1ai/%D0%B4%D0%BE%D0 %BA%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D 1 %8B/3421 (дата обращения: 09.01.2016).
11. Промышленные автоматизированные системы. Требования к стандартным архитектурам и методологиям предприятия. ГОСТ Р ИСО 15704-2008 // Федеральное агентство по техническому регулированию и метрологии. - [Электронный ресурс] - URL: http://labsm.ru/mod/resource/ view.php?id=485 (дата обращения: 10.05.2015).
12. Публичный аналитический доклад по развитию новых производственных технологий // Skolkovo Institute Of Science and Technology, Октябрь 2014. - [Электронный ресурс]. -URL: http://isicad.ru/ru/pdf/ReportSkolkovo2014.pdf (дата обращения: 09.01.2016).
13. Сервис-ориентированная архитектура и архитектура предприятия: Часть 1. Взаимодействие SOA и EA. - [Электронный ресурс]. - URL: https://www.ibm.com/ developerworks/ru/library/ws-soa-enterprise1 (дата обращения: 09.01.2016).
14. Сервис-ориентированная архитектура и архитектура предприятия: Часть 2. Сходства и различия. - [Электронный ресурс]. - URL: https://www.ibm.com/ developerworks/ru/library/ws-soa-enterprise2 (дата обращения: 09.01.2016).
15. Сервис-ориентированная архитектура и архитектура предприятия: Часть 3. Как они работают вместе? -[Электронный ресурс] - URL: http://www.ibm.com/ developerworks/ru/library/ws-soa-enterprise3 (дата обращения: 09.01.2016).
16. Системная инженерия. Процессы жизненного цикла систем. ГОСТ Р ИСО/МЭК 15288-2005 // Федеральное агентство по техническому регулированию и метрологии. -[Электронный ресурс]. - URL: http://www.gosthelp.ru/gost/ gost2011.html (дата обращения: 13.05.2015).
17. Системы менеджмента качества. Основные положения и словарь. ГОСТ Р ИСО 9000-2008 // Федеральное агентство по техническому регулированию и метрологии. - URL: http://protect.gost.ru/document.aspx?control=7&baseC=6&page
=0&month=1&year=2009&search=9000&id=174284 (дата обращения: 10.05.2015).
18. MBA в строительстве. - [Электронный ресурс]. - URL: http: //dpo .mgsu.ru/universityabout/Struktura/Instituti/IDPO/ mba/mba-v-stroitelstve/ (дата обращения: 09.01.2016).
19. BELOV M. How We Engineer Enterprise Systems // INCOSE Italian Chapter Conference on Systems Engineering (CIISE2014) Rome, Italy, November 24-25, 2014. - [Электронный ресурс]. - URL: http://ceur-ws.org/ Vol- 1300/ID 13.pdf.
20. GOUBKO M. Mechanism design and management: mathematical methods for smart organizations / Editors: M. Goubko, V. Burkov, V. Kondratyev, N. Korgin, D. Novikov. - New York: Nova Science Publishers, Inc., 2013. - P. 19 .
21. Guide to the Systems Engineering Body of Knowledge (SEBoK). - [Электронный ресурс]. - URL: http://www.sebokwiki.org (дата обращения: 13.05.2015).
22. MARCHETTA M., MAYER F., FORRADELLAS R.Q. A reference framework following a proactive approach for Product Lifecycle Management // Computers in Industry. - 2011. -No. 62(7). - P. 672-683.
23. Product Lifecycle Management (PLM) Definition // Интернет-ресурс. - [Электронный ресурс]. - URL: http://www.cimdata.com/en/resources/about-plm (дата обращения: 09.05.2015).
24. SCHUH G. ROZENFELD H., ASSMUS D. ETC. Process oriented framework to support PLM implementation // Computers in industry. - 2008. - No. 59(2) - P. 210-218.
Информационные технологии в управлении PLM-SYSTEMS FRAMEWORK
Mikhail Belov, IBS Deputy Director, Moscow, Candidate of Engineering Sciences ([email protected]).
Alexander Savich, IBS Consulting Director, Moscow, Candidate of Engineering Sciences ([email protected]).
Sergei Garichev, Moscow Institute of Physics and Technology, Moscow, Dean of Department of Radio Engineering and Cybernetics, Doctor of Engineering Sciences ([email protected]). Vyacheslav Kondratyev, Moscow Institute of Physics and Technology, Moscow, Doctor of Engineering Sciences ([email protected], +79099935660).
Denis Lytov, Moscow Institute of Physics and Technology, Moscow, Student ([email protected], +79654343116).
Abstract: Standard enterprise architectures supported by standard methodologies provide support methods for organization and coordination of engineering projects of enterprise as a whole as well as enterprise entities or enterprise subsystems [11, 17]. In [7] "Operation Systems Framework" approach is suggested as a basis for enterprise engineering.
This approach sets a compact support engineering representation of enterprise operational organization and can be used with the necessary localization to the different entities and operation subsystems of the company. For example in [J] the engineering of "Enterprise Management System" and Management Systems Framework are considered. In this article engineering of "Product Lifecycle Management" (PLM) and the PLM-systems Framework are considered.
Keywords: PLM-system, PLM-systems Framework, ontological and architectural models, quantitative models, huge hybrid models, PLM-superiority center.
Статья представлена к публикации членом редакционной коллегии Д.А. Новиковым.
Поступила в редакцию 14.05.2015.
Опубликована 31.01.2016.
