Система PLM – корпоративная информационная среда предприятия по автоматизации совокупности процессов проектирования, изготовления, сопровождения и утилизации изделия

PLM – корпоративная информационная среда предприятия по управлению жизненным циклом изделия

Ирина ЛЕШИХИНА

Марина ПИРОГОВА

PLM – корпоративная информационная среда предприятия по управлению жизненным циклом изделия

∙ Что такое PLM? ∙ Место PLM в современной иерархии программного обеспечения, области применения ∙ PLM: философия или система? ∙ Стратегии PLM ∙ Структура данных и процессов в системах PLM ∙ PLM: исторический очерк и современные вендоры ∙ Применение PLM: новые преимущества ∙ Что ещё почитать (обзор интернет-литературы по вопросу)

Что такое PLM?

Существует несколько, на сегодня признанных, определений системы PLM:

В литературе можно прочитать, что PLM – это корпоративная среда информационного взаимодействия расширенного предприятия по управлению жизненным циклом изделия.

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

Русскоязычная «народная» интернет-энциклопедия Wikipedia предлалгает следующее развернутое определение: «PLM (англ. Product Lifecycle Management) — технология управления жизненным циклом изделий. Организационно-техническая система, обеспечивающая управление всей информацией об изделии и связанных с ним процессах на протяжении всего его жизненного цикла,

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

Система… Среда… Технология…

Прежде всего, давайте разберѐмся с терминологией. А заодно и с прикладной областью.

Где и когда мы чаще всего слышим это сладкое сочетание звуков ПиЭлЭм? В авиастроении, судостроении, автомобилестроении и в некоторых оборонных отраслях. То есть, в тех «индустриях», которые к настоящему времени занимаются дискретным производством сложных технических изделий в рамках глобальной кооперации и сотрудничества многочисленных компаний-соразработчиков и поставщиков узлов, агрегатов и решений [1]. Важно отметить, что этим «индустриям» надо выпускать такие изделия не массово, а широкой номенклатурой специфицированных «под конкретного заказчика» изделий. Эти отличия современной промышленности существенно дистанцируют современное производство от того, которое «породил» когда-то «конвейерный» способ Форда, который тоже производил свой знаменитый «эпохальный» Тин Лиззи Форд-Т на основе унифицированных узлов, самым дискретным (из тогда существовавших) способом и для широкого круга Заказчиков. Правда, из всех допустимых модификаций и опций тогда заказчику было предоставлено выбирать лишь цвет кузова. Причѐм – любой. Причѐм при условии, что этот любой цвет – обязательно чѐрный. Вот в этом-то – в принципиально большей «отзывчивости» современного производства на запросы рынка, на требования Заказчика, в возможности гибко настраивать выпуск именно на востребованные рынком и проработанные модификации и варианты конечного изделия – и состоит одно из принципиальных и существенных отличий современного способа разработки и производства сложных изделий от его предшественников.

Итак, сформулируем характеристики современного дискретного производства:

- Изделия по структуре своей становятся всѐ сложнее и сложнее, включают в себя не только механические, но обязательно электрические и электронные компоненты, а в последнее время ещѐ и программные (software и специализированное ПО), причѐм «вес» последних всѐ более возрастает как по стоимости, так и по затратам на разработку;

- Доля основного производителя в составе конечного изделия всѐ больше и больше сокращается (до 20% и ниже), а доля «участия» соисполнителей, сторонних организаций и предприятий-поставщиков наоборот, всѐ возрастает и возрастает (до 80% и более);

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

Исходя из перечисленных характеристик, очертим круг обсуждаемых в данной статье областей применения технологий PLM: мы будем говорить не о производстве вообще, а только о современном дискретном производстве высокотехнологичных сложных изделий. Это и будет нашей прикладной областью. Это производство нуждается в надѐжной и эффективной информационной системе, которая, естественно, должна наилучшим образом соответствовать изменениям в структуре самого производства. Иными словами, информационная система теперь предназначена обеспечить поддержку разработки и выпуска самой широкой номенклатуры самых сложных и разнотипных изделий для самого открытого сообщества кооперирующихся производителей. Желательно также, чтобы такая система была «индифферентна» к уже развѐрнутым и уже используемым на производстве локальным системам (САПР, офисный документооборот, финансы, ресурсное планирование, что ещѐ забыли?), допускала бы лѐгкое интегрирование таких локальных систем и/или имела функциональность таких систем в своѐм составе (на тот случай, когда у пользователя ещѐ или уже нет соответствующего локального информационного средства). Также желательно, чтобы такая система была открытой, то есть позволяла бы динамично достраивать/перестраивать свою функциональность с одной стороны, и динамично вовлекать в свою работу пользователей в т.ч. и из сторонних организаций (соисполнители, «восьмидесятипроцентщики») с другой стороны. Использование такой системы эффективно лишь в случае одновременного охвата всех локальных информационных потоков от всех пользователей, вовлекаемых в реальный процесс разработки, изготовления, поставки и эксплуатации конечного изделия. И это уже – не тезис, а ТЗ. ТЗ на PLM, как этот PLM понимают сегодня: охват всех этапов работы с изделием («от концептуальной проработки до утилизации») на основе единых принципов интеграции информационных процессов, систем, структур данных для осуществления эффективной организации управления жизненным циклом изделий.

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

Для современного промышленного предприятия такими «обязательными» задачами жизненного цикла изделия являются:

- Управление инженерными данными (PDM);

- Управление проектом (Project Management);

- Управление процессами производства (MPM);

- Управление взаимодействием с внешними организациями (субподрядчики, соисполнители, поставщики и и т.д. – то, что ранее называлось SCM);

- Управление требованиями и взаимодействием с Заказчиком (то, что раньше называлось CRM, а теперь к этому добавляют и RqM);

- Автоматизация управления потоком работ (Workflow Management).

Кроме этих «типовых» задач, PLM конечно же включает в себя и множество других, не так чѐтко определяемых, но эти вышеприведѐнные – те, без решений для которых, скомпонованных воедино, нет собственно PLM.

С задачами разобрались, с концепцией PLM и областью приложения – тоже, что ещѐ можно было бы «упорядочить» на уровне категорий?

Конечно же само понятие (состав, структуру) - Жизненный Цикл Изделия.

В нашей стране (как и во всех промышленно-развитых «индустриальных» обществах) для промышленных предприятий существовал его величество Стандарт для описания существенных этапов, на которые можно было разделять любую промышленную деятельность по разработке изделия. В принципе, на той стадии зрелости понятий, которая существовала в то время, такой стандарт мог бы применяться для типизации тогдашнего понимания Жизненного Цикла Изделия (ещѐ без вовлечения в это понятие таких стадий, как эксплуатация, ремонт и утилизация). Взять, к примеру, ГОСТ 2.103-68 – основной документ по регламентации разбиения на этапы процессов разработки и создания конструкторской документации. Любой инженер, прошедший суровую школу отечественных технических высших учебных заведений обязан был знать этот ГОСТ как отче наш и первое, что он узнавал на занятиях по стандартизации – это то, что начинающий конструктор должен знать, в какой последовательности разрабатывается конструкторская документация и создается новая машина (изделие). А стадии разработки конструкторской документации и этапы выполнения работ, установленные в соответствии с ГОСТ 2.103-68, включают в себя следующие:

Этап разработки технического задания. Техническое задание-это документ, который содержит наименование, основное назначение, технические требования, показатели качества, экономические показатели, предъявляемые к разрабатываемому изделию, а также необходимые стадии разработки и специальные требования Заказчика к изделию.

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

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

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

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

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

Как видно из краткого описания, стандарт, применявшийся в XX веке в отечественной промышленности, по сути так и не охватывал все этапы жизненного цикла: такие задачи, как CRM (Сustomer Relationship Management –Управление информационными потоками между Производителем и Заказчиком) и RqM (Requirements Management – Управление Требованиями) не решались на отдельных, специально выделяемых под специфику действий и информационных потоков, этапах. Всѐ многообразие и особенности послепродажного сопровождения, сервиса, обслуживания, ремонта и утилизации сложных изделий было просто скрыто в дополнительных, очень абстрактных определениях подзадач этапа рабочего проектирования. В современных условиях без учѐта, без выделения в жизненном цикле изделия таких этапов, как послепродажное обслуживание и ремонт (в любом виде), эффективно управлять всем ЖЦИ уже невозможно.

Результат: (сегодня, увы, еще не ГОСТированный,) Жизненный Цикл Изделия, рассматриваемый с точки зрения задач современного расширенного дискретного производства сложных технических изделий (корабли, самолѐты, ракеты, реактивные двигатели, автомобили…) теперь состоит из следующих этапов (см. рис.1):

- Планирование Изделия (практически, аналог ТЗ);

- Концептуальная Проработка Изделия (практически, аналог ТП и первой части ЭП);

- Проектирование (ЭП+ТП);

- Инженерный Анализ (нет точного аналога в отечественном ГОСТе – ранее задачи анализа «правильности» конструкции изделия решались всѐ чаще

выпуском прототипов и натурным экспериментом, переход к технологии моделирования и инженерному анализу характерен для последнего десятилетия XX века и в ГОСТе отражения ещѐ не нашѐл);

- Изготовление (в ГОСТе не предусмотрен отдельный этап, но учитывается необходимость информационного сопровождения процессов изготовления изделия на этапе рабочего проектирования);

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

Рис.1. Этапы Жизненного Цикла Изделия (ЖЦИ)

Итак, на основе всего сказанного, можно подытожить:

Что такое PLM? PLM – это промышленная система информационного взаимодействия расширенного предприятия по управлению всеми данными об изделии и связанных с ним процессах на протяжении всего жизненного цикла изделия. И, поскольку PLM в таком определении, – это система для всего предприятия, то именно PLM является средой, в которой и решаются все задачи управления любой рабочей информации об изделии. А поскольку для решения таких задач в такой системе должен существовать свой набор приѐмов и методов такой работы, то PLM - это и особая технология работы с данными.

Место PLM в современной иерархии программного обеспечения, области применения (различия между PLM и ERP, PLM и PDM, PLM и PM и т.д.)

Когда мы слышим (или читаем в очередном корпоративном буклете), что на том или ином предприятии развѐрнута или действует (варианты: «успешно развѐрнута», «эффективно действует») система PLM, надо чѐтко давать себе отчѐт, что под этим термином (PLM) имел в виду тот или иной автор. Особенно теперь, когда мы с вами разобрались в терминологии и прикладной области для PLM. Вообще системы управления жизненным циклом изделия часто и несправедливо путают с другими корпоративными системами, особенно часто системами PLM по ошибке называют системы PDM, системы управления

проектами (Project Management) или даже системы ERP. Давайте рассмотрим эти отличия подробнее.

Системы управления цифровым определением изделия (старое название PDM=Product Data Management, новое, скорректированное название cPDM= common Product Definition Management) в качестве объекта так же, как и системы PLM, рассматривают цифровое описание разрабатываемого изделия. Однако, в отличие от PLM в системах PDM/cPDM рассматривается эволюция этого описания в пределах этапов «Проектирования» (ЭП+ТП+РП) –«Инженерного Анализа» -Технологической Подготовки Производства (ТПП). При этом этап ТПП - конечный по сути для всех систем PDM/cPDM – охватывает не все, а только отдельные процессы этапа ―Изготовление‖ в современной классификации ЖЦИ, приведѐнной выше. Именно работа инженеров-технологов по проработке технологий формообразования (проектирование штампов и пресс-форм, литьѐ, фрезерование, раскрой, сварка и т.д.) для деталей разрабатываемого изделия и является содержанием ТПП. Не более того. Как видно из такого краткого описания, системы PDM/cPDM полностью «поглощаются» и по структуре данных и по составу процессов системами PLM. Или, как обычно говорят, PDM – это подсистема системы PLM.

Системы управления проектированием изделия (PM=Project Management) так же, как и системы PLM, охватывают все этапы разработки изделия (за редким исключением – не всегда включается этап «Сопровождение», но только не для сложных объектов). Но структура данных в системах PM не охватывает «все данные об изделии». В системах PM рассматриваются лишь специфические параметры поэтапной исполняемости проекта: сроки, риски, процент готовности, ответственные и т.д. Системы PM имеют доступ (а не управление) к актуальным 3D- данным об изделии: в лучшем случае в системах PM производится визуализация текущего состояния 3D-моделей агрегатов, узлов, проектируемого изделия в целом для того, чтобы дать самое общее представление о ходе выполнения проекта. Не более того. Как видим из такого краткого описания системы PM полностью «поглощаются» и по структуре данных и по составу процессов системами PLM. Или, как обычно говорят, PM – это подсистема системы PLM.

Системы ресурсного управления, или как их ещѐ называют: системы планирования ресурсов предприятия ERP – в последнее десятилетие стали просто обязательным компонентом любой корпоративной информационной среды. Практически нет предприятия, которое бы не установило у себя или не вписало бы в план освоения информационных технологий ту или иную ERP-систему. По сложности, по модульности состава и по охвату ERP-системы относятся к «тяжѐлым» системам корпоративного уровня. В этом они похожи на системы PLM. А в чѐм же различия? Рассмотрим функциональные области применения систем ERP. Как правило, любая современная ERP-система состоит из следующих функциональных модулей (подсистем): ведение конструкторских и технологических спецификаций, определяющих состав производимых изделий, ведение реестров материальных ресурсов и операций, необходимые для изготовления изделий; формирование планов продаж и производства; планирование потребностей в материалах и комплектующих, управление сроками и объѐмами поставок для выполнения плана производства продукции; управление запасами и закупками; обеспечение учѐта и оптимизации складских и цеховых запасов; планирование производственных мощностей; управление логистикой;

оперативное управление финансирования ресурсного наполнения производства. Системы ERP, как и системы PLM, имеют дело со структурированными данными о составе (производимого) изделия (спецификации). Только в отличие от систем PLM, системы ERP используют те же конструкторские и конструкторско-технологические спецификации в качестве исходных данных, в то время как системы PLM именно управляют такими спецификациями. Что значит здесь «управляют»? Это означает, что системы PLM ведут эти спецификации от создания через реальную разработку, через наполнение по данным, через проработку структуры самой спецификации до выпуска таких спецификаций для использования в «третьих» системах, в т.ч. и в системах ERP. В то же время системы ERP имеют свой собственный внутренний набор функций и структур данных, применяемых для специфических процессов систем ERP. К таким специфическим (отличным от процессов, охватываемых теми же системами PLM) процессам относятся в т.ч. и вышеозначенные планирование потребностей в материалах и комплектующих, управление сроками и объѐмами поставок для выполнения плана производства продукции; управление запасами и закупками; обеспечение учѐта и оптимизации складских и цеховых запасов; планирование производственных мощностей; управление логистикой; оперативное управление финансирования ресурсного наполнения производства. Вот в принципах работы с общими данными (спецификации) и в различиях охватываемых процессов и состоит коренное отличие систем ERP и PLM.

PLM: философия или система?

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

Сегодня управление жизненным циклом изделия — это, как считают теоретики развития корпоративных информационных технологий для крупной индустрии, некоторая «философия», или, если хотите, набор решений, позволяющий объединять новые внедряемые системы с уже существующими и освоенными на предприятии. Реальный опыт свидетельствует, что современная промышленность еще не готова к полной интеграции систем автоматизации инженерной деятельности, охватывающих все стороны современного промышленного производства.

Интегративной основой системы PLM служит единая модифицируемая наращиваемая структура изделия, которая применяется на всех этапах

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

Для применения систем PLM или применения философии PLM необходимо понимание современного производства как совокупности типовых процессов, представляющих на том или ином этапе жизненного цикла изделия ту или иную типовую для промышленности совокупность работ. В 2005 году аналитическая компания Boston Group по заданию ведущих разработчиков корпоративных информационных систем провела работу по формализованному представлению основных процессов, сопровождающих жизненный цикл изделия. Если ЖЦИ будет представлен так, как он изображѐн на рис.1, то типовой состав процессов будет состоять из 24 процессов, а наименование и принадлежность этих процессов можно представить в виде схемы рис.2.

Рис.2. Процессный состав Жизненного Цикла Изделия.

Стратегии PLM

В соответствии с освоенными и универсальными для различных отраслей дискретного производства, практиками, основными функциональными подсистемами системы PLM являются следующие:

- Управление инженерными данными (PDM);

- Управление проектом (Project Management);

- Управление процессами производства (MPM);

- Управление взаимодействием с внешними организациями (SCM);

- Управление (вернее, сопровождение) требованиями и взаимодействием с Заказчиком (CRM + RqM);

- Управление - Автоматизация управления потоком работ (Workflow Management).

Для выполнения работ по разработке и выпуску изделия (по проекту) обычно организуется пул сетевых ресурсов в виде портала проекта. Портал проекта – это корпоративный информационный ресурс, общее рабочее пространство, в котором участники проекта могут отслеживать ход выполнения проекта по этапам ЖЦИ, степень согласованности выполнения проекта с заранее определѐнными критериями (экспертная оценка % выполнения), риски проекта. Портал отображает результат проекта, состояние и связанные задачи, предоставляет возможность контролируемого доступа к проектной информации, даѐт возможность проводить интерактивные обсуждения и совещания. Часто индивидуальное привлечение исполнителей к работе в составе PLM, оформляется в виде портала участника. Портал участника – это персональное рабочее пространство участника проекта, в котором отслеживается личное представление определенных проектов, заданий и уведомлений (о индивидуальном задании для участия в том или ином бизнес-процессе, об окончании этапа, изменениях файла, назначении совещания и т.п.). Применение функциональности Project Management позволяет компаниям достичь существенных преимуществ [2]: - улучшить взаимодействие между различными группами, осуществляющими управление проектом на каждом из этапов жизненного цикла изделия; - существенно сократить расходы и снизить затраты на проведение совещаний, обсуждений и дискуссий по ключевым вопросам проектов, избавиться от значительных трат на командировки, поездки, аренду помещений под конференции и рабочие встречи; - сократить в целом время выхода выпускаемых изделий на рынок; - повысить качество управления проектом на всех этапах жизненного цикла.

Project Management предоставляет возможности администрирования в проектах, включая: регистрацию пользователя, создание проекта на основе готовых шаблонов и последующее автоматическое приглашение участников проекта, управление политиками доступа участников к распределѐнной системе хранения проектных данных. Project Management позволяет организовать и запускать в действие систему управления проектами.

Задача подсистемы PDM - обеспечение автоматизированного сбора данных, эффективного управления и организации доступа к информации об изделии, автоматизации проведения изменений. Подсистема PDM предоставляет доступ к библиотекам шаблонов бизнес-процедур (эталоны процессов для Workflow).

Применение пакета функциональной подсистемы PDM позволяет компаниям достичь существенных преимуществ: - сократить время разработки изделия за счѐт автоматизации процессов PDM и консолидированного Vaulting’а инженерных данных об изделии; - автоматизировать взаимодействие и распределение данных между различными группами разработчиков в соответствии с принятыми на предприятии методиками разработок и разделением труда; - улучшить документальное авторское сопровождение по выпускаемым изделиям или предоставляемым услугам; - снизить затраты на получение достоверной проектной информации; - добиться устранения временных потерь при проведении совместных проектных разработок как внутри предприятия, так и в цепи поставщиков;

- сократить в целом время предоставления выпускаемых изделий или предоставляемых услуг на рынке

Функциональная подсистема MPM обеспечивает сопровождение проектных данных об изделии на этапе изготовления. В этой подсистеме автоматизируются все те процессы, которые используют данные о структуре изделия (PDM) и предназначены для того, чтобы подготовить все необходимые данные по изготовлению изделия. Функциональная подсистема MPM управляет производственным процессом. Для информационного сопровождения изготовления сложных промышленных изделий пользователи MPM получают возможность разрабатывать маршрутные технологии безошибочно, с использованием базы знаний процессов производства и на современной основе. Использование функциональной подсистемы MPM включает в себя автоматизированное управление производственными данными, эффективное управление ими и организованный доступ к информации об изделии. Информация об изделии, получаемая из PDM-систем в виде иерархически-организованной мультиформатной информации в составе конструкторско-технологической спецификации (eBOM) внутри подсистемы MPM реорганизуется, дополняется и выдаѐтся на уровень пользовательского интерфейса в виде производственной спецификации (mBOM).

Применение функциональной подсистемы MPM в составе корпоративной системы PLM позволяет компаниям достичь существенных преимуществ: - улучшить документальное авторское сопровождение по выпускаемым изделиям или применяемым процессам изготовления; - снизить затраты на создание и распространение пооперационных инструкций для применения маршрутных технологий; - сократить в целом время изготовления выпускаемых изделий; - приступать к выпуску производственных спецификаций на самых ранних этапах жизненного цикла изделий, что в целом сокращает время выхода готового изделия на рынок.

Для организации распределѐнной интегрированной консолидированной и масштабируемой БД для управления ЖЦИ компания в настоящее время используются только распределѐнные реляционные сетевые СУБД (например, Oracle10g.)

Наиболее полно концептуальный запрос на реализацию масштабируемой, интероперабельной и платформнонезависимой корпоративной системы управления процессами и данными на протяжении всего жизненного цикла изделия применяются в виде интегрированного семейства управляющих программ с использованием Web-технологий: Java 2EE и Java Beans, Java Server Pages, Java Message Service, HTML, HTTP, HTTPS, XML, XSL, SOAP и LDAP.

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

Структура данных и процессов в системах PLM

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

Основные возможности Project Management

Рис.3. Подмножество процессов Project Management

Отслеживание всех задач, ресурсов, действий, этапов и изменений с использованием механизмов подписки и уведомлений

Централизованное хранение проектной информации Простой доступ и визуальное отображение информации, поступающей от

систем CAD/CAM/CAE (от PDM) Автоматизация управления бизнес-процессами Проведение интерактивных совещаний и форумов обсуждения

Функциональность PM [3] позволяет руководству проекта разрабатывать ход выполнения работ, назначать участников и регламентировать их права доступа. Реализация функций управления проектами даѐт возможность:

- осуществлять управление, направленное на достижение результата;

- организовывать управление с использованием готовых шаблонов проектов;

- задавать иерархию проектов;

- создавать связи между этапами и объектами проекта и управлять ими;

- осуществлять расчет стоимости и трудозатрат проекта;

- создавать отчеты по проекту, временные диаграммы, отражающие состояние выполнения проекта;

импортировать проекты из «третьих» систем (к примеру, из Microsoft Project ) и экспортировать планы, разработанные в Project Management, в «третьи» системы.

Функциональность PM предназначена обеспечивать управление большими объемами информации независимо от ее формата, типа операционной системы и местонахождения участников проекта.

Возможности по управлению информации об изделии (как в PDM, так и в PM и MPM функциональных подсистемах) включают в себя:

- хранение информации, основанное на структуре папок, и администрирование доступа к документам, деталям и папкам;

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

- использование готовых шаблонов документов;

- автоматическое управление процессами согласования и утверждения документации;

- единую систему просмотра данных независимо от формата и создание замечаний и аннотаций по ним (функция «красного карандаша»);

- отслеживание истории изменений;

- параллельное управление информацией;

- обсуждение проектной информации на форумах;

- ведение личных записных книжек для хранения любых ссылок;

- импорт/экспорт проектной информации из одного проекта в другой (в настоящее время с использованием базового формата структурирования контента XML);

- управление структурой изделия.

Основные возможности PDM.

Рис.4. Подмножество процессов PDM

Подсистема PDM позволяет:

осуществлять управление проектом в режиме реального времени; организовать эффективное взаимодействие всех участников проекта

независимо от их местонахождения; организовывать общее рабочее проектное пространство с единым

управлением ведения проекта предоставлять участникам совместно используемые средства для контроля

хода выполнения проекта по стадиям, по полноте исполнения на каждой из стадий, по рискам, по времени исполнения

сократить время, необходимое для выхода изделий на рынок, благодаря организации единого контроля над ходом выполнения проекта;

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

Функциональность PDM обеспечивает управление данными различных индустриальных САПР: Pro/ENGINEER, CATIA, AutoCAD, Inventor, SolidWorks, Unigraphics и др. PDM должен предоставлять полнофункциональный набор инструментальных средств для автоматизации управления бизнес-процессами. Инструментарий включает в себя:

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

вложенных процессов), ссылок на процессы, условных переходов, голосования, синхронизации, временных отсрочек и циклов.

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

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

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

автоматического уведомления о ключевых событиях.

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

Основные функции подсистемы PDM включают в себя следующее:

Сбор в общую базу данных и управление любыми видами информации об изделии независимо от того, в каком приложении они созданы

Интеграция со всеми основными САПР и приложениями третьих систем корпоративного уровня (например, Microsoft Office)

Автоматическое создание и назначение идентификаторов для новых деталей, сборок и документов

Связь атрибутов, файлов, схем и т.д., управление версиями деталей и документов

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

Проведение изменений в соответствии с требованиями CMII Создание отчетов о причинах проведения изменений Создание запросов на проведение изменений Уведомление о проведении изменения Механизмы быстрого (например, без затрагивания технологической

подготовки) и комплексного проведения изменений

Для интеграции с подсистемой управления потоком работ (Workflow) подсистема PDM должна располагать полнофункциональными инструментами для автоматизации управления бизнес-процессами [4], следовательно, должна включать:

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

вложенных процессов), ссылок на процессы, условных переходов, голосования, синхронизации, временных отсрочек и циклов.

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

Хранение всех данных об изделии и предоставление к ним санкционированного доступа является одной из первоочередных задач любой PDM системы. Основными источниками данных при этом являются как САПР-системы, так и офисные приложения (напр., Microsoft Office).

Интеграция с САПР: Сохранение и предоставление данных о структуре изделия, составе и визуализация трѐхмерных моделей из машиностроительных и электротехнических/электронных САПР, включая наиболее распространѐнные индустриальные САПР: Pro/ENGINEER, CADDS 5, AutoCAD, Inventor, SolidWorks,CATIA4,CATIA5, Unigraphics, I-DEAS, Mentor Graphics, Cadence и др.

«Нисходящее» проектирование: Использование «нисходящего» механизма проектирования, то есть либо предварительное создание структуры изделия и проектирования затем САПР-моделей для заполнения соответствующих предусмотренных элементов заданной ранее структуры всего изделия, либо редактирование уже полученной структуры изделия для получения на его базе нового изделия.

Интеграция с офисными приложениями (как правило, MS Office): При работе с документальным информационным наполнением необходимо использовать основные операции: поиск, запись в архив, выписка из архива и др. непосредственно в офисных приложениях (интеграция офисных систем).

Как только структура изделия, полученная в САПР-системе, сохранена средствами PDM, еѐ могут просматривать и с нею могут работать уже средствами PLM сотрудники расширенного предприятия, в том числе и на производственных участках.

Контроль версий и итераций: система автоматически отслеживает все итерации и версии документов и составных частей.

Просмотр структуры изделия: одновременное сопровождение различных представлений структуры одного и того же изделия, например, структуры «как спроектировано», структуры «как производится» и т.д.

Управление ограничениями применимости: учѐт условий применимости того или иного исполнения детали в составе конкретного изделия - по дате, по номеру заказа, по серийному номеру изделия.

Что касается ведения изменений (Engineering change Management, CM1), то функция PDM - предоставить готовый к использованию стандартный механизм управления процессом внесения изменений, который является результатом накопления наилучшей практики использования систем такого рода.

Использование функциональностей Project Management и Workflow Management, интегрированных с PDM, позволяет не только осуществлять типовые процессы CMI, но и реализовывать полноценный распределѐнный Configuration Management (CMII). Процесс внесения изменений на всех крупных промышленных предприятиях осуществляется на основе стандартизованных для предприятия процессов и, следовательно, в системе PLM (в подсистемем PDM) осуществляется на базе шаблонов Workflow , отобранных путѐм анализа лучших методик выполнения всего комплекса работ (workflow), применяемых в современной индустрии.

Основные возможности MPM

Рис.5. Подмножество процессов MPM

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

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

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

применяется MPM автоматическое уведомление о ключевых событиях.

Функциональная подсистема MPM в качестве дополнительной функциональности может использовать систему визуализации 3D-данных и механизм предварительного просмотра и аннотирования для идентификации деталей и сборок.

Основные функции MPM включают в себя следующее:

Сбор в общую базу данных и управление любыми видами информации об изготовлении изделии независимо от того, в каком приложении они созданы

Управление преобразования конструкторско-технологических спецификаций, получаемых из систем PDM, в производственную спецификацию изготовления изделия (mBOM)

Контроль целостности при реконфигурировании состава изделия из вида, определяемого eBOM, в вид, определяемый структурой mBOM.

Разработка маршрутов (процессов обслуживаниия mBOM) Интеграция со всеми основными САПР, ERP, корпоративными офисными

приложениями (напр., Microsoft Office) Создание запросов на проведение изменений (CMI) Уведомление о проведении изменения (CMI) Механизмы быстрого (например, без затрагивания технологической

подготовки) и комплексного проведения изменений (CMI) Расширенная визуализация компонент, для изготовления которых

выпускается пооперационные инструкции.

Пользователь портала MPM,таким образом, располагает полнофункциональными инструментами для автоматизации управления бизнес-процессами изготовления изделия (покомпонентное изготовление, сборка). В ходе работы с порталом MPM пользователь получает доступ к:

готовым шаблонам бизнес-процессов («эталоны», «эталонные процессы»); автоматическому распределению задач; возможности создания сложных бизнес-процессов (включая поддержку

вложенных процессов, параллельных процессов), ссылок на процессы, условных переходов, синхронизации;

расширенной визуализации, включающей в себя: множественные виды, разнесѐнные виды для сборок, простановку основных определяющих размеров, аннотирование видов.

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

Спецификации изготовления

Программы для станков с ЧПУ

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

Технические иллюстрации изготавливаемых компонент, деталей, узлов и изделия

Технические описания

Маршруты изготовления

Ведомости (рабочего места, участка, цеха, на изделие или узел и т.д.)

Расписания (временные графики изготовления)

Ведомости заготовок и расходных материалов

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

Функциональная подсистема MPM реализуется в составе порталов корпоративной рабочей среды в виде индивидуального рабочего места разработчика производственных процессов и выпуска пооперационных инструкций (портал пользователя) для работы над изготовлением и выпуском изделия. Портал пользователя, выполненный в виде MPM, предоставляет пользователю доступ ко всей необходимой информации, в зависимости от назначенной роли, выполняемых задач и прав доступа. Кроме того, данные могут предоставляться пользователям в зависимости от этапа жизненного цикла и тех задач, которые выполняются на этом этапе. Конструктивно-технологическое членение изделия в этом случае передаѐтся из какой-либо системы PDM. Конструктивно-технологическое членение воспринимается функциональной подсистемой MPM в виде электронной спецификации изделия (eBOM), после этого подсистема MPM преобразовывает спецификацию eBOM с учѐтом применимости технологий, производственных процессов и производственных связей в производственную спецификацию изготовителя (mBOM). Все доступные для различных видов документов и других объектов операции д.б. представлены в ясной и понятной форме. Эффективность применения подсистемы MPM в составе системы PLM определяется также глубиной внедрения подсистем PDM и широтой интеграции процессов применения MPM в рамках единой системы управления проектами PM.

Хранение всех данных об изделии и предоставление к ним санкционированного доступа является одной из первоочередных задач любой MPM системы. При этом основными источниками первичных данных являются как САПР-системы, так и офисные приложения (напр., Microsoft Office). Подключение возможностей управления проектами позволяет непосредственно встраивать автоматизированные процессы изготовления изделия в состав этапов и работ жизненного цикла изделия. Интеграция в составе полного комплекса решений PLM даѐт возможность перейти к качественно новому высокому уровню управления разработкой и изготовлением новых сложных технических изделий в условиях широкой кооперации и географического распределения труда («глобализация»).

Интеграция с САПР: Сохранение и предоставление данных о структуре изделия, визуализация трѐхмерных моделей из машиностроительных и электротехнических/электронных САПР, включая Pro/ENGINEER, CADDS 5, AutoCAD, Inventor, SolidWorks,CATIA4,CATIA5, Unigraphics, I-DEAS, Mentor Graphics, Cadence и др. Однако, наилучшие результаты и полнота функциональных связей достигаются при применении в качестве интеграционного механизма единой подсистемы PDM.

«Нисходящее» проектирование процессов изготовления: Использование «нисходящего» механизма проектирования, то есть предварительное создание структуры производственных процессов изготовления («маршруты») изделия, которая затем декомпозируется до пооперационных инструкций.

Интеграция с офисными приложениями (например, MS Office): необходимость и возможность использования основных операций работы с производственными документами: поиск, запись в архив, выписка из архива и др. непосредственно в офисных приложениях (например, Microsoft Office). Атрибуты документа могут быть сохранены непосредственно в базе данных PLM, что даѐт возможность пользователю производить поиск по атрибутной информации в MPM

Ассоциативность в рамках единой системы PLM подсистем PDM и MPM : появляется реальная возможность управления составом моделей, наиболее полно отвечающей возможностям Изготовителя.

Управление ассоциативностью между моделями, процессами, eBOM и mBOM, а также возможность обмена данными (mBOM и пооперационными инструкциями) с системами ERP/MES

Как только структура изделия, полученная в САПР-системе, сохранена средствами MPM, еѐ могут просматривать и с нею могут работать сотрудники, в том числе и на производственных участках предприятия.

Контроль версий и итераций: система автоматически отслеживает все итерации и версии документов и составных частей.

Просмотр структуры изделия: одновременное сопровождение различных представлений структуры одного и того же изделия, например, структуры «как спроектировано», структуры «как производится» и т.д.

Управление ограничениями применимости: учѐт условий применимости того или иного исполнения детали в составе конкретного изделия - по дате, по номеру заказа, по серийному номеру изделия.

Использование функциональности Project Management и Workflow Management в работе с подсистемой MPM позволяет на основе встроенного механизма управления процессом внесения изменений (CMI) реализовывать полноценный распределѐнный Configuration Management (CMII) уровня предприятия .

PLM: исторический очерк и современные вендоры

К настоящему времени (вторая половина первого десятилетия XXI века) как сам термин PLM, так и рынок систем PLM, уже довольно чѐтко сформировались: заказчик, как правило, достаточно хорошо себе представляет, решение какого класса задач он может автоматизировать с помощью предлагаемых на рынке систем PLM, а разработчики не менее ясно позиционируют свои разработки в той

или иной прикладной области PLM. Если обратиться к истории направления PLM, то потребность в такого рода системах объективно могла появиться только после всестороннего развития локальных коллективных автоматизированных систем разработок (CAD/CAM/CAE/CIM и т.д.). Для высокопроизводительной совместной работы многих специалистов-проектантов, инженеров-технологов и других участников любой крупной промышленной разработки необходимо было решать задачи эффективного коллективного управления данными и процессами разработки. Исторически ранее всех остальных систем корпоративного уровня наиболее развитыми IT- системами коллективного пользования при разработке сложных изделий стали САПР. Именно для промышленного применения САПР ранее всего актуализировались задачи увязки и синхронизации управления данными и процессами разработки. Такое положение дел привело к тому, что к середине 80-х годов – ко второй половине 80-х годов XX века сформировался рынок систем PDM. системы PDM были ориентированы на чѐткое и слаженное функционирование звена разработки «инженер-проектировщик – инженер-технолог», а стержнем информационной структуры данных такого взаимодействия являлась структура конструкторско-технологической спецификации (КТС). Однако, потребности современного производства не могли быть удовлетворены простой автоматизацией эффективного информационного обмена инженерными данными между конструктором и технологом. Необходимо было отстраивать информационное взаимодействие и за пределы связки «конструктор-технолог», расширять структуру данных сверх КТС. Как ни странно, инициатива такого расширения пришла совсем с другого «берега» - от военных, из НАТО. Именно необходимость эффективно сопровождать необходимой структурированной информацией эксплуатацию сложной боевой техники и вызвала к жизни активизацию разработки систем CALS – систем эффективного сопровождения, послепродажной поддержки сложных высокотехнологических изделий оборонной промышленности (танки, самолѐты, корабли, ракетные комплексы). НАТО как наднациональная структура нуждалась в унификации не только военного оборудования, вооружения, приѐмов боевого применения этого вооружения, но и в унификации процессов поддержки и сопровождения эксплуатации унифицированных единиц такого вооружения. Для рационализации применения единых приѐмов такого эксплуатационного сопровождения и были прежде всего разработаны принципы и стандарты CALS –как это вначале расшифровывалось, Computer Aided Logistic System – единая система автоматизированной поддержки эксплуатационной логистики для сложной военной техники. Основу логистической поддержки составляли автоматизированные способы определения наилучших вариантов замен деталей, узлов, агрегатов и сборок сложных изделий в условиях реальной эксплуатации. Очень скоро, впрочем, выяснилось, что чисто «военные» задачи определения самого быстрого, или самого надѐжного, или самого безопасного, или самого выгодного способа замены одной сборочной единицы какого-либо изделия на допустимый аналог даже в реальных условиях использования данного изделия очень сильно зависят от точности и глубины представления информационной модели самого этого изделия. Иначе говоря, чтобы эффективно на поле боя найти кузню, чтобы подковать коня как можно быстрее, кроме собственно кузни на поле боя надобно было как можно точнее определить параметры подковы, гвоздя и технологические ресурсы самой кузни. То есть, чтобы эффективно выполнять логистические задачи для сложных изделий боевой техники, необходимо было иметь полное электронное определение самой этой техники. Такое информационное наполнение существенно упрощало анализ допустимых замен, поиск и учѐт взаимозависимых компонент, расчѐт результативных действий и т.п. Как раз на практике военной

глобальной эксплуатации сложных изделий выяснилось, что послепродажное сопровождение существенно и во многом определяется информационной полнотой описания самого этого изделия. Работы по инициативе CALS определили, что успех долговременной эксплуатации оборудования и изделий тем достижимее, чем доступнее полная информация об изделии. Чем раньше и чем полнее эксплуатационные структуры получат доступ к инженерным данным, тем лучше, качественнее, быстрее и рациональнее будет выполняться само сопровождение (эксплуатация+ремонт). Кстати, как известно, такое осознание привело к тому, что сокращение CALS претерпело существенное изменение в «расшифровке» - с начала 90-х годов XX века эти буквы означали «Continuous Acquisition and Lifecycle Support» — непрерывная информационная поддержка поставок и жизненного цикла изделия. Итак, со стороны кругов, вовлекаемых в применение CALS, недвусмысленно и ясно к середине 90-х годов XX века поступило подтверждение того, что необходимо наличие интеграции и по структуре данных и по их полноте между процессами эксплуатации и результатами процессов разработки-изготовления. То есть, в рамках полной автоматизации поддержки ЖЦИ инженерные проектные данные сохраняют свою ценность и за пределами конструкторско-технологических процессов разработки. Разработчики промышленных САПР-PDM и ведущие IT-аналитические государственные и международные институты к этому времени создают некоммерческий надгосударственный совет по проблеме поддержки ЖЦИ – PLCS. Концепция PLM наиболее естественно и полно отвечает запросам такого тотального охвата процессов и структур данных о сложных промышленных изделиях. Если же говорить о собственно аббревиатуре PLM, то, как гласит неофициальная легенда, бытующая в среде специалистов по этому направлению, «автором» самого термина и одновременно разработчиком одной из самых первых систем PLM является нынешний руководитель компании PTC, еѐ президент и COO Джеймс Е. («Джим») Хеппельманн. Во время работы в компании Methaphase в секторе передовых разработок (одна из таких его разработок впоследствии была реализована в форме проекта «Windchill») он предложил в официальной отчѐтной документации по передовым разработкам вместо термина «расширенный cPDM» использовать сокращение PLM. Современный рынок PLM оценивается на уровне 12-16 миллиардов $ в год с ежегодным гарантированным приростом в 10%. Как правило, аналитические компании, дающие оценку на этом уровне, в понятие «рынок систем PLM» включают также PDM-системы, САПР системы, системы инженерного анализа, системы PDM, CRM и SCM как корпоративного, так и уровня SMB. Если же говорить только о компаниях, непосредственно предлагающих на рынке системы PLM для промышленного использования в крупной дискретной промышленности, то по результатам закончившегося года здесь представлены три ведущие компании - . Dassault Systèmes (с долей рынка в $1.7 миллиарда), Siemens PLM Software (бывш. UGS) (с долей рынка в $1.4миллиарда ) и PTC (с долей рынка в $1 миллиард). Обычно к этой «большой PLM-тройке» добавляют ещѐ три компании – это Oracle, Autodesk и SAP. Однако, ни для Oracle, ни для Autodesk, ни для SAP PLM не является основным бизнесом, в то же время все они специализируются совсем в других областях. В любом случае, доля рынка «чистого» PLM, приходящаяся на эту тройку, существенно ниже любой из доли первой «большой» тройки.

Рассмотрим состояние основных продуктов семейства PLM от основной тройки поставщиков таких систем для потребителей дискретной промышленности (перечисление производится в алфавитном порядке и никакого рейтингового значения этот порядок не имеет). Dassault Systemes. Компания Dassault Systemes традиционно предлагает на рынке PLM несколько различных программных решений. Все они «сведены» под единым брендом ENOVIA, хотя на самом деле отдельные программы внутри этого бренда являются независимыми пакетами. Собственно разработкой самой Dassault Systemes, полностью воплотившей в себе все базовые идеи и инновации подхода PLM, исповедуемого в Dassault Systemes, является ENOVIA VPLM. Компания Dassault Systemes определяет область применения для такой полноценной системы PLM: «крупные распределѐнные промышленные предприятия, транснациональные корпорации, занятые выполнением крупных индустриальных проектов». Для задач менее амбициозных, то есть для подавляющего большинства отечественных промышленных проектов, компания Dassault Systemes предлагает популярную PLM-систему ENOVIA SmarTeam (бывш. SmarTeam). Пакет SmarTeam был приобретѐн компанией Dassault Systemes вместе с группой разработки и теперь распространением и развитием пакета занимается Dassault Systemes. Несмотря на то, что ENOVIA SmarTeam и ENOVIA VPLM – это два различных пакета, основанных на различных подходах и программных ядрах, тем не менее, компания Dassault Systemes объединяет их в одно общее семейство – семейство решений PLM для широкого спектра предприятий: от самых мелких до самых крупных. За последние три года компания Dassault Systemes сделала ещѐ один важный и крупный шаг в развитии своих возможностей PLM: ею была приобретена наиболее перспективная и одна из самых современных PLM-платформ – MatrixOne. В предыдущие годы неизменно MatrixOne в рейтингах и рингах индустриальных систем PLM занимала места не ниже третьего-пятого. Теперь MatrixOne – составная часть стратегической «триады» Dassault Systemes и переименована соответственно в ENOVIA MatrixOne. В отличие от ENOVIA VPLM и ENOVIA SmarTeam новинка в триаде – ENOVIA MatrixOne - расчитана на все рыночные ниши: от отдельных SMB-предприятий до транснациональных корпораций. ENOVIA MatrixOne таким образом устраняет наиболее болезненный аспект использования предыдущих ENOVIA-решений: невозможность масштабирования единожды применѐнных методик выбранного решения ENOVIA при переходе от уровня SMB к более высокому уровню проектов. Если ранее, до приобретения MatrixOne, у пользователя был очень ограниченный выбор: либо развѐртывать ENOVIA SmarTeam и таким образом ограничивать развитие PLM уровнем среднего предприятия (максимум), либо изначально, рассчитывая на крупный корпоративный (глобальный) характер PLM, «вложиться» в развѐртывание ENOVIA VPLM. Никакой эффективной, быстрой, практически освоенной и тиражируемой методики рационального перехода от уровня SmarTeam на уровень полномасштабного PLM в рамках «старой» ENOVIA компания Dassault Systemes не предлагала. Видимо, именно отсутствие такой методики и высокая начальная стоимость развѐртывания ENOVIA VPLM, и явились причиной практического отсутствия внедрений ENOVIA VPLM в России: строго говоря, до последнего времени все успешные отечественные внедрения PLM-технологий от Dassault Systemes – это именно внедрения SmarTeam. ENOVIA SmarTeam - на всех предприятиях: от мелких и средних – до самых крупных. Мы в России практически не имеем никаких крупных проектов внедрения именно ENOVIA VPLM. Видимо, это в том числе связано и с тем, что раньше не было иной

альтернативы применения ENOVIA VPLM, кроме как «эволюционировать» с более «простой» и освоенной отечественными предприятиями ENOVIA SmarTeam. Иное дело теперь: если предприятие опирается на принцип развѐртывания системы PLM «от простого – к сложному‖, и при этом оно ориентируется на решения от Dassault Systemes, то в отличие от предыдущих дет, когда рано или поздно надо было совершать затратный и трудоѐмкий переход с ENOVIA SmarTeam на ENOVIA VPLM, теперь такое предприятие может выбрать «третий» путь – применять масштабируемое решение ENOVIA MatrixOne.

Рис.6. Области применения PLM-решений от компании Dassault Systemes PTC Компания PTC изначально сделала ставку на масштабируемую систему PLM и в 90-х годах прошлого века отказалась от экстенсивного развития любой из своих «старых» систем PDM и пошла «радикальным» путѐм – финансировала разработку полнофункциональной системы PLM «с нуля». На практике компания PTC выкупила «на корню» группу разработчиков перспективных систем и бета-версию перспективной корпоративной системы PLM у компании Methaphase. Это и был прототип современной системы Windchill. Изначально, поскольку проект Windchill не был компиляцией различных подсистем, он выполнялся как масштабируемая открытая Web-центрическая система. Изначально Windchill не был интеграцией разнотипных подсистем и такой подход позволил принципиально избежать многочисленных проблем, которые возникают сейчас у других вендоров. Внедрение Windchill может быть выполнено сначала в рамках SMB, а потом та же

инсталляция Windchill может быть расширена («масштабируема») до любого уровня сложности и полноты функционала. При этом не надо менять само программное обеспечение – Windchill не различается, он один и тот же как для малых-средних предприятий, так и для крупных межнациональных производственных объединений на проектах любой степени сложности. Для увеличения функциональной мощности и наращивания охвата необходимо всего лишь добавить к уже существующей инсталляции Windchill дополнительные лицензии добавочных рабочих мест. В настоящее время концепция дальнейшего развития системы PLM компании PTC базируется на фиксированном понимании и функциональном разграничении корпоративных задач, возникающих в процессе разработки и создания новых сложных изделий. Эта концепция в компании PTC называется PDS – Product Development System. На рис.7 представлена в самом общем виде структура функциональностей, которые должны быть реализованы в любой корпоративной системе PLM, направленной на разработку изделий дискретного производства. Эти функциональности сгруппированы в соответствии с концепцией PDS компании PTC в пять основных подмножеств. В таком виде все возможные задачи, возникающие на любом из этапов жизненного цикла изделия, попадают в то или иное подмножество. А внутри каждого из подмножеств частная задача решается конкретным функциональным модулем. На рис.8 представлено программное соответствие элементам этой структурной модели PDS модулей, разрабатываемых компанией PTC. Как видно из этого сопоставления, основное большинство задач PLM выполняется в модулях Windchill.

Рис.7. Структурно-функциональная модель PTC для построения системы PLM. Основные функциональные области, выделяемые компанией PTC в процессах разработки промышленного изделия, это: - создание контента (проектных данных), -организация совместных проектных работ, -управление разнотипным контентным наполенением проекта,

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

Рис.8. Соответствие модулей ПО компании PTC элементам структурно-функциональной модели PLM (см. Рис.7.) В последние 8-9 месяцев компания PTC неожиданно выступила с новшеством, которое на первый взгляд идѐт вразрез с теми принципами, которые изложены выше: компания заявила о разработке и выпуске на рынок «параллельной» системы PLM для задач малого и среднего бизнеса. То есть, в секторе SMB компания PTC параллельно с уже присутствующим здесь своим продуктом Windchill стартует проект распространения «лѐгкой» системы PLM – Windchill ProductPoint. Итак, компания PTC, известная своей приверженностью к концепции «монокультуры» в PLM и добившаяся наиболее известных успехов как раз на ниве применения унифицированной масштабируемой универсальной системы PLM, совершает отход от своих принципов и «распыляет» ресурсы разработки, начиная сопровождать и распространять уже две системы PLM? Как следует из пресс-релизов компании, в данном случае выпуск на рынок SMB-пакета PLM системы Windchill ProductPoint – ответ на требование рынка и в какой-то мере – следование новомодным тенденциям. С одной стороны, рыночная ниша PLM для SMB слабо реагировала на многочисленные разъяснения PTC о том, что Windchill – не только система для индустриальных монстров. «В народе» как-то издавна, ещѐ с «прошлого века», за Windchill'ом закрепился ярлык системы PLM для Lockheed'а и Airbus'а. То есть, некоего программного мастодонта для промышленных элефантов, не для простых смертных. И при этом подразумевалось, что только такого масштаба элефантам под силу обуздать мощь такого мастодонта. Видимо, устав бороться с такого рода заблуждениями и не желая всѐ же терять нишу SMB, компания PTC наступила на горло собственной песне о масштабируемости, унификации, открытости и т.д. и выпустила на

потребу «заблуждающейся индустриальной SMB-публике» отдельный пакет – Windchill ProductPoint. Как и в случае с брендингом систем PLM от Dassault Systemes и от Siemens PLM Software (которых, подчеркнѐм, компания PTC как раз и упрекала за это), компания PTC просто «присвоила» наименование Windchill совсем с Windchill'ом ни генетически, ни идеологически не связанному пакету. Это если посмотреть со стороны рынка. А со стороны идей, тенденций и моды в распределѐнных сетевых информационных технологиях ко второй половине первого десятилетия XXI века стала очень популярной технология SharePoint от Microsoft. Вот именно на этом «модном» ядре и с использованием концепции PDS и был разработан Windchill ProductPoint. Итак, со стороны разработчиков из PTC выпуск Windchill ProductPoint – скорее дань моде, чем следование их же собственной концептуальной парадигме PLM (читай PDS) . Так, по крайней мере со стороны, выглядит факт выхода на рынок Windchill ProductPoint. Компания PTC утверждает, что на ближайшее будущее в качестве одной из главных выдвигается задача конвергенции «чистого» Windchill и Windchill ProductPoint, однако на сегодняшний день (конец 2009 года) дело обстоит так: в секторе SMB компания PTC предлагает два отдельных продукта: традиционный Windchill со всей его недюжинной мощью и новомодный, ориентированный только на рынок SMB, MS SharePoint’овый Windchill ProductPoint. И раз уж мы упомянули рынок, влияние его настроений в разговоре о системах PLM, то нельзя не упомянуть ещѐ одну рыночную PLM-инициативу от компании PTC, которая должна была бы по идее «оттянуть» на себя SMB-скептиков, не поступаясь при этом концептуальной PDS-девственностью чистого Windchill'а – «PLM по запросу», инициативу Windchill-on-Demand. Ведущие аналитики в первой пятилетке XXI века неоднократно отмечали: проникновение Windchill на рынок SMB существенно тормозит широко бытующее на этом самом SMB-рынке мнение, что для развѐртывания и внедрения PLM решений на базе Windchill от предприятия требуется наличие высококвалифицированного IT-персонала, высококачественной техники и СУБД для организации Vaulting'а. На этих трѐх китах – высокой культуре распределѐнных сетевых IT + техники высокой степени готовности + СУБД первого ряда (Oracle и SQL Server) – как раз и покоился технологический PLM-приоритет Windchill. И именно эти три фактора и были сдерживающими в деле завоевания Windchill'ом рынка SMB: какое малое предприятия даже для задачи автоматизации PLM, решится «по-взрослому» вложиться в инфраструктуру, системное администрирование и высокопроизводительную серверную группировку? Решение к PTC пришло от почти что конкурентов: компания IBM, развивая родственную Windchill'у идею о сервисно-ориентированной архитектуре информационных ресурсов, вышло с предложением предоставить свои ресурсы как сервисную платформу для развѐртывания «безразмерного» мультиинстанционного Windchill на технике самого высокого уровня (вероятность безотказной работы 0.999999 – недоступные никакому «простому смертному» заветные «шесть девяток»). Сетевой доступ гарантировался в режиме 24x7x365 с заказной пропускной способностью вплоть до гигабитного диапазона, обслуживание ресурсов и поддержание функциональности выполнялось специалистами IBM. А заказчику предоставлялась эта самая функциональность в виде аренды соответствующих сервисов (рабочее место PDM или Project Management) Windchill на базе возобновляемой годовой аренды, «проката» этих ресурсов. Напомним: Windchill – это Web-центрическое решение, следовательно, пользователю для доступа к функциональности PLM в Windchill надо всего лишь иметь Web-доступ к сервисам Windchill. Независимо от того, где «физически» эти сервисы реализованы. В случае Windchill-on-Demand за годовой взнос в сотню долларов за место или

около того пользователь получал сетевой доступ к полнофункциональному Windchill, который он сам мог реконфигурировать «под себя», использовать его возможности по Vaulting'у, ведению проектов и распределению заданий в коллективе. При этом с пользователя полностью снимались заботы по найму высококвалифицированного системного и сетевого персонала, пользователь освобождался от выполнения закупки и установки СУБД первого ряда и практически отпадала необходимость аренды спецпомещений под IT: всѐ, что ему оставалось – это иметь интернет-сетевой доступ к сервисам Windchill-on-Demand на ресурсах IBM (а за них он уже заплатил). И всѐ. Чистая SOA- чистый мобильный PLM. Вся тяжѐлая высокозатратная профессиональная работа по обслуживанию собственно системы PLM берѐт на себя IBM, используя при этом свои «безграничные» ресурсы, а пользователь только должен надлежащим образом (то есть, в соответствии со своими приѐмами работы в проектах) подписать своих проектных инженеров и менеджеров к этим ресурсам. Казалось бы – чем не решение? Удалѐнный PLM по подписке. Однако, распространившись на рынке SMB в Америке, Азии и Европе, такой «Windchill напрокат» не нашѐл понимания в России. Причина банальна: какой же отечественный SMB-разработчик «отважится» передоверить зарубежной, более того – американской, компании хранение своих проектных технических «секретов»? И никакие заверения о конфиденциальности предоставления такого рода сервиса или проприетарности такого рода обслуживания или о технических приѐмах защиты интернет-каналов связи, которые распространяла компания PTC, не сыграли никакой значимой роли. Факт: с 2005 года в России ни один из проектов Windchill-on-Demand так и не вышел на стадию практического применения. Кроме всего прочего – неуспех такой прогрессивной формы распространения функциональности PLM на рынке SMB был среди прочего одной из значимых причин старта работ по Windchill ProductPoint. Siemens PLM Software Системы PLM от подразделения PLM Softwarfe концерна Siemens – это по сути дальнейшее развитие плодотворного наследия компании UGS. Решения PLM компании UGS исторически развивались как составной комплекс различных программных систем, специализированных в той или иной функциональной области PLM. Также «исторически» разработчики этих отдельных PLM-компонент общего PLM-решения принадлежали не только к разным концептуальным направлениям в PLM, не только к разным программистским школам, но (опять же в исторической ретроспективе) и разным компаниям. Так PDM-ядро всех современных решений от Siemens PLM Software - это прекрасно зарекомендовавший себя на практике PDM-пакет для САПР UG, генетически восходящий к знаменитому iMAN от Unigraphics конца 90-х годов XX века. А решатель задач ведения проектов - это развитие того, что осталось от PLM-систем в компании Metaphase, когда из неѐ «выдрали» Windchill и когда саму компанию Metaphase поглотила компания UGS. Собственно PLM-система от Siemens PLM Software – это бренд Teamcenter, а сам Teamcenter «в прошлой жизни» - это пакет ведения проектов с тем же названием от компании I-DEAS, приобретенной вместе с самыми передовыми их решениями опять же компанией UGS. Если взглянуть на модули (читай: специализированные программные пакеты) системы PLM от подразделения PLM Softwarfe концерна Siemens, то все они сведены под единым брендом Teamcenter. Однако, всѐ семейство «распадается» на две группы (не функциональные, а по исторической принадлежности): одна группа восходит к расширенному PDM середины XX века

от компании Unigraphics, а вторая – к аналогичному семейству от компании I-DEAS (см. Рис.9.).

Рис.9. Структура PLM-семейства решений Siemens PLM Software Задача компании Siemens PLM Software при этом – провести интеграцию всех этих семейств и отдельных модулей наиболее эффективным и высокопроизводительным способом. Тут мы имеем третий способ решения задачи построения высокопроизводительной системы PLM: интеграция заранее отобранных «лидеров» по функциональным PLM-направлениям. Напомним читателю: Dassault Systemes предоставляет пользователю на выбор одну из трѐх систем ENOVIA (без какой-либо интеграции между ними), PTC до последнего времени предоставляло универсальный инструмент реализации системы PLM любого уровня и любой функциональности – проинтегрированный изначально Windchill. В случае Teamcenter от Siemens PLM Software необходимо было решить задачу интеграции функциональных модулей, причѐм решать еѐ не в рамках концепции всей системы в целом (как в случае с Windchill), а выполнять еѐ для уже готовых и опробованных отдельных решений. Но выполнять обязательно (в отличие от подхода Dassault Systemes) – иначе нет речи о «семействе PLM-решений Teamcenter». Если посмотреть на структуру самих составляющих решение модулей, то видно, что они разрабатывались часто не только в различных языковых средах (C, C++, Tcl/Tk, Java, специализированные языки разработки серверных приложений), но и с применением различных стилей и методик программирования (.Net, J2EE, использование клиент-серверной модели). Такой «разнобой» составляющих значительно осложнил задачу интеграции для специалистов компании Siemens PLM Software, но они тем не менее успешно решили еѐ в основном и за основу опять же взяли готовое опробованное интеграционное решение от тогог же I-DEAS – функциональность Teamcenter Integrator. В полном соответствии с царящими ныне тенденциями в разработке корпоративного, распределѐнного, многопользовательского платформно-

независимого программного обеспечения, компания Siemens PLM Software использовала подход и платформу J2EE для расширения интеграционных возможностей Teamcenter Integrator. Как готовое решение по интеграции отдельных пакетов в систему PLM семейство Teamcenter было представлено на рынке уже к 2005 году. Однако, к 2007 году назрела необходимость для того, чтобы считаться полностью «PLM» системой, дополнить Teamcenter MPM-составляющей. По «традиции» компания Siemens PLM Software выбрала одного из лидеров рынка автоматизации технологической подготовки производства – компанию Technomatix c одноимѐнным решением и приобрела возможность дальнейшего развития предоставляемой Technomatix функциональности MPM в Teamcenter. И в соответствии с уже опробованной методикой – проинтегрировать Technomatix в Teamcenter. Поскольку само решение Tеchnomatix разрабатывалось (как и все остальные составляющие Teamcenter) вне рамок интеграционного процесса и правил интеграции Teamcenter, то задача интеграции выполнялась практически «с нуля» и эффективность данного частного решения обуславливалась только опытом интеграторов, но не готовыми и опробованными интеграционными средствами самого Teamcenter. Тем не менее, после успешной интеграции Technomatix в систему Teamcenter последняя примет вид законченной промышленной PLM-системы. ∙ Применение PLM: новые преимущества

Основные современные поставщики PLM-решений исповедуют расширение применимости своих систем однозначно как расширение охватываемых PLM-системами процессов, вовлекаемых в ЖЦИ. И если в части поддержки на этапах эскизного, технического и рабочего проектирования, на этапе технологической подготовки производства и собственно производства основные вендоры конкурируют уже не в теоретической, а в практической области, то в том, что касается поддержки на этапах продаж и послепродажного сопровождения пока что ещѐ нет устоявшегося подхода. Это означает, что каждый вендор идѐт своим путѐм, предлагая своѐ видение (и, соответственно - своѐ программное решение) интеграции решений для завершающих этапов ЖЦИ в единую системуPLM. При всѐм разнообразии подходов, основной задачей, которую в первую очередь пытаются решить поставщики PLM-решений, является задача качественного точного информационного сопровождения эксплуатации конечного изделия. В настоящее время нельзя говорить о поставке сложных технических изделий без качественного сопровождения таких поставок высококачественной техдокументацией. Качественная (локализованная под Заказчика, структурированная, точно отражающая поставленное изделие, полностью отвечающая процедурам эксплуатации и т.д.) техническая документация стала реальной ценностью и тем ценнее, чем сложнее само конечное изделие. Таким образом, к основным задачам «классического» PLM сейчас добавляется ещѐ и задача TPM – Technical Publishing Management (управление подготовкой и выпуском технических публикаций).

Рис.6. Подмножество процессов TPM

Объектом TPM являются многочисленные типизированные технические публикации: эксплуатационные документы, руководства, справочники пользователя, инструкции по обслуживанию, ремонту, использованию. Функциональная подсистема TPM обеспечивает необходимой информацией по эксплуатации поставляемого изготовителем конечного изделия.Информация, представленная в технических публикациях, поставляется конечному пользователю (разработчиком конечного изделия) в зависимости от функций, обязанностей, задач и роли конечного пользователя в процессах эксплуатации изделия. Информация выдается пользователю в наиболее удобном для восприятия виде и в наиболее доступных форматах. С точки зрения PLM новая функциональная область – TPM – всего лишь дополняет общий информационный поток данных об изделии, закрывает спектр процессов, составляющих поддержку ЖЦИ, дополняя стадии разработки и производства стадиями эксплуатации, ремонта и утилизации. Таким образом, теперь, с включением функциональности TPM, PLM на деле становится наиболее универсальным и результативным подходом к унификации и стандартизации информационного сопровождения всего того, что связано со сложным современным высокотехнологичным изделием: от разработки концепции и до утилизации. Что и составляет Жизненный Цикл Изделия.

∙ Что ещё почитать (обзор интернет- литературы по вопросу)

Day, Martyn (2002.04.15). "What is PLM". Cad Digest. http://www.caddigest.com/subjects/PLM/select/day_plm.htm.

Hill, Sidney (2006.12.01). "A winning strategy". Manufacturing Business Technology. http://www.mbtmag.com/current_issues/2006/sept/coverstory1.asp?CategoryID=66.

Teresko, John (2004.01.02). "The PLM Revolution". IndustryWeek. http://www.industryweek.com/CurrentArticles/Asp/articles.asp?ArticleId=1558.

Goul, Lawrence (2002.06.05). "Additional ABCs About PLM". Automotive Design and Production. http://www.autofieldguide.com/articles/120506.html.

Sidney Hill, Jr., "How To Be A Trendsetter: Dassault And IBM PLM Customers Swap Tales From The PLM Front", retrieved on March 28, 2008.

CIMdata official reports (2006-10-11). "Comprehensive Information and Analysis of the PLM Market". Press release. http://www.cimdata.com/news_events/press_release.html?press_release_ID=30.

Daratech (2006-03-13). "PLM Market Projected to Reach $12 Billion in 2006, Up 14%". Press release. http://www.daratech.com/press/releases/2006/060313a.html.

Заключение

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

Об авторах:

ПИРОГОВА М.А. – к.т.н., доцент Московского Энергетического Института (Технического Университета), antikgb@rambler.ru

ЛЕШИХИНА И.Е. – к.т.н., доцент Московского Энергетического Института (Технического Университета),

Список использованных источников

1. Antti Saaksvuori. Product Lifecycle Management: ISBN: 3540781730; - Springer; 3rd ed. edition (May 9, 2008). - 253 pages

2. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) - Fourth Edition, PMI, 2008. – 459 pages

3. Wil M.P. van der Aalst, "Business Process Management Demystified: A Tutorial on Models, Systems and Standards for Workflow Management", Springer Lecture Notes in Computer Science, Vol 3098/2004.

4. Layana Fischer. 2009 BPM & Workflow Handbook. Methods, Concepts, Case Studies and Standards in Business Process Management and Workflow.ISBN: 978-0-9777527-9-9. WfMC, 2009. – 300 pages.