The beauty of simplicity: any level of selection in a hierarchy
Author: Hanwen Chen is a Certified Master Anaplanner and Professional Services Sr. Manager at Anaplan.
Use case
This is an interesting use case. One of our customers wanted to be able to include/exclude any list item/member in any level of a hierarchy to/from a group. The customer calls the group “Domain”. Domains are used for cost allocation. After an upper-level member is assigned/excluded to/from a domain, the descendants of the member by defaults will inherit the same domain or will be excluded from the domain. The functionality needs to be applied to three main hierarchies: Cost Center, GL Account, and Product. Cost Center hierarchy has 18 levels. GL Account hierarchy has 15 levels and Product Hierarchy has 8 levels.
Before I went to work on the project, the customer did have an existing built solution. But they couldn’t use the functionality due to two main reasons:
- The end users got very lost when navigating a member in a hierarchy on a UX page. For example, the UX page for cost center hierarchy had 18 grids published. Each grid represents a level of the cost center hierarchy and users use the grid to assign or exclude a cost center. Users had to go through 18 grids in a page to find a cost center and assign a domain to a cost center. In addition, users need to run processes to generate the assignment and exclusion. There are additional grids for users to review the final assignment results.
- A large volume of lists, modules and formula were used to support the functionality. It was very difficult to troubleshoot issues and maintain all these different components. The customer was not able to validate whether the built solution worked.
When I was asked to help them come up with a solution to provide the functionality, I was aiming at providing a simplified solution that achieved the following goals:
- It would be extremely easy for users to find a member such as cost center and include/exclude a domain to/from the member.
- It would dramatically reduce the number of the lists, modules and formulas used to support the feature.
- The solution can be easily replicated to reduce the development time and increase the scalability of the solution. For example, if I build the modules and lists that are used to support the feature for cost center hierarchy assignment, I can easily copy and paste the modules and formula with some changes to be used for GL Account hierarchy assignment.
Solution configuration
For illustration purposes, I use the Cost Center hierarchy as an example. The hierarchy has six levels in total.
The solution includes the configuration of UX Pages, lists, modules and formula.
UX page
The front end for users contains a simple table for users to assign a domain to a cost center. See screenshot below. Users select a domain from the context selector on the top of the table. To assign a cost center and its descendants to the domain, just simply check the “Include?” box of the cost center. To exclude a cost center and its descendants to the domain, check the “Exclude?”. The column “Assigned Domain” will display the assigned domain. The columns from “Parent” to “Org L5” can be used as filters to help users navigate the hierarchy. For example, if a user wants to see “Central Europe” and its descendants, the user can just simply apply “Central Europe” to the column “Org L3”.
When a user checks “Include?” for Central Europe, the assigned domain will show the “Org_Domain1” for Central Europe descendants. See the screenshot below.
Switzerland and Germany are part of the Central Europe. If a user wants to exclude Switzerland and its descendants from the domain, the user can just simple check the “Exclude?” box for Switzerland. The assigned domain will have blank value for Switzerland and its descendants. See the screenshot below.
Users found that it is extremely simple to assign or exclude a cost center to/from a domain by using the UX page.
Lists
There are two lists: Flat Organization and Flat Domain. Both are flat lists. The Flat Organization includes all the cost centers in the cost center hierarchy. The Flat Domain includes all the domains that can be assigned to a cost center. It can also include the domains associated with other hierarchies such as GL account and Product. A subset “s Flat Domain: Org Domain” is created to include only the domains related to a cost center.
Module and formula
Only one module is used to provide the assignment functionality for the cost center hierarchy. See “Domian Assignment to Cost Center” module in the screenshot below.
The section below “CC Domain Assignment Calc-“ is used to figure out the final assignment. The formula in these line items is very simple:
Replication of the functionality for other hierarchies
To build the same functionality for other hierarchies such as GL account, I just simply copied the module “Domain Assignment to Cost Center”, made changes if applicable such as the list and the property module in a formula, and named the module “Domain Assignment to GL Account”. See the screenshot below.
To create a UX page for users to assign a domain to a GL Account, just copy the existing UX page “Domain assignment to cost center” and name it “Domain Assignment to GL Account” and publish the assignment table by using the module “Domain Assignment to GL Account”. See the screenshot below. When the box “Include?” for SGA is checked, the domain value for SGA and is descendants is populated.
Given the logic stays the same between domain assignment to cost center and domain assignment to GL account, it should take less than an hour to build the same functionality for GL account hierarchy domain assignment, which dramatically reduced the development time of the project.
Summary
When building an Anaplan model or App, I believe that it is critical to always ask yourself if there is a way to simplify your design. The beauty of simplicity is that it can make users fall in love with what you build while reducing development time, and making the model/app very efficient and easy to maintain.
Simplicity is one of the design principles to which I always adhere when I provide a solution for customers. It is something I encourage the Solutions Architects and the model builders and the customers to adopt when they work with me on a project.
Questions? Leave a comment!
Comments
-
I like this approach and is a lot cleaner than solutions I have applied in the past because this accommodates all hierarchies in one view.
It would work well in account groupings that are stable and any other hierarchy that doesn't change much. However be careful if you are in a company that, cost center in particular, changes it's organization on a frequent basis. My organization and many others haven't truly separated the cost center population from their organizational structure and there are material swings in the hierarchy on a semi-annual and even quarterly basis. Selections can be renamed so an underlying code using level logic is needed for sanity. Hierarchy combinations, spits, and orphans of items above leaf can complicate the management of these type groupings.
Not being critical of this approach at all. it is brilliant. Just be aware that this may finally give some of you readers the ability to enable the process above…be aware of managing the changes over time may be a lot of work if you are plugging into a volatile hierarchy
0
