|
1 前言
PDM系统是一个平台统一、数据共享、高度集成的产品数据管理系统，电子化工作流提高流程可见性及可跟踪性，保证产品电子数据得到有效控制，对产品数据的版本及变更内容的传递起到源头管控作用。但是PDM系统作为整车企业设计研发产品数据管理系统，主要用户还是研发内部用户，而变更涉及到产品业务的方方面面，涉及到下游部门的各个环节，例如库存零件的消耗储存、生产准备、采购的成本变化评估，模、夹、检具的修改，甚至影响产品公告的变更等，都需要全公司各个部门都参与进来进行评审，怎样让这些部门获得所需要的信息在各自系统中完成自己的业务流程，最终在PDM系统中形成完整的业务闭环，业务流程在PDM系统中完成后，且便于各部门追查信息、跟踪变更的进展情况，了解变更的执行情况等，都需要系统实现这些功能。 常规的变更流程审核有以下几个问题： l 变更流程除了数据变更这个主线以外，还有多个业务变更的分支线，这些分支线是业务部门各自负责完成评审及实施，同时要反馈到数据变更流程中来，需要传递的信息较多。 l 变更流程的关联性很强，当公司的某一个业务流程发生变化时都有可能对变更流程产生影响，甚至是公司的组织架构发生变化时，都要同时调整变更的流程程序。这些都导致了变更流程可能频繁的要发生一些或大或小的调整。 l 变更流程涉及到修改的数据范围较多，特别是电子审核流程常见的问题就是盲签，单纯只电子流程审核中校验数据，往往数据反而不是最准确的，甚至和实际实物是不一致的。
2.需求分析
PDM系统作为企业产品研发数据的管理工具，数据形成过程中已经形成产品结构数模，同时这些数据的变更记录也在系统中实时进行，这就形成了系统数模与零部件实物信息实时同步。目前产品研发过程中的变更分为两大部分： l 研发内部的设计变更一般流程如下：设计人员提出变更申请，组长或分专业负责人校对（涉及到设计正确性、标准符合性、规范的符合性、公差尺寸等性能要求满足度、装配、干涉等检查），相关专业分项目负责人会审（涉及到各专业参与结构、装配相关的干涉检查，有的数据不需要会审），研发的标准化专业审核（涉及到标准规范性检查），而变更关于产品质量的问题审核（涉及到设计正确性、标准符合性、规范的符合性、公差尺寸等性能要求满足度、装配、干涉等检查），项目或者部门负责人批准。 l 研发以外的变更一般流程如下：产品研发部门技术主管根据供应商、生产部门、质量管理部门、采购管理部门、销售部门等相关部门提出的对影响零部件装配、成本或产品工艺改善等的变更需求，提出设计变更申请及评审的需求。对于涉及工艺标准、检验标准类的技术文件更改还需组织评审进行验证，涉及有库存处理的，还要明确库存处理方式进行等。质量管理部对涉及到国内产品生产一致性的变更进行会签，生产制造部门对涉及到模、夹、检具的变更进行会签，采购部门对涉及到成本变化等进行会签。 以上说明变更涉及到公司的方方面面，部门多、人员多、意见多，而这些都要在PDM系统中进行且记录下来，就要求系统流程既要有一定的规范性，又要有一定的灵活性，两者之间度的把握很重要。
3.基础要求
根据公司变更流程的规范性文件，由归口管理部门提供系统按照统一的数据格式和统一的数据传输规则将数据实时传输数据交换区，下游系统则根据需要从数据交换区读取数据，实现异构系统间的数据和信息交换，要求在管理过程中达到以下目标： l 主体业务流程的规范性：当企业产品研发数据进入PDM系统时，就是处理各种各样参差不齐的数据。虽然有很多流程进行规范，但这些流程本身应该是符合实际业务的，是成熟的，不能通过系统去验证业务的成熟度，否则流程朝令夕改或者不断的修补流动，不仅用户要不断的学习这些内容，对系统的开发和维护都是一个很大的工作量。但是流程业务本身就是不断的滚动完善的，有必须要能灵活的修改，所以这就要求业务流程主体是可控的，规范的，尽量减少这些的改动。 l 可开发的规范细则：系统操作及开发规范应用是在业务规范的基础之上，只有按照企业的规范要求真实的反应到系统操作中，才能保证后续结果的真实有效性。业务管理部门会对流程过程中的操作设置很多的判断条件，例如有些变更必须有试装验证、样件的鉴定等，需要系统在关键节点设置判断提醒条件以免用户犯错。 l 线下管理的参与：变更流程在系统中实现了电子化签批，但线下的管理也要积极的参与进来，很多业务部门都希望所有的管理工作通过系统实现，而忽视了线下管理的重要参与。其实线下的管理同样很重要，其中最重要的就是对人员的培训及业务的熟悉程度，如果完全靠系统来实现管理，而实际设计人员本身对流程不熟悉，会导致很多业务性的错误产生，线下管理和电子流程的结合才能更好的促进业务的推进。
4.应用方法论
流程的灵活性带来的结果是开发工作量的增加，设计人员学习的成本增加，因为通常都先用系统来过滤一些可预见性的错误。流程的固定性带来的结果是业务的僵化，不能及时纠错，用户使用性感受较差。两者之间的平衡需要信息管理部门和业务管理部门的判断，开发维护的成本与管理的成本之间的把握。产品研发各个阶段各个部门参与的程度不通，可以划分不同的阶段应用。
4.1方案设计阶段应用
初级应用就是完全按照变更的业务流程复制到系统中来，保证流程能顺利进行。 1) 最初级的应用，应该就是设计研发部门在系统中进行内部的变更流程，只是对数据的变更，当涉及到关联变更时，相关的专业参与到变更的评审中来。 但是这种方式有只能是产品研发前期的数据变更中应用，研发内部的一个小范围评委评审，因为变更的影响范围小，同时又需要快速反应，结果要及时的实施，所以流程的节点数量可能需要的不多。 2) 方案设计阶段的设计变更频繁，更多意义上是纯数据的变更，这个阶段系统功能设置及判断条件是对数据的检查，例如检查数据的属性是否填写完整，各节点人员选择是否正确等，系统的设置及开发工作量要相对较少。
4.2 工程开发设计阶段应用
工程开发设计阶段的变更开始增加部门参与进来，例如采购部门、工艺部门等开始对产品设计变更进行评审。PDM系统中流程节点参数设置可以多样性，系统维护人员自己对整个流程也要非常清楚，哪些是重要的流程信息，这些信息对促进变更的准确性有重要的影响，而这些信息怎样体现合适。 这个阶段的流程可能涉及到的子流程开始增多，业务管理部门会要求很多系统实现线下管理的功能，例如自动提醒功能，自动选择分支流程功能等等，而往往变更的业务是很容易有特例情况产生的，如果这时系统设置规则，往往当特例产生的时候反而会怀疑流程的准确性，这些都需要系统维护人员的把握。
4.3 工程试制验证阶段应用
工程试制验证阶段开始小批量的验证，变更的管控更严格，需要提供的相关数据也更多，例如需要提供样件验证的报告，对模、夹、检的影响等，这些都需要业务负责部门填写到变更流程中，业务流程的规范性就很重要了，因为每个部门不通的需求，所有的需求如果都实现的话，系统造成很大的负担，后期的维护也造成很大的困扰。例如涉及到成本较大的变更，质量管理部门、采购管理部门、库存管理部门都要给出意见，意见的侧重点不同，流程的驳回条件也不同，如果都要系统判断，则业务规则必须很详细规范，如果不能实现，则必须有所取舍，否则尾大不掉。
4.4 批量生产阶段应用
批量验证阶段同样周期更长，往往一个试验验证可能一两个月时间，这些都需要电子流程能帮助设计人员能跟踪流程，更方便用户追踪查找历史流程，在这个阶段系统要设置可供填写分支流程的结果信息框，特别是变更流程要形成一个闭环，流程最后需要一个节点去检查这些最终的结果实施情况，保证流程的准确性。 以上所有流程都有一个共同的需求，变更流程如何快速响应。特别是后期参与的部门越来越多，每个部门还要同时完成各自的分支流程，造成整个变更流程的周期很长，这就要求既要业务的规范性，又要流程能快速实施完成。
4.5 系统功能的可配置性
随着系统功能开发的越来越多，维护的成本也相应增加，特别是某一处业务的变动，可能会导致关联大范围的变动，不论是系统的功能测试验证还是开发成本，都是一个关注的问题，所以在综合评估业务的流程同时，也需要一位系统功能很熟悉的人员，对整个系统的维护开发工作整体评估，特别是提出主体的业务要固话下来，而业务变动可能频繁的需要系统设置成可配置的，这些都需要在前期规划提出。
系统功能的可配置性，就是要求尽量设置成OOTB的效果，当业务发生变化时，快速响应需求，只需要简单的设置测试，就能直接实施应用。例如在工程涉及阶段和工程验证阶段，可能只是参与部门的多少，整体业务流程主线不变，就可以通过一个业务流程模版，只是增加一些小的判断条件，实现功能设置。
5 结论
本文主要以汽车行业整车产品研发过程中为例，详细总结了PDM数据在产品研发过程中的变更流程与系统功能开发维护的应用心得。总之，为了为企业的业务发展的需求，通过科学严谨的技术分析，把握业务与信息技术之间的平衡度，才能更好的促进系统在企业的应用。 欢迎参加第十二届中国制造业产品创新数字化国际峰会 12月1-2日 长沙
|
