关于销售BOM设计方案的思考

背景

在设计整个报价配置器系统功能以及集成的时候，笔者在做这个功能框架设计的时候，除了考虑现阶段以及历史的一些信息，还规划了一些后期的功能和设计。但是在系统设计过程中，有一些功能的设计，或者说对应主数据的设计由于时间和精力问题，没有做深入的设计，更多的是满足现阶段需要并快速上线。但是项目的一个阶段工作告一段落的时候，适时还是要总结反思一下，设想一下如果资源充足情况下的设计方案。因为有些设计考虑的过于深远，会进一步扩宽项目的边际，增加开发及落地的周期以及风险，所以也不能事事都尽善尽美，一句话，合适的才是最好的。

这次思考的是销售BOM那块的设计。尽管和生产技术在场面上吵的不可开交，并和二供解决方案达成了形式上的共识，但是其实最本质的问题我们这次始终没有涉及。所以还是有些缺憾的。这里说的本质问题并不是指我们目前看到的具体的BOM内容，例如一个产品下该以什么维度搭建，更多偏向于销售BOM实施方案方向（SAP）。下文仅做方案构想和技术方案交流。

2、基础概念

首先我们先从基础概念入手吧，即先了解公司目前的业务场景以及常用系统基础概念，包括成套产品（销售）、项目销售以及销售BOM等。之后再聊整个方案，会比较有抓手。

概念解释：

• 什么是成套产品或什么是成套销售？

字面意思很好理解，成套销售指的是公司销售的产品是进行成套销售的，即销售相对固定组合的组合产品，组合产品会需要一些比较基础的组装操作，这些组装操作往往在仓库而非车间完成的。例如销售威派格小超市有卖的一套旺仔大礼包，里面需要包含一包仙贝，一包雪饼和一包小馒头。仓储的工作人员，直接基于清单或销售BOM（后文会详细解释）组装即可。需要注意的是，成套产品销售发货时必须整套一起发货，不能拆分发货。我们常见的比如旺仔大礼包，经常吃的同学会发现，里面的单独包装的仙贝，有时候会标注“不允许单独售卖”字样。这个和单独售卖的仙贝也许可能会共享一个产品总克数，但是在系统里对应的SKU编码（商品编码）是截然不同的。

针对这个模式，如果订单是按照母产品（旺仔大礼包）进行定价，那么需要发货时将子产品（大礼包中的仙贝、雪饼、小馒头等）的成本归集到母产品。在这个情况下，系统开票也是按照母产品进行开票（大礼包）。反之，如果是按照子产品进行定价，那么开票也是按子产品进行开票。

• 什么是项目销售？

目前我司主要的销售基本以项目销售为主。项目销售不同于产品销售，产品销售比如威派格小超市卖我一个旺仔大礼包，一手交钱一手交货即可，项目销售往往需要具备一定的周期性。从生产到销售的周期比较长的产品，往往都会采用项目类的销售，从销售产品生产、安装、调试、验收以及最终的维护，都由销售公司负责。

简单来说，威派格是项目销售为主，销售内容为成套产品（设备）为主的公司。主要注意的一点是，项目销售订单（SD订单）是不跑需求的，是需要由项目端创建预留发起需求。交货时也是通过对应项目来交货，销售订单也会关联到项目中的WBS元素，从而进行按项目的交货以及开票。

• 什么是销售BOM？

在制造型的企业中，BOM（Bill of Material）是会被经常提及的。BOM除了描述了一个产品（母产品）的组件（子产品）构成清单以及用量外，BOM也能承担许多部门和部门之间的需求信息传递的功能。所以我们今天要说的，并不是广泛应用的生产用BOM，而是销售BOM。可以从字面进行理解，销售BOM就是和销售行为，销售订单密切相关的。基本都是只有一层结构，子项基本都是以底层的零配件构成。

那么可以思考一下，在比较标准的场景里我们怎么用销售BOM进行信息的传递。首先我们要清楚，销售BOM盒销售订单之间的关系。首先我们在销售过程中，会产生对应的销售订单，销售订单中例如售卖了一个成套产品，那么我们就可以基于销售BOM展开对应产品下的物料清单，来汇总需要的组件明细信息。其次，业务流程上，销售端的需求会流转到生产部门生产，生产完毕后会需要物流部门进行发运。在最终发运时，仓储拣配使用的领料单信息也是源于销售BOM。

这里补充一个知识点：对于那些进货时是零配件，然后经过组装形成成套产品进行销售的企业，根据产品的销售订单的需求，使用Excel等工具来管理零配件的采购/进货/库存是很繁琐的。另一方面，对销售对象(成套产品)，采购入库对象(零配件)，出货对象(组装完的成套产品)，请款对象(成套产品)做到协同精准管理也是比较局限的。比如，接受到客户订单后 需要录入组装产品的客户订单，人工根据订单数量汇总所需零配件的数量才能下达零配件采购订单。所以销售BOM使用范围不局限于生产制造行业，根据业务需求，食品加工业、进出口贸易行业等同样可以使用。

简单来说，通过使用销售BOM，我们可以实现成套产品定价以及组件的进销存管理。

But 目前威派格没有使用这种模式，因为首先第一我们经常要缺料发货，那就没有成套以及成套BOM的概念了；第二由于组件组合情况过多（技术部门某同事说有三千多万中排列组合...）我们技术部门在PS里会有技术部门针对单套设备进行人肉挂料，替代了BOM的作用；第三，我们项目使用了PS，PS提供了WBS元素这个载体，相对来说需求下达流转没有那么困难。虽然有一些弊端，但是只能说受限于目前的企业实际业务场景，短时间应该也很难进行迭代升级了。

1. 本项目实际应用与规划思考

【本项目实际应用方案】

销售过程

1. 建立销售物料主数据概念：从PLM中现有物料主数据中选择以及根据现阶段需要进行补充，确认销售用物料主数据（产品、组件）与通用物料进行区分。报价配置器系统仅显示销售物料。原则上保持一物一码，通过赋予额外属性的方式进行分类标记。
2. 同步建立销售BOM：在SAP中同步建立销售BOM，BOM用途为5。根据与业务部门达成共识的主数据方案，二供设备以构成组件的方式搭建销售BOM，软件产品以模块构成组件的方式进行搭建，在报价配置器系统中只要输入父项物料，会自动根据对应的销售BOM带出下层物料以及对应的用量。在完成报价审批后，传输对应父项物料信息至OA合同评审中作为产品信息使用，后续由OA推送对应信息至SAP中SD模块创建销售订单。
3. 建立成套产品定价规则：财务对子物料进行定价，构成的子物料不进行库存管理以及成本核算，为虚拟物料。父项物料由销售BOM中维护的子物料清单自动卷积计算价格，在销售订单中把父项物料作为销售项目，并直接使用父项物料的价格，父项物料同样不做库存管理，为虚拟物料。
4. 是否进行可用性检查：父项物料及子项物料均不参与可用性检查

采购、入库、出库过程

1. 维持现状，由技术部门进行人员挂料后流转需求到生产和采购部门进行相应的业务活动，后续挂料清单打印装箱单后发运

请款过程

1. 维持现状，发票维度上只显示产品维度（父项物料）信息

【规划思考】

目前主要的问题点在于，目前在SAP中维护的销售BOM仅在报价配置器系统中进行了应用，对现有SAP中流转流程几乎没有去做推动及改动。虽然这是风险最低，上线比较效率的方案了。但是我们希望借助销售BOM来建立标准产品的概念，降低技术部门评审及挂料的工作量的诉求没有达到。没有借助销售BOM这一载体将信息从销售端穿透到生产物流端。此外，成套产品的概念及流程操作也依然没有做相应的改变，还是散件缺件发货的操作模式。

目前只能说，借助销售BOM，在报价阶段，提升用户的产品理解，减少定制化需求的比例，降低询报价专员的工作量等业务痛点。饭只能一口口吃了，事情也要一步步做。但是我们要对销售BOM这个概念以及其常用的应用有所了解，做好后续的规划，等待进一步优化的时机吧。知道自己实施或者设计的不足，适时总结，也是一种收获。