Матрица согласований для автоматизации закупок и HR

Зачем ботам нужны чёткие правила утверждения

Люди умеют обходить расплывчатые правила. Боты — обычно нет.

Возьмём фразу «менеджер утверждает крупные покупки». Человек в компании может понимать под «крупными» всё, что выше $2,000 для офисных товаров, но только $500 для ПО, если у команды нет заранее выделенного бюджета. Бот не может безопасно заполнить такие пробелы. Он либо остановит запрос, либо отправит его не тому человеку, либо одобрит то, к чему не должен прикасаться.

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

Цена выше, чем просто один неверный клик. Запросы перескакивают между менеджерами. Люди переделывают работу, потому что неверный человек дал согласование. Старший персонал втягивается в вопросы, до которых он не должен был добираться. Со временем сотрудники перестают доверять системе.

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

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

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

Что должна фиксировать матрица

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

Начните с ролей, а не с людей. Люди меняют работу, уходят в отпуск или подменяют друг друга. Роли остаются более стабильными. Записывайте такие записи, как «руководитель команды», «менеджер HR», «финансовый контролёр» или «начальник закупок», и указывайте, кто покрывает эту роль, когда обычного утверждающего нет на месте.

Далее определите действие, которое каждая роль может одобрить. Запрос на покупку, найм, изменение зарплаты, возврат или продление контракта — это разные действия. Если один менеджер может утверждать канцелярию, но не подписывать подписки на ПО, напишите это прямо. Боты ошибаются, когда правила сводят очень разные транзакции в один ящик.

Важны диапазоны сумм. Один единый лимит редко достаточен. Небольшие запросы часто требуют одного уровня проверки, большие — другого. Простая матрица может использовать диапазоны вроде до $500, $500–$5,000 и выше $5,000. Указывайте тип транзакции рядом с каждым диапазоном, чтобы правило оставалось понятным.

Некоторым действиям нужно два согласования. Запишите это как правило, а не как предложение. Покупка выше определённой суммы может требовать и владельца бюджета, и финансов. Корректировка зарплаты — и менеджера по найму, и HR. Если эти согласования должны идти в определённом порядке, зафиксируйте его.

Также нужны точки остановки. Бот должен передать случай человеку, когда:

• запрос не попадает ни в один из указанных диапазонов сумм
• у утверждающего конфликт интересов
• дело требует исключения из политики
• код бюджета отсутствует или неясен
• запрос смешивает категории с разными правилами

Добавьте причину для каждой точки остановки. Это поможет боту объяснить, почему он приостановил процесс, и поможет сотрудникам быстрее исправить проблему.

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

Роли, лимиты и действия

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

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

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

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

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

Устанавливайте пороги, которые соответствуют реальным расходам вашей компании. Если большинство покупок ПО лежит в диапазоне $800–$2,000, не делайте лимиты так, чтобы почти каждый запрос попадал в зону исключений. Рабочий процесс должен соответствовать нормальным моделям покупок, а не старому документу политики, которому никто не следует.

Команды также разделяют разные действия. Держите их раздельно:

• проверка — проверяет документы, соответствие политике или код бюджета
• утверждение — позволяет запросу продвинуться дальше
• отклонение или отправка на доработку — останавливает запрос или просит изменения
• финальное подписание — даёт разрешение на оплату, заключает контракт или подтверждает изменение

Это разделение важно. Финансовый аналитик может проверять отчёт о расходах, руководитель подразделения — утверждать его, а контролёр — давать финальное согласование свыше определённой суммы.

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

Пишите правила по шагам

Начните с одного запроса, который происходит часто. Покупка ноутбука, запрос на отпуск или счёт подрядчика — лучше, чем редкий крайний случай. Частые запросы быстрее выявляют настоящую политику и дают автоматизации безопасное поле для обучения.

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

Обычно простое правило следует этим шагам:

1. Назвать тип запроса.
2. Установить дефолтного утверждающего для каждого диапазона сумм.
3. Добавить ещё одного утверждающего, если запрос пересекает порог.
4. Добавить триггеры проверки для финансов, юристов, HR или безопасности.
5. Определить точный результат, который система должна вернуть.

Держите диапазоны сумм узкими и понятными. Не пишите «малые покупки» или «менеджер проверяет при необходимости». Пишите «$0–$500 идёт руководителю команды», «$501–$2,000 идёт главе отдела», «> $2,000 также нужно согласование фин/контроллера». Боты хорошо работают с точными диапазонами. Расплывчатые метки приводят к ошибочной маршрутизации.

Затем добавьте проверки, которые действуют независимо от суммы. Некоторые запросы требуют участия другой команды из‑за риска, а не цены. Контракт на ПО может требовать юридической проверки даже при небольшой сумме. Нового сотрудника может потребоваться проверить в HR до того, как менеджер согласует дату начала или компенсацию. Компенсация может потребовать финансовой проверки, если нет квитанции или расход вне политики.

Будьте конкретны по триггерам. Пишите «юридическая проверка требуется, если контракт с поставщиком включает автообновление» или «HR требуется, если отпуск превышает 10 рабочих дней». Это даёт системе понятный переключатель.

Завершайте каждое правило одним финальным ответом. Система должна вернуть что‑то конкретное: «одобрено», «отправлено в финансы на проверку», «требуется одобрение директора» или «отклонено — сумма превышает утверждённый бюджет». Один запрос должен давать один чёткий статус, а не расплывчатую пометку.

Если правило тяжело сформулировать, политика, вероятно, ещё не ясна. Исправьте политику, а потом автоматизируйте.

Обрабатывайте исключения до того, как они сломают поток

Обычные случаи просты. Исключения — то место, где системы согласований чаще всего ломаются.

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

Начните с исключений, которые происходят ежемесячно. Если команда видит их снова и снова, это уже не краевой случай.

В закупках это может быть экстренная замена ноутбука или продление ПО в тот же день. В HR — продление контракта, пока менеджер в отпуске. В финансах — счёт выше обычного лимита, который всё равно нужно оплатить из‑за сроков.

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

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

Запросы вне политики должны получать ещё меньше догадок. Система не должна решать, «похоже, правило применимо». Она должна пометить запрос как вне политики, приложить причину и отправить тому, кто отвечает за исключения.

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

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

Простой пример через закупки, HR и финансы

Проще тестировать матрицу, когда один запрос проходит через несколько команд.

Представьте продуктовую команду, которой нужен новый аналитический инструмент и подрядчик, чтобы настроить его до релиза. Продакт‑менеджер отправляет один запрос: покупка ПО за $18,000 в год и найм подрядчика на шесть недель. В запросе указаны имя поставщика, код затрат, длительность контракта, дата начала и причина, почему работа не может ждать.

Закупки сначала проверяют часть по ПО. Матрица говорит, что руководители команд могут утверждать ПО до $5,000, главы отделов — до $15,000, а CTO — до $25,000. Поскольку инструмент стоит $18,000, система пропускает руководителя команды и отправляет запрос к CTO.

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

Финансы рассматривают обе части вместе. Правила финансов требуют, чтобы владелец бюджета подтвердил наличие средств в текущем квартале, а финансы проверили условия оплаты. Если поставщик просит 100% предоплату, одобрение требует CFO. Если оплата помесячная и в пределах бюджета — может дать согласование менеджер по финансам.

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

Путь будет таков:

1. Определить тип запроса: покупка ПО и запрос на подрядчика.
2. Прочитать сумму, код затрат, флаг срочности, условия оплаты и уровень доступа к данным.
3. Направить согласование по ПО к CTO, потому что $18,000 выше лимита отдела.
4. Направить согласование по подрядчику в HR, затем в безопасность при доступе к данным клиентов.
5. Направить проверку финансов к владельцу бюджета, затем к CFO, потому что оплата 100% вперёд.

Этот путь точен. Система не догадывается, и потом никто не спорит о том, кто должен был согласовать что.

Ошибки, приводящие к неверным утверждениям

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

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

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

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

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

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

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

Проверки перед автоматизацией

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

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

Несколько проверок ловят большинство проблем:

• Протестируйте простое правило: сможет ли новый менеджер пройти весь процесс по правилу один раз, прочитав его?
• Проверьте каждый диапазон сумм. Ни один диапазон не должен заканчиваться фразой «спросить кого‑то» или «зависит от ситуации».
• Прочитайте каждое исключение и спросите, что система делает дальше: отправляет в юристы, ставит на паузу для ручной проверки, просит недостающие документы или отклоняет запрос.
• Убедитесь, что каждое решение оставляет след. Аудитор должен видеть, кто утвердил, какое правило применилось, какая сумма его вызвала и изменился ли путь из‑за исключения.
• Уберите дубликаты и коллизии. Если одно правило говорит, что глава отдела может утверждать до $5,000, а другое — что финансы должны утверждать всё свыше $3,000, у вас ещё нет рабочего правила.

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

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

Если вы формализуете правила до перехода на помощников с ИИ, внешняя проверка может помочь. Oleg Sotnikov, fractional CTO и советник по стартапам на oleg.is, работает с компаниями, которые превращают запутанные внутренние процессы в ясные системы, которым ПО может следовать без догадок.

Лучший финальный тест прост: возьмите один запрос, уберите имена и спросите «Смогли бы мы объяснить это согласование через шесть месяцев?» Если ответ «нет», исправьте правило до автоматизации.

Что делать дальше

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

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

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

Следите за моментом, когда люди говорят «ну, зависит». Это признак, что правило все ещё слишком размыто.

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

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

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