50 Ways to Boost Your Business and Decision Analysis

Jan Vanthienen of the University of Leuven presented on business and decision analysis. We visualize the business using process, data and rules models he says to visualize it, to automate it and to eliminate confusion and ambiguity. But there are concerns about just modeling processes. In particular if one tries to model the whole of one’s business in a process model then there is too much complexity, too many gateways and branches. So:

1. Why only model processes? Why not identify the decision in the process and then model the decisions too? Especially the day to day, repeatable, operational decisions that drive operational processes.
2. Decision trees, decision logic, should not be coded into a process model. We should simplify the process by externalizing this logic, these decision rules, from the process (in a decision model). Separate the decision rules from the process
3. Decision models are not just a lower level of the process model, they can span across multiple processes and activities. Separation of concerns is key.
4. Model decisions. And now you can use the Decision Model and Notation standard to do this – and see our white paper on decision modeling with DMN to learn more.
5. Apply proven techniques like decision tables and decision dependency networks, which have existed for a while, now standardized by DMN.
6. Decisions are often more important than the process – it does not matter how we pay the claim as much as it matters which claims we pay! Once the decision is modeled separately we can consider how to execute it in the context of our process but we need to understand the decision first.
7. Not all business rules are in a decision model – some relate to data or processes or are constraints. But decision rules should be in a decision model.
8. Separate decisions and processes can enable event-based processes, dynamic processes and goal-based processes. Removing the decisions makes it possible to build smarter processes.

Decision Models and Process Models do not have a 1:1 relationship, many processes and many decisions can be related. Decision Models can also be divided into two layers – a requirements level to show the structure and a logic level to show the specific business rules (as tables). Separating out your solution into a process model, a decision requirements model and decision logic model leads to:

• Simpler processes that are easier to manage and change
• Decision models express decision complexity more simply than process models
• Different people can manage the decision-making and the process flow
• It increases agility because it allows the process to change without a decision change and the decision to change without a process change.
• It allows reuse of decision-making
• It improves visibility

Jan explained the basics of a decision requirements model (see this post for my thoughts) and introduced decision tables as a friendly, business-focused way to represent the business decision logic this model requires unambiguously. Decision tables are an old and well-established technique (See for instance the CODASYL report from 1982…) but experience, user interface and other technical improvements have made them increasingly mainstream. The basic premise is that a tabular layout of the logic in a decision (or in part of a decision) is far easier to understand, verify and execute than any textual description of the decision. Even quite simple problems can be hard to describe in natural language.

Jan points out that there is a difference between the notation standard (DMN) and the methodology used to build good ones (such as the one I summarize in our white paper for instance). The notation may be new but the basic mechanics and methodology are well known. Even the standards effort has been going for several years. In the last few years the number of vendors supporting decision tables has exploded and soon he says (and I agree) the number supporting decision modeling will likewise expand.

Jan talked about some of the issues in decision table modeling:

• You can build the model first or the table(s) first
• Tables can return one or many values (single hit or multiple hit)
• In single hit tables, the rules might be unique so that only one is true or several might be true and we have to choose between them
• Jan likes to divide decision tables into good (unique and complete), bad  (priority and first tables) and ugly (any hit tables with overlapping rules but consistent answers). The critical distinction is the ability of the business to understand and manage these tables. He used some compelling but simple examples to show how a unique table is much easier to work with compared with a first hit, sequential table as well as allowing more analysis of the behavior encoded.
• DMN of course allows decision tables to be shown with rules as rows, rules as columns, cross-tab tables and those compressed to simple True/False cells. In theory you can pick the style that works best though in practice most companies pick one and stick to it.

Good tables he concludes have good structure, completeness, exclusivity, readability and correctness. They are normalized (factored) and focused on a specific, defined decision-making problem. And they are, of course, written in a standard way using DMN. So

1. Make it correct and make sure the business can own it
2. Make it execute efficiently

DMN applies good decision table principles, recognizes the variation in tables and lets you properly separate process and decision concerns. So use DMN (and if you want to get started, try our free decision modeling software DecisionsFirst Modeler).