Anaplan Use-Case 1: Boolean Aggregation
In Anaplan, data aggregation stands as one of the most important data manipulation necessity. This article delves into a use-case centered on Boolean aggregation, offering insights into potential solutions.
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 9 different flavors (packaging labels).
There are 15 varieties of potatoes that could be used to manufacture potato chips. However, since each variety has its unique taste, texture, and color, not every variety is used to make every flavor. Product Business Manager (PBM) plans and allocates each variety to the right flavor(s). For example, while Russet variety is used to make Classic and Roasted Jalapeno flavors only, Yukon Gold has been marked to manufacture Spicy Tango and Texan Chili only.
The potatoes required to manufacture the chips are sourced from partner organizations that grow and harvest the potatoes. Commodity Manager (CM) plans for the required weight of each variety of potatoes and sends the information to the growers, who need it to plan for the infrastructure and material required to grow, harvest, and supply the projected amount of the commodity to Crispy Bites over the coming years.
User Story
As Commodity Manager (CM), I need the system to assign whether a variety is In-Planning or not, so that I can use the information later to distinguish between relevant and irrelevant varieties while projecting the weight of potatoes required over the coming years.
I want In-Planning flag to be derived/updated from the Allocation page that Product Business Manager (PBM) uses to allocate varieties to different flavors. A variety is considered In-Planning if it is used to manufacture at least one flavor.
Analysis & Design
The problem statement requires us to derive the In-Planning? flag (in the Variety System module) using the Allocation? flag (from the Allocation module).
Source: INP01 Allocation @ Variety and Flavor
Target: SYS01 Variety @ Variety
This is a typical case of aggregation — source has two dimensions while target has just one (of them).
Implementation
Let’s explore two possible ways to implement the aggregation.
Vanilla Method: Anaplan is a pretty smart tool. If the source has a greater number of dimensions than the target, and if all the dimensions of the target line-item/module are included in the source line-item/module, and if the target line item directly refers to the source line item, then Anaplan will automatically apply the aggregation.
However, before we set the direct reference in the formula, we need two more things.
a) Set the top-level node of the dimension(s) being ditched. In this case, Flavor. If we don’t do this, the system will not accept the formula and throw an error.
b) Set the summary method of the source line-item to ANY, so that the system computes whether a variety is allocated to at least one flavor or to none. If we don’t do this, the system will accept the formula, without any issue, but will not calculate the aggregated value, because it wouldn’t know what aggregation method (ANY or ALL) to apply.
Finally, we define the formula of the target line-item by simply referencing the source line-item. The system does the aggregation automatically. Voila!
Though this aggregation method is simple to comprehend, it comes with its own issues. Remember we had to reluctantly set up the top-level of the ditched dimension(s) and the summary method of the source line item?
Everywhere Flavor dimension is pulled in, its top-level node is dragged with it as well, thereby showing unnecessary hierarchy in the data grid/UI pages.
Can the top-level be removed, hidden, or avoided from UI data grids/pages? Yes, it can. However, it requires a couple of more steps that we are not going to discuss in this article here.
Enabling summary method of the source line-item needlessly shows up summary statistics in the source module. If the source module has many dimensions/items (and hence, cells), summary could turn out to be prohibitively expensive.
ANY grouping: A little research reveals an alternative aggregation method — one that does not require any of the above-mentioned pre-requisites. Use ANY grouping function.
First, we need to create a line-item (format: Variety list) in the source module and hold Variety information in it, because ANY function accepts only list-formatted line item(s) we need to group the measure by.
Finally, we apply the aggregation function ANY while referencing the source line-item.
With just one new line item, ANY grouping method avoids both the downsides of vanilla aggregation method. That said, depending on the overall user requirements, one might still prefer the latter to the former.
Conclusion
With experience, I have learnt that Anaplan has a wide variety of tools/concepts. One can solve a problem in multiple ways, each using a set of different concepts. Putting oneself in the end user’s shoes and imagining user experience is paramount in solving the problem the right way — one that enhances (and not degrades) user’s interaction with the system/platform.
Last but not the least, these aggregation concepts can be extended beyond Booleans, and applied to number formatted measures as well. We just need to replace ANY with other aggregation functions such as SUM, AVG, MIN, MAX, etc.
