更新时间：2024-09-19 15:53
变更在企业的经营过程中无处不在，变更也贯穿于产品的整个生命周期。如何在实施变更的同时，保持日常工作的稳定和高效，是每个企业都面临的挑战。变更管理与需求管理紧密相连，高效实施变更，是实现需求清晰、简洁和有效前提。
先看看CMII对变更管理的定义：“变更管理是变更已发布文档和数据的闭环过程”。这里面有两层意思：
首先，变更的对象是文档(或数据)，而非实物。通常的做法是直接针对“有问题”的实物，这种做法缺少变更的分析与实施方案的确认，采取的措施可能不是针对问题根本原因的解决方案。看似是在解决问题，却不知不觉带来新的、更多的问题。
而且，不修改相关的文档，这个问题还有可能在其它产品或类似产品中出现。只有更新文档，才能彻底根除这一类问题的发生。
其次，这个闭环过程是一个自我修正的过程，也是一个重要的沟通过程。CMII把变更看出一种特殊的产品开发过程，变更请求就是产品开发的需求、变更的实施方案就是产品开发方案，这个方案同样需要经历提出、验证和发布这个闭环过程，这个闭环确保了结果(变更实施方案)与需求(变更请求)的一致。
变更的过程不是孤立的，受变更影响的信息能否被有效的识别、结构化、关联和所有(owned)，是变更过程能否快速和高效重要的前提。换句话说，如果产品的信息混乱、无序、不完善，就谈不上变更和变更管理，这是因为变更的基础不存在。所以要提高和改善变更管理，通常从建立产品层级结构(或基线)、建立零件与文档的命名、编号规则、建立文档所有权等配置(或构型)管理的基础业务流程着手。
变更有好坏之分，纠正错误的变更是坏变更，因为持续的纠错不是持续的改善。真正改进是好的变更，这类变更不是我们的结果和要求不一致，也不是因为之前工作的失误或错误，而是对现有设计和工艺的再提升和再改进，这类变更的目的是真正改进，也就是我们说的好变更。另一类变更是新产品开发的初次发布。
纠错、改进和新产品开发是变更的三个主要来源。因为变更的对象是文档或统一的已发布数据库，所以无论是新信息的初次发布，还是对已发布信息的修改和再次发布，都可以使用统一的变更流程。
有些企业有多个变更流程存在变更流程，原因是缺乏统一配置(或构型)管理流程基础，没有统一的信息识别、关联、结构化和所有的标准，市场与研发脱节、研发与生产制造脱节，生产制造与运行维护脱节，谁都掌握一部分信息，谁都没有全部完整的信息，可想而知，在这样的环境中，纠错的变更将层出不穷。变更流程必须符合整个企业的目标，使用统一的变更流程、实现信息在整个企业的持续一致和持续改善。换句话说，我们可以使用一套统一的变更流程服务整个企业，贯穿整个产品生命周期。
使用表单发起和控制变更。变更请求首选进入分析阶段，在变更分析阶段要做变更的技术评审和变更的成本估算，技术建议，是变更成本估算的依据。如果变更请求获得批准，则进入变更的实施阶段。变更实施阶段需要规划变更的实施计划以及变更的生效方式，工程师和设计人员按照变更规划的要求创建新文档或修改相关的文档、数据，并按照文档发布的流程确认、发布文档，在实施最后阶段还要按照变更实施计划应用文档，并按照规定的生效方式在设计或生产等环节导入变更。
当所有需要的工作都完成后，批准的变更请求才能结束。
我们之前已经说到，正确的变更控制流程是一个闭环过程，而且变更的对象是已发布的文档或文档库，这个闭环过程确保整个变更过程的可控和可追溯。
闭环变更流程中有4个关键控制点：
第一个控制点，评审和处理变更请求(ECR)，就是批准或否决ECR。
第二个控制点，规划和实施已批准的变更请求。
第三个控制点，确认变更中将要发布的新的和/或修订的信息。
第四个控制点，应用已发布的信息。
简单地讲，第一个控制点就是变更做不做，第二个控制点就是变更怎么做，第三个控制点就是具体的变更中文档的创建、修订和确认。最后就是应用新文档进行相关的工作。
这四个控制点同样适用于新产品的开发环节。
在闭环变更流程中，基线随着每次新信息发布和已发布信息修订而更新。4个变更控制点，是整个变更流程的关键点。变更状态统计也是通过变更控制点，来判断一个或多个变更的状态。
变更控制委员会(CCB)的职能与闭环变更流程紧密结合，通常每个变更都涉及CCB的三个方面职能：技术评审(费用估算)、商议决定和实施规划。依据CCB的三个职能，CCB又可分成：技术评审委员会、变更评审委员会(CRB)和变更执行委员会(CIB)。
传统的配置管理委员会CCB，经常把技术评审与商业决定或详细实施规划混淆在一起。这也是产生变更混乱的一个原因，就是职责不清。
技术评审：由受变更影响最高层阶文档的创建者来组织。我们之前提过，变更的对象是文档，换句话讲，变更影响到哪个层级的哪个文档，那么这个文档创建者，就是这个变更技术评审的负责人，要给出变更前后技术优劣的分析。能够这么做的前提是产品信息已经按照要求被识别、结构化、关联和所有。
变更评审委员会(CRB)，基于技术建议和成本做出商业决定。CRB除了做变更的审批，还需要为闭环变更制定3套标准：
第一，在多个CRB的环境中，如何为不同的ECR分配CRB。
第二，如何区分快速授权变更(fast track)和全流程变更(full track)。
第三，当费用超过多少时，在实施技术分析前，需要CRB的审批。换句话说，在ECR提交CRB审批之前，解决方案应该已经被验证，但如果验证这个解决方案需要一定的费用，而且这个费用超过一定的数额，那么在开始方案验证之前，需要得到CRB的审批。有些企业有ECR和ECO，将这个过程分解成两步，其实只要知道之间流程的关系和逻辑，具体的操作和流程设置就容易理解了。
快速授权变更和全流程变更
在这里我们要解释一下快速授权变更(Fast Track Change)和全流程变更(Full Track Change)，这两个概念和分类都是来自于CMII模型，我们在一些PLM软件的变更流程中也可以看到。
那么为什么要将变更分为快速授权变更(Fast Track Change)和全流程变更(Full Track Change)，它们在实施过程中的区别有什么呢？
我们希望创建的闭环变更流程，能够让所有的变更，都以可靠和高效的方式进行实施。但因为的我们的资源是有限的，因此我们需要按变更的复杂程度、紧迫性和风险，进行分类并采取相应的措施。在企业中，大部分变更(75%-85%)是相对简单和低风险的变更，对于低风险的变更，技术评审和CRB的职能，由个人完成，而非正式的CRB，技术负责人被授权批准他们自己的建议，说明他们的实施计划，并且执行这个计划，而非有正式的CIB去规划和实施，这类变更称之为快速授权变更(Fast Track Change)，快速授权变更快就快在变更的审批和实施都是由个人完成，而非正式的CRB和CIB。
将变更分为快速授权变更(Fast Track Change)和全流程变更(Full Track Change)的目的是将企业有限的资源用于处理那些少量但复杂和高风险的变更。判断变更是否属于快速授权变更(Fast Track Change)的标准是由CRB制定的，由变更专家I(CSI)实施执行的。具体的原则和标准各个企业有所不同，有些企业将不涉及生产和制造的变更，归为快速授权变更，有些企业将变更费用低于某个数量的，归为快速授权变更。这里要强调一句的是，不论是快速授权变更(Fast Track Change)和全流程变更(Full Track Change)，相关的文档都需要通过CSIII的审核才能发布和使用。
变更执行委员会(CIB)，规划和实施已批准的变更 。对于CIB成员来说，面临的第一个挑战就是，准确地规定实施计划中的所有需要完成的任务。其次，就是要承诺完成每项任务的时间表，并在实际实施过程中验证时间表是否有效。CIB成员要在处理当前工作的同时，确保其他各种不同的工作都能按期完成。
在企业中，技术评审人员通常是直接的设计人员或工程师，他们是文档或设计的创建者，CIB成员通常是部门经理或负责人，他们掌握资源的实际状态，制定的变更实施计划也最为可行。CRB成员通常是企业或项目的决策层。
在CMII的闭环变更流程中，有三个变更专家(Change Specialist，CSI，CSII，CSIII)，这三个变更专家分别负责闭环流程的一部分，在主流的PLM系统的变更流程中，都有对应的角色设置。
那么我们来解释一下这三个专家的职能：
变更请求从发起到被处理(批准或否决)，是变更专家I(CSI)的职能。CSI必须确保每个变更请求(ECR)包含充分的信息，以便变更评审委员会做出恰当的商业决定。这个角色需要同时具备一定的管理和专业技能。
所有的PR和ECR，首先汇总到CSI这里，CSI要对PR或ECR进行记录、分类，为每个PR和ECR，并安排给恰当的创建者，做技术评审、并给出技术建议。CSI负责汇总全流程变更的重复性成本和一次性成本。CSI还负责准备CRB的会议议程，并主持CRB会议。
变更专家II(CSII)的职能是，管理已批准变更的执行工作。
CSII负责汇总合并实施相关的ECR，由一个ECN来统一执行。那么，什么时候可以用一个ECN来执行多个ECR呢？这还是需要基于变更的影响分析，当多个变更影响同一个最高层级文档时（这个文档我们也称之为变更的控制文档），就可以用一个ECN来实施多个ECR。CSII另外一个职责就是协调CIB制定变更的详细实施计划，并分配变更的生效方式。所谓生效方式，就是变更的切入点，这是变更的有一个复杂点，生效方式的种类有按日期、按批次、按序列号或按旧库存耗尽等方式，究竟该选择哪一种呢？主要是基于变更的紧迫性、成本费用和对生产平稳性等方面的考虑。这个话题这次就不展开了，想和大家说明一点的是，不管采用哪种生效方式，变更中需要创建、修改和发布的文档都是一样的。
变更专家III(CSIII)的职能是，审查变更通知单和发布已更新的文档。
当文档按照变更实施计划都完成创建或修订后，CSIII负责审核相关的文档，这里CSIII原则只做形式的审核，文档是不是按要求创建、修改、确认，文档的内容正确性并不是有CSIII负责，如果熟悉CMII标准，文档的完整性和正确性，是由文档的创建者和使用者共同负责的。CSIII将新创建或修改的文档发布后，还负责分发工作授权（工作授权，CMII的六个基本表单之一），相关的部门按照工作授权的内容对实物进行相关的改造、报废工作。
在CMII的闭环变更工作流程中，所有的工作都是受控的。针对文档变更是通过ECR/ECN授权修改的，针对任何实物的修改是通过WA(work authorization 工作授权)授权的，WA中要做的工作在ECN中都有清晰的规定。最后还有完工记录，这个完工记录要符合WA的要求，完工记录也是CMII闭环变更中结果和需求一致的证据记录。完成工作包括完成工作相关的记录和表单。
在CMII的闭环变更流程中虽然引入了三个变更专家，但在实际工作中不一定需要三个不同的人来参与，具体是三个人、还是一个人，或者5个、10个人，需要根据企业的规模和实际情况而定，但三个专家的角色、职能和工作次序不能混乱。
实施计划，是变更实施过程中最重要的部分，然而，许多组织在发布他们变更的时候，却没有正式的实施计划。制定详细ECN的实施计划，分成6个步骤，当然也是一个不断迭代完善的过程。
在制定ECN的6个步骤中，第一步就是“定义所有的实施任务”，这里的任务包含两大类，一类是针对实物的，一类是针对文档的。产品的基线是制定变更实施任务的工作框架，我们来看一个例子：通过变更影响分析，变更的可互换性存在于部件2345-1,2345-1下阶的多个部件需要更改，也有多个文档需要创建或修改。
那么，ECN的影响列表，就要包含被废除和新替换部件和文档，还要说明被废除部件的处理意见，这就是变更的影响列表，这里面所有要做的事情就是变更实施的任务，如果加上时间和任务人，就是变更的详细实施计划。下表就是上面实物部件层级的一个转换。
变更影响列表和产品的基线格式是一致的，在最左边还是产品的层级，中间是支持文档，不过分成了新替换和被废除部件和文档，还有部件的处置意见。这些所有新文档创建或文档的修订，以及部件的处置工作，共同组成了变更实施计划中的任务。
PR、ECR和ECN是我们在变更管理中经常用的的几个表单，但在实际工作中，有经常相互混淆，有的公司所有的变更都由PR发起，有的公司只有ECR或只有ECN，将ECR和ECN合并成一个表单。产生的主要原因是对PR，ECR和ECN的定义和用途不清晰，对变更的流程也有混淆，我们先来看看对PR，ECR和ECN的定义吧:
问题报告(PR)用于定义问题，其他人员可以依据问题报告，重复相同的问题步骤，并准确地复现问题。通常写问题报告的时候，问题的根本原因或解决方案还不明确。
ECR既阐明问题，和问题的解决方案，也用于发起改进。使用ECR，定义和验证PR中问题的解决方案。PR与相应的ECR关联。所有在PR的流程中，PR的最后的状态大多不是“关闭/closed”,而是“pending”，PR的结束通常是以ECR的批准作为最终的关闭。
ECN则用于规划实施已批准的一个或多个ECR。如果ECR和ECN合并，除了将决策和实施混淆了，另一个问题就是显著降低了用一个ECN实施多个ECR的可能。
我们来看看CMII的PR、ECR的表单模板吧：
PR表单的上半部分，提出问题，说明问题。
PR表单的下半部分，主要是说明问题是怎么验证和解决的。那么PR审批，批准什么呢，主要是批准对问题的描述、定义和验证，以及针对问题的临时解决方法，最终解决方法就是修改相关设计或文档，通过ECR提出。
ECR表单的上半部分要包含的内容：
ECR表单的下半部分要包含的内容：
需求管理和变更管理是CM(配置或构型)的两个重要的方面，如果需求没有管理好，变更管理很难做好，如果变更流程繁赘、迟缓，又很难保持需求的清晰、简洁和有效，两种相辅相成，这也是变更管理的难点。通常我们改善变更和优化变更流程的努力和工作是从变更流程之外的需求管理开始的，就是建立规范的需求的识别(identification)、关联(linked)、结构化(structuring)和所有(owned)的原则和流程，这些都属于CM的范畴。
CM(配置或构型管理)是产品开发和研制的基础，因为没有一套规范的CM，团队的工作成果很难共享协同，工作成果也很难沉淀积累。创新很重要，但是积累也同样重要，如果创新需要灵感和火花，那么积累则更多需要的是方法和流程，这些方法和流程就是构型管理或配置管理。从CMII的角度，CM系统的基础或根基就是以下这七个方面，基线管理、产品开发流程、命名与编号规则、数据的完整性、验证和发布流程、变更和修订流程，以及已制造记录，我们构型管理或配置管理就是要把这7个方面做好，这是CM的基础，也是整个企业研发管理的基础。