November 16, 2008

Control: Got, or Not?

Execution means operations, and whoever is behind the wheel must have control; otherwise we can pretty much anticipate that things won't predictably get where they are supposed to be, and/or that there will be a crash.

Control of operations, by definition, means controlling the range of effects produced by driving a collection of interactions. The usual approach to tracking degrees of control is to put gauges on each one of the smallest number of critical states (conditions) produced within operations -- and to use real-time gauges as continuously as possible. The correlation of the information from the various gauges tells whether overall operations are proceeding within an acceptable range of behaviors.

The collection of gauges is readily recognized as a dashboard. But the correlation of them is where the actual control begins. The diagram above shows the Archestra model for this correlation.

The model shows how to avoid non-sense metrics and focus on essential observations and connections. For example, there is a shared boundary between Priority and Plan, where the sharing indicates the need for an instrument that coordinates the priority and the plan. The instrument is Policy. Meanwhile, the primary rational coordinator of  Priority and Quality is a Standard. And for example, the primary rational coordinator of Accounting and Reporting is Rules.

Each part of the model is a part that has an independent definition and can be independently produced, implemented, tracked and changed. In putting all the parts to use, procurement and architecture and engineering are required to assure that they can interact in an appropriate way; while management controls assure that they probably will interact appropriately.

The explanation so far leaves two areas for further clarification.

First, the model shows four "parts" that are more like regions: Priority, Plan, Activity, and Quality. Many people may detect some similarity in this quadruplet to earlier models such as the "Deming cycle", so it is important to note that the terms in the Archestra model do not attempt to share the Deming vocabulary or any other. In the Archestra model here, 

- Priority refers to identifying and grading preferences, which logically precedes the other three terms as a management or "controls" concern.

- Plan is seen as step two, by which priorities are organized to be actionable with presumed resources.

- Activity then logically follows the plans.

- And Quality -- although it is always a target and likely referenced in both prioritizing and planning -- is not actually in the sequence until Activity has caused some output or outcome that must be held against the need for quality.  In a control model, the place of this last step is important because quality must practically pertain to all actuals, not hypothetically pertain to all possibles. In fact, a major intent of building controls to this model would  be to achieve streamlining and transparency of observations about each part, so that as little time as possible is required to get awareness of whether priorities and quality are aligned. Misalignment is dealt with by corrections.

Second, let's take one of the four main items just discussed, for example Quality: the model shows that two of its shared boundaries are Standard and Process. But what about the other two apparent boundaries -- Practices and Goals? Frankly, this may be a flaw in the visual representation offered. However, the intent here is not that the Practices and Goals arrows connecting Monitoring, Modeling and Accounting are boundaries. Instead, using Quality again as the example, Modeling is the primary referent for Quality, and if Modeling is to be able to succeed as the referent for Quality, then Modeling must be logically complemented by the definitions of Monitoring and Accounting. Likewise, Reporting (aligned with defined Rules and defined Events) is the primary referent for Plans. And so on.

Customarily, Archestra models offer "maps" to use for identifying defects, discontinuities, or other problems that exist in an already active environment. The model is an abstraction and can be taken prescriptively, but it does not assume that the actual environment is already organized as illustrated. The argument of the model is that its illustrated organization can comparatively expose an important disorganization in an existing actual environment, and help to promote the source of the disorganization to a high level of corrective attention.

 

Posted by Malcolm Ryder at 8:56 AM

June 14, 2005

Archestra Topical Framework

The purpose of the Topical Framework is to organize Archestra content as an explanation of how the "functionality" of the enterprise structurally relates to the strategy. In effect, it "reverse-engineers" the enterprise capability.

The architecture of strategy is based on the following idea.

First: every enterprise accomplishes its intents by taking four essential types of action:
- Model: design an idea in a form that explains its production
- Build: realize the model in a specific form that is practically applicable to operations
- Use: put the built version into live action
- Change: modify, "in effect", the idea through remodeling, rebuilding, and/or reassignment

Second: each of those types of action can be "strategically" significant in the sense that it can critically alter the status of essential constituent conditions that define the current enterprise capability. This includes five essential conditions:
- market position: the location from which effectiveness is predicated
- performance logic: the theory and method behind the successful exercize of distinctive capability needed in the market
- competency: the distinctive capability accompanying the motivation of the enterprise in its environment
- infrastructure: the constructed support facilities underlying the exercize of competencies
- ownership: the ultimately authorizing stake limiting the intent and scope of the enterprise constitution

Beyond planning, capability is expressed through execution, and execution is based on functions.

- Architecture creates "spaces" for functions. Neither just physical nor metaphorical, these spaces are actually the domains of the conditions structurally comprising the overall enterprise capability. Managing the domains creates the potential positions that the enterprise can take and leverage.

- Strategy creates "functions" for those spaces. Strategy proposes and directs the action that leverages the positions provided by the spaces.

The Archestra topical framework conceptually represents how the four basic types of action (functions) relate to the five primary constituent domains (spaces). In this way it identifies a universe of "touchpoints"; each touchpoint is a topic of study.

In real organizations, the twenty touchpoints influence each other, and therefore each touchpoint has both cross-domain and cross-functional "presence"... However, the framework argues that each touchpoint makes a distinctively critical contribution to the complete enterprise capability. The framework initially represents each touchpoint uniquely, with a representative label indicating the kind of requirements and decisions that distinguish each touchpoint's importance.

As used in the framework, the names of these touchpoints do intentionally reflect the usual objects tracked around the enterprise. However, even moreso, they identify a more abstract concept that is appropriate. This emphasis on concept explains why some of the names fit where they are shown. For example, while any particular implemented "system" (such as an IT application) might usually be thought of as an Infrastructure issue, the concept of "a system" is more important to consider, and here it is shown in the Performance Logic space under "Build", where it generically pertains to all kinds of self-contained structures for continuous rational interaction.

As the framework evolves, some touchpoint names may change, allowing improvement in representing the critical essence of the relation.

In the framework, each touchpoint in a space contributes to execution through a function, and it can be discussed in terms of how it pertains to the way its function is managed.

This issue of managing the functions (i.e., "practice")is detailed in the following way.

As affected by the practices, a touchpoint in turn impacts its domain and the overall potential of the enterprise capability. Archestra content can describe this chain of influence.

Posted by Malcolm Ryder at 2:53 PM | Comments (0) | TrackBack