Principle #1. Organization Wholeness

In this and the following posts, I wanted to go over a few of the principles of Management Automation. For the purpose of keeping everything together, I’ll start off by restating the first principle, Organization Wholeness.

The principle of Organization Wholeness stands against the chunky, fragmentary, and self-centered approach to automation. Instead, it promotes a holistic, systematic approach to the entire organization and its environment.

The principle states: “Any organization is an open system created with the intent to perform work in the outside world. Irrelevant to its size and industry, the organization must have different management levels and functional areas, working together to accomplish the organization’s intended purpose.”

There are few key points here that we should pay attention to:

• The organization is an open system. The open system is a special class of systems studied by General Systems Theory. It doesn’t exist entirely on its own, but must operate in an environment that it relates to.
• The organization has an intent. This intent is an upper-level goal (or goals) set to drive the organization, usually decided upon by the organization’s founders. However, the organization may also generate goals for itself. Like a person, because it’s fully automated, the organization has self-actualization and its own will.
• The organization performs work in the outside world. The organization actively interacts with its environment and changes it. The organization’s upper-level goals have to do with objectives outside of the organization, not inside.
• The organization is composed of interacting elements. The elements of the organization perform different functions and are all interconnected. They work together, and no element is completely self-sufficient.
• The elements work together toward the overall organizational goal (or goals). The organization is goal-driven. Therefore, its elements must contribute to the upper-level organizational goals. If they don’t contribute, then the organization most likely doesn’t need them.

Now, how do we apply this principle? Remember, we are trying to create a comprehensive system. Therefore, even if your task is to automate a specific part of an organization (a component/subsystem), always consider all formal and informal collaborations it has with the rest of the organization and its surrounding environment. Then, do the following:

• Define the upper-level goals that drive your subsystem and be clear on how your subsystem will contribute to the overall organizational goals.

• Define what goals are set inside your subsystem, and which ones are propagated to other subsystems.
• Define how the supplementary information, required to achieve goals, will flow.
• Map the scope of your automated subsystem to a created model. Make conscious decisions regarding what you automate and what you do not, and why.
• Finally, remember that your subsystem will not be the only one out there. Consider all interactions, and plan to put some sort of interfaces in your component/subsystem. Your customers will love you for that! :)

When components are fully integrated with each other, and are not self-centered systems that work for purely individual goals, we can reach comprehensive management automation. Applying the principle of Organization Wholeness brings us closer to C2/GOMA.

Redefining OODA Loop: Detect-Decide-Respond

Increasing the level of automation in management is a common theme today, and many companies are attempting to do so in their own way. Today I came across an interesting presentation, “Turning Automated Decision Management into Real-time Operational Advantage” by Brian Safron, a Program Manager from Websphere Decision Management, IBM. (You have to register to view the presentation or the video.)

In his presentation, Brian talks about the approach taken by BPM solution providers. Their core product is the Business Process Management engine, which is essentially a simple rule-based decision-making workflow. To increase the level of automation--to make the BPM engine work in real-time--they have to somehow close the loop. They have to go from making decisions to performing actions.

“Brilliant minds think alike,” so their solution looks pretty obvious to us. To make it happen, they capture situational information and channel it into BPM software. Then they take the generated decisions and push them to actuators for execution. Here, we can immediately see the Observe and Act states from OODA Loop.

The part that was most interesting to me about their solution lies in the middle. The OODA Loop has a known shortfall related to an unclear boundary between the Orient and Decide states. To address this issue, the people from BPM mixed those two states into one and created a simpler, 3 state Detect-Decide-Respond (DDR) Loop.

Mapping DDR to the OODA Loop is simple:

• Detect = Observe
• Decide = Orient + Decide
• Respond = Act

Should we switch to the 3 state loop? Maybe. But I don’t think so.

A problem will arise when you approach multi-level management. Goals for business processes are implicit. The biggest limitation of the BPM system is that the processes it monitors are simple horizontal constructs. There is no vertical dimension related to the goals propagated throughout management levels. Therefore, because it can be applied to any situation, the 4-state OODA Loop gives us a better, cleaner model to look at information processing in multi-level management systems.

The principle Superposition & Composition, which utilizes the relation between Goal/Action states (Decide/Act states) and Observation/Interpretation states (Observe/Orient states), gives us a good reason to stick with the OODA Loop.

• Action is the most basic goal considered at any given management level. Action, propagated down to lower management levels, becomes a high-level Goal that has to be executed.
• Observation is the most basic Interpretation performed at any given management level. Interpretation, propagated up to higher management levels, becomes a low-level Observation that has to be analyzed.

Information flows between management levels, and decisions are made based on that information. Superposition & Composition gives us a repeatable pattern that can be applied at any management level, and, using the OODA Loop, connects all those levels together. Mixing the Decide (goal-setting) and Orient (interpretation of obtained data) states together creates a less capable 3 state loop. Therefore, it is not my choice...