Global Processes and Business Rules

We’ve written before about the importance of separating rules from requirements, particularly in use cases. We wrote that with the goal in mind of reducing the costs of system maintenance. Low-level rules like decision, calculation and inference rules tend to change frequently – and independently of other requirements. So a documentation approach that separates these rules from requirements can both reduce implementation costs (by encouraging separated implementation) and reduce the time required to manage and approve changes.

There are also benefits to abstracting high-level, or procedural rules, when dealing with global business requirements.

Global Businesses

When companies get large enough that they start operating globally, they face an additional level of complexity in managing their processes. And with that management burden comes the additional complexity of managing the software that implements those processes.

Global businesses usually don’t have the luxury of using the exact same processes, procedures, and rules in every company in which they operate. They also have to deal with nasty problems like selling a product from one country to a customer in a second country, with a delivery address in a third country. And the product may be shipped from a fourth country. Now imagine that the order is split to deliver portions of it to each of multiple destinations. And imagine it is further (orthogonally!) split because the products are being sourced from multiple locations. That’s a lot of complexity. How would you approach managing the requirements for something like that?

Let’s keep it simple and just imagine dealing with different processes and procedures in different countries. Global businesses usually organize around regions, like the Americas, Europe, Asia, etc. There are no formal rules to this organization, but the regional definitions are mostly consistent. Within some of those regions, there are often variations in how the business operates within countries in those regions. US Companies usually treat domestic US business differently than they would Canadian or Mexican operations – even on the same continent. And Europe, Africa and the Middle East have even more variation and distinct differences between countries.

Regional Growth

When companies grow into multi-national organizations, they don’t initially start in “every country” and then gradually grow all of the divisions in lock-step. Companies rightly focus on a single country until they are driven to grow into other countries. Then they establish footprints in those countries, grow those businesses, and eventually reach a size where they need to organize regionally.

The businesses in those countries and regions are usually given both guidance and latitude in the development of their businesses. As a result, the company will both develop new processes and extend existing processes into the new countries. Imagine a company like Caterpillar or John Deere that sells heavy construction equipment around the world. The company initially, likely, both manufactures and sells all of the vehicles in the same country. Then the company begins exporting vehicles to the other countries. Eventually, the business grows until the company sets up shop in the foreign country.

The company is now doing the same things in multiple countries (at a high level). Selling vehicles, leasing vehicles from a maintained fleet, financing purchases, etc. Consider the business of leasing vehicles – different countries have different cultures that approach borrowing differently. They also have different regulations about leasing versus sales. Our company may even decide to partner with a local third-party company that manages a fleet of lease vehicles for them in one country, while maintaining their own fleet in another country.

The people running these country-specific businesses have to react to local issues, regulations, and market dynamics. Success in those countries may require different operations than success in the home country. And the people responsible for these businesses are usually able to “do what it takes” to be successful in the different countries.

Global Processes

Now the company is faced with the situation where the same process (leasing a vehicle) exists in multiple countries or regions. At the same time, the process is different in each of the countries, because of the differences in how the business operates in those countries.

The company now has the same process defined multiple times. And that process is defined not only based on local influences, but also corporate policies, the policies that are in effect in the country where the company is based (and therefore reports income, etc), and those things that are common across the regions.

This means there is both variation and duplication in the process. And that creates opportunities for improvement.

Consider a use case that is part of a global process. For the vehicle leasing process, a use case (or sub-process) may be “Approve credit of lessee.” The company requires that all leases be made only to people who have been approved as credit-worthy. But determining credit-worthiness can vary by country. And the process required to determine credit worthiness will vary by country.

Variation by Country

Consider the definition of credit-worthiness. This is defined for a single country with a set of rules that represent the results of an actuarial analysis that does a risk-scoring process designed to weed out unprofitable loans. The credit-worthiness of a lessee in a third-world country would necessarily be different than the analysis in a major industrialized nation. And that means a different set of rules.

What about country regulations? There are different privacy laws in place in different countries. You may be allowed to contact character-references in one country, but not in another. You may have access to three years of records in one country, and seven years in another. These variations in regulation affect what you are allowed to do in the different regions.

And the businesses in different countries have evolved their processes independently over time. One business may choose to pre-approve a lease for repeat customers, while another country may require credit checks for all new leases.

These differences make the goal of globalizing processes and requirements seem insurmountable.

Why Globalize Requirements

There are many reasons to understand processes at a global level. Let’s look at just one. Reporting. Management accounting is the science (or art, if you ask a financial accountant) of inspecting measurable elements of your business so that you can make informed decisions about how you run your company. Being able to understand, analyze, and measure the same process in every country of the world provides benefits in strategic reporting and decision making. This consolidation can also be valuable for financial accounting and reporting of business performance for public companies. Making good management decisions is enough of a reason, so we’ll ignore the added financial accounting and external reporting benefits of a consolidation.

OK, so your construction equipment company operates in multiple countries. And you lease equipment in multiple countries. You want to know how profitable your leasing business is. Each country has developed different processes for leasing, with different rules for determining details like who to approve for a lease, and different calculations of profitability. For example, one country may monitor gross margins, another may track contribution margin. What about the rules for revenue recognition? One country’s business may recognize revenue at the time of signing a lease, while another may recognize revenue only when the payments are due (or when payments are made).

To get better control on your businesses, or more specifically, more consistent reporting, you need every country to follow the same process. Even though the “business” in each country needs to be handled slightly differently.

Consolidate Requirements

One approach is to take all 50 countries, analyze all 50 process variations, document 50 different use cases, and determine the proper reporting for each of the 50 situations. That’s a lot of analysis work. And a lot of risk to the reporting effort. You avoid disrupting the individual businesses, but you may make mistakes in any of the many analyses. And whenever any of the countries has a change in regulation, or when any of the businesses in those countries has a change in process or policy, you have to review and update your process, use case, and analysis for that country.

Another approach is to mandate that everyone follow an identical process – come hell or high water. This is completely impractical. For some countries, this will work. For others, this will force the businesses to operate at a competitive disadvantage (remember, there was a locally rational decision to deviate in the first place). And in the worst case, you may be “requiring” the business to operate illegally (or prevent it from operating at all) in some countries.

A third, more reasonable approach is to look for a common abstraction. Develop a description of the process and use case that applies to all of the countries, while allowing for a representation of the variations. This might encourage individual countries to make changes to their processes (in order to appear more consistent with the rest of the business), but it allows them to continue to deviate.

How is this possible – we’ve identified that each country has a different process, so how can the same process documentation be correct for the different countries?

Business Rules Provide the Abstraction

Most of the variations in process identified in the example above are really variations in rules, happening within similar or identical processes. Think of it from a use case perspective – here’s a snippet from the normal flow of the “Approve Credit” use case:

1. Lessee submits request for financing.
2. System approves lease per BR01, Credit Approval Rules.
3. Lessee confirms intent to lease.
4. System reserves vehicle.
5. …

The key is the abstraction of Credit Approval Rules. Even though those rules vary by country, all countries will follow the flow defined above. Note – this does not address the case when the processes are structurally different.

Then, within your business rules repository (or spreadsheet, or wherever you maintain the rules), you will have a ruleset (BR01) that defines when credit is approved and when it is rejected. What you can do is define different rulesets for different countries (or regions). BR01-USA, BR01-Canada, BR01-Mexico, etc.

When the business within a particular country changes its credit approval criteria, you only update those rules – and not the process or use case documentation. The use case remains unchanged.

In our calculate profitability example, you will need to either require the businesses to calculate the same way, or, because the data will be consistent, you can aggregate and report on the information at a global level – taking into account which transactions happen in what countries.

When Processes Are Structurally Different

What about when the process is significantly different in some countries? Perhaps the system reserves the vehicle in advance of qualifying the lessee (pre-approval of the lease)? We have a different process. Technically, it is a variation on the same process – the process would share the same name and have the same high level description. Only in the details would it be different.

We get to “make up an answer” here, I think – I don’t know of anyone who has standardized on a good solution for this problem. There are two reasonable obvious approaches that come to mind.
The first approach is to define multiple use cases, and organize them hierarchically beneath the original (global) version of the use case. If the use case is “UC01 Approve Credit”, then you would add “UC01A” or “UC01-USA” to reflect that this use case is a variation on the first one. Then you would trace the special case use case to the global use case.

This works, and minimizes redundancy, but it could be confusing to deal with this added complexity, in light of subordinate use cases, use case versions, and tracing of requirements. Would the requirement for “User submits application” be traced to UC01, or UC01, UC01A, etc.? You would trace to all variations for which the requirement is required. Each country-specific implementation team can then look at each use case and say “Do we use the global one, or do we have a special variation?” The team would then know precisely which requirements they had to implement.

Another approach would be to define the global use case – “UC01 Approve Credit”, and then for each country that has an alternative process, define an alternate flow through the use case. This takes care of the confusion with subordinate use cases and versioning. And it reduces the need for redundant tracing. But it makes the individual use case harder to read. And since most software today only traces requirements to use cases (and not individual steps in the use cases), it makes it harder for the implementation teams to know which requirements they have to implement for their countries variation.
Ultimately, we document requirements to foster improved communication. An approach that makes a use case harder to read (and approve), or harder to implement (or trace dependencies) is not as good as one that might make repository-maintenance more difficult, while improving the ability of the teams to understand both the contents and the dependencies of use cases.

Summary

Global businesses have variations in processes and use cases in the different countries where they do business. Documenting the individual processes leads to redundant documentation of requirements, makes it more difficult to analyze the processes (including reporting and accounting), and does not help in standardization of practices.

Abstracting rules, and finding commonalities in process patterns allows for consolidation of process documentation – which improves communication and analysis of requirements.

Utilizing alternate use cases to represent when individual companies or regions deviate from the global standard allows businesses to deviate their processes when needed, while minimizing the impact on making and managing changes to the processes across the organization. It also provides a framework for analysis, tracking, and encouragement of standardization of processes across a multi-national company.