П.В.Стрелков , директор по корпоративным проектам , Д.А Козаченко , директор по маркетингу (Pro|TECHNOLOGIES)

Предисловие 

Предлагаем вниманию читателей четвертую статью из цикла, посвященного одному из крупнейших в Восточной Европе проектов внедрения PLM на предприятиях Индустриальной группы “Украинская промышленно-энергетическая компания” (ИГ УПЭК). 
В первой статье (Observer #7/2010) был дан общий обзор проекта, описана схема организации работ и методология внедрения. Во второй статье цикла (#1/2011) мы более подробно рассказали об одном из первых этапов проекта – внедрении CAD/CAM/CAE-системы Pro/ENGINEER и создании электронного архива в среде Windchill. Третья статья (#3/2011) была посвящена вопросу автоматизации технологической подготовки производства в интегрированной среде Windchill – САПР ТП ВЕРТИКАЛЬ. 
Нынешняя, четвертая по счету публикация (рис. 1), нацелена на освещение вопроса интеграции систем PDM и ERP. Материал подготовлен на основе реального практического опыта нашей компании, полученного в ходе успешно завершенного внедрения комплексной системы автоматизации в УПЭК.

 

рис.1 Планируемый цикл статей, посвященных проекту внедрения PLM на предприятиях ИГ УПЭК 

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

Мы решили продолжить эксперименты с различными стилями изложения материала, и на этот раз предлагаем вам, уважаемый читатель, статью в форме “Вопросы и ответы” – то, что обычно называют FAQs (Frequently Asked Questions) или ЧаВо (часто задаваемые вопросы). На наш взгляд, такой формат позволяет представить максимум полезной информации в минимальном объеме. В данном случае это особенно актуально, учитывая богатый опыт Pro|TECHNOLOGIES и, соответственно, большой объем ценных сведений, которыми нам хотелось бы поделиться с вами. 

Итак, начнем! 

FAQs по теме интеграции PDM-ERP 

Перед тем как подробно отвечать на вопросы, перечислим их:

• Почему так мало реально работающих решений по интеграции PDM-ERP?
• А нужна ли такая интеграция вообще? В чём её ценность для предприятия?
• Какие ключевые требования предъявляются к интеграционному решению?
• В чём должна заключаться интеграция?
• Двухсторонняя или односторонняя интеграция?
• Типовой состав передаваемых данных?
• Какие варианты обмена данными существуют? Какой вариант предпочтительнее?
• Часто можно услышать: “наша система может быть интегрирована с чем угодно”. Это правда или маркетинговый ход?
• Бывают ли интеграционные решения “коробочными продуктами”? То есть, могут ли они работать по принципу “установил – и всё заработало”?
• Что конкретно было сделано для УПЭК?
• Каковы сроки создания интеграционного решения?
• Есть ли у Pro|TECHNOLOGIES опыт интеграции с ERP-системами на других предприятиях?

Почему так мало реально работающих решений по интеграции PDM-ERP? 
Действительно, если говорить про российские предприятия, то очень мало где мы можем увидеть промышленно эксплуатируемое решение, интегрирующее PDM и ERP. На то есть несколько объективных причин. 

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

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

И, наконец, третья важнейшая составляющая. Предположим, у нас есть действующие PDM- и ERP-системы, функционал которых задействован в необходимом объеме. Возникает вопрос наполнения этих систем данными. По большому счету, для промышленной эксплуатации PDM-системы достаточно некоторой ограниченной базы данных по стандартным и нормализованным деталям и материалам. Если, начиная с момента передачи PDM-системы в промышленную эксплуатацию, все новые разработки ведутся в её среде, то этого, на первый взгляд, вполне хватает. Но не для интеграции с ERP! Ведь предприятие производит не только новые изделия. Основной объем – это номенклатура, которая была освоена достаточно давно, и, соответственно, не попала в базу данных PDM-системы. Поэтому, возникает вопрос наполнения PDM-системы историческими, так называемыми “унаследованными” данными, что достаточно часто является очень сложной и трудоемкой задачей. 

В результате, говорить о полноценной промышленной эксплуатации интегрированного решения PDM-ERP можно только в том случае, если на предприятии решены все указанные выше проблемы. А это бывает не так уж часто. 

А нужна ли такая интеграция вообще? В чём её ценность для предприятия? 

Действительно, учитывая ответ на предыдущий вопрос, могут возникнуть вполне резонные сомнения, а нужна ли такая интеграция вообще… 

На наш взгляд – конечно же, нужна! И тому есть объективные доказательства. 

• Невозможно гарантировать наличие в ERP- системе правильных и актуальных составов изделий и данных по технологии, если они не создаются, не согласуются и не утверждаются непосредственно в рамках процесса конструкторско-технологической подготовки производства. Если существует разрыв (повторный ввод данных, пусть даже он и делается в самих конструкторскотехнологических подразделениях), вы никогда не получите в ERP-системе точных и актуальных данных. К сожалению, подтверждений этому правилу – огромное количество, а исключений практически нет. Цену ошибок, которые возникают изза этого при планировании производства, думаем, пояснять нет необходимости.
• На производстве всегда возникает большое количество изменений и/или отклонений от действующей конструкторско-технологической документации. В современных конкурентных условиях скорость проведения и внедрения таких изменений/отклонений в производстве часто становится критически важным фактором. И только наличие отлаженного механизма взаимодействия конструкторских, технологических и производственных служб позволяет делать это быстро. Инструментами для обеспечения такого взаимодействия и становятся PDM- и ERP-системы, а также средства их интеграции.
• Параллельная, а не последовательная работа конструкторов и технологов в последнее время уже не является “экзотикой” на наших предприятиях. Во многих компаниях это уже стандарт. Тем самым минимизируется время и повышается качество разработки изделий. Если включить в параллельную работу еще и службы снабжения, производственные подразделения, то вполне реально добиться сокращения не только цикла разработки, но и сроков вывода готовой продукции на рынок.

На наш взгляд, всё это в достаточной мере подтверждает актуальность вопроса интеграции PDM- и ERP-систем, а также ценность подобного интегрированного решения для предприятий. 

Какие ключевые требования предъявляются к интеграционному решению? 
Если говорить о типовых ключевых требованиях, которые наши заказчики предъявляют к решению, призванному интегрировать PLM и ERP, то их можно сформулировать в нескольких достаточно простых пунктах (рис. 2).

 
Рис. 2. Ключевые требования к интеграционному решению 

Во-первых, как правило, речь идет об обмене достаточно ограниченным набором типов данных. Для PDM – это информация о технологическом составе изделий и технологии изготовления. Если на предприятии применяется, помимо PDM-системы, такой PLM-компонент, как автоматизация управления проектами, то возникает необходимость в обмене данными по заказчикам, бюджетам проектов, календарным планам. Однако обмен проектными данными – тема отдельного обсуждения, и мы далее будем рассматривать только вопрос интеграции PDM и ERP. 

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

Одним из ключевых требований является простота предлагаемого интеграционного решения: оно должно быть простым в установке, обслуживании и сопровождении, и не должно требовать использования дополнительного и вспомогательного программного обеспечения. Важным аспектом является гибкость решения. PLM-система на предприятии живет и развивается, со временем заказчик может самостоятельно вносить какие-то изменения. Аналогично обстоит дело и с ERP-системой. Соответственно, разработанный интеграционный компонент должен быть достаточно гибким, чтобы подстраиваться под изменения как PLM-, так и ERP-системы без необходимости исправлять непосредственно программный код. Иными словами, определенный объем изменений в модуль интеграции должен вноситься без перепрограммирования, а только за счет настройки. 

В чём должна заключаться интеграция? 

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

Рис. 3. Типовой поток данных модуля интеграции PDM-ERP 

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

Следующий шаг – это консолидация технологических данных в единый сквозной технологический процесс и выгрузка обобщенной информации на так называемую шину обмена (в самой простой реализации она может представлять собой обычный FTP-сервер). Выгрузка должна автоматически производиться в тех случаях, когда утверждается новое изделие или отдельный его компонент, либо когда проводится изменение. Дополнительно должна существовать возможность в любой момент времени принудительно выгрузить данные из базы PDM в ERP по требованию администратора. ERP-система “забирает” данные с шины обмена и затем разбирает их в соответствии со своим внутренним алгоритмом. 

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

 
Рис. 4. Укрупненная архитектура модуля интеграции

Двухсторонняя или односторонняя интеграция? 

Как правило, когда речь идет об интеграции PDM и ERP, ключевым требованием является передача данных в одном направлении – из PDM-системы в ERP-систему. 

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

Рис. 5. Отображение хранящейся в ERP-системе информации об элементах изделия в интерфейсе PDM-системы 

В данном случае речь идет не о передаче данных из базы данных ERP-системы в БД PDM- системы, а только о выводе в интерфейсе PDM-системы данных, хранимых в базе ERP. Реализовать такое визуальное отображение гораздо проще, чем полноценную интеграцию, и в системе Windchill это не составляет никакого труда. 

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

Типовой состав передаваемых данных 

Типовой состав передаваемых данных представлен на рис. 6 (пример для одного элемента состава изделия – детали или сборочной единицы):

 

Рис. 6. Типовой состав передаваемых данных 

Передаваемые данные имеют иерархическую структуру. В общем случае для каждого элемента состава изделия в ERP-систему необходимо передать: 

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

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

Какие варианты обмена данными существуют? Какой вариант предпочтительнее? 

Если говорить про систему Windchill, то её интеграция с ERP-системой может быть реализована несколькими способами (рис. 7).

 

Рис. 7. Основные варианты обмена данными 

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

Второй способ – разработка интеграционного ПО на основе программного интерфейса (API) Windchill, либо использование специального дополнительного модуля Windchill ERP Connector. По своей сути эти механиз- мы похожи, поэтому их рассмотрение можно объединить в один блок. 

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

В заключение необходимо рассмотреть вариант интеграции PDM-ERP с помощью так называемого ПО промежуточного уровня (middleware). В качестве такового система Windchill использует TIBCO. Это программное обеспечение позволяет осуществить настройку, администрирование и выполнение транзакций по обмену данными между PDM- и ERP-системами практически не прибегая к кодированию на универсальных языках программирования (рис. 8).
 

Рис. 8. Реализация интеграции PDM-ERP с помощью ПО промежуточного уровня 

Компания PTC поставляет готовые настройки для интеграции Windchill с ERP SAP и Oracle Applications для использования с TIBCO. Недостатком интеграции на базе инструментария TIBCO является достаточно высокая стоимость владения, что приемлемо только в рамках очень больших проектов внедрения. 

Часто можно услышать: “наша система может быть интегрирована с чем угодно”. Это правда или маркетинговый ход? 

Как правило, подобное утверждение означает, что рассматриваемая система имеет программный интерфейс (Application Programming Interface – API) или встроенные механизмы импорта/экспорта, которые позволяют реализовать выгрузку данных в определенном формате. 

Если мы говорим про интеграцию именно с ERP-системами, то принципиальными являются ответы на следующие вопросы: 

• Содержатся ли в рассматриваемой системе такие данные об изделии, которые являются необходимыми и достаточными для планирования производства в ERP-системе (см. вопрос “Типовой состав передаваемых данных”)?
• Позволяет ли стандартный функционал (именно стандартный!) системы реализовать автоматическую выгрузку и загрузку данных по факту свершения определенных событий (утверждение документации и состава изделия, проведение изменений, и пр.) или это можно делать только в ручном режиме?
• Обладает ли разработчик и поставщик системы опытом по реализации интеграции (так как недостаточно просто владеть определенным инструментом, надо знать, как и для чего им пользоваться)?

В случае с Windchill и Pro|TECHNOLOGIES однозначный ответ на все эти вопросы – да! 

Бывают ли интеграционные решения “коробочными продуктами”? То есть, могут ли они работать по принципу “установил – и всё заработало”? 

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

Каким образом должен быть организован подобный проект? Ответ на этот вопрос мы дадим на примере УПЭК. 

Что конкретно было сделано для УПЭК? 

В рамках проекта на предприятиях ИГ УПЭК создание интеграционного решения было осуществлено, что называется, с нуля. Общая схема организации работ представлена на рис. 9.

 

Рис. 9. Схема организации работ 

Первый шаг – разработка детального технического задания на создание решения. В техзадании определяется общая архитектура решения, модель передаваемых данных, детальный атрибутивный состав, согласуются форматы передачи данных и сценарии работы интеграционного модуля, описываются требования к обработке исключительных ситуаций, порядок контроля и приемки работ. Отдельная задача, решаемая на этапе разработки и согласования ТЗ: выбор контрольного примера, который, с одной стороны, максимально охватывал бы все возможные ситуации, а с другой – был бы достаточно объемным, чтобы можно было проверить работоспособность системы в условиях, приближенных к “боевым”. 

Следующий этап – это настройка системы. Фактически, здесь речь идет о разработке интеграционного модуля – как со стороны PDM, так и со стороны ERP. Как правило, эта работа выполняется разными исполнителями. За разработку модуля интеграции со стороны PDM отвечает внедренец PLM-решения (в данном случае, это мы); вторую часть разрабатывает поставщик ERP-системы (в рамках проекта создания комплексной системы автоматизации эту работу выполнял отдел информационных технологий АО УПЭК). 

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

Четвертый этап – проведение полномасштабной проверки на выбранных контрольных примерах, фиксация всех возникающих замечаний и сбоев. 

Заключительная фаза – доработка интеграционного модуля и документации по результатам пилотного проекта (полномасштабной проверки) и принятие решения о вводе модуля в промышленную эксплуатацию. 

Каковы сроки создания интеграционного решения? 

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

Есть ли у Pro|TECHNOLOGIES опыт интеграции с ERP-системами на других предприятиях? 

Здесь необходимо отметить, что, когда мы говорим про ИГ УПЭК, то речь идет о пяти отдельных предприятиях, каждое из которых имеет свою специфику и свои уникальные требования. Таким образом, рассматривая проект создания комплексной системы автоматизации для ИГ УПЭК, мы фактически обобщаем опыт реализации пяти отдельных проектов по интеграции PDM-ERP. 

Если говорить про иные направления нашей деятельности, то нельзя обойти вниманием успешно выполненные работы по созданию интеграционного решения для ОАО “РКК ‘Энергия’ им. С.П. Королева”. Этот проект затрагивал интеграцию PLM- ERP в аспекте обмена проектной информацией. В настоящий момент активные работы по этому направлению ведутся со многими заказчиками. 

Заключение 

В этой статье мы постарались максимально четко и сжато дать ответы на вопросы, которые наверняка интересуют большинство предприятий – как уже использующих PDM/ERP-системы, так и тех, кто только планирует осуществить их внедрение. 

Компания Pro|TECHNOLOGIES обладает богатым реальным опытом выполнения проектов по интеграции (это касается не только связки PLM-ERP, но и совместной работы средств PLM с системами других классов – например, Business Intelligence или САПР ТП, о чём мы рассказывали в предыдущей статье). Мы готовы предложить своим заказчикам полный цикл работ по созданию интегрированных PLM- решений (что называется “под ключ”), начиная с разработки детального технического задания и вплоть до сопровождения интеграционного решения в промышленной эксплуатации. 

Цикл статей, посвященных проекту внедрения PLM на предприятиях ИГ УПЭК, мы продолжим в ближайшее время. Следите за публикациями!

Заказать обучение