Матрица согласований: правила по суммам, статьям и филиалам

Что такое матрица согласований и почему без нее все тормозит

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

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

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

Регламент в Word обычно описывает процесс общими фразами и примерами, но редко закрывает частные случаи. Матрица согласований отличается тем, что фиксирует конкретные «если - то» правила и роли, которые можно проверять и применять без трактовок.

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

Простой пример: филиал хочет купить компьютеры на 2,5 млн тенге. Без матрицы начнут выяснять, кто утверждает сумму, нужна ли ИТ-экспертиза, считается ли это «капексом», и кто подписывает для филиала. С матрицей маршрут собирается сразу, и заявка идет по цепочке без лишних вопросов.

Из чего состоит матрица: суммы, статьи, филиалы, роли

Матрица согласований - это таблица правил, где по набору признаков документа заранее понятно, кто и в каком порядке его согласует. Если описать признаки четко, согласование перестает быть перепиской в чате.

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

4 блока, без которых матрица не работает

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

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

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

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

Например, заявка на закупку ноутбуков на 3 200 000 тенге для филиала в Астане по статье «ИТ-оборудование» сразу попадает на согласование руководителю филиала, затем в финконтроль. Юристы подключаются только если это договор, а не разовая покупка. Когда эти условия записаны в матрице, уточняющих вопросов становится заметно меньше.

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

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

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

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

Владельцы данных

Чтобы матрица не превратилась в спор «кто должен поправить справочник», закрепите владельцев. Например: финансы ведут статьи и лимиты, HR или администратор системы - сотрудников и роли, бизнес-контролеры - центры затрат, а операционный блок - актуальность структуры филиалов.

Статусы и исключения

Сделайте короткий набор статусов и не усложняйте: «Черновик», «На согласовании», «Возврат на доработку», «Согласовано», «Отклонено», «Исполнено/Закрыто». У каждого статуса должно быть одно значение и понятное действие.

Исключения фиксируйте отдельно: отдельная причина, срок действия и кто разрешил. Например: «Срочная закупка для филиала, согласование сокращено на 7 дней по решению финансового директора». Если исключение нельзя описать одной строкой и ограничить по времени, оно почти наверняка станет новой нормой и разрушит матрицу.

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

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

1) Задайте понятные пороги

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

2) Назначьте владельцев диапазонов и порядок

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

3) Решите, где нужна параллельность, а где очередь

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

4) Добавьте финальный контроль только там, где он оправдан

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

5) Прогоните правила на типовых кейсах и поправьте

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

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

Правила по статьям расходов: чтобы не утонуть в деталях

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

Хорошее правило простое: детализация должна совпадать с тем, как вы управляете бюджетом и ответственностью. Если бюджет утверждается на уровне «Маркетинг» без разреза по активностям, не нужно заставлять сотрудников выбирать «SMM», «ивенты», «печатная продукция» только ради маршрута. А если лимиты и KPI разные, детализация оправдана.

Часто достаточно 5-10 верхних групп, а детали оставляют для аналитики, а не для согласования. Например: ИТ (оборудование, ПО, услуги), аренда и содержание офисов, маркетинг и продажи, командировки и представительские, профессиональные услуги и подрядчики.

Иногда одной статьи мало. Тогда лучше добавить не десятки новых подстатей, а одно понятное условие: проект, источник финансирования, тип договора. Пример: «Маркетинг» согласуется одинаково всегда, но «Маркетинг + проект X» уходит на отдельного руководителя проекта.

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

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

Филиалы и уровни управления: прозрачные маршруты

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

«Филиал решает сам» или «централизованно»

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

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

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

Как описать уровни маршрута

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

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

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

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

Эскалации, замены и сроки: как убрать переписку

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

Эскалация по срокам

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

Сроки (SLA) задавайте по типам заявок, а не одной цифрой на все. Например: типовые операционные расходы - 1 рабочий день на шаг; закупка оборудования - 2 рабочих дня; срочные заявки (с пометкой и причиной) - 4 часа в рабочее время; заявки с договором или юридическими рисками - 3 рабочих дня.

Замены и возврат на доработку

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

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

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

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

Типовые ошибки при настройке матрицы

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

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

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

Хорошая проверка - взять 10 реальных заявок за месяц и прогнать их по правилам. Если хотя бы в 3 случаях нужно уточнять «а это какая статья?» или «какой у нас тут филиал?», значит, определения и справочники не закреплены.

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

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

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

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

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

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

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

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

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

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

Пример сценария: закупка для филиала без лишних уточнений

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

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

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

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

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

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

Дальнейшие шаги: внедрение, инфраструктура и поддержка

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

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

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

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

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

Если вы упираетесь не только в правила, но и в реализацию - маршруты, роли, поддержку и «железо» под систему - это обычно зона ответственности системного интегратора. В Казахстане такие задачи, включая развертывание серверов и рабочих станций, решения для дата-центров и круглосуточную техподдержку, делает GSE.kz (gse.kz) как производитель и интегратор ИТ-инфраструктуры.