Intelligent Enterprise

The good news is that it's a lovely sunny, breezy and cool day: perfect fall weather for Toronto. The bad news is that I'm in Orlando, and was hoping to wear shorts more than sweaters this week. However, I'm here to attend — and speak at — the Business Rules Forum, not sit by the pool.

Ron Ross, executive editor of BRCommunity.com, kicked off this week's Business Rules Forum with a keynote called From Here to Agility; agility, of course, is one of the key reasons that you consider implementing business rules, whether in the context of BPM or other applications. It's pretty well attended — probably 200 people here at the opening keynote, and likely a lot of vendors off setting up their booths for later today.

Ross started with a couple of case studies, both of companies that could really use rules due to the lack of agility in their legacy systems, and of companies that have successfully implemented rules and achieved their ROI on the first project. He then looked at what might be motivating people to attend this conference and what they can expect; a bit of an unnecessary sales pitch, considering that these people are already here.

He talked about the importance of decisioning, and how it's a much better opportunity for business improvement than process; I'd have to agree that it's a much greater contributor to agility, but not necessarily a better opportunity for improvement overall. I'll have to think that through before my presentation this afternoon on mixing rules and process. He did have some convincing quotes from Tom Davenport's "Competing on Analytics," such as Davenport's conclusion that automated decisioning will be the next competitive battleground for organizations.

The goals to creating business agility:

• No artificial constraints in the representation of business products and your capacity to deliver them to customers — this is primarily a cultural issue, including a vocabulary to define your business practices, not a technical issue.
  
• All operational business practices represented as rules.
  
• All rules in a form such that they can be readily found, analyzed, modified and redeployed by qualified business people and product specialists.
  

Examples of operational business decisions:

• How do we price our product for this transaction?
  
• What credit do we give to this customer at this point in time?
  
• What resource do we assign to this task right now?
  
• Do we suspect fraud on this particular transaction?
  
• What product configuration do we recommend for this request?
  
• Can we confirm this reservation?
  

Note that these really are low-level, moderate complexity operational decisions, not strategic decisions: thousands or even millions of these decisions may be made every day in your business processes, and having agility in this type of decision can provide significant agility and competitive differentiation.

James Taylor and Neil Raden will be here later to talk about enterprise design management (EDM), but Ron gave us some of the basics: closed-loop decisioning that captures data about decisions, analyzing that data, then uses those results to make changes in a timely manner to the operational decisions. The "in a timely manner" part of that is where business rules come in, of course. That round-trip from analysis to deployment to execution to capture is key: we talk about it in BPM, but the analysis and deployment parts often require a great deal of an analyst's time in order to determine the necessary improvements.

He went on to talk in more detail about why a focus on "business process" isn't enough, since it doesn't make the business adaptive, create consistent and reusable rules, or a number of other factors that are better served by business rules. To achieve business agility, then, he feels that you need:

• Business-level rule management: having the business make changes to rules
  
• Business-level change deployment: having the business in charge of the governance process for changing and rolling out changes to rules
  
• Business-level organizational function to support the previous two activities
  

Looking at the problem decisions in existing legacy systems, look at the redundant, overlapping and conflicting rules; these could manifest as data quality problems, frequent change requests, or customer service problems. In many cases, these conflicting rules may be running on different platforms and address different channels. The key is to externalize these rules from the legacy systems into a decision service: a business rules management system that maintains the rules repository and is available to any application via a standard web services interface. This allows for a gradual transition from having these rules embedded within the legacy systems to centralizing them into a common repository that ensures consistent results regardless of channel or application. This provides consistency across channels, selective customer treatment and competitive time-to-market as well as rather painless compliance since your policies are embedded within the rules themselves and the rules management system can track what rules are executed at any given point in time.

Now, think of your BPMS as your legacy system in the context of the above paragraph…

E-MAIL  |