Заявка и заказ - не одно и то же
Входящую заявку ещё предстоит разобрать: что нужно клиенту и может ли компания это предложить. Для схемы ниже заказ - оформленный запрос на конкретные товары или услуги, который компания приняла в обработку; условия исполнения подтверждают на следующем этапе. Это рабочая граница процесса, а не определение момента возникновения договорных обязательств. Она нужна в том числе для измерений: скорость ответа на лид не показывает, сколько заказ ждёт комплектации, оплаты или отгрузки
Опишите заказ как набор состояний
- Принят в обработку
- Проверен
- Подтверждён
- Оплачен
- В работе
- Выполнен
- Закрыт
Это пример маршрута с предоплатой, а не обязательная последовательность для любого бизнеса. При отсрочке оплаты или частичных поставках состояния оплаты и исполнения придётся учитывать отдельно. Для каждого состояния задайте критерий входа, обязательные данные, владельца следующего действия и условие перехода
| Состояние | Что должно быть известно | Что запускает следующий шаг |
|---|---|---|
| Принят в обработку | Клиент, состав заказа, канал, время | Автоматическая проверка полноты |
| Проверен | Цена, наличие, ограничения, реквизиты | Подтверждение условий |
| Подтверждён | Срок, сумма, способ выполнения | Оплата или разрешение на производство |
| Оплачен | Подтверждённый платёж и его связь с заказом | Разрешение на выполнение по согласованным условиям |
| В работе | Ответственный, срок, ресурсы | Фактическое завершение операции |
| Выполнен | Факт поставки или оказания услуги | Документы, сверка, закрытие |
| Закрыт | Исполнение и расчёты сверены, необходимые документы получены | Завершение стандартного маршрута; возврат или спор открывается отдельно |
Таблицу можно прокрутить вбок →
Данные заказа должны вводиться один раз
Когда клиент сообщает адрес менеджеру, менеджер переносит его в таблицу, а оператор перепечатывает в учётную систему, компания тратит время на одну и ту же запись. Заодно появляются дополнительные возможности перепутать данные или использовать старую версию
Факт записывают в системе-источнике и передают дальше автоматически с устойчивым идентификатором заказа. Изменения связывают с тем же заказом, сохраняя историю версий, вместо создания «почти такого же заказа». Повторная доставка сообщения не должна повторно создавать документ или запускать операцию: это проверяется отдельно, одного идентификатора недостаточно
Архитектура передачи факта из системы-источника, повторная доставка сообщений и защита от дублей подробнее разобраны в материале «Как автоматизировать обработку данных между системами».
Продумайте, что будет при исключениях
Линейный маршрут удобен, пока всё идёт по плану. Но товар может закончиться, платёж - задержаться, клиент - поменять адрес или отменить часть заказа. Для каждого такого случая нужны реакция системы, ответственный и понятное продолжение работы. Иначе сотрудникам всё равно придётся разбираться в чате, только теперь ещё и исправлять статусы
| Исключение | Автоматическая реакция | Человек нужен когда |
|---|---|---|
| Нет наличия | Проверить альтернативу и срок пополнения | Нужно согласовать замену или новый срок |
| Не прошла оплата | Проверить статус уже отправленного платежа и уведомить ответственного; не инициировать повторное списание автоматически | Есть спор, частичная оплата или особые условия |
| Изменён заказ | Пересчитать сумму, срок и зависимые операции | Изменение влияет на обещанные клиенту условия |
| Ошибка данных | Заблокировать переход и запросить обязательное поле | Невозможно однозначно восстановить правильное значение |
Таблицу можно прокрутить вбок →
Четыре метрики для проверки процесса
APQC используем здесь только для определения границ времени цикла: в их определениях полный цикл включает и работу, и ожидание, но границы метрик различаются. Одна метрика считает календарные дни от размещения заказа клиентом до доставки, другая — часы от получения заказа до завершения его подготовки. Смешивать их нельзя. [1][2] Для практического контроля заказа в этой статье добавляем четыре авторских показателя ниже: полный цикл, долю ожидания, прохождение с первого раза и исключения.
Полный цикл. Время от принятия заказа в обработку до выбранного окончания процесса: например, доставки или закрытия. При сравнении граница должна оставаться той же
Доля ожидания. Часть полного цикла, в течение которой по заказу не выполняется ни одна операция. Не путайте её с суммой простоев всех участников
С первого раза. Доля заказов, завершённых без исправления ошибки, возврата на доработку или повторного согласования по вине процесса. Плановое изменение условий учитывайте отдельно
Исключения. Доля заказов, вышедших из стандартного маршрута. Разделяйте штатные особые условия и сбои: исключение не обязательно означает ошибку
В формуле нужны одинаковые единицы времени и полный цикл больше нуля. Для параллельных операций время активной обработки - длительность объединённых интервалов, когда выполнялась хотя бы одна операция, а не сумма человеко-часов. По такому расчёту видно, где стоит искать причину задержки: в нехватке исполнителей, очереди на согласование или разрыве между системами
Карта состояния заказа
Минимальная таблица для аудита
Строки - состояния заказа. Колонки - критерий входа, обязательные данные, владелец, автоматическое действие, допустимое время, исключение, маршрут ошибки и критерий выхода
Заполняйте карту по реальным переходам и журналам, включая возвраты. Она поможет найти места, где связь между системами всё ещё обеспечивает сотрудник вручную
Как внедрять без остановки продаж
- Возьмите один тип заказа с достаточным объёмом
- Зафиксируйте состояния, фактическое время между ними и исходные показатели качества
- Уберите повторный ввод данных
- Автоматизируйте стандартный маршрут
- Опишите три-пять наиболее частых исключений и дополните список редкими случаями с неприемлемыми последствиями
- Запустите на ограниченной группе заказов с возможностью остановить сценарий и продолжить обработку вручную
- Сравните цикл, переделки и исключения для сопоставимых заказов; укажите состав выборки и период. Незавершённые заказы учитывайте отдельно, чтобы они не исчезли из проверки
Источники и границы выводов
Источники относятся к указанным рядом с ними утверждениям. Таблицы, чек-листы и расчёты в статье - авторские рабочие инструменты, а не результаты клиентских внедрений
- APQC: Customer order cycle time in days - среднее календарное время от размещения заказа до доставки; определение включает выходные. Это конкретные границы метрики, а не обязательный срок для вашей компании
- APQC: время от получения заказа до завершения подготовки - отдельная метрика подготовки заказа в часах. Время цикла включает работу и ожидание; она не равна полному пути до доставки
