Automating SAP Profitability and Cost Management – Part 1

6 May 2014

Steve Mainprize

Steve Mainprize

Consultant

SAP Profitability and Cost Management (PCM) is used in different ways in different organisations.  In some, particularly when the organisation is taking its first steps with activity-based cost management, it’s used as a desktop tool, almost on a par with Excel. There might be a couple of people using it, and they make changes as and when circumstances change.

However, as the model’s scope and level of detail increase, and its outputs become more important to the business, the need to industrialise the PCM model and the processes surrounding it becomes apparent.

Automation is a great way of removing risk, streamlining processes, providing an audit trail and freeing key staff up to do what they ought to be doing – making great business decisions.

SAP PCM has a surprising capability for automation that’s not always appreciated. In parts one and two of this blog post series, I’m going to point up some PCM functionality that will help you build robust, repeatable processes around your SAP PCM model. I’ll also give you a few examples of how this can benefit you. Do bear in mind that these are only examples. Almost anything that you can do manually to a PCM model, you can do through automation – with a little imagination and a bit of work.

What’s in the SAP PCM toolkit?

For the purposes of this article, I’ll be looking at how you can combine the following SAP PCM features to automate your models:

  • Books: The default end-user interface for a PCM model. Often used for giving end-users access to the model layout via spreadsheet-like layouts, books can also be programmed to carry out many different functions, including model management. Books can act on a SAP PCM model by making use of PCM Console (see below), but you can also use them to read and write files on your computer. We’ll see how that comes in handy in some of the examples
  • SAP PCM Console: PCM’s scripting tool, which provides a way of defining a sequence of PCM actions to be taken. What SAP PCM Console does when you call it is determined either by a list of parameters that you pass into it, or, for longer sequences, you can give it a file containing the commands that you want to run.  One of the things you can do with PCM Console is run Data Bridge
  • Data Bridge: SAP PCM’s data acquisition tool, which can read data structured in a variety of different ways and use that data to update a PCM model’s structure and data.

Example – Release from development to live

Many SAP PCM users make use of separate environments for development and live running (and sometimes a separate test environment, but for the sake of this example, let’s just stick to development and live).

At some point, it’s going to be necessary to migrate changes from the development environment to the live environment. Moving changes manually is risky and error prone, but you can minimise the risk by building an automated process.

I like to have a separate SAP PCM model that provides change management functionality. Typically this change management model won’t have any modelling structure in it, but will have a set of books.  The books have buttons which, when clicked, run the desired process.  A “release to live” button might, for example, run a PCM Console job to:

  • Log in to the development PCM server
  • Open the development model
  • Export the structure of the development model to an XML file, using a predefined export specification (ESP) file
  • Log in to the live PCM server
  • Open the live model
  • Export the data from the live model to an XML file, using a predefined ESP file
  • Create a new model on the live server
  • Import the structure XML (from the development model) into the new model on the live server
  • Import the data XML (from the previous live model) into the new model on the live server.

We now have a new model on the live server that contains the updated logic from the development model and the same data as the previous live model.

All the above could be done manually, but it’s faster, more convenient and less risky to run the process through an automated process. Furthermore, the SAP PCM Console process can be configured to write to a log file, which provides a useful audit trail that can be referred back to if required.

Tip: to run SAP PCM Console – or any other program – from a book script, you can use the VB Script “Shell” object.  Your code might look something like this:
 


 

Example – Validating data and dealing with new dimension members

On the SAP PCM training courses, a lot of attention’s given to building dimensions; students learn how to add dimension members, how to set up hierarchies and attributes, how to choose consolidation types.  It’s important to understand this stuff, and it’s appropriate for the smaller dimensions, but real-world models frequently have dimensions – typically Activities, Responsibility Centers, Products, Customers and Channels – that are pretty big and difficult to maintain.

In fact, as a dimension gets bigger, it doesn’t just get harder to maintain manually, it gets much harder.  One reason for this is that you’re more likely to be dealing with system codes like customer codes, rather than easily-understood names, so typos and similar errors become more likely.  Another reason is that the rate of change increases.  A dimension with fewer members, like a Version dimension that has “Actual”, “Budget” and “Forecast” members may never need updating, but a dimension with several hundred customers in it is likely to have new members added to it regularly.

At the start of an import into PCM, you can choose whether you want the model to accept or reject data for dimension members that don’t already exist in the model.  If you choose to accept this data, the new members are added to the appropriate dimension automatically.  PCM places them at the end of the hierarchy, below the topmost member.  If the model owner wants the new members to be at a particular place in the hierarchy, she has to move them manually to the appropriate parent.

On the other hand, you can tell PCM to reject records that refer to dimension members that don’t already exist.  Under these conditions, PCM will not add the new dimension members, and after the import will tell you how many records got rejected.  You can look in the log to see the records that were ignored.  From a data management point of view, a lot of systems people would tell you that this option is the better one, all things being equal, because it lets you distinguish between valid data that you do want to load, and bad data that you don’t.

But... some of those rejected records may be perfectly valid, it’s just that the model hasn’t yet been told that those customers should be included.  We need a way to update the model with the latest customers, and if the customer list is being added to frequently, we’d much prefer to let the system handle it for us.

What we need to do is make sure that the model structure contains all appropriate dimension members before the data is loaded.  That way, you can load the data file and reject unrecognised dimension members.  The approach also allows you to automatically incorporate new dimension members into the model at the right point in the hierarchy, and therefore avoid the manual moving of dimension members that was described above.

Suppose we want to automatically update the Cost Object 1 dimension, and suppose that, as is usual, we’re using Cost Object 1 to model products.  Here’s how it might work.

We’ll need the feeder system to provide an additional extract or feed.  Let’s suppose we get this as a CSV, so that we can load it easily via Data Bridge.  This new “product list file” will be specified as having two fields, one of which is the product itself and the other is its parent.

Now we create a Data Bridge import to load the product list file into the model’s PARENTCHILD table (or PARENTCHILD_BULK, if the file has a lot of records).  You can use the Data Bridge wizard to do this, so you don’t need to write any code.

We create a button on a book that runs Data Bridge to firstly import the PARENTCHILD table, and then imports the data file.

When the PARENTCHILD import runs, any products that didn’t previously exist in the model will be added.  Any products that already existed in the model will be retained.  And a nice side-effect of this approach is that, if the product hierarchy has changed, for instance because of a reorganisation, then the model automatically reflects that and, even better, any assignment paths that assign activities to parent cost objects automatically use the new structure as well.

When the data loads, any data for valid new products will be loaded into the model, and any data for any invalid products will be rejected.  This is just what we want.

Tip: You can add further functionality to the button if you want.  For example, we’re expecting two files, one containing the dimension members and one containing the data.  We might write some script behind the button to check that both files are present, and maybe that the last-modified dates of each are within a couple of minutes of each other.  Another idea would be to get the button to archive the files to another folder, once they have been imported to PCM.

Example – Maintaining Model Structure

Suppose we want a simple roll-forward process, whose purpose is to add an extra period to the model

As with a lot of automated processes, you’ll really help yourself by having a consistent naming convention in your model.  Note that this solution relies on having a consistent naming convention for your model.  Let’s take an example, and imagine that out model has the following (quarterly) periods.
 


 

The scenario is that, every quarter, we want to run a process that adds a new period to the model.  Our book script is going to need to: 

  1. Run a PCMConsole job that does the following:
    • Login
    • Open the model
    • Export the PARENTCHILD table to a CSV, selecting the PERIOD table.  You’ll need to create an export specification file for this, but you’ll only need to create it once.
  2. Read line-by-line through the CSV produced by the previous step, and detect the period name that is the most recent, chronologically (i.e. “Q2 2014” in the above table) – here’s where we need some logic that understands the naming convention!
  3. From the previous step, derive the name of the next period (i.e. “Q3 2014”, since the previous last period was “Q2 2014”).
  4. Write the name of the next period to a new text file.
  5. Run a PCMConsole job that does the following:
    • Login
    • Open the model
    • Run Data Bridge to import the text file from step 4.  You’ll need to create a Data Bridge specification file and Data Bridge control file for this, but you’ll only need to create it once.

The effect that this has on the model – adding one new period – is simple enough that you could argue that taking the time to build an automated process isn’t really needed.  But remember that this is just an illustration, and that real-life scenarios are usually more complex.  Also, a real-life roll-forward process might include other features, such as a back-up of the model or a reset of some of the data.

So we’ve discussed three examples of how automation can be applied to a PCM model.  In my next post, I’ll discuss how you can automatically backup your models, transfer data from one part of your model to another, and use books to selectively output data or results from your model.

Bluefin and SAP S/4HANA - welcome to the one horse race