Saturday, August 05, 2006

The Problem with Processes

Businesses, in their planning and design activities, have a tendency to envisage the world as a set of neatly ordered, well-planned, pre-determined and sequenced set of activities. This approach sets out to ‘decompose’ these models into highly detailed descriptions of all the interacting parts within an ‘end-to-end’ process. This process-centric approach often falters when it spans departmental or external boundaries .Why? Because it is hard to capture and represent the softer, but often, more knotty problems associated with differing business values, politics et al. This appears to be at the root of the problem business face as there operations become increasingly diverse, dispersed and generally, more complex.

Such an approach promotes a high degree of engineering rigour and, by necessity, complexity that is, by nature, hard to consume (particularly by the business decision makers and the end users). The sheer volume of information produced means that the overall business context gets lost in the production of engineering wiring-diagrams. This approach is often blind to the real-world behaviour and human interaction ‘on-the-ground’. Often the focus is slanted towards process and organisational How than the business What.

Business are a tangle of Behavioural Threads

The reality is that most businesses are more organic and random than pre-determinable and mechanistic. Many of these Threads of behaviour work very well without top-down design – the folk on-the-ground are just simply good at getting-the-job-done and they often make things work despite unhelpful top-down processes, procedures and systems. This is the world of Post-It-Notes, spreadsheets and personal networks. This thought might lead us to believe that businesses must simply throw our hands up and just accept a more fatalistic and unplanned approach to running the business – a cross-our-fingers-and-hope model! Perhaps, however, there’s another way to grab back control by taking a slightly more abstracted but at the same time, real-world aligned approach.

Threaded Beads - Perhaps then it would be useful to think about “Processes” as a series of more abstract themes or “Threads” of business behaviour that run in all directions across the business enterprise. Each Thread is made up of ‘Beads’ of Capability or Service that are triggered by real-world events that undertake specific tasks and deliver interim of final outcomes.

Threads & Beads operates under differing sets of Values (Business Principles, Desired Outcomes, Drivers & Goals)

Each Thread has a set of guiding values around a specific business mission. Each Bead along the Thread also operates under a set of specific values. For example, a particular Bead might be implemented as service from a 3rd Party and will therefore inherit a set of values from outside the enterprise.
Sometimes one set of overall Thread values may conflict with another set. For example, the ‘Retail Distribution’ Thread and the ‘Oil Exploration’ Thread of a multi-national Oil comapany may be shaped by very different and, in some areas, conflicting values.
Values drive behaviour and motivate people and systems towards desired outcomes. Changes in the priority of values in combined sets can have a dramatic affect on the results. Perhaps a technique for c
apturing, analysing and managing multiple interacting Value Systems is needed?


Threads can cross paths and share or otherwise interact with Beads.. So a single Bead may need to function within the context of multiple, and some time conflicting, overall Thread values. Many business are focused on removing duplication and improving agility which is leading them to initiate efforts to discover candidates for, and embark on the design/implementation of, shared-services (both human-based and/or technology-based). Understanding the nature of these joins and unions is at the heart of this work.

Beads aren’t evenly spaced along the Thread

The relative degree of binding (joined-ness) between one Bead is often implicit inthe enterprise’s functional (Org Chart) or Operating Model. However, making this degree of linkage between one Bead and the next more explicit seems to be an important input to business decision making. Put this in the context of a world where third-party services play a more active part in overall business operations.

This thinking comes, in part, from looking at the pros and cons of Service Orientation. That is, the degree to which it may make sense to truly Service-Orient aspects of business operations, thus avoiding the “Lets-Service-Orient-Everything” pitfall.

Policies (The broad range of mandates and agreements such as Internal Policies, Law and external Contracts) apply across varies parts of the Thread – sometimes along the entire Thread and sometimes to a specific Bead or sub-set of Beads.

Events stimulate activity along the thread - sometimes in a predefined sequence but often not. Records of events can create an audit trail of the Thread and maintain the state of long-running business processes.

Content (e.g. Documents, conversations or messages) is produced and consumed along the length of the Thread. The ownership and rules that determine use of Content change during execution which, if not made explicit under Policies, can compromise information privacy and protection requirements.

Make Trust Levels Explicit

The amount of Trust along a Thread varies – this is influenced by many and varied soft factors such as: experience, relationship maturity, relative value of the service or competency.






Trust-based relationships are vital to
implementing relied-upon services from external providers. And the measure of Trust/Risk ever more pertinent in a world of regulatory control where accountability doesn’t necessarily reside with the service provider.

Is it not reasonable to believe that the measurement of the degree of Trust should be an key indicator on the CEO’s Dashboard?

And with the ever increasing information sources (fuelled by the Web) and the risk of misalignment of semantic meaning in a federated wor
ld, is it not also necessary to capture and manage the degree of Trust associated with such sources balanced against the degree of business risk?

So What? – Making Sense of The Tangle

The multiple Value-based contexts in combination with the dimensions of multiple policies, events, content & trust profiles are not sufficiently covered in process-based thinking or, the intrinsically hierarchic, enterprise-based business models (e.g. Org Charts and Operating Models).

Perhaps, with a perspective that puts these aspects front of mind, it would be possible create more realistic (actual-behaviour-aligned) models of historical, desired and run-time operational behaviour. Might, this in turn, provide the insights necessary to make more informed decisions around the alignment People-Process-Tec
hnology in the mission to deliver more agile, effective and efficient (and therefore competitive) business operations?

In a world where more activities are undertaken outside of the ‘four-walls’ of the enterprise and the need for ever tightening regulatory controls… Wouldn’t such an approach be necessary to manage business risk?

6 comments:

Tom Rose said...

Excellent thoughts! I believe you are correct, as the processes themselves are not rigid, and when trying to model them as such, its almost impossible. People are event driven, non-deterministic, and goal driven. Hence why we always have more exceptions to the process than use of the process, or perhaps more critically reuse of a process. The class of expert agent based, or case based reasoning systems are the answer, however, are complex, and dificult to wrap a persons thought process around. Today I think we successfully model business processes, not so much in terms of the process (how), but series of ordered goals (what) has to be done. How it gets done is really an unknown. I agree if we really want to optimize the "How" of business processes, it will take utilizing the expert systems to model, define, and analyze behaviors. I think we just now have at our disposale the computing power required to start utilizing expert system approaches in normal buisness operations. Fortunantly, there are decades of research and implementation on these type of systems that can be leveraged for a new class of business tools.

Tom

Nigel Green said...

Thanks for the post and the link Tom. I look forward to future discussions. Interestingly, we both seem to have a background in the RFID and agent space - I think you might find what my ex-colleagues at www.viagents.com are doing interesting.

Adrian Apthorp said...

Nigel, again I think we're talking about the white space. Not between applications but between parts of the business (a la Rummler Brache).

Picking up on Tom's point regarding the way in which processes tend to be described I agree that this tends be a rather 1 or 2 dimensional discussion, which leans toward top down design.

In large organisations you can not expect top down design to cater for every situation and variation due to scale and different local conditions. You therefore have to take a different approach to acheiving the emergent properties (the value deliverying processes) that you're looking for. As Christopher Alexander put it

"If you want to make a living flower, you don't build it physically, with tweezers, cell by cell. You grow it from a seed."

Taking this approach two things are required:
1) The rules and standards that need to be complied with.
2) Incentives to conform to those rules and standards.

These areas seem to correspond to your notions of policies, trust and values. Depending upon the type of organisation the incentives will take different forms and may result in conflict (e.g. local vs global profit).

Content is important in terms of the standards for what is passed along /is transformed by a thread.

I wonder if the basic systems engineering principles of modularity, coupling and cohesion can be applied? What makes an organisational unit? Cohesion of what and coupling of what? Traditional 'engineering' type approaches tend to focus on process and data. I think you're expanding this in to the area of motivation.

The following couple of links may provide some additional insights

The Cynefin Framework

http://www.agilearchitect.org/agile/articles/order%20and%20unorder.asp#References

Impact of service-oriented architecture on enterprise systems, organizational structures, and individuals

http://www.research.ibm.com/journal/sj/444/bieberstein.html

Chris Bird said...

I very much like the threaded beads analogy. There are indeed many conflicting threads all responsding in different time frames to the same "events".

There are almost always three kinds of threads to be thinking of. They are, what is the flow of goods? What is the flow of information? what is the flow of money?

So when teasing the business architecture apart, we want to know when one of these threads impinges on another. For example when we can recognize revenue (a money event) for a service provided (a goods or information event). In the VPEC-T model, these event interactions are indeed Policies.

We do have to make the assumption that all the threads operate asynchronously even when they deliver events to each other. Just because an operational "system" notifies a business event does not mean that other threads that need to be aware of the event are in a position to do their part. It is only when the threads have to come together (by policy, to enhance trust, etc.) that we need to place explicit process around the events.

Howard Smith said...

I think that poking at processes in this way is somewhat missing the point. If you want a process to execute it needs to be defined. But even here, process systems these days tend to support rich semantics for asynchronous interactions. It is quite feasible to model the kind of processes you are speaking of, and still execute them in computer systems or simulation tools.

Nigel Green said...

I'm afraid I think starting from a 'execute a process' PoV misses the point of this post. Of course, as you know, I'm not anti-process per se (that's like being anti-air!) - my point is that we need to recognise the variety of processes that exist within an enterprise. Some will never be 'executed' but all might need to be visible, for example. I see Events as both bread-crumb trail and actionable DNA of a process.

It's good to see you are as feisty as ever Howard.
n.