09 Jul Let’s Talk Integrating SAP and Salesforce
As companies march toward digital transformation and placing the right tools in the hands of the right people, SAP and Salesforce are often in the middle of those conversations. Both are leaders in various Gartner Magic Quadrants as of the 2020 report. New and established organizations are also heavily increasing the use of these systems.
Whenever two technologies or applications need to communicate, there are challenges that must be overcome. With SAP and Salesforce, there are five common challenges organizations face when integrating SAP ECC or CRM with Salesforce SFA or service solutions and platforms.
The Lens You Look Through
Probably one of the most interesting differences when integrating SAP and Salesforce is the lens they look through to see the world. Simply stated, your perspective. Each participant brings his or her viewpoint of the problem and how to solve it. The team member hears and understands the requirement in a way that is specific to them. Is that a quotation service that pulls the latest pricing information or is it a service order that will schedule a technician? Is a Salesforce account the same as a customer and which SAP partner function are you referring to? What functionality does that user story entail? This commonly leads to confusion, misunderstanding, and even frustration whenever all parties are not on the same page.
A good example of this challenge is with a recent implementation project to bring another business onto an existing Salesforce platform. The team was marching through sprints and user stories when a Salesforce team member thought of important functionality to regression test. So, they created a user story. The ETL and SAP teams received the story to prep data and script the scenario. Normally this isn’t a big deal. Unfortunately, the user story was written in Salesforce terminology. It didn’t translate what it meant for the other groups. The result was two weeks of emails, meetings, and phone calls to figure out the testing needs, instead of two hours.
It is essential for SAP, Salesforce, and ETL representation to fully understand and agree on the plan. Active listening techniques, asking clarifying questions, and restating your understanding can mitigate this controllable obstacle.
Agile vs Waterfall
Many of us are aware that SAP and Salesforce are very different applications and possess different strengths and weaknesses. You’ll likely experience the joys of employing different SDLC methodologies concurrently with an SAP and Salesforce integration effort. Salesforce commonly uses Agile due to its ability to make fast-paced changes to the UI and user experience functionality. Story-driven models that frequently move from one sprint to another are common in the Salesforce world. It allows for quick-delivery of functionality to the users.
SAP projects tend to struggle with Agile methodology, especially when code customization is required, and typically excel with the waterfall approach. One Salesforce implementor put it this way: “The moment you do an integration with SAP (or any world-class ERP system), everything slows down. You must be very strategic and intentional. Discussions about architecture and tools should start right away. It should happen before user stories are ever developed.” It doesn’t mean one is better than the other, it is simply a reflection of what best suits the technology.
The challenge – how to get Salesforce to slow down and “be more thorough and documented” while imploring SAP to “get a move on – we can’t wait forever”? Novels could be written on what’s been tried and doesn’t work well. The strategy first acknowledges the differences and brings a mindset of we can make this work instead of we can’t.
The team is then able to determine the SDLC hybrid that is agreeable to all parties. One good approach is to employ release (milestone) planning that includes a set number of stories/effort and execute a waterfall cycle within each release (sprint). This basically elongates the sprint and limits the waterfall approach’s timing in each sprint as seen in Figure-1. Once the methodology has settled, you should consider a schedule to migrate non-production systems.
Figure-1
The ETL You Choose
This is the one area I wish Sauron from “The Lord of the Rings” trilogy would make an appearance with the one ring to rule them all to create consistency. There are many ETL tools and partners to choose from. All of them vary in scalability, maintenance, feature set, error handling, and even implementation. This area is notorious for impacting the implementation project in either a positive or negative way.
Salesforce acquired MuleSoft middleware technology in 2018 to create some consistency. However, there are many options in this space, each with different challenges and capabilities which presents the challenge: the ETL technology and partner you choose can make or break the project. Choosing a known partner with hundreds of successful implements and a technology that balances functionality with other important aspects such as ongoing maintenance will tip the scale toward a positive experience.
The Data Model
Princeton University defines a data model as an organization of data elements, standards, and relationships often used as a communication aid between businesspeople defining the requirements for a system and technical people defining the design for those requirements. While this is true, the practical application of data models between Salesforce and SAP are vastly different. This leads to challenges when the two systems integrate.
Field Service Lightning (FSL) is a product that possesses a standardized data model for ordering, returns, and all transactional events. The data models can be significantly different between the standard FSL setup and how SAP requires the data to process the transaction. Take the concept of automatically replenishing sales representative stock as an example. It’s a very useful productivity and efficiency feature. But, how do you evaluate when the replenishment should occur and for which products? Architecturally, how do you do it? Should it be done via batch processing or real-time? What are the KPIs and thresholds to consider? Should the rep be in control of the process or done by the system? So many questions can stem from a single feature and all of them have ties to each application’s data model.
There are also technical limitations to consider, known as platform limitations in the Salesforce world. The maximum date allowed in Salesforce vs SAP is a common example of a data model difference. The Salesforce platform has a maximum year of 4000 where SAP allows up to year 9999 (evergreen concept). This limitation presents a challenge when you are extracting SAP pricing information or sending no end date service contract from Salesforce.
Issues like this exist and you are almost guaranteed to run into them. Leverage the experience of seasoned implementation partners to navigate these differences gracefully to avoid project delays or post-deployment issues.
Maintenance and Vendor-Provided Updates
One of the most underrated challenge areas for SAP and Salesforce integration projects is vendor-supplied release updates. Consider these for larger implementations or those with existing SAP or Salesforce applications. But, aren’t we talking about simple maintenance? Yes and no.
Both SAP and Salesforce provide application updates on a predictable schedule. They need to accommodate each other’s changes because of the heavy impacts on integration project timelines. These updates commonly change data definitions within the data model. They then require testing and potential corrections to existing functionality, among other disruptive effects. It is important to understand how SAP and Salesforce provide application updates and how to accommodate them within the integration project.
Salesforce’s Trailhead site is a fantastic tool to understand the cloud tool’s release strategy. In a nutshell, Salesforce follows a “seasonal” cycle that begins three months prior to the production release. Then, employs a push model where x servers have the features deployed.
SAP’s maintenance schedule for support package stacks varies by application. In general, the company follows a minimum support package levels to aid in planning flexibility. To find more information visit support.sap.com.
Regardless of who is driving the update, the trick is to understand the impact. The project will need to accommodate them from a cost and timeline perspective.
There are numerous challenges when integrating SAP and Salesforce, each with its own diverse waters to cross. Plotting a course to navigate these areas at the onset of your implementation journey can lead to lower cost and successful outcome. At a minimum, you’ll find calmer waters to sail on when considering these five challenges.
No Comments