Рекламодатель: ЗАО «Топ Системы»

ИНН 7726601967 ОГРН 1087746953557

Рекламодатель: ООО НТЦ «АПМ»

ИНН 5018019971 ОГРН 1035003357366

Рекламодатель:
ООО «С3Д Лабс»

ИНН 7715938849 ОГРН 1127747049209

5 - 2006

Системная интеграция и PLM: две стороны одной медали

Николай Ширяев

Какие цели преследует внедрение интегрированных PLM-решений

Какие интеграционные задачи решаются при внедрении PLM-решений

Нужно ли сразу же  интегрировать между собой все модули систем ERP и PDM?

Какие моменты следует учитывать при планировании интеграции

Окупаемость проекта

Данная статья посвящена вопросам, связанным с системной интеграцией при внедрении PLM-решений.

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

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

Таким образом, и системы PDM, и системы ERP, и системы CAD/CAM/CAPP/CAE, и даже офисные приложения могут быть элементами единого PLM-решения. Поэтому аббревиатуру «PLM»  в названиях ряда систем следует рассматривать не более как признак ориентации на комплексный подход к решению задач управления данными, а то и как рекламную декларацию. При этом ядром решения, за счет функции по аккумулированию и обработке информации, будут системы PDM и ERP.

Очевидно, что системы PDM и ERP должны обмениваться информацией c САПР, офисными приложениями и т.п. И функционировать эти системы в рамках крупного предприятия будут, скорее всего, на нескольких  программно-аппаратных платформах. Таким образом, без решения задач системной интеграции при внедрении PLM-решений не обойтись.

Какие цели преследует внедрение интегрированных PLM-решений

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

В начало В начало

Какие интеграционные задачи решаются при внедрении PLM-решений

Как правило, первое, на что обращают внимание при выборе PLM-решения, — это интеграция систем PDM с САПР (иной раз после разговора с представителями какой-либо компании даже может сложиться впечатление, что основная задача системы PDM — это формирование конструкторской спецификации в соответствии с требованиями ЕСКД). Безусловно, этот вопрос важен. Но не менее, а, возможно, даже более важен вопрос интеграции между системами управления предприятием (ERP) и системой управления информацией об изделии (PDM).

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

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

Фактические механизмы реализации интеграции во многом определяются схемой и последовательностью внедрения модулей ERP и PDM в компании: какая из систем является «держателем» централизованных справочников материалов, номенклатуры и т.п. И если первичная информация должна передаваться из ERP в PDM (например, данные о составе изделия для формирования производственной программы), то производственная информация в дальнейшем также может передаваться в систему PDM из ERP. Очевидно, что возможность использования двусторонней связи всегда предпочтительнее: больше возможностей для организации обмена данными между приложениями.

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

Другой вопрос: какую из систем лучше выбрать для визуального представления информации конечным пользователям? Тут уже многое зависит от возможностей конкретных систем PDM и ERP в этой части. Представление данных через корпоративный портал в ряде случаев удобнее для визуализации информации и позволяет сократить затраты на администрирование системы за счет отказа от установки программного обеспечения на рабочие места пользователей. Разумеется, необходимо предусмотреть интеграцию систем PDM и ERP со средствами календарного планирования, офисными приложениями и т.п. А также «завязать» все основные бизнес-процессы предприятия через процедуры Workflow.

При реализации решения в масштабах предприятия на первый план выходят следующие требования:

•  функциональность;

•  быстродействие;

•  гибкость;

•  масштабируемость;

•  безопасность.

Давайте подробнее рассмотрим каждое из них.

Функциональность

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

Быстродействие

При одновременной работе большого количество пользователей (нескольких сот или тысяч сотрудников)  с большими массивами данных вопросы производительности системы (особенно при формировании разного рода отчетных документов: ведомостей, спецификаций и т.п.) часто становятся определяющими.  Уже сейчас в России используются системы с несколькими тысячами одновременно работающих сотрудников, а базы данных с десятками миллионов активно модифицируемых записей перестали быть редкостью. И итоговая производительность будет определяться сочетанием как программных, так и аппаратных факторов. Очень важен правильный выбор архитектуры решения (как программного обеспечения, так и технических средств). Поэтому при планировании архитектуры системы, закупке и конфигурировании ПО и оборудования  необходимо предусматривать резерв на рост объемов данных и числа пользователей. В частности, для систем PDM и ERP большое внимание нужно уделять правильному выбору и конфигурированию СУБД и серверов, на которых они установлены.

Гибкость

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

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

Кроме того, преимуществом является то, что система поддерживает стандартные средства разработки (языки высокого уровня, скриптовые языки и т.п.), имеет открытый интерфейс прикладного программирования (API), а также поддерживает современные стандарты и форматы обмена данными (XML, ISO 10303 STEP и др.).

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

•    написание специализированных модулей интеграции с использованием API обеих систем;

•    через  универсальные форматы обмена данными типа XML, STEP и т.п.

Каждая из этих схем имеет свои плюсы и минусы: при работе через API часто возникает необходимость в большей производительности, но  использование XML обеспечивает в ряде случаев гораздо более гибкое решение.

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

Масштабируемость

Масштабируемость является одним из ключевых требований, предъявляемых к корпоративным системам. Масштабируемость решения зависит от:

•  архитектуры решения и модели данных — хотелось бы отметить, что само по себе построение решения в архитектуре «клиент-сервер», «трехзвенной», «Web-ориентированной» и т.п. не дает гарантий хорошей масштабируемости системы. Очень многое зависит и от того, как спроектирована модель данных (например, одна и та же структура данных может обеспечивать хорошую производительность при запросах одного типа, но очень сильно «проваливаться» на запросах другого типа). Разработчики каждый раз стоят перед дилеммой: повысить гибкость системы, но расплатиться за это снижением производительности или оптимизировать производительность, пожертвовав гибкостью;

•  возможностей по экстенсивному наращиванию мощности программно-аппаратного комплекса (поддержка кластерных решений и т.п.);

•  возможностей по смене программно-аппаратной платформы без изменения модели данных (например, переход с СУБД MS SQL Server на Oracle).

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

Безопасность

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

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

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

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

В начало В начало

Нужно ли сразу же  интегрировать между собой все модули систем ERP и PDM?

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

В начало В начало

Какие моменты следует учитывать при планировании интеграции

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

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

Для начального этапа проведения интеграционного проекта можно предложить следующие рекомендации:

1.  Не спешите и не ставьте перед собой задачи «сделать все и за неделю», а начните с формирования рабочей группы проекта с привлечением сотрудников всех заинтересованных подразделений.

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

3.  Выдерживайте сроки выполнения работ и четко фиксируйте все возникающие проблемы и отклонения от ТЗ.  Если вы проводите работы с привлечением компании-интегратора, то максимально формализуйте отношения с ней.

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

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

6.  Будьте готовы к тому, что настоящая работа начнется только после завершения собственно интеграции систем ERP и PDM.

В начало В начало

Окупаемость проекта

Как показывает опыт успешного внедрения подобных интеграционных решений нашими клиентами (Пензхиммаш и др.), затраты на интеграцию окупаются, как правило, менее чем за год. При этом окупаемость достигается за счет как существенной экономии рабочего времени (по отдельным показателям временные затраты сокращаются в несколько десятков раз (по отзывам представителей НПО «Искра» и института ТюменНИИгипрогаз), так и значительного сокращения числа ошибок при вводе данных.

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

***

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

В начало В начало

САПР и графика 5`2006

Регистрация | Войти

Мы в телеграм:

Рекламодатель:
ООО «Нанософт разработка»

ИНН 7751031421 ОГРН 5167746333838

Рекламодатель: ЗАО «Топ Системы»

ИНН 7726601967 ОГРН 1087746953557