Ideal World

In an ideal world, we would have a stable transaction system (Transaction Processing System (TPS) / Enterprise Resource Planning (ERP)) that we are using to facilitate our day-to-day business operations in place first. This would form the foundation for our Enterprise Performance Management (EPM) system, which would underpin our strategy, plans and forecasts. Both of these would then be exposed and made available via a comprehensive Business Intelligence (BI) tier.

As the organization matures systemically and begins to capture large volumes of data and unstructured data, the need to include Big Data capability becomes necessary. This would also of course need to be exposed by our same BI toolset. This will be discussed further in a future blog.



The reality is that ERP rollouts take time; in a large global organization, this could be years. Management cannot do without Management information while they wait for the implementation to complete. This results in a plethora of Cottage Industry systems being built using MS Excel and MS Access usually. This in turn breeds multiple versions of the truth, silos of information, fractured reporting, and cumbersome, often disjointed analytics. It also builds “single points of failure” around individuals who alone have knowledge of their particular system. Finally, it becomes hugely difficult to rein all of these in, and replace them with a formal EPM system when the time finally arrives.



So how does an enterprise go about achieving both and ERP and EPM Utopia?

The trick is to step back from product-based implementation and think of the exercise as an entire eco-system facilitating the business processes required to meet the business objectives. This should be organic, always flexing and growing with the business. I like to think of this as a Continuous Improvement Cycle, rather than a stacked or tiered system.

The applications required by key stakeholders for Statutory Reporting, Performance Management and Operational Management should drive chart of accounts design.

By defining the metadata and data requirements for the EPM, you will automatically provide a shopping list for the ERP solution, dealing with some of the key issues such as:


  • Data Granularity
  • Dimensionality
  • Use of Custom Fields
  • Multi-Dimensional view of data to be catered for, not just relational
  • Normalized and De-normalized Schema requirements.


This will have the added benefit that Data warehouses and staging areas will be much more efficient as there will not be massive requirements for metadata and data manipulation.

This means also that from the outset, as the ERP is rolled out across an organization, the Company will benefit from:


  • One version of the truth
  • Data lineage that is transparent
  • Optimized data warehouse, and staging area
  • Simple "drill-through" from EPM tools to detailed transactions
  • Redundant dimensionality will be avoided
  • Users can be consuming and interacting with data within a comparatively short time
  • A staging area can be built to transition easily from old ERP metadata to sourcing from the new
  • Having done it this way, future acquisitions will be easy to merge into the “mother ship”.


This might look something like the diagrams below:


Traditional View – A best practice tiered view




Organic Continuous Improvement System – step back and see it as a whole



With Product Examples



Become a member


Receive our newsletter to stay on top of the latest posts.