How to leverage user access: Anaplan (Planning) and Business Intelligence (Reporting)

NY User Group Members,

One of the more common questions we get as a Customer Success team is how to optimize the use the Anaplan platform with a Business Intelligence platform (or in some cases, a simple tool). This question comes in many forms – e.g.:

  • Why use Anaplan when we already have X visualization tool?
  • How do I communicate the difference between Anaplan and our BI software to our business leaders?
  • When should we use Anaplan versus our analytics platform?
  • Who should have access to Anaplan and who should access our BI tool? Or, should everyone access both?

First, I want to clarify what may already be clear to those reading: a planning process serves a much different purpose than a reporting function. Second, given statement #1, it’s helpful to think of planning (Anaplan) and reporting (your chosen BI tool) as extremely complementary. The thoughtful use of one gets you much more value out of the other.

The answer we give when asked any of the questions above is: It depends. The who, whyhowwhen to leverage each platform in your tech stack will depend on each customer’s state and priorities. 

That said, there are some initial elements to consider when considering the access strategy to your Anaplan and Business Intelligence platforms, some of which I’ve listed here. These are by no means exhaustive, but it serves as a diving board in aligning your teams. You could very well have elements of your own (feel free to add them here!).

In no specific order:

  1. Visuals and User Experience

    Anaplan's UI is better than ever before, especially given the continued investment in the (no-longer-New) UX. However, there may be particular visualizations that a particular BI tool offers that Anaplan does not yet offer. It would be valuable to consider what elements of visualization are must-haves for particular users / user groups. It is also essential to note that the keys to reporting with powerful data visualizations have more to do with being purpose-driven, accurate, and accessible. Substance over style, always.

  2. Granularity of Data for Planning vs. Reporting

    Anaplan customers often plan at a higher level of granularity than needed for historical reporting use cases. If there is additional granularity, attribution, or other data that has no relevance for Planning, you may be better suited to reporting that through your existing BI tool. The best Planning models focus entirely on an efficient, accountable, and actionable user experience without unnecessary complexity.

  3. Data Sources

    The optimal solution here truly depends on the data sources in question. If most of what the viewer needs to see does not come from Anaplan, it may make sense to have them consume the information from the BI tool (if it’s available there). If much of the analysis is being done in Anaplan, having dashboards update automatically in real-time, is a huge value. This is huge not just for the end-users; it also reduces the administrative costs of managing the reports.

  4. Modeling capabilities and Workflow

    Do the users need the ability to punch numbers and see results in real-time? Some BI tools allow for simple calculations, but anything beyond simple can require complex scripting and is really better suited in Anaplan because the results are quick and can easily be curated and/or adjusted using our natural language calculation syntax.

  5. Data Integrity Risks and Latency

    Any time you introduce an additional data pass off (e.g., from Anaplan to BI), you introduce risks for the data to be out of sync. Additionally, troubleshooting takes longer if you need to isolate whether data discrepancies are in Anaplan vs. BI vs. Database, etc. Really think through the requirements of your use case for this one. For example, you may need to be able to iterate through Planning changes and see the impact of various reports in real-time to make the optimal planning decision. You may also need to compare the plan against other data sources, but you only need to compare the final output of the plan, not each iteration. In that case, using Anaplan for iterating through the changes and then sending the final output to a BI tool may make sense. You get the best of both worlds while minimizing latency and data integrity risks.

  6. Workflow and Security

    Does the use case require approvals and/or specific security requirements? Most BI tools lack task-oriented and approve/reject workflows, so Anaplan is well-positioned if this is a need. Also, does security need to be duplicated? Anaplan has a robust, role-based security model to ensure that users only see the data they are entitled to see. Conversely, if you have a pervasive security model in your current BI solution, it may be easier to leverage that for your reporting needs.

  7. Ownership & Costs

    There will always be an incremental cost of managing an additional system (licenses, admin labor costs, time, etc.)

    It is also important to discuss who would own the technology that supports process. For example, if your Finance team does not want to give up control of the E2E process and rely on IT, they may consider a system(s) that can be managed by the business admins alone. Say Finance wants to update something inside their end-user view: if someone from IT owns the data warehouse, they are then relying on one more person/technology rather than being able to nimble with a technology they have.

  8. User Behavior and Change Management

    Ultimately, any design decisions should be made with the end-user in mind. How can we ensure that our users get access to the right information, as quickly as possible, with as little confusion as possible? This can be achieved by minimizing the # of platforms or systems that users interact with, along with the # of systems they need to be trained on using. This aspect may override any of the other considerations above. For example, you may choose to pull another data source into Anaplan, only needed for Reporting, because there are 1,000 Anaplan users that are already trained on how to access, interact, and use Anaplan. The change management aspect cannot be understated, so make sure to give it the requisite weight in your design considerations.


You can find more information about Anaplan’s UX, including access to micro-lessons for developing and adopting the UX, on the Anaplan Community at https://community.anaplan.com/t5/UX/ct-p/platformux.

 

Comments

  • @jeanlouise.manalo 

    Great post and awesome top 8 reasons. New UX seems to have that Power BI upgrade path, where each month we get something new. Honestly, the only time I need to leave Anaplan for supplementary BI purposes is when I need iterate on data, maybe some statistical modeling, or when there's really no other way to create that "C" level report. Plus, don't forget the Excel and PowerPoint Extensions. Lots of options. Anyway, great post. 

  • Thanks @JaredDolich! Great callout about the extension options, and I feel the same way about the capabilities of the New UX (though, yes, for certain C-level or investor reporting, some BI visualizations do pack a punch).

    I have to h/t @yelena_keselman and @patrick_caruso. Their extensive experience fielding questions like this one was key in distilling the bullet points. Our goal was to have a compass that can point our customers to the direction they want to go, with a spirit of collaboration. 

Categories