Enabling Operational Excellence
Enabling Operational Excellence
Enabling Operational Excellence
Enabling Operational Excellence

TURNING OPERATIONAL KNOWLEDGE & COMPLIANCE INTO A COMPETITIVE EDGE

We systemize tacit knowledge into explicit knowledge

Blog Enabling Operational Excellence

What is a Business Rule?

It’s become more and more apparent that software vendors are misleading people (badly) about the true meaning of ‘business rule’. Time to set the record straight. Here is an authoritative 3-part explanation. Take a moment and reacquaint yourself. As a business-oriented professional you’ll be glad you did!

   Reference Sources

[MWUD] Merriam-Webster Unabridged Dictionary (Version 2.5).  [2000].  Merriam-Webster Inc.
[SBVR] Semantics of Business Vocabulary and Business Rules (SBVR) (Version 1.0).  [January 2008].  Object Management Group.
  1. Rule When we say rule we always mean real-world rule. Here’s the dictionary meaning of “rule”. That’s what we mean.

[MWUD ‘rule’ 1a]:  guide for conduct or action; [MWUD ‘rule’ 1f]:  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 ‘criteria’  2]:  a standard on which a decision or judgment may be based

A real-world rule always tends to remove some degree of freedom.  If it does not, it’s not a rule.  2. Under Business Jurisdiction    When we say business rule we mean only rules that the business can opt to change or to discard. A business rule is always under business jurisdiction of your organization.  The 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: 

“The laws of physics may be relevant to a company … ; legislation and regulations may be imposed on it; 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. Business Rule

[SBVR]:  a rule that is under business jurisdiction

A business rule is a criterion used to:
    • guide day-to-day business activity
    • shape operational business judgments, or
    • make operational business decisions. 
A number of years ago, a colleague of ours, Mark Myers, came up with a highly pragmatic test to determine whether some statement represents a business rule or a system rule.  It almost always works.  Imagine you threw out all the systems running your business and did it all by hand (somehow).  If you still need the statement, it’s a business rule.  If you don’t, it’s not.  A colleague on the SBVR standardization team, Don Baisley, puts it another way:  “Business people don’t set variables and they don’t call functions.” Some people think of business rules as loosely formed, very general requirements.  Wrong.  Business rules have definite form, and are very specific.  Each should give well-formed, practicable guidance Here are a few simple examples expressed in RuleSpeak:  

A customer that has ordered a product must have an assigned agent. 

The sales tax for a purchase must be 6.25% if the purchase is made in Texas. 

A customer may be considered preferred only if the customer has placed more than $10,000 worth of orders during the most recent calendar year.

Business rules represent a form of business communication and must make sense (communicate) to business people.  If some statement doesn’t communicate, it’s not a business rule. 

Consider this example:  If ACT-BL LT 0 then set OD-Flag to ‘yes’.  Not a business rule. 

Consider another example:  An account must be considered overdrawn if the account balance is less than $0.  This statement communicates and therefore is a business rule. 

More observations about business rules:
    • In SBVR a business rule can be either a behavioral rule or a definitional rule.
    • Business rules can be technical, but only in terms of the company’s know-how or specialized product/service, not in terms of IT designs or platforms.
    • Expression of business rules should always be declarative, rather than procedural.
    • A business rule statement should use terms and wordings about operational business things that should be based on a structured business vocabulary (concept model).
    • Your company’s business rules need to be managed and single-sourced, so we strongly recommend rulebook management.
Business rules are not about mimicking intelligent behavior, they are about running a business Mimicking intelligent behavior in a generalized way is far harder (an order of magnitude or more) than capturing the business rules of an organization.  Unfortunately, expert systems have generally focused on the former problem, causing considerable confusion among business practitioners.  ~~~~~~~~~~~~~~~~~~~~  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

Continue Reading

Managing Know-How in the Knowledge Economy: What Role Do Business Rules Play?

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

[1] Merriam-Webster Unabridged Dictionary

Continue Reading

Decision Analysis: Don’t Drown in Decisions

Consider the following examples of decisions arising in a regulated environment (acks James Taylor):

Government agency in Europe has regulations relating to Social Benefits. The agency itself must make decisions like “Is this person eligible for this benefit?” and “How much benefit, and for how long, is this person entitled to?”” that conform with those regulations.

An individual company might also have a decision like “Is this person entitled to paid leave to care for a sick child?” that is dependent both on company policy/practices and regulations that relate to social benefits (because they might require companies of a certain size to pay for this kind of leave).

My Analysis Indeed, these are operational business decisions. I’m not surprised, by the way, they are in effect about money. Of course money entails decisions! But here are two important observations. 1. Regulations typically include a great many one-off behavioral rules (“one-off” meaning following no particular pattern). Examples might include:
    • Payment of benefits shall cease immediately upon the death of the beneficiary.
    • Payment of benefits shall not be made to any beneficiary living outside the country for more than 9 months of a fiscal year.
    • Payment of benefits shall not be made directly to any minor.
Is decision analysis suited to capturing/interpreting such one-off rules? Is it meaningful to have a decision such as “Should a benefit payment be made?” Shouldn’t such behavior be presumed automatic (but traceable and adaptable)? A better option is to simply have a task or action such as “Make payment”. Violations of related business rules for any particular case produces exceptions, possibly to be addressed by appropriate messages and/or procedures invoked automatically. That’s how basic business behavior becomes autonomous, so the business can concentrate on matters requiring greater skill, experience or intelligence. If you’re not careful everything becomes a decision. Where do you draw the line? Isn’t there a difference in simply being competent vs. being smart in doing business?

Aside:  Business vocabulary is as always obviously important. For example, does “payment” mean “accrual of benefit”, “act of payment”, “amount of payment”, or something else? No small issue.

(2.) Consider the following (one-off) behavioral rule:

A non-citizen may cash a payment of benefits for a citizen only if married to that citizen and the citizen is not deceased.

What happens in the case of death or divorce, and then the non-citizen tries to cash a payment? There’s no organizational decision involved there. There’s a personal decision … the non-citizen can decide to try to violate the rule … but we don’t really care about that. We only care about detecting the violation. We really don’t need or want an (operational business) decision here, do we? Again, if you have a decision for every possible kind of violation of every behavioral rule, you’ll very quickly drown in decisions. Don’t go there!  

Continue Reading

Do Business Rules Define the Operational Boundaries of an Organization?

Have you heard business rules described that way? You certainly have to stop and think about it for a minute. Without additional explanation the term “boundaries” could easily be misleading. For example the term could be interpreted incorrectly as suggesting business rules define scope – i.e., the operational edges of an organization or an initiative. They don’t. Let’s revisit the meaning of “business rule”. Business rules are guides or criteria used to:
    • shape conduct or actions
    • form judgments of behavior
    • make decisions
Respectively, yes, business rules therefore establish “boundaries” for distinguishing:
    • acceptable or desirable conduct or actions from what is unacceptable or undesirable.
    • proper behavior from what is improper behavior.
    • correct or optimal decisions from what are incorrect or suboptimal decisions.
But these “boundaries” (delimitations) are a result of applying business rules, not what business rules fundamentally are (i.e., guides or criteria). Furthermore, these boundaries (delimitations) are not as rigid as the term “boundary” suggests. Depending on enforcement level, many business rules can be overridden with proper authority or explanation, or even ignored (e.g., guidelines). Level of enforcement is an organizational decision. Note that the transgressing behavior in such cases is nonetheless still within the scope of organizational operations. My bottom line re “boundary”. Describing business rules can …
    • misleading.
    • wrongly suggest scope.
    • incorrectly assume all business rules are strictly enforced.
But otherwise sure, business rules do set up boundaries (delimitations) for how activity in the organization is undertaken. And that’s especially important when you start thinking about smart processes – as my recent posts suggest.

Continue Reading

Business Rules vs. Choices Made in Designing Systems … Not the Same Thing!

A colleague and I were recently discussing business rules. In the course of conversation he used this example: A customer may have only one address. Hold on! That’s not a business rule. Rather, it’s a design decision (probably a poor one) some IT person made in creating a system model. The business wouldn’t (and couldn’t!) make a real-world business rule about customers having only one address. But a design decision might be made to record only one (in a system). Eventually we agreed the desired business rule probably was: A customer may have only one preferred address.  ~~~~~~~~~~~~~~~~~~~~~~~~~~  This post excerpted from Building Business Solutions: Business Analysis with Business Rules (2011). See:  http://www.brsolutions.com/b_building_business_solutions.php

Continue Reading 1 Comment

Time Shock, Training, and Knowledge Companions: How to Develop Smarter Workers

Excerpted from Business Rule Concepts: Getting to the Point of Knowledge (4th ed, 2013), by Ronald G. Ross, 162 pp, http://www.brsolutions.com/b_concepts.php What people-challenges face your business today?  What role should business systems play? Time shock.  As the rate of change accelerates, workers are constantly thrust into new roles and responsibilities.  They must be guided through unfamiliar procedures and know-how as thoroughly and as efficiently as possible.  The business pays a price, either directly or indirectly, if getting workers up to speed is too slow (or too painful).  Time shock is like culture shock — very disorienting if you’re not prepared for rapid immersion. Training.  The flip side of time shock is training — how to get workers up to speed.  Training is expensive and time-consuming.  Yet as the rate of change accelerates, more and more (re)training is required.  Where do you turn for solutions? The foremost cause of time shock for business workers is rapid change in the business rules.  At any given time, workers might be found at virtually any stage of time shock.  Sometimes, you might find them completely up-to-speed, other times completely lost.  Most of the time, they are probably somewhere in between.  That poses a big challenge with respect to training. The only approach to training that will truly scale is on-the-job self-training.  Knowledge Companions. Such built-in training requires smart architecture, where pinpoint know-how can be put right in front of workers in real time as the need arises — that is, right at the point of knowledge[1].  What that means, in effect, is that the relevant portion of the company’s know-how — its rulebook — is ‘read’ to the worker on-line, right as the worker bumps up against the business rules. So a key idea that business rules bring to architecture is that operational business systems become knowledge companions for workers in the knowledge economy.  After all, isn’t making people smarter the whole point of knowledge?!

Continue Reading

Point-of-Knowledge Architecture: True Business Agility, Incremental Development, In-Line Training, and Real-Time Compliance

Excerpted from Business Rule Concepts: Getting to the Point of Knowledge (4th ed, 2013), by Ronald G. Ross, 162 pp, http://www.brsolutions.com/b_concepts.php Let me use an example to sketch the workings of business rules in smart architecture based on points of knowledge[1].  Refer to the Figure to visualize how the system works.

Aside: I have been using this same slide since 1994(!).

Suppose you have a process or procedure that can be performed to take a customer order.
  • An order is received.  Some kind of event occurs in the system.  It doesn’t really matter too much what kind of event this is; let’s just say the system becomes aware of the new order.
  • The event is a flash point — one or more business rules pertain to it.  One is:  A customer that has placed an order must have an assigned agent.
  • We want real-time compliance with business policy, so this business rule is evaluated immediately for the order.  Again, it doesn’t much matter what component in the system does this evaluation; let’s just say some component, service, or platform can do it.
  • Suppose the customer placing the order does not have an assigned agent.  The system should detect a fault, a violation of the business rule.  In other words, the system should become aware that the business rule is not satisfied by this new state of affairs.
  • The system should respond immediately to the fault.  In lieu of any smarter response, at the very least it should respond with an appropriate message to someone, perhaps to the order-taker (assuming that worker is authorized and capable).
What exactly should the error message say? Obviously, the message can include all sorts of ‘help’.  But the most important thing it should say is what kind of fault has occurred from the business perspective.  So it could start off by literally saying, “A customer that has placed an order must have an assigned agent.”  We say the business rule statement is an error message (or better, a guidance message). That’s a system putting on a smart face, a knowledge-friendly face, at the very point of knowledge.  But it’s a two-way street.  By flashing business rules in real-time, you have an environment perfectly suited to rapidly identifying opportunities to evolve and improve business practices.  The know-how gets meaningful mindshare.  That’s a ticket to continuous improvement and true business agility.

Smarter and Smarter Responses

Is it enough for the system simply to return a guidance message and stop there?  Can’t it do more?  Of course. For the order-taking scenario, a friendly system would immediately offer the user a means to correct the fault (again assuming the user is authorized and capable).  Specifically, the system should offer the user another procedure, pulled up instantaneously, to assign an appropriate agent.  If successful, the user could then move on with processing the order. This smart approach knits procedures together just-in-time based on the flash points of business rules.  It dynamically supports highly-variable patterns of work, always giving pinpoint responses to business events (not system events).  In short, it’s exactly the right approach for process models any time that applying know-how is key — which these days, is just about always! The Business Rules Manifesto (http://www.businessrulesgroup.org/brmanifesto.htm) says this:  “Rules define the boundary between acceptable and unacceptable business activity.”  If you want dynamic processes, you must know exactly where that boundary lies, and how to respond to breaches (at flash points) in real time. Is that as smart as processes can get?  Not yet.  Over time, the business rules for assigning appropriate agents might become well enough understood to be captured and made available to the system.  Then when a fault occurs, the system can evaluate the business rules to assign an agent automatically.  At that point, all this decision-making gets tucked very neatly under the covers.  Even if the business rules you can capture are sufficient for only routine assignments, you’re still way ahead in the game. Smart architecture based on business rules is unsurpassed for incremental design, where improvement:
  • Focuses on real business know-how, not just better GUIs or dialogs.
  • Continues vigorously after deployment, not just during development.
  • Occurs at a natural business pace, not constrained to software release cycles.
The Manifesto says it this way:  “An effective system can be based on a small number of rules.  Additional, more discriminating rules can be subsequently added, so that over time the system becomes smarter.”  That’s exactly what you need for knowledge retention, as well as to move pragmatically toward the knowledge economy.  Business rules give you true agility.

Continue Reading 1 Comment

The Point of Knowledge

Excerpted from Business Rule Concepts: Getting to the Point of Knowledge (4th ed, 2013), by Ronald G. Ross, 162 pp, http://www.brsolutions.com/b_concepts.php For me the point of knowledge (POK) is a real place.  POK is where elements of operational business know-how — business rules — are developed, applied, assessed, re-used, and ultimately retired.  In other words, POK is where business rules happen.  Knowledge is power, so  you can also think about POK as point of empowerment. POK corresponds to point of sale (POS) in the world of commerce.  POK and POS are similar in several ways:
  • In both, something is exchanged.  In POS, it’s goods.  In POK, it’s operational business know-how (from here on I’ll just say know-how).
  • In the world of commerce, we often say that consumer and supplier are parties in point-of-sale events.  Each of us is a consumer in some point-of-sale events, and many of us act as suppliers in others.  The same is true for POK.  Each of us is a consumer of know-how in some POK events, and many of us act as suppliers in others.  Sometimes we switch roles within minutes or even seconds.
  • A well-engineered experience at the point of sale has obvious benefits both for the consumer — a positive buying experience — and for the business of the supplier — real-time intelligence about sales volume, cash flow, buying trends, inventory depletion, consumer profiles, etc.  A well-engineered experience at the POK likewise has obvious benefits.  For the consumer, it means a positive learning experience.  For the business of the supplier, the benefits include real-time intelligence about the ‘hit’ rate of business rules, patterns of evolving consumer (and supplier) behavior, emergence of compliance risks, etc.
The consumer/supplier experience at  the POK is crucial to worker productivity and job satisfaction.  In no small measure, optimizing this experience is the real challenge in POK engineering.  It must  be deliberate.  After all, what’s exchanged  at the POK is know-how — something you can’t carry around in your hands.
Nonetheless, your company’s know-how is very real.  What do I mean by know-how?  MWUD says:

know-howaccumulated practical skill or expertness … especially: technical knowledge, ability, skill, or expertness of this sort

Today, much of your know-how is tacit — lose the people, you lose the know-how they carry in their heads.  How can you avoid that?  Make the know-how explicit as business rules.  That’s what POK are about. Critical success factors in engineering an effective POK include:
  • Communication must be strictly in the language of the business, not IT.
  • Interaction must be gauged to the knowledge level (and authorization) of each individual party.
  • Less-experienced parties playing the consumer role must be enabled to perform as closely as possible to the level of the company’s most experienced workers.
  • Know-how — business rules — must be presented and applied in a succinct, highly-selective fashion.
  • Know-how — business rules — must be presented and applied in a timely fashion (i.e., ‘just-in-time’) to accommodate fast-paced refinement and change in business policies and practices.

Continue Reading

The Motivation Behind Business Rules: Example

I was hiking in a National Forest in Montana last week, sorta in the middle of nowhere, when I came across this sign. I have long preached capturing the motivation for business rules — and communicating it (when appropriate) — and here is an excellent example. These business rules aim toward achieving three explicit goals:
                        • To protect wildlife habitat area.
                        • To provide wildlife security.
                        • To reduce the spread of noxious weeds.

Continue Reading

Is a Decision-Based Approach Sufficient for Business Rules?

Consider the following example.

Behavioral Rule: A student with a failing grade must not be an active member of a sports team.

This business rule:    
  • Is not about selecting the most appropriate sports team for a student – i.e., not about the decision, Which sport team is best for a student?.
  • Does not apply only at a single point of determination – e.g., when a student joins a team.
Instead, the business rule is meant to be enforced continuously – for example, if a student who is already active on some sports team should let his or her grades fall. What’s the business decision for when a student’s grades fall and they should be taken off a team? Be real, there’s no good answer to that question. This example is no outlier. Businesses have 1,000s of behavioral rules like this. Let’s be clear – I believe a business-decision-based approach is very powerful for decision rules. I have written much about that. And I don’t disagree that many business-rule projects have floundered due to lack of pragmatic organizing principles (e.g., “decisions”). But if you take a decision approach to behavioral business rules, either it will prove woefully incomplete with respect to integrity, or you’ll quickly start to drown in (system-level) decisions. In my opinion, an application that has to be designed and to operate to treat violations of behavioral rules as just more decisions is not a smart enough system. The detection of violation events for behavioral rules can be, and should be, completely under the covers (identified, detected and supported by a platform). Otherwise the solution won’t scale. And there will be so many decision dependencies it will steal from the very real value of a business-decision-based approach. This frankly is a sign of immaturity … or lack of imaginative leadership … or IT bias … or whatever … in some parts of the decision-model community. The detection of a violation of a behavioral rule is an event, not a decision. A business decision is a business decision; a system decision is … well … why even go there?! P.S. There are 3 specific examples and more complete discussion about this topic on http://goo.gl/NCnLi.      

Continue Reading 5 Comments

Our Clients

[cycloneslider id="our-clients"]