Chapter 5

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

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

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

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

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

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

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

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

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

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

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

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

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

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)

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

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

Best Practice article:
Filter Best Practice

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

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

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

Best Practice article:
Naming Convention

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

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

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

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

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

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

Try and keep Analytical modules out of the Hub

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

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

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

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

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.

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

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

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

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)