Когда «коробка» ломается о реальность. Опыт НЛМК по внедрению TMS

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

В 2022 году компания начала проект внедрения TMS (Transport Management System). Первоначально предполагалось использовать готовое «коробочное» решение. Однако уже в процессе стало ясно: типовые инструменты не учитывают отраслевую специфику и не масштабируются на нужную глубину. В результате продукт был фактически переработан, сохранилась лишь его архитектурная база. Евгений Груздев, старший руководитель проектов НЛМК ИТ, — о том, как «коробочная» система оказалась фреймворком для собственной разработки и к каким результатам это привело.

Логистика внутри комбината

НЛМК — один из крупнейших металлургических производителей в России. На одном только Липецком комбинате:

• свыше 700 единиц техники, включая тягачи, цементовозы, спецтранспорт;
  
• 18 типов транспортных средств, часть из которых не поддерживается в типовых TMS; более того, среди техники есть как уникальные позиции (ассенизаторная машина, тягачи), так и универсальные (для перевозки небольших предметов подойдет и пассажирское, и грузовое такси);
• более 600 ПК-пользователей и порядка 1000 пользователей мобильного приложения: диспетчеров, водителей, контролеров транспортных средств и заказчиков перевозок;
• порядка 1000 заявок в день и 500 рейсов, 24×7, в рамках сменной модели работы.

Решение о необходимости перехода на новую TMS витало в воздухе. До запуска проекта логистика управлялась через легаси-решение, которое мы поддерживали более 20 лет. Естественно, за такое время со стороны пользователей накопилось много пожеланий по доработке и развитию функционала, которые старая платформа не позволяла реализовать. Например, не поддерживала мобильный доступ, интеграцию с картографией, GPS-трекинг и другие функциональные возможности. Нормально работало только под Internet Explorer и Edge (Chromium — не, не слышали), были задержки в передаче данных между системами, которые достигали нескольких часов, также были нарекания с точки зрения информационной безопасности.

Фактически вся работа диспетчеров строилась на бумажных заявках. Специалисты подбирали ближайшую к точке старта единицу техники и назначали ей рейс, исходя из собственного опыта. Система была негибкой: даже если заявки предполагали небольшую занятость транспорта, вроде выезда ассенизатора или поездки для журналистов, в системе транспорт значился занятым на всю смену, невозможно было воспользоваться им на меньший срок. Из-за этого одной машине нельзя было поставить несколько задач в одну смену или объединить их в один сложный маршрут с несколькими точками и подзадачами. В итоге периодически возникал дефицит транспорта — тогда прибегали к аренде или по телефону связывались с водителями, выясняя, какая машина освободилась, и оформлять на нее рейс. Не было и инструментов для понимания, какая техника подходит для конкретной задачи — это решалось «вручную». На плечи персонала ложилась оптимизация маршрутов, объединение заявок, контроль доступности и компетенций. При этом никакой актуальной информации по статусам и пробегам не было.

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

На «коробках» учатся, или Момент, после которого не так пошло почти все

Таким моментом для нас стало решение о внедрении «коробочного» продукта с его минимальным «допиливанием» на месте.

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

Сейчас на рынке не так много TMS, либо они ориентированы на аутсорсинг и магистральные перевозки, либо это тяжелые корпоративные платформы уровня SAP. Мы выбрали систему на базе «1С» как наиболее гибкую с точки зрения модификации, тем более что в нашей команде есть специалисты, уже работавшие с продуктами «1С» и способные «допилить» эту «коробку» под нужды компании. Мы предполагали, что после внедрения наши запросы будут закрыты на 80%, доработки потребуют только оставшиеся 20% или около того. Но уже на этапе внедрения стало очевидно: модули не подходят под наши ключевые требования. Просчитались, но где?

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

Во-первых, как и многие аналогичные продукты, она была сделана для управления магистральными, междугородными перевозками, заточена под процессы, отличающиеся от наших. Там длина маршрута измеряется даже не десятками, а сотнями километров, и, как правило, простой маршрут «из точки А в точку Б» с одной задачей: тут погрузил, там разгрузил. А перевозки внутри комбината — это порой перемещения на сотни метров с несколькими точками погрузки или разгрузки. Даже маршруты по городу, за пределами комбината, особо длинными назвать нельзя. Конечно же, есть и продолжительные маршруты — например, командировки на большие расстояния, с которыми функционал справлялся. Но все же, один рейс может состоять из нескольких точек (скажем, машина сначала собирает грузы из нескольких цехов и потом везет их в конечную точку, иногда что-то выгружая на промежуточных) или представлять собой доставку по цепочке. Иногда «точку Б», то есть конечную точку маршрута, просто невозможно задать заранее (развоз сотрудников по городу или та же поездка с журналистами).

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

И по мелочи: интерфейс не масштабировался под мобильные устройства, отсутствовала интеграция с цифровой картой комбината, данными СКУД, ERP и медицинскими системами.

Собственная система, но — поверх платформы

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

Дополнительный плюс такого подхода для нас заключался в том, что мы понимали: после внедрения и отладки этого решения на липецкой площадке его рано или поздно нужно было бы масштабировать, перенося на другие площадки Группы НЛМК. Делать это с командой, которая сама разработала систему, понимает логику ее функционирования и может оперативно внести необходимые изменения, в разы, если не в десятки раз легче. Собственная разработка — процесс тяжелый, но он стал «страховкой» от возможных сложностей на последующих этапах.

На весь процесс, с постановки первых целей, внедрения «коробки», первых выводов, проб и ошибок и до запуска своей TMS, у нас ушло три года — с 2020-го по 2023-й, причем непосредственно разработка своей системы началась в 2022-м и заняла около года. В результате мы получили уникальное решение, которое полностью заточено под потребности конкретной площадки, но при этом может быть легко внедрено на других объектах. Сейчас в системе реализованы все необходимые процессы и удовлетворены все запросы пользователей (и даже чуть больше). Вот что в ней есть:

• цифровая карта комбината, где территория отображается с учетом ворот, точек въезда и выезда (в некоторых зданиях они различаются), зон доступа для грузового транспорта, высоты проездов;
• 26 шаблонов заявок, которые учитывают особенности всех типов техники и сценариев перевозок;
• три мобильных приложения: для водителей, диспетчеров и внутренних заказчиков автотранспорта;
• интеграция с 19 ИТ-системами предприятия — например, ERP, СКУД, системой для предрейсовых медосмотров, системой управления сменами, системой безопасности и др.;
• автоматизированные путевые листы, контроль выхода на линию, построение маршрутов и проведение предрейсового и послерейсового техосмотров.

Результаты

К середине 2024 года новая TMS обрабатывала более 30 000 заявок в месяц и задействовала весь парк в 700+ единиц техники. Общее число пользователей превысило 1500 человек.

Затраты на привлечение внешних подрядчиков снизились более чем на 15%. Кроме того, благодаря TMS в пределах комбината удалось полностью отказаться от бумажного документооборота по внутренним автоперевозкам. При выезде транспорта за пределы комбината по-прежнему выдаются бумажные путевые листы и другие необходимые документы, но в системе уже заложена возможность их оформления в цифровом виде после того, как будут приняты соответствующие изменения в законодательстве.

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

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

Выводы и рекомендации

Проект по внедрению TMS стал для нас хорошим опытом и еще раз показал, что универсальные решения редко соответствуют специфике конкретного предприятия вне зависимости от его масштабов и того, к какой отрасли оно относится. Даже если при первом приближении создается ощущение, что «коробка» закрывает 70–80% ваших потребностей, нужно быть готовым к глубокому рефакторингу или полной замене функциональности. Кастомизация требует продуктового подхода — с документацией и гибкой возможностью масштабирования. И эти задачи не всегда имеет смысл отдавать подрядчику: он не может погружаться в процессы на уровне цехов, то есть запросы не будут реализованы на 100%. В таких случаях лучше сразу формировать in-house-команду разработки и аналитики — это сэкономит время и средства, обеспечит получение желаемого результата, создаст дополнительную внутреннюю экспертизу для компании и определенный «запас прочности» для системы.

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

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