« Robotics - the next frontier for decisioning? | Main | Smarter Business Intelligence, smarter Performance Management »

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.

• Process Agility
  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
  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.

Posted by jtaylor in Business Process Management • Business Rules |Digg This|Add to del.icio.us

Trackback Pings

TrackBack URL for this entry:
http://www.ebizq.net/mt/mt-tb.cgi/369

Listed below are links to weblogs that reference Don't over-synchronize processes and rules:

» Intelligent Enterprise Magazine: Seven Trends for 2007 from James Taylor's Decision Management
Ian pointed me to this today: Intelligent Enterprise Magazine: Seven Trends for 2007. Doug, David and Penny from Intelligent Enterprise, with some help, came up with a nice list and it prompted me to cross-reference it with EDM: Capture Expertise... [Read More]

Tracked on January 3, 2007 10:53 AM

» More on BPM - what about Decision Services? from Enterprise Decision Management - a Weblog
Tulu Tanrikorur of New York Life wrote Business Process Management 101: The Basics of BPM and How to Choose the Right Suiteover on Intelligent Enterprise. It's a nice summary of various approaches to considering BPM and related software. However, while [Read More]

Tracked on May 8, 2007 10:41 AM

Posted by: Phil Ayres at June 20, 2006 09:35 AM