By: Naren Truelove, Vice President, Enterprise Data Management, AST
Many experts will agree that traditional Master Data Management (MDM) doesn’t address the challenges of synchronizing application level data and settings across numerous ERP modules and other systems. Those familiar with MDM deployments will observe that the slow degradation of data definitions and misalignment across applications rarely creates major issues quickly; it is more like death by a thousand cuts. Also, in the age of cloud these needs often quickly transcend ERP and must address solutions from multiple vendors, not just data across modules in an ERP system.
Oracle Cloud Enterprise Data Management (EDM), which has matured significantly in the two and a half years since its inception. There are major benefits that can be achieved very quickly using the solution. For example, financial reporting structures can be easily harmonized by installing and configuring out-of-the-box connectors to Oracle Cloud ERP Financials, as well as to the financial consolidation, close, and planning capabilities in Oracle Cloud EPM.
General ledger reporting segments and hierarchies in Oracle Cloud ERP can be synchronized with reporting dimensions in consolidation and planning in Oracle Cloud EPM. To the uninitiated, understanding the similarities and differences between these data structures is daunting, and that was before they could be governed in a single tool. Add in:
and the combination of insight and control that can be instituted in a matter of weeks makes it truly useful.
When applications are registered in Oracle Cloud EDM using prebuilt adapters, metadata is generated automatically for all data elements to be mastered. In the screenshot above, the applications that have been registered in EDM are shown. The registration definitions include all the segment types, hierarchies, and reporting dimensions being mastered for those applications, as well as the connection details for those cloud services.
When viewing an Application, all the nodes being mastered can be seen. In the example above, the general ledger (GL) account segments from the Oracle Financials GL are viewed in list format. The properties to the right include the account description, Boolean flags for allow budgeting/posting/etc., effective dates, and other metadata required by the general ledger in Oracle Cloud ERP.
While it’s useful to see all the metadata being mastered for an application, where Oracle Cloud EDM really stands out is when domain-specific views are created. In the example above, a custom view shows all the uses of GL accounts across these applications. The first tab shows the GL account structure as a hierarchy, rather than a list view. The properties for each account remain the same, the definitions required by the Oracle Cloud ERP GL.
The second tab in the account maintenance view shows the accounts dimension in financial consolidation and close (labelled FCCS). The same account that was highlighted on the prior tab is highlighted here, and at a glance one can quickly tell that the FCCS account dimension looks significantly different from the GL account hierarchy. It contains many prebuilt members, but all the leaf level GL segments are required, and many of the parent members are reused as well. The properties being managed are also quite different, and reflect the metadata used to manage and tune the performance of the financial consolidation and close in Oracle Cloud EPM.
The third tab in the view displays the planning account dimension. It is purpose-built to support multiple planning models and contains many prebuilt members. It also has the most complex property metadata, since the dimension can be tuned differently for use in the financial, workforce, project, CAPEX, strategic, and custom planning models within Oracle Cloud EPM.
Managing all these aspects centrally within Oracle Cloud EDM allows multiple teams to collaborate and effectively control the impacts of GL segment changes across the enterprise. The use case we’ve shared can be extended well beyond GL segment changes to include classification schemes, status codes and system settings. It can also include data warehouse reporting dimensions to keep the mappings used by the ETL process up-to-date. The ability to comprehensively validate metadata enables organizations to proactively control the impact of application-level changes across the enterprise, providing reporting landscapes like never before.