“The model has gotten slow” is the most common reason we get called into an existing Anaplan estate. The assumption behind the call is usually the same: the model has grown too big, and the fix will be painful. In our experience, size is rarely the real problem. The real problem is structure - and structure can be repaired without a rebuild.
1. Sparsity is a design outcome, not a fact of life
Anaplan allocates cell space for every combination of the dimensions applied to a line item, whether or not the combination is meaningful. A line item dimensioned by SKU × customer × week, where most customers buy a fraction of the range, can easily be more than 95% empty cells - paid for in workspace and calculated through on every change.
The fix is almost never “fewer dimensions”; it is more deliberate ones. Numbered lists keyed to the combinations that actually exist, subsidiary views to strip dimensions from line items that don’t need them, and a clear separation between sparse transactional modules and dense reporting modules. We have cut workspace consumption by half on production models without removing a single feature.
2. Line-item bloat hides in “temporary” logic
Every mature model carries archaeological layers: staging line items kept “just in case”, intermediate calculations no dashboard reads anymore, daily-grain detail that only ever feeds a monthly view. Each of them recalculates on every relevant change.
A disciplined audit - which line items have no referents, which views are never opened, which exports are no longer scheduled - typically retires 15–25% of the calculation graph. Anaplan’s own model-map and the module usage data are enough; the work is methodical rather than clever.
3. Calculation order and formula shape matter more than formula count
The engine is very good at parallelising independent calculations and very bad at being asked to do everything in one line item. Long chained formulas with embedded conditionals defeat the optimiser; so do early aggregations that force dense intermediate results. Splitting heavy formulas into staged line items - counter-intuitively - often makes models faster, because each stage parallelises and caches cleanly. The same applies to dimension order within a module: aligning it with the way data is loaded and read avoids constant pivoting work.
4. ALM hygiene is a performance feature
Models that have lived through years of direct-in-production changes accumulate structural debt: orphaned lists, divergent dev/prod structures, history that bloats the model file. Treating ALM seriously - a real dev model, structural changes flowing one way, periodic history clearing - keeps the model file lean and deployments predictable. It is also the precondition for any of the fixes above being safe to apply.
Where to start
- Measure before touching anything: workspace by module, calculation times on representative actions, sparsity of the ten largest modules.
- Retire dead logic first - it is free performance with zero functional risk.
- Then address the two or three sparsest large modules with targeted re-dimensioning.
- Leave formula restructuring for last; it has the highest skill requirement and the highest regression risk.
A focused performance engagement of this shape usually runs three to five weeks on a production model. The outcome is not just speed: a model that is cheaper to run is also cheaper to change, and that is where the compounding value sits.
