Enterprise Resource Planning Blogs by Members
Gain new perspectives and knowledge about enterprise resource planning in blog posts from community members. Share your own comments and ERP insights today!
cancel
Showing results for 
Search instead for 
Did you mean: 
Paulo_Vitoriano
Active Contributor


The purpose of this blog post is to compare two most common architectures for the extended project management based on SAP PS data.

Naturally SAP PS has a number of functional limitations. To cover these limitations various tools are available on the market.  I will not mention any of them specifically to avoid accusations of being bias or impartial, but instead will try to present an independent evaluation and compare two most common architectures.

First we need to give a definition to the extended project management tool by means of its functionality.

This is very much a best guess of what such solutions may include, because I am not taking any specific products in this review.

I will not list the extended project scheduling functionality here, as normally it would be a standalone function or application due to its complexity.

So, here we go:

1. Extended Cost Forecasting
2. Cost Forecast Phasing
3. Cost Variations/Change Management
4. Accruals Management
5. Extended Cost Planning
6. Extended Progress analysis
7. Extended reporting capabilities
8. Improved usability


When it comes to the system architecture there are two apparent choices: doing it in SAP ECC or doing it outside.  For the "outsiders" the common choice goes for SAP BI or SAP BPC.


Many companies are not exploring a full potential of SAP standard functionality.  None of "vanilla" implementations will reach out to dark corners of SAP PS customizing such as Forecast Workbench to understand what is available and what is not:



Let us get back to main topic and have a closer look at the individual aspects of ECC vs. BPC scenario:

Extended Cost Forecasting.

Most likely the BPC solution will not do any automatic recalculations for FTC value (Forecast to Complete) from one month to another.  Common recalculations that can be done automatically are:

  1. Decreasing the FTC value based on new Actual cost for the period

  2. Automatic roll-forward of phased FTC value to future periods


Even though such logic can be considered as simple and basic it can take a long time to process.  But in ECC it can be scheduled as a background job.


Generic BPC solution normally will include the so called “initializing” step every month, that is for example deleting the FTC value for the current month and forcing business users for manual entry of FTC every month as well as demanding a manual re-phasing.

Cost Variations/Change management.

In the ECC you can take PS Claims functionality as the foundation. That immediately gives you a number of important advantages completely for free and "out of the box". In particular a standard approval workflow, master data linkage to other data objects (that often not available in BI with standard extractors), classification system and all standard reporting for PM notifications. Taking the BPC road you will normally keep the whole thing in BPC and re-develop it from scratch. That is not necessarily a bad thing if final result exceeds the original or is highly specific, but that will come at a price. The problem here is that few companies really do investigate what the standard ECC can provide, but jumping directly into BPC development effort and consulting companies naturally never object such choice. Sometime it takes a single "expert" speaking based on his experience to influence the audience.


Below is the sample Claim screen from the standard SAP ECC:


Accruals management.

When it comes to figures calculated based on Progress version data for example, it is easier to calculate in ECC. In BPC you will normally enter figures manually, because your actual figures are bit outdated and I never seen a Finance department accepting a freeze period for financial postings. So you will need to keep one eye on ECC data to enter your BPC accrual figures. Next they still require a posting into ECC. The process is easier and more under control if you are in ECC already. Taking figures from BPC to ECC requires some manual steps and controls. Probably you will need to generate a flat file and make sure it is posted into ECC. How that status can be tracked back in BPC? What if it is not posted or posted twice? How BPC can recognize accrual postings when they flow overnight as actual cost into BPC and not do the double counting?  There are quite a number of interesting questions around this process.

Improved usability.

BPC provides an Excel interface and not much can be changed around it.  Without HANA you will not get a real-time data, so you keep being dependent on BI extractions and its schedule.  ECC on the other hand provides real-time data without need for HANA and all the classic drill-down options are available. It can be report-report interface from summary figures to line items or a drill-down to the master data. For example to Purchase order detail view. Output forms in ECC are almost unlimited, from the same Excel to classic ALV or PDF.

Another point on usability is that BPC does not “know” what is the current period, what is the previous period. BPC does not have own system variables for such basic characteristics therefore it will be an additional administrative task to maintain such environmental values manually every month.  That demands an extra discipline from the business organization.

In ECC the automatic forecast recalculation functions allow processing for hundreds of projects in a background, minimizing user efforts to update project forecasts. In BPC on the other hand it is always a manual task project by project.

Roles and Authorizations.

ECC solution can use all the standard authorization checks available in SAP PS module. Authorizations concept in BI is quite different and therefore will require a double maintenance or even a specific data model to cover for authorization workarounds. On another hand same workarounds can improve a system performance by dealing with a smaller data cubes.

The data you can trust.

ECC has a real-time data and that says it all. For BPC there is always a time gap.  Time gap is not necessarily a problem if you follow a strict process, so that indeed can be acceptable to some organizations during a month-end process when there is a freeze for actual postings in the current period for early month-end closing.  But no doubt it is an additional complication and demands an extra discipline from the business organization.  The real-time data is important not only for actual cost and commitments, but also for system statuses of WBS-elements for example.  Trying to feed accruals to the locked WBS will fail on the whole file. In ECC the system can flag you the issue immediately.

System performance.

The system performance depends very much on the data model for BPC and on ABAP developer qualification for ECC.  There is no apparent winners or losers for this criteria, but there is a need to test the system on big data volumes and run a number of stress tests.


Now let me tick all the boxes in a summary view. I will use a simple scoring model on the scale from 1 to 5.

ECC Development

BPC based tool

Extended Cost Forecasting

5

3

Cost Variations

4

3

Accruals Management

4

3

Roles and Authorizations

4

3

Performance

N/A

N/A

Usability

5

4

Total:

22

16

If you are lucky within your organization not to be politically engaged with any particular vendor (and I must admit I have not seen yet such organization), then you have a chance taking a healthy choice with open eyes.


One of my SAP contacts shared an interesting opinion on BPC.  He is saying that if your SAP BPC project goes for over 3 months then something wrong must be happening and it means it is not used the way it was designed for.  I would interpret this the way that BPC must be a simple tool, while a common mistake is about reinventing standard functionalities with BPC and making it complex.


Good luck!


9 Comments
Labels in this area