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!
