*1

_____

*1 Окончание. Начало см. PC Week/RE, N17/2006, с. 35.

ОБЗОРЫ

Как вести передачу - в обе стороны или в одну?

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

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

Представители компаний также высказались в пользу двусторонней интеграции. "Конструктору нужно максимально полно опираться на существующее "наследие", хранящееся в ERP, а нормировщик должен иметь возможность видеть инженерные и производственные спецификации в одном окне, а также иметь механизм для переноса ссылок, структур, наименований, нумерации и т. п., - уверен Дмитрий Шехватов. - Все это необходимо для сокращения числа ошибок, времени, трудозатрат и всех видов используемых ресурсов". Именно этим путем пошло предприятие "ССМ-Тяжмаш", когда объединяло Axapta и "Лоцман". "Такая интеграция обеспечила однократный ввод данных и позволила создать единое информационное пространство", - поделился впечатлениями от проекта Валерий Сидоров, менеджер группы внедрения ИТ на "ССМ-Тяжмаш".

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

На выбор степени интеграции влияет способ внедрения модулей ERP и PDM в компании, который должен учитывать, какая из этих систем является "держателем" централизованных справочников материалов, номенклатуры изделий и т. п. Но в идеале интеграция должна быть организована в обе стороны (рис. 2). Однако, как известно, сразу добиться совершенства сложно, поэтому на первом этапе можно ограничиться односторонней передачей, например, состава изделия и спецификаций из САПР в ERP. Уже это позволит существенно сократить число ошибок. Так, по данным компании АСКОН, ручное внесение состава изделия в ERP приводит к ошибочному вводу до 30% информации.

Рис. 2. Схема двустороннего движения потоков информации.

Из САПР в ERP должна передаваться информация

конструкторская (состав, массы и материалы изделия и

его компонентов) и технологическая (маршруты

изготовления изделия, ресурсы, назначенные

 заготовки, оснастка и оборудование). Сведения

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

 извещений. В обратную сторону - из ERP в САПР -

возвращаются данные о возможностях производства,

которые помогают техническим специалистам

определить, например, какое оборудование наименее

загружено,  а значит, его можно использовать в техпроцессе

Именно такой метод выбрало предприятие "Проект-техника". "Мы считаем, что наиболее оптимальной является односторонняя связь между PDM и ERP, - сказал Сергей Курмин. - Состав изделия формируется конструктором в PDM, а затем передается в ERP. Обратный перенос нам пока не нужен".

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

Что предпочтительнее: доступ или обмен?

Планируя объединение САПР и ERP, нельзя забывать, что далеко не всю информацию нужно обязательно передавать. В некоторых случаях достаточно обеспечить лишь доступ к одной системе из другой, скажем, через портал. Это позволит снизить затраты на интеграцию и ускорить реализацию проекта. Через Web-браузер пользователи смогут просматривать данные из различных источников - например, сведения о складских запасах и затратах из ERP или чертежи и модели из САПР. "В несложных производствах со значительным количеством типовых узлов, где проектирование занимает незначительную часть времени, выпуск идет небольшими сериями, а справочник материалов изменяется мало, можно, наверное, обойтись порталами", - полагает Дмитрий Шехватов.

Многое зависит от круга обязанностей пользователя. "Если для решения текущих задач ему достаточно просмотра и самостоятельного переноса данных из системы в систему, то доступ можно организовать через портал", - объяснил Иван Котов.

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

Технические методы

Реализовать интеграцию САПР и ERP, как уже отмечалось выше, можно различными способами. Аналитики CIMdata разделили их на три класса и перечислили в порядке возрастания сложности: файлы импорта/экспорта, связь через API-интерфейсы, полная (бесшовная) интеграция.

Как рассказал Сергей Беспалов, самым простым с точки зрения реализации, но более сложным с точки зрения поддержки целостности данных является механизм обмена через структурированные файлы импорта/экспорта: "В таком случае передача выполняется в соответствии с заранее разработанными и согласованными форматами. Источник данных (ERP или САПР/PDM) формирует их, а затем через механизм экспорта передает в файлы согласованного формата, которые читаются системой-приемником. Но при этом нужно поддерживать целостность таких данных. Например, довольно сложно обеспечить единые принципы кодирования номенклатурных единиц, поскольку и в ERP, и в PDM эти принципы могут быть разными, в связи с чем необходимо создать таблицу соответствия кодов, а также предусмотреть правила и механизм для синхронизации номенклатурных справочников в процессе импорта/экспорта данных. Данные правила и регламенты обмена следует четко проработать на начальном этапе разработки концепции интеграции".

Аналогичный подход применяет и "АНД Проджект". "Использование файлов экспорта/импорта хотя и менее технологично, чем API-интерфейсов, но в ряде случаев обеспечивает большую гибкость и не требует глубоких знаний в программировании, - сказал Иван Котов. - Наверное, поэтому большинство проектов по интеграции выполняется именно таким способом. Это старый, но проверенный подход, позволяющий достаточно быстро получить эффект".

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

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

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

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

Возврат инвестиций

Как следует из вышесказанного, препятствий на пути к интеграции САПР и ERP немало. Очевидно, что для их преодоления требуются финансовые затраты. Насколько они оправданны? Как оценить полученную выгоду?

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

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

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

Правда, все приведенные оценки носят эмпирический характер, поскольку статистика по окупаемости затрат на такие проекты в России пока отсутствует. По мнению Сергея Беспалова, это связано с тем, что еще довольно мало наших компаний при внедрении ERP- или PDM-системы пытается оценить экономическую целесообразность их интеграции. Для этого необходимо провести серьезную аналитическую работу, учитывающую очень много критериев, и практически ни одна из российских компаний всерьез этим не занимается. С ним согласен Иван Котов: "К сожалению, никто не берется оценивать ИТ-проекты с финансовой точки зрения, серьезных исследований нет. Можно долго говорить о том, что благодаря интеграции удалось уменьшить количество персонала и/или снизить нагрузку на пользователей. Но главное не в этом. Если в результате объединения PDM и ERP удалось сократить цикл подготовки производства изделия и ускорить вывод новых продуктов на рынок, считайте, что проект интеграции состоялся. В современных условиях основная конкуренция между производителями перемещается именно в эту область: сокращение цикла разработки "идея - модель - готовое изделие - выпуск в продажу".

Таким образом, речь идет о выживании предприятия, ведь от возможности взаимодействия между САПР и ERP зависит его конкурентоспособность. "Если вы не в состоянии построить сторожевой катер за восемь месяцев, а можете, скажем, сделать это за полтора года, то вы попросту никогда не получите такой заказ", - привел пример Дмитрий Шехватов.

Опыт первопроходцев

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

Прежде всего нужно от чего-то отталкиваться, а для этого нужно полностью внедрить хотя бы одну систему - САПР/ PDM или ERP. "Параллельное внедрение и интеграция - крайне сложная и затратная задача, которую могут позволить себе далеко не все компании, - объяснил Сергей Беспалов. - Но когда дело доходит до реализации другой системы, следует сразу планировать возможность ее взаимодействия с первой". С ним согласен Валерий Сидоров: "При внедрении различных систем на предприятии необходимо предусмотреть, будут ли они интегрированы и какие данные нужно передавать, а затем, исходя из этого, внедрять системы. Иначе потом возникают проблемы, связанные с разной логикой построения данных и другими нестыковками".

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

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

Своими силами предприятию трудно решить задачу интеграции. "Стоит найти грамотных консультантов с опытом решения подобных задач", - порекомендовал Николай Нырков. С ним согласен Артем Сурьянинов: "Хочу отметить огромную роль правильного выбора внешних консультантов, способных разобраться в проблемах предприятия и оказать помощь. Основными критериями их надежности может служить соотношение стоимость/функционал планируемого решения, а также возможность продемонстрировать работающую интегрированную систему САПР - ERP не на словах, а на деле - у конкретных заказчиков. Не поленитесь съездить на такие предприятия".

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

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

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

Реализацию проекта нельзя пускать на самотек. "Выдерживайте сроки выполнения работ и четко фиксируйте все возникающие проблемы и отклонения от техзадания. Если вы проводите работы с привлечением компании-интегратора, то максимально формализуйте отношения с ней. Кроме того, подробно документируйте интеграционное решение и обязательно привлекайте сотрудников подразделений к подготовке рабочих инструкций", - напомнил Николай Ширяев.

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

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

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

Версия для печати