Every business needs to have a scalable, reliable model in place that addresses all business functionalities and enables understanding of business performance in real time. With business processes going agile, and the exact ask being seldom clear, it is difficult for the solution architect to size the business model accurately for addressing the requirements.
Anaplan connected planning platform, a Cloud-native solution that supports detailed models, delivers the potential to achieve success in this area. Anaplan models offer desirable levels of module capacity and flexibility to address business needs. Though Anaplan allows high levels of capacity, it is crucial to ensure optimized size while designing models. Excessive model size costs more and involves overheads like data duplication.
Anaplan flexibility can enhance the model, but at the same time, can give a tough time to the architect or model builder in terms of controlling the right size for the model. Hence, it is imperative to follow certain methods meticulously to bring model to the right size that meets the requirements. Points discussed below, followed in chronological order, will drastically reduce the model size and ensure that model builders have followed the most optimized approach to designing and building models.
1. Check on the time settings
Native time dimension settings works best in most of the cases, except for a few. For instance, if the business would like to view data weekly but compute the month totals based on days and not on weeks, Anaplan has no time settings to address this scenario. Hence, either a custom or a fake time scale has to be created with custom mapping of days to month separately in module to use model calendar settings. Another possible solution is to use Week General Settings but this would not allow certain functions such as Month Value. Best approach in this scenario is to use 4-4-5, 4-5-4 or 5-4-4 time distribution.
2. Take the POC approach
Proof of Concept approach should be followed as part of design or initial model building to cover the basic functionalities. For e.g. to prove which time dimension settings would work fine, best approach is to do it. Certain pertinent questions that should be answered are:
- What value additional days to month level aggregation would bring that week to month aggregation cannot bring?
- How important is the differential data for the decision making?
- Perform a POC and showcase the aggregation of the numbers from days to month and from weeks to month via small proof of concept. This will tear the facts apart and will provide insight regarding the data.
3. Evaluate usage of custom lists for versions
Use native versions wherever possible. However, you cannot create subsets against them. There can be certain modules whose dimensionality depends on What-if versions and not actual version. Idea is to create a subset against the custom list of versions. In Figure 1, a subset named s-simulation is created to limit the weekly module size to 151,792,040 Cells (1.43 GB). Actual version being included would increase model size.
4. Go for hierarchy pruning
There are many instances wherein unnecessary transactional level details are brought into Anaplan. Business should be challenged with questions regarding the relevant list members to be included in Anaplan. If there is a requirement to drill back to the transaction data from the model, then there is a valid reason to hold transactional data.
For instance, a company reduced the number of service business units from 19 to 5, leading to 70% space reduction. They were pruned as they were not needed in the Anaplan model. In Anaplan, all the modules will not contain all the lists, it is a careful selection of the lists that would determine the size of the module. The intent should be to bring data that is absolutely relevant and useful rather than copying from the source.