About rob_marshall

rob_marshall · ‎08-24-2020

Try and keep Analytical modules out of the Hub

rob_marshall · ‎08-24-2020

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

rob_marshall · ‎08-24-2020

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

rob_marshall · ‎08-24-2020

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

rob_marshall · ‎08-24-2020

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

rob_marshall · ‎08-24-2020

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

rob_marshall · ‎08-24-2020

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

rob_marshall · ‎08-24-2020

Keep it simple. Export, Build etc. There is no need to include the module name in the view name Best Practice article: Naming Convention

rob_marshall · ‎08-24-2020

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

rob_marshall · ‎08-24-2020

Modules and saved views should be used as the source for other imports Best Practice article: Filter Best Practice

rob_marshall · ‎08-24-2020

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

rob_marshall · ‎08-24-2020

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)

rob_marshall · ‎08-24-2020

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

rob_marshall · ‎08-24-2020

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

rob_marshall · ‎08-24-2020

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

rob_marshall · ‎08-24-2020

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

rob_marshall · ‎08-24-2020

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

rob_marshall · ‎08-24-2020

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

rob_marshall · ‎08-24-2020

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

rob_marshall · ‎08-24-2020

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

rob_marshall · ‎08-24-2020

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

rob_marshall · ‎08-24-2020

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

rob_marshall · ‎08-24-2020

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

rob_marshall · ‎08-24-2020

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

rob_marshall · ‎08-24-2020

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

rob_marshall · ‎08-24-2020

If possible, try and avoid filtering on nested dimensions. Try and pivot the view differently. If this is not possible, ensure the filters are efficient Related to Rule: 4.02-01 Use efficient filters Best Practice article: Filter Best Practice

rob_marshall · ‎08-24-2020

Create filter modules dimensioned by the users list to support dynamic filtering of module data Related to Rule: 1.03-02 Performance and size can be dependent Users list Best Practice article: Increase end user adoption with smart filters

rob_marshall · ‎08-24-2020

If using multiple conditions in a filter, include the conditions in order of list size with numeric conditions last

rob_marshall · ‎08-24-2020

Do not use show/hide function for time; these are static. Using the Time Settings module makes the filtering dynamic when the model calendar changes Related to Rule: 2.01-07 Time Settings Module

rob_marshall · ‎08-24-2020

Try and keep filters in separate System modules. They can then be reused for different modules Relate to Rule: 2.01-15 Filters in separate modules