Product data is the gasoline to run the CPQ Engine (original) (raw)

“Product data is the gasoline to run the CPQ Engine”- that means better the product data quality, better the performance of CPQ. Oracle CPQ cloud solution is the best breed SaaS based solution for solving configuring, pricing and quoting challenges for any organization. With this article, I would like to highlight the important of product data in order to make CPQ Cloud solution successful.

Products are basically the offerings which sales team offers to their client to configure the right options, get quote and then eventually order. Product data includes items/SKUs with their technical specification/attributes and options. Technical attributes typically drive the option selection, pricing etc. during quoting. Traditionally ERP Systems are considered as system of record of product data, which means once CPQ engine get integrated with ERP, it is expected to run swiftly. But often times we have seen clients struggle with this approach and have multiple data integrity issues .

Here are few cases:

1. Product Searches in CPQ will not work as expected if Product Data is not consistent- One of the reason for the same is item descriptions are not consistent in the ERP systems. For example: “A12345” and “X12345” are both hard disks items with description as “500GB Samsung” and “500 Gigabyte Dell” respectively. Now if Sales person has to search to get all available hard disks of 500 GB, there is no easy way to search it as both the items have different way to describe 500 GB hard disk.

2. Incorrect Order fulfillment and revenue loss - Most of the ERPs do not hold technical attributes of the item. These attributes either exist in PLM system or few clients store it in spreadsheet/database which gets loaded in CPQ cloud as part of initial load. But at the later point of time, any changes on the item with respect to its technical attributes create issues in quoting and order fulfillment. For example – Item “A12345” represent a hard disk in ERP. Its technical attribute (size) as “500 GB” is stored in PLM/Spreadsheet. If there is any change made on this item in PLM/Spreadsheet which makes this item of size of 1 TB and this change is not propagated to CPQ, then a quote would be generated on this item in CPQ for 500 GB and order would be fulfilled for 1 TB.

3. Order creation failure, bad customer experience- During the configuration of the finished product, if the option selected by the client does not have the appropriate SKU available in CPQ, then quote creation will fail. For example- In CPQ, while configuring Hard Disk for a server, there are three options available – “500 GB/1 TB/2TB”. During initial data load, you have 3 SKUs “D12345/E12345/F12345” imported into CPQ with size attribute as “500 GB/1 TB/2TB” respectively. Later you have added another option as 4TB in CPQ but the SKU corresponding to it loaded in CPQ has size value as “1 Terabyte” in PLM/ERP then order submission will fail because of mismatch attribute value.

The above challenges are just few sample examples and these problems become multi fold when dealing with bills of materials. At times, it has the potential to cause the entire CPQ solution non-usable.

In order to avoid all these issues related to product data in CPQ cloud, it is recommended to have Product Master Hub solution deployed as single source of truth for product and its attributes for CPQ and ERP. We recommend using Oracle Product Hub Cloud (SaaS based Product Mastering Solution) to manage all item and attributes, this data will get published to both CPQ and ERP systems using with KPIT’s integration adapter.