We had this NPI concern shared by some of our customers, so we wrapped our head around a solution. Feel free to comment and suggest improvement, your input is always appreciated!

This article is also available on our blog. For more stuff on IBP and SAP supply chain solutions, click here! 

Introduction

A common challenge in an integrated IBP/ERP environment is the new product introduction (NPI) process. The problem lies in the fact that the planning activities for a new product may occur long before it is even created in the core ERP system. Of course, if products are created simultaneously in ERP and IBP thanks to a proper Master Data Management process, what follows is not a concern.

In fact, creating and planning the new product in IBP only is not an issue. The question is: how can we ensure a smooth data reconciliation between IBP and ERP? Manual interventions are often chosen as a workaround solution, but it can quickly turn into a mess.

As far as we know, there is currently no standard functionality in IBP that covers NPI special requirements. This paper is intended to demonstrate how we can easily overcome, with IBP flexibility and Hana Cloud Integration (HCI) capabilities, two common issues related to NPI: the creation of a new product, and then the integration with ERP.

Preliminary notes:

1. We are not addressing the problematic of product substitution, neither Like Modeling, Interchangeability or Supersession.

2. The logic described below could be applied to any other master data type, i.e. for new customers planning.

3. For purpose of explanation, we will make reference to SAP ECC all through this paper, but it could have been replaced by any other ERP system or SAP application.

Standard IBP Model

In a typical IBP planning model, the master data object product relies on a unique key indicator, the product identifier. As proposed by SAP in their out-of-the-box models, this ID is generally sourced from ECC and is mapped against the material number.

This basic data structure becomes troublesome when we have to create the product in IBP prior to ECC. One basic solution would be to temporarily create a product with a dummy ID, but it would then be impossible to update this identifier since the product ID is a key entry in the database. Obviously, we could manage this manually by deleting the dummy product and recreating a valid entry once the material is created in ECC, but unless related key figures data get extracted and reimported with the new ID, planning data would be lost. And this is not to mention the data manipulation risks and the time needed for such an operation.

Solution Proposal

Trying to keep things as simple as possible, we designed a solution based on two configuration points: a minor master data modification in IBP and a conversion dataflow setup in HCI.

Data Modeling

Basically, what we suggest is to use the existing PRDID attribute as a native IBP product number and to add a new attribute for the ECC material number that we will call MATNR for example.

As in standard models, PRDID is defined as the key attribute, while the new MATNR is just a simple characteristic. MATNR is mandatory, but since it is not a key field, value can (and should) be updated as soon as the ECC material number is known.

Here is a simple view of what value should be maintained for each attribute, depending on the scenario that applies at the time the product gets created in IBP.

Scenario 1 is mostly relevant for initial mass upload in IBP during a project cutover, while scenarios 2 and 3 are part of a day-to-day product introduction process in IBP. 

More concretely, for IBP end users, the new product introduction involves the following:

1. The planner first creates the product in the IBP database with a dummy ID. This dummy ID is registered in both PRDID field and MATNR field.

2. Once the product is created in ECC, the planner updates the MATNR with the correct value.  (This activity must become part of the standard product creation process).

3. All Excel planning views and Web UI Analytics must be displayed at MATNR level since this is the more up to date data available.

ID Conversion via HCI

Now, considering that:

• Master Data and Key Figures are extracted from SAP applications with the material number as key indicator;
• Data must be imported in IBP tables based on PRDID key attribute;
• PRDID does not always match the ECC material number;
• IBP planning outputs are exported back to ECC.

We need to configure an ETL process in Hana Cloud Integration (HCI) that will support a two ways integration flow between ECC and IBP.

To import data in IBP, a transformation task is inserted in the HCI process flow in order to link the ECC material number to the corresponding PRDID key attribute.

Doing so, we have to generate an intermediate product IDs conversion table, built directly from IBP product master data and extracted via HCI. The conversion table is made out of two fields, PRDID and its corresponding MATNR.

To allow data transformation, the conversion table must be stored in the same HCI datastore than the data to be converted. It could be stored for example in a custom table developed in ECC, or either as a flat file on a server directory.

Once all data is repatriated in a common datastore, a simple HCI query can convert ECC material number to IBP product ID.

• Both SAP source data and the Conversion table are used as Input to the query.
• A joint between the tables reconciles the IBP PRDID with the data extracted from ECC.

From a more technical perspective, here is a view of the dataflow described above. Keep in mind that this is not an exhaustive table mapping, but rather a rough example with INITIALINVENTORY key figure, just to illustrate in a simple manner how data are extracted from ECC, converted in HCI and loaded in IBP. In this example, the conversion table and ECC data are stored in a common repository. Note that HCI cannot extract data from ECC to a target files datastore. Thus, extraction must to be executed via a scheduled batch job in ECC or with another ETL tool.

Below is the result of such a dataflow, illustrated with a basic dataset.

Finally, to pull data from IBP back to ECC, the same conversion logic applies on reverse mode, i.e. IBP product number is converted to ECC material number. We shall just mention that it is judicious to exclude entries with dummy MATNR (flagged with a special range or prefix) from the query in order to avoid transfer inconsistencies (i.e. when a product ID exists in IBP but not in ECC).

Conclusion

The main benefit of this solution is to be low maintenance. The only manual action involved in all the process is to update the ECC material number in the IBP database once the information is available. Everything else is processed in the background and is totally transparent for end users. And last but not least, estimated efforts and time for implementing this solution are minimal, reflecting the simple configuration approach proposed by IBP.