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

Software vendors and others mislead people (badly) about the true meaning of business rule. Let’s set the record straight. The OMG standard SBVR (Semantics of Business Vocabulary and Business Rules, 1.4) defines business rule as a rule that is practicable and is under business jurisdiction. The definition has these three parts: (1) rule, (2) practicable, and (3) under business jurisdiction. Let’s look at each part in turn. 1. Rule Rule in business rule means real-world rule – in other words exactly what the dictionary says rule means. Here are the relevant meanings of rule from Merriam-Webster Unabridged Dictionary [MWUD].

guide for conduct or action [MWUD ‘rule’ 1a]

one of a set of usually official regulations by which an activity (as a sport) is governed [e.g.,] *the infield fly rule* *the rules of professional basketball* [MWUD ‘rule’ 1f]

A real-world rule always tends to remove a degree of freedom.  If it does not, it’s not a rule. Also, a real-world rule is declarative. It never does anything. It merely shapes behavior or decisions. If you’re using an approach where rules can actually do things (e.g., execute an action, set a flag or variable, call a function, etc.), they’re not business rules. You’re in TechnologyLand, and a procedural one at that. 2. Under Business Jurisdiction    Business rule includes only rules that the business can opt to change or to discard. A business rule is always under business jurisdiction of your organization. The important point with respect to external regulation and law is that your organization has a choice about how to interpret the regulations and laws for deployment into its day-to-day business activity – and even whether to follow them at all. So external regulations are not business rules per se. Business rules include only the rules that a business creates in response to external regulation. SBVR explains:

“… legislation and regulations may be imposed on [the company]; external standards and best practices may be adopted. 

These things are not business rules from the company’s perspective, since it does not have the authority to change them. 

The company will decide how to react to laws and regulations, and will create business rules to ensure compliance with them.  Similarly, it will create business rules to ensure that standards or best practices are implemented as intended.”

3. Practicable Practicable means a rule is sufficiently detailed and precise that a person who knows about it can apply it effectively and consistently in relevant circumstances. In other words, the person will know what behavior is acceptable or not, or how some concept is to be understood. A practicable business rule is one ready to become a deployed business rule – i.e., applied in day-to-day business activity. Whether the guidance is to be deployed to staff or ultimately to machines is immaterial. You should get the same results either way. Business policies are generally not practicable in this sense. Business rules always are. ~~~~~~~~~~~~~~~~~~~~ Excerpted from: Building Business Solutions: Business Analysis with Business Rules, 2nd edition, by Ronald G. Ross & Gladys S.W. Lam, 2015 Get the book:http://www.brsolutions.com/b_building_business_solutions.php Get the training: Instructor-led, online, interactive training: October 4-6, 2016 – Business Analysis with Business Rules: From Strategy to Requirements. http://www.attainingedge.com/online-training-business-analysis-with-business-rules.php ©Business Rule Solutions, LLC 2016. wwwBRSolutions.com 

Operational business decisions happen every minute of every day in your organization. You’d like to think that business managers can truly manage them. You’d also like to think that the results of those decisions are comprehensively correct, consistent, traceable, and repeatable (high quality). But are they? Based on real-life evidence I strongly suspect they often are not. Let’s be clear what kind of decision I mean. Say “decision” and many business people immediately think strategic decision (e.g., whether to enter some new market), or tactical decision (e.g., which supplier to use for a year-long special project). Those are not the kinds of decision I’m not talking about. I’m not talking about project decisions either. When IT professionals talk about “decisions” they often mean branch points within the deep systemic logic executed by machines – classic decision points in data processing. I don’t mean that either. Instead, I mean decisions in the day-to-day, minute-to-minute bread-and-butter operations of the business. Some examples of such operational business decisions:

• Whether to give a mortgage to a given applicant.
• What discounts a premium customer will receive on a purchase.
• Which customer gets preference if some product or resource is in short supply.

Your business makes these kinds of decisions hundreds or thousands of times a day – or hour, or minute. These are the kinds of decisions that regulators, auditors, and compliance officers care about. The kind your business partners deem important because they are directly impacted.   Are the decisions high quality? At a major insurance company a thoroughly competent, highly experienced business system analyst recently told us: “When we looked hard at business rules currently implemented in existing systems, we found at least 30% were flatly wrong.” After a moment’s reflection he added, “That’s a very conservative estimate; the actual figure was probably much higher.” The organization was just beginning to recognize the magnitude of the problem. And whose problem is it? The analyst said, “IT told us they couldn’t solve the problem because it was a business issue not a software issue. And they were absolutely right about that.” We might have thought this case an outlier if we hadn’t heard similar estimates from credible sources in many other companies. And we’ve found the same ourselves. Not long ago we were asked to conduct an audit of implemented business rules in one area of business for a major North American bank. The results frankly astounded us. We double- and triple-checked. No error. To conduct the audit first we harvested 518 business rules from the relevant Policies and Procedures Manual, the printed (and on-line) reference source for loan officers, and expressed them in RuleSpeak. How many business rules were implemented correctly in their automated system? We found zero – zero! – fully aligned. Some 447 were actually not implemented at all; the remainder just partially aligned. You wouldn’t think it possible but it gets even worse. We found 261 business rules implemented in their system that did not appear anywhere in the Manual. What sort of way of doing business is that?! Who (or what!) is making the decisions?! To put things in proper context it helps to appreciate the costs associated with maintaining legacy systems not built on business rules. In a recent visit to a very large health care organization, a high-level manager cited the following statistics. They’re staggering. He reported it takes their organization:

• 24 person-years per year to maintain a 30-year old monolithic COBOL legacy system.
• 400 person-days over a 4-month period to make changes to business rules of ‘moderate’ complexity.

The manager admitted sadly, “Truth be told, we work for our legacy systems, not the business.” Beyond these frightening costs the manager also described how a subtle stagnation had crept into the staff’s very way of thinking about their business. “Our business leads are so familiar with the limitations of our legacy systems, they don’t even consider business innovations they know from experience to be difficult for the system to handle. Sometimes I wonder if they can even think through innovation effectively anymore.” With variations it’s a story we hear time and time again. The need for innovation is ever more immediate, but the reality of achieving it ever so distant. Who (or what) is making the decisions is in your organization?! At BRS, we have dedicated ourselves to pioneering innovative techniques for achieving order-of-magnitude improvements in how businesses literally operate themselves. We offer no silver bullets. It’s heavy lifting to put an organization onto a different track with respect to their core knowledge practices. Is it worth it? Absolutely. When we see control over decisions coming back where they belong – into the hands of business managers – the results are always extremely rewarding.

When my older son graduated from college, he worked as an intern for a professional sports team.  At the end of his very first day of work he called me, puzzled.  “I asked them what my responsibilities were,” he related, “and they said, ‘We need you to know what we are supposed to be doing’.”  After a long pause he went on, “I wanted to ask them why they didn’t already know what they were supposed to be doing, but I didn’t think that would be such a great idea my very first day there.” Let’s see whether at some level that situation sounds familiar to you.  It turns out his area of responsibility had to do with ensuring operational compliance with corporate sponsorship agreements.  The sponsorships are quite expensive.  You might think these agreements would be relatively simple, but of course, there’s no such thing as a truly simple business.  A sponsorship contract:

• Outlines a complex configuration of promotional and other benefits, some automatable and some not, all usually tailored specifically for the individual sponsor.
• Is loaded with obligations, decision criteria, and computation formula (read ‘business rules’) to govern the sponsorship relationship.
• Is amended frequently, both formally and informally (via hand-shake), owing to the dynamic nature of the sponsors’ marketing needs.

To continue the story of my son’s first day, they gave him a stack of contracts and amendments, operational schedules, and invoices and told him to see if they all matched.  Of course they didn’t.  Not by a mile. By the end of the first week, my son had become fairly fluent in the organization’s governance problems.  (Ah, young minds!)  The contracts and schedules were all produced by different people at different times.  Some of the schedules were hand-done and some automated.  But even the ones that were automated often didn’t match the contracts.  The invoices were automated, but in many cases they too bore little resemblance to the contracts.  The IT people were not much help either.  “They seem to speak a different language,” my son reported naively.  Bottom line:  A number of the sponsors were becoming quite annoyed — not a good thing for a mediocre team in a mid-sized market. But there was still more.  The sales reps were, shall we say, quite creative in what they offered the sponsors.  Their terminology, which often found its way into the contracts, was highly idiosyncratic.  Yet they were talking about the same shared resources (e.g., banner boards in the stadium) that had to be coordinated real-time across many sponsors.  They seemed oblivious to some of the company’s rules — even though some, quite literally, were dictated by physics (e.g., a banner board can only say one thing at a time; there is only so much time during a game, etc.). By the way, my son went to one of the team’s games his first week at work.  The team lost.  Attendance was poor.  Sponsors were unhappy.  “I think it’s going to be a season,” he said. After a moment of reflection he added, “You know what really worries me is that I am going to figure all this out, then walk right out the door with all that knowledge.  They’ll be right back where they started.  Doesn’t seem to me like a very good way to run a business.” Welcome, my son, to the reality of business rule mismanagement in the 21^st century!

What business problems do business rules address?  My take: 1. Ad hoc rules: Most businesses have no organized approach for specifying their business rules. As a result, business workers often make up the rules as they go along. This leads to confusion, contradiction, and operational inefficiency. After-the-fact resolution of these problems wastes time and resources and causes frustration for customers and staff alike.

Business rule solution: Business rules ensure consistency in customer experience and provably on-target results for demonstrating compliance.

2. Miscommunication: Misunderstanding of key business concepts inevitably results in miscommunication. Does preferred customer discount mean the same across all departments? If not, what are the differences? What rules apply? Do these rules differ for different areas of the business? Are the rules consistent?

Business rule solution: A structured business vocabulary provides a foundation on which rules can be directly based.

3. Inaccessible rules: Finding out what rules apply to a given business situation often involves an open-ended search through multiple sources. It is not uncommon in the end to resort to the application source code. Pursuing rules in this fashion is time-consuming, inefficient, and inaccurate.

Business rule solution: An organized approach for managing business rules yields order-of-magnitude improvements in productivity and business agility.

4. Massive differentiation: Many businesses seek to support highly individualized relationships with growing numbers of customers and other partners across multiple jurisdictions for ever more complex products or services. How can businesses massively differentiate and, at the very same time, conduct each business transaction faster, more accurately, and at ever lower costs?

Business rule solution: Business rules support highly scalable customization and personalization and provide a structural solution for managing complexity.

5. The need to keep up to speed: Rapid change, at an ever faster pace, is a fact of life. In the digital age, people expect almost instantaneous implementation of changes. How can line workers consumed with day-to-day activities ever hope to keep up?

Business rule solution: Real-time delivery of business rules to knowledge workers creates a seamless, never-ending, self-training environment.

6. Knowledge walking out the door: By and large, baby boomers created much of the basic operational business capacity and operational systems we see in place in larger organizations today. Much of the related knowledge still sits in their heads – and nowhere else. Now they are retiring. On a smaller scale, people with vital operational knowledge walk out the door almost every day.

Business rule solution: A systematic way of capturing, documenting and managing business rules enables pragmatic knowledge retention.

~~~~~~~~~~

Make no mistake, the future lies with automation of white-collar work. Fewer and fewer business problems these days focus on manufacturing and production processes, i.e., the nothing-but-widgets category. For all the non-widget-centric business activity in the world – which includes just about all every conceivable form of white-collar work – the following needs become paramount.

1. Ensuring the quality of meta-data.
2. Demonstrating compliance based actual rules, rather than the artifacts and effects that IT systems produce.
3. Retaining, teaching and repurposing intellectual capital.

What would I do to correct the shortcomings of BPM for non-widget-centric business activity? Our answer is to become more why-centric, as opposed to narrowly how-centric.[1] You should focus on business capabilities, not just business processes. That shift has several essential features:

• Understanding business strategy as something distinct from business processes (and BPM). Business goals and business risks should be drivers of business process design – not the other way around. You need to be strategy-driven, not simply process-driven.
• Designing core metrics around business goals and business risks – the things that concern C-suite executives the most.
• Realizing that for white-collar work the 3-D world of widgets has vanished, and that tolerances and quality can be expressed only in terms of business rules.
• Treating business rules as a first-class citizen, externalized from process models.[2]
• Identifying operational business decisions (based on encoded business rules) as a crucial focal point in re-engineering business processes.
• Including a Why Button as part of every business solution. Pressing the Why Button leads immediately to the business rules that produced the results you see from any process.

~~~~~~~ Read more about the future for processes: BPM and the Knowledge Economy: Nothing But Widgets? http://www.brsolutions.com/2015/11/16/bpm-and-the-knowledge-economy-nothing-but-widgets/ What is the Future for Processes? http://www.brsolutions.com/2015/11/09/what-is-the-future-for-processes/ Are Processes and BPM Relevant in the Digital Economy? http://www.brsolutions.com/2015/10/19/are-processes-and-bpm-relevant-in-the-digital-economy/ Measuring Quality and Defects in the Knowledge Economy: http://www.brsolutions.com/2015/10/27/measuring-quality-and-defects-in-the-knowledge-economy/ Quality and Tolerances in the Knowledge Economy: http://www.brsolutions.com/2015/10/29/quality-and-tolerances-in-the-knowledge-economy/ ~~~~~~~~~~~~~~~ www.BRSolutions.com

	Interrogative	Basic Business Question	Kind of Model
1.	What	What inventory of things needs to be managed to support business activity?	structural model (e.g., concept model[1], data model)
2.	How	How do transforms of things in business activity need to take place to add value?	process model
3.	Where	Where does business activity occur?	network model
4.	Who	Who collaborates with whom to undertake business activity?	interaction model (e.g., organizational chart, use case)
5.	When	When does business activity take place?	temporal model (e.g., schedule, event model, milestone model)
6.	Why	Why are results of business activity deemed appropriate or not?	strategy model (e.g., Policy Charter[2], constraint model)

  If your business does nothing but manufacture or produce physical widgets (forget all the meta-data about those widgets), you will probably emphasize question 2 (i.e., process) above the others. Your overall approach and architecture will reflect that. You will naturally gravitate toward BPM. That tendency has at least three basic risks, even for organizations that do fall into the nothing-but-widgets category:

• Your metrics will largely focus on process productivity (e.g., throughput, bottlenecks, latency), rather than strategic goals and alerts centered on external risks. E-suite executives tend to be much more focused on the latter.
• Your mindset will be procedural, rather than declarative, which can cause you to embed business rules in process flows rather than externalize them. As a result your process models will be unnecessarily complex and your overall solutions un-agile.
• You approach will fall woefully short in addressing the intellectual capital that underlies your processes. Such operation business knowledge ranges from simple meta-data, to the business logic that underlies operational business decisions.

Fewer and fewer business problems these days fall into nothing-but-widgets category. Even for widget-centric businesses, at least three needs are increasingly urgent:

1. Ensuring the quality of meta-data.
2. Demonstrating compliance based actual rules, rather than the artifacts and effects that IT systems produce.
3. Retaining, teaching and repurposing intellectual capital.

These are not strengths of common BPM practices. ~~~~~~~ Read more about the future for processes: What is the Future for Processes? http://www.brsolutions.com/2015/11/09/what-is-the-future-for-processes/ Are Processes and BPM Relevant in the Digital Economy? http://www.brsolutions.com/2015/10/19/are-processes-and-bpm-relevant-in-the-digital-economy/ Measuring Quality and Defects in the Knowledge Economy: http://www.brsolutions.com/2015/10/27/measuring-quality-and-defects-in-the-knowledge-economy/ Quality and Tolerances in the Knowledge Economy: http://www.brsolutions.com/2015/10/29/quality-and-tolerances-in-the-knowledge-economy/ ~~~~~~~~~~~~~~~ www.BRSolutions.com

Quality must be viewed very differently in the white-collar world. The traditional view simply doesn’t fit. In Henry Ford’s day, for example, central to the concept of mass production was standardization of parts. That idea leads directly to the notion of manufacturing tolerances – i.e., upper and lower limits for parts in 3-dimensional space. The goal is to ensure physical interchangeability of physical parts. That idea is now standard practice, of course, across manufacturing and production sectors. But what are the ‘parts’ in white-collar work? White-collar processes simply don’t deal with physical things. How can you identify tolerances for them in 3-dimensional space? You can’t! In a very real sense, the ‘parts’ in white-collar work are literally just bits and bytes. If not tolerances as a basis for quality, then what’s the proper focus? My answer: consistency and reliability of results. For example, if I visit ten different branches of the same bank about getting a mortgage for my dream home, shouldn’t I get the same answer on my application from all 10 branches?! As you perhaps have experienced yourself, that’s not the way it works in many banks today. So one aspect of quality in white-collar work is the consistency and reliability of operational business decisions. Another aspect of quality concerns compliance. Every business is subject to ever growing numbers of (take a deep breath here) … acts, laws, statutes, regulations, contracts, MOUs, agreements, terms & conditions, deals, bids, deeds of sale, warranties, prospectuses, citations, certifications, receipts, legal notices … and the list goes on. Shouldn’t I expect consistency and reliability of results with respect to all those obligations and commitments? I believe we should. If it’s not about quality, then what?! My conclusion:When there isn’t any physical product from a business process, quality and defects must be measured by consistency and reliability of results, which are in turn always purely a matter of business rules. For background on this post, see: http://www.brsolutions.com/2015/10/27/measuring-quality-and-defects-in-the-knowledge-economy/ ~~~~~~~~~~~~~~~ www.BRSolutions.com

Caveat: I reserve the right to change my mind on this at any time and would love to be proven wrong. The key characteristic of many operational business decisions is that they need to be directly traceable to business policy, regulations, contractual obligations, and so on. You need to be able to readily demonstrate compliance in the broadest sense of the word. (That of course has always been true for business rules. That’s what they do!) So for that reason and others, I doubt that IBM Watson and peers will prove viable platforms for execution-time support of business rules. The engineering of rules themselves – rule engineering – will remain professional work for humans to do (hopefully assisted by machines). Fortunately effective techniques for rule engineering have been proven in practice.[1] I know some experts are calling for smart processes or intelligent processes these days. But if they’re not addressing business rules, they’re not really that smart. We want to enable smartbusiness, not just smart processes.  

You can find definitions and discussion of all terms in blue on Business Rule Community: http://www.brcommunity.com/BBSGlossary.pdf ~~~~~~~~ 1. Business Governance We define business governance as follows: 

a  process, organizational function, set of techniques, and systematic approach for creating and deploying business policies and business rules into day-to-day business activity

Our definition is based on Merriam-Webster Unabridged Dictionary [MWUD] definitionsfor governance 1, 2a, 4a, and 5. Why should any divergent definition be created?

1: the act or process of governing

2a : the office, power, or function of governing

4a: the manner or method of governing : conduct of office

5: a system of governing

And have a look at the MWUD definition of govern [1a]: 

to exercise arbitrarily or by established rules continuous sovereign authority over; especially:  to control and direct the making and administration of policy in. 

Note the high-profile roles of rules and policies in that definition.  ‘Governing’ a business involves coordinating how business policies and business rules are created (the making … of) and deployed (managed, distributed and monitored) within day-to-day business operations (administration).  Clearly, business governance and business rules are directly linked.  Why haven’t more people recognized the direct link between business governance and business rules?! 2. Governance Decision The original decision to create a business policy or business rule is an example of a governance decision.  Governance decisions should be part of a special business process, the governance process, which also coordinates deployment and retirement of business rules.  To support business governance you need a systematic approach, which is provided by a rulebook and general rulebook system (GRBS).  These tools also provide the traceability needed to support compliance. 3. Governance Process We define governance process as follows: 

a series of business actions and checkpoints indicating who should be doing what (business roles), and when, with respect to deploying business policy and business rules

That just follows naturally, doesn’t it? ~~~~~~~~~~~ Excerpted from Building Business Solutions: Business Analysis with Business Rules, by Ronald G. Ross with Gladys S.W. Lam, An IIBA^® Sponsored Handbook, Business Rule Solutions, LLC, 2011, 304 pp, http://www.brsolutions.com/bbs