Much as I often agree with Ismael Ghalimi over at IT Redux, his recent post on Why a BPMS needs a Business Rules Engine has several points with which I disagree. There's an interesting comment thread now clarifying his position (and mine) but it made me think about agility and, in particular, a recent Gartner piece on Achieving Agility: The Agile Power of Business Rules. The key reason for not embedding business rules into a business process management system and for not always synchronizing the updates of rules and processes is to deliver on the agility promise.
The Gartner piece, by Jim Sinur and Dave McCoy, has lots of good recommendations but the key is that any time you hard-code business rules or try and use a business rules approach without automating the management of business rules, you will drive down your effective business agility. So what is Agility? Well Wikipedia defines Agility thus
"Agility in business, often defined as the ability of a firm to sense and respond to business opportunities in order to stay innovative and competitive in a turbulent and quickly changing business environment. An agile firm (one that demonstrates agility) has the capabilities and processes to respond to unexpected environmental changes."
When we think about how a business might respond to changes we can define two kinds of response - changing a process or changing how a decision is made within a standard process. Let's consider each of these in turn.
Some kinds of change require me to change a process in response. For instance, if a particular locality introduces regulations into a previously unregulated process I might have to add a compliance step. If I open a new call center to handle a particular class of customers (to compete with someone who does this perhaps) then I must add a new branch and new steps to the processes that handle customer interactions.
When core processes, such as order to cash, are changed there is typically a significant impact on the organization as a whole. The changed process and the changed definitions in a BPMS are unlikely to be all there is to it. Organizational change, and perhaps new auditing, will likely be required. This kind of change then is hard to make really agile and will always be fairly time consuming.
Processes around the "edge" of a company with lower volumes, less repeatability and more manual steps do need to be easy to change as they are likely to change often. How I handle calls from my very largest customers, for instance, might be entirely defined by a custom contract which requires a distinct process to be created for each such contract.
Decision agility is required when change is required within a process that does not change the process itself. For instance, if I change the rules for determining price discount eligibility I will likely not change the process at all - at the same point in the process I will determine the discount, apply it and continue. Yet the decision as to what discount to offer will change. Being able to quickly change the decisions within a process, with or without a matching process change, is key to decision agility. This tends to matter most in core business processes which, while they are fairly stable in terms of steps and outcomes, can have significant variation in decision-making over time.
Process and Decision Agility
Both kinds are required and they are often used together. Clearly if I add a new sub-process to handle a new class of customers I will likely also change the decision logic for segmenting customers so as to put the right customers into this new sub-process. If I decide to change the way I handle risk management decisions I might create new needs for external verification or report, which will need their own processes and so on. Not all decision changes require process changes but it is pretty usual for all process changes to impact a decision - only fairly manual processes where everything is handled by people and worklists are likely to be an exception.
It is this need for a range of response options that means you cannot afford to make rule changes and process changes synchronized all the time.