Business process management (BPM) is still a young area,
with new products and technologies.
As with any new computing market, there are dozens of suppliers
of pre-existing products who are rebadging them as BPM software.
Sometimes this is reasonable, with the basic abilities of the
product matching most of the criteria for a BPM application.
At other times it is done on the basis that there is "one born
every minute". The stance of these suppliers is that if they say it
loudly and often enough, people will believe their product is
suitable for BPM. This is cheaper for them than building something
new or re-engineering the existing product line. It is the sort of
thing that happens whenever a new market emerges: you need to be on
your guard against it.
Among the major changes confronting users and designers of BPM
systems is the rise of service-based approaches to computing.
The way organisations manage their business processes continues
to evolve. Many have workflow and electronic data management
systems. Today's solution is to combine the basics of these with
system integration tools and activity monitoring to give BPM
software. Process management systems are now entering a third
stage, which is about managing computing services and orchestrating
them.
Computing services allow programs or entire systems to call for
or provide services to other programs and processes. To take a
simple example, the graphics part of a word processing program
might send a command to a printer or retrieve a piece of clipart
from storage.
A resource could be on the same machine, on the same network or
separated by the internet. Working like this over the internet is
often called web services. This uses XML and other standards to
define its components. The rise of middleware and the emergence of
the internet as a computing infrastructure have made this move to
web services possible.
Whether communicating through web services or some other method,
service requesters and providers should each be indifferent to
where the other is. The requester simply sends out the call and,
provided it is valid, the provider responds to it.
This kind of arrangement is known as "loosely coupled
computing". In this, a program always communicates with the same,
known resources.
There are, of course, many ways of defining how different
programs and applets communicate in a loosely coupled arrangement
or architecture. Inevitably, there is hot debate among their
adherents about which method is the best. These debates do not
concern us here. They are conducted at a high technical (and
emotional) level and change almost weekly.
Corporate computing is thus increasingly a matter of connecting
various computing service providers with requesters. This is
changing the manner in which organisations deliver business
services to their customers and interact with their suppliers,
partners and employees.
Orchestrating these programs and services has become inevitably
more complex. Higher levels of mass customisation and
personalisation at websites demand a widening range of choices and
interactions. Also, the technical environment is no longer the
closed and controlled system long familiar to IT departments. It is
open, unpredictable and rich with exceptions.
The result of these innovations is that organisations using
these loosely coupled arrangements are no longer in direct control
of the services other organisations provide.
Failures in delivery or processing, incomplete information and
unanticipated responses are now the norm rather than the exception.
Efforts to develop high-value application programs in this new
business environment have proved mainly to be:
- Costly
- Hard to change and extend
- Hard to validate
- Susceptible to failures and exceptions
- Unable to grow easily (scale)
- Unable to deliver the expected value.
From a technical perspective, workflow and BPM both provide
users with a process architecture that has well-defined initiators
and participants. Processes can be "workflow enabled" and made up
of reusable sub-processes. Organisations can encapsulate the
underlying process logic in a readily understandable way, which
helps them become responsive (agile) and adaptable (flexible).
The newer approach, of orchestrating and managing services
rather than programs, involves creating a service oriented
architecture. This separates the what (process and metrics) from
the how (resources provided by events and managed services). In
short, processes become managed services. These can be loosely
coupled, component-based and usable on various kinds of computer
and operating systems. Above all, they become reusable.
Organisations need something to co-ordinate the interworking of
all these reusable process elements. We call it the process event
manager. This will take charge of, and synchronise, the way process
components are extracted and linked to meet a specific process
need. It will do so according to user-defined process templates
that reside within the BPM software.
Much of what is wrapped up in the notion of BPM is well
established, if not old. This is true of nearly all computer
software and the way it is used. There are, however, important new
ingredients in any new comprehensive BPM software which could offer
real benefits to the business.
Jon Pyke is founder and president of The Process Factory and
senior vice-president of technology strategy at Global 360. This
article is based on an extract from his book Mastering Your
Organisation's Processes published by Cambridge University
Press