第五节 我国车企BOM技术路线之争

一、PDM/PLM发展历程

20世纪60年代，CAD技术在企业得到应用。作为一种比手工绘图更为先进的设计工具，CAD的应用无疑给企业带来了巨大效益，但同时也带来了新的问题——CAD产生了大量的电子数据，如何高效地存储、检索这些电子数据成为一个突出问题。同时，计算机辅助制造（Computer Aided Manufacturing，CAM）等技术也在同步发展，各单元计算机辅助技术日臻成熟之时，彼此之间却缺乏信息共享，这大大影响了CAD、CAM等计算机辅助技术优势的发挥。人们开始将注意力转向如何将这些数据进行合理、有序的组织，以充分发挥先进的设计工具的作用。PDM正是在这种背景下产生的。

正是由于CAD的需求驱动了PDM的产生，很自然地，CAD厂商开始开发PDM管理工具。最开始，PDM仅仅是作为CAD的一个模块，来存储、检索CAD产生的设计数据。附属于CAD的PDM形成一个“电子仓库”，一定程度上解决了大量数据的存储和检索问题。但产品设计、制造过程对这些电子数据的管理需求远远不止于此，与产品相关的数据集成管理要求、以产品为核心的结构化管理要求、数据发布管理等要求变得日益突出。这促使PDM从CAD中独立出来，形成一个独立的、专业的产品数据管理平台。这一时期典型的PDM产品有UG公司的iMAN、SDRC公司的Metaphase、IBM公司的ProductManager等。

以PDM的概念而言，PDM管理的是所有与产品相关的数据和过程。人们期望通过PDM平台，将产品开发过程中的数模、图文档等数据，以及产品结构、工程BOM、制造BOM、相关的工艺数据以及产品配置数据集中管理。事实上，这个时代的PDM也确实做到了这一点。特别是由于工程数据发布、制造数据发布的管理要求驱动，部分优秀的PDM对于工程BOM、制造BOM的管理，以及从工程BOM到制造BOM的构建提供了较为可行的方案，如IBM全球研发和各大工厂所使用的PDM平台ProductManager在这方面就做得非常出色。在这一平台上内嵌了一整套完善的变更管理方案，并基于严格的变更管理，工程BOM的发布控制、制造BOM的重构、重构过程中工程BOM与制造BOM的同步得到了保证。

从20世纪六七十年代到90年代，我们可以称之为传统PDM时代。传统PDM的功能从电子仓库管理逐步扩展，将电子文档从简单存储、检索管理演化到基于产品结构的结构化组织，从而扩展到BOM管理；为了更好地管控工程数据的发布以及变更，设计变更管理也成为传统PDM的一个重点。同时，各PDM厂商也在尝试进行简单的产品配置管理。总之，图文档管理、产品结构及BOM管理、设计变更管理以及简单的产品配置管理是传统PDM的主要功能。

传统PDM直到20世纪90年代末迎来了一个巨大转变期。这一转变的驱动因素主要包括以下五个。

1）随着CAD技术越来越普遍并深度应用，对CAD的深度集成要求日益迫切。主流CAD产品各有所长，都占了一定的市场份额，导致同一家企业不可避免地要处理异构CAD数据之间的信息交换问题，这就要求PDM能够充分集成异构CAD技术。而传统的PDM，对于从CAD发展起来的PDM产品，与自己的CAD集成尚可，而对于其他家的CAD则集成难度相当高；对于不是基于CAD发展起来的PDM，与CAD集成则更加困难。

2）产品开发过程中设计协同要求提高，不同专业之间如何基于同一设计环境协同工作变得十分重要，需要有相应的平台支持这一工作的展开。

3）CAD、CAE、CAM技术持续发展，应用越来越深入，要求通过PDM平台进行充分的信息共享与集成。

4）电子样机技术的发展为产品研发过程如何缩短产品开发周期、提前发现问题、降低产品开发成本带来了新的手段。

5）就纯信息技术而言，Web技术已经成熟，企业应用系统从传统的客户端/服务器（Client/Server）架构向浏览器/服务器（Browser/Server）架构转变已经成为潮流。

在这些业务和技术双重因素驱动下，传统PDM在20世纪90年代末迎来了巨大变化的关键时期。从传统PDM到PLM概念正式为业界普遍接受，这中间经历了几年的时间。在这几年里，PDM领域产生了不少新的、昙花一现的概念，如虚拟产品开发管理（Virtual Product Development Management，VPDM）、产品数据管理二代（Product Data ManagementⅡ，PDMⅡ）、协同产品商务（Collaborative Product Commence，CPC）、协同产品开发管理（collaborative Product Definition Management，cPDM）等。

IBM与著名的CAD厂商达索系统公司一直有深度的合作。1998年2月，达索公司在美国成立ENOVIA公司，再度与IBM合作，并开始以Product Manager为基础，研发新一代PDMⅡ/VPDM概念产品。VPDM强调的是对于数字化产品模型的管理，如基于上下文的设计、数字化样机（Digital Mockup，DMU）、多学科协同管理等。VPDM加上传统的以产品数据及工程发布为主体的PDM及PDMⅡ。达索公司的ENOVIAvpm产品正是在这一背景之下推出的VPDM产品。

cPDM、CPC更是从协同的角度提出的概念。CIMdata公司作为PDM行业著名的咨询服务公司，提出了cPDM的概念。cPDM是支持跨企业的协同工作环境，支持异构应用系统和异构数据的透明互操作，并具有开放式可扩展体系结构，提供多企业协作发展的完善的产品生命周期管理。cPDM的概念是针对产品开发由单一企业自主开发向广义企业或虚拟企业异地协同开发、制造和管理产品的要求而提出的。

1997年7月，对象管理组织（Object Management Group，OMG）组织公布了其PDM使能器（PDM Enabler）标准草案。作为PDM领域的第一个国际标准，本草案由许多PDM领域的主导厂商参与制订，如IBM、SDRC、PTC等。

PDM Enabler的公布标志着PDM技术在标准化方面迈出了崭新的一步。PDM Enabler基于CORBA技术，就PDM的系统功能、PDM的逻辑模型和多个PDM系统间的互操作提出了一个标准。正是在这一背景下，1999年Aberdeen提出了CPC概念。CPC所倡导的是一种依托因特网技术的新型软件与服务，它把产品设计、工程、制造、原料采购、销售、营销、现场服务以及客户紧密联系在一起，形成一个全球知识网。CPC支持商家对顾客（Business to Customer，B2C）和商家对商家（Business to Business，B2B）运作，能让离散型制造商大大改善他们的核心过程，让其产品迅速占领市场。CPC概念得到了PTC的认同，并将其作为PTC产品的核心概念进行推广。以Windchill和eMatrix为代表，CPC的主要特点是：基于分布式W/B计算框架的联邦式体系结构；基于Internet/Intranet；采用Java技术。

PDM领域在短时间内不断出现这些新的名词、新的概念，反映了在业务和技术双重驱动下PDM面临巨大变化时刻，各PDM厂商试图引领未来PDM潮流方向的野心与躁动不安。而这一纷争局面的终结者是PLM概念的提出。1999年，美国著名的咨询公司AMR research的PLM研究主任Michael Burkett认为：“许多公司重视新产品的即时上市，而没有认识到规划、供应链准备和制造的重要意义，没能在这方面为新产品的批量生产提供支持。”因此，他创造了PLM这个专业名词。

根据AMR research的定义：“PLM是一种技术辅助策略，它把跨越业务流程和不同用户群体的那些单点应用集成起来。与ERP不同，PLM将不会成为与某一软件厂商紧密集成的系统。PLM不会废止已有系统，它将使用流程建模工具、可视化工具或其他协作技术，通过一定的语义来整合已有的系统。PLM的内容大致分为四个应用部分：其一，PDM起着中心数据仓库的作用，保存产品定义的所有信息；其二，CPD让工程师和设计者使用CAD/CAM/计算机辅助工程（Computer Aided Engineering，CAE）软件以及所有与这些系统配合使用的补充性软件，以协同的方式一起研发产品；其三，产品组合管理（Product Portfolio Management，PPM），它是一套工具集，为管理产品组合提供决策支持；其四，客户需求管理（Customer Need Management，CNM），是一种获取销售数据和市场反馈意见，并且把它们集成到产品设计和研发过程中的软件。”

由以上PLM的定义可见，PLM实际上是对之前很多概念的融合。

二、我国车企PDM/PLM应用历程及应用过程中的困境

（一）我国车企PDM/PLM应用历程

PDM引入我国是在20世纪90年代。这个时候，中国正是计算机集成制造系统（Computer Integrated Manufacturing System，CIMS）概念流行之时。CIMS是通过计算机硬软件，综合运用现代管理技术、制造技术、信息技术、自动化技术、系统工程技术，将企业生产全部过程中有关的人、技术、经营管理三要素及其信息与物流有机集成并优化运行的复杂的大系统。作为国家“863计划”重点项目，且恰逢我国CAD应用开始起步，20世纪90年代，如何基于CIMS的理念实现CAD/CAPP/CAM之间的集成成为一个热点问题，许多高校和企业纷纷立项研究、试点这一课题。经过近十年的从论文到论文的研究，应该说成果寥寥。为什么这些研究不能取得成果呢？因为CAD/CAM都是别人家（SDRC、UG、达索等公司）的东西，软件具备哪些功能、有何限制其实是一个不能改变的事实；且这些CAD/CAM技术各自都有自己的技术特点，互不相同，因此在自己尚未构建一整套三维设计架构的前提下，各种研究仅仅停留在如何应用这些软件的层面上。

PDM的引入使得我国CIMS的研究难以为继，因为多数PDM产品是CAD/CAM厂商基于自身的CAD/CAM发展起来的，在这些计算机辅助技术的集成上国外厂商具有天然优势。因此，抛开PDM再去研究一个CIMS平台来集成CAD/CAM，其价值和意义都大打折扣，更何况，当时并没有可操作的方案。

我国部分车企在20世纪90年代末开始考虑采用PDM来管理研发数据。经历了十几年时间的选型、应用、升级、淘汰等过程，主流车企的PDM平台终于尘埃落定，可以概括为以下三点。

1）基于iMAN与Metaphase基础上发展起来的Teamcenter成为国际整车厂主流的PDM平台。同时，我国车企也跟随国际市场趋势，多数选择这一平台作为企业的PDM平台。

2）21世纪初，PTC公司挟第一个基于Web优势的大型PDM产品，在中国展开猛烈的销售攻势，使得其PDM产品Windchill在中国市场的占有率迅速上升。国内也有部分车企采用PTC公司的PDM产品。

3）达索公司从21世纪初开始，不断调整PDM策略，这使得达索在2002年到2008年这几年实际缺乏大型PDM/PLM平台参与到市场竞争中，因而在整车厂市场上显得相对薄弱。经过几年的收购、整合，达索最终形成了自己的PDM/PLM产品平台ENOVIA，特别是“V6”的理念帮助达索重新回到了企业级PDM/PLM这个市场中，重新赢得了一些重要客户。我国有部分车企采用达索的ENOVIA作为其PLM平台。

以上是主流PDM厂商在中国汽车市场三足鼎立的大致局面。

（二）PDM/PLM应用过程中的困境

从应用策略以及应用效果来讲，我国车企的情况可以分为两种。一种是对于PDM/PLM能做什么、不能做什么有着清晰的认识，因而对PDM/PLM在企业中的定位也非常清晰。一方面，没有对于PDM/PLM寄予不切实际的期望，因此不会强其所难，浪费很多工夫在PDM/PLM不擅长的领域；另一方面，对于PDM/PLM比较擅长的、成熟的领域则充分利用起来，在落地上做得比较到位。在这些车企，PDM/PLM系统的用途比较单纯——作为数模、图样等技术文档资料的管理工具，作为DMU管理的平台，作为不同设计专业的协同平台。这种应用方式对于企业设计数据规范的形成、设计效率的提高、工程数据的发布都有很大帮助，大大提高了研发管理水平。目前新兴的车企大多以这种情形为标杆，非常理性地对待PDM/PLM。

相对于这种应用比较良好的状况，另一种情形则不那么乐观，甚至可以说是“一把辛酸泪”。这种类型的车企因为缺乏完整的国际大车企研发体系做参照，规范的研发体系始终未能建成。具体表现在产品开发方面，则是虽然大规模应用CAD工具，但CAD的相关规范制定、遵守非常不到位；更谈不上BOM体系，基本都是下游各单位出于实际需要倒逼、拼凑一份各个业务领域所需要的数据（如采购件清单、ERP所需要的制造BOM等）。在这种情形下，由于CAD没有形成很好的规范，PDM/PLM系统只是简单地将数模、图文档进行存储、检索，因此其作用非常有限，数据可信度低、可用性差。设计人员也更愿意将数模、图样存储在自己的计算机中，以方便修改，使得数据的共享性及时效性大打折扣。同时，由于PDM/PLM市场宣传的作用、各种概念的炒作，以及车企由于缺乏完整体系做参照而对自己的需求、做法缺乏清晰的认识，这些车企往往对于PDM/PLM寄予过高的期望并对此深信不疑。这种状况的结果就是，PDM/PLM被主要用来管理BOM，而设计协同以及DMU等的应用反而极少。一方面是一期又一期的PDM/PLM实施，另一方面是年复一年地重复着BOM问题，最终BOM数据甚至走不出PDM/PLM系统，走不出研发领域，使得PDM/PLM成为一个名副其实的“食之无味、弃之可惜的鸡肋”。

由于汽车行业产品组合的多样性、复杂性，同时汽车行业高生产节拍生产对于物流要求的复杂性，都使得BOM管理特别复杂。用PDM/PLM管理BOM的车企普遍存在一些共性问题。

首先，BOM形态之间的转化与一致性难以保证。研发端的数据最终是为生产制造、销售、售后服务的，表现在BOM上，就是工程BOM要转化为能够支持生产制造的制造BOM和能够支持售后维修的售后服务BOM。从业务的要求来讲，制造BOM应该准确、及时同步工程BOM信息，并直接为ERP等生产制造系统提供主数据来源，这是对制造BOM天经地义的要求。实现方案可以是多样的，比如在PDM/PLM中统一管理工程BOM、制造BOM，然后通过系统集成将制造BOM直接输送给ERP；或者在PDM/PLM中管理工程BOM，在ERP中管理制造BOM，但二者必须是无缝集成，实现从PDM/PLM中的工程BOM到ERP的制造BOM的无缝对接。为什么必须实现上述无缝集成呢？因为只有这样，制造BOM才能够准确、及时同步工程BOM信息。如果这个集成过程加入人工环节，显然，其准确性、及时性是无法保证的。虽然业务要求如此，但现实是，我国使用PDM/PLM管理BOM的车企，几乎没有一家真正实现了从PDM/PLM向ERP的无缝对接。绝大多数的情形是：下游制造、物流等部门依据上游发布的各种文件（包括研发部门的工程BOM），手工在ERP中另起炉灶搭建一个支持生产的制造BOM，久而久之，上游的数据仅仅只是一种参考，而不是直接的依据。售后服务BOM的情形也类似，在此不赘述。

其次是变更问题。变更问题是普遍存在的，汽车行业的复杂性远远超过一般制造业，因此其变更问题尤为突出。主要表现在以下五方面。其一，变更流程与其所控制的数据是两套数据，缺乏紧密的关联，因此往往变更流程不能控制数据的状态，导致流程归流程、数据归数据“两层皮”现象，这使得数据的可信度大大降低。其二，从变更申请的提出到设计变更数据的组织、执行，到制造端的承接与执行，到生产现场的切换，往往是一个十分漫长的过程，中间涉及的部门多、业务环节多。而这一全过程缺乏总体、端到端管控，使得变更的一致性管理差。特别是在BOM形态转化上有问题时，同一个变更在研发环节的执行和制造环节就更容易造成偏差。其三，设计数据由于DMU、数模组织的需要，往往存在一些其他业务领域（采购、制造、物流等）所不需要的层级。而在PDM/PLM中，按照精确装配方案，下面的零部件发生变更，其上级零部件及上级的上级零部件都必须升级版本，这一连串的升版本导致数据变更的范围非常之大。而往往这些层级又是其他业务领域所不关注的（对其业务没有影响），这样就导致其他业务部门必须承受由于PDM/PLM中数据组织方式而带来的对他们来说没有意义的变更，但他们必须去识别、处理。其四，生产现场发生紧急变更时，往往由于情况紧急，变更常常没有纳入系统进行管理。这些游离于系统之外的变更使得BOM数据严重失真，特别是在这种类型的变更频繁发生时。而PDM/PLM系统对此类变更往往缺乏有效的管理手段。其五，变更的落地环节，即断点管理也是一个十分复杂的过程，从规划到实际切换，不仅涉及复杂的信息流，而且涉及实物流。PDM/PLM对于断点环节的信息流管理显然是力不从心的。

第三，BOM的组织形式也是一个非常突出的问题。在PDM/PLM中，工程BOM是可以按照超级BOM的模式进行组织的。我国车企在PDM/PLM系统中管理的工程BOM确实也是按照超级BOM模式进行组织的，但配置信息管理却并不规范，很多车企配置信息只是作为说明性的信息体现在BOM上。这样，通过配置信息解析单车BOM就变得不可能，或者说，至少不能保证通过同一套配置数据对不同形态的BOM进行解析。更有甚者，由于BOM形态转化问题，很多车企制造BOM是基于工程BOM另起炉灶在Excel中维护、导入到ERP中的。这种手工维护的方式使得配置化超级BOM的模式变得更加困难，因此，一般下游的制造BOM多为单车BOM。在PDM/PLM中的工程BOM以超级BOM形式存在，走出PDM/PLM之后，却通过Excel或者手工在ERP中维护的制造BOM却是单车BOM，这种组织方式的不对等必然加剧信息不一致问题；同时，变更的传递也会由于变更对象（BOM）的组织方式不同（工程BOM为超级BOM、制造BOM为单车BOM）产生不对等现象。这种不对等现象完全靠手工处理、人为识别，是一项十分繁重且容易出错的工作。

总之，我国采用PDM/PLM系统管理BOM的车企，饱受上述BOM形态转化、变更不能有效管控、配置信息不对等等问题，从而痛定思痛，积极探索PDM/PLM之外的BOM管理方案，从而形成了目前汽车行业普遍采用的独立的企业级BOM平台管理跨业务链BOM的新思路。

三、关于PDM/PLM管理BOM局限性的一点思考

20世纪90年代，BOM管理就是PDM软件的基本功能之一。那么，作为每个主流PDM软件都有的基本功能，为什么好像发挥不了作用呢？特别是2000年之后，由PDM时代进入了PLM时代，制造业，特别是汽车行业用PLM解决了BOM管理问题的情况非常少见，这岂不是咄咄怪事？

很多人认为，PDM难以管理BOM可以理解，但作为产品全生命周期的PLM管理平台为什么不能管好BOM呢？我的看法恰好相反，20世纪90年代部分PDM产品管理BOM其实要比现在PLM产品管理BOM更深入，更能够体现BOM管理的思想。其详细原因将在后续章节有所论述，简单来看，就是传统的PDM时代，数模的应用不是太复杂，DMU还没有得到大规模应用。PDM对于数模管理以及与CAD的集成相对较为简单。因此从BOM角度，可以更多地考虑下游业务部门的要求。进入21世纪之后，虚拟产品开发管理成为PLM的重心，数模、DMU的管理要求大大加强，从而导致PLM平台对于CAD工具的集成以及互操作复杂度增强。PLM系统数据建模必须迁就这一核心要求，即需要以几何关系为重心考虑一切数据关系。这种以几何信息为重心的数据模型与以跨业务领域协同的考虑点是完全不一样的，二者之间存在难以调和之处。这就导致了PLM在BOM管理上反而会比传统的PDM更加力不从心。正是在这个意义上，下面要谈的PLM的局限性并非是指PLM本身存在的问题，而是指PLM为了更好地满足其核心业务范畴而自然难以兼顾另外一个维度，即跨业务领域协同的BOM管理模式。

（一）版本管理模式的局限性

PLM中版本管理是一个非常重要的功能，无论对于数模、图样、零部件还是BOM，版本管理似乎是一个不可或缺的管理方式。正如日常工作中，建立一个三维模型、完成一个二维图样，甚至写一篇报告，将一个阶段性的成果存成一个版本也是一个极为方便、极为自然的做法。但同时也应该看到，版本管理方式是在极端动态、不断有变化有调整的环境中对数字化资料、信息流进行一种比较粗放式的管理方式。研发阶段，特别是研发的早期阶段，一切都没有定型，经常会发生变化，且工作成果、工作对象表现为产品数据，因此采用版本管理是一种非常实用的方法。但走出研发领域，情况就未必如此了。

当走出研发领域，零件版本对于采购、生产物流、配件维修等的作用是非常不明显的，因为实物的跟踪都以零件号为基础。这样就产生了一个由基于版本管理与基于零件号实物跟踪的信息错位，制造企业的很多突出的矛盾和问题由此引发。所谓实物跟踪，是指一个零件的出库入库管理、零件的结算、零件的切换等。为了解决这个问题，引出了一个令很多企业头痛的问题：什么时候零件该升版？什么时候该换号？业界给出的方案是3F（形状、功能、装配，即Form、Function、Fit）原则，即当零件的形状、功能、装配没有改变时，就不需要换号；反之，有一项受到影响，则需要另外一个零件号来表达。虽然原则如此，但操作起来却十分困难，一个典型的场景是，当零件由供应商设计时，一个设计变更是否涉及3F，这个沟通成本是十分巨大的。更何况，只凭这三个要素是否都能满足不同维度的零件号管理要求（如，从生产切换的要求、从售后切换的要求、从零件结算管理的要求），这在整车企业实在是一个值得商榷的事情。

其实，在“实物”世界里，即跨业务领域的业务中，零件管理要求也很简单，可以概括为：当影响到物流、结算时，一定要以不同的零件号加以区分。当不影响物流、结算时，其他业务部门（如需要准确知道零件技术资料信息的业务部门，采购与供应商进行沟通时）所需要知道的，是某个时刻某个零件所对应的数模及图样的版本，而不是某个版本的零件。

从BOM角度来讲，其应用方式也是这样的，即给定某个时刻，人们希望得到的是这个时刻生效的零件清单是什么。而PLM中某个产品的某个版本的BOM，如C版本的BOM，下面有零件P1处于A版本、P2处于D版本、P3处于C版本……这样的信息对于研发以外的业务领域，其价值实在有限，因为处于A版本的P1零件、处于D版本的P2零件、处于C版本的P3零件合起来表达了一个什么样状态的产品其实是没有明确意义的。

在PLM领域，有个精确装配和非精确装配的问题与版本管理机制相关。当一个产品其结构有很多层次时，最底下一个叶子节点（零件）发生变更而升版时，其父亲节点原则上也是要升版，才能够准确管理这一次变更。同样，父亲的父亲也需要升版，一直传递上去，造成每次变更整个产品自上而下所有环节都需要升版。所谓精确装配是指严格按照这种升版机制管理产品数据；而非精确装配则是指为了简化这种管理机制，牺牲掉一些管理需求，规定只是其直接父亲升版。在车企，非精确装配往往很难满足要求，因此大多需要采用精确装配的模式，这就导致大量的信息冗余。这种冗余对于研发来说或可接受，但如果都传递到其他业务领域，则是一种灾难。

出于不愿意把这种版本管理带来的“纠结”传递到研发以外的业务领域，有些车企干脆采用两套编码来处理：零件编码与物料编码。物料编码用来管理跨业务领域的零部件相关工作，而零件编码仅限于研发内部的产品资料管理。这样做的好处是，设计人员可以比较单纯地考虑零件设计，一种设计方案的改变要不要换号则留给零件号向物料号转化的过程中来考虑；但坏处也是显而易见的，两套编码必然会带来维护上难度的增加，以及人为造成的不一致因素。

（二）BOM结构的局限性

BOM本质上代表了零部件以何种方式构成产品，这里的零部件是指供货级别的零部件。为什么要强调供货级别的零部件呢？我们构建一个BOM，不论是何种形态的BOM，都是为了把零部件准备到位，无论从物料筹措、财务结算还是先期的成本控制、寻源定点，无不是基于供货级别零部件开展的。零部件供货级别没有确定而要实质性地开展这项业务是十分困难的，这显而易见。换句话说，不能确定零部件制造加工深度的BOM显得没有任何业务可操作性。可见，锁定了制造加工深度、确定了供货级别，这一层级的零部件才是BOM的核心。但在产品开发的不同阶段，不同的业务部门出于各自需要，会以不同的方式对这些供货级别的零部件进行组织，这样，BOM的层级就多了起来。特别是对于研发领域，出于设计分工的需要，或者出于方便组织数模的需要，会产生很多虚拟层级。当多层级BOM产生时，根据我们上述对于供货级别零部件的论述，不同层级的BOM处理方式应该区别对待，比如供货级别的零部件是我们进行物料筹措、物料拉动、财务结算等业务的基本单元，其下层结构当然是代表了该供货级别零部件唯一的构成方式，因此，当该供货级别零部件无论被用到哪里，其下层结构应该是唯一的。但供货级别零部件的上层结构则只是代表了如何组织这些供货级别零部件的一个“容器”，这个“容器”显然在不同的产品上有不同的内容，是一个更为高效的应用方式。PDM/PLM软件对于产品结构或BOM，以无差别的方式处理不同层级，在“容器”和“实物”管理方式上的差异化方面考虑较少，使得BOM更偏向表达产品结构，而对于BOM的核心层管理手段比较有限。同时，这种方式也必然导致不必要的数据冗余、零件号（虚拟件）数量的增加。

在BOM结构上，另一个值得注意的问题是BOM的多视图方案。PDM/PLM自20世纪90年代就一直宣扬BOM多视图，不同的PDM/PLM产品，或者同一种PDM/PLM产品在不同阶段，虽然都叫多视图，但其内涵或者管理方式是不同的。其管理方式可以分为以下两种。

方式一，基于同一套BOM数据，工程、制造、售后等各自维护自身业务领域的信息，从而构成一个包含多业务领域信息的BOM。在需要各自领域的BOM时，通过各个业务领域所设置的业务规则抽取各自的BOM。方式一的多视图模式示意图如图1-1所示（以工程BOM、制造BOM为例）。

在这种管理模式之下，新车型开发时研发形成一套承载设计信息的BOM数据，这就是传统车企通常所说的工程BOM。在这套BOM数据的基础上，工艺、制造等业务部门维护工艺路线、工位甚至库位等生产、物流相关的信息；考虑到工艺过程要求、委托外协加工要求，增加工艺合件；考虑工位拆分要求，甚至还需要将工程BOM的一行拆分成两行制造BOM；考虑到装配过程以及财务结算要求，还要加上相应的辅料等。所谓的制造BOM视图，就是通过一定的规则，从这个“大”BOM中抽取出制造所关心的信息，典型的如不需要体现设计虚拟件、需要体现合件，以及合件与下级子件之间的关系、一般情况下不需要体现供货级别零件以下的子件，等等。

这种模式理论上看起来很完美，保证了单一数据源，但实际上如果充分考虑制造、生产物流的需求，需要从可操作性、可用性方面考虑以下三方面要素。

1）同一套数据既要表达设计领域的虚拟件概念，又要表达工艺制造领域的合件概念、售后领域的维修包概念，以及自制备件的概念，那么从数据关系来讲，BOM下的零部件关系必然是一种网状关系，即一个零部件可能有多个子件，同时一个子件可能有多个父件（一个子件可能从设计维度属于某个设计虚拟件，从工艺维度属于某个合件）。制造BOM视图的“抽取”实际上是按照制造、生产物流领域的要求，从这种网状零部件关系中抽取所需要的零部件清单，这个抽取条件可能比BOM本身更复杂，从而使得这种数据组织模式和视图的形成方式失去可操作性。

2）产品上的一个零件发生设计变更时，有一个生效、最终切换的过程，这中间有大量的生产准备工作要做。因此，一个零件的设计变更从工程BOM到制造BOM实际上是需要体现这一生产准备过程所需要的时间的，而不是工程BOM上的每一个变更立刻体现在制造BOM上。这种制造BOM视图，因为所基于的是同一份数据，那么工程BOM的所有变化实际上是时时刻刻体现在制造BOM上的。而支撑生产、物流的制造BOM必须保证其稳定性和严肃性，否则将导致生产紊乱，特别是高节拍生产模式下，各种状态的零部件不加控制地混在制造BOM中，必将是一个非常棘手的问题。

3）就制造BOM而言，考虑到同一个产品在不同制造基地生产，制造BOM需要体现不同制造基地的物流、工艺的差异性。因此，如果在一套数据上来表达，将大大增加这个零部件“网络”的复杂性。复杂性越高，可操作性越低。

方式二，不同BOM视图各自拥有自身一套BOM数据，一般都是基于发布的工程BOM基础上、根据各自业务领域的需要重新构建的结果。仍然以制造BOM为例，工程BOM和制造BOM是两套数据，制造BOM在发布的工程BOM基础上根据生产准备过程的业务需要另外构建。其示意图如图1-2所示。

严格来说，这种形式形成的制造BOM已经不能称之为一个视图，而是一个独立的业务阶段所对应的一种BOM形态。这种模式构建的制造BOM可以避免上述第一种模式的许多问题，但设计变更的同步将变成一个非常突出的问题，特别是当制造BOM发生大量重构的情形之下，工程BOM上的某个零部件发生设计变更，该零部件在制造BOM上可能已经被进行了工位拆分，可能已经被重构到一个或者多个合件下面。这种变更的传递是非常困难的。

无论是针对方式一还是方式二，上述只是讨论了单车BOM的情形就已经非常复杂了，如考虑超级BOM模式，则问题还要复杂得多。同一个功能零部件，由于系列化设计的要求，需要考虑多种配置，那么就存在多个变型零部件。这在构建合件时就增加了难度，如一个合件由三个子件构成，每个子件都有几种配置，如第一个零件有两种变型设计、第二个零件有三种变型设计、第三个零件也有三种变型设计，那么合件在理论上的组合就有18种。我们可以试想一下，要在制造BOM上重构出这18种合件，搭建好底下的子件关系，同时这18种组合情况代表了18种配置情形，都需要在18个合件上表达出来……这将是一种怎样的复杂程度？

总之，对于以上两种方式，方式一所谓的视图概念基本不具备可操作性；方式二是一个可行的方案，但有些关键点必须要做得非常好才具有可操作性，比如变更的同步问题，比如合件问题等。不幸的是，PDM/PLM在上述层面都没有达到可用性要求，因此，在复杂制造业，特别是汽车行业，很少能够看到企业真正使用PDM/PLM的这些功能在管理不同领域的BOM。

四、PDM/PLM与ERP之间的信息壁垒

研发数据以及产品定义主数据如何正确、高效地传递到下游生产领域，一直以来是一个困扰企业多年的问题。这个问题具体体现在PDM/PLM如何与ERP集成上。

PDM/PLM从20世纪90年代中期进入中国市场以来，迄今有近20年的历史。在这20年中，有很多企业实施过PDM/PLM，甚至有些企业实施过第二次、第三次。但讲到与下游ERP的集成，很少有比较成功的案例。综合起来，呈现以下两种态势。

第一种态势，企业对PDM/PLM实施较好，能发挥PDM/PLM所擅长的功能，并且能取得一定效果。在这种情况下，PDM/PLM与ERP的集成往往非常困难，导致上游PDM数据走不出研发部门，从而反过来也影响了PDM/PLM效益的发挥。

第二种态势，企业弱化了PDM/PLM对研发的管理功能，而仅仅作为面向下游进行产品数据组织的工具。这种情况下，PDM/PLM与ERP的对接会稍微顺畅一些，但缺点是PDM/PLM的真正功能和优势没有发挥出来，特别是对于三维协同的优势等。

以上两种态势都不是理想状况，不是我们企业所希望看到的情形。一个良好的PDM/PLM实施应该是既能够发挥PDM/PLM在设计协同、三维建模与验证等层面的优势，同时也能够很好地解决研发数据往制造、物流等下游单位传递的问题。但这个问题，即设计与制造的信息壁垒问题，一直困扰着企业很多年而没有得到很好的解决。

很多人会有疑问：以目前的IT技术这么发达，为什么系统之间的集成还会是一个问题呢？

确实，IT技术从20世纪90年代到现在，20多年来取得了很大的发展，系统集成技术从原来的点对点集成到EAI/ESB模式集成都已经非常成熟，从技术上讲，系统集成应该是一个不存在的问题。

我们说系统集成技术非常成熟、不存在问题，这里有个前提，就是系统之间的输入、输出要有清晰的定义，并且输入、输出信息之间的关系即便不是直接的相等关系，也应该是可以通过规则的定义而由系统自动进行匹配的关系。在这种前提下，无论多么复杂的系统接口，技术上都是没有问题的。

基于这样一个前提，我们不妨来分析一下PDM/PLM的输出与ERP的输入之间的关系。

一个比较成功的PDM/PLM实施，一般在三维设计协同方面做了很多工作，但从软件包功能的现实性以及企业管理方面的独特性等来考虑，PDM/PLM很难延伸到研发部门以外。因此，从PDM/PLM系统输出的信息自然是研发、设计工作的自然结果，即主要是产品的设计信息。这些设计信息一方面包括数模、图样等下游ERP所不关心的信息，同时也包括BOM等ERP所关心的信息。但即便是BOM信息，也是完全以设计为出发点进行组织的，承载的是设计相关的信息，不能比较完整地承载采购、工艺、物流等生产准备相关的信息。而从ERP的输入要求来看，恰恰这些与供货、工艺、物流相关的信息，比如是否总成供货、供应商信息、工位的定义等是要求作为输入信息的。这中间就存在信息的差距，并且这种差距不是能够通过简单的规则可以进行映射的，而是相关业务信息的缺失。

基于以上分析，我们就比较容易看明白PDM/PLM与ERP的集成的难点所在，即PDM/PLM系统所输出的信息，往往不是ERP所要的信息，中间不能通过一些规则的定义简单进行输出 / 输入信息的匹配，而是缺少了相关业务环节的介入，导致从PDM/PLM到ERP这一信息链路的隔断。也就是说，PDM/PLM到ERP的集成，难点本身已经超出技术之外。

另外一个值得探讨的问题是，为什么目前PDM/PLM实施很难兼顾到设计协同与上下游价值链的协同？

探讨这个问题前，我们首先需要澄清一下设计协同与上下游价值链协同的具体内涵。所谓设计协同，在这里强调的是通过一个设计管理平台，将设计工具（CAD，如CATIA等）、数字化验证工具（DMU工具），以及工艺验证工具等充分集成，为设计团队提供一个基于上下文的、各种设计任务相互关联的环境。而上下游价值链的协同是指跨部门的管理工作，比如产品规划、产品工程、采购、制造、售后等相关业务环节在产品开发过程中的及时参与等。

对于设计协同，随着三维技术的不断发展与推广应用，这部分的核心越来越倾向于在三维模式下各设计专业的分工协作，也就是说，这一领域的协同所基于的基础信息是以几何信息为主体的、带有非常明显的“技术”色彩的数据。比如，我们采用CAD进行三维建模，然后基于DMU工具进行电子样机的相关验证、CAE分析，通过三维工艺验证工具进行可装配性、可制造加工性验证等。显而易见，这些信息是表达了非常深的技术要素的，也就是说，这些信息以承载深度的设计技术为核心。

对于上下游价值链的协同而言，情形会有差别。这种协同对信息的要求是，产品开发不同阶段、不同部门的人需要准确地知道产品由哪些有物流要求的零部件构成。所谓有物流要求的零部件，是指产品生产最终将是这些零部件的落实过程。产品的成本考虑、采购考虑、库存考虑等都是以这些零部件为对象。比如在规划阶段，我们需要知道这样一个构成产品的完整的零部件清单，基于这个清单来决定哪些零件要全新设计、哪些零部件可沿用、哪些零部件可以在沿用的基础上进行小的调整等；在制订产品目标成本时，也是基于这些零部件来考虑制造、采购、原材料等成本；采购流程也是基于这个清单展开的；生产现场物料拉动也是针对这些零件清单进行拉动的。可以看到，从上到下，贯穿全价值链的信息主线就是这种具有物流管理价值的零部件清单，它起到传承产品、定义主数据的作用。这种零部件清单并不需要反映非常深的技术，而是从管理的宽度着眼，通过主信息链将各个业务部门串联起来。

这样，从信息的特征角度来讲，我们可以看到两种不同类型的信息链，一种是反映技术深度的、一种是反映管理宽度的。而对同一个应用系统（或者说是PDM/PLM系统）而言，我们很难通过同一数据模型建立起既能够反映技术深度，又能够体现管理宽度的信息链。这也是为什么PDM/PLM的实施会出现上述两种态势的原因。

一个显而易见的解决问题的思路是，既然存在差异、差距，那么就需要在两者之间搭建一座桥梁。PDM/PLM与ERP之间集成的难题，其实际的可操作的解决方案正是如此，如图1-3所示。

上述思路首先要承认每个软件系统都有其专注的方向和最擅长的领域。比如PDM/PLM，其所专注和最擅长的方向是产品设计本身，要延伸到生产准备和物流领域就非常勉强；又比如ERP，其所专注和擅长的领域是与生产相关的计划、物料管理、财务等，要往前延伸到工程领域，甚至设计领域就非常困难。只有正视这样一个事实，才不会非常勉强地希望通过PDM/PLM或者ERP软件包的功能延伸来达到解决问题的目的，否则就又会走到PDM/PLM与ERP集成难的老路上去。

基于这样的思路，面对从设计到制造的现实问题，很多企业，特别是复杂的制造业，比如汽车行业的整车厂和零部件厂，曾经试图或者已经建立起一些“过渡”系统或者“中间”系统。PDM/PLM的设计数据传到“过渡”系统或“中间”系统中，然后由数据维护人员“补齐”ERP所需要的数据，然后再往ERP中发放。

总的来说，这种思路可谓对症下药，方向是没错的，但同时也存在以下问题。

1）在产品开发各个阶段，存在着大量变更，由此带来许多变更问题。这些变更往往牵涉很多部门，比如工程、制造、售后等。那么在这些“过渡”或“中间”系统中有数据管理员维护这些信息时，如何保证从PDM/PLM到下游更改是同步的？特别是当在“过渡”或“中间”系统中维护与工程BOM存在结构上的差异的制造BOM时，当变更发生时，这种从工程到制造的BOM重构的同步尤其困难。

2）“过渡”或“中间”系统为正常流程开了“后门”。很多在正常情况下应该是从PDM/PLM中发起的流程，可能为了便利或者快捷的要求，直接在“过渡”或“中间”系统中进行。这样就会造成PDM/PLM信息越来越只起到参考作用，到最后PDM/PLM就无足轻重了。

3）这样的“过渡”或“中间”系统似乎解决了从工程发放到生产准备阶段数据衔接问题，但并没有涉及产品开发早期阶段的要求，比如先期采购定点、成本分析等。

正因如此，“过渡”或“中间”系统在企业中很少有能够长期有效地解决PDM/PLM到ERP之间集成问题的情况。本质上讲，这种方案人为地搭建了一个“桥梁”，并由专人来维护这座“桥梁”，以取代业务部门的真正参与。因为缺少业务部门的真正参与，业务流程还是不能够有效地“串”起来，造成数据与业务的脱节。

基于上述分析，我们很容易想到更为完善的方案，那就是让这座“桥梁”直接与业务挂钩，通过它真正将各部门的业务整合在一起。

要让这座“桥梁”起到这样的作用，那么“桥梁”的跨度必须足够大，能够将产品规划、产品工程、财务、采购、生产准备、售后服务等各环节联系起来。因此我们可以说，这座“桥梁”不再是由某几个数据管理人员来维护的、局限于IT部门或者某一个业务部门的“桥梁”，而是一座企业级别的“桥梁”。而这座“桥梁”的实质就是代表产品定义本身的BOM。企业级BOM这个概念也因此产生。

五、车企BOM管理技术路线

目前PDM/PLM管理BOM存在诸多困境，那么，我国车企究竟要采用什么样的方案管理BOM呢？到底是该采用PDM/PLM系统来管理BOM，还是采用独立的BOM系统？这对于我国车企是一个十分纠结的问题。

下面我们从国际车企的做法、BOM管理与数模管理的关系等方面来进行分析。

（一）国际著名车企的一般做法

欧美系的车企早在20世纪70年代就开始构建自己的BOM系统，典型的，如美国通用汽车的GPDS系统、福特公司的WERS系统、沃尔沃汽车的KDP/KOLA系统等。这些构建于20世纪70年代的系统，虽然技术上非常古老，还是采用大机系统、非图标化页面进行操作，但一直支持这些大的整车厂的业务。概括而言，这些系统有以下共同特点。

1）是全球性的系统：针对该车企的所有部门、研发机构、制造基地乃至合资车企，均采用这套系统的数据。

2）完全是根据企业业务流程和管理需要量身定制的系统：这套系统沉淀的是该车企方方面面的管理思想、管理规范，以确保全球范围内业务模式的统一。正是由于与业务贴合紧密，因此，如果有的车企既生产乘用车又生产商用车，那么一般有两套系统来支持各自的业务，如沃尔沃，乘用车采用的是KDP系统，商用车采用的是KOLA系统。

3）都是独立于CAD/PDM/PLM之外的自开发的系统：这些系统既没有采用商品化的软件，也没有最终形成商品化的软件在行业内应用。

4）从管理的内容来看，都是集中在车型的定义以及零部件的用法管理。所谓零部件的用法，是指通过一系列配置特征及其逻辑关系来指明零部件是如何被用到车型上去的。换而言之，这些系统都是以超级BOM的模式来管理车型BOM，并基于超级BOM定义零部件与车型配置之间的关系。

日系车企，以丰田、日产为代表，也有自己的企业级BOM系统，如丰田的SMS、日产的G2B系统。相对于欧美系车企的以零部件为导向的整车开发，日系车企则倾向于在整车开发的策划阶段确定好车型及各种配置关系。这种差别体现在BOM管理层面，大体而言，日系车企的配置管理相对来说要比欧美系车企简单一些，可以采取矩阵表的方式，而不需要像欧美系车企那样通过复杂的配置条件来表达零部件的用法。

与欧美系车企一样，这些日系车企的BOM系统也是独立于PDM/PLM系统之外的、自开发的系统。

总体而言，这些国际著名车企，目前绝大多数都是采用自开发的、独立于PDM/PLM之外的系统来管理BOM。

（二）整车开发过程中两条平行的业务线

BOM和数模作为整车开发过程中两个非常重要的信息流，代表的是两条平行开展的业务线，即以BOM为核心的业务线和以数模为核心的业务线，如图1-4所示。

简而言之，BOM这条线代表的是围绕物料这一“现实世界”而开展的一系列的策划、采购、制造、物流、售后维修这条线；而数模这条线是围绕整车设计、零部件设计、CAE检测、电子样机，乃至三维工艺验证等活动而展开的“虚拟世界”的业务线。这两个“世界”通过供货级别零部件这一关键要素关联起来。

围绕着BOM这条线，跨部门的协同协作得以展开。这些协同协作参与的业务领域及主要活动包括以下五个方面。

1. 产品规划领域

整车开发策划阶段，对于要开发什么样的车需要进行定义，往往是市场部门与产品规划部门、设计部门协同工作共同给出结果。车型规划体现为规划配置表，在规划配置表中定义了基于市场调研、分析的结果，以及企业自身技术发展规划所确定的新车型配置需求。规划配置定义了要研发什么样的车型，它将成为进一步进行工程设计的直接依据。BOM业务也由此展开。

2. 采购领域

在产品开发的早期阶段，需要进行新车型采购规划，因此，首先要确定该新车型有哪些外购件，再根据外购件的特性，配合整车开发计划进行采购项目计划的制订。BOM为采购提供外购件清单，采购项目管理基于该清单展开，并开始下面一系列的寻源定点工作以及零部件开发及质量管理工作。

3. 成本、重量领域

早期需要策划整车的目标成本和目标重量，设计过程中需要对整车、各系统、模块进行成本和重量的估算，以及目标的平衡与调整。这些工作都依赖于高质量的BOM数据。

4. 销售、售后领域

售后备件工程师基于客户满意度与售后备件的盈利要求提出售后维修件要求，这些要求在工程设计阶段就需要加以考虑，这样才能保证在产品上市时备件能及时供应。因此，在产品设计阶段，备件工程师就需要与设计部门协同工作，基于工程BOM提出哪些件有售后维修要求、需要拆分等。对于销售，最终上市时能够销售什么样的产品，是与研发一起基于车型配置表，以及市场营销策略定义出来的一整套销售配置数据。

5. 制造、物流领域

根据企业的设备、资源、生产线等情况，以及工艺水平确定制造加工深度，这是BOM非常重要的输入。同时，在生产准备阶段，需要基于制造BOM定义工位等信息，作为物料拉动业务的基础。

而围绕数模这条业务线，主要是总布置、各设计专业（车身、底盘、电子电器等）之间的协同，各种设计及验证辅助工具之间的集成工作，更多体现为设计内部的技术管理。

（三）PDM/PLM中BOM管理与企业级BOM管理要求之间的差异

PDM/PLM中BOM管理与企业级BOM管理是两种性质迥异的业务，因此从管理特性上表现出了很大的差异。

首先，从业务要求来看，BOM支持的业务主线要求在整车开发较早阶段就要有BOM存在，只有这样才能支持产品策划阶段的成本分析、重量分析以及先期采购管理。这时详细设计工作还远未开始。而PDM/PLM中，BOM天然是设计的结果，也就是说，只有设计到一定阶段，BOM才会产生。这就导致BOM难以支持车型正向开发前期的协同工作。

其次，BOM的关注点不同。在PDM/PLM中，BOM是面向设计专业内的协同，强调DMU的技术深度。而企业级BOM是面向跨业务链的协同，强调的是管理的宽度。

第三，正是由于BOM的关注点、用途不同，BOM的组织存在方式差异。PDM/PLM的BOM更多是基于数模组织以及DMU的需要，从而形成了其特有的构成方式。这种构成方式对于数模这条业务线而言是合理的，但对于跨业务链的协同则是效率极低的。这部分内容将在第四章和第六章展开论述。

第四，管理的内容也有所侧重。在PDM/PLM中，管理的内容重点在对设计有影响的要素，因此对于设计变型件、焊点等信息都是需要管理的，但并非面向量产管理所有的零部件。而企业级BOM是面向量产、面向物料组织的所有零部件，包括没有几何要素的零部件，如软件等。

正是这些管理时点、产生方式、组织方式、管理内容的不同，体现在很多具体的管理方式上也存在非常大的差异。以零部件号为例，对于跨业务链协同的BOM这条主线而言，当影响到物流、结算时，零件变更需要给新的零件号；但对于数模主线而言，这个往往不是必需的，更方便、更习惯的是产生一个新的版本。

总体而言，作为跨业务链协同的BOM主线，其体现的是公司的管理规范和管理体系，相对来说是比较稳定的；或者说如果要变，其变化的驱动因素来自于经营方式的变化，比如由传统的大批量生产转向个性化定制与自由选配模式。而PDM/PLM所管理的数模这条主线是经常变化的，这种变化的驱动因素是设计、验证工具的不断进步、革新带来的。且一个先进的设计体系是需要跟随市场上技术进步而进步的，因此我们可以看到CAD/PLM会不断升级。而BOM的升级，因为牵涉的业务面太广，涉及的历史数据的迁移或切换过于复杂，对企业是一件需要慎重考虑的事情。这就是为什么我们看到国际著名车企如通用汽车等，CAD/PLM早已不是当初的CAD/PLM，但BOM系统还是当年的BOM系统的原因。

（四）技术路线的选择

基于上述分析，我想车企到底是在PDM/PLM系统中构建企业级BOM体系，还是采用独立的BOM系统构建企业级BOM体系，其答案应该是不言而喻的：构建一个独立的BOM系统无疑是目前最佳选择。

这一结论会遇到很多挑战，或者说是质疑。典型的质疑如：PLM是产品全生命周期管理，覆盖企业级BOM是应有之义，为什么现在的PLM产品不能覆盖企业级BOM需求呢？能不能通过PDM/PLM定制化实现？

对于第一个问题，前面已有较多论述，在此从PLM的定义出发再补充一点说明。根据本章第五节中AMR research对PLM的定义，我们特别需要注意这一点：“它将使用流程建模工具、可视化工具或其他协作技术，通过一定的语义来整合已有的系统。”从这一点来看，PLM对于全生命周期覆盖的设想在于通过“使用流程建模工具、可视化工具和其他协作技术”去“整合已有的系统”。而企业级BOM是要建立起一个端到端的结构化的、完整的、一致的信息流。这一结构化的、完整的、一致的信息流的建立要远比流程集成和系统集成难得多。而另一方面，正如在本章第四节关于PDM/PLM与ERP之间的信息壁垒所论述的，如果没有这一结构化的、完整的、一致的信息流进行支撑，要集成很多流程和系统也就会成为空中楼阁。PLM近20年的实践也证明了这一点。

对于第二个问题，能不能通过定制PDM/PLM来达到汽车企业管理全价值链BOM的需求，这里要考虑的是，对于一个商业软件包，我们是否能够改变其底层架构（包括数据架构和技术架构，特别是数据架构）？如果能（但现实情况显然是不能），这当然是可以得。那么接下来的问题是：这个成本会是多大？在此基础上开发利用了原系统的什么内容？考虑清楚这些问题，才会对可行性和必要性有正确的评判。

在思考这个问题时，我想到了20世纪90年代PDM刚导入我国，很多人会问一个问题：为什么要PDM系统？为什么不能在ERP中实现？这个问题与为什么不在PLM中建立企业级BOM管理体系一样，其纠结之处在于：我们永远也不能证明一个软件不能做什么。不论如何回答，总绕不过一个问题：虽然管理研发与管理生产、财务等由于业务特征不同而有很大差异，但ERP难道不能通过定制化或者扩展功能达到上述要求吗？

今天来问这个问题当然有些可笑，可当时却是事实。

管理是一门实践的科学，过于纠结于疑问本身是没有意义的，应付诸于实践；正如过多探讨ERP是不是应该把PDM包含进来没有意义，而20多年过去了，ERP和PDM各自的应用实践才有意义。

幸运的是，我国车企已经或正经历着这一企业级BOM的实践。