Научная статья на тему 'Конструктор PLM–систем'

Конструктор PLM–систем Текст научной статьи по специальности «Экономика и бизнес»

CC BY
1089
271
i Надоели баннеры? Вы всегда можете отключить рекламу.
Ключевые слова
PLM-СИСТЕМА / КОНСТРУКТОР PLM-СИСТЕМ / ОНТОЛОГИЧЕСКИЕ И АРХИТЕКТУРНЫЕ МОДЕЛИ / КОЛИЧЕСТВЕННЫЕ МОДЕЛИ / БОЛЬШИЕ ГИБРИДНЫЕ МОДЕЛИ / ЦЕНТР PLM-ПРЕВОСХОДСТВА. / PLM-SYSTEM / PLM-SYSTEMS FRAMEWORK / ONTOLOGICAL AND ARCHITECTURAL MODELS / QUANTITATIVE MODELS / HUGE HYBRID MODELS / PLM-SUPERIORITY CENTER

Аннотация научной статьи по экономике и бизнесу, автор научной работы — Белов Михаил Владимирович, Савич Александр Валентинович, Гаричев Сергей Николаевич, Кондратьев Вячеслав Владимирович, Лытов Денис Александрович

Стандартные архитектуры предприятия, подкрепленные стандартными методологиями, обеспечивают опорные решения для организации и координации проектов инжиниринга предприятия в целом, а также инжиниринга частных сущностей и подсистем предприятия [11, 17]. В [7] инжиниринг предприятия предложено проводить на основе подхода «Конструктор систем деятельности». Этот подход задает компактное опорное инжиниринговое представление устройства деятельности предприятия, а также может применяться с необходимой локализацией к разным сущностям и подсистемам деятельности предприятия. Так, в [5] рассматриваются инжиниринг «системы менеджмента предприятия» и, соответственно, «Конструктор систем менеджмента». В данной работе рассматривается инжиниринг «системы управления жизненным циклом продукта» и, соответственно, «Конструктор PLM-систем».

i Надоели баннеры? Вы всегда можете отключить рекламу.

Похожие темы научных работ по экономике и бизнесу , автор научной работы — Белов Михаил Владимирович, Савич Александр Валентинович, Гаричев Сергей Николаевич, Кондратьев Вячеслав Владимирович, Лытов Денис Александрович

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.
i Надоели баннеры? Вы всегда можете отключить рекламу.

Plm-systems framework

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 [5] 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.

Текст научной работы на тему «Конструктор PLM–систем»

УДК 658.5 ББК 65.050

КОНСТРУКТОР PLM - СИСТЕМ

Белов М. В.1, Савич А. В.2

(IBS, Москва) Гаричев С. Н.3, Кондратьев В. В.4, Лытов Д. А.5

(Московский физико-технический институт (ГУ), Долгопрудн ый)

Стандартные архитектуры предприятия, подкрепленные стандартными методологиями, обеспечивают опорные решения для организации и координации проектов инжиниринга предприятия в целом, а также инжиниринга частных сущностей и подсистем предприятия [11,17]. В [7] инжиниринг предприятия предложено проводить на основе подхода «Конструктор систем деятельности». Этот подход задает компактное опорное инжиниринговое представление устройства деятельности предприятия, а также может применяться с необходимой локализацией к разным сущностям и подсистемам деятельности предприятия. Так, в [5] рассматриваются инжиниринг «системы менеджмента предприятия» и, соответственно, «Конструктор систем менеджмента». В данной работе рассматривается инжиниринг «системы управления жизненным циклом продукта» и, соответственно, «Конструктор PLM-систем».

1 Михаил Владимирович Белов, зам. директора IBS, кандидат технических наук (MBelov@IBS.ru).

2 Александр Валентинович Савич, директор по консалтингу IBS, кандидат технических наук (asavich@ibs.ru).

3 Сергей Николаевич Гаричев, декан ФРКТ МФТИ, доктор технических наук (sng355@gmail.com).

4 Вячеслав Владимирович Кондратьев, доктор технических наук, профессор МФТИ (biggroup1@gmail.com, +79099935660).

5 Денис Александрович Лытов, магистр ФРТК МФТИ (derfrei@frtk.ru, + 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. Проведение онтологического инжиниринга С*.

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

Результат - словарь терминов.

Для смыслового описания системы и задания сущностных понятий и терминов С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. Эскиз МСЯ Центра РЬМ-превосходства

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

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 (MBelov@IBS.ru).

Alexander Savich, IBS Consulting Director, Moscow, Candidate of Engineering Sciences (asavich@ibs.ru).

Sergei Garichev, Moscow Institute of Physics and Technology, Moscow, Dean of Department of Radio Engineering and Cybernetics, Doctor of Engineering Sciences (sng355@gmail.com). Vyacheslav Kondratyev, Moscow Institute of Physics and Technology, Moscow, Doctor of Engineering Sciences (big-group1@gmail.com, +79099935660).

Denis Lytov, Moscow Institute of Physics and Technology, Moscow, Student (derfrei@frtk.ru, +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.

i Надоели баннеры? Вы всегда можете отключить рекламу.