Version Control

VersionDateDescriptionAuthor
v.116.04.2021CreationJosiane Peytraud

1. General overview

On the GBU Segmentation, there is an information named GBU Segment. The list of possible values depends on the GBU.

Core CRM is the master of this information. It's then sent to SAP with a job which runs every 4 hours.
In CRM Analytics, the displayed GBU segment is directly taken in CRM and not from SAP. As any other information, those information are extracted one a night.

Only Data Steward, Admin and Admin(Lite) are able to update the GBU Segment.

Linked to this information, there are 2 others:


2. GBU Segment

2.1 When creating an account

When creating an account, a record is automatically created in the object GBU Segmentation with:

2.2 When assigning a corporate group to an account

When assigning a corporate group to an account:

2.3 When changing the GBU segment at Corporate Group

When changing the GBU Segment at Corporate group level, the GBU Segment of all the accounts assigned to this corporate group is automatically changed except is the check box “Do not cascade from the corporate” is ticked.

2.4 When changing the GBU segment at Account

For those who are able to update the GBU segment, 

Each time a GBU Segment is changed,

Every 4 hours, a job selects all the records with those ticked checkboxes. For each selected account, if it's not a Prospect and not a ship-to, so if it is a SAP Account sold-to, it searches all the sales views corresponding to the GBU in the Account Team Member (ATM) object and sends the new value to SAP if the sales view doesn't have the checkbox "Do not Send to SAP" ticked in Utility. We send the API name of the GBU Segment and not the value. So if we "just" rename a value, nothing to be done on WebMethods side, only on CRM and SAP.

3. Utility

All the sales views are defined in the object Utility, record type "Sales View" with the following information:

Each time an update is done on the sales view of an account in SAP, a job requires Core CRM to get the corresponding GBU Segment. To do so, the program first check what is the corresponding GBU in utility, then "goes" to the GBU segmentation to get the information.
If the sales view doesn't exist in Utility, a notification is sent to sbs-is-crm.support@solvay.com and the information is stored in a log.
When a sales view is added in the object Utility, a job checks if this sales view is listed in the log, and if yes, for each concerned account, sends the GBU Segment to SAP.

4. Account Team Member (ATM) - Custom object

On the ATM object, there is a field GBU. This field is updated with the night job which updates the SAP Account team. 
For each account created or updated, SAP sends the list of all the sales views. For each of them, based on what is set up in utility, we determine the GBU.

5. Challenging Process

Generally, the review of the GBU Segment is done in mass once a year. But for exceptional reasons, it can happen that a sales manager needs to change it. But as he can’t do that himself, we’ve put in place a challenging process (Approval process).
On the GBU segmentation, there is an option to request a change named “Challenge GBU Segment”.
This option is available on the GBU Segmentation (so for Accounts) and on the Corporate GBU Segmentation (for Corporate Groups).

For GBU Segmentation, so at Account level:

For Corporate GBU Segmentation, so at Corporate Group level: no specific check. The approval request is possible.

6. Analytics

On analytics, the GBU Segment information is taken from Core CRM. But they are not able to get the value. They are extracting the API Name of the picklist. So a mapping table has been set up on QV side.

If we change a value in the GBU Segment picklist, we need to ask QlikView team to update the mapping table they have set between our API Names and the values to display.

7. Useful links

CEM Customer Segmentation Implementation Playbook V2

CEM - Integration Specifications (SAP Interfaces)