12 этапов, 46 часов ожидания: как я искала узкое место в рабочем процессе

Аннотация

Я разобрала процесс запуска клиентской рекламной кампании на 12 этапов и отдельно измерила время работы, ожидания и возвратов. Выяснилось, что команда тратила на саму задачу меньше пяти часов, хотя полный цикл занимал почти три дня. Основная задержка возникала на операции продолжительностью всего 17 минут.

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

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

Но после первой выгрузки временных меток эта версия развалилась. Из почти 51 часа полного цикла непосредственно над задачей работали 4 часа 52 минуты. Остальные 46 часов она в основном где-то лежала.

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

Сначала пришлось превратить рабочий процесс в данные

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

Процесс начинался после получения заполненного брифа и заканчивался фактическим запуском кампании. Между этими точками оказалось 12 операций:

1. регистрация брифа;
2. проверка исходных данных;
3. уточнение недостающей информации;
4. подготовка медиаплана;
5. согласование бюджета;
6. подготовка технического задания;
7. создание креативов;
8. проверка креативов;
9. сборка кампании;
10. проверка настроек;
11. финальное согласование;
12. запуск.

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

Processing time показывает, сколько времени сотрудник действительно работал над задачей.

Queue time — сколько задача ждала до начала обработки.

Полный срок этапа можно записать совсем просто:

T этапа = T ожидания + T обработки

А полный цикл:

Lead Time = Σ Queue Time + Σ Processing Time

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

Самая долгая операция не оказалась проблемой

Для первого прохода я взяла 38 запусков за несколько недель и посчитала медианное время. Среднее специально не использовала как основной показатель: несколько кампаний с очень долгим согласованием заметно тянули его вверх.

Самой трудоёмкой операцией оказалось создание креативов — медиана 71 минута. Второе место занимала сборка кампании — 54 минуты. Подготовка медиаплана требовала 39 минут.

Если смотреть только на рабочее время, план оптимизации практически пишет себя сам: автоматизировать часть дизайна, шаблонизировать сборку кампаний и ускорить медиаплан.

Но я добавила время ожидания.

Перед созданием креативов задача ждала в среднем около полутора часов. Перед сборкой кампании — чуть больше двух. А перед согласованием бюджета — 9 часов 18 минут.

Само согласование бюджета занимало медианные 17 минут.

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

Причём сотрудника, отвечавшего за согласование, нельзя было назвать медленным. Наоборот, отдельные заявки он обрабатывал быстро.

Проблема была в режиме поступления задач.

Очередь возникала два раза в сутки

Согласование бюджета выполнял руководитель направления. В течение дня у него были встречи, текущие задачи и несколько других процессов. Запросы на бюджет он открывал пакетно — обычно около полудня и ближе к вечеру.

С его точки зрения это разумная организация времени. Вместо постоянных переключений он обрабатывал несколько запросов за один заход.

Но поток задач жил по другому расписанию.

Если медиаплан попадал на согласование в 12:20, а предыдущая пачка была проверена в 12:00, задача могла пролежать до вечера. Если запрос приходил поздно, ожидание переносилось на следующий день.

При этом интерфейс таск-менеджера ничего подозрительного не показывал. Статус был корректным, ответственный назначен, просрочки ещё нет.

Только временные метки показывали, что именно здесь задачи перестают двигаться.

Я посчитала коэффициент потока:

Flow Efficiency = Processing Time / Lead Time × 100%

При 4 часах 52 минутах фактической работы и примерно 51 часе полного цикла эффективность потока получалась около 9,5%.

То есть более 90% времени задача существовала в процессе, но никто с ней ничего не делал.

И это уже было интереснее попытки сэкономить дизайнеру пятнадцать минут.

Загрузка сотрудника и узкое место — разные вещи

На этом этапе я едва не сделала ещё один неправильный вывод: раз очередь возникает перед руководителем, значит он перегружен и нужно передать согласование кому-то ещё.

Но очередь сама по себе не объясняет причину.

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

В среднем на согласование приходило около восьми запросов за рабочий день. На одну проверку требовалось 17 минут. Даже если считать два с половиной часа чистого времени, руководитель технически мог обработать весь дневной поток.

Мощности хватало.

Не хватало доступности мощности в тот момент, когда она требовалась.

Это два разных ограничения.

Если на этап поступает 20 задач в день, а он способен обработать только 15, возникает capacity bottleneck — нехватка пропускной способности.

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

Для аудита я стала различать несколько признаков:

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

После этого стало понятно, что нанимать дополнительного согласующего бессмысленно. Мы бы увеличили мощность там, где её и так достаточно.

Первое изменение заняло меньше времени, чем сам аудит

Мы не автоматизировали согласование и не меняли ответственного.

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

Руководителю оставили только исключения.

Среднее ожидание на пятом этапе после этого снизилось с 9 часов 18 минут примерно до 1 часа 40 минут.

Полный цикл тоже заметно сократился.

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

Узкое место переехало.

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

Второе узкое место оказалось совсем другого типа

На восьмом этапе креативы проходили проверку. Первоначально эта операция занимала всего 14 минут, поэтому я почти не обращала на неё внимания.

Но после ускорения согласования перед проверкой стала формироваться очередь.

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

Примерно 23% комплектов возвращались дизайнеру хотя бы один раз.

Это означает, что часть задач проходила маршрут:

создание → проверка → возврат → исправление → повторная проверка.

Для таск-менеджера это выглядело как обычная работа внутри двух этапов. Для процесса фактически появлялась дополнительная петля.

Я отдельно посчитала First Pass Yield — долю задач, прошедших этап без возврата.

FPY = количество задач без возврата / общее количество задач × 100%

При 38 запусках с первого раза проверку прошли 29.

FPY получился около 76%.

Само значение не катастрофическое. Но каждый возврат снова занимал место в очереди дизайнера, а затем возвращался в очередь проверки.

Один дефект создавал нагрузку сразу на двух участках.

Вместо ускорения проверки пришлось менять вход в неё

Можно было попросить проверяющего работать быстрее. Это сократило бы несколько минут и почти ничего не изменило.

Я взяла девять возвращённых комплектов и вручную разложила причины. В большинстве случаев повторялись три вещи: неверный размер одного из форматов, расхождение текста с утверждённым вариантом и отсутствие обязательного элемента.

То есть значительная часть ошибок была формальной.

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

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

После изменения количество возвратов снизилось.

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

Если просто добавить мощность на участок проверки, дефекты продолжат поступать быстрее.

После этого я посмотрела не на этапы, а на незавершённую работу

Ещё одна величина, которую я раньше почти не использовала в подобных аудитах, — WIP, Work in Progress. Это количество задач, которые уже вошли в процесс, но ещё не вышли из него.

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

Чем больше WIP, тем менее очевидно, почему конкретная задача стоит.

Здесь полезна связь, известная как закон Литтла:

L = λ × W

где L — среднее количество задач внутри системы, λ — средняя скорость поступления или завершения задач, W — среднее время нахождения задачи в системе.

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

Хотим сократить его до полутора дней при той же пропускной способности — WIP должен приблизиться к шести задачам.

Это не означает, что достаточно просто запретить брать новые задачи. Но связь хорошо показывает неприятную вещь: бесконечно запускать работу в систему и одновременно требовать сокращения lead time невозможно.

Что показал повторный замер

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

Главный эффект пришёл не от ускорения работы сотрудников.

Мы сократили ожидание согласования бюджета, убрали часть формальных возвратов и ограничили количество одновременно запущенных задач на отдельных этапах.

Фактическое время обработки изменилось сравнительно мало. Команда не стала внезапно рисовать в два раза быстрее или за пять минут собирать кампанию.

Зато уменьшилось время, когда работа просто лежала.

Именно поэтому полный цикл сократился намного сильнее, чем сумма сэкономленных минут отдельных сотрудников.

Для меня это стало хорошим критерием качества оптимизации. Если processing time уменьшился на 20%, а lead time почти не изменился, скорее всего, мы ускорили не то место.

Теперь аудит процесса я начинаю с пяти чисел

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

Для первого прохода мне достаточно нескольких показателей:

• Lead Time — сколько задача находится внутри процесса целиком;
• Processing Time — сколько времени над ней действительно работают;
• Queue Time — сколько она ждёт между операциями;
• WIP — сколько незавершённых задач одновременно находится в системе;
• First Pass Yield — какая доля проходит ключевые проверки без возврата.

Эти показатели не дают готового ответа, но довольно быстро показывают, куда смотреть.

Большой Queue Time указывает на очередь. Низкий FPY — на переделки. Растущий WIP при неизменной скорости выхода — на перегруженный поток. Высокая загрузка конкретного сотрудника сама по себе при этом вообще может не быть проблемой.

И только после этого я смотрю на автоматизацию, найм или перераспределение обязанностей.

Иначе слишком легко потратить деньги на ускорение участка, который не ограничивает систему.

Вывод

До этого разбора мне казалось логичным искать в длинном процессе самую долгую операцию. В цепочке из двенадцати этапов именно она выглядит главным кандидатом на оптимизацию.

На практике всё оказалось менее очевидно.

Первое ограничение занимало всего 17 минут, но создавало больше девяти часов ожидания. После его устранения следующим ограничением стала проверка, причём тормозила её уже не скорость сотрудника, а возвраты с предыдущего этапа.

То есть одного постоянного виновника у процесса вообще не было.

Было текущее ограничение системы.

И после каждого изменения оно перемещалось.

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

Только после этого становится видно, что действительно тормозит цепочку.

Иногда это сотрудник.

Иногда правило согласования.

Иногда плохой вход на следующий этап.

А иногда — семнадцатиминутная операция, перед которой задача почему-то проводит весь рабочий день.