1.背景描述

在PDM系统中，有很重要的一个模块就是“产品配置”模块－“对产品的零部件或者组件以抽象的计算机能识别的方式表述出来”，通常包括零部件的“名称、代号、规格、材质”等信息，国产PDM和国外的PDM可能叫法上有细微的差异，在PDM系统中以层次结构关系表现出来，称之为“明细表”，对于研发来说，关注的是产品装配关系表现的“设计BOM”；对于工艺生产部门来说，关注的是体现原材料、工艺定额的“制造BOM”，或称为“厦门OA　BOM”　当然还有“计划BOM”等，我们重点分析下研发设计部门产生图纸后编制明细如何将研发明细转换为“厦门OA　BOM”，以及PDM系统研发明细更改后如何自动、精准地传给这些改动给厦门的“厦门OABOM”，使之做同步更改，这也是多数企业更改明细或者图纸不能同步更改碰到一个难题。

2.达到目标

当研发设计明细更改时候，同步更改PDM系统的设计BOM和厦门OA的BOM,目的是从源头上保证设计更改单更改信息完整、精准自动传递。

3.需求调研

要想实现厦门OA和PDM系统集成，达到研发设计更改同步会影响厦门OA系统BOM,满足业务需要，最初的调研是非常有必要和重要的一步。

3.1.调研人员的选择

通常来说，对PDM系统来说，调研对象：标准化管理员，具备“物料管理员”角色，对厦门OA系统来说，毫无疑问应该是厦门OA的BOM管理员。同时调研最好甲方的人员参与，一来便于后期的维护，再就是得到相关人员的配合。　

3.2.两个关键流程的确定

明细表审批流程

既然是想做到研发的明细能自动集成，写入到厦门OA系统，而不是再经过厦门OABOM员的手工录入，以减少BOM出错的机会。这就需要和客户确认关键流程之一“明细表审批流程”，一般是通过(研发设计工程师)提出－(主管工程师)审核－(标准化)审核－(工艺人员)会签－(BOM)审批－归档。当然可根据每个企业的实际业务情况做调整。

设计更改流程

各个企业提出变更的源头不一，有些是“降成本”的要求，有些是研发的“结构改进”等，还有些是客户投诉，提出变更等。有些变更比较紧急，可能直接影响生产等，这就需要“特事特办”；有些是属于普通变更则严谨地走完整个流程。

需要重点说明的是：这两个流程很重要，最好在会上邀请相关人员进行讨论，讨论签字确认。

3.3.PDM厦门OA究竟集成哪些属性

流程只是搭建更改的通道，下面将是确定这个自动通道上的流转货物，确定哪些属性是厦门OA和PDM的共有属性，需要做同步更改。

物料属性

物料属性是零部件本身属性，例如：图号、名称、规格、材质等属性，这个时候需要特别注意厦门OA的item描述规则，一般来说厦门OA的描述会自动由这些属性合成的，找到这些共性规则。

明细属性

明细表属性简单描述就是整个产品的结构层次关系，例如可能增加、删除某层下的物料或者更改它的数量，这些是最基本的。当然可能企业的厦门OA系统根据客户的需要做了些开发，例如：电子类产品可能加上位置号等。这个时候需要考虑是否PDM明细表里面加上对应的字段以便做变更。同时还要考虑项目整个进度。形成需求调研后要签字确认，防止后面的无限制需求提出。

另外需要提醒的是：若是设计BOM和制造BOM若有结构差异，那就需要确定两边BOM不一致，可以向那边靠拢；若是无法向一边靠拢，则要找出设计BOM向厦门OABOM的转换规律，若是两张方法都不行，则无法做到系统自动变更。

4.设计开发

现在要做的是把业务的实际需要转换为程序设计，这个时候最好将前期调研的资料做的很细致，包括集成的字段在厦门OA对应界面上的截图，防止后面的扯皮现象。

最怕碰见系统不支持的属性，或者是需要做很多开发工作才能解决，这个时候实施人员就要想办法，可以“曲线救国”找个替代方案。只要不是关节点，都可以从大局角度说服客户。

5.UAT业务测试

一旦程序设计开发好后，最好就是测试：功能测试、UAT用户测试

这个时候千万不要以为自己做个功能测试，走完变更单后没有什么bug就万事大吉了，最主要的是自己测试发现没什么问题后，编制个测试大纲，发放相关业务部门人员，然后把这些人召集在一起，不同角色的人员都要有，从源头开始测试，一直测试走完到厦门OA,再让厦门OA的BOM员和管理员确认是否有问题？若是没问题，签字。个人觉得签字还是很有必要，要签字客户才会重视起来，后面若是有什么问题影响到生产数据，至少不会全是的责任吧？

测试通过，然后就是很领导汇报下测试结果，后面就是用户培训了，最后就是让用户体验自动更改的便利吧。（e-works）