Intelligent Enterprise

At last week's Business Rules Forum, Kathy Long of the Process Renewal Group talked about how to derive rules from processes and use them as guides to the process. There are a number of process-related problems that can occur when the rules are not explicit: assumed policies, activities with experience as the only guide, and inconsistent (and therefore likely non-compliant) processes.

The key things to consider when analyzing the guides for a process can be focused around what happens at a given activity (and what knowledge is required, what decisions are required, what reports have to be generated) as well as a number of other factors. Long presents a number of questions to ask to drive out the rules and make them explicit.

Long also made a distinction between policies and rules, the key differentiator being that rules are actionable, whereas policies must be interpreted into more concreted business rules in order to take action. Within rules, there are both structural rules (can't be broken) and operative rules (which have a bit more wiggle room); this sounds a bit like the distinction between a fact and a rule that I heard in another session, which makes me unsure that there's a really common vocabulary for some of these things.

Looking at process analysis techniques, Long presented categories of activities as real value-added (impact the customer's requirements), business value-added (required to run business, such as regulations), and non value-added (the 65% to 85% of work that doesn't contribute to either RVA or BVA). There's a whole list of verbs — adjust, approve, expedite, inspect, verify and many others — that tend to indicate that activities are NVA and should be considered for elimination. Many of these exist because something wasn't done right the first time; a lot of the NVA activities can be cut if there are ways to reduce the error rates in the RVA and BVA activities.

This isn't, of course, really about rules: it's about process improvement. Sure, the appropriate addition of business rules can certainly lead to process improvement, but it's also about the myriad other ways that we improve processes, such as establishing accountability and eliminating unneeded steps that are only there for historical reasons. Some thoughts that Long gave us to take away:

• The greatest opportunity to improve a process is by changing the rules
• Challenge all policies
• Validate all compliance interpretations
• Eliminate the use of assumed policies
• Ensure that all rules are documented including the use of experience/knowledge
• Create consistent rules across the enterprise
• Structure rules so that they can be easily changed
• Allow the business to design its own processes

I was surprised she didn't talk at all about some of the technology issues, such as how BPM and BR can be used together to improve processes, but her focus was not at all on technology: her only case study was about improving a process based on a manual procedural change.

I learned a lot at the Business Rules Forum, which made my time there definitely worthwhile. However, I'm still left with the feeling that I mentioned in my first post: we need to start having much more crossover between different technology areas such as BPM and BR. I've been writing since mid-2005 about the importance of looking at BPM and BR together, but in spite of the technology advances that have occurred since then to facilitate this, I'm not seeing much happening in the real world.

Sandy Kemsley is an independent systems architect specializing in business process management, Enterprise 2.0, enterprise architecture and business intelligence. She is also the author of the Column2 blog on BPM, Enterprise 2.0 and technology trends in business. Write to her at Sandy [at] Column2.com.