To speak plainly, most companies have no coherent strategy for integrated compliance. Laws, regulations, contracts, deals, agreements, guarantees, warranties, etc. all represent business obligations, the very essence of business rules.

What form of traceability is needed for business obligations? Traceability from governing rules to automated rules, where:

• Governing Rules include acts, laws, statutes, regulations, contracts, MOUs, agreements, terms & conditions, deals, bids, deeds of sale, warranties, guarantees, prospectuses, citations, certifications, notices, and business policies
• Automated Rules include code tables, parameter settings, procedural code, implementation rule statements, help messages, etc.

Governing rules provide the baseline for running the business. These governing rules must be interpreted and supplemented, ultimately getting implemented in a wide array of platforms and tools.

In most companies today there is virtually no traceability for obligations between governing rules and automated rules. There’s an abyss, a big black hole, where there should be ready knowledge. Where does that leave the company?

• Companies’ corporate memory is riddled with disconnects and gaps. Going back in time, it is difficult or impossible to determine who interpreted what governing rules into what implementation components, or why they did it the way they did.
• Companies consequently are deeply dependent on hero-professionals to retain tacit knowledge. You hope they remember things correctly and thoroughly – and that they don’t leave the company.

A solution to the compliance challenge requires rethinking and reworking the traceability landscape for obligations to feature three layers of rules, not just two. The middle layer, practicable rules, is key.

practicable rule: an expression of a business rule that a capable (authorized) worker can read and understand and decide directly whether or not the business is in compliance in all circumstances to which the rule applies

Practicable rules are ones you can run the business by, whether or not ultimately automated. They should be expressed in structured natural language (e.g., RuleSpeak^®) based on business (not IT or data) vocabulary. Here is an example:

An account may be considered overdrawn only if cash withdrawal is greater than the current balance of the account.

The acid test for whether a business rule is practicable is this:

You can give the statement either to a knowledgeable worker for use in day-to-day business operations to apply manually, or give to IT for implementation in an automated system, and get the same results either way.

Is that possible?! Absolutely!

The re-engineered landscape for compliance and traceability reveals the two distinct interpretations that need to be tracked:

1. First, governing rules are interpreted into practicable rules.
2. Second, those practicable rules that can be automated (by no means all of them) are interpreted into specifications that automated platforms can execute.

The key to operational excellence for compliance is committing both kinds of interpretations explicitly to automated corporate memory right as they happen.

By the way, business-side rule management does not have to be pursued at an enterprise scale. You can start out at any scale, including the project level. 

~~~~~~~~~~~

Read more about the Big-5 business challenges: http://www.brcommunity.com/articles.php?id=b904

Compliance in a broad sense means satisfying obligations and delivering on promises. Even high-quality customer service involves compliance of this kind – your products and services are always what you say they are, and your delivery of them meets customers’ expectations.

Some critical observations:

 

1. Laws, regulations, contracts, deals, agreements, guarantees, warranties, etc. all represent obligations, the very essence of business rules.
2. These obligations are constantly amended, extended and (sometimes) terminated, so you need direct traceability for them.
3. The typical IT view of traceability is far removed from what the business actually needs to manage obligations.

Many professionals are so immersed in system development they cannot easily separate the notion of obligations (business rules) and requirements – e.g., specifications for modifying some system feature or procedure. Say ‘traceability’ and they immediately think traceability for requirements.

How system development needs to trace requirements into system designs is a very different proposition than the traceability needed for business obligations. The two kinds of traceability can and should be separated.

• Requirements are about building systems, whereas business rules are about running the business.
• Requirements generally fade into the background when a system is delivered, whereas deployment sparks a whole new phase of life for business rules.

~~~~~~~~~~~

Read more about the Big-5 business challenges: http://www.brcommunity.com/articles.php?id=b904

Question: Do business rules derive from strategy? Answer: In our experience only about 2-3% of a company’s business rules derive directly from strategy (goals and objectives). Needless to say, those are a critical 2-3%. The rest of a company’s business rules concerning behavior derive from regulations, contracts, agreements, business policies, warranties, deals, certifications, etc. Let’s call all those obligations. Every business has a choice of whether to comply with its obligations. Generally speaking, the risks of not doing so will be high in a good many (though not all) cases. So there’s certainly something to be said for being a good corporate citizen in a free enterprise system. The key is to make sure all business rules align with strategy, even if most don’t derive directly from it.