One of our clients, a major pharmaceutical company, called us with a significant problem.  They had created a business process model some 28 pages long.  No one could follow it, and everyone was confused.

The problem was clear to us immediately — business rules embedded in the flow.  We extracted all the business rules, reducing the business process model to just four pages!  Now everyone could understand the business process.  In the bargain, they could also now clearly see the business rules and which ones needed to be modified. 

There is nothing unusual or exceptional about this story — it happens all the time.

Notation for Modeling Business Processes with Business Rules

At the risk of saying the obvious, business processes and business rules are not the same.  In fact, they are fundamentally different.  Specifically, a business process transforms something, always.  Business rules properly expressed in declarative form do not transform anything, ever.  (The evaluation of business rules might result in something being transformed, but that's a different matter.)

Thou Shalt Not Kill Could anyone possibly mistake that Commandment for a process?! Analysis The process of murder transforms a live person into a dead person by killing them. The concept of murder is defined as the act of killing someone. The rule about murder is that there shouldn't be any of them. The first is about doing; the second is about knowing; the third is about prohibiting.  Three very different things.

What notation should you apply for modeling business processes?  Use your own judgment, but here are a couple of tips from our experience.

• Keep the notation simple.  To explore how value-add is created cross-functionally at the business level and to discuss it with business people, you don't need fancy event symbols and such.  In fact, they'll work against you.  And they're mostly not necessary for business rules anyway.
  
  
• Always keep in mind that the boxes found in a business process model refers to real things (activities) in day-to-day operations of the business, not to how those things are represented or coordinated in a system.  Big difference!  A business process model, for example, should have no tasks whose sole purpose is updating stored data.
  
  
• Never think of the arrows between the boxes as data flows; a business process model is not a data flow diagram.  (Data flow is about how the logic of a procedural program works.)  Instead, think of each arrow as a hand-off of work between business tasks, possibly to a different actor.  Output(s) from one or more previous business tasks become input(s) to some other business task.  As above, these inputs and outputs are not data, not information about operational business things.  They represent the actual things themselves.  Of course, that line gets a bit fuzzy when the things the business works with are intangible (e.g., insurance policies, financial products, tax, etc.); nonetheless, since the customer thinks about those things as very real, real they are.
  
  
• Some business tasks in a business process model are likely to require extensive know-how, for example Adjudicate Claims.  Such decision tasks, which can be the source of a great many business rules, require special analysis and representation techniques.  We use Q-Charts for that.

How Business Process Models, Concept Models, and Business Rules Relate:  It's All About What State You're In Business Process Models:  A completed transform often achieves a business milestone and a new state for some operational business thing(s).  Example:  claimant notified. Structured Business Vocabulary (Concept Models):  In concept models (also called fact models) such states are represented by verb concepts (also called fact types) — for example, claimant is notified (or claimant has been notified, if you prefer).  A concept 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.

Collectively, the boxes and arrows in a business process model represent management's blueprint for understanding, coordinating, and revising how operational work in the organization gets done — that is, how value add is created.  Consequently:

• Responsibility for performing business tasks can be re-allocated (or automated) as appropriate.
• Bottlenecks can be identified and corrected.
• Appropriate business rules can be applied to ensure work is done correctly.

Conditional Flows:  The Secret of Relating Business Process Models and Business Rules

A conditional flow in a business process model is an arrow labeled with an 'if' condition indicating that work follows the given path only if the condition is satisfied for a given case.  Figure 1 illustrates an example of the conditional flow, "if owner approval required".

Figure 1.  Conditional Flow in a Business Process Model.

The secret of effective business process modeling with business rules is:  Never embed the criteria used to evaluate a conditional in the conditional itself.  Instead, just name the conditional using an adjective (e.g., valid) or past participle (e.g., required, as in Figure 1). 

Criteria for evaluating conditionals should always be expressed separately as business rules.  Fortunately there's nothing particularly hard about that.  Here are some sample business rules that permit evaluation of the conditional flow in Figure 1.

1. An order that exceeds the customer's credit limit by more than $50,000 must be approved by the owner.
   
   
2. An order that exceeds the credit limit of a long-time customer must be approved by the owner.
   
   
3. A rush order placed by a new customer not yet given a credit limit must be approved by the owner. 

Should actual business rules (or references to them) appear on the business process model itself?  Generally, no.  The purpose of the business process model is to provide a management blueprint for how work gets done.  Showing business rules just clutters that picture.  There will be lots of business rules — which ones will you show?

What if business practices for some business process vary extensively across organizational or geographical units?  Think states.  Developing business rules for states of things referenced by your business vocabulary (concept or fact model) ensures that basic imperatives for all variations of the business process can be identified and coordinated.  Then local variations of the business process can be created as (and if) needed. 

Summary

If you're looking to manage business activities on a business-process basis, stability is key.  But business rules aren't stable.  In fact, many change quite rapidly.  What should you do?  Separate the business rules from the business process model, so the business process model can do its job.

Adherence to the best practices identified in this discussion is also how you keep a business process model simple.  Frankly, most business processes aren't nearly as complicated as people think.  What's complicated is the know-how needed to perform the business process correctly.  That know-how should be represented by business rules.

# # #