Маршрут, выпуск, реакция: единая операционная система автобусного предприятия
Зачем читать
Если вы руководите АТП или диспетчерским центром автобусного парка - вы знаете про разрыв между планом, фактом и реакцией. План на день есть. Что произошло на маршрутах за день - частично в Excel, частично в чатах, частично у диспетчера в голове. К утру следующего дня - новый план, и старая боль повторяется.
Эта статья - про то, как этот разрыв закрывается операционной системой AAMX.
Что такое AAMX
Это операционный хаб для АТП. Один интерфейс для трёх ролей:
- Диспетчер. Видит план выпуска, факт, отклонения, реакцию.
- Менеджер парка. Видит водителей, машины, маршруты, нагрузку.
- Руководство. Видит KPI, документы, аналитику без сбора Excel-таблиц по понедельникам.
В основе - Traccar (открытый GPS-трекинг, проверенный в индустрии) + наш слой бизнес-логики.
Что закрываем
Четыре типовые боли АТП:
1. Разрыв между планом и выпуском
План вы знаете. Выпуск на линию - тоже. Но связь «план не выполнен потому что водитель Х не вышел / автобус Y сломался / диспетчер Z не успел перенаправить» - её собрать тяжело.
В AAMX план и выпуск - один экран. Отклонения видны в момент возникновения, а не на следующий день.
2. Реакция на инцидент
Маршрут отклонился. Водитель не отвечает. Что делает диспетчер? В половине АТП - звонит другому водителю, ругается в чат, отправляет диспетчера на КПП. В AAMX - инцидент классифицирован, помечен, ответственный назначен, история сохранена.
Не для того чтобы «потом разобраться кто виноват». Для того чтобы через месяц увидеть паттерн: какие маршруты регулярно проблемные, какие водители часто отклоняются, какие машины ломаются чаще.
3. Документы и отчёты
Путевые листы, контроль предрейсовых медосмотров, остатки топлива, замена резины. В стандартной системе это либо в бумагах, либо в трёх разных таблицах без связи.
В AAMX это привязано к водителю и машине, видно историю. Готовые отчёты для контролирующих органов формируются за минуты, не за день.
4. KPI диспетчера и менеджера
Сколько отклонений в день? Сколько вышло на линию вовремя? Какова средняя дистанция между плановой и фактической точкой остановки? Эти метрики либо считаются раз в квартал, либо никогда.
В AAMX это в дашборде, в режиме онлайн.
Технически
- Backend: FastAPI на Python
- Frontend: Vue 3, мобильно-адаптированный
- GPS-трекинг: Traccar (порты 5001-5256)
- БД: PostgreSQL
- Деплой: Docker Compose, на нашем сервере или на ваших мощностях
- Интеграции: открытый API для интеграции с вашими существующими системами
Что НЕ обещаем
Чтобы не было разочарований:
- Не «уберём всех диспетчеров и сэкономим N% штата». Хорошие диспетчеры - редкий ресурс, AAMX делает их работу проще, не заменяет.
- Не «гарантируем X% снижения простоев». Конкретные цифры зависят от вашей ситуации, мы их показываем после пилота на 1-2 месяца.
- Не «сертифицировано ФСТЭК / УЗ-3». Это отдельная аттестация, которая нужна не всем АТП. Если нужна - обсудим отдельно.
- Не «полностью облачная SaaS». Мы можем развернуть на нашем сервере или на ваших мощностях - в зависимости от ваших требований к данным водителей.
Демо
Демо - 20-30 минут, по видеосвязи или у вас на месте (при условии что АТП в Тюмени или рядом).
Что показываем:
1. Карту парка в реальном времени
2. Создание плана выпуска
3. Фиксацию факта и отклонений
4. Документы по водителю
5. Дашборд KPI
После демо - формируем коммерческое предложение под ваш парк.
Кому это подходит
- АТП с парком от 20 автобусов
- Региональные перевозчики
- Муниципальные АТП городов от 500 тыс. жителей
- Школьные и корпоративные перевозчики
Кому пока не подходит
- Парки до 10 машин (неэкономично)
- Перевозчики опасных грузов (другие требования к ПО)
- АТП без диспетчерского центра (нужен человек, который реагирует на оповещения)
Контакты
aamx.ru - кнопка «Запросить демо». Email 1@aamx.ru с темой «AAMX демо».
Как понять, что пора внедрять операционный хаб
Самый простой признак - диспетчерский день заканчивается не отчётом, а восстановлением картины по сообщениям. Если руководитель утром спрашивает, почему вчера часть выпуска ушла с отклонениями, а ответ собирается из звонков, таблиц и памяти людей, значит система уже нужна. Не потому что люди плохо работают, а потому что процесс стал сложнее, чем инструменты, которыми его ведут.
Второй признак - повторяемость одних и тех же проблем. Например, один маршрут регулярно выходит с задержкой, но причина каждый раз описана по-разному. В одном отчёте виноват водитель, в другом машина, в третьем пробки, в четвёртом нет отметки. AAMX полезен именно здесь: он не спорит с людьми, а собирает факты в одну историю и показывает, где проблема повторяется.
Третий признак - рост парка. Пока машин 8-10, многое держится на личном контроле. Когда автобусов 30, 50 или 100, ручная координация начинает съедать время руководителя. В этот момент важно не просто добавить ещё один чат, а выстроить систему, где каждый инцидент получает статус, ответственного и итог. Тогда управление становится не реакцией на шум, а работой с понятными событиями.
FAQ для руководителя АТП
Нужно ли менять весь текущий софт сразу? Нет. Обычно пилот начинается с ограниченного контура: карта, выпуск, отклонения и несколько отчётов. Если уже есть Traccar или другая GPS-система, смотрим, что можно использовать, а что нужно связать через API.
Можно ли развернуть на своих серверах? Да. Для парков с требованиями к локализации данных это нормальный сценарий. В таком случае заранее обсуждаем доступы, резервное копирование, обновления и ответственность за инфраструктуру.
Сколько времени занимает пилот? Ориентир - 1-2 месяца. За это время можно увидеть, какие отклонения повторяются, какие отчёты реально нужны и где система даёт пользу диспетчеру, а не только руководству.
Что будет после демо? Мы не предлагаем покупать «коробку вслепую». После демо фиксируем контур, роли, список интеграций, риски по персональным данным и стоимость внедрения. Напишите на 1@aamx.ru с темой «AAMX демо», и мы подготовим сценарий под ваш парк.
Ещё один важный момент - язык публикаций. AAMX нельзя продавать как «волшебную платформу, которая наведёт порядок сама». Для перевозчика убедительнее звучит спокойная логика: где сегодня теряются данные, кто отвечает за реакцию, какой отчёт нужен утром и какие решения можно принять быстрее. Поэтому в статьях и постах лучше показывать один рабочий день диспетчерского центра, а не набор функций.
Например, утро начинается с выпуска. Диспетчер видит план, затем первые отклонения, затем комментарии по причинам. Руководитель не вмешивается в каждую мелочь, но видит, что процесс не распадается. Вечером данные не исчезают в чатах, а остаются в истории. Через месяц можно смотреть не отдельные скандалы, а повторяемые причины: маршрут, машина, водитель, смена, район, время суток.
Именно такая подача делает материал полезным для SEO и продаж. Читатель узнаёт свою ситуацию, понимает ограничения и видит следующий шаг: запросить демо, показать свой текущий процесс, обсудить пилот на 1-2 месяца. Это лучше, чем обещать абстрактную цифровизацию автопарка.
Когда в статье появляются такие рабочие сцены, списки перестают быть основой текста и становятся вспомогательными. Руководитель АТП читает не каталог возможностей, а описание понятного перехода: от разрозненных таблиц к общей картине, от устных объяснений к истории событий, от реакции после смены к управлению в течение дня.
Для AAMX особенно важно объяснять цену через потери времени. Если диспетчер каждый день тратит полчаса на восстановление событий, а руководитель раз в неделю собирает отчёт вручную, это уже стоимость. Если часть отклонений повторяется, но не фиксируется системно, это тоже стоимость. Пилот нужен, чтобы перевести эти ощущения в цифры конкретного парка.
Поэтому готовый материал должен вести к демо, но не давить на покупку. Хороший следующий шаг - показать на встрече текущий процесс выпуска, список проблемных маршрутов и то, какие отчёты сейчас собираются вручную. После этого можно честно сказать, где AAMX даст пользу быстро, а где внедрение не окупится.
AAMX
