There are lots of good reasons for adopting business process management as an approach, and a Business Process Management System as a technology. The benefits that can be gained are real but they can be undermined by over complex process designs. If the process you end up designing is the BPMN or BPEL equivalent of spaghetti code, then your process won’t be agile and it won’t be cost-effective. It’s also unlikely to deliver a positive customer experience or to be easy to continuously improve. The benefits of BPM are dependent on you developing processes that are reasonable, that are not over-complex.
In my experience working with clients, however, I find many over-complex processes are being designed. Often these processes are over-complex because the decisions within those processes are not being identified and separately modeled or managed. Instead, large numbers of gateways and branches are being used to manage business logic and business rules are spread one at a time through the process.. Other tasks are identified as manual tasks with cheat sheets and procedures are presented to users to guide them through the decision making.
Instead of mixing processes and decisions and applying a single approach (BPM) and a single tool (a BPMS), the clients I have been working with are separating them out. They find the decisions – the parts of the process that validate things, determine eligibility, calculate prices, select appropriate terms, assess risk – and design and manage these separately. They use a Business Rules Management System or a decision engine to manage these decisions. The combination of a separation of concerns and the use of a tool designed for managing decisions simplify both the process and decision. The resulting decisions and process collaborate, typically using SOA, to deliver the business result required.
When decisions are separated out like this, especially when they are also moved early in the process, a dramatic improvement in straight through processing and a matching reduction in process execution time/complexity are possible.
This is particularly true in stable, core processes. Processes at the edge of a business are often less stable and evolve rapidly. No-one is 100% sure what the process should be and so it gets changed a lot based on experience. Some of these edge processes never really stabilize at all. In these processes decisioning is going to be dynamic, hard to formalize and need to remain flexible. Core processes, however, are much more stable. Everyone knows the paths that work through the process, the activities involved are well defined. Changes to these processes are a big deal, disruptive to the company regardless of how they are implemented.
In these processes what changes are the decisions and the business rules behind those decisions – what makes a customer eligible for this level in the loyalty program, what price is this policy for this customer, what’s the best retention offer to make. These decision changes can be mistaken for a process change if the decision has not been broken out but they are not process changes – the activities, their sequence and their purpose all remain the same. The decision-making behavior of a specific activity is what changes.
These core processes are also the focal point for the balance between standardization/globalization and flexibility/localization. Many companies want standard processes, globally enforced. At implementation time, however, they find that local variations or product-specific exceptions undermine this attempt at standardization. They end up as one company said to me with a “worldwide standard process with hundreds of local exceptions”.
This is far from ideal as they now have to manage a much more complex process—the actual process has hundreds more elements than the original “simplified” process that was envisioned. This reduces agility, increases risk of errors and problems, reduces the ability of the various groups involved in the process to share and collaborate, and makes it harder to spot opportunities to improve the core process. Plus the process diagram is ugly.
In many of these cases, though, it is not the process that needs local exceptions but a decision within the process. Because the original process design did not explicitly identify the decisions within the process (they were probably pretty simple in the global version anyway), exceptions are seen as exceptions to the process. But if the decisions are called out, often the exceptions are clearly related to a decision. In a standard order to cash process with a “what is the customer discount?” decision might have local exceptions while in the supplier onboarding process the local variations might be in the “is this a complete, valid set of supplier data?” decision. One company found that if it externalized the decision that validated a supplier’s data as complete it could use a standard onboarding process (and a much simpler one) while still allowing different countries to have different tax IDs or company types for example. All the local variation was encapsulated as rules in the validation decision.
Of course this does not make the exceptions go away. But it does help you separate concerns – process in process management, decision in decision management – and use a technology ideally suited to handling lots of rules and figuring out the right ones to apply (a business rules management system).
Most companies have both kinds of processes and most therefore will need to manage decisions as well as processes. If they focus initially on core processes, like underwriting in Insurance say, they will likely adopt rules and focus on decisions first. If they focus initially on edge processes, they are less likely to see the value of rules and decisions in the short term and will focus purely on process. But their core processes will require decisioning.
