How are BOM structures implemented and maintained in CPQ?
The actual BOMs from the ERP system are implemented as data tables that are populated from the ERP system. We have standard data table templates that define the attributes to be integrated in from ERP. These data tables are mapped using a single UI to Oracle CPQ BOM tables that allow Oracle CPQ to reference the customer’s unique BOM structures in a standardized Oracle CPQ schema. Updates the mapping of ERP BOM structures to their corresponding Oracle CPQ configuration models, attributes, and attribute values are required after ERP BOMs are updated. This can be accomplished in Excel and then uploaded to Oracle CPQ or in the Oracle CPQ data table edit UI.
What is the BOM structure functionality, advantages and limitations?
Oracle CPQ provides customers with a sales-centric way of selecting and configuring products. Typically sales users focus on meeting their customers functional needs and on articulating the benefits of product offerings. This differs fundamentally from the ERP-centric perspective that focuses on how a product will be produced or fulfilled. CPQ’s BOM Mapping features bridge the gap between these two perspectives in a way that meets the needs of both stakeholders yet enables automation and efficiency in managing their mapping. Previously Oracle CPQ customers could create custom table-based BOM Mapping and use Advanced Actions on Recommended Item Rules to perform a similar Mapping Function. CPQ’s 2016 R1 Release introduced platform-level support for BOM Mapping that reduces the level of effort and customization needed for implementation. Powerful table-based BOM Mapping Rules can be used to dynamically create Recommended Items in configuration without coding logic. Oracle CPQ has continued to enhance these features by adding support for visualization of multilevel BOM hierarchies in the commerce transaction, and leveraging BOM Mapping to support System Configuration (for bundling of multiple configured models) and Asset-Based or Subscription Ordering (for asset-based instances of unique products and services).
Can BOM structures in Oracle CPQ be imported and synchronized with Agile and/or Oracle EBS?
Yes. Automated synchronization of BOM structures into Oracle CPQ is a central principle for Oracle CPQ BOM Mapping. However, since every ERP implementation contains unique BOM structures, some level of customization is required to create the extract from ERP.
Can cost data be pulled in from Oracle EBS?
Yes. The majority of Oracle CPQ customers integrate product costs into Oracle CPQ for use in calculating margins on transactions and to support approval processes.
Is this a batch or dynamic process?
Cost data is typically integrated into Oracle CPQ by a periodic, scheduled integration due to the fact that for most customers costs are relatively stable and do not change on a high frequency. Customers with more dynamic costs can synchronize on whatever frequency is required using CPQ’s powerful integration toolkit.
How is import and sync implemented (out-of-the-box functionality, custom interface)?
Many Oracle CPQ customers maintain base-line cost data on their Product Master data store. Oracle CPQ provides out-of-the-box parts synchronization that can be easily customized to include additional attributes such as unit cost.
What versions of Agile/Oracle EBS are supported?
Oracle CPQ can integrate with virtually any PLM or Product Master. Oracle CPQ provides simple setup for administrators to enter the access credentials and endpoint from which to obtain product data which accommodates many simple integration use cases. Using these features Oracle CPQ effectively pulls data from the external Product Master. Alternatively, customers with more complex use cases requiring more filtering, transformation, or data manipulation may need to create a scheduled process outside of Oracle CPQ to pull data from their Product Master and then initiate an upsert to CPQ’s parts and product data (effectively a push into CPQ).
How is part cost stored in CPQ?
Most customers with stable costs store part cost in the Oracle CPQ Parts object, which contains a standard attribute to hold unit cost. Customers with more complex requirements may store this in an Oracle CPQ data table.
How is sub-item cost rolled up to top-level items and then displayed for the top-level line items in a quote?
Sub-item costs can be rolled up into top-level models using CPQ’s standard configuration rules. Most Oracle CPQ customers do this.
How do you prevent non-sellable sub-items from appearing in Part Search and accidentally being added to quotes?
Only sellable items need to be replicated in CPQ. Customers can filter out only sellable items for integration into Oracle CPQ or alternatively, they can tag non-sellable items in their BOM Mapping tables as ‘Manufacturing BOM’ items as opposed to ‘Sales BOM’ items, which are sellable.
What is the typical time associated with projects to bring BOM functionality on-line?
The elapsed time required to implement BOM functionality varies among customers depending on the number of parts, the number of configuration models and their complexity, their current state with CPQ, and the maturity of the organization in understanding both their sales-centric and the fulfillment-centric product views and how to map them.
What type and number of headcount are required to implement and administer the BOM cost functionality?
This is entirely a function of the scale, complexity and organizational maturity associated with the implementation. We recommend that customers new to Oracle CPQ engage an experienced systems integrator to, at minimum, advise on planning their project.
Are there customers that have implemented this functionality and what have been their experiences (positive, negative, what they’d do differently)?
Yes. We have numerous customers that have implemented this functionality and more that are currently in the process of implementing. It is crucial that customers implementing BOM Mapping give thought to their Oracle CPQ configuration structures – their sales-centric view of products. Customers need to understand how their product hierarchy maps to the choices offered to sales users. Specifically, product structures should be designed to assure re-usability of attributes and rules across models. Doing so assures that the effort to administer models and BOM Mapping is minimized.
Related Topics
For more information, refer to the Oracle CPQ BOM Mapping Implementation Guide.
See Also
