Business Analysis Thought Leadership - Articles



BA ARTICLE ARCHIVE
» July 2014 (5)
» June 2014 (7)
» May 2014 (5)
» April 2014 (5)
» March 2014 (7)
» February 2014 (6)
» January 2014 (6)
» December 2013 (7)
» November 2013 (4)
» October 2013 (5)
» September 2013 (6)
» August 2013 (8)
» July 2013 (8)
» June 2013 (7)
» May 2013 (8)
» April 2013 (8)
» March 2013 (4)
» February 2013 (6)
» January 2013 (6)
» December 2012 (5)
» November 2012 (7)
» October 2012 (6)
» September 2012 (6)
» August 2012 (5)
» July 2012 (9)
» June 2012 (5)
» May 2012 (9)
» April 2012 (7)
» March 2012 (7)
» February 2012 (5)
» January 2012 (7)
» December 2011 (6)
» November 2011 (6)
» October 2011 (8)
» September 2011 (6)
» August 2011 (8)
» July 2011 (7)
» June 2011 (7)
» May 2011 (5)
» April 2011 (8)
» March 2011 (6)
» February 2011 (5)
» January 2011 (6)
» December 2010 (5)
» November 2010 (9)
» October 2010 (5)
» September 2010 (6)
» August 2010 (8)
» July 2010 (6)
» June 2010 (6)
» May 2010 (10)
» April 2010 (5)
» March 2010 (8)
» February 2010 (7)
» January 2010 (7)
» December 2009 (7)
» November 2009 (7)
» October 2009 (6)
» September 2009 (8)
» August 2009 (10)
» July 2009 (9)
» June 2009 (5)
» May 2009 (10)
» April 2009 (5)
» March 2009 (12)
» February 2009 (8)
» January 2009 (6)
» December 2008 (9)
» November 2008 (8)
» October 2008 (9)
» September 2008 (4)
» August 2008 (6)
» July 2008 (8)
» June 2008 (17)
» May 2008 (12)
» April 2008 (7)
» March 2008 (21)
» February 2008 (16)
» January 2008 (13)
» December 2007 (9)
» November 2007 (25)
» October 2007 (2)
» September 2007 (23)
» August 2007 (12)
» July 2007 (11)
» June 2007 (7)
» May 2007 (6)
» April 2007 (9)
» March 2007 (5)
» February 2007 (3)
» January 2007 (2)
Articles and White Papers
Sunday, May 13, 2012
5621 Views 1 Comments 4 members voted Article Rating

In creating a viable business solution, you need both a business process model and business rules – not just one or the other. The trick is not to get them entangled, to remain clear about which is which. The good news is that by separating them you can simplify your business process models dramatically – often by an order of magnitude or more. This discussion explains how.

Excerpted with permission from Building Business Solutions: Business Analysis with Business Rules, by Ronald G. Ross with Gladys S.W. Lam, An IIBA® Sponsored Handbook, Business Rule Solutions, LLC, 2011, 304 pp, http://www.brsolutions.com/bbs

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.

About the Author:

Ronald G. Ross is recognized internationally as the ‘father of business rules.’ He is Co-founder and Principal of Business Rule Solutions, LLC, where he is active in consulting services, publications, the Proteus® methodology, and RuleSpeak®. Mr. Ross serves as Executive Editor of BRCommunity.com and as Chair of the Business Rules Forum Conference. He is the author of nine professional books, including his latest, Building Business Solutions: Business Analysis with Business Rules with Gladys S.W. Lam (2011, http://www.brsolutions.com/bbs), and the authoritative Business Rule Concepts, now in its third edition (2009, http://www.brsolutions.com/b_concepts.php). Mr. Ross speaks and gives popular public seminars across the globe. His blog: http://www.ronross.info/blog/ . Twitter: Ronald_G_Ross

Rate this:

COMMENTS

Posted on Monday, May 14, 2012 12:28 PM by
ajmarkos
Ronald:

You say: "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.) "

Some corrections are needed. First: Data Flow Diagram is a business process model.

A business system consists of manual and/or automated processes interacting, with processes decomposing into procedure. At higher levels of abstraction, business systems are notorious for being very non-sequential; there is no identifiable sequence. One of the major reasons data flow diagrams where created is to document the non-sequential nature of processes (procedure) at the bigger picture level."

A major fault of modern day process modeling techniqes like BPMN is that they are sequential in nature. This renders them inappropriate for larger scale efforts where decomposition, via first coming up with the bigger picture, is needed to handle complexity.

For bigger picture process modeling efforts, a big-picture-oriented process modeling technique is needed: Data Flow Diagrams.

To handle the details, after decomposing a complex system using DFD's, the BA then switches over to a sequence based technique for analysis in the small.

Also real important: I know that the BABOK says something to the effect that DFD's are for modeling computer systems, and that Business Process Modeling techniques are for modeling, well, business processes. This is flat out wrong. Data Flow Diagrams are just as appropriate for modeling 100% manual business processes. The DFD data store symbols, for example, are not meant to just represent data files. They can just a appropriately represent in/out baskets on someones desk, or a Work In Process storage area next to a milling machine on a factory floor. There is nothing "computery" about DFD's, they can be used for "computery" systems, but they do not have to be.

Tony



ajmarkos
Only registered users may post comments.

Do you twitter?: If you want short updates on what's going on in the BA world and at ModernAnalyst.com, simply follow us on Twitter: http://twitter.com/ModernAnalyst



Featured Digital Library Resources 

Copyright 2006-2014 by Modern Analyst Media LLC