Как мы переписали legacy-систему с помощью ИИ и оставили работать в ней ИИ-агентов

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

В НЛМК ИТ мы решили проверить на реальном проекте не только новый инструмент, но и новый подход к организации разработки. Вместо привычной проектной группы мы дали задачу одному инженеру, который координировал команду ИИ-агентов.

В результате эксперимента трудозатраты IT на разработку сократились в 10 раз. Но самое интересное произошло уже после миграции. Мы оставили ИИ-агента работать внутри новой системы – теперь он помогает пользователям.

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

Почему пришлось менять работающую систему

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

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

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

Снаружи задача кажется простой: нужно сформировать сертификат. Внутри – система, которая принимает данные из нескольких источников и обрабатывает их.

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

И вот здесь у нас появился еще один вопрос: а можно ли часть этой работы переложить на ИИ?

А что, если делать привычным способом

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

Внутри НЛМК к этому моменту уже была собственная платформа с ИИ-агентами. Ее идея в том, чтобы человек мог не просто пользоваться ИИ как помощником, а организовывать рабочий процесс, передав отдельные инженерные операции цифровым сотрудникам. Один агент может работать с требованиями, другой – с кодом, третий – проверять результат, четвертый – тестировать, а цифровой тимлид может двигать процесс дальше. Человек при этом контролирует работу этой команды и отвечает за результат. Это означает довольно существенное изменение модели реализации проекта с выделением роли ИИ-инженера: он организует работу цифровых сотрудников и доводит решение до результата. Именно эту модель мы и решили проверить на реальной legacy-системе.

Сначала только один цех

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

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

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

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

Дешевле, но не быстрее

А вот со сроками получилось интереснее. Мы рассчитывали, что новый подход позволит не только снизить стоимость, но и заметно ускорить миграцию. Этого не произошло: весь проект занял примерно те же полгода.

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

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

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

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

Как переводили пользователей

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

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

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

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

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

Вместо чат-бота решили сделать цифрового сотрудника

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

Сейчас в интерфейсе системы есть кнопка «ИИ». Пользователь нажимает ее и начинает диалог с агентом. Агент легко оперирует всем массивом знаний по системе, знает правила ее работы. Он может отвечать на вопросы не только из разряда «куда нажать», но и может, например, определить, какой сертификат был связан с конкретным вагоном. То есть это не просто справочник по интерфейсу, а цифровой сотрудник, который работает внутри контекста системы.

Сейчас мы продолжаем перевод системы в промышленную эксплуатацию и собираем статистику по ИИ-поддержке. Целевой показатель, который рассматриваем, – 70–80% пользовательских запросов закрывать без участия человека.

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

Что мы получили как результат эксперимента

Если собрать результаты в одну картину, получилось несколько выводов.

Первый. AI может быть не только инструментом для ускорения работы разработчика. При определенной организации процесса он позволяет по-другому распределить саму инженерную работу.

Второй. На первом участке миграции трудозатраты IT на разработку сократились в 10 раз. Полная миграция пилотной системы стоила примерно в 5 раз дешевле, чем предварительная оценка по классическому подходу.

Третий. Срок миграции при этом не сократился: интеграции с внешними системами остались существенным ограничением.

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

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

И это, пожалуй, самый неожиданный результат.

Мы начинали с вопроса:

«Можно ли дешевле перенести legacy-систему на современный стек?»

А пришли к другому: «Можно ли сделать так, чтобы после миграции система получила собственного цифрового сотрудника – и часть ее дальнейшего жизненного цикла тоже выполнялась с помощью ИИ?»

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