Использование Таблиц принятия решений (Decision Model and Notation) на практике

07.08.25

Автоматизация бизнес-решений включает такие действия, как выявление, спецификация и изменение требований в течение жизненного цикла программного продукта. На каждом из этих этапов аналитик может столкнуться с неочевидными бизнес-правилами и их противоречиями, которые затрудняют описание логики системы. Расскажем о том, как выявить, специфицировать и проверить требования на полноту с помощью таблиц принятия решений (Decision Model and Notation, DMN).

Меня зовут Артем Кагукин. В ИТ я с 2008 года, и за это время я успел поработать на разных позициях – в сопровождении, тестировании, был менеджером продукта. Но большая часть моего рабочего пути связана с бизнес-анализом и системным анализом. Я работал в различных продуктовых и аутсорс-компаниях, моими заказчиками были как госкомпании, так и частные клиенты. Сейчас я руковожу отделом бизнес-анализа и системного анализа, оставаясь при этом практикующим специалистом – продолжаю заниматься выявлением и спецификацией требований. А еще я преподаю бизнес-анализ и системный анализ.

Принятие решений в условиях сложной бизнес-логики

Бизнес в своей работе постоянно сталкивается с необходимостью принимать решения – как на уровне компании, так и на уровне департамента или отдельного специалиста. Это актуально для любой предметной области:

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

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

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

клиент подает заявку;
сотрудники банка проверяют заявление;
в результате проверки принимается одно из трех решений:
- кредит одобряется и выдается с подписанием документов, перечислением денег и т. д.;
- заявка отклоняется с уведомлением клиента;
- также возможен контроффер – встречное предложение с измененными условиями (допустим, клиент хотел получить 100 тысяч рублей на год, а мы ему предлагаем 50 тысяч на год. Или наоборот, предлагаем 100 тысяч на 2 года).

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

На слайде представлен реальный пример методической инструкции компании, где я работал. Инструкция на английском, потому что это небанковская кредитная финансовая организация для Мексики. Общий объем – порядка 44 страниц. На слайде показано только оглавление, но этого достаточно, чтобы убедиться, что проверок действительно много.

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

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

При проектировании любой новой функциональности информационной системы аналитик может столкнуться с проблемами выявления и спецификации требований. Нужно определить:

Есть ли противоречия в многообразии выявленных бизнес-правил?
Все ли требования выявлены, все ли комбинации бизнес-правил учтены?
Как сгруппировать требования в спецификации?
Как их презентовать команде и клиенту?

Возникает еще и такой вопрос – какой формат представления требований лучше для моделирования сложной бизнес-логики?

Под «форматом» представления требований я подразумеваю:

текстовый;
матричный – в виде таблицы;
графический – в виде различных диаграмм;
прототипы – в виде экранных форм.

Под словосочетанием «лучше для моделирования» – подразумеваю формат, который удобнее использовать для:

выявления противоречий и пропусков,
детализации – раскладывания требований на части;
объединения требований в целое.

А «сложная бизнес-логика» здесь подразумевает то, что комбинаций бизнес-правил достаточно много: используются не 2?3 бизнес-правила, а гораздо больше – 15?20 и так далее.

С моей точки зрения, для моделирования сложной бизнес-логики удобнее всего использовать матричные (табличные) и графические формы представления. И мы сейчас попробуем в этом попрактиковаться – разберемся, как строить такие модели.

Построение модели системы как часть работы системного аналитика

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

Системный аналитик может выбирать один или несколько форматов представления требований для моделирования системы:

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

Эти определения взяты из русского перевода BABOK Guide – свода знаний по бизнес-анализу от Канадского института IIBA.

Для построения моделей существуют аналитический и синтетический методы:

Аналитический метод основан на разложении сложной системы или набора бизнес-правил на более простые, логически обособленные элементы. Мы последовательно выделяем отдельные части, изучаем их, и в случае неполного понимания – делим дальше. Таким образом, постепенно формируется целостное представление о работе системы в целом и о том, как функционируют заложенные в ней правила.
Синтетический метод, наоборот, предполагает изучение системы в контексте ее окружения. Мы рассматриваем бизнес-правила как часть живой среды, где они взаимодействуют с другими системами, объектами и процессами. Вы изучаете эти взаимодействия и, дополняя по мере необходимости модель новыми элементами, понимаете, как работает ваша система.

Мы сейчас будем работать по аналитическому методу – будем дробить бизнес-правила на части, анализировать их логику, выделять отдельные блоки, а затем – собирать общую картину работы системы и формулировать постановку задачи.

Этап №1: изучаем бизнес-правила

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

У нас есть три упрощенных бизнес-правила.

Если погода ясная и безветренная, и я не работаю, то я пойду за едой в магазин.
Если погода дождливая или ветреная, то я закажу еду.
Если я работаю, то я закажу еду.

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

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

Блок, связанный с погодой – погода ясная и безветренная, дождливая или ветреная.
И блок, связанный с работой – работаю и не работаю.

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

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

Для начала изучим исходные документы от бизнеса – это два бизнес-правила: правило выдачи кредита и правило формирования контроффера.

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

Попробуем применить к этим документам аналитический метод – выделим из общей информации о существующих бизнес-правилах 3-4 «блока правил». Например, такие:

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

Подчеркну, что это – один из возможных вариантов. С помощью аналитического метода вы можете выделить в системе 5, 6 или даже 10 блоков – то, как именно вы разобьете бизнес-логику, зависит только от вас. Главное – что мы здесь применяем аналитический метод: дробим систему либо набор бизнес-правил на куски и по этим кускам пытаемся понять принципы работы всей системы.

В данном конкретном случае мы продолжим работать с тремя блоками.

При декомпозиции могут возникнуть проблемы – когда мы решаем:

сколько блоков правил выделить;
как назвать блоки правил.

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

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

По факту, это форма представления требований.

Синим цветом в таблице выделены колонки со входными параметрами – в данном случае: тип клиента и размер заказа.
Зеленым цветом обозначена колонка выходного параметра – размер скидки.

У каждого входного параметра есть перечень возможных значений

Для типа клиента возможных значений два – VIP и обычный.
Для размера заказа возможных значений тоже два – < 10 и >=10.
И для скидки три возможных значения – 0.05, 0.10 и 0.15.

И далее выводим перечень комбинаций этих входных параметров, в данном случае:

VIP-клиент с размером заказа <10 получит скидку 0.10
VIP-клиент с размером заказа >= 10 получит скидку 0,15
обычный клиент с любым размером заказа – скидку 0.05

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

Таблицы принятия решений являются частью нотации DMN (Decision Model and Notation) – это международный стандарт, предназначенный для описания и моделирования повторяющихся решений в организациях.

В нотации DMN используются три способа представления требований:

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

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

Я вам сейчас дам лишь базовое представление о работе с таблицами принятия решений – только минимум, который я использовал в работе. В целом стандарт Decision Model and Notation (DMN) предлагает гораздо более широкий инструментарий для моделирования. В конце я дам ссылки для самостоятельного изучения, а сегодня мы сосредоточимся на основах.

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

Мы условно делим входные данные на три блока: «Документ», «Доходы» и «Кредитная история».
Каждый из этих блоков можно детализировать на два входных параметра.
У каждого из этих входных параметров есть несколько возможных вариантов значений.
И последний столбик – это выходной параметр – некий результат:
- либо выдаем кредит;
- либо не выдаем;
- либо проверяем вручную;
- либо предлагаем контрофер согласно той схеме BPMN, которая у нас была определена ранее.

Получается, что всего у нас 6 входных параметров: у первого – три возможных значения, у остальных – по два.

Если перебрать все возможные комбинации, то согласно правилам комбинаторики получится 3 * 2 * 2 * 2 * 2 * 2 = 96 вариантов комбинаций входных параметров.

Это достаточно много, поэтому мы эти входные параметры сейчас упростим – я сейчас расскажу, как.

Этап №2: выделяем блоки правил

Но прежде давайте снова вернемся к упрощенному примеру про погоду и работу.

В этом примере у нас два блока бизнес-правил: Погода и Работа.

Определим параметры для блока правил «Погода»:

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

Таким образом, мы формируем набор входных параметров для двух блоков правил.

Первый блок «Какая погода?» – условный параметр, принимающий два значения: «Хорошая» и «Плохая».
Второй блок – «Я работаю?» – тоже два возможных значения: «Работаю» и «Не работаю».
И выходной параметр – это итоговое действие: либо «Схожу за едой», либо «Закажу еду».

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

Сначала берем параметр «Хорошая погода» – с ним возможны две строки: «Работаю» и «Не работаю».

Аналогично для параметра «Плохая погода» – снова две строки «Работаю» и «Не работаю».

Итого получается 2 * 2 = 4 строки.

Далее, анализируя бизнес-правила, мы заполняем выходные значения для каждой комбинации. Например:

если погода хорошая и я не работаю – схожу за едой;
во всех остальных случаях – закажу еду.

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

Так, блок «Документ», который содержал два входных параметра, мы сводим к одному блоку: «Документ удостоверяющий личность валиден?» – Да или Нет.

То же самое делаем с двумя другими блоками:

«Источник доходов есть и позволяет платить за кредит?» – Да или Нет
«Кредитная история положительная?» – Да или Нет.

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

Таким образом, это уже не 96 возможных комбинаций параметров, а гораздо меньше – 2 * 2 * 2 = 8.

С этим уже можно начинать работать – заполнять таблицу для 8 возможных комбинаций входных параметров.

Для удобства я буду использовать числовой формат 0=нет и 1=да, потому что так удобнее воспринимать комбинации. На этом этапе нам просто нужно просто вспомнить комбинаторику – заполнить 8 строк уникальными комбинациями полей для трех входных параметров.

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

Напомню, что у нас предусмотрено 4 возможных варианта выходных параметров:

1 – выдаем кредит;
0 – не выдаем;
2 – проверяем вручную;
3 – предлагаем контроффер.

Рассмотрим, какие проблемы могут возникнуть при определении выходных параметров:

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

Здесь показан результат – выходные параметры для трех блоков правил. Мы здесь видим:

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

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

Например, мы видим, что если документы не прошли проверку, остальные параметры уже неважны – решение в этом случае будет отрицательным.

Это позволяет объединить несколько строк в одну и упростить таблицу принятия решений, сократив количество бизнес-правил.

Этап №3: разбираемся с отдельными блоками

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

Вернемся к упрощенному примеру, где мы выделялил блоки «Какая погода?» и «Я работаю?»

Вроде с работой здесь только два варианта, а вариантов погоды побольше – есть ясная, безветренная, дождливая и ветреная погода.

Таким образом мы можем определить:

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

Например, если погода ясная (1) и безветренная (0), то она хорошая: 1.0.0 = хорошая.

Для всех остальных вариантов – дождливая или ветреная – погода плохая.

Ну и есть еще восьмое бизнес-правило, когда погода не ясная, не дождливая, не ветреная – непонятно, что делать. Такое тоже в практике может случаться. Будете обращаться к стейхолдерам, к владельцам бизнес-правил, чтобы они давали соответствующие пояснения – возможно, где-то что-то упущено. Может, инструкцию не ту дали.

Возвращаемся к примеру с кредитной заявкой и пытаемся проанализировать блок правил «Документ». У него есть два входных параметра:

Тип документа – паспорт (0), вид на жительство (1), другое (2)
Срок окончания – не прошел (0), прошел (1)

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

А далее – определить результат комбинаций (выходные параметры) согласно описанию в бизнес-правилах – проверка документа пройдена: Да (1) или Нет (0).

Какие проблемы могут возникнуть на этапе анализа конкретного блока?

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

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

Теперь упрощаем – с помощью фильтра определяем правила для невалидных документов.

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

У нас определяется комбинация параметров для валидных документов, а все остальное мы считаем невалидным – и определяем это в конце последней строкой:

Если у нас в качестве документа используется паспорт и срок удовлетворяет – документ валиден.
Если тип документа – вид на жительство и срок удовлетворяет – тоже документ валидный.
Все остальные варианты не подходят.

Сделаем то же самое для блока правил «Доходы».

У него тоже два входных параметра:

Ежемесячные перечисления на счет в течение 12 месяцев есть?
X > какого-то значения?, где X равно средняя ежемесячная сумма доходов / сумму кредита

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

Проговорю, какие проблемы на этом этапе могут возникнуть:

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

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

Если ежемесячные перечисления на счет в течение 12 месяцев есть и проверка соотношения пройдена, то мы считаем, что источник доходов есть и позволяет платить за кредит.
В остальных вариантах проверка на источник дохода считается не пройденной.

И последнее – попробуем составить и заполнить таблицу принятия решений для блока правил «Кредитная история».

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

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

Брал в течение прошедших двух лет кредит у нас и вернул без просрочки? Значения – Да или Нет.
Кредитная история у агрегатора? Значения – Положительная (1) или Отрицательная (0).

И значения выходного параметра:

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

Таким образом мы смогли выявить, специфицировать и проверить требования на полноту. Для этого мы составили:

Общую таблицу принятия решения, состоящую из принятия решения по трем блокам правил – «Документ», «Доходы», «Кредитная история».
И после изучения бизнес-правил по каждому из этих блоков составили для них три отдельные таблицы принятия решений.

Этап №4: визуализируем связи между процессом и таблицами принятия решений

Чтобы все это визуализировать и показать результат заказчику и команде, можно использовать BPMN.

В BPMN для действий есть отдельный элемент «Business Rule», для которого просто можно сделать гиперссылку на общую таблицу принятия решений для этих трех блоков.

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

Таким образом из BPMN мы переходим на общую таблицу, а потом из общей таблицы к конкретным: по документам, доходу, кредитной истории – можем и общую картину показать, и по отдельности посмотреть.

Также можно визуализировать связь между процессом и таблицами принятия решений с помощью диаграмм Decision Model and Notation.

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

Для начала расскажу, какие элементы здесь что означают:

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

Итого: нас была общая таблица принятия решений под названием «Решение о выдаче кредита» – она обозначается соответствующим прямоугольником.

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

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

Проверка кредитной истории
Проверка доходов
Проверка Документов удостоверяющих личность

На уровне каждой отдельной таблицы мы можем посмотреть входные данные.

Допустим, для таблицы принятия решений «Проверка доходов» входные параметры:

Операции по счету клиента
Сумма кредита, которую он непосредственно запросил в заявлении.

Источником для входного параметра «Операции по счету клиента» был «Счет клиента в банке».

А для входного параметра «Сумма кредита» – «Заявка клиента». Соответствующие элементы и связи показывают нам это.

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

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

Особенности использования Decision Model and Notation: таблиц принятия решений и диаграмм.

Какие можно выделить преимущества?

Таблицы принятия решений помогают управлять большим количеством правил – выявлять противоречия, пропуски и зависимости. Используя обычные фильтры Excel можно быстро и удобно находить всю нужную вам информацию.
Таблицы принятия решений хорошо сочетаются с BPMN. В случае сложных схем с множеством ветвлений и шлюзов, DMN позволяет вынести бизнес-логику в отдельные таблицы и тем самым упростить и сделать нагляднее основную BPMN-схему.
Таблицы принятия решений можно использовать для автоматизации. Существуют платформы, которые позволяют использовать DMN не только как способ визуализации, но и как рабочий инструмент в автоматизированных системах. Примеры:
- Terrasoft BPM’Online или российская альтернатива ELMA365 – комплексные решения для автоматизации бизнес-процессов.
- Sparx Enterprise Architect – инструмент с поддержкой DMN.
- OpenL Tablets – система, с которой я лично работал. Мы использовали её в страховой компании для моделирования логики работы с разными штатами США (Техас, Нью-Йорк и др.). Например, набор полей, форма валидации, расчеты страховых премий – всё это моделировалось с помощью таблиц. Таблицы можно было редактировать через Excel или веб-интерфейс, а потом система принимала на вход набор параметров и возвращала результат, например, рассчитанную страховую премию. DMN в таком виде использовалась и для бизнес-решений, и для организации взаимодействия между фронтом и бэком.

Какие могут быть сложности?

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