Contact us FR

How Oracle Cloud EPCM Changes Our Approach to Rule Maintenance

Published November 28 2022
Back to insights

Our last blog post delved into how Oracle Cloud Enterprise Profitability and Cost Management (EPCM) changes our approach to Data Integration. Now it’s time for us to focus on the core of our profitability applications; how we create and manage rules within EPCM and how it differs from Oracle Cloud PCM.

Oracle EPCM rule maintenance and execution

What Changes?

The most significant changes between Oracle Cloud PCM and Oracle Cloud EPCM concerning rules creation and maintenance can be summarized as follows:

Oracle Cloud PCM Oracle Cloud Enterprise PCM
  • POV = Model Data + Data
  • POV = Data
  • Model = Rule Sets and Rules
  • Rule Sets and Rules maintained through either Rules UI or Design UI
  • Rules are created and maintained within a model that is then executed against a POV
  • Models are maintained through the Designer UI only
  • Models can be compared to identify variances
  • Rule Numbers are associated with Rule members in Essbase
  • Rules members generated in Essbase are named as they are created in PCM (no rule numbers!)
  • Rule dimension cannot be altered or changed
  • Rule dimensions can accommodate Attributes, EDAs, and alternative hierarchies

Models vs. POVs:

The first line above will be the most interesting for those with experience implementing Oracle Cloud PCM. Since Hyperion Management Ledger, the concept of the Point of View (POV) has been fundamental and is the center point of all our rule and data management within the applications. When we create and maintain Rules in PCM, we always do so within a POV, which can then be copied to new POVs as they are added. However, this approach had several drawbacks:

  1. Until relatively recently, rules had to be copied from an existing POV to the new POV to execute the calculations. This wasn’t too bad for the Actual scenario as we tend to execute one POV at a time, but for Budget and Plan scenarios, which can have many POVs in a single cycle, this added unnecessary tasks and time to the process.
  2. Clients who have Budget and Plan scenarios in their PCM application can have hundreds, and sometimes thousands, of POVs in their application. This can create performance issues as the same rule set and rules may be duplicated in the back-end tables hundreds or thousands of times.
  3. It increased integration complexity when moving data between the calculation and reporting applications. To ensure that the Rule Balancing Report works correctly, and the users have access to a desired POV’s Program documentation, the Model data (Rule Sets and Rules) must be migrated to the Reporting application along with the data.

Oracle addressed some of these drawbacks by introducing the ability to select a POV as the “Model POV” and another as the “Data POV”:

Oracle EPCM Data POV and Model POV

The above approach solved the drawback of copying the POV multiple times in the calculation application (it is still necessary to do so in the Reporting application) and introduced the possibility of parallel execution of POVs. Still, it came down to the implementation partner’s experience implementing an approach that made sense for the client.

In EPCM, Oracle has changed the approach to POV management by introducing separate concepts for managing rules (Model) and executing rules against a data POV. Here is a rundown of what creating a model, managing rules, and executing calculations looks like in EPCM:

  1. We start by defining a “Model” in the Models UI. We can create as many models as we like and differentiate them, for example, by Scenario (e.g., a model for Budget vs. Actual).

    Oracle EPCM Models User Interface screenshot
  2. Next, we create or maintain the Rule Sets and Rules within a given model in the “Designer” UI. This UI is almost identical to the “Designer” UI in Oracle Cloud PCM and should be familiar to those who have worked on it.

    Oracle EPCM Designer User Interface screenshot
  3. Finally, we execute our calculations by going to the “Calculation Control” UI, selecting the appropriate Data POV(s) and clicking the “Calculate Model” button, selecting the Model from the drop-down menu, and clicking the “Run” button.

Oracle EPCM Calculation Control User Interface screenshot

The above approach is significantly superior to the old POV approach in Oracle PCM as it not only standardizes our process to Rule creation and maintenance, cuts out unnecessary terminology and complexity but also introduces the possibility of future enhancements, such as security being applied at the Model level.

Essbase Database Rule Names:

The other HUGE change for us, which we spoke about in an earlier blog, is that the rule names, as deployed to the Essbase database, will be consistent with how they are named in the Designer UI. This is a significant change as Oracle Cloud PCM would automatically associate a Rule defined in the UI with an existing Rule number (R0001) in the Essbase database outline.

This approach had advantages as it ensured proper naming conventions in the Essbase database outline and applied a consistent approach across all clients. Still, it also had a significant drawback in the inability to know which rule was associated with a rule number without looking at the Program Documentation or Rule Balancing Report.

In EPCM, the Rule name as defined in the UI is the Rule name as defined in the Essbase database outline. This leads to greater transparency, traceability, and troubleshooting capabilities but does mean that clients must be more aware of how their rules are named in the application.

What’s the Impact on How We Implement?

If your implementation partner followed leading practices, the change to how we create and maintain Rule Sets and Rules in EPCM is not fundamentally different from that of Oracle Cloud PCM. Still, it enforces leading practices and ensures that all clients, regardless of their implementors’ skill, have a consistent experience and introduces some key benefits:

  1. Models are centrally maintained within the Model UI, reducing maintenance effort.
  2. Increase application performance due to not having hundreds or thousands of unnecessary POVs with model data.
  3. Enhanced traceability and analytics due to the alignment of Rule names defined in the UI and deployed to the Essbase database.
  4. The complexity of automation requirements decreases when moving required artifacts from the calculation cube to the reporting cube.

Conclusion

In EPCM, Oracle has worked diligently to help clients have an efficient and consistent approach to Model Management regardless of the level of skill of the implementation partner. They have analyzed what the leading practices for Model Management were deployed at clients and institutionalized them in the tool.

In the next blog, we will detail some of the new functionality available in EPCM when we look at executing our models against POVs and how it changes our approach to Rule Execution in our allocation solutions.

For comments, questions, or suggestions for future topics, please reach out to us at infosolutions@alithya.com.  Visit our blog regularly for new posts about Cloud updates and other Oracle Cloud Services such as Planning and Budgeting, Financial Consolidation, Account Reconciliation, and Enterprise Data Management.  Follow Alithya on social media for the latest information about EPM, ERP, and Analytics solutions to meet your business needs.