SPM stands for "Sustainability Portfolio Management". It's a Solvay proprietary approach to assess business sustainability risks and opportunities that runs on PF7.
The objective of SPM reporting in BW is to provide a "Sustainability view" (Market Alignment, Operations Vulnerability) for the sales of the group.
Sales are extracted from P&L in WBP and then enhanced with an SPM dimension, through a sequence of steps (lookup in mapping tables).
SPM Master Data (SPM Product, SPM Application) is loaded from PF7.
Final report is in QlikView dashboards.
Functional Owner: Jean-Francois Goupillier (previously Marc Piret)
How many users? Which user category ? Is there critical period ? Which geographical perimeter? Describe in one sentence: around 50 users, worldwide or 200 users / European Site
2017 - First development covering most of the GBUs (pilot: Aroma and Special Chem)
link to the project folder: https://drive.google.com/drive/folders/0BxkySrtHryoBejV1VG5CbmNwM3c
2018 - Extension for GBU Specialty Polymers and Composite Materials
link to the project folder: https://drive.google.com/drive/folders/18bJbaF-EfKSDfYl5X1uWe25xiwa99ClU
June/2021 - Project SPM Improvements (will be detailed hereafter)
List of application role + menu role and explanation if we have several applications role with specials rules.
| Role Code | Role Description | Explanation |
|---|---|---|
| ZBI_RCS_SPM_A01 | Sustainable Portfolio Management - End User Role | Role for the application |
| ZR_RCS_CA_M58 | SPM - Sustainable Portfolio Management | Role menu for the application |
List of authorization objects mandatory for the application.
| Authorization object | Explanation |
|---|---|
| CPFCTR1_2 | GBU |
The InfoArea where SPM is located is IA_SD_SPM.
There is one MultiProvider named MVSDSP01.
Detail of main topics with explanations of the rules and only the main + special rules about queries to run and use in the correct way
Sales data is loaded from P&L using APDs.
The APDs load current + previous month into Direct Update DSOs, then it goes to the next level DSOs, which keep all historical sales (allowing a complete recalculation of SPM data every day).
The Sub-Activity field (0G_CWWE01) is very important to define the GBU and Group of Activities.
From Rhodia query, it gets directly field C_TECMAT-0G_CWWE01 (normally IECRAxxx)
From Solvay query, (due to PQ1 decomission and SpS projects), it gets from different fields depending on the month being loaded. It takes C_TECHBA (old object from PQ1) if month < 01/2018 (kept for reloading purposes) and from C_TECPCT2 if month >= 01/2018. In any case, it takes the attribute C_REST_BA (Restated BA) and move to 0G_CWWE01 (single object in the query for both legacies).
Example:
List of APDs:
(The last 2 APDs are not scheduled on a regular basis. They were created for reloading purpose, allowing to inform the period to be loaded in the query variant).
Some mapping tables were created in WBP with maintenance views (restricted to very few users).
The access is done via transaction ZSPM in WBP.
Update on June/2021
There are basically 3 steps:
For Rhodia Legacy - based on GBU / Group of Activities / Sub-Activity / Product Line 2 / Product Line 0 / Commercial Product
For Solvay Legacy - based on GBU / Group of Activities / Sub-Activity / PIF hierarchy / Product hierarchy / Material Group
Example:
How it's stored in mapping table
How the derivation is done from a sales record
Important: the lookup in the mapping tables is done from the most specific case (complete key) to the most generic case, so for example, when reading ZSPM_TAB1 to get SPM product, it does the following:
Update on June/2021 -
The SPM product can now be defined by informing directly GBU + com.prod (in ZSPM_TAB1) or GBU + mat.group (in ZSPM_TAB2)
For both legacies, based on SPM product obtained in step 1 + End-Use fields (Market, Application, Segment, End-Use)
Example:
How it's stored in mapping table
How the derivation is done from a sales record
Update on June/2021 -
In order to assign SPM PAC, the user can inform directly the End-Use, without having to inform Market / Application / Segment in table ZSPM_TAB3.
C_GBR14 was replaced by the new C_GBR34.
Multiple PACs
We can have multiple PACs assigned to the same combination of GBU + SPM prod + End-Use. In that case, the percentage field will define the split to be done among several PACs, so the routine takes into account this percentage in order to allocate the sales.
There are some cases, (for example in Novecare for Agro with "Formulations & Blends" ), that we must overwrite the SPM product derived in step 1 with the SPM product obtained directly from SPM PAC master data, because it splits in 3 different PACs in table 3, with a different product assigned to each PAC.
So this "recalculation" was implemented in a recursive transformation into DSOs DBSDSP02 (Rhodia) and DBSDSP04 (Solvay).
In terms of the data flow, this is where these lookups are implemented
| Table | View | Description | Comment |
|---|---|---|---|
| ZSPM_TAB1 | ZSPM_V1 | SPM Product (Rhodia) | |
| ZSPM_TAB2 | ZSPM_V2 | SPM Product (Solvay) | |
| ZSPM_TAB3 | ZSPM_V3 | SPM Applications | |
| ZSPM_TAB4 | ZSPM_V4 | SPM End-Use to Market (SPP) | Specific to GBU Specialty Polymers |
| ZSPM_TAB5 | ZSPM_V5 | SPM Applications (SPP) | Specific to GBU Specialty Polymers |
| ZSPM_TAB6 | ZSPM_V6 | SPM Non-integrated GBUs | Only for GBUs where sales doesn't come from P&L |
Update on June/2021:
The specific objects developed for SpP described below were decomissioned as SpP started to use the Corporate End-Use in GBR.
For GBU Specialty Polymers, sales figures are loaded normally from P&L (sales in PF1) and the derivation of SPM product (step 1) follows the normal SPM flow.
The only difference is in the PAC derivation (step 2) since Specialty Polymers doesn't use the "Corporate End-Use" (C_GBR14).
They maintain their own End-Use information in Sales Force, so some new objects were created in BW to load this data from Sales Force.
New InfoObjects
C_SFEU1 is loaded with the existing End-Use values in SalesForce (code + text) from an excel file
And then updated with attributes below, which are maintained in WBP in table ZSPM_TAB4.
So this table ZSPM_TAB4 was created to map the SalesForce End-Use with Corporate "Market / Segment / Application"
Regarding the End-Use link with the customer, in the case of SalesForce, it's done by the sold-to (and not ship-to). Actually, it's done for a SF account ID that can map to N sold-to codes. Also, the product level can vary, can be done at material group (commercial product) or product hierarchy.
So we have the following rules into C_SFEU2:
Example of data received from SF (directory /exploit/BW/SPM) and the mapping of SF account to sold-to via table ZSF_SOLDTOS
For SPM PAC derivation, there is table ZSPM_TAB5, which assigns a PAC based on GBU + SPM Prod + SF End-Use (C_SFEU1).
Finally, in SPM query, attributes Market / Segment / Application come from different objects depending on the GBU
For Composite Materials (and potentially any other GBU not integrated in WP1/PF1 yet), it was developed a "light", temporary solution, where the sales are informed manually, in an aggregated way.
So in table ZSPM_TAB6, user can inform the sales amount directly at this level: by GBU, month, SPM product, SPM PAC, Corporate Group and Corporate End-Use.
Since SPM Product and PAC are manually informed, there are no derivations in this case and the data goes straightforward to cube CRSDSP90, to be combined with the other cubes in MVSDSP01.
Sales amounts must be informed in EUR. There is no quantity (volume) information, and no detail on customer/material.
Update on June/2021 - New source for SPM Master Data is WPE (replacing PF7)
Dependencies with other application (BW, QV, Externals tools like PVelocity or Dynasis etc...
Detail of process chain, list + link between or special event done for the loading
Detail of frequency : monthly; weekly or else
PC SPM_MAIN is scheduled daily at 05:00 (CET).
The following PCs do not run on a regular basis. They are used only to reload historical data
They execute the corresponding APDs,
So for example, if we need to reload P&L data for Rhodia (WP1) for 2018, just update the variant in RSRT as follows and trigger the PC to reload.
This will take data up to business layer, then it will go the cubes with the regular daily load.
if possible, give some information on average process chain duration, amount of data loaded and total data volume example: daily process chain loaded in 30 min, weekly chain loaded in 1h15, with around 2k to 10k lines in DELTA mode for a total of 10M lines in cube. The purpose is to give a general overview of the volume of data managed y the application
| Key Figure | Estimation |
|---|---|
| ~ Average Process Chain Runtime | 35 minutes |
| ~ Average nb of rows loaded per load | |
| ~ Total nb of rows loaded (if full) | |
| ~ Average Runtime for 10k lines |
Give details if any historisation is done, example: keep only data greater than beginning of Y-3
SPM keeps current year + 3 previous years.
This is controlled with a routine in the DTPs into DSOs DBSDSP01 (Rhodia) and DBSDSP03 (Solvay)
Query end user documentation should be created in the public "Customer Support Wiki" space under the corresponding BW application page : BW - Application. Technical query query documentation, if necessary should be added as a sub-page of this documentation using the BW Technical Query Documentation template.
List the most important and complex queries only with a link to the documentation
Queries:
Give detail on all complex functionalities: list most important and/or complex KPI, query jump, alerts
Indicate if there are broadcasts and give some details on the broadcast settings.
Give the list and explanation on the known, not-solved, bugs.
List recurring procedures
Detail planned major evolution if already known. Example: complete decommissioning of application is planned in 2017 / Extension to solvay perimeter planned in 2nd semester of 2016