« Making space for Strategy | Main | Who is IT's customer? »

May 18, 2005

Strategy versus Change, and the battle for Agility

Now that we're used to the idea that change is the number one challenge to a company's business performance, it would seem that strategy and change compete for the right to dictate priorities.

Business intelligence vendors go so far as to say that "managing change" is the top survival skill of a business. But the meaning of this is typically specified just as Business Objects puts it in their white paper on enabling business insight: "...organizations, plans and management theories don't accomplish anything directly... success lies in making each person as productive as they can be..." -- which means "to make the right choices among their daily decisions."

The most important aspect of that idea is that the point is not to make the same choices correctly and repeatedly, but to make the right choice each time.

What we could be seeing is a gradually forming understanding that productivity and agility are two views of the same thing - effectiveness:
- productivity being the view that describes resource-effectiveness, and
- agility being the view that describes process-effectiveness (as supported by productivity).

This proposes the logic of responding to an appropriate awareness of change. If timely information about new states can be input to people's decision-making on a continuous basis, the actions driven by those decisions become the life of the processes that drive the company. Ultimately, the process behavior is the output of the linkage between the people and the process.

Given "inputs" and "outputs" as just described, it seems that the people-process link can itself be treated as a (processing) system.

But there are caveats: the inputs are only meaningful to the extent that they are actually usable, and the outputs will of course be subject to tolerances that the business either mandates or discovers within its idea of "business-valuable".

That means there are three stages of management involved in the progression from the initial awareness of change to the business response provided:

- information modeling...
- followed by decision support...
- which is followed by policy compliance.

But this description still leaves "successful" decision support as either a wishful assumption or as a "black box". What's the related caveat? A decision is a micro-process, so to speak. The question is, in that middle stage, how do we organize decision-making so that it actually effects a dynamic alignment of new changes to previous objectives?

To get through this problem, the first step is to think about decision management.

Decision management would mean that the types, distributions, and timing of decisions would be defined and controlled throughout their lifecycle, with alterations made according to the demonstrated patterns of value generated from their current setup.

One useful analogy for understanding what this means is asset management, in which a collection of assets is categorized, inventoried, and tracked throughout their distribution into a user-population according to ownership, location, and occasion of actual use -- from the birth (acquisition) of each asset to its death (disposal). At a given moment, the condition of all these assets can be mapped, and that map can be used to establish correlations of asset distribution against economic impacts. These correlations tend to be used along with allocation histories to establish recommendations, permissions and standards for the use of the asset.

By analogy, each type of "decision" is an asset, and it may be "owned", "allocated" and "utilized" in various ways over time.

What controls decisions?

This perspective on decisions gets into the issue of what the organizational chart looks like, insofar as the orgchart might map how responsibilities and authorities are mixed, matched and bundled around the enterprise.

But (due to the analogy) we're also considering the aspect of "recommendations, permissions and standards" being applied to the decisions. Here, therefore, it makes sense that we'd look into what is considered to be an "acceptable decision" -- acceptable both in terms of how the decision is made and regarding what the decision addresses. The subject of the decision would represent some point or issue of "business value" that makes the decision important to have and use in the first place. That is, the decision will address the subject, but the subject actually validates the need for the decision.

Thus, if we take the subjects of all the decisions being made, and we map them out per their interrelationships and impacts, the subjects map should look like a model of value-capture -- or in other words, like a strategy.

This is pretty much what is presented by many "strategic performance management" solutions today, which offer a strategy map that is decomposed into objectives, their supporting (underlying) performance targets, and the initiatives that secure prioritized achievement of targets. It makes sense that these are, in fact, the "subjects" of business value-capture. Decisions and actions go on to address those subjects.

But that's only half of the picture...

"Business processes" present a different view of action-requirements that drive decisions. The processes are modeled to operationally coordinate resources and actions around specified events that have defined business value. But the events are mainly transformative ones, representing a prescribed change to the state of some environmental condition or some relationship.

If we take the desired states that all the processes are pursuing, and we map them out per their interrelationships and impacts, the states map should look like a model of the operational environment -- or in other words, like an ecosystem.

This leaves us with the challenge of reconciling the two main models -- strategy and ecosystem. This reconciliation, which needs to be continuously produced in real-time, is the essence of "alignment".

Managing alignment

So - regarding change: if decision-management is the people-process linkage where alignment takes place, and there are inputs and outputs regarding alignment, then how can we manage the alignment as a dynamic process? The answer we decide upon will be the real basis of the agility that otherwise is presupposing productivity.

Finding the answer means understanding why environmental states change, and what to do about it.

Along with that, the really big issue to consider is this: what happens out there that makes the business "change the subject?"

Here is an approach that deals with both issues.

Let's position the business model as the principal client of all operations. The business model makes judgements about whether it has different needs now than it did before. In effect, the business model (not something else) changes the subjects.

If it has new needs, and then requests follow-up action to them, it looks to business processes to conduct the fulfillment of the needs. The request that it makes will describe what kind of conditions need to prevail, and this will indicate both a difference from current states and a priority for achieving the difference.

Processes will see the requested difference as the result of events that should now occur, and the processes have to "configure themselves" to execute the events that generate the desired future states.

The requested priority will mean that some configuration options are viable while others are not. Therefore, some "intelligent rules" will need to be imposed on the real-time configuring of the process. The source of these intelligent rules may range widely -- from historically successful habits, to negotiated policies, to analytically discovered recommendations. (This is entirely typical of a change management procedure.)

Meanwhile, a risk-lowering condition is that multiple processes could "collaborate" to "orchestrate" the appropriate event-support, which means that one process will not be burdened with singly covering the huge variation that can occur from one request to the next. Here, there is evident need for a "broker" that can acquire and coordinate the support on time. The source of this brokering can range widely -- from contracts, to service agents, to discretionary managerial intervention.

We've seen it before

Think of the business model as a client with a portfolio, who decides to change contributions or investments -- from one part of the portfolio to another part, or from one level to another level within a part. Operations should respond to that decision by acting through rules and brokering to adjust the portfolio to the client's current needs.

An Enterprise Performance Portfolio segments business model needs into areas for operational attention applied and adjusted in real-time by rules and brokering that engineer process workflow for targeted, risk-managed fulfillments of business model demand. This links business strategy to the business ecosystem, facilitating agile response to change that translates resource productivity into business performance.

Posted by Malcolm Ryder at May 18, 2005 3:34 PM

Trackback Pings

TrackBack URL for this entry:
http://www.malcolmryder.com/cgi-bin/mt-tb.cgi/47

Comments

Post a comment