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

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

Looking to Find Out What Decision Analysis is About? Make Business Processes & Business Architectures Smart? Design Business-Friendly Decision Tables? Write Business-Friendly Business Rules? >>> Free downloads …

As part of the April announcement of the new 4th edition of my book Business Rule Concepts: Getting to the Point of Knowledge, I’m pleased to make available some additional complementary (and complimentary!) downloads: Decision Analysis – A Primer: How to Use DecisionSpeak and Question Charts (Q-Charts) – 49pp http://www.brsolutions.com/IPSpeakPrimers (free) Decision Tables – A Primer: How to Use TableSpeak – 121pp http://www.brsolutions.com/IPSpeakPrimers (free) Tabulation of Lists in Rulespeak®: A Primer Using “The Following” Clause – 16pp http://www.brsolutions.com/IPSpeakPrimers (free) We’ve comprehensively written-up state-of-the-art experience and insight in these important areas. I hope you will make the most of them! P.S. Do have a look at other items of interest: http://goo.gl/WPV7O  

Continue Reading

Q&A: Simplifying Business Process Models and Achieving Dynamic Business Processes – All By Using Business Rules

The OMG standard  SBVR[1] distinguishes between two fundamental kinds of business rules[2]:
    • Definitional rules (including decision rules) are about shaping knowledge (and cannot be violated).
    • Behavioral rules are about shaping conduct (and can be violated).
Question: Should definitional rules be included in business process models? Answer: You might have 100s or 1,000s of business rules about determining creditworthiness. In what sense is directly including all those business rules in a model of a business process useful? (Note carefully I said business rules, model, and again business (process).) So my answer is no, don’t include them. Question: Or, to put it another way, do we simplify business process models by removing only the behavioral rules? Answer: Again, no. Question: And am I right in assuming that these behavioral rules are associated with decision points in process flow charts, and what we are being urged to do is eliminate decision diamonds from those charts? Answer: Assuming you mean binary branch points in traditional flowcharts, I’ve seen both definitional and behavioral rules modeled procedurally by those. Traditional flowcharting is spectacularly unsuccessful for behavioral rules, because as I’ve said many times, each generally has two or more flash points[3] where it could be violated and needs to be checked. Those flash points could be in completely different flow charts (or procedures or use cases). Consider this simple business rule: An agent must be assigned to a customer that has placed an order. Flash points:
    • When the first order is placed by a customer.
    • When an agent leaves the company (which could leave an order-placing customer without an agent).
How likely is the second event to be handled by the same flowchart (or procedure or use case or even business process) as the first? That’s why business rules need to be a first-class citizen in the requirements world. It is also why we need ‘watchers’ outside the process (automated as much as possible) to:
    • Detect violations of behavioral rules (like cops and referees).
    • Permit dynamic invocation of selective (read “selectively different”) responses.
Call the result dynamic process or what you will; behavioral rules are the pragmatic means to stitch together highly responsive business activity in real-time operational activity. ~~~~~~~~~~~~~~~~ If you liked this blog post you might also enjoy: http://www.brsolutions.com/2012/05/01/r-i-p-straight-line-old-school-processes/


[1]Semantics of Business Vocabulary and Business Rules. Release 1.0 of SBVR came out in Dec, 2007. For more information see the SBVR Insider section on BRCommunity.com.
[2]For logic wonks, the distinction is based (very carefully) on necessities (alethic modal logic) vs. obligations (deontic modal logic).
[3] For more on flash points see my blog post: Flash Points: Where Business Rules Meet Events http://goo.gl/pl9sT

Continue Reading

Business Rule Manifesto FAQs Added to BRCommunity.com

I am pleased to announce that a comprehensive set of authoritative FAQs about the Business Rules Manifesto has been added to BRcommunity.com: http://www.brcommunity.com/brm.php The Manifesto is celebrating its 10th anniversary this year – and remains as powerful and as vibrant to today’s business challenges as ever. I will be covering a good many of its insights in my Sunday tutorial, Business Rules: The Why and the What, at this year’s Business Rules Forum conference, part of BBC2012 (Oct. 28 – Nov. 2, Ft. Lauderdale, FL): http://www.buildingbusinesscapability.com/ The FAQs explain in-depth how the Manifesto relates to a great many pressing issues on today’s business agenda, including …
    • Requirements
    • Business Processes
    • Business Analysis
    • Business Agility
    • Enterprise Architecture
    • Zachman Framework  
    • Knowledge Retention
    • Events
    • Enforcement
The new BRCommunity Insider also provides insight into the general positioning and structure of the Manifesto, as well as point-by-point clarification of individual Principles. The Manifesto is just 2-pages and free. It has now been translated into some 15 languages: http://www.businessrulesgroup.org/brmanifesto.htm The Manifesto is a rare thing in our field – a timeless work that seems more and more prescient which each passing year.

Continue Reading

How Business Rules, Events and Processes Should Relate: Eight Simple Principles

I’ve written on this subject many times before, but let me summarize my position concisely. By the way, I expect heavy flak on the last point. See what you think. (1) Business rules should be expressed declaratively based on common business vocabulary.

An implication for business rules: No direct invocation of functions.

(2) No reference whatsoever should be made to events in expressing business rules.

Exception: Some business rules (a small minority) truly apply only at the time a given business event occurs. Example: A hotel guest must be given fresh cookies upon check-in.

(3) Behavioral rules (unlike decision rules) should always be evaluated immediately when any relevant event occurs. Such ability supports real-time compliance. (Read about behavioral rules vs. decision rules on http://www.brcommunity.com/b623.php.)

One Implication: You have to know what those relevant events are.

(4) The events to which a declarative rule applies can (and should) be determined automatically.

USoft proved the principle 20 years ago. SBVR’s treatment of business rules is based on the assumption.

(5) It’s important to determine the events automatically for behavioral rules because that way you can take programmers out of the business of event detection and management.

The benefits of doing so would be immense.

(6) Events bear a direct relationship to business rules in the sense that behavioral rules need to be invoked automatically when events occur.

How else can you achieve comprehensive consistency of behavior?!

(7) Business rules bear no such direct relationship to processes.

Do we really want programmers and designers to remain in the business of event detection and management forever?! In my opinion that’s a very bad idea.

(8) Some (many?) business capabilities (e.g., highly social ‘processes’) could be modeled and run without business process models altogether.

How would it work? You need:

  • Declarative business rules.
  • Work milestones (states through which loosely organized work still must progress).
  • Automatic event identification (as in USoft).
  • Event detection and management (as in Tibco).
 

Continue Reading

The Procedural Paradigm Won’t Scale: We Need Configuration Agility!

It’s been said that I claim the procedural paradigm won’t scale anymore. Guilty as charged! Let me explain. Procedural vs. Declarative In the big scheme of things, you have two basic choices for conceptualization, and ultimately implementation, of business capabilities: procedural vs. declarative. Let’s make sure we agree on what these terms mean. I’ll draw directly on Merriam-Webster Unabridged to make sure we’re on the same page. If the terms don’t mean what they’re supposed to mean, all bets are off. But I guess that goes without saying, doesn’t it?

procedure: 1a: a particular way of doing or of going about the accomplishment of something 1b (1): a particular course of action (2): a particular step adopted for doing or accomplishing something (3): a series of steps followed in a regular orderly definite way

You can spot the seeds of the scalability problem right away with repeated use of the word “particular” and with the phrase “regular orderly definite way” in the definition. Given the degree of product/service customization desired today, and the accelerating rate of change, how much business activity still occurs in a particular and regular orderly definite way? The answer, of course, is less and less all the time. ‘Exceptions’ have become the rule. The essential characteristic of procedures is that they flow. The flow comprises the steps by which a thing is intended to become a different thing (or the same thing in a different state). The essence of ‘procedure’ is therefore that something will be hopefully transformed. For sure, that’s a very basic, very important, very necessary part of any business capability. The problem arises taking procedure beyond that point. Something declarative, in contrast, doesn’t flow. It just states something that must (or should) be true.

declarative: 2: having the characteristics of or making a declaration : ASSERTIVE;  specifically : constituting a statement that can be either true or false

Business rules are that way; they simply give guidance. They don’t do anything. They don’t flow anywhere. They can’t be anything other than true or false. In short, business rules are fundamentally different than procedures. Big-P Process The traditional procedural paradigm (I’ll call it Big-P Process) embeds business rules in procedures (and in process models and in procedural code).What happens when you treat things that could be declarative in a procedural way? You get bloat. You lose business intent. You produce needless complexity. And you also get what I call configuration stagnation. As you scale, these problems grow exponentially. How many business rules are we talking about? Any given business capability easily has hundreds, sometimes thousands of business rules – especially when you begin to factor in the know-how needed to make smart operational business decisions. And don’t our businesses increasingly depend on ever more complex know-how? Is there any end to that trend in sight? At the scale of today’s business, the Big-P Process paradigm simply doesn’t work. It results in ungovernable business operations and unretainable know-how. Big-P solutions are like setting the business in concrete. It’s all so unnecessary and so counterproductive. It’s just not smart. Configuration Agility The key question for agile business capabilities is how the business is configured (and quickly reconfigured) for operation at any given point in time. In the Big-P paradigm, the building-blocks become thoroughly entangled with flow (procedure). The result is essentially a semantic dead zone. Because things that could be expressed declaratively aren’t, the opportunity is lost to use logic to automatically evaluate business rules (read ‘business practices’) for conflicts, anomalies and other logical defects. The future clearly does not lie in that direction. Instead, it lies with granular, declarative, semantically-rich specification of business configurations in building-block fashion. It lies with the paradigm that can produce the optimal configuration agility. In addition to procedures, smart configuration models will feature at least these other building blocks for business capabilities, all specified at the business level:
  • business rules 
  • operational business decisions 
  • structured business vocabularies (concept models, also known as fact models) 
  • business goals and risks 
  • business events
From an engineering perspective, the secret to agile configuration is ‘late binding’ – that is, bringing all the pieces together for execution (i.e., performance of procedures) as late as possible. That way, performance can be as up-to-date and as flexible as possible. Smart configuration models should be the new mantra for enterprise architecture. In a world of constant and accelerating change, I simply see no alternative. Doing more of the same is simply not going to work anymore (and already hasn’t been for a good, long while). [Warning, plug coming]: Smart configuration schemes also address business governance and compliance – essential in a world of constant change – and just-in-time (JIT) delivery of know-how for operational workers. In our new book, Building Business Capabilities (see http://www.brsolutions.com/b_building_business_solutions.php) we call systems built using smart configuration models business operation systems (as opposed to ‘information systems’).  

Continue Reading 2 Comments

What Role for Business Rules in *Business Processes*? One of the ‘Must-Knows’ of Business Rules …

Celebrating the 10th Anniversary of the Business Rules Manifesto[1] http://www.businessrulesgroup.org/brmanifesto.htm FAQ #3 Question: How do business rules relate to business processes? First, be clear that rules and processes are not the same. The point seems obvious, but it’s surprising how much difficulty many IT professionals have perceiving the difference. Indeed, if you’ve come up coding procedural programs or specifying use cases, seeing that rules are something different than procedural statements can be quite challenging, at least at first. So the Manifesto makes the point explicitly …

2.2 Rules are not process and not procedure.  They should not be contained in either of these.

The result of separating rules and processes is rule independence, a pervasive idea across the Manifesto’s ten Articles. Its implications are far-reaching. For one thing, rule independence permits re-use of individual rules across all the processes and procedures of a business solution. Although IT professionals readily ‘get’ the importance of ‘re-use’, it’s probably not exactly the right term, however, to use for rules. If you were playing a game of chess or football, you wouldn’t say, “we re-use individual rules any time we can”. People don’t naturally talk like that. Instead, you’d probably say something like, “we apply individual rules wherever relevant.” In talking with business people and subject matter experts, we should be careful about wrapping what we say around implicit IT thinking. Rule independence also provides a new, high-power lever for rule quality, something difficult to achieve when rules are embedded in processes or procedures. Just as for the rulebook of a game, rules for the business need to be cohesive – that is, not conflicting, misleading or incomplete. You also need to apply the rules consistently, so your processes get consistent results in like circumstances. The Manifesto summarizes these important points as follows …

2.3 Rules apply across processes and procedures.  There should be one cohesive body of rules, enforced consistently across all relevant areas of business activity.

 


[1] The Manifesto is free, only 2 pages long, translated into 15 languages. Have a quick look (or re-look!). No sign up required. Well worth your time.

Continue Reading 1 Comment

Understanding Strategy as a Key Business Analysis Tool: It’s Not Business Process!

John Matthias recently wrote this about our new book, Building Business Solutions: Business Analysis with Business Rules[1]:

“I especially liked the discussion about the mission and goals. I still see business process analysis in organizations I visit where the goals are not articulated well, and the results are not useful. (I’ve done it myself.) It’s easy to get lost among the trees, unaware of the contours of the forest or what direction you’re going.”

Indeed! That’s why we came up with the Policy Charter, which is the deliverable in our approach that lays out the elements of strategy and their motivation.  A Policy Charter is all about business goals, business risks, and business policies. It’s not about business process! [2] How do you distinguish between good business strategy and bad business strategy? Noted strategy expert Richard Rumelt distinguishes the good and bad as follows.[3] Good Business Strategy Rumelt, p. 20: “good strategy requires leaders who are willing and able to say no to a wide variety of actions and interests.  Strategy is at least as much about what an organization does not do as it is about what it does.” Rumelt, p. 243: “good strategy is, in the end, a hypothesis about what will work.  Not a wild theory, but an educated judgment.  And there isn’t anyone more educated about your [business] than the group in [the] room.”  Bad Business Strategy Rumelt, p. 32: Bad strategy “… is not simply the absence of good strategy.  It grows out of specific misconceptions and leadership dysfunctions.  To detect a bad strategy, look for …
  • Failure to face the challenge. When you cannot define the challenge, you cannot evaluate a strategy or improve it.
  • Mistaking goals for strategy.  Many bad strategies are just statements of desire rather than plans for overcoming obstacles.”
Rumelt, p. 32: Bad strategy “… is long on goals and short on policy or action. …  It uses high-sounding words and phrases to hide [its] failings.”  He means (and says) fluff. The Three Skills of Good Business Strategy What do you need to be successful with strategy? Rumelt (p. 268) says: “… you must cultivate three essential skills or habits.
  • First, you must have a variety of tools for fighting your own myopia and for guiding you own attention.
  • Second, you must develop the ability to question your own judgment.  If your reasoning cannot withstand a vigorous attack, your strategy cannot be expected to stand in the face of real competition.
  • Third, you must cultivate the habit of making and recording judgments so that you can improve.”
Good stuff!


[2] The standard for organizing business strategy is provided by the Business Motivation Model (BMM). See www.BusinessRulesGroup.org
[3] Rumelt, Richard [2011].  Good Strategy Bad Strategy:  The Difference and Why It Matters.  New York, NY:  Crown Publishing, a division of Random House Inc.

Continue Reading 1 Comment

To-Do Items, Checklists and Out-of-Tolerance Business Events … Business Process Problems?

Does a to-do item constitute a business process? No. Does a checklist constitute a business process? No. Does an out-of tolerance event constitute a business process? No. Analysis of the following case study illustrates. The take-away: “Process” shouldn’t be force-fit to every aspect of business operations. That kind of ‘Big-P process’ perspective as I frequently call it puts blinders on you. Case Study: An organization runs public conferences. In reaching an agreement with a hotel, it must commit to a room block of a certain size. If the conference does not fill the room block, it must compensate the hotel. The amount of the compensation is roughly equivalent to the cost of the number of room nights not filled. So it’s prudent to always guesstimate on the low side. Sometimes conference attendance exceeds expectations. If the hotel is already heavily booked for the conference dates (e.g., for other conferences), attendees will not be able to secure a hotel reservation. Not having a hotel room may naturally discourage them from coming. So it’s wise to constantly monitor the number of hotel reservations vs. the size of the room block. Once exceeded, provisions should be made immediately to secure more hotel rooms for attendees, often at a nearby hotel. Analysis: Business process problem? No. This is really an operational business event – in particular, a spontaneous event.
  • The operational business event is when hotel room block is exceeded
  • A business rule could be specified defining the appropriate conditions producing the operational business event. 
  • An appropriate response to the operational business event might be Notify conference organizer.
If detecting the spontaneous event via testing of the business rule and notifying the conference organizer can all be automated, fine. If not, monitoring the hotel room block should be assigned as a job responsibility for staff, possibly just one of many ‘checklist’ items to perform daily. Does a to-do item constitute a business process? No. A to-do item – or even a whole checklist – is not a business process! Each item is what it is, simply a job responsibility. Simply notifying the conference organizer is not a business process either. A business process needs to be something more substantial, like Secure additional hotel rooms. Tip for Business Analysts: To be a business process it’s not enough for someone to be informed, something must be transformed. After-the-Fact Settlement: What happens if the hotel registration overflow is not detected in real time? Nothing good! Suppose the hotel continues to accept reservations knowing they can be accommodated at near-by hotels. Now you need an additional business process: Handle hotel registration overflow. It’s a business process you’d rather not have(!). Transferring registrations to other hotels entails significant work and communication, leaving some registrants inevitably unhappy. Clearly you need a ‘fairness’ rule for who gets transferred – probably first-come, first-serve. The bottom line: Failure to detect operational business events in real time can result in highly undesirable ‘settlement’ problems downstream. Use business rules in real time to detect out-of-tolerance business transactions whenever you can. Tip for Business Analysts: Stay alert for business processes involving after-the-fact settlements. Could real-time reaction to operational business events eliminate them? ~~~~~~~~~~~~~~ This post excerpted from our new book Building Business Solutions: Business Analysis with Business Rules. See: http://www.brsolutions.com/b_building_business_solutions.php

Continue Reading 1 Comment

R.I.P. Straight-Line, Old-School Processes!

Consider the business rule: A vehicle must not exceed the posted speed limit. Some of the issues for this business rule are (a) how do you detect a violation and (b) how do you respond to a violation. These issues raise the question, whose process is it? Are we talking about the process of the person driving down the street, or the process of the policeperson operating the speed trap? The two processes are obviously related in some way, but definitely not the same. The cop’s process is best viewed as interrupting the driver’s process. Let me come back to that point in a minute. There are two fundamental kinds of business rules[1]:
  • Decision rules (or a little more broadly, definitional rules). These are the kind of business rules that expert systems traditionally addressed. It’s the kind you find in decision tasks – e.g., whether someone should be given credit.
  • Behavioral rules. These are business rules that can be violated – e.g., speeding down the street, or being off-sides in football. For behavioral rules you need cops or referees or whatever to interrupt a more basic process when a violation occurs. It’s just the natural way to do things (if you don’t want anarchy).
Aside: You might say the examples of behavioral rules I’ve cited (speeding and off-sides) are not automatable. Well, I’m less and less sure about that these days. I see a lot of cameras where I live ‘watching’ for cars running red lights. The camera takes a picture of your license plate and the position of the car in the intersection and you get a ticket in the mail. For the record, I haven’t gotten one. But they do make me more careful about yellow lights. In any case, a great many behavioral rules are automatable. They arise as interpretations of some law, act, statute, regulation, contract, agreement, business deal, MOU, business policy, license, certification, warranty, etc.  For these kinds of business rules, you need a ‘watcher’ outside the process, standing ready to interrupt the process if a violation occurs. A classic example: The fuel rods in a nuclear power plant must be covered with water. If a process of operating the power plant ever violate that rule, I want an immediate violation response to interrupt the guilty process(!). That business rule is about operating a power plant, but the same idea holds true for business processes in general. Detecting violations of behavioral rules is how you can stitch together dynamic processes in real time. Such dynamic processes cannot be achieved by embedding business rules in either a model of the business process, or the process itself. The ‘watcher’ must be on the outside, protecting the interests of the larger (business) community. Such rule independence is the fundamental idea of business rules, as expressed by the Business Rule Manifesto[2]. R.I.P traditional, hard-wired processes!    


[1] Based on SBVR, the OMG standard Semantics of Business Vocabulary and Business Rules. See the SBVR Insider section on www.BRCommunity.com for more information. [2]http://www.businessrulesgroup.org/brmanifesto.htm The Manifesto (2 pp, free) been translated into 15 languages.
 

Continue Reading 4 Comments