Vous êtes sur la page 1sur 4

16 Ways to Save Money on EPM Initiatives

I have been in the EPM industry since 1997 when a got the opportunity as a financial analyst at Citibank to be the SME for branch profitability and sales reporting application. Hooked on the application of technology to solve analytical and planning problems, I quickly found myself in the world of EPM consulting which I stayed in for the next ten years. My earlier career focused on corporate profitability continued to drive my project management decisions on the consulting side of the fence. In 2009, I had the opportunity to join a large Pharma/Device manufacturer in Chicago as the EPM Manager. I quickly found out that managing a large EPM project budget was more difficult than I had thought. I found myself managing 5 vendors on 6 simultaneous EPM projects. I learned more in 2 years as a corporate manager about EPM project management than I had in the previous 10 years in consulting. Based on my recent experience making project choices to get the most bang out of my EPM project budget, I have put together a list of 16 ways to help EPM project decision makers save money on their EPM projects.

Do not move forward unless you are sure that the consultants truly understand what the expected deliverables are.

1. Clear consensus on requirements

Hold someone in your organization directly accountable for making sure that the EPM requirements are well thought out, vetted by all stakeholders, complete, as future-proof as possible, and accurate. Do not move forward unless you are sure that the consultants truly understand what the expected deliverables are. If you dont have a company Subject Matter expert (SME) paying attention to requirements on your project then your project, even if you have a good project manager, doesnt have anyone behind the wheel. If your consulting team is providing technical solutions to things you didnt ask for then you have lost control. If you have requirements meetings and ask for functionality that never gets documented, then you have lost control. Once you have lost control of the requirements, you lose control of the project costs.

2. Hold on to every dollar

Dont be lulled into complacency at the beginning of a project by a large budget. You will need every dollar by the time the project rolls out. No matter how large your budget is, if you arent focused on costs, you will be begging for additional funding to finish your project.

3. Commitment from business users

Dont start a project unless the company subject matter experts will have dedicated time for the project. Who is going to provide the functional requirements, mentor the technical team on your companys specific needs, and provide ongoing testing? If the ideal person for this job is already under water then expect him or her to be a bottleneck that will cause project delays and increase project costs.

4. Keep users engaged

Dont wait too long to bring the users in. They may require changes that will throw your budget way off. Your company SME may have a vision. He may have agreed to compromises relating to technical limitations. Everything may be on track. Powerful end users who have a slightly different vision or who dont understand the compromises could create a scope creep problem for you. Your company SME, project manager, and maybe you need to continually sell the vision and keep the end users in the loop as requirements changes are made.

5. Do your work up front

For a large number of projects, you end up paying high value consultants to do work that could be done by business analysts (BAs) at half the cost. Engage a BA to build out the chart of accounts, entity hierarchy, product hierarchy, etc. in Excel. Spend the time to gain consensus from all stakeholders. Try to merge the hierarchies across systems. For example, work towards an account structure that works for your Financial Consolidation, Planning, and reporting. Those hierarchy structures can then be loaded into your EPM metadata management tools for continued refinement and production automation.

6. Understand and prepare data

Data integration for an EPM project, even from the general ledger, can be a long complex process. There are many, many hidden rules that go into an organizations data. The rules of the game are pretty simple. You need sku level sales data, customer account balances, etc. that tie out to a given GL account balance. This is a multi-month activity that can be best done by a BA using tools such as Excel or Access. Tying out your data using high priced consultants is both risky and expensive. Data delays lead to EPM development delays which lead to project overruns. Data acquisition and cleansing is really its own project. Actually it is the core project that adds the most value.

You need to think in terms of progress versus requirements. A simple approach is to have a list of requirements in Excel. Set dates when you can review progress against each of those requirements.

7. Get a second opinion on the technical design

You are going to get a better technical design if the architect knows that their work will be seriously evaluated. Your solution may look well thought out and sophisticated, but it may be a port from another client. The original work may have been done by a real architect, but you are just working with an understudy. You want a solution that will address your companys specific needs. Get a second opinion to make sure that you are getting what you are paying for. Usually a suboptimal solution will have performance issues. This is a red flag that you need an additional set of eyes.

8. Review progress weekly

You need to think in terms of progress versus requirements. A simple approach is to have a list of requirements in Excel. Set dates when you can review progress against each of those requirements. This will prevent items from slipping off the list and make sure that what is being built is what you need. I recommend an Agile development methodology which provides frequent reviews of progress.

9. Consider offshoring

My experience successfully utilizing offshore resources has left me with the following general guidelines: a. A technical upgrade is the best first step towards offshoring EPM work. b. The typical offshore developer is usually more technical than business focused. The developers typically have risen up the support ranks rather than coming over from FP&A or Accounting. c. The developers work on bigger teams than US developers. They are more specialized. d. The model I have worked with was somewhat of a black box. I worked directly with onshore and offshore managers who interfaced with the developers. e. The black box approach creates a higher chance of going off in the wrong direction, but mistakes cost less. f. Development costs are cheaper so experimentation is financially possible. g. My personal management time was 4 times greater than managing US developers. h. I would ease into this slowly and get advice from people who have done this before. I spent a lot of project dollars learning how to making offshoring work for EPM development.

Organizations are often tempted to use internal support resources for development. Support staff maintain but typically have never architected and developed an enterprise solution before.

10. Consider contractors for some roles

Reputable EPM contractors who you know and trust, can be a valuable addition to a project team. You can get top talent without paying the middle man. The downside is that you become the middle man. You will get into the business of having to keep a project staffed in a volatile EPM job market with no backup. A big part of that is identifying which applicants are a good fit technically for your project. Finally, there isnt really anyone to hold accountable other than you if the project goes bad.

11. Beware using in house EPM support staff for development

Organizations are often tempted to use internal support resources for development. Support staff maintain but typically have never architected and developed an enterprise solution before. At the very least, bring in an architect to design the application, and an experienced developer to mentor your support team. Remember, you may only get 2 weeks of development time per month from support staff.

12. Dont hire consultants on a T&M basis for long term support

You are paying someone premium rates to perform the same routine tasks month after month. Document your support processes from top to bottom and give someone within your organization a chance to take on the support role. Or hire an organization that specializes in EPM managed support and delivers services on a retainer basis.

13. Insure you have internal alignment

Sort out the politics first. I have built a few solutions that were simultaneously targeted for sun setting by IT. Sometimes, if IT really wants to deliver the application out of the data warehouse, versus OLAP tools, its better just to jump on their bandwagon. The message to IT is simply this. Here is our detailed set of requirements. Provide a technical solution recommendation that meets all of these requirements. Remember, moving something to Phase2 is roughly equivalent to having your great idea put in the parking lot in a brainstorming session. In both cases, you are being steered away from your vision.

14. Start with a roadmap

I look at EPM as a journey, not a destination. Understand the mid-term and long-term vision for EPM in your organization. If your organizations goal is to build an EPM system that shares data and metadata, then develop the overall architecture and incorporates future EPM projects. Working with a tool set that can accomplish your long-term vision provides tremendous long-term cost savings.

...look at EPM as a journey, not a destination. Understand the mid-term and long-term vision for EPM in your organization.

15. Invest in ongoing user training

Any system is only valuable if it is used. A trained user community will get the most value out of the system, provide the best feedback, require less support, and create enthusiasm for future investments in EPM. Some very nice CBT tools exist today to provide self-serve, ongoing training.

16. Consider outsourcing your EPM Infrastructure

There are several companies in the marketplace today that specialize in EPM Application Hosting. You lease or buy hardware in their data center. They maintain the hardware, perform the software installations, monitor and maintain the health of your applications, and provide ongoing technical support. By sharing a Hyperion administration engineering team across several clients, they can provide lower costs and higher quality than many organizations that provide support internally. In my role as the EPM Manager I analyzed the 3 year and 5 year total costs of outsourcing EPM Application Support vs. keeping Application Support in house. The quotes from outsourcing vendors to provide EPM infrastructure and engineering support were significantly lower than the quote for comparable hardware and services from IT. As a result, my organization chose to outsource our EPM infrastructure and technical software support to a regional managed hosting company specializing in Oracle Application Support.

ClearLine Group
2275 Half Day Road, Suite 350, Bannockburn, IL 60015 855.ClrLine (855.257.5463) contact@clearlinegroup.com www.clearlinegroup.com

Vous aimerez peut-être aussi