Organizational reporting structure in Anaplan: Seeking Input and Insights

Options
E.L.
E.L.
in Modeling

Hello,

I work at a company's headquarters, where we use Anaplan applications 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.

Best Answer

  • TristanS
    TristanS
    edited October 2023 Answer ✓
    Options

    @E.L. I have worked on projects for global companies and as you have highlighted restructures tend to complicate implementation. Before I provide my suggestion I'd like to provide background on the typical restructures that can occur

    1. Move organisational unit to a different parent level
    2. Merging of organisational units (at various levels)
    3. Addition of new organisational units (again at various levels)
    4. Splitting of organisational units (again at various levels)
    5. Combination of any 4 above

    For example, here's the original Organisational units prior to a restructure

    Total Organisation

    • Region 1
      • Platform 1X (revenue 25 which is a sum of B1 and B2)
        • Branch B1 (revenue 10)
        • Branch B2 (revenue 15)
      • Platform 1Y (revenue 50 which is a sum of B3 and B4)
        • Branch B3 (revenue 20)
        • Branch B4 (revenue 30)

    Restructure Scenario 1: Move organisation unit B2 from 1X to 1Y

    If you captured revenue data for this using a list hierarchy (rather than a flat list) as per representation above and you move the existing leaf B2 list to the new parent 1Y. You will get the following result:

    • Region 1
      • Platform 1X (revenue 10)
        • Branch B1 (revenue 10)
      • Platform 1Y (revenue 65 which is a sum of B2, B3 and B4)
        • Branch B2 (revenue 15)
        • Branch B3 (revenue 20)
        • Branch B4 (revenue 30)

    So impact are as follows:

    • You will lose the revenue view for both Platform 1X and 1Y prior to the restructure. Using Versions will not help keep the original revenue information
    • You get the restated revenue view for both Platform 1X and 1Y as a result of the list restructure

    If you want to be able to have both views available to you then here's my suggestion:

    1. Capture the data as part of a flat list instead of a list hierarchy. Use "Flat list Branch" as a dimension in your module. E.g. call the module "Revenue Flat"
      1. B1 (revenue 10)
      2. B2 (revenue 15)
      3. B3 (revenue 20)
      4. B4 (revenue 30)
    2. In your list hierarchy, apply concatenated child parent keys (if not done yet) so you can track the restructure movement of B2. For example,
    • Region 1
      • Platform 1X
        • Branch B1 (use code B1:1X)
        • Branch B2 (use code B2:1X)
      • Platform 1Y
        • Branch B2 (use code B2:1Y)
        • Branch B3 (use code B3:1Y) … etc

    3. Have a module to store the dates/period when the list hierarchy (not the flat list) was active. For example,

    • Region 1
      • Platform 1X
        • Branch B1 (Start Period: Jan 2022 , End Period: <blank> to mean still current)
        • Branch B2 (Start Period: Jan 2022 , End Period: Nov 2022). So Revenue period is active if it is between Jan 22 and Nov 22
      • Platform 1Y
        • Branch B2 (Start Period: Dec 2022 , End Period: <blank>)
        • Branch B3 (Start Period: Dec 2022 , End Period: <blank>)

    4. Have a mapping module between your hierarchy list and flat list. For example, name the module "Mapping"

    • Region 1
      • Platform 1X
        • Branch B1 (maps to flat list B1) ⇒ you should be able to auto calculate it based on the code
        • Branch B2 (maps to flat list B2)
      • Platform 1Y
        • Branch B2 (maps to flat list B2)
        • Branch B3 (maps to flat list B4)

    5. Have a calculation module for the revenue depending on the use case you have

    Module below calculates revenue before and after restructure. So you see what the revenue of the parents were before and after the restructure. Shows the revenue impact of the restructure to its parent lists

    • Region 1
      • Platform 1X
        • Branch B1 ⇒ if revenue period is between start period and end period then Revenue Flat.Revenue[LOOKUP: Mapping.Flat Branch] else 0
        • Branch B2 ⇒ same formula for all items. This should return revenue from Jan 2022 to Nov 22
      • Platform 1Y
        • Branch B2. This should return revenue from Dec 2022 to present
        • Branch B3

    Module below calculates revenue as restated for the the latest restructure

    • Region 1
      • Platform 1X
        • Branch B1 ⇒ if isblank(End Period) then Revenue Flat.Revenue[LOOKUP: Mapping.Flat Branch] else 0
        • Branch B2 ⇒ same formula for all items. This will be 0 for all periods
      • Platform 1Y
        • Branch B2 ⇒ This should return revenue from Jan 2022 to present

    Module below calculates what the revenue would have looked like if no restructure was done. You would need an input module as point of reference for which structure to look at.

    E.g. Input Module: Active Structure as of Date? ⇒ and you enter Oct 2022

    • Region 1
      • Platform 1X
        • Branch B1 ⇒ if isblank(End Period) then Revenue Flat.Revenue[LOOKUP: Mapping.Flat Branch] else 0
        • Branch B2 ⇒ same formula for all items. This should return revenue from Jan 2022 to present as B2 under 1X was active on Oct 2022
      • Platform 1Y
        • Branch B2 ⇒ This should return 0 as B2 was not active on Oct 2022

    Hope this gives you an idea to work on for the other scenarios but this should provide you a starting point with your design

Answers

  • E.L.
    E.L.
    Options

    Thank you very much for your help, very appreciated!

Categories