SAP PCM to SAP FS-PER conversion - up close and personal (part 1)

3 November 2017

Steve Mainprize

Steve Mainprize

Consultant

Are you currently running SAP Profitability and Cost Management (PCM) and considering making the move to SAP Performance Management (FS-PER)?  Steve Mainprize, SAP PCM expert, gets up close and personal with one of the first PCM to FS-PER conversions in the world.

Recently I’ve been working with MSG Global Solutions and Nexontis Consulting, the SAP Partners that developed FS-PER. We’ve been talking with a customer that has been using PCM for many years to allocate their costs, in the traditional PCM way, and wanted to find out how a real-life PCM model could be converted into an FS-PER model. As far as we are aware, this is the first time that anyone has attempted to convert a PCM model of this complexity into FS-PER.
 

Approach and objective  

Our objective was to discover how easy, or difficult, it was to convert a PCM model to FS-PER, and to confirm the expected performance gains of FS-PER. I’ll talk more about performance in a future post, but here I’ll focus on the work that was done to convert the model from the existing tool to the new one.

The PCM model we worked with was reasonably typical, in that it followed the three standard steps of Activity-Based Costing (ABC):
  1. Allocation of resources to Activities, based on Resource Drivers;
  2. Iterative reallocation of service costs from one Responsibility Center to Responsibility Center;
  3. Allocation of Activities to Cost Object dimensions.
We did as direct a conversion of the PCM model as possible, mapping the dimensions as modelled in PCM directly to fields in FS-PER, not considering how the dimensions might be more effectively remodelled in FS-PER.  We followed this approach because our objective was to understand what was generally involved in converting from PCM to FS-PER, rather than doing the optimal conversion for this specific PCM model.

If converting a particular PCM model to FS-PER, we would approach this differently. PCM’s dimensions are predefined, so it’s not unusual for a PCM model builder to use the dimensions in imaginative ways, such as:
  • concatenating two or more natural dimensions into a single PCM dimension, or
  • using a single dimension for more than one purpose, or
  • establishing an implied relationship between two dimensions by way of a naming convention.
In our case, one of the PCM dimensions was in fact the concatenation of what would ideally have been three separate dimensions.

In FS-PER, you have complete flexibility to define the dimensions that you want. So, in a real-world conversion from PCM to FS-PER, you wouldn’t rebuild the FS-PER model to exactly match the PCM model. You would instead choose whatever dimensions you needed to model the business problem.
 

What our PCM model looked like

Here are some other features of the PCM model that should be noted:
  • Our PCM model only had a single version and a single period, so we omitted those dimensions from the FS-PER model.
  • Our PCM model had two Cost Object dimensions, so we only implemented two Cost Object dimensions in our FS-PER model.
  • Our PCM model included a number of Activity Driver rules; we didn’t implement those at all in the FS-PER model. Instead, we just transferred the calculated PCM Activity Driver Values results to FS-PER.
  • There were no complex overrides in the PCM model.
I wrote up a set of specifications and guidelines for the FS-PER team. About 80% of the functionality that I described was “core PCM” functionality, and the rest was specific to the particular model. I also provided them with the data and structure tables from the PCM model, as comma-separated values (CSV) files.
 

Building the FS-PER model

The FS-PER team addressed the conversion in four phases. The first phase was to load the PCM data and structure into FS-PER, and the remaining phases corresponded to the three standard steps of Activity-Based Costing (ABC), as above.
Loading the PCM data and structure was easy, and took only a matter of hours. The first allocation phase, in which costs are allocated to activities using resource drivers, was completed in a day.

The step that was hardest of all to implement was the activity reassignment, primarily because it requires that the allocation tool iterates until all the reassignments are completed. Another complication was that the allocation paths here are dependent on dimension hierarchies.

The FS-PER team managed to complete the activity reassignment within a week. FS-PER allows control logic to be placed around the calculation steps, and it was this feature that allowed them, with a bit of exploration and investigation, to build the iterative reassignments. 

We had to reorganise the hierarchies a little to adapt them for FS-PER. The hierarchies in PCM are stored as parent-child relationships, but the team found it more useful to rearrange the hierarchies in FS-PER into a multi-level structure. This made it easier for FS-PER to identify the leaf-level nodes from a given parent; in PCM, assignments are often made to group dimension members, with costs being then assigned to the descendants of those groups. Developing this approach to hierarchies was useful, as it could later be re-used in the Cost Object Assignment.

The team took a further week to complete the Cost Object Assignment. It’s probably worth repeating that the conversion that the team performed was very specific to this particular PCM model. The FS-PER model was built to handle exactly two Cost Object dimensions, with only three possible orders:
  • to both Cost Objects in a single step or
  • to Cost Object 1, then (Cost Object 1 and Cost Object 2), or 
  • to Cost Object 2, then (Cost Object 1 and Cost Object 2). 
All Cost Object Assignments were by Responsibility Center. This massively simplified the number of possible scenarios, compared to the number of options in PCM. Allowing for overrides, non-overrides and variable configurations of cost object assignments would make the problem much more complicated. 

For any model, including this one, there usually are a limited number of different cost object assignments, but it does imply that the Cost Object Assignment step in FS-PER is likely to be developed from scratch in each model, compared to PCM where the tool would provide you with all the possible combinations as standard. 

This isn’t necessarily an unsurmountable problem, but it means that an FS-PER implementation is likely to be more rigid, and some changes that you might want to make in your model later, particularly changing allocation paths and an increase in the number of dimensions, are likely to be more difficult in FS-PER.
 

Rule-based calculations

We didn’t attempt to replicate the PCM rules engine, which allows the model to calculate (for example) drivers based on other input data. This would be really expensive to attempt within the scope of this work, and so we just used the rules-based PCM driver values as data in the FS-PER model. In a real-life FS-PER solution, a similar approach might well be needed, with pre-calculated results being provided as input data to FS-PER.

Fundamentally, this is because FS-PER models are strictly relational, but PCM models include relational and multidimensional structures. In a relational environment, it is very difficult to replicate the program structures and cross-table, cross-dimension relationships that are native to the PCM rules engine.


Lessons learned

I think it would be great in future if the FS-PER developers could supply some sample content based around PCM in particular, or Activity Based Costing in general.  I’d imagine this as a set of basic building blocks that illustrate how to approach the ABC methodology, which the modellers could adapt to their own requirements.  It would be useful to have as sample content because this basic content would be very similar for all ABC models in FS-PER, and it would avoid every new implementation having to reinvent the wheel.

I don’t believe it’s a good plan to build a conversion tool that takes a PCM model and converts it into an FS-PER model. Although every PCM model runs on the same basic rails, almost every PCM model bends the product enough that no single conversion process is going to be able to derive an FS-PER model from a PCM model. With FS-PER not being “officially” a PCM replacement, SAP doesn’t consider that it has an obligation to provide such an upgrade path.
 

Further reading

Keep an eye out for Steve’s next insight where he’ll be looking at the performance aspects of this piece of work, and discussing how taking advantage of FS-PER’s speed might be truly transformational for cost allocation projects. If you are still considering the options available to you when PCM goes out of maintenance click here for the low down.
 

About the author

Steve Mainprize

Consultant