Это обзорная статья, а не кейс KT.Team. Ниже — открытый разбор того, что публично сделано на MuleSoft (Mule ESB / Anypoint Platform) в ритейле и e-commerce: как интернет-магазин, кассы, склад, CRM и логистику связывают слоем API и какой бизнес-результат это даёт. Все цифры — из публичных источников, ссылки в конце.
Бизнес-проблема: канал есть, единого остатка нет
Типичная розничная компания накапливает системы по одной: сайт на e-commerce-платформе, кассы (POS) в магазинах, склад (WMS), ERP с товарными остатками, CRM с клиентом, отдельный сервис доставки. Каждая знает «свою» правду об остатке и о заказе. Итог — overselling (продали то, чего нет), отказы по онлайн-заказам, невозможность собрать заказ из ближайшего магазина и отсутствие единой карточки клиента.
Результат, который нужен бизнесу, формулируется в трёх метриках: точность остатка по всем каналам, время от оформления заказа до начала сборки и скорость вывода новой функции в новый магазин/рынок. MuleSoft адресует именно их через подход API-led connectivity.
Как устроен слой API (System / Process / Experience)
MuleSoft не предлагает переписывать ERP или e-commerce-ядро. Бизнес-логика выносится в API *рядом* с системами, тремя слоями (79Consulting):
- System APIs — тонкие адаптеры поверх источников: e-commerce, ERP, CRM, POS, WMS, PIM/MDM, 3PL. Они инкапсулируют доступ к данным и не содержат бизнес-логики.
- Process APIs — оркестрация: «единый остаток», «маршрутизация заказа», «выбор точки отгрузки». Здесь и живёт omnichannel-логика.
- Experience APIs — витрины под конкретный канал: веб, мобильное приложение, касса, личный кабинет.
Ключевая идея в отчуждаемости: System API переиспользуются между процессами. У Lotus's это дало 70% переиспользования API, что напрямую сократило сроки и стоимость разработки (MuleSoft / Lotus's).
Единый остаток товара (single inventory view)
Эталонную реализацию MuleSoft опубликовал в составе Accelerator for Retail (Use case 4 — Real-time inventory management). Там связаны Salesforce B2C Commerce, SAP S/4HANA, Salesforce Service/Sales Cloud и PIM/MDM (Anypoint Exchange).
Логика «единого остатка» опубликована буквально по шагам:
1. Покупатель выбирает товар и вводит индекс на витрине.
2. Inventory Process API обращается к MDM и находит товар по universal product ID (сводит разные артикулы каналов к одному).
3. Process API вызывает SAP S/4HANA Product Availability System API за реальным остатком.
4. Один и тот же результат отдаётся и в B2C-витрину, и в интерфейс Salesforce — с наличием по конкретным магазинам.
Готовые компоненты Accelerator: System API для B2C Commerce, для наличия, товаров и заказов в S/4HANA; Process API для инвентаря; Experience API для B2C и для Salesforce.
Что это даёт в реальном ритейле: Lotus's на этой архитектуре вышел на 98% точности остатка по более чем 2000 магазинам и 250 000 активных SKU на магазин плюс склады. GANT через inventory API показывает наличие в конкретном магазине в момент клика покупателя, сопоставляя данные магазина и остаток ритейл-системы; за счёт переиспользования эту функцию выкатили на пять рынков втрое быстрее, чем при point-to-point (GANT).
Сквозной заказ (omnichannel order)
Второй процесс — единый заказ. Заказ из любого канала (веб, мобильное приложение, магазин) попадает в один OMS/ERP, а Process API решает, откуда отгружать: со склада, из ближайшего магазина (ship-from-store) или выдать самовывозом (BOPIS). В Accelerator оркестрация создания заказа идёт в SAP S/4HANA, с обнулением доставки для самовывоза.
Бизнес-эффект показывает SMCP (Sandro, Maje, Claudie Pierlot): на API-led connectivity компания собрала единую карточку клиента по онлайн- и офлайн-поведению и поставила цель сократить время от заказа до начала сборки с 2,5 часов до минут, чтобы доставлять заказ покупателю за 2 часа (SMCP). Это и есть «сквозной заказ»: канал продажи отвязан от точки исполнения.
Подход без модификации ядра
Важная для долгосрочной эксплуатации деталь: и e-commerce, и SAP, и CRM остаются стоковыми — логика omnichannel живёт в слое API рядом, на международных стандартах (REST, OAuth, единый product ID через MDM). Это loosely coupled и отчуждаемо: новый канал или новый рынок добавляется переиспользованием существующих System API, а не новой point-to-point-интеграцией. Отсюда и метрики скорости у GANT и Lotus's.
Схема
Трёхслойная схема: снизу System APIs поверх e-commerce, ERP (SAP S/4HANA), CRM, POS, WMS, PIM/MDM и 3PL; в центре два Process API — «Единый остаток» (агрегирует наличие по universal product ID) и «Сквозной заказ» (маршрутизирует заказ в OMS и выбирает точку отгрузки: склад / магазин / самовывоз); сверху Experience APIs под веб, приложение, кассу и CRM. Все каналы спрашивают один остаток и пишут в один заказ; System API переиспользуются между процессами.
Вывод по бизнес-процессу
Слой API на MuleSoft превращает разрозненные системы в один процесс «увидел остаток → оформил в любом канале → собрали из оптимальной точки». Оценивать его стоит по трём цифрам из публичных примеров: точность остатка (98% у Lotus's), время заказ→сборка (2,5 ч → минуты у SMCP) и доля переиспользуемых API (70%, кратно ускоряет новые рынки). Если эти показатели не двигаются — интеграция сделана ради интеграции.
