Какие бизнес-процессы автоматизировать в первую очередь: практическая система выбора

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

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

Ниже — методика, которая помогает выбрать такой процесс без обещаний универсальной окупаемости. Она подходит для заявок, документов, согласований, оплат, сервисных операций и обмена между CRM, сайтом, 1С, телефонией и другими системами.

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

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

Полезная формула для описания процесса:

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

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

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

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

Для каждого кандидата достаточно короткой карточки:

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

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

Оцените пользу, готовность и риск отдельно

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

Потенциальная польза

Критерий Что выяснить Высокий приоритет
—————— —————————————————- ———————————————————————
Повторяемость Как часто возникает одинаковый маршрут? Процесс регулярно потребляет внимание команды
Ручные передачи Сколько раз данные переписывают или пересылают? Одни сведения вводятся в несколько систем
Ожидание Где работа лежит между участниками? Результат зависит не от выполнения, а от своевременного напоминания
Цена ошибки Что происходит при пропуске или неверном действии? Теряется заявка, нарушается обязательство или требуется переделка
Управляемость Можно ли сейчас увидеть состояние процесса? Руководитель собирает статус вручную

Готовность к автоматизации

Критерий Что проверить Признак готовности
———————— ————————————————————— ———————————————————
Определённое начало Существует ли однозначное событие запуска? Его можно получить из системы или зафиксированной формы
Формализуемые правила Можно ли объяснить решение без «обычно смотрим по ситуации»? Условия перечислены и согласованы
Качество данных Есть ли обязательные значения и единые справочники? Данные структурированы и проходят проверку
Наблюдаемый результат Как система поймёт, что действие выполнено? Есть статус, ответ API, запись или другое подтверждение
Владелец процесса Кто принимает решения о правилах? Назван конкретный ответственный со стороны бизнеса

Риск

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

— Можно ли отменить действие?
— Затрагивает ли оно деньги, юридически значимые документы или персональные данные?
— Что будет при двойном выполнении?
— Кто заметит ошибку и как быстро?
— Можно ли сначала перевести систему в режим рекомендации, оставив подтверждение человеку?

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

Как пользоваться оценочной шкалой

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

Практический порядок такой:

1. Оценить потенциальную пользу каждого кандидата.
2. Отдельно оценить готовность правил и данных.
3. Вынести критичные риски в список ограничений, не маскируя их общим баллом.
4. Выбрать несколько процессов с высокой пользой.
5. Из них начать с того, где результат можно проверить и безопасно вернуть в ручную обработку.

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

Опишите процесс до разработки

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

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

До начала автоматизации бизнес-процесса (https://synchroweb.ru/avtomatizaciya-biznesa/) ответьте на вопросы:

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

Условный пример: обработка заявки с сайта

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

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

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

Здесь автоматизируется не форма и не уведомление, а весь участок от отправки данных до подтверждённой постановки заявки в работу. Страница сайта остаётся публичной точкой входа, которую проектируют в рамках разработки сайта (https://synchroweb.ru/razrabotka-sajtov/), а CRM становится владельцем дальнейшего клиентского маршрута.

Инженерная надёжность: что должно быть предусмотрено

Защита от повторного выполнения

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

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

Осмысленные повторные попытки

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

Очередь и изоляция сбоя

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

Журнал действий

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

Регулярная сверка

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

Ручной маршрут

Автоматизация должна сообщать не только «ошибка», но и то, что делать дальше. Ответственному нужны исходные данные, причина, уже выполненные действия и безопасные варианты: повторить, исправить, отклонить или связать с существующей записью. Такой интерфейс может быть частью CRM либо отдельного веб-сервиса для сотрудников (https://synchroweb.ru/veb-servisy/).

Где решение должен оставить за собой человек

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

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

Не подменяйте автоматизацию усилением контроля

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

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

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

Как измерять результат без рекламных процентов

До запуска зафиксируйте исходное состояние на репрезентативном объёме операций. После запуска измеряйте те же показатели:

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

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

Что не стоит брать первым

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

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

Порядок запуска первого процесса

1. Собрать реестр кандидатов по фактической работе.
2. Оценить пользу, готовность и риск раздельно.
3. Выбрать участок с ясным началом и проверяемым результатом.
4. Описать текущий и целевой маршрут вместе с исполнителями.
5. Определить владельцев данных и технический контракт.
6. Спроектировать дубли, ошибки, повторные попытки, журнал и ручную очередь.
7. Зафиксировать исходные показатели и критерии приёмки.
8. Запустить на ограниченном контуре и проверить исключения.
9. Только после стабильной работы расширять автоматизацию на соседние процессы.

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

Документация и данные по теме

— ИСИЭЗ НИУ ВШЭ: «Цифровые технологии в бизнесе: практики и барьеры использования» (https://issek.hse.ru/news/890550436.html)
— Object Management Group: стандарт Business Process Model and Notation (https://www.omg.org/bpmn/)
— IETF RFC 9110: идемпотентные HTTP-методы (https://datatracker.ietf.org/doc/html/rfc9110#section-9.2.2)
— Официальная документация 1С: REST interface (https://1c-dn.com/1c_enterprise/rest_interface/)