Ольга Височинська
Head of Product
Ваш сайт працює на Magento, замовлення з маркетплейсів приходять з Rozetka і Prom, залишки лежать в 1С, і десь посередині людина перевіряє, яка цифра справжня, перш ніж підтвердити замовлення.
Рітейлер з великим каталогом продає в усіх каналах одночасно: сайт, маркетплейси, магазини, кол-центр, B2B. Система управління замовленнями стоїть у центрі виконання, але маршрутизує тільки на тих товарних даних, які отримала. Понад 50 000 SKU ці дані ніколи не бувають рівномірно якісними, і розрив закривається людьми.
Цей матеріал пояснює, що робить система управління замовленнями, чим вона відрізняється від ERP і складської системи, чому вона ламається саме на великому каталозі, і що з цього реально доступно на українському ринку.
Система управління замовленнями приймає замовлення з усіх каналів продажу, перевіряє наявність по складах, вирішує, звідки відвантажити кожне, і веде його до доставки й повернення. Англомовна абревіатура - OMS, order management system.
Категорія широка: від інструментів, які просто синхронізують замовлення й друкують накладні, до систем оркестрації, що маршрутизують між десятками складів у реальному часі. Не всі витримують великий каталог, і різниця стає видимою не на кількості замовлень, а на кількості товарів.
Більшість рітейлерів уже мають дві з трьох систем, перш ніж хтось пропонує третю. Перетин реальний, і вендори з усіх боків кажуть, що закривають замовлення. Різниця не в тому, що система зберігає, а в тому, яке рішення їй дозволено ухвалити.
Що WMS робить із замовленнямСкладська система перетворює замовлення на фізичну роботу в межах одного приміщення - приймання, розміщення, збірка, пакування, відвантаження. Вона працює з тим, що їй передали, і не бачить ані каналів, з яких прийшло замовлення, ані інших складів, які могли б його відвантажити. Питання «з якого складу відвантажувати» вирішено до того, як замовлення до неї дійшло.
Що ERP робить із замовленнямERP записує замовлення як фінансову й облікову операцію: що продано, за якою ціною, проти якого залишку. Це майстер-запис, за яким усі звітують.
Цей запис точний і повільний. ERP побудована на консистентності, тому залишок відображає підтверджений стан, а не поточний. В одному каналі ця затримка непомітна. У п'яти - це різниця між «є на складі» і «можна продати», і саме там починається оверселл. Та сама межа є між ERP і PIM: ERP зберігає товарні записи, але керувати товарним контентом не призначена, ми розбирали це в ERP vs PIM.
Що робить OMS, чого не роблять ані ERP, ані WMSМіж моментом оформлення і моментом, коли складська система побачила замовлення, хтось має вирішити, звідки воно поїде. Найближчий склад чи найдешевший? Розбити на два чи чекати, поки на одному буде все? Віддати останню одиницю з магазину чи зберегти її для покупця в залі?
Це рішення не ухвалює ані ERP, ані WMS. ERP знає підсумки, WMS знає одне приміщення, а логіка маршрутизації живе між ними. У більшості рітейлерів це місце займає людина з таблицею і набором правил, яких ніхто не записав.
Кількість замовлень - це те, що вимірюють усі, і воно рідко ламається першим. Рітейлер з 500 SKU і 50 000 замовлень на день має проблему пропускної здатності, а вона давно вирішена. Рітейлер з 50 000 SKU і 5 000 замовлень на день має проблему точності, і точність залежить від каталогу.
Як розмір каталогу впливає на точність замовленьКожне рішення про маршрутизацію читає атрибути товару, тому кожна прогалина в каталозі стає не пропущеним рішенням, а неправильним. Вага й габарити визначають перевізника й вартість, категорія, на якому складі лежить SKU, ознака небезпечного вантажу, що можна везти разом.
Коли ці поля порожні, система не зупиняється, вона підставляє значення за замовчуванням і відвантажує. На 500 SKU це хтось помітить. На 50 000 помилка спливе за тижні як перевитрата на доставку або скарга клієнта. Маршрутизатор не помилився. Помилився запис, який він прочитав.
Що стається, коли залишки й товарні дані живуть окремоSKU буває в наявності й непродаваним одночасно. Замовленню потрібні обидва записи в один момент, а вони оновлюються за різними годинниками: залишок рухається за секунди, товарні дані, коли їх хтось відредагував.
Більшість стеків закриває це інтеграцією за розкладом. Працює, поки каталог не змінюється швидше за інтервал синхронізації, тобто під час онбордингу постачальника, сезонних запусків і будь-якого прайсу в новому форматі. Для SKU, які приходять узагалі без придатних даних від постачальника, це вже не проблема синхронізації, а проблема джерела, ми розбирали її в матеріалі про збагачення даних для SKU без інформації від постачальника.
Скільки правил маршрутизації додає кожен новий каналСклади помножити на канали, а не канали плюс один. Три канали на чотири локації - це дванадцять маршрутів, у кожного своя логіка резерву, свої дедлайни й свої винятки. Додали п'яту локацію, додали три маршрути, не один.
Саме тут команди перестають писати правила й починають писати винятки до правил. І саме тут управління замовленнями перестає бути процесом і стає питанням архітектури.
Огляди систем управління замовленнями зазвичай порівнюють IBM Sterling, Manhattan Active Omni, Kibo та SAP - платформи, побудовані для розподілених мереж і американського рітейлу. Вони працюють. Але український рітейлер з ними стикається рідко: впровадження - це enterprise-програма з партнером, ліцензія рахується за рядок замовлення, а локальних перевізників і маркетплейсів у коробці немає.
Реальний шортліст виглядає інакше.
Найпоширеніший варіант. Знайомо бухгалтерії, працює з обліком. Але це облікова система: маршрутизації в ній немає, вона добудовується під кожен склад окремо і в підтримці дорожчає з кожним роком.
Повна гнучкість, 6–18 місяців, залежність від команди, яка це написала. Логіка маршрутизації існує рівно в тому вигляді, у якому її встигли зробити.
Замовлення обробляються, але каталожна логіка обмежена, а маршрутизація базова. Витримує один-два канали.
HootCore працює тут: маршрутизація за відстанню, залишком і пріоритетом, розподіл кошика між складами до підтвердження замовлення, збірка через мобільний застосунок зі скануванням, інтеграції з Новою Поштою, Укрпоштою, Meest, Rozetka, Prom, Magento. Розгортання можливе on-premises, модулі підключаються окремо.
Що варто знати: маршрутизація в HootCore вирішує, звідки відвантажити, за відстанню, залишком і пріоритетом, але не рахує, скільки це коштуватиме. Розрахунок вартості доставки за відстанню зараз у розробці. Повернення в модулі замовлень не закриті, рітейлеру з великим потоком RMA потрібен окремий процес.
Відстань і пріоритет - це не те саме, що вартість, швидкість і залишок, пораховані разом. Спитайте, які змінні входять у рішення, а які налаштовуються один раз і більше не перераховуються.
За рядок замовлення, за користувача, за касу чи за транзакцію. Рітейлер зі 100 магазинами і помірним потоком замовлень платить протилежне до рітейлера з трьома складами і великим потоком.
Майже кожна OMS - це надбудова над тим, що вендор продавав раніше: над ERP, касою, складською системою чи бухгалтерією. Це визначає, що вона робить добре, а що вважає вже вирішеним кимось іншим.
Маршрутизація читає атрибути. Якщо каталог наповнюється вручну з прайсів постачальників без валідації, жодна система замовлень цього не виправить.
ERP записує замовлення як фінансову операцію й тримає майстер-запис. OMS вирішує, звідки замовлення відвантажити. ERP не маршрутизує, а її залишок відображає підтверджений стан, а не поточний, саме тому на кількох каналах починається оверселл.
Якщо продаєте в одному каналі з одного складу - ні. Щойн замовлення приходять з кількох каналів і можуть поїхати з кількох складів, рішення про маршрутизацію існує незалежно від того, чи є система, яка його ухвалює.
Вісім із дев'яти західних платформ ціни не публікують узагалі. IBM - виняток: від 2,8 центів за рядок замовлення на вході. Українські рішення рахуються за проєктом. Важливіша за цифру одиниця тарифікації: за рядок, за користувача чи за касу.
Питання не в тому, яка система управління замовленнями краща, а в тому, навколо чого вона побудована і що вона вважає вже вирішеним. Для рітейлера з каталогом від 50 000 SKU вирішеним зазвичай вважають каталог, і саме там ламається все інше.
Якщо ваші помилки в замовленнях ведуть до товарних даних, а не до логіки маршрутизації, почніть з каталогу. Забронювати демо
Поспілкуйтеся з нашою командою та подивіться, як HootCore інтегрується у ваш існуючий tech stack — від управління товарними даними до обробки замовлень