So, this week we are resuming where we left off at the end of the last post, dealing with tables and broader frameworks for capturing how decisions are made. This is essentially the final step of documenting what you have learnt through analysing the logic behind how a decision is made (and /or the decision-making step in a process, depending on where you are coming from).
We’ll skip straight into it I think.
What exactly is a decision table?
A decision table is a matrix that represents what the decision should be in a given scenario based on specific criteria. They are a way of distilling a large number of business rules down into visual and easier-to-understand guidance on what decision should be made for a decision-making step.
When do you use a decision table?
You use a decision table when there are more than a few business rules which guide the decision-maker in what decision should be made, and sorting through the list of rules starts to get confusing.
Why would you use a decision table?
Decision tables are consolidated and visual ways of representing multiple business rules. Decision tables are a useful replacement for the following two other approaches.
In a complicated decision-making step where there are lots of possible answers, framing the decision logic through business rule statements only may result in looooong lists of business rules which make it very difficult to sort through all the logic and know what the actual decision (answer) should be. Decision tables have the potential to make decision-making steps far more intuitive and efficient.
In a procedure where there are multiple decision-making steps, framing all the decision logic through decisions (in a flow chart, they are often represented as diamonds) which then split off the procedure into separate pathways for each answer, can make a complicated and awful looking flow chart. If you look at the image on this earlier post (http://superiorbusinessanalysis.com/2014/02/10/charting-the-flow/), this should hopefully make a bit more sense!
How do you develop a decision table?
Gosh it took a while to get here, didn’t it? This was supposed to be the crux of last week’s post, but it sure didn’t work out that way. We’ll continue on with last week’s example of trying to answer the question: ‘How many of a certain type of fruit chew should be ordered?’
After exploring the considerations, options and exceptions we had got to the point of framing the business rules and now need to translate them in a decision table. As I mentioned in my last post, documenting the business rules ad nauseum for the purpose of developing a decision table is really overkill as we are more interested in the considerations. However, through documenting business rules should give you a very clear picture of what needs to go in the decision table.
So, first off we can eliminate any exceptions from needing to be shown in the decision table. In our example, we know that rainbow chews do not follow the same rules as the other fruit chew types, and that where a certain type of fruit chew is being promoted, additional fruit chews will need to be ordered. Therefore, we keep these exceptions in business rule form and do not try to meld them awkwardly into the decision table.
Next, we go back to the considerations.
In our example, we know that the considerations and the associated options are as follows:
Is this type of fruit chew usually in stock? – Yes / No
Has this type of fruit check ever been stocked before? – Yes in last 10 years / Yes in last 2 years / Yes in last 6 months / No
Therefore, we use the considerations down the left column/s of our decision table, as shown below, and the possible options in the next column, and then finally add in what the answer would be.
And there we go – as easy as that! There is your decision table.
Of course, it is not always as easy as that. The more considerations there are, the harder it is to fit all the decision logic into the one table. At a certain level of complexity where there are many considerations, there will be a need to develop a broader decision-making framework where multiple decision tables are used to represent the full breakdown of decision logic.And there we go – easy as that! There is your decision table.
But to expand this decision table to cater for another simple consideration is not too hard at all. Imagine that another consideration is ‘Customer Inquiry’, where you either have or have not received 2 or more customer inquiries after a certain flavour of fruit chew in the previous month. We simply split up the right hand columns to take account for the additional consideration.
If you have another consideration which fits neatly into the two considerations we’ve captured already, then you may be able to grow the table a bit more. However it becomes an issue when a further consideration is required that does not neatly fit within an existing consideration. Then you really need to start looking into breaking the decision down into other sub-decisions and creating some other decision tables.
How does a decision table fit into the big picture?
As we saw earlier, decision tables are used to make a decision-making step in a procedure easier. Therefore, in the same way that templates are supporting instruments that make a production step in a procedure easier, and in a same way that forms are supporting instruments that make an information-gathering step in a procedure easier, decision tables are supporting instruments to the procedure too.
When someone is following a procedure and they come to a decision-making step, the procedure should refer them to a decision table or – if it is more complex than can be represented in a single decision table – a broader decision-making framework.
What could a broader decision-making framework look like?
It could be a representation of how multiple decision tables logically link between each other to come to a final conclusion. These could be in the form of high-level or detailed Q-Charts that Ross and Lam also explore. (Their primer which is available at http://www.brsolutions.com/b_ipspeakprimers_toc1.php gives a lot of useful information on how you might develop this and I’d better say that their primer and their decision modelling course are the key references for this post.) Or some other decision-support tool, whether that be an actual decision support system or a decision tree or some other amazing decision logic presentation tool that I have never seen.
Well, that’s it for today folks. I hope that’s helped make a bit more sense to you of what decision analysis and tables are all about – sitting down and thinking it through like this has certainly helped me!
But before I go, what do you think?
What do you think about using decision tables to support your day to day business? And do you have any examples of other decision-making framework tools?