Как договориться о единых статусах заказа между продажами, складом и бухгалтерией?

Чтобы статусы заказа работали, продажам, складу и бухгалтерии нужно договориться не о красивых названиях, а о событиях. Каждый статус должен отвечать на один вопрос: что уже произошло, кто это подтвердил и какое действие теперь можно или нельзя делать.

Если продажа видит «в работе», склад — «не передан», а бухгалтерия — «нет документа», дело не в том, что кто-то выбрал плохую систему. У разных людей нет общей картины одной операции.

Начните с реального заказа, а не со списка полей

Возьмите один недавний заказ и пройдите его путь вслух. Когда менеджер пообещал срок? В какой момент склад увидел задачу? Что бухгалтерия считает основанием для счёта? Кто сообщает об отмене? Обычно уже на этом разговоре обнаруживается несколько разных значений слова «готов».

Полезно описывать не экран системы, а событие. Не «статус поменяли на отгрузку», а «склад подтвердил наличие и взял заказ в сборку». Событие можно проверить. Название на кнопке потом легко поменять, а непонятное действие останется непонятным в любой программе.

У статуса должен быть один смысл

Хороший статус не пытается одновременно сказать всё. «Согласован» — это согласована цена, оплата, наличие или дата? Если ответ зависит от того, кто смотрит, статус надо разделить либо добавить явный признак.

Например, простая цепочка может выглядеть так: черновик → подтверждён клиентом → передан на склад → собран → отгружен → закрыт. Рядом иногда нужны отдельные признаки оплаты и документов. Они не обязаны повторять движение товара. Главное — не прятать несколько независимых фактов в один общий цветной ярлык.

Назначьте владельца каждого перехода

Статус меняется не потому, что человеку так удобнее, а потому что произошло подтверждённое действие. У передачи на склад владельцем может быть менеджер, у сборки — кладовщик, у закрытия периода — бухгалтерия. У каждого перехода полезно зафиксировать входные условия и то, кого система должна уведомить.

Это защищает от распространённой ситуации: менеджер ставит «отгружен», чтобы клиенту было спокойнее, а склад ещё не начал сборку. В моменте всем проще. Потом руководитель не понимает, почему отчёт показывает одно, а реальность — другое.

Не забудьте про отмену и возврат

Почти любая аккуратная схема выглядит красиво, пока заказ идёт по плану. Поэтому сразу разберите два неудобных случая: клиент изменил заказ после передачи на склад и товар вернулся после отгрузки. Кто может остановить движение? Что происходит с резервом? Кто узнаёт об изменении? Какая запись остаётся для истории?

Необязательно автоматизировать все исключения сразу. Но ручной порядок должен быть явным. Иначе люди будут обходить систему сообщениями, а статусы постепенно потеряют доверие.

Свяжите статусы с решениями, а не с отчётностью

У каждого состояния спросите: кто должен что-то сделать, увидев его? Если ответ «никто», возможно, статус лишний. Если два отдела должны действовать по-разному, им может понадобиться не ещё один общий статус, а свои понятные сигналы.

Передача заказа из продаж в исполнение — это как раз место, где легко потерять деталь: комментарий, срок, способ оплаты, особое условие. Полезный порядок этого перехода я описывал в материале о передаче заказа между отделами.

Проверьте схему на живых сценариях

• Обычный заказ без исключений.
• Частичная оплата или изменение количества.
• Отмена после передачи на склад.
• Повторная отправка данных между системами.

На каждом шаге посмотрите, что видит сотрудник, какое действие ему доступно и что увидит следующий отдел. Если вы не можете проследить одну операцию целиком, статусы ещё не стали общей системой координат. Этот принцип особенно важен для интеграций: данные могут прийти дважды или с задержкой, но смысл заказа не должен раздвоиться. Подробнее — в статье о проверке одной операции в интеграции.

Короткий чек-лист

1. Каждый статус описывает одно проверяемое событие.
2. У перехода есть владелец и понятное условие.
3. Оплата, товар и документы не смешаны в одном неопределённом статусе.
4. Отмена и возврат не живут только в личных сообщениях.
5. Схема проверена на реальном заказе от создания до закрытия.

Связанные вопросы

Что делать, если система уже полна старых статусов? Как показать клиенту этап заказа, не раскрывая внутреннюю кухню? Нужен ли отдельный статус для частичной отгрузки? Как исправлять неверный переход, не стирая историю? Ответы зависят от процесса, но начинать всегда стоит с одинакового смысла событий.

Единые статусы не делают работу медленнее. Они убирают лишние уточнения и позволяют отделам доверять одной картине заказа. А это и есть основа автоматизации, которая помогает, а не добавляет ещё один экран.