Perspective 4 – Business Rules (Part 1)

It is time for our next perspective!!!  We are now moving into “Perspective 4, Business Rules.”

For those who may just be joining us, this year I have been focusing on the different perspectives on understanding your organization.  So far, we have discussed 3 of the perspectives which are: The Organization, The Customer, The Process.  Today, we move into Part 4 which is about defining, identifying, and writing business rules.

As you look through these different perspectives and start to uncover how the organization in which you work operates, you have come across business rules along the way. Whether you knew it or not, you have probably identified some as you discuss the customer experience, and as you mapped/modeled processes. That said, remember that it is not a good practice to process map/model business rules. Doing so will add complexity to the process map/model that will make it very hard for the audience to consume and follow. However, business rules are very important to capture and can tell you a lot about your operations.

Let us start with what a Business Rule is. In its simplest definition it’s a rule that defines or constrains some part of the business operations. The outcome of the rule should either be true or false. Business rules are extremely important to capture and understand in your business as many of these rules can help organizations stay compliant with policies or regulations that may govern their organization.

Let us go a little deeper and look at how to identify, write, and store business rules.

How to identify business rules

As stated above, a business rule is a rule that defines, or constrains, some part of the business operations. Business rules are typically owned by the business, unless of course the organization in which you work is set up in a hybrid function with business and technology mixed, but typically the rule should be owned by the business. Business rules tend be static, and not change much over time. However, that does not mean they do not, or will not, change.

One way to identify a business rule is if the business owner needs to make a decision. This is not always the case because not all business rules are decisions, but this is why it’s common to see business rules in process maps/models, because the person creating the process map tries to document every single decision that is made in the process. Let me tell you a story of where I have witnessed this firsthand.

I was working on a project where the business was mapping a new process for the organization. This process was going to be a game changer in the industry so there was a lot of pressure to get everything right. I remember walking into the room where the process was being documented with sticky notes (to make it easier to move and change the process as discussions occurred) and I saw over 20 decision symbols. The process took up half of the conference room. When I started asking questions around all the different decision points, it became evident what was being documented were business rules. You see, the team was documenting every single rule that could qualify a customer for a type of loan. I recommended that all off the rules could be wrapped up into one activity, which stated “Run Eligibility Rules”, From there we created a document that listed out all the business rules and linked that document to the process activity. From that activity either the rules ran successfully, or they failed, and the process went on from those two paths. In this case, the process map went down from taking up ½ of the conference room to a ¼ of the conference room. It was also easier for the audience to follow the process. So, as you create process maps/models determine if your decision points really serve better as a business rule and should be stored in a business rules engine, or some other container, of if the decision should be in the process map/model.

Another way to identify a business rule is if the rule is very specific to how a certain activity, or operational process in the business needs to function. Meaning, it is an easy way for a business owner to determine how he/she needs to conduct business. We will get into some examples below and this will all begin to make sense if it has not already.

Note: I should also mention you will also hear about business rules in the context of database administration. Not only is this where many business rules tend to be stored and analyzed, but they are very useful to database administrators as it alerts them on how relationships need to occur within database models.

Now let us talk a little bit about how you write business rules.

How to write business rules

When you write business rules you want to ensure the business rules are specific and clear. I would also recommend you make them as concise, specific, and attainable as you can. Remember these rules help to define how business owners will conduct their operations or processes, so you want to be as specific and clear as possible. In addition, when the technology teams implement business rules or build solutions leveraging the business rules you want to ensure there is a clear understanding of what needs to be developed. Many of you may already be familiar with how to write a business rule as you may have written them in the past, but I wanted to provide a few examples below if you are not as familiar with business rules.

Examples:

1. A credit check must be performed before an auto loan can be approved.
2. A customer deposit must occur by 2pm Pacific Standard time for it to be available same day for the customer to use.
3. A customer must give authorization before their credit report can be ran.

As you can see above the rules are very specific and advise the business owners how they need to conduct business. These rules would probably be captured in a job aide or standard operating procedure as well, especially when the rules could potentially cause an organization to be out of compliance with regulations. Once you have written your business rule ask yourself:

1. Is the business rule clear?
2. Is the business rule specific?
3. Is the business rule attainable?
4. Can the business rule be tested?

If you have answered “no” to any of these questions, go back and look at your business rule. At a minimum these items should be true.

As discussed earlier, you can identify business rules in many ways. In addition, you can see how it can be tempting to capture these rules in process maps/models, especially if attached to a regulation to ensure there is demonstration of where there are regulatory touchpoints. There is definitely justification to capture some rules in a process map/model, but not all. For example, #2 above could be an example of a business rule that is not included in a process map/module, where #1 and #3 may need to be included before the next activity could occur. However, it really depends on how the process map/module is created, and the purpose of the process map/model.

Now that you have some context around how a business rule is created, in my next post I will discuss how to store these rules once you have identified them.