How to build a Polaris reporting model in less than two weeks

Hanwen

Author: Hanwen Chen is a Certified Master Anaplanner and Professional Services Sr. Manager at Anaplan.

Over the past nine months, I have been involved in multiple Classic-to-Polaris conversion projects. One consistent requirement across these engagements is the need for scalable reporting solutions that support multiple natural dimensionalities. Customers are increasingly looking to Polaris to enable this type of reporting capability at scale.

This article demonstrates how you can quickly build a Polaris reporting model in less than two weeks by leveraging existing data from Data Hubs and Classic models. By reusing structured data and applying a streamlined setup approach, teams can rapidly enable scalable, multi-dimensional reporting in Polaris without rebuilding the entire model from scratch.

Common patterns in Classic models

From my experience, when reviewing existing Classic models that were not originally designed for reporting with multiple natural dimensions, two common patterns typically emerge:

1. Flat data structures with additional attributes.
   Data is often stored in a flat structure with additional attributes that describe the elements. It may also include dimensions such as Time. The flat structure typically serves as the data key and may be a concatenated list of multiple dimensions, such as project–department–account. Additional attributes describe other aspects of the dimension, for example, the region associated with a department or the category associated with a project.
2. Incomplete or inconsistent dimension structures in Data Hub.
   The Data Hub often lacks well-defined hierarchies or dimension structures that can support reporting directly. Without these, it becomes difficult to enable flexible multi-dimensional reporting.
   

If you observe these patterns in your Classic models, the following approach can help you implement a Polaris reporting model efficiently.

Solution configuration

1. Report dimensions & data sources.
   Start by identifying the dimensions required for reporting and the sources that provide the necessary data elements. For example, a report might include Time, Version, Cost Center, Product, and Region as key dimensions. These dimensions determine the structure of the reporting model.
   Next, determine which systems, models, or module views will provide these dimension structures and data elements. Typically, this includes the Data Hub and existing Classic planning models. Clearly identifying dimensions and sources upfront ensures a smooth and streamlined setup process.
2. Data Hub configuration.
   The Data Hub serves as the central repository for master data and actuals. To prepare the Data Hub for Polaris reporting:
   
   1. Configure dimension structures: Ensure flat lists exist to support the required reporting dimensionalities.
      
   2. Create output views: Build export views that structure the data for loading into Polaris. Well-designed export views minimize transformation work, simplify integration, and improve data load performance.
      The Data Hub is critical because it standardizes dimensional structures and reduces complexity in the Polaris reporting model.
3. Classic model configuration
   Classic planning models provide plan and forecast version data. Before integrating with Polaris:
   
   1. Prepare plan/forecast data: Ensure version data is structured and ready for export.
      
   2. Validate data elements: Confirm that all dimensions required for reporting are included in the Classic model and align with the Data Hub structures.
      Proper preparation ensures the Polaris reporting model can consume version data efficiently without extensive transformations.
4. Polaris reporting model setup.
   Once the Data Hub and Classic model are ready, configure the Polaris reporting model:
   1. Set up flat lists and hierarchical structures.
      Create the reporting dimensions required in Polaris.
   2. Build modules to receive actual and version data.
      Design modules to store imported data from the Data Hub (actuals) and Classic models (plan/forecast versions).
   3. Create processes to populate dimension data from the Data Hub.
      Set up imports and processes to load dimension structures into Polaris.
   4. Create processes to load actual data from the Data Hub.
      Import actuals prepared in the Data Hub export views.
   5. Create processes to load version data from the Classic models.
      Import plan and forecast versions from Classic models.
   6. Set up bulk upload processes.
      Enable bulk upload processes to load multiple versions of data as needed.
   7. Configure mapping and validation processes.
      Set up mapping logic and validation modules and pages to ensure correct dimensional mapping and data integrity.
   8. Create reporting modules and report pages.
      Include multi-dimensional reports, variance reporting (e.g., Current Forecast vs. Plan), and other analytical views to provide meaningful insights from the data.
      

Final thoughts

By leveraging existing Data Hubs and Classic models, teams can significantly accelerate the implementation of a Polaris reporting model. Instead of rebuilding data structures from scratch, this approach focuses on reusing structured data and aligning it with Polaris’ scalable dimensional architecture.

With the right setup, it is entirely feasible to stand up a functional and production-ready Polaris reporting model in less than two weeks.

Additional tips and tricks in each configuration can further streamline building your Polaris reporting model. In a follow-up article, I will share these tips and tricks to help teams implement more efficiently.

Questions? Leave a comment!

……………

Other articles by Hanwen:

• The beauty of simplicity: any level of selection in a hierarchy
• The power of the ‘No’ version approach in Anaplan
• Data distribution design from Data Hub to multiple spoke production models

abhi4246

@Hanwen With this approach,how do we plan to manage security across both the Classic and Reporting models?

Also, from a real-time refresh perspective, would users need to make changes in the Classic model and then run an action in the Reporting model to reflect the latest data?

Trying to better understand how we plan to address these additional dependencies, compared to building the solution directly in Polaris instead of following the DataHub/Classic-to-Reporting model approach.