Пример условный. У дистрибьютора один склад и двое ворот разгрузки. Поставщики пишут менеджеру в почту и мессенджер: «приедем в четверг к десяти». Менеджер отмечает это в общей таблице и отвечает «хорошо». Два поставщика просят одно и то же утро, и каждая просьба по отдельности выглядит нормально: ворота свободны, в таблице пусто. В четверг к воротам приезжают две машины, а погрузчик в это время занят третьей.
Что здесь пошло не так? Запрос поставщика превратился в подтверждение без проверки мощности. А в таблице не было разницы между «поставщик хочет приехать» и «склад его ждёт».
Пять состояний поставки
Прежде чем что-то автоматизировать, договоритесь о состояниях и о том, что переводит поставку из одного в другое.
- Запрошено. Поставщик предложил поставку и удобное время. Ничего ещё не зарезервировано.
- Удержано. Мощность склада временно зарезервирована под эту поставку, и у брони есть понятный срок истечения.
- Подтверждено. Согласованные проверки пройдены, и у обеих сторон есть номер брони.
- Прибыло. Машина на территории склада.
- Принято. Записан фактический результат приёмки.
Два правила следуют из этого сразу. Нельзя отмечать поставку принятой только потому, что её время подтвердили: подтверждённая бронь говорит о намерении, а приёмка — о факте. И нельзя обещать одну и ту же мощность двум запросам только потому, что каждый выглядел приемлемым, когда его проверяли отдельно.
Временная бронь с понятным сроком
Удержание нужно, чтобы склад мог придержать окно, пока идёт согласование: поставщик уточняет состав, менеджер проверяет технику. Но у удержания обязательно должен быть срок. Иначе бронь, о которой все забыли, неделями занимает ворота, и новые запросы получают отказ без причины.
Когда срок истекает, мощность освобождается, а поставщик получает сообщение, что окно больше не держится. Продлить удержание может только человек или правило, о котором договорились заранее.
Одна мощность — одной заявке
Самое частое место ошибки — проверка свободного окна. Если два запроса проверяются по отдельности, оба увидят свободные ворота. Поэтому окончательную проверку делает система, в которой хранятся брони, в момент подтверждения и по текущему состоянию всех броней, а не по сводке, подготовленной заранее.
Мощность — это не только ворота. Складу может понадобиться определённая техника, например погрузчик или рокла, и бригада, у которой есть время на эту поставку. Какие именно ограничения проверять, решает склад. Важно, чтобы их проверяла система, а не память менеджера.
Конфликт — ответственному, с вариантами
Если мощности не хватает, запрос уходит конкретному ответственному за операции склада. Ему нужно видеть три вещи:
- какую поставку просят и когда;
- какое ограничение мешает: занятые ворота, нет техники, нет людей;
- какие варианты он может одобрить: другое время, другие ворота, разделение поставки.
AI-ассистент здесь полезен как помощник: он может прочитать письмо поставщика, вытащить из него желаемое время и состав поставки, собрать сводку и предложить варианты. Но подтверждает бронь не ассистент. Правила бронирования соблюдает учётная система, а решение по конфликту принимает человек.
Изменения тоже нужно предусмотреть
Поставщик опаздывает, бронь истекает, погрузчик уходит в ремонт. У каждого такого изменения должен быть путь восстановления: бронь обновляется, а все, кого это касается, получают сообщение. Поставщик узнаёт, что окно сдвинулось, бригада на складе — что машина приедет позже.
Храните историю: кто и когда изменил обязательство и почему. Через месяц на вопрос «почему эту поставку перенесли» должно быть можно ответить по записи, а не по переписке. Та же идея — не терять состояние при сбоях связи между системами — подробно разобрана в статье о тайм-аутах при передаче заказа в ERP.
«Принято» — это факт, а не ожидание
Машина приехала — это ещё не приёмка. Принятым поставка становится, когда записан фактический результат: что и в каком количестве приняли. Если приняли не всё, это отдельный случай, и он должен быть виден как частичная приёмка, а не как обычная.
Что проверить до запуска
Перед запуском прогоните на тестовом стенде четыре сценария:
- два конкурирующих запроса на одно окно;
- опоздание поставщика;
- отменённый слот;
- частичную приёмку.
И отдельно проверьте, что экран, на котором работает склад, и сообщения, которые получают поставщики, описывают одно и то же состояние. Если на экране «удержано», а поставщику ушло «подтверждено», автоматизация создаёт ту же путаницу, что и таблица, только быстрее.
Чек-лист
- Состояния «запрошено, удержано, подтверждено, прибыло, принято» описаны, и известно, что переводит поставку из одного в другое.
- У удержания есть срок, и по его истечении мощность освобождается, а поставщик получает сообщение.
- Окончательная проверка мощности делается в системе броней в момент подтверждения, по текущему состоянию.
- Известно, какие ограничения проверяются: ворота, техника, бригада.
- Конфликты уходят названному ответственному вместе с поставкой, ограничением и вариантами.
- AI-ассистент готовит сводку и варианты, но не подтверждает бронь.
- При опоздании, истечении брони или недоступности техники бронь обновляется, и все затронутые получают сообщение.
- Хранится история: кто, когда и почему изменил обязательство.
- Поставка становится принятой только после записи фактического результата, частичная приёмка видна отдельно.
- На тестовом стенде проверены конкурирующие запросы, опоздание, отмена и частичная приёмка, а экран склада и сообщения поставщикам совпадают.
С чего начать
Разумный первый шаг — один процесс приёмки на одном складе, с согласованными правилами и ответственным, который отвечает за конфликты. Опишите, где сейчас подтверждаются поставки, какие ограничения у склада и кто решает, если запросы пересекаются. Это описание предлагаемой автоматизации, а не готового модуля планирования склада.
Если вам нужно связать заказы, склад и доставку, посмотрите сценарий «Заказ → отправление» на странице автоматизации процессов. А если хотите начать с приёмки, расскажите нам в Telegram (@infracortex_studio), где ваша команда сейчас подтверждает поставки: в таблице, почте или мессенджере.