« Architecture and Strategy | Main | More on "Great Management versus Great Strategy" »

June 26, 2005

Can Collaboration Improve Processes?

Processes live on the communication of critical information about events. Can collaboration do for processes what infrastructure does for systems?

We normally rely on "process" to maximize our chance to leverage a perceived opportunity. Yet sometimes the process doesn't get the job done for us. A mismatch of some kind occurs between what the process can deliver and what satisfies the requirement of the situation.

Knowing that can happen, we've all had moments when we could use some extra help, but the help that was available wasn't the help that we wanted, and we faced a trade-off. At times like that, our instinctive aversion to risk often overrides the willingness to change for gain -- and either we fall back on an existing substitute approach or we let the opportunity go by.

In the parlance of value and performance, that's a comparison of opportunity cost versus effectiveness. At the trade-off moment in the scenario, we're "forecasting", not experiencing, both sides of the trade-off -- pain versus gain -- and this means that the expectations we form become the virtual reality to which we respond. We pin our sense of "effectiveness" on the expectation, and the risk is that we'll therefore underachieve.

Effectiveness is really a measure of how well opportunity has been exploited. But because our ability to assess opportunity cost shapes our perception of opportunity itself, it changes what we think we can do. Consequently, that assessment ability is actually one of the decisive terms of our probable ultimate effectiveness.

What does this mean about process? When we feel that we need help beyond the current process, we are usually thinking either that:
- the process requirements are beyond our own range of ability, and/or...
- the opportunity requirements are beyond the range of the process.

It follows that when our operation is hampered by either of those problems, the two main types of help are:
- bringing added execution capabilities to the process; and
- supplementing the process with "more processes".

What we have to realize is that in either of those two cases, something other than "process" might be the missing piece of our effort. How does the missing piece change things?

The essential purpose of a process is to make causality manageable and practical. But in order to get effectiveness from this, the results of the management must be relevant to the occasion at hand. The occasion asks the process to make certain things happen, and the process must leverage available resources to generate appropriate results. The available resources are, in effect, the environment of the process.

This is similar to the relationship between a system and its infrastructure. A system manages the interoperability of components, but this succeeds only because the system can draw on an underlying infrastructure that supports the system's functions. The infrastructure is the "environment" of the system.

Improving the supporting environment can add more execution capabilities. This can be approached in two ways:
- enrich the environment so that it offers more choices that are useful to the process or system; or
- optimize the environment for a particular process or system.

In the case of processes, how is that done? Looking under a process, the main visible infrastructure elements are knowledge, instruments, agents and rules.

Knowledge: brings the ability to proactively determine the likely impact of choices and conditions

Instruments: bring the tools appropriate for making decisions and for manipulating conditions based on decisions

Agents: bring the positioning and skills necessary to leverage conditions towards targeted states, primarily through use of the instruments

Rules: bring the terms of acceptability for types of actions per condition.

Systemically blended, the four elements create a process component that can convert a defined type of input in a predictable way. Correspondingly, because the conversion is predictable, the output may also be predictable.

But the essential responsibility of a process is to do the input conversion in a certain way, not to generate a uniquely specified output.

That sounds wrong, but we know it is actually true -- because experience has already shown that for us to obtain a specified result our own current processes are not the only way:
- there is "luck";
- there are alternative processes; and...
- beyond luck and process there is "service", where someone else handles the issue altogether in a way we are not responsible for...

The main reasons we use processes ourselves, with the responsibility for their output, are:
- to minimize uncertainty, and...
- to maximize autonomy.

Thus, if we run into a process deficiency, and we need to improve effectiveness in the face of the pain-vs.-gain trade-off, then certainty and autonomy are at stake.

In general, infrastructure supports the process vis-a-vis uncertainty and autonomy.
- For minimizing uncertainty, infrastructure features "configuration" that assures conditions critical to relating targeted events internal to a process.
- For maximizing autonomy, infrastructure features management control of the resources needed to maintain the components of the process.

With those effects, the process assurance fortifies its permission to execute -- a privilege often dependent on whether the infrastructure is tolerated by the customers and sponsors of the process. (For example: some consumers won't authorize delivery through ground transportation; some programmer/analysts won't authorize processing through a certain database management system; some messengers won't authorize transmission through a certain channel; etc.)

This is the context in which we should consider the prospect of collaboration as an "improvement"...In terms of processes, will collaboration have to help minimize uncertainty, maximize autonomy, and leverage permission?

The key thing to keep in mind is that the goal is to improve the effectiveness of the process, not necessarily to change the process itself.

By improving the environment of the process, its effectiveness can be improved. Collaboration can improve the process environment by making the management of resources better for the process.

By definition, collaboration means that two parties are working together (co-labor). In using collaboration for process effectiveness improvement, the point of the collaboration is to have the different parties each become part of the same process by their literally "co-operating" the process towards the given goal.

Defining responsibilities is a critical part of designing systemic co-operation. This design directs how the underlying elements are blended to generate the process components. In this co-operation, collaboration specifically begins when the roles of individual parties are accountable for the elements that make up process components: knowledge, instruments, agents and rules. Responsibilities then relate the roles to each other as a "process infrastructure".

To increase effectiveness, collaboration can attend to supporting multiple processes, and/or it can support optimizing any given process to certain requirements.

In particular, process optimization refers to the process being able to dynamically select and orchestrate the best resources for operating against real-time requirements. As a managed activity, collaboration is part of that orchestration.

By leveraging the availability and scale of a larger community of resources, collaboration produces an infrastructure (i.e. functional environment) in a way that allows the process valuable freedom from customary constraints of resource availability and scale that otherwise might leave the process short of capability to fulfill real-time requirements.

Posted by Malcolm Ryder at June 26, 2005 6:41 AM

Trackback Pings

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

Comments

Post a comment