导读：研发数据以及产品定义主数据如何正确、高效地传递到下游生产领域一直以来是一个困扰企业多年的问题。这个问题具体体现在PDM/PLM如何与ERP集成上。本文结合PDM/PLM与ERP集成存在的问题介绍了一种解决方案。
01、问题的提出：设计到制造的信息壁垒
研发数据以及产品定义主数据如何正确、高效地传递到下游生产领域一直以来是一个困扰企业多年的问题。这个问题具体体现在PDM/PLM如何与ERP集成上。
PDM/PLM从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在设计协同、三维建模与验证等层面的优势，同时能够很好地解决研发数据往制造、物流等下游单位传递的问题。但这个问题，即设计与制造的信息壁垒问题，一直困扰着我们企业很多年而没有得到很好的解决。
02、问题分析：为什么这个问题会成为我们企业信息化过程中的一个“拦路虎”？
很多人会有疑问：以目前的IT技术这么发达，为什么系统之间的集成还会是一个问题呢？
确实，IT技术从上世纪九十年代到现在，二十多年来取得了很大的发展。系统集成技术从原来的点对点集成到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的实施会出现上述两种态势的原因。
03、解决问题的思路：架构一座由PDM/PLM通向ERP的“桥梁”
一个显而易见的解决问题的思路是：既然存在差异、差距，那么就需要在两者之间搭建一座桥梁。PDM/PLM与ERP之间集成的难题，其实际的可操作的解决方案正是如此。如下图所示：
上述的思路首先要承认每个软件系统都有其专注的方向和最擅长的领域。比如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这个概念也因此产生。
04、一种全新的看待BOM的视角：企业级BOM的思路
企业级BOM代表了产品开发生命周期各阶段产品定义的核心信息。这条核心信息链像人体的脊椎一样指挥手、足等的活动，让各个业务部门都这条信息链的指挥下工作。
各跨价值链的产品定义主数据都定义在企业级BOM系统，并由这些主数据触发相关业务流程。比如由早期BOM触发早期定点流程、目标成本定义流程等等。因此，企业级BOM是架构在各业务领域应用系统之上、为各领域系统提供主数据支持的系统。各业务领域系统包括研发领域的PDM/PLM系统、采购领域的电子采购系统、生产领域的ERP和MES系统、售后领域的EPC系统等。
在企业信息化架构中采用企业级BOM方式的时候，系统集成的方式发生了很大的变化，如下图所示：
在上述模式下，各业务应用系统之间的集成由原来的通过纯粹IT的手段对系统进行连接变成通过一个统一的产品定义主数据系统进行连接。各业务领域所需要的主数据统一在企业级BOM系统中维护，从而解决了PDM/PLM所输出的信息不是下游ERP、MES等系统所需要的信息的矛盾，并且便于将产品管理的阶段推到设计之前的概念、规划阶段。
上述架构避免了“过渡”或“中间”系统存在的问题，较好地解决了上下游信息的贯通和价值链的整合。
那么，企业级BOM管理的范畴是什么？
产品定义的数据主要以BOM的形态存在，包括在概念 /规划阶段的早期BOM、产品设计与工程阶段的工程BOM、成本BOM、制造BOM、售后服务BOM、海外件BOM等。这些贯穿价值链的BOM形态构成了企业级BOM管理的核心内容。
产品研发往往是面向多产品型号进行规划，考虑以多种选装配置的组合满足市场要求。因此在复杂的制造业、特别是汽车行业需要考虑产品的配置管理。产品配置管理就决定了各种形态的组织方式是一个产品一个BOM还是按照产品线的规划进行超级BOM的组织。两种组织方式在各种形态的BOM管理上有很大差别。因此产品配置管理是企业级BOM管理的重要内容。
在产品开发过程中，会不断发生变更。这些变更会影响到不同形态BOM之间的数据准确性和一致性。如果变更没有很好地管理，各种形态的BOM也就不可能有准确的状态，并最终导致各种BOM相互割裂。因此，企业级BOM需要对产品开发过程中的变更进行完整管理，从变更的发起、到工程变更的执行、到制造端的变更的跟踪、生产现场的临时授权以及现场断点跟踪整个过程。
综上所述，企业级BOM管理系统包含三大核心的、密不可分的组成部分，即：各形态的BOM管理、产品全配置管理、企业级变更管理。
05、集成的方案：上下游业务系统的集成需要传递的关键信息
下游的ERP系统的产品数据组织方式有两种，即带配置的组织方式和不带配置的组织方式。
带配置的组织方式无疑是未来的发展方向。因为在带配置的情况下，数据的冗余度减小、方便维护跨具体产品型号的生产相关的信息，并且变更发生时不需要针对不同的产品型号分别处理，便于变更的同步。
就现状而言，ERP多以不带配置进行实施为主，这主要是受企业数据管理规范以及ERP软件包的能力所限。
在两种模式中，系统集成的复杂度以第一种带配置的为高。在这种集成场景下，需要传递配置特征库以及配置规则。
以车厂为例，在传带配置数据的情况下，要传递的主要信息如下图所示：
如下有是不带配置的ERP实施，则传递的主要信息如下图所示：
06、小结
1.目前制造企业普遍存在从研发到制造的信息壁垒，具体体现在PDM/PLM与ERP的集成困难上。
2.PDM/PLM与ERP之间的集成，难点并不在IT技术层面，而是缺少必要的业务环节，使得PDM/PLM所输出的内容并非ERP所要求输入的内容。
3.很多企业在解决这一难题时，采用一些临时办法，比如构建一个“过渡”或者“中间”系统，该系统从PDM/PLM系统接收数据，然后由专门的数据维护人员补齐ERP所需要的数据。这种方案搭起了一座由PDM/PLM通往ERP的桥梁，对问题的针对性很强，但由于缺少业务的真正介入以及对产品开发前端的覆盖和变更控制，因而在数据一致性保证方面存在很大的问题。
4.通过企业级BOM系统构建一个跨越各个业务领域应用系统的业务协同平台是真正解决跨价值链产品定义主数据整合的方案。
