Top Challenges Leveraging SAP VC and SAP Pricing in Salesforce
By Steve Zocchi, Manfred Hettenkofer and Gene Eun at Model N
Most of the world’s leading manufacturing companies use SAP as the platform for the back office and manufacturing. Many have also become Salesforce users and increasingly, the need to unify the two worlds is coming to the forefront. SAP and Salesforce are very different environments and integrations that extend beyond simple data transfer can get messy and expensive. Here are the top challenges we see when companies try to integrate CPQ on Salesforce with SAP pricing and Variant Configuration (VC).
Extractions are not complete
A common approach is to extract information from SAP and import it into a 3rd party CPQ solution. In order to do that, a lot of information contained in the knowledge base of a KMAT such as the configuration profile, object dependencies, materials, BOM, pricing procedures, implementation settings, etc must be collected. Since there are many different database tables and configuration settings that are connected and relevant, only a highly experienced resource will understand how all the components factor into configuring and pricing in SAP. Due to the many objects and complex relationships of data in the VC and pricing area in SAP, typically only a portion of the knowledge base is extracted, leaving gaps that need to be manually augmented within the target CPQ solution. This adds significant manual maintenance and testing effort during an implementation and later when changes are made on the SAP VC and Pricing Procedures.
Auto-conversions are not so automatic
During implementation time, entire teams of programmers must develop code that converts the extracted data into data structures and settings that can be imported into the CPQ solution. Due to programming effort and data complexity, programmatically performed data conversions from SAP into another CPQ solution are often so limited that only about 20% of data can be imported. These conversion programs often only perform the structural transformation of the Class 300 data from the allowed expressions in object dependencies; a complete transformation is virtually impossible. When attempting the transformation of Constraints or Constraint Networks into rules, this endeavor is surely so complex that it cannot be accomplished with this approach. This means a significant portion has to be dealt with and augmented manually in the target CPQ solution. Also, every time an admin in SAP makes slight changes to the object dependency, BOM, classification, pricing procedures, or KMAT, there is a risk that the transformation and import logic cannot handle the changes, causing significant effort to adjust the code, frequently at a high cost.
A common practice for pricing integration with SAP ERP is to make direct calls into SAP to request and return itemized price records for all quote lines. The only mechanism available in SAP to retrieve prices for products that match the prices later when an SD Order is place is through a Simulate Order BAPI call. These performance intensive BAPI calls must be made frequently from the CPQ solution as almost any change performed by the sales rep in the quote requires a full re-price action of all quote items. Due to the many and frequent real-time calls this, integration is extremely ‘chatty’. Additionally, any time the SAP ERP system goes through a maintenance window and the BAPI service is not available, sales reps cannot create or update quotes. Having consistently accurate itemized prices for quote lines and quote totals are essential to ensuring the price on a given quote matches the price on the resulting order placed later in SAP ERP.
To avoid ‘chatty’ integrations, some CPQ solution providers suggest a workaround by making the CPQ solution the system of record for pricing information. By doing so, they avoid the need for real-time Simulate Order BAPI calls. However; it also means any investments made into SAP Pricing Procedures are no longer used in the quoting process. Sales Orders created in SAP from imported quotes using the Sales BOM method generate a sales order with line items that have sublines representing the sales BOM components and itemized pricing stored as manual pricing conditions. The downside to the Sales BOM method is that any changes that affect sales order lines and prices on an order must be performed in the originating CPQ solution, because it is the system of record for pricing and configuration logic. Since sales orders can’t be changed in SAP if they are created with the Sales BOM method the integration between the CPQ solution and SAP must now be further enhanced to facilitate the change order process.
There is no question that there is huge value in leveraging SAP for quoting natively in Salesforce. If SAP could be the single system of record for pricing and product configuration information, it would then be possible to unite front office with back office processes. Sales reps could easily and quickly access accurate and complete information in a cloud-based environment. Also, the selling process could be easily extended to channel sales partners such as distributors, VARs, wholesalers, and brokers by leveraging Salesforce Community Site capabilities.
In addition, administrators could augment SAP product data and rules with additional information that can help sales reps be more effective and productive. For example, an administrator could add the translation of product and option names, product-specific legal terms and conditions, images, market exclusion rules, or bundle rules. With a Salesforce-native CPQ solution, a company can optimize its go-to-market approach by enabling solution selling which combines guided selling for SAP products with non-SAP products, software and services on a single quote for its customers.
Bolting together Salesforce and SAP VC is expensive and generally not effective
Model N took a different approach by building a dedicated engine into the Revvy CPQ for SAP solution. The Revvy SAP Engine periodically synchronizes directly with SAP Pricing Procedures and SAP VC “out of the box”. The synchronization generates a complete run-time version of all Pricing Procedures, pricing set-up, and entire VC knowledgebase. The run-time data can be used by the Revvy SAP Engine to calculate price lines for products and options on the quote as well as provide a product configuration experience that emulates SAP. Orders in SAP SD generated from quotes created in Revvy CPQ for SAP have configuration and pricing results that are precisely the same as orders had they been created manually in SAP. In fact, since the orders that originated from Revvy CPQ quotes are fully functional, they can be changed directly in SAP in the event of an order change requested by the customer.
With Revvy CPQ for SAP this can be accomplished with no custom integrations, chatty pricing calls, or expensive conversion custom coding. Revvy CPQ for SAP synchronizes all relevant data from SAP with the press of button and prices and configures SAP products natively in Salesforce, exactly the same as if they had been priced and configured in SAP.
Why risk the challenges of bolting together Salesforce and SAP when you can get a Salesforce-native CPQ solution with interoperability with SAP “out of the box”?