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

Everyday Always-On Compliance

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

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

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

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

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

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

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

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

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

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

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

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

Is that possible?! Absolutely!

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

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

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

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

~~~~~~~~~~~

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

Continue Reading

One-Size Traceability Does Not Fit All!

traceabilityCompliance 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

Continue Reading

Wanted: A New Knowledge Paradigm

ParadigmShift[1]My inner geek gets as excited as the next professional about all the technological innovations adding up to what gurus are calling the digital platform or digital business – or simply digital. This new wave of technological capability features social, mobile, cloud, big data, and more. It promises a host of new capabilities to accelerate innovation including robotics, 3D printing, internet of things, cognitive, and augmented reality. WOW!!

But there’s a little voice inside me counseling caution. When have new platforms or channels ever fixed major business challenges?!

It’s all too easy to get caught up in ChannelMania, a state of virtual panic about introducing the next big thing, keeping up with the Joneses technologically. In the frenzy you can easily lose sight of the hidden business costs.

We should step back, take a deep breath, and ask ourselves some fundamental questions.

  • How well can we really manage yet more channels?
  • Do we deliver consistent business results to our customers?
  • Are we happy with our current lot in managing change?
  • Does the company have any real strategy to address ever-accelerating complexity?
  • With all the new agile methods, is the business actually becoming more agile?

It’s not too hard to envision what real operational excellence would look like.

  • Your customers would get consistent business results through any of many channels.
  • Rolling out business change would be faster and cheaper.
  • You could demonstrate compliance at every turn.
  • You could manage complexity at scale.
  • You’d provide stellar customer experience at inhuman speeds.

The question, of course, is how do we get there? I argue that we need a new knowledge paradigm. I call it Business Knowledge Engineering.

~~~~~~~~~~~

Read about the new knowledge paradigm: http://www.brcommunity.com/articles.php?id=b900

Continue Reading

‘Business Rule’ Means These 3 Things

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 

Continue Reading

Who (or What!) Makes Your Day-to-Day Business Decisions?

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.

Continue Reading

Governance, Compliance and Business Rules (Through Young Eyes)

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 21st century!

Continue Reading 1 Comment

Six Succinct Reasons for Business Rules

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.

~~~~~~~~~~

Continue Reading

Quality and Tolerances in the Knowledge Economy

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

Continue Reading 2 Comments

Why Not Just Use IBM Watson or Similar Platforms for Automating Operational Business Decisions?

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.
www.BRSolutions.com

[1] These include platform-independent expression guidelines such as RuleSpeak (free on www.RuleSpeak.com). In our book Building Business Solutions: Business Analysis with Business Rules we explain patterns for harvesting business rules from business process models and other deliverables. We have also developed highly effective techniques for decision engineering. See our Primers (free): http://www.brsolutions.com/publications.php#primers  
 

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