Mission NOT impossible: Org hierarchy redesign for production deployed models

Tiffany.Rice · April 18

Author: Tiffany Rice, Certified Master Anaplanner and Tech Lead at Prudential.

In a dynamic and ever changing business environment, it is inevitable that business requirements for forecasting and planning shift over time. Particularly in times of economic volatility we see companies leaning into transformation projects to realign their business practices with the demands of the market. One such project may come in the form of an organization redesign to transform decision-making and financial management.

For mature Connected Planning ecosystems, these types of shifts can feel seismic when adding new levels to shared/common list structures across multiple production deployed models. Continue reading to learn how with diligence and planning, you can minimize the magnitude of the quake.

Learn the business objectives

Seek first to understand the why and vision for the post-transformation process.

Identify new levels to be used and determine if that drives any change in the current modeling process.
Consider existing production data and align with business partners on expectations for mapping and data retention. If data need to be retained, that will introduce complexity which should be cared for in the implementation.
Understand the timeline to implement, contemplate that a “downtime” period may be needed where the models are offline.

Define where the new levels will be inserted within the list hierarchy

The impulse may be to add at the lowest level, which may or may not be optimal. You should contemplate how the definitions for the existing level translate to the new and how those levels are used in the process.

If modeling is heavily based around a specific summary level, that will factor into the number of formulaic updates should that list definition change.
When list subsets are driven by the hierarchy, understand the appropriate level(s) needed to define that subset in the future.

Contemplate hierarchy exceptions

Transformation can take time and all business unit may not be prepared to realign on the new structure within the necessary timeframe. In a perfect world you would wait until all the pieces in place but in the real world progress may need to be made incrementally.

Stay closely aligned with database teams who may be managing the hierarchy updates.
Consider how the exceptions will be managed, the points of commonality, and the mechanism you will use to bridge the legacy structures to the new.
If needed, a data hub model can help to facilitate the ingestion of differing data sources and stage the consolidated hierarchy based on the logic for the exception management process.

Prepare and align the teams

Review models and apps to understand potential impacts and create an action plan which notates the key decision points and the sequential tasks to be completed. This should be a collaborative process with primary stakeholders to ensure everyone understands the work to be accomplished and there is consensus in the approach.

Export the module line items to assess and track formulas that may need to be addressed as part of the implementation.
- If reparenting existing lists, be on the look out for PARENT() functions and the use of ratio summary methods. You will need to temporarily remove these formulas while making the list updates.
- Consider calculations that inherit values from a higher level, additional steps may be needed for these calculations to trickle to the desired output level.
Consider the UX implications and outline the pages that will require modifications. Look out for usage of show/hide levels and level based filtering as these may need to be updated.
Determine approach for data mapping (if applicable), import actions may be needed to manage the production data changes.
Appreciate the model to model connections within your ecosystem, saved views and import actions may need to be reviewed and updated to ensure that source and target are aligned.
Notate scheduled integrations that may need to be paused during implementation.
Remember that adding new levels may impact the model size and additional workspace may be needed. This is also a great time to revisit sparsity optimization in your model to mitigate any size increase.
If using Application Lifecycle Management (ALM) contemplate the sequence of steps and series of revision tags that may be needed. Consider your data retention needs here as the order of events may matter to ensure that production data is maintained.
Look for ways to get a jump start on the implementation, there may be pre-work items you can do in advance of the production cutover.
Devise a testing plan. Work with your business partners to make sure everyone is clear on the definition of success and validation parameters. Comparing to previous values may not work if there are expected data and/or process changes.

Execute your model revision action plan flawlessly!

This is the fun part, when all your preparation pays off! Work diligently and stay connected with your stakeholders to track progress and mitigate any potential roadblocks.

Archived copies of production models can be used for recovery if needed.
When assigning parent hierarchy to the new lists, work bottom to top. As in the circle of life, the parents must be born before they can have their own children.
Lookout for the "Level Common Mismatch" error message, this may mean a line time formula or summary method needs to be addressed before changing the list’s parent.
Cleanliness is next to godliness — ensure names and identifiers are updated consistently throughout including in notes. Nothing is more confusing than a line item named “L3” that is formatted as L4 list.
Changing list or line item names may impact module to module import action mappings. Review each model to model import to ensure configuration is correct and continues to work as intended.
When creating new lists, modules, or actions ensure user model role access is updated.
Renaming a saved view can impact model to model imports, edit the “Import Data Source” in the target model to select the new saved view name.
If modifying an action to have a different import data source, revisit the import action configuration. Source to target mapping may need to be redefined.

Conclusion

While changing core model hierarchies may be a daunting thought, these exercises are a natural part of doing business and models can be reconfigured to support evolving requirements. While there may be challenges along the way, this can be a very rewarding experience and provide the opportunity to become reacquainted with your full connected planning ecosystems.