There is no SAP S/4HANA without SAP Business Partner

It is probably the topic in the SAP world that currently occupies companies the most: the conversion to the latest ERP generation SAP S/4HANA. But before you can migrate, there are a few mandatory tasks to complete. One of these is the introduction of SAP Business Partner as the central master data object for all natural and legal persons with whom a company has a business relationship.

Harmonize customers and suppliers under SAP Business Partner

Prerequisite for the migration

With regard to SAP S/4HANA, SAP Business Partner enjoys a high status: without him, a migration to SAP S/4HANA is not possible. Companies must therefore have already introduced the Business Partner before they can start their actual system conversion to SAP S/4HANA.

With the Business Partner as the central master data object, SAP is also carrying out a fundamental change in the data structure of the ERP system. In previous versions, there were different data pools for customers, suppliers and employees. SAP S/4HANA is designed to enable a higher degree of process automation. To achieve this, it is necessary to bring the various roles more closely together, since there is often overlap – for example, a company can be a supplier and customer at the same time. The SAP Business Partner ensures the consistency of the master data by assigning the corresponding roles as customer and/or vendor to the same master data object.

Customer-vendor integration

The conversion to SAP Business Partner must be carried out before the S/4HANA conversion in the ERP system. The functionality that links SAP Business Partner with the customer and/or vendor master records is called customer-vendor integration (CVI). During the initial conversion, the Business Partner is generated via the CVI. During operation, the CVI keeps the basic data between the business partner and the customer/vendor synchronous.

In SAP S/4HANA the Business Partner is the leading master data object. This means that the basic data is maintained in the Business Partner and transferred to the objects customer and vendor. In the ERP system, on the other hand, companies still have the choice and can continue to maintain customers and vendors, while the Business Partner only runs technically in the background.

What are the concrete reasons for initially running the Business Partner in ERP only technically in the background? On the one hand, this can delay the necessary training for the Business Partner; the users initially maintain the master data in the familiar transactions. Another important point is that in the ERP release the complete field and function scope is not yet available in the Business Partner maintenance – the full functionality is only available under SAP S/4HANA. In practice, it must therefore be evaluated on the basis of the concrete requirements in the company whether the business partner can already be used in ERP as a leading object in maintenance.

Step by step to SAP Business Partner

The implementation of SAP Business Partner is carried out in several stages. It usually starts with a workshop in which the participants define the exact design and concept of the Business Partner. The following questions, among others, are relevant: What scenarios are there? Which account groups are in use? How can numbering be mapped within the Business Partner so that it interacts optimally with customer/vendor numbering?

From a technical point of view, the first step is to implement the relevant SAP notes. Depending on the support package level of the ERP system, this can be more or less. Importing the notes is a necessary prerequisite for SAP Business Partner and creates the optimal basis for its implementation. This is followed by the implementation of the customizing for the Business Partner and the CVI. This step is mainly concerned with the mapping between the account groups and the Business Partner world, which was determined during the concept definition.

With clean data to higher acceptance

Data cleansing is one of the largest blocks in the changeover, whereby a distinction must be made between mandatory and optional topics. Cleansing data inconsistencies is one of the mandatory tasks in order to be able to technically generate the Business Partners. Further checks such as the duplicate check and an address validation are not mandatory, but they do make sense in order to start the business partner era with really clean data.

Clean data is an important prerequisite for user acceptance of SAP Business Partner. The search for duplicates in the customer and supplier data should not only be carried out within the respective dataset, but also across the entire company. This is the only way to determine where links between customers and suppliers are missing – with negative consequences for SAP Business Partner. If a link between customer and supplier is missing, the system creates two business partners from the same company and thus a duplicate. If the user department is hindered in its work by a large number of duplicates after the conversion, the willingness to adapt to the new data structure decreases.

Companies often underestimate the effort that data cleansing requires. They should give appropriate priority to data cleansing and involve not only IT but also the business department. In general, the rule of thumb is: The longer the ERP system has been in use, the more errors are likely to occur during data cleansing. The reason for this is that, for example, mandatory fields, customizing settings and checking rules have changed over the years. IBsolution offers data cleansing with duplicate check and address cleansing at a fixed price.

From training to activation

To be able to use SAP Business Partner effectively, employees must be trained in the use of the new master data object. The scope of the training depends on whether a company is already converting data maintenance in ERP to the Business Partner. If it does, not only the IT colleagues but also the end users must be trained in time.

Before companies activate SAP Business Partner in the production system, they should perform several test runs in the various test systems. A common recommendation is to perform at least two test conversions  for example, on a sandbox test environment and the QA system. After all, nobody can know in advance exactly how many data inconsistencies the system will produce.