Some time back I came across an HBR article called Who Has the D? How Clear Decision Roles Enhance Organizational Performance (fee for full article) and I heard from a friend today that Bain was using this approach (see this Bain article for instance Who has the “D”?) as part of building what it calls a Decision-driven organization. Obviously, with my focus on decision management, this really caught my eye. Reading the great (free) piece on decision-driven organization on the Bain website a couple of things stood out.
Firstly Bain’s survey results show that people in high performing companies are much more likely to say that “Once decisions are made they result in prompt, effective action” and that “The decisions that matter get made promptly and well”. Clearly decision making is therefore a big deal for high performance companies and this is, of course, no surprise. Secondly they identified a number of elements to being successful in becoming a decision-driven organization and one stuck out. Over and over again when I talk to companies about decisions I am struck by their assumption that only senior people and knowledge workers are making decisions. But the folks at Bain see the same thing I do and correctly identify “Outstanding frontline execution, enabled by the right tools and working practices” as a critical success factor. When it comes to decision-making in the frontline, or decision execution more accurately, the issue is much more about making sure that the frontline people (and systems) can quickly find out what the right decision is or what the constrained set of options is than about them making an unstructured, freeform decision.
Which takes me back to the HBR paper which outlines a set of roles for decision-making to help make it clear who is supposed to do what. This outlines Bains’s RAPID® approach (also described in the Bain article). RAPID helps you define who Recommends how to make a decision, who must Agree to it, who Performs it, who should provide Input and who actually Decides. While the paper/article apply these to “manual” decision making I thought I would take a stab at applying it to automated decisions to show that the same approach works just as well in decision management.
- Recommend
The Recommender is responsible for making a proposal on any decision changes – new or changed rules, adoption of updated models for instance – gathering input and providing data and analysis to make a sensible choice of decision-making logic – Decision Analysis. They are responsible for consulting with input providers – hearing and incorporating their views, and winning their buy in so that the decision as automated delivers results that are accepted. - Agree
If your role is to agree then your responsibility is to negotiate changes to the rules with the Recommender if you have and escalate unresolved issues to the decider if the “A” and “R” can’t resolve their differences. As someone with an Agree role you can, if necessary, exercising veto power over the rules or rule change - Perform
In an automated system the Performer might be passing on the decisions of the system and handling exceptions, those decisions not handled automatically by the rules. - Input
The Input role is about providing relevant policies, regulations and expert opinion to the Recommender. Information provided should shed light on the proposal’s feasibility, legality and practical implications - Decide
The Decider serves as the single point of accountability for the decision. Their role is to resolve any impasse in the process of specifying the rules and analytics required so that an agreed set of logic and analytics can be implemented. They also need to be able to commit the organization to the decision making approach defined and to any changes in it.
If you are implementing an automated decision and applying business rules and analytics, you should think about these roles. Who plays them for each decision? How do you develop a working environment that allows the Recommend, Agree, Input and Decide roles to collaborate over the rules and models? Does the Recommender have the impact analysis tools they need? Can people in the Agree and Input read and understand the decision logic being implemented so they can actively participate in discussing it. All of this is worth knowing as you manage your decisions.
This post is largely based on one I wrote for the EDM blog called ‘Who has the “D” when the “D” is automated?’
Comments on this entry are closed.