ABPMP January 2016 webinar Denis Gagne

Dan has served as the US Practice Director for BPM/SOA consulting at Capco, as the
US Practice Director for Business Transformation for Insurance, Healthcare and Life
Sciences at Infosys Technology, as an Executive Consultant for IBM, and as a CIO. He
is the author of three books on Business Transformation and over 50 papers and
articles. Dan is also the author of the PEX column BPM Straight Up: Separating Fact
from Fiction and a co-author of the ABPMP CBOK, Check out the ABPMP BPM
CBOK.
Dan Morris, CBPP, CBA Managing Principal Wendan Consulting
Executive leaders, practitioners, authors
Dan has over 25 years of experience in business and IT operation transformation and management. He is currently serving as a
Managing Principal for Wendan, Inc. Wendan is a BPMS methodology and consulting firm offering the ADDI (Architect, Design,
Deploy, Improve) BPMS methodology.
Denis Gagne, CBPMP, OCEB Business and Technical Advanced
CEO & CTO Trisotech
Photo
For over a decade Denis Gagné has been a driving force in the majority of international BPM standards in use today. He is
a member of the Workflow Management Coalition (WfMC) Steering Committee, chair of the Business Process Simulation
Working Group (BPSWG), and the co-Editor of the XPDL 2.2 process definition standard. For the Object Management
group (OMG), Denis is the Chair of the BPMN Interchange Working Group (BPMN MIWG), a member of the Business
Process Model and Notation (BPMN), the Case Management Model and Notation (CMMN), and the Decisions Model and
Notation (DMN) team. M. Gagné is the driving force behind www.BusinessProcessIncubator.com, a free online resource
providing access to BPM, Change Management, Process Improvement, Lean and Six Sigma resources.
Trisotech is a global leader in digital enterprise solutions, offering innovative and easy-to-use software tools that allow
customers to discover, model, analyze and find insights into their digital enterprise.

The looming rules crisis
• Business and technical rules – what are they and where do you find them?
• Why are they important?
• Who should be responsible for finding them?
• Aligning rules to business model activity
• Identifying rules
• Rule definition
• The rules crisis
• What we need to consider doing about it

An introduction to DMN
Business Decision Management
Where strategies come to life!
Business Decisions Management:
An introduction to the Decision Model and Notation (DMN)
Denis Gagné,
CEO & CTO
DMN 1.1 and 2.1 Member at OMG
Chair BPMN MIWG at OMG
BPMN 2.1 Member at OMG
CMMN 1.1 Member at OMG
Chair BPSWG at WfMC
XPDL Co-Editor at WfMC

Simpler
Agile
Smarter
Processes

The evolution of business applications
“Giving back control to business”
Data
Process
Rule
Business
Application
Process
Rule
Business
Application
Data
Process
Rule
Business
Application
Data
Process
Business
Application
Data
Rule
Legacy Modern

Informed decision-making comes
from a long tradition of guessing and
then blaming others for inadequate
results.
Scott Adams

• Strategic Decisions
• Tactical Decisions
• Operational Decisions

Decision
Management Agility
Accuracy
Consistency

Decision
Discovery
Decision
Services
Decision
Analysis
Identify decision
requirements and
model decision logic
that are important to
your organization
Deploy decision
services based on
unambiguously
specified decision
models
Continuously improve
decisions by managing
and monitoring
business decisions
Decision Management

Decision Modeling
What question do we want to answer?
• Possible answers
What is required to make the decision?
• Information
• Reference data
• Transaction data
• Knowledge
• Policies
• Regulations
• Guidelines
• Other decisions

DMN What is DMN
www.DMNWebModeler.com
• What is DMN?
• Decision Model and Notation
• DMN is a standard published by the Object Management Group (OMG).
• Why DMN matters?
• A common meta-model and notation for describing and modeling
repeatable Business Decisions
• Enables various groups to effectively collaborate in defining a Decision
Model
• Provides a standard notation for Decision Tables
• Current Status
• DMN 1.0 released Sep 2015
• DMN 1.1 to be released Q1 2016

DMN Decision Model and Notation
The purpose of DMN is to provide the constructs that are
needed to model decisions, so that organizational decision
making can be readily depicted in diagrams, accurately defined
by business analysts, and (optionally) automated.

DMN Uses of DMN
• Modeling human decision making
• Modeling requirements for automated decision making
• Automating decision making

DMN Who benefits from DMN
• Business people managing and monitoring business decisions
• Business Analysts designing decision models
• Developers automating decision making

Variable Every work effort instance looks
slightly different
Unpredictable The exact course of action is
unknown and highly situation
specific
Emergent The exact course of action only
emerges during process execution
when more information becomes
available
DMN
DMN Complements BPMN & CMMN

Decision details
DMN
is a about Deciding
Defines tasks
within business
processes where
decision-making is
required to occur.
Business
Process
Model
Defines the
decisions to be
made in those
tasks, their
interrelationships,
and their
requirements for
decision logic.
Decision
Requirements
Diagram
Defines the
required decisions
in sufficient detail
to allow validation
and/or
automation.
Decision
Logic
DMN Core concepts
is a about Processing

DMN
Decision Requirements
Diagram
DMN Core Concepts
DMN
Business Process Model
Decision Logic (Decision Table)

Decision as
Business
Rule Task
Business
Process
Model
DMN Deciding as an activity
Decision

Business
Concepts
Inputs
Knowledge
Sources
Decision
Requirements
Diagram
DMN Decision Requirements Diagram
DMN
Decision
Input Input Knowledge
Source
Knowledge
Source
Business
Knowledge
Model

Defines the
decisions to be
made in those
tasks, their
interrelationships,
and their
requirements for
decision logic.
Decision
Requirements
Diagram
DMN
• A network of Decisions, Inputs, Knowledge
Sources, and Business Knowledge Models
• Depicts Information Requirements, Knowledge
Requirements and Authority Requirements for
Decisions
• May be composed of Human Decisions and/or
External Decisions

Defines the
decisions to be
made in those
tasks, their
interrelationships,
and their
requirements for
decision logic.
Decision
Requirements
Diagram
DMN

Defines the
required decisions
in sufficient detail
to allow validation
and/or
automation.
Decision
Logic
DMN Decision Logic
DMN
• At the decision logic level, every decision is
defined using a value expression which specifies
how the decision’s output is determined from its
inputs
• At that level, the decision is considered to be
the evaluation of the expression
• The value expression may be notated using a
boxed expression

DMN Boxed Expression
In DMN, the decision logic is represented as
Boxed Expressions
A Boxed Expression is either:
• a Decision Table
• a Boxed Expression (FEEL)
• a Boxed Invocation
• a Boxed Context
• a Boxed List
• a Boxed Function
• a Relation

Input set
Business
Rules
Calculations
Output set
Decision
Logic
DMN Decision Logic – Decision Table
DMN
Input
set
Output
set
Individual
Rule
Hit
Policy

Input set
Business
Rules
Calculations
Output set
Decision
Logic
DMN Decision Logic – Decision Table
DMN
• Rows : Rules (other orientations possible)
• Input column: variable with allowable values
• Output column : variable with allowable values
• Cells : expression or hyphen (- irrelevant to the rule)
• Hit policy: determines what to do with rules that
matches

DMN Example

DMN Expression Language
• The expressions in the Boxed Expressions are FEEL expressions
• FEEL stands for Friendly Enough Expression Language
• FEEL has the following features:
• Side-effect free
• Simple data model with numbers, dates, strings, lists, and contexts
• Simple syntax designed for a wide audience
• Three-valued logic (true, false, null) based on SQL and PMML
• A simple subset of FEEL, S-FEEL, is for where the decision logic is
modeled mostly or only using decision tables

DMN Expression Language (Common usage)
Legend
Expression Description
Operation
+ Addition
- Subtraction
/ Division
* Multiplication
Comparison
> Greater than
>= Greater or equals to
< Smaller than
<= Smaller or equals to
[number1..number2] Close interval, between number1 and number2 inclusive (ex.: [10..20] means >=10 and <=20)
(number1..number2) Open interval, between number1 and number2 exclusive (ex.: (10..20) means >10 and <20)
[number1..number2) Interval, >=number1 and <number2
(number1..number2] Interval, >number1 and <=number2
Not(value) Works on all types, for example not(STUDENT) will be true if the input is anything but STUDENT.

DMN Hit Policies
• The hit policy specifies what the result of the decision table is
when more than one rule matches the input data.
• The hit policy is summarized using a single character
• The character is the initial letter of the defined hit policy
(Unique, Any, Priority, First, Collect, Output order or Rule order)
• The default value is Unique
• Decision Tables with Unique hit policy SHALL NOT contain
overlapping rules

DMN Single and Multiple Hit Tables
• A single hit Decision Table shall return the output of one
rule only
• A multiple hit Decision Table may return the output of
multiple rules (or a function of the outputs, e.g. sum of
values).

DMN Single Hit Policies
• Unique: no overlap is possible and all rules are disjoint. Only a single rule can be matched. This
is the default.
• Any: there may be overlap, but all of the matching rules show equal output entries for each
output, so any match can be used. If the output entries are non-equal, the hit policy is incorrect
and the result is undefined.
• Priority: multiple rules can match, with different output entries. This policy returns the matching
rule with the highest output priority. Output priorities are specified in the ordered list of output
values, in decreasing order of priority. Note that priorities are independent from rule sequence.
• First: multiple (overlapping) rules can match, with different output entries. The first hit by rule
order is returned (and evaluation can halt).
First hit tables are not considered good practice because they do not offer a clear overview of the decision logic. It is
important to distinguish this type of table from others because the meaning depends on the order of the rules. The last rule
is often the catch-remainder. Because of this order, the table is hard to validate manually and therefore has to be used with
care.

DMN Multiple Hit Policies
• Output order: returns all hits in decreasing output priority order. Output priorities are specified
in the ordered list of output values in decreasing order of priority
• Rule order: returns all hits in rule order. Note: the meaning may depend on the sequence of the
rules
• Collect: returns all hits in arbitrary order. An operator (‘+’, ‘<’, ‘>’, ‘#’) can be added to apply a
simple function to the outputs. If no operator is present, the result is the list of all the output
entries
Collect operators are:
• + (sum): the result of the decision table is the sum of all the distinct outputs
• < (min): the result of the decision table is the smallest value of all the outputs
• > (max): the result of the decision table is the largest value of all the outputs
• # (count): the result of the decision table is the number of distinct outputs

DMN DMN Diagrammatic Elements
Business
Knowledge
Model
Knowledge
Source
Decision
Input
Information Requirement Knowledge Requirement Authority Requirement
Elements
Requirements
Annotation
Association
Artefacts

DMN DMN Elements
Decision
Input
The act of determining a set of
outputs from a number of inputs
Information used as input

DMN DMN Elements
A function encapsulating
business knowledge
Authority for business knowledge
or decision
Business
Knowledge
Model
Knowledge
Source

DMN DMN Requirements
Uses as input Invokes
Information Requirement Knowledge Requirement Authority Requirement
Depends on

DMN DMN Artefacts
A text used for comment or
explanation.
Used to link a Text
Annotation to an Element
Annotation
Association

DMN DMN allowed connections
Decision uses Input
as input
Input as information
requirement to the
Decision
Decision uses Decision 2
as input
Decision 2 as information
requirement to the
Decision
Information Requirement

Decision invokes Business
Knowledge Model
Business Knowledge Model
as knowledge requirement to
the Decision
Decision Knowledge Model
invokes Decision Model 2
Business Knowledge Model 2
as knowledge requirement to
the Business Knowledge
Model
Knowledge Requirement

Decision depends on
Knowledge Source
Knowledge Source as
an authority
requirement to the
Decision
Input depends on
Knowledge Source
Knowledge Source as
an authority
requirement to the
Input
Authority Requirement

depends on Knowledge
Source
Knowledge Source as an
authority requirement to the
Authority Requirement
Knowledge Source depends
on Knowledge Source 2
Knowledge Source 2 as an
authority requirement to the
Knowledge Source

Thank You
Questions and Columns
For a copy of the slides and recent PEX columns please contact
Denis Gagne at:
dgagne@trisotech.com
514-990-6639 Ext. 444
Dan Morris at:
daniel.morris@wendan-consulting.com
630-290-4858

ABPMP January 2016 webinar Denis Gagne

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (7)

Plus de Denis Gagné

Plus de Denis Gagné (20)

Dernier

Dernier (20)

ABPMP January 2016 webinar Denis Gagne