Меня зовут Артем Кагукин. В ИТ я с 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 в таком виде использовалась и для бизнес-решений, и для организации взаимодействия между фронтом и бэком.
-
Какие могут быть сложности?
-
Нет смысла использовать таблицы принятия решений для простых правил или небольшого количества правил.
-
Должна быть четко определена бизнес-терминология входных и выходных параметров. Здесь, как и с любым глоссарием, могут быть проблемы. – двойственности, нестыковки и так далее. Этот этап может занять значительное время, особенно при взаимодействии с несколькими заинтересованными сторонами.
-
Проблема определения полноты входных параметров. Таблица позволяет проверить все комбинации значений только по заданным параметрам. Но если вы упустили какой-то важный входной параметр, то даже при полной проработке всех известных комбинаций, итоговая логика окажется неполной.
Рекомендации и полезные ссылки
При применении таблиц принятия решений:
-
Идите от общего к частному.
-
Не пытайтесь сразу мельчить – разбивайте большой блок правил на кусочки постепенно и разбирайтесь с ними, Возможно, этого будет достаточно.
-
Комбинируйте форматы: таблицы принятия решений и диаграмм.
-
Используйте их разумно, с умом, и не бойтесь нового.
Вы можете использовать этот инструмент не только для автоматизации, но и просто для выявления и спецификации требований, потому что представление информации в Excel хорошо воспринимается бизнес-пользователями и не вызывает отторжения.
Полезные ссылки, которые могут пригодиться для дальнейшего изучения:
-
Спецификация Decision Model and Notation от OMG – того же консорциума, который разработал и UML. В спецификации описано множество нюансов: как задавать приоритеты правил, что делать при пересечении условий, как работать с множественными совпадениями и многое другое. Я показал вам лишь базу – те 20%, которые на практике покрывали у меня примерно 80% задач.
-
Делаем качественные требования с помощью Таблиц принятия решений – статья по итогам доклада, в котором я подробно рассказываю, почему таблица удобнее по сравнению с текстовыми форматами, с тем же Use case. Сейчас я не объяснял, почему таблицы лучше – просто показал, как ими пользоваться. Но если интересно узнать аргументы – можно ознакомиться.
-
Моделирование решений: краткий ликбез по нотации DMN для аналитика – материал про моделирование диаграмм.
-
Статьи и видео, которые мне в свое время помогли погрузиться в эту тему:
-
OpenL Tablet. No-code система использующая Decision Model and Notation – open-source движок для управления бизнес-правилами, с которым я работал в страховой сфере. Хорошее решение, особенно если нужно отделить логику от основной системы.
-
Книга Real-World Decision Modeling with DMN by James Taylor – книга на английском для тех, кто хочет глубже разобраться в теме.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции Анализ & Управление в ИТ-проектах 2023.
