Уберизация здорового человека: мы решили транспортный вопрос на предприятии
Как устранить аварию? Вовремя доставить на место ремонтника с правильными руками и инструментами. А как это делать быстро и автоматизировать взаимодействие всех участников процесса — я, Сергей Куцанин, руководитель проектов в ЕвразТехника ИС, расскажу в статье.
Качканарский комбинат очень большой: от одной точки до другой можно идти часами. Для решения этой проблемы на предприятии есть служебный транспорт. Но возникает новая задача — обеспечить наличие транспорта в нужном месте в нужное время.
Для этой задачи мы придумали сделать аналог «Яндекс.Такси» для домашнего пользования при помощи телеграм-бота и решения от МТС. Приглашаю под кат — узнать, что из этого получилось.
Сначала было так: у каждого подразделения — своя техника. Если техника нужна внепланово — можно обратиться к диспетчеру, он подберёт и пришлёт машину. Вроде разумно. Но посмотрим внимательнее.
Допустим, условный электрик Василий должен отправиться на ремонт в другой конец комбината. Свободной машины нет, и Василий обращается к диспетчеру. При этом свободная машина может стоять рядом, но на неё имеет планы механик Пётр. И если Василий просто скажет: «Дай мне съездить починить локомотив», — Пётр может отказать, ведь нет гарантии, что ремонт электрика закончится быстро.
Так что диспетчер ищет машину, которая не прикреплена к другому подразделению. Ей, разумеется, нужно время доехать до Василия. А Василий ждёт и нервничает.
Транспорт — в общий доступ
При первом взгляде стало понятно: технику надо забрать из постоянного пользования и передать одному подразделению, которое будет выделять её всем желающим. Так и сделали.
Транспортом стал распоряжаться промышленный диспетчер. Он расставлял приоритеты и определял, куда отправить машину.
Но быть в курсе всего, что происходит на комбинате, следить за всеми машинами и мгновенно отвечать на все сообщения — это задачи не для диспетчера, а для супергероя. Диспетчеру надо было помочь.
Так мы задумались об IT-решении, которое смогло бы принимать заявки от подразделений и распределять по автотранспорту.
Автоматизировать хотелось в сжатые сроки, используя готовое решение. Мы сравнили разных подрядчиков: не все поддерживали нужную бизнес-модель. Например, некоторые решения не подразумевали возможности создания изолированной рабочей области. То есть мы не могли использовать такие системы для управления собственным автопарком и ограничить доступ к оформлению заказов.
Ненадёжные решения без долгосрочной техподдержки мы сразу отмели. Из оставшихся выбрали самое быстрое: МТС предоставили нам тестовый стенд для полноценной работы через неделю. Для сравнения: большинство девелоперов предлагают от полугода до года разработки.
В итоге мы организовали MVP на нескольких машинах всего за месяц. Раздали смартфоны водителям, завели на карте геоточки (пункты назначения для маршрутов) и начали практически в ручном режиме оформлять заявки. Эксперимент удался, и мы решили масштабировать его на весь парк дежурного автотранспорта.
Дать сотрудникам самим заказывать транспорт
Но в решении МТС нет роли заказчика. Подаёт заявки и распределяет их между водителями диспетчер. (Ещё он может посмотреть статистику.)
А нам нужно было, чтобы любой сотрудник мог запросить технику. Эту часть пришлось разрабатывать самим. Мы сделали телеграм-бот, в котором можно было оформить заявку. Заявки передавались через API в платформу МТС. А она уже распределяла транспорт и следила за статусом заявок.
О технической стороне
Наш бэкенд выполняет три задачи:
управляет внутренней БД,
работает с API МТС,
работает с API Telegram.
Диаграмма развёртывания приложения
Сам бэкенд написан на C# на платформе .NET.
Внутренняя БД сделана на PostgreSQL. В ней мы храним информацию о пользователях и заявках, а также данные для телеграм-бота.
API MTC «Мобильные сотрудники» довольно функционально. Например, с помощью REST API из платформы МТС можно получать список задач, доступных точек на карте, свободных исполнителей и прочего.
API МТС «Мобильные сотрудники»
Надо было подобрать нужные методы, обернуть вокруг них клиента и написать бот для пользователей. Когда пользователь оставляет заявку в боте, информация в нужном виде передаётся на платформу МТС и там обрабатывается.
Проект занял примерно полгода. Так как проект не требует значительных ресурсов, решили не привлекать полноценную команду. Сама разработка велась три месяца силами двух человек:
DevOps-инженер (готовил сборочную линию),
Project Manager, аналитик, разработчик, а также автор этой статьи в одном лице.
Как мы добились эффективности
Во-первых, мы разметили территорию на 6–7 крупных геозон. Внутри каждой геозоны есть примерно десяток геоточек (объектов, куда можно заказать транспорт). Всего на территории комбината 50–60 таких геоточек. Например, у нас есть геозона »9-й квартал» и в ней 12 объектов.
Данные о геоточках используются при оформлении заявки. Они подтягиваются через API из платформы MTC, чтобы минимизировать ручной ввод.
Пример разметки геозон и точек на карте
Во-вторых, классифицировали имеющийся транспорт: уазики, буханки, уазики с кузовками, газончики, уралы с манипуляторами. При этом машины могут попадать сразу в несколько категорий. Например, газели относятся к категориям транспорта на четырёх и на 6 человек. Это позволяет отправлять на вызов наиболее подходящий транспорт.
Как видит систему заказов сотрудник
Теперь, если электрику Василию нужна машина, он открывает бота и делает заявку.
При заказе он выбирает задачу — например, перевозка персонала, документов или грузов. Это нужно в первую очередь чтобы определять подходящие модели транспорта: для грузов — грузовой, для персонала — пассажирский с достаточным количеством мест. Набор доступных геоточек также фильтруется с учётом задачи вызова (например, складские ворота доступны только для задачи «перевозка груза»). Затем Василий отвечает на несколько уточняющих вопросов: какой вид транспорта куда подать, куда он планирует ехать и когда.
Заявка попадает через бот в систему МТС «Мобильные сотрудники». Там машины уже распределены по территориальной близости, степени свободности и категории транспорта. Система классифицирует заявку и назначает подходящую машину.
При этом у водителя в мобильном приложении отображаются все необходимые данные о заказе: номер, заказчик, описание задачи, конечные точки маршрута и время, когда нужно забрать заказчика.
А у заказчика тем временем меняется статус исполнения заявки (водитель взял в работу → водитель подъехал → водитель закончил). К тому же из системы МТС заказчику приходит ссылка, по которой он может отслеживать водителя.
Машина подана, электрик добрался до поломки — машина уезжает. Завершив ремонт, Василий снова сделает заявку в боте.
А вот так список заявок видит диспетчер:
Список заявок в личном кабинете диспетчера
Распространяем решение на тепловозы
Идея появилась после того, как шеринг дежурного автотранспорта успешно запустился.
Хотя бо́льшую часть работы в рудовозном районе выполняют электровозы, тепловозы ещё нужны для вспомогательных задач: привезти песок на экипировку, восстановительный поезд и так далее.
Здесь обнаружилась та же история. Например, нужен тепловоз — забрать из депо два вагона и два поставить на ремонт. Только у другого подразделения есть доступный тепловоз. Но, как мы уже поняли, его не дадут, поскольку на него есть планы.
Мы знаем, что делать.
Во-первых, открепляем тепловозы от подразделений и передаём в общее пользование. Назначаем ответственных за выделение техники по запросу.
Во-вторых, дорабатываем IT-решение. Вариативность заявок на тепловозы значительно выше, чем на автотранспорт. Поэтому логика оформления заявок оказалась сложнее. Пришлось разработать матричную структуру: она позволила в зависимости от типа заявки применять разный набор параметров, которые должен заполнить заказчик.
Например, для «маневровых работ» нужно указать станцию начала работ, время начала и планируемое время занятости. А для «транспортировочных работ» — вид подвижного состава, номер пути, номер оборудования и пункт назначения. Типов заявок набралось 14 штук.
Общий стек и принцип остались без изменений, пришлось лишь разработать нового бота и новый личный кабинет МТС.
Возможности пользователей сохранились. Заказчик может оставить заявку и следить за её статусом. Исполнители видят всю нужную информацию по заказу. А руководители цеха и дежурные по станции могут контролировать, где находятся в тепловозы, какие задачи выполняют, как передвигаются и сколько времени простаивают.
Так мы снова убедились, что совместное пользование на базе современной платформы помогает бизнесу (даже без существенных затрат).
Что изменилось после нашего решения
Во-первых, выяснилось, что нам нужно меньше техники. Исключив простои машин, мы смогли отказаться от 10% легковых авто.
Во-вторых, мы сделали процесс прозрачным для заказчика. Теперь он понимает, когда ждать машину, и лучше планирует свой рабочий день. А ещё пользователь может посмотреть в боте, какие машины заняты, какие свободны и на какое время исполнения заявки сейчас можно рассчитывать.
В-третьих, мы разгрузили грузовики и большой пассажирский транспорт за счёт легковушек — стали лучше понимать, какую машину отправить на конкретный заказ. Теперь автобус не везёт одного человека.
В-четвёртых, мы разгрузили диспетчеров. Распределением машин, контролем заявок и движением транспорта дирижирует система. Но диспетчер всё видит и при необходимости может перехватить управление.
Конечно, нельзя сказать, что мы сократили срок исполнения заявки для тех, у кого раньше была выделенная машина, — если машина закреплялась за твоим подразделением, она всегда находилась в доступе. Но тем сотрудникам, у кого выделенной машины не было, стало гораздо проще.
