There seems to be an ongoing debate regarding process and business rules.  If there is no formal process then how would people know which rules to use or what work to apply them to?  If we have processes defined, but have no rules to guide them, nothing will happen.  In fact, both concepts are essential and both must exist.

For eighteen years I've been explaining process concepts to people.  To understand a process we often use a graphical notation to represent our knowledge.  However, the majority of individuals I encounter documenting process are only capturing 50% of the 'types' of information they need and potentially only 15% of the 'knowledge' they need to understand and/or improve process.  The typical process model will look like a 'flow'.  It will have inputs and outputs and lots of decision diamonds.  And for years people have assumed this was sufficient information to allow them to make decisions about changing and/or reacting to process/problems.  In most instances these diagrams are at an extremely detailed or low level.  With all this apparent 'detail' it has been assumed that there is more than sufficient information to understand and analyze processes.  Figure 1 provides such a diagram.

Figure 1.  Receipt and Payment of a Cell Phone Bill

This diagram represents what is happening in a relatively simple process, Receipt and Payment of a Cell Phone Bill.  This process is for a relatively small company, with locations only in the United States, which was growing very rapidly.  In the course of their first year they expanded from using no cell phones to over 500.  (There will be a series of columns that will examine different aspects of their growth and its impact on their processes, their ability to document those processes, and their ability to analyze and improve those processes.)

In order to completely understand this process, I'm including ­— along with this diagram — a description of the process from a policy perspective.  There are basically four departments involved in this process.  The department policies are as follows:

The Finance Department Policy:

• When the cell phone bill is received from the phone company (Cell Company),
• Determine if the bill is reasonable based on predefined budget parameters
• If not reasonable, send back to Cell Company
• Otherwise,
• Enter charges in an Excel spreadsheet for tracking
• Send the bill to Sales for review and approval
• If bill is not received in 3 days, send email to Sales Admin for follow-up
• When bill is received back from Sales,
• Review the bill for correct approvals
• Send the bill to Accounting for payment.

The Sales Department Administrative Assistant Policy:

• When the cell phone bill is received from Finance,
• Review the bill to assure that set limits have not been exceeded
• Amounts over the set limits will be paid by employees
• Bills with international charges will not be paid.
• Send the bill to Sales Manager for Approval
• When bill is received back from Sales Manager
• Verify that the bill has been signed.
• If not signed, send back to Sales Manager for signature. 
• Send the signed bill to Finance for final review and payment. 

The Sales Department Sales Manager Policy:

• If charges appear unreasonable, send to Finance for follow-up with Cell Company
• If the charges include international calls, send back to Finance.
• Otherwise,
• Approve the phone charges.  Send to Finance for payment via Admin.

The Accounting Department Policy:

• When bill is received from Finance,
• Send payment of bill to Cell Company

The reality is that these diagrams — as detailed as they are — provide very little useful information when it comes to trying to determine where the real problems are in the process and what the potential solutions might be.

In fact, there are four types of information/knowledge necessary to accurately understand processes and make the appropriate changes.  In addition to Inputs and Outputs, two other types of information are required.  These are Guides and Enablers. 

Guides are something that determines why, how, or when an activity occurs.  Guides include:

• Any type of starting and completion events related to the process
• Time based
• Receipt or Sending of things or information
• Any type of information used as reference material during the process
• Any type of knowledge or experience needed to perform the activities in the process
• Business Policies
• Business Rules
• Procedures
• Acceptance / Completion Criteria
• Culture
• Performance Targets
• Performance Criteria

Enablers are something (person, facility, system, tools, equipment, asset, or other resource) utilized to perform an activity/process.  Enablers include:

• Human Resources
• Systems
• Facilities
• Tools
• Equipment
• Any type of resource necessary

This column's focus is on the Guides.  A major portion of Process Guides is the equivalent of Business Rules.  Whether you consider information/knowledge to be tacit or explicit, both types are included as Guides.  To understand the 'real' potential for process improvement, the Guides must be documented and understood.  Often process documentation/diagrams do include some of these Guides as rules in the form of decision diamonds.  But they are so buried in the detail it's difficult, if not impossible, to extract them and analyze them separately.  Other Guides are included through the use of some graphic like a box with words like 'send' or 'receive', which are not activities at all but events that occur in the process.

Figure 2 shows "x's" over information that represents some type of 'Guide'.  Decision points and events are considered Guides. 

Figure 2.  Guides in the Receipt and Payment of a Cell Phone Bill

The problem is two-fold.  First, not all Guides are represented in the flow.  Second, this type of flow can and does become so complex in its representation that all hope of having an intuitive picture of the process is lost. 

A more appropriate and useful diagram is represented in Figure 3.  If we use this diagram, along with our knowledge of what the policies are and all the other factors that are Guides to this process, the understanding and analysis of this process becomes more obvious to everyone.

Figure 3.  An improved view of the Receipt and Payment of a Cell Phone Bill

For example, without the decision diamonds and events cluttering up the picture, we can see that this is a relatively simple process that has been made complex by trying to incorporate just some of the Guides.  From an analytical point of view it would suggest that most of our focus on fixing this process should be on fixing the 'guides' or 'business rules', not necessarily the 'flow' of the process.

In this more simplified version, it is immediately apparent that there are 'three' review activities.  This should certainly raise the question of which of these, if any, adds any value to the process.  A more simplified view allows analysts to focus more easily on things like value-add, flow, sequence, and roles and responsibilities without all the other clutter to distract.

In fact, this being the case, the new process might look like the one below.

The conclusion we should be able to make is:  the simpler the 'picture' of the process, the better the picture.  Process models are a means of communicating knowledge and understanding of process.  As such, we must not get lost in the detail, believing that with detail comes understanding and enlightenment.  The reverse is almost always the case.  This company was able to take a process that had eventually grown into a fifteen-day process and reduce it to four to five minutes because they were able to focus on the really important aspects of the process — the 'guides/rules' separately from the 'flow' of the process.  The simpler, the better.  So, please "Keep It Simple"!

# # #