Ваш заказ собран: зачем бизнесу отдельная OMS-система

Для покупателя заказ — это единое действие, а для компании — целая цепочка с участием интернет-магазина, склада, оплаты, доставки, контакт-центра и учетных систем. Пока каналов и вариантов исполнения немного, управлять этой цепочкой можно средствами ERP, e-commerce-платформы и WMS. Но по мере роста бизнеса процесс усложняется. Заказ можно оформить на сайте, изменить через контакт-центр, получить в торговой точке или разделить на несколько доставок. У каждой системы появляется собственное представление о том, что происходит с заказом.

В результате сотрудники сверяют данные вручную, покупатель получает противоречивые статусы, а запуск нового способа доставки требует изменений сразу в нескольких системах. Эту задачу решает OMS (Order Management System) или система управления заказами.

Разберемся, за что отвечает OMS, в каких ситуациях она приносит бизнесу наибольший эффект и когда стоит создавать собственную платформу.

Представим, что покупатель оформил заказ. После этого компании нужно:

• проверить возможность исполнения заказа;
• подтвердить заказ;
• получить оплату;
• передать задания на склад и в службу доставки;
• сообщить покупателю сроки;
• обработать возможные изменения;
• проконтролировать заказ до получения;
• при необходимости оформить отмену или возврат.

Каждую операцию может выполнять отдельная система. Например, складскими процессами управляет WMS, перевозкой — логистическая система, а доступностью товаров и резервами — система управления запасами. Задача OMS — связать эти операции в единый процесс и сохранить целостную картину заказа.

ERP отвечает за ресурсы компании, учет, финансы и документы. WMS управляет складскими операциями: размещением, отбором, комплектацией и отгрузкой. Пока процесс исполнения заказа остается простым и линейным, отдельная OMS может быть не нужна. Например, если заказ всегда оформляют в одном канале, собирают на одном складе и доставляют одним способом.

Сложности начинаются, когда появляются новые каналы продаж, склады, способы получения и варианты изменения заказа. Заказ перестает принадлежать одной системе. Его отдельные части оказываются распределены между интернет-магазином, ERP, складом, службой доставки и контакт-центром. Каждая система видит свой участок, но ни одна не управляет процессом целиком.

Из-за этого возникают проблемы:

1. покупатель и сотрудники видят разные статусы;
2. для выяснения состояния заказа приходится обращаться к нескольким системам;
3. нестандартные ситуации обрабатываются вручную;
4. изменения передаются между участниками с задержкой;
5. новый бизнес-сценарий требует доработок в нескольких системах;
6. сложно понять, на каком этапе и почему остановился заказ.

OMS создает единый контур управления заказом: она не заменяет остальные системы, а координирует их работу.

Дополнительная система не всегда упрощает ИТ-ландшафт. Иногда она создаёт новый слой интеграций и увеличивает стоимость поддержки. 

Внедрение OMS может быть избыточным, если:

• у компании один основной канал продаж;
• заказ проходит по простому и стабильному маршруту;
• нестандартные ситуации возникают редко;
• существующая ERP справляется с объёмом и изменениями;
• бизнес не планирует развивать новые способы продажи и получения заказов;
• затраты на внедрение выше ожидаемого операционного эффекта.

В такой ситуации стоит уделить внимание текущим процессам: оптимизировать ERP, автоматизировать отдельные операции или улучшить взаимодействие между системами.

Когда потребность в отдельной OMS подтверждена, возникает следующий вопрос: выбрать готовый продукт или создать собственную систему. На практике вариантов больше. Компания может использовать облачный сервис, коробочное решение, технологическую платформу, собственную разработку или сочетание готовых и заказных компонентов.

Когда подходит готовая OMS

Готовый продукт уже содержит распространенные сценарии работы с заказами, инструменты настройки и типовые интеграционные возможности.

Он подходит, если процессы компании близки к стандартным:

1. жизненный цикл заказа не отличается от распространенных моделей;
2. бизнес готов адаптировать часть процессов под продукт;
3. важно сократить объем собственной разработки;
4. решение поддерживает необходимые интеграции и нагрузку.

Когда стоит выбирать заказную разработку

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

Например:

• используются уникальные сценарии исполнения;
• процессы часто меняются;
• готовые продукты требуют слишком глубокой адаптации;
• есть особые требования к нагрузке и доступности;
• компания хочет самостоятельно управлять развитием платформы;
• способы доставки и получения заказа являются конкурентным преимуществом.

Заказная разработка дает больше свободы, но требует больше ответственности. Компании придется самостоятельно развивать систему, поддерживать ее стабильность и сохранять экспертизу внутри команды. Поэтому сравнивать нужно не только стоимость запуска. Важно оценить совокупную стоимость владения на несколько лет, скорость будущих изменений и зависимость от поставщика или собственной команды.

«Петрович» специализируется на продаже товаров для строительства, ремонта и обустройства дома, а также на комплектации крупных объектов. Сегодня в инфраструктуру компании входят 22 строительно-торговых центра, производственные площадки и распределительные центры. Ежемесячно «Петрович» обрабатывает около 500 тыс. заказов, при этом более половины розничных продаж приходится на онлайн.

Система товародвижения компании развивалась вместе с бизнесом и сегодня является одной из наиболее зрелых и технологически продвинутых на рынке. Чтобы сохранить этот уровень в условиях дальнейшего роста, компания приняла решение выделить управление заказами и запасами в отдельную OMS/IMS-платформу.

Перед запуском проекта рассматривались разные варианты реализации — от готовых решений до собственной разработки. В итоге компания выбрала кастомную платформу, которая сможет учитывать специфику её процессов и масштабироваться вместе с бизнесом. В основе решения — платформа Temporal для построения устойчивых бизнес-процессов и микросервисная архитектура.

Проект реализуется в высоконагруженной среде: целевая архитектура системы обеспечивает обработку большого потока заказов в режиме реального времени с учетом различных сценариев — от стандартной доставки до сложных цепочек с участием нескольких складов и торговых точек. Система поддерживает актуальность данных во всех контурах, синхронно обновляя статусы заказов, резервы и информацию о наличии товаров. В периоды пиковых нагрузок она масштабируется и обеспечивает непрерывность обработки заказов, позволяя компании развивать онлайн-продажи без потери качества сервиса.

Одной из ключевых задач проекта стало поэтапное выделение логики управления заказами из существующей системы товародвижения без остановки бизнес-процессов. Запуск MVP запланирован через восемь месяцев: первая версия платформы позволит проверить ключевые бизнес-сценарии и оценить эффективность новой архитектуры.