In the first part of this blog I discussed the dilemma facing decision makers as they look to the future of EPM within their environments. I discussed the myriad of choices the modern CIO faces with ‘how’ and ‘where’ to deploy a Hyperion EPM solution. I covered the ideas of TPS (Time, Place, Source) and gave same insight into the value of delivering more within each of those categories than has been traditional. Today I’m here to talk about how we go about achieving that.
There is a long history in the Hyperion world of reviewing things. We are quite versed in application reviews, technical reviews, architecture reviews and tuning reviews. It really doesn’t matter what we call it, at the end of the day the goal is to look at some components design and fix it or make recommendation for fixing it. What is interesting about all of these reviews is that they have a very focused and specific purpose: fix this problem, tune this server, and adjust this rule. In looking back at the bulk of the reviews I’ve done in my career, I realize that the majority of them were tactical in their approach. The goal of the review was to solve a current pain, and while they were successful in achieving those goals, I started wondering if there wasn’t a need for another approach.
Fortunately the opportunity presented itself to try something different with a client who was looking to do a major upgrade and wanted to know ‘is there a better way to be doing this’. Here was a chance to try a more strategic approach to looking at their environment, their usage of the product, the IT options available to them in today’s world, and of course the changes in the new EPM code line they would be adopting. This client looked to make the most of their existing EPM investment. Research and studies have shown us that an EPM investment has a typical ROI of one to two years. But what if we wanted to have a five-year or even a ten-year ROI model that maximized our original investment? This idea is inspiring. So, I took this template and converted it into a reusable model, and thus was born the Engineering Study. Let’s take a gander at what that looks like:
- Understand: The first goal of an engineering study is to help a client understand where they are. It is built around discussions of what products are licensed, how they are used, and what areas might be candidates for growth or possibly even reduction.
- Quantify: A second goal of these discussions is to understand ‘how much’ stuff there is in the current Hyperion system. Much like people, some clients are neat and tidy while some are data pack rats. We take an inventory of all the existing objects that would move to the new system. This allows a client to ‘weed out’ all of the old content that’s simply lying around, and focus on what is actually used to drive business needs.
- Qualify: Third we talk about the need for any new products. Are there any new company wide initiatives where EPM can drive value? If another division is looking to analyze large amounts of product data for marketing purposes, perhaps Essbase can help. Or if someone is looking for a more manageable chart of accounts, perhaps DRM is the solution. The goal here is to look at the strategic landscape in the company and make sure existing tools are being leveraged to solve internal needs before other divisions purchase a competing (and perhaps unnecessary) equivalent.
- Locale: Next we talk about the hardware/infrastructure side of the foundation. We take a close look at the costs for a physical on-premise solution and then compare those against other non-traditional models such as a virtualized model, a cloud model, a hosted model and even an in-memory machine model. We also look at areas that may not be addressed by the current systems like high-availability and disaster recovery.
- Plan: Once we have qualified all of the above aspects we build a solution that addresses all the needs of the client for the next upgrade cycle (usually three to five years). That solution includes a high-level project plan for how to get there and the resources involved.
- Support: Final conversations center around supporting that model with the appropriate resources once CheckPoint is no longer on site. This can involve staff augmentation, managed services, or staff increases or training on the client side.
Always keep the end in mind
As can be seen from the list above, this is very different from your standard technical review. It is also more time-consuming. The goal of the Engineering Study is not only to figure out what is next, but also to extend and return more from the existing EPM investment. Most clients see a big return on investment in the first year or two after go-live. However, research has shown that extending and deepening a company’s exposure to EPM only increase the net return and the ROI. The return on investment is best seen when it’s multiplied across many departments and users within an enterprise. Taking a step back and looking at how EPM is being used today can help you understand what areas to address next. Not only can a study help move you to the next version, it can help you define and tackle exposing other parts of your enterprise to EPM.
The goal here isn’t simply to upgrade the existing world and get a new version that will support the latest client OS or the new browser. The goal here is a thoughtful assessment of the product suite and its implementation ensuring that your EPM investment is still driving positive business decisions, ultimately remaining agile and delivering value will be the ideal outcome for any upgrade project.