Выявление автоматизации начинается с записи экрана

Почему схемы процесса упускают самые неудобные детали

Когда люди рисуют процесс, они невольно делают его аккуратнее. Они вспоминают официальный путь, а не настоящий. Блоки выглядят опрятно. Работа обычно — нет.

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

Именно из-за такого разрыва проекты по автоматизации часто идут не так. Мелкие действия решают, сработает ли workflow в первый день или развалится, как только данные станут грязными.

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

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

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

Что дает запись экрана с комментариями

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

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

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

Чаще всего оказывается, что «задача» на самом деле состоит из трех более мелких частей:

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

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

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

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

Сначала выберите одну задачу, которую стоит записать

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

Держите рамки узкими: один человек, одна задача, один результат. «Отправить еженедельное обновление по запасам» — достаточно конкретно. «Управлять запасами» — слишком широко и затянет в работу побочные задачи, отвлечения и разовые исключения.

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

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

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

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

Как провести сессию записи

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

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

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

Перед началом настройте запись так, чтобы ничего не упустить:

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

Не подсказывайте человеку каждый шаг. Если вмешиваться каждую минуту, вы меняете сам процесс, который пришли наблюдать. Дайте тишине немного побыть. Если человек слишком долго молчит, задайте один нейтральный вопрос вроде: «Что вы сейчас проверяете?» — а потом снова отступите.

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

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

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

На что смотреть во время записи

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

Сначала отмечайте каждое копирование и вставку. Если оператор копирует имя клиента из почты в CRM, а затем вставляет номер заказа в таблицу, фиксируйте каждый переход. Именно такие движения между инструментами чаще всего становятся первыми кандидатами на автоматизацию, потому что они повторяются весь день и редко попадают в process mapping.

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

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

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

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

Хорошие заметки звучат конкретно. «14 раз скопировал номер отслеживания со страницы перевозчика в CRM» — это уже можно использовать. «Обновил данные по доставке» — нет.

Простой пример из команды поддержки

На поверхности тикет поддержки выглядит просто. Клиент спрашивает: «Где мой возврат?» Агент читает тикет, открывает CRM, проверяет историю заказа и пытается понять, что произошло, прежде чем написать ответ.

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

В этот момент агент все еще не ответил клиенту. Он выполняет работу по поиску, по памяти и по двойному вводу.

Реальная сессия часто выглядит так:

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

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

Вот почему записи экрана так полезны для automation discovery. Диаграмма процесса может сказать: «проверьте право на возврат и обновите статус». Запись показывает, что происходит на самом деле: какая вкладка открывается первой, что копируется, где человек сомневается и какой шаг повторяется, потому что инструменты не общаются друг с другом.

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

Как превратить заметки в первый workflow

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

Возьмите заметки из записи и разнесите каждое действие по четырем группам:

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

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

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

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

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

Держите первую версию достаточно узкой, чтобы можно было отслеживать каждый запуск и быстро исправлять ошибки. Команды, которые движутся к AI-first operations, часто добиваются лучшего результата именно так: они учатся на одной живой передаче, а не ставят все на огромный план.

Ошибки, из-за которых команды идут не туда

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

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

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

Скриншоты создают другую ловушку. Замороженный экран показывает, что произошло, но не почему. Когда оператор делает паузу на 15 секунд, спросите, что он проверял, какой риск видел и почему доверил одному варианту, а не другому. Эта короткая пауза часто несет больше смысла, чем сам клик перед ней.

Плохую сессию discovery обычно можно заметить быстро. Запись кажется слишком гладкой, будто это не обычный день. Задача происходит лишь время от времени. В заметках нет мелких поисков и шагов copy-paste. Никто не спрашивает, почему оператор сомневался. А потом план сборки пытается автоматизировать все сразу.

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

Короткая проверка перед тем, как что-то строить

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

Используйте запись и заметки, чтобы ответить на пять простых вопросов:

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

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

Есть простое правило: если вы не можете ответить на один из этих вопросов по записи, не начинайте строить. Запишите еще одну сессию. В automation discovery одна дополнительная запись стоит дешевле, чем исправление плохого workflow после того, как люди уже начали им пользоваться.

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

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

Что делать дальше

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

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

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

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

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

Если задача проходит между командами или смешивает старые инструменты, API и AI-системы, рамки могут быстро стать путаными. В таких случаях помогает взгляд со стороны. Oleg Sotnikov на oleg.is работает как Fractional CTO и startup advisor, и такая узкая практическая работа по автоматизации хорошо соответствует тому, как он помогает командам двигаться к AI-driven software development, не превращая маленький пилот в большой рискованный проект.