Anaplan Terms

PrevContributor

Hello Anaplanners, I am from the Hyperion/Essbase side of BI and I am diving into Anaplan. If anyone from Essbase background, I have questions on the Anaplan terms. Is List in Anaplan similar to Dimensions in Essbase (for example Entity dimension has members and roll-ups such as NYC, CHICAGO, LA, etc in Essbase. In Anaplan, as the cities can roll up to USA or Entity can we consider Entity as a list.  How do we compare Line item in Anaplan? Is it similar to Account dimension? Kind of confused about module and model. Is model similar to a planning application in hyperion and module similar to DATAFORMS, REPORTS etc related to a specific model? Any analogy would be very helpful. Thanks Nirmal

michel_maurel

Hi,
I have only a poor knowledge of Essbase, migrating an Essbase projetct into Aalan, but here are some asnwers :

List : yes, looks like dimensions. SOmewhat different as far are features are concerned, but the role is about the same.

Line items : not too familiar with accounts in Essbase. Line items are the place in Anaplan where formulas are setup, where links between modules are setup, the place where data in entered by the user. That's the meauserues, the KPI, the metrics. 

In analogic terms, module is the equivalent of a tab / sheet in an Excel Workbook. which has dozens of tabs / sheets.

Essabase in monolythic, One Unique Big Cube, where all the dimensions are crossed, and hundreds of scripts.
Anaplan is multi mocules (or multi cubes in BI terms) and each individual module have the relevant dimensions. for the purpose of the data the module is intened to deal with.

That avoid us to mix the products, customers, banks, balance sheet accounts, vendors, currencies and employee in the same place when we only want to setup the payroll.

My best advice is forget all about Essbase and start from scractch. Essbase was born in 1985 or so in a monolythic world where IT was predominant and planning was rigid for the next 15 years to come.

Anaplan is born in a collaborative world where business and end users are predominant, and where today's models are valid only for a short while, because in 6 months a new need will appear.

Do not try to transpose your Hyperion mind into Anaplan. Try to start from the user's need and from the need of flexibility and constant change. If you setup something too complex and too long to modify, try something easier. Always thing to "what will happen at the end of the year : will this set up still be valid ?"

Your starting point is a good point : lot of usefull stuff in this forum.
 
Kind regards.
Michel.

.
 
.