A decision requirements diagram (DRD), developed with with the Decision Model and Notation (DMN) standard, provides analytics projects with focus and direction, delivering value quickly without huge upfront costs or time investment.
- Outlines the business problem
- Frames the use of the analytic
- Sets up a solution approach that is likely to work.
In the first post in this series on Fixing the Broken Links in the Analytics Value Chain, I summarized survey results from the Economist Information Unit (sponsored by ZS Associates).
This survey identified two broken links in the analytics value chain – the failure of many analytic projects to accurately define and frame their problem so they could adopt an effective solution approach and the problems many analytic projects have operationalizing their result to generate improved actions and the change management that goes along with it. This post is about using decision modeling with the DMN standard to frame your analytic project and fix the first broken link.
My experience is that this step – framing the problem – is persistently under-called by analytic teams. In the rush to find new data, analyze it and try new techniques, teams rush the step CRISP-DM calls Business Understanding. But companies are realizing a hacker approach and a technical focus isn’t good for the business.
One of our clients who has adopted decision modeling for their analytic project requirements say they like to spend 80% of their time understanding the business problem and NOT spend 80% of their time understanding data (the classic analytic project).
A lack of suitable techniques is another issue. Most analytic teams that try and solve this problem do so with requirements documents and perhaps a list of metrics or key objectives and nothing more. While defining suitable measures of success is a critical first step, success in framing requires teams to recognize that analytics can’t improve metrics, only better decision-making can do that. The question is which decisions, made how, and by whom?
To frame analytic projects effectively, teams need to take the measures they have identified and find the business decisions that impact those measures. In particular, they need to find the day to day, repeatable, operational decisions that impact those measures. One or more of these decisions will have to be made differently thanks to any future analytic if there is to be any impact from the project.
Documenting these decisions, describing them in terms of the question that must be answered to make the decision as well as the possible answers, is a great first step. But how, exactly, are those decisions being made? How should they be made? Modeling the decision-making approach using the simple but powerful DMN standard clarifies the decision-making.
With a decision model, the roles of different groups in defining the approach and making the decisions day to day can be defined. The systems, processes and business environment that will be impacted by any changes can be identified. A clear understanding of the decision-making to be improved is formed.
With a decision model the team can identify how different potential analytics could change that decision-making for the better. They can define how the organization could tell they have improved it, thanks to linked metrics and measures, and they can do all this with strong business and IT participation – no need for the analytics team to go off and geek out on their own.
The end result is a clear frame for the analytic project that:
- Outlines the business problem (we don’t make this decision accurately enough and this is the measure that tells us this)
- Frames the use of the analytic (an analytic that predicted this kind of thing would be helpful at this point in the decision-making)
- Sets up a solution approach that is likely to work (these people will need to believe the analytic and it will need to be delivered in this specific business process to be useful).
In the final post in the series next week I’ll discuss how you can operationalize analytics to fix the action and change/management link. Meanwhile to learn more, download our brief on the 6 Questions To Ask Your Business Partner Before You Model.
Read the Rest of the Analytics Value Chain Series
- How To Fix The Broken Links In The Analytics Value Chain
- Operationaling Analytics with Decision Modeling