Узкое место - не самый занятый человек и не самый медленный отдел. Это участок, чья доступная мощность ограничивает выпуск всего процесса и перед которым регулярно накапливается очередь или ожидание
Нарисуйте мощность по этапам
В операционной системе оптимизация процессов связано с эффективность компании. Если анализ процессов растёт только на одном шаге, а очередь переезжает дальше, системного эффекта нет
| Этап | Вход в день | Мощность в день | Очередь | Вывод |
|---|---|---|---|---|
| Проверка заявки | 120 | 150 | Нет | Запас мощности |
| Расчёт | 120 | 95 | Растёт | Кандидат на bottleneck |
| Согласование | 95 | 130 | Эпизодическая | Не ограничивает обычный поток |
| Оформление | 95 | 110 | Нет | Запас |
В этом примере нанять людей в оформление бессмысленно: до них физически не доходит больше 95 задач в день. Улучшение расчёта способно увеличить throughput всей цепочки
Четыре признака настоящего ограничения
- Перед этапом регулярно растёт незавершённая работа или очередь
- После этапа следующие участки периодически простаивают
- Ускорение этого участка увеличивает выпуск всего процесса, а не только локальную метрику
- Исключения и повторная работа часто возвращаются именно сюда или создают дополнительную нагрузку
Как проверить гипотезу за неделю
- Выберите один сквозной поток и единицу результата
- На каждом этапе посчитайте вход, выпуск и очередь по дням
- Отделите активное время от ожидания между этапами
- Посмотрите причины возвратов и долю исключений
- На ограничении попробуйте одно изменение и проверьте, вырос ли общий throughput
Что менять на bottleneck в правильном порядке
Сначала защитите дефицитную мощность от лишней работы: уберите ненужные проверки, перенесите подготовку входа раньше, отделите простые кейсы от сложных, сократите rework. После этого имеет смысл автоматизировать операции или добавлять ресурс
Почему “все должны быть загружены на 100%” опасно
Если каждый этап работает на пределе и у системы нет буфера, небольшая вариативность создаёт очередь. Операционная эффективность не равна максимальной занятости каждого сотрудника. Иногда небольшой запас мощности вокруг bottleneck делает весь процесс быстрее и устойчивее
Какие данные снять до улучшения
Вход и выпуск каждого этапа - первая точка, которую стоит зафиксировать до любых изменений. Рядом соберите Backlog по этапам, а затем время ожидания и активной работы, доля возвратов и доступная capacity по ролям. Все значения должны относиться к одному типу потока и сопоставимому периоду, иначе сезонность и разный состав кейсов исказят вывод
- Вход и выпуск каждого этапа
- Backlog по этапам
- Время ожидания и активной работы
- Доля возвратов
- Доступная capacity по ролям
Не пытайтесь “сбалансировать” все этапы до одинаковой загрузки. Для потока полезнее иметь небольшой запас вокруг ограничения, чем заставлять каждый участок работать на 100% и создавать очереди при любой вариативности
Сравнение throughput процесса и backlog перед bottleneck лучше делать на ограниченном типовом потоке: сначала снять базовую точку по «Вход и выпуск каждого этапа» и «Backlog по этапам», затем изменить один механизм и повторить замер. Так проще отделить эффект процесса от изменения спроса, состава команды или структуры входящего потока
Как проверить результат на том же потоке
Связка throughput процесса, backlog перед bottleneck, cycle time, utilization bottleneck и rework на ограничении показывает, дошло ли улучшение до результата целиком. Одна красивая локальная метрика недостаточна: если скорость выросла ценой качества, backlog переместился дальше или экономия не превращается в usable capacity, гипотезу нужно пересчитать
Хотите найти реальное узкое место, а не самого занятого человека?
Покажите один сквозной процесс и объёмы по этапам. Мы поможем собрать карту очередей и мощности, проверить bottleneck и выбрать изменение, которое влияет на общий выпуск
Частые вопросы
Как отличить bottleneck от просто занятого отдела?
Узкое место ограничивает throughput всего процесса: перед ним копится очередь, а увеличение его мощности увеличивает общий выпуск
Можно ли найти узкое место без process mining?
Да. Для первой диагностики достаточно timestamps, объёмов и очередей по нескольким этапам. Process mining полезен, когда поток большой и ветвящийся
Нужно ли сразу нанимать людей на bottleneck?
Нет. Сначала уберите лишнюю работу, rework и плохой вход, затем оцените автоматизацию и только после этого дополнительный ресурс
Почему после оптимизации bottleneck появился в другом месте?
Потому что система теперь упирается в следующий ограничивающий этап. Это нормальный эффект роста пропускной способности
