Как найти ручные операции, с которых стоит начать автоматизацию

• Процессы

К вопросам по статье

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

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

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

Для каждой операции запишите пять вещей

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

Отделите лишний шаг от нужного решения

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

Не вся ручная работа лишняя. Иногда она нужна для контроля качества. Тогда задача — уменьшить подготовительную рутину, сохранив момент принятия решения.

Выберите первый этап

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

Оцените и состояние исходных данных. Автоматизация не исправляет сама по себе разные названия одного клиента, пропущенные поля и неопределённую ответственность. Иногда первый этап — привести данные и правила в порядок.

Как провести обследование без многомесячного проекта

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

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

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

Лист наблюдения одной операции

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

Отделите перенос, решение и контроль

Перенос переносит уже известное значение из одного места в другое. Решение выбирает вариант на основании условий. Контроль обнаруживает несоответствие. Внешне все три действия могут выглядеть как работа в таблице, но автоматизировать их нужно по-разному. Замена переноса интеграцией обычно не требует изменения коммерческой политики. Автоматический выбор скидки без согласованных условий — уже другое вмешательство.

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

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

Карта процесса без декоративной схемы

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

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

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

Диагностический пример ручной передачи заказа

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

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

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

Как сравнить кандидатов на автоматизацию

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

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

Считать время вместе с исправлениями

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

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

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

Бизнес-процесс выбора первого этапа

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

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

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

Что показывает опыт реального проекта

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

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

Приёмочная матрица первого пилота

Комплект аналитических артефактов

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

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

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