Yes! Here are a couple use cases. This would be a huge win and save customers that use a data hub an immense amount of time.
First, let me preface with another limitation that should be considered and that is the inability to "push" data. By definition, any synchronization from the data hub will now require two processes on two separate dashboards (or NewUX pages). While automation is always a possibility, this is not practical with administration (e.g., master data management inside Anaplan). If you want all the pitfalls and "gotchas" of having to sync alternate hierarchies, reach out to me privately. I'll give you an earful. Also, I have documented all the steps required to sync DH to spoke for hierarchies that are administrated in the DH and synchronized in the spoke applications. It's a lot more work than most people realize, especially if you have all the proper auditing working.
Use Case #1 | Call Centers
Call centers, large ones, are usually broken up into smaller groups that are organized by the types of calls to be received (product or service) and by the skillset of the call agent. This would be the grain of the hierarchy. From there, there are several requirements to have this lowest level report into multiple parents. The first is a hierarchy that is used for forecasting demand. The second is a hierarchy that is used for reporting, usually by a product or service aggregation. The demand hierarchy is used to allocate budget across the service desks and/or 3rd parties. The product hierarchy is used for reporting and integration with the GL. Note: there sometimes is a third aggregation which is based on location to determine required headcount.
Use Case #2 | Retail
The lowest product level for retail is different for most retailers but generally, it is SKU for hardlines, and style-color for softlines. By the way, if the retailer needs both hardlines and soflines, there are additional hierarchy challenges. What typically happens from here is that this lowest level will have 20-50 properties assigned to them, with some of them having further aggregations (alternate hierarchies). The most typical example is a traditional hierarchy where product rolls up by product categories, like class, department, division, etc.. Then things start getting hard. For apparel, there is a concept of a season. Seasons are not time properties but rather, product properties. For example, a sweater belongs to the spring collection, or spring season. These collections are used in wholesale as "modules" that are used in sales to their customers. There might be an intermediary level called "delivery" which suggests a type of condition needed for floorsets and/or contractual obligations made with the manufacturer. For hardlines, there is sometimes a vendor rollup needed which may have multiple hierarchy levels. For example, buying imported goods vs domestic for the same product. As you can imagine the list is rather large.
I happen to utilize alternate hierarchies quite a bit in my last project. I always disliked the fact that I had to duplicate a list, not only for model size perspective but also from a maintenance point; I had to ensure I have processes to synchronize the alternate list(s) with the original list. Below are 2 examples of when I actually used alternate hierarchies in my last project (Real Estate Investment Portfolio Management) Example 1: Business Case: Report and analyze financial and non-financial data of a Real Estate hotel investment Portfolio.
Data: We were given a master list of the Hotel Assets with various attributes such as:
- Brand (Sheratorm Hilton,.....) - Type (Extended stay,....
- Market ( Airport, suburban, Urban,.....)
And a few other attributes
The natural hierarchy was Hotel --> portfolio
That's how we get the monthly actuals for each hotel and then calculated the financial P&L as well as non-financial data such as #rooms, Occupancy Rate, POR, PAR,... etc
The user wanted to see how the assets are performing based on some of the attributes mentioned above (Brand, Type, Market,.....) not only based on the managing portfolio
Alternate hierarchies came in handy here. I had one calculation module dimensioned by the Hotels, yet I was able to create multiple reporting modules/dashboards dimension by the alt lists without repeating the underlying P&L calculations.
Use Case: Quarterly Board Reporting of fund performance based on a hierarchy different from the hierarchy used by the financial team; Tying the financial performance of the Board report with that of the finance/accounting report.
An Asset could be acquired under a particular deal (Deal #), yet during the life of the fund, assets could move from one deal to another for reporting fund managers' performance comparisons for example. From an accounting perspective, the asset still exists under the original deal.
Again, we used the original hierarchy in the Accounting module and used an alternate hierarchy that group the assets under the appropriate reporting deal in the Quarterly Board model.
If you need any further clarifications/information about the details of the use cases please let me know
Einas "Give a Man a Fish, and You Feed Him for a Day. Teach a Man To Fish, and You Feed Him for a Lifetime"
A supply chain/procurement use case that I have seen an example of this is when a SKU should be under both a category and a supplier. Many procurement departments might group this under a category and assign a buyer to it at that level, but it is also critical to know what the total spend/SKU's look like from a supplier perspective. Right now, this is usually done by choosing the important one, and then the less important of the roll-ups just becomes a reporting hierarchy.
In the Trade and Promotion world, Most promotions are assigned to a retailer or a group of retailers, but they also have a type of promotion. In some cases depending on the requirements, we might have a type of promotion rolling up into a retailer, and that same couple of promotion types would be duplicated for each retailer. It would be nice to be able to roll those up elsewhere and still be able to segregate them by the supplier as well.
On the SPM side, similar use case where accounts might role up to an Account type, Region, Account Size, and a Rep. Obviously depending on some of these would be better suited as a property, but having the ability to have an account role-up a couple of places would cut down on the duplicative nature of some of the reporting created here.
A couple of other random thoughts/questions I have (and don't expect you to have answers on right now):
- How would Sync-ing on a page work? You could have multiple hierarchies displayed on a page, and syncing could get a little weird.
- How would selective access work? In my first example, there could be reasons to assign selective access to different roles, on different hierarchies.
I am sure I could come up with several other examples of where this would be a big-time help. Looking forward to this one when and if it comes to fruition!
Alternate hierarchies enable natural rollup of items that may depend upon the business or functional area:
Geo - The Minneapolis office is in the north central sales region, the eastern professional services area, the americas administrative team, ... but in the G/L, the transactions are all coded to Minneapolis.
Products and services rollup differently for procurement, for manufacturing, for sales, and for marketing.
Cost center rollups in FP&A often have "prior org", "current org" and "planned re-org" hierarchies to allow comparison and restatement before / after reorg. In matrix organizations, Cost Centers may also need to roll up both according to management responsibility and by function.
Accounts - alternate rollups in an accounts hierarchy can be used as a means of mapping accounts to summary report lines using the parent-child relationship.
Picklists - I'm not coming up with any examples off the top of my head, but there may be situations where alternate drill paths to attributes are useful. These would be attributes that sum, but not things like currencies since rollup of euros and pounds makes no sense.
Time - We sometime use alt-time lists for special situations. Fiscal Year for accounting vs Calendar Year for tax. The odd situation where a company changes their fiscal year end. (I've suffer through that one. It's a mess.)
Drilling - We currently address alt hierarchies by summing attributes, but that doesn't make it quite as easy for end users to expand an alternate hierarchy to leaf level or to mix multiple rollup nodes
When looking at Financial Consolidation a company would always need a 'Statutory' rollup based on ownership and a 'Management' hierarchy based on how the company is actually managed (e.g. by geography, brand, ...). Each hierarchy rolls up 'companies' but with different parents/hierarchies
This is the start of the initial investigative phase - It is high priority, but it is way too early to be talking details, thinking of timelines or how it would look. That is all to come. I will come back to this thread at the appropriate time
Time based hierarchies or slowly changing dimensions are very tricky in a multi-dimensional world, and I don't this solving for that directly - however, the before / after of changes could be possible
In terms of selective access, again, too early to say, but valid to raise it as part of the discussion
I have a couple examples of using alternative hierarchies:
1) S&OP use-cases
1.1 Products Properties and Reporting needs
Quite often Different departments look on a different aggregations of same SKU's
S&OP: Category -> Brand -> Type -> Pack Set -> ... -> SKU
Demand: Category -> Brand -> Type -> SKU
This is used by business to see what volumes will be needed by specific pack.
Agree with requirements that @JaredDolich shared concerning product hierarchies. This is quite typical for all S&OP use-cases. Reporting usually requires to slice and dice and see summaries by specific product properties which leads us to tailor reports and customise specific hierarchies to show proper properties.
1.2 Product Aggregates
This one a little different. I faced it particularly in Demand planning when customer do have a hierarchy of SKU's and would like a maintain both SKU details and aggregate of smaller SKU's as they dont need to forecast really each low level SKU, but rather do precise forecast of TOP100 and rest aggregate to groups. So actuals are coming by SKU, but Forecasting really on Top SKU + Aggregates. Example:
SKU 1 -> SKU 1
SKU 100 -> SKU 100
SKU 900 -> Group A
SKU 999 ->Group A
SKU 1000 ->Group B
2) Security segregation
One of the examples that I faced also in hospitality industry:
Hotels could be structured for planning purposes by Geography like:
Country -> Brand -> City -> Hotel
But managed and reviewed by Brands + Property of the Hotel Size (Big, Med, Small)
So from a process side planning is feeded from a bottom-up by hotel, but reporting and manager reviews are done by another properties of the hotels and they need to be Secured with selective access. And it was done through segregation of hierarchies and different security settings for each of it.