Какие задачи автоматизировать первыми — и где оставить человека

Автоматизируйте задачу, а не должность

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

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

Google SRE предлагает распознавать toil по повторяемости, предсказуемости, ручному характеру, возможности автоматизации и отсутствию долговременной ценности. Это полезный фильтр, но не приказ писать скрипт. Иногда лучший ход — устранить причину лишней работы, изменить форму или убрать ненужное согласование. Автоматизация плохого процесса закрепляет его быстрее.

Сначала измерьте исходный процесс

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

Матрица частоты, риска и стоимости ошибки

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

Выберите уровень автономности, а не бинарное «да или нет»

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

• Подсказка: человек видит собранный контекст и сам действует.

• Черновик: система предлагает результат, человек редактирует и подтверждает.

• Проверяемое действие: правило исполняется только после автоматических gate-проверок.

• Ограниченная автономность: действие разрешено для узкого класса случаев и лимита.

• Ручное решение: неоднозначные, ценностные, юридически значимые или необратимые случаи.

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

Разберите три кандидата без самообмана

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

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

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

Проведите пилот так, чтобы его можно было остановить

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

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

Посчитайте эффект вместе со скрытой ручной работой

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

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

Оставьте человеку ответственность, контекст и право остановки

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

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

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

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

Практический следующий шаг

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

• Процесс разложен на узкие задачи с входом, выходом и владельцем.

• Частота и ручное время измерены, а не восстановлены по памяти.

• Цена ошибки, обратимость и способ обнаружения зафиксированы.

• Уровень автономности ограничен минимально необходимыми правами.

• Есть теневой режим, журнал, критерий остановки и ручной fallback.

• Эффект считается вместе с исключениями и сопровождением.

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

• Как спроектировать устойчивый no-code сценарий

• Как принимать решения по данным без дорогой BI-системы

• Как проверить качество входных данных

• Как проверить, действительно ли технология экономит время