变更管理 (工程)

维基百科，自由的百科全书
  此条目页的主题是系统工程方面的变更管理。关于变更管理的其他用法，请见“变更管理”。

系统工程中的变更管理流程，是一种对系统变更的请求、决定可达性、计画、实施、和评估的过程，主要目的系以一系列相互关联的因子，来支援变更的处理和可追溯性[1]。

绪论[编辑]

变更管理、变更控制、和形态管理三者间常有重叠和混淆。下列定义仍未整合这些领域：

变更管理能够带来改善受影响系统、从而满足“客户需求”的好处而被接受。但也为了它潜在混淆和不必要地复杂化变更管理而饱受批评。在某些情况下，特别在资讯科技领域，更多的资金和工作任务被投入于系统维护〈和变更管理〉，而非系统的初始创建[2]。在大型ERP系统初期实施期间的典型企业投资约占整体预算的15-20%。

同样的道理，Hinley[3]描述二种雷曼软体演化法则：

  • 持续变更法则：使用的系统必须变更，否则自动变得不那么有用。
  • 增加复杂性法则：透过变更，系统结构变得越来越复杂，需要更多的资源来简化它。

变更管理在制造领域也非常重要，由于不断增加的全球性竞争、技术进步、和苛求的客户[4]，也面临著许多的变更。许多系统在使用时往往会发生变更和演变，所以这些行业的问题在很多方面都有一定程度的经验。

注记：在下面的流程中，变更委员应负责不仅仅是接受/拒绝的决策，也要优先考虑变更请求如何批次处理的影响。

流程和交付标的[编辑]

元建模技术常用于有关变更管理流程的描述，图一为描绘在本节中所解释的过程数据图。

Figure 1: Process-data model for the change management process


活动[编辑]

有六种主要活动共同组成变更管理流程，包括：识别潜在的变更〈Identify potential change〉、分析变更请求〈Analyze change request、评估变更〈Evaluate change〉、规划变更〈Plan change〉、实施变更〈Implement change〉、审查〈Review〉和变更结案〈close change〉。这些活动由四个不同的角色所执行，详列于表一。这些活动(或其下属活动)也详列于表二。

表一、变更管理流程中的角色
角色 说明
客户 客户系遇到问题、或新功能需求而请求变更的角色，可以是个人、或组织实体，可在公司内部或外部要求实施变更。
专案经理 专案经理是变更请求相关的专案的所有者。在某些情况下，会有一位专门的变更经理，在那种情况下承担这个角色。
变更委员会 变更委员会决定是否实施一个变更请求，有时，此项任务也可由专案经理履行。
变更执行者 变更执行者系为规划、实施变更的人，对于规划细节有部分由专案经理负责，可能会有争议。
表二、变革管理流程中的活动
活动 下属活动 说明
识别潜在的变更 需要新功能[5] 客户需要新功能，并阐述需求。
遇到问题[5] 客户遇到系统上的问题(例如：程式错误)，并导致一件问题报告的后果。
请求变更 客户透过建立一个变更请求，提案变更。
分析变更请求 确定技术可行性 专案经理确定变更请求提案的技术可行性，导致一个“变更技术可行性”。
确定成本和效益 专案经理确定变更请求提案的成本和效益，导致一个“变更成本和效益”。这和上述的下属活动可以任何顺序完成，彼此独立。因此，建模为无序的活动。
评估变更 基于变更请求，其“变更技术可行性”和“变更成本和效益”由变更委员会作成通过/未通过的决策。这被建模为一个单独的活动，因为它是一个重要的流程步骤，并且具有执行它的另一个角色。兰柯‧何姆斯〈Remko Helms〉建议将此建模为一个下属活动〈没有任何活动包含它〉 。
规划变更 分析变更影响 在一个“变更影响分析”确定了变更范围(亦即受变更影响的其他项目)，这个活动导致另一个通过/未通过的决策，或甚至构成“分析变更请求”活动的一部分，可能会有争议。
建立计画 为了实施变更而建立一个变更计画，一些流程说明〈例如：Mäkäräinen, 2000〉阐明可能“保留”变更，并以批式方式处理这些变更，这个活动可被视为一个好做法。
实施变更 执行变更 变更是“被计划的”，这个活动和普及变更有很强烈的关系，因为系统的其他部分〈甚至其他系统〉有时也需要适应变更。
普及变更 由“执行变更”活动而来的变更，必须普及于受其影响的系统其他部分，因为这个与上述下属活动彼此高度依赖，而被建模为并行活动。
测试变更 变更执行者测试其所执行的变更，是否满足了“变更请求”。如图所示，这可能导致一个和上述二个下属活动一起进行的叠代流程。
更新文档 “文档”更新，以反映实施的变更。
发布变更 一个新的“系统发布”公开化，以反映实施的变更。
审查和变更结案 验证变更 新的“系统发布”中的变更实施，由专案经理进行最后一次的验证。也许这必须在发布之前发生，但是由于其与文献资料来源和图表复杂性相互矛盾的考量，选择以这种方式进行建模，并包括这个议题。
变更结案 完成这个变更周期，亦即，结束“变更日志登记”。

交付标的[编辑]

除了活动，过程数据图〈如图一〉也显示了每个活动的交付标的，亦即数据。这些交付标的、或概念说明于表三，就此而论，最重要的概念为“变更请求”和“变更日志登记”。

有些概念是由作者所定义〈亦即缺乏参考文献〉，因为未能发现〈好〉定义，或者它们明显是一个活动的结果，这些概念标有星号〈*〉。概念的性质已经被排除在模型之外，因为它们大部分都是微不足道的，图表可能会很快变得太复杂。因此，一些概念〈例如：“变更请求”、“系统发布”〉借助由 Weerd 提出的版本控制方法[6]，但是由于图表复杂性的限制，这也被排除在外。

表三、变更管理流程的概念说明
概念 说明
需求 一个组件〈或项目; NASA, 2005〉的必需功能。
问题报告 说明第一级服务台雇员无法解决的问题的文件，包括：日期、报告问题者的连络资讯、问题的地点和说明、采取的行动和处置 ... 等项目，但是这在图中并无描述〈Dennis, et al., 2002〉。
变更请求 说明请求的变更、以及为何它很重要的文件，可源自“问题报告”、系统强化、其他专案、底层系统的变更、和高层管理者，这里总结为“需求”〈Dennis, et al., 2002〉。重要的属性：“通过/未通过决策”，亦即，要执行变更？或不要执行变更？
变更日志登记* 在所有变更〈例如：为了一个专案〉的集合中的不同输入，是由“变更请求”、“变更技术可行性”、“变更成本和效益”、“变更影响分析”、“变更计画”、“测试报告”、“变更验证”所组成。如果这个过程被提前终止〈亦即，如果变更没有执行〉，并非所有这些项目都必须包含在内。
变更技术可行性 这个概念表明是否“可靠的硬体和软体、技术资源能够满足提案系统的需要〈亦即，变更请求〉、并在需要的时间内可借由组织获得、或开发”〈Vogl, 2004〉。
变更成本和效益 实施所需的预期工作、和实施变更所带来的优势（如节约成本，增加收入），也被称为经济可行性〈Vogl, 2004〉。
变更影响分析 评估变更的程度〈Rajlich, 1999〉。
变更计画 “为实现某些目标、或实现某种目的（亦即，变更）而采取的计划、方法、或设计”（Georgetown University, n.d.）, 在这种情况下就是变更。
项目 “用于表示任何产品的非特定术语，包括系统、子系统、组件、下属组件、部件、套件、附属件、电脑程式、电脑软件或部件”（Rigby, 2003），具有〈重叠的〉子类型：“新增项目”和“变更项目”。
新增项目* 不言自明：一个新创建的“项目”；“项目”的子类型。
变更项目* 不言自明：一个已经存在，但已被改变的“项目”；“项目”的子类型。
测试报告 “说明对（受变更影响的〉系统或组件进行测试的实施和结果的文件”（IEEE, 1991〉。
文档 根据宾夕法尼亚州立大学图书馆（2004）的定义，文件是“附有其他材料（通常非书本）的印刷材料，并说明、给出使用说明、或以其他功能作为主要材料的指南”。在这方面，它也可以是数位材料、甚至是训练教材，只要和系统（或部分的系统〉关连。
系统发布 “出售或公开展示的商品”（Princeton University, 2003），由一个或多个“项目”、和随附的文档所组成。
变更验证 确认变更实施的结果，是否满足早先所建立的要求（Rigby, 2003）。

除了“变更”之外，还可以区分偏差和豁免[7]。偏差是在一个项目创建之前偏离其需求的授权（或其请求）。 豁免本质上是相同的，但是在项目的创建期间、或创建后。 这两种方法可视为简约的变更管理（亦即，对当前的问题没有真正的解决方案）。

范例[编辑]

在软体开发可找到运作中变更管理流程的好范例。用户通常会报告错误、或希望从其软体程式中获得新功能，从而导致变更请求。然后，软体产品公司将探究实施这一变更的技术和经济可行性，从而决定变更是否真的实现。如果确实如此，则必须透过使用功能点来规划变更。变更的实际执行，会导致电脑程式的创建或更改，并且在普及这个变更时，可能会导致其他程式码片段也发生变更。在初步测试结果看起来令人满意之后，可以将文档与软体一起更新并发布。最后，由专案经理验证变更，并在变更日志中登记结案。

Figure 2: Example change request for the car industry
Figure 2: Example change request for the car industry

在这里所处理的变更管理的另一个典型范围，就是制造业领域。以一辆汽车的设计和生产为例，如果在长距离驾驶后发现车辆安全气囊自动填充空气，这毫无疑问会导致顾客投诉（或者在测试阶段所期望的问题提报）。反过来，这些会产生一个变更请求（见右图二），这可能会证明变更是合理的。 尽管如此，还是要做一个最简单的成本和效益分析，然后才能批准变更请求。在分析对汽车设计和生产时程的影响之后，就可创建实施变更的计划。依据这个计划，这个变更实际上是可以实现的。随后在这个新版汽车被公开发布之前，有望得到彻底的测试。

在工业厂房[编辑]

由于复杂流程对于即使是小变更也非常敏感，所以对工业设施和流程的变更的适当管理，被认为是安全的关键。美国职业安全与卫生管理局（OSHA）制定了指导如何进行变更和记录的相关规定。主要的需求是由一个多学科小组对一个提案的变更进行彻底审查，以确保尽可能多的观点被用来最大限度地减少发生危害的机会。在这种情况下，变更管理被称为“变更的管理”（MOC），它只是流程安全管理许多要素之一，第 1910.119(l).1节。

参见[编辑]

参考文献[编辑]

  1. ^ Crnkovic, Asklund & Persson-Dahlqvist, 2003
  2. ^ Dennis, Wixom & Tegarden, 2002.
  3. ^ Hinley 1996.
  4. ^ Huang & Mak, 1999.
  5. ^ 5.0 5.1 ，实际上，不需要“需要新功能”和“发现问题”两者同时出现才需要变革，一般只要一种即可。然后分别建立两个“起始点”(即初始状态)，两者都需要变更。
  6. ^ Weerd 2006
  7. ^ Scott & Nisse, 2001.

延伸阅读[编辑]

取自“https://zh.wikipedia.org/w/index.php?title=变更管理_(工程)&oldid=74290246”