Business processes change. Frequently. For years, IT departments have had to try to adapt business applications to support new procedures as they are developed. But with budgets falling, business processes becoming more complex and real-time, and computer systems pervading every level of the enterprise, IT directors need to find ways to cut down the amount of time and money spent adapting the underlying systems to cope with change. Many are now looking at business process management (BPM) as a way to meet the challenge.
At the highest level, BPM modelling tools enable companies to model their business processes, systems, resources and organisational hierarchies. The models are similar to the flowcharts used by most programmers and many business people and break each process into a series of steps that allocate resources and require people or systems to make decisions or perform functions. The model can take account of processes that activate in response to specific events or the reallocation of resources if a person or system is unavailable.
BPM and workflow management systems then manage enterprise applications directly from those models. In theory, as the processes change, all companies have to do is make a few changes to the model and this will modify the systems accordingly.
Workflow interchange
Naturally though, there are limitations to even the most ambitious BPM system. While it is relatively easy for computers to notify employees about their workflow commitments using email and other communications technologies, notifying other systems and instructing them is, paradoxically, a harder task.
To give applications instructions as part of a business process, BPM systems need to be able to communicate with those applications. Some applications, such as SAP, have their own workflow systems with which other workflow applications can communicate. Other applications have interfaces that BPM systems can access using their own technology, web services or enterprise application integration tools.
If an application does not provide an interface, as is the case with many bespoke applications, corporate developers will have to add one. But this integration cannot be just the ‘hardwiring’ to the application of an interface based around the current business process, as the first time the process changes the interface will have to be rewritten. Integrators need development tools that can read the business process models created by BPM systems if they are to keep up with changes in processes.
Unfortunately for both users and BPM vendors, there is no single standard for defining business process models. This means that unless the development tools or other workflow management systems speak the same modelling language, each needs to be reconfigured using its own tools whenever a business process changes.
“Workflow standards would be implemented widely if vendors had good reasons for doing so,” says James Kobielus, an analyst with The Burton Group. “Workflow vendors differentiate themselves competitively on the depth, sophistication and flexibility of their tools and platforms. No standard workflow languages match the complete functionality of high-end workflow vendors’ process definition features – and that’s by design. These standards support a bare common denominator of workflow design features, which keeps vendors from adopting any one standard widely and also spurs new vendor coalitions to develop new standards to address deficiencies with existing standards.”
Process polyglot
Business Process Modeling Language (BPML) is an attempt to create a standard language that meets the requirements of workflow systems. It claims to be able to describe workflows for any vertical market, be able to incorporate other workflow languages, and exchange information about business processes with other systems. It is XML-based, so while it is human-readable, it is hard to generate correctly without computer assistance. But since there is no standard graphical notation for it as of yet, the few tools that support it have to use their own modelling systems to create it. Nevertheless, it has backing from both the Workflow Management Coalition and the Business Process Management Initiative, two of the main standards bodies.
A more fundamental issue for its adoption is that few users are demanding standards for integrating vendors’ workflow tools. Companies generally implement workflow products for particular applications, not for their entire system infrastructure. If BPML is to work, it needs more vendors to adopt it as a way of exchanging business process information. And if that is to happen, customers are going to have to take the lead.
BPM systems can certainly save organisations time and money. Departmental workflows can be made responsive, easy to change and highly automated. It is going to take pressure from users to force vendors to commit even more to the implmentation of standards.
