Картирование бизнес-процесса перед автоматизацией — это описание того, как работа в действительности проходит от запускающего события до проверяемого результата. Полезная карта показывает не только основную последовательность действий. В ней обозначены ответственные роли, данные и системы, правила принятия решений, передача работы между участниками и порядок действий в нестандартных ситуациях. Без этой информации автоматизация чаще ускоряет существующий беспорядок, чем устраняет его.
Карта процесса не обязательно должна быть сложной диаграммой. Для небольшого процесса достаточно понятного реестра этапов и простой схемы потока. Важнее согласовать границы, назначить одного владельца процесса и проверить описание на реальных случаях. Только после этого можно обоснованно решить, какие действия автоматизировать, где сохранить участие человека и как система должна обрабатывать исключения.
Почему картирование должно предшествовать техническому решению
Автоматизация многократно и последовательно выполняет заданную логику. Если логика не определена, техническое решение строится на предположениях. Уже во время разработки обнаруживаются дополнительные согласования, источники данных, особые случаи клиентов и неформальные правила, о которых знал только один сотрудник. Требования начинают меняться, стоимость растёт, а проверить правильность работы системы становится трудно.
Процессный подход рассматривает компанию как систему взаимосвязанных процессов, а не как набор изолированных задач. Для автоматизации это принципиально: изменение одного этапа может перенести нагрузку в другой отдел, добавить проверку данных или повлиять на клиентский опыт. Ускорение отдельной операции ещё не означает улучшения конечного результата.
Цель картирования — не записать каждый щелчок мыши. Карта должна давать достаточно точный ответ на семь вопросов:
- что запускает процесс и где он заканчивается;
- какой бизнес-результат он создаёт;
- какие действия и решения составляют стандартный маршрут;
- какая роль отвечает за каждую часть работы;
- какие данные поступают, изменяются и передаются дальше;
- какие исключения меняют ход процесса;
- по каким показателям будет оцениваться улучшение.
Если у участников нет общего ответа на эти вопросы, составлять техническое задание на автоматизацию ещё рано.
Сначала определите границы процесса и результат
Слишком широкая карта быстро становится непрактичной. «Обслуживание клиентов» или «обработка счетов» — недостаточно точные границы. Лучше определить процесс от конкретного начального события до конкретного конечного состояния.
Для согласования счетов началом может быть получение документа от поставщика через установленный канал. Завершение может иметь три варианта: счёт согласован и готов к учёту, отклонён с указанием причины или возвращён на уточнение. Такие границы показывают, что входит в автоматизацию, а что остаётся за её пределами.
Результат следует описать с позиции его получателя. «Счёт перемещён в следующую папку» — действие системы. «Согласованный счёт с полными учётными данными доступен для проведения к установленному сроку» — проверяемый результат.
В начале карты зафиксируйте:
- название процесса;
- запускающее событие;
- возможные конечные состояния;
- получателя результата;
- владельца процесса;
- главный показатель качества, времени или стоимости;
- действия, сознательно исключённые из охвата.
Это соглашение не позволяет разным участникам вкладывать разный объём работы в одно и то же название процесса.
Описывайте фактическую, а не идеальную работу
Во время обсуждения сотрудники часто рассказывают об официальном порядке. В повседневной работе всё может происходить иначе: сведения запрашивают в чате, устное согласие заменяет запись, данные переписывают в личную таблицу, а срочные случаи идут в обход очереди. Для автоматизации нужен фактический, а не декларируемый маршрут.
Возьмите один или несколько недавно завершённых случаев и проследите их от начала до конца. Откройте использованные письма, записи в системах, документы и историю статусов. Спрашивайте не только «что происходит дальше?», но и:
- что сотрудник получает перед этим этапом;
- что именно он проверяет;
- какое решение принимает;
- что создаёт или изменяет;
- кому передаёт результат;
- где и почему работа ожидает продолжения;
- как он действует при отсутствии нужной информации.
Если реальная практика расходится с регламентом, сначала зафиксируйте это расхождение. Иногда следует изменить сам порядок работы, а не программировать систему, повторяющую неформальный обходной путь.
Описывайте этапы на одном уровне детализации
Этап процесса должен быть завершённым действием с видимым результатом. «Обработать заявку» — слишком широкая формулировка. Её можно разделить на проверку обязательных полей, определение категории заявки, выбор ответственной команды, создание записи в CRM и отправку подтверждения о получении.
При этом не стоит разбивать каждое действие на щелчки по экрану до выбора конкретного решения. Карта описывает бизнес-работу. Подробный сценарий интерфейса появляется позже — в пользовательском потоке или спецификации реализации.
Для каждого этапа используйте одинаковую структуру:
- Действие. Что именно выполняется; формулировку лучше начинать с глагола.
- Исполнитель. Роль человека, система или внешний участник.
- Вход. Информация или событие, необходимые для начала.
- Результат. Что создано, изменено или согласовано.
- Система. Где фиксируются действие и его результат.
- Правило. Какие условия влияют на выполнение или дальнейший маршрут.
- Время. Сколько занимает работа и сколько случай обычно ожидает.
В дальнейшем этот реестр станет основой требований, тестовых сценариев и критериев приёмки.
Покажите роли, ответственность и точки передачи
Многие задержки возникают не внутри действия, а при переходе работы от одного человека или подразделения к другому. Поэтому на карте полезно использовать дорожки, или swimlanes, разделяющие роли и системы. Каждое пересечение границы между дорожками — точка передачи, которую стоит проверить отдельно.
У процесса должен быть один владелец. Он отвечает за конечный результат и работу процесса в целом, хотя не обязан выполнять все действия. Для каждого этапа указывается исполнитель и, при необходимости, согласующий. Не превращайте консультируемых сотрудников в скрытых согласующих. Иначе случай будет ждать человека, чьи полномочия на принятие решения нигде не определены.
В каждой точке передачи зафиксируйте четыре вещи: что передаётся, кто принимает, как получатель узнаёт о новой работе и как проверяет полноту входных данных. Автоматическое уведомление бесполезно, если непонятно, кто принял задачу и к какому сроку она должна быть выполнена.
Рассматривайте данные как часть процесса
Автоматизация компании часто останавливается не из-за схемы потока, а из-за данных. У одного клиента несколько идентификаторов, обязательное поле пустует, сумма хранится как текст, или две системы одновременно считаются главным источником. Поэтому данные нужно описывать вместе с этапами.
Для каждого существенного набора данных определите:
- название и бизнес-смысл;
- источник и авторитетную систему учёта;
- обязательные и необязательные поля;
- формат и допустимые значения;
- проверки перед использованием;
- права на просмотр и изменение;
- место и срок хранения результата;
- дальнейшего получателя данных.
Небольшому процессу не нужен полный корпоративный каталог данных. Но поля, влияющие на решения, платежи, статус клиента, налогообложение или права доступа, должны быть описаны однозначно. Иначе разработчикам придётся выводить бизнес-правила из старых файлов и отдельных примеров.
Превратите точки решений в явные бизнес-правила
Ромб с вопросом «всё в порядке?» не является полноценным требованием. Системе нужно проверяемое правило: какие поля оцениваются, какие пороги применяются, какой источник считается достоверным и что делать при конфликте условий.
Маршрут согласования счёта может зависеть от суммы, центра затрат, статуса поставщика, наличия заказа на закупку и лимита договора. У каждого правила должен быть бизнес-владелец. Если руководитель финансов меняет порог согласования, должно быть понятно, где это правило управляется и как изменение будет протестировано.
Отделяйте бизнес-правило от технической реализации. «Если сумма превышает порог, требуется дополнительное согласование» — бизнес-правило. Конкретная таблица базы данных, вызов API или блок условия в платформе автоматизации — выбор реализации.
Проектируйте исключения так же тщательно, как основной маршрут
Основной поток обычно прост. Сложность появляется в исключениях. Если их нет на карте, после запуска сотрудники начинают вручную исправлять данные, создавать параллельные таблицы или направлять разработчикам цепочку якобы небольших доработок.
Полезно разделить ситуации на три вида:
- Бизнес-исключение: случай корректен, но требует другого маршрута, например новый поставщик или необычно крупная сумма.
- Исключение данных: обязательной информации нет, значения противоречат друг другу или запись может быть дубликатом.
- Технический сбой: система недоступна, соединение завершается по timeout или внешний сервис отклоняет запрос.
Для каждого существенного исключения укажите условие обнаружения, ответственного, безопасное временное состояние, уведомление, срок решения и точку возврата в основной поток. Также должно быть ясно, можно ли повторить операцию и как предотвратить дублирование.
Реестр исключений не должен предсказывать абсолютно всё. Начните со случаев, которые регулярно отнимают время сотрудников, создают финансовый или юридический риск, затрагивают клиента или способны остановить весь поток. Редкие случаи с низким риском можно сознательно оставить для ручной обработки.
Выберите подходящий формат карты
Формат зависит от сложности процесса и аудитории. Для простого процесса внутри одной команды достаточно таблицы этапов и небольшой блок-схемы. Если участвует несколько ролей и работа часто передаётся между ними, полезна swimlane-диаграмма. Для процессов с большим количеством событий, параллельных маршрутов, сообщений и подпроцессов можно использовать BPMN — стандартизированную нотацию моделирования бизнес-процессов.
BPMN даёт точный язык для событий, действий, шлюзов решений, участников и потоков сообщений. Но начинать с полного набора символов необязательно. Карта должна помогать бизнесу и технической команде одинаково понимать процесс. Если читатель не может объяснить её без автора, нотация стала важнее содержания.
На практике часто нужны два связанных артефакта: визуальная карта для общего понимания и подробный реестр этапов, данных, правил и исключений для разработки.
Практический пример автоматизации: согласование счёта поставщика
Начало процесса: счёт поступил на установленный адрес электронной почты или через канал электронных счетов. Завершение: документ с нужными учётными данными согласован, отклонён или отправлен на уточнение.
Основной маршрут может выглядеть так:
- Система регистрирует документ и проверяет формат файла.
- Извлекаются данные поставщика, номер и дата счёта, сумма и срок оплаты.
- Система проверяет возможный дубликат и сопоставляет поставщика с реестром компании.
- Ответственный сотрудник добавляет центр затрат, проект или ссылку на заказ.
- Счёт направляется согласующему в соответствии с правилами.
- После согласования данные и документ передаются в бухгалтерскую систему.
Одного этого списка недостаточно. Нужно описать действия для нового поставщика, превышения лимита договора, отсутствующего заказа, несовпадающих налоговых данных, повторной подачи счёта и отсутствия согласующего. Следует также определить достоверный источник реквизитов поставщика и систему, в которой хранится окончательное согласование.
Именно эти детали превращают общую идею автоматизации в процесс, который можно разработать и протестировать.
Проверьте карту на реальных сценариях
До начала разработки пройдите процесс вместе с его участниками. Используйте обычный случай, срочный случай, неполные данные и несколько наиболее важных исключений. На каждом этапе проверяйте, известны ли вход, ответственный, правило решения и следующее состояние.
В проверке должен участвовать не только руководитель. Сотрудники, ежедневно выполняющие работу, знают реальные обходные маршруты и недостатки данных. Представитель IT или разработки заметит неясные границы систем, недостаточные права доступа и действия, после которых не остаётся проверяемого следа.
Завершите проверку списком открытых вопросов. У каждого вопроса должны быть владелец и срок решения. Видимый открытый вопрос управляем. Опасно скрытое предположение, которое уже во время разработки превращается в новое требование.
Когда процесс готов к проекту автоматизации
Процесс не обязан быть идеальным до начала разработки. Он должен быть достаточно понятным, стабильным и измеримым. Перед передачей технической команде проверьте:
- границы и результат процесса понимаются одинаково;
- текущий поток подтверждён реальными случаями;
- у этапов есть исполнители, входы и результаты;
- правила решений сформулированы в проверяемом виде;
- для существенных данных известны источники и требования к качеству;
- у важных исключений есть ответственный и безопасный резервный маршрут;
- определены исходные показатели и ожидаемое улучшение;
- явно обозначены точки согласования человеком;
- учтены требования к доступу, персональным данным и аудиту;
- владелец процесса будет принимать готовое решение.
После картирования нередко выясняется, что некоторые действия можно удалить, объединить или стандартизировать. Это полезный результат. Нет смысла автоматизировать работу, которая больше не нужна процессу.
Карта процесса — это соглашение, а не только диаграмма
Хорошая карта соединяет потребность бизнеса с технической реализацией. Она показывает не только идеальную последовательность, но и ответственность, движение данных, основания для решений и действия в случае отклонения от стандарта.
Начните с границ и результата. Затем опишите реальный поток на одном уровне детализации, выделите точки передачи, назовите достоверные источники данных и превратите расплывчатые решения в проверяемые правила. Не откладывайте исключения до конца разработки: именно они часто определяют, сможет ли система работать в повседневной жизни.
После проверки общей модели на реальных сценариях автоматизация бизнес-процессов становится предсказуемее. Техническая команда понимает, что разрабатывать и тестировать, а владелец процесса получает конкретную основу для оценки того, действительно ли готовое решение улучшает работу.
