I am attending IBM IMPACT and this is a duplicate post for one running on the IBM IMPACT Blog.
Business rules get everywhere – we have business rules in our user interfaces, in data quality, in business processes and more. But when organizations adopt a business rules management system they are focused on improving decision-making. A business rules management system like WebSphere Operational Decision Management lets us automate, improve and manage decision-making in our business processes and systems.
To be successful with a BRMS, as with any technology, we need to be clear what we are going to do with it. We need requirements for our project which clearly specify what is needed and how that will add value to our business. If better decision making is our goal then our requirements specification process should ensure that we know which decisions we are trying to improve and have a good idea of the decision-making involved. Our requirements should include an understanding of what policies or regulations apply, what information is available, who makes the decision and who has a say in how the decision should be made and much more.
In my client work I find that too many projects do not do a good job of this. Without good decision requirements these projects are likely to flounder around and fail to have a positive business impact. Traditional requirements techniques like use cases or requirements lists tend to identify the need for decision-making but are not suitable for specifying how decisions should be made. Simply capturing business rules in a spreadsheet or list focuses on details before structure and often results in a “big bucket of rules.” To be successful we need a new way to capture our requirements – a decision requirements model.
A decision requirements model has five elements:
1. Decisions
Each decision is specifically identified and described with a precise, detailed question and a set of possible (allowed) answers. So a retention decision might be written as “Which of the available retention offers should be made to this customer if they call in to cancel their service?” with any of the defined marketing offers being allowed as an answer.
2. Information Requirements
Decision-making involves information and the most basic piece of a decision requirements model is an understanding of the data or information that must be available to make the decision at the business concept or business object level.
3. Knowledge Requirements
To make a decision requires knowledge, know-how. This could be expertise or best practices in people’s heads, it could be policy or regulation, or it could be analytic insight like the results of data mining or a predictive analytic model. The model should identify what knowledge must be available to make any decision and what additional knowledge will help make a good decision.
4. Decision Structure
A single decision definition is not enough to specify a business rules project. Decision requirements models also describe how to go about making the decision, how to answer the question. Perhaps you have to decide how valuable the customer is, how likely they are to respond to a retention offer and which product category would be most appealing before you can pick a retention offer. This begins to identify the pieces of your decision-making and each piece can be identified as a decision, a sub-decision if you like.
You can repeat this process, breaking down each piece of the decision-making into more granular decisions or questions until you understand it fully. This decision decomposition outlines how you want to make this decision, or how you want the people in your call center to make the decision, each time. It’s not code or business rules but it is precise. With this in hand you can look at the information and knowledge you identified and see if still seems complete given your new understanding (it won’t be) and you can see exactly where in the decision making each element comes into play.
5. Decision-making context
Finally decision requirements need to include organizational, application and business context for the decision making. Understanding who decides how a decision should be made as well as who has to make it clarifies the organizational context of a decision. Understanding the business processes, events and systems that need a decision shows how your decision-making will need to be implemented, its application context. Understanding the business objectives and metrics that will be impacted gives you a performance context.
Here’s an example
In this example we are using the notation being adopted as part of the Decision Model and Notation standard, currently under development for the Object Management Group (both IBM and my company, Decision Management Solutions, are submitters on this standard). Decisions show as rectangles with the solid arrows showing information requirements – decisions at the arrow end require the information that comes from an external information source (oval) or decision at the blunt end. Knowledge Sources, such as policy documents or regulations, are shown as documents and the dashed line shows which decisions require which knowledge sources – known as authority requirements.
With a decision requirements model in hand your business rules can be identified and described not as a single list but in terms of the rules for each of these sub-decisions. This focuses rule capture and completeness checking on a much more well defined scope. You also already know what the possible actions for the rules can be (the answers allowed for the question you identified) and how these rules fit into the larger picture. You also know which organizations and external knowledge sources are likely to be relevant. The model also shows you who cares about the rules and will need to review them as well as who will be maintaining them over time (because you know which pat of the organization owns or makes each decision in it).
If you have questions about decision requirements modeling why not come by one of my sessions at IMPACT:
- I’m giving an Ignite presentation, 5 minutes on decision modeling at 12:00 or so on Tuesday in the Social Corner at the Solution Center
- I’m giving a Champion’s Corner talk in the same location at around 1pm, just me and a white board discussing decision requirements modeling
- I’m presenting on Decision Management Cases: Agility and Adaptability in Insurance, Travel and Healthcare (3188) at 5pm in Lido 3101B
- I’ll be signing my book right after that at the bookstore so feel free to come by and ask questions, even if you already have the book!
Enjoy IMPACT!
Comments on this entry are closed.