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

There are two fundamental kinds of business rules: behavioral rules and decision rules.[1] Behavioral rules are rules people can violate; decision rules are rules that shape knowledge or information. Decision rules cannot be violated – knowledge or information just is what it is defined to be. Common to all business rules, no matter which category, is that you want them directly traceable for compliance and other purposes. How do  behavioral rules and decision rules apply differentially to service workers vs. white-collar workers vs. gold-collar workers? Service workers are primarily subject to obeying behavioral rules, or are charged with applying them. Examples:

• A counter attendant must not accept a credit card for a purchase under $10.
• A flight attendant must ensure passengers have buckled their seat belts for each take-off and landing.

Service workers are subject to operational business decisions made by white-collar workers, but do not play a significant role in making such decisions themselves. White-collar workers are typically involved in business processes where operational business decisions are made. Examples:

• Should this loan applicant be given a mortgage?
• What flight crew should be assigned to this flight?

White-collar workers generally do not define decision rules themselves – that’s typically work for gold-collar workers. Where such rules are incomplete, unspecified or contradictory, however, white-collar workers generally rely on personal heuristics and experience to make decisions. This approach puts the main goals for white-collar work – consistency and traceability – at jeopardy. White-collar workers, like all workers, are subject to behavioral rules. Examples:

• A loan officer must not handle a loan application placed by a family member

• The website description for a new product must be approved by two senior managers.

Gold-collar workers (for explanation see http://www.brsolutions.com/2014/08/11/is-%e2%80%9cknowledge-worker%e2%80%9d-the-best-term-for-decision-engineering/)[2] are responsible for non-routine, knowledge-intensive work. The primary goals for such work is that it be insightful (e.g., as in the case of medical diagnosis that fits the available data better) or creative (e.g., as in the case of a new marketing strategy). This type of work is generally beyond the scope of decision rules. Although gold-collar workers often conduct their work in relatively independent fashion, the work is generally subject to “very close normative control from organizations they work for” [Wikipedia]. Think medical malpractice or following generally accepted principles of accounting. These normative controls, since they can be violated, are sets of behavioral rules. www.BRSolutions.com

Some people argue that a knowledge worker is someone who gets paid to improvise or innovate, a factor distinct from the amount of training the worker receives. By this criterion even blue-collar workers can be considered knowledge workers if they constantly improvise or innovate. I don’t find the notion helpful. In my mind, a blue-collar worker who is constantly improvising or innovating, for example, has become an engineer – which is gold-collar, not blue-collar. (For explanation of gold-collar work, see http://www.brsolutions.com/2014/08/11/is-%e2%80%9cknowledge-worker%e2%80%9d-the-best-term-for-decision-engineering/) With respect to white-collar work, what I see in many organizations is white-collar entropy, all resulting from continuous and counterproductive ‘improvising’. A vacuum of coordination filled with too much information simply does not translate into a more productive organization. The more likely result is inconsistency, the enemy of good customer experience. The improvise-and-innovate argument also holds that knowledge workers don’t just apply rules – they invent rules. Hang on a minute. To take a real-life example, do we really want police officers (officers on the beat) inventing rules?! I think not. Their job is to apply rules (laws), not invent them. Otherwise we’d be living in a police state. In a well-run organization, just as in society, above all you want consistency at the operational level. If I call my bank ten different times, I should get the same answer ten different times. If I apply for a mortgage from the same bank at ten different branches, I should get the same result ten different times. In my experience, that’s hardly the norm. Why? If staff works in an environment where many of the rules are tacit, contradictory, ambiguous, poorly implemented, inaccessible, and/or unintelligible, of course the staff will improvise. Contrary to what some believe, well-defined rules do not lessen creativity (space to improvise and innovate about how to get desired results). That’s not the way it works. Absence of rules is literally anarchy – and only the bad guys look clever in that context. www.BRSolutions.com

In my most recent post, I distinguished between white-collar and gold-collar workers. See http://www.brsolutions.com/2014/08/11/is-%e2%80%9cknowledge-worker%e2%80%9d-the-best-term-for-decision-engineering/ Can you differentiate between white-collar work and gold-collar work by whether it can be automated? In a day and age when IBM Watson can win at Jeopardy, I think it’s probably foolish to try. But I don’t think that’s the right question. Instead, I would ask whether the problem spaces are sufficiently distinct that they require different approaches. The answer to that question is definitely yes. That’s one reason I think it’s important not to say simply “knowledge worker” in process models. Companies pay gold-collar workers for their professional insight, creativity, and ability to digest huge amounts of knowledge on a continuous basis. Novel, unexpected results that fit the data better are at a premium. That’s not what companies pay white-collar workers for – or at least it shouldn’t be. Instead, they should pay white-collar workers to produce consistent results on decisions reached through directly traceable logic – that is, business rules. Unexpected results represent a failure – of an individual worker, a training regimen, or the rules themselves. More often than not, I think the problem actually lies with the rules. In many companies, we ask humans to make operational business decisions in a fog of byzantine rules – rules often far more complex than reasonable (or profitable). In addition, the ‘real’ rules are frequently more tacit or inaccessible than anyone cares to admit. In my view we simply have never been serious about defining, organizing and managing the rules in white-collar decision-making in a reasonable, scalable manner. And we certainly haven’t yet harnessed the power of computers to help with the business-side problem of rule management. www.BRSolutions.com

I get this question all the time, and it’s a painful one, so let me answer on the record. Question: In our enterprise architecture tooling, there’s a business dimension in which we define Business Concepts (the real business language), and an IT dimension containing Information Objects (data organization model). How can we solve the problem that business expresses rules as they relate to Business Concepts, while IT needs to translate these into rules related to Information Objects? We don’t want to bother business with IT model concerns, nor duplicate the rules in two places. Can you please shed light on an elegant approach to this dilemma? My answer: The standard SBVR[1] provides the ‘elegant’ approach, which is technology that can “read” language based on the business vocabulary (e.g., RuleSpeak) and/or dialog with people to disambiguate those statements. Until such technology is commercially available – and why not, look what IBM Watson can do! – two forms of each statement are unfortunately necessary. The key for your rule management regime is to maintain traceability between them. By the way, the mapping is almost certainly 1:m, not 1:1. I wish I had a better answer, but there just is none today. All I can say is that current implementation technologies for business rules are very, very primitive. ~~~~~~~~~~~ Acks: Tom Andries www.BRSolutions.com

I’ve been writing a lot recently about the knowledge economy and what makes a business smart. Let me dig a little deeper. The kind of knowledge I’m talking about might be better described as know-how.

know-how:  accumulated practical skill or expertness …  especially:  technical knowledge, ability, skill, or expertness of this sort[1]

Know-how that you can encode and retain is represented by business rules and the structured business vocabularies (concept models) on which the business rules are based.  Know-how is a subset, a small one probably, of knowledge.  Briefly, knowledge can range from practical to theoretical, from certain to probabilistic, and from frequently applicable to infrequently applicable.  At the risk of saying the obvious, you can’t run the day-to-day operations of a business on knowledge that is theoretical, probabilistic, or infrequently applicable.  In short, business rules are about know-how management, a strictly limited subset of knowledge management. Like knowledge, know-how can be either tacit (in people’s heads) or explicit.  The classic test for when knowledge is tacit is ‘lose the person, lose the knowledge’.  Obviously you want to retain know-how. As a senior manager recently put it, “No organization should depend on absent brains.”

know-how retention:  expressing know-how explicitly in a form understandable by business people and business analysts, and managing the know-how, such that it is always available for future reference or use (by those capable and authorized)

The over-time infrastructure needed to retain know-how is provided by a general rulebook system (GRBS).  It’s what rule management should really be all about. ~~~~~~~~~~~~~~~~~~~~~~~ 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

United Airlines today rolled out this new business policy regarding upgrades on one of its routes. How easy would it be for your company to roll out a change in business policy like this to all operations and all systems with a single click?

guest post by Cay Hasselmann ~~~~~~~~~~~~~~~~~~~ The two oldest references on a business rule language I personally could find was in the British Library. One was on the building of the Pyramid in the Cheops Dynasty (2613-2498 BC), where 100,000 workers were involved for over 20 years. In some scrolls you will find what I would say are part of a basic rulebook.       The other is from China during the Chou Dynasty (1046–256 BC), which is a rulebook for government officials.

You can find definitions and discussion of all terms in blue on Business Rule Community: http://www.brcommunity.com/BBSGlossary.pdf ~~~~~~~~~~~~~~~~~~~ rulebook:  the collection of elements of guidance for a business capability, along with the terms, definitions, and wordings that support them

Discussion:  The rulebook of a game enumerates all the do’s and don’ts (rules) of that game along with the terms and definitions (vocabulary) needed to understand the rules.  Each participant in the game, whether player, coach, referee or umpire, scout, spectator, or media person, is presumed to understand and adhere to the rules to the extent his or her role in the activity requires.  The rulebook sometimes suggests how to play the game to maximum advantage, but never dictates playing strategy.

Similarly, a rulebook in business includes the business rules (and advices) needed to perform day-to-day operational business activity correctly or optimally, along with the structured business vocabulary (fact model) needed to understand the business rules correctly.  Each participant in the business activity must adhere to the business rules to the extent his or her role requires.  The rulebook never dictates business strategy, but should reflect, enforce, and measure it. 

Unlike the rules for a game, however, business rules change, often quite rapidly.  Therefore knowing the original source of each business rule, its know-why, and its full history of modifications, as well as how and where the business rule is currently deployed, is essential in effective rulebook management.

rulebook management:  the skills, techniques and processes needed to express, analyze, trace, retain, and manage the business rules needed for day-to-day business activity general rulebook system (GRBS):  an automated, specialized, business-level platform for rulebook management

Discussion:  Key features of a general rulebook system (GRBS) include rich, interactive support for structured business vocabularies (fact models) and comprehensive traceability for business rules (not software requirements). 

Unlike a business rule engine (BRE) a GRBS is not run-time.  Think of a GRBS as more or less like a general ledger system, except for Business Analysts.  Because of the potential of GRBS to support compliance and accountability, a GRBS is indispensable for improved business governance.

~~~~~~~~~~~~~~~~~~ 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, October, 2011, 304 pp, http://www.brsolutions.com/bbs  

There are very important differences in the traditions of business rules vs. expert systems. Perhaps that’s why business rules had a completely different origin. In any case, they didn’t start finding each other until the late 1990s. (The first Business Rules Forum Conference was in 1997 … and every year since except in 2000.) The general goal of expert systems was broadly to mimic intelligent behavior – any kind of intelligent behavior. As a colleague put it, that’s like trying to read the mind of God. Human behavior (even the not-so-intelligent kind) is exceeding complex. The goal of business rules was always to capture the rules of organizations, not individuals. That’s one or two or more orders of magnitude easier – those rules have to come from somewhere … and that ‘somewhere’ was originally knowable (even if an arbitrary design decision by some programmer). So the issue with business rules is as much about business traceability (rule management) as it is expression. This problem goes right to the very heart of business governance and business agility. Continuing to embed business rules in procedural code (a) makes the business rules very difficult to trace, and (b) very difficult and expensive to change. It’s like setting the rules in concrete. It also precludes the possibility in the future of supporting specification-time detection of anomalies and intelligent dialogs to help Business Analysts remove ambiguity. For business rules, it ultimately comes down to the words you use and ‘remembering’ the interpretations made of them. There’s no way to demonstrate compliance without words, and no way to support transparency and accountability without traceability. The solution to all these problems, which are problems of business governance and therefore business engineering, leads inevitably in one direction. That’s why I’ve put so much time into researching business rules since the early 1990s and before. (Originally we thought in terms of databases and integrity constraints, another difference in origin from expert systems.) It’s also why I’ve spent so much time on the SBVR standard over the past 6 years or more. (At the risk of oversimplifying hugely, SBVR is about words and sentences.) The bottom-line: The way we do things today simply has to change. Change does take time. It also takes false starts and trial-and-error. But we’ll get there. Hey, business automation is barely one human generation old. That’s incredibly fast in the big scheme of things. ~~~~~~~~~~~~~~~  Read more about the history of business rules: http://www.brcommunity.com/history.php