未来工厂

在制造业做信息化的，没有不知道BOM的，许许多多看似不相干的问题，无论是制造领域的、销售的、采购的、物流的、财务的乃至售后服务领域的，追根溯源大多会在BOM问题上碰头。BOM是制造业信息化核心模型中的核心，这样的说法应该是不过分的，如今，BOM家族涌现了EBOM、DBOM、MBOM、SBOM、PBOM、CBOM等等新词儿，模样像孪生子一样，关系又密切的一塌糊涂，难免让人心生疑问，这都是什么东东？它们是什么关系？有必要分的这么细吗？这么分是业务上需求还是技术上的需求？可以简化整合在一个平台上么？

事实上，这些概念互相交叉、互相贯通、互相依存，即便是咬文嚼字，也不是一句话两句话可以说的清楚的。

早期BOM的定义¶

三十年前的MRPII、ERP时代，BOM的概念是很纯洁的，它只是Production Plan生产计划子系统中的一个模块，也有专家倒过来说的，历史上是先有BOM的，后有MRP，再有MRPII，然后才发展出ERP的。不管怎么说，BOM是ERP的核心模块。BOM的原始定义是这样的：

A bill of material is a complete, formally structured list of thecomponents which make up a product or assembly. The list contains the description and object number of each componenttogether with the quantity and unit of measure.

物料清单是一套完整的、形式上被结构化了的组件清单，该清单描述了产品是如何构成的或是如何装配的。清单中包含了每个组件的说明和对象编号，以及数量和计量单位。

这个概念的定义用词很精确、很考究，从技术和业务两方面加以论述，其中业务部分又细分为业务目标和信息两部分内容：

a)  技术上讲，BOM是完整的，不是零散的、残缺的；数据是结构化的，不是非结构化的普通文档如TEXT文本或WORD文档，也不是半结构化的描述性数据如XML、JSON，它有清晰的数据模型，比如列表、树、网络等模型结构，隐含着具有标准的搜索算法，如纵向展开、横向展开、反查等等。

b)  业务目标上讲，BOM是描述产品是如何构成的或是如何装配的，请注意，这里明确区分了产品构成和生产装配两种结构，这是面向开发的Design BOM和面向制造的Manufacturing BOM的根本区别。

c)  业务内容上，是组件的相关信息。如代码、名称、数量、计量单位、提前期、供货地点等等，ERP厂商会根据需要增加自己的条目，如报废率等等。

如果再抽象一点的说，广义上的BOM包含节点以及节点之间关系这两类信息，在IT系统上体现为物料主数据和产品结构数据（狭义的BOM）。

通常，业务人员讲BOM的时候，多数是广义的、模糊的，而IT人员尤其是ERP专家，往往说的是狭义的产品结构数据。同时，人们也容易将技术上不同的BOM和业务上不同的BOM混在一起讨论，各说各话，因此，在现实工作中经常会产生各式各样的冲突和意外。澄清一些概念是必须的。

按技术角度分类¶

从IT技术上看，BOM的结构是通过父子关系（上下级关系）来定义的，因此，它是一种树形结构。根据节点的性质可以分为：

S-BOM Simple BOM简单BOM：  单一产品对应单一的结构，每一个节点对应一个实体物料。这是最基本的BOM，其他类型的BOM，都是为了管理和使用上的方便，通过为节点定义不同的属性而产生的变化。

V-BOM Variant BOM（变体BOM）：是为了简化维护BOM的工作量和复杂性，将相似的产品组合在一起的方法，即不同的产品使用相同的结构。技术实现上面就是在节点上增加可配置的Feature/Option（特征/选项），或者叫Character/Values，通过不同的属性值推演出不同的产品BOM。适用于描述产品系列、产品族、平台的结构数据。典型的是平台化的汽车，根据发动机排量、自动/手动变速箱、颜色、左右舵、座椅类型等等不同特征的选项，组合出多种车型和细分配置。

M-BOM multiple BOM（多重BOM），也叫alternativeBOM（替换BOM）：同样是为了简化维护BOM的工作量和复杂性的目的，但描述的是同一产品的不同结构，即同一个产品，存在可以互相替代的结构，以适应不同的批量、日期、工艺结构等的需要。技术实现上面通过BOM的版本来区分。比如同样一款车，在工艺布局不同的工厂生产，就可以通过不同的版本号来定义BOM。

Plan-BOM计划BOM：子项的数量是百分比，子项各数量之和为1，用于企业顶层销售经营SOP计划中，计算产品系列中各产品的配比。

PHANTOM-BOM虚拟BOM：为了计划、调度、运输、搬运、出入库记账的方便，将一些离散的零件组成Group或Kit，归集到一个父项下面，但父项并不是实体的物料。比如一家供应商为整车制造厂，供应两种以上的零件，在拉动的时候，为每一个零件产生一个拉动单，不如为这几个零件做一个组合，一个拉动单就够了。

WBS-BOM：为了减少成品和半成品的物料数量，在物料代号之前用WBS来表示生产批次，用以区分。比如销售计算机，不同项目需要的计算机配置不同，如在内存和硬盘不同。一般情况下，我们要为不同的计算机创建不同的物料编码，然后建立不同的标准BOM。在配置变化比较频繁的情况下，则需要建立大量的物料代码和多个BOM，维护起来会很麻烦。在这种情况下。我们只建一个计算机的物料代码，然后用WBS编码+物料号创建WBS BOM，实际组成部分可通过WBS BOM进行展开，这样在PS上只需要挂一个物料‘计算机’的需求，然后跑MRP时会自动根据WBS BOM的组成，创建结构相同或相似但零部件性能不同的生产订单。

Flat-BOM扁平化BOM：为了避免多层级BOM的复杂性，通过定义物料的功能、位置等属性，免去结构层次划分，把所有物料零件展示在同一个层级上的形式，对于分类管理零件，尤其是变更管理，比较直观。在有DBOM支持的情况下，EBOM扁平化好处非常多，如果有CBOM支持生产阶段的成本归集，对于最终装配流水线型FAS制造，MBOM扁平化使用起来也非常方便，特别容易通过Excel方式使用，缺点是零件逐级反查上级直至最终产品不容易。

Super BOM超级BOM：为父项是可配置物料定义的BOM称之为超级BOM，在该物料下面挂上了所有可能使用的物料，即所有可能的选装项和必装项。通常为产品族、产品系列、平台定义超级BOM。它并没有专门的技术结构，它是用Variant BOM加分类等技术组合实现的。

按业务分类¶

盘古老哥自从开辟天地之后，他的大斧子就一直挥个不停，太极分了两仪又分四象再分八卦，把人类从动物中分离出来，然后从狩猎分出了农业、分出了商业、分出了工业、分出了服务业、分出了各行各业。为什么要分呢？根本原因，就是专业化，专业化能带来效率、质量、成本的优势。

BOM也是如此，好好的一个概念，不停地细分，如今已经被分的七零八落了，这也没别的原因，就是业务的专业化。企业越大，产品越复杂，组织越需要专业化分工，BOM也就越细分。粗略收集一下，先如今BOM大约已经分了且不限于如下几种：

CBOM（Costing Bill Of Material）：简称成本BOM，其实是成本测算BOM，Costing是动词，不是名词，包括Product costing产品成本测算、Unit costing单位成本测算、Standard costing标准成本测算。在研发、试制、生产、销售各个阶段，都有不同的测算内容和成本归集方式，基本上是从下到上的累积方法。

DBOM：设计BOM，是设计部门在研发阶段的产品信息，通常是CAD平台上的BOM，对应图纸的说明性文本，包括产品明细表、图样目录、材料定额明细表等等，DBOM信息的来源是设计部门提供的成套设计图纸中的标题栏和明细栏信息，有时候也涉及工艺部门编制的工艺卡片上部分信息。有两种用途，一种是设计结束前汇总的结果，用于交付制造或创建EBOM，另一种用法是开始设计前编制，用于分解设计任务，安排设计工作。对于复杂产品联合开发，由于过于专业，CAD平台通常不一致，因此，DBOM通常是分散的、局部的。

EBOM(Engineering

BOM)：在产品工程开发设计管理中使用的，涵盖产品整体的技术结构数据，它精确地描述了产品全部的设计指标及零件与零件之间的设计关系。对应文件形式主要有产品明细表、图样目录、材料定额明细表、产品各种分类明细表等等，在研发到试制投产阶段的使用，为创建MBOM提供基础数据，通常在PDM平台上使用，因此，EBOM是整体的、系统的。

MBOM （Manufacturing BOM）：生产部门在EBOM的基础上，根据制造装配要求完善的、在正式生产阶段使用的BOM，是ERP系统中的核心模块。可以包括产品加工、装配过程中所需的零部件生产、采购、物流、质量检查、工具工装、成本等所有信息。从历史的发展看，MBOM最接近BOM的初始概念，也是BOM应用中最广泛的。对于中小型企业，以MBOM为核心，增加些对销售、成本、质量等业务的支持就足够了。

PBOM （Plan BOM）：在企业正常生产运行阶段中，用于顶层编制中长期销售经营计划SOP，使用配比对现有产品线产品进行平衡计算，进行产品的销售生产预测以及产能利润模拟。

PBOM （Process BOM）：工艺BOM，按照加工装配过程对DBOM进行信息补充、结构调整、完善的BOM，是研发到正式生产阶段的产物，技术上可以独立也可以合并在EBOM平台中，业务上是EBOM向MBOM过渡阶段最重要的内容，特别是对流水线装配模式，工艺BOM的结构基本就是MBOM的结构。

SBOM（SALE BOM）：十年前说销售BOM时，指的是订单生产MTO方式时，用销售订单安排产生以及成本归集，销售订单下面会挂着零部件明细表BOM。现在说销售BOM时，也有可能说的是B2C平台上，厂家为了给用户更好的参与体验，让用户在客户端（PC端或者手机上）在线选配自己的商品，即提供选配支持的BOM。

SBOM（Service BOM）：服务BOM，在售后服务领域使用的BOM，一是在维修时使用，二是在订购备品备件时为MRP使用。

TBOM：试验BOM，在研发阶段，试验测试样机样品时使用的BOM。

... ...

特点、关联与策略¶

DBOM是家族中最基础也是最不正经的BOM，不精确、不一致、不稳定。用它来组织采购生产，变来变去的会非常气人。三十年前，笔者的总调度室师傅常常把研究所叫成劳改所（老改所）、劳改队，把他们的工程师叫劳改犯，见面的第一句话常常是：“哥们儿，改造好没？今天还改啥？”

DBOM是新产品开发阶段中使用的，一种情况是按订单设计制造ETO模式下的，所谓的全新设计，单件或单批次生产。这个BOM的寿命很短，出于时间进度和成本的考虑，一般不会对这BOM进行严格的工程化处理，其中有的零件可能都没起名字，这样的产品更像是艺术品，逼格很高，个性十足，它的BOM么，也就不那么讲究，归档的时候能交给档案室就很不错了，零零散散的，不成体系。

另一种情况，是专业开发公司或者是大企业中相对独立的研发中心使用的，纯粹是偏向产品开发的，聚焦于产品的结构、功能、性能、外观等，能仿真模拟到可装配就够了，最后图纸一卖就结束了。它是面向市场的、面向客户的、前瞻的、预判的、储备的开发，它设计的时候是开放的、浪漫的、鼓励创新的、鼓励有想象力的，不针对具体的工厂需求，不会从工业工程/人机工程的角度去考虑装配的问题，更不会考虑哪个工厂是何种布局用什么设备采用什么工装了，这个环境生长的BOM是比较野蛮的，玩儿DBOM的是大师、是专家、至少是屌丝，都有性格。

MBOM是面向制造的，它以产品装配结构为主线，把工艺的、质量的、采购的、物流的、成本的相关信息关联起来，从而保证系统性和一致性，它面向工厂、车间、库房、供应商，面向计划员、调度员、采购员、工程师、库管、操作工。它是严肃的、规矩的、死板的，跟生产布局、工艺过程、加工设备、工具工装模、包装大小、供应商距离都密切相关的。它是直白的、琐碎的、说明性的、命令性的，与艺术性无关，让大师、专家、屌丝们去支持生产一线解决一线的问题，肯定缺少共同语言，他们没耐心、做不好、也不经济。一线员工也不理解大师们的情怀，不崇拜专家的玄奥，更不屌屌丝的激动和忧伤，互相伤害是一定的。

另外，超大型跨国企业，它产品开发往往是联合开发，比如美国通用汽车，它开发一个车型，底盘可能是在欧洲Opel开发的，内饰可能是在韩国大宇开发的，造型可能是在意大利开发，动力可能是在北美开发，而制造可能是在中国、南美、南亚、美国本土等几十个工厂，这样复杂的开发活动和复杂的应用场景，大量异构的CAD平台和ERP平台，不可能建立出对所有工厂都通用的DBOM，也不可能让世界各地的设计人员去支持世界各地的工厂生产，仅从沟通语言方面上讲也是做不到的。

因此，对于产品复杂、开发过程复杂、生产组织复杂的企业，DBOM与MBOM是必须分开的，必须把浪漫诗意散文化的DBOM转化为说明文的MBOM。

DBOM向MBOM转换，不是件容易的事，不是简单把DBOM的信息转换到ERP平台，它要补充处理许多信息，如：

1、  调整BOM中的零部件父子关系，DBOM的父子关系是组成关系，MBOM的是装配关系，需要按照装配工艺进行组合，便于物料的配套Feed，比如部件之间的连接装置，是独立成一个部件或是放在哪个部件之下合适，完全取决于装配和物流的需要。也就是说设计BOM中的父子关系可能变成制造BOM中的兄弟关系或者更复杂的旁系亲属关系。

2、  DBOM中的零部件号拆解，DBOM中的零件是成品零件，如果它是企业自制零件，则可能随着其生产路线变化，在MBOM中存在几个对应的代码，比如精加工之后的零件与粗加工后的零件可能需要分开识别，零件热加工前后也许需要赋予新的代码，用于不同车间的交接领送料。也就是说DBOM里的一个零部件随着生产路线变化，可能在MBOM中存在几个对应的代码，而且代码之间根据生产路线流转顺序存在父子关系，最后进入总装工序对应的代码才是DBOM中的零件代码。

3、  合并出新的部件或合成件，有些零件在DBOM上没有定义成组合关系，但出于分步装配的需要、或者加工技术需要、或者搬运吊装需要、或者因为共用同一板材的需要，可以把多个物料合并到一起，在MBOM中定义虚拟的父项或者实体的父项来组合这些物料。

4、  负数量处理，DBOM中子项的数量都是正数，但在制造过程中，由于有副产品的产生和回收，或者根据原型产品进行变形设计，也可能使用加减的方法进行变形，因此，MBOM中可以有负数。

5、  工具工装，对于特殊工序使用的特殊工具工装以及包装等，可以挂到MBOM上，在MRP运行时，产生工具工装的需求计划。

6、  质量检测，对于特殊工序特定零件的质量标准及检测项目，可以挂到MBOM上，在MRP运行时，产生质量检测任务。

7、  购制数量调整，DBOM中子项数量是产品组成的准确值，在MBOM中，要把预留、备用、报废率等因素考虑在内。

8、  购制期量标准的设置与调整，DBOM中的零部件只有数量，没有采购制造的提前期、订货批量等定义，要补充的。

9、  编码转换，DBOM中的物料，在不同国家不同工厂不同供应商那里，很可能有不同的编码，MBOM的物料代码要保证其本地化。

10、 成本要素，DBOM定义相同的产品，到了具体的工厂，除材料成本之外，还要定义许多可变不可变的东西。

这些工作谁来做？这是什么性质的工作？交付物是什么？什么时间做？

前文分析过，设计大师与一线制造是互相伤害的天敌，因此，做这件事的一定需要一种亦鸟亦兽的中间角色，通常叫技术管理，他们在设计大师面前代表制造提出需求讨要数据，在制造面前代表专家权威发布。是很牛X的管理岗位。其实，两头的脾气都很大，都惹不起，这个角色很受气，好处是出了问题可以两头甩锅，不会被杀头。而且，要以产品装配结构为主线，把工艺的、质量的、采购的、物流的、成本的相关信息关联起来，需要多个平行部门参与，由一个偏中立的角色牵头是大家能接受的。同时，在跟踪解决问题时，领导也需要一个置身事外又涉事其中的信使。因此，这个角色在企业中还是很受重视的。

度娘说了：工程化即系统化、模块化、规范化的一个过程。指将具有一定规模数量的单个系统或功能部件，按照一定的规范，组合成一个模块鲜明、系统性强的整体。工程化往往包含大量学科和学科分支的知识，是一个复杂的系统工程过程。按照这个说法，把艺术化的DBOM向工业化BOM转化的过程，正是工程化的过程。

这么高大尚的工作一定要有规范、体系、平台，要有交付物，不能把功劳算到两头去，要在中间搭一座桥梁，这座桥，是开发过程的里程碑，这就是EBOM。

EBOM通常叫工程BOM，其实，准确地说应该叫工程化BOM，Engineering是动词，是在特定阶段的一系列活动，不是面向开发的，是面向开发管理的，面向管理的！！！使用阶段主要是从DBOM阶段性交付到正式生产前这一段时间，包括寻源、试制、试装、产品验证和过程验证等环节。

那么，测试的TBOM与EBOM有必要分开么？如果企业没有独立的中试实验室或者试验试装中心，开发测试工作是在工厂中完成的，那就没有必要分开了。

用EBOM或者MBOM可以取代Sale BOM么？如果仅仅是MTO模式创建订单使用，完全可以的，历史上就是这样的。但如果这个企业的Marketing能力很强，B2C做的很大，Sale BOM的存在还是很有必要的，比如用户在线定制自己的订单，如果选项是一大堆冰冷的难懂的技术指标，客户的体验一定是很惨的，如果可选项是经过精心设计的市场化噱头，那客户的感觉就不一样了。因此，销售选装与产品技术选装是可以也是应该分开的，分开了就需要关联，需要转换，在哪里转换，就看三家谁的本事大了。

Service BOM的信息来源是EBOM或者MBOM，用EBOM或者MBOM可以取代ServiceBOM么？不能。第一、自从进入多品种定制化生产阶段以来，售后服务的难度就加大了。以往一本产品目录就可以包罗万象，应付所有的维修问题，现在做不到了。产品批次、选装、替换、变更以及多供应商策略，导致同名同姓的产品，装的零件可能并不一样，同名同姓的零件，长的也可能不一样。出长差去用户那里维修，带错零件的概率增大了，4S店里给哪些零件预备库存的难度也加大了，这些问题让设计或制造人士去支持解决，烦死人了，不能够的。第二、EBOM或者MBOM产品结构定义到可采购的级别，比如发动机，一个零件号就够了，但在维修的4S店里，发动机可维修零件的颗粒度要细很多，否则有点毛病就换发动机就赔死了。因此，Service BOM的内容比EBOM、MBOM要多许多。第三、维修备件的储备和订购，要考虑在维修期内但已经不生产的产品，这其中的替换借用关系非常复杂，一旦存在外部替代关系，EBOM和MBOM就不够用了。

CBOM是众多BOM中比较难为情的，虽然COST很重要，虽然COSTING很专业，虽然每个阶段都有它的身影，但它却不是自有的独立的体系，它的信息都是来自于其他BOM，并且在各个BOM中的要素和归集算法都不同，只能依附在人家的屋檐下面。建设和维护独立的CBOM平台是不科学的，每个xBOM项目开发过程中，不为COSTING预留功能也是不厚道的。

BOM应用的起点、重点与难点¶

BOM应用的起点是零部件的统一编码，没有统一的物料编码体系，开发与制造的效率、成本、质量问题都无从谈起。

在BOM应用中，重要的是科学恰当地分类分层，选择合适的模型，理顺它们的关系并统一管理。不是说把BOM分成DBOM、EBOM、MBOM就够了，怎样进行平台化管理？怎样进行模块化开发？怎样支持多国、多工厂制造？仅仅使用PDM/PLM/ERP厂商的DEMO模型是不够的，再进一步进行业务细分然后二次开发是必须的。只要有分解，就要有关联，松耦合还是紧耦合？一体化集中还是集成？这些技术问题很难搞，但最重要的是业务BOM转化的节奏与数据一致性的矛盾如何处理，不是技术，是业务。

管理BOM最难的当然是变更。这个话题太大了，远远不只是变更的流程管理，它的复杂性不能用一个章节来讲了。