<img src="https://certify.alexametrics.com/atrk.gif?account=3HHNq1DlQy20Y8" style="display:none" height="1" width="1" alt="">
Businessman-reading-a-newspaper-000070585809_Large_cropped_again.png

SAP BPC & EPM
Thought Leadership

3 Reasons You Will Be Happy With BPC

Posted by
David Den Boer
David Den Boer
on Tue, Sep 10, 2013 @ 09:09 AM
Find me on:

EPM BPC AssistanceAt the Apollo temple in Delphi (Greece), an ancient quote is carved in stone, alternately translated as "Nothing in excess" or "All things in moderation". This is a great credo to live by as we all know what excess can bring, especially if we think about things that may seem to be good at the outset. In life, we can think of things like food, wine, and even work that - when managed in small quantities are indeed good things, but when taken to excess, they can become destructive.
It should come as no surprise that BPC is a lot like this. As a flexible and powerful tool, BPC can be a highly valuable catalyst of transformation for your enterprise. For the very same reasons, however, it can be a very frustrating experience when implemented improperly . When a system with the expectations that BPC has fails to deliver frustration abounds. Since Apollo is not available to divinely influence your BPC implementation, you'll have to settle for reading my advice.

In the last 6 months, Column5 has done more application reviews for clients seeking to improve their BPC foundation than since the company was founded in 2005. Why is this? Recurring threads indicate several common root causes. We will list 3 of the most common complaints and their root causes. This is an overview of the same guidance we give our clients.

1.) Performance - "It's too slow!" Over the many years we have worked with software solutions, one can imagine that the formula for user satisfaction can be expressed thusly: P-(P*10%) = Column5 EPM BPC Consultants where P = current performance, and Column5 EPM BPC Consultants = customer satisfaction. In other words, no matter how fast the solution's going, if it were going 10% faster, users say they would be happy. Unfortunately, the next day you test it (which is 90% of Day 1) and the expectation returns. "It's too slow!" Don't get me wrong, I do empathize with the users who genuinely have performance problems, but there are plenty out there who complain simply because they can about any system. For those, it's important to establish a realistic and very specific "pass/fail" test. Gain agreement that if the system performs at 'x' speed, users will be happy. Let's assume expectations were set up front, and continue to focus on the users who are not experiencing performance that meets those expectations.

We routinely get calls from customers asking to improve another partner's implementation that isn't performing quite right. Typically, we walk in after the client has gone live and executives are receiving complaints from users about the time certain steps take in the system. The request is to "speed up the system" with a week's worth (or very short time frame anyway) of consulting. Of course, the elephant in the room must be addressed.

How did we get here? What causes performance to be poor? (Hint: it isn't as simple as finding a check box being unchecked, usually) Performance is the manifestation of every single decision made in the project leading up to the performance test. What implementation partner did you select? What was the scope of the solution you developed? How did you scale the hardware and software environment? Who performed the integration with the platform? How were business rules created? Who defined the user navigation path? Were best practice standards employed? Who tested the system? How trained are your users?

When you consider all the things that "could" go wrong, you will be surprised you managed to go live if you didn't think of all these steps in the process while the implementation was starting. The temptation is to blame the software as if the system is fatally flawed with bad code and its inherently slow. I am here to tell you, this notion is completely false. Implemented properly, the system has excellent performance, as many happy customers can (and do) personally attest to. So why is this not your experience?

A proper implementation starts with choosing the right partner. A good partner knows how to resist the temptation to cut corners  when they know doing so will increase the risk for a performance problem down stream. A good partner will push back on inappropriate scope, will develop to best practices and will thoroughly test the system to ensure performance is optimized. Anyone who suggests such steps are unnecessary is flirting with a performance problem.

What to do if you're experiencing a BPC performance problem right now? Performance challenges are caused by layers of bad decisions...and all of those contributing factors must be identified. Column5 offers a comprehensive evaluation of your current state. We examine your system top to bottom and give detailed recommendations that our clients can often implement largely on their own. More importantly, we give you the knowledge on how the system SHOULD be approached and how to avoid falling into such challenges in the future.  If you are researching how to get more value from your product or how to stabilize and enhance your experience, we recommend scheduling an Application Assessment.

2.) User Friendliness - "It's too hard to use!" This one is hard to believe, but its out there. Most users know that BPC has an incredibly easy to use and vastly popular primary interface - Excel. Fewer users are aware that there are actually many choices on how to interact with BPC data. There are web clients (several interact with BPC directly), native "book" publication that supports HTML, PDF, and other formats, compatibility with Microsoft Office programs like PowerPoint and Word (in addition to Excel), mobility solutions, and multiple BI tools can all access BPC data, so its hard to believe any informed customers could legitimately believe BPC is hard to use based on the interface. In reality, the flexibility knows no bounds. Since this asset can also be a liability, invoking our friend Apollo again is required.

Some customers go to wild excess with the interfaces. The top reason cited by the user as justification for over-engineering interfaces is that we "need to make the reports (or planning templates) look exactly like the old ones, or the users won't use it". The unsuspecting junior consultant will likely fall for this every time. They may jump through hoops to fulfill this request, and in so doing create a monster. We will find Visual Basic, lookups, dynamic formatting and all kinds of clutter embedded in the Excel that makes operating a report a nightmare. BPC's interfaces include completely native Excel and support every capability Excel does. Here's a spin on Apollo, "Just because you can, doesn't mean you should!"

BPC users have to realize they bought the market's leading EPM solution to solve business problems. No matter what system their users had prior to the purchase, this is an upgrade, or it should be! BPC can't achieve that promise if the decision was made to hang all the requirements (many borne of legacy limitations) of your old system/approach around BPC's neck like a millstone. Consider a more change management friendly approach, and educate those users to be BPC advocates. Help them understand how they can write dynamic reports on their own to do the analysis they need. They will gravitate towards the best practice reports if this is done correctly!

When it comes to "hard to use" - another trend we have seen lately is solutions left by weaker consultants  have some serious limitations embedded in them. An example: Complex logic is embedded in the spreadsheet. BPC comes with a robust calculation engine that can do just about any single calculation. For some reason, some consultants never learned how to leverage this powerful feature, and they default to putting logic in the spreadsheet. Either they write verbose cell based formulas, or they embed "black box" VBA in the workbook. A telltale symptom is that users have to constantly open spreadsheets when there are updates to key drivers (like global rates), hit refresh, then send in the updated results. No wonder users say the system is hard to use in such a case!

If your consultant is telling you information that doesn't sound right, get a second opinion. Our goal is to demystify this solution, and equip our clients with an independent ability to expand the solution. If you get only one consultant to offer "solutions", and that consultant is either uneducated to the highest level or uninterested in truly solving a problem (rather than padding his bank account), then there will undoubtedly be additional concerns in the future. At that point your system may be so convoluted that an entire rebuild is needed.

3.) Administration ability - "It's too hard to maintain!" Another common complaint is the maintenance profile. Depending on the implementation party's skill level, the solution left in your environment may contain very sophisticated capabilities. The question is, did the developers leave simple interfaces with a logical process to effectively maintain the system? Sadly, most do not. Most "BPC experts" cut corners and develop "black boxes" because its what they know, and not a system best practice.

You've got a solution that's showing its age, and you want to upgrade. You inadvertently hire the wrong resource to do the work and wind up in a worse place than you began. It actually happens all the time. This image is from a Spanish cathedral with a priceless work of art. The church hired an unqualified person to do the restoration work, and was left with a frustrating result. To avoid such disasters, and suboptimal results, call Column5, the EPM experts.

Column5 holds EPM events frequently, and one user interaction from more than a year ago stands out. We were presenting on the proper way to configure a consolidation solution including parameters being set within easy to use maintenance interfaces which the system implements automatically. A user in the back row shot their hand up. "We use BPC for consolidations, and we use intercompany eliminations...but you keep talking like there's a feature in the system that handles this for me. Our consultants implemented this in a series of 20 spreadsheets and our close process is to open each spreadsheet and keep sending in eliminating entries until they all balance. If you're now telling me there's a built in feature that makes it so I only have to push one button to do all my interco entries as part of the close, I am going to be so happy!"

Can you imagine? If this is how your system works, rest assured "you're doing it wrong". Yet this is the output of "consultants" actively competing for your business.

That's the bottom line. If your experience with BPC is such that you believe it has "performance problems", it's "too hard to use" and it's "hard to maintain"; it's not the system but the implementation of that system. You should be contacting Column5 to seek out a better way. Your organization does not have to function like this and what you are experiencing is not at all the "norm" with BPC. It is the consequences of many bad decisions throughout the implementation process. We can help you recover from those missteps starting today.

Webcast: Latest SAP EPM Roadmap

Interested in learning more about the planned innovations and future direction that SAP has up their sleeves? Join Column5 and SAP’s Pras Chatterjee for an informative discussion on the updated roadmap for BPC and EPM including BusinessObjects Cloud.

view webcast

Related Articles:

11 Dirty Secrets of EPM Projects

Organizational Change Management in EPM & BPC Implementations

Death of the Budget - Long Live the Rolling Forecast

SAP BW-IP, SAP BPC NW 10.1 Standard and SAP BPC NW 10.1 Embedded Compared

 

 

Topics: Best Practices, Performance, Implementation

Subscribe

Recent Posts

Posts by Topic

see all