We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

James Taylor's Decision Management

James Taylor

Don't over-synchronize processes and rules

Vote 0 Votes

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.

2 TrackBacks

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

More on BPM - what about Decision Services? from Enterprise Decision Management - a Weblog on May 8, 2007 10:41 AM

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

1 Comment

Nice post James. I agree with your three agility descriptions. Experience has taught me that if you do not pay attention to these from the initial definition of any business process system, you will end up with a high chance of failure. This prompted me to blog a little about my own experience in this area.

The problem as I have seen it extends beyond the pure implementation of rules and processes. Typically organizations want a nice usable/pretty application user interface (UI) to sit over the top of their new workflow process, to appeal to vocal users and executive sponsors. Poor design of these often reduces the agility of your rules, or the ability to really use the power of the underlying rules or process engines.

Best practice says ‘start simple’, and for business processes, rules and the applications around them this is essential.

James Taylor blogs about decision-management technologies such as predictive analytics and business rules, discussing how they deliver agility, improve business processes and bring intelligent automation to SOA.

James Taylor

James Taylor blogs on decision management for ebizQ, and is an independent consultant on decision management, predictive analytics, business rules, and related topics.

Sponsored Links



 Subscribe to this blog by RSS
Subscribe by email:

Recently Commented On

Recent Webinars

    Monthly Archives