Вернуть себе завод

Переход на российское программное обеспечение - это не финиш, а только середина пути. Как вернуть предприятиям управляемость, которую они утратили вместе с уходом западных вендоров, рассказал генеральный директор ГК "УльтимаТек" Павел Растопшин.

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

Павел Растопшин: В тот момент у новых владельцев была другая повестка. Главная задача стояла - сохранить производство, не допустить его остановки, разобраться с юридическими вопросами, персоналом, контрактами. Системы работали: линии выпускали продукцию, данные передавались, отчеты формировались. Это создавало иллюзию, что все в порядке. Тогда никто не задумывался о документации, исходных кодах или резервных копиях. Тем более что западные вендоры и интеграторы ушли не в один день - процесс растянулся на год-полтора, и острота проблемы нарастала постепенно.

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

Приведите пример. Как выглядит такая ситуация на реальном заводе?

Главный риск не в том, что система завтра перестанет запускаться, а в том, что после первого серьезного сбоя никто не сможет быстро понять, как ее восстановить

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

Особенно уязвимы непрерывные производства и решения на стыке ИТ и автоматизации: MES, SCADA, учет и маркировка, интеграции с ERP и WMS. Верхний уровень связан с контроллерами, датчиками, приводами, принтерами и сканерами - замена одного компонента способна нарушить всю цепочку. Новый владелец оказывается заложником архитектуры, которую никто не документировал.

Реально ли заменить такую систему без остановки завода?

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

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

Что в таком проекте самое сложное и дорогое?

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

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

Российское ПО и оборудование готовы к масштабной замене? Промышленники сетуют, что отечественные аналоги уступают западным.

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

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

Обеспечивают ли существующие государственные меры поддержку таких проектов?

Павел Растопшин: Если подходить формально, мер много. Есть льготные кредиты, налоговые преференции для производителей и другие варианты. Это создает общий фон и стимулирует спрос.

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

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

Что считать успешным результатом импортозамещения?

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

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