Сегодня зададимся старым вопросом, но уже в новых реалиях.

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

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

Почему задача ждёт? Первое объяснение - перегрузка: у исполнителя много работы, до этой задачи просто не дошли руки. Так бывает, и тогда помогает перераспределение работы. Но не всегда. Часто задача стоит потому, что непонятно, кто должен взять её следующей. Формально она кому-то направлена, но адресат не уверен, что вопрос в его компетенции, и откладывает его до выяснения. Или задача пришла без части сведений, и исполнитель ждёт, пока появится время спросить.

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

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

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

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

Представим ситуацию, в понедельник менеджер запрашивает справку для клиента и отправляет запрос не тому специалисту. Тот пересылает его коллеге только в среду. Конечный исполнитель видит, что не указан период, и просит уточнить. Ответ приходит в четверг, но заявки отдел разбирает по вторникам, поэтому справку готовят через неделю после запроса. Работа заняла двадцать минут, срок - восемь дней. Медленно никто не работал, каждый поступал разумно со своей стороны. Задержку создали переходы: неясный адресат, неполный запрос и недельный цикл разбора.

С чего начать поиск? Не с внедрения системы учёта, а с восстановления пути нескольких реальных задач. Возьмите три-пять недавно выполненных запросов и пройдите по каждому: когда поступил, кто и когда над ним работал, где он ждал и почему. Полезно отметить и то, сколько раз задача возвращалась за уточнениями. Даже на таком небольшом материале часто видно, что работа занимает малую долю срока, а ожидание повторяется в одних и тех же местах.

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