This week one of the team’s priorities has been working on defining the requirements for an integrated budgeting, reporting and consolidation solution. The key priority in this workstream is the importance of breaking down reporting requirements into distinct use cases…
We commonly find that there are two main use cases for reporting. The first use case is month-end reporting or journal support reporting. You are at working day one, posting your accruals: you need to have immediate visibility of the journal you have just posted, otherwise you risk duplicating the journal or wasting time investigating. This means you need real time reporting and the ability to drill from balances to transactions. Also, if your ledger and consolidation structures are different, you need your ledger data mapped to your consolidation tool format, to avoid an iterative loop of posting journals, loading, posting more journals….
The second use case is what we call analytical reporting: preparing the management reporting packs, writing up commentary, investigating discrepancies to budget or forecast, as well as add-hoc reporting. Here you need a far more flexible view of data. You also need a greater range of data: metrics, often combined with financial data to create key performance indicators, budget and forecast data. In addition there is often a difference in the timing of the data: normally this data needs to be synchronised with the data published in the consolidation tool for financial reporting. Coming back to the topic of the blog, for this reporting use case, quicker or more frequent data refreshes are not necessarily better!
Do these contrasting requirements ring true to your experience? Is so, the key point to take away from this blog is that different technology might be appropriate to address your distinct use cases. For example, in our experience, Oracle OBIEE or Oracle Essbase XOLAP are excellent online reporting tools for month-end; and a classical Oracle Essbase configuration delivers excellent cross-dimensional capability for analytical reporting.
If reporting is an area you are focusing on at the moment, I highly recommend putting the following on your pre or post holiday reading list:
If you would rather discuss it in more detail with a member of our team then do get in touch.
Some good news to share! We have started a comprehensive BI (Business Intelligence) Finance initiative for the UK’s favourite retailer. We have been asked to design a solution to use Oracle Hyperion DRM (Data Relationship Manager) as the single repository of all the retailer’s financial masterdata. Oracle Hyperion DRM will provide them with a comprehensive governance solution enabling efficient maintenance of all their core financial masterdata.
Oracle Hyperion DRM’s scope will encompass Oracle EBS, ERPi (Enterprise Resource Planning Integrator), FDM (Financial Data Quality Management), HFM, Essbase and OBIEE (Oracle Business Intelligence Suite Enterprise Edition) applications and tools.
This represents another great opportunity to show how masterdata management (MDM) should be a primary consideration at the start of any EPM (Enterprise Performance Management) initiative, not, an afterthought.
We look forward to sharing more over the course of the project. Off to celebrate!
We were recently asked by a client what the difference was between metadata and Masterdata. This got us thinking that it would be worthwhile digging into this a bit more. The term ‘metadata’ has two broad meanings. Though the word literally means ‘data about data’, it is often used to refer to data about the organisation of data, such as the columns and tables in a database and the relationships between them. The term is also used more strictly to refer to information about the content of data (also known as metacontent). Examples of this kind of metadata include summaries of contents, keywords for searching, and information on the source and owner of the data.
‘Masterdata’ refers to the non-transactional data that describes a business or other organisation. Typically this data covers:
- Internal entities such as departments, employees and products;
- External entities such as customers and suppliers; and
- Organisational information such as reporting hierarchies and the chart of accounts.
Masterdata is required to support transaction processing, and to organise reporting and analysis.
A common problem with masterdata is that it is spread over the reference data contained in multiple, possibly inconsistent systems (particularly if a company has grown through mergers and acquisitions). Masterdata management (MDM) is the process of consolidating some domain of this information – customer information or account details, say – into a single authoritative source of data. Seismi focus on using MDM to drive business process change and create truly integrated financial processes. Seismi’s chosen tool for MDM is principally by deploying Oracle Hyperion DRM (Data Relationship Management).
We hope this has clarified the differences between metadata and masterdata. If not then please do get in touch and we can dicsuss it in more detail. At least we will be better prepared for when we are asked again!