Управління складськими запасами: дистриб'ютор FMCG

Управління складськими запасами в дистриб’ютора FMCG рідко ламається на самому складі. Воно ламається раніше: коли замовлення торгового представника приходить голосовим у Viber, менеджер увечері переносить його в BAS, а залишок, який ТП бачив зранку, вже продали іншому клієнту. І пізніше: коли товар відвантажили клієнту з простроченим боргом, бо про борг ніхто не знав у момент замовлення.

Ця стаття для власника або операційного директора дистриб’юторської компанії, яка працює з магазинами, кіосками, HoReCa і невеликими мережами. Тут немає теорії логістики. Є послідовність: як прийняти замовлення так, щоб воно одразу резервувало товар; як порахувати точку замовлення з урахуванням строку придатності й промо; як поставити ліміти боргу; що з цього може робити штучний інтелект, а що мають рахувати формули.

Окремо розберемо вибір: готова програма для торгових представників, доробки в BAS чи власна система під ваш процес. І чесно скажемо, коли автоматизація не окупиться.

Коротко

Запаси і дебіторка — це одні й ті самі гроші. Надлишок на складі й прострочений борг клієнта однаково заморожують оборотні кошти. Керувати ними треба в одному місці.
Прогноз починається з замовлення ТП. Якщо ТП не записує те, що клієнт хотів, але чого не було, система ніколи не побачить справжній попит.
Точка замовлення для FMCG — не лише «продажі × днів поставки». Строк придатності, вимоги мереж до залишкового строку, кратність упаковки й промо змінюють розрахунок.
ШІ розбирає замовлення у вільній формі, читає листи постачальників і готує чернетки. Кількість у заявці рахують формули, а підтверджує людина.
Почати можна з одного процесу за тиждень. Перша версія системи — за кілька днів, далі модулі по одному, поки стара схема ще працює паралельно.

Чому в дистриб’ютора запаси і борги — це одні гроші

Як виглядає день, коли замовлення живуть у месенджерах

Торговий представник виходить на маршрут. У нього 15–20 точок за день. У кожній він рахує полицю, говорить із товарознавцем і формує замовлення. Половина клієнтів диктує замовлення усно, частина пише у Viber, хтось надсилає фото рукописного списку. ТП переписує це в нотатки або пересилає менеджеру як є.

Увечері менеджер в офісі розбирає повідомлення від усіх ТП. Переносить позиції в облікову систему, уточнює незрозуміле дзвінками, перевіряє залишки. Частина позицій, які ТП пообіцяв зранку, вже закінчилась. Клієнт отримує неповне замовлення і дізнається про це лише при доставці.

У цій схемі немає жодної точки, де одночасно видно три речі: що хоче клієнт, що є на складі і скільки клієнт винен. Кожну з них знає окрема людина, і вони зводять дані вручну раз на день.

Три місця, де застрягають гроші

Залишки без правила поповнення. Закупівельник замовляє «як минулого разу» або «щоб вистачило». За швидкими позиціями виникає дефіцит, а повільні лежать місяцями й наближаються до кінця строку придатності.

Відвантаження без перевірки в момент замовлення. Товар резервується лише тоді, коли менеджер вніс замовлення. До цього два ТП можуть пообіцяти той самий останній палет двом різним клієнтам.

Дебіторка, про яку дізнаються пізно. ТП «знає клієнта» і бере нове замовлення, хоча попереднє ще не оплачене. Бухгалтерія бачить прострочення через тиждень, коли товар уже відвантажено.

Усі три місця — це оборотні кошти, яких немає в касі. Тому далі ми говоримо про управління запасами й дебіторкою разом: це один процес «замовлення → резерв → відвантаження → оплата → поповнення».

Як порахувати, скільки грошей заморожено у вашому складі

Порахувати можна за вечір, у вивантаженні з облікової системи. Для кожної позиції вам потрібні три цифри: середній продаж за день, термін поставки від постачальника в днях і звичайний розмір партії.

Розумний максимум = точка замовлення + звичайна партія. Як рахувати точку замовлення, покажемо нижче.
Надлишок = фактичний залишок − розумний максимум. Якщо результат від’ємний, надлишку немає.
Заморожені гроші = надлишок × собівартість одиниці.
Складіть надлишки по всіх позиціях і окремо подивіться на перші 20 позицій за сумою. Зазвичай саме там основна частина проблеми.

Приклад (умовні дані). Вода 0,5 л продається в середньому по 30 коробок на день. Постачальник везе 4 дні, страховий запас тримаємо на 2 дні продажів. Точка замовлення: 30 × 4 + 30 × 2 = 180 коробок. Звичайна партія — тижнева, 210 коробок. Розумний максимум — 390 коробок. На складі 900 коробок. Надлишок — 510 коробок, це 17 днів продажів, які лежать без потреби. Помножте 510 на собівартість коробки — і отримаєте суму, яку можна було б тримати в обороті.

Так само порахуйте прострочену дебіторку: сума боргів, у яких минув термін відстрочки, по кожному клієнту. Дві цифри разом — надлишок і прострочка — показують, скільки грошей у бізнесі заблоковано неуправлінськими рішеннями.

Управління складськими запасами починається з прийому замовлень

Чому замовлення ТП — головне джерело даних про попит

Прогноз будь-якої програми спирається на історію продажів. Але продажі — це не попит. Якщо позиції не було на складі, ТП її не записав, і в історії залишився нуль. Наступного разу формула бачить «не продається» і замовляє ще менше. Так дефіцит відтворює сам себе.

Тому перше правило: замовлення ТП фіксує не лише те, що відвантажать, а й те, що клієнт хотів. Окреме поле «хотіли, але не було» з кількістю. Через місяць ви побачите, які позиції системно недозамовляєте, і точка замовлення почне рахуватися від справжнього попиту.

Друге правило: замовлення потрапляє в систему в момент оформлення, а не ввечері. Тільки тоді резерв, залишок і ліміт клієнта перевіряються одночасно.

Як працює прийом замовлення через Telegram-бот

Для ТП найпростіший інтерфейс — бот у Telegram. Не треба встановлювати окремий застосунок і вчитися новому інтерфейсу. Сценарій виглядає так:

ТП обирає торгову точку зі свого маршруту. Бот показує борг клієнта, ліміт і останні три замовлення.
Бот пропонує рекомендоване замовлення: середній продаж цієї точки між візитами мінус те, що ТП порахував на полиці.
ТП виправляє кількість або пише позиції текстом: «кола 0,5 — 4 упаковки, сік яблучний 1 л — 2 ящики».
Система розпізнає позиції, підставляє артикули й перевіряє залишок із урахуванням уже зроблених резервів.
Якщо товару не вистачає, бот одразу пропонує заміну або часткове відвантаження. Неотримана кількість записується в «хотіли, але не було».
Якщо замовлення перевищує ліміт або в клієнта є прострочка, бот попереджає ТП, поки той ще в точці. Можна одразу попросити оплату або зменшити замовлення.
ТП підтверджує. Товар резервується, замовлення стає в чергу на збирання, клієнт отримує підтвердження в месенджері.

Різниця з ручною схемою не в швидкості набору. Різниця в тому, що конфлікти виявляються в точці, а не на складі ввечері.

Клієнти, які пишуть у Viber, WhatsApp чи на пошту

Частина клієнтів не перейде на новий канал, і змушувати їх не варто. Для них ШІ розбирає повідомлення у вільній формі: список у тексті, фото рукописного бланка, вкладення Excel від мережі. Він знаходить позиції в каталозі, кількість і адресу доставки.

Важливо, що робить людина. Розібране замовлення не йде на склад автоматично. Менеджер бачить чернетку з підсвіченими сумнівними позиціями: «”Сік 1” — у каталозі три соки по 1 л, уточніть». Він виправляє одне-два поля і підтверджує. Якщо позиція незрозуміла взагалі, система готує уточнювальне питання клієнту, а менеджер вирішує, чи надсилати.

Так ми робимо й у власних системах: ШІ розбирає заявки й повідомлення, уточнює деталі з клієнтом у Telegram і готує чернетки відповідей, але клієнту нічого не надсилається без людини, якщо інше не погоджено. Детальніше про те, як зібрати всі канали в одну чергу, — на сторінці про автоматизацію обробки замовлень і заявок.

Резерв під замовлення і перевірка ліміту

Резерв — це кількість, яка ще фізично лежить на складі, але вже обіцяна клієнту. Вільний залишок = фактичний залишок − резерви. ТП і менеджери мають бачити саме вільний залишок, а не фактичний.

Три правила, без яких резерв не працює:

Резерв має термін. Якщо замовлення не відвантажили, наприклад, за два дні, резерв знімається і менеджер отримує сповіщення. Інакше «мертві» резерви блокують товар.
Пріоритет резерву задано заздалегідь. Наприклад, мережі з договірними штрафами за недопоставку резервуються першими, а роздрібні точки — в порядку надходження.
Перевірка ліміту йде разом із резервом. Немає сенсу резервувати товар клієнту, якому все одно не відвантажать через борг.

ABC і XYZ: які позиції контролювати щодня

Як розбити асортимент на групи

У дистриб’ютора FMCG сотні або тисячі позицій. Рахувати точку замовлення вручну для кожної неможливо, а однакові правила для всіх дають надлишки повільних позицій і дефіцит швидких. Розв’язок — розбити асортимент двома способами.

ABC — за внеском у виручку або маржу. Відсортуйте позиції від найбільшої виручки до найменшої. Група A — невелика кількість позицій, на які припадає основна частина виручки. Група C — довгий хвіст, який дає мало грошей. Межі між групами компанія обирає сама; головне — щоб група A вміщалася в щоденний контроль однієї людини.

XYZ — за стабільністю продажів. Для кожної позиції порахуйте, наскільки тижневі продажі коливаються навколо середнього. Технічно це коефіцієнт варіації: стандартне відхилення тижневих продажів, поділене на середнє. X — продається рівно, Y — коливається через сезон чи промо, Z — продається рідко й непередбачувано. Часто беруть межі 0,1 і 0,25, але перевірте їх на своїх даних.

Перераховуйте групи щомісяця. Нова позиція перший місяць іде в окрему групу «новинки» з ручним контролем.

Матриця: що робити з кожною групою

Група	Що це	Правило поповнення	Хто контролює
AX	Ходові й стабільні	Автоматична чернетка заявки за точкою замовлення, щоденна перевірка	Система, менеджер підтверджує
AY	Ходові, але залежать від сезону й промо	Точка замовлення з поправкою на промо-календар	Менеджер щотижня переглядає прогноз
AZ	Дорогі й непередбачувані	Під конкретні замовлення клієнтів або мінімальний запас	Керівник закупівлі вручну
BX, BY	Середні	Автоматична чернетка раз на тиждень	Система, менеджер підтверджує
CX, CY	Хвіст зі стабільним попитом	Мінімальна партія, рідкі поставки	Система
CZ	Хвіст без попиту	Кандидати на виведення з асортименту або роботу під замовлення	Власник раз на квартал

Сама таблиця нічого не автоматизує. Але вона відповідає на питання, де потрібна людина, а де достатньо правила. Саме це й треба закласти в систему.

Точка замовлення для FMCG: строки, промо, кратність

Базова формула

Методичні матеріали Logistics Cluster з управління рівнями запасів пропонують простий розрахунок: буферний запас дорівнює часу очікування поповнення в днях, помноженому на щоденне споживання; рівень повторного замовлення дорівнює буферному запасу плюс страховий. Там же наголошено, що для кожної позиції треба встановити максимальний рівень запасу з урахуванням місткості складу й умов зберігання.

Для дистриб’ютора це означає: коли вільний залишок опускається до точки замовлення, система формує чернетку заявки постачальнику. Розмір заявки — до розумного максимуму.

У статті про автоматизацію складського обліку ми детально розібрали страховий запас для виробництва. У FMCG до цієї формули додаються чотири поправки.

Поправка 1. Строк придатності обмежує максимум

У виробника металу надлишок просто займає місце. У дистриб’ютора напоїв і снеків надлишок псується. Тому максимальний запас обмежений не лише складом, а й строком.

Приклад (умовні дані). Строк придатності йогурту — 30 днів. Товар приходить від виробника із залишком 25 днів. Мережа за договором приймає товар лише із залишком щонайменше 18 днів. Отже, у вас є 7 днів, щоб продати партію в мережі. Усе, що не встигне за 7 днів, можна продати лише в традиційну роздрібну торгівлю, а потім — списати. Запас для мереж понад 7 днів продажів — це прямий ризик списання.

Що закласти в систему:

облік партій із датою виробництва й кінцевою датою;
відвантаження за правилом FEFO: першою йде партія, у якої строк закінчується раніше;
окремий поріг залишкового строку для кожної мережі з договору поставки;
сповіщення закупівельнику, якщо партія не вкладається в строк за поточним темпом продажів.

Поправка 2. Промо і сезон рахують окремо

Промо мережі чи виробника різко піднімає продажі на 1–2 тижні, а потім вони падають нижче звичайного: покупці запаслися. Якщо змішати промо-тижні зі звичайними, середнє завищиться, а страховий запас роздується.

Правило: позначайте промо-тижні в історії продажів і рахуйте середнє й коливання лише за звичайними тижнями. Під кожне промо — окрема ручна заявка за планом акції. Те саме із сезоном: морозиво й вода влітку, подарункові набори перед святами — для них точка замовлення перераховується від продажів того ж сезону минулого року, а не від останнього місяця.

Поправка 3. Кратність і мінімальна партія постачальника

Розрахунок може дати 137 коробок, а постачальник відвантажує палетами по 80. Система має округлювати до кратності й показувати наслідок: 160 коробок — це на скільки днів продажів більше, ніж треба. Якщо постачальник має мінімальну суму замовлення, чернетка має добирати до неї позиції, які й так скоро дійдуть до точки замовлення, а не випадкові.

Поправка 4. Резерви і замовлення в дорозі

Точку замовлення порівнюють не з фактичним залишком, а з вільним залишком плюс товар, який уже замовлено й везуть. Без цього система замовляє ту саму позицію двічі: вчора і сьогодні, бо вчорашня поставка ще не прийшла.

Прогноз попиту: що робить ШІ, а що — формули

Що потрібно на вході

Для розрахунку точки замовлення достатньо продажів по позиціях за останні кілька місяців. Для врахування сезону потрібна історія щонайменше за рік. Перш ніж щось автоматизувати, наведіть лад у даних:

приберіть задвоєні артикули: «Кола 0,5» і «Coca-Cola 0.5 л» мають бути однією позицією;
позначте періоди, коли позиції не було на складі, щоб нулі не рахувалися як «не продається»;
позначте промо-тижні;
звірте фізичні залишки з обліковими хоча б по групі A.

Якщо пропустити цей крок, будь-яка модель дасть упевнені, але хибні цифри.

ШІ робить

Читає неструктуровані джерела. Лист постачальника про зміну ціни, промо-календар мережі в PDF, повідомлення ТП «у точці на Сихові відкрили конкурента поруч». ШІ витягує з них факти й ставить позначки в системі.
Пояснює відхилення. Чому прогноз по позиції розійшовся з фактом: промо в сусідній мережі, погода, нова точка. Закупівельник читає пояснення, а не сирі цифри.
Готує чернетку заявки й листа постачальнику. Кількість бере з формули, текст листа пише сам.
Пише короткий звіт. Щоранку в Telegram: які позиції дійшли до точки замовлення, які партії не встигають за строком, у яких клієнтів прострочка.

ШІ не робить

Не рахує кількість і ціну. Це роблять формули, які можна перевірити на прикладах. Модель, що «вгадує» кількість, неможливо налагодити, коли вона помиляється.
Не надсилає заявку постачальнику без підтвердження. Автоматичне відправлення можна ввімкнути пізніше для групи AX, з лімітом суми й переліком постачальників.
Не замінює знання закупівельника. Те, що постачальник через місяць підніме ціну, або що мережа скоротить полицю, система дізнається від людини.

Чернетка заявки постачальнику: що в ній має бути

позиція, кількість після округлення до кратності, причина (дійшли до точки замовлення, промо, сезон);
на скільки днів продажів вистачить залишку без цієї поставки;
на скільки днів вистачить після поставки і чи вкладається це в строк придатності;
остання ціна закупівлі й відхилення від неї в новому прайсі;
кнопки «підтвердити», «змінити», «відкласти».

Закупівельник перевіряє заявку за кілька хвилин замість того, щоб збирати її з нуля. Як побудувати весь процес закупівлі — заявки, вибір постачальника, оплати — розібрано в статті про автоматизацію відділу постачання.

Як це виглядає на ринку

Українська компанія ABM Cloud описує кейс дистриб’ютора автозапчастин AVD Trade, який постачає близько 1500 дилерів. До впровадження замовлення формували вручну в Excel на розсуд менеджерів, і кожен відповідав приблизно за 10 тисяч позицій. Після інтеграції система почала автоматично розраховувати буфери запасів, а продажі в мінус заборонили. Висновок для FMCG той самий: людина фізично не може тримати в голові тисячі позицій, і правило поповнення має рахувати система.

Дебіторка як частина запасу: ліміти, нагадування, блокування

Як встановити кредитний ліміт

Ліміт — це найбільша сума, яку клієнт може бути винен вам одночасно. Найпростіша формула:

Ліміт = середнє відвантаження клієнту за тиждень × (відстрочка в днях ÷ 7) × коефіцієнт запасу.

Приклад (умовні дані). Магазин бере товар раз на тиждень на приблизно однакову суму. Відстрочка — 14 днів. Отже, у нормальному режимі він винен вам дві тижневі закупівлі. Коефіцієнт запасу 1,3 дає ліміт у 2,6 тижневої закупівлі. Якщо борг перевищив цей рівень, клієнт або платить повільніше, ніж домовлялися, або різко збільшив закупівлі. Обидва випадки варті уваги людини.

Ліміт перераховується автоматично раз на місяць. Новому клієнту — передоплата або мінімальний ліміт перші два-три місяці.

Ланцюжок нагадувань

День	Що відбувається	Хто	Як
За 2 дні до терміну	Дружнє нагадування про рахунок	Система	Telegram, Viber або email за погодженим шаблоном
День терміну	Повторне нагадування з номером рахунку	Система	Той самий канал
+3 дні	Задача ТП: з’ясувати причину під час візиту	Система ставить, ТП виконує	Задача в Telegram ТП
+7 днів	Нові відвантаження блокуються, дзвінок керівника продажів	Керівник	Телефон
+14 днів	Акт звірки й офіційний лист	Бухгалтерія, юрист	Email, пошта

Шаблони повідомлень клієнтам погоджуєте ви заздалегідь. Лише тоді система надсилає їх без участі людини. Усе нестандартне — розстрочка, спір щодо поставки, повернення — йде менеджеру.

Ціна забутого нагадування цілком реальна. У нашій компанії з виробництва на верстатах з ЧПК система в перші тижні показала замовлення, яке програли, бо вчасно не нагадали клієнту. Там ішлося про продаж, а не про оплату, але висновок той самий: нагадування має ставити система, а не пам’ять менеджера. Детальніше про скоринг клієнтів і прогноз оплат — у статті про управління дебіторкою в оптовій компанії.

Хто платить вчасно: прості ознаки ризику

Складний скоринг не потрібен на старті. Достатньо чотирьох ознак за останні шість місяців:

середня затримка оплати в днях і чи вона зростає;
кількість прострочень понад тиждень;
частка часткових оплат;
різке зростання замовлень на тлі повільних оплат.

Клієнти з двома й більше ознаками отримують позначку «ризик». ТП бачить її в боті до того, як бере замовлення. Менеджер з дебіторки щодня працює зі списком ризикових клієнтів, а не з усім портфелем.

Блокувати чи попереджати

У системі Saloy ми свідомо зробили «ворота» перед виробництвом м’якими: якщо в замовлення є відкриті питання до клієнта, система попереджає, а не блокує. Для дистриб’ютора з дебіторкою логіка інша, і її варто розділити на два рівні:

Попередження — борг близький до ліміту або є прострочка до тижня. ТП бачить попередження, замовлення проходить.
Блокування — прострочка понад тиждень або перевищення ліміту. Замовлення не йде на склад. Зняти блок може лише власник або фінансовий директор, і кожне зняття записується з причиною.

Головне — щоб правило було явним. Коли ТП відвантажує «під своє слово», ризик ніхто не бачить, доки він не стане безнадійним боргом.

Документи й українська специфіка

Що система формує сама

Після підтвердження замовлення система формує рахунок, видаткову накладну, а за потреби — акт і комерційну пропозицію, з сумою прописом і у PDF. У наших проєктах цей набір документів уже готовий і працює, тому на запуску його лише налаштовують під ваші реквізити й шаблони.

Бухгалтерський облік, податкові накладні й реєстрацію в ЄРПН зазвичай веде бухгалтерія у звичній програмі. Система управління не дублює облік, а передає туди готові дані про відвантаження: без повторного ручного введення.

Мережі, EDI і е-ТТН

Мережі працюють з постачальниками через електронний документообіг. Наприклад, платформа EDIN пропонує обмін електронними документами між торговельними мережами й постачальниками, окремий сервіс для е-ТТН і обмін даними між дистриб’ютором і виробником. Якщо ваші мережі вже на EDI, замовлення від них мають потрапляти в ту саму чергу, що й замовлення ТП, з тими самими резервами. Інакше склад працює з двома незалежними потоками.

Повернення й прострочений товар

Повернення від торгових точок — слабке місце FMCG-дистрибуції. Товар повертається з різних причин: строк закінчується, пошкоджена упаковка, позиція не продалася. Кожне повернення треба фіксувати з причиною й партією. Тоді через місяць видно, які позиції і які клієнти дають найбільше повернень, і це впливає на точку замовлення та на умови роботи з клієнтом.

Готова програма, BAS чи своя система

Порівняння варіантів

Варіант	Що закриває	Коли підходить	Обмеження
Excel і месенджери	Нічого автоматично	Кілька ТП, невеликий асортимент	Немає резерву в реальному часі, усе тримається на людях
SFA-додаток для ТП (наприклад, SalesWorks від SoftServe Business Systems)	Замовлення з телефона в точці, оплати, анкети, збір даних про полицю	Великі дистриб’ютори й виробники з багатьма ТП	Окреме впровадження, інтеграція з обліком, логіка продукту замість вашої
Оптимізатор запасів (наприклад, ABM Inventory)	Розрахунок буферів і заявок по кожній позиції	Тисячі позицій, кілька складів	Не закриває прийом замовлень і дебіторку
BAS із доробками	Облік, документи, податкові	Облік уже в BAS, є свій програміст	Мобільний інтерфейс для ТП і зручні сповіщення — окремі доробки
Зв’язка n8n або Make	Швидко з’єднати бота, пошту й облік	Один-два прості сценарії	Багато сценаріїв без єдиної логіки важко підтримувати
Своя ШІ-система управління	Бот ТП, резерв, ліміти, нагадування, чернетки заявок, звіти	Специфічний процес, Telegram як основний інтерфейс	Потрібно описати процес і мати відповідальну людину

Коли краще готова програма

Чесно: якщо виробник-принципал вимагає працювати в його системі дистрибуції, не будуйте паралельну. Доробіть те, чого в ній бракує: нагадування, звіти, розбір замовлень із месенджерів. Так само, якщо у вас тисячі позицій на кількох складах і головна проблема — саме закупівля, спеціалізований оптимізатор запасів дасть результат швидше.

Готова програма також краща, коли ваш процес стандартний і ви готові підлаштуватися під логіку продукту. Пройдіть тест «готова CRM чи своя система» — він займає 15 хвилин і показує, що вам ближче.

Коли варто своя система

ТП і менеджери вже живуть у Telegram, і ви не хочете ще один застосунок;
правила резерву, лімітів і пріоритетів у вас свої і не вкладаються в налаштування готового продукту;
облік лишається в BAS, а бракує саме оперативного шару: замовлення, резерви, борги, задачі;
ви не хочете платити за кожного користувача і хочете, щоб код і дані належали вам.

Ширше про те, які процеси компанії автоматизувати першими і якими програмами, — у матеріалі про автоматизацію бізнес процесів.

BAS як джерело правди

Найчастіше облік у дистриб’ютора вже в BAS, і переносити його нікуди не треба. Система управління звертається до бази через HTTP-сервіси: читає залишки, ціни й борги, записує підтверджені замовлення. BAS лишається джерелом правди для бухгалтерії, а ТП і менеджери працюють у зручному інтерфейсі.

Що узгодити з вашим програмістом BAS на старті: які дані віддаються і як часто, хто створює документ реалізації, що відбувається, якщо BAS недоступний. Останнє важливо: бот має приймати замовлення й тоді, просто з позначкою «не перевірено», і довантажити їх, коли зв’язок відновиться.

Як запустити за 4 тижні

Тиждень 1. Опис процесу і цифри «до»

Перший тиждень — не розробка, а опис. Ми проходимо з вами шлях замовлення від ТП до оплати і фіксуємо цифри, з якими потім порівнюватимемо:

скільки замовлень на день і за який час вони потрапляють в облік;
скільки разів за тиждень клієнт отримав неповне замовлення;
надлишок і прострочену дебіторку за розрахунком із першого розділу;
скільки часу менеджери витрачають на перенесення замовлень і нагадування.

Опис процесу займає тиждень і має фіксовану ціну, яка зараховується в запуск.

Тиждень 2. Перша версія: бот для 3–5 ТП

Перша робоча версія готова за кілька днів. Для системи Saloy вона була готова за один день: картки замовлень і клієнтів, канбан, дашборд, вхід через Telegram. Для дистриб’ютора перша версія — це бот прийому замовлень із каталогом, залишком і боргом клієнта для 3–5 ТП, які погодилися тестувати.

Стара схема працює паралельно: ТП дублює замовлення звичним способом. Так пілот нічого не ламає, а розбіжності між двома потоками одразу показують помилки.

Тиждень 3. Резерв, ліміти, нагадування

Додаємо резерв під замовлення, перевірку ліміту з попередженням і блокуванням, ланцюжок нагадувань за погодженими шаблонами. Розбір замовлень із Viber і пошти — для клієнтів, які пишуть туди.

Тиждень 4. Поповнення складу і рішення про масштаб

Додаємо ABC/XYZ і чернетки заявок постачальникам для групи A. Порівнюємо цифри з першим тижнем. Якщо результат є — підключаємо всіх ТП. Два тижні система працює паралельно зі старим способом, потім старий вимикається.

Що ми перевірили на власних проєктах

Ми не маємо готового кейсу FMCG-дистриб’ютора, і не будемо його вигадувати. Але механіки, з яких складається така система, працюють у наших проєктах:

Telegram як основний інтерфейс. У системі Saloy майстер запускає таймер командою в боті, а ШІ-асистент у призначений день пише клієнту, розбирає відповідь і записує її в картку. Якщо відповідь неясна — перепитує.
Перенесення розрахунків з Excel зі звіркою. Для виробника металоконструкцій ми перенесли розрахунок із книги на 104 аркуші й звірили з Excel на контрольних прикладах — збіглося до копійки. А в самому Excel знайшли помилки, які передали інженеру, а не виправили мовчки. Ваші таблиці замовлень постачальнику майже напевно теж містять такі місця.
Бекапи з першого дня. Одного разу оновлення зі старої копії затерло свіжий модуль, і ми відновлювали його вручну. Тепер контроль версій і щоденна резервна копія — обов’язкові.

Як це виглядало від першого дня до повної системи — у кейсі власної системи управління бізнесом.

Типові помилки і як їх уникнути

Почати з прогнозу, коли замовлення ще в хаосі

Прогноз будується на даних із замовлень. Якщо замовлення вносять увечері з помилками, прогноз буде помилятися впевнено. Послідовність така: прийом замовлень і резерв, потім дебіторка, потім поповнення складу.

Рахувати середнє разом із промо і дефіцитом

Промо-тижні завищують середнє, а тижні дефіциту — занижують. Обидва спотворюють точку замовлення. Позначайте такі тижні й виключайте їх із базового розрахунку.

Будувати бота без ТП

Бот, зроблений без реальних торгових представників, вимагає переробок після запуску. ТП знають, скільки секунд у них є біля полиці і що треба бачити першим. Візьміть двох-трьох ТП у тестування з першого дня.

Залишити обхід ліміту «за домовленістю»

Якщо блок можна зняти дзвінком знайомому менеджеру, його знімуть. Зняття блоку — лише з причиною і з записом, хто зняв.

Ігнорувати строк придатності в розрахунку

Точка замовлення без обмеження за строком у FMCG дає списання. Для швидкопсувних груп максимум рахується від строку, а не від місткості складу.

Не перераховувати правила

Групи ABC/XYZ, ліміти клієнтів і точки замовлення застарівають. Перерахунок раз на місяць має бути автоматичним, із коротким звітом, що змінилося.

Коли автоматизація запасів не окупиться

Дуже малий масштаб. Один-два ТП, кілька десятків позицій, власник сам бачить усі замовлення. Добре зроблена таблиця дасть більше. Як її побудувати — у статті про облік складу в ексель.
Немає людини, яка відповідає за процес. Система показує проблему, але рішення ухвалює людина. Якщо ніхто не реагує на сповіщення про прострочку, нагадування нічого не змінять.
Облікові залишки не збігаються з фізичними. Спершу інвентаризація по групі A, потім автоматизація. Інакше резерви будуються на неіснуючому товарі.
Процес змінюється щотижня. Якщо ви ще шукаєте модель дистрибуції — канали, територію, асортимент, — автоматизуйте лише прийом замовлень, а правила поповнення залиште на потім.

Часті питання

Чи можна вести управління складськими запасами в Excel? Можна, поки замовлення приймає одна-дві людини і позицій небагато. Межа настає, коли кілька ТП одночасно резервують той самий товар: Excel не показує вільний залишок у реальному часі.

Чи потрібна WMS-система для дистриб’ютора FMCG? WMS керує фізичними операціями на складі: адреси комірок, маршрути збирання, сканування. Вона потрібна великому складу з багатьма комірниками. Більшості дистриб’юторів середнього розміру спершу бракує не WMS, а прийому замовлень із резервом, лімітів і правил поповнення.

Що робити з клієнтами, які не хочуть переходити на бот? Нічого не змінювати для них. ШІ розбирає їхні повідомлення у Viber, WhatsApp чи на пошті, а менеджер лише підтверджує чернетку. Бот — інструмент для ТП, а не вимога до клієнтів.

Скільки часу займає запуск? Тиждень на опис процесу, перша версія — за кілька днів після нього, уся система — 2–4 тижні. Два тижні нова система працює паралельно зі старою схемою.

Кому належать дані і код? Вам. Систему ставимо на ваш сервер або на наш із передачею будь-коли. Щоденна резервна копія. За кожного користувача окремо платити не треба.

Чи замінить ШІ менеджера з дебіторки чи закупівельника? Ні. ШІ бере на себе рутину: нагадування, чернетки заявок, звіти, розбір повідомлень. Рішення про розстрочку, спірну поставку чи велику закупівлю ухвалює людина — але тепер вона працює зі списком проблем, а не з усім портфелем.

Якщо ви дистриб’ютор і замовлення ТП досі доходять до складу через месенджери й вечірнє перенесення, опишіть, як у вас зараз іде одне замовлення від торгової точки до оплати. Покажемо робочу систему на демо за 30 хвилин і чесно скажемо, що вам вигідніше: готова програма, доробка BAS чи своя система. Детальніше — ШІ-система управління бізнесом.