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

Ad-hoc согласование vs преднастроенный маршрут

Есть два способа отправить заявку на согласование:

• Ad-hoc (вручную) — оператор сам выбирает согласующего(их) и пишет комментарий. Гибко, но держится на памяти оператора: кого выбрать, в каком порядке, всех ли. Подходит для разовых нетиповых случаев.
• По маршруту — заранее настроенная схема, привязанная к услуге. Оператор просто выбирает маршрут, дальше система ведёт заявку по этапам сама.

Маршрут снимает три типичные ошибки ad-hoc: забыли согласующего, перепутали очередность, согласовали не тем составом. Для повторяющихся сценариев (закупка, доступ, отпуск) маршрут обязателен; для редких — ad-hoc достаточно. Хорошая система даёт оба варианта в одном окне «На согласование».

Этапы и очерёдность

Маршрут — это последовательность этапов. Заявка проходит их по порядку: следующий этап активируется только когда согласован предыдущий. Это и есть «очерёдность людей»: сначала руководитель отдела, потом финансы, потом гендир.

Начало → [Руководитель] → [Финансы] → [Гендир] → Готово
         согласовал↓       согласовал↓     согласовал↓
                  активируется    активируется    заявка
                  следующий       следующий       согласована

Каждый этап знает своих согласующих. Пока этап не пройден, заявка ждёт именно его участников — остальные подключатся позже. Это предотвращает ситуацию «гендир согласовал раньше, чем непосредственный руководитель посмотрел».

Правила «все/любой» и параллельные ветви

На каждом этапе может быть несколько согласующих, и важно правило:

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

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

Отклонение на любом этапе обычно останавливает весь маршрут: заявка возвращается инициатору/оператору, SLA снимается с паузы.

Привязка к услуге

Маршрут логично привязывать к услуге (или нескольким): «закупка ПО» → один маршрут, «доступ к 1С» → другой. Тогда при отправке заявки этой услуги на согласование система сразу предлагает релевантные маршруты, а не весь список.

Полезно держать на одну услугу несколько маршрутов — например, по сумме («до 100 тыс — только руководитель», «свыше — плюс финдиректор») или по типу. Оператор выбирает подходящий. Это гибче, чем один универсальный маршрут на все случаи, и понятнее, чем ad-hoc каждый раз.

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

Когда нужны сложные схемы, а когда нет

Соблазн настроить ветвистый граф на всё — частая ошибка. Здравый подход:

• Один согласующий — для большинства бытовых заявок (мелкие доступы, расходники) хватает простого «руководитель согласовал». Не усложняйте.
• Линейная цепочка — для закупок и доступов с понятной иерархией (руководитель → финансы → гендир).
• Правило «любой» — где согласующие взаимозаменяемы; снимает зависимость от одного человека.
• Параллельные ветви — только когда реально есть независимые направления согласования (бюджет + безопасность + юр), которые незачем выстраивать в очередь.

Маршрут должен ускорять и упорядочивать согласование, а не превращать заявку на мышку в квест из семи подписей. Начните с простых маршрутов на самые частые услуги, усложняйте только там, где это реально отражает процесс компании. Согласование — частый кейс и для ESM (отпуска, договоры), где маршруты даже важнее, чем в ИТ.