Почему ваш интернет-магазин продаёт больше, чем есть на складе: синхронизация складских остатков ERP, сделанная правильно

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

Перепродажа сверх остатка - это вопрос консистентности

Синхронизация остатков располагается на спектре между двумя видами издержек:

• Синхронизироваться слишком редко - и вы продаёте то, чего у вас нет.
• Резервировать в реальном времени - и вы платите за это: нагрузкой на API ERP, задержкой на этапе оформления заказа и инженерной сложностью.

Ошибка - выбрать одну точку на этом спектре для всего каталога. У ритейлера с 40 000 SKU может быть всего 200 позиций, которые вообще когда-либо приближаются к перепродаже сверх остатка, - ходовые товары, промо-позиции, распродажа последних единиц. Именно они заслуживают резервирования в реальном времени при оформлении заказа. Остальные 39 800 отлично обслуживаются пакетной подачей раз в 15 минут.

Трёхуровневая модель, которую мы внедряем

1. Пакетный уровень - базовый вариант. Остатки передаются ERP → интернет-магазин по расписанию. Дёшево, надёжно, подходит для всего, что имеет достаточный запас на складе.
2. Пороговый уровень - когда доступное количество опускается ниже настраиваемого порога, SKU автоматически переводится на обновления по событиям.
3. Уровень резервирования - оформление заказа создаёт жёсткую резервацию в ERP до подтверждения заказа. Применяется к небольшому числу товарных позиций, для которых перепродажа сверх остатка обходится дороже, чем вызовы API.

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

Проектируйте интеграцию исходя из цены ошибки - и архитектура сложится сама.