Введение
Бизнес в своей работе принимает различные бизнес-решения для максимизации прибыли: какую скидку предоставить клиенту, какой продукт предложить, одобрить сделку или нет и прочее. Все эти бизнес-решения принимаются на основании комбинации различных данных. Компании стараются автоматизировать эти процессы, чтобы снизить риски и повысить эффективность.
Автоматизация бизнес-решений включает такие действия, как выявление, спецификация и изменение требований в течение жизненного цикла программного продукта. На каждом из этих этапов аналитик может столкнуться со следующими проблемами:
Выявление требований: проблема анализа и выявления противоречий бизнес-правил клиента.
Спецификация требований: сложность описать множество требований с разными условиями поведения, трудность представления данных требований команде и клиенту.
Изменение требований: импакт-анализ и проблема быстрого внесения исправлений.
В своей работе для решения этих проблем я примерял Таблицы принятия решений (Decision table).
Для лучшего понимания данной статьи желательно иметь общее представление о DMN. Немного теории:
Decision Model and Notation (DMN) — это стандарт, разработанный OMG (Object Management Group). Стандарт предназначен для описания и моделирования повторяющихся решений в организациях.
Одной из целей DMN является стандартизация различных форм и типов таблиц принятия решений. Стандарт предполагает представлять требования в виде графов (Decision Requirements Graph), диаграмм (Decision Requirements) и Таблицы принятия решений.
Таблицы принятия решений могут быть вертикально и горизонтально-ориентированные. Для любой ориентации таблицы главными атрибутами являются входные и выходные параметры. Входные параметры — это условия или переменные. Выходные параметры — это результат для определенного набора входных параметров. На рисунке ниже вы можете посмотреть примеры вертикально и горизонтально-ориентированной таблицы с одинаковым набором входных и выходных параметров.
Практическая часть
Перейдем от теории к практике. Процесс получения кредита наличными или на счет можно представить в виде действий:
Клиент подает заявление на кредит.
Система выполняет скоринг: автоматический процесс анализа платежеспособности клиента на основании данных его анкеты.
Сотрудник банка выполняет верификацию анкетных данных клиента.
Происходит выдача кредита: подписание договора с клиентом и выдача средств клиенту
Безусловно в этом процессе могут быть различные «если». Для понимания контекста прошу схему процесса ниже считать полной и достаточной. В разное время при работе с данным процессом передо мной ставили различные задачи, которые я решал с помощью Таблиц принятия решений:
Доработать предложение клиенту кредитного продукта в зависимости от различных входных условий: возраст, статус и другое.
Оптимизировать Верификацию заявки сотрудником банка: решение должно подсказывать верификатору, какие проверки и в какой очередности выполнять, верификатор должен выполнять все необходимые проверки, решение должно быть конфигурируемым.
Задача 1. Предложить клиенту доступный кредитный продукт
Описание задачи: Доработать предложение клиенту кредитного продукта в зависимости от различных входных условий: возраст, статус и другое.
Использовал в работе: Варианты использования, Таблицы принятия решений.
Первое действия в процессе получения кредита — «Подать заявление на кредит» клиентом. Действия пользователя можно представить в формате Варианта использования:
1. Пользователь инициирует заполнение заявки.
2. Система отображает форму для идентификации клиента.
3. Пользователь заполняет данные: ФИО, номер телефона, согласие на обработку персональных данных.
4. Система отправляет данные для аутентификации клиенту и отображает клиенту форму для аутентификации.
5. Пользователь вводит данные для аутентификации.
6. Система проверяет введенные данные.
7. Система сохраняет данные Пользователя.
8. Система отображает анкетные данные для заполнения: личные данные и данные о доходах и расходах.
9. Пользователь заполняет данные и подтверждает завершение заполнения.
10. Система сохраняет заполненные данные.
11. Система предлагает Пользователю доступный кредитный продукт: срок кредитования, сумма кредитования, необходимость страховки.
12. Пользователь выбирает условия кредитования и дает согласие на запрос кредитной истории.
13. Система сохраняет заполненные данные и информирует клиента о принятии заявки в работу.
Обратите внимание на 11 шаг. Тут не расписано как именно система предлагает доступный кредитный продукт. Как это показать? Передо мной стояла именно такая задача: понятно и полно описать требования к определению условий выбора системой кредитного продукта.
Для решения данной проблемы можно использовать стандартный шаблон функциональных требований [Условие] + [Система должны].
Если клиент «Новый» и его возраст от 18 до 58 лет, то Система должна предложить клиенту кредитный продукт «Старт»
Если клиент «Новый» и его возраст от 20 до 58 лет, а разница его доходов превышает расходы на 100000 рублей и кредитная история отсутствует или положительная, то Система должна предложить клиенту кредитный продукт «Успех»
и т.д.
Однако в таком случае придется написать несколько отдельных требований, связать их друг с другом и затем каждое отдельное предложение связать с шагом 11 Варианта использования. К тому же сами требования достаточно сложные для восприятия человеком. Мне такой способ показался неудобным. Сделав несколько подходов, я свел все правила выбора кредитного продукта в одну Таблицу принятия решений. На рисунке ниже вы можете увидеть, что у меня получилось. Это представление видится более компактным и удобным для анализа и презентации команде и заказчику.
Примечание: Обратите внимание на первые две строки. На примере видно, как для нового клиента банка может быть предложен продукт «Старт» или «Успех». Выбор продукта зависит от трех других параметров: «разницы доходов и расходов», «кредитной истории», «возраста» клиента.
Задача 2. Оптимизировать работу верификатора
Описание задачи: решение должно подсказывать верификатору, какие проверки и в какой очередности выполнять, верификатор должен выполнять все необходимые проверки, решение должно быть конфигурируемым.
Использовал в работе: Анализ бизнес-правил, Моделирование процессов, Таблицы принятия решений.
Работу я начал с анализа бизнес-правил: что именно проверяют верификаторы, что является критерием отказа в кредите, при каких условиях нужно дополнительно связаться с клиентом для уточнения данных. Эти правила определяют риск-менеджеры. Часть правил устанавливается законодательством страны, часть правил регламентируется самим банком.
Сначала я попробовал использовать Моделирование процессов: с помощью нотации BPMN. Я описал действия подпроцесса «Верифицировать заявление». На рисунке ниже представлена часть схемы.
Однако ветвлений было так много, что я остановился не закончив ее. Анализировать, синтезировать и выявлять противоречия в такой форме не удобно.
Таблицы принятия решений помогли мне справиться с трудностями. Что я делал?
Анализ: собрал все бизнес-правила в таблицу.
Синтез: выполнил объединение нескольких однотипных правил в одно.
Визуализация: совместил таблицу принятия решений со схемой BPMN.
Ниже вы можете видеть фрагмент Таблицы принятия решений, содержащей все правила.
Такая форма представления требований позволяет удобно выполнять поиск противоречий в правилах, а также объединять несколько правил в одно. Например, если клиент предоставил удостоверяющий документ NIE или DNI и есть подозрения на его фальсификацию, то выполнять остальные проверки уже не требуется. Причина: результат этих проверок не повлияет на конечный результат. В таблице ниже вы можете видеть пример такого объединения.
После этого я совместил схему BPMN с Таблицей принятия решения и смог представить это заказчику и команде.
Бизнес-правила для Верификатора меняются. Сделать данное решение конфигурируемым (настраиваемым) можно с помощью No-code/low-code систем. Одной из таких систем является OpenL. Она предоставляет возможность конфигурировать решение с помощью Таблиц принятия решений. Пользователь может через окно браузера или через экспорт-импорт excel файлов вносить необходимые изменения в требования. Изменения сохраняются и сразу доступны в рабочем продукте Верификаторам. Знание принципов Таблиц принятия решений помогло мне быстро освоиться в системе OpenL и вносить необходимые изменения.
В заключение
Знание принципов построения таблиц Таблиц принятия решений из DMN поможет вам:
улучшить качество формулируемых вами требований: сделает их полными и удобными для анализа и презентации.
повысит ваш уровень компетенций в работе с no-code системами для конфигурации готовых решений: сделает вас более востребованными на рынке.
Помните, что таблицы «используются, когда бизнес-аналитик моделирует требование или набор требований, имеющих сложную, но однородную структуру, которая может быть разбита на элементы, применимые к каждому значению в таблице» (цитата из «Руководстве к своду знаний по бизнес-анализу, ВАВОК). Разумное сочетание табличного представления требований вместе с другими формами представления требований может быть удобным инструментом в руках бизнес-аналитика и системного аналитика.
Полезные ссылки
-
Статьи и видео для общего понимания:
OpenL Tablet. No-code система использующая Decision Model and Notation
Комментарии (2)
PavelSandovin
14.08.2022 22:52+1Спасибо за эту статью и ссылки на стандарт OMG.
В своей практике применяю таблицы решений достаточно часто. Поделюсь в этом комментарии отработанной на многих проектах техникой:
1. Если валидатор проверяет 1, 2 или 3 атомарных бинарных условий - таблица решений не нужна, так как пространство состояний не превосходит 2^3 = 8 и легко перечисляется непосредственно.
2. Если условий 3, 4 и среди них есть небинарные, имеет смысл уже браться за Excel (или иную таблицу) и строить таблицу решений.
3. Если условий 5 и более, то не важно, бинарные они или нет - таблицу решений делать обязательно.
4. В процессе построения таблицы решений всегда следует проводить 2 этапа:
а) формальный - просто выписываем все пространство состояний;
б) кластеризация и отбрасывание "невозможных" по бизнесу случаев (например, если поле "Серия паспорта" обязательно для заполнения, и передается от подсистемы, дающей гарантию на его заполнение - все кейсы с пустым значением этого поля можно помечать как невалидные).
При этом на шаге б) значения не стоит выкидывать совсем, лучше их помечать каким-либо цветом или зачеркнутым шрифтом. Потом соответствующие колонки (строчки) можно скрыть.
Почему сразу не начать с п. б)? В некоторых случаях так делать можно, но есть риск механических ошибок. Поэтому лучше все же сохранить историю построения таблицы.
Один из самых успешных случаев применения описанной техники - организация тестирования функционала на основании таблицы решений, в которой пространство возможных состояний составляло более 530 кейсов. Это позволило за 2 недели выявить, и оперативно ликвидировать ошибки, которые до того тянулись из релиза в релиз.
Так что подтверждаю, таблицы решений - мощный и нужный инструмент.
Myclass
Вы описали пример, который в каждой книге по BPMN присутствует. Но не используя Rule Task где как рад таки он и нужен - в месте, где используется score или решение, основанное на матрице решений. Новичкам я посоветовал бы не вашу статью, а именно книгу. У вас это как-то сложновато описано. Хотя, кто знает - может быть найдётся свой читатель.