Sample behavioral business rule:A customer that has placed an order must have an assigned agent. A practitioner wrote: In process design this means that an activity ‘Assign agent’ must happen before an activity ‘Take order’.My analysis: Here’s how behavioral business rules like this one should work according to standards:
If the business rule is violated in performance of the process ‘Take order’, then the process (activity) ‘Assign agent’ should be (optionally) invoked automatically so the violation can be corrected immediately (by the appropriate actor).
In performance of the process ‘Retire agent’ (which hasn’t been mentioned!), if the business rule is violated – i.e., the retiring agent is assigned to some customer who would thereby be left agent-less – the process (activity) ‘Assign agent’ should be (optionally) invoked automatically so the violation can be corrected immediately (by the appropriate actor).
There’s one business rule, but two kinds of events (in separate processes) where the rule can be violated. I’ve literally looked at 10,000s of business rules. Probably 95% or more are multi-event like this, and therefore often multi-process. You can see from this example how easy it is for business analysts to completely miss the second event. My contention is that’s one big reason why systems today often give such inconsistent results – the other event(s) are overlooked or in another process altogether. Conclusions
It’s highly misleading to say ‘business rules are part of processes’. No, not really. (I run into that statement all the time.)
We’re not designing processes today in a very intelligent way. Designers shouldn’t have to think, ‘O.K., which process (activity) has to come first because of the business rules?’. That approach forces us into sequences where no natural sequence is meaningful. In any case there are far too many behavioral business rules for it to be practical.
P.S. If you think ‘decisions’ will fix this fundamental problem, sorry, but I’m afraid you’re in for a rude awakening!~~~~~~~~~~~~~~~~~~~~www.BRSolutions.com
Semantics of Business Vocabulary and Business Rules (SBVR).
Ron Ross, Principal and Co-Founder of Business Rules Solutions, LLC, is internationally acknowledged as the “father of business rules.” Recognizing early on the importance of independently managed business rules for business operations and architecture, he has pioneered innovative techniques and standards since the mid-1980s. He wrote the industry’s first book on business rules in 1994.
“A great class that explains the importance of business rules in today’s work place.”
Christopher – McKesson
“Instructors were very knowledgeable and could clearly explain concepts and convey importance of strategy and architecture.
It was a more comprehensive, holistic approach to the subject than other training. Emphasis on understanding the business prior to technology considerations was reassuring to business stakeholders.”
Bernard – Government of Canada
“You did a wonderful job!! The material was organized and valuable.”
Janell – Texas State University
“Sessions flow together well and build upon the concepts for the series which makes the learning easy and better retention.
The instructor is knowledgeable and very attentive to the audience given the range of attendees skill and knowledge of the subject at hand. I enjoy her training sessions.”
Deborah – American Family Insurance
“I found the course interesting and will be helpful.
I like the pragmatic reality you discuss, while a rule tool would be great, recognizing many people will use Word/Excel to capture them helps. We can’t jump from crazy to perfect in one leap!
Use of the polls is also great. Helps see how everyone else is doing (we are not alone), and helps us think about our current state.”
Trevor – Investors Group
“Your work has been one of the foundations of my success in our shared passion for data integration. It has had a huge impact on innumerable people!”
“We actively use the BRS business-side techniques and train our business analysts in the approach. The techniques bring clarity between our BAs & customers, plus more robust requirements for our development teams. We’ve seen tremendous value.”