1. Визначте, яке рішення має приймати система
Розділіть три задачі: виявити потребу, запропонувати кількість і дозволити закупівлю. Їх не обов’язково автоматизувати одночасно. На першому етапі система може щодня формувати список рекомендацій, а закупівельник — перевіряти його з урахуванням домовленостей із постачальником. Це дозволяє виявити помилкові правила до появи фінансових зобов’язань.
Визначте межі: один склад, конкретна група товарів, одиниця обліку та відповідальний. Не змішуйте поповнення магазину із центрального складу й зовнішню закупівлю, якщо в них різні строки та обмеження. Запишіть, що вважається успіхом: менше непланових термінових замовлень, доступність погодженого асортименту або зменшення залежалих залишків. Цілі можуть конфліктувати, тому «мінімум запасів і жодного дефіциту» без умов не є коректним завданням. Погодьте, які компроміси прийнятні та хто вирішує суперечності між доступністю, бюджетом і місцем зберігання.
2. Узгодьте фізичний, доступний залишок і позицію запасу
Фізичний залишок описує наявні одиниці, але не всі вони доступні для продажу: можливі резерви, карантин, пошкодження чи контроль якості. Доступний залишок відповідає на питання про можливість виконати нове замовлення зараз. Для поповнення потрібна ще інформація про підтверджені надходження та незакритий попит. Назви полів у різних системах відрізняються, тому перевіряйте зміст, а не лише заголовок звіту.
У спрощеній моделі позиція запасу може визначатися як придатний наявний запас плюс підтверджені замовлені надходження мінус невиконані зобов’язання, ще не враховані іншим способом. Не віднімайте той самий попит двічі: якщо він уже зменшив вихідний доступний залишок, повторне віднімання резерву завищить потребу. Запишіть формулу саме для ваших полів і перевірте її на одному замовленні від резервування до відвантаження. Так само не зараховуйте непідтверджену чернетку закупівлі як гарантований товар у дорозі. Рекомендація повинна показувати складові, щоб закупівельник міг пояснити результат.
3. Виміряйте строк до придатного товару
Строк постачання — не лише обіцянка перевізника. Для рішення про поповнення може бути важливим час від дозволу на замовлення до моменту, коли товар прийнято, перевірено й дозволено використовувати. Якщо погодження закупівлі займає два дні, а приймання ще день, їх не можна ігнорувати тільки тому, що доставка триває швидко. Водночас чітко позначте початкову подію, щоб не змішувати різні визначення.
Зберіть фактичні строки за порівнюваними постачаннями, подивіться на розкид і причини затримок. Поставки з різних маршрутів або різними умовами не завжди варто зводити в одне середнє. Позначайте часткові надходження: дата першої коробки не означає, що весь замовлений обсяг уже доступний. Для товару з нерегулярними поставками невелика історія не дає надійної оцінки майбутнього. У таких випадках потрібен явний ручний перегляд і сценарії затримки, а не впевнене число з двома знаками після коми.
4. Перевірте просту точку замовлення на прикладі
Навчальний приклад, не рекомендація для конкретного бізнесу: попит стабільний, у середньому 6 одиниць за день; поповнення займає 5 днів; погоджений фіксований буфер — 12 одиниць. Спрощена точка замовлення становить 6 × 5 + 12 = 42 одиниці. У моделі безперервного контролю сигнал виникає, коли визначена позиція запасу досягає цього рівня або опускається нижче. Це сигнал перевірити чи створити поповнення за погодженим правилом, а не відповідь на питання про кількість закупівлі.
Буфер 12 у прикладі обрано умовно. Формула не доводить жодного рівня сервісу й не враховує сезонність, нестабільний попит, обмеження постачальника або затримки. Якщо стан переглядають лише раз на тиждень, потрібно врахувати також інтервал між переглядами: модель безперервного сигналу вже не описує процес. Не копіюйте 42 в ERP без перевірки припущень. Спочатку відтворіть кілька історичних рішень і подивіться, коли виник би сигнал та який товар реально був би доступним на той момент.
5. Відокремте момент замовлення від його кількості
Досягнення порогу не означає «замовити до порогу» або «замовити ще стільки само». Кількість може визначатися цільовим рівнем, інтервалом перегляду, мінімальною партією, упаковкою та обмеженням бюджету. Якщо розрахункова потреба становить 17 одиниць, а постачальник відвантажує коробками по 6, округлення до 18 має бути видимим. Але навіть арифметично правильне округлення не є автоматичним дозволом на закупівлю.
Перевірте мінімальну суму замовлення, строк придатності, місткість складу, товари-замінники та вже заплановані переміщення. Система має показувати початкову потребу й причину кожного коригування. Інакше неможливо зрозуміти, чому рекомендація раптово збільшилася вдвічі. Для нового товару історичного попиту може не бути; його початковий запас — окреме асортиментне рішення. Для товару, що виводиться з продажу, стандартне поповнення може бути заборонене навіть за низького залишку. Такі стани потрібно зберігати явно, а не покладатися на пам’ять конкретного закупівельника.
6. Сегментуйте асортимент за рішеннями, а не лише літерами ABC
ABC-аналіз за річною вартістю споживання може допомогти розподілити увагу, але він не показує автоматично маржинальність, критичність або ризик дефіциту. Недорога деталь може зупинити виробництво, а дорогий повільний товар — мати прийнятний строк очікування для покупця. Вкажіть, за яким показником побудована класифікація та яке правило змінюється для кожної групи.
Додайте стабільність попиту, можливість заміни, строк поповнення та життєвий цикл. В одязі модель, колір і розмір можуть мати різну поведінку: загальний запас моделі не гарантує наявності потрібного розміру. Не роздрібнюйте аналіз до випадкових висновків за кількома продажами. Для рідкісних позицій іноді потрібне ручне рішення або закупівля під підтверджене замовлення. Таблиця нижче показує три різні режими контролю. Їхня мета — визначити, кому й коли переглядати рекомендацію, а не надати універсальну матрицю для всіх магазинів.
Різні товари — різні режими контролю
Навчальні приклади, не готові параметри для ERP. Кількості визначаються за вашими даними.
Таблицю можна прокрутити горизонтально.
| Ситуація | Режим | Що перевіряти |
|---|---|---|
| Регулярне стабільне споживання | Погоджений сигнал поповнення й періодичний перегляд параметрів. | Строк, буфер, упаковка та підтверджені надходження. |
| Сезонна модель одягу | План на сезон із ручним переглядом винятків. | Розміри, залишок сезону й ризик непроданих позицій. |
| Рідкісна критична деталь | Окреме рішення про резерв або закупівлю під потребу. | Наслідок відсутності, заміна та реальний строк отримання. |
Висновок. Літера ABC не замінює рішення про критичність. Документуйте причини ручного коригування.
7. Не вважайте продажі повним виміром попиту
Коли товару немає, продажі можуть дорівнювати нулю не через відсутність інтересу, а через неможливість купити. Якщо механічно використовувати цей період у середньому, система зменшить прогноз і продовжить дефіцит. Позначайте дні недоступності та окремо аналізуйте відмови, запити, передзамовлення або заміни, якщо такі дані надійно фіксуються. Не вигадуйте втрачений попит із довільного множника.
Акції, сезонність і великі разові замовлення теж потребують пояснення. Не видаляйте їх автоматично як «викиди»: вони могли повторюватися за планом. Для майбутньої акції погодьте сценарій, горизонт і відповідального за перегляд після завершення. Повернення відокремлюйте від нового попиту; товар після повернення не завжди одразу придатний до продажу. Збережіть причини ручних коригувань, щоб згодом перевірити їхню якість. Якщо закупівельник регулярно виправляє одну групу рекомендацій, це сигнал переглянути модель або дані, а не просто додати ще одну приховану поправку.
8. Використовуйте pull і kanban там, де вони відповідають потоку
Lean Enterprise Institute описує pull як поповнення за потребою наступного етапу, а kanban — як сигнал у такому потоці. Практичний висновок: потрібні зрозумілий тригер, визначена кількість і відповідальний за реакцію. Дошка зі статусами задач сама по собі не створює систему поповнення запасів. Для повторюваного споживання варто перевірити, чи сигнал можна зробити простим і видимим без складного прогнозу.
Перед запуском погодьте, що відбувається при втраті сигналу, зміні упаковки, затримці постачання або різкому зростанні споживання. Не переносіть одну кількість на всі товари й не зменшуйте буфери лише заради красивого показника запасу. Стабільність потоку та здатність реагувати мають значення. Почніть з обмеженої зони й простежте кілька циклів від споживання до відновлення рівня. Якщо сигнал приходить вчасно, але ніхто не має повноважень зробити замовлення, проблема залишається організаційною. ERP може зафіксувати сигнал, але не замінить домовленість про дію.
9. Запускайте рекомендації з журналом винятків
Спочатку порівнюйте рекомендацію системи з рішенням відповідального без автоматичного надсилання постачальнику. Для розбіжностей записуйте причину: неточний залишок, запізніле надходження, акція, обмеження бюджету або неправильне правило. Перевіряйте не тільки середній запас, а й дефіцит, термінові закупівлі, залежалі позиції та час ручного перегляду. Покращення одного показника може погіршити інший.
Коли правила стабілізуються, визначте межі автоматичної дії: допустимі товари, суми, постачальники й умови зупинки. Зміни параметрів повинні мати автора та пояснення. Якщо дані застарілі або надходження не підтверджене, рекомендація має показати невизначеність, а не удавати точність. Регулярно переглядайте параметри після зміни попиту чи строків. Робоча система поповнення — це не один раз виставлені мінімальні залишки, а керований цикл спостереження, рішення та перевірки.
- Зміст усіх складових залишку погоджений.
- Попит не віднімається двічі через резерви.
- Строк враховує момент доступності товару.
- Поріг і кількість закупівлі визначені окремо.
- Винятки та право підтвердження закупівлі явні.
Офіційні джерела
Першоджерела для перевірки термінів і подальшого читання. Практичні приклади Routio — навчальні, а не клієнтські кейси. Налаштування систем звіряйте з документацією своєї версії.