打通研发到生产的信息壁垒：关于PDM/PLM与ERP的集成

（一）问题的提出：设计到制造的信息壁垒

    研发数据以及产品定义主数据如何正确、高效地传递到下游生产领域一直以来是一个困扰企业多年的问题。这个问题具体体现在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在设计协同、三维建模与验证等层面的优势，同时能够很好地解决研发数据往制造、物流等下游单位传递的问题。但这个问题，即设计与制造的信息壁垒问题，一直困扰着我们企业很多年而没有得到很好的解决。

（二）问题分析：为什么这个问题会成为我们企业信息化过程中的一个“拦路虎”？

    很多人会有疑问：以目前的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的实施会出现上述两种态势的原因。

（三）解决问题的思路：架构一座由PDM/PLM通向ERP的“桥梁”

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

图1 PDM/PLM与ERP之间集成桥梁

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

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