Recent Posts


So…What is FDMEE? And Why Should I Care?
Posted on March 19, 2014
Author: Tom Blakeley, Performance Architects

Several months ago Oracle released a product called Oracle Hyperion Financial Data Quality Management Enterprise Edition (FDMEE) in Version of EPM– hallmarked as the more athletic, and handsome, brother of the old standby Oracle Hyperion Financial Data Quality Management (FDM). After working through a couple implementations of the tool I’ve come up with a short list of reasons why you should care about this product, and what it means for the EPM space.

Let’s start by talking about what FDMEE is, exactly. FDMEE is a data integration tool that helps transform data and metadata from a variety of sources into a consumable format for Hyperion products like HFM, Planning and Essbase. It allows you to apply mapping logic though a friendly user interface, and manage the data load process via a web console in Hyperion Workspace. For those of you who are thinking, “Tom, that sounds a lot like FDM,” you’re correct!  It does sound like FDM. What differentiates FDMEE are a few changes that make it a superior option to what FDM can do on its own – and this is why you should care.

First and foremost, FDMEE leverages the 64-bit architecture seen in products like ERP Integrator (ERPi), another Hyperion product that used to be paired with FDM to get data out of particular source systems such as EBS and PeopleSoft. This move to a 64-bit architecture has brought noted stability and scalability when it comes to implementing the tool; I haven’t been able to break the tool by throwing “too much” data at it, or running too many processes in parallel. Since FDMEE is Java-based as well, we’re able to tune the application to improve things even more.

Second, FDMEE integrates directly with source systems and target applications. When you need to source data from PeopleSoft and load it to Hyperion Planning, there isn’t a two-step process to jump from ERPi to FDM – instead we go straight from one to the other. This reduces complexity and removes an integration point – helping to both shorten development time, and also give folks like me the opportunity to add value to Finance users with a bit more free time. FDMEE interfaces directly with EBS, JD Edwards, SAP, flat files, and the open interface table – a custom source system that lets FDMEE receive data from a data warehouse, an ODS, or other custom sources.

Third, I’ve found FDMEE to be friendlier for Finance users than FDM and ERPi – and this is a huge plus. The tool now sits in Hyperion Workspace, so users don’t have to navigate between ERPi in Workspace and FDM on a separate webpage when making changes or running a job. The tool also has a built in scheduling process to run automation routines that is managed through the tool’s web interface, making it simple for a user to schedule a reload job.

Fourth, FDMEE lets you source metadata from a source system and load it into target applications. This capability exists in ERPi, but for those folks who only have FDM this is a huge step in a new direction. Now, reporting and planning systems can be paired with metadata sourced on a regular basis from a general ledger; adding new accounts, entities, departments, etc. on the fly. This reduces maintenance for the administrators, and when paired with creative mappings, can ensure that data always finds its way into the Hyperion world.

Finally, users can now start in a retrieve form, a web form, or a report and drill back to FDMEE to see source records, mapping logic and process times. From there, users can continue on and drill all the way back into a source system, such as EBS, to review individual transactions and see the detail. This is a deadly combination.  When paired with mappings that bring data to a summary level for reporting, users can quickly drill back and analyze data – reducing the need for all the detail existing in Hyperion.

For example, we could map all GL travel expense accounts to a member called “Travel Expense” in Hyperion, creating a summary number for reporting. If the need arises to see detail, users can quickly drill back into FDMEE to view the balance on every source Travel Expense account, and if interested, continue on into the ledger to review all the transactions that make up a single chart-string balance. In the old world, this was a clunky process that took several steps, and FDMEE has reduced the complexity making life easier.

I could continue on for several pages about everything else I’ve learned, but instead I’ll wrap things up and shamelessly plug my upcoming presentation at Collaborate on FDMEE on April 8th, 2014 from 3-4 PM PST entitled “What is FDMEE? And Why Should I Care?” (Session ID: 14801; a full list of Performance Architects’ eight sessions and booth information is available here). In short, FDMEE certainly is the natural progression of FDM and ERPi, bringing together the best of both worlds, and adding a little extra. For folks considering integrating source systems with Hyperion, FDMEE is a serious contender.

More to come in future blogs, but for now, have a good one.

Author: Tom Blakeley, Performance Architects


© Performance Architects, Inc. and Performance Architects Blog, 2006 - present. Unauthorized use and/or duplication of this material without express and written permission from this blog's author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to Performance Architects, Inc. and Performance Architects Blog with appropriate and specific direction to the original content.

Leave a Reply

Your email address will not be published. Required fields are marked *