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

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

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

Определите границы процесса

Начните с двух вопросов: что запускает процесс и какой результат означает его завершение. Границы не должны зависеть от конкретного сотрудника или канала связи.

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

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

Соберите участников, а не только руководителей

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

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

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

Ролевое описание переживает кадровые изменения и позже превращается в понятную модель прав доступа.

Опишите основной маршрут

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

Что происходит на этапе

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

Кто отвечает

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

Какие данные нужны

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

Какое решение принимается

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

Добавьте исключения

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

Проверьте как минимум такие вопросы:

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

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

Найдите потери и спорные места

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

Ищите:

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

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

Нарисуйте целевой маршрут

Целевая карта не обязана копировать текущую. Уберите действия, не создающие ценность, объедините повторяющиеся проверки и определите единый источник данных.

Для каждого автоматического действия задайте основание. Уведомление нужно не потому, что система умеет его отправлять, а потому что участнику требуется вовремя принять решение. Обязательное поле появляется не «для отчётности», а потому что без него следующий этап невозможен.

Что передать исполнителю

Готовый пакет для проектирования автоматизации включает:

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

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

Чек-лист готовности карты

• Начало и конец сформулированы как события.
• У каждого этапа есть результат и ответственная роль.
• Обязательные данные перечислены.
• Условия ветвления можно проверить.
• Описаны возврат, отмена, замещение и срочный маршрут.
• Видны ручные переносы и точки ожидания.
• Целевой процесс проще или прозрачнее текущего.
• Участники подтвердили, что узнают реальную работу.

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