AY

Abdoulay e M. Yansane Abdoulay e M Yansane Abdoulay e Mou ke Yansane

Moving Beyond Seven Common EPM Frustrations:

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, specifically with the Oracle/Hyperion products, for the last 15 years. Here are seven common frustrations that I see frequently along with some recommended solutions.

#1: The constant vying for EPM ownership between the Business and IT.
One common re-occurring question across many organizations is who should manage the EPM systems, Finance or IT? My belief is that neither of the organizations is individually fully qualified for the task. Each side needs to realize that it is in their best interest to work closely with the other. That mutual realization will hopefully lead to collaborative efforts such as a Center of Excellence (COE) or some other team effort to support and evolve the EPM systems that the senior leadership team has entrusted both organizations with managing. IT Here are some things you should think about EPM applications are continually evolving to adapt to changes in the business. The traditional strategy for IT support is to put the application into production and throw away the key until the next phase of the project can be funded. Finance has often responded to this by leveraging IT to provide the data and leveraging Excel or some legacy departmental point solution to perform a lot of their EPM tasks like planning and modeling. Finance likes what they have because they have control, but they dont have the staff anymore to keep going down this route. Finance lives in a world of continuous change since they man the Financial GPS system that the senior leadership team uses to plot the future course for the corporation. IT needs to find ways to inject flexibility into their EPM support model to help finance absorb this change. IT, does your staff have trusted access to first-hand knowledge of the business needs that is required to design and support your companys EPM platform? In your job, an important skill is to extrapolate what you know from experience and apply it to new technologies and business functions. In many organizations, the rough extrapolation of ERP, relational database knowledge, and reporting technologies to EPM without real world experience and advice often leaves the Finance guys on the other side of the conversation with the impression that You just dont get it. If your EPM/BI team isnt being embraced by the business then you have the wrong guys. Sure, they have a tough job and need you to back them up, but if they cant establish a trust relationship then the lines of communication can never be put in place. Better business information starts with the ability to understand the needs of your business customers. You have to be able to ask the right questions to draw out the detail around what the business truly needs. You live and die by predictability. You measure your success by measures like 99.95% uptime or 24/7 support. Slow and steady wins the race. At the same time, your footprint has been downsized over the last few years. Yet you still want to control all technology in your business. Why? When it comes to EPM solutions, you need to recognize the business needs will continue to evolve, you should be mentoring, supporting, and providing governance to technological innovation to support this and not stifling it. Finance Here are some things you should think about Having evolved over time, your EPM systems no longer provide the efficiencies you hoped for. You have just moved resources from maintaining monster spreadsheets to maintaining EPM applications. You still need to reconcile differences between your legal, management, and planning applications. You are still putting out almost as many fires as you did before, and you still have a lot of monster spreadsheets that only a handful of your people understand. What you really need is an architect to re-design your EPM ecosystem to get the efficiencies to allow your team to spend more time on the key deliverables that you promised to your senior leadership team. The EPM systems and processes that you have cobbled together are a big risk to your organization. You dont have the controls, processes, redundancies, design, etc. in place for long term sustainability. You cant keep making changes directly in your production systems. You dont have a backup or documentation if your Hyperion guy walks out the door. You need structure and a solid technical foundation. Your IT organization can help you with that. You should be keenly aware that you dont give your technical folks enough lead time to make the changes that you need. I could make the changes myself in Excel in minutes, really isnt a valid argument. You need to plan better and recognize that investing in the proper architecture up front; will allow more flexibility in the long term. You need to be a better partner with the technical teams that support you.

AY

Both IT and Finance I have been in the meetings with both of you present. I have felt the tension. I have seen the finger pointing. You both need to stop, take a deep breath and realize that each of you needs to make adjustments. YOU are half the problem. Sit down and build your roadmap for the future together.

#2: Not enough focus on locking down the go forward business process.
A lot of organizations decide to change their business processes at the same time that they are implementing a new system or upgrading an older one. Often, the business process cant be changed without changing the underlying system. Conversely, it is not optimal to build new systems around older, outdated business processes. Most financial system managers realize that the business process reinvention effort needs to proceed the system development phase of the project, but, often, the two phases end up getting worked on concurrently. Reworking or altering a business process is an extremely time consuming activity that requires a great deal of senior leadership buy in, subject matter expertise, consensus building, and change management. It is a very project based activity that requires a great deal of dedicated time from manager and director level employees who have too much on their plates already. Often, business process related projects are headed up by managers who dont have a deep background in large scale project leadership. Their management skills have been refined around monthly, quarterly, and yearly deliverables. They have managed a lot of smaller projects, but not larger ones. They may have trouble estimating tasks, measuring progress in a meaningful way, and accounting for the complexities that are created by making widespread process changes. In these cases, utilizing a proven change management methodology is especially important. Frequently, the high level process changes do get conceptualized and documented before the systems project begins. The trouble starts when the system implementers start asking for the details. Problems really ensue when the system output gets reviewed by the business users. Nuances and complexities related to the process changes emerge. This often happens late in the project when deadlines are fast approaching and budgets are drying up. The process engineering team points to the systems implementation team and asks them why they didnt ask more questions. The systems implementation team takes the position that they can only build around what they know about. The outcome varies from temporary frustration to a failed effort, but the situation could have been avoided. The answer is simply to place more emphasis on process change. Set realistic deadlines, require soup to nuts level process architecture documentation, ensure consistent involvement from the business process owners, consider engaging professional industry specific change management expertise, and dont try to time box process change activities into an already determined system rollout schedule.

#3: Lack of Vision around Enterprise architecture.

It is surprising to me that organizations continue to move forward with Oracle EPM 11x implementations without looking at all the capabilities that Oracle offers. For example HFM is often conceptualized and built as a stovepipe solution in the same organization that Hyperion Planning is separately being rolled out in a similar stovepipe fashion. This happens because all too often two different groups are charged with implementing and supporting each of these two solutions. Companies waste valuable resources on redundant support efforts. Meanwhile users waste valuable time bouncing between redundant systems. Users end up needing multiple versions of Smart View (or the Essbase Add-In), chart of account and organization hierarchies are slightly different, the same data between multiple systems is not directly comparable, and users still need to merge data from multiple sources in Excel for planning and reporting purposes. What needs to change The business and IT groups that support EPM within an organization need to gain a holistic view of the collective user experience with all corporate financial systems. That user experience should be the central focus of all forward thinking around EPM architecture. Move away from thinking such as, We need a new implementation of HFM, Planning, Essbase, HSF, etc. in order to accomplish these department goals. You really should be thinking more about how to build an EPM System that collectively helps your organization achieve its strategic goals. HFM, Planning, Essbase, HSF, etc. are best thought of as specialized modules in that system. What your users are looking for is one stop shopping for consolidations, financial planning, operational planning, strategic planning, management reporting, and legal reporting.

#4: Slow adoption of implementing the Oracle EPM vision as it was intended. EPM implementers incorporate too much customization.

AY

The truth is that a lot of Oracle Hyperion implementers have been around for a long time now. A lot of senior implementers and architects have skills and experience that have been built based on client opportunities. I believe that there is a general tendency for implementers to go with what has worked at past clients. This is generally a good practice, but it does cause many implementers to hold onto outdated practices too long. A real problem emerges when custom solutions relying on programming, scripting, SQL databases, data exports, etc. are used instead of vetted packaged solutions that Oracle offers. It is a good idea to get an independent review of the system design document by a qualified third party to ensure that your new system isnt being developed based on standard practices from the prior decade. Customization has a tendency to complicate support and slow down the ability for organizations to quickly migrate to future patches, product releases, and new modular solutions down the road. In the early days of Hyperion, customization equated to innovation and competitive advantage. Today, in the era of packaged enterprise modular solutions, customization may be a real barrier to future adoption of innovations that are emerging from Oracle and other EPM software vendors.

#5: Not enough emphasis placed on EPM Support.

For many organizations, support is the largest EPM expense. In reality, support may also be the most important thing for a corporation to get right in order to really have a successful EPM System. The biggest problems that I see around EPM Support are the following: Organizations dont do enough advanced planning around support.

One of the key considerations when reviewing system design documentation is to determine what it is going to take to support the new system. Another important consideration is whether or not the design leverages corporate standards around automation, ETL, scripting, etc. The goal should be to build an automated solution that integrates tightly with the existing environment.

Another consideration is transition to support. The support transition should be built into the project plan. The following questions need to be answered:

What is the transition process? What are the resource requirements? What are the skill requirements? What training is required for internal support resources? What application support documentation will be provided?

EPM Support Staff frequently are in over their heads. Organizations that do not have access to experienced Oracle Hyperion application and installation/infrastructure support resources typically struggle to support their EPM systems. It takes more than attending a boot camp type class and a few weeks of shadowing the development team to really support an Oracle Hyperion solution. Without the proper support expertise, I have seen more than one Oracle EPM system quickly become a problem child. Hiring or contracting the right support talent usually is the best first step to reigning in the problem child.

#6: EPM Implementation Architects dont 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 dont have visibility

AY

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 organizations 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. ITs 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.

#7: Not enough freely available vendor independent information to help Financial Systems Managers to make informed decisions.
There is an abundant amount of information available from both individuals and consulting companies around technical Oracle EPM topics. Most of this information is directed at more of a technical audience. I use this information every day. However, when I worked as a Financial Systems Manager I needed an entirely different kind of information. I needed information that would tell me in advance what the decision points were that I would be faced with for an EPM implementation and what my best options were for each decision. I needed information on tool selection, infrastructure selection, support options, off shoring, etc. I needed management advice around EPM so that I didnt have to reinvent the wheel for 80 hours each week. There is a lot of information out there in this area, but a lot of the bigger consulting companies who have this information are not as generous with their ideas and experience as the technical folks are.

Hopefully more individuals in the industry will see the value in sharing their EPM management experience over time. In the meantime, check out the ClearLine Thought Leadership Library. I have spent quite a bit of time creating EPM management documentation from my own experience rolling out and supporting very large Oracle EPM solutions. I hope it helps.

Read my previous articles:

Taking the Bull by the Horns and Seeking Out EPM Project Advice http://www.clearlinegroup.com/taking-the-bull-by-the-horns-and-seeking-epmproject-advice/ A Financial System Managers Guide to Implementing the Hyperion EPM Product Suite http://www.clearlinegroup.com/wpcontent/uploads/2012/09/BigBangTheory.pdf 16 Ways to Save Money on EPM Initiatives http://www.clearlinegroup.com/wp-content/uploads/2012/09/16-Ways.pdf
By Paul Mack on December 11, 2012 / Business Intelligence, Enterprise Performance Management / 2 Comments Tags: dashboards, data filtering, Data mapping, data quality, data warehouses, dimensional structures, Enterprise Performance Management, EPM, Essbase, finance, financial systems, HFM, HSF, Hyperion, Hyperion Financial Management, Hyperion Planning, IT, Meta Data, Oracle, reporting, Smart View, SQL database, systems