What Frustrates Me About the EPM Industry and How It Can Be Made Better

I recently read an article on entrepreneurship that featured Richard Branson. In the article, Branson was quoted as saying that the “real opportunity in business is the ability to identify the frustrations in a particular area and have real solutions to remedy those frustrations.”

That started me thinking about the common frustrations that I have seen while working in the Enterprise Performance Management (EPM) industry for the last 15 years. Here are seven common frustrations that I see frequently along with some recommended solutions.

(This is the sixth of 7 articles discussing frustrations with the EPM industry. To be sure you don’t miss out on any articles of interest, please sign up for our weekly newsletter at http://www.epmchannel.com/register-for-our-weekly-digests/.)

#6: EPM Implementation Architects don’t look outside of the Oracle Hyperion Box.

It is not enough to have a great EPM System. That system needs to be deeply integrated into the IT ecosystem that it resides in.

Single Version of the Truth
If data, dimensional structures, data mappings, and business logic is centrally maintained and pushed out to all relevant corporate business systems, then, for the most part, all systems will report the same results. Maintaining unique dimensional structures, data mappings, and business logic in downstream systems creates a tremendous amount of redundant and costly activities at the system support level, and also among financial analysts who must understand and account for differences between the different systems that they rely on.

Data Mapping Transparency
Many companies have systems that provide detailed data which, for a variety of reasons, does not tie back to the summarized financial numbers. These variances to the financial numbers are a source of frustration, confusion, and complexity for the groups that use these systems. Often, the variances are the result of systems that have arcane, complex logic that is not easily accessible or well understood. The answer is to move towards sourcing data from repositories that are standardized on a readily available set of mappings that all parties have agreed to. That set of mappings need to be documented in a format that semi-technical business analysts can understand and communicate to their management.

Data Ownership
IT generally will say that the business is responsible for data quality. At the same time, the varying business groups will say that they don’t have visibility into the mappings for the systems that they use. They rely on IT to get the data right. This can create a lot of conflict and a lack of control around an organization’s ability to predictably deliver quality data. This results in a lot of extra re-occurring trouble shooting cycles during reporting periods.

The solution here is simple. There needs to be an enterprise level solution that allows the business to have a single point of control for dimensional structures, data transformations, data filtering, and exception reporting. IT’s responsibility should be around tool selection, implementation, and support. The business needs to take responsibility for data quality using these tools. Tool examples include:

Metadata Management — For centralized control of dimensional structures across the enterprise.

Data Warehouses — For standardizing the data through a single set of maps and filters that can be used in multiple business applications.

Data Quality Exception Reporting — Move data exception reporting as close to the source as possible. ERP and data warehouse exception reporting will allow a single group of business analysts to identify data quality issues and solve them upstream. If data quality issues are allowed to tumble to downstream systems then multiple groups must each take time to independently address these issues. Different downstream efforts will lead to redundant work, different reporting results between systems, and conflicting requests made back to the source system team to correct issues.

By Paul Mack, from: http://www.clearlinegroup.com/moving-beyond-seven-common-epm-frustrations/