Decision modeling and the graphical decision requirements diagram (DRD) helps analytics teams:
- Assess the predictive model’s value in business terms.
- Select the right delivery option.
- Know how to make the analytic actionable.
This is the third in a series of blog posts on Fixing the Broken Links in the Analytics Value Chain. I started by summarizing some great survey results from the Economist Information Unit (sponsored by ZS Associates). This survey identified two broken links in the analytics value chain. In the second post, The Analytics Value Chain: Framing Analytics with Decision Modeling, I addressed one of these (the failure of many analytic projects to accurately frame their problem so they could effectively solve it).
This post is about using decision modeling to fix the second broken link – the problems that analytic projects have operationalizing their results.
The first step in making sure that an analytic is going to be used and the business value will be realized is to make sure the evaluation of a completed model is a business evaluation not a technical one. Analytic teams can use a decision model that puts their analytic into a business decision-making context to evaluate the analytic to make sure it’s really going to help improve that decision-making.
Without decision modeling, analytic teams often assess the statistical accuracy of a model in technical terms without considering if the model is going to be useful in business terms.
The next step is making sure you select the right analytic delivery options. The style of analytic (is it visual or numeric, fixed or interactive for instance) must match the style of decision making intended. An automated decision, embedded in a website for instance, requires a different approach to a manual decision being made by a call center rep. An analytic that must be used to make a decision by a mobile worker is different from one that supports a desktop worker and so on.
A decision model also helps ensure the organizational impact is clear. Whose behavior will have to change? Have they been involved in reviewing the analytic? Which systems or processes will have to be re-coded around the analytical decision? Can It make these changes? Does the data the model need exist in those systems?, etc. Far too many models get built but take so long to deploy they are worthless by the time anyone uses them – or the organization just gives up on it. Getting this clear up front makes for an easier, quicker deployment cycle.
It’s important to remember that real improvement to decision-making is going to require that you wrap your analytic model in decision-making logic to make it actionable. Your decision model shows you how to do this, modeling the non-analytic elements of the decision-making as well as showing how the analytic is used by the decision. For instance, a decision model for claims processing might include a fraud prediction as well as audit, regulatory and policy-based exclusions.
A quick aside here: A business rules management system (BRMS), especially one integrated with good analytic model deployment capabilities, is an effective platform to deploy a decision service to automate or support the decisions you have modeled. It will let you deploy your model for real-time or at least low-latency execution too, an increasingly important consideration. Integrated with your decision model it can support the ongoing maintenance and management of the decision-making that’s wrapped around your analytic.
One final thing. Change is not a one-time thing. Once deployed, models must be monitored and kept up to date, so make sure you capture the right data to prove it works and to see when it degrades. Nothing undermines long term success like an un-monitored model. A decision model shows what interim results and business outcomes should be tracked and this should be combined with data about the model and its behavior to allow ongoing monitoring and improvement of the model and the decision.
Decision modeling can fix the broken links in your analytic value chain. Check out our brief on the 5 Things You Need to Know Before You Deploy Your Model to learn more.
