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 in 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 Data Model
• Separate view for Baseline Volume planning KPIs
• Promotions at a 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 the same business plan
• Shortened deployment cycle for enhancements – fewer objects to touch and retest

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

 

What is the Simplified Data Model?

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

Figure 1: A preview of CBP-plan utilizing Simplified Data Model:

 

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 compliant 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 number-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.

Figure 2: High-level comparison of objects from our labs’ system

 

b. The simplified data model also takes advantage of the “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).

Table 1: Scenario – “Non Overlapping” Plan

 

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 happens on the fly as part of the Simplified Data Model

• • 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

Figure 3: Scenario – the need for some of the planning functions has been eliminated

 

c. Number of planning functions significantly reduced

Table 2: Comparison betweeen number of planning functions

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

 

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

Table 3: Comparison betweeen need for data storage

 

General Q&A on the Simplified Data Model

 

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