This blogpost is about the process of getting Product Information (Product Data + Product Configuration Rules) from the Product Management Team to the Team that maintains your CPQ Tool.

While I recognize that there are multiple CPQ tool vendors that claim that a product (model) can be setup in their tool by a business team (e.g. Product Management Team) I have to actually run into an organization that doesn’t have a more technical person or team maintaining this data. To keep the CPQ tool updated with new or changed Product Data and Configuration Rules is, in most cases, not a small task. Yes, there are ways to reduce the necessary maintenance (e.g. setup as many reusable configuration rules across Product Models as possible, use data based rules by using tables etc.) but it still requires some maintenance. Let us look at two key questions with regards to CPQ tool maintenance

1. Who should maintain the CPQ tool?

2. What should you document in what form?

regarding 1: There are basically three options 

• Ideally the Business Team (in our case the Product Management Team) maintains the Product Data and Configuration Rules since they are the closest to the Products. Based on my experience though this is a real challenge since that team is usually focused on other tasks. Also consider that in many cases the Product Management Team thinks differently (more high level)  than a technical team (more detail focused).  As a rule of thumb I’d say if your company has simple configuration rules this is an approach you might want to try.
• Create a hybrid team that consists of people with skills in both business and technical areas (e.g. former Product Managers, former CPQ tool developers) to setup your CPQ tool. This team then represents the glue between the Product Management Team and the CPQ maintenance team. This approach can be used to document all Product Data and Configuration Rules and to help your support teams trace CPQ tool issues. This approach is probably the best for medium complexity configuration rules.
• Use a technical Team to setup and maintain your CPQ tool. This approach is used mostly in larger companies. It requires a well thought through and formalized process and form of communication between all stakeholders. This approach is mostly used when the configuration rules are complex.

Note: An important criteria to consider for all these options is the size of your company, the size of the impacted teams and in what physical location you need to have your CPQ team?

regarding 2: What should you document?

• Document the Configuration Rules (Why does something work the way it works? Who provided that Configuration Rule? When did they provide this Configuration Rule?). This document will be key to understand how the product configurator works and to ensure that the configuration rules work the same across various Product Models. This is a key requirement to ensure a high re-usability of configuration rules. I have seen various forms used like Excel, Word, HP ALM, DB etc. Different vendors might provide different forms for their tools. In general I’d recommend to use a format that you are comfortable with and that provides you the minimum information you need!
• Your Product Setup should be documented in the New Product Introduction (NPI) Process in any case independent from any configurator setup and hence I don’t try to cover this here.

Note: Obviously not everything applies to everyone and so while a small startup company might get away with setting up a Product Model in an Excel spreadsheet (for some time) or Steelbrick CPQ with one resource this is not an option for a larger company. There are simply more teams involved and company policies to consider. In any case I consider it important to have configuration rules documented and accessible for non-technical resources.

_____________________________________________________

Explanation of terms used:

Product Model: represents all (1) Product Data and (2) Configuration Rules for a Product (e.g. Laptop XYZ) –> Example: Laptop XYZ is represented by

1. Product Data:

• All Product Numbers that go into a Laptop XYZ like processor, RAM, Hard Disk Drive etc. This consists of a Product Number, Product Description, Product List Price etc.
• A Bill of Material (BOM) shows what Product Numbers are available for a Laptop XYZ and for what purpose (e.g. Sales or Manufacturing)

2. Configuration Rules: Graphics Processor ABC is only available with 8 GB RAM and similar rules that describe what combination of Product Numbers represent a valid and working solution.

– Product Management:  is the team owning the planning, forecasting, and production or marketing of the product Laptop XYZ  at all stages of the product lifecycle. This team owns the Product Data and Configuration Rules.

– CPQ Tool maintenance: In order to keep your CPQ tool up to date the following needs to be ensured

• Products + Bill of Materials (BOM) are setup and remain up-to-date : Example: Product Number 123 (e.g. HDD 250GB) is replaced by Product Number 456 (e.g. HDD 500GB) on a given date
• Prices are setup and remain up-to-date: Example: List Price for Product Number 789 changes from $50 per unit to $45 per unit on a given date in a given country/sub-region/region
• Quote functionality and linkages (e.g. Contract Life Cycle Management) are available and remain up-to-date. Example: A quote form needs to change because a company moved to a new building and so the address needs to change on the quote form or the standard Terms & Conditions have changed and so a different T&C form needs to be attached to the quote.