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


We systemize tacit knowledge into explicit knowledge

Blog Enabling Operational Excellence

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

Breach Specifications for Decision Rules

Your ability to respond in appropriate ways to pinpoint circumstances where business rules are breached – automatically and independently of processes – provides the mechanism you need to support very smart, very friendly business systems. Normally we think about breaches occurring for behavioral rules, where a breach means a violation has occurred. Can breaches occur for decision rules too? The answer is yes and no. Read on! A breach occurs for a business rule when the business rule isn’t satisfied upon being applied to some set of circumstances (state of affairs). Normally we think about breaches occurring for behavioral rules, where a breach means a violation has occurred (e.g., you violated the posted speed limit). The potential for violations of behavioral rules raises several important questions that business analysts should answer in advance of deployment for each behavioral rule[1]:

1. What level of enforcement should be applied.

2. What special response to a violation is appropriate, if any.

3. What special message, if any, should be returned to some worker(s) upon a violation.

Unlike behavioral rules, no definitional rule[2] can ever be violated. Literally, things must be correct under such rules by definition. Let’s take an example. Suppose somebody asserts “2+2=5”. According to the rules of mathematics, we know the correct answer is 4. The answer “5” is deemed irrevocably wrong. But is the asserted answer ever allowed to stand?
    • If the rule is defined as a decision rule, the asserted answer is never allowed to stand. More precisely, the assertion would never be recognized to have happened in the first place. If someone asserts “2+2” the answer “4” is concluded immediately. Period. No breach, no opportunity for error.
    • If defined as a behavioral rule (one that is not strictly enforced), the asserted answer is allowed to stand, but a violation is recognized. How might that capability be useful? Suppose the error were made by a student in grade school. It might be quite useful for the student and/or a tutor to know about it immediately and automatically. Specifying an appropriate violation response can make such notification happen.
In business, of course, definitional rules can be far more complex. Nonetheless, your ability to respond in appropriate ways to the pinpoint circumstances where certain rule-related events occur – automatically and independently of processes – provides exactly the mechanism you need to support very smart, very friendly operational business decision systems. Decision Rules and Breaches Decision rules[3] are a special kind of definitional rule involving implications (e.g., A implies B). They support inferences and determinations – identifying an appropriate outcome from among a set of alternatives. Like all decision rules, definitional rules cannot be violated. They are simply deemed true by definition. Purely from a business perspective, however, some assertions of fact(s) may make it appear that a breach-like event has occurred. I take pains to emphasize any such perception is purely from the business perspective, not from the perspective of logic. You perceive a breach of a decision rule simply because it’s useful to do so, not because any true violation has occurred. In evaluating some particular case (situation, set of circumstances, or matter of concern), for example, things might not follow the ‘happy path’. Think of a breach of a decision rule as a bump in the road – a gap along the happy path. Let’s return to the three questions listed earlier. Although the first question about enforcement level obviously doesn’t apply to decision rules, adjusted versions of questions 2 and 3 remain in play. Consider the following simple business example. Suppose a bank has this decision rule:

A credit application must be considered discrepancy-free with respect to a credit report for the applicant if all the following are the same:

    • name
    • date of birth
    • Social Security Number
    • current address
    • previous address
Let’s suppose that an applicant uses just the initial for her middle name on her credit application. If the credit report shows her full middle name, then the names are not the same and the credit application will not be considered discrepancy-free. Note carefully the rule hasn’t been violated; it did its ‘work’ correctly and it did reach the proper conclusion (not discrepancy-free).  But a gap – a breach – for her case has been identified from a business perspective because the rule failed on one of the conditions. We should be able to take advantage of that breach to take appropriate action – selectively, automatically and in real time. For example, the desired response to the breach might be to insert the following to-do item in the work queue of the responsible staff member: “Review discrepancy and manually ok if appropriate”. (The to-do item should naturally also provide ready access to the related documents.) The breach of the rule causes this action to occur automatically. Think about how many decision rules might exist for determining credit-worthiness, and how many selective conditions they might have. Could you build a responsive system by incorporating the selective responses needed into the related process model(s)? Not a chance – that approach won’t scale. Instead, the selective responses need to be specified based on the business-rule side of things. Kinds of Breach Specifications for Decision Rules Breach specifications for a decision rule can be of the following two kinds.[4] Breach Response. A breach response can be an action of virtually any kind. For example, a breach action might be to:
  • Add some task(s) to a (non-redundant) to-do list in some appropriate work queue.
  • Add some documentation items to a (non-redundant) not-yet-received list.
By these means very selective follow-up processing/handling (“what to do next”) can be organized pertaining to any specific issue (breach) for a given case. Such selectivity is made possible by the granularity of the rules. Breach Message. A specially-worded breach message can be forwarded to any involved party either inside or outside the company. A breach message generally explains one or both of the following at any level of detail desired:
  • Why the rule or condition failed. (The rule or condition statement already indicates very precisely what the issue is, but the breach message can explain in a more friendly manner.)
  • What should be done to address the issue.
More Complex Example Breach specifications apply selectively and specifically to a decision rule and/or any of its conditions. A breach specification applies if and only if that decision rule and/or condition fails (is not true) in evaluating some specific case (e.g., a specific credit application). An example of a decision rule with condition-specific breach specifications is illustrated in Table 1. Table 1. Example of More Complex Decision Rule with Condition-Specific Breach Specifications

Decision Rule

Breach Response

Breach Message

A fluctuating income must be considered eligible if all the following are true:     

Conditions of the Decision Rule



  • the applicant has a 3-year proven track record of consistent income
  • the applicant is likely to have comparable income in the future
Add to-do item for that credit application: “Contact employer to verify applicant has reasonable opportunity for future income.”  
  • the income is validated
Add required documentation items not yet received to a pending list for the credit application. To applicant: “[date] Here’s a list of documentation items related to your income we have not yet received. [pending list].”
  Using Breach Specifications Breach specifications can be:
  • General for an entire decision rule including all its conditions. (The example in Table 1 doesn’t include any whole-rule specifications. If the rule did they would appear in the first row.)
  • Specific to a given condition.
  • Specific to collections of conditions (none shown for the example).
A breach is detected only if the conclusion of the rule as a whole, or some particular condition within it, evaluates to not true. Things being true should be viewed as moving the case along the desired path (i.e., no breach has occurred).[5] Decision rules (and breach specifications) should be expressed carefully so as to preserve this positive orientation. Generally, breach actions should be specified only if something can be done to overcome a failure (of a rule or condition). The goal is to move things forward in the case.[6] In the example above, for instance, if nothing whatsoever can be done to correct an issue, the credit application should simply be declined. A behavioral rule to that effect should be specified. In hierarchies of decisions (e.g., as in Q-Charts[7]) and decision rules (e.g., as based on series of logical dependencies), breach specifications should generally be made only at the lowest level of rule reduction/decomposition. A rule at a higher level in a logical hierarchy only evaluates to not true if some rule(s) below it evaluate to not true. Define breach specifications at the lowest level of granularity. ~~~~~~~~~~ www.BRSolutions.com
[1]Ronald G. Ross, “Breaking the Rules:  Breach Questions,” Business Rules Journal, Vol. 14, No. 2 (Feb. 2013), URL:  http://www.BRCommunity.com/a2013/b688.html
[2]Ronald G. Ross, “What Is a Business Rule?” Business Rules Journal, Vol. 11, No. 3 (Mar. 2010), URL:  http://www.BRCommunity.com/a2010/b525.html   
[3]Ronald G. Ross, “Decision Rules vs. Behavioral Rules,” Business Rules Journal, Vol. 14, No. 7 (July 2013), URL:  http://www.BRCommunity.com/a2013/b709.html 
[4]Although rules can be specified in violation specifications for behavioral rules (e.g., to express some sanction or penalty), they should never be specified within breach specifications for a decision rule. Such ‘nesting’ of rules, especially on the basis of ‘not true’, is inappropriate.
[5]Otherwise the advantages of overall declarative specification can be forfeited.
[6]By default, breach specifications for a decision rule apply only the first time it is evaluated for each case. The assumption is that all business rules, including decision rules, are evaluated on a continuous basis. Re-application of any breach specification for a case therefore requires additional timing and iteration criteria. Whether a case is evaluated iteratively on the same set of decision rules based on timing criteria applied by or for some external process or platform is outside the scope of this discussion. No matter what the scheme of evaluation, the expression of the decision rules – as for all business rules – should be completely unaware of it.
[7]Ronald G. Ross, “Modeling Decision Structures — Part 2:  Question Charts (Q Charts™) and Hybrid Diagrams,” Business Rules Journal, Vol. 14, No. 10 (Oct. 2013), URL:  http://www.BRCommunity.com/a2013/b722.html

Continue Reading

A Follow-Up Note to Business Analysts about ‘Decision’

In a recent blog post I called attention to the fact that there’s a major collision of terminology with respect to the term decision as used by different communities. See: http://www.brsolutions.com/2014/07/06/a-note-to-business-analysts-about-%e2%80%98decision%e2%80%99/ My basic observation was that both communities are correct in their own context – but since the contexts intersect the result is a significant potential for confusion.
  • Business Analyst Community. Decision is often used in talking about business analysts’ own work – i.e., what methods to use, go/no-go on change, tool selection, choice of elicitation approach, etc. Its usage also seems to cover the sense of “management decision” – e.g., what course should project work take.
  • General Business Community. Decision always refers to a determination in business activity – e.g., should this applicant be given a mortgage, what should be charged for shipping an order, etc. This is the focus of decision in the business rules / decision engineering community.
Let me make some additional observations. A first question one should ask to clarify decision is what is the time horizon? Is it strategic or operational? A second question one should ask is what does decision actually refer to when used by each community for a given time horizon? Table. What Decision Refers to Based on Community and Time Horizon
Time Horizon of Decision

General Business Community

Business Analysis Community


strategic business decision strategic project decision or change initiative decision or option analysis


operational business decision  —
  In contrast to operational decisions, strategic decisions are always longer in time horizon, and generally made only once (which isn’t to say they can’t be revisited sometimes). This point is true for both communities. The distinguishing characteristics of an operational business decision is that it:
  • Is highly repetitive (100s, 1000s, or more per day, hour, etc.).
  • Can be encoded as practicable business rules.
Note: My analysis doesn’t address operational decisions for the Business Analysis Community (the cell show with dashes). That’s not because decision isn’t applicable in that context, but rather simply because it’s outside the scope of the present discussion. I recently saw the following draft definition of decision, which illustrates the problem of mixed meanings quite clearly.

An activity to answer a question or select an option from a known or knowable set of possible options. Typically defined in terms of business rules and made in response to events or at defined points in a business process.

  • The first part of the definition is reasonable for decision in any usage. It applies to both communities and to any time horizon.
  • The second part of the definition pertains only to the meaning of operational business decision. Strategic decisions, whether for the General Business Community or for the Business Analysis Community, are generally not based on specific business rules and are not made in response to events or at defined points in a business process. Strategic decisions are simply different in kind from operational business decisions.
The focus of a strategic decision is also quite different for each of the two communities.
  • General Business Community: The focus is on conducting future business in a certain way.
  • Business Analysis Community. The focus is on conducting a proposed initiative in a certain way to change the business itself.
Bottom Line: For clarity, I would always qualify decision to indicate which kind is meant. We certainly don’t need any more confusion in business engineering than already exists! www.BRSolutions.com

Continue Reading

A Note to Business Analysts about ‘Decision’

Perhaps the following point about the term decision is already clear to all, but at the risk of stating the obvious, I’ll make it anyway. There’s a major collision of terminology with respect to decision as used by different communities.    
    • In the business analyst community, decision is often used in talking about business analysts’ own work – i.e., what methods to use, go/no-go on change, tool selection, choice of elicitation approach, etc. Its usage also seems to cover the sense of “management decision” – e.g., what course should project work take.
    • In the larger business community, decision always refers to a determination in business activity – e.g., should this applicant be given a mortgage, what should be charged for shipping an order, etc. This is the focus of decision in the business rules / decision engineering community.
In the context of their own communities both usages are correct. Unfortunately, the collision often results in confusion about the appropriate focus – and about which methods to use – for both audiences. In situations such as this, the best practice is to define the concept in question for each community. Terms considered to be obvious usually aren’t. It’s not clear to me that this has been done explicitly in the business analyst community. Another best practice is to qualify the term every time it’s used. So we always say operational business decision when talking about the business context, not just decision. That also distinguishes the concept we mean from other potential sources of confusion – e.g., strategic business decisions and system-level decisions or IT decisions. I believe what the business analyst community means by decision is strategic project decision or strategic change decision. But I can’t really be sure since as I say the term doesn’t seem to have been defined. www.BRSolutions.com

Continue Reading 3 Comments

Semantic Muddle in the Decision Model & Notation (DMN) Standard

Comment by DMN proponent: In common business use the term “decision” is often overloaded to mean “decision output”. So I “make a decision to do X” is the act, whereas I “use the decision as input to another decision” is referring to the decision output. I’m not sure there are any semantic issues with (i.e. possible problems caused by) this overloading? My response: Since DMN is a standard (and in particular claims to be a business standard), then it must stick with its own definition of terms in all cases. Otherwise, in what sense is it a standard (especially a business standard)? In defining “decision” DMN had two fundamental choices (from Merriam-Webster Unabridged dictionary): 1. a : the act of deciding; specifically : the act of settling or terminating (as a contest or controversy) by giving judgment 1. b : a determination arrived at after consideration : SETTLEMENT, CONCLUSION DMN explicitly chose the first meaning. I strongly prefer the second, but then I’m a big fan of all things declarative. So in BRS TableSpeak[1] an outcome by definition is a decision. Since DMN explicitly chose the first meaning, however, an outcome (conclusion) is by definition *not* a decision. A decision is an act, never the result of the act. Hey, I’m just reading what is written in the standard. If DMN somehow allows ‘overloading’ of the term “decision” — the central term in the standard — all bets are off. A term that you can use any way you want when it happens to suit you is a term that has not been standardized at all. The result is semantic muddle. Pretty big deal. Sorry! www.BRSolutions.com  

Continue Reading 4 Comments

Is a Decision-Based Approach Sufficient for Business Rules?

Consider the following example.

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

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

Continue Reading 5 Comments

A Playful Riff on “Decide”

A person close to the DMN (Decision Model Notation) standard recently wrote:

I can’t see how you can object to the idea that decisions can be automatic, or used for detection, unless you maintain that decisions can only be taken by people?

  My Response Putting theological questions aside, in the beginning there was man. Well, people. Well, animals and people. As far as science is currently aware, there is nothing else in the universe that can “decide” something. Well, let’s put quantum mechanics aside. How things get “decided” there is just plain weird. That’s not human scale anyway (as far as science is currently aware). My point is that the concept “decide” makes absolutely no sense unless you acknowledge that “deciding” is a human concept. People decide stuff (or decide when things have been “decided”.) When Machines “Decide” Can machines “decide” things? Of course. Can they often “decide” things better than humans? Of course. Can they often “decide” things instead of people? Of course. Would you call what it is the machines do in such cases “deciding” if there were no people who could do the thing we call “deciding” in the first place? Of course not. “To decide” is fundamentally a human characteristic. If you try to remove the “human” sense of “to decide” from the verb, it’s not how the average person would understand it. This sense comes across clearly in the real world definition of “decide” [MWUD]: to dispel doubt on. When Machines “Doubt” Can machines “doubt”? I’ll let the philosophers decide that (yes decide). I’ll just say this: I doubt (yes doubt) it would be called “doubt” unless people experienced “doubt” in the first place. So when you use the word “decide”, even for what machines are doing, use it for things that people would call “decide”. If you want to use the word “decide” for machines in some other way – for things that people wouldn’t call “decide” in the real world – then please, just plainly admit you’re in systemland, not in peopleland.

Continue Reading

The DMN definition of ‘decision’ … I don’t think so(!)

A person close to the DMN (Decision Model Notation) standard recently wrote:

In DMN a decision is deliberately defined very broadly … 

“a decision is the act of determining an output value (the chosen option), from a number of input values, using decision logic defining how the output is determined from the inputs”.

My Response I’ve already written that the DMN definition of “decision” seems to be a bit circular. (To know what a “decision” is you need to know what “decision logic” means. But since “decision logic” says “decision”, seems like you need to know what “decision” means.) Let me tell you what else I find wrong with the definition. (All dictionary definitions from MWUD.) Problem 1. MWUD defines “decision” as (1a) the act of deciding. It defines “act” as (1a) a thing done or being done. So which is it? Is a decision a thing “done” or a thing “being done”? In other words, is a decision the result of an action or process, or the performance of an action or process? Big difference! Which does the standard mean? Some clarity would be nice. Problem 2. MWUD defines “decide” as: to dispel doubt on: (a) to arrive at a choice or solution concerning which ends uncertainty or contention *decide what to order for breakfast*  (c) to infer or conclude from available indications and evidence So the real-world definition of “decide” talks about …
  • Arriving at “a choice or solution”.
  • Basing that choice or solution on “indications and evidence”.
Do you see anything in that definition that reduces what is used in making decisions to “inputs” and “outputs”?! That’s ITspeak, not businessSpeak. So let’s not pretend the DMN standard is really about business modeling per se. It’s business reduced to a system view. Problem 3. “Input value” is definitely ITspeak. Fields and attributes in files and databases are what have this kind of “value”. In the business world, people talk about cases, applications (appeals, requests, petitions), communications, situations, circumstances, trends, profiles, and the like. They don’t talk about “input values” to a decision. Get real. Again, the authors of the DMN standard should either be clear it’s really about system stuff … or admit to causing confusion, deliberately or otherwise.

Continue Reading

My 3 Biggest Fears Regarding the DMN (Decision Model Notation) Standard

A person close to the DMN (Decision Model Notation) standard recently wrote:

“Under DMN we would say that the automatic detection of the violation of a constraint is indeed a decision.”

My Response … Which part of any definition of any of the following terms in your statement would in any way, shape or form lead to the notion of “decision”?!
  • automatic
  • detection
  • violation
  • constraint
You’ve put you finger squarely on the three confusions (shortcomings) I fear most from the DMN standard — failure to:
  1. Comprehend that behavioral rules are a quite different animal from decision (or definitional) rules.
  2. View “decision” from a businessperson’s point of view.
  3. Define “decision” as meant in the real world.
Is this going to put another standard emanating from an IT background parading as a “business” paradigm? Another standard where hype beneficial to existing vendor products outweighs true clarity and innovative leadership? I am hoping for the best … I want the standard (if good) to succeed … but fear the worst. I’m afraid your statement doesn’t instill much confidence.

Continue Reading 1 Comment

Announcing New Online Interactive Training: Decision Analysis & Decision Tables: All About Modeling Decisions

  Location: Online Interactive Training Why Attend … Working on developing requirements? Wrestling with complex business process models? Harvesting business rules to implement in a rules engine? Many professionals are finding there are big gaps in their current approaches:
  • Their requirements methodology fails to capture and specify decision logic.
  • Their business process models mangle the logic for making decisions.
  • Their decision management platforms support implementation but don’t connect to the business.
This training provides proven, pragmatic solutions. It provides 8 easy steps so you can think clearly before you implement. More info:  http://www.attainingedge.com/online-training-decision-analysis-and-decision-tables.php Register for full series!

Session 1. Business-Friendly Decision Analysis

Next Session: November 20, 2013 @ 10:30am – 12:00noon (ET)

  • Why decision analysis
  • What decisions and decision logic are about
  • The elements of decisions
  • Using DecisionSpeak to ask the right questions
  • Diagramming decision structures (Q-Charts)
  • Question, considerations, outcomes, and exceptions (Q-COEs)
  • What kinds of business rules are suited for decision analysis – and which are not
Register Session 1

Session 2. Analyzing Decisions and Developing Decision Structures

Next Session: November 20, 2013 @ 3:30pm – 5:00pm (ET)

  • How to establish and refine scope for decision analysis
  • Identifying exceptions
  • Delineating subdecisions
  • Kinds of decision dependencies
  • Hybrid dependency diagrams
  • Critical success factors for conducting decision analysis

Session 3. Designing Decision Tables

Next Session: November 21, 2013 @ 10:30am – 12:00noon (ET)

  • How to keep decision tables as simple as possible
  • How to maintain business alignment
  • How to set-up decision tables using TableSpeak
  • When to use which format when
  • Completeness, anomalies and certainty of outcome
  • Vocabulary, integrity (correctness) and validity
  • Pitfalls
  • Best practices

Session 4.Beginning-to-End Decision Analysis

Next Session: November 21, 2013 @ 3:30pm – 5:00pm (ET)

  • 7 steps from initiation to testing
  • Roles and responsibilities for each step
  • What to watch out for in interpreting from sources
  • Sample deliverables
  • How to develop scenarios for testing
  • Complete case studies
  • Implementation: highlighting 3 business rule and decision management platforms

Continue Reading