跳转到内容

变更管理 (工程)

维基百科,自由的百科全书

系统工程中的变更管理流程,是一种对系统变更的请求、决定可达性、计划、实施、和评估的过程,主要目的系以一系列相互关联的因子,来支援变更的处理和可追溯性[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.

延伸阅读

[编辑]