Steven Barry is a Certified Master Anaplanner and Connected Planning Sales Lead at Kearney.
In Part 1 of the series, I introduced the decision contract as a way to clarify what decision a planning process must produce before the team begins designing the Anaplan solution. The contract defines the decision, owner, timing, required evidence, guardrails, and downstream commitment.
The real benefit appears when the contract begins to shape the solution. A decision-centered design focuses the model on the right business intersection, routes work based on materiality, and connects each decision to its broader impact.
The following principles can help translate a decision contract into practical Anaplan design choices.
- Model the decision at the correct level.
The dimensionality of the solution should reflect the level at which the decision is made.
A regional revenue commitment may exist by region, period, and scenario. A demand override may exist by product, location, and week. A hiring decision may exist at the individual position or requisition level.
This does not mean every supporting calculation must use the same dimensionality. It means the final decision, its owner, its status, and its rationale should be identifiable at the appropriate business intersection.
When the decision level is unclear, models often become larger and user experiences become more complicated than necessary. - Calculate before asking the user.
Users should not be asked to manually provide information that the platform can calculate or derive.
Anaplan should establish a credible starting point using available actuals, assumptions, statistical outputs, prior decisions, and business rules. The user should then apply judgment where judgment is valuable.
This changes the role of the planner. Instead of rebuilding a forecast from the beginning, the planner reviews the baseline, evaluates exceptions, and makes targeted adjustments.
It also creates a measurable comparison between the system recommendation and the final human decision. - Escalate based on materiality.
Many approval processes are designed around organizational hierarchy. Every submission moves from one level to the next, regardless of its value, risk, or complexity.
A decision contract allows the solution to route work based on materiality.
A routine adjustment within tolerance may not require additional approval. A large override, a change affecting a strategic customer, or a decision that creates a capacity constraint may require further review.
This reduces unnecessary work for leaders and gives them more time to focus on the decisions that could materially affect the business. - Capture the reason, not just the number.
A numeric adjustment without context is difficult to review and even harder to learn from.
The solution should capture why a decision was made. Structured reason codes can identify common drivers such as pricing, timing, customer behavior, supply constraints, hiring delays, or changes in demand. Commentary can provide additional detail when it is needed.
Structured rationale also creates information that can be analyzed. Over time, the business can determine which assumptions are most frequently wrong, which risks are recurring, and which types of overrides tend to improve the outcome. - Make the downstream impact visible.
Decision-makers should be able to see what their decision changes.
A demand increase may improve projected revenue while creating an inventory or production constraint. A delayed hiring decision may reduce near-term cost while putting a strategic initiative at risk. A sales forecast adjustment may affect workforce capacity, cash expectations, or delivery commitments.
Anaplan is particularly valuable when it connects these consequences across functions. The decision page should provide enough visibility for the owner to understand the broader impact before committing. - Close the loop when actuals become available.
Most planning processes move quickly from one cycle to the next. Teams spend significant time producing a plan but much less time evaluating the quality of the decisions made during the prior cycle.
The decision contract creates a structure for that evaluation.
Once actual results are available, the business can compare the baseline, the human adjustment, the approved decision, and the final outcome. This helps determine whether overrides improved accuracy, whether guardrails were appropriate, and whether additional review created value.
The purpose is not to penalize decision-makers when circumstances change. The purpose is to make the planning process smarter over time.
Measure decisions, not just task completion
Many Anaplan implementations measure whether users logged in, completed their inputs, submitted their plans, or received approval.
These metrics are useful for administering a process, but they do not prove that the process is working well.
A decision-centered process should also measure how long it takes to move from a business signal to a committed decision, how many decisions require manual review, how often submissions are returned for rework, and how frequently approved decisions change before execution.
Where possible, organizations should also evaluate whether human overrides improved the baseline and whether the agreed downstream action was completed.
Not every metric needs to be automated immediately. Tracking a small number of these measures for one planning cycle can reveal where the real bottlenecks exist.
A high submission rate may hide a large amount of rework. A fast approval process may hide unclear accountability. A highly accurate forecast may still arrive too late to influence the business.
A better conversation at the start of an implementation
The decision contract changes the questions asked during requirements gathering.
Instead of beginning with, “What spreadsheet do you use today?” the team can ask, “What decision does this spreadsheet support?”
Instead of asking, “Who approves this input?” the team can ask, “Who has the authority to make the final commitment?”
Instead of asking, “What fields should be mandatory?” the team can ask, “What evidence is necessary to make this decision responsibly?”
Instead of asking, “Which dashboard should we build?” the team can ask, “What information and actions does the decision owner need at the moment of decision?”
The answers provide a stronger foundation for user stories, solution architecture, workflow design, and adoption planning.
Conclusion
A well-built Anaplan model can make an existing process faster, more controlled, and easier to maintain. That is valuable, but it should not be the limit of the ambition.
The greater opportunity is to improve how the organization makes decisions.
Before beginning the next use case, take one critical planning decision and write its decision contract. Define the decision, owner, timing, evidence, guardrails, and downstream commitment. If the stakeholders cannot agree on those points, the process is probably not ready to be built. If they can agree, many of the model and user experience design choices become much clearer.
What is the most important decision supported by your Anaplan solution, and what changes in the business once that decision is made?
