Коротко: запаси добре надаються AI, бо кожне корисне запитання тут вимагає поєднати чотири-п'ять джерел: залишок, відкриті замовлення постачальникам, відкриті замовлення клієнтів, терміни постачання й історію споживання. Людина робить це за двадцять хвилин на позицію — і тільки для тих позицій, про які хтось згадав.
Покриття, а не залишок
Питання «скільки в нас на складі» має просту відповідь і майже нульову цінність. Питання, яке справді потрібне: чи вистачить наявного плюс того, що приїде, на те, що вже обіцяно, і на те, що ми очікуємо продати до наступного надходження.
Асистент розділяє дефіцит на три різні ситуації, і це розділення й робить перелік дієвим:
- Замовлення постачальнику взагалі немає — треба розміщувати, і чим раніше, тим краще.
- Замовлення є, але приїде пізніше, ніж потрібно — треба прискорювати або шукати альтернативу.
- Позиція вже обіцяна у відкритих замовленнях клієнтів — найдорожча категорія, бо тут ідеться про зірваний строк, а не про порожню полицю.
У стандартному звіті всі три виглядають однаково — як позиція нижче точки замовлення. Дії при цьому потрібні різні.
Постачальник, який завжди запізнюється
Планування йде за підтвердженими датами. Якщо постачальник стабільно приходить на одинадцять днів пізніше, план не спрацює — тихо, кожного разу, і ніхто не побачить причини.
Історія фактичних надходжень проти підтверджених дат лежить у Business Central повністю. Порахувати середнє відхилення по кожному постачальнику — робота на кілька хвилин для системи й на кілька днів для людини, тому її ніхто не робить. Асистент може підставляти реальні терміни замість номінальних і одразу показувати, які позиції від цього переходять у зону ризику.
Механіка самого розрахунку — у нашому матеріалі про точку замовлення й страховий запас.
Заморожений капітал
Дзеркальна проблема й зазвичай більша сума. Товар, що не рухається, невидимий у звіті про прибутки й дуже помітний у балансі.
Ключове в тому, як подати результат. Перелік із чотирьохсот повільних позицій — це звіт, за яким ніхто нічого не робить. «€180 000 не рухалося понад рік, і 60% цієї суми — в одинадцяти позиціях» — це рішення, яке можна ухвалити сьогодні. Далі йдуть уточнювальні запитання, і саме тут перевага розмови над звітом: чи це сезонне, чи це під контракт, чи це залишок після зміни модельного ряду.
AI і аркуш планування
У Business Central є аркуші планування й потреби, і вони працюють. AI їх не замінює — це варто сказати прямо, бо продають зазвичай навпаки.
Що AI додає: пояснення, чому пропозиція з'явилася; позначку, коли вона спирається на нетипову історію (одне велике разове замовлення, яке система сприйняла за попит); підстановку фактичних термінів постачання замість налаштованих. Якщо картки номенклатури підтримуються в порядку, механізм планування рахує добре, а асистент дає можливість його розпитати. Якщо налаштування поповзли, AI успадкує це сповзання й нічого не врятує.
Де аналіз стає тонким
Дві речі, які ламають цифри непомітно.
Метод собівартості. FIFO, середня й стандартна поводяться по-різному, а вартість, знята до прогону коригування, є попередньою. Асистент має це позначати, інакше цифра розійдеться з книгою й ніхто не зрозуміє чому. Деталі — у розборі методів оцінки запасів.
Локації. Товар, який є в компанії, але лежить не на тому складі, для конкретного замовлення не існує. Аналіз на рівні компанії там, де бізнес працює на рівні локацій, формально правильний і практично марний. Суміжна тема — розбіжності залишків на складі: якщо облікові залишки розходяться з фактичними, аналітика поверх них рахує неіснуючий товар.
З чого почати
Найдешевший перший крок — не проєкт, а перевірка. Візьміть двадцять позицій, які найчастіше створюють проблеми, і порахуйте вручну: скільки з них зараз у зоні ризику за фактичними, а не підтвердженими термінами постачання. Якщо результат вас здивує, у вас є привід рахувати це регулярно. Якщо ні — ваші налаштування в порядку, і AI тут дасть небагато.
Як це виглядає у вигляді рішення — на сторінці AI для запасів у Business Central.
Часті запитання
Чим це відрізняється від аркуша планування?
Аркуш рахує пропозиції з налаштувань картки й робить це добре. AI пояснює, чому пропозиція з'явилася, позначає, коли вона спирається на разовий сплеск попиту, і підставляє фактичні терміни постачання замість налаштованих. Це доповнення, а не заміна.
Що робити, якщо картки номенклатури застаріли?
Спершу полагодити їх. Точки замовлення, терміни й модифікатори мають відповідати дійсності, інакше і механізм планування, і AI рахуватимуть від неправильних вхідних. Це оцінюють на discovery, і чесна відповідь часто саме така.
Чи враховується сезонність?
Якщо є два-три роки історії — так. За меншого періоду асистент опише випадковий сплеск як сезонність, і зробить це переконливо. Він має вказувати, на скількох періодах побудований висновок.
Чи працює це з кількома складами?
Так, і має працювати саме так. Аналіз на рівні компанії ховає ситуацію, коли товар є, але не там, де потрібен. Для цього налаштування локацій має відповідати тому, як ви справді працюєте.
Чи може агент сам створювати замовлення постачальникам?
Може, у межах дозволів. Оскільки непроведене замовлення закупівлі легко виправити, створення без нагляду з переглядом перед випуском — розумна стартова позиція. У фінансах межу проводять суворіше, бо там помилки відмотувати дорожче.