I couldn’t quite drag myself out of bed for the 8am sessions, but I did want to hear Kathy Long of the Process Renewal Group talking about process and rules. She talked about how to derive rules from processes, and use them as guides to the process. There’s 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 focussed around what happens at a given activity (are what knowledge is required, what decisions are required, what reports have to be generated) as well as a number of other factors; she presents a number of different questions to ask in order to drive out the rules and make them explicit.
She also made a distinction between policies and rules, where the key differentiator is that rules are actionable, whereas policies must be interpreted into more concreted business rules in order to take action. Within rules, there’s 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 a session yesterday, which makes me unsure that there’s a really common vocabulary for some of these things.
Looking at some of their process analysis techniques, she 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 (that 65-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 are because something wasn’t done right the first time; a lot of the NVA activities can be cut if there’s 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 that 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 have to head off for a mid-day flight home, so that was the end of my Business Rules Forum experience. I’ve actually learned a lot here, which has made my time here definitely worthwhile. However, I’m still left with the feeling that I mentioned on my first post back on Tuesday: 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.
FYI – Structural and Operative rule definitions supplied in her presentation were taken from the SBVR specification –
http://www.omg.org/cgi-bin/doc?dtc/2007-06-06