«Вы нас плохо предупреждали»: почему замена PLM не дает результата

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

Как компании формулируют задачу – и что за этим стоит

После ухода вендоров российские компании оказались в разных ситуациях. Часть из них, пока лицензии действуют, работает на Siemens, PTC или SAP, другие в один момент лишились доступа к западным решениям и вынуждены менять PLM в цейтноте. При всей разнице в исходных условиях формулировки запроса у заказчиков во многом совпадают. Но за словом «PLM» в каждом случае понимают разный объем задач.

Одним нужен электронный архив конструкторской документации, хотя изначально запрос звучит как «Хотим PLM». В ходе обсуждения выясняется, что чертежи и модели теряются, актуальные данные перемешаны с устаревшими, а производство не может работать без точной информации. Это не «неправильная задача» – просто она другая.

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

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

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

Ограничения подхода «перенести как есть»

Проекты по замене PLM-систем, как правило, стартуют одинаково – с запроса «перенести все как было». Но через год возникает вопрос: «Зачем мы это сделали?».

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

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

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

Почему PLM не дает эффекта

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

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

Отдельного внимания требуют интеграции: PLM все равно придется состыковывать с ERP, производственными и учетными системами. Если это не учесть заранее, сложности проявятся уже на этапе внедрения, когда цена ошибки значительно выше.

Управленческие факторы внедрения

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

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

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

Отдельная история – зависимость от интегратора. Зачастую проект воспринимается как полностью внешняя задача: есть подрядчик, значит, он все и сделает. На практике это работает только на этапе внедрения. Дальше PLM остается внутри компании, и если в ней нет людей, способных ее развивать и настраивать, любые изменения потребуют привлечения интегратора.

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

Граница между внедрением и результатом

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

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

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

Авторы — Виталий Лоза, руководитель направления машиностроение, «Софтлайн Решения» (ГК Softline), и Александр Тимошин, директор АППИУС