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

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

Первая ошибка — контролировать не процесс, а людей в ручном режиме. Пока собственник читает переписку, просматривает таблицы и задает вопрос, почему документ лежит третий день без движения, срок уже потерян. Вторая ошибка — смешивать согласование бюджета с обсуждением качества идеи. Если на одном этапе одновременно спорят о целесообразности, цене, лимите, источнике финансирования и сроки оплаты, заявка зависает без даты выхода. Третья ошибка — отсутствие единого статуса. Участники пишут «на рассмотрении», «в работе», «ждем ответ», а управленческой картины нет.

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

Основа системы

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

После карты маршрута я ввожу набор статусов. Их хватает пяти: создана, на согласовании, возвращена на доработку, согласована, отклонена. Для контроля просрочки нужен еще признак «срок шага нарушен». Я не добавляю десяток промежуточных отметок, потому что избыточная детализация ломает прозрачность. Смысл не в красоте процесса, а в том, чтобы собственник за минуту видел, где и у кого стоит решение.

Отдельно определяют норматив по времени для каждого шага. Не общий срок на всю заявку, а срок на конкретное действие конкретной роли. Финансовый контроль — один срок. Руководитель подразделения — другой. Юридическая проверка, если она реально нужна, — третий. Норматив привязывается к типу заявки. Срочный платеж нельзя вести по тем же правилам, что плановое перераспределение бюджета на следующий месяц.

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

Контроль и эскалация

Контроль просроченных согласований не равен ежедневной рассылке с красными строками. Нужен короткий механизм эскалации. Я делю просрочку на две зоны. Первая — рабочая. Руководитель функции получает сигнал, что срок шага нарушен, и в течение короткого окна принимает решение или передает его дальше. Вторая — управленческая. Если заявка выходит за предел повторной просрочки или блокирует платеж с понятным риском для бизнеса, сигнал поднимается собственнику или директору по финансам. Без промежуточной зоны собственник быстро превращается в диспетчера мелких задержек.

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

Для собственника я собираю один отчет, а не пачку выгрузок. В нем три блока. Первый — объем просрочки: сколько заявок вышло за срок и на какую сумму. Второй — узкие места: на каких шагах и у каких ролей скапливается задержка. Третий — возраст просрочки, чтобы видеть не только количество, но и глубину проблемы. Если в отчете нет суммы, нет возраста и нет шага, управленческого решения из него не получится.

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

Внедрение без шума

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

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

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