Как заменить ERP в компании из сферы такси без остановки бизнес-процессов

Команда Хоулмонт делится историей проекта по миграции устаревшей ERP — критически важной для бизнеса системы, которая должна работать 24/7. Система включала более 600 экранов и большой объем функциональности, что делало задачу особенно сложной. При этом команде нужно было не только воспроизвести расчеты старой системы, но и оптимизировать распределение заказов.

Задача

Заказчик — крупная такси-компания из Великобритании, которая специализируется на корпоративных перевозках. Задача заключалась в том, чтобы заменить устаревшую ERP-систему. Речь шла о разработке уникального решения на заказ.

У проекта было множество условий и ограничений:

• У старой и новой систем сильно отличались схемы базы данных и архитектура
• Не было доступа к исходному коду старой системы
• Практически не было документации
• Расчеты старой системы нужно было повторить в новой точь-в-точь
• Старая система работала с высокой интенсивностью, на новую тоже должна была лечь существенная нагрузка

Самое сложное — старую ERP-систему нельзя было останавливать при замене. Она должна была функционировать в режиме 24/7, чтобы бизнес не останавливался.

Решение

Вызов 1. Как обеспечить работу системы в режиме 24/7

Любая ошибка или отключение на время миграции парализовали бы обработку тысяч заказов и назначение машин на вызовы. Классическая методология «большого взрыва» — когда старую систему отключают, а процессы одномоментно переводят в новую систему — была слишком рискованной. При сбое пришлось бы проводить обратную миграцию, что означало недели простоя.

Поэтапная миграция

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

Методология Parallel Running

Для исключения рисков остановки бизнеса при миграции мы использовали методологию Parallel Running. Суть методологии в том, что во время опытной эксплуатации старая и новая системы работают параллельно. Для этого требовалось реализовать возможность работы двух систем на едином наборе данных в режиме реального времени. При любых сбоях базы данных должны были гарантированно возвращаться в консистентное состояние. Готового решения, тем более для разных баз данных, на рынке не было, поэтому мы разработали свой инструментарий. Со временем он вырос в отдельный продукт xDbStream. В отдельной статье можно узнать подробнее о методологии Parallel Running и проектах, когда она подходит больше всего.

Вызов 2. Как перенести большой объем функциональности

Старая ERP-система отличалась большим объемом функциональности и содержала более 600 разделов. Разработка могла занять очень много времени. Однако, несмотря на общее количество, многие функции были типовые.

Фреймворк для ускорения разработки

Чтобы снизить трудозатраты на выполнение шаблонных задач, мы решили разработать Java-фреймворк для повышения продуктивности. Это помогло реализовать функциональность в срок и обеспечить пользователям консистентный опыт. Также фреймворк позволил снизить порог входа и привлекать к проекту начинающих разработчиков. На базе этих разработок позднее была построена платформа Jmix.

Вызов 3. Как извлечь пользу из новых качественных данных

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

Система интеллектуального планирования Auto Allocator

В основе модуля Auto Allocator — различные алгоритмы оптимизации, а также эвристики и метаэвристики. Они позволяют находить хороший (хотя и не обязательно оптимальный) вариант без полного перебора всех возможных решений. В результате заказчик получает сочетание качества и скорости.

Наиболее интересные технологии Auto Allocator — Early Promising и Driver Swarm Management.

Early Promising

Технология Early Promising позволяет распределять машины с учетом еще не подтвержденных заказов. Пока клиент еще только вводит детали заказа, система уже подбирает ему водителя и показывает время прибытия. В результате повышается точность и удовлетворенность клиентов.

Driver Swarm Management

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

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

Мы разработали механизм Drive Swarm Management, который позволяет операторам создавать так называемые Hot Spot. Иначе говоря, можно указать, сколько автомобилей, в какой точке и к какому времени нужно собрать. Также ERP умеет определять такие точки автоматически, на основе исторических данных и анализа предзаказов. После определения Hot Spot система назначает машины бизнес-класса на обычные заказы, если требуется ехать в нужную сторону и к нужному времени. Клиент получает повышение уровня сервиса, а машина оказывается там, где нужно.

Вызов 4. Как принести результат бизнесу, а не просто выполнить ТЗ

Работа над проектом была организована таким образом, чтобы команда не просто следовала ТЗ, а понимала, как ее решения повлияют на бизнес заказчика.

Погружение разработчиков в бизнес-процессы

Что мы сделали, чтобы сломать барьер между бизнесом и разработкой:

• Погружение в особенности бизнес-процессов. Разработчики наблюдали за работой диспетчеров и изучали их боли.
• Прямое общение. Разработчики общались с пользователями вместе с аналитиками, чтобы понять суть задачи.
• Участие во внедрении. Разработчики участвовали во внедрении, проводили обучение и получали обратную связь от пользователей.

В итоге разработчики превратились в экспертов в логистике такси и смогли предлагать заказчику новые, более эффективные решения. С таким уровнем погружения джуниоры вырастали в сеньоров за 2 года вместо 5 лет.

Результаты

Миграция ERP-системы прошла без стресса для заказчика, у команды всегда был план Б. Больше всего времени потребовалось на замену модулей расчета стоимости поездки и зарплаты водителей, так как требовалось полностью повторить логику расчета из старой системы. В течение двух лет использовались две системы параллельно. В случае выявления расхождений мы проводили анализ и вносили изменения, пока расчеты не стали совпадать на 100%. За все время миграции ERP бизнес не простаивал ни разу.

Диспетчеризация вышла на новый уровень благодаря модулю Auto Allocator. Среди достигнутых результатов:

• Выполнение SLA с учетом разных уровней клиентов и типов заказов (срочный и ко времени)
• Снижение пустого пробега машин
• Справедливость распределения заказов среди водителей

Из всех заказов 99,5% распределяется автоматически, операторы подключаются только в самых сложных случаях. Эффективность автопарка повысилась на 5%. Такого результата можно было бы достичь, если бы у компании появилось 100–200 «бесплатных» водителей. В денежном эквиваленте экономия составила миллионы фунтов в год.