Posts in the series:
- Benefits of Decision Modeling
- What is a decision model and what is DMN
- Decision Modeling: Decision Requirements
- Decision Modeling: Decision Logic
- Decision Modeling: Finding and modeling decisions [this post]
- Decision Modeling: Input Data and Knowledge Sources
- Building decision tables from decision models
- ML, AI and other forms of Data Analysis and Advanced Analytics
--
One of the most important things in decision modeling is identifying decisions. This move away from trying to capture individual rules – in a sheet or list – and toward modeling meaningful decisions is crucial to successfully applying decision modeling. It is also one of the key benefits of the approach – decisions turn out to have all sorts of advantages over rules as a management artifact. You can find decisions in several ways.
Finding decisions – top down
The most effective and game-changing way to find decisions is top down. Go talk to the SMEs who make the decision today – or who handle exceptions and supervise the decision. First ask them to name the decision you are working on - what do they call it? Ask them how they decide it – what interim or sub-decisions do they think they make on the way? How do they decide? Experience is that this moves along rapidly, with SMEs able to describe their decision, their sub-decisions and their sub-sub-decisions with only a little prompting. They can get a little too focused on sequence (see below) and can get into the weeds sometimes, but mostly this is a straightforward approach to building a first cut model.
A note. You may be told that this cannot possibly be allowed – that the business SMEs have already written down their requirements and that you must work from those documents or talk only to the business analysts who wrote them. This rarely goes well, so we insist. Business SMEs generally want the system to work well so will give you a little time. And they often really enjoy decision modeling – they learn something from the model and they find it refreshing that someone asks them “how do you decide” not "what do you need the system to do".
Finding Decisions - bottom up
You can also find decisions bottom-up. You can look at rules that are being requested or suggested and ask what decision those rules are making – why is that a rule? You can infer decisions from existing functions that make calculations or determinations. You can take an analytic model – a prediction or a classification – and describe it as a decision. And once you have identified these bottom-level decisions, you can ask “why?” – why are we deciding this? Generally, it’s to help you make another, higher-level decision. Well, what else helps you make THAT decision? You can then combine this bottom-up discussion with top-down analysis of the decisions you find to build out a model.
Questions and Allowed Answers
One of the most effective ways to describe a decision is to write a really specific question for it (the question that must be answered to make the decision). You can also think through the possible or allowed answers for the question. This combination bounds the decision. A credit check decision, for instance, might answer the question “what credit grade is assigned to this customer at this time?” and the answers might be A through F.
Every time you identify a decision, make sure you know the question and allowed answers. Specific questions and allowed answers eliminate any ambiguity in the names of your decisions. They often make it clear what kinds of rules might be needed or what sub-decisions are going to be relevant. And they allow you to talk about a decision and what it does BEFORE you know how it will do that. This allows you to defer pieces of the model until later and build models that cross domain areas.
Sub-decisions
Identifying the sub-decisions of each decision in your model is the core activity in decision modeling. As SMEs talk about a decision, they almost always break it down into steps or pieces, these are sub-decisions. If there are several ways to make a decision, those are sub-decisions too. If a decision seems to include very different rules or decision-making approaches, that’s a sign that some sub-decisions will clarify things.
For instance, our credit check decision might have a sub-decision that creates a grade from a credit report, another that creates a grade from your history with the bank, a third might use an external service based on alternative data sources and you might have a couple of decisions to check for exceptions like new arrivals in the country.
Don’t be afraid to create sub-decisions. Good models have a lot of simple decisions in them.
Dependency not sequence
A critical element in a successful decision model is that it is based on dependency not sequence. When we build an information requirement between two decisions, we are showing that decision A depends on decision B – we cannot make decision A unless we have already made decision B. It’s really important not to add requirements between decisions that are really independent of each other. It is not enough that a decision is generally, even always, made before another – even if I always make decision A and then make decision B, decision B need not depend on decision A. Only if the result of decision B changes as a consequence of decision A, only if the specific answer from decision A matters to the way I decide B, can I show a requirements link.
This often requires some focus. SMEs will generally tell you sub-decisions in a particular order, one they have designed for efficiency. Take this example:
An SME talking about how they price an insurance policy might say “first I determine the driver’s age category, then I check their driving record and training certifications. Then I determine their eligibility rating and then calculate their score”. You might capture this using a decision model like the one on the left – with the “first” decision at the bottom and later decisions dependent on each prior one. But this would be wrong, as it captures sequence not dependency and implies that each decision is only used by the “next” one – something that is clearly not true.
The real requirements model looks like the one on the right. The driver eligibility score is the final decision and to calculate it we need the eligibility rating, driving record category, and age category. To determine the driver eligibility rating we need both age category and training certifications. We do need the four sub decisions before we can determine the score, but the order in which we determine training certifications, age category and driving record doesn’t matter and we can now clearly see what the true dependencies are. This will allow us to build an effective decision table.
Requirements not availability
Sometimes SMEs will say things like “it makes no sense to do B before A” or “I would never decide B unless I had decided A” or “we always have the result of A before we decide B”. Unless they can explain how the result of decision A CHANGES their approach to decision B, there’s no requirement. Just because something is or could be available, doesn’t mean there’s a requirement.
Sometimes you’ll only spot this when you start writing rules for the decision and find that the value in a column never makes any difference – it’s the same value in every row. That means you have captured a requirement that isn’t a real requirement. If there’s a true dependency, there will be some difference.
Similarly, when you first ask SMEs what information they need to have available to make a decision – input data, the topic of my next blog post – they will often give you a long list of data elements that will be useful. Once you build the model, you may well find that some of that data doesn’t seem to make a different to the decision-making. This is common – almost all SMEs find that the decision model refines their sense of what data is needed. Keep checking that all the requirements in your model are truly required.
Experience is that is REALLY worth being a hard ass about this. Don’t add requirements that aren’t there!
Networks not trees
One final note about reuse. When you start building a decision model, it often feels like a tree – a top level decision has some sub-decisions, and those sub-decisions have further sub-decisions and so on. Remember, though, that a decision model is a network not a tree: a decision can be a sub-decision of several decisions. You might find, for instance, lots of decisions that depend on a customer’s credit rating or how you categorize a transaction.
Never create duplicates in a decision model – there is only ever one decision or one input data with the same name, content and meaning. Every object in DMN can be reused in multiple hierarchies and on multiple diagrams. Obviously, you can’t contradict yourself – you can’t sometimes say decision A depends on decision B and C other times day on decision C and D – and you can’t build a cyclic dependency – an infinite loop of requirements. But you can and should reuse things.
In the next post, I’ll talk about how to find and link Input Data and Knowledge Sources into your decision requirements.
If you want more detail, you can get a text book on the approach (written by me and Jan Purchase): Real-World Decision Modeling with DMN 2nd Edition. If you or your company need help with decision modeling, drop me a line james@decisionmanagementsolutions.com and we can schedule a quick call to discuss. And if you’re excited about decision modeling and keen to do more, why not join DecisionAutomation.Org and participate?
#IBMChampion