Avoid the Decision Model Pitfalls. The decision models create the balance between data and decision-making so make sure you get it right.
There are many different techniques to model a decision, yes it depends on the audience and purpose of the model. A decision can be modeled using code (Python, Java etc.) or diagram (no-code) techniques. It may use order-based or tree-based approach to model a decision.
However, when it comes to business decisions, these criteria are clearer. A model for a business decision is about a specific function of a business. Therefore, the audience is business folks who probably do not have the programming skills or knowledge. Therefore, a technical code-based model is not going to be the best choice. Even then, an order-based approach such as flow or flat tree is going to neglect important details of business decisions, which is critical knowledge to organizations for reengineering and rethinking business decisions.
To that extent, we should also avoid many terms that are commonly used when it comes to business decisions. For example, “Decision-making process” is a confusing and misleading term at best. It makes people think about decision-making as a process, encouraging them to use process modeling to represent a decision-making scenario, i.e., a business decision.
We have often established that decisions are different entities with different structures, hierarchies, authorities, owners, and so on; therefore, they cannot be modeled with any reductionist approach (e.g., process modeling). Business process modeling will fail your decisioning efforts as it has an abstract “perceived reality” of the business decisions.
The question is: What problems does a reductionist approach, such as a process model, create if we use it to model business decisions?
The best way to explain the pitfalls of decision model using reductionist approach is to start with an example of Decision Graph and see what will be missed if we don't use graph technique.
Decision Graph
We MUST use decomposition techniques to model decisions into smaller, more easy-to-understand decision units, and as a result, we will create a “Decision Graph.” A Decision Graph is a set of connected nodes that specify the structure and hierarchy of business decisions.
Let's start with an example.
Imagine we have a decision “A” that is decomposed into decisions “B” and “C.” In a graph, we have “A” at the top (root level) and two other decisions, “B” and “C” as nodes connected to the root “A.” This means decision “A” depends on decisions “B” and “C.”
Also, “Decision C” has a dependency on a business knowledge named “Business Knowledge C.” In the above model, we also show that the inputs to “Decision B” and “Decision C” are “Input B” and “Input C”.
As you can see in the above Decision Graph, there is no order between “B” and “C.” This model simply says A = B + C as a simple decision structure.
Book a Custom Demo
Decision Model Pitfalls – The Reductionism Problem
The Reductionist view reduces the decision models to a simple view based on “sequence or order of steps” to achieve a final decision.
People are very familiar with the concept of orders and sequences, so it is easy for everyone to look at something and say: we do this first, then this, and then that. This makes everything like a process! Orders of steps to be run one after another.
What can possibly go wrong when we model the above decision in a reductionist view such as process, workflow, activity diagram, Flowchart and so on?
Loss of knowledge and context
Any flow mostly represents a reduced version of what happens during the execution of models. In this case, that is either “A->B->C” or “A->C->B”. As you can see here, because the process is based on the order of activities, you have suddenly lost critical knowledge of how these decisions are structurally connected. You have a process model that flattens hierarchy and executes them, but knowledge about the structure is not captured or lost.
Incorrect, incomplete, and bad performance
In any reductionist approach, you explicitly encode that sequencing decision into the reduced model. This is not only the INCORRECT view because no order is important, but an INCOMPLETE view, as whatever you use as ABC or ACB, is only one of the options.
Bad execution performance
During execution with a decision engine, when order is irrelevant, the decision engine can run decisions “B” and “C” in parallel. When you tie to a specific sequencing, the flow will execute in the sequence explicitly defined, leading to poor performance at runtime. (sequence vs parallel performance)
Very difficult to update
When you need to update the decisions graph, it is easy to add a set of nodes in a hierarchy level or remove, rearrange, or delete a whole hierarchy. However, in a flow model, all the flow steps should be reordered, as any change in the hierarchy requires reordering all the steps of the flow view. Imagine you need to reorder the sequences of an existing complex process entirely; how hard that can be!!
Lose opportunity in reengineering
A decision reengineering means you revisit how decisions are made and make an adjustment to improve the outcome. The refactoring of decisions is based on dependencies of nodes, required business knowledge, and dependent input data, i.e., other nodes in the hierarchy and their relationships. Flattening the hierarchy leads to a loss of context and dependencies; therefore, the refactoring of decisions is impossible. Consequently, no decision reengineering can be done!
No support for situation-aware decisions
The reductionist models (e.g., process, flow, etc.) assume that all decisions follow a single path. They don't account for situation-aware decisions for dynamic nodes, evolving conditions, or outcomes that might require alternative paths or logic.
I can still add another five issues with the reductionist approach, but let's leave it here for now!
Conclusion
The decision model pitfalls all start with reductionist approach. This technique aims to simplify models by reducing the graph to a linear model which leads to lose of fundamental knowledge about the business decisions. As the result it creates less accurate and wrong model.
An effective decision model that communicates to the business group and accurately specifies decisions has below characteristics
🔹Business-friendly language – Targets the business, operation and SME teams
🔹Clear decision logic – Allows defining rules-driven and computational and predictive models clearly
🔹Flexible and adaptable – Easy to adapt and adjust to changing situations
🔹Visual representation – As they say a picture is worth 1000 words!
🔹Transparent and explainable – enables explaining how a decision is made and executed
🔹Executable – No need to hand-over to make it executable – decisions must be executable on its own.
🔹Support decisions network – allows specifying decisions in a non-linear model and connects multiple decision graphs in a non-leaner method.
The models presented by the reductionist approach are incomplete at best (and mostly incorrect) and suffer from performance at runtime. They don't allow for decision reengineering and are very difficult to update in changing and dynamic environments.
To learn how to use decomposition technique on modeling business decisions please have a look at “How to frame business decisions systematically” article.
Last updated November 3rd, 2025 at 11:22 am Published October 17th, 2024 at 12:34 pm
