Comparing complex calculations: Anaplan v TM1 v Cognos Planning v Hyperion v Excel

The Cognos Planning™ Administrator’s Forum recently filed this question – In all the analytics, the math plays an important role. In Cognos Planning we did math on the Dimensions and in TM1™ we do it on the cubes. How can you handle complex math in Anaplan?

A cube or dimension is an artificial construct with no reference to the business process. Thus a lot of redundant and scripted calculations are necessary to represent a business process. Anaplan uses the Line Item (think metrics, measures, drivers etc) as its fundamental calculation construct enabling complex calculations to be built representing the business process in its natural state.

Take a set of related Line Items. For each Line item dimensionality may vary – a useful innovation in itself – and dimensions may be added or deleted to the previously defined structure on the fly. We call this structure a module recognizing that the variable dimensionality prevents it from being a cube. A module contains a set of related LI’s, hierarchies and perhaps time and versions.

Calculations are applied to a Line item using the familiar spreadsheet formula editor with some significant differences. Calculations are defined using natural language and apply to all dimensions for that LI. Like a spreadsheet a large range of functions are offered, but each are potentially far more powerful. Where possible we follow the excel function structures, and optimize accordingly. For example,  the V and H Excel™ Lookups are combined into a single Anaplan Lookup. It applies across multi-dimensional structures and can reference other modules delivering much more capability.

Consider a simple Anaplan Look Up in action. Define a LOOKUP Table with a module name Pay Table, with dimensions Grades (1-4), Regions (A..D) and a single Line Item – Basic Pay:

A different module labelled Example of LOOKUP comprises employee names (dimension) and 3 Line Items – Grade, Region, Salary. Grade and Region are formatted to read from a pick list each defined by the dimensions Grade and Region in the Pay Table.

The formula for salary in module Salary Plan is simple :

Pay Table.Basic Pay[LOOKUP.Grade, LOOKUP.Region].

Anaplan can combine LOOKUP, SELECT and SUM and other functions to express very complex calculations within a single formula. Beside the ‘in-the-moment’ formula editing (no taking the model off-line) – the real value is evident in the BluePrint – all the formula for a module expressed on one page. Return to the module in 3 months and its straight forward to review the logic and edit changes as required, even by somebody who is unfamiliar with the model logic.

Anaplan also offers rich treatment of time, particularly time offsets. Coupled with a built in dimensional structure for versions – Anaplan quickly builds the most complex calculation constructs imaginable. Where the constructs become unwieldy (and some do) our dev team review and introduce new functions to simplify the expression.

Our fastest time to value so far was a small application for a $10B company – 75 users. 8 hours to build the app and ready for deployment. No software, no servers, no IT project queue. They have identified another 40+ apps for deployment. Our largest implementation has just commenced for several 1,000 users.

Its taken 100’s of years of experience to get this far – but Anaplan is the platform offering a  tool of thought to rapidly prototype, build, deploy and edit complex models and applications by business users – NO IT.