Менеджер создаёт заявку на отгрузку.

Клиент указан, товар указан, количество вроде тоже есть. Даже комментарий добавлен - видно, человек старался, не просто кинул пустую карточку в систему.

А потом комплектовщик открывает заявку и видит, что товар указан общим названием, без артикула. Адрес доставки есть, но без уточнения склада. В комментарии написано «срочно», но не написано, к какому времени. Контрагент указан, а отгрузочные реквизиты подтянулись старые, потому что в прошлый раз отгружали на другое юрлицо.

И начинается не отгрузка. Начинается уточнение заявки.

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

А система показывает заявку в работе. Шикарная формулировка для ситуации, где работа ещё не началась.

Пока люди не уточнят исходные данные, бизнес-процесс не выполняет отгрузку. Он собирает вход, который должен был быть собран до старта.

Плохой вход редко выглядит как пустая заявка. С пустой заявкой всё понятно: её сразу вернут.

Гораздо чаще он выглядит как заполненная заявка, по которой всё равно нельзя работать без уточнений.

И дальше у компании появляется знакомый вид деятельности: восстановление смысла по косвенным признакам.

Чат, звонок, старый заказ, скрин от клиента, письмо «вот это имели в виду».

Архивная работа, только без архива.

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

Проблема в том, что вход в процесс не был собран в пригодном виде.

Если первый исполнитель регулярно собирает недостающие данные, стоит проверить предыдущий шаг процесса.

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

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

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

Если склад не может собрать заказ без артикула, значит артикул должен быть не пожеланием, а обязательным полем. Документы зависят от юрлица - значит реквизиты не должны жить в комментарии. Если срочность меняет маршрут, у неё должно быть основание, а не просто слово «срочно».

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

Иначе компания получает не процесс, а эстафету уточнений. Один недозаполнил. Другой переспросил. Третий нашёл старый чат. Четвёртый всё равно отгрузил не туда.

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

Ещё больше обо мне | sergey-suslov.ru