Monday, November 28, 2011

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.

    Monday, November 14, 2011

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

    Sunday, October 23, 2011

    9 Principles of Management Automation

    How is management automation developed today? “Well, there are many ways,” you might say. And you’d be absolutely right. Today it is still an art rather than a science. Companies had to invent their own methods of development, make mistakes, learn from those mistakes, and later repeat them all over again. While doing research in C2/GOMA, we saw a lot of typical mistakes as well as many good solutions. As a result of our work, we formulated 9 principles to guide the development of management automation.

    While some of these principles may seem obvious, we believe all of them are critical for creating a good management automation system.

    Here are our 9 principles:

    1. Organization Wholeness. 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.

    2. Continuous Management. 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.

    3. Functional Completeness. Any complete management automation system must have 5 tightly integrated functional groups: Sensing, Analysis, Management, Execution, and Communication & Collaboration.

    4. Goal-Orientation. Most interactions in an organization are driven by goals. Higher-level goals are detailed, broken down into sub-goals, and propagated throughout management levels until they are executed. The outcomes are then composed together and included in the overall achievements of the organization.

    5. Information Integrity. Any decision in an organization has reasons and consequences. An analysis, based on the information and outcomes of previous goals, is used to drive new decisions. The management automation system, in order to help its users make logical and correct decisions, must provide an infrastructure to keep the information whole and complete.

    6. Shared Situational Awareness. Decisions in an organization must be based on actual situational information. Because of this, the management automation system must provide shared situational awareness based on validated and consolidated data. The situational information can be represented in different forms, graphically or textually, and visualized by the use of Common Operational Pictures (COP views).

    7. Standard and Unambiguous Communication.  Communication in a management automation system must be based on commonly understood languages and standard protocols through all aspects and levels of the organization. This will aid understanding and the seamless integration of automation processes.

    8. Automated Decision Making. Any decision in an automated system will be made 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.

    9. Complementary Information Types. The management automation system, in addition to having formal and structured information, must also support informal and unstructured data in order to respond to unpredictable real-world situations. The structuring of information in this way will enable the management automation system to respond realistically to real-world circumstances, make informed decisions, and effectively increase the level of automation.

    These 9 principles of management automation, if implemented, will greatly aid in the formation of management automation systems. In this post, I mainly wanted to present the 9 principles and give a general overview. In my next posts, I will discuss them in further detail.

    Keep reading!

    Thursday, October 6, 2011

    Levels of Reasoning in Goal Setting

    The setting and reaching of a goal is most often pictured as a deliberately planned and executed act. But in reality this is extremely rare. Most often we can see things around us happening that are just following the flow, without any special considerations or thoughtful actions. That creates a disconnection between goals and everyday life. In C2/GOMA we are trying to automate the most common everyday situations using a goal-oriented approach. In order to do that, we have to bridge that gap somehow. We need to change the way we think about goals and accept the fact that goals may not always be deliberately planned. Jens Rasmussen came up with a model called “3 levels of human behavior/reasoning,” which gives us a totally new approach to goal setting.

    In the paper “Skills, Rules and Knowledge; Signals, Signs, and Symbols, and Other Distinctions in Human Performance Models”, Jens Rasmussen writes: “The introduction of information technology based on digital computers for the design of human-machine interface systems has led to a requirement for consistent models of human performance in routine task environments and during unfamiliar task conditions. A discussion is presented of the requirement for different types of models for representing performance at the skill-, rule-, and knowledge-based levels...”.

    Further down he defines 3 levels of human behaviors:

    1. Skill-Based: “The skill-based behavior represents sensory-motor performance during acts or activities, which, following a statement of an intention, take place without conscious control as smooth, automated, and highly integrated patterns of behavior.”

    2. Rule-Based: “At the next level of rule-based behavior, the composition of such a sequence of subroutines in a familiar work situation is typically controlled by a stored rule or procedure which may have been derived empirically during previous occasions, communicated from other persons’ know-how as instruction, or a cook-book recipe, or it may be prepared on occasion by conscious problem solving and planning.”

    3. Knowledge-Based: “During unfamiliar situations, faced with an environment for which no know-how or rules for control are available from previous encounters, the control of performance must move to a higher conceptual level, in which performance is goal-controlled and knowledge-based. In this situation, the goal is explicitly formulated, based on an analysis of the environment  and the overall aims of the person. Then a useful plan is developed...”

    You shall remember that C2/GOMA defines goal as “a future state of affairs that person or system plans or intends to achieve.” But the definition does not explicitly say how that state is set and achieved. It could be deliberately planned, intuitively figured and carried out, or, even, could be a preset function.

    Following Rasmussen’s reasoning loosely, we can apply his 3 levels of human behavior to Goal Setting:

    1. Knowledge-based Level. For new and unfamiliar goals, or goals approached in a new way, the person will use his or her knowledge and creativity to come up with a unique plan to achieve them.
      • Examples: researching and deciding on which school to choose for one’s child, acting at a new job position for the first few days, living in a new unfamiliar country, or planning to rob a bank for the first time.
    2. Rule-based Level. For familiar goals, which a person has had previous experience with or learned about from available sources, a pattern-based (or template/rule-based) plan is used. He or she may apply minor tweaks to make that plan a better fit to the current situation.
      • Examples: interacting with a cashier at a store, cooking breakfast, or following a known business-process at work.
    3. Skill-based Level. For goals that are habitual, or anticipated by human nature, a person may act automatically without any conscious effort.
      • Examples: walking down the stairs, saying “hello” to a person who says “hello” to you, driving a car, or pretending to do your work.

    As you can see, most of our goals (or future states) are set and achieved at an unconscious, skill-based level. When we set a goal to walk to a nearby place (future state: take a certain position in space) we don’t plan every step, our body simply acts automatically. When we need to type something on a computer (future state: enter specific text) our fingers just press buttons by themselves. We don’t think about it much.

    Sometimes, we may use our brain to deal with minor changes in a situation to tweak patterns we acquired over our lives, picked up from family members, learned at school, or watched on TV. The human brain is a perfect pattern-based machine. Its associative memory can store an enormous amount of different patterns and quickly find something, even if it’s loosely related and based on some weird association. In this regard, there is no computer available yet that can match a human’s brain. Even when meeting something new, a person will most likely find something similar in his or her past experience and will quickly apply it to the new situation.

    To tell the truth, it is actually very rare that we sit and sweat and try to invent something totally new. It is rare that we try to take on unfamiliar situations and goals. Most of us don’t like that. Working at the knowledge-based level is an area for weird creative individuals. Most of us prefer to stop or walk away from a situation when there is no suitable pattern found.

    The majority of our goals are set and carried out at the rule and skill-based levels, and only a few--many times the most important--are performed at the knowledge-based level.

    There is one more aspect I want to mention here. C2/GOMA doesn’t make a strong distinction between people and automated systems. That’s one of the strengths of the theory--a person can be replaced by a computerized system or robot and nothing will really change. The management model will stay the same.

    How is this possible?

    Actually, it’s quite simple. Consider the following: any automated controller or computer program works deterministically. It generates a predictable response to given inputs. Thus, if the goals (future states) of an automated system are preset, and plans to achieve those goals are hardwired into the system design, the system acts at a skill-based reasoning level much like a human would.

    Some automated systems, powered by Artificial Intelligence, can act nondeterministically, or may alter their behavior based on achieved results. For instance, rule-based expert systems use predefined rules to generate responses, neural networks are trained on known datasets to be able to recognize familiar inputs, and statistical learning systems are able to process historical information collected in databases and then discover statistical patterns. These methods are still not as sophisticated as the human brain. But they are already able to achieve quite a lot... You’re absolutely right, if you recognize reasoning in these systems at a rule-based level.

    But what about the knowledge-based level of reasoning? Most people don’t want and don’t like to operate at the knowledge-based level, and, so far, automated systems are not able to reach that level yet. Therefore, even though C2/GOMA is trying to automate as much as possible, there are still areas with new unfamiliar goals where creative people cannot be replaced with technology. However, considering the rapidly expanding knowledge of our information age, such creative and special areas are shrinking quickly. The three levels of reasoning and goal achievement may soon all be carried out by management automation systems.

    Sunday, October 2, 2011

    Goal Orientation

    Goal Orientation is the second key to the C2/GOMA principle. It states that most interactions in an organization are driven by goals. Higher-level organizational goals are detailed, broken down into sub-goals, and then propagated throughout the management levels until they are executed. After the goals and sub-goals are completed, the following results are then composed together and become included in the overall achievements of the organization.

    If the Continuous Management principle is concerned about a single Decision Making Entity, then the Goal Orientation principle provides a model to compose individual Decision Making Entities into a complete management system.

    Depending on the organization, the goal structure may significantly vary. However, the formation will usually contain the following six levels of goals:

    • Policies, regulations, laws - goals from above and outside the organization, set by a government through legislative acts
      • Planning horizons: Multiple organizations/entire industries for 3 to 10+ years
    • Long-term goals - goals related to strategic initiatives, changes in organizational structure, and entering/exiting markets
      • Planning horizons: Entire organization or organization departments for 5 to 10+ years
    • Mid-term goals - goals having to do with changes in products and services, large investments, and hiring employees
      • Planning horizons: Organization departments for 3 to 5 years
    • Short-term goals -  goals having to do with typical projects and hiring contractors
      • Planning horizons: Departmental groups from a few weeks to 1 or 2 years
    • Real-time dispatching - goals related to day-to-day management, task assignments, and emergency management
      • Planning horizons: Daily, across multiple resources
    • Specific operations - goals having to do with the work of individual resources
      • Planning horizons: Daily, individual resource work

    Historically, the creation of an organization’s goals and their orientation was tightly related to the organization’s structure and top levels of management. Structures like these, where goals are defined and flow in a strictly top-down manner, are known as “hierarchical structures.” In the modern world rigid hierarchical structures are becoming less popular due to their inefficiency and lack of agility. This has given birth to a more relaxed organizational structure where goal propagation and orientation is not tightly related to the chain of command, and where goal making is instead allowed at multiple levels. Relaxed structures like these are called “networks.”

    Theoretically, it is possible to have goal propagation from lower to higher levels across different chains of command, but, practically, it may not make sense due to incompatible planning horizons.

    As the second key to the C2/GOMA principle, an organization’s goal orientation must fit its structure in order to be effective. With an effective goal orientation, management automation will be much easier to carry out.

    Thursday, September 15, 2011

    Continuous Management

    Continuous Management is one of two key C2/GOMA principles. It is based on the OODA Loop concept, which states, “A work of any active element in a management system can be considered as an information transformation process that goes through 4 distinct states: Observe, Orient, Decide and Act”. In this post I will discuss active elements, the OODA Loop, and Continuous Management in C2/GOMA.

    Active Elements (or Decision Making Entities) are system elements that actively contribute to a management process. They can be a person, a group of people, an automated Decision Support System, a robot, or a low-level microcontroller.

    The Continuous Management principle gives us a universal model to look at the work of any active element In the OODA Loop cycle (Observe, Orient, Decide, Act):

    • Observe: The active element receives initial information from the outside world (viewed world).
    • Orient: The active element interprets the information and makes certain conclusions (understood world).
    • Decide: The active element creates an action plan based on its goals and interpreted situation (action plan).
    • Act: The active element acts upon the plan by either taking action or delegating actions to other active elements. The actions performed then cause changes in the system and the environment (produced results).
    • Observe: The active element receives new information from the outside world with changes caused by previous actions and external factors.
    • Orient: The active element interprets the information, compares it to expectations, and makes certain conclusions.
    • Decide: The active element then makes adjustments to the action plan, or generates a new plan if the previous one was accomplished (or if it failed).
    • Act: The active element performs a new set of actions or delegates them to other active elements, and then--
    • The cycle repeats over and over again.

    Here you can see the distinct methods of the OODA Loop being done, performed by an active element at any given state, that we call “Management Functions.” There are four different types of Management Functions:

    • Observation Functions: obtain initial information from the outside world, perform a preliminary check, and consolidate similar information received from different sources.
    • Orientation Functions: interpret information, apply it to expectations (plans), and make conclusions.
    • Decision Functions: generate or adjust an action plan.
    • Execution Functions: execute or delegate actions while making potential minor adjustments to accommodate for possible situation changes.

    While looking at these functions and steps, it is important to understand that the OODA Loop is not a machine that creates states. The states represent stages in the information processing flow. All the states are active at the same time, which is illustrated by the following figure:

    The OODA Loop is a constant process continually moving.

    There is one more interesting fact to look at. Many of you probably know about the following pyramid model: Data - Information - Knowledge - (Results):

    • Data - raw unprocessed information
    • Information - processed, interpreted, relevant information
    • Knowledge - actionable information, action plans
    • Results - post-actionable information, effects of planned actions

    If you relate those information categories to the states in the OODA Loop you can see that they map really well.

    This fact is another confirmation that the OODA Loop can describe the information processing flow in any management system that turns raw information into actions and results.

    So, why is Continuous Management so important to C2/GOMA?

    When people develop management automation, they perform a lot of analysis. By doing that, they extract management functions and implement them. But when those functions are put together, they may not fit each other and the management reality seamlessly. As a result, the created management systems become incomplete, have numerous gaps, and do not address the organization’s problems well.

    To improve, a different step than analysis must be made--synthesis. The Continuous Management principle uses the OODA Loop as a synthetic model to put different management functions together, link them in a natural flow, reconstruct the entire system, and then see how it works as a whole.

    By doing this, the Continuous Management principle helps to eliminate the gaps in automation for an individual Decision Maker. It provides management functions and the required information, promoting a continuous flow to deal with gaps in information and functionality. Then, by providing management functions that are able to work alongside each other, moving information at different stages simultaneously, it covers the gaps in time between business processes. The principle of Continuous Management, with the OODA Loop and active elements, will greatly aid any organization’s management automation.

    If you have any questions, I invite you to comment with them below.