Привет, Хабр! Меня зовут Сергей Корнеев, я руководитель направления аналитики отдела прототипирования в ПГК Диджитал. Мы занимаемся разработкой пилотных цифровых решений (Proof of concept, MVP), которые упрощают жизнь нашим коллегам и способствуют повышению эффективности бизнеса.
В этой статье расскажу, как мы задумались над процессом осмотра вагонов, как IT-решения помогают бизнесу и почему мы выбрали Telegram-бот, а не другие варианты.
В чём была проблема?
Раньше сотрудники, проводящие осмотр вагонов, использовали бумажные распечатки или ноутбуки. Это было неудобно в полевых условиях, особенно в плохую погоду. Гораздо удобнее просто ввести номер вагона в смартфоне и сразу получить нужную информацию в соответствии со своей ролью.
Другой сценарий: осмотрщики звонили коллегам по телефону, просили проверить данные по вагону в системе, что отвлекало их от работы. Ошибок при передаче информации было мало, но, например, можно было неверно расслышать номер вагона. Самым сложным была именно подготовка и затрачиваемое на неё время: печать материалов или формирование выгрузок из разных систем, а также необходимость носить с собой ноутбук.
Путь решения
Заказчиками проекта выступили коллеги из отдела нормативно-технического регулирования и инноваций нашей материнской компании – Первой грузовой компании (ПГК), они занимаются повышением эффективности эксплуатации вагонов компании.
Для проверки гипотезы о востребованности такого инструмента был выбран формат рабочего прототипа: базовая сборка функционала с возможностью “боевого” тестирования на реальных пользователях и данных. Команда прототипирования рассмотрела несколько вариантов и остановилась на разработке Telegram-бота.
Почему Telegram-бот?
Мы рассматривали разные варианты: мобильное приложение, веб-интерфейс. Но:
Мобильное приложение — долго и дорого, у нас не было свободных разработчиков под мобильную платформу.
Веб-интерфейс — медленнее, чем Telegram-бот.
Telegram-бот — идеальный баланс: по результатам custdev мессенджер уже установлен у всех сотрудников, он удобный и быстрый.
Внедрение прошло легко: анонсы на внутреннем портале, корпоративное ТВ, демонстрация. Уже через короткое время после успешного завершения прототипа у нас было более 90% всех сотрудников, участвующих в бизнес-процессе.
Процесс разработки и технологический стек
По рекомендации наших сотрудников информационной безопасности (ИБ) команда разработки спроектировала многоуровневую архитектуру с реализацией полноценной демилитаризованной зоной (ДМЗ).
Вполне прогнозируемым видится и стек используемых технологий. Так, два backend-а написаны с использованием микросервисной архитектуры в парадигме FastAPI (Python). Почему два? Ответ прост: Часть данных находится во внутреннем контуре ИС ПГК. Здесь работает основной backend, отвечающий за аутентификацию, авторизацию (PostgreSQL), обработку запросов пользователей с использованием данных из различных витрин данных (Oracle, MsSQL), средства администрирования и т.д. Стоит упомянуть, что для поддержания актуальности доступов к данным, реализован scheduler-механизм (автоматически запускается по расписанию), который сравнивает перечень активных пользователей с учетными записями в ActiveDirectory и деактивирует тех, кто ушёл из компании и не имеет более учётки AD. Также, система использует Email-Service для подтверждения прав пользователей при регистрации/периодической реактивации.
Второй backend архитектурно планировался к размещению в ДМЗ. Он отвечает за интерфейсную часть, реализованную через Telegram-Service. Между собой backend-ы общаются через Kafka (брокер сообщений).
Считаю, плох тот проект, в котором не возникло “нештатной” ситуации, удивившей фантомной ошибкой, требующей приложения усилий в тестах. Не буду утомлять подробностями, но есть некоторые нюансы при разборе с помощью Listner (consumer) сообщений от Kafka. Если разбор очередного сообщения несколько затянулся, брокер считает его ошибочно “не разобранным” и отправляет вновь. Поэтому все полученные сообщения сразу оборачиваются в обёртку и запускаются в отдельном автономном процессе. Так ответы на некоторые запросы в Telegram пользователь видит в не том порядке, в каком отправил. 🙂
В завершении самого “скучного” блока про техстек хочется отметить систему ролевого доступа. Естественно, к любому объекту/сущности системы у каждой роли прописывается индивидуальная матрица по типу доступа (CRUD+массовые операции). Любой пользователь может обладать произвольным количеством ролей (права суммируются). В дополнении к этому система анализирует вхождение каждого пользователя в спецгруппы ActiveDirectory и ограничивает выданные ролевой моделью доступы матрицей доступов групп AD. Таким образом, функционирует трёхуровневая система безопасности, нивелирующая человеческий фактор (корп-Email => Ролевая модель => AD).
Кстати, все запросы пользователей, изменения состояний, сущностей и т.д. логгируются, что позволяет, не только произвести “разбор полётов” в случае инцидентов, но и перманентно проводить всестороннюю аналитику востребованности сервисов.
Как определяли функционал?
Заказчик собрал пожелания сотрудников и передал в отдел прототипирования. Основные требования:
получать информация по вагону (дислокация, комплектация, ремонты, накладная);
удобный и мгновенный доступ через Telegram;
отсутствие необходимости отвлекать коллег.
Как проходило тестирование?
Первый этап — тестирование внутри отдела прототипирования.
Второй этап — тестирование заказчиками.
Третий этап — запуск на конечных пользователях.
Неожиданных багов не было, помимо упомянутых выше нюансов при разборе с помощью Listner (consumer) сообщений от Kakfa. Обратную связь от первых пользователей собирали итеративно и вносили правки.
Результаты
Подготовка к запланированному осмотру вагона сократилась с 3 минут до 1 минуты.
Незапланированный осмотр — с 15 минут до 1 минуты.
Сотрудники больше не отвлекают коллег запросами по телефону.
Работа с Telegram-ботом удобнее, чем с бумагами или ноутбуком.
Более 90% сотрудников, участвующих в бизнес-процессе, проявляют регулярную активность.
Отзывы коллег
Сотрудники центрального аппарата и филиалов ПГК уже активно пользуются ботом и рекомендуют его коллегам. Среди плюсов они отмечают возможность в любой момент и в любом месте с телефона получить практически всю информацию о вагоне. Специалисты, которые выезжают "в поле", пользуются ботом часто, так как это существенно сокращает получение оперативной информации (экономия в среднем 5-10 минут).
Среди недостатков коллеги назвали отсутствие истории по операциям дислокации, а также предложили добавить функцию по определению номера вагона через камеру смартфона и возможность загружать список вагонов: станция дислокации, станция назначения, парк (рабочий/нерабочий).
Как бот повлиял на рабочие процессы?
Роли и обязанности сотрудников не изменились, но сам процесс стал быстрее и удобнее. Сопротивления не было, наоборот, коллеги ждали удобный инструмент.
Дальнейшее развитие бота
Бот будет дальше совершенствоваться: появятся новые функции по обратной связи от пользователей, например, добавление информации по номерам деталей, интеграция с системами учёта деталей.
К слову, другие Telegram-боты для различных команд бизнеса уже внедрены и развиваются.
Выводы и советы
Telegram-бот — не костыль, а удобное решение, которое можно внедрить быстрее и дешевле мобильного приложения.
Автоматизация не всегда требует сложных технологий — иногда достаточно удобного интерфейса.
Если сотрудники ждут инструмент — внедрение пройдёт легко.
Telegram соответствует требованиям ИБ при правильном подходе.
Что учитывать?
Не стоит усложнять — мобильное приложение могло бы занять больше времени и ресурсов.
Интеграция с внутренними системами может оказаться сложнее, чем кажется.
Проект не заканчивается на первой версии — развитие идёт на основе реальных запросов пользователей.
Что думаете? Делитесь в комментариях, как Telegram-боты помогают вам в работе!