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[1]:

• 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

Professionals should always focus on business solutions first, then and only then on designing systems. Not just lip service, I mean applying the power techniques of true business architecture[1]. The first of these techniques is structured business strategy. See: http://www.brsolutions.com/2015/05/31/basics-for-business-architecture-1-structured-business-strategy/. The second technique is business processes and business rules. Effective business solutions require architecting both the following:

• What is done to create value-add (business processes).
• What ensures value-add is created correctly (business rules).

Many professionals are unclear about the respective roles of business processes vs. business rules. At the risk of stating the obvious, let me make the following points.

1. Business processes and business rules are different. They serve very different purposes: A business process is about doing the right things; business rules are about doing things right.
2. There is no conflict whatsoever between business rules and business processes. In fact, they are highly complementary. Each makes the other better. If they don’t fit hand-in-glove, somebody is simply doing something wrong.
3. You need both. Neither can substitute for the other. Period.

~~~~~~~~~~~~~~~~~~~~~~~~~ www.BRSolutions.com

Business Process Models: A completed transform often achieves a business milestone and a new state for some operational business thing(s). Example: claimant notified. Fact Models: In fact models (structured business vocabularies) such states are represented by fact types, for example, claimant is notified (or claimant has been notified if you prefer). A fact model literally represents what things the business can know (remember) about completed transforms and other operational business events. Business Rules: Business rules indicate which states are allowed or required. They should not reference business processes or business tasks by name, just the states they try to achieve. For example, a business rule might be: A claimant may be notified that a claim has been denied only if the specific reason(s) for denial have been determined.  ~~~~~~~~~~~~~~~~~~~~~~~~~~  This post excerpted from our new book (Oct, 2011) Building Business Solutions: Business Analysis with Business Rules. See:  http://www.brsolutions.com/b_building_business_solutions.php