Integration with backend systems is key to the success of any Retail Execution solution. You want to leverage your investment in your existing ERP solution, especially if it is a powerful and capable solution like SAP ECC or S4/HANA.
Spring has been in the forefront of this problem, having implemented numerous integrations with SAP in key CPG customers over the last 15 years, and also by being an SAP partner and partly owned by SAP (SAPphire Ventures).
“CONA Services, LLC selected Spring 4 years ago based on several different reasons. One reason was their solution closely supported SAP’s master data for Sales and Merchandising. This allowed CONA to get the system operational with the first bottler in less than 4 months. Spring’s integration is scalable and performant which allows CONA to get the data in and out of the system quickly to support over 12,000 users.” Director of Architecture, CONA Services - A Coca-Cola System IT Services Company
With more than 15 years of experience in this space, we have encountered a number of different environments as well as overcoming numerous integration challenges that many CPG companies face. We have highlighted 5 critical factors to be considered when selecting a Retail Execution vendor for your field force, related to SAP integration:
1. Data Model Adherence: Yes, you can create new entities, objects and APIs in a generic way or dynamically, but if the data model of your provider has too few standard entities or if it is oversimplified, the integration logic will be complex and hard to maintain, leading to more costs both of setup and operation. Spring has evolved its data model to be very close to the SAP data model over the years, in some cases even having the same equivalent entities, especially for a data structure as complex as pricing. This greatly simplifies the integration effort, as it becomes very close to a 1:1 mapping with simpler data transformation logic. This contributes both to a speedy setup project, but also to great performance and easy maintenance;
2. Configurability Needs to Be Granular: Even with having a matching data model, you still need flexibility to configure new fields, new entities and the related exposed API for integration. Also, flexibility of the API layer must consider version management, as you don’t want to break existing flows when creating new ones. Configurability to adapt to different circumstances of how your SAP instance is configured is also very important. For example, the ability to switch between synchronous and asynchronous mode, and choose specific modes depending on the specific interface. In our experience, sometimes it is important to reuse an existing interface from SAP, and the way some interfaces work might not have a good performance if you have only a synchronous mode. As in other cases being synchronous and really waiting for the integration return is important, as your business process in SAP might require that, so it is important to have this type of configurability in an interface by interface basis.
3. Keeping Integrity While Considering Performance: Transactional systems used to connect to SAP typically rely on a lot of data integrity checks to make sure all transactions are fully consistent. ACID (Atomicity, Consistency, Isolation, Durability) properties are key for any transaction based system. However, sometimes this type of guarantee comes with a heavy cost in terms of performance (too many validations) and also integration project implementation, as you really need to ensure an exact order of calls for each interface, which can be a daunting task given a typical integration can have up to 400 different integration interfaces, and the dynamics of each workflow inside your SAP implementation may not easily guarantee this. For example, you may use customer groups like Target Groups, referencing specific customer stores, but a specific store may not be up to date when it is referenced by the group, causing a dependency error in the integration. Our approach is to ensure all the needed validations are executed, but to also allow for requests to fail and be ‘replayed’ later, manually or automatically, using a cache structure. The key points are:
All of these characteristics help to ensure a good integration performance, reduced implementation cost, while keeping the proper level of data integrity.
4. Targeted Data Extraction from SAP: Sometimes using standard SAP interfaces (default BAPIs) is too much for the needs of a retail execution solution, both in terms of records (vertical) and of fields (horizontal). In our experience this leads to complex mapping and also performance issues, as sometimes just a few records are changed (e.g. for Business Partners) but the exposed interface hits a large number of records and fields, not only slowing the integration process but also using a lot of unnecessary server resources. Also, for the retail execution solution side, you can have the integration lasting hours, generating extra processing and possibly delaying the access to data of important field processes (e.g. an update in a service ticket of an in store deployed asset, like refrigerators, regulated by SLAs). We have tackled this problem by multiple forms, and one of them is using a reference architecture for an SAP connector, that can be installed as an RFC inside ECC, to extract only the specific fields needed for a typical retail execution solution (e.g. specific fields for Business Partners) and also only the changes since the last API access. We have experienced performance gains of up to ~60% for large amounts of records such as 500K business partners for example.
5. True Scalability and Performance Must Be Proven By a Simulation: obviously scalability is key for any integration project, and it needs to be elastic and adaptable to your demands, otherwise you will either have a large invested capacity that is rarely used, or you’ll reach a bottleneck if you have an unplanned integration surge (e.g. critical short time campaign leads to millions of promotion related pricing condition records). Aside from the very important point that you should really plan ahead and consider your scalability and performance benchmarks within a safety margin, our experience has proven that simulating system behavior really can make a difference. Retail Execution solutions that rely on offline access from the mobile app typically work with a middleware architecture, which means that you can have conflicts between data synchronization from mobile devices and the transactional load from integration to and from SAP. Since it is very hard to anticipate all possible issues, having a simulation can really help you find critical issues in advance and fix them before it is too late. Spring has invested in a simulator tool that is capable of actually replaying actual production loads or simulated loads, executing processing logic that is driven by mobile device synchronization, web portal access, batch processes execution and of course the SAP integration load. For critical transactional systems like field sales, you should not risk going live without running a true simulation first. Below is a diagram with a simplified view of the simulation setup that we use:
Connecting in an efficient and cost effective way with SAP is of course fundamental for any retail execution application, as SAP is typically the main source of truth for your master data and transactional data, so it is crucial to have a partner that really understands the complexity and then the potential issues that comes from SAP integration.
If you are interested in seeing a demo of Spring Global or have questions about an SAP integration, you can contact us here.