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

 很多企业至少在研发端的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的具体问题,很多时候就会有头疼医头、脚痛医脚的感觉。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 4)生产切换的要求。

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

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

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

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

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

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

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

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

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

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

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

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