1什幺是变更管理？

我们先看看CMII对变更管理的定义吧“变更管理是变更已发布文档和数据的闭环过程”。这里面有两层意思

，变更的对象是文档(或数据)，而非实物。我们通常的做法是直接针对“有问题”的实物，这种做法缺少变更的分析与实施方案的确认，採取的措施可能不是针对问题根本原因的解决方案。看似是在解决问题，却不知不觉带来新的、更多的问题。

而且，不修改相关的文档，这个问题还有可能在其它产品或类似产品中出现。只有更新文档，才能彻底根除这一类问题的发生。

，这个闭环过程是一个自我修正的过程，也是一个重要的沟通过程。CMII把变更看出一种特殊的产品开发过程，变更请求就是产品开发的需求、变更的实施方案就是产品开发方案，这个方案同样需要经历提出、验证和发布这个闭环过程，这个闭环确保了结果(变更实施方案)与需求(变更请求)的一致。

变更的过程不是孤立的，受变更影响的信息能否被有效的识别、结构化、关联和所有(owned)，是变更过程能否快速和高效重要的前提。换句话说，如果产品的信息混乱、无序、不完善，就谈不上变更和变更管理，这是因为变更的基础不存在。所以要提高和改善变更管理，通常从建立产品层级结构(或基线)、建立零件与文档的命名、编号规则、建立文档所有权等配置(或构型)管理的基础业务流程着手。

2变更的种类和来源

变更有好坏之分，纠正错误的变更是坏变更，因为持续的纠错不是持续的改善。真正改进是好的变更，这类变更不是我们的结果和要求不一致，也不是因为之前工作的失误或错误，而是对现有设计和工艺的再提升和再改进，这类变更的唯一目的是真正改进，也就是我们说的好变更。另一类变更是新产品开发的初次发布。

纠错、改进和新产品开发是变更的三个主要来源。因为变更的对象是文档或统一的已发布资料库，所以无论是新信息的初次发布，还是对已发布信息的修改和发布，都可以使用统一的变更流程。

有些企业有多个变更流程存在变更流程，原因是缺乏统一配置(或构型)管理流程基础，没有统一的信息识别、关联、结构化和所有的标準，市场与研发脱节、研发与生产製造脱节，生产製造与运行维护脱节，谁都掌握一部分信息，谁都没有全部完整的信息，可想而知，在这样的环境中，纠错的变更将层出不穷。变更流程必须符合整个企业的目标，使用统一的变更流程、实现信息在整个企业的持续一致和持续改善。换句话说，我们可以使用一套统一的变更流程服务整个企业，贯穿整个产品生命周期。

3变更的生命周期

使用表单发起和控制变更。变更请求首选进入分析阶段，在变更分析阶段要做变更的技术评审和变更的成本估算，技术建议，是变更成本估算的依据。如果变更请求获得批准，则进入变更的实施阶段。变更实施阶段需要规划变更的实施计画以及变更的生效方式，工程师和设计人员按照变更规划的要求创建新文档或修改相关的文档、数据，并按照文档发布的流程确认、发布文档，在实施阶段还要按照变更实施计画套用文档，并按照规定的生效方式在设计或生产等环节导入变更。

当所有需要的工作都完成后，批准的变更请求才能结束。

4闭环变更流程

我们之前已经说到，正确的变更控制流程是一个闭环过程，而且变更的对象是已发布的文档或文档库，这个闭环过程确保整个变更过程的可控和可追溯。

第一个控制点，评审和处理变更请求(ECR)，就是批准或否决ECR。

第二个控制点，规划和实施已批准的变更请求。

第三个控制点，确认变更中将要发布的新的和/或修订的信息。

第四个控制点，套用已发布的信息。

简单的讲，第一个控制点就是变更做不做？第二个控制点就是变更怎幺做？第三个控制点就是具体的变更中文档的创建、修订和确认。就是套用新文档进行相关的工作。

在闭环变更流程中，基线随着每次新信息发布和已发布信息修订而更新。4个变更控制点，是整个变更流程的关键点。变更状态统计也是通过变更控制点，来判断一个或多个变更的状态。

5变更控制委员会

变更控制委员会(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软体的变更流程中也可以看到。

我们希望创建的闭环变更流程，能够让所有的变更，都以可靠和高效的方式进行实施。但因为的我们的资源是有限的，我们需要按变更的複杂程度、紧迫性和风险，进行分类并採取相应的措施。在企业中，大部分变更(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成员通常是企业或项目的决策层。

6三个变更专家的职能

在CMII的闭环变更流程中，有三个变更专家(Change Specialist，CSI，CSII，CSIII)，这三个变更专家分别负责闭环流程的一部分，在主流的PLM系统的变更流程中，都有对应的角色设定。

那幺我们来解释一下这三个专家的职能

变更请求从发起到被处理(批准或否决)，是变更专家I(CSI)的职能。CSI必须确保每个变更请求(ECR)包含充分的信息，以便变更评审委员会做出恰当的商业决定。这个角色需要具备一定的管理和专业技能。

所有的PR和ECR，汇总到CSI这里，CSI要对PR或ECR进行记录、分类，为每个PR和ECR，并安排给恰当的创建者，做技术评审、并给出技术建议。CSI负责汇总全流程变更的重複性成本和一次性成本。CSI还负责準备CRB的会议议程，并主持CRB会议。

CSII负责汇总合併实施相关的ECR，由一个ECN来统一执行。那幺，什幺时候可以用一个ECN来执行多个ECR呢？这还是需要基于变更的影响分析，当多个变更影响同一个最高层级文档时（这个文档我们也称之为变更的控制文档），就可以用一个ECN来实施多个ECR。CSII一个职责就是协调CIB制定变更的详细实施计画，并分配变更的生效方式。所谓生效方式，就是变更的切入点，这是变更的有一个複杂点，生效方式的种类有按日期、按批次、按序列号或按旧库存耗尽等方式，究竟该选择哪一种呢？主要是基于变更的紧迫性、成本费用和对生产平稳性等方面的考虑。这个话题这次就不展开了，想和大家说明一点的是，不管採用哪种生效方式，变更中需要创建、修改和发布的文档都是一样的。

当文档按照变更实施计画都完成创建或修订后，CSIII负责审核相关的文档，这里CSIII原则只做形式的审核，文档是不是按要求创建、修改、确认，文档的内容正确性并不是有CSIII负责，如果熟悉CMII标準，文档的完整性和正确性，是由文档的创建者和使用者共同负责的。CSIII将新创建或修改的文档发布后，还负责分发工作授权（工作授权，CMII的六个基本表单之一），相关的部门按照工作授权的内容对实物进行相关的改造、报废工作。

在CMII的闭环变更工作流程中，所有的工作都是受控的。针对文档变更是通过ECR/ECN授权修改的，针对任何实物的修改是通过WA(work authorization 工作授权)授权的，WA中要做的工作在ECN中都有清晰的规定。还有完工记录，这个完工记录要符合WA的要求，完工记录也是CMII闭环变更中结果和需求一致的证据记录。完成工作包括完成工作相关的记录和表单。

在CMII的闭环变更流程中虽然引入了三个变更专家，但在实际工作中不一定需要三个不同的人来参与，具体是三个人、还是一个人，或者5个、10个人，需要根据企业的规模和实际情况而定，但三个专家的角色、职能和工作次序不能混乱。

7制定变更的实施计画

实施计画，是变更实施过程中最重要的部分，，许多组织在发布他们变更的时候，却没有正式的实施计画。制定详细ECN的实施计画，分成6个步骤，也是一个不断叠代完善的过程，见下图。

在制定ECN的6个步骤中，第一步就是“定义所有的实施任务”，这里的任务包含两大类，一类是针对实物的，一类是针对文档的。产品的基线是制定变更实施任务的工作框架，我们来看一个例子通过变更影响分析，变更的可互换性存在于部件2345-1,2345-1下阶的多个部件需要更改，也有多个文档需要创建或修改。下图方框里的部件编号，是将被废弃的部件编号，方框外的部件编号，是新替换的部件编号。

那幺，ECN的影响列表，就要包含被废除和新替换部件和文档，还要说明被废除部件的处理意见，这就是变更的影响列表，这里面所有要做的事情就是变更实施的任务，如果加上时间和任务人，就是变更的详细实施计画。下表就是上面实物部件层级的一个转换。

变更影响列表和产品的基线格式是一致的，在最左边还是产品的层级，中间是支持文档，不过分成了新替换和被废除部件和文档，还有部件的处置意见。这些所有新文档创建或文档的修订，以及部件的处置工作，共同组成了变更实施计画中的任务。

8PR、ECR与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表单的下半部分要包含的内容

12. 创建者提交技术建议的日期

13. 估算的一次性成本

14. 估算的重複成本

15. 是否需要客户批准

16. 实施的关键时间因素

17. 提供商业决定的CRB

18. CRB成员的实际决定

19. 分配变更的优先权(如果被批准)

20. 否决的原因或需要的具体信息

21. CRB主席的签名

22. 处理日期

23. ECN编号和生效(如果是快速授权变更)

24. 页码

9变更的複杂性

需求管理和变更管理是CM(配置或构型)的两个重要的方面，如果需求没有管理好，变更管理很难做好，如果变更流程繁赘、迟缓，又很难保持需求的清晰、简洁和有效，两种相辅相成，这也是变更管理的难点。通常我们改善变更和最佳化变更流程的努力和工作是从变更流程之外的需求管理开始的，就是建立规範的需求的识别(identification)、关联(linked)、结构化(structuring)和所有(owned)的原则和流程，这些都属于CM的範畴。

CM(配置或构型管理)是产品开发和研製的基础，因为没有一套规範的CM，团队的工作成果很难共享协同，工作成果也很难沉澱积累。创新很重要，积累也同样重要，如果创新需要灵感和火花，那幺积累则更多需要的是方法和流程，这些方法和流程就是构型管理或配置管理。从CMII的角度，CM系统的基础或根基就是以下这七个方面，基线管理、产品开发流程、命名与编号规则、数据的完整性、验证和发布流程、变更和修订流程，以及已製造记录，我们构型管理或配置管理就是要把这7个方面做好，这是CM的基础，也是整个企业研发管理的基础。欢迎拍砖留言，期待您的真知灼见！