Oracle’s release of the 184.108.40.206.340 PSU of DRM coupled with the 220.127.116.11.200 PSU of FDMEE have brought exciting new functionality. As EPM environments get more complex with multiple applications, multiple ERPs, cloud hosted solutions, and governance requirements – its important for these tools to evolve to assist in day to day operations.
I’ve illustrated a few examples of solutions with DRM and FDMEE – but first a little context:
- In this example, Master Data refers to the hierarchies / properties / metadata within the EPM ecosystem that define the business – sourced from an ERP system and then may be also within the EPM application for analytics. This will be noted by a yellow arrow.
- True Data refers to the numbers, statistics, and dollars that are being described by the master data/metadata. In the diagrams, this will be an orange arrow.
- Mappings are the rules to map data from one value to another, such as mapping numerous GL accounts to one, or specific cost centers to a portion of the P&L. In the diagrams, this will be a green arrow.
Before we jump into the fun new stuff, I’ll go through some of the legacy solutions to loading Master Data, True Data, and Mappings leveraging tools in the EPM space. Then I’ll go into the new features, how they work together, and *hopefully* future functionality.
FDMEE Data Load, Manual Metadata Updates
In an environment without DRM, there are a couple options to manage both metadata and data to keep them in sync. First, would be a manual metadata maintenance approach by an administrator into EPMA or into a classic application. Depending on the number of monthly changes or number of applications to manage, the administrator might have quite a bit of manual work to do (and a higher possibility of problems due to fat-fingering or inconsistencies in the hierarchies).
After configuration, true data flows through from EBS to FDMEE (with help from ODI) to be mapped, and then loaded to the EPM application via out-of-the-box functionality.
FDMEE Metadata & Data Load from Source
Another configuration for a “without DRM” scenario is only available currently for those with Oracle EBS, Fusion, and PeopleSoft Enterprise Financial Management. For Metadata, leverage FDMEE’s “metadata rules” to load hierarchies used within the ERP into FDMEE, which then can be loaded into downstream EPM applications. The pros here are that it is OOTB functionality after configuration, no custom code or jobs are required. However, the caveat is that the hierarchies/metadata that is sourced from FDMEE can have little to no modification – only prefixing and suffixing is allowed. That said, any member names or descriptions that violate the downstream application’s limitations are going to cause problems. View limitations for Planning & HFM on my blog here.
For True data, the same configuration applies for FDMEE. FDMEE adapters pull data from the source into FDMEE to be mapped, and then load to the application (Extract, Transform, Load).
DRM Metadata Management & FDMEE Data Load (Pre-Patch)
Still pre-.200 and .340 patches, DRM has been a fantastic alternative to load metadata to EPM applications. DRM can be updated with the MCOA using a developed export/import process (or source the MCOA and push also to the ERP). From there, the Master Data can be validated, cleansed, and enriched within DRM to prepare for loading into the EPM application.
Additional batch/developed export/import jobs will also have to be created on this side, in that there are no OOTB adapters to load directly to classic EPM applications. This has historically been solved with DRM batch scripting and using Outline Load Utility, load rules, or ODI Knowledge Modules.
DRM has EPMA upload templates to assist in creating OOTB exports in EPMA format, and the exports can then be automated with the DRM Batch Client and the EPMA Batch Client. Note, this is only available for EPMA applications, which can be HFM, HTP, Hyperion Planning, and Essbase.
Custom-Integration DRM Mapping Management (pre patch)
Historically, DRM has been leveraged to map data from FDMEE, but required additional configuration and scripting to accomplish – sometimes leveraging a separate data repository to push the mappings into the FDMEE tables. This approach, even though it requires configuration, does help master the mappings within DRM and shows the history and changes to mappings over time – which can come in handy during audits.
FDMEE & DRM Integrated Hierarchy Management (new patches)
In the .200 and .340 patches, new functionality has been released to leverage the OOTB adapters to source systems from FDMEE to load hierarchies into DRM. Not only does this cut down on the amount of ‘customized’ processes to import from source system to DRM, but it then also trumps the source > FDMEE > application ‘metadata rules’ route by allowing the data to be consumed, cleaned, validated, and enriched in DRM before heading its way downstream to the EPM applications.
Note, only 2 source systems are currently supported for these features: Oracle EBS and Oracle Fusion.
Integrated DRM Mapping Management for FDMEE (new patches)
Also with the newly released patches, integration between DRM and FDMEE for managing mappings comes OOTB. In the past, mappings have been managed in DRM and then custom jobs had been built to update the FDMEE mapping tables from DRM exports.
Oracle’s now created DRM templates that create exports and allow for configuration of explicit mappings to be housed and managed within DRM, and then exported to load directly into FDMEE. No custom processes needed. Remember, however, that this is only for explicit mappings – no like, between, in, or multi-dim.
This is also only available for Oracle EBS and Oracle Fusion.
All In: DRM & FDMEE New Features for Metadata & Data Loads
With the source connection to FDMEE leveraged to load DRM with hierarchies, and the OOTB integration of DRM to FDMEE for mapping tables; both tools are playing on their strengths to facilitate clean metadata and mapping processes for both products. It also cuts out some of the customization that was required in other implementations.
Potential Future of FDMEE and DRM
The .200 and .340 patch have created great new functionality in integrations for EPM… but what’s coming next? Although there are no confirmations from Oracle, My assumption is that the next step would be creating integrations to push or pull metadata from DRM back into FDMEE using metadata rules. The metadata could then be loaded into the EPM application using the the current load functionality from the “FDMEE Metadata & Data Load from Source” option. This would allow the ERP source hierarchies to be cleansed and validated, and reduce even further the ‘customized’ integrations and batch scripting we see in implementation today.
Remember this is just HB’s assumption, this isn’t official from Oracle!
As always in EPM, there is more than one solution to a problem. What’s the best solution for you? Hopefully laying out this options can help you decide whats best for your organization.
What new features or functionalities are you hoping for with the future of DRM and FDMEE integration? Send me a note to firstname.lastname@example.org or tweet me at @hyperionbarbie with your ideas!