Anaplan Use-Case 2: Relevant List Items

Gaurav Dembla
6 min readMar 1, 2024

In business planning, not all the members of a dimension are required for planning. This article delves into a use-case centered on using a limited and relevant set of items of a list.

NOTE: This article is a segment of the Anaplan Use Cases series. If you haven’t already, I encourage you to read through the introductory blog Why Anaplan Use Cases Series? to understand the background behind this endeavor.

Context

Let’s take an example of a hypothetical food manufacturer Crispy Bites which manufactures and sells packaged potato chips in different flavors (packaging labels). There are 15 varieties of potatoes that could be used to manufacture potato chips. However, not every variety is used to make Crispy Bites flavors.

The In-Planning Boolean indicates whether a potato variety is to be used for the manufacturing of chips and to be considered for sourcing from the growers. At the same time, each Variety has been classified under one of the three Variety Types: All-Purpose, Starchy and Waxy.

Variety System Module

Commodity Manager (CM) plans for the sourcing of required weight of each variety of potato and sends the information to the growers. On the existing commodity planning page, CM gets to see all the varieties, even the irrelevant ones (such as Vivaldi and Bintje) that are not used to manufacture any flavor.

Existing Commodity Sourcing planning page

User Story

As Commodity Manager (CM), I need the commodity planning page to be restricted to In-Planning varieties, so that I can focus on planning for the required varieties only, and do not waste my time projecting for the irrelevant ones, by mistake.

Expected Commodity Sourcing Planning Page

Solution

The problem statement requires us to limit the list of varieties on the commodity planning page to only the ones that are in the scope of planning. Since we have In-Planning? flag in the Variety system module, we have two ways to improve the commodity planning page.

Filter Method: Anaplan provides a filter option that can be accessed from the top bar of the module.

Filter option in the top bar

Press the filter icon in the commodity planning module ‘INP02 Commodity’. In the subsequent dialogue box, simply pull the In-Planning line-item from the Variety system module as a filter.

Filter dialogue box

Once done, we see a reduced list of varieties in the commodity module. Now, the user can focus on the relevant varieties while planning for the required weight of a potato variety.

Commodity page after filter activation

The method poses two problems:

a) Let’s assume that the user, at some point in future, requests to use the planning numbers further, perhaps, for some summary report. For example, if the projected weight is aggregated by Variety Type, then the numbers of the irrelevant varieties unnecessarily fall into the summarized (aggregated) numbers.

Aggregation without filter
Aggregation with filter

Note that the aggregated numbers do not change even after applying the filter on the source module. Anaplan simply takes out the irrelevant varieties and creates a view — a façade off the source module. What we see is a façade. Underneath the façade is the original dataset (with all the varieties and the associated numbers), which is regarded as the source for aggregation.

If the user just needed to see only relevant (In-Planning) varieties on the UI planning page, we would be fine. But it is not unreasonable to assume that at some point, he/she might want to take things further and apply aggregation sans Variety dimension. In such a case, applying filter on the module would yield misleading results.

In fact, this is the reason Anaplan recommends creating Saved View when a filter is applied. As part of Anaplan modeling best practices, it is strongly advised to not use filters in the Modules, but only in the Saved Views.

b) Applying a filter on the module yields no benefit whatsoever. The size of the module and the cell count of each line item remains the same. If it were a high-dimensionality module, not realizing any benefits in terms of model performance or size would be highly unacceptable.

Commodity Module Size

List Subset: If we seek a strategic and robust solution to the problem at hand, we can go ahead with creating a list subset. We can use the In-Planning flag in the Variety system module to create (update) a subset of the list Variety. The subset can then be used in the planning module(s) to limit the pages to relevant varieties only.

In-Planning? (SYS01 Variety) → SS Variety: In-Planning

Steps:

a) Create a Subset off the Variety list.

b) Create a Saved View off the Variety system module.

c) Create and run an import action to populate the variety list subset from the saved view.

Subset should be populated/updated as follows.

d) Change the dimension of Commodity planning module from the Variety dimension to the Variety list subset. As soon as the subset is applied to the module, the cell count reduces from 45 to 18.

A quick look into the summary reporting module shows that the weight is aggregated correctly now.

While the second approach (offers a sustainable solution, there is just one downside — introduction of an action button (corresponding to the import process outlined in step c above). The import action needs to be triggered by the user whenever the scope of a variety changes in the manufacturing of Crispy Bites potato chips. Assuming that such a change would be a rare occurrence, there might not be a downside after all!

Conclusion

The list subset approach not only ensures that the right (relevant) numbers move ahead in the data flow, but also handles the potential problem of sparsity. Why use/keep members (items) of a dimension (list) in module(s) when they are not required in the planning process?

If an Anaplan modeler/developer works in an Agile development environment, it is difficult to spare time to think beyond the user stories at hand. However, for an efficient and less chaotic development, it is imperative that the modeler thoroughly understands the pros and cons of multiple approaches to a given problem, and then probes the business user to seek clarity on what lies ahead in user requirements. The team does not need to boil the ocean — modelers just need to openly discuss the pros and cons of different approaches, provoking users to divulge information that might be pivotal to building the right foundations of the Anaplan model now.

Remember “A stitch in time saves nine”!

--

--

Gaurav Dembla

Love for data and planning has enabled me to acquire skills in Anaplan and data mining/visualization! www.linkedin.com/in/gauravdembla/