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

Posts Tagged ‘operational business decisions’

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

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 Let IT Figure Out the Business Rules for Automating Operational Business Decisions?

My Answer: Look at it this way. If you have no explicit business rules enabling people to do something correctly and consistently, you’ll have no rules for a machine to do it right. Except for speed and memory, machines are no smarter than people. The test of high-quality business rules is whether people could do it right. It’s shocking to me how many people think they can just use a BRMS or decision management platform to address a problem without having to express the rules clearly to other people first. I guess that silver bullet syndrome will always be with us. In any case, making tacit know-how explicit as business rules is first a business and communication problem, then and only then a platform problem.

Continue Reading

Are Business Rules Good for Incremental Design? You Bet!

You can find definitions and discussion of all terms in blue on Business Rules Community: http://www.brcommunity.com/BBSGlossary.pdf 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 ~~~~~~~~~~~~~ Discussion …  First a definition to make sure we’re on the same page …

incremental design:  developing a system through repeated cycles (iteratively) and in smaller portions at a time (incrementally)

Business rules are unsurpassed for step-by-step enhancement of deployed know-how in business capabilities over time (incremental design).  The Business Rules Manifesto[1] puts 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 know-how retention and to move pragmatically toward the know-how economy Support for incremental design with business rules is quite straightforward.  For example, a decision task might start off manual (performed by humans).  As time and resources permit, decision rules for handling the simplest cases can be captured and encoded, removing these cases from the manual workload.  Perhaps you start supporting a modest 20% of all cases.  The only required changes to the system to support additional cases are to specify:

(1) What new cases are covered (by providing appropriate selection criteria). 

(2) What new outcome(s) are needed (if any) for the new cases covered. 

(3) What new (encoded) decision rules should be used for the new cases. 

At a subsequent time, you ramp up to 50% of all cases, then perhaps 80%.  You may never get to 100% – nobody is talking about taking humans completely out of the loop for every operational business decision(!).  The net result is simply applying human resources where best suited, the really hard cases.

Continue Reading

‘Rules of Record’ … Why ‘System of Record’ Isn’t Enough

Business computing today is characterized by a tangled web of interfaces and data movement from system to system, from source to sink. Knowing the official ‘systems of record’ is basic for resolving discrepancies and demonstrating compliance. But that’s merely a start. What your business really needs today is to know the rules of record. A focus on business rules, rule management, and decision management makes that possible. This post explains. First a little background. If every piece of data in the organization had a single, clear home, identifying official versions would be easy. But in today’s world, operational data is extracted, merged, massaged, re-platformed, and reported many times over, often obscuring original sources. Identifying a ‘system of record’ establishes which source is official for each element (or chunk) of data. In other words, it gives you physical traceability back to source.[1] That’s a first and very basic step for compliance. What physical traceability doesn’t do is explain why that source may have a different value from the copy of the data you’re actually seeing. You might call that difference semantic drift (although that term probably dignifies what often is just plain sloppiness about the meaning and use of data). Since you can’t be sure what rules were applied to create the official version, you can’t easily do a delta on what you’re actually seeing. In other words, you have no semantic traceability back to source. From a compliance point of view, knowing the rules for source data is paramount. Of course, if those rules never changed, you might be able to reconstruct them at an acceptable price when and as needed for compliance. But today, change — at an ever faster pace — is the name of the game. Add massive personalization and customization to the mix and you quickly reach an impossible threshold of complexity and expense. The solution is simply never putting yourself in a position of having to reconstruct rules. Rather, you want to manage rules in such way to keep them ‘on the record’ — i.e., to maintain rules of record for each operational business decision your company makes. Impossible? Not at all. That’s exactly what business rules, rule management, and decision management is all about. There is proven technology to support it.[2] All you need to do is change how you look at the problem. References [1] For additional background on ‘system of record’ see: http://en.wikipedia.org/wiki/System_of_record http://www.yourwindow.to/information-security/gl_systemofrecord.htm [2] For example, Raden and Taylor write, “Logging rules as they execute to create a record of how a decision was made is a common requirement of decision services. They can be managed like a typical logging requirement, except that using business rules makes it easier. Using business rules also makes it possible to use the logged information in both customer-facing and regulatory conversations, because the rules are more user-friendly.” James Taylor and Neil Raden, Smart (Enough) Systems: How to Deliver Competitive Advantage by Automating Hidden Decisions, Prentice-Hall (June 2007), ISBN: 0132347962, p. 358. ~~~~~~~~~~~~~~~~~~ The original version of this post appeared as: “‘Rules of Record’ ~ Why ‘System of Record’ Isn’t Enough,” Business Rules Journal, Vol. 9, No. 1 (Jan. 2008) http://www.BRCommunity.com/a2008/b385.html

Continue Reading

Don’t Fall Victim to the Whirlpool of Decision Hype

Consider the following behavioral business rule: A renter must not have possession of more than one rental car. In discussing enforcement of this rule, one reviewer said something to the effect, “We have to think about what happens ‘at the time of the decision’. Hold on. What ‘decision’?! I don’t see any decision. What ‘decision’ could he possibly be talking about? When it comes to behavioral rules and their enforcement, there’s no ‘decision’ in a meaningful business sense. Let’s think it through.
  • There was the governance decision to create the business rule in the first place, but that’s not operational business activity per se.
  • There might be a decision about whether and how strictly to enforce the rule, but that is an enforcement question, not an operational business decision either.
  • If the decision is ‘Are we following our rules?’ that’s a bogus operational business decision. It might be valid as a test or simulation, but that’s not a decision per se either.
A good analogy for the enforcement of behavioral rules is a game of football. There are referees who ‘watch’ on-going (business) activity and throw a flag when a violation occurs. But they stand on the outside of the plays (processes) looking in. Now a player may ‘decide’ to violate a rule, but we frankly don’t care about individual ‘decisions’ of those kinds. We care only about the resulting (business) behavior (hence behavioral rules). Let’s return to the behavioral rule: A renter must not have possession of more than one rental car. Here’s the important point with respect to business processes. The rule is expressed declaratively. Although specified only once, it is presumably relevant to multiple business processes – e.g., for new bookings, rescheduling of existing bookings, extension of open rentals, late returns, etc. We call points in business processes where a rule needs to be tested ‘flash points’. Like the referees in a football game, a run-time business rule facility should be watching all on-going activity to detect violations anywhere and everywhere they might happen. You might say the facility is ‘deciding’ that violations occur, but who cares … again, those are not operational business decisions. For our purposes, violations either happen or they don’t. Don’t get me wrong. ‘Decisions’ do have an important place in both business rule thinking and in creating smarter business capabilities. But right now there seems to be a whirlpool of decision hype that’s sucking up altogether too many good brain cycles. We need to see what role decisions do play in business analysis clearly so we can exploit the new techniques to their fullest.

Continue Reading

A Buzzword Like ‘Decision’ that Covers Everything May Soon Cover Nothing

One thing that concerns me about ‘decision’ or ‘decision management’ is that everything potentially becomes a decision. Software vendors love it when complex problems can be reduced to a single buzzword. Engineers of true business solutions should hate it. I’m sure I’ll be accused of negativism, so for the record, let me say that top down analysis of operational business decisions is extremely useful, either along with, or outside of, business processes. We have a highly pragmatic approach for decision analysis based on ‘question charts’ (Q-Charts). We use it extensively to capture decision rules. But do I think that decision analysis is the most important part of delivering a winning business solution? Not by a long shot. Your strategy for the business solution is much more important. Even that’s not enough though – strategy only tells you why. We need business models that cover all aspects of a business solution (think what, how, where, who, and when). So no, it doesn’t (or at least shouldn’t) all boil down to ‘decisions’ … unless by that you mean anything and everything. And what good is that? I’m always very careful to say ‘operational business decision’ instead of simply ‘decision’. Immediately that excludes governance decisions (e.g., creating a business policy) and strategy ‘decisions’ (as in MBA-school ‘business strategy’). That’s an important first narrowing of the field. Something else commonly mistaken for an operational business decision is a simulation of “what would happen if we did this operational task right now”. For example, let’s run a claim by all the behavioral business rules and see if the claim is acceptable before we do it for real. That’s simply a test, not a decision. That’s a second important narrowing of the field. Clearly we need a solid definition of what a decision is and isn’t in the context of business analysis. We define an ‘operational business decision’ as: a determination in day-to-day business activity requiring know-how or expertise; the resolving of a question by identifying some correct or optimal choice. To make such decisions you need decision rules (think classification or inference rules) that ‘map’ cases to outcomes. Decision rules are one type of definitional rule. The two types of business rules in SBVR are definitional rules and behavioral rules. Business capabilities do usually involve large numbers of decision rules, but they also always involve large numbers of behavioral rules. Behavioral rules are rules you can violate, like speeding through a school zone. There’s no decision to that … you either are or you aren’t speeding. Well, you may have made a personal decision to speed, but let me tell you, City Hall doesn’t care. Personal decisions – out of scope too, a third important narrowing of the field.

Continue Reading

How Business Rules, Decisions, and Events Relate in True-to-Life Business Models

What is operational business know-how? How can you model it? What results can you achieve by doing so? The answers lie with creating true-to-life business models based on behavioral rules, decision rules, operational business decisions, and operational business events — all as first-class citizens. Understanding their intertwined roles is key to creating top-notch business solutions and business operation systems unmatched in their support for business agility and knowledge retention. Find out what ideas and techniques you need to create know-how models: http://www.brcommunity.com/b623.php

Continue Reading 1 Comment

Our Clients

[cycloneslider id="our-clients"]