Products must reflect real issues, not suppliers' business goals
A process is nothing more than a series of events that takes place in order for a desired outcome to be reached. These events are inter-related in a manner that allows the desired outcome to be reached quickly and efficiently.
This inter-relationship is what business process management (BPM) sets out to achieve. But already we are seeing a new phrase entering common usage: business process optimisation (BPO). The optimisation of processes has always been a key element of BPM, and BPO is simply another acronym introduced by certain suppliers in an attempt to make gains within the BPM space. The question is which type of supplier will drive BPM development.
Enterprise resource planning systems may have succeeded in linking together functionally discrete elements of an organisation, but the cost (and not just in financial terms) was unexpected, or at least not clearly stated. What organisations got with ERP systems were "bland" processes. Certainly they may have reflected processes in place at design time, but what they failed to provide was an easy way to change those processes post-implementation.
This is precisely the same scenario as having processes locked into legacy systems. Whether one looks at legacy systems and their procedural code bases, or at more modern ERP systems, the pattern is the same: processes that are difficult to change. Having failed to deliver extended value, many of the ERP suppliers are now talking up BPO, taking these systems and the processes they contain and optimising the processes.
Optimisation is not the answer. Making a process more efficient, which can be carried out in any number of ways does not directly correlate to making a process more exposed. It is a relatively simple task to take a process, expose it for a period of time, make some adjustments by redefining the events or creating added parallel flows, then burying it again. What is less easy to do, especially given the architecture of many ERP systems, is to expose the processes and keep them exposed during process runtime.
If ERP suppliers are allowed to own the process space, all we will end up with are processes that are more efficient than they were when the systems were introduced. There is nothing within BPO from the ERP suppliers that talks to the need of change in a dynamic environment.
There is strong synergy between content and process. The events that go to make up an individual process are most often defined by their content. Process flows are highly dependent upon this content in two ways. Firstly, in terms of process execution, where the requirement for content allows the ongoing flow to continue. In this case, a process event will only trigger another event once the correct content has been attached to the event.
Enterprise content management suppliers could also lay claim to BPM ownership: the availability of content, or the actual content, can define which path the process takes. In this way the process definition can be based upon the content. As content can be seen as the fuel for the process flow, it makes sense for the content provider to own the process as well. Not so.
The next type to consider is the integration supplier. In truth, there are some integration technology suppliers that have strong claims. The future of BPM will be highly dependent upon the implementation of a service-oriented architecture (SOA). The ability to deliver and consume process parts, as defined in the web services model, requires an underlying architecture that facilitates this. This is where BPM in the conceptual sense and the technology to make the concept a reality come together.
Given this high level of synergy between the two, SOA suppliers could argue they are the natural owners of the BPM space. But which is the more important part of this duality in organisational terms? The SOA may provide the foundation on which BPM will work, but it is the processes themselves that are most important. In support of this contention, it helps if we understand what true BPM will bring to an organisation and how that might be achieved.
First, there will be the ability to change processes quickly. For this to happen, the process "rules" have to be exposed and exist independently of the process itself. This is not as strange as it sounds. Just as content needs to be served dynamically to the process at the point in time the process definition demands it, so too with the rules for the process runtime. If rules have an independent existence, they can be altered. This alteration will be reflected during the next process runtime instance.
Second, there has to be a design environment that allows processes to be defined with no regard to the underlying infrastructure. This is not simply a modelling exercise. The process definition designed within such a tool has to be directly translatable as an application. This application will not necessarily exist for a long period of time, and over its lifespan it may be altered in many subtle ways by its interface to the process rules.
Finally, BPM will allow linear flows to become more parallel in nature. This is highly dependent upon the implementation of a SOA. The more linearity that can be taken out of a process runtime, the more efficient that process becomes. Historically, processes have been implemented in a linear fashion, driven by the procedural languages that instanced them. Parallelism was created only in a minor way by the calling of sub-routines with programs. The complexity this created meant they were kept to a minimum. Processes driven on an SOA do not contain this inherent linearity.
Given these requirements, the contention would be that they can only be delivered by suppliers who put processes first. These suppliers need to understand the inter-dependencies that pro-cesses have with other elements of an organisational and technology infrastructure, and they need to demonstrate how their products address these interdependencies.
If BPM is placed in the hands of ERP, enterprise content management or integration suppliers, we run the very great risk of having yet another promise disappear into thin air. There is an historic context for this. The truly defining technologies of the past 30 years have come to fruition by having suppliers involved who understood the issues and who built products with a focus on those issues. Clearly, databases are a prime example of this.
This same focus has to be brought to the BPM space. It is easy to understand why suppliers want to extend their offerings to include BPM, and there is nothing wrong with this. What is wrong is to allow those suppliers to subvert BPM to their own ends, to shape it to fit in with their technology. If this is allowed to happen, BPM will not become the defining technology we all desire.
Mike Thompson is principal research analyst at Butler Group
This was first published in December 2004