Principle #8. Automated Decision Making

Please, answer one silly question: Why are management automation systems created? It seems the answer is quite obvious. They are created to automate management, i.e. to replace manual functions with functions performed by machines and/or by computers. So, why is the task of replacing manual operations ignored so often? Instead of doing so, system designers just throw a bunch of tools at managers, and managers then have to figure out how to use them to get things done. Such tools are usually focused on gathering initial data and on performing specific actions, leaving intellectual work out of the picture.

In order to focus system designers on building more complete automation, and to outline some main implementation approaches, we introduced the principle of Automated Decision Making.

To start, let’s define what the term “decision” means from a goal-oriented point of view. At a basic level, when a person says, “I made a decision,” he is typically saying that, “I’m going to do this, I won’t do that, and I’ll do those in a different way.” There we can immediately see that he is talking about goal setting--he set some goals, removed some, and changed others.

From the description above we can come to a more formal definition: “A decision is a set of operations over goals (create, delete, update) made for a specific reason.”

We can see in this definition the related functions of “decision making,” “planning,” and “goal setting.” In the context of OODA loop these functions are performed at the Decide state, in which goals are defined based on higher-level goals, broken down into subgoals and actions, and then attached to execution strategies that are chosen and adjusted. Decisions lead these functions.

When people say that decisions must be attached to reality, they mean that decision making cannot be based on desires only, but also must take into account real facts. Such facts are:

1. Knowledge about the system and environmental structure
2. Facts that describe the state of the system and environment
3. Internal and external uncontrollable factors, that can negatively or positively affect execution
4. Important facts about the execution process of a continuous management system with a closed loop

The main provider of facts in the OODA loop is the Orient (analysis) state.

As we already discussed in posts about the OODA Loop definition and it’s implementation attempts, the Orient (analysis) and Decide (planning) states often have no clear boundaries and can be mixed together. However, those two states are responsible for most of the intellectual work performed by managers, which many system designers tend to work with and develop components around. When such components are implemented they are usually called “Decision Support Systems” or DSS.

There is a variety of different options to implement decision making. The two main approaches are called the analytical (rational) approach and the statistical (natural) approach:

• Analytical approach - uses apriori knowledge of management processes to generate and validate management decisions. In other words, at the implementation stage there is a clear pattern to make decisions. That pattern can be implemented as a mathematical model (linear or non-linear programming, graphs, and so on) or as heuristics (business rules and special algorithms).
• Statistical approach - doesn’t require the apriori model. Instead it uses statistical learning methods to process past management decisions in relation to upper-level set goals and situational information. As a result, a statistical model (typically a classification) is generated to predict future management decisions in similar circumstances.

The analytical approach is based on a formal knowledge about a system and its behavior. In contrast, the statistical approach uses the history of past management decisions, and it’s the most commonly used approach by humans. The human brain doesn’t necessarily count well, but it is a perfect associative computer which can find and modify various patterns collected in the memory. A former student, who has just found his or her first job, tries to maximally use the knowledge obtained at university. But as the student gets more experience, that university knowledge is used less and less, and he or she will more often apply patterns from successful past decisions made on the job.

Both approaches have their own pros and cons:

• Analytical DSS
• Pros:
• Able to operate immediately after a system install
• Able to generate quality (optimal) decisions
• Has high computational performance
• Can be parameterized for flexible configuration
• Can be viewed as a glass box and is able to explain why a decision was made
• Cons:
• Narrow, typically implemented for specific management tasks
• Requires significant resources to implement
• Often is not able to improve the quality of generated decisions over time. (requires manual tweaking or reimplementation)
• Does not work well with poor incoming data and produces bad decisions (garbage in - garbage out)

• Statistical DSS
• Pros:
• Highly universal. Able to generate various management decisions
• Self-learning. Able to adjust its model based on new data to improve decision quality
• Works well with incoming data errors. Even when incoming data is bad, it can produce acceptable suboptimal decisions
• Cons:
• Requires a history of past management decisions to operate
• Generates suboptimal decisions (although they can be better over a long run)
• Requires a well-structured history with formally defined goals, which may not always be available
• Usually is quite slow and requires significant computational resources
• Often is not able to explain the decision (however, there are exceptions like Decision Tree models)

It is sometimes possible to combine these two approaches in particular DSS implementations.

Many times, organizations have a problem with implementing DSS because of the high technical complexity and cost of DSS and sometimes a lack of necessary supporting technologies. Here we have to understand that automation does not have to be all or nothing. In most cases, automation can be increased gradually, going through the following levels:

• Manual - Operations are performed by humans manually without any automation at all.
• Recommendation - A DSS suggests a partial (facts or decision elements) or complete decision, which can be reviewed and modified by a human.
• Approval - A DSS generates a complete decision which is verified and approved by a human before it goes to execution.
• Supervision - A DSS generates a decision and passes it to execution right away. A human observes the management process from the outside and is able to interfere if something goes wrong. Most SCADA systems operate at this level.
• Unsupervised - The system works without any human involvement. Most low-level automation controllers work at this level.

As you can see, Decision Support Systems can lead to Automated Decision Making.

Here is the 8th principle’s definition:

“Decisions in management automation systems are subjected for automation by Decision Support Systems (DSS). DSS can be analytical or statistical, and may operate at different levels, gradually increasing from manual levels in an organization to fully automated levels.”

Key points of Automated Decision Making:

• Decision-making can and should be automated. This is one of the key reasons behind developing management automation systems.
• Components used to generate facts and decisions are called Decision Support Systems (DSS).
• There are two DSS categories: analytical (based on a apriori model)  and statistical (self-learning, without the apriori model).
• Automation is not all or nothing. The level of automation can be changed gradually.

Usage of Automated Decision Making:

• When you design a system, make a conscious decision about the level of automation desired to make management decisions. In addition to “none” (manual model) or “all” (fully automated), you may use partial automation solutions (partial or complete recommendation levels, supervision levels).
• Often, in addition to having automation at a high level, it makes sense to implement a manual mode. Such a mode is useful when the system parameters go outside of their normal range and the system can make a costly mistake (like in nuclear power plants or airborn planes).
• Know about the pros and cons of different DSS types. If there is a well-defined decision pattern, use the analytical model. Otherwise, a statistical DSS might be the answer. Keep in mind, though, that statistical DSS solutions are still at a very early stage of maturity and do not always work as expected.
• Finally, in order to automate a decision it must be repeatable, i.e. it must have some sort of pattern--clear or unclear. If a decision is unique, or if there is no pattern, we will not be able to automate it well with our current level of technology. But that doesn’t mean we can ignore such decisions! The GOMA system will provide tools to managers to formulate their unique decisions manually. It shall then trace them throughout the entire system (see Information Integrity principle) until they are broken down into well-defined goal/action levels and executed. Those traces will allow managers to collect captured results and link them back to decisions made at any level, whether they were generated automatically or not. That’s the power of GOMA--bringing transparency and manageability into complex multi-level management systems!

Decision Support Systems, even if they are implemented at a basic level, can lead to Automated Decision Making. This will in turn lead to strong management automation systems.