Business process management (BPM) has been around for years. Although organizations have bought BPM software, many feel that the benefits have not been recognized as expected. The biggest issue is that the tools are predicated on the capability of the organization using them to be able to adequately define its own processes.

It is a common belief that, the only people capable of defining business processes are the people within the business itself. Unfortunately, in many cases, these are the last people who should be allowed to define the process. Many of them will be averse to change and attempt to ensure that any new process reflects the existing way of doing things.

But, the biggest issue, far beyond this disagreement, is determining what the heck a “process” actually is. Is it prospect to cash? How about claiming expenses? Is it reading an email? It’s possible that it is all of these and more, but organizations can get very confused in defining the correct levels of granularity for BPM and therefore spend a lot of time doing things wrong.

For example, if too high a view is taken of a process, automating it can make things much worse. By defining a process end-to-end as closely as possible, it becomes difficult to manage exceptions to it or change it when the market or business dictates. Ask any person to describe such an end-to-end process. It is unlikely that there will be any one person in an organization who can do so; and with many BPM vendors using a “process owner” as a predominant role in their approach, the whole thing falls at the first hurdle. A large automated process falls into the same problematic area as a monolithic application. It becomes prescriptive, and users and technologists alike do not like to try to change it. Such processes span too many areas and too many people to be a valid approach.

So, how should a process be viewed? If we take a more realistic view of how processes work within an organization, then we stand a chance of coming up with something that will work.

Let’s consider the process of vacation booking. This is very simple, but anyone can explain it? As an end user, before reading beyond this sentence, jot down your thoughts on the end-to-end process for vacation booking in your organization.

Done? You probably have the main input for your own end user role - when you need the time off. You also probably have the main outputs - the dates required for updating your own calendar, a form for sending the request to the next role in the process and so on. But does that next role do? Look at the form and say “yes/no” after comparing the time required against the time you have remaining in your entitlement? In your notes, did you cover the need for HR to have full records to compare against already booked vacation times from other people, fill in the requisite forms for the inland revenue, and complete a database so project managers, supervisors and others roles within the organization can see who is where and when?

Any full process will have bifurcations all over the place, and defining the process requires input from many roles and individuals. The problem is that each of these roles and individuals has their own perceptions of needs. So much time can be spent on defining the process that by the time it is automated, the real process need has changed.

If we look at a process at a task level, however, we can carry out automation and manage changes to the process far more quickly.

In the vacation booking example, the end-user’s task is to provide enough information to determine whether this time off will be allowed. The next stages of the process will need information such as the employee’s name, department, contact details, the dates required, etc.

In an automated process, one of the next stages may be to look up the HR database that compares the employee’s entitlement against time requested and sends back a simple yes/no. This may be run in parallel against a project database that is looking at the critical path to see whether the employee’s skills are required during that time and, if so, whether the skills can be covered from elsewhere during the time. Again, a yes/no response will be may be sent back. Other tasks will be carried out either in parallel or in serial and an overall yes/no response sent back to the employee, based on balanced scoring from the various responses received.

If we take a task viewpoint, the individual or the action becomes the main focus. Each must only ensure that its input needs are fulfilled and that it provides the correct outputs required by the next stage. Even here, we can be more dynamic than we would in a fully defined process approach. If the next stage of the process changes and requires more in the way of input, we don’t have to change the previous stages immediately. The preceding stage still sends what it has always sent, but the changed stage now raises an exception stating the needs for more information. If the preceding stage is human-oriented, this can be directly requested from the human. If it is a machine-to-machine interaction, the expectation may raise the event to a human to gain the required information directly.

A task-oriented approach is not only theoretically possible, it is something that is easily done. The tasks themselves are easily defined. Each task is defined by the user responsible for it. The inputs and outputs can be defined using XML schemas in exactly the same manner that the metadata around Web services is already defined today. The registry of tasks is so similar to the registry of function used for Web services (the universal description, discovery and integration, or UDDI) that such a construct is easy to replicate for a task-oriented environment. Obviously, once we start to pull together a group of tasks, we are managing a process – and so, from taking a task-oriented view, we create a real BPM solution.

Task orientation also drives greater functional reuse. Because each task is functionally independent, its requests and submissions can be managed in the same way as Web services, and the overall process can be dynamically constructed to reflect the needs of the business on a moment-to-moment basis.

Business task enablement, rather than BPM? Seems like a valid approach to me.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access