Аспекты миграции инженерных данных при переходе на отечественные PLM-платформы

Тимур Мирзаев,
функциональный архитектор центра компетенции в промышленности, Группа «Борлас» (ГК Softline)

Фотис Папаиоану,
руководитель группы отдела автоматизации управления жизненным циклом изделия, Группа «Борлас» (ГК Softline)

Альберт Хайдаров,
директор по развитию бизнеса, Группа «Борлас» (ГК Softline)

Почему вопрос миграции стал ключевым

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

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

Данные об изделии в PLM/PDM являются «цифровым фундаментом» разработки любого нового продукта, обеспечивая вместе с тем точность и актуальность планирования в ERP->системе. Данные — это не только файлы CAD->моделей и чертежей, но и структуры изделий, их версии и ревизии, статусы согласования и история изменений, связи между объектами, технологические маршруты и процессы, а также другая информация для смежных систем (рис. 1).

Рис. 1. Миграция затрагивает не файлы, а связанную инженерную экосистему

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

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

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

Что происходит, когда миграция рассматривается как «простая выгрузка данных»

На раннем этапе многие предприятия воспринимают миграцию как относительно прямолинейный процесс: выгрузить данные из одной системы -> загрузить в другую -> проверить результат.

Однако на практике подобный подход редко работает в промышленных проектах.

Основная причина заключается в различии моделей данных и принципов работы платформ. Даже при схожем функционале «старых» и «новых» PLM->систем у них есть масса очевидных различий:

различаются  структуры объектов;

• по->разному реализованы конфигурации и вариантность;
• используются разные механизмы управления версиями;
• различаются правила хранения связей между CAD->данными;
• различаются механизмы статусов, маршрутов и согласований.

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

Подходы к миграции PLM->систем

Сегодня можно выделить два принципиально разных подхода к миграции инженерных данных.

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

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

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

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

Подобные проекты нередко превращаются в длительные инициативы с постоянно изменяющимся объемом работ.

Подход 2. Типизированная миграция на базе специализированного инструментария

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

Сравнение подходов

Рис. 2. Сравнение подходов к миграции

Он изначально обладает рядом существенных преимуществ перед проектным подходом (рис. 2). В частности:

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

Такой подход особенно востребован в проектах перехода с Siemens Teamcenter/NX на отечественные платформы, где у предприятий часто повторяются схожие классы инженерных объектов и процессов.

Почему пилотная миграция становится обязательным этапом

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

Именно поэтому целесообразно применять подход пилотной миграции.

На пилотном этапе переносится ограниченный набор данных:

• типовые изделия;
• ключевые структуры;
• CAD->связи;
• статусы согласования;
• основные справочники и классификаторы.

Это позволяет:

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

Фактически пилотная миграция становится инструментом технической верификации всей стратегии перехода.

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

Ключевая проблема — не перенос файлов, а сохранение инженерной логики

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

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

• чертеж должен сохранять связь с 3D->моделью;
• спецификация — с составом изделия;
• ERP — получать корректные атрибуты;
• маршруты согласования — сохранять историю изменений.

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

Именно поэтому современные инструменты миграции все чаще строятся вокруг нескольких принципов:

• Сохранение связности инженерных объектов.
• Контроль полноты переноса.
• Управляемый маппинг моделей данных.
• Возможность поэтапной миграции.
• Поддержка различных сценариев преобразования данных.

Как меняется подход предприятий к проектам перехода

Многие предприятия откладывают проекты миграции из->за высокой неопределенности (рис. 3).

Рис. 3. Рост стоимости миграции при откладывании проекта

Основные их опасения связаны со следующими рисками и проблемами:

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

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

1. Анализ текущего ИТ->ландшафта, в который «вписана» PLM->система.
2. Проведение пилотной миграции.
3. Настройка дополнительных правил преобразования.
4. Определение этапности переноса данных (по изделиям или их составным частям, по заказам (проектам), по подразделениям и т.п.).
5. Промышленный запуск.

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

Рис. 4. Снижение рисков достигается через этапность и проверяемость результата

Практический опыт: переход  от «уникальных проектов» к промышленным инструментам миграции

Мы с коллегами наблюдаем на рынке заметный рост спроса не просто на услуги миграции, а на наличие готового технологического инструментария. Особенно это актуально в вопросах перехода с Siemens Teamcenter/NX на отечественные PLM->платформы, где предприятия ожидают предсказуемых сроков, минимизации ручных операций и повторяемости результата с одновременной прозрачностью контроля и возможностью масштабирования миграции при необходимости.

В ответ на такой запрос предприятий уже есть специализированные решения, включающие:

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

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

Что становится критически важным для успешной миграции

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

Ключевыми факторами здесь становятся:

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

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

Подобный подход сегодня мы применяем в проектах миграции с Siemens Teamcenter/NX на T->FLEX PLM, где используются как отраслевые методики миграции, так и специализированные модули переноса инженерных данных, обеспечивающие контроль полноты и связности информации.