Worked examples

Five Anaplan problems, solved from the exports

Each scenario walks through a kind of situation we meet in Anaplan estates and shows exactly what AnaDocs AI produces for it: the pages, the numbers and the decisions they support.

How to read these. These are illustrative scenarios on anonymised model profiles, not customer testimonials. The model sizes and counts are typical of what we see; every figure is the kind AnaDocs computes from a model’s structure, and the features named are live in the product today. On your own model you will get your numbers, not these.

Polaris decisionBudget from real blockers Builder has leftDocument the unexplainable Slow modelRecover 31% of memory Already on PolarisTune, do not migrate Centre of ExcellenceEight models, one map

Scenario 1 · Polaris migration decision

Should this FP&A model move to Polaris, and what would it cost?

The situation

A Classic planning model of 52 modules and about 700 line items had hit its workspace limit twice in a year. Polaris was on the roadmap, but every estimate of the migration effort was a guess, and the team feared the formulas that would stop working.

What AnaDocs showed

Engine detection confirmed Classic from the exports and sized the model against Anaplan’s published cell costs.
12 line items will not work as exported (LOOKUPs on a coarser time scale and mapping dimensions Polaris rejects), 57 will calculate differently and need reconciling, and 184 patterns work but would hurt performance in Polaris.
A phased plan: 48 delivery days plus 14 client-side days, 11 weeks to cutover including a parallel run, priced at the team’s own day rate, with the assumptions editable on the page.
Fix Studio produced paste-ready rewrites for the blockers, and the remediation workbook listed every finding by module.

What changed

The migration was approved with a budget grounded in a count of real problems, not cell counts.
The 12 blockers were fixed in the Classic model first, so the move itself carried no surprises.
The plan and the workbook became the project charter.

Scenario 2 · The builder has left

A 234-module model nobody could explain any more

The situation

The architect who built a 234-module, 2,000-line-item commercial planning model over four years left the company. Three weeks later a quarter-end change was needed in a module whose formulas ran to 400 characters, and nobody dared touch it.

What AnaDocs showed

Every formula in plain English with its references, and a lineage view showing what feeds each line item and what depends on it, across modules.
Module purposes and a business glossary generated from the structure, so the new builder could read the model like a document.
The Copilot answered questions such as “which modules feed the margin reporting?” and cited the exact module and line item for every claim.
A handover pack and the full documentation site, exported for the team.

What changed

The new builder made the quarter-end change in two days instead of the fortnight the team had planned for.
The documentation is regenerated after every release, so the knowledge no longer lives in one head.
Onboarding for the next hire started from the handover pack rather than from screen-shares.

Scenario 3 · The model that got slow

Finding the 31% of memory nobody was using

The situation

A supply-planning model had grown to 110 GB. Saves took minutes, the nightly process overran, and the team was about to request a bigger workspace at a five-figure cost.

What AnaDocs showed

The Optimisation report for Classic listed where memory and calculation time went, ranked by impact, each rule traced to Anaplan’s own guidance and the Planual.
Summary methods left on by default on large line items, text line items dimensioned by day, and two staging modules nobody read any more accounted for 31% of the model.
The health score rose from 58 to 82 as the quick wins were applied; every change came with a paste-ready fix and a “how to verify” step.
The Model diff confirmed that no formula logic had changed, only size.

What changed

The workspace upgrade was cancelled; the model fell to 76 GB.
The nightly process finished inside its window again.
The report is re-run before each release to stop the creep returning.

Scenario 4 · Already on Polaris

Tuning a Polaris model when the grid says 361,000 TiB

The situation

An insurance model had been built on Polaris from day one. Classic-era tooling priced it as a dense grid of 73 quadrillion cells and recommended a migration it had already made. The real size was 17 GB, and nobody knew where it went.

What AnaDocs showed

AnaDocs read the reported size and the populated cell counts, detected Polaris, and showed the real 17 GB with the per-module split instead of an impossible dense figure.
The Polaris track of the Optimisation report ranked the tuning backlog in the order Anaplan’s own Polaris guidance recommends: “All cells” formulas first, then one-to-many LOOKUP chains, then summary methods on large line items.
No migration plan, cutover or effort estimate was shown, because the model already runs on Polaris; the page says so and points to the tuning list.

What changed

The team rewrote the eleven “All cells” formulas that drove most of the populated-cell growth.
Calculation effort on the heaviest module fell by half, measured in Anaplan after the change.
The tuning backlog became a standing item in the release checklist.

Scenario 5 · The Centre of Excellence

Eight models, one data hub, and three risks nobody had written down

The situation

A CoE ran eight models across three workspaces, fed by a data hub. Each model had an owner; nobody owned the connections between them. A list changed in one model broke a report in another every few months.

What AnaDocs showed

Build my estate pulled all eight models in one background job, and the estate map drew the real feeds from Anaplan’s import definitions: six confirmed imports, four file hand-offs and one CloudWorks flow.
The data hub was flagged as a hub and single point of failure for the UAT model.
Risks with evidence: the SKU list differed across four models, the test model was one revision behind development, two feeds had failed on their last run, and one import pointed at a model the login could no longer see.
The Consolidation tab found the same cost-allocation module rebuilt in three models.

What changed

List ownership moved to the hub, with drift now caught by the estate instead of by a broken report.
The two failed feeds were repaired the same day; the stale UAT copy was synced.
The quarterly CoE review now opens with the estate map and the risk list.

Which scenario is yours?

Bring one model. We will run AnaDocs AI on it live, and you keep the documentation, the health score and the Polaris report whether or not we speak again.

Request a demo → Sign up free