The biggest challenge facing the standard BW content is not knowing which scenario it will cater to (since most of the content can potential cater to multiple scenarios) leading to a very bottom up design approach where the source system data model is faithfully replicated into the BW side. Now this in turn results in modifications (copy and change) of the original content, sometimes up to 80% in an implementation at the customer end.

On the other hand, as part of the EPM suite, SAP Spend Performance Management (SPM) is designed top-down. This is possible because the exact end user scenario is known (which is Procurement Analytics). And the benefit for the customer is that there is hardly any customization involved (under 20%) to the SPM data model. In fact there are a large number of implementations without a single modification in place to the SPM data model. Extraction customization on the other hand is dependent on the customizations made to the source system.

But there are occasions where customizations are needed. And in this case, the flexibility of the SPM architecture comes to your aid. As you will see, there are numerous loose couplings within the application to enable for rapid implementation time customizations.

Here are some of the key ‘loose’ coupling points:

·         The Extractor Starter Kit

·         Inbound

·         Data model

·         Data mgmt.

·         Reporting

Flexibility of Data Extraction: SPM application has its own data extractor starter kit (explained in this wiki) which helps in getting a jump start in data extraction. This is a highly customizable/configurable framework. You could add new fields to existing extractors, add custom code for each field or add brand new extractors on this starter kit framework.

Flexibility of Data Enrichment: Data enrichment (normalization, classification and cleansing of data) enables higher level insight into the data. This is an additional services provided by SAP. Customers are also free to go with a service provider of their choice.

Flexibility of source systems: The SPM application is not tied to SAP source systems. In fact the SPM application is architected ground up, keeping multiple source systems (SAP and non-SAP) in mind and is only loosely coupled to the SAP source systems.

Because of this you could bring in data from any source systems. It is best to match the fields to the SPM inbound data specifications (defined in “Master data for Spend Performance Management.xls” and “Transaction data for Spend Performance Management.xls” in service market place) to simplify the process or you could use the template mechanism to map the non matching field names in SPM data mgmt.

Flexibility of data load:

i.                     BW Data sources Vs Flat Files: SPM application allows for both BW data source and flat file based data loads. The choice depends on various factors, for on premise installations using BW data sources for SAP source systems is the best practice. For hosted solutions OR for external data (like market/commodity pricing information) OR for bringing data from non SAP source systems, flat files are the best way.

ii.                   Data Flow options for loading enriched data: Explained in detail in this article Spend Analytics.

iii.                  Data Load mechanisms: Explained in detail in this article here.

iv.                 Custom Data: Customer specific master data and transaction data can be uploaded into the SPM application. Here is a SPM Customization Series: Loading data in Customer Defined Dimension detailing how to load customer defined data into SPM.

v.                   Source system dependence config: Because of all this flexibility on the source system data, the uniqueness of records needs to be taken into proper consideration. This configuration is explained in Upload Types in SPM blog post.

Flexibility of custom fields: SPM has about 15 custom dimensions available for use by the customer for “any” dimension that is not already included in the data model. These dimensions are obviously shared (they have to be) across various SPM objects like Invoice, Contract and Purchase Order etc….
There are also numerous custom measures (Amount type, Quantity type and Number type) provided for the individual objects.

Flexibility of Data Model: In case there is a need for extending the data model, the overall application structure allows for this kind of flexibility. You could add new master data or new DSOs and cubes and extend the existing queries, by including it in the multiprovider (0ASA_MP01) or by creating brand new queries.

Flexibility of UI coupling with BW: The BW queries are loosely coupled to the SPM UI and this process is data driven. When the queries are extended because of addition of new dimensions or new measures or new objects, all that needs to happen is a refresh of metadata (triggered in the UI) and the back end changes get taken over by the SPM UI.

Flexibility of Ad-Hoc reporting: Although SPM comes with somewhere in the range of 140 out of the box scenario specific reports. The empowerment of creating ad-hoc reports by the business user is a key feature of the application. And strong content management facilities within the application help advance the ad-hoc reporting capabilities.

Flexibility of linking to external applications at runtime: Any URL based external resource can be wired up to the SPM UI by simply configuring the URL and mapping the parameters. And then this becomes a related application link available from any relevant report.

So as you can clearly see, despite the strong out-of-the-box offering, the SPM application is truly flexible on all fronts (starting from data extraction all the way to reporting) and can be made to bring about a custom fit based on the implementation needs!

The Spend Performance Management (SPM) data model already covers all the necessary dimensions for the Procurement Analytics scenarios. In addition to the Procurement specific dimensions there is a provision for 15 additional custom dimensions shared across all the SPM analytical objects (like Invoice, Contracts etc…).

But even with these built in provisions there can be a need for having additional customer defined dimensions. So how would you go about adding such a dimension and loading data in SPM?

Let’s take a ‘make believe’ example. Let’s say that we want to add a Spend Quality Dimension. Let’s call this characteristic infoobject as ZXASPENDQ. And in this example, the characteristic does not have any attributes (although it could just as easily have them) but is enabled for texts.

Now let’s create this infoobject. Make sure to turn on the texts flag and leave the Master Data flag as checked. And then activate the infoobject (make sure to attach it to a transport if needs to be delivered thru the system landscape).

Next step is to create a test file (csv format with semicolon as separator and double quotes as escape character). SPM also supports BW datasources to load data on top of the flat file based mechanism, for our example the flat file would suffice.

To load this file in SPM, first this new upload type must be registered in the table OPMDM_TYPES. Go ahead and do so, use the following values. The target type is “IOBJ” for infoobject (“DSO” if it’s a data store for loading transaction data). The target name is the infoobject tech name, the upload group is “MDAT” for master data. Feel free to ignore the rest of the fields except for the last one. Just set it to “XSA”.

Additional details can be found at Upload Types in SPM and Source System Independence considerations during data load in SPM.

Save the new entry.Additionally, in the text table, OPMDM_TYPEST, make the text entry for internationalized view.

And now you are set to load data for this customer defined dimension/attribute and you can proceed to use the SPM Data Mgmt. Tool for loading our data file into this infoobject. And that’s it!

(For more details on how to use the data mgmt. tool, refer to the following documentation in this location (link). Go to the 2.1 documentation and open up the Application Help >> Data Management.)