在信息化项目中，不同系统之间的接口是保证信息系统发挥整体效率的重要手段，也是衡量很多项目是否成功的一个标志。企业集成需求、PDM软件架构和ERP软件架构这三个因素，决定了PDM与ERP集成的内容和方式。不同软件能提供的集成方式不同，不同企业的集成需求也有不同，所以很难制定一套标准的集成内容和方式——即使采用了相同的PDM和ERP软件，不同企业的集成内容和方式也很少完全相同，这给PDM与ERP集成增加了难度。

    实际上，接口实施不仅仅是个技术问题，也是一个管理问题。

    ERP系统实施一般会对企业基础管理水平提出很高的要求，在传统开环粗放管理模式下，大量基础数据在企业是不需要维护和管理的，很多业务通过口头协调就可以完成，这样的模式根本不能适应计算机管理的要求。因此在接口中需要的很多数据就是原来业务中的真空数据，没有人维护此类数据。因此完整接口实施方案中还要落实接口中每种数据来源的业务维护负责人，以及业务维护频率要求和业务数据质量要求。

    有的企业还存在这样一种情况：出于不同的管理目的，不同的业务部门都在维护同类的数据，而且这些数据并不完全一致，这种数据也对接口数据的可靠性造成了冲击。

    一般企业在谈接口实现方案时，更多的是从接口内容和技术实现方式去考虑问题，一种常见的想法就是：如果两套系统都已经成功上线了，ERP是知道需要什么数据的，因此PDM只需要按照ERP的需要将这些数据按约定方式传递到ERP系统中就满足了接口要求。实际上很多项目接口实施很不顺利，往往是因为完成接口开发，但在实际业务中并没有真正开始使用。

    根据笔者所在公司的经验，接口除了从系统中通过查询、筛选、计算、获取数据，导出数据，对比历史数据并读入新数据几个环节是典型计算机算法技术问题之外，其他的更多功能是：通过接口实施解决企业的业务管理问题，只有在管理问题得到充分沟通和解决的情况下，接口在集成上的优势才能充分发挥。

另外，笔者发现：必须将接口数据维护制度化，接口才能长期正常运转。

二、PDM和ERP接口实施模型

    笔者分析了国内某PDM公司近五年接口项目的成败实施经验，提出了一个基于管理改进和技术实现的五层PDM和ERP接口实施模型。

图1 PDM与ERP五层接口实施模型

    根据我们的实施经验证明，一个PDM/ERP接口集成项目必须考虑到这五个方面的问题，否则将无法有效组织起真正的接口业务实现。

    大部分接口项目更多地考虑了接口内容和接口方式，但对其他三个方面考虑得不够充分，这样项目实施风险就比较大。

    1.PDM和ERP接口制度

    接口制度是保障接口长期运转的关键问题，对于需要接口的数据，在管理上一定要明确四个问题：

●不同数据由谁负责维护？解决接口数据没有来源或者多个来源的问题。

    ●在什么业务环节维护7将接口数据维护和更新作为某个业务环节的岗位职责，确保不但有人负责，而且是对业务制度负责，从而避免将接口基础数据维护的职责放在IT部门的怪现象。

    ●数据维护要达到怎样的质量要求?手工作业条件下数据的规范性是无法得到保证的，因此要在实施过程中提出很多操作细则，以近一步规定怎样的数据是不符合规范的。例如：字符的全角半角格式统一；一些手工作业条件下，通用的类似符号填写格式的统一；一些无编码的物料编码规则的设计等，都是数据维护质量要求中要考虑的问题。数据维护质量要求应该由IT部门负责，并不断根据业务变化加以扩充和完善。

    ●发生更改时如何维护？数据更改时要界定：怎样的更改只在PDM系统中变更但不影响ERP系统数据，怎样的更改只在ERP系统中变更，怎样的更改需要两者同步变更。

    这些在业务上要根据实际要求界定清晰，对于一般项目，用户理解上可能以为：只要是更改就需要重新传递接口数据，这是不对的认识，实际上，在企业中有很多更改并不影响设计文件的内容，这个时候更改造成的数据一致性也没有必要通过接口来维护，而是直接在ERP系统中进行维护即可。

    即使是双方都要同步更改的内容，接口更改维护方式也要考虑：是通过接口重新输出，还是由人工在两边系统通过业务流程来保障手工更新。

    因为很多通过接口传递的数据内容在缺少人工校验性检查的情况下，如果发生更改，将直接覆盖历史数据，因此可能是不可靠的，所以必须加上人工校验的环节，由此，很多时候通过接口产生数据的管理成本还不如手工更改成本低，或者在项目开发经费内设计一个专用的中间接口数据检查窗口成本不足，这个时候企业和供应商也应该就接口更改维护制度有清晰的约定。

2.PDM和ERP接口方式

    接口可以采用多种方式实现。常见方式有以下几种：

    ●DATA方式

    即开放PDM系统的文件或数据库格式给对方，由对方软件直接读取数据。这样的情况一般在企业有开发能力，而且只需要信息提取（不是写入）时才使用。实际中这种情况很少出现。

    ●脚本方式

    脚本语言多是一种专用高级编程语言。通过这类专用语言，用户可以对程序进行界面配置，实现简单的功能扩展，给用户提供了一定的灵活性，而且只需用户懂一点程序设计知识即可。这类语言的缺点是没有通用性，功能有限，由于解释执行，所以速度受到很大限制，并且要求应用软件开发商实现专用编程语言及调试环境有较大难度。

    ●链接库方式

    基于结构化的软件，可以提供软件内部使用的动态链接库，供用户使用。动态链接库是速度最快的接口，KMCAPP目前的二次开发接口就属于动态链接库方式。

    但是动态链接库在接口升级时会遇到麻烦，用户程序难以和正在运行的应用程序进行数据交换。用户也难以使自己的模块（用户实现的动态连接库）嵌入应用程序。

    ●COM组件方式

    基于组件对象模型的软件可以提供软件的COM对象接口。组件应用程序由多个组件打包而成，组件之间的联系是一种松散耦合，因此其中某个组件的改变将不会影响其他组件，并且可以利用应用程序进行修改，从而使改进变得方便。

    ●中间文件方式

    最常用也是最安全、成本最低的接口方式是中间文件接口。

    3.PDM和ERP接口内容

    接口方式一旦确定，就需要确定接口的内容，完整的接口内容应包括接口数据、数据格式和接口样例。

    接口数据一般包括三方面的内容：

    ●设计BOM，也就是产品装配关系：

    ●制造BOM，主要是根据产品装配关系和工艺路线先后排序关系，依据一定规则自动或半自动生成的一个制造产品结构树。

    ●工艺BOM，工艺BOM主要是要获得每个零部件在各个工序上的工序名称、工序内容、工时定额、设备工装等信息。

    接口格式首先要明确数据交换提交的方式：是文件数据还是数据库数据，然后明确交换文件的名字以及存盘路径。

    接口格式还包括文件或数据表所包含的字段名、字段次序、字段类型、字段长度、分隔符（如是文本文件）是否必填；默认值；下游系统对应含义；实际数据样例；接口对应数据来源；该字段在实际操作中填写规则……例如表1格式。

表1 实际操作中填写规则

    通过这种对照表实际上要让企业、ERP供应商、PDM供应商对项目中接口的每个字段在理解和实际业务意义上完全达成一致，这样的接口才能被相互理解和有效验证。

    最后，接口内容要包括接口样例。

    接口技术协议附件必须包括用户方提供的产品样例数据，产品样例数据必须具备典型特性，能够覆盖企业各种可能的产品结构和工艺数据情况，保证验证样例数据对接口测试的完整性。如果一个产品样例不能提供足够的产品样例数据，用户方可提供多个样例，直到可覆盖各种可能情况为止。

    用户方要保证样例数据的规范性，此时可能还需要针对接口样例提供数据规范性录入操作说明。

    依据所提供产品样例最终得到的接口中间文件将以完整实例作为验证标准依据。如果有多个样例，则需提供多个完整的接口中间文件实例。

    准备接口样例将大大加快验证时间和接口程序调整反复时间，也有利于企业和供应商快速就接口协议达成一致性理解，是最快的验证接口有效性的方式。

4.PDM和ERP接口一致性维护

    接口数据还存在一个一致性维护的问题，接口数据的一致性通过“握手方式”来保障。一致性分为静态一致性、动态一致性和双向一致性。

    ●静态一致性：如物料编码信息，原始工艺设计信息。这部分信息通过设计部门原始信息在PDM系统中记录来保证ERP和PDM系统中的一致。

    静态一致性中最大的问题可能是设计系统图号和ERP系统中物料编码的不统一，因此存在一个对应关系，这个对应关系的获得可能需要进行大量基础工作。

    ●动态一致性：如设计更改信息，在一个系统内的数据更新后，要求另一个系统内的数据也要进行相应的处理。  

“握手方式”即明确如何让对方系统得到要进行更改的信息（也可能是依靠人员来进行手工操作），从而使对方系统对接口文件进行处理。

    动态一致性在技术上包括增量提交数据或和历史数据比对后分类（新增，删除，修改，无变化）提交数据等方式。

    ●双向一致性：有些复杂的系统要求对方系统对处理的数据结果进行反馈，从而更新本身系统的数据。一般项目中不做此类一致性维护，除非是定制开发且双方互相开发数据库结构才能实现这种一致性维护。

    5.PDM和ERP接口操作

    接口操作首先要确定接口入口——从哪里开始汇总接口数据，接口数据每次包含多少对象，这些对象是如何联系在一起的。

    例如接口数据是每次都从一个完整的产品上开始汇总，或者从一个完整的工程任务上开始汇总，或者从任意零部件上都可以发起汇总，这些需要结合企业业务来约定。

    接口操作要确定接口启动条件，也就是约定当数据达到怎样的规范要求后，才可以启动接口输出，此时也可以约定接口输出负责人员。例如当产品结构发布，相关工艺数据也发布后，才能启动接口。如果有明确接口时机要求，接口程序应适当做校验性判断，防止提供不正确的数据给下游系统。

    接口操作中也应包括是否需要校验性检查，检查的内容是“程序完成”还是“通过人工完成”，这些都需要约定。

    最后应提供接口操作指南作为业务指导。

三、总结

    本文提出的接口实施模型中涉及的各个问题，如果没有得到明确约定或解决，将很难成功完成一个接口项目，笔者所在公司在此业务模型的指导下实施的接口项目，接口全部得到成功应用。而目前接口实施过程中之所以大量出现各种业务问题，就是因为对接口实施业务规律把握得不够，这种接口业务问题的解决，本质上是和一个公司人员的实施经验紧密相关的。