Hierarchy Management

There are peculiar scenarios like mergers or acquisitions when the Master Data of the company changes. Name and/or Code gets changed in the source system, and we want to update the hierarchy with these new details in Anaplan without creating new entries —which will increase the model size exponentially. We also want to make sure that the data isn't affected due to this exercise. 

The below article will explain how these cases should be handled effectively. Here a simple two-level hierarchy has been taken into consideration, i.e., SKU -> Brands

Current State: This is how our hierarchy looks like in Anaplan as of now.

Future State: This is how it should look like in Anaplan (Due to Changes in Source System) – Both the Name and Codes have been changed in the source system and the same should be reflected in Anaplan.

Step 1: All we need is the mapping between the Old Name & New Name and Old Code & New Code – Sample like below. This information can be put into one file or multiple files. Remember this will be a one-time effort and once the change is implemented we would need only three columns i.e., New Name, New Code & Parent.

Step 2: Replacing the Codes—Create an Import and map “New Code” from the source file to “Code” of the list keeping everything else same. Check “Items uniquely identified by – Name only”. This will  match the Names within Anaplan with the Source file replacing the Codes associated with the corresponding Names.

As we can see in the below screenshot nothing got created instead 6 got updated.

Step 3: Replacing the Names—Perform the same exercise that we did in Step 2 but this time edit the import by mapping “New Name” from source file with “Name” of the List. Check “Items uniquely identified by – Code only”. This will  match the Codes within Anaplan with the Source file replacing the Names associated with the corresponding Codes.

As we can see in the below screenshot nothing got created instead 6 got updated.

Data before Hierarchy Change 

Date after Hierarchy Change  

There can be scenarios when only Codes Change and Names remain the same – in this case, you only need to take Step 2 and in other scenarios where Names Change and Codes remain the same then you only need to take Step 3.

 

 

Now let's extend this use case to the Numbered List with the same two level hierarchy SKU->Brands, SKU being a Numbered list.

 

Current State: This is how our hierarchy looks like now

 

Future State: This is how it should look like 

 

 

Any given Numbered list will have Unique Codes but not the Unique Names. If only the Display Names change then all we have to do is replace the old display names with the new display names and run the import action normally choosing "Code" option in the import mapping. We should be able to replace the Display Names successfully. Trickier part is when the Codes change along with Display Names of a Numbered list. This needs to be tackled very carefully and here is what needs to be done.

 

Step 1: Create a SYS Module dimensioned by SKU# List

 

 

Step 2: Import New/Latest Code from the source system into “New Code” Line item. It’s important to mention here that we are importing based on the mapping of Old Codes

Source File:

Mapping

 

Target Module

 

Step 3: Import the New Code from Saved View of SYS module to the SKU# List mapping on Name (#ID)"

Here is our SKU# list post change. All the codes have been replaced successfully in the target list

 

We should be able to see the latest master data in our SKU hierarchy without impacting the hierarchical structure and without impacting any transactional data associated with it.

 

 

Note: All these hierarchy related changes are to be done within Data Hub. This article just demonstrates the best practices – and to show that there is no data loss or any impact on model size (Which could have been possible had we inserted new items into the hierarchy).