This is a part of a continuing series of articles about the basic information required to understand business processes.  In a previous article, I wrote about the high-level concepts of IGOEs.^[1]  I explained each of the concepts of the IGOE:  Input, Guides, Outputs, and Enablers.  In another article, I selected just one element of the IGOE acronym, the 'Guides'.^[2]  In that article, I explored one of the questions that guides help us answer about a process, "How do decisions get made?"  That article took a high-level look at guides and how they provide the data required to understand decision criteria and business rules.

In this article, we will examine in more depth how business rules can be extracted from the guides and how all of that information can be aligned and traced through all the processes that use it, creating "one view" of the rules.  We will also explore how capturing the guides for processes provides value to an organization to the detail level of Business Rules.  For this purpose, we'll use the payment of a bill to explain the concepts of starting with company policies and driving down to business rules.

Figure 1 is an example of an IGOE for bill payment in an organization.

Figure 1.  Pay Cell Phone Bill — IGOE 

In looking at the guides for this process, we can see that there are several variations of the company policy that apply to this process.  For clarity in the example, they have been broken down into:  company policy—Finance, company policy—Sales, and company policy—Accounting.  Normally, we would just document "company policy" as one guide.  We also have "Bill Payment Procedures" as a guide, along with the bill itself and the Excel spreadsheet that is used to enter some of the information regarding the bill.  The focus of this article will be on the Company Policies for Finance and the Bill Payment Procedures.

In the same way that we decompose (or break down) the details of a process, we can also break down the details of the different types of information that are used or referenced in a process.  Figure 2 is an example of the conceptual decomposition of a company policy.

Figure 2.  Conceptual Decomposition — Company Policy 

If we were to look up in the Company's Policy and Procedure Manual under the topic of Paying a Cell Phone Bill, we would find the following information in some kind of document format.

Company Policy:  Paying Cell Phone Bills

Pay all Valid Cell Phone Bills by Due Date

Then, if we looked in each Department's Policy guide, we would find the policy information in some kind of format similar to the one below.  There would probably be policy reference numbers and version references as well so we should be able to tell whether we are looking at the latest version of the policy.

Department Policy:  Paying Cell Phone Bills — Finance

• Review all cell phone bills for reasonableness;
• Track monthly charges;
• Ensure only domestic charges are paid by the company;
• Validate correct approvals.

Department Policy:  Paying Cell Phone Bills — Sales

• The company will pay for domestic cell phone calls within established limits;
• Employees are responsible for amounts over the set limits;
• Manager must sign off on approved bills;
• Finance is responsible for research and resolution of exceptions with the phone company.

Figure 3 is an example of a specific company policy related to "Paying a Cell Phone Bill" that has been broken down in a somewhat graphical format.  This format enables us to see the relationships between the various policies and procedures in the Company.

Figure 3.  Decomposition of a Specific Company Policy 

It is easy to see that everyone is following the same basic company policy "Pay all Valid Cell Phone Bills by Due Date."  However, each department addresses the compliance to this policy in its own specific way.  This example shows only the breakdown for the Finance department.  In addition, each person at the Task Level also has his/her own specific agenda and responsibilities.  As we begin to break each of these tasks down to even lower levels of detail, the specific business rules begin to emerge.  For example, the rule "salaried employees are employees who are not eligible for overtime and/or hourly pay" should be the same rule we would see if we looked at some of the organization's human resource-related processes or perhaps even in some of the other areas of the company where approvals are required.

Figure 4 is a diagram representing the decomposition of the Pay Cell Phone Bills process.

Figure 4.  Decomposition of Pay Cell Phone Bills 

For the purposes of this example, we will focus on the Review Cell Phone Bill branch of this decomposition/ node tree, as shown in Figure 5.

Figure 5.  Review Cell Phone Bill 

The details of the "company policy" for Finance as it relates to Review Cell Phone Bill are in bold in the bulleted list of Figure 6.  The bulleted list represents the job procedure for the role performing this activity.  The bulleted items not in bold refer to the tasks necessary for compliance with different departmental policies.

Figure 6.  Job Procedures of Review Cell Phone Bill  

As we continue to break down the details of this activity into its specific Tasks — Check for Reasonableness and Enter Bill — we can also break down the part of the departmental policy that applies to these specific tasks.  In Figures 7 & 8, the bullets at the top of each diagram represent the specific portion of the job procedure that applies to this work, and the larger bulleted list to the side labeled (respectively) "Business Rules:  Check for Reasonableness" and "Business Rules:  Enter Bill" represent the business rules that specifically apply to these job tasks.

Figure 7.  Business Rules:  Check Reasonableness  

Figure 8.  Business Rules:  Enter Bill 

Figure 9 is just another way of looking at the relationships between the policies, procedures, and business rules.

Figure 9.   Alternative View of the Relationships 

Representing the relationships in a graphical format enables an organization to better understand the relationships and also to see where there are gaps in those relationships and/or overlaps and redundancies.  This information is difficult to analyze and improve without a clear way of understanding and viewing the improvement opportunities.

In Summary

The most important concept from this article is that it is invaluable to understand how an organization's policies and procedures are impacting the organization at an operational level.  It's also critical to understand the significance that a change to a policy can have on the operational efficiency and effectiveness of an organization.  In addition, as an organization matures and begins to appreciate the opportunities that a business rules approach provides, organizations that have documented and analyzed their guides as part of their process management efforts already have a majority of the information they will need to move forward with, and take advantage of, all the benefits of a thorough business rules approach.

The same decomposition of information that this article has applied to guides can be applied to inputs, outputs, and enablers.  Applying these concepts to inputs and outputs allows an organization to understand all the relationships between the information in the processes, down to the data entity level and the systems or other sources for this information.  This becomes invaluable when considering the enhancement, replacement, or purchase of new technology to support the business.  It also makes it clear that separating process and data should never happen, just as separating process and rules should never happen.  Since business processes are how we deliver value to our customers, all aspects of those processes can contribute to or constrain an organization's ability to deliver value.

As always, remember to start at the top and "Keep it Simple!"

[1]  Kathy A. Long, "What is an IGOE?," Business Rules Journal, Vol. 13, No. 1 (Jan. 2012), URL: http://www.BRCommunity.com/a2012/b634.html  

[2]  Kathy A. Long, "IGOE — Link to Decision Criteria," Business Rules Journal, Vol. 13, No. 5 (May 2012), URL: http://www.BRCommunity.com/a2012/b653.html  

# # #