Таблица решений представляет бизнес-правила как сочетания условий и результатов. Разместите условия в столбцах, отведите каждому правилу отдельную строку и укажите, что должно произойти при совпадении с этой строкой. Самая полезная проверка проста: возьмите правдоподобные входные данные и посмотрите, выдаёт ли таблица именно тот результат, который вы ожидали.
Например, служба поддержки может направлять обращения по-разному в зависимости от того, затронута ли рабочая среда, заблокирован ли обычный сценарий работы и существует ли временный обходной путь. Таблица позволяет сравнить эти сочетания рядом друг с другом. Блок-схема затем покажет, где такое решение находится в общем процессе.
Когда таблица решений понятнее блок-схемы
Используйте таблицу решений, когда результат зависит сразу от нескольких входных данных и нужно сравнить правила. Блок-схема удобнее, когда главный вопрос — что происходит сначала, что затем и куда возвращается работа после исключения. Эти представления могут описывать один процесс на разных уровнях: нарисуйте общий рабочий процесс в Boardmix, а правила маршрутизации разместите рядом с соответствующим решением.
Представьте блок-схему с вопросом «Затронута ли рабочая среда?», после которого в нескольких ветвях повторяется «Есть ли обходной путь?». На такой схеме трудно заметить, что две ветви приводят к противоречащим друг другу результатам. В таблице повторяющийся вопрос занимает один столбец. Строки можно сравнить, не прослеживая пересекающиеся стрелки.
Таблица решений — не матрица выбора. Матрица оценивает альтернативы по критериям, например стоимости и удобству. Таблица проверяет условия, например блокировку рабочего сценария, и возвращает заданный результат. В этом примере также не используются вероятности и не рассчитывается ожидаемая денежная стоимость.
Определите входные данные до составления правил
Ниже приведён условный процесс поддержки, а не политика поддержки Boardmix. Он определяет, куда направить обращение для первичного разбора, но не обещает время ответа и не устанавливает причину сбоя.
- Затронута рабочая среда: проблема возникает в действующей среде, где выполняется обычная работа. Для проблемы только в тестовой среде ответ — «Нет».
- Обычный сценарий заблокирован: пользователь не может завершить задачу привычным способом. Для косметического дефекта ответ — «Нет».
- Есть обходной путь: известен временный способ завершить ту же задачу. Непроверенная идея исправления обходным путём не считается.
«Заблокирован» и «есть обходной путь» не являются противоположностями. Обычный способ работы может не действовать, хотя ручной или альтернативный вариант остаётся доступным. Запишите это различие рядом с таблицей, иначе два человека могут по-разному описать одно обращение.
В этом учебном примере все три значения должны быть известны до применения таблицы. Если из обращения непонятно, затронута ли рабочая среда, сначала запрашивают сведения. Неизвестное значение нельзя незаметно заменять ответом «Нет».
Полный пример таблицы решений
Каждая строка ниже — отдельное правило. «Любое» означает, что значение не влияет на результат именно этой строки, а не что информация отсутствует. Таблица рассчитана на единственное совпадение: полный набор входных данных должен соответствовать одной строке, но не двум.
| Правило | Рабочая среда затронута? | Обычный сценарий заблокирован? | Есть обходной путь? | Куда направить |
|---|---|---|---|---|
| R1 | Нет | Любое | Любое | Очередь тестовой среды |
| R2 | Да | Нет | Любое | Обычная очередь поддержки |
| R3 | Да | Да | Да | Приоритетная очередь поддержки |
| R4 | Да | Да | Нет | Первичный разбор инцидента |
Прочитайте R3 как предложение: если рабочая среда затронута, обычный сценарий заблокирован и обходной путь есть, направьте обращение в приоритетную очередь поддержки. Результат указывает направление обращения. Он не означает, что проблема уже решена.
Возьмём обращение: «В рабочей среде не действует кнопка экспорта, но отдельные записи скачать можно». После подтверждения, что скачивание записей позволяет завершить задачу, получаем Да / Да / Да. R1 не подходит: рабочая среда затронута. R2 не подходит: обычный сценарий заблокирован. R3 подходит. R4 не подходит: обходной путь существует.
Теперь изменим только среду: такой же сбой возникает в тестовом пространстве. Срабатывает R1 независимо от двух остальных значений. Это не делает дефект неважным — так устроено явно заданное правило примера. Если у команды другая политика, нужно изменить правило, а не прятать исключение в примечании.
Найдите пересечения правил и непокрытые входные данные
У трёх логических переменных восемь возможных сочетаний. R1 покрывает четыре, R2 — два, R3 и R4 — по одному. Эти группы не пересекаются, поэтому таблица охватывает все сочетания значений «Да» и «Нет».
Полнота покрытия и правильность — разные свойства. Таблица может учитывать каждое сочетание, но реализовывать неверную бизнес-политику. Ответственный за маршрутизацию должен проверить результаты, особенно смысл слов «приоритетный» и «инцидент» в своей организации.
Два распространённых нарушения легко показать на этом примере:
- Пересечение: замените условие блокировки в R2 с «Нет» на «Любое». Заблокированный рабочий сценарий с обходным путём теперь соответствует R2 и R3. У одного обращения два направления.
- Пробел: удалите R3. Заблокированный рабочий сценарий с обходным путём не соответствует ни одной строке. Выбор самой похожей строки означал бы добавление несуществующего правила.
В инструментах формального моделирования такое поведение называют hit policy — политикой обработки совпадений. В документации Camunda о политиках таблиц решений Unique запрещает несколько совпавших правил, а First выбирает первое подходящее правило. Разница существенна: перестановка строк в таблице First может изменить результат. Не полагайтесь на визуальный порядок, если он не является намеренной частью политики.
Таблица в этой статье — проектный документ, а не исполняемая модель DMN. Если разработчики реализуют её в приложении или движке правил, там нужно отдельно задать типы входных данных, обработку совпадений и ошибок.
Проверьте таблицу на конкретных случаях
Храните примеры рядом с правилами, чтобы последствия будущих правок были видны. Этот небольшой набор проверяет все направления и отдельный путь запроса недостающей информации:
| Случай | Данные: рабочая среда / блокировка / обходной путь | Ожидаемый результат |
|---|---|---|
| Вход не работает только в тестовой среде | Нет / Да / Нет | R1: очередь тестовой среды |
| В рабочей среде неверно отображается подпись, но задача выполняется | Да / Нет / Нет | R2: обычная очередь поддержки |
| Экспорт в рабочей среде не действует; альтернативное скачивание работает | Да / Да / Да | R3: приоритетная очередь поддержки |
| Экспорт в рабочей среде не действует; альтернативы нет | Да / Да / Нет | R4: первичный разбор инцидента |
| В обращении не указана среда | Неизвестно / Да / Нет | Запросить сведения; пока не применять R1–R4 |
Если правила содержат числа или даты, добавьте значения непосредственно ниже границы, на ней и выше неё. Для условия «сумма больше 100» проверьте 99,99, 100 и 100,01 в соответствующей валюте и с нужной точностью. Решите, включается ли граничное значение, до построения схемы. Выражение «крупный запрос» нельзя проверять единообразно, пока организация не определит его смысл.
Проверьте и значение за пределами допустимого набора. Если разрешены только «Да» и «Нет», пустое поле, опечатка или «вероятно» требуют отдельного способа обработки. Маршрут по умолчанию должен быть осознанным решением, а не способом скрыть некорректные данные.
Формат, который можно использовать для своих правил
Начните с этой короткой спецификации, затем добавьте строки правил. Она сохранит контекст таблицы, даже если её скопируют в проектный документ.
- Решение: на какой один вопрос отвечает таблица?
- Входные данные: название, определение и допустимые значения каждого условия.
- Результаты: точные направления, категории или действия, которые может вернуть таблица.
- Обработка совпадений: единственное правило, первое совпадение или другая выбранная политика.
- Неизвестные значения: что происходит до применения правил, если необходимый факт отсутствует?
- Примеры: обычный случай для каждого результата и граничные случаи для диапазонов.
На доске Boardmix разместите определения входных данных слева, таблицу в центре, а примеры обращений справа. Используйте одинаковые идентификаторы правил в таблице и тестовых случаях. Тогда участник обсуждения сможет сослаться на R3, а не говорить «третья штука посередине». Нерешённые вопросы по политике держите отдельно от утверждённых строк.
После согласования направлений свяжите решение с общим процессом: получить обращение, собрать нужные сведения, применить правила и направить обращение дальше. Откройте Boardmix, чтобы описать таблицу решений и рабочий процесс.
