Use Case 2: Reducing End-to-End Complexities Associated with SAP Integrations

What is the Business Problem?

Integrating with SAP can be both challenging and time-intensive; of course, this is the case due to its complexity.

The complexities can be due to several reasons:

• Businesses have heterogeneous landscapes. They rarely just rely on SAP. There is a requirement to integrate with diverse applications, databases, etc. And, the integration landscape becomes more and more complex as businesses grow.

• Business processes have a high degree of customizations, custom fields, and unique requirements, which further increases the complexity.

• Inconsistent data formats, structures, and governance across systems. It is crucial to ensure data consistency.

STEP Solutions

Next, this topic covers the following scenarios to address the business problem outlined above and its corresponding solutions:

• Scenario 1: STEP as the owner of data creation

• Scenario 2: STEP and SAP as the co-owners of data creation

Scenario 1: STEP as the owner of data creation

Customers would like the creation of data to take place in STEP. STEP would be the system where creation, enrichment, and approval of data occurs. The creation of data should take place in STEP and not SAP because of the following reasons:

• There is no consistency in data created in SAP. There are huge number of duplicates leading to bad data quality.

• The complex organizational structures make maintenance of data both cumbersome and complex.

• Integration for obtaining product information in online shops is very cumbersome and requires lots of manual efforts in the shop platform.

STEP will act as a centralized data repository that serves as the single source of truth for master data, and data flows out of STEP to SAP (through the middleware, like Mulesoft) and other downstream systems. STEP will still be getting existing data from SAP in the form of data templates and reference data, but all the new data would be created and maintained in STEP. There will be a ‘SAP Data Model Mapper’ on both the inbound and outbound side that will be responsible for converting and mapping the data into the SAP or STEP data model as required. Since creation and maintenance of data will be done in STEP, the user privileges to create and maintain data in SAP would be removed or at least restricted. This is a strict governance style that ensures improved data quality and reduced redundancy, enhanced data governance, simplified data integration, and better decision making.

Scenario 2: STEP and SAP as the co-owners of data creation

Customers would like to create, modify, and maintain data in SAP but enrich it with additional data in STEP (e.g., marketing text, etc.). In this scenario, STEP is only allowed to modify the data that is not governed in SAP.

STEP can serve as the single source of truth for master data. However, the data entry remains flexible, allowing changes to be made through existing source systems, like SAP in this case.

This specific case strikes a balance between central control and decentralized data management and accommodates diverse data sources and organizational needs.

Implementing SAP Integrations

Keeping these two use cases in mind, we have developed comprehensive guidelines for implementing SAP integrations, which will simplify the process, further making it smoother and more efficient. And, with these guidelines and having STEP in your landscape, you can expect a significant reduction in end-to-end complexities with respect to SAP integrations.

Real-life examples

There is an organization that operates with a highly complex structure across many countries and thousands of plants worldwide. When a material is created, it needs to be accessible to all these plants, but SAP does not natively support this. To manage this, data is fed into SAP through Excel files, XMLs, and interfaces like IDocs, OData, and occasionally BAPI calls, which require extensive technical knowledge. The primary challenge is that SAP activities rely on the 'Material Name' field, which is limited to 40 characters. Organizations often have creative ways to squeeze essential details into this limited space, but it can be difficult to convey all necessary information. Typically, material names are built by combining attribute values, but if they exceed 40 characters, adjustments are needed. This often results in inconsistent naming patterns, making it difficult for users to find existing materials. Consequently, users frequently create duplicate entries, further complicating data management.

Given the background above, it is evident that the organization is facing significant issues with redundant and inconsistent data. They need a solution to better manage their material information, leading us to some crucial questions:

• How can we manage data redundancies and inconsistencies?

• Where should data be stored, and how should it be governed?

• Which system should be responsible for owning and governing material information?

The answers to these questions will be crucial in deciding the proposed implementation approach. For the sake of simplicity, we know that this organization has already pondered over these questions, and the relevant information required to decide the proposed implementation approach is readily available.

Approach 1: STEP is the owner of data creation and maintenance

Implement STEP to take control of material creation and maintenance, ensuring that the required SAP tables like MARA (Material Master: General Data), MAKT (Material Master: Descriptions), and MARM (Material Master: Units of Measure) are properly populated. In this approach, STEP is the owner and single source of truth for material information. To achieve this, existing material information will flow out from SAP into STEP in the form of data templates and reference data, and all the new data would be created and maintained in STEP using either data templates or reference data. Furthermore, the creation and maintenance of material information will be governed by workflows, which ensures creation and maintenance of consistent and unique material information without any duplication.

However, it is important to notice that STEP was not made the owner of plant-specific information, storage locations information, and sales organization-specific information. SAP is responsible for that mostly because this information is tied more closely to the operational processes, although plant-specific information (MARC) and sales organization-specific material information (MVKE) could be generated in STEP and then sent over to SAP. This will speed up the process and make the initial creation of plants easier. However, the maintenance of data within the plant views could remain in SAP. It is an essential decision as to which level of data should be governed in STEP, and which elements should remain under the control of SAP.

Approach 2: STEP and SAP are co-owners of data creation and maintenance

Implement STEP to transfer and consolidate product information for online shops. SAP would still own and be responsible for the information being created and maintained in SAP. But, the enrichment and approval of product information, like marketing descriptions, would be created and maintained in STEP.

Ultimately, the goal is to improve data quality and standardize processes, with customers playing a crucial role in key decisions related to SAP integrations. Customers need to decide if they would like STEP to be a leading system of material creation or not, based on their requirements.