Performance

1.05-02 Always use a code
Using codes is more efficient for loading and using lists so strive to always have a code for lists. This is especially important for numbered lists Exception: 1.05-02a Static non hierarchy lists: For simple static lists (such as Yes/No) it is OK not to have a code, but even then, Y and N can be used as codes Related to…
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…
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-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-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-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-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-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-03 Flat lists for data export
Use the flat list structures to create modules and views for downstream exports
5.07-02 No Analytical modules
Try and keep Analytical modules out of the 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…
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
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-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.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-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-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-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-04 Only include the fields that are needed
Use the Ignore field if there are any unwanted fields in the source data
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-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:…
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
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
4.03-02 Keep Filters in separate modules
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
3.06-02 Instructions
Use text and instructions where possible, although keep it simple and don't overwhelm the user with verbose language
3.03-04 Split it up
Consider using multiple pages instead of putting all elements on one
2.03-03 Headers
Ensure headers are set to No Data to avoid unnecessary calculations
2.03-02 Try not to use TEXT as a format, or limit it as much as possible
Anaplan (as with computers in general) is optimized for numbers and Booleans. Text formats use more memory than any other format due to the way computers need to store the data. Minimize the use of text if possible. Set to BLANK rather than leave empty or invalid text. Related to Rule: 2.02-04 Text Strings
2.02-20 Don't use RANK formulas with large lists
RANK is a calculation intensive formula that cannot multi thread. Used in conjunction with large lists it can lead to poorly performing calculations. The same applies to RANKCUMULATE Exceptions to this are when the formula also applies to Time.
2.02-18 Break up formulas
The engine works more efficiently when calculations are broken up into separate line items. So, break up formula expressions where possible. This is especially true for calculations that are referenced many times and/or calculations that don't change that often Best Practice articles: Formula Structure for Performance…

Performance

Discussion List