You might ask why you should be concerned about business rules if you are already busy process modeling, improving your business processes. The simple answer is that one does not work without the other.
Business processes describe how an organisation delivers value to its customer and other stakeholders. It outlines the activities and variations that a process is made up of in different levels of detail. These activities are executed either by a human being (with or without the support of technology) or are fully automated. However, nearly all business processes have decisions to be made about them.
The outcomes of these decisions define what the next activity in the process will be. Again, these decisions are either made by a human being, or by a technology using some form of logic. One of the key areas where we use business rules is to guide the outcome of a decision. Some of these decisions are critical to your success in the market, or even for the survival of your organisation.
For example, if you are a bank and a potential customer enquires about a large loan for a development project, how do you make sure that your employee has taken all relevant factors into account when deciding to grant the loan or not? How do you define who can make this decision?
This is where business rules come in.
Some people say you can model the process with the relevant criteria and possible outcomes, and then show in this process when to approve the loan, when to reject it, and who can do which activity.
Interestingly, I have seen many examples where these rules are modelled in processes. The main reason why business process models are very complex and hard to read is that modellers include business rules logic in the flow of the process model. Every time one criterion is changed, added or evaluated differently, the process model must be updated. To automate the process, it means that either the implementation needs to be changed every time, or that the consultant will translate these into system rules and then execute them, ideally via a business rules engine.
The example process below uses rules for every process step as they guide each activity. While some of these process steps might include a set of business rules and/or decision table(s), others might have simpler rules, like what medium (email, letter, phone call, etc.) to use when communicating with the customer.
The defined rules should be linked back to the business processes and relevant individual process activities.
Here’s an example of business rules:
|
Example using RuleSpeak® |
|
A loan application for an amount smaller or equal to $1M must be completed within 10 business days. |
|
Business attire must be worn during working hours. |
|
A customer may only be deemed ‘gold customer’ if he has an approved loans equal to or more than $1M, and has not defaulted on any loan repayments. |
|
A customer must be considered ‘black listed’ if at least one of the following is true: - He has defaulted on loan repayments more than three times in one financial year. - He has no income for more than 12 consecutive calendar months. - He is not an Australian citizen and has a negative credit rating in the country of origin. |
Rather than modeling business rules logic in a process model, one should express them as a single or set of statements, or as a decision table. There is a web page dedicated to Rule Speak -http://www.rulespeak.com/en/, and here it explains how to express business rules in ways that business people can understand and manage them.
Download the paper below to read more about why we should spend more time on business rules.