Planual Explained - Day 11

Misbah

"Rule 2.01-13": Article 2, Chapter 1, and Rule 13 – “Separate Transaction Data from Attribute/Property Data”. Keep the non-time based data in a separate module from static attributes. It goes against NECESSARY element of PLANS if you wish to go against the rule

Here is how it was done in Pre Planual Era: Even after best practices on Data Hub we still used to accept the unique key and load as is from the source system without analyzing the components of the key.  Remember there are 4 Corner Stones and Data is one among the largest piece of the puzzle. Hence spend good amount of time in analyzing the data. Here is the unique key which gets loaded into the system.

 

What is wrong with this method? It looks like a prefect key to be loaded into Anaplan as there are no time periods in the key, there are proper delimiters, no duplicates etc. But if you look at the key closely it might not be the ideal key to be loaded as is into Anaplan as there can be attributes as well which do not change with time. In the below key Segment is an attribute of Customer

 

Here is how it should be done in Planual Way: Understand the source data and the unique key carefully and see if the key contains any attribute which doesn’t change with time and follow the steps

Step 1: Create an attribute module within Anaplan and store the mappings between the two as one time activity

 

Step 2: Load the key without Segment part. Here is the ideal key to load into Anaplan

 

Step 3: Create a SYS module to extract all components of the Key and reference Segment as from Step 1

 

Step 4: In the Data module just reference Segment & Other Attributes from Attribute Module and create a view to be sent to spoke model

 

rob_marshall

@Misbah 

 

Well done, and this coincides with rule 5.04-02 (Create separate files for attributes and data).

 

Rob

einas.ibrahim

Thanks @Misbah 

This post touches very close to home. I joined a project with models that have been implemented over 3-4 years so certainly in the pre-plaunal era. The models used this method of the combined key. The key didn't only include the dates but also included 2-3 of the static attribute and the version (which was very challenging to match actuals and budgets smoothly)

I'll take this a step further and say the static attributes were later used as dimensions.  which absolutely doesn't make sense as they don't change over time or any other dimensions (like region or account) 

It took me a while to convince others that this is not 'a best practice' and it is a major reason why our models' sizes are unnecessarily big.

 

My question is this ...

When you have live models with modules and modules build based on this combined key structure and communicate with other spoke models that have the same structure, how do you "fix" this issue?

 

 

Misbah

@einas.ibrahim 

 

Tough Question. Let me play Safe here - "It Depends"  .

 

To be honest, It calls for a remediation exercise. In fact we recently got one such case where we revamped entire Data Hub and the Spoke models. After the exercise we gave the business new data hub and new planning application - the good part in our case was that the business agreed to stop using the application for a few weeks but that might not be case in every such scenario/situation.

 

I know that doesn't answer your question but I am sure you know what I am talking about.

einas.ibrahim

Absolutely, I know where you are coming from.
I know it's very difficult without a commitment from the business to either pause or be willing to switch to a new and improved model - that would be implemented in parallel. 

I thought I'd raise the question to see what others - who might have faced the same issue- did. 
It is a challenging situation.

Misbah

Thanks @rob_marshall. Yes it does, there are other rules as well which kind of gel well with few other rules.