Imagine this scenario: You are working with an existing Anaplan customer who implemented Anaplan a while ago. You notice that the lists, modules, actions, and subsets are disorganized, lack structure, and are difficult to identify. What is the first place you should start?

Solution: Naming conventions! This may be a simple concept at face value however you may be surprised as to how big of an impact deploying naming conventions can have. Naming convention (or lack thereof) can be a big factor as to how well your model is to navigate, troubleshoot, maintain, and administer.

Here are some guiding principles on naming conventions:

  1. Lists - ensure hierarchical lists have a level denoted. Make use of the "Lx" prefix. (i.e. L1 Total Company, L2 Regions, L3 Sub-Regions, L4 Countries). Ensure flat lists are denoted with the term "flat". I.e. Countries flat.
  2. List Subsets- ensure list subsets utilize a prefix to denote their category. i.e. Top Countries SS. Without a prefix on list subsets, it is easy to confuse them with regular lists. This makes organization, troubleshooting, and administrating difficult.
  3. Actions- ensure Actions follow numerical naming convention. i.e. 1.1. Load data into landing module. 1.2. Create L1 Products list, etc. Numbering your actions according to which process you want them to align with can help provide direction as to how you want to organize your Actions menu. i.e. Process 1: Create Hierarchy includes 1.2. Create L1 Total Company, 1.3. Create L2 Regions, 1.4. Create L3 Sub-Regions etc.
  4. Line Item Subsets- ensure line item subsets utilize a prefix, typically "LISS" is used. i.e. "LISS Entries". Note: make sure your team distinguishes the naming convention between Line Item Subsets and List Subsets as these can often times be confused.
  5. Modules- ensure that modules follow the D.I.S.C.O. format.

Below is a breakdown of D.I.S.C.O.

D: Data modules. Here you will store data related to your model. i.e. Volume.

I: Input modules. Here your end users will either enter information that informs your data or enter key assumptions/drivers for your model.

S: System modules. The glue that holds the entire model together. System modules contain metadata about particular dimensions.

C: Calculation modules. Calculation modules are the engine behind the model. This is where you can use the power of dimensionality to create new ways of looking at your data. Here your input, data, and system modules will be referenced to drive multidimensional analysis of your data.

O: Output modules. Output modules are an important part of every Anaplan model. Sometimes, output modules take just as long to create as the actual engine itself. This is where your end users will most likely interact with the data. Here you can slice and dice your data in ways that make it easier for your audience to digest and consume your data.

See the infographic below for a high-level summary on why naming conventions are so important:

No alt text provided for this image