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

Копились и другие проблемы.

Например, пользователи стали продвинутыми и жаловались на дружелюбность интерфейса. На самом деле тяжело представить в одном предложении слова «дружелюбность интерфейса» и нашу старую систему заявок на транспорт.

Всё это работало только под IE/Edge, не поддерживало Хромиум, конфликтовало с требованиями ИБ.

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

Мы давно задумывались о рефакторинге или миграции, суть споров сводилась к самопису или «коробке».

Мы всё проанализировали и решили, что надо взять готовую «коробку», которую потом нужно будет допилить процентов этак на 10.

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

Сейчас я расскажу о дьявольском опыте использования чужой «коробочной» версии как фреймворка для своей разработки. Забегая вперёд — второй раз мы в это не полезли бы.

Задача

Итак, есть автотранспорт НЛМК: это 18 видов техники и такси. Какая-то техника уникальная, например, ассенизаторная машина, тягач-буксировщик, вакуумная машина или цементовоз. А какая-то — с частично перекрывающимся функционалом, например, портативное оборудование можно возить и в пассажирском такси, и на грузовом, какие-то вещи можно класть в машину и навалочной погрузки, и штучной, такси и автобусы частично взаимозаменяемы, самосвал с манипулятором грайферного типа умеет делать всё то же самое, что и обычный самосвал, а ещё хватать предметы и так далее.

Диспетчерская, по идее, должна получать заявки от производства, составлять оптимальное распределение техники и раздавать задачи.

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

Выглядело это примерно вот так:

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

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

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

В-четвёртых, система предполагала множество ручных операций. Интеграций почти ни с чем не было, поэтому всё держалось на опыте диспетчеров.

Плюс, конечно, всё это надо было сделать на более современном стеке, чтобы оно работало везде, проверить, чтобы это соответствовало требованиям ИБ, и убедиться, что интерфейс дружелюбнее, чем был. Хотя любой интерфейс при любых вариантах дружелюбнее, чем был.

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

Классический случай запущенного техдолга.

Надо было выбрать и внедрить TMS.

Это Transportation Management System

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

Чего хотели:

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

• Улучшить утилизацию собственного транспорта за счёт интеграции карт и оптимизации маршрутов.

• Снизить пробеги, то есть экономить топливо. И вообще контролировать треки транспорта прямо там же, где раздаются заявки.

• Больше данных для анализа, в частности, планирования.

Выбор был между решениями на 1С или SAP. В итоге выбрали standalone-решение на базе 1С. Собственно, по заголовку поста вы уже догадываетесь, куда нас завела дорога приключений, и сейчас я расскажу, как нам прострелили колено.

В чём засада

Поначалу всё смотрелось очень хорошо: сравнили несколько вариантов решений, которые наиболее полно соответствовали заявленным требованиям. При этом на 100 % ни одно из решений не соответствовало предъявленным требованиям. Каждая система нуждалась в существенной доработке:

• В «коробочном» варианте система имела функционал заявок и выдачи путевых листов, мобильного клиента для водителя, отслеживание транспортных средств на карте, учёт парка автотранспорта, учёт технического осмотра и так далее. Сейчас система постоянно отслеживает местоположение автомобиля, следит, сигнализирует диспетчеру обо всех отклонениях от маршрута и автоматически по данным GPS понимает, когда началось выполнение рейса и когда он завершился.

• Прошлую систему мы поддерживали 20 лет, и там накопилось много процессов, которые на рынке мало кто видел. То есть все эти процессы в виде фич надо было перенести в «коробочную» версию. Естественно, предполагалась некоторая доработка.

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

• Чтобы автоматически печатался путевой лист, нужно ещё с десяток интеграций (но, к счастью, простых).

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

Будущее наступило почти сразу.

Но сначала мы пошли по стандартному проектному треку: описали бизнес-процессы, определили объём. Принесли «коробку», посмотрели на процессы, наложили их друг на друга, определили разницу между тем, что есть, и тем, что надо.

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

Мы прекрасно понимали, что всё это заточено под массовый рынок вроде ЧОПов (которым надо видеть свой автопарк), складов и так далее. На берегу предполагалось, что можно начать переделывать, быстро получить пригодную систему и потихоньку силами подрядчика её допиливать. Для подрядчика — продавца массовой версии — это форк их продукта, и они должны были обеспечить вторую-третью линии поддержки, где третья фактически допиливает фичи.

Всё пошло не по плану

Большая часть TMS на рынке сделана для крупных систем, предполагающих длинные маршруты. У нас на НЛМК цеха расположены близко друг к другу, это сотни метров. На коротких плечах наша «коробочная» система просто пасовала по производительности. Обновление GPS-данных шло медленно, с лагом около одной–двух минут. У нас это означало, что пока система думает, уже нужно делать следующий кусок маршрута, следующую заявку. На 700 единиц техники сам модуль расчёта уже начинал захлёбываться и тормозить, что подвешивало систему.

В итоге подрядчик в своё ядро после переговоров не полез (точнее, делал это крайне медленно по понятным причинам), зато мы вывели свою команду разработки и начали дорабатывать чужой движок.

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

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

Плюс предполагалось масштабировать это на другие площадки Группы НЛМК, поэтому в итоге своя команда с экспертизой всё равно была бы нужна. Без экспертизы это было бы одним удачным внедрением или парой — как получится.

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

Чем всё закончилось

Всё это заняло три года — с 2020-го по 2023-й.

Собрали систему, которая умеет всё что нужно, повторяя большую часть наших процессов. К ней сделали несколько мобильных приложений разного назначения: для диспетчеров, водителей и заказчиков. Там сделали спеки и вывели отдельную команду. Спроектировали 26 шаблонов-макетов форм заявок, продумали бизнес-логику, чтобы под каждый шаблон не писать модуль, сделали гибкую настройку, а также синхронизацию, вывели бизнес-логику на сторону 1С.

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

Для того чтобы система могла грамотно составлять маршруты и следить за состоянием перевозок, в решение от 1С интегрировали цифровую карту комбината.

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

Сегодня система насчитывает больше двух тысяч пользователей, через неё каждый месяц проходит более 30 тысяч заявок. Средний парк — 700 единиц техники. Работа с системой ведётся через десктопную версию и три мобильных приложения. Среди них есть отдельное приложение для технических специалистов: машина не сможет покинуть территорию гаража, если механики не отметят в программе её соответствие техническим нормативам. Кроме того, есть 14 интеграций с различными системами и сервисами. Собираются данные для планирования.

Затраты на привлечение стороннего транспорта сократились примерно на 15 %, а расходы на поддержку и обслуживание собственного снизились на 10 % за счёт оптимизации его использования.