individual-entry-BA-Blog

« What kinds of problems lend themselves to EDM? | Main | Progressive Financial Services Firms Demonstrate the Value of Predictive Analytics; Decision Services Offer a Path for Others to Follow »

Process Management and Decision Management

(Posted by guest blogger, James Taylor)

I posted a little piece on the potential unification of business processes and business rules on my other blog recently - Please don't just unify rules and process. This prompted some very interesting comments and links from a variety of sources and made me think it was worth recapping here.

The value of keeping business rules, specifically the business rules that drive business decision-making, separate from the specification of a business process that needs a decision made have been covered on this blog before:

  • Long running processes should get the right rules for a decision at the point in time that the decision is being made and not lock in those rules when the process is first instantiated.
  • Decisions, and the rules behind them, may need to be shared across many processes and systems not built with a process point of view.
  • The rate of change, and the ownership of that change, may be quite different for the definition of a process and the definition of the decisions within it.

In the end it comes down to the fact that process agility is not the same as decision agility. If agility is about sensing and then (correctly) responding to a business change I should be able to make various kinds of change depending on what is called for. If I need to change my process then I may well have to also change some rules in the decisions used by those processes and I may well find it easiest to discuss the changes needed to the process in terms of "process rules". The reverse, however, is not true. I might change the decision as to what offer to make, what price to use, what shipment date to promise without in any way changing the process of completing the order. This is decision agility and a unified process/rule view is not going to help.

One of the main causes of confusion comes from failing to differentiate between rules as a way to describe behavior (the business rules approach, you might say) and the specification of decisions using business rules. Business rules are declarative, atomic and business-friendly and so make a great tool when describing process flow or event correlation. CEP engines and BPM tools alike should support rules constructs for this reason. However, managing business decisions is a separate activity that also requires rules and typically requires far more rules, rules that change more often and rules that have more domain knowledge within them. These kinds of rules are better managed using a separate business rules management system (BRMS) so that they can be shared and reused across decisions, across processes and across systems.

There are some other things to note:

  • Decisions are typically stateless where event processing and business process execution are stateful. Rules for decisions therefore have different constructs from rules for business process or event processing
  • It has been said that rules and processes are tightly linked. Well yes and no. Yes, many processes benefit from being described at least partly in a rules-based way. No, this is not true of the rules that are used to implement the business decisions because business decisions should not be tightly coupled with the processes that use them.
  • A unified environment might make it easier to manage processes but  there would still be a real need to manage decisions separately - this is the premise of enterprise decision management.
  • Data and rules are also tightly related yet no-one proposes doing away with separate rules and database management. There are rules for metadata and rules in MDM for example. Again, this is not the same as the rules you need for decisions.
  • Unified audit trails is something that might be useful but I don't think this benefits from a unified environment either as other things besides rules and process need to be in the audit trail.
  • Simulation of potential changes is the one area where a loose coupling makes life harder. I don't think this is enough of a problem to justify coupling but I do think it is an area that needs work.

There's much more that can be said on this but here are some links in which I think most of what could be said has been:

JT

Visit my Smart (Enough) Systems Blog(RSS) or my ebizQ blog (RSS). Buy the bookor visit the companion wiki.

First time on the EDM blog?
Subscribe to the EDM blog feed or check out some other recent posts:

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d83451629b69e200e54fa7ba238834

Listed below are links to weblogs that reference Process Management and Decision Management:

Comments

Gavin Terrill

> Data and rules are also tightly related yet no-one proposes doing away with separate rules and database management.

C.J Date did in "What, not How", although admittedly the idea hasn't garnered mainstream acceptance - http://www.tdan.com/view-book-reviews/5597

The comments to this entry are closed.

Search Site


  • dmblog.fico.com

Subscribe

  • enter your email

Upcoming Events

  • FICO Tools & Analytics User Forum 2012
    BERLIN: September 11-12, 2012 LONDON: September 18-19, 2012 Gain new insights for improving business performance through advanced analytics and decision management tools.