GOPAL GANAPATHY, ESSILOR OF AMERICA

FEATURES Spring 2017

10 OAUG INSIGHT MAGAZINE OAUG.ORG

GOPAL GANAPATHY, ESSILOR OF AMERICA

11

Implementing a budgeting and planning system is a crucial decision for any company to make. The information contained in the system is important from a management and, ultimately, the shareholders’ perspective. Having just implemented the Hyperion Planning solution in 2015, our team came up with key lessons that could be applied by other customers facing such an opportunity.

This article highlights the secret ingredients that form the perfect recipe—from selection of the solution to post implementation—from both a project management and systems administrator perspective.



Background and Context of the Implementation • 2013

◆ Existing application was to be de-supported by the end of the year.

◆ Identified solutions for replacement.• 2014

◆ Conducted solution evaluation with various vendors.◆ Identified solution.◆ Evaluated vendors and proof of concept.◆ Finalized vendor.

• 2015◆ Implemented Hyperion Planning in the first half of

the year.

Based on the above experience, we uncovered the Top 10 Secret Ingredients for the Perfect Recipe:1. Business Case and Sponsorship.2. Requirements Gathering.3. Solutions Evaluation.4. Vendor Selection.5. Team Selection and Project Organization.6. Design Structure.7. Data Integration.8. Change Management.9. Security Setups, User Access and Issues Logging.10. Support Organizations and Post Implementation.

Business Case and Sponsorship As with any new implementation and the resultant investment, it was important for us to conduct a feasibility analysis before undertaking the effort. Part of that analysis included defining the business driver(s) for implementing a new solution. In our case, it was easy as our current tool was being de-supported.

Next, we needed to identify the executive sponsor for the project who could sell the vision to executive management for the investment. This individual was our senior vice president of finance business analysis.

A business owner is also critical for defining the key business users who will provide the requirements. The business owner

manages and resolves any issues that arise with the business requirements within the

various business units during the implementation. This role automatically fell in the lap of our director for budgeting and planning.

Another crucial element to sponsorship is establishing a steering committee. An odd number is always good when a vote on a critical decision is needed. Our committee consisted of the executive sponsor and business owner along with top leaders from the financial analysis and management reporting areas. The committee also included a top leader from information technology (IT). The project manager, system administrator and vendor also rounded out this team.

Requirements GatheringFor any successful project implementation, success criteria are set at the beginning of the project when gathering the right requirements. Our executive sponsor directed that all the users must adopt the solution by placing it in their performance appraisals.

As the project manager, I worked with the business owner to identify the key subject matter experts (SMEs) from the business units who were to be part of the project core team. There was a deadline set for business units to provide their requirements and for the business owner to review and consolidate the common requirements.

Solutions EvaluationOnce the high-level requirements were solidified, the next ingredient was to start working on solutions evaluation. We started with researching the solutions available for an enterprise performance management (EPM) system. Events like Beyond Budgeting and the COLLABORATE annual conference helped us collect ideas, especially through the networking sessions. Solutions can be on premises, hosted and cloud based.

Once the list of solutions was available, I worked with sourcing and IT to schedule vendor demonstrations. We chose one vendor per solution. Initially, there were a couple of sessions with technical team members to understand the high-level requirements and set up the demos. The demos were held with the project core team.

Sourcing conducted post-demo surveys to gather rankings based on weighted criteria. Once all the rankings were consolidated, the solutions were chosen based on optimal ranking of strategic internal infrastructure, requirements, cost and time for implementation.

13

Vendor SelectionAfter the solution (tool of choice) was identified, we initiated the vendor selection process. We worked with sourcing to identify a few vendors with expertise in implementing the tool, which in this case was Hyperion. We included the vendor that originally did the demo of the tool in the solutions evaluations process, as we liked them.

Sourcing then issued the request for proposal (RFP) to the vendors, which included standard and project-specific questions. A timeline was established within which the RFP was to be completed and returned to the sourcing manager. The sourcing manager then set up meetings to review with the vendors and project teams.

Based on the responses, we selected the top two vendors. We requested them to provide a proof of concept (POC) based on the business requirements document. They were also asked to present their timelines and estimates. We then interviewed the vendors’ references to collect their feedback.

Based on the presentations, reference feedback and other criteria, such as timeline, implementation methodology and estimates, the sourcing manager surveyed the project team to gather and review collective insights and selected the final vendor. Once the vendor was chosen, we presented our results and recommendation to the steering committee and got approval to proceed.

Team Selection and Project Organization After the vendor was chosen and the project budget approved, I started to assemble and organize the project team. The project sponsor and business owner were identified at the start of the effort. The business owner and main business (financial) analysts were also part of the core team.

One of the lessons learned was to hire an experienced Hyperion systems administrator before the actual project got started. A budget delay put us behind in hiring that resource and meant that we had to get the newly hired administrator caught up after two months of project initiation.

Next, we met with the vendor staff to finalize the statement of work (SOW) and contract. We added the identified IT resources and hosted resources; in our case, it was Oracle Managed Cloud Services (OMCS). We then created a responsibility assignment matrix (RACI) and published the communication plan.

I held weekly status meetings and published meeting minutes and weekly status reports to management regarding accomplishments, issues/risks, actual spend vs. budget and

forecast to completion. I conducted steering

Top 10 Secret Ingredients for a Hyperion Planning Solution

1. Business Case and Sponsorship

2. Requirements Gathering

3. Solutions Evaluation

4. Vendor Selection

5. Team Selection and Project Organization

6. Design Structure

7. Data Integration

8. Change Management

9. Security Setups, User Access and Issues Logging

10. Support Organizations and Post Implementation



committee meetings periodically and briefed the executive sponsor and other top-level stakeholders on the status of the project. During these meetings, we discussed budget, scope creep and timeline impacts. The business owner also conducted periodic update meetings with the users and provided them progress reports at various stages of the project.

The first thing to consider in designing a decision support system, is data source and structure

Design Structure The first thing to consider in designing a decision support system is data source and structure. At Essilor, our enterprise resource planning (ERP) tool is Oracle E-Business Suite (EBS), therefore, we were ahead while designing data integration. This was because it was easy to integrate the data to and from both systems as they are both on OMCS Infrastructure.

Essilor’s very large product category was a challenge for us; our stock-keeping unit (SKU) catalog is huge. Also, we have more entity and cost center roll-ups than the total number of entities and cost centers. Therefore, we had to design the aggregate storage option (ASO) cube as our reporting cube and have block storage option (BSO) as a planning cube.

Due to the large outline, our BSO calculation was taking hours and turned into a major pain point. To overcome this issue, we ended up partitioning data to the ASO cube, where the data is aggregated instantly. We had to reduce one complete dimension to make our planning cube small and manageable. On the same front, we had to reduce our version and kept only one version. This was a bad design. We lost the privilege to version control without multiple versions. It cost us a lot of time and effort while reviewing and updating our budget.

Our second design flaw was failing to anticipate that the planners will use ad hoc forms to submit data to the planning cubes. We have three plan types, and the data between them are pushed only when planners save a data form. However, if you submit data through an ad hoc form, the data was pushed to one cube but not the other cubes. At multiple points of time, our planning types were out of sync. To overcome this design flaw, we set up a business rule to run at the end of the day to sync the data between cubes.

One design that worked well was the ASO cube. Our reporting cube was an Essbase standalone ASO cube, which is pretty gigantic with all dimensions. This cube gave us what we

needed in terms of reporting. This cube was updating daily with actuals from Oracle EBS and budget from the planning cube.

Data Integration We chose Oracle Data Integrator (ODI) as our data integration tool. ODI is a versatile tool. We only needed to integrate it with Oracle EBS; however, ODI can integrate with most other ERP systems available. We had to load text files, and ODI was a great tool for this.

ODI comes with prebuilt knowledge modules. Our administrator learned about this tool before he was hired to manage our EPM application. After reading an ODI book, “Getting Started with Oracle Data Integrator 11g: A Hands-On Tutorial,” by David Hecksel, our administrator was able to create the ODI application.

ODI does a complex transformation. Even if you don’t have a complex transformation, it’s great for extraction and loading. Another good feature of ODI is that you can run SQL and PLSQL just as efficiently. It is also great with scheduling. Between Oracle Hyperion Financial Data Quality Management Enterprise Edition (FDQMEE) and ODI, we decided to go with ODI.

ODI does a complex transformation. Even if you don’t have a complex transformation, it’s great for extraction and loading.

Change Management We held multiple system review sessions with the planners while they are still developing the system. We began by describing the design and architecture of the Hyperion Planning session followed by Smart View basic trainings. As we progressed, we had more advanced training for Smart View and WebForms.

For the core reporting team, we had specific Hyperion Financials Reporting training. This approach helped us receive periodic feedback from the users and implement changes. We created a change request form to organize and prioritize change requests. This approach also helped us to not put too much pressure on the original project plan but to also build a system that is friendly and efficient. We created user guides and job aids for Smart View for users to help ease the transition.

“

“

15

Security Setups, User Access and Issues Logging At Essilor, we have native Hyperion users who are provisioned through Shared Service. This made it easy and structured to manage users in a centralized location for both the Essbase and Planning users. The fact that we could group users and assign them access at one time has saved a lot of time and effort.

However, the Hyperion server is located in the Oracle hosted environment, and we could not leverage our network user ID and password to log in to the Hyperion system. This situation is a huge disadvantage. We are continuously resetting users’ passwords and managing them after the initial setup. We created an issues logging workflow to track issues through the various sprints and the final user acceptance testing (UAT). We also created a user access workflow for new users or users who had to change roles within the Business.

Support Organizations and Post Implementation Building and deploying a system is only half the story; the rest of it is support, continued utilization and enhancement. Keeping the EPM system up to date is vital to maintaining the liveliness of the system. It was easy to do because our server was hosted with Oracle. As a result, we are just a release behind the latest release and our users don’t even notice when we upgrade our systems. System upgrades have minimal downtime thanks to the Oracle Support team. We can use any new function that is available with the new release. The administrator was able to manage the system support with no extra work. This practice is highly recommended. ◆

Gopal Ganapathy, PMP, MBA, CSM, ITIL, is a finance project manager at Essilor of America. He has over 16 years of program and project management experience in multiple industries on technology and business teams. In his current role, he managed the Hyperion Planning Implementation for Essilor of America, a subsidiary of Essilor International, the world’s leading provider of eyeglass lenses.

Investigating the benefits of other reporting solutions? Our team of experts has compiled a step-by-step checklist to help you on your journey.

3 Considerations When Replacing Oracle Discoverer

Download the full checklist at: go.excel4apps.com/oaug17

EvolveUser-friendly, self-serve reporting in Excel

3.

ReviewAssess and prioritize current Discoverer reports

1.

MigrateGain efficiencies with smart report conversion

2.

Documents

GOPAL GANAPATHY, ESSILOR OF AMERICA