" />

« Data, Dictionaries, and Organizational Performance Alignment | Main | Managing knowledge about Knowledge Management »

May 26, 2005

Business Process Management and Organizational Architecture: a performance ecology

This month, Gartner Group research chief Peter Sondergaard outlined the top emerging issues in Business-IT management, by identifying the already driving needs to:
"...foster greater business agility, to promote quick build-up and tear-down of business partnerships, to facilitate adjustment and deployment of resources where needed and to render harmless approaching danger well in advance of that danger's arrival," Sondergaard said.

We're accustomed already to the idea that processes must be readily modifiable to keep up with changes and risks. But a closer study of Sondergaard's statements yields two other survival requirements:

(1) repositioning and security capabilities: this will require a mature "sense-and-response" ability that exploits forecasting.

(2) re-organization capabilities: this will require a mature ability to "re-compose" the organization by exploiting a model of it components.

In a nutshell, a form of organizational architecture must drive suitable types of readiness.

Meanwhile, business processes will remain the delivery vehicle for the operational impact that creates business value. To users of a process, the process is virtually the organization... But forecasting and organizational modeling determine whether the business process executes effectively -- that is, in the right direction and at the right strength.

Said differently, processes execute with critical "ecological" dependencies on their environment.

This dependency can be described from two viewpoints. In one, any process is essentially a "behavior" of the organization that enacts it. In the other, the process is a "user" of the organization that hosts it. Either way, to modify a process and obtain effectiveness, the organization that enables the process must successfully adapt as well. The issue is to determine the nature of the necessary adaptation. Is it repositioning, reorganization, training/maturation, or a blend?

The more frequently or continuously processes must be changed to meet requirements, the more explicit it is that the logical purpose of a process is to "map" the current requirements to the current functional capacity of the organization. In this view, "successfully" adapting a process to changing requirements means that changes of the underlying organizational structure must keep up with or even precede changes of the process. (The lessons we have already learned about mapping requirements to organizations come from project management and product management, where the organizations are often shaped and managed specifically to conform to fulfillment of the new requirements.)

Here, it is important to see organizational "structure" as a configuration of functional capacity. The purpose of the organizational structure is to deliver the capacity, and the purpose of the process is to leverage the capacity.

Usually, the chosen configuration will be selected according to criteria of cost, risk, availability, scale, stability and durability. But those attributes really describe outcomes of the organization-in-use, as enabled by the interactions of its elements. To recombine the elements and predictably obtain the same (or acceptable) attributes, the elements must be identified in terms of the properties they are known to exhibit in interactions.

In powering business agility, forecasting and modeling are both going to be based on those interactive properties of the elements, which comprise the business' operating environment.

Organizational building blocks

The type of understanding that will exploit elements defined this way is akin to both chemistry and meteorology.

Chemistry is an especially compelling metaphor: we already recognize that preparing a chemical "reaction" is precisely how we proactively develop the solution impact that we seek. It emphasizes that the structure (i.e., the chemical composition, the "organization") hosting the reaction is the driver of the reaction, containing within itself the potential and also sometimes the catalyst. Accordingly, the prescriptions that are developed by a chemist reference what is known about the interactions of the chemical elements, to compose the offering. Similarly, we are entering an era that calls for organizational composers, working with or without automated help...

Meteorology is also a compelling metaphor because of its constant analysis of the environmental dynamics. Meteorological analysis accomplishes tasks by means such as distinguishing weather "elements" from weather "factors", by determining what underlying elements are interacting, and tracking how they are interacting when certain dynamics occur. The interactions of elements are factors; factors combine to produce dynamics; and systems of dynamics produce the common high-level weather structures.

Abstracting the components of an environment or state such as the weather, we might identify:
- Structure: a seasonal climate
- Dynamics: a rainstorm, tornado, wind current, etc.
- Factors: a high-pressure system, cold front, etc.
- Elements: air, water, heat, etc.
Although we still can't control the weather based on what we know about it, we understand much about the near future weather because this analytic discipline helps us to model it and forecast it in advance.

Decomposing a business's internal organization this way, the business can then plan for the organization's states or behavior just as we might plan for the weather's, and exploit reorganization. Likewise, decomposing the external environment of the business helps with making decisions about where and when we can best "locate" ourselves to accomplish what we need or want, repositioning as needed.

Process architecture

Linking elements to factors to dynamics to structures is an abstract design technique. It can produce architectural models that are:
- the prescriptive composition of the business organization; this addresses the need for a re-organization capability
- the projected state of a business environment; this supports a repositioning capability.

Here is a diagram about composing an organization:


The picture gives an example of the many-to-many relationships that build up an organization, from assets to resources and so on.

In effect, a running business process issues requests that must intelligently "invoke" a certain configuration of these relationships during run-time.

The "intelligence" includes rules, permissions, and qualifications of various kinds. At run-time, if new items have entered the picture or earlier ones have changed or left, some of these rules, permissions and qualifications might need to be discovered on the fly, to assess and accomodate the differences from expectations.

The same approach can describe external environments as well as internal organizations; for example, a market space might be decomposed into:
- (structure) channels and partnerships
- (dynamics) campaigns and contracts
- (factors) products and services
- (elements) features and property

This market decomposition would exhibit the same many-to-many relationships of one tier's items to the next tier, whether going up the hierarchy or down.

Process-driven architecture

Leveraging that architecture, a business process requests a real-time configuration of an organization. The process always anticipates the potential for effectively exploiting the organization to meet the expected current or future state. But that anticipation is not always satisfied.

As business process management(BPM) increasingly centers itself around a business analyst role (performed by a manager or other employee) and expands that role across functions, it also extends itself into a request-management function that wants to ensure the satisfaction of the request with available and approved resources.

The key challenge in the request management effort is to determine whether the request can be satisfied through an existing organization or must be through a "reorganization" that makes acceptable resources available. The challenge for the analyst is to get the process to make the optimal number and type of requests in the available environments.

If a reorganization is suggested, it is likely not permitted until the request has been assigned a priority that effectively authorizes the reorganization for the request. (This prioritization typically comes from strategy and performance management.)

In this scenario, "orchestrating" resources brings selected factors into play, enabling the dynamics that a process attempts to manage. The orchestration is the virtual real-time organization. In effect, the organization becomes a resource agent for the process. And that orchestration comes with scale and scope issues that must be assessed for their implications in cost, risk, stability, duration, etc.

Which came first: the chicken or the egg?

BPM is evolving (expanding)into a complex of practices within which the design of the process prescribes a solution for the delivery of business outputs, and that prescription requests a fulfillment through organizational functions.

In that way we can say that the targeted process catalyzes the organization. But at the same time, those prescriptions are speculative without knowledge of the organizational potentials, and speculation is a risk to business efficiency and effectiveness.

Necessarily, the attending organization may be a "just-in-time" organization derived through bidding, collaboration, or the standing availability of a qualified outfit (whether internal or external).

What's especially important to note is that the criteria for selecting or composing the organization should effectively function as architectural standards looking for compliance by the actual organization that winds up engaged with the process.

These ersatz standards must be validated against evidence of the business' tolerance for them. We can't always get what we ask for, and we have to be careful because we might get it!

Why "architectural"... ?

By demanding certain combinations of cost, scale, scope and duration, the criteria effectively specify what capacity can be expected from given organizational (structural)configurations. The business must agree to those expectations, or seek sufficient capacity through whatever means available. The issue is whether the specification is too constraining or not.

In that way we see that architecture is actually what is being exercized. Far better that this is understood from the start than to encounter it as a barrier. The challenge is to apply architectural discipline proactively, yet in a manner that is calculated to maximize the ability of processes to obtain the organization that they need on demand.

Posted by Malcolm Ryder at May 26, 2005 9:25 AM

Trackback Pings

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

Comments

Post a comment

Thanks for signing in, . Now you can comment. (sign out)

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)


Remember me?