At time of this writing, I am not aware of any standard industry definition for business process.  Like many, I would heartily welcome a good one.  The best I have seen is:

Business process:  the tasks required for an enterprise to satisfy a planned response to a business event from beginning to end with a focus on the roles of actors, rather than the actors' day-to-day job^[1]

An important direction for many companies today is managing business activity on more of a beginning-to-end, value-add basis.  That requires thinking cross-organizationally about fundamental business processes.  What can rules do for business processes?  Roger Burlton, a noted industry expert on applied business modeling techniques, says it this way:  "If you separate the rules, you can develop remarkably stable processes."  If you are looking to manage business activities on a process basis that's exactly what you need.  He goes on to say:  "The really rapid change is in the rules ... not in the business processes."  Yes!

How do rules and business processes interact?  Burlton observes that business processes "... transform inputs into outputs according to guidance -- policies, standards, rules, etc...."  The key phrase in that is according to guidance.  Exactly what does it mean? 

Definitive answers suited to the business perspective have recently emerged.^[2]   Oversimplifying just slightly, 'guidance' means rules of two fundamental categories, as follows.^[3]

• Structural rules organize (i.e., structure) basic knowledge of the business, always carrying the sense of logical necessity or impossibility.  A structural rule can be ill-conceived, misunderstood, or misapplied, but it cannot be directly violated.

• An operative rule can be violated directly by people involved in affairs of the business.  Operative rules govern the on-going conduct of business activity, always carrying the sense of obligation or prohibition.

How Structural Rules Relate to Business Processes

Let's start with structural rules, whose relation to business process is a direct one.  They simply off-load work pertaining to knowledge.  There are at least two ways in which this happens:

Computation.  Computation rules provide the business logic to perform any calculations that can be encoded.  Such computation logic can be highly complex, involving many rules.

Decision Making.  Inference rules can determine the proper outcomes at decision points ('branch points') in a business process.  Such decision-making rules can range from simple (e.g., has this product been discontinued? or is this a repeat customer?), to quite complex (e.g., is this insurance claim potentially fraudulent? or what is the best of available job position for this applicant?).  Complex cases can involve large numbers of inference rules.  All such logic can be off-loaded from the business process.

Aside:  This off-loading does not have to happen all at once.  In other words, you do not have to know and encode all the rules in advance.  In anyone says so -- nonsense!  For example, a decision point may be handled manually at first, and only later be automated using encoded inference rules, as time, cost, and feasibility permit.  To say this differently, business rule systems are quite good at supporting continuous improvement methodologies.

How Operative Rules Relate to Business Processes

Now let's look at how operative rules relate to business process.  As mentioned above, operative rules are ones that people can violate.  In a game of football, operative rules are why you need referees on the field during each game -- someone to watch and intervene if any violations occur.  Operative rules, which arise anytime people are involved (not just knowledge), are a distinctive feature of the business rule approach.

Operative rules monitor on-going work as it occurs in the business process.  The particular aspect of work they monitor ranges from specific to quite general:

Iteration.  Business processes often involve iteration (loops).  Timing and repetition criteria for these loops can be expressed as rules.  Examples include:

Maximum time allowed between iterations.

For example:  Additional information must be requested at least every 5 days if appropriate information is not received.

Minimum time allowed between iterations.

For example:  Additional information must not be requested more often than every 24 hours.

Maximum iterations permitted.

For example:  The total number of requests made for additional information for a claim must not exceed 10.

Maximum time permitted for completion.

For example:  Requests for additional information for a claim must not be made after 10 days.

Service Level Agreements.  A service level agreement generally involves four things:  (1) an action item, (2) a party, (3) escalation criteria, and (4) timing criteria. 

For example:  A customer service request must be brought to the attention of a supervisor if the request is not resolved within 4 hours.  In other words:  (1) the action item customer service request (2) must be brought to the attention of a supervisor (3) if not resolved (4) within 4 hours.

Aside:  This rule statement really isn't in atomic form, but for the sake of sticking to the main message, I'll ignore that here.

Compliance.  A business process can involve hundreds of rules (or more!) addressing specific things people need to do to comply with business policy and/or external regulation.  A business process cannot possibly address that many rules directly, especially if it's developed with a goal of managing business activity on a cross-organizational basis. 

Aside:  Actually, that would be even more difficult than it would seem at first glance.  Most rules involve two or more events where they need to be evaluated.  Consider the rule:  A customer must be assigned to an agent if the customer has placed an order.  This rule involves two events:  (1) When a customer places an order (an obvious one), and (2) When an agent leaves the company (a less obvious one).  A business process that focuses on fulfillment of customer orders is very unlikely to address that second event.

What should the business do?  Do what comes naturally -- maintain a separate rulebook, as in football.  This rulebook gives the guidance that business processes should follow.^[4]  It should be automated using a knowledge-smart work environment that business people and analysts can use directly to manage business rules at the business level. That way a business process model can focus on the vital thing it needs to do -- give a planned response to a business event from beginning to end.

Excerpted from Chapter 6, Business Rule Concepts:  Getting to the Point of Knowledge (Second Edition), by Ronald G. Ross.  www.BRSolutions.com (September 2005).  ISBN 0-941049-06-X.  Reprinted with permission.

References

[1]  Janey Conkey Frazier (Swimlane Process Maps), actually given originally for workflow.

[2]  In particular based on:  Semantics of Business Vocabulary and Business Rules (SBVR), by the Business Rules Team, August 2005.  Available to OMG members at www.omg.org as bei/2005-08-01:  BRT's revised submission to the Object Management Group's (OMG) Business Semantics of Business Rules RFP.   For background on the SBVR and the consortium that produced it, refer to "A Brief History of the Business Rule Approach," Business Rules Journal, Vol. 6, No. 1.  Available at www.BRCommunity.com/a2005/b216.html

[3]  For more, see Chapter 5, Business Rule Concepts: Getting to the Point of Knowledge (Second Edition), by Ronald G. Ross, September 2005. ISBN 0-941049-06-X - www.BRSolutions.com-

[4]  This is the notion of Rule Independence. The need for Rule Independence, and for business-people tools to support it, is given by: The Business Rules Group, Business Rules Manifesto ~ The Principles of Rule Independence, ver. 1.2 (Jan. 8, 2003).  Available at www.BusinessRulesGroup.org (in English as well as translations to numerous other languages).

# # #