General presentation

Objective of the application

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.

List of contacts

• Functional Owner: Marc Piret (Sustainable Development & Energy (SDE) 

• IS Reporting Leader: Diogo Paiva (IS Supply Chain M&S Data)
• BW Developer: Laressa Moretti (SBS IS) 

Usage information

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

History

The project had 2 phases:

1 - First development covering most of the GBUs (pilot: Aroma and Special Chem)  

link to the project folder: https://drive.google.com/drive/folders/0BxkySrtHryoBejV1VG5CbmNwM3c

2 - Extension for GBU Specialty Polymers and Composite Materials 

link to the project folder: https://drive.google.com/drive/folders/18bJbaF-EfKSDfYl5X1uWe25xiwa99ClU

Roles & Access

Roles and access

List of application role + menu role  and explanation if we have several applications role with specials rules.

Authorization objects

List of autorisation objects mandatory for the application.

Dataflow overview

Link to dataflow presentation: 

The InfoArea where SPM is located is IA_SD_SPM.

There is one MultiProvider named MVSDSP01.

Functional and Technical rules on Workbench + Reporting

Rules & Explanations

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

Aquisition of data

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.

The Sub-Activity field (0G_CWWE01) is very important to define the GBU and Group of Activities.

From Rhodia query, it gets directly field 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).

Transformation of data (Derivation of SPM characteristics)

Some mapping tables were created in WBP with maintenance views (restricted to very few users).

The access is done via transaction ZSPM in WBP.

There are basically 3 steps:

1) Derive SPM product

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:

1. Search with complete key = GBU + Group of act + Sub-act + Line 2 + Line 0 + Com.prod
2. If not found, search with GBU + Group of act + Sub-act + Line 2 + Line 0 + Com.prod = space
3. If not found, search with GBU + Group of act + Sub-act + Line 2 + Line 0 = space + Com.prod = space
4. and so on ... until the search is done only with GBU + Group of act.

2) Derive SPM PAC (Application)

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

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.

3) Recalculate SPM product 

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).

List of SPM mapping tables

In terms of the data flow, this is where these lookups are implemented

Dependencies with other applications

Dependencies with other application (BW, QV, Externals tools like PVelocity or Dynasis etc...

Data loadings

Info providers and objects loaded

Detail of process chain, list + link between or special event done for the loading

Loading frequency

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, only for reload (they execute the APDs for reload mentioned before)

Average performance

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

Record Keeping

Give details if any historisation is done, example: keep only data greater than beginning of Y-3

Keep current year + 3 previous years.

Reporting

Queries End User Documentation

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.

Main queries

List the most important and complex queries only with a link to the documentation

Main functionalities

Give detail on all complex functionalities: list most important and/or complex KPI, query jump, alerts

Broadcast

Indicate if there are broadcasts and give some details on the broadcast settings.

Maintenance

Known bugs

Give the list and explanation on the known, not-solved, bugs.

Recurring procedure

List recurring procedures

Planned Evolution

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