Как выбрать первый процесс для автоматизации

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

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

Матрица выбора без магического балла

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

Что измерить до разработки

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

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

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

Условный пример: заявка из формы в рабочую очередь

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

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

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

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

Как выглядит законченный первый этап

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

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

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

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

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

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