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

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

Цифры, из которых складывается решение. Рынок e-commerce в России в 2025 году — около 13,4 трлн ₽ при 8,3 млрд заказов. Доля маркетплейсов — 81% от числа заказов и порядка 62% от объёма продаж; Wildberries, Ozon и Яндекс Маркет вместе дают больше 85% онлайн-продаж.

В первом полугодии 2026 года интернет-торговля выросла примерно на 19%, до 7,2 трлн ₽, а доля e-commerce в розничных продажах поднялась до 22,2% против 20,9% годом ранее.

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

Первое, что делает OMS, — приводит заказы из разных источников к одной структуре. Она сложнее, чем кажется из интерфейса корзины.

Заказ — то, что оформил клиент: позиции, оплата, адрес, обещанный срок. Он живёт целиком и виден клиенту.

Отправление — часть заказа, которая едет из одного места. Три позиции с разных складов превращаются в три отправления с разными сроками. Клиенту при этом лучше показывать один заказ с несколькими доставками, а не три заказа.

Резерв — обещание товара под конкретный заказ. Резерв имеет срок жизни: неоплаченный заказ не должен блокировать товар на неделю.

Статусы — двухуровневые: технический для систем и человеческий для клиента. «Ожидает подтверждения склада» и «Собираем заказ» — одно и то же событие на разных языках.

История и события. Каждое изменение фиксируется: кто отменил, когда изменился адрес, почему сдвинулся срок. Без журнала разбор спорной ситуации превращается в переписку между отделами.

Ключевая механика и главный источник отмен. Остаток в учётной системе и остаток, который можно продать, — разные числа.

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

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

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

Когда заказ собран, система решает, откуда его отгружать. Правило — не одно, а набор с приоритетами.

Именно они превращают набор систем в единый сервис, и каждый из них — отдельная логика в OMS.

Самовывоз. Клиент заказывает онлайн, забирает в магазине. Нужны резерв в конкретной точке, срок хранения, уведомление о готовности и понятный процесс выдачи для продавца.

Доставка из магазина. Магазин становится микроскладом: там собирают и передают курьеру. Нужен интерфейс для сотрудника торгового зала — простой, потому что он работает между покупателями.

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

Заказ из зала. Нужного размера нет — продавец оформляет доставку клиенту прямо у прилавка. Требует доступа к остатку сети и мобильного интерфейса.

Обмен и доплата. Сценарии, которые обычно забывают, а они бьют по клиентскому опыту сильнее прочих.

Клиентскую часть таких сценариев мы обычно делаем как веб-кабинет и витрину, а операционную — как рабочие места для сотрудников: у продавца и у сборщика разные задачи и разные экраны.

Дата доставки — то, что клиент запоминает и по чему судит о сервисе. Считается она из нескольких величин: доступности товара, времени сборки в конкретной точке, расписания отгрузок, времени перевозки, режима работы пункта выдачи.

Слабое место — время сборки. Оно разное для склада и магазина, для одной позиции и для десяти, для утреннего заказа и для вечернего. Если система берёт среднее значение, обещание регулярно не выполняется на пиках.

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

Сценарии, которые ломают учёт чаще всего, потому что их проектируют последними.

Отмена до сборки — простой случай: снять резерв, вернуть деньги, зафиксировать причину.

Отмена после сборки или отгрузки — возврат в точку, распаковка, приведение товара в продажу, обратная логистика. Здесь появляются деньги: возврат оплаты, чек возврата, компенсация доставки.

Частичная отгрузка — часть позиций уехала, часть отменена. Клиенту нужен корректный документ и понятная сумма, бухгалтерии — правильный набор чеков.

Возврат части заказа — пересчёт скидок, которые давались на весь заказ, и правил бесплатной доставки от суммы. Самое частое место арифметических споров с клиентом.

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

Для большинства ритейлеров площадки — уже основной объём, и с точки зрения OMS это ещё один канал со своими правилами.

Работа идёт по двум базовым схемам: товар лежит на складе площадки и отгружается ею, либо хранится у вас и отгружается по её заказу. Вторая схема как раз и требует OMS: заказы приходят потоком, сроки жёсткие, за просрочку — санкции и снижение видимости в поиске.

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

Если вы сами строите площадку, а не только продаёте на чужих, устройство такого продукта разобрано отдельно — в материале про создание маркетплейса.

• Сайт и приложение — оформление заказа, статусы, история в кабинете клиента.
• Учётная система — товары, цены, документы, деньги; практическая механика обмена описана в материале про интеграцию с 1С.
• Склад — задания на сборку и отгрузку, подтверждение факта.
• Кассы и торговые точки — остатки, продажи, выдача самовывоза, возвраты.
• Службы доставки — заказ перевозки, трек-номера, статусы, стоимость.
• Маркетплейсы — заказы, остатки, статусы, документы.
• Платежи и фискализация — оплаты, возвраты, чеки.

Ключевое требование ко всем обменам одно: заказ не должен теряться и не должен дублироваться. Отсюда очередь, повторы, ключ операции и журнал с возможностью переотправки — иначе первая же недоступность площадки превращается в потерянные заказы.

Объём работ определяют число каналов, количество точек отгрузки и сложность правил. Контур для одного склада и одного сайта — это не то же самое, что сеть из пятидесяти магазинов и трёх площадок.

По нашим работам: заказная система управления заказами под процесс — от 1,7 млн ₽, складские модули и рабочие места сборщика — от 1,5 млн ₽, отдельная интеграция (площадка, служба доставки, учётная система, касса) — от 150 тыс. до 1,5 млн ₽, аудит существующего контура — от 200 до 600 тыс. ₽. Точная цифра считается по каналам и правилам: оценка проекта бесплатная.

Прикинуть порядок бюджета можно заранее — бесплатный калькулятор оценки собирает вилку по составу работ за несколько минут.

Остаток считают по учётной системе. Резервы, сборка, витрина и товар в пути не вычитаются — отмены по причине «нет товара» растут, и клиент уходит к тому, кто не отменяет.

Правила распределения зашили в код. Каждое изменение приоритета склада становится релизом, а операционная реальность меняется еженедельно.

Магазины подключили без интерфейса для продавца. Сотрудник в зале получает систему, рассчитанную на оператора склада, и заказы собираются в конце смены.

Причины отмен не заполняются. Метрика есть, разложить её нельзя, улучшать нечего.

Обмен с площадками сделан без повторов. Личный кабинет недоступен пять минут — часть заказов не доехала, узнали из претензии.

Первое — посчитать долю отмен и разложить её по причинам хотя бы вручную за месяц. Обычно две трети приходится на отсутствие товара, и это сразу указывает на остаток, а не на логистику.

Второе — выписать каналы и точки отгрузки: откуда приходят заказы, откуда можно отгружать, какие сценарии выдачи уже обещаны клиентам. Этот список определяет сложность проекта.

Третье — сформулировать правила распределения словами, до всякой автоматизации: что важнее — скорость, стоимость доставки или разгрузка магазинов. Если правило не формулируется на словах, система его тоже не сформулирует.