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 ‘decisioning’

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