В процессе обработки заявок аналитик измеряет только время работы сотрудников, игнорируя ожидание между этапами. Какой показатель он занижает?
Он занижает полное время прохождения заявки, или lead time: период от поступления заявки до её завершения. Время непосредственной работы сотрудников — это только processing time; ожидание в очередях, передачи между ролями и согласования также входят в путь заявки.
Разделение времени обработки и времени ожидания появилось из практики управления операциями и совершенствования процессов. Оно решает исходную проблему неверной диагностики: организация могла считать процесс быстрым, потому что сотрудники мало работали с каждой заявкой, хотя клиент ждал результата несколько дней.
Такое различие особенно важно для процессов с очередями, ручными согласованиями и передачей работы между подразделениями. Оно позволяет отделить трудоёмкость операции от задержек, возникающих из-за организации процесса.
Если аналитик учитывает только активную работу, он может заключить, что процесс эффективен, хотя заявка большую часть времени находится без движения. На основе такого измерения бизнес способен автоматизировать уже быстрый этап и не устранить реальную причину задержек — очереди, неполные входные данные или ожидание решения.
Например, сотрудник тратит на заявку 20 минут, но заявка ожидает назначения два дня, проверки — ещё день, а согласования — сутки. Processing time равен 20 минутам, но lead time составляет несколько дней. Для клиента обычно значим именно полный срок получения результата.
Lead time измеряют от события, означающего поступление заявки в процесс, до события, означающего получение результата. В него включают активную работу, ожидание, простои, очереди, передачи между участниками и согласования.
Processing time — сумма интервалов, когда участник действительно выполняет работу по заявке. Разница между lead time и processing time показывает совокупное время ожидания, хотя для точного анализа его полезно дополнительно разделить на очереди, внешние зависимости, ожидание данных и организационные задержки.
Аналитику следует заранее зафиксировать границы измерения: какие события считаются началом и концом, учитываются ли возвраты, паузы по инициативе клиента и календарные нерабочие дни. Иначе одинаково названный показатель будет рассчитываться разными способами.
Нельзя считать, что сокращение processing time автоматически сократит lead time. Если заявки поступают быстрее, чем их успевают брать в работу, небольшое ускорение операции может даже увеличить очередь из-за роста пропускного потока. Поэтому оценку решения нужно связывать с целевым результатом процесса: сроком выполнения, долей соблюдения SLA, стоимостью и качеством.
В службе закупок заявка обрабатывалась сотрудником в среднем 25 минут, поэтому предлагалось автоматизировать заполнение формы. Однако анализ событий показал: 80 процентов календарного времени заявка ожидала проверки бюджета и подписи руководителя.
Рассматривались три варианта. Автоматизация формы уменьшала processing time, но почти не влияла на очереди. Увеличение штата согласующих могло сократить ожидание, но повышало постоянные расходы. Настройка маршрутизации по лимитам и автоматическое согласование типовых заявок снижали задержки, но требовали чётких правил и контроля исключений.
Выбрали третий вариант, сохранив ручную проверку для нестандартных закупок. Решение было обосновано тем, что основной резерв находился в ожидании, а не в активной работе. Результат оценивали по lead time, доле заявок, выполненных в срок, и числу ошибочных автоматических согласований, а не только по минутам работы сотрудника.
В разных организациях термин cycle time используют неодинаково: иногда для полного времени прохождения единицы работы, а иногда только для времени активной обработки. Поэтому аналитик не должен полагаться на название показателя; он обязан описать его начало, конец и включаемые интервалы. В документации лучше явно указать формулу и события, например: «от регистрации заявки до закрытия, включая ожидание и нерабочие периоды».
Возврат не следует автоматически исключать из измерения. Если клиент всё это время ждёт результата, интервал должен оставаться в lead time; отдельно стоит отметить причину возврата и число повторных циклов. Для анализа причин можно дополнительно рассчитывать время первого прохождения, суммарное время обработки и долю заявок с возвратами, но эти показатели нельзя смешивать.
Среднее скрывает длинный хвост задержек: небольшое число заявок может ждать очень долго, почти не меняя среднее значение. Поэтому для SLA и клиентского опыта полезно смотреть медиану, перцентили, например 90-й или 95-й, а также распределение по типам заявок и маршрутам. Сегментация нужна, чтобы редкие сложные случаи не маскировались массовыми простыми заявками и наоборот.