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

Объёмный план затрагивает весь производственный цикл: от закупки сырья и управления запасами до отгрузки продукции клиентам и, конечно, включает производство. Все должно быть согласованно, четко подогнано одно к другому и работать как часы. Без крутой ИТ-системы здесь не обойтись.

С 2016 года мы пользовались зарубежным софтом, но система устарела, а обновления стали недоступны. Нам предстояли муки выбора российского решения, инженерные компромиссы и кастомизация. И тут мы первыми в России рискнули сделать ставку на систему объемного планирования In.Plan. Только вот нюанс: решение было облачным, а нам был нужен крепкий on-premise прямо в нашей промышленной инфраструктуре, ну и других требований к кастомизации было миллион.

Муки выбора

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

В результате мы выбрали систему In.Plan. Модуль In.Plan SNP, на наш взгляд, был самым зрелым из представленных решений. Уже на этапе «коробки» система покрывала 75–80% функционала и позволяла рассчитывать оптимальные планы продаж, производства, закупок и перемещений с учетом особенностей металлургии. А металлургия – это сложные производственные цепочки, ограничения по мощности оборудования и более 20 000 единиц продукции.

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

Оставшиеся 20-25% функционала потребовали серьезных доработок, работ по настройке «коробки» и внедрению (тестирование, обучение пользователей, опытно-промышленная эксплуатация), на которые понадобилось порядка 10 месяцев, но об этом чуть позже.

Что было в коробке?

Архитектура In.Plan изначально задумывалась под требования enterprise-уровня: масштабируемость, надежность, безопасность и гибкость кастомизации.

In.Plan пошел по платформенному пути, где каждое технологическое решение усиливает гибкость продукта.

Прикладной уровень

В основе системы:

·       Frontend на Angular — для построения динамичных интерфейсов;

·       Более 20 backend-сервисов на Java (Spring Boot) — каждый отвечает за свою функцию в архитектуре.

Чтобы обеспечить гибкую работу с объектами системы, реализована архитектура метаданных. Метаданные доставляются в оперативную память сервисов через Kafka, а сами данные хранятся в PostgreSQL.

Хранилища и аналитика

Для задач отчетности и многомерного анализа обеспечена бесшовная интеграция между PostgreSQL и ClickHouse — это позволяет:

·       Строить отчёты на базе Apache Superset;

·       Реализовывать OLAP-кубы с обратной записью (агрегация/дезагрегация сценариев планирования в режиме реального времени).

Алгоритмическая подсистема

Расчётные модули системы используют:

·       Apache Spark, Python (Pandas) и SQL;

·       Запуск как по расписанию (Airflow), так и «на лету» — через API, контейнеры и шаблоны.

Особое внимание уделено оптимизационному ядру. По стандарту используется Google OR-Tools в связке с различными солверами, но для НЛМК мы совершили подключение к солверу стороннего вендора.

Инфраструктура

Архитектура In.Plan полностью контейнеризирована: все модули работают в Docker, оркестрация выполняется через Kubernetes.

CI/CD-процессы построены с использованием GitLab, Helm и Terraform, что позволяет безопасно и быстро обновлять систему.

Для мониторинга и логирования применяется Prometheus, Grafana, а для трассировки — OpenTelemetry.

In.Plan использует тот же стек, что и мы — Java 21 и микросервисную архитектуру, как и наша Единая Цифровая Платформа (ЕЦП).

Что доработали? Важность букв: какое ТЗ — такой результат

Мы сразу поняли, что не хотим строить «космический корабль» и не пытались выдумать новый функционал «с нуля», а максимально описали систему, на которой раньше работало объемное планирование: ключевой функционал, модель данных, отчетность, стратегии оптимизации для расчета плана в солвере. ТЗ было настолько детальным, что все было реализовано в точности, как мы хотели.

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

Во-вторых, ряд продуктов может не иметь спроса в периоде планирования, т.е. эти продукты и маршруты производства по ним не актуальны для планирования. Но если они присутствуют «в поле зрения оптимизатора», то на их просчет тоже тратятся вычислительные мощности. Оптимально сразу исключить их. Мы настроили алгоритм фильтрации входных данных перед подачей в оптимизатор и сократили время расчета плана от 15 до 20%.

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

В математике это называется жадный алгоритм (greedy algorithm). Он берет производственную цепочку и «разматывает» ее с конца — по связям смотрит ее до самого начала, собирая показатели. Например, чтобы произвести 100 тонн оцинкованного рулона, нам нужна 101 тонна на прокате, а до этого 102 тонны на разливке сляба (только таких продуктов тысячи, а длина цепочки для каждого продукта ~15 переделов). Таким образом, каждый передел производства делает свой вклад в сквозную себестоимость, и мы покомпонентно видим из чего она сложилась для каждого продукта. По сути, это постпроцессинг, который не прогнозирует и не советует, а расшифровывает уже полученный результат.

А еще мы научились считать себестоимость и маржинальность для уникальной позиции спроса. Что это такое и чем отличается от единицы готовой продукции? Это сложно. Например, мы запланировали произвести продукт А (всего 1000 тонн, из них 600 тонн в одном цехе, а 400 тонн в другом). Эти 1000 тонн мы хотим продать 6 клиентам, каждый из которых планирует купить разное количество продукции. Какому клиенту запланирован металл из какого цеха раньше понятно не было, а теперь мы это легко вычисляем. Это дает возможность увидеть маржу по клиенту, а потом размещать заказы в нужном нам цехе, ориентируясь на полученный план.

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

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

Для расчета единого объемного плана, было настроено подключение к солверу стороннего вендора, а для интеграции — ETL‑решение DatAx, разработка компании Axenix. In.Plan был интегрирован со смежными продуктами (Планирование спроса, Управление данными, Управление квотами, Отчетность и т.д.), что позволило сделать процесс сбора данных максимально быстрым и эффективным, минимизировать ручные манипуляции.

Cloud сделали On-premise

Еще одной проблемой было то, что почти все решения были заточены под облако. По корпоративным стандартам, да и с точки зрения конфиденциальности, нам требовался полноценный on-premise — все должно было жить на наших, липецких и московских, серверах, чтобы ни один байт чувствительных производственных данных не ушел «на сторону».  Для решения такой задачи была необходима глубокая проработка возможности перемещения системы совместно с вендором и ИБ.

Перевести облачную систему в on-premise — испытание не для слабонервных. Команда Axenix не испугалась задачи и адаптировала архитектуру: глубокая интеграция с нашими BI, Kafka, Clickhouse, внутренними модулями планирования, собственная система авторизации и безопасности. Развертывание прошло на серверах НЛМК, вся поддержка — внутри периметра, никакой зависимости от облака и платформы третьих сторон.

Метрики эффективности

Запуск в эксплуатацию прошел спокойно: пользователи быстро адаптировались, а In.Plan показал х2 ускорение производительности расчета плана с 25 до 12 минут. И это только расчет в оптимизаторе. Время от подачи входных данных до формирования отчетности сократилось в большее количество раз. Кроме того, если раньше параллельность расчетов набора планов (продаж, производства, закупки и др.) была не доступна, то после внедрения мы смогли запускать сразу 3 расчета одновременно. Сходимость планов между старой системой планирования и In.Plan составила 99,9 % уже на первом этапе внедрения, что говорит о корректности и достоверности получаемого результата, но уже с сильным облегчением процесса расчета. 

Сходимость планов между системами измерялась по следующим разрезам:

Проект стартовал с модулей Supply Planning и Optimizer, повторение функционала заняло всего 5 месяцев, а полный цикл внедрения платформы — 10 месяцев, что стало рекордом для отрасли.

На других надейся, сам не плошай

Наш принцип — не отдавать внедрение на 100% подрядчику. Проект изначально строился как совместная работа трех сторон — команды продукта In.Plan, интегратора и специалистов НЛМК (бизнес-эксперты и команда НЛМК ИТ). Такой формат стал моделью партнерства в цифровой трансформации, где объединились методология, разработка и бизнес-экспертиза. Ключевой особенностью стала совместная разработка: функциональные эксперты, тестировщики, аналитики и инженеры-математики нашей компании работали бок о бок с командой интегратора Axenix, участвуя во всех проектных сессиях, совместно прорабатывали требования и напрямую влияли на итоговое решение. Такой уровень взаимодействия обеспечил эффективную передачу знаний и еще на этапе внедрения позволил сформировать внутренний центр компетенций In.Plan: наша команда переняла экспертизу у команды Axenix, глубоко разобралась в функциональности системы и активно участвовала в циклах тестирования и приемки системы.

В рамках партнерства несколько наших разработчиков (специалисты по Java и Angular) были интегрированы непосредственно в команду разработки In.Plan. Работая совместно с командой In.Plan, они участвовали в разработке требований к платформе и создании нового функционала. При этом реализуемые улучшения носили универсальный характер: они вошли в базовую линейку развития продукта In.Plan в рамках его регулярных релизов. Таким образом, новые возможности, разработанные при участии НЛМК ИТ, стали доступны не только самому предприятию, но и всем пользователям платформы In.Plan.

User onboarding

Внедрение системы In.Plan в НЛМК стало важным шагом в совершенствовании процессов планирования. На всех этапах внедрения мы работали с Axenix в составе единой команды, которая обеспечивала поддержку и обучение пользователей. Системой активно пользуются специалисты отдела объемного планирования – это 5 пользователей, так как построение плана должно быть консолидировано, а вот отчетами и результатами полученного плана пользуются смежные функции, такие как продажи, закупки, производство, контроллинг и многие другие.

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

Что дальше?

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

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