NOTE: The following information is also attached as a PDF for downloading and using off-line.
The process of designing a model will help you:
Understand the customer’s problem more completely
Bring to light any incorrect assumptions you may have made, allowing for correction before building begins
Provide the big picture view for building (If you were working on an assembly line building fenders, wouldn’t it be helpful to see what the entire car looked like?)
Understand the requirements and the customer’s technical ecosystem when designing a model
When you begin a project, you gather information and requirements using a number of tools. These include:
Statement of Work (SOW)
Definition of the project scope and project objectives/high level requirements
Goal of the project – big picture view of what needs to be accomplished
Which systems will provide data to the model and which systems will receive data from the model? What is the Anaplan piece of the ecosystem?
Current business process
Remember that if the current process isn’t working, it needs to be fixed before design can start.
What key pieces of business logic will be included in the model?
Is a distributed model needed
High user concurrency
Security where the need is a separate model
Regional differences that are better handled by a separate model
Is the organization using ALM, requiring split or similar models to effectively manage development, testing, deployment and maintenance of applications?
This functionality requires a premium subscription or above.
These have been written by the client – more specifically, by the subject matter experts who will be using the model.
Why do this step?
To solve a problem, you must completely understand the current situation. Performing this step provides this information and the first steps toward the solution.
Results of this step:
Understand the goal of the project
Know the organizational structure and reporting relationships (hierarchies)
Know where data is coming from and have an idea of how much data clean-up might be needed
If any of the data is organized into categories (for example, product families) or what data relationships exist that need to be carried through to the model (for example, salespeople only sell certain products)
What lists currently exist and where are they are housed
Know which systems the model will either import from or export to
Know what security measures are expected
Know what time and version settings are needed
Document the user experience
Front to back design has been identified as the preferred method for model design. This approach puts the focus on the end-user experience. We want that experience to align with the process, so users can easily adapt to the model. During this step, focus on:
User Roles – who are the users?
Identify the business process that will be done in Anaplan.
Review and document the process for each role.
Focus on the main steps. If available, utilize user stories to map the process. You can document this in your any way that works for you. Here is a step-by-step process you can try:
What are the start and end points of the process?
What is the result or output of the process?
What does each role need to see/do in the process
What are the process inputs and where do they come from?
What are the activities the user needs to engage in? Verb/object – approve request, enter sales amount, etc. Do not organize during this step. Use post-its to capture them.
Take the activities from step 4 and put them in the correct sequence.
Are there different roles for any of these activities? If no, continue with step 8. If yes, assign a role to each activity.
Transcribe process using PPT or Lucid charts. If there are multiple roles, use swim lanes to identify the roles.
Check with SMEs to ensure accuracy.
Once the user process has been mapped out, do a high level design of the dashboards
Include: Information needed,
What data does the user need to see?
What the user is expected to do, or decisions that the user makes
Share the dashboards with the SMEs – does the process flow align?
Why do this step?
This is probably the most important step in the model design process. Maybe it seems as though it is too early to think about the user experience, but ultimately, the information or data that the user needs to make a good business decision is what drives the entire structure of the model.
On some projects, you may be working with a project manager or a business consultant to flesh out the business process for the user. You may have user stories, or it may be that you are working on design a bit earlier in the process and the user stories haven’t been written. In any case, identify the user roles, the business process that will be completed in Anaplan, and create a high level design of the dashboards. Verify those dashboards with the users to ensure that you have the correct starting point for the next step.
Results of this step:
List of user roles
Process steps for each user role
High level dashboard design for each user role
Use the designed dashboards to determine what output modules are necessary
Here are some questions to help you think through the definition of your output modules:
What information (and in what format) does the user need to make a decision?
If the dashboard is for reporting purposes, what information is required?
If the module is to be used to add data, what data will be added and how will it be used?
Are there modules that will serve to move data to another system? What data and in what format is necessary?
Why do this step?
These are the modules that are needed to support the dashboards or export to another system. This is what should guide your design – all of the inputs and drivers added to the design are added with the purpose of providing these output modules with the information needed for the dashboards or export.
Results of this step:
List of outputs and desired format needed for each dashboard
Determine what modules are needed to transform inputs to the data needed for outputs
Typically, the data at the input stage requires some transformation. This is where business rules, logic, and/or formulas come into play:
Some modules will be used to translate data from the data hub.
Data is imported into the data hub without properties and modules are used to import the properties. Reconciliation of items takes place before importing the data into the spoke model.
These are driver modules that include business logic, rules.
Why do this step?
Your model must translate data from the input to what is needed for the output
Results of this step:
Business rules/calculations needed
Create a model schema
You can whiteboard your schema, but at some point in your design process, your schema must be captured in an electronic format. It is one of the required pieces of documentation for the project and is also used during the Model Design Check-in, where a peer checks over your model and provides feedback.
Identify the input, outputs and drivers for each functional area
Identify the lists used in each functional area
Show the data flow between the functional areas
Identify time and versions where appropriate
Why do this step?
It is required as part of The Anaplan Way process. You will build your model design skills by participating in a Model Design Check-in, which allows you to talk through the tougher parts of design with a peer.
But more importantly, designing your model using a schema means that you must think through all of the information you have about the current situation, how it all ties together and how you will get to that experience that meets the exact needs of the end-user without fuss or bother.
Result of this step:
Model schema that provides the big picture view of the solution. It should include imports from other systems or flat files, the modules or functional areas that are needed to take the data from current state to what is needed to support the dashboards that were identified in Step 2. Time and versions should be noted where required. Include the lists that will be used in the functional areas/modules.
Your schema will be used to communicate your design to the customer, model builders, and others. While you do not need to include calculations and business logic in the schema, it is important that you understand the state of the data going into a module, the changes or calculations that are performed in the module and the state of the data leaving the module, so that you can effectively explain the schema to others.
For more information, check out 351 Schemas. This 10 to 15 minute course provides basic information about creating a model schema.
Verify that the schema aligns with basic design principles
When your schema is complete, give it a final check to ensure:
It has been kept simple.
“Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage to move in the opposite direction.” ― Ernst F. Schumacher
“Design should be easy in the sense that every step should be obviously and clearly identifiable. Simplify elements to make change simple so you can manage the technical risk.” --Kent Beck
The model aligns with the manifesto.
The business process has been defined and works well within the model.
In most use cases, a single model provides the solution you are seeking, but there are times it makes sense to separate, or distribute, models rather than have them in a single instance. The following articles provide insight that can help you, during the design process, to determine if a distributed model is needed.
What is Application Lifecycle Management (ALM)?
What types of distributed models are there?
When should I consider a distrbuted model?
How do changes to the primary model impact distributed models?
What should do after building a distributed model?
It is important to understand what Application Lifecycle Management, or ALM, enables clients to do within Anaplan.
In short, ALM enables clients to effectively manage the development, testing, deployment, and ongoing maintenance of applications in Anaplan. With ALM, changes can be introduced without disrupting business operations by securely and efficiently managing and updating your applications with governance across different environments, and quickly deploying changes to run more “what-if” scenarios in your planning cycles as you test and release development changes into production.
Learn more here: Understanding model synchronization in Anaplan ALM
Training on ALM is also available in the Education section 313 Application Lifecycle Management (ALM)
There are two different types of distributed models that should be considered as early as possible when a client chooses to implement Anaplan:
A Split Model is where one model, known as the Primary Model, is partitioned into multiple Satellite Models that contain the exact same structure, or metadata, such as versions and dimensions, as the Primary Model. The Split Models will be 90% identical to the Primary Model and will have about a 10% difference. The Split Model method is most commonly used when multiple regions are involved in a client’s workspace.
For example, the Primary Model may contain 3 different product lines. Region 1 sells product lines A and B, while Region 2 sells only product C. In this case, a Split model may be used to provide consistency in structure across the models, but variation with the product lines as not all product lists are applicable to each region.
ALM Application: Split Models
For Split Models, ALM allows clients to maintain the Primary Model, as well as all Satellite Models in their workspace using one development model. Clients may make changes to their development model, and then deploy updates to their live models without disrupting the application cycle.
Similar Models are models that vary slightly in structure or metadata. The degree of difference is usually less than 5%. If it gets to be greater than this, or there’s a greater difference in user experiences, it may be impractical to use similar models. For example, the Similar Models method is used when multiple regions are involved that must view the same data, ideally from a Master Data Hub.
ALM Application: Similar Models
For Similar Models, ALM requires clients to maintain one development model for each similar Model being used. Comparable to Split Models, each development model may be edited, tested, and then deployed to the production model without disrupting the application cycle.
In many situations, enterprises need to split very large and complex models for various reasons including:
Performance issues, including data volume and user concurrency
Metadata time cycle differences
Regional / Business process differences
Anaplan is a platform designed to enable businesses to build models in almost endless configurations, so there is no pre-set size recommended where a model can be distributed. It is not uncommon to have a 15 billion cell model that is performing complex calculations, but is only used by a single person, or just a few people, to remain as a single model. However, in contrast to that, it is also not uncommon to have a distributed model as small as 1 billion cells, with complex calculations and multiple people in multiple locations using the model.
As a general guide, this table takes into consideration the factors that influence a single model or distributed model solution.
Large Data Volumes, (> 10GB)*
High User Concurrency*
Sample Model 1
Sample Model 2
Sample Model 3
Depends on actual volume
Sample Model 4
Sample Model 5
Depends on actual volume
Sample Model 6
Depends on user concurrency
Sample Model 7
Depends on actual volume
* As always, appropriate testing and tuning needs to occur to optimize the model. Different combinations can have a dramatic effect on desired performance and experience.
Anaplan has robust security across its platform. In some cases, it’s possible to achieve region-specific experiences using selective access. If this is the case, then distributed models are not necessary. But in mixed environments where model builders and end users operate in the same model, and where various business processes exist, at times it makes sense to separate or distribute models rather than have them in a single instance. For example, you may have different countries that all need access to a workforce planning application. You also have model builders from each country modeling and maintaining their section. By distributing the models and restricting access, this problem is abated.
Where there is a need to segregate administration (model builder) roles, the split models will need to be in different workspaces, as the admin role is by workspace, not by model.
Metadata Time Cycle Differences
A single instance of a model, serving the world across multiple time zones, does not respect the different business cycles involved, and therefore, updates to data and/or metadata of a model will affect the entire community, some of who may be in the middle of their planning cycle. These changes may be small, but in many instances are large scale and frequent changes, which require pauses in the application cycle for end users.
However, a configuration that does respect business cycles and time zones, and distributes the model, can be beneficial to the business as business regions that are in down-time, (i.e. in the middle of their night, where usage is very low), can, independently, carry out updates to data and metadata without affecting other regions.
ALM Application: Metadata Time Cycle Differences
Alternatively, ALM prevents pauses in the application cycle altogether by providing a development environment for each model. Edits may be made to development models at any time without disrupting live production models for end users. Then, once edits have been completed on the development model, they may be deployed to live production models without any disruptions or down-time for end users. As a result, using ALM removes any risk for pauses in the application cycle for any user at any time.
Regional / Business Process Differences
Similar to the workforce planning example above, regional differences may exist. It may not be practical to attempt to include all regional variances that exist across countries for workforce planning in a single instance. Much of the functionality would not be relevant to every region, and so confusion and frustration would occur, as well as complication of user interface. In this instance, a distributed model would be the best solution.
Another consideration is that of differing business processes. That is to say, both processes are intrinsically the same, but different enough to warrant separate treatment and business processes that are completely different.
An example of this may be a process where a business updates a forecast. Perhaps they get to the same point in a revenue forecast, but how different parts, or divisions, of a business get to that point, is different. One may do an initial bottoms-up forecast, submit up to management for draft approval and then do a final submit. Another may do a top-down approach where a target is set and that target needs to be validated. These are connected, yet separate, processes that may warrant separate instances of an application.
ALM Application: Regional / Business Process Differences
If regional and business processes are similar between satellite models, and the metadata between them can be synched from a single development (primary) model, then ALM can be used to develop, test, and produce the single development model that feeds the satellite models. If the regional and/or business processes cannot conform to use the same metadata from a single development model, then multiple development models must be used. In this case, ALM would be used to update, test, and produce each development model, which would then feed into each respective satellite model.
When changes occur to the primary model, that need to be copied to the other models, careful coordination of this should be applied. There are several time-saving techniques that can make model changes across distributed models simple and quick. This of course depends on the complexity of the change, but generally, changes are merely to fix an issue, or add very small things such as views or reports.
Some of the model change techniques are:
Module update via export/import
Primary module is updated
Export of module blueprint to .csv format
Import of new line items into receiving module blueprint
Import of new formulas/dimensionality into receiving module
Model Blueprint Update
Model blueprints can also be updated on a batch basis where required
Simple Copy & Paste. Anaplan supports full copy and paste from other applications where minor changes to model structure are needed
New lists or dimensions can be exported to a csv file from one model to another, or a direct API model-to-model import can be carried out to add new lists to multiple models.
Changes to data or metadata are handled in a different way. Item changes within existing lists or hierarchies are handled via an import, which may take place in a specific model or models, or ideally within a Master Data Hub.
It is a best practice to use an Anaplan model as a Master Data Hub, which will store the common lists and hierarchies, and will be the unique point of maintenance. Model builders will then implement automated data imports from the Master Data Hub to every single model, including Primary Models and Satellite Models (See: Master Data Hubs document).
Careful consideration of the business processes and rules that surround changes to the primary model, and then the coordination of the satellite models should be put in place, as well as clear governance.
ALM Application: When Changes Occur
It is highly recommended for clients to utilize ALM if metadata changes, such as any dimension, may be required at any time during implementation or even after the deployment phase of Anaplan. ALM allows clients to add or remove metadata from models, as well as test their effects, in a safe environment without running the risk of losing data or altering functionality in a live production model.
Once a model is built, testing of the user concurrency and data load levels occurs, and then optimizing the system for the specific use case and conditions is carried out. Then, we have three main options in order to tune for optimum performance. These are the main optimization options:
1. Model design
Is the model designed correctly?
Have you reduced sparsity and unnecessary complexity?
Is the model too big?
Have you neatly designed the model to have input, engine and output modules?
Have you cleaned up as you go?
Quite often, problems exist when you have added to the model, tested something that did not work out, and then not removed what you tested and didn’t work. This piece is not fulfilling any requirements. Sometimes we refer to this as model debt. Remember, Anaplan is a living, breathing model and so any line items that exist in the model, whether used or not, are used by the engine. A surplus piece (model debt) is an inefficient use of model space.
2. Model calculations
Check that calculations are as efficient as possible. Are you using standard functions to be more efficient?
3. Platform code
Do we need to engage L3 and/or engineering to look at code optimization?
Performance Issues Including Data Volume & User Concurrency
Performance and the experience the end user has is of critical importance when deploying applications to a wide audience. Therefore, several factors need to be considered when deploying, in order to optimize performance and determine whether a single instance or distributed instance strategy is best:
In order for end users to enjoy the best possible experience, and have an average response less than two seconds to most popular requests, model size and concurrency must be managed appropriately. In many cases a base model is produced that contains all the dimensionality and calculation logic and then the model is subjected to a series of tests that determine what the end user experience and model performance will be.
The first test is a load test where data is loaded into the model to simulate what the production model volumes would actually be. During this test, basic functions are performed such as data input, allocations, filtering, pivoting, sorting, list formatted item drop down manipulation etc. This is done both in an automated fashion and via human intervention. If it is determined that some or many functions are slow and server memory and CPU are used to the maximum, this is likely a case for distribution. If however, the model is slow, but user concurrency is minimal, then this could form a case for a single model instance as the system is merely processing numbers and not being accessed by a user community. Otherwise, this model could also be split to provide a better user experience.
The size of a model measured in # of cells or in memory size is a good indicator for splitting a model. We are setting the expectation that a model size should not go beyond 15B cells or 120 GB of memory. So if an application requires 30B cells, it should be split in 2 models. Here’s an example on how a split model decision can be made:
First, estimate the size of the application: List the main dimensions that will be used in each application and define the expected number of cells for each the valid combinations of dimensions (these will be modules).
# of cells for the group
Customer: 80 (incl. hierarchy rollups)
Product: 1500(incl. rollups)
Time: 36 months, 12 Q, 3 Year, 3 YTD
Version: 2 (Actual, Budget)
Line items: 50 metrics
Time (should be same for each group)
Versions (should be same for each group)
Total Application 1
Then summarize how many models will be needed for each application.
Estimated size in cells
Estimated size in GB
# required models
The second test is user concurrency. If you have an application that requires a large user base to interact with it, a user concurrency test should be performed. As a general rule, user concurrency is approximately 10% of the total user community. Therefore, if you have a total user base of 1000, around 100 people will be on the live system, performing tasks, at any given time. It is usually unlikely that many more than that number would be accessing the system at the same time.
In some cases though, applications follow a set high concurrency pattern and this needs to be taken into account. For example, a weekly sales forecast may have 1000 users on the system, but very likely, each Sunday, (if forecasts are due Monday), the user concurrency will be quite high, maybe as high as 50% - 60%. Your processes and experience will determine exact concurrency in high traffic applications or periods. The best approach to get to the right number of users in a model is to test the concurrency with automated tests, and then with manual tests that include a large number of real users.
First, start with User Acceptance Testing, or UAT. In short, UAT involves human users simultaneously performing scripted tests inside the platform. During these tests, system behavior will be monitored and reported by each of the human testers, which may be provided via a user survey that is launched post UAT.
Then, automated testing can be performed in the platform. Automated testing simulates user actions across the platform. To do this, coordinate with the Anaplan QA Team to schedule automated testing of load, performance, and concurrency.
It is also important that the server be monitored while the automated testing is in place to monitor memory and CPU usage. The Anaplan QA team can obtain server monitoring metrics as part of the model performance testing process. In either case, application tuning needs to happen to optimize for all conditions needed.
Multi-Model Application Optimization
The Application Tuning Lifecycle includes a 2-step, iterative tuning process that reoccurs during the model building process. In the first step, the complete build is carried out. Step 2 is tuning at the application level, (i.e. optimizing the design and the calculations or business rules), by Anaplan’s L3 Support team and the Solution Architect. Additional platform level or code optimizations may also be made with the assistance of Anaplan’s engineering department on rare occasions.
This is step four of the model design process.
Next, your focus shifts to the inputs available. Remember that sometimes a dashboard is used to add information.
Using the information gathered in steps 1 through 3:
Identify the systems that will supply the data
Identify the lists and hierarchies, especially the hierarchies needed to parse out information for the needed dashboards/exports
What data hub types are needed?
Why do this step?
During this step, you should be thinking about the data needed to get to your defined output modules. All of the data in the system or in lists may not be needed. In addition, some hierarchies needed for the output modules may not exist and may need to be created.
Results of this step:
Lists needed in the model
Hierarchies needed in the model
Data and where it is coming from
Importing and exporting data in and out of Anaplan area fairly simple processes, however they can significantly affect the platform’s performance, as well as the business consistency.
These articles take a closer look at this topic.
How do exports impact platform performance?
How do exports impact business consistency?
How do I troubleshoot issues related to exports?
How do I create an export model?
Platform performance is affected each time a user runs an import or an export, as he or she will block all other users of the model from performing any tasks while the import or export runs. This creates what is called a toaster message: basically a blue box at the top of the Anaplan screen that indicates to every connected user that the platform is processing an action.
Any person who frequently exports out of Anaplan will likely become very unpopular among the users of the model, especially if exports last more than a few seconds. Users who are not workspace administrators can:
Export data out of a module within a dashboard
Run an import prepared by an administrator
Run a process that an administrator has prepared.
The process can combine a number of imports and exports
When users run exports there can be misalignment of data that causes issues in the business process. If users export out of a dashboard, it's most often for custom reporting purposes. During this, the user filters, sorts, create sums via a pivot table, uses lookup for attributes, and displays additional data. All of these are certainly needed for reporting.
Worst case scenario, the user will create additional KPIs or ratios that he could not find in the Anaplan model. Next, this user will copy all of this data into a PowerPoint deck, make additional formatting changes, add comments to the numbers or variances, and present this deck to his meeting attendees.
This user has spent a few days to do the tasks described above, and within these few days the model has changed: Data might have changed, structures might have changed, some calculations might have changed, new calculations are now available, and maybe even user access has changed. Now, this user’s deck is misaligned; they are presenting data, analysis, and conclusions that can be irrelevant or that conflict with another presenter of the same meeting who exported from the platform in a different timeframe.
At this point, the executive sponsor may ask why they invested in a great platform like Anaplan, if the organization is still having the same issues as before where shadow processes are frequently occurring. Not to mention that the additional accurate and insightful comments included in the deck are now disconnected from the rest of the data, and will remain buried in people's email, instead of being available to all. Then, the next week, or next month, the meeting happens again, and all the work of extract, reformat, recalculate, copy/paste, and comments needs to be done again.
So, how can we help customers with this issue? Whenever possible, ask end-users “Why do you need these exports?” and “What do you need to do with the exported files?”
You will likely get answers such as:
Create my own filters and sorts, search a specific data, compare things
Reformat and present
Reformatting data for presentation purposes
Always export the same data and put it in an Excel or PowerPoint file for distribution
Export to other systems
Put the Anaplan data in a different system (write back to operational tool, push to a reporting platform)
Do additional “what if” scenarios, such as editing the hierarchies and comparing the results, because they don't know how to do this in Anaplan, and it seems easier and faster
Urgent specific analysis
Specific analysis are suddenly required, but are not yet available in the Anaplan dashboards, or the user does not know how to build this in Anaplan
Printing large quantities of reports and data from Anaplan
Report with high impact on model size
The following table lists recommendations for each issue above to be considered in your model design in an effort to deliver a high performing and collaborative model:
1. Ad-hoc analysis
Build dashboard features, such as model-user-based filtering, which covers most of the filtering requirements, using item’s attributes.
Train end-users how to use the native filter, search, and sort functions. It'll require change management as users will see a usability gap with Excel, for example. Focus on what each Anaplan filter can do that Excel filters cannot do (and/or, multi-dimensional filtering).
Build decluttered dashboards that display relevant information:
Only display items that make 80% of the number (use rankcumulate function)
Only display items below/above a specific threshold
Make the threshold value by user - use a user dimension
Allow sorting rows alphanumerically
Have a line item with the item name, so that sorting by alphanumeric is possible, or set by default
When grids show items created on the fly, find a way to always display newly created items on top
If manual line item selection is tedious due to the use of the manual show/hide on 50+ line items, use a modeling solution based on line item subsets that provides a check box-based line item selector.
2. Reformat and present
Utilize the PowerPoint add-in. Build module views in your model to select what data you need to present. Then, create these views in PowerPoint via the add-in and edit the formatting once for all (leverage the 3 key features: table, text, and charts).
Start with building a quick Proof of Concept to show your customer how that works and what the benefits are. Format the PowerPoint using the customer’s colors and branding. Show how the data refresh is automated, and the same deck can be used week over week, month over months without having to re-export.
3. Recurrent reporting
Analyze the reporting requirement, envision building an equivalent dashboard, and perform a gap analysis on what's being required and what the dashboard can offer.
Work on change management and training to migrate users to use the online dashboard. Emphasize the dynamic functionality of dashboards in Anaplan that differentiates from a static export: Row sync / chart sync / cell sync / level selection / Master-detail
If licensing is an issue, then setup a meeting to review the 2.0 pricing model and compare the cost of extra Anaplan licenses versus the cost of the manual export/reformat/distribute. Emphasize the security risk of email distribution of Excel, PowerPoint, and/or PDF files. Customers should be reminded that every user who receives an Excel, PowerPoint, or PDF file will have access to the same data set, even though selective access has been implemented in Anaplan, which may be a significant security risk.
4. Export to other system
This is a very good reason for exporting. Although, if the target system is a BI system, always check if that report could not be living in Anaplan instead. The reasons to report outside of Anaplan are license, and use of data that are not meant to be in the Anaplan model.
If you export to other systems, consider exporting either out of the Master Data Hub, or have a dedicated export model that has the same data as the main model. Also, implement the incremental export to only export data that has changed since the last export.
Usually, only administrators should export to other systems, which should be done outside of normal business hours, if possible. If end-users are exporting, we recommend setting up a filtered view that is focused on what they want to export. This will avoid exporting a large data set that may take longer than necessary to process.
Control the format of the number that gets exported: Use the Round() function to control the number of digits.
We can see customers doing hierarchy simulations in Excel by simply regrouping, splitting, renaming nodes, recalculating all rollups and comparing results.
It's possible that the customer does not feel that he/she is skilled enough to build a hierarchy simulation in the Anaplan platform. As a result, very few projects have implemented hierarchy versioning within Anaplan, though it is actually possible using standard modeling functionality.
6. Urgent specific analysis
When end-users do not yet have the ability to build their own dashboards or analysis, they will ask for export functionality out of dashboards in order to be able to create these analysis without depending on the modeling team to build these for them. This is a good reason to enable these users to export, which should only be allowed to specific end-users.
Since show/hide the export action is by dashboard, and not by role, you'll need to duplicate the dashboard: One for standard end-users who will not need to export and build their own analysis, and one for advanced users who will.
In that case, always ask the user who creates these analysis out of an export file to share with you (or the project team) the report that he/she has built, and add this dashboard to the product backlog with a high priority. Your goal will be to eliminate all dashboards or reports built outside of the Anaplan platform.
7. Batch Printing
The customer might need to distribute printouts of the plans to the user community in preparation of a large planning summit where each user will need to come briefed and prepared for discussion around the plan.
The Anaplan platform does not provide an easy way to generate reports in a batch mode, so it's best to leverage a third party BI platform for such activity. In that case, have an administrator run a set of exports, that include required planning data, into a flat file that the BI platform can import, format, and distribute.
8. Report with high impact on model size
If a report requires dimensionality that was not planned to be added to the model, and could significantly increase the size of the model, then allowing export and Excel reporting using a pivot table may be the best solution. That can be the case if end users need to export a flat transactional data set, and re-create the sums on some of the columns available in the flat transaction module.
This can require the creation of a large, multi-dimensional module, depending on the size of the dimensions the end users need to combine. Creating this module may not be possible due to size limitations, or for user access reasons, as non-administrators do not have the ability to create a module.
In that case, we'll allow exporting to a .csv file and let users run the export/sums in either Excel or another system. Be aware that performance of an exported report in Excel that contains millions of cells can be poor, which in-turn can frustrate the user experience.
Always envision building the equivalent analysis in Anaplan, if possible, in either the main model or in another model specific to reporting.
Allowing model users to export data out of an Anaplan model on a large scale mode (e.g. many end-user run exports) is not a good practice. One approach is to create an "export model" in Anaplan that is specifically for exporting purposes.
This export model will have the same data set and selective access definitions as in the main model, but will not have any of the data entry or reporting dashboards. In comparison, it will only have dashboards with buttons that run specific exports. To ensure a good user experience, provide a hyperlink to the export model from a dashboard in the main model. For example, users start from their usual, main model, see a link named "Exports", and when clicked, are redirected to the export model where they see a set of predefined buttons that run exports.
It is important to explain to the customer and model users that:
Exports are executed sequentially (first in, first served): users have to wait until previously executed exports are finished before they can run their own export.
There will be data latency as the export model will be synced likely once or twice a day from the main model. The export from the main model to the export model is a blocking operation and must ideally be run at times that are least likely to not disrupt operations. Users will need to understand the schedule and plan their exports accordingly.
Functional Areas should be sorted by grouping dashboards and modules separately. Doing this allows for quick access to dashboards, as well as improved control over user access assignments of these areas.
Use the Reorder button to sort the Functional Areas. Select the rows that should be moved, and then click the Reorder button to choose where to move them to.
The Contents Panel provides end users with links to dashboards and modules that are accessible by their user role. Workspace administrators should remove all unnecessary dashboards and modules for each role to keep the navigation options succinct. Always keep the Contents Panel in line with the business process and the user role.
User Roles should be created for each business function. Once created, Selective Access should then be applied to all lists, which helps to control the access that each end user needs. Avoid creating different Roles, with varying access rights, for the same type of end user. This can cause additional model maintenance that can often be avoided.
Sort Roles in a sensible fashion using the Reorder button. E.g. Most privileges, some privileges, least privileges.
Consider using a module to control user access. This will allow model builders to provide clear instructions on the roles and access rights in the model, along with the ability to change user access rights from a convenient dashboard. Additionally, an import can be created and ran as part of a process to import user access from this module. Note, only model builders will have access to import data into the user list.
More information on User Roles and Selective Access can be found in Learning Center under Advanced Topics.
When user roles are given access to lists (for edit), memory is pre-allocated for those users to increase model size: Give User Role access only to the lists that they will possibly update through actions.
A large and complex model such as 10B cells can take 10 minutes to load the first time it's in use after a period of inactivity of 30mn.
The only way to reduce the load time, besides reducing the model size, is by identifying what formula takes most of the time. This requires the Anaplan L3 support, but you can reduce the time yourself by applying the formula best practices listed above.
One other possible leverage is on list setup: Text properties on a list can increase the load times and subsets on lists can disproportionately increase load times by up to 10 times. See if you can impact the model load on reviewing these 2 and use module line item instead.
A model will save when the amount of changes made by end-users exceeds a certain threshold. This action can take several minutes and will be a blocking operation. Administrator have no leverage on model save besides formula optimization and model size reducing. In very specific conditions depending on the Customer contract with Anaplan, and under a validation process with our technical Operations team, the Model Save action can be tuned with the help of L3 support where the frequency and processing time can be adjusted together: less frequent but takes longer, or more frequent and take less.
A model will roll back in some cases of invalid formula, or when a model builder attempts to create a process, an import a view which name already exists. In some large implementation cases, on a complex model made of 8B+ cells, the rollback takes approximately the time to open the model, and up to 10 minutes worth of accumulated changes, followed by a model save.
The recommendation is to use ALM and have a DEV model which size does not exceed 500M cells, with production list limited to a few dozen items, and have TEST and PROD model with the full size and large lists. Since no formula editing will happen in TEST or PROD, the model will never rollback after a user action. It can roll back on the DEV model, but will take a few seconds only if the model is small.
Details of known issues
PERFORMANCE ISSUES WITH LONG NESTED FORMULA
Need to have a long formula on time as a result of nested intermediate calculations.
If model size does not prevent from adding extra line items, it's a better practice to create multiple intermediate line items and reduce the size of the formula, as opposed to nesting all intermediate calcs into one gigantic formula.
This applies to summary formulae (SUM, LOOKUP, SELECT).
Combining SUM and LOOKUP in the same line item formula can cause performance issues in some cases. If you have noticed a drop in performance after adding a combined SUM and LOOKUP to a single line item, then split it into two line items.
RANKCUMULATE CAUSES SLOWNESS
A current issue with the RANKCUMULATE formula can mean that the time to open the model incl. rollback, times can be up to 5 times slower than they should be.
There is currently no suitable workaround, our recommendations are to stay within the constraints defined in Anapedia.
SUM/LOOKUP WITH LARGE CELL COUNT
Separate formulas into different line items to reduce calculation time (fewer cells need to recalculate parts of a formula that would only affect a subset of the data)
A known issue with SUM/LOOKUP combinations within a formula can lead to slow model open and calculation times, particularly if the line item has a large cell count.
All line items do not apply to time or versions.
Y = X[SUM: R, LOOKUP: R]
Y Applies to [A,B]
X Applies to [A,B]
R Applies to [B] list formatted [C]
Add a new line item 'intermediate' that must have 'Applies To' set to the 'Format' of 'R'
intermediate = X[SUM: R]
Y = intermediate[LOOKUP: R]
This issue is currently being worked on by Development and a fix will be available in a future release
Calculations are over non common dimensions
Anaplan calculates quicker if calculations are over common dimensions. Again, best seen in an example. If you have, List W, X Y = A + B Y Applies To W, X A Applies To W B Applies To W This performs slower than, Y = Intermediate Intermediate = A + B Intermediate Applies To W All other dimensions same as above. Similarly, you can substitute A & B above for a formula, e.g. SUM/LOOKUP calculations.
CELL HISTORY TRUNCATED
Currently history generation has a time limit of 60 seconds set. The history generation is split into 3 stages with 1/3 of time allocated to each.
The first stage is to build a list of columns required for the grid - this involves reading all the history - if this takes more than 20 seconds then the user receives the message "history truncated after x seconds - please modify the date range", where x is how many seconds it took. No history is generated.
If the first stage completes within 20s it goes on to generate the full list of history.
In the grid only the first 1000 rows are displayed, the user must Export history to get full history. This can take significant time depending on volume.
The same steps are taken for model and cell history. The cell history is generated from loading the entire model history and searching through the history for the relevant cell information. When the model history gets too large then it is currently truncated to prevent performance issues, unfortunately this can make it impossible to retrieve the cell history that is needed.
Make it Real time when needed
Do not make it real time unless it needs to be.
By this, we mean do not have line items where users input data being referenced by other line items, unless they have to be. A way around this could be to have users have their data input sections which is not referenced anywhere, or as little as possible and, say, at the end of the day when no users are in the model, run an import which would update into cells where calculations are then done. This may not always be possible if the end user needs to see resulting calculations from his inputs, but if you can limit these to just do the calculations that he needs to see and use imports during quiet times then this will still help.
We see this often when not all reporting modules need to be recalculated real time. In many cases, many of these modules are good to be calculated the day after.
Don't have line items that are dependent on other line items unnecessarily - this can cause Anaplan to not utilize the maximum number of calculations it can do at once. This happens where a line items formula cannot be calculated because is it waiting on results of other line items. A basic example of this can be seen with line item's A, B, and C having the formulas: A - no formula B= A C = B Here B would be calculated, and then C would be calculated after this. Whereas if the setup was: A - no formula B = A C = A Here B and C can be calculated at the same time. This also helps if line item B is not needed it can then be removed, further reducing the amount of calculations and the size of the model. This needs to considered on a case by case basis and is a tradeoff between duplicating calculations and utilizing as many threads as possible - if line item B was referenced by a few other line items, it may indeed be quicker to have this line item.
Summary cells often take processing time even if they are not actually recalculated because they must check all the lower level cells.
Reduce summaries to ‘None’ where ever possible. This not only reduces aggregations but the size of the model
A dashboard with grids that include large lists that have been filtered and/or sorted can take time to open. The opening action can also become a blocking operation; when this happens, you'll see the blue toaster box showing "Processing....." when the dashboard is opening. This article includes some guidelines to help you avoid this situation.
Rule 1: Filter large lists by creating a Boolean line item
Avoid the use of filters on text or non-Boolean formatted items for large lists on the dashboard. Instead, create a line item with the format type Boolean and add calculations to the line item so that the results return the same data set as the filter would.
This is especially helpful if you implement user-base filters, where the Boolean will be by user, and by the list to be filtered.
The memory footprint of a Boolean line item is 8x smaller than other types of line items.
Warning on a known issue: On an existing dashboard where a saved view is being modified by replacing the filters with a Boolean line item for filtering, you must republish it to the dashboard. Simply removing the filters from the published dashboard will not improve performance.
Rule 2: Use the default Sort
Use sort carefully, especially on large list. Opening a dashboard that has a grid where a large list is sorted on a text formatted line item will likely take 10 seconds or more and may be a blocking operation.
To avoid using the sort: Your list is (by default) sorted by the criteria you need. If it is not sorted, you can still make the grid usable by reducing the items using a user-based filter.
Rule 3: Reduce the amount of dashboard components
There are times when the dashboard includes too many components, which slows performance. A reasonably large dashboard is no wider than 1.5 page (avoiding too much horizontal scrolling) and 3 pages deep. Once you exceed these limits, consider moving the components into multiple dashboards. Doing so will help both performance and usability.
Rule 4: Avoid using large lists as page selectors
If you have a large list and use it as a page selector on a dashboard, that dashboard will open slowly. It may take10 seconds or more. The loading of the page selector takes more than 90% of the total time.
Known issue / This is how Anaplan works: If a dashboard grid contains list formatted line items, the contents of page selector drop-downs are automatically downloaded until the size of the list meets a certain threshold; once this size is exceeded, the download happens on demand, or in other words, when a user clicks the drop down. The issue is that when Anaplan requests the contents of list formatted cell drop-downs, it also requests contents of ALL other drop-downs INCLUDING page selectors.
Recommendation: Limit the page selectors on medium to large lists using the following tips:
a) Make the page selector available in one grid and use the synchronized paging option for all other grids and charts. No need to allow users to edit the page in every dashboard grid or chart.
b) If you have a large list, it makes for a poor user experience, as there is no search available. Using a large list as a page selector creates both a performance and a usability issue.
Solution 1: Design a dashboard dedicated to searching a line item:
From the original dashboard (where you wanted to include the large list page selector), the user clicks a custom search button that opens a dashboard where the large list is displayed as the rows of a grid.
The user can then use a search to find the item needed. If possible, implement user-based filters to help the user further reduce the list and quickly find the item.
The user highlights the item found, closes the tab, and returns to the original dashboard where all grids are set on the highlighted item.
Alternate solution: If the dashboard elements don't require the use of the list, you should publish them from a module that doesn't contain this list. For example, floating page selectors for time or versions, or grids that are displayed as rows/columns-only should be published from modules that does not include the list.
Why? The view definitions for these elements will contain all the source module's dimensions, even if they are not shown, and so will carry the overhead of populating the large page selector if it was present in the source.