Деньги теряются не только на стройке. В таксопарках, где машины сдаются в аренду водителям, а оплата приходит тремя разными путями — наличными, по QR-коду и списанием через агрегатор, — встречается ровно та же картина: учёт есть, а ответа на простой вопрос «сколько должен этот человек» нет. Таксопарк на две сотни с лишним машин управлял долгом водителей по бумажным ведомостям и вечерней сверке в Excel, и каждый день терял на этом часы четырёх операторов. Знакомая история? Пожалуй, да, в особенности для таксопарков и других компаний с парком арендуемых активов, поэтому редакция er10.kz решила разобрать кейс из рубрики «Было-Стало».
Экспертом выступил Ержан Серикбаев, основатель REFACTOR.KZ, эксперт по операционной трансформации и финансовому контролю. За десять дней его команда запустила учётное ядро, которое автоматически считает долг каждого водителя по всем источникам оплат, а за два месяца довела систему до боевой эксплуатации с интеграциями с CRM, банком, агрегатором такси и мессенджером.
Таксопарк сдаёт в аренду около двухсот машин примерно сотне водителей, которые работают через агрегатор такси. Аренда начисляется каждый день, и оплата тоже приходит каждый день — но тремя разными путями: наличными оператору, по QR-коду через банк и списанием с баланса водителя в личном кабинете агрегатора. Договоры велись аккуратно — в CRM, с фотографиями машин, ставкой аренды и электронной подписью, — а вот деньги в CRM не сходились.
Услуга по наведению финансового порядка в таксопарках и арендном бизнесе предназначена для таксопарков, логистических и транспортных компаний среднего масштаба с парком от 50 до 500 единиц техники. Срок реализации: от 1,5 до 8 недель. Стоимость: от 1,5 до 8 млн тенге. Специальное предложение для читателей ER10 Media: бесплатный предварительный аудит.
Чтобы воспользоваться предложением, обращайтесь по ссылке.
В чём заключалась проблема?
Учёт при этом вёлся по машине, а не по водителю: одна машина — одна строка в ведомости. А на одной машине за месяц могло смениться до десяти водителей. Операторы каждый вечер переносили бумажные ведомости в Excel, долг считали вручную и записывали в примечания.
«Я не могу сравнить, сколько мы ему начислили и сколько он оплатил. Я не могу понять долг» — Владелец таксопарка
Это была не проблема дисциплины операторов, а проблема модели данных: если учёт ведётся по машине, а платит человек, долг восстановить невозможно в принципе. Компания уже пробовала решить это переходом на электронную ведомость в онлайн-таблице — и попытка провалилась на тестировании: ручной ввод остался ручным, просто переехал в другое окно. Порядка двухсот действующих договоров, сотни платежей в день из трёх источников — и по каждому нужно понять, чей он и за что. Четыре оператора занимались в основном не работой с водителями, а сверкой вчерашних цифр.
Владелец пришёл с запросом на отдельное приложение для финансового учёта, а не ещё одну доработку CRM. Идея команды была в другом: не «приложение с формами», а бухгалтерская книга по каждому договору, где долг равен сумме начислений минус сумма оплат, а всё остальное — интеграции, экраны, кабинет водителя — строится вокруг этой одной формулы. Рассматривали и доработку CRM, и готовую систему для таксопарков — первое не решает задачу со счётом, второе дорого и не совпадает с реальным процессом парка. Выбрали лёгкое учётное ядро с открытой моделью данных, куда интеграции подключаются по одной, не ломая то, что уже работает.
- Учётное ядро. договоры синхронизируются из CRM, аренда начисляется автоматически по ставке из договора с учётом простоя, каждая оплата разносится по категориям, а все операции проходят через два состояния — черновик и подтверждено.
- Источники оплат. банковские счета выставляются по начислениям и закрываются автоматически, кассовые смены сверяются с выпиской, списание у агрегатора разносится автоматически или вручную, а чеки водители присылают в мессенджер — система распознаёт сумму и ставит платёж в черновик.
- Роли и экраны. у оператора — карточка договора с долгом и историей, у контролёра — закрытие смены и своя ведомость, у владельца — панель с долгом парка и топом должников, у водителя — личный кабинет по телефону и коду.
Панель владельца: долг парка, активные договоры, топ должников и структура оплат за 30 дней. Макет с условными данными.
Карточка договора: начисления и оплаты по всем источникам, статус каждой операции и текущий долг. Макет с условными данными
Что оказалось сложнее всего?
Не формула долга, а границы дня. Начисление аренды идёт «за сегодня», списание у агрегатора приходит «за вчера», кассовая смена закрывается вечером, чек в мессенджер водитель может прислать ночью. Пока у системы не появилось единое понятие «рабочий день», сверка давала расхождения, которые не были ошибками ни одной из сторон. Вторая сложность — двойные оплаты: один и тот же платёж мог прийти и по QR, и как чек в мессенджере, и его нужно было распознавать, а не принимать дважды.
Исходный план на шесть спринтов пришлось пересобрать: после запуска ядра потребности парка пошли шире периметра — появилась роль контролёра с закрытием смены, учёт долга за повреждения машин, акт сверки в Excel под подпись водителя, ежедневные резервные копии с проверкой восстановления. Две ошибки поймало ревью ещё до боевого запуска: импорт списаний у агрегатора мог тихо остановиться на неполной странице, а токен кабинета водителя проходил проверку как операторская сессия. Обе нашли тесты и код-ревью, а не пользователи. Третья — организационная: документация проекта отстала от боевого кода на два месяца, и её пришлось досгонять задним числом.
Кто принимал решения и что изменилось в работе команды?
Ключевые решения распределялись между тремя участниками: владелец определял правила учёта — что считается простоем, как разносить депозит, кто имеет право подтверждать операции; эксперт отвечал за архитектуру и приоритеты; разработчик — за реализацию, и с какого-то момента лучше владельца знал, что парку нужно завтра, потому что ежедневно общался с операторами напрямую.
Ержан Серикбаев: «Критерий отбора идей был один — уменьшает ли это ручной ввод или ручную сверку».
Критерий отбора идей был один: уменьшает ли это ручной ввод или ручную сверку. Кабинет водителя прошёл этот критерий, потому что снимает с операторов звонки «сколько я должен»; часть вариантов дашбордов — нет. Был и спор о постконтроле: заказчик хотел, чтобы система подтверждала оплаты сама, команда настояла на двух состояниях — черновик и подтверждено, — потому что наличные и платежи из мессенджера нельзя принимать без человека. Компромисс: банковские и агрегаторские оплаты подтверждаются автоматически, остальные — нажатием оператора.
Особое значение имела работа с операторами парка: именно они каждый день показывали, где система расходится с реальностью — в какой момент закрывается смена, что делать с чеком за вчера, как учитывать замену машины посреди дня. В результате у оператора появилась карточка договора вместо бумажной ведомости, у владельца — панель с долгом парка в реальном времени, у водителя — собственный кабинет, а у процесса сверки — акт в Excel под подпись вместо устного спора.
Решение реализовали двое — эксперт и один разработчик — с опорой на ИИ-инструменты: первые спринты были написаны по методу «спецификация → тесты → код», каждая задача шла через отдельного агента и код-ревью. Это позволило запустить учётное ядро за десять дней вместо квартала. Ещё пять лет назад для такого набора инструментов — от учётного ядра до четырёх интеграций и кабинета водителя — потребовалась бы команда из четырёх-пяти человек и около полугода работы.
Сейчас система находится на боевом сопровождении уже несколько месяцев и обслуживает порядка двухсот договоров. Следующий этап обсуждается: перепробег по данным GPS с автоначислением, штрафы с автоматическим сопоставлением водителя и удалённой подписью, ежедневная выгрузка сумм в отчётность парка.
Фрагменты, кейс и цифры в этой статье обезличены и частично изменены по условию заказчика: название таксопарка условное, реальные договоры, суммы и скриншоты боевой системы не публикуются.
Что этот кейс может дать другим компаниям?
Опыт проекта показывает, что для порядка в деньгах не всегда нужна новая CRM или готовая отраслевая система. Во многих случаях достаточно навести порядок в том, что у компании уже есть. Из этого кейса можно выделить три принципа:
- Проверить, по какому объекту ведётся учёт денег. Если долг числится за машиной, столом или точкой, а платит человек, учёт сломан, и никакая автоматизация его не починит.
- Строить от одной формулы, а не от списка функций. Сначала одна книга начислений и оплат по каждому договору, затем интеграции подключаются по одной, каждая за заглушкой — это даёт рабочий результат за дни, а не за квартал.
- Оставить человеку подтверждение, а не отменять его целиком. Это дешевле, чем объяснять клиенту, почему система «сама» списала лишнее — наличные и платежи из неформальных каналов нельзя принимать без человека.
Если оставить один урок из этого кейса: проблема «я не могу понять долг» почти никогда не решается новой программой. Она решается сменой объекта учёта — с актива на договор — и одной книгой, куда автоматически попадают все начисления и все оплаты. Ядро такой книги маленькая команда с ИИ-инструментами способна запустить за десять дней. Всё остальное — интеграции, роли, кабинеты — наращивается вокруг неё по одной, по мере того как бизнес начинает видеть свои деньги.
