Модель решения и обозначения - Decision Model and Notation

Модель решения и обозначения (DMN) - стандарт, опубликованный Группа управления объектами.[1] Это стандартный подход для описания и моделирования повторяемых решений в организациях, чтобы гарантировать взаимозаменяемость моделей решений в разных организациях.

Стандарт DMN предоставляет отрасли нотацию моделирования для решений, которые будут поддерживать управление решениями и бизнес правила. Обозначения предназначены для чтения как бизнес-пользователями, так и ИТ-пользователями. Это позволяет различным группам эффективно сотрудничать в определении модель решения:

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

Стандарт DMN можно эффективно использовать автономно, но он также дополняет BPMN и CMMN стандарты. BPMN определяет особый вид деятельности, задачу бизнес-правил, которая «обеспечивает механизм, позволяющий процессу предоставлять входные данные для механизма бизнес-правил и получать результаты вычислений, которые может предоставить механизм бизнес-правил».[2][3] который можно использовать, чтобы показать, где в процессе BPMN следует использовать решение, определенное с помощью DMN.

DMN стал стандартом бизнес-анализа в соответствии с БАБОК v3.[4][5]

Элементы стандарта

Стандарт включает три основных элемента

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

Сценарии использования

Стандарт определяет три основных варианта использования DMN.

  • Определение ручного принятия решений
  • Определение требований для автоматизированного принятия решений
  • Представление полной, выполнимой модели принятия решений

Преимущества

Использование стандарта DMN улучшит бизнес-анализ и управление бизнес-процессами, поскольку

  • другие популярные методы управления требованиями, такие как BPMN и UML не обрабатывают принятие решений
  • рост проектов с использованием систем управления бизнес-правилами или BRMS,[6] которые позволяют быстрее вносить изменения[7]
  • он способствует лучшему взаимодействию между бизнесом, ИТ и аналитиками в компании[8]
  • он обеспечивает эффективный подход к моделированию требований для Прогностическая аналитика проекты и удовлетворяет потребность в "понимании бизнеса" в методологиях расширенной аналитики, таких как CRISP-DM
  • он предоставляет стандартные обозначения для таблиц решений, наиболее распространенный стиль бизнес правила в BRMS

Связь с BPMN

DMN был разработан для работы с BPMN. Модели бизнес-процессов можно упростить, перенеся логику процесса в службы принятия решений. DMN - это отдельный домен в OMG, который предоставляет явный способ подключения к процессам в BPMN. Решения в DMN могут быть явно связаны с процессами и задачами, которые используют эти решения. Эта интеграция DMN и BPMN была тщательно изучена.[9] DMN ожидает, что логика решения будет развернута как служба принятия решений без сохранения состояния и побочных эффектов. Такую службу можно вызвать из бизнес-процесса, и данные в процессе можно сопоставить с входами и выходами службы принятия решений.[10]

Пример DMN BPMN

Как уже упоминалось, BPMN родственный OMG Стандарт для моделирования процессов. DMN дополняет BPMN, обеспечивая разделение проблем между решением и процессом. В приведенном здесь примере описывается процесс BPMN и DMN DRD (схема требований к принятию решений) для подключения клиента банка. Моделируются несколько решений, и эти решения будут определять реакцию процессов.

Новый банковский счет

В модели процесса BPMN, показанной на рисунке, клиент делает запрос на открытие нового банковского счета. Приложение для создания учетной записи предоставляет представителю учетной записи всю информацию, необходимую для создания учетной записи и предоставления запрошенных услуг. Это включает имя, адрес и различные формы идентификации. На следующих этапах рабочего процесса вызываются службы «Знай своего клиента» (KYC). В сервисах «KYC» проверяются имя и адрес; с последующей проверкой международной криминальной базы данных (Интерпол) и базы данных лиц, которые являются «политически значимыми лицами (PEP ) '. PEP - это лицо, которому доверено видное политическое положение или его близкий родственник. Депозиты лиц из списка PEP потенциально коррумпированы. В модели процесса это показано как две службы. Правила противодействия отмыванию денег (AML) требуют проведения этих проверок до того, как клиентский счет будет сертифицирован.

Рисунок: процесс принятия решений о создании нового клиента банка.

Результаты этих услуг, а также формы идентификации отправляются в решение о сертификации новой учетной записи. На схеме процесса это показано как действие «правила», проверка учетной записи. Если новый клиент проходит сертификацию, то его учетная запись классифицируется на адаптацию для Business Retail, Retail, Wealth Management и High Value Business. В противном случае заявка клиента отклоняется. Решение «Классифицировать нового клиента» классифицирует клиента. Если процесс проверки учетной записи возвращает результат «Вручную», то проверка PEP или Интерпола вернула точное совпадение. Представитель учетной записи должен визуально проверить имя и приложение, чтобы определить, действительно ли совпадение, и принять или отклонить заявку.

Подтвердите решение о новом аккаунте

Логика структуры решения и данные, связанные с проверкой учетной записи.

Учетная запись сертифицирована для открытия, если адрес человека подтвержден, и если предоставлено действительное удостоверение личности, и если заявитель не включен в список преступников или политически значимых лиц. Они показаны в виде дополнительных решений под решением «подтвердить новую учетную запись». Сервисы проверки аккаунта обеспечивают 100% совпадение адреса заявителя. Для того, чтобы идентификация была действительной, клиент должен предоставить водительские права, паспорт или удостоверение личности государственного образца.

Проверки против PEP и Интерпола являются «нечеткими» совпадениями и возвращают совпадающие значения оценок. Баллы выше 85 считаются «совпадением», а баллы от 65 до 85 требуют «ручного» отбора. Люди, соответствующие любому из этих списков, отклоняются в процессе подачи заявки на учетную запись. Если есть частичное совпадение со списком Интерпола или PEP со счетом от 65 до 85, тогда сертификация устанавливается вручную, и представитель учетной записи выполняет ручную проверку данных кандидата. Эти правила отражены на рисунке ниже, который представляет собой таблицу решений для того, передавать ли предоставленное имя для проверок списков.

Бизнес-правила для оценки результата совпадения PEP и Интерпола «Нечеткое».

Категория клиента

Процесс адаптации клиентов зависит от того, к какой категории они относятся. Категория определяется:

  • Тип клиента, бизнес или частный
  • Размер средств на депозите
  • И предполагаемая чистая стоимость

Это решение показано ниже:

Решение о категории клиентов.

Существует 6 бизнес-правил, которые определяют категорию клиента, и они показаны в таблице решений здесь:

Таблица решений DMN с бизнес-правилами для классификации клиента по категории на основе входных данных.

Сводный пример

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

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

Связь с Decision Mining и Process Mining

Также были предложены методы автоматического обнаружения, которые выводят модели принятия решений на основе данных о выполнении процесса.[11] Здесь модель решения DMN выводится из обогащенного данными Журнал событий вместе с процессом, использующим решения. При этом интеллектуальный анализ решений дополняет процесс добычи с традиционными сбор данных подходы.

Рекомендации

  1. ^ Стандарт OMG «Модель решения и обозначение (DMN)», текущая версия
  2. ^ Стандарт OMG «BPMN», текущая версия
  3. ^ Покупка, янв (5 января 2015 г.). «Рецензия на книгу: моделирование процессов и решений в BPMN / DMN». Управление принятием решений для финансового блога. Lux Magi Ltd. Получено 19 апреля 2015.
  4. ^ IIBA (15 апреля 2015 г.). Руководство к Своду знаний по бизнес-анализу® (BABOK® Guide) (3-е изд.). п. 512. ISBN  978-1927584026.
  5. ^ «Моделирование решений стало стандартом для бизнес-аналитиков».
  6. ^ Манн, Стефани. «Управление бизнес-правилами: инструменты, методы достижения успеха». ebizq.net, Руководство для инсайдеров по BPM следующего поколения. Получено 19 апреля 2015.
  7. ^ Обнаружение решений в ваших бизнес-процессах с помощью IBM Blueworks Live, Издательство IBM Redbooks, 2014 г. ISBN  0738453579
  8. ^ Ронен, Гил; Фельдман, Яков. «Модели решений с использованием стандартов dmn и bpmn: рекомендации по ипотеке». Slideshare. OpenRules.
  9. ^ F. Hasic et al. (2018). Дополнение процессов интеллектуальными решениями: принципы интегрированного моделирования. Системы поддержки принятия решений, 107, 1-12.[1]
  10. ^ F. Hasic et al. (2020). Решение как услуга (DaaS): подход с сервис-ориентированной архитектурой для принятия решений в процессах. IEEE Transactions on Services Computing[2]
  11. ^ J. De Smedt et al. (2019). Целостное обнаружение моделей решений на основе данных о выполнении процесса. Системы, основанные на знаниях, 183, 104866[3]

внешняя ссылка