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 ‘decision management’

The Debate Continues: Expert Systems vs. Business Rules … Yet Another Response

guest post by Jan Purchase, Director of Lux Magi Ltd ~~~~~~~~~~~~~~~~~~~~~ I do see value in distinguishing ‘policy’ rules from ‘expert’ rules. It’s also clear that, at their extremes, these rule types are poles apart. Still I fear that this distinction may be a continuum rather than a discrete dichotomy. Policy rules might be exemplified as the constraints of business operational practice – the rules that dictate what a company should and should not do. They might be mined from the boundary conditions of the fact model of the company’s business capability – as you suggest in your excellent book on this subject[1]. An example policy rule might assert, for example, “A company agent may be assigned to a high-value customer only if the agent is assigned to at most five other clients”. Expert rules, on the other hand, are often seen as more complex – for example, using heuristics to determine the best, anti-cancer drug to apply in a given situation, or forecasting regional sales opportunities. Often these expert rule bases use expert experience, genetic algorithms, fuzzy logic and feedback loops to reach a decision. They seek to augment, or even supplant, the wisdom of a small population of subject matter experts. But isn’t there a middle ground too? Consider an insurance policy decision rule that bin-sorts clients into good, bad and medium risk (the latter to be referred to a human underwriting expert). If this were a simple four-row, decision table based on the value of the policy and the risk profile of a client, you would probably consider it a ‘policy rule’. But if I add scorecarding, heuristics and analytics, at what point does it become an ‘expert rule’? Would you consider all decision rules (as opposed to constraint rules) to be ‘expert rules’? Or do they need to be complex or directly represent the experience of SMEs? Don’t all rules, to some extent, represent the wisdom of experts? Don’t many of them constitute and inform policy? In short: Is there a simple question we can ask (concerning a rule) to determine if it is a ‘policy’ or ‘expert’ rule? ~~~~~~~~~~~~~~~~~~~~~~~~ See my reply to Jan: http://www.brsolutions.com/2012/05/29/the-debate-continues-expert-systems-vs-business-rules/ Answer to Jan’s Question: The question to ask of every rule is whether the end-point is enforcement or is it a decision. An enforcement rule never becomes a decision rule, and a decision rule never becomes an enforcement rule. Once an enforcement rule, always an enforcement rule (assuming you don’t retire it). You can adjust thresholds (e.g., the mph of the speed limit), you can change the enforcement level (e.g., from ‘strictly enforced’ to ‘override with explanation’), you can change the sanctions (or eliminate them), etc., etc. And you can and should use analytics to measure and improve the rate of success in achieving underlying business goals. But it’s black and white. Enforcement is enforcement and decisions are decisions.

Continue Reading

The Debate Continues: Expert Systems vs. Business Rules

Here is my latest post in the on-going debate over decision management systems, expert systems, and business rules. ~~~~~~~~~~~~~ There is a fundamental difference between rules whose intent is enforcement (however strict) vs. rules whose intent is to make (expert) decisions. Rules whose intent is enforcement (e.g., speed limits) revolve around:

* detection of violations (think speed trap) * level of enforcement (e.g., strictly enforced) * violation message (electronic sign flashes ‘You’re speeding’) * violation response (cop chases you down the street with siren) * sanction or penalty (speeding ticket and a fine)

I chose an example that is probably not automatable (never be too sure) because such ‘behavioral rules’ (SBVR term) are everywhere in everyday life and therefore easy to comprehend independently of existing platforms and IT support. But there are a huge number that are automable; we just seem to be blinded to them sometimes for whatever reason (probably technical bias). Behavioral rules would not be involved in diagnosing (deciding) what’s wrong with a missle or classifying (deciding) the risk category of a prospect for insurance. In SBVR those are ‘definitional rules’ (or you could call them decision rules). They are about (encoding the know-how to make) smart (expert) decisions. It is true that decision rules often support behavioral rules in some fashion (e.g., is this particular speeder worth bothering over?). But it always comes down to this fundamental distinction: Is the end-point about enforcement, or is it about a decision. Enforcement and decisions are simply different. Are decision rules and behavioral rules both business rules? Yes. Should they be treated the same by platforms and methodologies? No. Why? They are different. Failing to understand the difference harms both business ‘users’ (poor governance processes) and decision management systems (oversell).

Continue Reading 4 Comments

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

The Fundamental Problem of Software Engineering is Not about Decisioning

I am always very careful to talk about ‘business rules’, not ‘rules’. We define ‘business rule’ as a criterion used in business operations to guide behavior, shape judgments or make decisions. We have not perceived any poverty of guidance that fits that definition(!). One reason we always say ‘business rules’ is because we make no attempt to capture rules that mimic intelligent behavior in the original sense of expert systems. That problem is at least an order of magnitude more difficult than capturing organizational (business) rules … which is hard enough as it is. Business rules always trace to some source … even if the source is now unknown (or has gone to work for the competition). Organizations are dependent on people on the inside, and on interactions with people and organizations on the outside. So a great many business rules are about the behavior (of people and organizations). Ensuring conformance with such behavioral rules – and being able to change and redeploy them quickly – is the fundamental failing of traditional software development. It literally boils down to keeping your commitments (as expressed in contracts, agreements, MOUs, deals, certifications, regulations, acts, laws and so on). I’m all for better decision management, but fail to address the root problem of software engineering and we’re simply grasping at straws.

Continue Reading