基于PLM的的一体化闭环工程变更管理研究

　　引言：工程变更是制造企业生产经营活动中贯穿产品整个生命周期的一项重要活动，航空救生产品结构复杂，组成零部件多，产品开发和制造流程复杂，当客户需求更改、供应商发生变化、设计错误、产品开发流程和开发计划调整、产品出现质量问题、产品生产制造过程中发现问题和产品版本升级或新产品的引入等，都可能提出工程更改的需求。如何有效管理航空救生产品研制过程中的变更管理，追溯变更影响范围，高效地实现变更管理，是航空机载行业企业实施PLM系统的重点和难点。本文针对航宇救生装备有限公司（以下简称“航宇公司”）产品开发过程中的工程变更管理业务、工程更改管理的实施和应用进行了深入分析，以航空机载机械产品为流程载体，基于CMII理论规范，在PLM系统上进行了工程实践，构筑了一个基于PLM工程变更管理平台，运用PLM系统对航空机械产品的工程变更进行一体化闭环管理，实现对产品的上下游（研发、工艺、制造等）更改数据的完整性、一致性的整体控制，同时实现变更流程的闭环、可追溯，为航宇公司产品实施PLM更改管理和建立可行的变更管理机制提供了一个切实可行的解决方案。

　　1.1 CMII的基本理论

　　CMII（Configuration Management II）是国际技术状态管理协会(ICM)定义的关于配置管理的规范，目前工程变更流程控制方面存在多种标准规范，国内外公司普遍采用ICM提出的CMII标准。CMII提供了一整套产品定义以及在整个产品开发生命周期内工程变更管理的规范，规定了不同权限的变更管理职能设置，并可以根据变更的影响度，选择变更的快速路径或完全路径。CMII对企业变更管理的要求主要体现在以下几个方面：面向整个产品生命周期的数据对象，不断改进的变更过程，文档数据等更加清晰、简明、有效；采用闭环交流过程，有效的衡量监督。

　　基于CMII的闭环工程变更，将工程变更的“端到端”路径打通。从工程变更的问题报告的提出，到工程变更的任务执行、反馈，实现闭环控制。产品设计数据的变更将对下游的工艺数据（PBOM、工艺路线等）、服务资料数据（产品的手册、图册等）均产生相应的影响。只有将产品的工程变更形成一体化的闭环控制，才能对产品的上下游（研发设计、工艺、制造等）数据的完整性、一致性进行控制，同时实现变更的可追溯。

　　1.2工程变更分类

　　工程更改主要活动是产品的设计和制造，涉及领域包括企业的设计、工艺、制造、质量和售后等部门，根据GJB3206A规范，根据更改流程的复杂程度采用不同的变更流程，更改类型分为I类更改、II类更改、III类更改。

　　a)I类更改：影响装备战术技术性能、互换性、通用性、安全性的更改。

　　b)II类更改：不涉及装备战术技术性能、互换性、通用性、安全性的更改和其他一般性修改、补充。II类更改又分成IIa、IIb类两部分：涉及到技术方案更改、关键元器件停产禁运和国产化替代引起的更改等为IIa类；普通设计更改，即一般性的更改、补充为IIb类。

　　c)III类更改：勘误译印、修正描图等不影响装备质量的更改和补充。

　　1.3工程变更控制的框架模型

　　变更控制的目的不是控制变更的发生，而是对变更进行管理，确保变更有序进行。为执行变更控制，必须建立有效的范围变更流程，它对管好项目至关重要。变更控制流程主要包括四个关键控制点：申请、评估、执行、实施。

　　其中工程更改申请是表示对更改前的申请，主要是对更改的类型，更改的主要原因及相关信息进行汇总，是工程更改控制的对象之一。工程更改控制的申请提交后，启动工程更改评估环节,审批人员对更改进行审批，并进行变更影响分析,衡量更改是否对整个流程有影响，以及给出后续变更建议等等。变更评估核心是变更的影响分析，将更改前的状态和更改后的状态作一个判断和对比，包含:技术状态审核,变更范围确定,影响范围评估等;变更执行则是对更改的落实，当变更评估审核通过批准之后，明确实施更改时，需要立即组织更改的策略，然后对现有项目的产品数据和工作流实施更改;变更实施则是对变更实物、外协数据等的处理。整个变更过程中要求流程封闭，过程中信息流连贯，各个环节节点都能得到变更反馈，跟踪和验证，确保变更被正确执行。具体工程变更控制框架模型如图1所示：

　　图1工程变更控制框架模型

　　航空救生产品开发和制造过程中的更改是一个不断重复的过程，更改涉及到了设计、工艺、采购、制造、工装和销售等多个部门，变更实施周期长，跨部门业务活动多。因此，工程变更管理是航宇公司PLM技术管理信息化建设实施的重点工作。以往手工变更的方式设计变更切换点确定难度大，信息共享与传递不及时，业务执行与管控的联动性差，很难有效控制数据的变更和变更追溯，信息不能及时发布，造成生产数据前后不一致，从而影响企业产品质量。具体如下：

　　1）缺少变更的分类机制，“简单变更”和“复杂变更”没有严格的界定，I类更改、II类更改、III类更改，没有严格参照“技术状态管理程序”执行，全凭设计师主观判断，由于考虑不周全，容易反复，导致工程变更的实施效率低，更改时间较长。

　　2)变更的来源缺乏管控，无法追溯。由于粗放的企业技术管理，问题的收集、提出多数通过邮件、电话等线下方式，跟踪难度大，可追溯性差，容易信息失真，且变更来源的数据无法结构化。

　　3）变更数据“不关联、不共享、不闭环”，容易造成业务疏漏，产品的工程变更未能实现闭环控制。更改过程出现信息的不共享，端到端的更改得不到有效控制，对流程的下一步骤造成更改上的困难，导致数据没有同步性且效率低，变更一致性、完整性难以保障，信息共享与传递不及时，变更任务的执行情况不能及时反馈，对产品的设计和制造造成很大的影响。

　　4）在数据更改过程中，往往过于注重更改的数据结果，对产品数据变更带来的影响缺少必要的分析，缺乏更改影响分析手段，变更的影响范围广，评估困难。特别是对“三品”的处置，易造成浪费和产品信息的不一致。

　　5）工程变更流程缺乏监控和评审环节。缺少必要的评审环节来决定是否真正需要变更，甚至由于缺乏相应机制，设计师变更不经过评审环节直接进行变更。因而有些变更是盲目的，缺乏计划和审核措施，造成更改频率高，甚至出现错误的变更。

　　3.1ECM（工程变更管理）的对象模型

　　变更管理的研究,首先就是建立一套完备的信息模型,使得通过该模型能够完整地保存变更的原因、变更任务和相关的变更数据,并建立变更后产品数据之间的内部依赖关系,使得无论发生何种变更,都能够保证产品数据的完整性、一致性和有效性、变更过程的可跟踪性和变更历史的可追溯性。从而确保工程人员在实际工作中尽量减少错误出现,提高变更的效率和产品的质量。

　　从面向对象的思想出发,在PLM系统中将整个变更管理系统的业务对象主要抽象为以下五个:PR(Problem Report)问题报告、ECR(Engineering Change Request)工程变更请求、ECN(Engineering Change Notice)工程变更通知、更改任务（ECA，Engineering Change Activity），更改任务执行（ECO，Engineering Change Order）。所有的对象类都继承PLM中的任务基类,这样在变更流程运行中,各个对象都会以任务的形式在各操作者之间传递相关的数据。具体如下：

　　1）问题报告（PR，Problem Report）。产品在试制、交付给客户等阶段，针对产品质量或性能问题，公司研发部门以外的其他人员均可通过PLM系统提交关于产品的问题报告。该流程可将产品的问题数据结构化，做到可追溯，有据可查。彻底改变以往反馈产品问题的平台不一致问题。

　　2）更改请求（ECR，Engineering Change Request）。对上游的问题报告流程与下游的更改通告流程起着承上启下的作用。该流程负责对产品的问题、改进方案、涉及的受影响机型产品进行评审。用以评估是否需要发起更改通告流程。

　　3）更改通告（ECN，Engineering Change Notice）。该流程是整个工程变更活动中最重要的环节。经过评审委员会评审通过后，主要负责管理产品改进的图纸更改，受影响的机型产品，更改通知单的管理（产品更改的具体实施时间、更改前后的变化描述、物料的处置方式等等）。包含了对更改任务（ECA）的详细定义。

　　4）更改任务（ECA，Engineering Change Activity）。更改通告中具体的任务活动。

　　5）更改任务执行（ECO，Engineering Change Order）。

　　3.2 PLM系统中ECM（工程变更管理）的基本过程

　　PLM平台通过预先规定的工作程序，完成对设计数据的更改工作，能够根据数据与数据之间的关联关系自动搜索某项更改所涉及的影响范围，及时给有关人员发送通知提醒，使其关注某项更改可能会造成的影响。工程更改将与产品零部件的版本管理与产品的技术状态管理结合起来，有助于确定产品零部件之间的借用关系，评估更改影响，提供一个完整的产品信息管理解决方案。

　　利用PLM系统中基于变更事项、变更请求、变更单以及变更活动、变更对象基础之上的变更控制流程,把变更事项作为可以选择的流程,使设计人员在PLM系统中只要提交变更请求和变更活动的流程,而变更单就会在系统自动生成。在PLM系统通过对现有变更流程业务分析和定制化开发,可以实现变更流程的简化、调整、整合来优化变更流程。PLM系统根据实际的工程变更需求，将EC（工程变更）的过程分为“请求、评估、实施”三个基本环节(如图2)，左边是一个复杂而完整的EC流程：首先获得详细的产品缺陷问题描述，这些问题可以来自企业内部(比如产品制造)，或者企业外部，比如产品销售或用户反馈，然后根据问题的大小和紧迫程度，决定是否提交正式的EC请求；重要的EC请求在实施之前需要进行评估。评估包括问题调查、原因分析、解决方案分析和变更建议四个步骤。即将问题调查单和问题描述一起发给技术人员来定位问题起因，组织专家进行讨论，统一各方面的意见，并探讨问题的解决方案。如果达成一致，且方案可行，则提出解决建议单，并向相关的部门和技术人员发出正式的变更实施单。变更实施单的提出，表明正式开始变更活动，通过一系列的更改流程，最终完成产品信息的更改。图2右边，则是简单的变更流程，一般是III类更改（勘误类更改）,省去了评估环节，具体工作内容如图2流程：

　　图2

　　PLM系统基于CMII的闭环工程变更理论，支撑对所有工程更改的闭环管理。包括对跨专业、数据借用、与工艺BOM、与在制品的处理措施等的闭环，同时包括从问题报告、变更请求、变更单到变更任务执行的闭环，以上所有变更活动，经历了非研发部门、研发设计、工艺、制造，均在同一数据平台PLM完成。变更数据下发至下游环节的制造商务部门，进行变更活动的执行、实施，即ECO的执行，ECO执行完成后，执行完成情况会反馈至PLM平台各环节部门，形成工程变更活动的闭环管理。通过实施,在PLM平台上最终实现了变更管理。

　　4.1工程变更整体业务框架

　　图3

　　从上图可以看出，工程更改总体业务过程如下：

　　●问题管理：问题报告为可选项，根据需要决定是否采用，可以采用的方式是“线下收集”。

　　●提出更改：利用更改请求提出更改，更改请求为可选项，根据需要决定是否采用。对于I类、II类更改，必须要求通过更改请求（ECR）来进行问题分析确认，并提出切实可行的工程更改建议（ECP）,然后触发多个变更指令（ECO），并进行详细的工程更改影响分析，如：生产影响，用户影响等；对于III类更改，则不需要发起ECR流程。

　　●更改评估：对于I类、II类更改，必须基于已批准的ECR发起工程更改建议，对本次更改进行全面的评估验证。

　　●数据更改：更改指令（ECO）为必选项，用于关联实际更改的数据。研发设计工程师设计完成产品图纸，发布产品的EBOM，一旦发生更改则触发ECO指令，更改设计数据；工艺工程师基于EBOM、图纸进行PBOM、工艺路线、作业标准等工艺数据的设计、发布，若由于设计更改导致工艺发生更改，则触发MCO(工艺更改指令)，工艺更改又会影响生产更改，进而触发PCO……,从而形成工程更改闭环。

　　●更改贯彻：工艺部门依据设计更改在工艺设计过程中完成必要的工艺更改；相关制造单位依据更改信息完成产品制造过程。各部门落实完成后将结果依次反馈至问题的提出方。

　　4.2工程变更实现模型

　　航宇更改管理的核心是实现一体化闭环变更，主要控制更改实施的准确、快速及完整,一体化工程变更的主要目标：从变更问题来源的数据，到变更实施、执行、反馈，实现全方位的可控。因此，实现时将使用更改请求（ECR）、更改建议（ECP,类似与ECN）及更改指令（ECO）三个变更对象来实现更改信息记录及管理模型，更改过程控制的实现中简化更改的审核步骤，突出更改的过程控制及信息完整性。具体如下：

　　●ECR：工程更改申请，用于提出问题和分析问题。

　　●ECP：工程更改建议，用于分析验证问题，并明确需要更改的数据及关联数据。

　　●ECO：工程更改指令，用于实现数据的更改和发放。

　　业务框架如图4所示：

　　图4 ECR/ECP/ECO业务框架

　　为了达到快速实现工程变更的目的，问题报告（PR）采用线下收集，公司可以规定：I类、II类更改必须发ECR和ECP，III类更改可以直接发ECO。针对I、II类更改，一个ECR只能产生一个ECP，ECP中填写的受影响数据，在ECP批准后，会触发多个ECO，即一个更改数据只能通过一个ECO完成更改和落实。针对III类更改，可通过一个ECO更改多个数据。图样及模型新发时，自动产生ECO，作为数据发放依据。ECR/ECP/ECO实现逻辑图如图5所示：

　　图5 ECR/ECP/ECO逻辑图

　　4.1工程变更实现流程

　　发生设计变更原因多种多样，既有客户需求发生变更导致的设计更改，也有设计改进导致的更改，也有外购件停产导致的更改等各种原因。工程更改主要涉及到三个方面：1）通过变更记录记载由设计变更所引发的工艺、生产执行、保障整个闭环业务过程的相关信息；2）通过变更记录记载由工艺变更所引发的生产执行、保障整个闭环业务过程的相关信息；3）通过变更记录记载由保障端变更所引发的保障闭环业务过程的相关信息。在技术状态更改控制流程中，将根据更改流程的复杂程度将采用不同的变更流程，工程变更流程主要涉及以下三个流程，ECR流程、ECP流程ECO流程具体逻辑如下：

　　a)根据Q/22SG.CX8.1-3《技术状态管理办法》中技术状态控制的规定，在技术状态更改时，由ECR、ECP和ECO组成完整的技术状态更改程序。通过工程更改请求ECR判断更改需求和确定更改类别，ECR经审签后形成工程更改建议ECP。在ECP编制前，需开展更改设计，进行更改影响分析，影响分析主要包括四个“维度”，分别为：设计维，工艺维，生产执行维，外场交付保障维，形成完成的解决方案并完成相关验证工作。ECP经审签后，技术状态的更改通过工程更改单ECO来实现。ECO直接引用ECP中的相关数据，并上传产生的对象的模型，经审签后归档。

　　b)三类更改直接发ECO,不包含”三品”处理,勘误类更改;

　　c)I,II类更改必须启动ECR/ECP/ECO,包含”三品”（三品分为出厂产品、制成品和在制品）处理,串行流程,ECR完成后触发ECP流程(1:1,1对1),ECP完成后触发ECO(1:N,1对多),反向闭环,即ECO落实归档后,ECP归档,ECP归档后,ECR归档,最终完成整个更改闭环。具体流程如：图6所示：

　　图6一体化完整变更流程图

　　工程变更管理涉及企业技术和管理等较深层次的问题，PLM更改管理为企业技术管理信息化的实施和应用提供技术手段和支撑平台。引用CMII的理论，结合产品特点、产品开发和制造业务流程制定合适的工程更改管理机制和更改流程，确保产品数据的完整性、一致性、有效性和可跟踪性,使得与产品研制有关的人员能够在并行的工作方式下及时获取最新的有效数据，减少工程更改次数，缩短更改周期，从而提高产品质量，减少产品研制成本。整个工程变更活动保证了数据的一致性、完全可追溯，实现了闭环管理。不仅提高了工程变更活动的效率，更提升了企业的核心竞争力;同时也为制造企业的更改控制提供了一种切实可行的有效方法。伴随着CMII变更管理流程的逐步完善与优化，其应用将得到进一步拓展和有效提高。

思普 思普PLM