analyst.by

Белорусское сообщество бизнес и системных аналитиков

Делаем качественные требования с помощью Таблиц принятия решений

Автор: Артем Кагукин

Я в бизнес-анализе более 10 лет. На данный момент работаю Lead BA в компании *Instinctools и преподаю в IT-Academy. За это время я успел поработать с разными клиентами, командами, подходами. Пробовал различные способы спецификации требований: моделирование с использованием нотации BPMN и UML, естественный язык, таблицы событий и реакций системы, прототипирование и прочее. В этой статье хочу поделиться своим опытом использования Таблиц принятия решений (Decision Table) и показать, как и для каких целей их можно использовать. 

Введение

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

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

  • Выявление требований: проблема анализа и выявления противоречий бизнес-правил клиента.

  • Спецификация требований: сложность описать множество требований с разными условиями поведения, трудность представления данных требований команде и клиенту.

  • Изменение требований: импакт-анализ и проблема быстрого внесения исправлений.

В своей работе для решения этих проблем я примерял Таблицы принятия решений (Decision table).

Для лучшего понимания данной статьи желательно иметь общее представление о DMN. Немного теории:

  • Decision Model and Notation (DMN) — это стандарт, разработанный OMG (Object Management Group). Стандарт предназначен для описания и моделирования повторяющихся решений в организациях.

  • Одной из целей DMN является стандартизация различных форм и типов таблиц принятия решений. Стандарт предполагает представлять требования в виде графов (Decision Requirements Graph), диаграмм (Decision Requirements) и Таблицы принятия решений.

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

Вертикально-ориентированные таблицы: правила в столбцах

Горизонтально-ориентированные таблицы: правила в строках

https://lh4.googleusercontent.com/gcPDTeMVRZl2SD0IKI43W1n1O5Sb5F_wGj9ha093ceaob32FE9SzOHmzeYsOc3cgRYFUVT4R65SZLJe2gGSAaxugAFgYcjHQOXdwrPmpmSauIwCIjzgQ-mjbf0ila4DEgW3L1pMUCTc7rHAq5UHWTw

https://lh3.googleusercontent.com/zDPohM9xgas0LVWUVxzCuswSbjTGoDZEn9M5u_6Bj3CDAhKeed9B1LXkgCWt8NzMYN-luwibJCpb-l68Nc9YMsRIptMyCdyylscjyhR-WVVhbXhsUVjkFYBua2n_r2-k750fB6Y4N06BbSHc0mixIA

 

Практическая часть

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

  • Клиент подает заявление на кредит.

  • Система выполняет скоринг: автоматический процесс анализа платежеспособности клиента на основании данных его анкеты.

  • Сотрудник банка выполняет верификацию анкетных данных клиента.

  • Происходит выдача кредита: подписание договора с клиентом и выдача средств клиенту

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

  • Доработать предложение клиенту кредитного продукта в зависимости от различных входных условий: возраст, статус и другое.

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

 

https://lh4.googleusercontent.com/m1pM3xzZROpUCjw_fUYCBFvAbE1cM5GzawhZPPRDSRBl3Ut-lUOfjCGSKzbmL0aAZa7ToBGBW8u5lXhjgDsosbBv2JKC2pdyoNf22NRNA_p02BZStIApRhn-gIQzN2ZeQ3rWOkKSkEXGKOERRJEh3w

Предложить клиенту доступный кредитный продукт

 

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

Использовал в работе: Варианты использования, Таблицы принятия решений.

Первое действия в процессе получения кредита — «Подать заявление на кредит» клиентом. Действия пользователя можно представить в формате Варианта использования:

1. Пользователь инициирует заполнение заявки.

2. Система отображает форму для идентификации клиента.

3. Пользователь заполняет данные: ФИО, номер телефона, согласие на обработку персональных данных.

4. Система отправляет данные для аутентификации клиенту и отображает клиенту форму для аутентификации.

5. Пользователь вводит данные для аутентификации.

6. Система проверяет введенные данные.

7. Система сохраняет данные Пользователя.

8. Система отображает анкетные данные для заполнения: личные данные и данные о доходах и расходах.

9. Пользователь заполняет данные и подтверждает завершение заполнения.

10. Система сохраняет заполненные данные.

11. Система предлагает Пользователю доступный кредитный продукт: срок кредитования, сумма кредитования, необходимость страховки.

12. Пользователь выбирает условия кредитования и дает согласие на запрос кредитной истории.

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

Обратите внимание на 11 шаг. Тут не расписано как именно система предлагает доступный кредитный продукт. Как это показать? Передо мной стояла именно такая задача: понятно и полно описать требования к определению условий выбора системой кредитного продукта.

Для решения данной проблемы можно использовать стандартный шаблон функциональных требований [Условие] + [Система должны].

  • Если клиент «Новый» и его возраст от 18 до 58 лет, то Система должна предложить клиенту кредитный продукт «Старт»

  • Если клиент «Новый» и его возраст от 20 до 58 лет, а разница его доходов превышает расходы на 100000 рублей и кредитная история отсутствует или положительная, то Система должна предложить клиенту кредитный продукт «Успех»

  • и  т.д.

Однако в таком случае придется написать несколько отдельных требований, связать их друг с другом  и затем каждое отдельное предложение связать с шагом 11 Варианта использования. К тому же сами требования достаточно сложные для восприятия человеком. Мне такой способ показался неудобным. Сделав несколько подходов, я свел все правила выбора кредитного продукта в одну Таблицу принятия решений. На рисунке ниже вы можете увидеть, что у меня получилось. Это представление видится более компактным и удобным для анализа и презентации команде и заказчику.

https://lh5.googleusercontent.com/I2kwyvh1EpR7pqSXNTf1SkMhR3fjZNLAhRiLrpjwSVd7BOJs6yw1vUocEj7nLjnbiU0bsaXEA030klPHOtH2IWoG-AYpPT07YKLGfHtQRmganAhIeo6ayNNhgTr4YpSyaiKRut01V9voRbyX9XgGGA

 

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

Оптимизировать работу верификатора

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

Использовал в работе: Анализ бизнес-правил, Моделирование процессов, Таблицы принятия решений.

Работу я начал с анализа бизнес-правил: что именно проверяют верификаторы, что является критерием отказа в кредите, при каких условиях нужно дополнительно связаться с клиентом для уточнения данных. Эти правила определяют риск-менеджеры. Часть правил устанавливается  законодательством страны, часть правил регламентируется самим банком.

Сначала я попробовал использовать Моделирование процессов: с помощью нотации BPMN. Я описал действия подпроцесса «Верифицировать заявление». На рисунке ниже представлена часть схемы.

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

https://lh6.googleusercontent.com/QIpo8LdbY3LlYV1cbgOeBhjYcmM0KEhGf3SbIYZRG1fNQ289-tcQofl-U991lsLY-Ke1UQkx5-GUJoh-SYCiTVM-8Wtn35zeE7aB5w-b9t9egmbGJCpeVOv-lO25ji3wm8pPs7zVmKJviVKE209-iA

Таблицы принятия решений помогли мне справиться с трудностями. Что я делал?

  • Анализ: собрал все бизнес-правила в таблицу.

  • Синтез: выполнил объединение нескольких однотипных правил в одно.

  • Визуализация: совместил таблицу принятия решений со схемой BPMN.

Ниже вы можете видеть фрагмент Таблицы принятия решений, содержащей все правила.

https://lh4.googleusercontent.com/RY6cgN_-6HQ-QGrZcf9JJgmlgCpgFUnz7bM1_STZWosVo8aVDG6H6NxESRUQIix-qDnBPwWD8VBKvuTQfBs36mZDKB1JdZbumjxwuwi0Y0M9s3sbLfc7Mqeu4KP3_LDnGfFlPCSJjJUJQ5pIf23CgQ

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

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

https://lh4.googleusercontent.com/ip-XkMMhCs1w3OIVgQ4uZ9mop9lKecWszH4o1ziJJG19Cp23lvK3ukb9AuFpmPxgkgn4i9_l5XL0UIbsjL48RaaKg0henMZif659eSI_2u6o7O-bfCmsewB5Ac65mFe3TnN8x3oBpwKmbHUnQeXB9g

https://lh4.googleusercontent.com/nTTVaAZcepe8Lo7d4tM9MTLrwZg5dVwaE5Y38jZM7FHYc_hxFh5V9R2LMCW2slxRYtyjasZL-7ne9yJSAjeqLqU764D5qt209kWZQ4hELJRHWmAusCgQEMySFL1uMp5H61dWtaD2LQzPRFmVAT4AIw

После этого я совместил схему BPMN с Таблицей принятия решения и смог представить это заказчику и команде.

https://lh5.googleusercontent.com/nKStu_UIMfvDR0cVREDg46jrZwjOu5EA4VfSY7SXCMx9BaR0qeIrnWsnMXvjfPDFmBr1Grgok5Rjxu3Pc1RtD1XqT1J3pi6NIy1grG3wrJuyjyabPsMyTZldpOrWyj2YYhV2dtuzn6kQo5OseOIxPA

Бизнес-правила для Верификатора меняются. Сделать данное решение конфигурируемым (настраиваемым) можно с помощью No-code/low-code систем. Одной из таких систем является OpenL. Она предоставляет возможность конфигурировать решение с помощью Таблиц принятия решений. Пользователь может через окно браузера или через экспорт-импорт excel файлов вносить необходимые изменения в требования. Изменения сохраняются и сразу доступны в рабочем продукте Верификаторам. Знание принципов Таблиц принятия решений помогло мне быстро освоиться в системе OpenL и вносить необходимые изменения.

В заключение

Знание принципов построения таблиц Таблиц принятия решений из DMN поможет вам:

  • улучшить качество формулируемых вами требований: сделает их полными и удобными для анализа и презентации.

  • повысит ваш уровень компетенций в работе с no-code системами для конфигурации готовых решений: сделает вас более востребованными на рынке.

Помните, что таблицы «используются, когда бизнес-аналитик моделирует требование или набор требований, имеющих сложную, но однородную структуру, которая может быть разбита на элементы, применимые к каждому значению в таблице» (цитата из «Руководстве к своду знаний по бизнес-анализу, ВАВОК). Разумное сочетание табличного представления требований вместе с другими формами представления требований может быть удобным инструментом в руках бизнес-аналитика и системного аналитика.

 

Полезные ссылки

  1. Спецификация  Decision Model and Notation от OMG

  2. Статьи и видео для общего понимания:

  3. OpenL Tablet. No-code система использующая Decision Model and Notation

  4. Книга Real-World Decision Modeling with DMN by James Taylor

 


06 Августа, 2022


Добавить комментарий
Также Вы можете войти используя: Facebook Google