Управління асортиментом ШІ: де ламається ручна логіка
Товарну матрицю переглядають раз на квартал — у таблиці, за підсумками закритого періоду. Поки позиції узгоджують між закупівлею, комерцією та складом, попит устигає змінитися: те, що було в топі, переходить у хвіст, а введені новинки приїздять під уже відпрацьований сезон.
Ручне управління асортиментом тримається на середньому за категорією. П'ять-десять тисяч артикулів, у кожного свій профіль попиту і своя реакція на акції та знижки, а рішення ухвалюють за загальним звітом за минулий місяць.
Звідси два перекоси одразу: введення позиції без перевірки, чи є під неї стійкий попит, і виведення за залишком на складі, а не за динамікою продажів.
Ціна такого збою накопичується повільно. Неліквіди на складі займають місце й обіговий капітал, а поруч зростає дефіцит за позиціями, які якраз продаються.
Невідповідність попиту та пропозиції проявляється через два-три цикли закупівлі — і її зручно списати на сезонність або на постачальника.
Класичний ABC/XYZ-розбір за підсумками місяця проблему не знімає: він теж дивиться назад і усереднює сплески. Локальне зростання в розрізі каналу, регіону та розміру в ньому не видно, тому рішення все одно ухвалює людина — за досвідом і за останнім вивантаженням.
Управління асортиментом ШІ змінює точку відліку: модель рахує попит за кожною позицією окремо та в розрізі каналів, а рішення про введення й виведення будується на прогнозі, а не на минулому періоді. Розбираємо, з чого складається така система і що вона дає в цифрах.
Що змінюється після впровадження: вимірювані ефекти
Ефект від рекомендацій ми не оцінюємо на око: в системі фіксуються чотири величини — точність прогнозу попиту, оборотність запасів, частка неліквідів і швидкість перезбирання асортиментної матриці.
Перші дві показують, наскільки точно модель описує майбутній попит, наступні дві — скільки капіталу лежить на складі мертвим вантажем і як швидко категорійний менеджер устигає відреагувати на зсув ринку.
Точність прогнозу попиту вважаємо окремо — за товарною позицією, складом і тижнем, а не усереднено за категорією: усередині групи помилки взаємно гасяться, і метрика починає брехати.
Базовий сезонний профіль будуємо на відкритій моделі Prophet, поверх неї модель донавчається на промо та локальних сплесках. Помилка прогнозу на порівнянному горизонті падає на 20–35% проти планування за середнім за минулий період.
Оборотність зростає не за рахунок урізання матриці, а за рахунок перерозподілу: рекомендації підказують, що перекинути між складами, що дозамовити і від чого відмовитися.
Частка неліквідів знижується спочатку за рахунок раннього виявлення позицій зі спадним попитом, потім — керованими розпродажами та замінами.
Найшвидше змінюється швидкість перезбирання асортименту: замість квартального циклу в таблицях матриця перераховується за подією — сплеск попиту, зміна постачальника, вихід новинки.
Прогін займає хвилини, тому менеджер перевіряє кілька сценаріїв і одразу бачить їхній вплив на оборотність і неліквіди.
Режими роботи моделі: пакетний, потоковий, гібридний
Режим перерахунку задає, як швидко зміна попиту доходить до матриці і скільки коштує затримка.
Пакетний, потоковий і гібридний варіанти розв'язують одну задачу різними способами: перший рахує за розкладом на всьому обсязі, другий реагує на події, третій розділяє гарячий і холодний контури.
Вибір визначають дві речі — потрібна частота перерахунку рекомендацій і розкид попиту всередині матриці.
Якщо основна маса позицій поводиться стабільно, а реагувати потрібно на кілька десятків артикулів, подієва обробка всього каталогу не дає нічого, крім навантаження на джерело даних.
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Пакетний перерахунок | Стійкий попит, матриця на тисячі позицій, рішення ухвалюються раз на добу | Рекомендація старіє між запусками; сплеск попиту відображається із затримкою до наступного циклу |
| Потоковий | Акції, сезонні піки, швидко змінюваний топ асортименту | Чутливий до шуму: за слабких сигналів матриця «тремтить»; розрахунок складніше відтворити й розібрати постфактум |
| Гібридний | Неоднорідний каталог: ядро стабільне, частина позицій живе в режимі постійних коливань | Потребує явного розділення пріоритетів і захисту від конфліктів версій між контурами |
На практиці частіше беруть гібрид: топ позицій і акційні групи перераховуються за подіями, решта матриці — регламентним пакетом.
Обидва контури пишуть в одну вітрину рекомендацій з версіонуванням, тому оновлення матриці залишається відтворюваним, а розбіжності між розрахунками розв'язуються за пріоритетом, а не за часом запису в базу.
Як ми впроваджуємо систему: етапи інженерної роботи
Впровадження йде ітераціями: кожен етап закінчується артефактом, який перевіряється на історичних даних, а не статусом у звіті.
Модель не запускається на всій матриці одразу — спочатку вузький контур, де рекомендації порівнянні з поточною політикою закупівлі, і лише потім розширення. Нижче — послідовність робіт.
- Аудит даних. Збираємо історію продажів, залишків, поставок, знижок і промо за доступний період; перевіряємо повноту матриці «товар — день», дублі, пропуски й розриви в довідниках. Фіксуємо, яких категорій даних достатньо для прогнозу, а які доведеться вести за ручними правилами.
- Схема моделі. Визначаємо горизонт прогнозу та рівень рішення — окрема товарна позиція або кластер взаємозамінних. У признаки йдуть сезонність, промо, еластичність попиту, термін придатності та канібалізація; схема валідується на відкладеному періоді, який модель не бачила.
- Налаштування правил відбору. Поверх прогнозу накладаються обмеження бізнесу: мінімальна викладка, кратність упаковки, поличний простір, ліміти постачальника. Правила лежать окремо від моделі, тому змінюються без перенавчання й узгоджуються з категорійними менеджерами.
- Перевірка якості рекомендацій. Порівнюємо запропоновану політику закупівлі з фактичною на тих самих періодах: рахуємо точність, частку дефіциту, обсяг надлишків і кількість ручних правок. Якщо рекомендації не виграють у поточного процесу — повертаємося до схеми моделі, а не розширюємо пілот.
- Пілот на обмеженому контурі. Запускаємо на кількох категоріях паралельно з попереднім процесом, звіряємо план і факт щотижня та налаштовуємо пороги спрацювання.
- Передача в експлуатацію. Віддаємо регламент перенавчання, панель контролю деградації прогнозу, інструкції для менеджерів і порядок відкату до попередніх правил, якщо якість опускається нижче узгодженого порогу.
Що передаємо на руки: конфігурації та регламенти
Передаємо не «працюючу систему», а набір артефактів, за якими ваша команда зможе змінювати правила сама — без звернення до нас за кожним коригуванням. Кожен пункт перевіряємо на прийманні: якщо за документом не можна відтворити крок, він не вважається зданим.
- Конфігурація моделі: признаки, пороги спрацювання, ваги правил і межі, за якими рішення йде на ручну перевірку — з поясненням, як налаштування впливає на видачу.
- Регламент перезбирання асортименту: періодичність, джерела даних, порядок запуску, контрольні точки та умови, за яких перезбирання зупиняють і повертають попередню версію.
- Політики доступу та ролі: хто змінює правила, хто лише дивиться, хто погоджує виведення категорії — з розподілом за рівнями та журналом дій.
- Схема інтеграції з обліковою системою: звідки беруться довідники та залишки, як часто йде синхронізація, що робити при розбіжності та як читати журнал обміну.
- Документація на систему: логіка рішень, словник даних, інструкції для аналітика й оператора, порядок ескалації збоїв.
- Набір перевірок: сценарії на типові та граничні випадки — нова категорія, нульовий залишок, сезонний сплеск — щоб правки не ламали видачу.
- План передачі: спільний розбір із вашою командою, прогін перезбирання на вашій стороні та період супроводу змін.
Після приймання правки в правилах, запуск перезбирання та розбір збоїв ваша команда закриває за регламентом — ми залишаємося на зв'язку, коли змінюється сама логіка.
Кейс: перезбирання асортименту та відхід від неліквідів
Дистриб'ютор з матрицею близько 9 000 артикулів перезбирав асортимент раз на сезон. Категорійні менеджери зводили продажі, залишки та умови поставок у таблицях — на одне перезбирання йшло три тижні, і до його кінця частина розрахунків уже була неактуальною.
Ціна такого режиму видна в цифрах того періоду: частка неліквідів трималася на 34%, точність влучання в попит не перевищувала 58%, а виведені раніше позиції поверталися в матрицю за інерцією — даних для впевненого рішення бракувало.
Що змінили
Модель рахує попит за кожним артикулом щодня: сезонність, оборотність, вплив сусідніх позицій і акцій. На виході — чотири класи рекомендацій: залишити, скоротити частку, вивести, ввести заміну.
Дані підтягуються з 1С без ручних вивантажень, тому перезбирання матриці займає два робочі дні замість трьох тижнів.
Метрики до і після
- Частка неліквідів: 34% → 11% за два квартали.
- Точність влучання в попит: 58% → 84%.
- Перезбирання матриці: три тижні → два дні.
- Виручка на артикул: +19% за незмінного обсягу полиці.
- Термін до ефекту: перші рішення щодо виведення — на третьому тижні, стійкий зсув — до кінця другого кварталу.
Рішення залишається за категорійним менеджером: система показує розрахунок і причину, спірні позиції йдуть в обмежений тест, а не в ручну ротацію. Звідси й результат — скоротили не асортимент, а час на рішення, які раніше відкладали.
Чим модель ранжування відрізняється від правил на порозі
Правила на порозі — детермінований шар: товар потрапляє у видачу, лише якщо виконано умови за залишком, терміном поставки та обмеженнями майданчика. Такий шар пояснюваний і відтворюваний — будь-який показ розбирається за кроками.
Там, де помилка дорога (заборонена категорія, нульовий залишок, прострочений термін), правила надійніші за будь-яку модель.
Модель ранжування працює не замість них, а всередині допустимої множини: упорядковує те, що пройшло поріг, і вирішує, що показати першим за обмеженої кількості місць. Навчання йде на зворотному зв'язку від покупців — переглядах, додаваннях у кошик, поверненнях. Метрика якості тут — приріст виручки на зайнятих позиціях, а не точність влучання.
Окрема проблема — холодний старт позиції: у нового товару немає історії, і модель його занижує, бо не бачила взаємодій.
Допомагають ознаки з атрибутів і близькості до працюючих товарів плюс зарезервована частка показів на дослідження — інакше новинки не отримують шансу, а система навчається лише на старому асортименті.
Обмеження рекомендацій тримаємо в правилах: замкнений контур зворотного зв'язку підсилює популярне, популярне отримує більше показів, і асортимент стискається до десятка хітів.
Тому задаємо стелю частки одного товару у видачі, ліміт на повтори та переоцінку ваг на відкладеному періоді.
На практиці це один контур: правила задають, що показувати допустимо, ранжування — у якому порядку. Перше дає передбачуваність і розбір інцидентів, друге — гнучкість під попит.
Технічні сумніви перед стартом проєкту
Сумніви перед стартом стосуються не алгоритмів, а даних і процесів. Нижче — п'ять питань, які ми закриваємо до запуску, щоб результат не залежав від якості вихідних вивантажень.
Дані брудні — система взагалі заробить?
Профілюємо історію транзакцій: дублі позицій, пропуски в цінах, некоректні повернення. Нормалізацію та довідники категорій збираємо до навчання — інакше модель вивчить помилки обліку як закономірність.
Чи вистачить обсягу історії продажів?
Для тижневого прогнозу потрібні півтора-два повні цикли продажів — інакше не видно спадів. Коротку історію агрегуємо до категорій: точність за окремими позиціями нижча, і це проговорюємо заздалегідь.
Чому система так рекомендує?
Рекомендація розкладена на фактори: еластичність, внесок акцій, канібалізація сусідніх позицій, залишок і термін поставки. Закупівельник бачить, із чим сперечається, і відхиляє пораду вмотивовано.
Врахуєте нашу сезонність?
Сезонні профілі будуємо за кожною категорією окремо, з поправкою на свята, акції та локальні події. Календар мережі задається явно — минулі піки не переносяться на новий період механічно.
Хто супроводжує модель після запуску?
Модель дрейфує разом з асортиментом і попитом. Регламент: контроль точності, алерти на відхилення, планове донавчання та розбір спірних рекомендацій разом із вашою категорійною командою.
Обговорімо задачу та повернімося з планом робіт
Щоб повернутися з оцінкою термінів і планом робіт, нам достатньо опису поточного процесу: звідки беруться дані про продажі, залишки та поставки, хто і як часто ухвалює рішення про введення й виведення позицій.
Корисно знати, де саме втрачається час — ручна звірка звітів, розрізнені таблиці, затримка між сигналом і рішенням.
За таким описом збираємо картину цілком і приходимо з конкретикою:
- Розбір процесу — розкладемо управління асортиментом на кроки та знайдемо, які з них автоматизуються, а які залишаються за людиною.
- Схема даних та інтеграцій — покажемо, звідки система бере історію продажів, залишки та зовнішні фактори, і що потрібно з боку облікових систем.
- Оцінка термінів — назвемо тривалість етапів і момент, коли з'являться перші управлінські рішення на даних.
- Склад команди — зафіксуємо, хто веде аналітику, хто відповідає за модель, хто за впровадження та супровід.
- План робіт — етапи з перевірюваним результатом на кожному, без довгого «сліпого» періоду на початку.
- Критерії приймання — заздалегідь домовимося, за якими метриками вважаємо рішення працюючим: точність прогнозу, частка позицій з автопідказкою, швидкість реакції на зміну попиту.
- Старт проєкту — визначимо першу ділянку асортименту для запуску, щоб ефект було видно до повного розгортання.
Опишіть задачу у вільній формі — поточний процес, вузькі місця, що хочете отримати. Ми повернемося з оцінкою, схемою рішення та планом впровадження, а далі вже вирішите, чи підходить склад команди та терміни.
