PERCENTIX BLOG

The Oracle | Sun Acquisition and What it Means for Enterprise Performance Management

What's old is new.  Bell bottom jeans, aviator sunglasses, big band jazz, vertical integration...err...yes, vertical integration.  By most historical accounts, Andrew Carnegie introduced the concept of vertical integration some time ago, and in the recent past we have seen business process outsourcing essentially debunk the merits of this once cherished business practice.  If you need a primer on vertical integration use this Wiki link: http://en.wikipedia.org/wiki/Vertical_integration.  Cheap labor abroad drove much of the drive around outsourcing, reinforced by a increasingly educated set of foreign workers who are inexpensive when compared to their US counterparts.  However, the economic turmoil experienced from 2007 to the present has stressed companies in multiple ways, so much so that organizations are revisiting the concept of vertical integration (VI) in an effort to improve the quality of their products, protect the supply chain from systemic risks, hedge currency fluctuations, and most importantly, use VI as a means to enhance the customer experience.  Which leads me to the point of this blog: Oracle's acquisition of Sun Microsystems.  

By all accounts, Oracle|Hyperion is a tiny fraction of the overall Oracle technology stack, albeit a very critical one.  Oracle's acquisition of Hyperion was indeed a trendsetter, noted by the quick reaction of SAP and IBM.  But setting trends for the sake of setting trends is foolish: Oracle realizes the importance of the Chief Financial Officer and wants access to that office.  So, when viewing the impact of the Sun acquisition on Oracle|Hyperion EPM, I feel justified in composing this blog despite the rather small footprint of EPM on the overall stack.

So, what does it mean for Oracle|Hyperion EPM?  Well, in the short, term, not much.  There is no question that Oracle has made great strides with the original Hyperion software offering, enhancing the customer experience with new features and functions, as well as integrating the technology with ERP solutions for drill back and tighter integration.  The Sun acquisition, in immediate terms, is a long term strategic play and the short term effects for EPM are minimal.  Things do get interesting in the long term, in my opinion.

The long term effects of the Sun acquisition will be felt throughout the Oracle technology stack, Hyperion EPM included.  Here's a very brief sampling (clearly not exhaustive) of what I believe we will see in the next 3 to 5 years.

1. Oracle|Hyperion EPM in a box

• "EPM in a box" offerings will begin to surface, essentially integrating hardware and software for a simple plug a play solution. Today, a customer will make a license purchase of Oracle|Hyperion EPM (think Planning, Essbase, HFM, etc) and will then make a determination on what hardware to use. Most of the time customers select a set of servers which run a version of Microsoft Windows, although they do have the option of selecting UNIX based environments (in my experience I have only really seen Essbase used with consistent success on UNIX boxes). Customers then procure the hardware, install the OS, then have a consultant come in and install the Oracle|Hyperion components. Sometimes we see "fancy" setups that use SAN environments but mostly the work is restricted to the set of boxes designated for Oracle|Hyperion EPM use. In the new world, Oracle will literally deliver a server(s) to your server facility, or even host it for you, that has everything installed and ready to go with a few minor tweaks (security authentication, etc). They may even have that locked down with enough pre-installation contact with the client. So, from a client's perspective, after conducting your due diligence on EPM solutions, all you need to do is take delivery of your box and plug/play. Ease of use cannot be understated in this regard and neither can a "clean install". I have seen companies struggle intensely with bad installs, which ultimately has led many to completely reinstall the software. A bad install can haunt you for a very long time. In the future, a customer will simply identify what they want to buy (Hyperion Planning, Hyperion Essbase, HFM, etc) and the servers will show up at their data center, ready to go. There's just something beautifully elegant about preconfigured hardware and software, particularly when they are engineered to go together (if you don't understand what I mean...look at Apple and their suite of products which unite software and hardware).

2. Reduced strain on infrastructure related issues

• Now that we have EPM in a box, we can expect that infrastructure related issues with the hardware/software should begin to subside in a material way. Today, we constantly see issues with upgrades that occur on the server OS which then cause a conflict with the Oracle|Hyperion EPM software and subsequently require the trained eye of an Infrastructure Consultant that specializes in this area. Tomorrow, the hardware will be specifically built to support Oracle|Hyperion EPM. Any changes to the hardware will be tested in advance of release, to be leveraged by the client and thus avoiding conflicts. Infrastructure related issues can be a huge problem for customers as they fight to keep their end users happy. End users tend to really enjoy the rich analysis that Oracle|Hyperion EPM offers and they place the system at the center of their daily activities. Any downtime is frowned upon and can reduce end user satisfaction quickly.

3. Improved scalabilty

• Today, there are hardware guidelines provided Oracle depending on the Oracle|Hyperion EPM software tools purchased, however, there is this grey area of what to recommend for large scale deployments. Don't get me wrong, no other EPM system, and I REALLY mean no other, can scale the way that Oracle|Hyperion EPM can scale. However, when recommending hardware to a client, certain variables such as user counts, etc must be factored in. Most of the time, consultants will use the Oracle guidelines as a proxy for recommendations and combine that with their own experience. In the future, this new "purpose built" hardware may render experience and recommendations irrelevant. Plainly stated, if you are buying Oracle|Hyperion Planning with full use Essbase and you are rolling this out to 1,000 users, well, your software will arrive preconfigured to work with the right amount of hardware for that task. I love it...let's hope it happens.

4. Tighter integration with...well, just about everything

• Without question, the key benefit I can foresee to clients lies in the ability to unite the organization from a technology perspective. Think about it: start at the top with strategic planning tools like Hyperion Strategic Finance to set out goals and model high level future movements in the business, then use Hyperion Planning to take this down to a detailed level, only to be supported by seamless drill thru functionality to E-Business Suite, which will be linked tightly with demand planning tools like Demantra, etc. In theory, a customer could have set of Oracle|Sun servers completely built out to support their entire supply chain from Design to Manufacturing to Financial Consolidations and Reporting. Today, these systems exist in various capacities, often linked via a hodgepodge of servers throughout the company (and, heaven forbid, with the use of Excel-macros, etc). I know of consultants that have built entire careers designing, building and maintaining data interfaces. Data interfaces can be a huge burden on any organization and tighter integration of the entire Oracle stack, thanks to good hardware/software engineering via the Sun acquisition, can really put a significant dent into this area. This is a huge competitive difference when you think about the longevity, sustainability, and maintenance of the system.

5. Countless other benefits that I have missed...

Obviously I have simplified things greatly.  The bottom line is that the Sun acquisition is good for Oracle and good for Oracle|Hyperion EPM.  Stay tuned.  I'm sure Larry and Co. will be unveiling more and more innovation related to this deal over the next few months...

Uh Oh, Your EPM Project is in Trouble...What Should You Do?

First, let me say openly, it happens.  Yes, Enterprise Performance Management projects do occasionally go the "wrong" way, leaving a trail of tears, blown budgets, and irate Executive Sponsors.  Most research shows that IT projects (please realize that I consider EPM projects to be much more than IT projects but this is the best data point we have) have a 60% to 75% chance of falling short of expectations, which is just a nice way of saying that they fail.  So, the odds are against you before key stroke number one.  If someone tells you that they have never had a project go awry, they either have very little true experience or they are lying to you.  If a consulting firm tells you something along those lines, run...run like the wind and don't look back.

If you are in the middle of a bad project, keep reading.  If you are in the middle of a good project, keep reading.  If you are about to start a project, keep reading.  If you are perfect, without failure, and have an affinity to walk on water, hit Starbucks and buy yourself a well deserved cup of coffee.  

Now that I have everyone's attention, here are my top three recommendations on what to do if your EPM project is taking a turn for the worst.

1.   Don't Panic.  Stop and Think.

Generally reserved for personal emergency situations, this recommendation cannot be understated within a project based business world.  Your external project manager has just informed you that all key metrics involving scope, dollars, and time (the Consulting Trinity) are currently out of control and will only get worse.  It would be very easy to panic here, but instead now is the time to stop and think.  Realize that a physical reaction does not exist which will make the situation any different.  Jump, yell, throw a pen, slam your computer, it doesn't make any difference and you only make yourself look rather ridiculous in front of your colleagues, and they will remember this.

Instead, stay calm and consider the levers that you have to pull.  Every project has levers including people, cost, time, scope, expectations, etc.  I will describe how to do this in points 2 and 3 below but in the meantime, poise counts in this situation, and you would be well served to ingrain that in your thinking now.  And on another note, I know it may seem like the wrong time, but remember that you are about to have an extremely valuable experience.  In my opinion, almost anyone can handle a good situation, but it takes an extraordinary individual to deal with a bad business situation.  Navigate this field of land mines well and tough situations begin to look easy...and become the type of professional Executives value the most...people like them, frankly.

2.    Figure Out What to do Internally

• Identify the key internal players
• There are typically two players here: the internal players and the external players.  Internally, there is a key set of people that really matter to the project.  Usually, these individuals include the project sponsor (usually an Executive) and the end users, both of which are expecting you to get this project done with them in mind.  The project sponsor wants the project completed within the allotted dollars and probably isn't so time sensitive and the end users are more time sensitive and care less about the project budget.  Either way, you've got a problem and a formidable audience but not all participants are created equal.  Some have power and others have less power.  Figure out who has power and focus on them (a no-brainer, I know but you would be surprised what I have seen over the years).  Then...
• Talk to the those with power and influence and reset expectations
• Be honest.  Be brutally honest.  Paint the true picture of what is occurring, but also create a proposed plan of action to get the situation resolved.  Do not show up empty handed...you better have a proposed plan, but stress the "proposed" part.  You are there to explain the situation, sell your plan, and solicit feedback, which will ultimately get you the support you need.  If the project scope grew, say that.  If the consulting team is failing, say that.  If you need more money, say that.
• Only go to the well once...go twice and suffer a professional death
• Whatever you ask for must be more than sufficient to get the job done.  Your first instinct will be to sugarcoat the real numbers and timeline required to finish the project.  Resist all temptations to do this.  Put the real numbers and timeline out there.  Be fearless in this regard.  At the same time, you will need to introduce a new level of oversight to ensure this does not happen again.  Your plan should outline this new set of controls that will guarantee success.  Yes, I said guarantee, because, barring a sponsor driven expansion of scope/dollars, you only get to do this once.  Do it twice and you've lost all credibility and should probably get a job that isn't so project driven.
• Now that you have the funds and extended time, over communicate
• Ok, hotshot, you've successfully navigated the internal team.  Now is not the time to take a few days off and count your blessings.  Whip your team into shape.  Be merciless with deadlines and dollars.  Drop by the executive sponsor's office for 5 minutes at least once a week and let him know that you are pushing your hardest to get the job done.  Let him know your plan is working.  If your plan is not working, let him/her know that too.

3.    Figure Out What to do Externally

• Is it really the consulting team's fault?
• Chances are that you are working with an external consulting team that focuses on EPM.  Clearly the situation has not gone as you envisioned and the EPM utopia expressed within the consulting team's PowerPoint deck now seems like a slow trek thru the bowels of Hades.  But is it their fault?  Only you can make this assessment but I would strongly encourage you to be candid about this.  Do not simply use the consulting firm as a scapegoat.  That may solve your internal problem (everyone loves to hang the consultants...come on, admit it, it's fun) but in the long run, switching out the consultants for unfounded reasons only increases the cost to your company.  If the consulting team has held up their end of the bargain, be honest about that and be thankful that you have a consulting partner that has performed.  This is a valuable, and rare commodity.    That said, if the situation stems from actions taken, or not taken, by your consulting partner, you must confront them.  Demand an explanation.  Demand a remedy.  Determine whether or not the relationship is good for your company.
• If it is the consulting team's fault...
• Don't be afraid to switch the team out for another team.  Look, if it really is their fault, unless you are exceedingly close to finishing the project, it is likely that the actions will be repeated.  I am risking professional exile here, but there really are firms that have a "change order" strategy for their business.  This means that they will bid your project at a low dollar amount to win your business, then they will bank on change orders (requests/approval for more money and time) being processed.  Firms like this are counting on you to fear changing them out.  The mindset is: you've come this far with us, you will be hesitant to make any changes, so open up the checkbook.  If you feel this is what is occurring, I will say it again...run...run like the wind.
• What to look for in a replacement for the consulting team
• Some say that the definition of insanity is to do the same thing every time and expect a different outcome.  There's a great deal of truth in that and quite relevant when selecting a new consulting partner.  If you are set on switching out the consulting team, be sure to do your diligence on new prospects.  Look for a firm that has the type of client references you would respect.  Tell them about the situation you just faced and ask them how they would have dealt with it.  Be frank with new prospects.  Let them know that the stakes are high because you've asked for more money and time, and we all know you only get to do that once.  As a consulting professional, I hate to say this, but perhaps a financial holdback (some % of the billing fee) is in order place some skin in the game.  That may make sense and can create more urgency, etc.  But of all the traits to look for in your new consulting partner, I would submit that you need an expert that actually has turnaround experience.  Find someone that really has dealt with really bad project situations and literally turned them around.  Kind of like you just did (by following the rules within this invaluable blog...:)).  Find someone like you.

So there you have it, a quick and dirty primer on how to deal with a the EPM version of the Titanic.  I've hit the high points but have definitely skipped a lot due to time constraints.  If you have any questions or want additional insights, feel free to email me at tantunez@percentix.com.

CFO Question: So how many reports should I have in my organization?

Let's use the 80/20 rule today. 

In the hundreds of meetings I have had with CFO's, VP's of Finance, Financial Planning Manager's, etc there is one question that seems to strike fear into their respective hearts: how many reports should we have?  I suppose the reason for this is twofold.  First, given the simplicity of the question, Executives worry that the number they provide will be either too large or too small.  Secondly, Executives worry that they will be ridiculed if they provide an answer of "I don't know".  So, I'll give you the Economist's answers: it depends...but we can provide a good range for most situations.  Clearly the differences between organizations drive varied reporting needs, however, if we narrow the question a bit, without diluting the end goal, we can provide some fairly good rules of thumb. 

In the end, enterprise performance management is about managing the business, and it is not about reporting.  If we isolate the true management of the business, using the CFO's perspective as our proxy for report volume, I believe we can provide much better guidance.  In my experience, a typical CFO, and his or her direct reports, can effectively manage 80% of the business operation with the use of 10 to 20 reports.  Within these 10 to 20 reports, using EPM technology, a finance professional can analyze various cost centers, roll ups, etc with extreme precision and accuracy.  Relying on more than 10 to 20 reports suggests an overuse of technology and a misunderstanding of the core business.

The remaining 20% of the business can be analyzed and managed using ad hoc reporting tools and databases.  Now, be sure to pay attention to these "outlier" reports because they will lay the foundation for new ways in which to analyze the numbers.  Analysts are extremely crafty and resourceful, often mining millions of rows of data to secure a new insight into the business.  Quite iterative, this process will yield new reports that take into account market changes, competitive movement, etc AND will also reveal holes in your current data, which is to say some of the data required to manage the changing nature of your business does not exist because it is not currently recorded...which can lead to changes in the underlying ERP system. 

So, use the 80/20 rule with respect to reporting.  Don't' let anyone lead you to believe that you must build thousands of reports simply because the technology can do so a bit more quickly.  It's smart business and will save you a great deal of pain and effort in the long run.

Are You A Chief Financial Officer Thinking About Enterprise Performance Management? 5 Keys to Success for CFO’s

I've spent the better part of 8 years working with CFO's, VP's of Finance, Corporate Controllers, FP&A Managers, etc on Enterprise Performance Management (EPM) related initiatives.  Spanning verticals ranging from metals and mining to retail to medical devices, the keys to success from a CFO's perspective remain the same, in my opinion.  Initially, there is a tendency to "over think" what needs to be done, coupled with a deep admiration for the technical sophistication EPM tools have acquired over the years.  And although my clients differ in their core businesses, the keys to success, as well as the levers of failure, remain relatively constant.

One key point to keep in mind about this blog, it will not be focused on tips and tricks for administrators or how to build a better calculation (there are plenty of blogs about this).  Instead, this is a blog meant for Executives contemplating an EPM solution or managing an existing EPM solution.  This blog will be business focused because that is where the true value of these systems lies.

So here is a quick primer, admittedly based on both my successes and failures, that will assist CFO's considering EPM solutions or CFO's with existing EPM/Budgeting, Planning, and Forecasting deployments that have not met expectations. 

Top 5 Keys to Success for CFO's Considering EPM Solutions and Software

1.  The most important investment you will make is not in EPM software. 

Perhaps this is the consultant bias in me but there is no question that an accurate diagnosis of where you want to go is required. Sometimes referred to as "visioning" or "diagnosis", CFO's should expect to spend anywhere between $50,000 to $500,000 (depending on the size of the contemplated deployment) analyzing the basics. As rudimentary as this sounds, it is rarely done. More often than not, there is a race to buy the "technology", ostensibly fueled by demonstrations that cause even the most seasoned of CFO's to superimpose their organization into a prebuilt software demo. My preliminary estimates conclude that companies which do not conduct a thorough up front analysis typically spend a factor of 2 to 3 times the original financial estimate. Lastly, be extremely wary of consulting firms that provide you with a fixed bid or "rock solid" estimate of implementation costs without going thru an initial diagnosis phase. Most EPM firms will skip the initial step because they are more attuned to dealing with the technical components of an implementation. 

2. Your data is probably not as good as you think. 

I know what you are doing to say: "I've spent all of this money on ERP systems and consulting and my data is probably not right?". Well, it's a bit more complex than that but suffice it to say that most companies have actually increased the amount of manual excel data manipulation that occurs outside of the ERP system post-ERP implementation. The reason for this is simple, ERP systems are great at processing millions of transactions quickly but are not made for business analysis. Good financial analysts get around this by dumping data into Excel and creating robust models. Many clients struggle with getting clean financial data (actual data and metadata - think cost centers, product categories, etc) into their financial planning or consolidation systems. And the stakes are high. Bringing a EPM system into a production environment is difficult enough, but to bring a system online with actual data that is incorrect is the single quickest way to lose end user confidence and acceptance. So, think about your data before embarking on an EPM implementation. A good firm will never overlook this critical point.

3.  Face the reinvestment realization and manage it.

Over the course of nearly a decade, I have seen that the reinvestment realization component of EPM is often ignored by Senior Executives primarily because of the incremental financial cost. Here's the harsh truth, two things are sure to change over time: the way a company reviews/analyzes/plans for the business and the underlying technology. For most companies, these changes occur within a 3 to 5 year period but there are companies that are inherently so dynamic that they will fundamentally change their forecasting/budgeting methodologies annually. These business changes will lead to material changes in the EPM deployment, which of course will lead to incremental costs in time and money. Similarly, expect newer and enhanced versions of the software to surface every 1 to 2 years. EPM technology is constantly changing and I strongly advise my clients to seriously consider upgrades every 1 to 2 years. Although this might sound like overkill it really saves clients a great deal of pain in the long run. The longer you postpone an upgrade, the more difficult it will become to upgrade from technical and business perspective. These are sophisticated tools and should be treated as such. I have seen upgrades postponed for 5 years, which ultimately led to a much more difficult upgrade path for the client.

4. Projects tend to have challenges at the beginning...and definitely at the end (Change Management/Deploy). 

I briefly addressed the challenges faced at the beginning of project in point 1: lack of investment in diagnosis. Clients are probably tired of hearing me say this but I believe that is a singular truth. In the middle of a project there is a "heads down" mentality increases the difficulty required to identify problem areas. To be sure, the "build", or middle portion of the project, is creating true value that end users can utilize to manage the business. However, EPM projects have historically had a rough track record with respect to Change Management. Why? Too much focus on technology. Plain and simple. Make sure you spend, at a minimum, as much time and money on the final stage (Deploy - testing/training/documentation, etc) of the project as you do on the initial stages (Diagnosis and Design) of a project. Do not make the mistake of rolling a system that has been partially tested and give end users every opportunity to receive proper training sessions. I know this sounds simple, but again, much like the diagnosis phase of a project, it is often overlooked because so much effort is spent on the build phase.

5. Focus on three key themes: Simplification, Standardization, and Communication.

The best EPM projects are "about" something. In my opinion, if project team members, at the highest and lowest levels, cannot explain what the project will achieve in one sentence, you probably have a problem. After numerous engagements across various industries, I have found that simplification, standardization, and communication are three key themes that really drive to the heart of a truly world class EPM project. A quick chat on each:

• Simplification - Simplification does not mean your EPM solution will not be sophisticated, and in fact, I would strongly argue the contrary. Over engineered EPM systems, and believe me there are many of these, represent a fundamental lack of understanding. It is much easier to compensate for this lack of understanding with high powered calculations or fancy dashboards than it is to truly ask the right questions of Executives and end users. Within your EPM project, look to simplify the most critical business points: create simple models that accurately reflect the business, design a system that is intuitive, remove manual data entry and use driver based planning, eliminate useless reports, etc. For every part of the system, you must always ask "how can this be made simpler?" because a process can typically be made simpler, but discovering how this can be done is more difficult than it sounds.

 

• Standardization - To really have an impact with EPM you must standardize. The efficiency gains reaped from standardization are, by most studies, within the 15% to 35% range depending on the circumstances. Standardization takes many forms but the most basic are data definitions/naming conventions, look and feel, modeling techniques, global business drivers, etc. Again, you are probably surprised that I am stressing this point but, in my experience, even the best of companies forget this point for a number of reasons.

 

• Communication - So much of EPM is centered on communication. Focus on process for just a second: if you are a corporate department managing the budgeting/forecasting process across the enterprise, consider how much time you spend communicating dates, submission rules, guidelines, etc to your end users. I spent a few years as an FP&A Manager at Toshiba Semiconductor and can fully appreciate how much time is spent on such tasks. With EPM, you can eliminate a great deal of the overlapping and repetitious communication that occurs on a daily basis with your end users. Stress to your team the importance of using the system as a communication tool.