I have been getting a bit behind with my blogging and tweeting recently but I was struck by a comment on Howard Dresner’s thread (@howarddresner) based on preliminary results from his survey (http://wisdomsurvey.com).
#BetterDecisionMaking (so far) is the top goal for #BusinessIntelligence – wisdomsurvey.com #BIWisdom
— Howard Dresner (@howarddresner) March 8, 2013
and Boris Evelson (@bevelson) chimed in to agree that Forrester’s surveys also show the same results.
MT @howarddresner: #BetterDecisionMaking is the top goal for #BusinessIntelligence – wisdomsurvey.com #BIWisdom > same in our surveys
— Boris Evelson (@bevelson) March 8, 2013
Now this got me thinking. If better decision making is really the number one goal for business intelligence one would expect that those working with business intelligence tools know which decisions they are trying to improve and that they have a pretty good idea what the structure of that decision-making looks like: 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 for instance. Particularly when the decision in question is going to be made over and over again – every week, every day or every second. The more operational a decision the more important this understanding is going to be.
My experience, however, is that most people have only the vaguest sense of the decisions they are trying to improve. They say things like “if we could predict customer churn we would be able to make better customer retention decisions” or “if we understood our customer segmentation better we could make better marketing decisions” and then they behave like that’s a precise enough definition to begin.
In our client work we find that this is not, in fact, enough. Without good decision requirements projects are likely to flounder around and are much more likely to create analytic results that don’t have a business impact, even if they are predictive and insightful. Good decision requirements have five elements:
- Question and answers
The first step is to state the decision you are trying to make 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. - Define the information
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. - Define the knowledge
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. Understanding what knowledge must be available to make any decision and what additional knowledge will help make a good decision both constrains the decision-making you are trying to influence and shows where business intelligence and analytics can have an impact. - Define decision making precisely
It’s not generally enough to have a question like the one above, you need also to understand how you go about answering 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 off. Now you have started to identify the pieces of your decision-making and you can repeat this process, breaking down each piece of the decision-making into more granular 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, it’s not SQL, 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 each element comes into play, making it easier to focus your analytic efforts. - Define the decision-making context
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. Failing to understand these is likely to undermine the rollout of your analytics, no matter how wonderful the analytics are.
Focusing on decision requirements is becoming increasingly common in projects focused on predictive analytics and on business rules. It’s less common in BI projects but as organizations scale up their BI efforts and focus more on repeatable, operational decisions this same approach will offer great value across the board. Carole-Ann Matignon said over on Smart Data Collective that Decision Management adds the last piece of intelligence missing from Business Intelligence. And the first step in succeeding with Decision Management is good decision requirements.
If you are interested in learning more about these techniques and how they can be put to work in projects, drop me a line james@decisionmanagementsolutions.com
Comments on this entry are closed.