Seeking Advice: Establishing a unified organizational structure & managing restatements

ELinge

Hello,

I work at a company's headquarters, where we use Anaplan for reporting purposes. Some of these Anaplan models have been developed in-house, while others have been created by external consultants. This has resulted in a situation where we have multiple lists containing more or less identical organizational structures. Whenever changes occur within our organizational framework, we find ourselves having to make individual adjustments to each of these lists.

I will soon be beginning an Anaplan project with various objectives, one of which is to establish a unified organizational structure that can be utilized across all our models. Currently, I'm in the process of creating a project plan, and if possible, I'd like to discuss some potential challenges with you. I've been working with Anaplan for six months and have successfully created reporting modules in the past, but this project represents my most substantial endeavor yet.

Background / Problem Description:

The company I work for operates globally, organized into regions, platforms, and branches. For instance, regions include Nordics, Europe, and Pacific, while platforms are typically countries, except in the United States, where they correspond to local companies. Branches are usually our local offices where operations take place, though some branches also house smaller delivery units (which won't be included in the organizational structure for now).

The primary objective of my project is to establish a monthly reporting structure where platform managers can report key performance indicators such as revenue or Net Promoter Score (NPS) for all underlying branches. This module itself is straightforward and won't pose any issues. The challenge arises when the company's organizational structure changes, typically involving branch mergers or the creation of new platforms. In such cases, we require the new branch to submit a restatement, which may involve recalculating metrics like revenue or NPS. Occasionally, a merger may necessitate the splitting of an existing branch, and in such instances, the key figures for that branch must also be recalculated. Crucially, we must retain historical data for all branches as of December 31st of each year.

We're currently establishing an Anaplan data hub where we'll store platform-level revenue, imported from another reporting software.

Solution / Potential Issues:

My thought is to create new lists for regions, platforms, and branches within the data hub. I'm considering using subsets to keep track of active branches and those that have been used in the past. Additionally, I intend to use subsets to allow different models to include either some or all of the branches.

Furthermore, I plan to create a module for importing historical data. This module will include all branches, both active and historical, and the import will be performed manually (or potentially automatically) at the beginning of each year when the previous year is "closed." Is there a better way to handle this, possibly by utilizing versions in Anaplan?

In the event of an organizational structure change, I would like platform managers to have the ability to modify the list structure themselves, but an administrator would need to approve the change before updating the list. My idea is to maintain two similar lists: one that is locked and stored in the data hub and another that users can edit. When a user submits a change, I can export the updated list and then import it into the locked data hub list. Is this approach feasible, or are there better solutions?

For restatements, I'm considering creating a restatement form in Anaplan, allowing users to specify which metrics need adjustment. Subsequently, the administrator would manually update this information.

If anyone has suggestions on how to tackle this challenge or personal experiences with creating similar functionality, I would greatly appreciate your insights. Please let me know if you require additional information.

Thank you in advance!

Best regards,

E.L.

JaredDolich

@E.L.

Surprisingly, this is a common use case, especially if Anaplan has been implemented by multiple parties. Sorry to hear this is happening. I suspect you'll get plenty of opinions so you'll need to balance what's possible vs. what's practical. Some thoughts for you to consider:

• Big picture - you should try to set yourself up to follow the Anaplan Way - modified Scrum - so that you're prioritizing your time appropriately AND there exists a user story that defines the success criteria. Also consider laying out the groundwork for an Anaplan COE so you don't find yourself in this situation again.
• Start by collecting the requirements for the reports you're considering. Look for ways to create a common set of lists because presumably you'll need to aggregate the data along those lists. Create user stories and have the consumers of the reports agree to the changes & aggregations, if any.
• Create the lists independently in the data hub from anything else. Spend a good amount of time getting these lists synchronized to the apps (spokes).
• Create audits to ensure lists are complete and you don't create orphans
• Promote to Production (ALM)
• One by one switch the reports to use the new lists. Run them through the sprint reviews.
• Promote to Production.
• Consider removing or deleting the obsolete lists.

Last resort: If you find yourself in a situation where the report consumers are unwilling to switch to a common set of lists, you can create intersection tables (many-to-many) combinations to bring some sanity to the reporting. But, it will come at a cost which is that someone will have to manage the valid intersections.

Good luck, just some thoughts.