Chapter 5

Actions

5.01-01 Naming Convention

Use numeric prefixes to signify the order within the process (e.g. 1.1 Import Products, 1.2 Import Product details).  There is no need to include the technical module name in the description

 

Related to Rule:
5.02-01 Naming Convention

 

Best Practice article:
Naming Convention

5.01-02 User Facing Actions in a process

Import and Export actions need to be republished if modified or replaced, whereas Process Actions are always consistent with whatever is held within the Process, making management easier

Exception:
5.01-02a Numbered list actions: Actions involving numbered lists (Create, Assign, Copy Branch and Delete Branch) cannot be placed in a process

Related to Rule:
4.01-11 Publish Process Actions instead of Import/Export Actions

5.01-03 Keep User actions (in general) to a minimum

Critically review the need for user driven actions, consider the effect on user concurrency. Attempt to use formulas instead.  This may need additional modules, but the user experience could be improved as a result

5.01-04 Delete one off actions

For imports that are one offs, delete the import and data source

Processes

5.02-01 Naming Convention

Use "friendly" names for user facing processes.  For data hubs or administrative processes use numeric prefixes to signify the order of the processes

 

Related to Rule:
5.01-01 Naming Convention

 

Best Practice article:
Naming Convention

5.02-02 Keep actions in a process to a minimum

Each action in a process triggers a recalculation so try and minimize the number of actions

Source Models

5.03-01 Remove unwanted sources

For one off imports, or when source models are no longer required, delete the source model to keep the list tidy

Imports

5.04-01 From source system, create a code defining all attributes

Ideally, this would be a separate file that is unique vs. using the same file for the transactional load

 

Exception:
5.04-01a Code is >60 characters: If the code is >60 characters, you will have to use combination of properties

 

Related to Rule: 
5.04-02 Create separate files for attributes and data

 

Best Practice article:
Data Hubs: Purpose and Peak Performance

 

 

5.04-02 Create separate files for attributes and data

The data file should have the key and values based on the dimensions.  Non dimensional data should be in a different file

 

Related to Rule: 
5.04-01 From source system, create a code defining all attributes

 

Best Practice article:
Data Hubs: Purpose and Peak Performance

5.04-03 Data or Time period should not be part of the unique row

Consider what actually makes the row unique; include only attributes in the key, not data fields or dates

 

Related to Rule: 
1.05-11 Do not embed Numeric values or Dates within the Code of a list

 

Best Practice article:
Data Hubs: Purpose and Peak Performance

5.04-04 Only include the fields that are needed

Use the Ignore field if there are any unwanted fields in the source data

5.04-05 Pre aggregate in the source

Wherever possible, aggregations should be done in the source system.  This is likely to reduce the size of the import file meaning faster imports

5.04-06 Import the correct granularity

Only imported data at the granularity needed.  There is no need to bring in transactional data at a weekly level when Planning happens at the month level

5.04-07 Import using the correct formats

Line items holding the Imported line items should reflect the data. List formatted, numbers, and dates. Don’t use text (unless it is a true text field)

5.04-08 Never use a list as an import source

Import sources should always be done from a module view.  This allows for filtering and only including the elements required for each import

5.04-09 Always use saved views as import sources

Modules and saved views should be used as the source for other imports

 

Best Practice article:
Filter Best Practice

5.04-10 Unify the date format

Use a generic date format (e.g. YYYYMMDD) whenever possible to simplify the imports and remove the need for date mismatches and manipulations

 

Best Practices article:
Untangling Anaplan Time Mapping in Imports

5.04-11 Use zip files for faster imports

Anaplan will accept a zip file format as an import source.  For large files, this will greatly improve the import speed

Exports

5.05-01 Naming Convention

Keep it simple.  Export, Build etc.  There is no need to include the module name in the view name

 

Best Practice article:
Naming Convention

5.05-02 Only include what is needed

Only include the line items that are required for the import. Create multiple views if the module is used for different imports.  The number of columns in the view does affect the speed of the import. The fewer the columns, the faster the import will be

5.05-03 Split views for List and Module imports

Create two views from a source module. One for the import to the list (using name, code and parent), and a view for the attributes to the associated System module

 

Related to Rule: 
5.05-02 Only include what is needed

5.05-04 Ensure view filters are optimized

Only use one filter criteria...If more are needed, combine them into one line item

 

Related to Rule: 
4.02-01 Use efficient filters

 

Best Practices article:
Filter Best Practice

Import Data Sources

5.06-01 Naming Convention

Rename the import sources as soon as possible.  For a saved view include the module name (e.g. module.saved view). For model imports, include a shorted version of the model name (e.g. model_module.saved view)

 

Best Practice article:
Naming Convention

5.06-02 Delete unwanted sources

For one off imports, or when import sources are no longer required, delete the sources to keep the source list tidy

Data Hub

5.07-01 No Hierarchies

There should be no need for composite list hierarchies in the Hub. They can be built to "test" the actions, but after testing they should be deleted

 

Exceptions:
5.07-01a Validation purposes: If data is needed to be consolidated to check against source systems, although the flat modules with attributes can be used to sum data
5.07-01b Combining Source systems: Combining multiple source systems into one feed from the data hub to the spoke model(s)


Best Practice article:
Data Hubs: Purpose and Peak Performance

5.07-02 No Analytical modules

Try and keep Analytical modules out of the Hub

5.07-03 Flat lists for data export

Use the flat list structures to create modules and views for downstream exports

5.07-04 Get the correct format

Get the data from IT in the correct format as well as the correct granularity

 

Related to Rule: 
5.04-06 Import the correct granularity

5.07-05 Use System modules

Use System modules for filtering data (current period, current FY year, etc.)

 

Related to Rule:
2.01-15 Filters in separate modules

 

Best Practice article:
Filter Best Practice
Data Hubs: Purpose and Peak Performance

5.07-06 Master data should be built by the source system

Try and avoid creating Master Data in the hub.  This should really come from the source system(s)

5.07-07 Keep Transactional Analysis out of the planning models

Use the Data hub (or another reporting model) to keep detailed transactional data out of the main planning models. Large amounts of historic transactional data can inflate the size of the planning model and lead to reduced performance.

5.07-08 Pre aggregate for downstream exports

It is more efficient to aggregate the data in the hub and then export it, rather than accumulate it through the import to the downstream models

5.07-09 Avoid using a Top Level for large lists of transaction data

Don't create a transaction list with a top level.  The calculations will need to sum for all items in the list even if only a single item is added

 

Exception:
5.07-09a Check totals: If a check total of all transactions is needed, but again using the flat attributes modules is preferable

 

Related to Rule:
5.07-10 Add intermediate sub totals to transaction lists

 

Best Practice article:
Top Level Item and Parent Hierarchy

5.07-10 Add intermediate sub totals to transaction lists

If you need the totals for validation purposes, create intermediate subtotals within the transaction list.  This will significantly reduce the calculation load

 

Related to Rule:
5.07-09 Avoid using a Top Level for large lists of transaction data

5.07-11 House a Data Hub in a separate Workspace

House the Data Hub in its own workspace.  This allows for the data hub to expand in size without disrupting inbound or outbound integrations.  It also allows for segregation of duties (users who manage the data, are kept separate from the production models)