Как составить карту процесса согласования документов: пошаговое руководство

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

Зачем нужна карта согласования и чем она отличается от регламента

Регламент описывает правила текстом: сроки, роли, порядок эскалации. Карта — это визуальная модель потока. Она отвечает на вопросы «что происходит дальше?» и «кто отвечает за этот шаг?» за секунды, не требуя перечитывания трёх страниц текста. Главная польза карты — сделать неявные соглашения явными. Часто оказывается, что юристы смотрят договор после финансового директора, хотя логичнее наоборот, или что технический директор согласует коммерческие условия, которых не должен касаться.

Карта нужна, когда:

• Согласование занимает больше установленных сроков, и непонятно, на каком этапе застревает.
• Новые сотрудники не понимают, кому отправлять документ и в каком порядке.
• Документы возвращаются на доработку по одной и той же причине снова и снова.
• Внедряется ЭДО или BPM-система — без карты настроить маршруты невозможно.
• Проходит аудит или сертификация (ISO 9001, SOC 2 и др.), требующая документированных процессов.

Если в компании 2–3 типа документов и согласование линейное (автор → руководитель → директор), формальная карта может быть избыточной — достаточно чёткого регламента. Карта становится необходимой при ветвлении, параллельных потоках, условных переходах или участии более 4–5 ролей.

Подготовка: что собрать перед рисованием

Не начинайте рисовать схему в редакторе до того, как соберёте фактическую информацию. Иначе получите идеальную карту несуществующего процесса.

1. Перечень типов документов

Составьте список всех документов, проходящих согласование: договоры, сметы, технические задания, внутренние приказы, платежные поручения, HR-документы. Для каждого типа укажите: инициатор, критичесность, типичный срок, правовые риски. Часто оказывается, что «договор» — это пять разных подтипа с разными маршрутами.

2. Реальные участники и их роли

Поговорите с инициаторами и согласующими. Спросите: «Кому вы отправляете сейчас?», «Кто может поставить вето?», «Есть ли кто-то, кто согласует «неофициально» по чату?». Зафиксируйте не только должности, но и конкретных сотрудников с замещением. Роль — это не «Иванов», а «юридический советник по договорной работе».

3. Текущие маршруты (как есть)

Проследите 5–10 реальных документов каждого типа от создания до подписи. Зафиксируйте: последовательность этапов, время на каждом, количество итераций возврата, причины возвратов. Это даст базу для выявления узких мест.

4. Критерии принятия решений

На каждом этапе согласующий принимает решение: согласовать / вернуть на доработку / отклонить / эскалировать. Уточните, по каким критериям: чек-лист, экспертиза, пороговые суммы, наличие рисков. Если критериев нет — согласующий работает по интуиции, и процесс непредсказуем.

5. Сроки и SLA

Каковы нормативные сроки на этап? Есть ли эскалация при просрочке? Кто контролирует дедлайны? Без временных параметров карта бесполезна для управления.

Выбор нотации и инструмента

Для карт согласования достаточно двух нотаций: BPMN 2.0 (стандарт де-факто для автоматизации) и блок-схемы (flowchart) — для ручного использования и презентаций. Не смешивайте их на одной схеме.

Критерий	BPMN 2.0	Блок-схема (Flowchart)
Сложность изучения	Средняя (нужно знать элементы: пулы, дорожки, шлюзы, события)	Низкая (прямоугольники, ромбы, стрелки)
Выразительность для ветвлений	Высокая (исключительные, параллельные, включительные шлюзы)	Ограничена (только ромбы с да/нет)
Поддержка в BPM/ЭДО	Прямой импорт в Camunda, ProcessMaker, ELMA, Bitrix24, Directum	Требует перерисовки в системе
Читаемость для бизнеса	Требует обучения	Интуитивно понятна
Рекомендация	Если планируется автоматизация или аудит	Для внутреннего использования, обучения, быстрой диагностики

Инструменты: draw.io (бесплатно, поддерживает BPMN), Lucidchart, Miro, Visio, Bizagi Modeler (бесплатно для BPMN), Camunda Modeler. Для командной работы выбирайте облачные редакторы с версионированием.

Пошаговое построение карты

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

Чётко зафиксируйте событие старта (например, «Загрузка проекта договора в ЭДО инициатором») и событие окончания («Документ подписан всеми сторонами и зарегистрирован в журнале»). Все, что до старта и после финиша — вне границ этой карты.

Шаг 2. Выделите дорожки (swimlanes) по ролям, не по именам

Каждая горизонтальная дорожка — одна роль (функция): «Инициатор», «Юридический департамент», «Финансовый директор», «Технический эксперт», «Генеральный директор». Не создавайте дорожку под конкретного человека — при смене сотрудника карту придётся перерисовывать.

Шаг 3. Расставьте действия (задачи) в хронологическом порядке

В BPMN это прямоугольники с закруглёнными углами (User Task / Service Task). В блок-схеме — прямоугольники. Название задачи — глагол + объект: «Проверить юридические риски», «Согласовать коммерческие условия», «Подписать оригинал». Избегайте названий вроде «Работа с договором» — они не несут информации.

Шаг 4. Добавьте шлюзы (точки принятия решений)

В BPMN — ромбы (Exclusive Gateway для выбора одного пути, Parallel Gateway для параллельного выполнения). В блок-схеме — ромбы с вопросительным условием. Подписывайте исходящие стрелки: «Да / Нет», «Согласовано / На доработку / Отклонено», «Сумма < 1 млн / Сумма ≥ 1 млн».

Типичные точки ветвления в согласовании:

• Пороговые суммы: до 100 тыс. — только руководитель отдела, выше — финдиректор, выше 5 млн — гендиректор.
• Тип документа: договор поставки / оказания услуг / агентский — разные наборы согласующих.
• Наличие рисков: юрист выявил риск — на эскалацию к руководителю юротдела; рисков нет — сразу к финдиректору.
• Результат проверки: согласовано / возвращено на доработку / отклонено.

Шаг 5. Обозначьте циклы возврата (rework loops)

Это критически важный элемент. Стрелка от решения «На доработку» должна возвращаться к инициатору (или автору правок) с указанием, что именно меняется. В BPMN это цикл через Exclusive Gateway обратно к задаче инициатора. Обязательно укажите максимальное число итераций (обычно 2–3) и что происходит при превышении — эскалация или отказ.

Шаг 6. Добавьте события-таймеры и эскалации

Если согласующий не реагирует в течение SLA (например, 2 рабочих дня), процесс должен двигаться дальше: напоминание → эскалация к руководителю согласующего → автоматическое согласование (если разрешено политикой) / отклонение. В BPMN используйте Boundary Timer Event на задаче согласования.

Шаг 7. Зафиксируйте артефакты и данные

Каждая задача оперирует данными: чек-лист согласования, отчёт экспертизы, протокол разногласий, подписанный PDF. В BPMN это Data Object, связанные с задачами пунктирными стрелками. Это поможет потом настроить формы в ЭДО.

Шаг 8. Валидируйте карту с участниками

Пройдитесь по схеме с каждым согласующим: «Вот ваш этап. Вы получаете документ сюда. Проверяете это и это. Если ок — жмёте «Согласовать», идёт дальше к такому-то. Если не ок — «На доработку», уходит инициатору. Верно?». Исправьте расхождения до внедрения.

Типовые паттерны маршрутов согласования

Не изобретайте велосипед. 80% процессов строятся на комбинации нескольких базовых паттернов. Распознайте свой случай и адаптируйте.

1. Линейный (последовательный)

Инициатор → Роль 1 → Роль 2 → … → Подписант. Подходит для низкорисковых документов с чёткой иерархией. Риск: затор на любом звене блокирует весь процесс.

2. Параллельный (одновременный)

После инициатора документ уходит сразу нескольким согласующим (юрист, финдиректор, техэксперт). Все работают независимо. Процесс ждёт завершения всех веток (Parallel Gateway — Join). Ускоряет процесс, но требует чётких критериев у каждого, иначе собирают противоречивые правки.

3. Условный (по порогам/типам)

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

4. С предварительной экспертизой (pre-screening)

Инициатор → Координатор/Секретарь (проверка комплекта, оформления, обязательных реквизитов) → только потом к экспертам. Снимает 30–50% возвратов по формальным причинам.

5. С обязательным протоколом разногласий

Если юрист или финдиректор ставит «На доработку», процесс не просто возвращается к инициатору, а требует заполнения структурированного протокола: пункт документа / замечание / предложение / решение (принято/отклонено). Это дисциплинирует стороны и создаёт аудит-трейл.

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

Перед утверждением проверьте карту по пунктам. Если хоть один пункт не выполнен — карта не готова к внедрению.

• Единая точка входа и единая точка выхода (или явно описанные альтернативные выходы: «Отклонён», «Отозван инициатором»).
• У каждой задачи есть ответственная роль (не имя).
• У каждого шлюза подписаны все исходящие потоки условиями, покрывающими 100% случаев (нет «иначе» без описания).
• Циклы возврата имеют ограничение по итерациям и выход при превышении.
• На задачах с риском зависания навешаны таймеры эскалации.
• Параллельные ветки имеют явную точку синхронизации (Join).
• Артефакты (чек-листы, протоколы, подписи) привязаны к задачам.
• Карта проходит «тест на новичка»: человек, не участвовавший в разработке, может пройти по схеме и объяснить, что делает на каждом шаге.
• Версия карты, дата, автор и статус (Черновик / На согласовании / Утверждена / Архив) указаны на схеме или в свойствах файла.

Частые ошибки и как их избежать

Ошибка	Последствие	Как исправить
Рисуют «как должно быть», игнорируя «как есть»	Карта не соответствует реальности, сотрудники её игнорируют	Сначала зафиксируйте текущий процесс (as-is), потом проектируйте целевой (to-be) с обоснованием изменений
Слишком детализированные задачи («Проверить пункт 3.1», «Проверить пункт 3.2»)	Схема нечитаемая, в ЭДО создаются лишние этапы	Объединяйте в одну задачу «Юридическая экспертиза» с прикреплённым чек-листом; детали — во вложении, а не на схеме
Отсутствие ветки «Отклонено»	Документ висит бесконечно, если согласующий против	Всегда добавляйте выход «Отклонён» с уведомлением инициатора и фиксацией причины
Параллельные ветки без синхронизации	Процесс уходит дальше, пока один из согласующих ещё не закончил	Обязателен Parallel Gateway Join перед следующим этапом
Роли дублируются (юрист и юрисконсульт в разных дорожках делают одно)	Двойная работа, конфликты, неясная ответственность	Объедините в одну роль или чётко разделите зоны ответственности (например, «Юридическая экспертиза рисков» / «Проверка соответствия типовым формам»)
Нет версионирования карты	В ЭДО загружена старая версия, сотрудники работают по разным схемам	Храните карту в системе управления документами с версиями; в ЭДО загружайте только утверждённые релизы
Игнорируют замещение (отпуска, болезни)	Процесс встаёт при отсутствии ключевого согласующего	В свойствах роли укажите замещающего; в BPMN — используйте Candidate Groups вместо конкретных пользователей

Внедрение: от карты к работающему процессу

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

1. Пилот. Выберите 1–2 типа документов, загрузите маршрут в ЭДО/BPM в тестовой среде. Прогоните 10–20 реальных документов. Замерьте время цикла, количество возвратов, загрузку согласующих.
2. Сбор обратной связи. Опросите участников пилота: что мешает, что неясно, где не хватает информации. Внесите правки в карту и настройки системы.
3. Обучение. Краткая инструкция (1–2 страницы) для каждого участника: «Что я делаю», «Какие кнопки жму», «Куда пишу комментарии», «Что если не согласен», «Кому пишу, если зависло».
4. Перевод в прод. Поэтапно включайте типы документов. Не переводите всё сразу — риск сбоя слишком высок.
5. Мониторинг первых 2–3 месяцев. Еженедельно смотрите дашборд: среднее время цикла, % просрочек, % возвратов, топ узких мест. Вносите коррективы в карту и SLA.

Как поддерживать карту актуальной

Процессы меняются: появляются новые типы документов, меняется структура отделов, вводятся новые нормы закона. Установите правило: карта пересматривается раз в полгода или при триггере (реорганизация, новый вид деятельности, смена ЭДО, результаты аудита). Ответственный за актуальность — процессный владелец (process owner), а не автор карты. Заведите журнал изменений: версия / дата / что изменилось / почему / кто утвердил.

Сценарии: как адаптировать карту под ваши условия

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

• Малый бизнес (до 50 человек, 3–4 типа документов). Блок-схема в draw.io, линейные маршруты с 1–2 условными ветками. ЭДО не обязательна — достаточно почты/облака с правилом именования файлов. Карта служит обучающим материалом для новичков.
• Средняя компания (100–500 человек, ЭДО есть). BPMN в корпоративном репозитории. Маршруты настроены в ЭДО (Directum, 1С:Документооборот, Bitrix24, Диадок). Есть предэкспертиза секретарем, параллельные ветки юрист/финансы/техэксперт, пороговые суммы, таймеры эскалации. Процессный владелец — руководитель ДО или QMS-менеджер.
• Холдинг / крупная корпорация (филиалы, дочерние общества). Единая карта-шаблон + локальные вариации. В BPMN — подпроцессы (Call Activity) для типовых фрагментов (юридическая экспертиза, финансовая экспертиза). Централизованное управление шаблонами маршрутов, локальные администраторы только настраивают параметры (пороги, роли). Аудит трасс — обязателен.
• Проектная организация (строительство, IT, инженерия). Согласование привязано к этапам проекта (ТЗ → ЭП → Смета → Договор). Карта включает шлюзы по этапам проекта и ролевую матрицу RACI. Часто требуется согласование заказчиком (внешний участник) — в BPMN это отдельный пул (Pool) с сообщениями (Message Flow).

Практический следующий шаг

Начните с инвентаризации: за 30 минут составьте таблицу «Тип документа — Инициатор — Текущий маршрут (как есть) — Боль (сроки, возвраты, споры)». Это даст понимание, какие процессы болит больше всего. Выберите один самый проблемный тип и постройте для него карту as-is. Потом — to-be с устранением выявленных проблем. Не пытайтесь охватить всё сразу.

Главный принцип: карта согласования — живой инструмент управления, а не артефакт для аудитора. Если она не помогает сократить время цикла и число итераций — её нужно менять, а не формально утверждать.

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

FAQ

Нужно ли рисовать отдельную карту для каждого типа документа?

Если маршруты принципиально отличаются (разные роли, разные шлюзы, разные артефакты) — да, отдельные карты понятнее. Если отличаются только пороговыми значениями — удобнее одна параметризованная карта с таблицей правил маршрутизации в приложении. В BPMN это реализуется через Business Rule Task или DMN-таблицу решений.

Как отобразить согласование «в копию» (для информации, без права вето)?

В BPMN — отдельная дорожка с задачей типа «Service Task» или «User Task» без исходящего шлюза решения (только «Принят к сведению»), либо параллельная ветка, не блокирующая основной поток (Non-Interrupting Boundary Event). В блок-схеме — параллельный прямоугольник с пометкой «В копию» и стрелкой, не влияющей на основной Join.

Что делать, если согласующий требует правок, выходящих за его компетенцию?

Это организационная проблема, а не графическая. В карте зафиксируйте: у задачи согласующего есть чек-лист зоны ответственности. Правки вне чек-листа — основание для эскалации к процессному владельцу. Внедрите правило: «Комментарий без ссылки на пункт чек-листа не считается основанием для возврата».

Как обработать ситуацию, когда документ согласован всеми, но генеральный директор не подписывает неделю?

На задаче «Подписание генеральным директором» навесьте Boundary Timer Event (например, 3 рабочих дня). По истечении — эскалация к заместителю или секретарю СД для включения в повестку совещания / напоминание через ассистента. В карте это отображается как альтернативный исходящий поток от таймера.

Стоит ли включать в карту этапы после подписания (регистрация, отправка контрагенту, архивирование)?

Если эти этапы выполняются теми же участниками в рамках единого процесса — да, включите до точки «Документ в архиве / у контрагента». Если это отдельный процесс (работа архивиста, логистика оригиналов) — вынесите в отдельную карту «Пост-согласование» и свяжите через событие «Согласование завершено».