Виталий Лоза

По данным международных исследований, правильно выстроенное управление жизненным циклом продукта (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), и Александр Тимошин, директор АППИУС

По оценкам Strategy Partners, к 2030 году российские решения для управления жизненным циклом продуктов (Product Lifecycle Management, PLM) могут занять до 93% рынка систем этого класса, при этом сам рынок продолжит расти темпами порядка 16% в год. Со стороны это выглядит как довольно уверенный рост: освободившуюся нишу быстро закрывают, появляются новые продукты, запускаются проекты. Но если смотреть не на динамику, а на то, как этот рынок устроен в принципе, картина становится сложнее. Риск здесь не в дефиците решений, а в их совместимости – и в том, смогут ли они вообще работать вместе через несколько лет.

Рынок разделился

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

Часть предприятий успела внедрить решения Siemens, PTC, SAP до ухода западных вендоров. Эти системы развернуты в локальном контуре, лицензии есть, процессы на них уже выстроены. Пока все работает, никто не торопится что-то менять. И дело не только в деньгах. Любое изменение – это вмешательство в уже работающие процессы, а последствия такого шага заранее оценить сложно. Поэтому компании предпочитают не трогать то, что работает, и откладывают решения на годы.

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

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

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

Как рост приводит к фрагментации

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

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

Откуда берется разрыв

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

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

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

Логика внедрения. Процессы чаще всего переносят как есть. Это быстрее и безопаснее в моменте, но вместе с ними переносятся все несостыковки между функциями, данными, согласованиями. Сама система их не устраняет – она делает их явными.

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

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

Где развитие идет быстрее

Есть сегменты, где внедрение PLM идет заметно быстрее – и причины там вполне приземленные. Речь о ретейле, пищевой промышленности, FMCG. Там нет сложного инженерного моделирования, нет тяжелых 3D-сборок и длинных циклов подготовки производства.

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

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

Системы есть – взаимодействия нет?

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

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

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

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

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