BPM? I’d Prefer BTE, Thanks

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.