Организация виртуального предприятия по управлению и поддержке жизненного цикла изделия. Принципы, задачи, технологии Текст научной статьи по специальности «Экономика и бизнес»

УДК 62.5G:681.51

DOI 10.18698/2308-6033-2016-06-1500

Организация виртуального предприятия по управлению и поддержке жизненного цикла изделия. Принципы, задачи, технологии

О Е.И. Кузин1, В.Е. Кузин2

1 МГТУ им. Н.Э. Баумана, Москва, 1G5GG5, Россия

2 ОАО «Силовые машины», Санкт-Петербург, 195GG9, Россия

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

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

Введение. Многие полагают, что достаточно закупить современную многофункциональную систему PLM (Product Lifecycle Management), и после выполнения рутинных процедур по ее развертыванию IT-специалистами, а также освоения инженерами, проблемы создания наукоемких изделий будут решены. Однако такая точка зрения является глубоким заблуждением.

Внедрение системы PLM является следствием кардинального пересмотра стратегии предприятия по ведению своего бизнеса и способа зарабатывать деньги. На смену традиционной бизнес-модели, в соответствии с которой предприятие продает свою продукцию конечному потребителю, приходит сервис-ориентированная бизнес-модель, предполагающая продажу бесперебойного «функционирования изделия» конечному потребителю. Для реализации такой бизнес-модели требуется создать систему поддержки жизненного цикла изделия (ПЖЦИ), обеспечивающую в результате управление стоимостью ЖЦИ [1, 2].

Для построения системы ПЖЦИ необходимо следующее.

1. Для всех предприятий, вовлеченных в ПЖЦИ, разработать описание бизнес-процессов, информационных потоков, структуру взаимодействия всех участников бизнес-процессов, структуру прикладных систем и др., проанализировать функциональность, устранить избыточность и неэффективность, поскольку «переносить» плохо органи-

зованные бизнес-процессы, информационные потоки, дублирующие или устаревшие приложения в систему РЬМ недопустимо.

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

3. Проанализировать функциональные возможности, информационные потоки и способы интеграции используемого программного обеспечения.

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

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

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

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

Необходимо разработать такую архитектуру предприятия [1-4], при которой станет возможным достижение стратегической цели:

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

• получить целостное, многоаспектное детализированное взаимоувязанное описание различных сторон деятельности предприятия, обеспечивающее эффективное использование 1Т-инструментов и реализацию стратегии;

• оптимизировать в масштабе всего предприятия бизнес-процессы и 1Т-операции, что в свою очередь приводит к сокращению времени их выполнения и затрат, повышению производительности;

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

Разработкой такой архитектуры должны заниматься специалисты, обладающие инженерными знаниями, знаниями 1Т-технологий и системной инженерии. Отсутствие проработанной архитектуры неизбежно приводит к значительному затягиванию сроков внедрения системы ПЖЦИ, трудностям ее адаптации к постоянно изменяющимся условиям ведения бизнеса и исправлению обнаруженных ошибок, росту затрат и даже полному провалу проекта внедрения ПЖЦИ.

Виртуальное предприятие, обеспечивающее ПЖЦИ. Современное производство характеризуется, с одной стороны, разукрупнением и специализацией предприятий (по технологическому или предметному признаку), географическим распределением, а с другой — объединением предприятий в цепочки поставок. В создании, эксплуатации и ремонте наукоемкой продукции принимают участие большие и малые предприятия, объединенные в виртуальное предприятие (ВП) [1]. Под ВП понимают динамическую, открытую бизнес-систему, основанную на формировании юридически независимыми предприятиями единого информационного пространства с целью совместного использования своих технологических и информационных ресурсов для реализации всех этапов работ по выполнению проекта (заказа клиента) — от проектирования до сдачи продукции конечному потребителю [1, 5, 6]. ВП формирует единую организационно-технологическую и информационную среду за счет временного объединения ресурсов различных предприятий.

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

тры, конструкторские бюро предприятий, компании заказчиков, поставщиков, партнеров, эксплуатационщиков и ремонтников, т. е. объединяет участников всех этапов ЖЦИ. Пример такого ВП приведен в таблице, где приняты следующие обозначения: БКС — базовая контрольная структура; ТТ — технические требования; PMI (Product Manufacturing Information) — технические условия; LSA — анализ логистической поддержки; LSAR — база данных (БД) с результатами анализа логистической поддержки; ТС — технологический состав; ТС с ЛКН — ТС с отображенными на нем логистическими контрольными номерами; ТО — техническое обслуживание; ТР — текущий ремонт; СР — средний ремонт; КР — капитальный ремонт; ТТХ — тактико-технические характеристики; УП — управляющая программа; BPMS (Business Process Management System) — система управления бизнес-процессами; PDM (Product Data Management) — управление данными об изделии.

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

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

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

Виртуальное предприятие, обеспечивающее ПЖЦИ

Проектирование Подготовка производства Поставка комплектующих и производство Эксплуатация и обслуживание

Создание БКС Проектирование состава (ТС с ЛКН) Объемное планирование производства ТО-1

Инженерные расчеты: кинематические, прочностные, тепловые и др. Разработка сквозного ТП Оперативно-календарное планирование производства ТО-2

Разработка технологических 3Б-моделей Объемное планирование поставок материалов, комплектующих, инструмента и оснастки ТО-3

Компоновка Разработка эскизов операций Оперативно-календарное планирование поставок материалов, комплектующих, инструмента и оснастки ТР-1

Л о о (D Я 0 & 1 о (D И со Параметрическое, ассоциативное 3Б-проектирование в контексте Автоматизированный расчет норм основных материалов ТР-2

с ТТ (PMI) Автоматизированный расчет норм вспомогательных материалов Расчет плановых прямых и общецеховых затрат (по заказам и изделиям) ТР-3

S w Автоматизированный расчет норм трудо-емкостей Учет выполнения производственных операций по заданиям (нарядам) СР

Автоматизированный выбор инструмента и режимов обработки Учет перемещений материалов, комплектующих, полуфабрикатов КР

Автоматизированное проектирование УП и постпроцессоров Учет расхода материалов, комплектующих и деталей Мониторинг ТТХ и отказов

Имитационное моделирование производственного процесса Учет фактических прямых и общецеховых затрат Материаль- но-техни- ческое обеспечение ремонтов

Окончание табл.

Проектирование

Подготовка производства

Поставка комплектующих и производство

Эксплуатация и обслуживание

Н

S

САПР CAE

(NX, (An-

Catia, sys,

Pro-E, LS

SW, SE, Dyna)

Ком-

пас, T-

Flex)

LSA (...)

САПР ТП (Teamcenter Mnfg, NX CAM, Adem, T-Flex, TechCard, Вертикаль)

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

Диспетчирование

производственных

заданий

Материально-техническое обеспечение ремонтов

PDM (Teamcenter, Enovia, Союз-PLM, T-Flex, Search)

Сквозное управление бизнес-процессами — координация взаимодействия

(БРМ8)

Единое информационное пространство

Единая система управления (верхнего уровня)

Головное КБ

КБ 1

Техническое управление / Технологический институт 1

Завод 1

Ремонтное предприятие 1

С m

S W S

и

н £

£

Завод М

Ремонтное предприятие Ь

Логистическая компания 1

Эксплуатирующее предприятие 1

КБ N

Техническое управление / Технологический институт М

Логистическая компания М'

Эксплуатирующее предприятие L'

Заказчик контракта жизненного цикла

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

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

• завершению этапов разработки и введению в эксплуатацию наукоемких изделий к заданному моменту времени без превышения установленных затрат.

Следует отметить также наличие проблем вследствие неодинакового понимания представителями бизнеса и 1Т-специалистов целей ВП и способов их достижения.

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

Архитектура виртуального предприятия. Основной причиной рассогласования результатов работы 1Т-специалистов и целей бизнеса является отсутствие полного, системного, многоаспектного, формализованного описания ВП, обеспечивающего единообразное понимание представителями бизнеса и 1Т-специалистами целей, задач и способа организации всего ВП, а также путей достижения целей и методов решения задач. Такой системный взгляд обеспечивает архитектурный подход к моделированию предприятия [7-9].

Представление об архитектуре предприятия имеет свои корни в таких дисциплинах, как «Системный анализ», «Моделирование сложных систем», «Интеграция предприятия» (дисциплина, изучающая способы соединения и сочетания людей, процессов, систем и технологий таким образом, чтобы обеспечить как людей, так и процессы «нужной информацией о нужных им ресурсах в нужное время») и «Разработка программного обеспечения». Архитектура предприятия в целом является основным механизмом интерпретации и реализации целей предприятия через адекватные 1Т-инфраструктуру и системы. Это достигается путем создания определенного числа взаимосвязанных архитектурных представлений. При этом преследуют две цели. Во-первых, дать подробное, целостное и системное описание самого предприятия для поддержания порядка ее функционирования; во-вторых, иметь стратегический план развития предприятия с описанием того, как предприятие сможет эффективно достигнуть стратегических целей, перейдя из текущего состояния в будущее, с учетом существующего внешнего окружения, технической и технологической оснащенности предприятия. Поэтому архитектурная методология описывает ряд референсных архитектур — текущую, промежуточную, целевую — и применяет их для обеспечения плавного управляемого перехода предприятия в целевое состояние. Таким образом, основной задачей архитектуры предприятия является создание целостного, многоаспектного, взаимоувязанного описания функционирования предприятия, обеспечивающего син-

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

В настоящее время создано множество методов описания архитектуры предприятия. На рис. 1 приведен пример описания архитектуры предприятия по методологии TOGAF (The Open Group Architecture Framework), разработанной группой OMG (Object Management Group) [7].

Рис. 1. Архитектура предприятия TOGAF

Представленная архитектура включает в себя четыре аспекта (представления):

1) бизнес-архитектуру — определяет структуру предприятия в терминах его стратегических целей, организационной структуры, бизнес-функций, бизнес-процессов и бизнес-информации. Бизнес-архитектура показывает, каким образом могут быть достигнуты стратегические цели, и в свою очередь подразделяется на такие аспекты (представления), как стратегия, возможности (ключевые виды деятельности), поток создаваемой ценности, бизнес-знания, организационная структура;

2) архитектуру данных — содержит модели, стандарты и правила сбора данных, способы их размещения, хранения, интеграции и использования. Эта архитектура также может быть представлена контекстуальным описанием, концептуальной, логической и физической моделями, детализированным описанием;

3) архитектуру приложений — основана на функциональных и бизнес-требованиях, определяет способы взаимодействия между приложениями, базами данных, программным обеспечением среднего слоя и помогает решить проблемы интеграции приложений, а также замены устаревших пакетов, чей жизненный цикл завершен, но-

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

4) технологическая архитектура — включает в себя 1Т-инфра-структуру, программное обеспечение среднего слоя, сети, коммуникации, стандарты и др.

На рис. 2 приведена метамодель архитектуры предприятия ТООЛБ [10], которая идентифицирует все типы «строительных блоков», применяемых для описания архитектуры (приложения, сущности данных, технологии, бизнес-сервисы, участники бизнес-процессов), показывает связи, которые возможны между ними (например, между сущностями данных и использующими их приложениями, приложениями и реализующими их технологиями, участниками бизнес-про-

Принципы построения архитектуры, видение, требования к архитектуре Видение архитектуры_

Принципы построения архитектуры

Бизнес-стратегия

Технологическая стратегия

Бизнес-принципы, цели, стимулы

Видение архитектуры

Заинтересованные лица (стейкхолдеры)

Требования к архитектуре

Требования

Ограничения

Допущения

Недостающие элементы

Бизнес-архитектура

Стимулы Цели Задачи Метрики I

Оргяттттоптпитгмй аспект

Организационные подразделения Расположение Участники Роли

Функциональный аспект

Бизнес-сервисы Контракты Качество сервисов Процессы События Управляющие сигналы Изделия Функции

Архитектура информационных систем

Данные Приложения

Сущности Сервисы информационных систем

Логическая структура данных Логическая структура приложений

Физическая структура данных Физическая структура приложений

Технологическая архитектура

Сервисы платформ

Логическая структура компонентов технологии

Физическая структура компонентов технологии

Реализация архитектуры

Возможности, решения, планы по миграции

Функциональные возможности Комплекс работ Контракты на реализацию архитектуры

Управление реализацией

Стандарты Руководства Спецификации

Рис. 2. Метамодель архитектуры предприятия ТОвЛР

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

Несмотря на то, что с момента появления понятия «архитектура предприятия» прошло около 30 лет и было разработано множество подходов к описанию архитектуры предприятия, например, ТООЛБ, БоБаБ, БЕЛБ, 2аеЬшап, ЛКК [3, 7-9, 11], в настоящее время не суще-

ствует единого общепризнанного определения данного понятия. Отсутствие единой трактовки этого понятия и большое разнообразие типов организационных систем, относящихся к понятию «предприятие», привели к тому, что архитектуры, разработанные в соответствии с разными подходами, значительно различаются типами моделей и набором строительных блоков. Кроме того, не все разработанные подходы включают в себя методологии разработки построения архитектуры предприятия. Так, архитектура Захмана [11] по существу является таксономией, основана на общем словаре и наборе аспектов для описания сложной системы — предприятия. Подход Захмана не дает указаний по последовательности действий при построении архитектуры или руководства по реализации и нацелен на обеспечение полноты описания предприятия. В отличие от подхода Захмана ядром TOGAF является именно методология ADM (Architecture Development Method) — метод разработки архитектуры. К настоящему времени не сформулировано обоснование преимущества применения той или иной методологии для конкретного предприятия. Более того, консультанты по построению архитектуры предприятия рекомендуют сочетать фрагменты нескольких методологий.

Архитектурный подход позволяет получать значительные результаты, в частности, в создании ВП, обеспечивающих ПЖЦИ. Главная роль в архитектурном описании отводится бизнес-архитектуре, которая в дальнейшем отображается на другие архитектуры, например на архитектуры приложений и технологическую. Однако в настоящее время бизнес-архитектура не обладает достаточной гибкостью, маневренностью и адаптивностью в соответствии с гибкостью и маневренностью бизнеса, не обеспечивает проверки корректности разработанной бизнес-архитектуры и ее соответствия стратегическим целям. Прежде всего данные недостатки связаны с использованием императивного подхода к описанию бизнес-процессов, предполагающего алгоритмическое представление функционирования ВП в виде жесткой последовательности действий.

В описании бизнес-архитектуры в явном виде отсутствует описание стратегических целей, которые рассматриваются в лучшем случае как необязательное дополнение, что приводит к тяжелым последствиям, обнаруживаемым слишком поздно. Предлагаемые языки описания бизнес-архитектуры, например, стандарт Archimate [12], не обеспечивают формальной проверки корректности модели, описывающей бизнес-архитектуру, и соответствия стратегическим целям (их достижимости). Кроме того, бизнес-архитектура, как правило, не является рабочим инструментом, используемым бизнес-пользователями в ежедневной практике, а всего лишь описанием, созданным и поддерживаемым архитектором. В некоторых случаях это приводит к тому, что создание архитектуры превращается в самоцель для ее создателей,

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

Декларативный подход к описанию бизнес-архитектуры. Для

решения приведенных выше проблем предлагается методология описания бизнес-архитектуры, в основе которой лежит декларативный подход [13]. Описание бизнес-архитектуры представляет собой иерархическую структуру ГОБЕ(0)-подобных [14] (расширенных) бизнес-функций, описанную в предикатах математической логики дизъюнктов Хорна, включающую в себя подмножество логики предикатов первого порядка, а также лямбда-выражения. Кроме того, эта структура бизнес-функций дополнена описанием их информационных моделей, представленных в виде семантической сети. Декларативный подход обеспечивает гибкость и адаптивность, формальный аппарат логики предикатов первого порядка — автоматическую проверку не только корректности модели, но и достижимости стратегических целей. Разработанный интерпретатор позволяет сделать модель исполняемой и использовать ее в ежедневной практике непосредственно бизнес-пользователями, которые, анализируя результаты выполнения бизнес-процессов, могут оперативно вносить все необходимые изменения в модель, корректировать распределение ресурсов и, возможно, стратегические цели, проводить проверку различных управленческих решений путем имитационного моделирования.

ВП являются подклассом сложных систем, называемых бизнес-системами (БС). В процессе функционирования БС переходит из одного состояния в другое в результате выполнения бизнес-процессов. Состояние БС описывается совокупностью характеристик, к которым относятся измеримые показатели, например, KPI (Key Performance Indicators) — ключевые показатели эффективности, финансовые и экономические показатели, показатели состояния различных ресурсов (материальных, информационных, людских) и др. Эти показатели имеют иерархическую структуру. На верхнем уровне находятся интегральные показатели: финансовые, экономические, отражающие степень (процент) завершения этапа проекта, готовности наукоемкого изделия, которые затем декомпозируются по временным интервалам и по подразделениям вплоть до терминального уровня. На терминальном уровне находятся показатели степени завершения конкретных узлов изделия в конкретном представлении — электронном макете, функциональном, конструкторском или технологическом составах изделия или непосредственно степень готовности самого узла, а также состояние используемых ресурсов.

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

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

Переход между состояниями предлагается описывать с помощью бизнес-функций, в основу которых положена бизнес-функция нотации ГОЕБ(0) [14], которая преобразует входные ресурсы в выходные с использованием механизмов под соответствующим управлением. Для построения формального описания БС, характеризующейся сложной операционной семантикой, потребовалось расширение этого понятия. Прежде всего, в операционной семантике требуется формально разделить обобщающее понятие «механизмы» на следующие категории: бизнес-подсистемы (подразделения), месторасположение, персонал, технические средства. Кроме того, в нотации ГОЕБО описания всех компонентов бизнес-функции (ресурсы, механизмы, управление) являются текстовыми, что не позволяет их использовать для построения формального описания БС. Поэтому бизнес-функцию необходимо расширить за счет описания соответствующей информационной модели — семантической сети, включающей в себя все информационные объекты, участвующие в бизнес-функции, а также их свойства, в том числе вычислимые.

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

Бизнес-функция может быть описана следующим кортежем:

БГ = <Х, У, С, Б, Ь, ТЫ, М, РгеСопё, РоБЮопё, ЛЬ>,

Хуу,

[]_о

Бизнес-функция

7г

где X, У — множества входных и выходных ресурсов; С — множество целевых утверждений (задания, перераспределение ресурсов, плановые показатели и др.); В, Ь, 81/, Т1$ — описание обеспечивающих ресурсов (бизнес-подсистем, месторасположения, персонала (участники (исполнители) бизнес-функции), оборудования); 1М — информационная модель бизнес-функции; РгеСопё, Рс^Сопё, ЛЪ — соответственно начальное, целевое и аварийное состояния, выраженные в виде предусловия начала выполнения бизнес-функции, постусловия ее успешного и аварийного завершения (рис. 3).

На рис. 4 приведен пример бизнес-функции, используемой для описания бизнес-процесса согласования конструкторской документации (КД). Процессы согласования являются ключевыми бизнес-процессами ПЖЦИ. В процессе согласования принимают участие сотрудники технологического и технического бюро цеха. При поступлении электронного макета изделия (ЭМИ)

Сг\_О

и ь т

Рис. 3. Бизнес-функция

Ревизия ЭМИ

Справочник материалов

Справочник инструмента

Справочник операций

Справочник оборудования

Отчет о проблеме

Согласование КД

ЭМИ со статусом «Согласован»

Технологическое бюро цехаХ

Начальник

Цех X технологи-

ческого

бюро цехаХ

ТС

Рис. 4. Пример использования бизнес-функции

и наличии необходимой информации во всех справочниках предикат, описывающий предусловие 8^, принимает значение «истина», активируя бизнес-процесс согласования КД (циклический процесс проверок возможности изготовления детали или сборки узла). Если замечаний у согласующих нет, то ЭМИ считается принятым, создается экземпляр объекта «Статус ревизии изделия» со значением «Согласовано с технологом».

В противном случае участники создают отчеты о проблемах с изложением причин невозможности изготовления. Отчеты подключаются к ЭМИ. Наличие экземпляра объекта «Отчет о проблеме», привязанного к данному изделию и не обработанного конструктором, или наличие экземпляра объекта «Статус ревизии изделия» со значением «Согласована технологом» приводят к тому, что предикат, описывающий постусловие этой бизнес-функции принимает значение «истина», обусловливает успешное завершение бизнес-процесса, описанного этой бизнес-функцией. Управляющим сигналом является задание «Проверить изделие на технологичность», ТС (ТеатСеПег) — программная среда, в которой выполняется бизнес-процесс, описанный бизнес-функцией.

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

Заключение. Предложенный декларативный подход к описанию бизнес-архитектуры основан на логике предикатов первого порядка и лямбда-исчислении. ВП показано в виде сложной БС, для описания которой используется бизнес-функция, представляющая переходы БС между ее состояниями. Разработано формализованное описание бизнес-функции, включающее пред- и постусловия ее запуска и завершения, а также информационную модель, определяющую цели, ресурсы и весь контекст, необходимый для выполнения и анализа бизнес-процесса. Декларативный подход обеспечивает маневренность и адаптивность, используемый математический аппарат — формальную проверку корректности и достижимости целей. Управление изменяющимися бизнес-процессами и адаптацией к ним корпоративных 1Т-систем предприятия должно превратиться в «рутинную» деятельность, поскольку фактически управление предприятием есть управление его архитектурой в контексте достижения наибольшей эффективности функционирования предприятия.

ЛИТЕРАТУРА

[1] Кузин Е.И., Кузин В.Е. Управление жизненным циклом сложных технических систем: история развития, современное состояние и внедрение на машиностроительном предприятии. Инженерный журнал: наука и инновации, 2016, № 1. DOI: 10.18698/2308-6033-2016-1-1457.

[2] Кузин Е.И., Кузин В.Е. Создание интегрированной системы поддержки жизненного цикла изделия. Инженерный журнал: наука и инновации, 2016, № 2. DOI: 10.18698/2308-6033-2016-2-1458

[3] Lankhorst M., et al. Enterprise Architecture at Work: Modelling, Communication and Analysis. Berlin Heidelberg: Springer-Verlag, 2005.

[4] Minoli D. Enterprise Architecture A to Z. Boca Raton: Auerbach Publications, 2008.

[5] Cunha M.M., Putnik G.D. Trends and Solutions in Virtual Enterprise Integration. Tekhne-Review of Politechnical Studies, 2004, vol. 1 (1), pp. 143-164.

[6] Cunha M.M., Putnik, G.D. Agile Virtual Enterprises: Implementation and Management Support. USA: Idea Group Publishing, 2006.

[7] The Open Group Architectural Framework (TOGAF). Version 9.1. URL: http://pubs.opengroup.org/architecture/togaf9 -doc/arch/

[8] DoDAFArchitecture Framework. Version 2.02.

URL: http://dodcio.defense.gov/Library/DoD-Architecture-Framework/

[9] FEAF. Federal Enterprise Architecture Framework. Version 1.1. URL: https://www.whitehouse.gov/omb/e-gov/FEA

[10] TOGAF Metamodel content.

URL: http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap33.html

[11] Карпенко С. Применение модели Захмана для проектирования ИТ-архитектуры предприятия-2011.

URL: http://www.management.com.ua/ims/ims177.html

[12] Open Group. ArchiMate 2.0 Specification. The Open Group, 2012. URL: http://pubs.opengroup.org/architecture/archimate2-doc/

[13] Kuzin V., Kuzina G. CMMN Implementation in Executable Model of Business Process at Order-Based Manufacturing Enterprise. In: Proceedings of the 2013 OTM Confederated International Workshops in Lecture Notes in Computer Science, vol. 8186. Berlin Heidelberg, Springer, pp. 112-123.

[14] Методология IDEF0. Стандарт. Русская версия. Москва, МетаТехнология, 1993.32. МС ISO 9000:200033, МС ISO 9001:200034, МС ISO 9004:2000.

Статья поступила в редакцию 18.04.2016

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

http://dx.doi.org/10.18698/2308-6033-2016-06-1500

Кузин Евгений Иванович родился в 1946 г., окончил МВТУ им. Н.Э. Баумана в 1970 г. Канд. техн. наук, доцент кафедры «Системы автоматического управления» МГТУ им. Н.Э. Баумана. Автор более 10 публикаций. Область научных интересов: управление сложными техническими объектами, CALS-технологии. e-mail: evgeny.cuzin@yandex.ru

Кузин Вадим Евгеньевич родился в 1973 г., окончил МГТУ им. Н.Э. Баумана в 1995 г. АО «Силовые Машины». Автор семи публикаций. Область научных интересов: управление сложными системами, имитационное моделирование, управление бизнес-процессами.

Organisation of virtual enterprise for control and support of product life cycle. Principles, objectives, technologies

© E.I. Kuzin1, V.E. Kuzin2

:Bauman Moscow State Technical University, Moscow, 105005, Russia 2Joint-stock Company Power Machines, St. Petersburg, 195009, Russia

The article deals with the main principles of creating a virtual enterprise for control and life cycle support of science intensive high-tech products. We examined the goals and objectives of the architecture of the virtual enterprise providing the science intensive hightech product life support. We defined the main problems which appear when using existed approaches to the enterprise architecture modeling. Moreover, in this paper we propose the declarative approach to the description of the virtual enterprise architecture of the product life support. That is based on the use of the first order predicates and the calculus lambda logic and provides an automatic model correction test, strategic goals conformity and also flexibility and adaptability.

Keywords: product life support control, PLM, enterprise architecture, business process control, united information space.

REFERENCES

[1] Kuzin E.I., Kuzin V.E. Inzhenernyy zhurnal: nauka i innovatsii — Engineering Journal: Science and Innovation, 2016, no. 1.

DOI: 10.18698/2308-6033-2016-1-1457

[2] Kuzin E.I., Kuzin V.E. Inzhenernyy zhurnal: nauka i innovatsii — Engineering Journal: Science and Innovation, 2016, no. 2.

DOI: 10.18698/2308-6033-2016-2-1458

[3] Lankhorst M. et al. Enterprise Architecture at Work: Modelling, Communication and Analysis. Berlin Heidelberg, Springer-Verlag, 2005.

[4] Minoli D. Enterprise Architecture A to Z. Boca Raton, Auerbach Publications, 2008.

[5] Cunha M.M., Putnik G.D. Tekhne-Review of Politechnical Studies, 2004, no. 1 (1), pp. 143-164.

[6] Cunha M. M., Putnik G.D. Agile Virtual Enterprises: Implementation and Management Support. USA, Idea Group Publishing, 2006.

[7] The Open Group Architectural Framework (TOGAF). Version 9.1. Available at: http://pubs.opengroup.org/architecture/togaf9-doc/arch/

[8] DoDAFArchitecture Framework. Version 2.02.

Available at: http://dodcio.defense.gov/Library/DoD-Architecture-Framework/

[9] FEAF. Federal Enterprise Architecture Framework. Version 1.1. Available at: https://www.whitehouse.gov/omb/e-gov/FEA

[10] TOGAFMetamodel content. Available at: http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap33.html

[11] Karpenko S. Primenenie modeli Zakhmana dlya proektirovaniya IT-arkhitektury predpriyatiya [Application of Zachman model for the design of IT architecture of an enterprise-2011]. Available at: http://www.management.com.ua/ims/ims177.html

[12] Open Group, ArchiMate 2.0 Specification. The Open Group, 2012. Available at: http://pubs.opengroup.org/architecture/archimate2-doc/

[13] Kuzin V., Kuzina G. Proceedings of the 2013 OTM Confederated International Workshops in Lecture Notes in Computer Science, vol. 8186. Berlin-Heidelberg, Springer, pp. 112-123.

[14] IDEF0 Methodology. Standard. Russian version. Moscow, MetaTechnology, 1993.32 МС ISO 9000:200033, МС ISO 9001:200034, МС ISO 9004:2000.

Kuzin E.I. (b. 1946) graduated from Moscow State University in 1970. Cand. Sci. (Eng.), Assoc. Professor, Department of Automatic Control Systems, Bauman Moscow State Technical University. Author of more than 10 publications. The scientific interests include complex engineering products control, CALS-technology. e-mail: evgeny.cuzin@yandex.ru

Kuzin V.E. (b. 1973) graduated from Bauman Moscow State Technical University in 1995. Works at Joint-stock Company Power Machines. Author of 7 publications. The scientific interests include complex systems control, simulation modeling, business process control.