前言：即便是复杂的销售过程，交易也不应受到冗长报价流程的阻碍。CPQ技术可以启动自动化报价流程，帮助销售代表快速响应客户，提供准确报价方案并达成更大规模交易。但如果没有实现销售BOM和生成BOM之间的转化，也就谈不上真正的线索到现金（L2C）端到端的业务全流程了。
企业为了实现销售精细化管理，会采用了专业的销售过程管理（SFA）解决方案。尽管如此，还是会在报价环节遇到很多问题。例如：报价中的BOM（物料清单）不符合客户需求；客户抱怨报价时间太长；销售代表抱怨不能自动生成满足要求的报价书等。越来越繁多的BOM，越来越复杂的选配参数和规则，导致传统的SFA系统无法支持一线销售在客户提出需求后，快速准确的选配好产品并给出合适的报价。有些企业自研了报价工具，又发现其是个孤立的系统，无法和CRM、ERP很好的集成，实现打通的前后端——线索到现金（L2C）流程。解决以上场景中的问题，我们需要CPQ。CPQ 是复杂销售过程管理的核心流程，是连接CRM和ERP的桥梁。
什么是CPQ
CPQ 代表”配置、价格和报价” ( Configuration，Price & Quotation )
- CPQ 需要从ERP获取基本产品信息（生产BOM），并添加了所有其他信息（定义销售BOM），如定价，促销，捆绑销售，配置规则和建议内容等，这些信息不易存储在ERP中。
- CPQ 能够指导销售人员给出合适产品的合适报价，以合理价格赢得交易，并给出促成交易的建议。
- CPQ 会从CRM系统中提取商机数据，并将完成的报价和产品信息返回到CRM系统中进行长期存储。
- CPQ 完成报价后，能够一键生成ERP中的销售订单后者合同。
- CPQ 可支持所有渠道，包括直销，合作伙伴，分销商，电商等渠道上的产品选配，价格调整，生成报价书。
Garter 2020 CPQ 魔力象限报告指出：在2019年，CPQ的全球应用市场增长了15.5%，达到了大约14.2亿美金。
实现销售BOM和生产BOM转化的意义
SAP对CPQ的理解开始于1994年，推出了Variant Configuration（VC），用于生产端和设计端定义可配置的产品（生产BOM），以及属性间复杂的关联和互斥规则等。当今一线的销售人员越来越需要一个专业的CPQ工具确保快速，准确的完成可销售的复杂产品（销售BOM）的配置和报价，同时企业还要确保销售给出的报价能够带来健康的利润。然而从销售的视角看CPQ，对可销售产品的属性和参数的理解是和生产端的产品不一样的，也就是我们说的销售BOM和生产BOM是不一样的。
销售BOM应该建立在生产BOM的基础上，然后从销售的视角重新去规划，比如说：产品目录，价格种类，以及多层级的可配置销售的复杂产品。销售要能跟客户有效的沟通，理解客户需求后，自己通过选配属性，系统自动根据配置和价格规则实现主动提示和选配控制，重要的是销售在选配的同时，马上就看到报价的变化，真正的所见即所得。但是根据销售BOM选配出来的报价，里面具体的产品项是从销售视角定义的，当报价传递到ERP端，要能自动生成包含生产BOM的销售订单，这就需要实现销售BOM和生产BOM的映射和转换。
过去这个BOM间的转化多是在CRM项目实施过程中提出的，但是很难清晰定义到底该在CRM端做转化，还是在ERP端做转化。其实无论在哪端做，都不是容易的事情。所以市场上自研发的CPQ，基本是个孤立的平台，和CRM和ERP都没打通。有一些选择了独立平台CPQ的，上线后多失败，又回到自研的老路上。
Why SAP CPQ
SAP CPQ 能够有效的实现销售BOM到生产BOM之间的转换，为什么呢？因为SAP对CPQ的理解和定位有自己独特的视角，很多企业自研发CPQ初衷是提升销售效率和体验，是不跟任何流程挂钩的，是个独立的销售工具。SAP认为CPQ是连接前端的CRM和后端ERP的一个桥梁，尤其是和后端ERP是需要紧密集成的。所以SAP在2018年收购了CallidusCloud的解决方案，其中的CPQ是一个有近20年历史的，专业的和纯云平台的解决方案。CallidusCloud CPQ作为一个独立的CPQ应用，被收购之前就和SAP ERP有标准的集成接口。收购后，SAP花了更多的时间和精力，结合特定的L2C（线索到现金）的业务流程，开发了更多标准集成组件，推出了开箱即用的集成流程，实现了无缝集成的销售报价到ERP订单自动生成的流程，也就是销售BOM到生产BOM的转化。
总结
那么CPQ本质到底是什么呢？它其实不是一个应用，而是一个平台，是一个引擎。销售前端看到的配置界面，系统提示相关配置规则等，都是需要在CPQ平台通过配置规则和参数，甚至结合少量代码实现的。通过访谈国内几家成功应用SAP CPQ的企业，我们发现CPQ最大价值是让企业在生产BOM的基础上，有机会认真从销售视角去定义销售BOM，梳理相关销售产品的配置和价格规则，最后定义在CPQ平台里。实际上这个梳理规则，并在CPQ平台通过配置实现的过程，本质上是一个研发/生产BOM向销售BOM转化的过程。
- 首先，产品主数据一定是从ERP导入进来的，也就是可以映射到的生产BOM。
- 其次，根据销售的视角，梳理产品目录和类型。
- 接着，梳理产品可选配（关联或者互斥）规则，可捆绑打包的规则，以及价格控制的规则。
- 然后，从财务的角度，从利润分析和风险管控的角度，可以梳理相应的规则和模型，在CPQ平台上实现。那么销售使用CPQ工具的时候，可以做到报价的时候就实现销售配置相关的财务风险管控。例如：当销售选择相应产品配置，给出一定折扣后，系统可以通过模型分析出利润率，对于低的利润，触发多级报价审批。从销售的角度梳理报价审批流程，在CPQ中通过配置就能实现，要比在ERP实现灵活和快捷。
- 最后，以上梳理工作会产生从销售视角实现配置和价格管控的一些规则和逻辑，通过配置或者是部分的脚本，在CPQ平台上实现，包括最后用户使用的选配界面。
以上工作需要企业销售运营，IT和实施团队合作，从销售视角，梳理清楚业务规则，最后在CPQ平台上快速实现，而且以后也易于维护和调整。这样一个完整的过程也可以看做是一个研发/生产BOM向销售BOM转化的过程。很多时候，企业前端CPQ项目启动是由研发部门提出的，这是因为老的ERP里的VC无法满足前端销售不断变化的业务，以及较高的销售效率和体验的需求。
综上所述，基于专业的、和ERP紧密集成的CPQ平台，从设计实现和最终使用的不同视角来看，是可以实现销售BOM和生产BOM的双向转化的。
CX老兵 – Ivan，SAP大中华区客户体验解决方案专家
超过18年CRM领域的经验，涉及解决方案的BD，GTM，架构，售前，顾问和实施等工作。最近11年专注于市场上主流SaaS CRM/CX解决方案，熟悉Oracle CX、Salesforce和SAP CX等解决方案。
更多有关CPQ和客户体验解决方案的知识，可参见专家Ivan的视频分享：