Хорошее описание процесса показывает реальный путь задачи: от события на входе до принятого результата, включая людей, данные, решения и исключения.
Рассмотрим условный пример. Оптовая компания решила автоматизировать обработку заявок. В презентации процесс выглядел просто: письмо клиента поступает в почту, система извлекает позиции, менеджер получает готовый заказ в CRM.
На первой рабочей неделе выяснились детали. Клиенты присылают разные форматы, дефицитные позиции требуют подтверждения закупок, а бухгалтерия принимает заказ после проверки реквизитов.
Автоматизация столкнулась с тем, чего на схеме не было. У компании существовал реальный процесс с ветвлениями, ручными решениями и неявными правилами. Его краткая версия описывала только удобный маршрут.
Описание бизнес-процесса перед автоматизацией строится по наблюдаемой работе. Схема должна отвечать на четыре вопроса: что происходит, кто принимает решение, какие данные используются и как понять, что результат принят.
Установите границы процесса одним событием и одним результатом
Фраза «автоматизировать продажи» охватывает слишком много разных потоков. Выберите конкретный отрезок, который можно проследить от начала до конца.
Примеры границ:
- от поступления заявки до назначения ответственного менеджера;
- от заполненного брифа до согласованного коммерческого предложения;
- от записи звонка до карточки контроля качества;
- от запроса сотрудника до подтверждённого ответа из базы знаний.
Старт процесса — наблюдаемое событие. Результат — состояние, которое можно проверить. «Клиент написал» подходит как старт. «Менеджер работает с заявкой» описывает деятельность и оставляет границу открытой. Более точный результат звучит так: «заявка классифицирована, ответственный назначен, срок первого ответа зафиксирован».
Запишите получателя результата: он задаёт требования к полноте, формату и сроку.
Снимите текущий процесс по фактам
Регламент показывает задуманную последовательность. Для карты текущего состояния нужны реальные случаи: завершённые задачи, журналы систем, переписка, версии документов и наблюдение за сотрудниками.
Возьмите несколько примеров с разными исходами. Проследите каждый от старта до результата: кто выполнял шаг, какую систему открыл, сколько задача работала и ждала, где её вернули и какое решение изменило маршрут.
Интервью стройте вокруг последнего конкретного случая: «Что вы открыли первым?», «Откуда взяли значение?», «Как поняли, что можно отправлять дальше?». Lean Enterprise Institute рекомендует отображать текущее состояние вместе с материальным и информационным потоком. В офисном процессе на карте появляются документы, сообщения, поля систем и ожидания.
Запишите шаги языком наблюдаемых действий
Каждый шаг формулируйте через глагол и объект: «менеджер проверяет реквизиты по карточке контрагента», «руководитель подтверждает скидку выше порога», «система создаёт задачу с датой первого контакта». Общие формулировки скрывают данные и критерий завершения.
Для первого описания достаточно таблицы:
| Поле | Что фиксировать |
|---|---|
| Шаг | Конкретное действие |
| Исполнитель | Роль или система |
| Вход | Данные, документ, событие |
| Выход | Проверяемый результат шага |
| Правило | Условие выполнения или решения |
| Система | Где выполняется действие |
| Время | Работа и ожидание отдельно |
| Исключение | Причина другого маршрута |
Диаграмму можно построить после заполнения таблицы. Нотация BPMN стандартизирует события, задачи, шлюзы и потоки и помогает общаться бизнесу с технической командой. Для небольшого внутреннего сценария часто хватает простой блок-схемы при условии, что роли, решения и исключения читаются однозначно.
Разделите работу, ожидание и передачу
Отмечайте рабочее время, ожидание и повторную работу отдельно. Ускорение десятиминутного действия даст небольшой эффект, если задача сутки лежит между отделами. Ручной перенос десятков полей, напротив, может оказаться сильным кандидатом.
Microsoft описывает процесс-карту через действия и переходы, которые позволяют анализировать маршруты, время и повторную работу. Для внутренней диагностики достаточно связать каждый шаг с наблюдаемым показателем.
Найдите решения, которые сотрудники держат в голове
Самая важная часть процесса часто выглядит как короткая пауза перед следующим действием. Сотрудник смотрит на данные и решает: подтвердить, вернуть, уточнить, передать руководителю или выбрать другой шаблон.
Для каждого такого места запишите:
- какие варианты решения существуют;
- какие данные использует сотрудник;
- где хранится правило;
- кто имеет право принять решение;
- как фиксируется основание;
- что происходит при недостатке данных.
Условный пример: менеджер выбирает тип предложения по отрасли клиента, составу закупки, доступности товара и уровню скидки. Эти признаки нужно записать для автоматизации маршрута.
Правило можно представить таблицей решений. В строках указываются условия, в столбце результата — действие. Сложные случаи помечаются как зона экспертного решения и остаются в человеческом контуре.
Исключения показывают настоящий объём проекта
Удобный маршрут называют happy path: данные заполнены, системы доступны, участники отвечают вовремя. Автоматизация, построенная только вокруг такого случая, быстро накапливает ручные обходы.
Соберите из истории задач случаи с пропущенными полями, расхождением источников, новым форматом файла, превышением полномочий и ошибкой интеграции. Для каждого назначьте маршрут, срок и ответственного: запросить сведения, поставить в очередь, остановить или вернуть.
Редкие случаи можно оставить для ручной обработки. Журнал покажет, какие маршруты повторяются достаточно часто для следующей версии.
Опишите данные как отдельный слой
Карта шагов должна сопровождаться реестром данных. Для каждого поля или документа укажите источник, владельца, формат, обязательность, частоту обновления, конфиденциальность, место хранения и правило проверки.
Условный пример: название товара встречается в письме, CRM и учётной системе. Требуется выбрать авторитетный источник и правило сопоставления. Знания из переписки и памяти экспертов переводятся в справочник, критерий либо процедуру эскалации.
Привяжите качество к точкам контроля
Рядом с шагом зафиксируйте объект проверки, критерий приемки, ответственного, способ фиксации и действие при отклонении. Для заявки это корректная категория, заполненные поля и срок ответа. Для документа — совпадение фактов с источниками, структура и согласованная версия.
Чем выше последствия ошибки, тем сильнее контроль. Юридические, финансовые и кадровые решения требуют отдельной оценки риска и чётко назначенной ответственности.
Снимите базовые показатели до изменений
Выберите показатели, связанные с целью: полное и рабочее время, объём очереди, возвраты, ошибки и соблюдение срока. Зафиксируйте период, выборку и источник. При отсутствии статистики обозначьте экспертную оценку и начните сбор фактов во время пилота.
Формулу ожидаемого эффекта тоже стоит записать заранее. Например:
объём задач × изменение времени на задачу × стоимость рабочего часа
Это расчётный ориентир. К нему добавляются затраты на внедрение, лицензии, поддержку, контроль качества и обработку исключений.
Разворот: готовая карта ещё не означает готовность к автоматизации
После описания процесса может выясниться, что технология стоит в конце списка действий. Сначала компании требуется определить единый источник данных, договориться о критерии качества или убрать лишнее согласование.
Автоматизация стабильного фрагмента приносит больше управляемости, чем перенос хаоса в новый интерфейс.
Разделите будущий процесс на четыре типа участков:
- Жёсткое правило. Условие можно выразить однозначно; подходит обычная автоматизация.
- Работа с содержанием. Нужно извлечь, классифицировать, сопоставить или подготовить черновик; здесь возможен AI.
- Экспертное решение. Требуется ответственность, контекст или оценка последствий; решение остаётся у человека.
- Исключение. Данных недостаточно или риск вышел за пределы; задача переходит на отдельный маршрут.
Эта разметка помогает сформировать техническое задание без преждевременного выбора платформы.
Соберите паспорт процесса для команды внедрения
Итоговое описание может занимать несколько страниц. Главное, чтобы в нём были:
- название, цель и владелец процесса;
- старт, завершение и получатель результата;
- карта текущего состояния;
- роли, системы и передачи;
- данные и источники истины;
- правила решений и список исключений;
- критерии качества и точки контроля;
- базовые показатели;
- проблемы текущего потока;
- гипотеза будущего состояния;
- границы первого пилота.
Следующий шаг — выбрать участок с достаточным эффектом по методике первого процесса для AI. Прикладной разбор этой логики есть в гайде об автоматизации коммерческих предложений.
Частые вопросы
Обязательно ли использовать BPMN?
BPMN полезна для сложных процессов и взаимодействия с технической командой. Для первого пилота подойдёт простая схема, если она однозначно показывает события, действия, роли, решения, данные и исключения.
Кто должен описывать процесс?
В работе участвуют владелец процесса, исполнители, представитель смежного отдела и специалист по автоматизации. Владелец принимает границы и критерии результата. Исполнители восстанавливают фактический маршрут.
Вернуться в блог