Given our focus on masterdata and integration we get to understand how a wide range of clients solve the problem of transforming data between their general ledger, consolidation, reporting and forecasting systems. These domains have very different business requirements which are often reflected in different structures and levels of detail. Inevitably some form of mapping process is required. So far so good; there are many solutions to govern the mapping between financial applications. If you use the Oracle Hyperion product for your EPM (Enterprise Performance Management) layer, there is a high chance you will be using Oracle Hyperion Financial Data Quality Management (FDM) for an element of this mapping.
FDM is a great tool when used correctly. It acts as a gate keeper to other Hyperion applications ensuring that all data is mapped and validated according to pre-defined business rules or “validations”. This audit trail is invaluable and needs to be retained at all costs.
There are, however, two areas of FDM functionality where this audit trail can be jeopardised. Firstly, FDM contains the ability to run “import” scripts. These scripts can modify the content and structure of the initial import files. If they are not used correctly they can create a “disconnect” between the source application and FDM. Changes of this nature can become very difficult to trace and thereby undermine the comprehensive audit trail provided by FDM. Secondly, FDM also provides the flexibility to create new financial totals based on rules contained in the application. These rules, or “Logic Groups”, can be difficult to understand and are not traced in the audit trail. Whilst powerful, they should be used with caution and not without a full understanding of their limitations.
There is one final area of FDM that needs careful consideration. It is imperative that you perform regular housekeeping on your mapping tables. A key advantage of FDM is the flexibility offered by the mapping tables. Your approach to mapping will change over time and it is very important that you delete mappings that are no longer used. If you do not, your mapping approach will become increasingly difficult to understand over time.
A final word: when implementing any form of ETL (Extract Transfer Load) process it is imperative that your implementation partner demonstrates that the audit trail is complete and easy to use. We suggest that your test strategy always includes tests that trace values from target application to the original source. Until next time….