/13270325/i_800.jpg)
Два-три года назад заказчики приходили к интеграторам с простым запросом: «У нас были западные CAD-, PLM- и ERP-продукты, подберите российские аналоги». Сейчас вопрос все чаще звучит иначе: «PLM мы уже внедрили. Как связать ее с MES, ERP и бизнес-аналитикой, чтобы данные передавались без потерь?» Это не значит, что переход на российское ПО завершен – предприятия находятся на разных этапах. Но характер запросов меняется.
Более того, раньше PLM нередко воспринимали как отдельный ИТ-проект: сначала как электронный архив, затем как инструмент управления разработкой изделия. Теперь от нее ждут работы в общем производственном контуре: состав изделия, спецификации, версии документов и сведения об изменениях должны переходить в MES и ERP, где они используются в производстве, закупках и планировании ресурсов. И вот здесь обычно начинается самая сложная часть проекта.
Каждый в своей экосистеме
После 2022 года на рынке появилось много новых промышленных продуктов, и многие вендоры начали развивать собственные экосистемы. Даже у зрелых PLM-, ERP- и MES-систем не всегда есть готовые коннекторы друг к другу, в итоге соединять продукты разных производителей приходится уже на стороне заказчика.
Открытый API позволяет связать их напрямую или через интеграционную шину, но не определяет, какие данные и по каким правилам будут передаваться. Так, сейчас мы участвуем в проекте по созданию инфраструктуры для нового производства. Партнерская команда внедряет ERP, наша – PLM. Мы настраиваем обмен между ними и отдельные модули, а затем еще будем проверять всю связку в опытно-промышленной эксплуатации.
Такие работы съедают заметную часть бюджета: например, по данным опроса Минпромторга, средняя стоимость внедрения PLM на крупном предприятии электронной отрасли оценивается примерно в 300 млн руб., а срок составляет около трех лет. При этом порядка 23% расходов уходит на интеграцию с другим ПО и оборудованием, еще 10% занимает миграция данных.
Государство компенсирует часть затрат через гранты, субсидии и льготные программы – эта поддержка помогает запустить проект, но настройка обмена остается задачей самого заказчика. Общие требования к совместимости только формируются: в 2024 году Минпромторг и Росстандарт запустили программу стандартизации PLM-систем, а в конце июня 2026 года Росстандарт утвердил первые стандарты для платформ промышленной автоматизации. Пока эти правила не заработали, каждое предприятие самостоятельно определяет порядок обмена данными в своих проектах.
Есть и другая проблема – зависимость от уникальных доработок. Если их умеет сопровождать только один подрядчик, предприятие оказывается привязано не к одному продукту, а ко всей этой собранной конструкции. При замене любого ее элемента приходится переделывать связи с соседними приложениями.
Единый контур не заканчивается на границе холдинга
Даже если внутри крупного холдинга работает единая платформа, остается обмен с поставщиками и подрядчиками. Головное предприятие передает им 3D-модели, спецификации, конструкторскую документацию и извещения об изменениях, при этом участники производственной цепочки могут использовать совсем другие CAD- и PLM-системы.
Тогда информацию приходится переводить из одного формата в другой или выгружать вручную. Каждое изменение должно пройти по той же цепочке обратно, и чем больше в ней ручных операций, тем выше риск, что документы задублируются, версии разойдутся, а обновленная спецификация придет с задержкой.
Поэтому для крупного заказчика важна не только внутренняя интеграция. Еще до выбора PLM нужно понимать, как предприятие будет обмениваться данными с поставщиками: какие форматы они используют, какую информацию смогут принять и как конкретно им будут передаваться изменения.
Что проверить до закупки
До закупки стоит выяснить, с какими ERP-, MES- и аналитическими системами предстоит настроить обмен, есть ли для них готовые коннекторы и открытый API. Обычная демонстрация этого не покажет: вендор работает на подготовленном примере и внутри собственной экосистемы.
Совместимость лучше проверять на данных заказчика. В пилоте можно передать структуру изделия, внести изменение в документацию и посмотреть, как оно дошло до смежной программы. Заодно выяснится, что уже работает в коробке, какие модули придется настраивать и понадобятся ли отдельные коннекторы. Эти работы должны попасть в оценку проекта до выбора PLM, иначе их объем станет понятен уже во время внедрения, когда к покупке продукта добавится отдельная интеграционная задача со своими сроками и бюджетом.
Как не заменить одну зависимость другой
Рынок со временем отсеет часть разработок: сильные вендоры останутся, слабые уйдут, но продукты, которые сохранят свои позиции, не начнут автоматически работать друг с другом.
Общие стандарты помогут задать правила для рынка, но контур у каждого предприятия свой. Заказчику все равно придется разбираться, какие данные передаются между программами, где хранится их основная версия и кто отвечает за сопровождение каждой связки. Если этого не сделать, временные коннекторы, ручные выгрузки и точечные доработки останутся в инфраструктуре на годы. Формально каждый продукт будет выполнять свою функцию, но любое изменение потребует новой стыковки. Так и возникает лоскутная автоматизация, и дешевле всего избежать ее на этапе выбора продукта: пока ПО не встроено в процессы, совместимость – это требование к вендору, а после внедрения – расходы самого заказчика.
Автор – Николай Флягин, руководитель группы технической экспертизы Департамента решений САПР и ГИС «Софтлайн Решения» (ГК Softline)
