Basically, a business partner is a natural or non-natural person a company is interacting with. This could be a specific account, a contact or also an own employee. Obviously, this leads to an overlap with vendor and customer accounts, as per definition, both are entities affected by similar business activities.
As initially stated, the SAP Business Partner concept isn’t new and wasn’t invented with S/4Hana. The term originates from the SAP CRM area where the Business Partner term and object has already been used well before S/4Hana. In addition, the Business Partner (BP) object is available on classic SAP ECC Systems for the integration of CRM and SRM systems.
For SAP MDG the BP isn’t new as well, as Master Data Governance (MDG) for vendors and customers has been based on the BP concept/technology from the start. The real novelty can be found in SAP truly pushing this approach with S/4Hana and forcing users to use the BP as primary entity to maintain vendors and customers. The BP is not only used for vendors and customers, it rather is the primary object for all entities a company is doing business with.
The design choice makes sense, as all entities have a basic set of required core data which are independent of the real purpose of the BP (e.g. Employee, Vendor, Customer, etc.). This core data consists of mainly general data (name, search term, etc.), addresses and bank details. To differ the purpose of a BP, additional data like a BP Type, Group and Roles can be maintained on this global level.
As already mentioned, the BP is introduced as the primary object for vendors and customers with S/4Hana. The main additional piece to define a BP as a vendor or customer is data from purchasing, sales or finance or further specific data like credit or dunning details. Additional vendor or customer specific data can be placed as well. From a technical standpoint, the data is still placed in the corresponding vendor and customer backend tables via the so-called Customer-Vendor-Integration (CVI). This is also the answer to one of the key questions when thinking about the feasibility of replicating/interfacing to SAP ECC systems: Yes, proprietary interface technologies like IDOC’s are still available and working to connect classical SAP ECC systems.
Moving one step further, the BP concept now provides the possibility of a single BP being vendor and customer at the same time. Both accounts are then linked via the overlying BP. This is one of the major benefits of the approach: the same entity can be centralised in a single “golden record” as the Business Partner acts as primary object regardless of the purpose.
However, this implies that the data which is maintained on the Business Partner level must be valid for both vendor and customer. In the next step, we thus must look at the ownership of these global attributes: if either is changed, both the vendor and the customer record are updated, demonstrating the necessity of finding answers to the key question of ownership. If no answer can be found, the possibility to keep vendors and customers separated in different BPs is still available. In conclusion, both approaches are possible and viable (Same-BP or Separated-BPs), but the Same-BP approach is a huge – but often controversial – opportunity from a data quality perspective.
Does the Business Partner approach really revolutionize MDM? From my perspective, the answer is no. SAP is pushing an approach that has already been available in the past and isn’t a complete novelty, especially for SAP CRM, SRM and MDG. The concept is however becoming more transparent for customers as S/4Hana projects are gaining traction.
It is thus essential to design and set up the Business Partner concept in a timely fashion and correctly to ensure that the transition from legacy concepts is feasible and opportunities for the business can be realized. As the business requirements can vary heavily from company to company, developing an individual concept like this is a very specific tailoring job.
Add Comment