Help with understanding how Anaplan works

KIRAIKAWAII

Hi Everyone,

 

I am able to do the exercises but struggle to understand what is happening conceptually, given I am used to an excel world in finance! For example, with employees, at it's simplest:

 

I would have a tab with all the employee details (name, start date etc), with a unqiue Key - then I would cross reference in calculations in another tab.

In Anaplan, I need to upload an employee data csv but then set up a system module with all the employee details. I also need to put formulas to get the code or parent details from another source.

 

I understand the concepts of modules within models (inputs, calcs, outputs) but as to why you need a seperate systems module vs just using a data source that would have all that data (eg. HR system), I get confused at why we set it up as we do, and in the case of the Model 1 exercises (SYS08 Employee Details lesson 6 and 7), why once I upload the employees data with every detail, I still need a formula to relate to code and dept despite having already matched Code to Name in the Source to Target Input Data screen.

Can someone help me at a basic level understand?

Thanks,

 

Kiraikawaii

 

 

 

JaredDolich

@KIRAIKAWAII 

You've got it. I would just amend your definition slightly.

• Lists hold the hierarchies. You get two primary keys, a Name and a Code. Hierarchies can be structured (like a parent/child) or flat, like Days of the Week.
• System modules are dimensioned using only one list and hold all the properties of that list. So if your list is Employees, you would put all the properties of the employees in the System module

Here's a great demo of DISCO, which stands for different types of modules in Anaplan

• D = Data (holds transactional data)
• I = Input (a module where the user enters helpful information, usually drivers)
• S = System (properties of the list)
• C = Calculation (transformations from one aggregation to another, or from one list to another
• O = Output (reporting views and sometimes this serves as the module where planning occurs)

JaredDolich

@KIRAIKAWAII 

I'll give it a try. 

With Employees, lets say you have two people with the same name and your using XLOOKUP (or VLOOKUP) in Excel. How would you find that employee? Probably, you would look up their Employee ID instead. Anaplan is the same way. There are two fundamental principals you have to keep in mind:

• Calculate once, refer often. Because Anaplan is a cloud solution and all the calculations are done in memory, you have to be efficient with the modeling. That's why we create system modules. These are modules that hold the properties of the list. So, for example, the salary of an Employee, or the employee's first name. You will calculate anything you need to about the Employee in the System module. All other modules that need an employee property will "lookup" that property from the System module because it's already calculated there.
• Think Front to Back. Decide what the process is that you want to enable. Then work your way backwards. Each module should satisfy a specific use case. It's okay to create a lot of modules to enable a process. Just make sure each module is dimensioned correctly and flows in the direction that will satisfy the requirements.

Hope it helps. With a little practice, you'll be an Anaplan pro just like you are with Excel. 

KIRAIKAWAII

Thanks @JA , appreciate the quick reply (on a Sunday no less!)

 

Just to confirm (and this is a very broad assumption given my level!) - the lists we create are purely for data and for hierachies etc; and the systems modules will reference any number of lists to house all the details, and necessary calcs derived from these details, for all the other modules to use to make it memory efficient?

 

So in my basic mind, I can see System Modules as a massive data refernce library with calcs, much like I would have in an excel tab - the lists have data, and can be used to easily update by both admins and users (dependant on company policy), which System Modules will reflect, which then flow to the rest of the model.

Thanks,

 

Kiraikawaii

KIRAIKAWAII

Wonderfully explained @JaredDolich, thank you!

Kiraikawaii