Why data mapping is the wrong focus with Salesforce and SAP Integration
Working in the Enterprise Application World for 25 years, you hear about a lot of projects that have outright failed or that failed to meet the original goal of the project. In recent years as Salesforce.com has become the dominant CRM package preferred by Sales Executives, many enterprises have begun to try to integrate it to SAP, the leading ERP package. The results have been mixed depending on what they were trying to accomplish.
I am stating the obvious when I tell you that Salesforce CRM and SAP ERP were designed to do two very different things in two very different ways.
When companies first determine a need for integrating the two platforms they may have a simple objective of simply exposing existing customer data from the ERP system to the CRM system. The IT Team will usually go out and acquire one of the existing Extract, Transform, and Load (ETL) platforms such as Informatica, Boomi, or Mulesoft and map the existing customer from ERP to CRM in one or two months – mission complete! Well, no.
Now the sales team sees the benefit and begins to ask for Credit, Sales, and Delivery Data. The team goes back to the drawing board and now decides they need custom data objects to hold the data in Salesforce. And, they will need data quality tools to ensure the daily batches are in sync if a mapping is incorrect. The IT Team now undertakes a much more significant (and expensive) mapping/development exercise to move data in one direction from ERP to CRM and after six months – mission complete! Well no.
This is where it breaks. The sales team now asks the question that should have been addressed Day One. Why can’t we just create customers in SAP directly from the account in SFDC? Why can’t we create a Quotation or Sales Order from the Opportunity instead of relying on inside sales? You are now leaving the world of data sync (and mapping) and entering the world of Process Integration.
The investment you made in that cloud platform and that 9-12 months of mapping ends here. You are now moving from a simple CRM System designed with little data dependencies and the administrator in mind to a complex ERP system with massive data dependencies and specialized skill sets to integrate Lead to Cash Processes. This is not an exercise in mapping/syncing data.
To understand why iPasS is not going to solve your challenge you need to understand that these tools evolved from the world of ETL. Boomi was originally a premise-based product heavily utilized for EDI before its move to the cloud. Informatica was used for building data warehouses. These products were used simply to extract the data, map the data (transform), and then load the data in disparate systems. As these mapping exercises became more complex, these ETL companies added additional Master Data Management and Data Quality Suites to try to be more proactive when daily batches failed and the systems were again out of sync adding even more costs and complexity.
The problem with the ETL approach – cloud or otherwise – is that it only effectively addresses moving data out of the complex ERP System to the simpler CRM System. When you change the direction, and try to move data into ERP you now need to follow complex master data rule sets that govern the data. And you have yet to address Process Integration which requires interaction with users in addition to the master data and configuration governing the actual process.