CPQ 选型第一步：看清你要买的是哪一类
市场上的 CPQ 实际分两类架构：基于订单的 CPQ 与独立 CPQ。卖标准产品选前者，卖复杂产品选后者——选错就是项目中后期推倒重来。
两类 CPQ 概览
起源决定能力边界
基于订单的 CPQ（Order-Anchored）
- 出身
- 从 CRM 长出来，作为销售流程的一个模块
- 核心使命
- 让销售把商机快速转成订单
- 配置形态
- 目录式选型 + 价格规则（选 SKU、加 add-on、套折扣）
- 适合卖什么
- SKU 化、参数有限、规则浅的产品 — SaaS 订阅、标准消费品、IT 服务
- 代表
- Salesforce CPQ纷享销客 CPQ销售易 CPQ
独立 CPQ（Standalone）
- 出身
- 从产品配置和制造领域长出来，产品形态本身就是核心命题
- 核心使命
- 让任意复杂产品的'配置-定价-报价'全过程数字化
- 配置形态
- 多层级 BOM 建模 + 智能配置规则引擎 + 工程级约束
- 适合卖什么
- ETO/CTO、深 BOM、跨学科约束的产品 — 工程机械、储能、电梯、电气成套、商用车
- 代表
- Tacton（海外）Experlogix（海外）锋巢 CPQ（国内）
基于订单的 CPQ 在复杂产品场景的三堵墙
不是好坏问题，是适配问题。但适配错了，项目中后期会撞这三堵墙：
BOM 墙
多层级、跨层依赖的 BOM 写不进目录式数据模型。一个工程机械底盘可能 10+ 层、200+ 节点、跨层耦合，目录式 CPQ 需要把这些拍扁成 SKU 列表，建模时已经丢掉一半信息。
规则墙
工程级约束（选项互斥、参数耦合、市场可用性、动态映射）无法通过 if-then 价格规则表达。当规则数从几十条涨到几百条时，目录式 CPQ 的规则维护成本指数级上升。
生态墙
CPQ 在企业系统中真正的位置，是连接 CRM、ERP、PLM 的销售协同枢纽——从 CRM 取商机、从 PLM 取产品与 BOM 数据、把订单与报价推给 ERP。当 CPQ 嵌入在某一 CRM 内部时，与 ERP/PLM 的集成需要额外路径，CPQ 难以充分发挥跨系统协同的能力。
选型决策
基于订单的 CPQ 适合你，如果：
- 你卖 SaaS 订阅、续费、消耗型计费产品
- SKU 标准化、配置深度浅、参数少
- 销售流程是核心，产品复杂度低
- 已经在 Salesforce/纷享销客/销售易生态深度投入
独立 CPQ 适合你，如果：
- ETO/CTO 制造业，产品族多变型多
- BOM 多层级、跨层依赖
- 工程级配置规则，互斥/耦合多
- 需要本地部署或跨 CRM/ERP/PLM 协同