Как устранить аварию? Вовремя доставить на место ремонтника с правильными руками и инструментами. А как это делать быстро и автоматизировать взаимодействие всех участников процесса — я, Сергей Куцанин, руководитель проектов в ЕвразТехника ИС, расскажу в статье.

Качканарский комбинат очень большой: от одной точки до другой можно идти часами. Для решения этой проблемы на предприятии есть служебный транспорт. Но возникает новая задача — обеспечить наличие транспорта в нужном месте в нужное время.

Для этой задачи мы придумали сделать аналог «Яндекс.Такси» для домашнего пользования при помощи телеграм-бота и решения от МТС. Приглашаю под кат — узнать, что из этого получилось.

Сначала было так: у каждого подразделения — своя техника. Если техника нужна внепланово — можно обратиться к диспетчеру, он подберёт и пришлёт машину. Вроде разумно. Но посмотрим внимательнее.

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

Так что диспетчер ищет машину, которая не прикреплена к другому подразделению. Ей, разумеется, нужно время доехать до Василия. А Василий ждёт и нервничает.

Транспорт — в общий доступ

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

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

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

Так мы задумались об IT-решении, которое смогло бы принимать заявки от подразделений и распределять по автотранспорту.

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

Ненадёжные решения без долгосрочной техподдержки мы сразу отмели. Из оставшихся выбрали самое быстрое: МТС предоставили нам тестовый стенд для полноценной работы через неделю. Для сравнения: большинство девелоперов предлагают от полугода до года разработки.

В итоге мы организовали MVP на нескольких машинах всего за месяц. Раздали смартфоны водителям, завели на карте геоточки (пункты назначения для маршрутов) и начали практически в ручном режиме оформлять заявки. Эксперимент удался, и мы решили масштабировать его на весь парк дежурного автотранспорта.

Дать сотрудникам самим заказывать транспорт

Но в решении МТС нет роли заказчика. Подаёт заявки и распределяет их между водителями диспетчер. (Ещё он может посмотреть статистику.)

А нам нужно было, чтобы любой сотрудник мог запросить технику. Эту часть пришлось разрабатывать самим. Мы сделали телеграм-бот, в котором можно было оформить заявку. Заявки передавались через API в платформу МТС. А она уже распределяла транспорт и следила за статусом заявок.

О технической стороне

Наш бэкенд выполняет три задачи:

• управляет внутренней БД,

• работает с API МТС,

• работает с API Telegram.

Сам бэкенд написан на C# на платформе .NET.

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

API MTC «Мобильные сотрудники» довольно функционально. Например, с помощью REST API из платформы МТС можно получать список задач, доступных точек на карте, свободных исполнителей и прочего.

Надо было подобрать нужные методы, обернуть вокруг них клиента и написать бот для пользователей. Когда пользователь оставляет заявку в боте, информация в нужном виде передаётся на платформу МТС и там обрабатывается. 

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

• DevOps-инженер (готовил сборочную линию),

• Project Manager, аналитик, разработчик, а также автор этой статьи в одном лице.

Как мы добились эффективности

Во-первых, мы разметили территорию на 6–7 крупных геозон. Внутри каждой геозоны есть примерно десяток геоточек (объектов, куда можно заказать транспорт). Всего на территории комбината 50–60 таких геоточек. Например, у нас есть геозона «9-й квартал» и в ней 12 объектов. 

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

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

Как видит систему заказов сотрудник

Теперь, если электрику Василию нужна машина, он открывает бота и делает заявку.

При заказе он выбирает задачу — например, перевозка персонала, документов или грузов. Это нужно в первую очередь чтобы определять подходящие модели транспорта: для грузов — грузовой, для персонала — пассажирский с достаточным количеством мест. Набор доступных геоточек также фильтруется с учётом задачи вызова (например, складские ворота доступны только для задачи «перевозка груза»). Затем Василий отвечает на несколько уточняющих вопросов: какой вид транспорта куда подать, куда он планирует ехать и когда.

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

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

А у заказчика тем временем меняется статус исполнения заявки (водитель взял в работу → водитель подъехал → водитель закончил). К тому же из системы МТС заказчику приходит ссылка, по которой он может отслеживать водителя.

Машина подана, электрик добрался до поломки — машина уезжает. Завершив ремонт, Василий снова сделает заявку в боте.

А вот так список заявок видит диспетчер:

Распространяем решение на тепловозы

Идея появилась после того, как шеринг дежурного автотранспорта успешно запустился.

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

Здесь обнаружилась та же история. Например, нужен тепловоз — забрать из депо два вагона и два поставить на ремонт. Только у другого подразделения есть доступный тепловоз. Но, как мы уже поняли, его не дадут, поскольку на него есть планы.

Мы знаем, что делать.

Во-первых, открепляем тепловозы от подразделений и передаём в общее пользование. Назначаем ответственных за выделение техники по запросу.

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

Например, для «маневровых работ» нужно указать станцию начала работ, время начала и планируемое время занятости. А для «транспортировочных работ» — вид подвижного состава, номер пути, номер оборудования и пункт назначения. Типов заявок набралось 14 штук.

Общий стек и принцип остались без изменений, пришлось лишь разработать нового бота и новый личный кабинет МТС.

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

Так мы снова убедились, что совместное пользование на базе современной платформы помогает бизнесу (даже без существенных затрат).

Что изменилось после нашего решения

Во-первых, выяснилось, что нам нужно меньше техники. Исключив простои машин, мы смогли отказаться от 10% легковых авто.

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

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

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

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