Why are many BPC embedded projects unsuccessful?

Business Planning and Consolidation (BPC) Embedded has been offered by SAP for some time now and yet, general perception in the industry is that many have not achieved the success that they set out to achieve. In this article, I am outlining some of the reasons why some BPC Embedded solutions have not succeeded. The first step is to look at the history of the product.

SAP BPC Embedded: A History

BPC Embedded emerged as a new product when BPC 10.1 was released back in 2014. The Embedded environment was, and still is, only available on the NetWeaver platform that runs on the SAP HANA database. A few months after the initial release, a sub-project was released in the form of BPC Optimised for S4/HANA. This had the same internal workings but came pre-delivered with standard templates that were designed to increase the speed of adoption.

A few years later, in 2016, the Consolidation functionality was released for BPC Embedded and this led to the release of yet another product – BPC Optimised for S4/HANA Real Time Consolidation (RTC). The consolidation engine from BPC Standard was ported to BPC Embedded to provide customers with a single, unified Embedded environment that was capable of doing both Planning and Consolidation more effectively.

Today, when we talk about BPC Embedded, it is important to clarify that more than 90% of the software product is essentially the BW-IP (Business Warehouse – Integrated Planning) solution, the rest consists of specific functionalities from BPC Standard. These include work status, business process flows, and data access profiles. For the consolidation models, the heritage of BPC Standard is slightly more notable thanks to the Business Rule engine for the consolidation logic from Standard.

The backbone of BPC Embedded is BW-IP was released in 2005 and was the primary offering for comprehensive planning from SAP. Interestingly BW-IP was competing with OutlookSoft before SAP bought Outlooksoft in 2007. Later, OutlookSoft was rebranded as BPC and then, with Embedded in the line-up, to BPC Standard. The main appeal of the OutlookSoft product was the balance it achieved between flexibility and complexity. It was far less technically complex that BW-IP and, because of that, it was relatively easy for a professional with a business background to grasp the fundamentals in a short period of time. Professionals with business background and limited technical skills can develop and architect successful solutions and this was, and still is, a key driver for the success stories that sit behind BPC. It is doubtful that the same can be said for BW-IP, even today.

The Benefits of BPC Embedded

So, you’re probably asking why BPC-IP remains a key option in the planning product line-up from SAP if there are limited success stories. Actually, in many cases, it remains a preferred choice over BPC Standard and SAP Analytics Cloud. The reason for this is the numerous benefits that walk hand-in-hand with BPC Embedded. I’m not going to name them all as that would take far too long to read, but the key advantages are:

• Analysis for Office is lighter than EPM add-in workbooks
• A comprehensive toolset of the BW Queries
• Active data locking keeping the data integrity
• Fantastic performance of AMDP/SQL Script logic
• Little to no data redundancy, if done right
• Real-Time access to source data from S4
• Shared master data across the whole BW landscape
• The option of being the Enterprise Reporting tool
• Much nicer user experience in a cross-model environment
• The capability of matrix security
• Out of the box “what if” modelling
• Out of the box comprehensive disaggregation functionality
• Plan on key figures backed by real master data with dropdowns
• Multi-key figure modelling

The Complexity

All these benefits come at a price and this happens to be the higher technical complexity. This stems from the fact that BW-IP uses lower-level components that allow for more flexibility, while most of the BPC Standard components on NetWeaver are mapped to predefined BW objects. There are a few exceptions such as: Member Formulas, Business Process Flows, Consolidation Engine, and Logic Script specific to BPC Standard.

This means that when you build BPC Standard components, you work a level of abstraction higher than BW-IP/BPC Embedded. For example, the BW queries required in BPC Embedded for creating input forms are replaced by one BW query per model in BPC Standard, as set by the system out of the box. Due to that limitation in the query building, BPC Standard has more versatility with EPM add-in.

However, by pushing the functionality from the BW query to a workbook, the system needs to move the primary data processing a layer above. The capabilities of EPM add-in has its benefit in line of business-driven systems, but inevitably makes the EPM add-in heavier. As a result, this affects performance. However, in smaller environments with smaller sets of master and transaction data and light formatting on the workbooks, the difference in performance is immaterial. Similarly, the BPC Standard model creation is quite limited as it is mapped to specific types of BW components. This makes the BPC Standard build engine take decisions on behalf of what has been created in BW. This makes the build process even more straightforward, but it does limit the functionality. For example, you may have a case for a multi-key figure model or planning on key figures backed by master data, rather than just numeric values.

The topic of complexity is more profound than the shared examples above and, admittedly the article has only scratched the surface. However, the main take-away related to a BPC Embedded project should be the higher volume of design decisions and components to be configured compared with BPC Standard. As a result, the price of more flexibility is paid by considerably more complexity.

The Key to Success

Due to the technical complexities, many professionals with business backgrounds struggle to learn it, and to therefore contribute to the design of the BPC Embedded solution. Inevitably, any solution led exclusively by technical people will frequently miss important functionalities and this will then knock on to more development cycles and patching work. The consequence of that includes budget overruns, trade-offs and an unhappy user base.

To mitigate these challenges, it is essential to have both a team with the right blend of skills combined with exceptional communication for the successful implementation of a SAP EPM solution. Efficient collaboration is a critical success factor and often having remote working team mates can prove to be challenging. By default, team members should have in-depth knowledge of the solution based on real life experience. Building comprehensive, lengthy, proof of concepts is helpful, but real project expertise is a significant benefit.

Having business people with technical skills and technical people with business skills. This makes the team members capable of asking the right questions, seeking collaboration in the right moments and contributing substantially to the design of the solution. It is worth emphasising again that the key difference of the Embedded project is the technical proficiency required by the team. I consider the business, project management, soft skills and client involvement just as critical, of course, but they are critical to the success of any project.

“It is essential to have both a team with the right blend of skills combined with exceptional communication for the successful implementation of a SAP EPM solution”

In short, BPC Embedded projects are challenging and complex, but if done successfully they can deliver a lot of value to the users and to the company implementing them. 

Latest Resources