Mining Business Rules

Photo by Dane Deaner on Unsplash

Photo by Dane Deaner on Unsplash

Business Rules Defined

Business rules define and constrain the behavior of an organization, including its solutions.    Let’s say a business has a policy that it will not conduct business with countries with sanctions against them. The business placed these countries on a "blacklist." The business expects:

  1. Employees to follow the policy. 

  2. Its customer relationship management system to reject leads from blacklisted countries.

  3. Its purchasing system will not enable purchases from blacklisted countries.

Items 2 and 3 implement the company’s blacklist policy as business rules.

Most people think of business rules as policies, decisions, or even “the way we do things,” making rule discovery challenging. Stakeholders mine for business rules in the context of capturing requirements. For example, a business analyst capturing requirements for a CRM solution asks, “What constraints do you have on sales territories?” A manager recalls that the company has a policy against doing business with sanctioned countries, and the CRM solution should not allow leads, accounts, or contacts from those countries.

Fitting Business Rules into Discovery

Confusion sometimes arises between business requirements, processes, and rules. Business rules apply to requirements and processes, as shown in this concept map:

A business rule applies to a process when it influences the process steps. It could even launch a process. For example, a business rule asserts that a lead converts to a contact when it has a purchase timeframe within a specified number of days. When someone updates the purchase timeframe on the lead to meet the criterion, the solution converts the lead according to the business rule.

A business rule should be defined separately from its enforcement, like separating business requirements from their implementation. In our first example, the business used the country blacklist rule in three different ways.

Maps to the Rules

Mapping concepts and processes when capturing requirements provides a source for mining business rules. A concept map shows relationships between an organization's entities - people, places, and things. Here is a map showing some Salesforce account concepts:

The map shows an Account presenting an Opportunity. When does the business record an opportunity? The process map below shows opportunity creation in step 3 when a sales representative qualifies the account in step 2:

What qualifies an account to have an opportunity? Sales management decides that an account should have at least a medium interest level and intend to purchase within 90 days to qualify. These two conditions form the premise of the account qualification business rule.

Once a business rule emerges in discovery, a stakeholder, such as a business analyst, should document the rule for implementation and reference. If the rule applies only to a process step, like the account qualification rule, the process map can include it. Elements.cloud, used to create the process map above, has a feature to attach a table to a process step. For example, the table attached to step 2 (Qualify account for presentation) shows the account qualification criteria:

Sales_Happy_Path_Qualification_Criteria.png

Rules that apply in multiple cases, such as the blacklisted countries, should be documented in one place where each enforcement case can refer to it. 

Other Business Rule Sources

Business rules often come from the minds of stakeholders, like the sales managers defining the account qualification business rule. Documenting rules makes a meeting of the minds easier, especially when people have different ideas about a business rule.

Sometimes a legacy system enforces business rules, making them easy to overlook in discovery.  Business analysis should extend to legacy systems, even when the business intends to change the rules and processes. The legacy system may have enforced the rules for valid reasons.

In some cases, a regulatory agency has a business conform to its rules. The agency should make those rules explicit, with little need for discovery.

Summary

Every organization has its rules, even though it rarely defines them as such. They typically manifest as policies, “the system,” or even management folklore. Curating business needs into requirements should bring business rules out into the open for clarification, documentation, and enforcement in a new solution.

Mining for business rules is easier said than done. It requires looking at what drives each step of a process, especially decisions. 

Business rule enforcement can happen when data changes. For example, “assign lead to sales rep.” and “convert lead to contact” imply rules specifying a lead’s assignment or conversion when it changes.  

Business rule discovery pays off with clarity into how and why a company makes decisions, processes data, and operates within constraints.

Previous
Previous

Four Business Analyst Misconceptions

Next
Next

Diving Deeper Into Requirements