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

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

И здесь начинается проблема.

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

Если передать такое описание разработчику, автоматизация не устранит неопределённость. Часть этой неопределённости просто попадёт в новую систему.

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

Для большинства бизнес-задач первоначального описания можно начать с десяти вопросов:

1. Какой результат должен давать процесс?
2. Что запускает его?
3. Какие данные нужны на входе?
4. Кто участвует и за что отвечает?
5. Какие действия выполняются и в каком порядке?
6. Где принимаются решения?
7. По каким правилам принимаются эти решения?
8. Какие нестандартные ситуации возможны?
9. Какие данные создаются или изменяются?
10. Как выглядит успешное завершение процесса?

Этого уже достаточно, чтобы обнаружить значительную часть неопределённости ещё до разработки.

Сначала опишите не систему, а работу бизнеса

Одна из самых дорогих ошибок при подготовке автоматизации — начинать с будущего интерфейса.

• «Здесь нужна кнопка».
• «После нажатия должно открываться окно».
• «Менеджеру нужна новая вкладка».

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

Допустим, компания хочет автоматизировать согласование скидок.

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

Когда правила понятны, интерфейс можно спроектировать несколькими способами. Когда правила непонятны, даже красивый интерфейс не решит проблему.

Опишите сначала текущий процесс, затем желаемый

Перед автоматизацией полезно разделить две картины.

Первая — как процесс реально работает сейчас.

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

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

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

Вторая картина — как процесс должен работать после изменения.

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

Это важное различие. Если сразу автоматизировать процесс «как есть», можно потратить деньги на ускорение лишних действий.

Шаблон описания бизнес-процесса для автоматизации

Для первого уровня не нужна большая схема. Начните со структурированного документа.

Главная цель такого шаблона — не создать красивую документацию. Нужно убрать неоднозначность.

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

Пример описания бизнес-процесса

Возьмём типичную задачу сервисной B2B-компании — обработку новой заявки.

Название

Обработка новой B2B-заявки.

Цель

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

Триггер

На сайте отправлена форма обращения.

Входные данные

Система получает:

• имя;
• контактные данные;
• название компании;
• содержание запроса;
• выбранную услугу.

Если какие-то данные обязательны для дальнейшего решения, это нужно указать отдельно.

Участники

Потенциальный клиент отправляет заявку.

Ответственный за первичную квалификацию проверяет её полноту и соответствие базовым требованиям.

Менеджер продаж работает с заявками, которые прошли квалификацию.

Здесь важны именно функции, а не имена сотрудников. Конкретный человек может поменяться, а роль в процессе останется.

Основной сценарий

1. Клиент отправляет форму.
2. Система создаёт новую заявку.
3. Ответственный сотрудник получает уведомление.
4. Проверяется полнота данных.
5. Проверяется соответствие заявки критериям компании.
6. Подходящая заявка передаётся менеджеру продаж.
7. Менеджер связывается с клиентом.
8. После разговора заявка переводится на следующий этап либо закрывается с указанной причиной.

Уже здесь появляются вопросы, которые невозможно увидеть из фразы «нам нужна автоматизация лидов».

Например, что именно означает «подходящая заявка»?

Пока компания не может ответить на этот вопрос, системе тоже нечем руководствоваться.

Опишите правила принятия решений

Шаги показывают последовательность работы. Но для автоматизации этого мало.

Системе нужно понимать правила.

Например:

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

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

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

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

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

Нормальный сценарий обычно объяснить легко.

Клиент отправил заявку, сотрудник обработал её, руководитель согласовал, клиент оплатил.

Но бизнес ежедневно сталкивается с ситуациями, которые не укладываются в прямую последовательность.

Например:

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

Для каждой существенной ситуации нужно определить действие.

Что система делает автоматически?

Когда она должна остановить процесс?

Кому отправляется уведомление?

Может ли сотрудник продолжить работу вручную?

Как потом обработать незавершённую операцию?

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

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

Зафиксируйте, откуда берутся данные

Практически любая автоматизация работает с информацией.

Поэтому для каждого важного поля или документа полезно ответить на три вопроса:

Откуда данные появляются?

Например, клиент вводит их в форму, менеджер получает по электронной почте или другая система передаёт их автоматически.

Где они хранятся?

CRM, ERP, бухгалтерская система, база данных, таблица или другой источник.

Какая система считается основной?

Если адрес клиента отличается в CRM и системе выставления счетов, автоматизация должна знать, каким данным доверять.

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

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

Найдите узкое место до автоматизации

Описание процесса полезно ещё по одной причине: оно показывает, что именно стоит автоматизировать.

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

Можно автоматизировать перенос данных и сэкономить сотруднику несколько минут.

Но основная задержка останется.

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

Здесь сначала нужно определить правило работы, а уже потом автоматизировать его.

Поэтому перед разработкой полезно спрашивать:

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

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

Как понять, что процесс пока рано автоматизировать

Иногда результат правильного анализа — решение пока не разрабатывать систему.

Это разумно, если сотрудники не договорились, как должен работать процесс.

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

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

Другой признак — постоянные ручные исключения.

Если практически каждая сделка требует вмешательства руководителя и решения «по ситуации», возможно, сначала нужно стандартизировать правила.

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

Если правила невозможно сформулировать даже людям, передавать их системе рано.

Когда достаточно текста, а когда нужна схема BPMN

Не каждый процесс нужно сразу превращать в сложную диаграмму.

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

BPMN или другая формальная схема становится полезнее, когда:

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

Поэтому вопрос не в том, «нужен ли BPMN вообще».

Нужно выбрать уровень формальности, который соответствует сложности задачи.

Текущая версия статьи правильно исходит из того, что начинать можно с простого описания триггера, входов, действий, результата и ролей.

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

Описание процесса ещё не является полноценным техническим заданием.

Но после хорошей подготовки значительно проще определить объём проекта.

Для каждого участка уже можно решить:

Что остаётся ручным.
Например, переговоры с клиентом.

Что автоматизируется.
Создание карточки, распределение заявки, уведомления, изменение статуса.

Что требует интеграции.
Например, получение данных из формы сайта или передача информации в другую систему.

Какие права нужны каждой роли.
Кто может только просматривать данные, кто изменять, кто согласовывать.

Как проверить правильность работы.
Для каждой функции формулируется ожидаемый результат.

Например:

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

Это значительно полезнее требования «добавить в CRM проверку заявки», потому что разработчик понимает ожидаемое поведение системы.

Проверка перед передачей процесса разработчику

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

Пройдите описание от первого шага до последнего и последовательно задайте вопросы:

1. Что запускает процесс?
2. Кто получает первый сигнал?
3. Какие данные ему нужны?
4. Что он делает?
5. Как понимает, что действие выполнено правильно?
6. Что происходит дальше?
7. Где принимается решение?
8. По какому правилу?
9. Что произойдёт, если обычный сценарий нарушится?
10. Где сохраняется результат?

Особенно полезно спросить сотрудников: «А что происходит в реальной работе, когда всё идёт не по плану?»

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

Каким должно быть хорошее описание процесса

Хороший документ не обязан быть длинным.

Он должен позволять человеку, который не работает внутри вашего отдела, понять:

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

После этого уже можно обсуждать CRM, интеграции, автоматические уведомления, генерацию документов, AI или собственную разработку.

Но последовательность лучше не менять.

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

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