企业级BOM架构座谈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之神