摘要 工程变更管理是企业实现管理信息化过程中必须解决的问题,工程变更管理的有效实施可以确保产品开发过程的高效率和经济性。本文讨论了企业信息化中工程变更管理的存在的主要问题:如:上下游更改数据缺少一体化管理,以及变更的流程无法闭环等,基于CMII理论基础,提出了基于WINDCHILL的PLM工程变更管理模型,并结合实例介绍了企业信息化系统中工程变更的实现模型和处理流程。最后以Windchill为基础,结合航宇救生装备有限公司的实际运转情况,构筑一个基于Windchill的PLM工程变更管理平台。 引言:工程变更是制造企业生产经营活动中贯穿产品整个生命周期的一项重要活动,航空救生产品结构复杂,组成零部件多,产品开发和制造流程复杂,当客户需求更改、供应商发生变化、设计错误、产品开发流程和开发计划调整、产品出现质量问题、产品生产制造过程中发现问题和产品版本升级或新产品的引入等,都可能提出工程更改的需求。如何有效管理航空救生产品研制过程中的变更管理,追溯变更影响范围,高效地实现变更管理,是航空机载行业企业实施PLM系统的重点和难点。本文针对航宇救生装备有限公司(以下简称“航宇公司”)产品开发过程中的工程变更管理业务、工程更改管理的实施和应用进行了深入分析,以航空机载机械产品为流程载体,基于CMII理论规范,在Windchill PLM系统上进行了工程实践,构筑了一个基于Windchill的PLM工程变更管理平台,运用PLM系统对航空机械产品的工程变更进行一体化闭环管理,实现对产品的上下游(研发、工艺、制造等)更改数据的完整性、一致性的整体控制,同时实现变更流程的闭环、可追溯,为航宇公司产品实施PLM更改管理和建立可行的变更管理机制提供了一个切实可行的解决方案。 1.工程变更的技术分析 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工程变更控制框架模型 2.航宇公司变更主要存在的问题 航空救生产品开发和制造过程中的更改是一个不断重复的过程,更改涉及到了设计、工艺、采购、制造、工装和销售等多个部门,变更实施周期长,跨部门业务活动多。因此,工程变更管理是航宇公司PLM技术管理信息化建设实施的重点工作。以往手工变更的方式设计变更切换点确定难度大,信息共享与传递不及时,业务执行与管控的联动性差,很难有效控制数据的变更和变更追溯,信息不能及时发布,造成生产数据前后不一致,从而影响企业产品质量。具体如下: 1)缺少变更的分类机制,“简单变更”和“复杂变更”没有严格的界定,I类更改、II类更改、III类更改,没有严格参照“技术状态管理程序”执行,全凭设计师主观判断,由于考虑不周全,容易反复,导致工程变更的实施效率低,更改时间较长。 2)变更的来源缺乏管控,无法追溯。由于粗放的企业技术管理,问题的收集、提出多数通过邮件、电话等线下方式,跟踪难度大,可追溯性差,容易信息失真,且变更来源的数据无法结构化。 3)变更数据“不关联、不共享、不闭环”,容易造成业务疏漏,产品的工程变更未能实现闭环控制。更改过程出现信息的不共享,端到端的更改得不到有效控制,对流程的下一步骤造成更改上的困难,导致数据没有同步性且效率低,变更一致性、完整性难以保障,信息共享与传递不及时,变更任务的执行情况不能及时反馈,对产品的设计和制造造成很大的影响。 4)在数据更改过程中,往往过于注重更改的数据结果,对产品数据变更带来的影响缺少必要的分析,缺乏更改影响分析手段,变更的影响范围广,评估困难。特别是对“三品”的处置,易造成浪费和产品信息的不一致。 5)工程变更流程缺乏监控和评审环节。缺少必要的评审环节来决定是否真正需要变更,甚至由于缺乏相应机制,设计师变更不经过评审环节直接进行变更。因而有些变更是盲目的,缺乏计划和审核措施,造成更改频率高,甚至出现错误的变更。 3.WINDCHILL系统中ECM对象模型及变更基本过程 3.1ECM(工程变更管理)的对象模型 变更管理的研究,首先就是建立一套完备的信息模型,使得通过该模型能够完整地保存变更的原因、变更任务和相关的变更数据,并建立变更后产品数据之间的内部依赖关系,使得无论发生何种变更,都能够保证产品数据的完整性、一致性和有效性、变更过程的可跟踪性和变更历史的可追溯性。从而确保工程人员在实际工作中尽量减少错误出现,提高变更的效率和产品的质量。 从面向对象的思想出发,在WINDCHILL系统中将整个变更管理系统的业务对象主要抽象为以下五个: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)。…