Моделирование решений · Конспекты по бизнес-анализу

Что это#

Руководство BABOK® описывает модели решений (decision models) как способ показать, как данные и знания объединяются для принятия конкретного повторяющегося решения; часто их используют вместе с моделями процессов. Важны три элемента: решение, информация, которую оно использует, и знания (правила), которые оно применяет. Руководство называет три нотации:

Таблицы решений (decision tables) — когда результат зависит от сочетаний значений нескольких входов. Каждая строка — правило, каждый столбец — вход, последний столбец — результат.
Деревья решений — когда решения следуют одно за другим; ветви показывают альтернативы.
Диаграммы требований к принятию решений — для сетей взаимозависимых решений.

Взгляд DMN#

Стандарт OMG «Модель и нотация решений» (Decision Model and Notation, DMN) — первоисточник диаграмм требований к принятию решений. Он разделяет два уровня:

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

На диаграмме требований к принятию решений есть элементы четырёх типов: решение; модель бизнес-знаний (повторно используемая логика — набор правил, таблица решений или прогнозная модель); входные данные; источник знаний (полномочный источник, на котором основана логика, — политика, нормативный акт или эксперт). Их связывают требования трёх видов: требование к информации (данные или подрешение поступают в решение), требование к знаниям (решение вызывает модель бизнес-знаний) и требование к полномочиям (источник знаний управляет решением или моделью).

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

Политики срабатывания#

Если одним и тем же входам может соответствовать больше одной строки таблицы решений, DMN требует, чтобы в таблице была объявлена политика срабатывания (hit policy):

Для одного результата: Unique (перекрытия запрещены), Any (перекрытия допустимы, только если дают одинаковый результат), Priority (побеждает результат с наивысшим приоритетом) и First (побеждает первая по порядку подходящая строка). Спецификация предостерегает от опоры на First: тогда смысл таблицы зависит от порядка строк.
Для нескольких результатов: Output order, Rule order и Collect — с возможной агрегацией в виде суммы, минимума, максимума или количества.

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

Когда применять#

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

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

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

Как это делать#

Сформулируйте решение как вопрос с определённым набором возможных ответов.
Нарисуйте требования: входные данные, подрешения, модели бизнес-знаний и источники знаний.
Выберите представление для логики каждого решения: таблицу, дерево или одно предложение, если решение тривиально. Вигерс и Битти советуют переходить от текста к таблицам или деревьям, как только условия начинают сочетаться.
Постройте таблицу: по столбцу на каждый вход, результаты справа, по одному правилу в строке. Используйте - для «любое значение».
Проверьте полноту и перекрытия. Каждое сочетание должно попадать под какое-то правило. Следите за границами: Вигерс и Битти предостерегают от диапазонов вроде 1–5 и 5–10, где непонятно, какое правило покрывает 5.
Явно объявите политику срабатывания.
Проверьте таблицу на реальных случаях, включая граничные значения, и получите подтверждение владельца правила.
Свяжите решение с шагом процесса, который его использует, и договоритесь, кто может менять правила.

Пример#

«Мастерская» (вымышленная сеть веломастерских) хочет, чтобы система онлайн-записи автоматически решала, нужна ли предоплата.

Требования к принятию решения:

Решение
Входные данные
Модель бизнес-знаний (таблица решений)
Источник знаний

Рис. 1. Требования к решению «Нужна предоплата?». Сплошные стрелки — требования к информации, пунктирные стрелки — требования к знаниям, пунктирная линия с точкой — требование к полномочиям. Нотация: диаграмма требований к принятию решений DMN (упрощённые фигуры)

Показать текстом

Решение: «Нужна предоплата?»
  <- информация: Тип клиента (входные данные)
  <- информация: Неявки за последние 12 месяцев (входные данные, из истории бронирований)
  <- информация: Оценка стоимости ремонта (входные данные)
  <- знания:     Правила предоплаты (модель бизнес-знаний: таблица решений)
                    <- полномочия: Политика бронирования владельца (источник знаний)

Таблица решений (политика срабатывания U, суммы в долларах, вымышленные):

U	Тип клиента	Неявки за последние 12 месяцев	Оценка стоимости	Нужна предоплата
1	Зарегистрированный	0	-	Нет
2	Зарегистрированный	1 и более	-	Да
3	Новый	-	меньше 150	Нет
4	Новый	-	150 и более	Да

Позже владелец добавляет: «Для грузовых велосипедов предоплата нужна всегда». Новая строка для грузовых велосипедов перекрыла бы правило 1 и нарушила бы политику Unique. Аналитик просит владельца выбрать: добавить столбец «тип велосипеда» и разделить правила или перейти на Priority, поставив «Да» выше «Нет». Конфликт разрешают на встрече, а не в коде.

Частые ошибки#

Несколько решений втиснуты в одну таблицу → моделируйте каждое решение отдельно и связывайте их на диаграмме требований.
Пробелы и пересекающиеся диапазоны → проверяйте граничные значения и объявляйте политику срабатывания.
Политика First скрывает конфликты → разрешите конфликт или используйте Priority с явным ранжированием.
Решения закодированы цепочками шлюзов процесса → смоделируйте решение один раз и ссылайтесь на него из процесса.
Неопределённые входные термины → определите каждый вход в глоссарии или словаре данных.
Нет владельца правил → зафиксируйте источник знаний и того, кто утверждает изменения.

Чек-лист#

Решение сформулировано как вопрос с закрытым набором ответов.
Показаны все входы, подрешения и источники знаний.
Каждый входной термин определён.
Таблица полна; границы проверены.
Политика срабатывания объявлена.
Реальные случаи разобраны с владельцем правила.
Определён шаг процесса, который использует решение.

Источники и что почитать#

IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015. Рус. изд.: Руководство к своду знаний по бизнес-анализу (Руководство BABOK®), версия 3.0. Техника 10.17 «Моделирование решений».
Object Management Group. Decision Model and Notation (DMN), version 1.1. 2016. Рус. пер.: официальный перевод спецификации DMN 1.1 (ELMA). Разд. 5 (введение), 6 (требования к принятию решений) и 8 (таблицы решений и политики срабатывания).
K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013. Рус. изд.: К. Вигерс, Дж. Битти. Разработка требований к программному обеспечению, 3-е изд. М.: Русская редакция; СПб.: БХВ-Петербург, 2014. Гл. 9 (бизнес-правила, таблицы решений, пересекающиеся диапазоны).
Учебные материалы по бизнес-анализу (модуль «Анализ стратегии»: таблицы решений и деревья решений).