My Favorite News in CPQ Updates: SAP CPQ 2011
SAP introduces a new release of CPQ every quarter. We read all the release notes and then we dive in with some hands-on testing as soon as our tenant is updated. These releases cover a LOT of new functionality and updates to existing functionality. In this blog series, we will talk about what we think are the major news stories in each update. I hope this helps to guide your hands-on testing and design thinking.
CPQ 2011 Update
We were excited to get our hands on the latest release of SAP CPQ in our Test/Demo Sandbox tenant. This release contains a critical bug fix and new feature that we really need for an active implementation project. Here are some highlights:
The Issue and Fix
The dreaded “page scrolling” issue is fixed, mostly. This issue occurred if the user saw more than one page of attributes on a given configuration tab and scrolled down to select or specific an attribute value. If that value assignment triggered a rule execution, then CPQ would scroll back up to the top of that page. That experience is a non-starter for most users, and so we had previously arranged tab layouts to avoid scrolling. Even that was not a great experience as numerous tabs were often required to fit all the attributes of a complex product.
If a user scrolls down the page to specify an attribute in the 2011 release, CPQ will no longer scroll back to the top of the page (unless the Responder happens to be on the Configuration Tree). So be careful to stay on the Configuration Summary when scrolling down a configuration page). Even then, CPQ will scroll about one line after specifying a value. That is not ideal but is far better than the previous experience. We have alerted SAP to these findings and hopefully they can also correct these soon.
The moral of this story is that it is now possible to have scrolling pages of attributes in configuration if that is the ideal user experience.
The New Feature
We model a lot of multi-instance (hierarchical) configuration products and systems. The Configuration Tree in the Responder has always been a nice feature for visualizing and navigating through the instance tree, but only product names of each instance could be displayed in previous releases. This is fine if each product only occurred once in the instance tree, but what about situations where multiple instances of the same product (configured differently) appeared in the same configuration? There was no way to distinguish one instance from the other without clicking on it to see its configuration.
In CPQ 2011, you now have a general application parameter to display either product names or part numbers in the Configuration Tree. Because part numbers can be calculated via formula, a user can now distinguish between different instances of the same configurable product. This makes the Configuration Tree much more usable for such scenarios. One caveat is that configurable products without part numbers will appear as a blank line in the tree (i.e. the system will not revert to the name of a product without a part number). This can be a little confusing at first and should be considered in your product design.
As a side note, SAP VC has this same issue (i.e. showing only configurable material number or description in the instance browser). It would be great if SAP could provide the option to show dynamic material/product descriptions in both SAP VC and CPQ (in the instance browser and responder respectively).
Until release 2011, VC (Variant Configuration) models that were synchronized from SAP ERP were required to use the ERP based VC KB (Knowledge Base) configuration engine and pricing calculations with CPQ quotes. Non-configurable materials had the option of using ERP or CPQ based pricing calculations.
With the 2011 release, you now have the choice to use various combinations of the ERP or CPQ configuration engine with ERP or CPQ pricing calculations on a product-by-product basis. This opens some interesting solution possibilities. But as I am fond of saying, just because you can do something does not mean that you should. Why would anyone with VC models not want to use ERP configuration and pricing in CPQ? Isn’t native VC integration one of CPQ’s biggest selling points?
To that I respond that not all VC implementations are the same. Some companies have VC models that are heavily engineering or manufacturing focused, and they are not very usable (as-is) for sales quoting. They may not even include variant pricing. In such cases, sales quoting is often done outside of VC in separate applications or even using spreadsheets. Successful quotes are then reentered into VC for fulfillment. This is not ideal, but the thought of having one VC model that serves both sales and manufacturing may be daunting from usability, maintenance, and performance perspectives.
The chart below shows the supported combination of configuration and pricing options. Any combination is supported except that variant pricing cannot work without variant configuration. This makes sense since there is no way to set variant keys and factors in standard CPQ configuration.
Pricebook or Custom Pricing
Standard CPQ Configuration
So, the prospect of using native CPQ configuration and/or pricing in conjunction with VC manufacturing configuration may have appeal in some specific contexts. Currently the main advantage of this scenario is a common data model between VC and CPQ; you can systematically synchronize your VC characteristics and corresponding CPQ attributes. Synchronization means that when characteristics or values are added to VC models, they can be synchronized to CPQ and leveraged in layouts and rules. This enables VC and CPQ to “speak a common language” which is the key enabler for future sales order integration.
You read that right, sales order integration is not fully supported for “Standard Configuration” scenarios. At least not yet. The issue is technical because Variant Configuration value assignments are retrieved from CPS when CPQ submits a quote to an ERP sales order. But CPS does not run for “Standard Configuration” scenarios, so if you are able to create a sales order in this scenario, its configuration will be blank.
There are of course other potential downsides to this approach. The main problem to avoid is maintaining sales configuration and pricing logic in both CPQ and VC. The logic would have to be modeled in two very different paradigms yet produce the same exact outcomes. In practice, this is rarely accomplished 100%. Another potential problem is that all quote and sales order configurations would have to be created and changed in CPQ to enforce CPQ sales rules and pricing. While ERP configuration and pricing can be leveraged in CPQ, the vice versa is not true.
In summary, I believe that this scenario is best for creating complementary (rather than replacement) sales configuration and pricing in CPQ. In most cases, I would recommend leveraging VC configuration and pricing in CPQ when VC models already exist or modeling capabilities that go beyond the native CPQ functionality are required.
Other Noteworthy Updates
Here are a few miscellaneous updates that will make your life a little easier or a little more interesting.
Two new attribute types were introduced in preparation for the upcoming SAP BRIM integration in the 2102 release (so you can start modeling products in advance of implementing the integration!)
Business Partners are now the default way to manage customers and other parties when quoting with Quote 2.0 (this was a challenge when we integrated CPQ with our S4H system)
Global attribute maintenance screens have been redesigned according to SAP Fiori standards (and are now consistent with product attribute look and feel in Products 2.0)
You no longer need to scroll to check your syntax on the Formula Builder (yea!)
All of these updates and more are described in more detail in the SAP_CPQ_2011_Whats_New PDF document on the SAP CPQ main help page.
Nice job SAP! Overall experience with the new release has been quite good. We are looking forward to seeing CPQ 2102.