变更在企业的经营过程中无处不在，变更也贯穿于产品的整个生命周期。如何在实施变更的同时，保持日常工作的稳定和高效，是每个企业都面临的挑战。变更管理与需求管理紧密相连，高效实施变更，是实现需求清晰、简洁和有效前提。然而，不同企业对变更管理的理解和实践不尽相同，今天我们结合CMII标准，对变更管理涉及的概念和流程做个初步的探讨，敬请专家同仁拍砖指正。
1 什么是变更管理？
我们先看看CMII对变更管理的定义吧：“变更管理是变更已发布文档和数据的闭环过程”。这里面有两层意思：
首先，变更的对象是文档(或数据)，而非实物。我们通常的做法是直接针对“有问题”的实物，这种做法缺少变更的分析与实施方案的确认，采取的措施可能不是针对问题根本原因的解决方案。看似是在解决问题，却不知不觉带来新的、更多的问题。而且，不修改相关的文档，这个问题还有可能在其它产品或类似产品中出现。只有更新文档，才能彻底根除这一类问题的再次发生。
其次，这个闭环过程是一个自我修正的过程，也是一个重要的沟通过程。CMII把变更看出一种特殊的产品开发过程，变更请求就是产品开发的需求、变更的实施方案就是产品开发方案，这个方案同样需要经历提出、验证和发布这个闭环过程，这个闭环确保了结果(变更实施方案)与需求(变更请求)的一致。
变更的过程不是孤立的，受变更影响的信息能否被有效的识别、结构化、关联和所有(owned)，是变更过程能否快速和高效重要的前提。换句话说，如果产品的信息混乱、无序、不完善，就谈不上变更和变更管理，这是因为变更的基础不存在。所以要提高和改善变更管理，通常从建立产品层级结构(或基线)、建立零件与文档的命名、编号规则、建立文档所有权等配置(或构型)管理的基础业务流程着手。
2 变更的种类和来源
变更有好坏之分，纠正错误的变更是坏变更，因为持续的纠错不是持续的改善。改进设计(或工艺)是好的变更，这类变更不是因为我们的结果和需求不一致而产生的，也不是因为之前工作的失误或错误，而是对现有设计和工艺的再提升和再改进，这类变更的唯一目的是真正改进，也就是我们说的好变更。另一类变更是新产品开发的初次发布。
纠错、改进和新产品开发是变更的三个主要来源。因为变更的对象是文档或统一的已发布数据库，所以无论是新信息的初次发布，还是对已发布信息的修改和再次发布，都可以使用统一的变更流程。
有些企业有多个变更流程存在变更流程，原因是缺乏统一配置(或构型)的流程基础，没有统一的信息识别、关联、结构化和所有的标准，大家使用不同的配置(或构型)“语言和流程”在工作，市场与研发脱节、研发与生产制造脱节，生产制造与运行维护脱节，结果是谁都掌握一部分信息，谁都没有全部完整的信息，可想而知，在这样的环境中，纠错的变更将层出不穷。变更流程必须符合整个企业的目标，使用统一的变更流程、实现信息在整个企业的持续一致和持续改善。换句话说，我们可以、而且应该使用“一套统一”的变更流程服务整个企业，贯穿于整个产品生命周期。
3 变更的生命周期
使用表单发起和控制变更。变更请求首选进入分析阶段，在变更分析阶段要做变更的技术评审和变更的成本估算，技术建议，是变更成本估算的依据。如果变更请求获得批准，则进入变更的实施阶段。变更实施阶段需要规划变更的实施计划以及变更的生效方式，工程师和设计人员按照变更规划的要求创建新文档或修改相关的文档、数据，并按照文档发布的流程确认、发布文档，在实施最后阶段还要按照变更实施计划应用文档，并按照规定的生效方式在设计或生产等环节导入变更。
当所有需要的工作都完成后，批准的变更请求才能结束。
4 闭环变更流程
我们之前已经说到，正确的变更控制流程是一个闭环过程，而且变更的对象是已发布的文档或文档库，这个闭环过程确保整个变更过程的可控和可追溯。
闭环变更流程中有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软件的变更流程中也可以看到。那么为什么要将变更分为快速授权变更(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成员通常是企业或项目的决策层。
核心关注：拓步ERP系统平台是覆盖了众多的业务领域、行业应用，蕴涵了丰富的ERP管理思想，集成了ERP软件业务管理理念，功能涉及供应链、成本、制造、CRM、HR等众多业务领域的管理，全面涵盖了企业关注ERP管理系统的核心领域，是众多中小企业信息化建设首选的ERP管理软件信赖品牌。
转载请注明出处：拓步ERP资讯网http://www.toberp.com/
本文标题：如何做好变更管理？（上）
相关文章
