Таблицы решений для бизнес‑правил в потоках согласования

Почему правила согласования так часто ломаются

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

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

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

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

Множество скрытых правил живёт в местах, которые никто не аудирует. Они сидят в старых письмах, чатах и комментариях к прошлым запросам. Кто‑то однажды написал: "Для подрядчиков всё необычное сначала отправлять в юридический отдел", и теперь это предложение управляет реальной работой, хотя так и не попало в политику. Правило есть, но только в памяти и поиске по почте.

Простой процесс с расходами показывает, как быстро это ломается. Если траты на еду до $50 проходят автоматически, что происходит, когда в чеке алкоголь? Что если сотрудник вместе с клиентом? Что если поездка была заранее одобрена? Если никто не записывает эти исключения, каждый согласователь создаёт свою приватную версию правила.

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

Что делает таблица решений

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

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

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

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

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

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

Сначала соберите реальные правила

Большинство потоков согласования терпят неудачу из‑за плохих исходных материалов. Официальная политика говорит одно, а повседневная работа следует смеси ответов по почте, сообщениям в чатах, заметкам в таблицах и памяти.

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

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

Не спрашивайте их про идеальный процесс. Спросите о последних пяти странных случаях, которые они помнят. Эти случаи быстрее выведут реальные правила, чем отточенная политика.

Финансовый руководитель может сказать: "Я одобряю всё ниже $2,000." Это звучит ясно, пока вы не спросите про крайние случаи. Вдруг появляются новые условия: новый поставщик, отсутствующий чек, поездка во время заморозки найма или запрос по проекту клиента. Эти детали уже влияют на решения, значит им место в наборе правил.

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

Затем отделите жёсткие правила от привычек. Жёсткое правило идёт из политики, соответствия, контроля бюджета или юридических ограничений. Привычка — это что‑то вроде "я обычно спрашиваю Сэма, если сумма кажется высокой" или "я предпочитаю сам проверять маркетинговые расходы". Привычки важны, потому что они влияют на работу, но они не должны незаметно проникать в автоматизацию.

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

Подбирайте столбцы осторожно

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

Начните с фактов, которые уже есть в форме, политике или исходной системе. "Сумма больше $500" работает. "Срочная закупка" обычно не работает, если политика не определяет "срочную" в чётких словах, а форма не фиксирует это одинаково каждый раз.

Самые безопасные столбцы обычно простые. Фиксированные категории, такие как отдел, тип расхода, тип контракта и страна, подходят хорошо. Так же работают явные флаги: чек приложен, менеджер одобрил, поставщик в списке одобренных или клиент подтверждён. Жёсткие диапазоны тоже полезны — они оставляют меньше места для споров.

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

Небольшой финансовый пример делает это очевидным. Предположим, запрос на расходы включает сумму, отдел, является ли это командировкой (да/нет), приложен ли чек (да/нет) и уровень сотрудника. Это надёжные столбцы. Сравните их с "высокий приоритет" или "разумная стоимость". Люди по‑разному понимают такие ярлыки, и инженеры в итоге кодируют личные догадки из старых писем или привычек одного менеджера.

Если вы находите расплывчатый ярлык, разберите его на измеримые части. Замените "высокий приоритет" на "авария сервиса да/нет" или "нужно до даты события да/нет". Замените "крупная сумма" на числовой диапазон. Таблица станет длиннее, но безопаснее.

Простые столбцы проще строить, тестировать и защищать, когда кто‑то спрашивает: "Почему это было одобрено?"

Стройте таблицу шаг за шагом

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

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

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

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

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

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

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

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

Простой пример с согласованием расходов

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

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

Первые две строки показывают, почему сумма сама по себе недостаточна. Сотрудник и подрядчик подают одинаковый чек на $300, но компания может относиться к ним по‑разному. Если инженеры услышат только: "обеды до $500 требуют одобрения менеджера", они могут одобрить оба. Таблица предотвращает такую ошибку.

Отсутствие чека важно не меньше. Многие команды считают это мелочью и пытаются исправить позже. На практике это меняет маршрут. Система должна приостановить заявку и запросить доказательства, а не предполагать, что менеджер разберётся после одобрения.

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

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

Ошибки, которые создают плохую автоматизацию

Плохая автоматизация обычно начинается до того, как кто‑то пишет код. У команды есть документ политики, пара старых писем и менеджер, который говорит: "Мы это решаем вручную." Тогда инженеры превращают этот беспорядок в логику потока, и скрытые пробелы становятся багами.

Одна распространённая ошибка — прятать исключения в заметках. Если правило говорит "CFO одобрение свыше $5,000", а в заметке указано, что расходы на выставки могут пропускать этот шаг, заметка уже не просто заметка. Это правило. Поместите его в таблицу как условие и результат, иначе кто‑то пропустит это.

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

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

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

Худший ответ — "решайте по ситуации". ПО не умеет принимать «суждение», если вы не свели его к именованным проверкам. Замените расплывчатые результаты на чёткие действия, например:

• вернуть на доработку из‑за недостающей информации
• направить в финансы для проверки конфликта
• эскалировать к конкретному ответственному
• отклонить с указанием причины

Таблица решений работает только когда каждая строка может выполняться без побочных разговоров. Если кто‑то всё ещё должен спрашивать: "Что мы обычно делаем здесь?", правило не закончено.

Быстрая проверка перед началом работы инженеров

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

Быстрый обзор ловит большинство очевидных проблем:

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

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

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

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

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

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

Когда вы находите несоответствие, держите исправление простым. Найдите строку, которая почти подошла. Запишите недостающее условие простыми словами. Решите, является ли это реальной политикой или единичным исключением. Затем добавьте, объедините или удалите строку и протестируйте тот же кейс снова.

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

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

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

Если логика согласований запутана или разбросана по нескольким командам, внешняя проверка поможет до того, как инженеры построят поток. Oleg Sotnikov at oleg.is работает как Fractional CTO и консультант стартапов; проверка неясной логики процесса до того, как она превратится в дорогостоящие ошибки автоматизации, естественно входит в такие услуги.