Skip to Content
Product Information

SAP’s Simplified Datamodel Represents a Paradigm Shift for SAP Trade Management Architecture (4.0 FP03)

Introduction

SAP Trade Management is an Integrated, holistic Trade Management solution that enables a coordinated business process for field sales to create account-specified plans aimed at maximizing profitability that fully integrates with S&OP, Supply Chain Management, Finance, etc.

There are 3 major components to SAP’s Trade Management Solution:

·         SAP Trade Promotion Planning and Management

·         SAP Customer Business Planning

·         SAP Advanced Trade Management Analytics

 

The ‘technical components’ are TMAC 4.0 (installed on SAP CRM) and TMAB 4.0 (installed on BWonHANA). More information can be found at SAP Trade Management .

SAP has released the latest version of TMAC/TMAB -Ver 4.0 FP03 in September 2019. This edition brings a plethora of new features.

Some of these are listed below:

  • Simplified Datamodel
  • Separate view for Baseline Volume planning KPIs
  • Promotions at lower level of customer hierarchy than plan
  • Possibility to simultaneously edit more than one promotion linked to same business plan
  • M:N relationship between long-term agreement and short-term promotion
  • Redesigned Product Replacement Tool
  • Enhancements to PMDC (Pertinent master data changes)
  • Fewer planning or background/update jobs to be executed
  • Parallel processing of promotions assigned to the same plan

What does this mean for business?

  • The implementation time can be greatly reduced – for instance we got this content running in our labs in 1 week and plan to use it to drive blueprint workshops at one of our ongoing projects.
  • Improved offline and, to a certain extent, online performance by using real-time calculations
  • Simultaneously edit more than one promotion linked to same business plan
  • Shortened deployment cycle for enhancements – fewer objects to touch and retest

 

We have installed the new feature pack in TekLink labs environment to evaluate and understand the new features. In this blog I will cover the “Simplified datamodel”. This, in my opinion, is the cornerstone of the release. This new architecture allows many features.  One key feature is now the ability of -multiple users to edit promotions assigned to the same plan.

What is the Simplified Datamodel?

As the name suggests, it is all about “Simplicity”.  The new architecture consists of BW/4 HANA complaint object types and representing a new approach to rolling up promotions to plan.

Here is a preview of CBP-plan utilizing Simplified Datamodel:

 

Some Key Benefits include:

  1. Simplified BW data model with fewer objects
  2. Simplified implementation for customers by reducing dependency on planning functions
  3. Need for redundant data storage is minimized, thereby reducing sizing for customers

 

Customers can derive enormous value in terms of lowered TCO and implementation cost. The new-architecture consists of BW/4 HANA complaint object types paving the path for future TMAB-addon for BW/4 HANA offering (in very crude terms BW/4 HANA (new codeline) is to BW on HANA what S/4 is to ECC-on-HANA).

1.    Simplified BW data model with fewer objects

The paradigm shift is the use of ‘real-time’ roll-up instead of planning functions. The model consists of modern objects – “HANA composite provider”, “HANA calculation views” and “Advanced datastore objects” in place of legacy DSO objects. The new architecture allows the solution to achieve the same functionality with fewer BW objects.

Here is high level comparison of objects from our labs system.

a)       The no-of-objects that require maintenance significantly reduced – mostly “Planning infrastructure” –

Key Benefit: Aggregation levels reduced from about 25 to 15, indirectly a reduction in planning functions.

 

b)    The simplified datamodel also takes advantage of “query simplification concept” introduced in FP02.

Key Benefit: only 6 BW queries instead of 19!

 

This above math is for only one of the scenarios – “non overlapping plans”. In a real-implementation you can expect at least 3-such ‘profiles’ (overlapping plans, non-overlapping plans, FISCAL period view..) – which would result in a benefit of 57 Queries (legacy) vs. 18 (Simplified).

Type of Plan Query Categorization No. of Queries – Legacy datamodel No. of Queries – Simplified datamodel

Normal Plan

(Non-Overlapping Plans)

TU Views 6 1
CU Views 6 1
NU Views 4 1
Summary TU 3 3
Total 19 6

 

2.    Simplified implementation by reducing dependency on planning functions

The architecture is based on modern objects – “HANA composite provider” and “HANA calculation views”. This enables:

a)     Most calculations that require CBP and promotion plan data happen on the fly as part of the Simplified Datamodel

  • Example: if you change the uplift, the cost of the promotion is calculated with the plan data read on the fly using a calculation view
  • Example: if you make a change to the baseline in CBP, the promotion cost is re-calculated on the fly using the new baseline

b)    Many Calculations moved to the views, reduced dependency on calculations in planning functions

 

In the above figure for instance the need for some of the planning functions has been eliminated

c)     Number of planning functions significantly reduced

Evaluation criteria

No. of planning functions

 in legacy – model

No. of planning functions

 in Simplified model

Integrated planning profile

 JBPS (legacy) vs. SIDM (simplified)

 

20*

 

10

No of RSCRM_EVENTCUST entries (i.e. assigning queries to planning functions) – for Normal Plan (Non-Overlapping plans)

 

Over 250 entries

 

20-30 entries

*this is an approximate no., TPO & other functions excluded from legacy datamodel for comparability

3.    Need for redundant data storage is minimized, thereby reducing sizing for customers

 

Evaluation criteria Legacy – model Simplified model
Dual storage of Actuals data Physically make a copy of “Actuals” data to CBP-Plan DSO Read Actuals-data in BW-query
Dual storage of Reference data Physically make a copy of “Actuals” data to CBP-Plan DSO Read reference-data in BW-query

 

General Q&A on the Simplified Datamodel

 

Q: Can the Simplified Datamodel and legacy Datamodel co-exist?

A: The answer is yes. In “standard out-of-box”, the configuration has to be set at “Sales organization level”. A given Sales-Organization can use either “Simplified model” or “legacy” – this restriction can probably be lifted by coding SAP provided BAdIs. The constraint on Sales organization should not matter for new implementations. For customers already using CBP, a detailed analysis is necessary to chart out the migration path.

Q: Why is SAP moving to HANA views and aDSOs?

A: Many of the new features – such as real-time roll-up of promotions created at a lower-level of customer than plan, editing of multiple promotions belonging to same plan simultaneously etc. would have been difficult to achieve without the new architecture. aDSOs and HANA views are objects supported in BW/4 HANA, making that migration possible in the future. There are numerous advantages of using aDSO instead of DSO, explanation of this is out of purview of this blog.

Q: How do we add new KPIs and calculations?

A: The basic method remains the same. Copy the content objects, add your logic to planning functions, changes to HANA views etc. based on specific business needs.

Q: Are there any constraints?

A: SAP has listed a few constraints such as planning only in “TU view” in “delivered content”. It is conceivable that you might be able to overcome these in your custom implementation.

Q: How is promotion planning changing?

A: Query simplification doesn’t apply to promotion object. However, use of HANA view brings with it many advancements– such as roll-up of Long-term promotion rates in short-term promotions, n:m relation between LTA and Short-term promotions etc.

Q: Main advantages from IT standpoint?

A: From an IT standpoint the reduction in planning function and no-of-objects will make implementation cycles shorter and bring in cost-savings in the long run for supporting the solution. Example – it will be less disruptive to add new key-figures to actuals-aDSO as the planning-aDSO doesn’t have to be changed in this scenario.

About the Author

Arvind Bhaskar is a VP at TekLink International Inc. and Chief Architect of TekLink’s Trade Management Practice.  He has played the role of SME and Architect in multiple CBP and TPM projects including Parmalat, CSM Bakery, Affinity Petcare, Conagra Brands and Kellogg’s. In addition to being architecturally and strategically focused, Arvind remains very product ‘hands-on’ working with SAP solutions over the last 20 years. He holds an MBA in Analytical Finance from Chicago Booth.

 

 

 

 

 

 

 

 

 

 

 

 

 

Be the first to leave a comment
You must be Logged on to comment or reply to a post.