Приклад умовний. Дистриб’ютор має один склад і двоє воріт розвантаження. Постачальники пишуть менеджерові на пошту й у месенджер: «приїдемо в четвер на десяту». Менеджер позначає це в спільній таблиці й відповідає «добре». Двоє постачальників просять той самий ранок, і кожне прохання окремо виглядає нормально: ворота вільні, у таблиці порожньо. У четвер до воріт приїжджають дві машини, а навантажувач у цей час зайнятий третьою.
Що тут пішло не так? Запит постачальника перетворився на підтвердження без перевірки потужності. А в таблиці не було різниці між «постачальник хоче приїхати» і «склад на нього чекає».
П’ять станів поставки
Перш ніж щось автоматизувати, домовтеся про стани й про те, що переводить поставку з одного в інший.
- Запитано. Постачальник запропонував поставку й зручний час. Нічого ще не зарезервовано.
- Утримано. Потужність складу тимчасово зарезервовано під цю поставку, і бронь має зрозумілий строк спливання.
- Підтверджено. Погоджені перевірки пройдено, і обидві сторони мають номер броні.
- Прибуло. Машина на території складу.
- Прийнято. Записано фактичний результат приймання.
Із цього одразу випливають два правила. Не можна позначати поставку прийнятою лише тому, що її час підтвердили: підтверджена бронь говорить про намір, а приймання — про факт. І не можна обіцяти ту саму потужність двом запитам лише тому, що кожен виглядав прийнятним, коли його перевіряли окремо.
Тимчасова бронь зі зрозумілим строком
Утримання потрібне, щоб склад міг притримати вікно, поки триває погодження: постачальник уточнює склад поставки, менеджер перевіряє техніку. Але утримання обов’язково повинно мати строк. Інакше бронь, про яку всі забули, тижнями займає ворота, і нові запити отримують відмову без причини.
Коли строк спливає, потужність звільняється, а постачальник отримує повідомлення, що вікно більше не утримується. Подовжити утримання може лише людина або правило, про яке домовилися заздалегідь.
Одна потужність — одній заявці
Найчастіше помилка трапляється під час перевірки вільного вікна. Якщо два запити перевіряють окремо, обидва побачать вільні ворота. Тому остаточну перевірку робить система, у якій зберігаються броні, у момент підтвердження й за поточним станом усіх броней, а не за зведенням, підготовленим заздалегідь.
Потужність — це не лише ворота. Складу може знадобитися певна техніка, наприклад навантажувач чи рокла, і бригада, яка має час на цю поставку. Які саме обмеження перевіряти, вирішує склад. Важливо, щоб їх перевіряла система, а не пам’ять менеджера.
Конфлікт — відповідальному, з варіантами
Якщо потужності бракує, запит іде до конкретного відповідального за операції складу. Йому треба бачити три речі:
- яку поставку просять і коли;
- яке обмеження заважає: зайняті ворота, немає техніки, немає людей;
- які варіанти він може схвалити: інший час, інші ворота, поділ поставки.
AI-асистент тут корисний як помічник: він може прочитати лист постачальника, витягти з нього бажаний час і склад поставки, зібрати зведення й запропонувати варіанти. Але бронь підтверджує не асистент. Правил бронювання дотримується облікова система, а рішення щодо конфлікту ухвалює людина.
Зміни теж треба передбачити
Постачальник запізнюється, бронь спливає, навантажувач іде в ремонт. Кожна така зміна повинна мати шлях відновлення: бронь оновлюється, а всі, кого це стосується, отримують повідомлення. Постачальник дізнається, що вікно зсунулося, бригада на складі — що машина приїде пізніше.
Зберігайте історію: хто й коли змінив зобов’язання і чому. За місяць на запитання «чому цю поставку перенесли» має бути змога відповісти за записом, а не за листуванням. Ту саму ідею — не втрачати стан під час збоїв зв’язку між системами — докладно розібрано у статті про тайм-аути під час передачі замовлення в ERP.
«Прийнято» — це факт, а не очікування
Машина приїхала — це ще не приймання. Прийнятою поставка стає, коли записано фактичний результат: що й у якій кількості прийняли. Якщо прийняли не все, це окремий випадок, і його має бути видно як часткове приймання, а не як звичайне.
Що перевірити до запуску
Перед запуском проженіть на тестовому стенді чотири сценарії:
- два конкурентні запити на одне вікно;
- запізнення постачальника;
- скасований слот;
- часткове приймання.
І окремо перевірте, що екран, на якому працює склад, і повідомлення, які отримують постачальники, описують той самий стан. Якщо на екрані «утримано», а постачальникові пішло «підтверджено», автоматизація створює ту саму плутанину, що й таблиця, лише швидше.
Чек-лист
- Стани «запитано, утримано, підтверджено, прибуло, прийнято» описано, і відомо, що переводить поставку з одного в інший.
- Утримання має строк, і коли він спливає, потужність звільняється, а постачальник отримує повідомлення.
- Остаточну перевірку потужності роблять у системі броней у момент підтвердження, за поточним станом.
- Відомо, які обмеження перевіряють: ворота, техніку, бригаду.
- Конфлікти йдуть до названого відповідального разом із поставкою, обмеженням і варіантами.
- AI-асистент готує зведення й варіанти, але не підтверджує бронь.
- Коли постачальник запізнюється, бронь спливає чи техніка недоступна, бронь оновлюють, і всі зачеплені отримують повідомлення.
- Зберігається історія: хто, коли й чому змінив зобов’язання.
- Поставка стає прийнятою лише після запису фактичного результату, часткове приймання видно окремо.
- На тестовому стенді перевірено конкурентні запити, запізнення, скасування й часткове приймання, а екран складу й повідомлення постачальникам збігаються.
З чого почати
Розумний перший крок — один процес приймання на одному складі, з погодженими правилами й відповідальним, який відповідає за конфлікти. Опишіть, де зараз підтверджують поставки, які обмеження має склад і хто вирішує, якщо запити перетинаються. Це опис запропонованої автоматизації, а не готового модуля планування складу.
Якщо вам потрібно пов’язати замовлення, склад і доставку, подивіться сценарій «Замовлення → відправлення» на сторінці автоматизації процесів. А якщо хочете почати з приймання, розкажіть нам у Telegram (@infracortex_studio), де ваша команда зараз підтверджує поставки: у таблиці, пошті чи месенджері.