Универсальные согласования в системе: статусы и эскалации

Что значит «универсальные согласования» и почему это важно

Универсальные согласования в системе - это когда один и тот же механизм ведет по маршруту разные документы: заявки, договоры, счета, кадровые приказы, изменения в ИТ, закупки. Меняется не код и не логика, а настройки: кто согласует, в какой последовательности, какие сроки, что делать при просрочке.

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

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

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

Хороший результат выглядит так: один движок, а процессы задаются параметрами. В нем заранее определены общие правила - единая модель статусов и причин возврата, тайм-ауты и эскалации по ролям, отдельный этап подписания с проверками, делегирование без потери ответственности и истории. Тогда добавление нового типа документа становится задачей настройки, а не «переписывания заново».

Базовые сущности: документ, маршрут, шаг и задание

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

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

Маршрут описывает правила движения документа: кто участвует, в каком порядке и при каких условиях. Внутри маршрута есть шаги, а у шага - одно или несколько заданий. Задание всегда адресовано конкретному исполнителю (согласующему или подписанту). Наблюдатель видит ход процесса, но не принимает решений. Администратор настраивает правила и решает исключения.

Минимальный набор объектов обычно такой:

• Документ: данные и итог процесса.
• Маршрут: схема согласования и правила.
• Шаг: логический этап (например, юристы, финансы, безопасность).
• Задание: конкретное действие конкретного человека.
• Решение: результат по заданию (одобрено, отклонено, на доработку) и комментарий.

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

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

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

Статусы: как спроектировать понятную модель

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

Минимальный набор статусов документа

Начните с короткого набора и удерживайте его. Если добавлять статус под каждую роль («у юристов», «у ИБ», «у бухгалтерии»), модель быстро расползется и ее станет трудно поддерживать.

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

Статусы шага и заданий

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

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

Чтобы решения были проверяемыми, храните вместе с каждым переходом:

• причину (комментарий или код причины)
• кто инициировал (пользователь, система, делегат)
• время события
• источник (веб, мобильное, интеграция)

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

Маршруты согласования: последовательность, параллель и правила

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

Типы шагов и как их комбинировать

Шаг маршрута - это «пакет» заданий согласующим. На практике хватает нескольких типовых вариантов, которые можно смешивать в одном маршруте:

• Последовательный шаг: задания идут одно за другим.
• Параллельный шаг: задания уходят всем сразу, шаг закрывается по правилу завершения.
• Смешанный шаг: сначала параллельно (например, эксперты), затем последовательно (руководители).
• Условный шаг: включается только при выполнении условия (сумма, категория, риск).

Хороший прием - задавать шаги не ФИО, а повторяемыми группами. Например, «руководитель подразделения инициатора», «владелец бюджета», «служба ИБ». При запуске система подставляет реальных людей по оргструктуре. Если руководитель сменился, маршруты не нужно переписывать.

Правила завершения шага

Чтобы параллельные шаги не зависали, заранее задайте, что считается «пройдено»:

• Все: нужны ответы от каждого.
• Большинство: достаточно N из M.
• Один ключевой: шаг закрывается, когда согласовал человек с определенной ролью.
• Комбинированное правило: ключевой плюс хотя бы один эксперт.

Пример: для закупки серверов сначала параллельно собирают визы от ИБ и эксплуатации, затем последовательно идут финдиректор и руководитель. Для нового документа (например, акта ввода) вы выбираете другой шаблон маршрута и состав ролей, не добавляя «особую логику».

Тайм-ауты: сроки, напоминания и правила истечения

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

SLA удобно задавать на двух уровнях. SLA шага - общий срок на этап (например, «Финансовое согласование» должно завершиться за 2 рабочих дня). SLA задания - срок на конкретного исполнителя внутри шага (например, каждому из двух согласующих дается по 1 рабочему дню). Так проще управлять параллельными согласованиями и заменами.

Чаще всего достаточно трех типов тайм-аутов: на старт (исполнитель должен взять задание в работу за N часов), на решение (принять решение до дедлайна) и на подпись (отдельный срок, когда нужна ЭЦП или другая форма подписания).

Дальше важнее всего определить, что система делает при истечении срока. Работает подход «сначала мягко, потом жестко»: напоминание, затем эскалация, а авто-решение - только для низких рисков и только по явному правилу. Для критических шагов (например, по безопасности) уместна остановка процесса до решения.

Пример: заявка на поставку серверов для госоргана уходит на согласование. На старт дается 4 часа, на решение - 1 рабочий день. Если срок вышел, система сначала напоминает, через 2 часа эскалирует руководителю. Авто-решения нет, потому что сумма выше лимита.

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

Эскалации: как поднимать проблему без ручного контроля

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

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

Чтобы эскалации не превращались в спам, задайте лимиты и интервалы: первая эскалация после N часов или дней просрочки, повтор не чаще заданного интервала, максимум 1-3 эскалации на одно задание. После последней - либо автоотказ, либо обязательное решение руководителя.

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

Пример: заявка на закупку серверов для проекта (например, стойки S200 для дата-центра) зависла на шаге финансового согласования. Через 24 часа уходит напоминание, через 48 часов задача уходит руководителю финансов, а исходный согласующий получает уведомление, что задача эскалирована.

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

Подписание: отдельный этап с четкими правилами

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

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

Варианты подписи лучше поддерживать настройками одного шага, а не отдельными процессами. На практике встречаются подтверждение в интерфейсе (для внутренних регламентов), подпись КЭП/ЭЦП (для юридически значимых документов), серверная подпись - когда подпись ставится сервисом по четкому правилу и с ограниченным доступом.

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

Для доказательной базы храните минимум: дату и время (с часовым поясом), кто подписал и по какой роли, идентификатор версии и хэш содержимого, результат проверки и причину отказа, данные сертификата (если применимо), технический след (устройство, IP, идентификатор сессии).

Делегирование: замены без потери контроля

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

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

Ограничения лучше задавать явно, иначе появятся риски и путаница: делегирование только в пределах подразделения или по роли (например, «заместитель руководителя»), обязательные дата начала и окончания, запрет на делегирование «дальше по цепочке» там, где это критично, отдельное правило для финансовых лимитов (выше суммы - только руководитель).

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

Пользователь должен видеть делегирование в интерфейсе и в отчете: «Решение принято Ивановой как заместителем Петрова (делегирование до 15.02)».

Изменения по ходу процесса: отзыв, доработка, повтор

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

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

Доработка после замечаний работает как управляемый цикл: «вернули на доработку» -> «инициатор исправил» -> «повторное согласование». Чтобы не плодить копии, храните версию документа (номер или хэш) и привязывайте повтор к конкретной версии. Так видно, что именно изменилось и когда.

Частичное согласование можно сохранять, но только по правилам. Если изменился раздел, который затрагивает финансовые условия, логично отправить повторно финансы и юристов, а технические согласования оставить действительными. Удобно иметь признак «требует пересогласования при изменении полей X».

Чтобы не получить бесконечные возвраты, задайте дисциплину: лимит попыток доработки (например, 2-3), обязательная причина возврата из справочника плюс комментарий, блокировка повторного запуска без изменений ключевых полей, правило «после N возвратов - эскалация владельцу процесса».

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

Частые ошибки при внедрении универсальных согласований

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

Типичные ошибки:

• Смешивают статусы документа и статусы заданий в один список. Документ живет своей жизнью (черновик, на согласовании, подписан), задания - своей (назначено, в работе, завершено, просрочено). Если склеить это в одно, станет непонятно, что именно произошло.
• Плодят исключения в коде: «для договоров так», «для закупки иначе», «для ИТ-заявки еще иначе». Нужна конфигурация маршрутов, правил, тайм-аутов и эскалаций, а не ветки if-else.
• Включают авто-решения без прозрачного лога. Если система сама переводит шаг в «согласовано» (например, по тайм-ауту), пользователь должен видеть: кто, когда и по какому правилу это произошло.
• Теряют версии. Это часто всплывает на подписи: документ отправили на правки, внесли изменения, а подписали старую редакцию.
• Не отвечают на вопрос «кто отвечает сейчас». Это критично при делегировании, замене сотрудника и параллельных шагах.

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

Короткий чек-лист перед запуском

Перед запуском полезно проверять не «функции», а понятность правил. Если пользователь не может быстро объяснить, что происходит и почему, процесс будет ломаться на исключениях и обходных путях.

1) Статусы: объясняются ли за минуту

Спросите у двух людей из разных ролей (инициатор и согласующий), что означает каждый статус. Если ответы отличаются, статусов слишком много или они пересекаются.

Проверьте, что статусы показывают состояние задания и документа, а не «эмоцию» процесса. «На согласовании» и «Ожидает подписи» обычно нужны, а «В работе у Петрова» лучше оставлять как исполнителя, а не как статус.

2) Тайм-ауты и эскалации: что будет при тишине

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

Короткий прогон по вопросам:

• Когда уходит первое напоминание и кому?
• Что происходит при истечении срока: автоэскалация, смена исполнителя или блокировка?
• Кто получает эскалацию и что именно увидит в истории (дата, причина, кто не ответил)?
• Можно ли отличить «просрочено» от «остановлено по причине» (например, ожидание данных)?

3) Подпись и делегирование: следы в истории

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

Делегирование проверьте на прозрачность: в карточке и журнале должно быть видно, кто действовал, от чьего имени и на каком основании (замещение, отпуск, разовое поручение).

Пример процесса: от заявки до подписи

Представьте закупку серверов для нового проекта: инициатор создает заявку с обоснованием, суммой, спецификацией и сроками. Дальше работает единая модель, где меняются только маршрут и роли, а не логика обработки.

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

• Черновик
• На согласовании
• На доработке
• На подписании
• Подписано или Отклонено

Пример маршрута: сначала бюджет (финансы), затем ИБ, затем юристы, после чего документ уходит на подпись руководителю. Тайм-ауты работают одинаково: например, на каждом задании есть срок 48 часов. Через 24 часа система отправляет напоминание, а по истечении 48 часов фиксирует просрочку и запускает эскалацию.

Эскалация выглядит так: если согласующий ИБ не ответил 48 часов, статус задания становится «Просрочено», а новое задание уходит его руководителю (или дежурному). При этом исходное решение блокируется, чтобы не было двух противоречивых ответов.

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

Главная выгода единой модели: завтра вы добавите еще один шаг (например, проверку соответствия стандартам закупки), но статусы, тайм-ауты, эскалации, подписание и делегирование останутся теми же. Меняется маршрут, но не поведение процесса.

Следующие шаги: как внедрять без переписывания логики

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

Практичный путь внедрения:

• Зафиксировать роли и типы шагов (согласование, проверка, подписание, ознакомление) и правила переходов.
• Собрать 2-3 пилотных процесса разной природы: простой (1 согласующий), параллельный (2-3 согласующих), с подписью и эскалацией.
• Прогнать пилоты на реальных кейсах: отпуск, закупка, доступ в систему, договор.
• Проверить универсальность: добавляется ли новый процесс настройками, без новых статусов и исключений в коде.
• Ввести метрики: доля просрочек, среднее время шага, число возвратов на доработку.

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

Прототип стоит показать сразу нескольким сторонам: бизнесу (удобство), ИБ (права и аудит), юристам (подпись и хранение), ИТ (интеграции со справочниками и учетными записями).

Если на этапе внедрения нужна системная интеграция и поддержка, иногда проще подключить интегратора. Например, GSE.kz (gse.kz) занимается системной интеграцией и инфраструктурными решениями, что полезно, когда согласования тесно связаны с ИТ-процессами, закупками и поддержкой."}