Since 2018, I have given presentations on SAP CPQ being a game changer for SAP system landscapes. It fills a giant gap that existed in the SAP product portfolio for two decades. In discussions with our customers, I often share and explain many of my favorite CPQ features. Now I am sharing them with all of you through a series of blog posts. Each blog will focus on one set of features.
Native ERP Integration, Part 1
“I heard that the native integration is really hard to get working and then it doesn’t work all that well.”
I hear that roughly every other week from prospective customers. If you had told me that a year ago, I would have agreed based on personal experience. If you tell me that now, I will tell you that you are wrong, and I can show you why. Sure, we still find a few glitches from time to time, especially if you have an uncommon on-premises setup for your ERP system. But by and large, the integration works, and it works well (especially considering all that it can do).
Nearly every CPQ vendor claims some form of “integration” to SAP Variant Configuration. You *must* understand that all such integration is not equal. Not by a long shot. Integration is not a “check the box” kind of feature. All integrations support *basic* configuration, pricing, and quoting. But how much integration is enough? That depends on your business requirements and implementation – both current state and (perhaps more importantly) future state.
What’s in Your Silo?
Think of CPQ and ERP as two silos. They are separate applications with their own databases and code base. CPQ is most often deployed as a cloud application whereas ERP is most often on premises. Yet these applications must share and keep synchronized extensive amounts of data and complex business logic. They require a “common language” so that CPQ quotations can become valid ERP sales orders.
Fundamentally, non-SAP integrations attempt to replicate the data and logic of SAP configuration and pricing. That means they extract it from SAP ERP, transform it into their own representation, and then execute it within their CPQ application. Some data are easier to transform than others. The illustrations that follow provide a greatly simplified idea of how this works. Let’s start with the basic data:
ERP Materials generally align 1:1 with CPQ Products
ERP Customers generally align 1:1 with CPQ Accounts
ERP Characteristics generally align 1:1 with CPQ Attributes
After that, it gets much more complicated. SAP Object Dependencies are functionally analogous to CPQ Rules, but in most cases, their representations and syntax are dramatically different (and often do not align in a 1:1 manner). Furthermore, the sequence of execution and the interaction among object dependencies can be *very* difficult to emulate. Nuances abound. For these reasons, I show that transformation as a very circuitous path (see below). And one that requires extensive testing and ongoing vigilance – to ensure that it keeps working as your VC models evolve. On top of that, SAP configuration profiles control how multi-level (i.e., hierarchical) configurations and bill of material explosions are handled. There is no direct analog for this in CPQ applications.
SAP pricing condition records are somewhat analogous to CPQ Price Lists and Formulas, but they generally align for very basic scenarios only – list price calculation for example. The SAP condition technique provides a powerful means to perform cascading price searches across various dimensions (e.g., customer specific price first, regional price second, and so on). In addition, you can reference other materials, condition types, and sales areas within these price searches. There are many more nuances but in sum, the condition technique is very difficult to replicate and goes above and beyond what CPQs can natively do.
On top of that, SAP pricing procedures provide a stepwise calculation across a series of price searches (e.g., base price first, material surcharge second, percentage off that sum third, and so on). Plus, you can get a breakdown of all the price searches and stepwise calculations to confirm that they worked as expected. No CPQ offers anything like this natively. Sure, you can write a huge, complex pricing script in CPQ that searches tables and performs calculations, but that is not a data-driven solution that can be analyzed and governed with change management. More importantly, how do you ensure that SAP ERP will calculate the same pricing for a corresponding sales order (we will come to that in a minute)?
So, think about that. We started with SAP data and logic on the right. We transformed that into CPQ data and logic on the left. Now we create a CPQ quote using its native functionality and then submit that to SAP to create a sales order. Then that sales order is validated against SAP’s data and logic. What could go wrong? 😊
About this time, your CPQ vendor may be recommending that you don’t maintain configuration or pricing logic in SAP. “Just let CPQ do all of this and send the result to ERP without validation.” Frankly, that’s like the tail wagging the dog. You would be forcing all configuration and pricing to originate in CPQ. That’s fine, right? “All configuration and pricing must start with a quote.” Well, except for direct sales orders that don’t get quoted. And sales order changes. And repeat orders, partial orders, contract release orders, and inquiries. And EDI. And more.
Say “Uncle!”
When I was young, my older brothers would often wrestle me to the ground, and despite my best efforts, I was never able to escape their grasp. They would demand that I “say ‘uncle’” which meant that I gave up and would submit to doing things their way. In a way, I feel that SAP’s approach to its CPQ and ERP integration for configuration and pricing is likewise unbeatable. And it is getting better and more capable with each quarterly release. I believe that competing integrations still get consideration mainly because customers struggle to understand the difference to SAP’s integration. Once that happens, I believe it will be “game over” for integration alternatives.
What is so different about the SAP integration approach? SAP CPQ and SAP ERP are still silos, and the basic data (materials, customers, characteristics) are still replicated from the ERP to CPQ. But rather than trying to transform ERP configuration and pricing into the native CPQ representation, SAP has developed microservices on the SAP Cloud Platform that can supplant the corresponding CPQ logic as shown in the image below. CPQ manages the user experience and user interface, but it continually calls these microservices whenever a configuration or pricing computation is required. Sales orders in ERP are validated against the same logic.
The SAP microservices leverage the proven Knowledge Base (KB)/Runtime Version and Standalone Pricing functionality that SAP developed more than 20 years ago for the IPC. SAP has improved the performance of these services over the IPC and is continually improving the KB generation process. These microservices can be natively leveraged in SAP CPQ and the SAP Commerce Cloud as well as any custom application. New stateful pricing services are in development that will support far more complex pricing scenarios, including full support for manual condition overrides and group conditions (i.e., multi-item pricing calculations). These services will "raise the bar" even higher.
Don’t Hit a Wall
If you think the preceding sounds complicated, I can assure you that it is just the tip of the iceberg. Before SAP acquired Callidus and there was an SAP CPQ with native ERP integration, eLogic developed many custom integrations between third-party CPQs and SAP ERP. There was no better option available. We have firsthand knowledge of how complex this integration can become, especially when you consider data change scenarios like option, rule, or price updates, combined with transactional change scenarios, such as reconfiguration and repricing. On top of that, there are frequently performance issues and errors to diagnose and resolve.
Keep in mind that SAP made substantial investments of time and money to get this integration right. Also consider that SAP fully controls and understands the nuances of its CPQ application, its ERP application, and its integration. And yet by my count, it took them more than one year to get this working acceptably well. Remember my opening statement?
Now imagine any third party attempting to provide and maintain comparable integration. The question is not *if* you will “hit a wall” with this integration, but *when*. Unfortunately, it may be very difficult to see a wall coming until you hit it. Now what? Can you make it around the wall? Can you even go live with the solution? Some don’t. Beware of making decisions based solely on vendor claims and “happy path” integration demos. Also consider who will continually fix and maintain third-party integrations – especially proprietary ones – because that someone may ultimately be you.
New Game in Town
eLogic is gladly out of the custom CPQ to SAP ERP integration business. We leave that “heavy lifting” to SAP and continually advise SAP on what additional integrations could benefit customers. That said, we sometimes develop integration enhancements, enabling customers to gain specialized competitive advantages. These enhancements are orders of magnitude simpler than building comprehensive integration from scratch.
We know that many SAP ERP customers have not yet implemented CPQ applications, mainly because of profound gaps in configuration and pricing integration. If you are one of those customers, then your wait is over. Don’t believe me? Then put us to the test. We will gladly demonstrate one of *your* VC models running in *our* SAP CPQ system within a day or two (subject to a few caveats). Interested? Send a note to marketing@elogic.com for more details.
Thanks for reading! Read on for 2 + 3 in this series: