Principle #2. Continuous Management

The principle of Continuous Management looks at any activity in any level of an organization as an OODA Loop management process. This approach presents a universal model to look at the management performed by a single person, a group of people, or an autonomous system. Also, because of the OODA Loop approach, the transition from manual to automated processes and visa versa is made easy, without drastic changes to the way management is being done. These facts are very useful in the development of management automation systems.

Similar to other principles, the principle of Continuous Management stands against the gaps in automation. In this case, it is concerned about the gaps in local management areas caused either by an absence of required information flows or management functions, or their poor integration. To address these gaps, the OODA Loop can be used as a model where information flows coming into a system are processed and transformed continuously by management functions through 4 distinct states: Observe, Orient, Decide and Act. Also, because of the OODA Loop, information flows and management functions can all be active at the same time.

Continuous Management is defined as the following: “Any activity in an organization can be considered as a continuous management process that transforms information through 4 distinct states: Observe, Orient, Decide and Act. Even the simplest work can be viewed as the management of a particular piece of equipment or one’s own body.”

Key points of this definition:

• Management is a continuous process. Situational information is captured and interpreted, action plans are defined through higher-level goals, and actions are executed that lead to situation changes. Then, the changes in the situation are observed and interpreted, goals and plans are changed, and new actions are executed. By doing this, the management cycle repeats itself again and again, and, in that cycle, all information flows are interconnected.
• Management is an information process. Situational information, interpretations, goals, and plans are all information flows. They are produced and/or consumed by a management automation system. Even actions, which cause physical effects in the outside world, can be defined as information about work done and its related changes.
• Management has a broad meaning. Management in C2/GOMA is not considered as an activity performed exclusively by professionals with a “Manager” title. It understands any type of goal-driven activity as being a type of management. Any work, even the most simple function, can be viewed as the management of particular piece of equipment or one’s own body. Moreover, C2/GOMA management is not limited to the activities performed by only humans, but also by automation systems, Artificial Intelligence, robots, microcontrollers, and so on.
• Management can be described with the OODA Loop. In essence, what is management? It is a procedure that processes information and leads to related actions. Before taking action, newly observed information has to be interpreted and turned into decisions about what actions to take and when. Management has to Observe, Orient, Decide, and Act.

Finally, now that we see how Continuous Management is defined, how do we apply it?

1. Use a common approach to management automation problems. In its essence, the management process does not depend on who manages (an individual, a group, or an automation system) nor on what is being managed (an entire organization, a department, a dozer, or just pair of hands with a shovel). Apply the same approach throughout the system.
2. Utilize the OODA Loop as an analytical model. When you need to analyze a system, in order to understand what management functions and information flows exist there, try the following:
1. Define what situation information is captured and who/what produces that information.
2. Define how information is interpreted, what facts are used for decision making, and how those facts are chosen.
3. Define how action plans are formulated.
4. Last, define what actions are taken, what effects are observed, and what will drive new decisions.
3. Utilize the OODA Loop as a synthetic model. If you already have your management automation components defined, you can use the OODA Loop to verify whether or not the functions are integrated correctly, what gaps there are, and how the implementation compares to reality:
1. Classify components by states in OODA Loop.
2. Classify information flows and link them together into cause and effect chains.
3. Create an OODA Loop model for the real system.
4. Compare the real (required) model to the current (developed) one. Define what management functions are absent and which ones are excessive.
5. Define what information flows are absent or excessive.
6. Finally, analyze the external dependencies and compare them to public interfaces.
4. Improve the flexibility and reusability of automation solutions by implementing and utilizing generic management procedures.
5. Stop doing disruptive, gappy management automation using isolated sequential functions. Even though the simple, single-function machine is well understood and proven, the alternative is not much more complex, and it is much more powerful. Try to implement a management system that uses functions for all 4 states of the OODA Loop and close the management cycle.

By doing this, the principle of Continuous Management will help us create complete management automation systems.

Automation Experts vs Their Clients: Automation Tools Instead Of Automation Solutions

In the biggest part of my daily life, I develop management automation systems. And, as every respectful professional, I am proud of my work. I see my work making a real difference for my clients. I know that I’m adding real value to my field. Can you imagine, then, what a shock it is when I realize it’s not at all like that in reality?

Once upon a time, I met my client. After we exchanged our greetings, my ears were ready to hear positive feedback about my work. But, instead, silence was his response...

“What’s up?” I asked. “Don’t you like our system?”.

“Well,  the system seems to be ok...” he responded.

“Well, and... does it help you in your work?” I asked.

“Well, yes... It seems it helps...”

Only later on, in a restaurant after two or three shots, my client relaxed and started to curse all the buttons and screens that were making his life so difficult.

“But how can it be like that? Why must I hear all of that after so many days and nights of my hard work? This guy just doesn’t understand anything in computer science!!” I thought, angrily.

The truth is that we were both right. The guy was right--his life and work became really terrible. And I was right too--he didn’t understand a thing about the high art of computer science...

But there is one firm rule in business: “The customer is always right!” So, let me suppress my angry ego and look at the world through eyes of that simple man.

How it all began.

Just imagine a simple haul truck. Steering wheel, pedals, gear selection, and ignition key.

Overall, there is nothing special. The operator starts the truck with the key, turns the steering wheel, and presses pedals. He loads the truck one place and unloads it in another, and he does this over and over, many times a day.

Next come the automation experts.

A group of the smartest automation experts then approached the haul truck and started to fill it with various automations. They added several sensors and intellectual control systems. They installed system displays with guidance marks, allowing the driver to change operation modes and observe state indicators, and they put in several screens to help visualize situational information. Finally, they installed systems to monitor the operator’s fatigue level, suggest optimal decisions, or just to entertain him and help him stay awake while driving. After all these new installations, the results looked something like this:

The tired but satisfied automation experts washed their hands. The haul truck had become really cool and even looked as good as the space shuttle Challenger!

Later, the operator got back to his truck and what followed was a silent scene of terror.

“Is this what you guys did for my millions?!” he asked, horrified.

“Yep! Don’t you like it?!”

“NO!!!”

Of course, the operator wasn’t right. The automation he got was amazing and state of the art. However, as he was the customer, he was right by definition.

What the client really wanted.

The client was a simple man and he did simple things--he would load his haul truck, drive it on a road with a steering wheel and pedals, and unload it before driving back. Sometimes he might have to fuel it or go to maintenance, but that’s it.

When the client paid the big buck, he wanted a solution for his problems. He wanted an automation system, not him, to load the truck, drive it to a dump location, unload it, and then drive it back. And he, the client, just wanted to sit back and watch it work, making minor corrections from time to time.

He didn’t need a Challenger at all. Before, just a simple haul truck was enough for him.

“But how can it be like that? What if something unexpected happens?” the automation experts asked.

“Well, if something happens, just give me back my steering wheel and pedals and I’ll make it right,” the client replied.

Thinking aloud.

From that story we can see a huge gap between the mindsets of the automation experts and their clients.

Automation experts try to build powerful and optimal systems. Because life is a complex thing, their systems allow many ways to observe, analyze, make decisions, and then act upon them. This leads to the creation of automation tools, which let clients do whatever they want, and even more.

But the client pays money, and for his money he wants do nothing. He just wants to rest in peace... He wants to nap, while the expensive automation system works for him. Does he care about optimization? Well, yes, of course... It’s important that the smart automation system works close to the same level he does. Otherwise, he has to steer that steering wheel by himself. Thus, he is interested in automation solutions for his problems, not the automation tools he gets.

Here’s another example of this mindset difference:

We have a system that collects a large amount of data--sensor readings from onboard systems, operator reports, and measurements from external monitoring systems. We create an application, which allows a user to plot all that data on a map and then filter it in a hundred different ways, draw it in different colors, lay one dataset on top of the others, and do many other useful and complicated things. We solve hundreds of complex technical issues, and the developed system becomes really cool. With its help, people can do many types of analysis and make decisions on hundreds of different problems. Very cool! But all of these aspects of our system are just automation tools, and that is not what our client needs. That’s not what he paid for.

Again, he needs automation solutions for his problems. One client is responsible for road maintenance, and, by pressing a button, he would like to see roads maintained all by themselves. Another client has a problem with fixing too many truck breaks, and, by pressing a button, he would like to see which operators burn those breaks in order to get them warned, retrained, or fired. As automation experts, we need to just keep it simple: one problem--one click--one answer. The popular phrase goes “less is more.” And that is exactly right!

Innovation Models

Recently, I attended a workshop led by Jay Paap about some very interesting innovation models, and I wanted to share what I learned with you. You may ask, how is innovation relevant to C2/GOMA? Well, the fact is that C2/GOMA is a new thing, so it is an innovation itself.

If you are a researcher or a practitioner, you might have experienced having your brightest and most useful ideas staying on paper and never seeing the light of day because of a lack of money. Therefore, in order to get the attention of money lenders and investors to make it happen, you should have a basic understanding of the innovation process and considerations that follow a good idea.

At the beginning of his workshop, Jay started with the definition of “idea.” He gave a simple, but powerful formula:
 

Here, “need” represents the customers’ current and emerging (or unarticulated) needs, and “technology” represents a solution to satisfy those needs.

The definition says that an Idea is a new and unique way of putting new or existing technology to work to address a new or existing need valued by the customer.

Then, Jay presented the Marquis Innovation Model:

In this model, innovation begins with the practice of relating technology to customer needs with the goal of developing new ideas. An idea is then selected. It is put through a concept test, developed, and--depending on whether it performs well or not--is then either used or diffused.

It is a straight-forward model. However, in most organizations, we can find a few problems in this process implementation:

1. Not clearly defined/lost needs. When people hear or see a problem (or need) they quickly jump into solution mode (technology) and never capture and analyze the need properly. Or, they may get a formal request for a solution from a customer and never try to understand the needs that are behind it. By moving so quickly, they don’t create new ideas. Without properly defined underlying needs, people are never able to consider alternative technologies, or review their ideas after time passes. This is a big issue in organizations, and it is seen rather frequently.
2. No clearly defined gates. A gate is a decision point in the process where the process can be stopped if needed. The truth is that the innovation process can be stopped at pretty much any time, but many people do not realize this, or they refuse to acknowledge it. By having defined and set gates in the process, people are made to reassess the growth and direction of their innovation. A gate enables the reanalysis and filtering of ideas. But a lack of these gates leads to two big problems: (1) people are reluctant to try something new because they fear the failure of the project, and (2) wrong ideas, that people started working on, are followed through to the end and result in failure with big damage.

Clearly defined ideas (needs and technologies) and the proper analysis and filtering at different gates are critical to successful innovation. We know what to do to get innovative ideas, but what do we do to create helpful gates? What criteria do we use? Jay Paap then went on to talk about making sure an innovation will be successful.

Whether an innovation will be successful or not is the biggest consideration in the innovation process, and the ultimate measure of success in marketing is financial results. It is measured as the Return of Investments (or ROI) and is calculated with the following formula:

In this formula, “Investment” represents the the amount of investments the company makes to create a new technology, and “impact” represents the overall negative or positive results of the new technology.

Unfortunately, clearly defining ROI in this form is nearly possible. Most often we only see the real numbers and returns at the end of the process. At the beginning, investments are roughly estimated and the future impact is almost a wild guess.

To simplify the estimation process Jay Paap transformed the ROI formula. He noticed that Investment is linked to Impact based on whether or not the innovation is useful to the customer. Customers will pay money only for something that is useful and has value to them. The innovation must create a positive change for the customer--it has to positively impact his or her performance and quality of life.

With this information, Jay took the ROI formula and changed it to the following:

In his new formula, “Productivity” stands for the extent to which an investment in a technology will yield a measurable change in the performance of a process, product, or service, and “Leverage” stands for the extent to which an improvement in a performance will be perceived as having value by the customer.

By performing the above calculation we can more easily see what kind of overall impact our innovation will result in. Also, because Leverage and Productivity are not strictly financial characteristics they are easier to assess.

Because Productivity is a characteristic of a Technology, and Leverage is a characteristic of a Need, Jay represented both characteristics on the following S-curves:

Finally, Jay showed how the right level of investments in Productivity and the correct amount of performance improvement in Leverage will lead to the highest level of impact:

Good investment in productivity leads to good technology performance, which leads to a high impact with customers. With good investment, a healthy level of Productivity can be reached that will result in a high level of Leverage, which, following the reformed calculation above, gives a good Return of Investments.

By checking our innovation process with this formula at the correct gate, we can tell if our clearly defined idea will be successful and have a strong impact on customers.

These are very interesting and helpful models. Hopefully, understanding and practicing them will help you push your ideas forward, make them happen, and maybe even be rich someday. Whenever a new idea appears in your head, just look for the needs of customers, estimate the productivity and leverage of the innovation process, and be prepared to present your idea to your managers or investors. 

It can be done!

Most of the above information can be found in the award winning paper, “Predicting the “Unpredictable”. Anticipating Disruptive Innovation”, written by Jay Paap and Ralph Katz.

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...