Составьте карту передач до AI и сократите потери до изменений в команде

Почему работа кажется медленной даже при полной команде

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

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

Это ожидание прячется в обычных обновлениях. Кто-то пишет «с моей стороны готово» и ждёт, пока следующий человек заметит сообщение. Кто-то просит быстрое согласование, но у согласующего на ближайшие четыре часа встречи. На бумаге задача заняла один день. На практике на неё ушло 40 минут реальной работы и несколько часов простоя.

Обычная административная работа только усугубляет проблему, потому что люди повторяют одни и те же данные в разных местах. Имя клиента попадает в CRM, потом в тикет, потом на доску проекта, потом в черновик счёта. Срок копируется из чата в задачу, потом в таблицу, потом в сводное письмо. Каждое лишнее поле по отдельности кажется мелочью, но команда платит за него снова и снова.

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

У большинства медленных процессов один и тот же рисунок. Слишком много людей трогают одну задачу. Передачи зависят от того, заметит ли кто-то сообщение. Одни и те же данные вводят больше одного раза. Согласования зависают у людей, которые не меняют итог.

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

Лучший первый шаг простой и немного скучный. Посчитайте каждого человека, который касается одной задачи, каждое место, где меняется статус, и каждый раз, когда кто-то заново вводит один и тот же факт. Команды часто обнаруживают, что сама работа была несложной. Слишком сложным был путь.

Что нужно посчитать на текущем пути

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

Начните с согласований. Считайте каждый раз, когда кто-то должен сказать «да», прежде чем задача сможет двинуться дальше. Команды часто думают, что у них одно согласование, но в реальности их больше. Проверка у менеджера в чате, проверка у продуктовой команды по почте и финальное одобрение в тикете — это уже три согласования.

Переходы статуса тоже важны. Каждый шаг от «новая» к «в работе» к «на проверке» к «в ожидании» добавляет трение. Скрытые переходы часто ещё хуже. Человек пишет обновление в чат, копирует его в письмо, потом правит тикет, чтобы все были в курсе. Это уже три перехода статуса ради одного кусочка прогресса.

С холодной головой отслеживайте повторный ввод данных. Если кто-то вводит одно и то же имя клиента, номер заказа, дедлайн или детали бага в больше чем один инструмент, считайте каждый повтор. Одно лишнее копирование может занять 30 секунд. Десять таких повторов в неделю незаметно съедают часы.

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

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

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

Как пройти один workflow от начала до конца

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

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

Запишите каждый шаг в точном порядке, в котором он происходит. Формулируйте прямо и конкретно. «Продажи отправляют запрос в операционный отдел» лучше, чем «запрос проходит проверку». Укажите, кто делает шаг, что именно он делает и где он это делает.

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

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

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

Следите за шагами, которые никто не может объяснить в одном предложении. Если один человек говорит: «Мы всегда так делали», а другой отвечает: «Кажется, finance однажды это попросили», пометьте такой шаг. Сбивчивые шаги часто оказываются старыми правилами, которые пережили свою причину.

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

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

Какие согласования и переходы статуса стоит оспорить

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

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

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

Та же логика относится к переходам статуса. Если работа в тикете переходит из «в работе» в «на проверке», а кто-то ещё пишет то же самое в чат, почту и таблицу, это не прозрачность. Это дублирование. Оставьте одно место, где живёт прогресс, и пусть все пользуются именно им.

Несколько шагов заслуживают немедленной проверки:

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

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

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

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

Простой пример из реального процесса

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

Поддержка открывает случай и проверяет номер заказа, дату заказа, сумму оплаты и статус доставки. Потом агент копирует эти данные в форму возврата для finance. Finance открывает эту форму, ещё раз проверяет номер заказа и сумму и вводит имя клиента, сумму возврата и ID транзакции в бухгалтерский инструмент.

Операции тоже подключаются, потому что посылка могла потеряться или повредиться в пути. Руководитель операционного отдела проверяет складское сканирование, заметку перевозчика и запись о запасах, а потом добавляет комментарий в общую таблицу. Теперь один возврат уже затронул поддержку, finance и operations.

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

Исходный путь и более короткий путь

Обычный вариант выглядит так:

• support проверяет тикет и заполняет форму возврата
• менеджер поддержки одобряет возвраты выше установленной суммы
• finance заново вводит те же данные о заказе и оплате
• руководитель finance одобряет возврат
• operations записывает проблему с доставкой в отдельную таблицу

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

Более короткий путь сначала убирает лишнее. Поддержка один раз собирает подтверждение в общей записи. Если сумма возврата ниже понятного лимита, а доставка уже показала повреждение или сбой, finance обрабатывает возврат без повторной проверки менеджером. Operations смотрит только те случаи, где неясны запасы, мошенничество или спор с перевозчиком.

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

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

Ошибки, которые тратят время ещё до автоматизации

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

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

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

Во многих картах процесса показан только нормальный случай. А это проблема. Реальная работа включает недостающую информацию, срочные запросы, изменения со стороны клиента, неудачные проверки и переделки. Именно эти исключения создают самые длинные ожидания и больше всего повторного ввода. Если их пропустить, workflow выглядит аккуратно на бумаге и разваливается в реальности.

Команды также тратят время, когда каждая группа защищает свой шаг без доказательств. Продажи говорят, что заметка о передаче важна. Operations говорят, что лишний статус помогает. Finance говорит, что ещё одно согласование снижает риск. Возможно, они и правы. Но каждый шаг должен быть подтверждён фактами, а не привычкой.

Несколько вопросов быстро отсеивают шум:

• Кто использует результат этого шага?
• Что сломается, если убрать его на две недели?
• Как часто он находит реальную проблему?
• Кто-то другой уже не проверяет то же самое?

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

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

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

Быстрая проверка перед автоматизацией

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

Попросите одного человека объяснить весь путь простыми словами. Он должен суметь сказать, где задача начинается, кто её трогает, какая информация движется и как всё заканчивается. Если объяснение ломается на середине, проблема не в инструменте. Сам маршрут неясен.

Перед автоматизацией любого процесса используйте простой чек-лист:

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

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

Передвижение задачи — ещё один тревожный сигнал. Запрос, который идёт из поддержки в продажи, потом в finance, потом в operations и обратно, может выглядеть организованным на бумаге, но каждый переход статуса добавляет ожидание. Если те же данные копируются в письмо, тикет и таблицу, повторный ввод вредит сильнее, чем думает большинство команд.

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

Следующие шаги для небольшого и безопасного пилота

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

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

Прежде чем добавлять AI, уберите один лишний элемент. Уберите одно согласование, если оно существует только потому, что «мы всегда так делаем». Или уберите один шаг копирования, если кто-то постоянно вставляет одни и те же данные во второй инструмент. Такая небольшая очистка важнее, чем кажется. Если процесс раздут, пилот тестирует хаос, а не AI.

Практичный план пилота часто умещается на одной странице:

• выберите один высокочастотный workflow с заметной задержкой
• зафиксируйте текущий cycle time, error rate и число передач
• уберите одно согласование или один повторный ввод данных
• протестируйте AI на одной очищенной задаче, а не на всём процессе
• сравните цифры через одну или две недели

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

После изменения отслеживайте три показателя: cycle time, error rate и число передач. Cycle time показывает, стала ли работа быстрее. Error rate показывает, не создала ли скорость новых проблем. Число передач показывает, стал ли процесс действительно проще. Если хотите ещё один показатель, считайте, как часто кому-то приходилось исправлять результат AI, прежде чем задача могла двигаться дальше.

Команды обычно замечают, что одно убранное согласование и один убранный шаг копирования экономят время ещё до того, как автоматизация вообще что-то делает.

Некоторые пилоты кажутся небольшими, но одновременно затрагивают правила продукта, внутренние инструменты и структуру команды. В таких случаях полезна внешняя проверка. Oleg Sotnikov на oleg.is работает как fractional CTO и startup advisor, и именно такая очистка процессов часто становится разницей между полезным AI-пилотом и дорогим обходным путём.