When a customer is moving from on-prem Hyperion to Oracle EPM Cloud, there are some important reporting considerations that must be made up front. I still see customers out there struggling to understand how FR, EPRCS, and Smart View fit into the Oracle EPM Cloud reporting mix, and what to expect when they make the move from on-prem to Cloud.

Tip #1: Reporting should be assessed up front

On countless projects throughout the years, I’ve seen many customers make the mistake of not including reporting at the beginning of an implementation or migration. Reporting becomes an afterthought, or customers don’t want to spend the money on consulting and exclude this altogether from the project.

I’m just going to say this as plainly as possible.

Not including reporting up front is a bad idea and will most likely cost you both time and money.

Reports are often the final, most tangible items that come out of Analytics, Planning, and Consolidations systems. Therefore, why wouldn’t you include them as important artifacts at the beginning of a project?

There are several negative repercussions of not including reporting up front. These are usually realized after the fact and several months into the project when there is no time to make u-turns. Here are some real-life consequences that I’ve heard from others or have witnessed personally:

• Application design changes
• Data integration additions or changes
• Calculation additions or changes
• Reporting interface additions or changes

This then leads to:

• Backpedaling
• Project change orders ($$$)
• Project flow disruption
• CHAOS

Some general reporting questions to start with:

• What are the important data elements for critical path reporting? Have these been captured in the new Oracle Cloud design and architecture?
• How many reporting elements are calculated manually in the report (vs. calculated in the source application)? Is it possible to take some development time to push these calculations to the source application?
• How many reports do you have? Do you really need all of them? What are the most important reports? This might be the perfect opportunity to go through a reports rationalization exercise to reduce the reporting migration effort.
• What are your reporting feature must haves? Do you know which Oracle Cloud products address those?
• What direction has your company always wanted to go with reporting? Does Oracle Cloud answer the “art of the possible”, now that every reporting tool has received a face lift?

By including reporting in the initial requirements and design, customers can ensure that the application design, data elements, data integrations, and interfaces meet their reporting needs before they start developing/migrating reports.

Tip #2: Choose the right reporting tool for your reporting needs

It can be a bit daunting to wade through the many Oracle reporting options that exist out there, both for Oracle EPM and BI Cloud. Here is a slide that I show in my EPRCS webcasts and to customers that helps to explain the lay of the land based on what type of reporting you’re trying to accomplish:

While there is some overlap between the technologies, there are reporting features that exist only in certain solutions. Therefore, it’s important to pick the right tool for the features you need. There isn’t a single Oracle reporting tool that perfectly handles all types of reporting functionality.

Tip #3: Understand the reporting ramifications of moving from Oracle on-prem to Cloud

Another important EPM Cloud reporting consideration is understanding how different the Oracle Cloud world can be for reporting. If you’re an on-prem Hyperion customer moving to Oracle Cloud, some things can work a lot differently.

In Hyperion on-prem:

• EAS is used for Essbase administration, can help with reporting troubleshooting, and talks to Planning Essbase cubes
• Smart View can use either the Essbase or Planning connection with Hyperion Planning
• FR on-prem talks to Planning, Essbase, and HFM from a single install environment
• Planning and HFM can have multiple applications within the same environment and (theoretically) unlimited cubes

However, in Oracle EPM/BI Cloud:

• There is no EAS (although there is a rebuild of it in the OAC Essbase web interface) and the EAS Cloud equivalent does not talk to Planning Cloud Essbase cubes
• Smart View only uses the Planning connection with Planning Cloud
• FR in Cloud (“WebFR”) only talks to the product and instance it’s attached to, not all products and instances
• Planning Cloud and FCCS can only have one application per pod, with a limited number of cubes each
• Cloud has cool, new reporting features that never existed in on-prem

^^ The above is far from an encompassing list, but you can start to see how different Oracle Cloud can be, based on your unique experiences on-prem.

Why is this important? As customers decide to make the move from Oracle on-prem to Cloud, the experience and architecture can change in significant ways, which then has implications on reporting. In addition, the admin, developer, and end user experiences will differ (which can be exciting in some ways, but may be disappointing in other ways). See the next tip about architectural impacts to reporting when moving to a multi-pod Cloud environment.

In addition, the reporting landscape has changed from Oracle on-prem to Cloud. There are new and exciting options in Cloud. Here is another slide that explains the Oracle on-prem reporting tool vs. Cloud equivalent option:

Tip #4: Static reporting in BI tools <> static reporting in EPM tools

Some customers who moved to OAC may be curious about the Published Reporting tool provided there, which is the Cloud version of BI Publisher. This reporting tool is the static reporting solution (grid-based reporting) provided within the BI tool suite. Please note that I am not an expert in this technology – my friend Wayne Van Sluys has helped my education in this area (and provided some of the more technical details below):

BI Published Reporting is like much of Oracle’s BI tools: better equipped for relational data than multi-dimensional data. For instance: it’s a bit challenging for BI to understand asymmetrical hierarchies, it’s more cumbersome to build with if you’re used to Oracle EPM reporting tools and Excel pivot tables, and does not provide the same options and user experience with member selections…just to name a few differences.

However, BI Published Reporting: does allow for email distribution, scheduling, and burst scheduling (similar to bursting in FR), has licensing options not based on named users, can be embedded into OAC BI dashboards, can be developed in MS Word RTF Template Builder, and has additional functionality that the Oracle EPM reporting stack does not offer (drop-downs for member selections, filtering on drop-downs, etc.).

Although the Oracle BI and EPM reporting stacks have many features in common, they are not equivalent.

Tip #5: Educate yourself on the reporting impacts of a multi-pod Oracle Cloud environment

Next, customers should understand the ramifications of moving to a multi-pod Oracle Cloud environment, especially if they’re coming from a single Planning or HFM application, or a hybrid reporting environment that includes both standalone Essbase cubes and an EPM application. Moving to a multi-pod Oracle Cloud environment has potential ramifications to: overall data flow, which reporting tools can be used, and reporting security, to name a few.

Some questions to ask:

• For reporting elements required for a single report, will all of these be sourced from a single Oracle EPM Cloud application? If not:
  • What Oracle EPM/BI reporting tool can bridge that gap? For instance, FR cannot talk to other Cloud instances so will you need to move to Smart View, EPRCS, or another reporting tool for this report?
  • If you move to EPRCS, did you account for that in your software licensing costs? Although EPRCS is a cost-effective reporting solution, you will potentially need licenses for every reporting user which can add up if you have hundreds of users. (Note that Oracle plans to push a version of EPRCS MR to EPM Cloud application solutions in the future. Does it make sense to wait for that to avoid paying for additional EPRCS licensing costs? Another blog post highlighting the differences between pure EPRCS MR and this new “lite” version will come out closer to the release. Note that there will be restrictions on what this “lite” version can do, which are also important to consider in your reporting strategy. Think of this MR “lite” version as more like FR, but with MR’s future-looking architecture as the foundation. #safeharbor)
  • If your reporting must be in FR, what new data integrations will need to be created to ensure that the data is all in one application to continue reporting out of FR? How does this impact the end user SLA for reporting data?
• If you have split out Workforce into a separate pod in Cloud, what is that impact to Workforce or consolidated reporting? See above point. Also, what security implications are there for Workforce reporting users out of the Workforce instance?
• If you have both OAC Essbase and an EPM Cloud application, FR does not talk to OAC and will not in the future. Therefore, if you previously used FR with Hyperion Essbase, will you need to move to Smart View or some other reporting tool like EPRCS MR?

Tip #6: Don’t discount the end user reporting experience

In order to maximize user adoption of your new Oracle Cloud technology, it’s important to think carefully about the end user experience. I’ve found that many customers want as little disruption as possible when moving to Oracle Cloud, so there are specific end-user considerations to think through.

Some general questions to ask yourself:

• If end users will be moving to a new reporting tool, what is the change management plan? What is the training plan?
• Oracle EPM Cloud potentially changes monthly. What is the on-going training plan for end users?
• Where will users report out of? Does this require multiple logins or accessing multiple areas within the same Cloud product? What features can you use in Oracle EPM Cloud to make this the best possible experience for end users?
• Will end users have to report in multiple tools temporarily to work around any current Cloud reporting limitations? What does the short-term and long-term reporting architecture look like for this? What is the change management plan for this change?
• What is the current reporting SLA for end users? How does that change with Oracle Cloud? In addition to potential new data integrations, you must also remember that Oracle EPM Cloud requires a one-hour maintenance window every night when users will not be able to access the environment. This applies to every instance of Oracle EPM Cloud (although you could sync up that maintenance window between all instances).

The Smart View End User Experience

In the case of Smart View, the experience is relatively the same. And, if you’re going to have a hybrid architecture (some Hyperion on-prem and some Cloud), luckily Smart View is backwards compatible so you can have everyone on the same version.

However, here are some gotchas that you need to plan for when moving to Smart View Cloud:

• If Hyperion Planning users are currently using the Essbase Smart View connection on-prem, they will have to move over to the Planning connection in Cloud.  There are some important feature gaps between the two with no workarounds.
• Many of the ad hoc reports that were previously created in Hyperion on-prem will have to be rebuilt and tested in Cloud
• If you’re using the HSGetValue function, the connection string will have to be edited to point to Cloud. Luckily, most of this can be handled through a find/replace.
• New private connections for Cloud! But note that there is a way to standardize and centralize these and push out a single list to all users.
• Smart View gets updated at least once a year and you really need to stay on the latest version in order to take advantage of new Cloud features. This is especially important for OAC Essbase users. What will be the process to push out Smart View updates to all end users?

The EPRCS End User Experience

Let’s say that you’re moving end users from on-prem or Cloud FR to EPRCS MR. The end user experience is very similar between both tools, but it’s not the same. For instance, you can access FR reports from Planning Cloud task lists, but you currently cannot access MR reports this way (enhancement coming). Set yourself up for success by creating a change management plan. Also, do your research to understand what the differences are between the two technologies so you can create a robust training plan.

~~~~~

As you can see, there are a number of considerations when moving from Oracle on-prem reporting to Cloud. Good luck on your journey!