企业级BOM应该如何搭建

1.引言：关于BOM架构问题概述

　　在企业的BOM管理实践中，有两类问题表现得非常突出，一类是关于数据冗余的问题，另一类是关于配置信息的传递的问题。

　　数据冗余带来的问题非常明显：同一份数据在产品上被重复定义，必然带来产品数据不一致性，不一致性带来的问题是变更管理的问题。当同样的数据被定义在两处地方的时候，发生设计变更时，必然要考虑如何同步的问题。另外，数据冗余也会造成不必要的工作量增加，数据维护困难。

　　很多企业至少在研发端的BOM都按照超级BOM模式进行组织，是否解决了这一数据冗余问题呢？答案是否定的。超级BOM在一定程度上确实缓解了这一问题，但超级BOM本身的架构如果不合理，则这一问题还是显得非常突出。比如我接触过的企业，很多都以分组为单位组织BOM数据，有的企业甚至会将全车所有的小开关放在一个分组下，其中任何一个发生变化，都需要重新构建一个分组。而每个小开关的变化实际上是比较独立的，从分组上并无共同的特性，这样就会导致分组不断增加，以满足其中任何一种开关的变化以及这种变化的组合。这种模式下，所谓超级BOM相对于单一产品BOM，其实并无优势可言。

　　另一类问题即关于配置信息的传递问题在国内企业中也非常突出。国内除了实施过企业级BOM的极少数车企外，配置化信息实际上没有被充分利用，基本都停留在配置表作为记录产品信息以供下游参考的表单，研发端的BOM虽然以超级BOM方式组织，但真正利用配置信息进行BOM解析的很少，到制造端就更难了。从数据组织方式来看，研发端的BOM往往会基于设计的需要定义一些中间层级，这些中间层级包括上面所说的分组以及一些其它设计虚拟件。配置化信息往往作用在这些层级上，而这些层级无论是制造、试制、售后甚至研发端的成本分析、重量管理都可能不需要。这样问题就产生了，当BOM向其它领域传递的时候，这些配置信息就“丢失”了，需要各个业务领域重新梳理配置关系，这就导致了各个业务领域所需的BOM事实上完全独立，而不能够做到贯通。

　　上述类似的问题非常多，由于篇幅关系，不在此一一枚举。分析造成这些问题的原因，我经过长期的项目实践以及理论研究，总结了以下两个方面：

　　1）多年PDM实施的影响：PDM数据组织方式无疑是偏向技术的，很少关注跨业务领域的管理，其对BOM的组织实际上缺乏管理内涵。这对于PDM来说无可厚非，因为毕竟研发内部的技术问题才是其关注的核心。但作为企业的用户而言，如果完全被这种思路所束缚，则企业的信息化就难以有突破。

　　2）企业对于配置化管理实际上心存畏惧，总期望走一个“即借鉴国外先进管理经验、又照顾本企业实际情况”的“稳妥”的路子，把配置管理考虑得过于简单、过于“具有可操作性”（例如在分组层级定义，那么对于汽车这样的复杂产品，最多也就200-300个分组，配置条件很好定义），从而导致实际上没有什么配置化管理。

　　这些问题都指向了一个根本的问题：BOM究竟怎么搭建？这是一个BOM架构问题。现在企业很多BOM管理层面的问题实际都与之相关，脱离BOM架构问题去解决BOM的具体问题，很多时候就会有头疼医头、脚痛医脚的感觉。

2.BOM架构的三个层面

　　一个完整的对产品进行定义的抽象模型包括三个层次。

　　首先，市场需求的多样性要求企业以多样化的产品去满足，因此企业的产品往往基于系列化进行规划、研发、生产。这样，产品将会变得非常多，比如有些商用车厂，可销售车型达到上万个甚至几十万个。多样化的产品定义，我们可以认为是产品定义的**个层次。

　　其次，零部件数量繁多。特别是国内企业，零部件控制往往做得不到位，导致零部件号急剧膨胀，***零部件号在企业中也非常普遍。这些零部件以何种形式进行组织，这是产品定义模型的第二个层次。

　　最后，也是最关键的问题是这些零部件是如何被产品所使用，这是BOM的核心问题，在产品定义模型中起到承上启下的作用。我们可以认为这是产品定义的第三个层次。

　　上述产品定义的三个层次，**个层次属于产品型谱定义。这部分难度在于业务定义，而IT管理层面问题比较少。第二个层次属于设计问题，在PDM/PLM中有较好的解决方案（特别是零部件结构层级）。第三个层级则是企业级BOM要解决的核心问题。

　　从企业级BOM管理思路而言，BOM所肩负的使命是贯穿全业务链，进行跨业务领域的协同管理。这一思路需要体现在BOM架构中才能够得以落地。对应到上述产品定义的三个层次，BOM架构考虑包括三个方面的内容：

　　1）超级BOM应该在哪个层级进行搭建比较合理？这一问题对应到产品定义的**个层级，即超级BOM与产品型谱的关系。

　　2）超级BOM以下分多少层结构比较合理？这一问题对应到产品定义的第二个层级的问题，即BOM的分层结构。

　　3）配置定义在哪一层级比较合理？这一问题对应到产品定义的第三个层级的问题，即零部件使用关系如何表达。

3.BOM与产品型谱的关系

　　在实施企业级BOM时，一般会与客户首先讨论产品型谱。客户往往会有困惑，觉得这两者没有必然的联系。这种困惑是有一定道理的。很多企业多少年来在企业范围内就没有统一过型谱定义，但并不见得不管理BOM。

　　产品型谱的定义对于企业非常重要。产品型谱定义有助于在全企业范围内，从产品规划、产品设计、产品制造、产品销售形成统一的对产品家族的完整认识，确保策划的产品能满足市场需求，设计、生产的产品与规划相匹配，从而与市场一致，确保销售能够正确引导市场的购买行为等。当然，产品型谱并不是为BOM而定义，不实施BOM项目，也需要规范化产品型谱定义。在企业级BOM系统实施中强调产品型谱定义，是期望企业能够比较全面、比较彻底、比较长远地建立起BOM管理规范。

　　那么，产品型谱究竟影响了BOM什么？简而言之，影响了BOM的构建策略。当企业没有规范化型谱的时候，BOM的构建策略就不容易建立起来，或者说比较随意。

　　所谓BOM构建策略，是指超级BOM应该搭建在什么产品上，要解决的问题是超级BOM基于平台搭建还是基于产品系列或产品型号搭建、新的改型项目要不要另外搭建一个BOM等问题。

　　对于这一问题，不同企业答案会有差异。以我实施项目的经验，总结了以下关键因素：

　　1）企业实施平台化程度、对设计重用度的期望。

　　2）历史数据的状况、复杂程度。

　　3）人员专业技能状况、业务规范程度。

　　4）生产切换的要求。

　　以上四个层面决定了BOM在哪一个层级构建。项目实施时，需要就具体企业的情况进行以上四个层面的分析。

　　以上讨论的是BOM架构的**个问题，即超级BOM应该在哪一层级进行定义的问题。简而言之，定义层级**对应到产品型谱的一个固定层级，从设计重用角度这一层级越高越好，但需要考虑历史数据、人员技能、规范化程度、生产切换等具体情况进行具体分析。

4.零部件的组织模式

　　关于零部件的组织模式，可以简单定义以下模型进行说明：

　　在上述模型中，零部件组织模式可以简化为三层结构，即代表零部件上层组织的设计虚拟层、BOM核心层以及零部件结构层。

　　设计虚拟层可以对应到企业中一般的分组、模块层级或者其它虚拟总成级别。从企业级BOM管理思路而言，这一层级搭建得越深，BOM管理效率越低。企业级BOM管理中一个重要的实践经验是扁平化思路，所谓扁平化思路，就是尽量使得这一层级的层次变少、甚至没有。

　　据我对于多个客户的实施经验，企业在这一层级的定义上问题**。层级过多、将这一层级实例化都是典型的问题。企业往往缺少对这一层级进行管理的有效方式，而是简单按照PDM的方式进行管理，束缚了企业级BOM核心管理思路。

　　BOM的核心层是指无论哪个业务领域都非常关注的层级。那么哪一层级才是各个业务领域都关注的层级呢？毫无疑问，是生产线上所需要的具体的零部件，这些零部件实际由装配供货级别和采购供货级别零部件构成。BOM在从规划、工程、制造、生产、售后等各个业务环节流转的时候，这些信息是不可缺失的。而BOM如果能够保证这些信息准确无误地传送，才能够说达到了贯通各个业务领域协同的作用。因此这一层级才是BOM的本质。

　　零件结构层级是指零件本身的打散结构。这一层级的特点是下面再没有配置变型，即任何一个零部件底下的结构代表了一个固定的结构，确保在不同地方被使用的时候，这个零件的固定结构是一致的。

　　传统的PDM/PLM对于零部件的组织方式，在零件结构这一层级的管理是比较合适的，而BOM核心层以及以上的设计虚拟层则并不适合于企业级BOM的管理思路，如对于设计而言，往往因为坐标位置的关系需要实例化设计虚拟层等，在此不再细化讨论。

5.配置层级的定义

　　讨论完以上关于零部件组织方式的问题之后，配置层级的定义就有了水到渠成的答案：所有BOM的核心信息都需要定义在BOM核心层，才能够保证信息在各个业务领域的贯通；配置信息作为超级BOM最为关键的信息，毫无疑问应该定义在该层级。

　　这一理念表达如下图所示：

　　不同业务领域实际上是针对这些零部件的不同运用，而BOM的构建过程实际上是从产品策划开始，产品设计、产品策划、采购、制造等一起确定零部件的采用以及其制造加工深度的过程，而BOM首先是管理这一过程的信息化工具，其次是承载这一过程各阶段的成果。

6.结语：企业级BOM架构的**使命是支持跨业务领域协同

　　企业在BOM管理层面出现的问题必须借助BOM架构上的改变来解决，在原有框架下很难解决一些根本性的问题。上述讨论都是基于企业级BOM思路出发、而不是基于设计内部的技术出发进行探讨。这一思路的核心观点是BOM是企业全业务链中起到协同作用的管理工具，因此基于这一思路进行BOM架构设计的**使命必然是支持跨业务领域的协同。这一重要使命恰好将企业级BOM与PDM/PLM进行了清晰的定位：PDM/PLM以其三维结构/CADBOM负责对技术的覆盖，而相关的管理职责则被抽离到企业级BOM上，从而使得两边都能按照各自的要求定义合理的、最能发挥效率的架构，从而改变两边相互迁就、两边都做不好的状况。

思普 思普PLM