End-to-End Operational Decision Automation

Operational decisions drive the behaviour of business. Therefore, decision-centric organisations will become the front runner of Operational Decision Automation as this becomes a key player in running business efficiently. As we discussed in an earlier post, operational decisions are good candidates for automation, because they are mostly structured and repetitive. They consume data and information and produce results in many different forms (i.e., value, list of options, etc.) based on a decision logic (rules, analytics, calculation, etc.).
Often when discussing operational decision automation, the focus is on decision modelling and execution, but there is much more to it than just the decision part. In this post we are going to have a look at the broader picture and then dive into the details in future posts.

The Decision-Centric Approach^® enables organisations to think, model, execute and manage operational decision automation as a complete decision-making methodology rather than as individual, separate components, steps, processes , etc. which will cause a disconnected decisioning experience and in turn becomes a bottleneck that fails to meet the expected ROI.

OODA Loop – the decision cycle

Many organisations are faced with the pressure of reacting to the internal and external forces that cause constant re-evaluation of how to best to run their businesses. To best answer these questions, they need to understand how to put together a framework for operational decision automation in different situations by defining the necessary changes by each one. The best way to think about it is using a decision-cycle called OODA loop.

The OODA loops for operational business decisions is designed to ensure the effectiveness and efficiency of complex operational decisions. It suggests, there are four stages in any operational decision automation activity – observe, orient, decide and act. From the perspective of a business seeking to automate operational decisions in a continuously changing and competitive landscape, we can map the OODA loop’s stages and translate them as follows:

1. Observe: Look for triggers, external and internal business events. Connect to relevant data sources (i.e., database, files, services, etc.).
2. Orient: Building context for decision execution. Orchestrate, transform, predict and build the decision’s context.
3. Decide: Model the decision’s logic. Deploy and execute decision models based on business decisions, rules, analytics and AI.
4. Act: once the decision is reached, apply the results and consequences of the decisions made.

Note that the OODA loop is a non-linear cycle and has multiple feedback and backward transitions from different stages. The OODA loop for operational decision automation is designed to ensure the effectiveness and efficiency of complex operational decisions. It empowers organizations by sitting on top of each one.

Observe

Enables organisations to be aware of internal and external situations and connect to relevant data sources, as well as get notification for specific business events by understanding how to use and apply them. The problem with that is that organisations simply cannot keep pace. That’s where we need to take another approach.

Data is necessary for decision automation at different stages such as development and testing, as well as in production. However, the source data changes from one to another. The quality of each might not be the same. Therefore, the ability to connect to different data sources and build a quality matrix around the data is very important.

Orient

Decisions do not exist in a vacuum. They need a context. The context provides all of the relevant data and information to the decision model. In the Orient stage, a valid context is created for the decision model.

In operational decision automation the context is made up of at least two different scopes:

• Operational scope: such as application data, processes, tasks, events etc.
• Business scope: defines goal, motivation, objectives, constraints, principals etc.

Also, in the Orient stage the collected data and information will be put into a perspective if needed. For example, individual data can be viewed and translated from different viewpoints (e.g., safety, regulation, operation, etc.). Sometimes, the information can be extracted from the scope by some prediction mechanisms (e.g., regression algorithms). And sometimes data enrichment is required based on what decision is needed. The backward transition allows the collection of more data and information if necessary.

As is evident, the orientation and building of the context may not be as trivial as we imagined and there are lots of dependencies to be managed, which can then be evolved and changed over time while automating operational decisions or even when they are operationalized and placed into production. Therefore not putting this responsibility in application later is a critical factor for a successful operational decision automation.

Once the context is created, then it can be passed to the next stage.

Decide

At this stage of the decision-cycle, the decision is modelled. This is the heart of the cycle and allows decision modelling and execution.

The context from the previous stage is passed to the model and, once executed, the results are created and ready for the next stage.

Modelling of decisions happens at two levels:

• Conceptual models – High level models that describe the components of the decision-making model
• Decision logic models – the implementation of the decision logic algorithm using multiple methods (i.e., Decision table, boxed expressions, natural language, PMML, tree-subtree, business rules, etc.)

We are going to talk about the modelling of decision-making scenarios in more detail in future posts.

Act

After decisions are made, the results are submitted to the Act stage, which is responsible for taking an action based on the context and results of the decision model.

This action can be any or all of those shown below:

• Decision Optimisation – finding the best decision results based on constraint and other criteria
• Decision Robotics – enables the decision automation to interact with systems, applications, and so on
• Human Interaction – creates tasks and requires humans to take action on some tasks and, after receiving the results, continue to the next step
• Process Orchestration – engage in more sophisticated comprehensive orchestration of activities in order to accomplish an outcome.

Finally, the results in the evaluation context are stored in the decision results repository for reporting and performance measurement reasons. The execution then goes back to the beginning of the cycle if necessary and the cycle is restarted from the beginning.

Conclusion
As described here, there are much more than decision modeling and management to operational decision automation.

If the focus becomes purely on decision i.e. decision modeling and management, ultimately companies meet the same constraints that drove them to look for decision management in the first place, which is that they couldn’t deal with the volatility of operational decisions. This is called, the disconnected decisioning experience.

When you are undertaking operational decision automation, keep in mind that it requires much more than the decision modelling and implementation of decision logic. It requires different data and information be collected and compiled together as the context. The context will then be passed to the decision model for execution. The results of the decisions must be processed and action taken upon those. Full end-to-end operational decision automation brings significant value to organisations and performance can be measured based on business values and KPIs.