One of the interesting BPM debates I’ve been following in the past months has been about the relevance of BPM technology standards such as BPMN and BPEL (with some protagonists claiming that BPEL isn’t powerful enough as a modelling or implementation language to express the richness of some processes; and others claiming that in fact it’s just fine – for example, see the online debate between Keith Swenson and Ismael Ghalimi. The issue of technology standards in BPM implementation is an important one, but what particularly interests me is what the debate says about BPM more broadly.
You see, in the “BPMN vs BPEL” debate the truth is that both camps are right, in their own way: BPM is a very big umbrella, under which a variety of specific technologies and approaches are sheltering. In some situations, BPEL is “the right tool for the job” – and in others, it isn’t. The world of business processes is far from straightforward. Not all business processes are created equal. Some are very stable and predictable; some are unstable and dynamic. Some are highly automated and procedural; others are very collaborative and focused largely on extracting and combining the tacit knowledge held in the brains of domain experts. The tricky question is, if BPM is an umbrella that’s big enough to shelter a number of very different approaches to software modelling and implementation, how do you know which technology capabilities are going to be important for you to invest in, and which are going to be irrelevant?
It turns out that the nature of the process improvement scenario you’re pursing will influence the technology capabilities you’ll need – not only in terms of the process implementation platform you use; but also in terms of the design tools that will be most suitable, and in terms of the monitoring and optimisation tools that will be most suitable. In other words, the kinds of processes that you’re looking to manage and improve will affect your technology needs right across the whole BPM activity cycle.When it comes to considering the kind of technology capabilities you’ll want to enlist in your BPM initiative, there are three process characteristics that stand out in particular that you need to consider which should shape your thinking: process lifetime, resources, and scope. Although there’s not the space to go into a lot of detail in this article, in the sections below I’ll call out some of the major factors you’ll need to explore.
Process lifetime
The instances of some business processes (think mobile telecoms service provisioning) typically complete within minutes or hours; whereas others can take weeks, months or even years to progress to completion (think insurance claims management). Organisations looking to improve the efficiency of short-lived processes are typically working in high-throughput environments; in these circumstances, runtime platforms need to be optimised to be able to scale efficiently, manage distributed transactions, handle errors semi-automatically, and so on.
On the other hand, when it comes to improving long-running processes that may execute for weeks, months or years, there are other additional factors in play. Many people understand that in order to support long-running processes it’s important to be able to persist process state, and manage compensating transactions (for when work needs to be “backed out” of a process instance); but there’s often more to consider. Specifically, the longer the lifetime of a process, the more likely it is that at some point, the structure of running process instances will have to be re-cast in some way – the paths that process instances will follow in operation can’t be completely determined at runtime. Some work might have to be re-done because of an unanticipated customer issue; work might have to be completely re-routed or re-planned because of a workforce reorganisation; and so on. In these circumstances it’s vital that both design tools and the runtime platform can enable running process instances to be arbitrarily re-shaped, in flight, without affecting either their operation, or the operation of other running process instances.
Process resources
The instances of some processes rely mostly on existing software applications to carry out process actions (good examples here are trading processes in financial services; order management in online retail environments; and so on). For other processes, the chief actors are personnel – they might be domain experts, or support staff, or a mixture. Of course it’s obvious that to support the former types of “system led” processes, robust application integration technologies need to be in the mix; whereas in the latter type of “human-led” processes, the ability to route, re-route and escalate work based on organisational models is crucial. These factors are important to consider not only in the runtime environment, but also in the design environment. How important is it that any human participants in your processes have “friendly” user interfaces in front of them when they carry out process work, or alternatively, is it important that people can carry out process work in the context of applications and desktop environments that they’re already used to using? The answers to these questions will have a significant bearing on the sophistication of the design tools you’ll need, as well as the openness of the runtime platform.
As well as considering the impact of human and/or systems resources on the way you improve and automate your processes, you need to consider the information dimension. In order for resources to take actions within a process, they (whether they’re automated systems or people) will need certain information to hand. In some circumstances, that information will be very structured and predictable (think again about order management in online retail). In other circumstances, large volumes of unstructured and hard-to-predict information will need to be accessed (think about the claims files that administrators will need to access in order to progress insurance claim, for example). In the latter case, both your design environment and your runtime platform should be flexible enough to interoperate with content/document management systems and be able to make use of complex, unstructured catalogs of information.
Process scope
Some processes are pretty restricted in scope – the resources required to see them through to completion are all “owned” by one team or department. For others, the picture is a lot more complicated – the “ownership” of the process might span departments, and might even span organisations (where suppliers and partners all need to contribute to a provisioning or scheduling process, for example). For processes where ownership spans multiple domains of control, there are a number of factors to be considered. How can you secure the process environment so that external parties can only play certain roles and see certain information, but still make it easy for them to participate? What if a partner or supplier wants to take control of the way that parts of the process work, but you still want to control “your” other parts – how can you federate the design, ownership and operation of the process? How can you provide useful metrics and other feedback to external parties, in a secure and controlled environment? Identity management and access-control, role-based monitoring and dashboarding, governance and process federation issues all need to be considered here.
Not all requirements are scenario-driven
Although many of the factors that will shape your BPM technology requirements will be shaped by the nature of the processes you’re interested in improving, as outlined above, there are other crucial requirements that should be in play regardless of the scenario you’re pursuing.BPM initiatives have to be able to drive and coordinate activity across many teams, departments, and automated systems throughout the organisation – it’s simply not enough for them to be limited to working within one department. To really deliver value, BPM technology has to bake analysis, monitoring and measurement of business activity right into the act of automating processes. And it has to actively promote the involvement of business specialists. To be truly valuable, BPM technology tools must possess all these characteristics.
