Modeling Decisions and Processes with DMN

*
Jan Vanthienen
KU Leuven
Faculty of Economics and Business
Business Information Systems Group
Research and teaching:
• Business Analysis
• Information & Knowledge Management
• Business intelligence & Analytics
• Decision models & tables
• As a business analyst, you identify business needs and determine solutions to
business problems. To this end, you model and improve processes and manage
organizational change from a holistic view of the situation.
• One of the most important things for business is not just data and processes, but
improving and automating decision making. We often spend a lot of effort on
modeling business processes, but forget about important elements in the process:
the decisions.
• Decision management has a new standard, DMN. This may look trivial, but DMN
fully fits the business analysis mission to describe decisions and decision logic
from a business point of view, with a straightforward road to implementation.
• Modeling decisions and processes raises an interesting challenge: how to combine
both approaches and which comes first? That is what this session is about.

Prof. dr. Jan Vanthienen
jan.vanthienen@kuleuven.be
KU Leuven (Belgium)
Leuven Institute for Research in Information Systems
*

*
LIRIS (Leuven
Institute for
Research in
Information
Systems)
Decision & Process Modeling
Jan Vanthienen
KU Leuven
Faculty of Economics and Business
Business Information Systems Group
Research and teaching:
• Business Analysis
• Information & Knowledge Management
• Business intelligence & Analytics
• Decision models & tables
IBM Faculty Award
Belgian Francqui Chair 2009 at FUNDP
- Bpost bank Research Chair Actionable Analytics
- Colruyt-Symeta Research Chair Smart Data and Decisions in Marketing
- IBM Fund Intelligent Business Decision Making
- Microsoft Research Chair on Intelligent Environments
- PricewaterhouseCoopersChair on E-Business
Email: jan.vanthienen@kuleuven.be
(c) Jan Vanthienen, 2019 3

*
*Modeling Small and Large Data
*Large Volumes of data
* Many objects (e.g.: Customers, Products, …).
* Many features (e.g.: Age, Income, …).
*Velocity: data streams
* Phone calls, Bank transactions,
Web site visits, …
*Variety: different types of “data”
* numbers, text, speech, video, audio,
scanned documents, photos,
social media updates, sensor data, …
*Veracity:
* messy, untrustworthy data
Decision & Process Modeling(c) Jan Vanthienen, 2019 4

*

Why would we only care about the (big) data or the processes?
Decisions are important for business.
Where is the decision?
How do we model the decision?
• Correct
• Complete
• Consistent
• Comprehensible
• Compliant
• Modular
• Traceable
Who makes the decision?
Can we improve the decision?
Can we automate the decision?
*
?
Decide acceptance?

*
The evolution of computing
Calculation
Data processing
Communication
Decision making
•Big Data
•Analytics
•Knowledge-based AI

*
*Made Frequently
*Non-trivial
*Made Rapidly
*Made Consistently, Repeatable
*High volume
*Measurable business impact
*Deterministic
*Frequent change (but compliant)
*Comprehensibility, Explainability
*Automated or manual

*
Mileage accrual
Customer Type
Traveller
data

*
(Source: Decision Management Solutions)
 Separating (decision) rules
from the process
simplifies the process
 Improved agility, reuse,
focus, visibility
 Simplify nested decision paths:
Model the decision separately
Decision depends on:
o data
o decision logic
o intermediate decisions

*
Layered decisions
DMN
Decision tables

*
•Law
•Procedure
Text
• Specification
• Pseudocode
Schema
•Code
•Execution
System
Domain
expert
IT
* Hard to define
* Not standard
* Not executable
* Hard to maintain
 Manual work
 Expensive to maintain
 Low traceability

*
*Decision model & notation, knowledge representation
*Flexible execution
•Law
•ProcedureText Decision
logicModel Executable
knowledgeResult
 Comprehensible
 Xplainable
 Made Consistently
 Executable
 Automated
 Flexible
 Generic

1. Decisions requirements 2. Decision logic
*
Applicant Risk Rating
U
Applicant Age Medical History Applicant Risk Rating
1
> 60
good Medium
2 bad High
3 [25..60] - Medium
4
< 25
good Low
5 bad Medium

Decision(s) (logic) need to be modeled
* A standard for processes (BPMN)
is not enough
* What is the decision?
* Eligibility, rating, retention, offer,
selection, hire, credit, …
* What is required to make this decision?
* Information
* Knowledge sources
(regulations, analytics, expertise)
* Other decisions
* Decision logic
Decision Modeling & Notation standard (DMN)
*

*
Informaton requirement
Knowledge requirement
Authority requirement

*
*If CustomerType = US and OrderType = Web then Discount = 8%
*If CustomerType = US and OrderType = Phone then Discount = 5%
*If CustomerType = non US then Discount = 0%
* Inputs in one rule are always ANDed. No ORs, no parentheses
* Every row is a rule
* The order of the inputs is the same for every rule
* “-” means: does not matter in this rule (irrelevant)
Inputs Outputs
Information items
"rules"
(rows)
values

End of year premiums (simplified real case, French company)
1. Anciennity premium
If the employee has an anciennity of at least 3 years and (s)he was absent for
less than 4 weeks during the year, (s)he will get an anciennity premium.
2. Presence premium
If the employee has an anciennity of at least 1 year and (s)he was absent for
less than 2 weeks during the year, (s)he will get a presence premium.
3. Productivity premium
If the employee has an anciennity of at least 3 years, (s)he is entitled to a
productivity premium, but the premium is only awarded if:
- (s)he was absent for less than 2 weeks during the year
- or (s)he was absent for less than 4 weeks during the year and his/her
appreciation score was excellent.
Premiums can be combined.
*DIY: Build your own table

*
*E.g. If CustomerType = US and OrderType = Phone then Discount = ?
Various solutions:
* Take the first rule that applies (from top to bottom) and stop (8%) FIRST
* Make sure the rules do not overlap UNIQUE
* Allow rules to overlap, but only if the output is the same ANY
* Take the output with the highest priority, listed in decreasing order (5%) PRIORITY
* Collect (and add) the output of every rule that applies (13%) COLLECT
-> We need a standard

*
*Decision tables (DT)
* Decision rules in a tabular format
*Decision table methodology (DTM)
* How to use a constrained form of decision tables in order to model decisions
* Goal-oriented decision modeling network
* Good decision table design
* Single hit tables (complete, consistent and correct), relations between
tables, table notation, contraction, optimization, normalization.
*Decision Modeling & Notation (DMN) standard
* Standard syntax and notation for exchange
* Recognize other forms of tables
* Combine tables with other concepts in decision modeling
* Standard expression language FEEL

Good decision table models are a proven technique to represent decision rules
Consistency,
completeness
and correctness by design
*

*
DMN identifies different table types, indicated by the first letter:
Single hit (returns one rule):
*If only one rule can match every case: (U)nique hit indicator
*If more then one rule can match a certain case: Choose only one
The Hit Indicator tells which one:
- A(ny), P(riority of outcome)
- F(irst)
Multiple hit:
*If all applicable rules are required:
* results in an output collection (list, or operation on list)
* List order is No order (arbitrary), Rule order, Output order
* An operation may be applied, e.g. C+
Good
Ugly
Bad

*
*Some of this is methodology
*But if you can choose 2 out of 3, what do you choose?
Compact Consistent
Correct

• Decisions, decisions, decisions
• Decisions in process modeling
• Process variability
• ’Simple’ operational decisions
• Eligibility, credit, churn, social security, finance,
insurance, healthcare, security, definitions, …
• Regulations, legislation
• Enumerating and evaluating alternatives, constraints,
options
• Combinatorial optimizations
• Scheduling and resource allocation
*Application areas & Tools

*It is not a rebirth of rule-based systems
*It belongs at the business side, not the IT side. It is part of BA
*Emphasis on structuring, verification, model quality, …
*It is a model (& notation) standard
*No lock-in, but compatibility (TCK)
*Straightforward execution is common. More sophisticated
execution (inferences) is possible but the standard ≠ the tools
(-> research area)
*It is not the ultimate full-blown knowledge representation
*Complexity has its price
*Already so much better than not modeling decision (logic)
*

*
Issues DMN solves
How to connect decisions and processes

*
*What is the decision?
* eligibility, price, insurance, theft rating, customer offer,
retention, supplier selection, hire, credit, …
*Who, what, how?
*Who owns the decision?
*Who makes the decision every day?
*Who is impacted?
*What triggers the decision?
*When are we making this decision?
*What is required to make this decision?
* Information requirements
* Knowledge sources (regulations, analytics, expertise)
* Other decisions
* Decision logic

*Separating decisions and processes
* Using a standard modeling notation.
*Decision table types
* Recognize, and unambiguously exchange.
*Decision modeling methodology
* Keep the insights of the past and avoid confusion.
*Separating decision structure and decision logic
* Allows to model decision relations, even if not all logic is expressed in tables.
*Standard notation for exchange and implementation
* Strict notation and simple expression language.
*

*
*Separating decision structure and decision logic
*Allows to model decision relations, even if not all logic is
expressed in tables.

*
*Decision modeling methodology
*Keep the insights of the past and avoid confusion.
*Good decision table models are a proven technique to represent decision rules
Consistency, completeness and
correctness by design column 4 subsumes column 1• Exclusivity
• Completeness

*
*Standard notation for exchange and implementation
*Strict notation and simple expression language ((S-)FEEL).
*FEEL (“Friendly Enough Expression Language) implements
the required mechanisms
* Built-in types, functions and operators
* Every decision in a DRD can be defined using a formal expression that
specifies how the decision’s output is determined from its inputs
* Complete decision models can be defined
* Formal expressions may also be encapsulated as functions
*S-FEEL (“Simple FEEL”) is a basic subset of FEEL designed to cover
the essential requirements of Decision Table-based DMN models
*DMN tools

*
*Separating decisions and processes
*Using a standard modeling notation. refuse high
riskapplicant
accept low risk
applicant
GoodMedicalRecord
Age<20
21<=Age<50
Age>=50
BadMedicalRecord
accept
medium risk
applicant

*
Process-decision consistency
Which comes first?

Decision models are not
lower level details of one process
* Decisions models
can span
over multiple activities,
and even multiple processes
* Separation of concerns
* Sometimes the process is about
one large decision
Model of the decision(s)
*

*

Decision & Process Modeling
*Decision outcomes and gateways
*Order of decisions
*Available inputs
(c) Jan Vanthienen, 2019 37
*Repeat all decisions in process?
Hasić, F., De Smedt, J., Vanthienen, J.: Redesigning Processes for Decision-Awareness:
Strategies for Integrated Modelling. QUATIC 2018: 247-250.

*
*How to integrate processes and decisions?
*How to redesign a process to split off decisions?
*Where to start?
*From an existing process?
*From a decision?

*
*This approach views decisions as local concerns (details)
with respect to decision points in the process model
(decision activity before an XOR-split).
But:
* decisions do not only happen at XOR-splits (decision logic
≠ routing logic). Decisions can impact other things.
*The holistic business decision is lost and fragmented.
*Redesigning the process takes out relevant input data and
all possible decision outcomes for one decision at the time.

*
*This approach tries to identify decision constructs from the
existing process model and externalizes the decision constructs
into a separate decision model.
*It uses mappings and transformation rules from process
constructs to decision constructs.
*This impacts and simplifies the process model.
*But: The extracted decision model is strongly dependent on how
the process was modelled (decisions can be in gateways,
activities or data).

*
*The decision-centric approach starts with the
decision (model).
*The process model is constructed afterwards
in such a way that it is automatically consistent
with the decision model.
*The process model needs to provide the
relevant data for the decision model and needs
to take care of data storage, and data and
decision outcome propagation within the
process.

*Sometimes the entire process is about a decision
*Model the decision first,
and then think about how to execute it
*The same decision
can be processed in many ways
*The process of making a decision
depends on the desired criteria
(throughput, efficiency, data collection,
customer comfort, …)
*

*
Start each individual decision activity as
soon as all its preconditions are fulfilled
Avoid superfluous decision activities
(unnecessary work)
Group customer contacts
naturalization

*

*
*DMN models the logic of a decision, but allows to answer different decision questions.
*The basic decision/process:
* John Doe is 50 and has 30 years of service, process John’s case
* The customer puts in an claim/order/loan request.
* Do we accept the order? What is the price? How to process the order, etc.
*There is more than this basic decision
• What-If, Optimization and Incomplete data
• Why do I get this result?
• What can I already decide with these incomplete data?
• Goal seeking: What do I have to change to obtain that result?
• Optimization: How do I get the maximum?
• Overview: Who finally gets this result? Where is my case?
• Decision Analysis: Are there some strange assignments in giving this result?
• Decision Maintenance: What if the policy changes?
• Traceability: How easy is it to trace back to the original text (rules)?
What is really the question?
Different inferences of the
same decision logic

*
* Hasić, F., De Smedt, J., Vanthienen, J.: Augmenting processes with decision intelligence: Principles for integrated
modelling, Decision Support Systems 107 (2018) 1 – 12.
* Hasić, F., De Smedt, J., Vanthienen, J.: Redesigning Processes for Decision-Awareness: Strategies for Integrated
Modelling. QUATIC 2018: 247-250.
* De Smedt, J., Hasić, F., vanden Broucke, S.K., Vanthienen, J.: Towards a holistic discovery of decisions in process-
aware information systems, International Conference on Business Process Management, Springer (2017).
* Batoulis, K., Haarmann, S., Weske, M.: Various notions of soundness for decision-aware business processes. In:
International Conference on Conceptual Modeling, Springer (2017) 403–418.
* Janssens, L., Bazhenova, E., De Smedt, J., Vanthienen, J., Denecker, M.: Consistent Integration of Decision (DMN)
and Process (BPMN) Models, CAiSE forum (2016).
* De Smedt, J., vanden Broucke, S., Obregon, J., Kim, A., Jung, J., Vanthienen, J.: Decision Mining in a Broader
Context: An Overview of the Current Landscape and Future Directions, BPM Workshop DeMiMoP (2016).
* Vanthienen, J., Caron, F.: Modeling business decisions and processes – which comes first?, Proceedings of the
International Conference on Knowledge Discovery and Information Retrieval and the International Conference on
Knowledge Management and Information Sharing (2014), pp. 451 - 456.
Research topics: Decision & Process Modeling, Mining and Analytics
http://feb.kuleuven.be/drc/LIRIS/misc/JVResearch

Modeling Decisions and Processes with DMN

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Modeling Decisions and Processes with DMN

Similar to Modeling Decisions and Processes with DMN (20)

More from BA and Beyond

More from BA and Beyond (20)

Recently uploaded

Recently uploaded (20)

Modeling Decisions and Processes with DMN