变更管理
  变更管理泛指在项目进行过程中,对变动、更改的部分进行有效预见、应对、管理的过程。由变更管理对象的不同可以分为:
  变更管理 (工程),是系统工程方面的一种过程 ,系统工程方面的变更管理过程是指就某一系统的变更提出请求,确定可行性以及开展计划、实施和评估的过程。
  变更管理 (人员),是个人、团队、组织机构以及社会变更的一种结构化方法
  变更管理 (信息技术服务管理),是一个信息技术服务管理学科。

变更管理的目的与目标
“变更管理”这项 SMF 的目标就是提供严格有序的流程,以确保在尽量避免正常操作运转所受干扰的前提下,将所需变更调整引入 IT 环境。为实现这个总体目标,变更管理过程应提出以下要求:
• 通过提交变更请求(RFC)正式启动变更程序。
• 在确定轻重缓急和对基础架构或最终用户影响程度的基础上,为变更事项指定优先级和类别。所做指定将对变更请求受理速度及其所循授权途径产生影响。
• 建立快捷高效的申报程序,将 RFC 交由变更管理人员和变更顾问委员会 (CAB) 核准或否决。
• 制定变更部署计划,变更部署范围可能大相径庭,并需要在较为关键的过渡性里程碑处进行回顾评审。
• 与“发布管理”这项 SMF 密切配合。后者通常嵌套在变更管理过程当中,负责将变更事项发布并部署到生产环境。如需进一步了解“发布管理”这项 SMF ,请参阅 http://www.microsoft.com/technet/itsolutions/cits/mo/smf/default.mspx 。
• 在将变更付诸实现后执行一个回顾评审程序,判断变更调整活动是否达到既定目标,并决定是否保留变更成果或将其恢复原状。

变更管理的重要定义
CAB 应急委员会 (CAB/EC)。 只负责处理紧急变更事项的 CAB 专设机构。组建这个委员会的目的在于,针对具有特殊优先级的紧急变更事项做出授权或予以否决。
变更。 刻意导入 IT 环境的一切新增 IT 组件,要么对 IT 服务级别产生影响,要么对整个 IT 环境或它的某一部分产生影响。
变更顾问委员会 (CAB)。 CAB 是一个跨职能部门,负责评价针对业务需求的变更请求、优先级别、成本/效益指标以及对其他系统或过程的潜在影响。CAB 通常针对变更请求提出付诸实施、深入分析、暂缓实施或彻底否决等建议。
变更类别。 变更部署对 IT 和业务产生所影响的衡量指标。为确定变更类型,有关方面将对变更复杂程度和所需资源(包括人员、资金及时间)加以衡量。此外,部署风险(包括可能发生的服务中断)也是一个影响因素。
变更发起人。 最初提起变更请求的人员;这个人可能是业务代表或 IT 部门成员。
变更管理人员。 IT 机构中对变更管理过程负有全面管理责任的角色。
变更拥有者。 负责在 IT 环境下计划并实施变更事项的角色。变更拥有者角色由变更管理人员针对特定变更事项指派给有关人员,担当这个角色的人员将在收到已经核准的 RFC 的时刻起承担相关职责。变更拥有者必须遵循业经核准的变更时间安排。
变更优先级。 决定变更请求核准与部署速度的变更分类机制。解决方案需求的紧迫性和不予实施变更的业务风险是赖以确定优先级的主要标准。
配置项目 (CI)。 受配置管理职能控制的 IT 组件。每个 CI 都可能由其他的 CI 组成。大到整个系统(包括全部硬件、软件和文档),小到单个软件模块或次要硬件组件,不同 CI 的复杂程度、大小和类型可能存在天壤之别。
发布。 由一或多项变更组成的集合,其中包括已通过测试并被引入生产环境的新增和/或变更配置项目。
变更请求 (RFC)。 这里指正规变更请求,包括针对变更的描述、受到影响的组件、业务需求、成本估算、风险评估、资源需求及核准状态等信息。
流程摘要
  在以变更管理为中心的语境中,变更可被定义为包括硬件、软件、系统组件、服务、文件或程序在内的一切对象——有条不紊地将变更引入 IT 环境,并对 IT 服务级别协议 (SLA)、IT 环境或 IT 环境某一组成部分施加影响。变更可以是永久或暂时的。变更既可能是以新创或修订版本组件全面取代当前版本组件,又可能是安装完全不同的组件或剔除过时组件。
  不论是永久或暂时、新创或修订,符合上述定义的所有变更事项必须置于变更管理过程的掌控之下。变更管理应对 IT 环境下的所有变更实施管理。这一点非常重要,因为变更有可能:
• 对多个用户构成影响。
• 有可能导致关键任务或关键业务伺服中断。
• 涉及硬件 (如服务器或网络设备) 或软件调整。
• 影响基于 IT 系统存储的数据资料。(这主要取决于数据类型——例如,电子商务网站报价单更新操作应由变更管理程序控制,但在公司数据库中更新客户信息的操作将无法以此方式控制。)
• 涉及影响多个用户的运转和程序调整。

  我们还可对这张高阶图表做进一步编排,以提供详尽的端到端程序说明,进而描绘出全面完整的变更管理程序蓝图。这份“变更管理 SMF”指南的其余部分还提供了详细阐述这些变更管理程序的图表。
变更请求
  一般来说,身处业务环境的任何人均可提供变更请求,并因此成为变更发起人。由于可能成为变更发起人的人员基础较为广泛,而这些人员对变更申请程序的熟悉程度各不相同,因此,需要由一个程序确保变更请求的同质性和完整性,并将无关请求剔除。
  虽然变更请求可由企业中的任何人提出,但却通常由“MOF 团队模型”角色群体中的某种角色发起并提交。一般来说,每个角色群体都会提交与职责范围相关的变更请求。
  无论变更请求是为了改善或摒弃现有服务,还是为了新建服务项目,都将促使变更管理程序做出相应调整。在受控变更管理程序中,这些需求都将导致变更请求 (RFC)的形成。RFC 是记录变更提议全部相关信息的标准文档,内容涵盖从基本事项 (例如,修改数据库系统字段名) 到详细信息(例如,变更产生的广泛影响——与已修改字段名相关的交互或服务系统)。
  RFC 必须解答与变更提议相关的一系列问题,诸如“什么”、“为什么”、“谁”、“何时”、“哪里”及“如何”等。RFC 必须对变更本身、实现变更所需开展的工作、变更执行主体、变更实现手段和变更涉及的配置项目加以说明。RFC 还应披露变更目的支持信息、变更对组织机构的影响、在失败情况下的复原计划、变更成本、预算核准签名 (如有必要)以及变更提议的轻重缓急。RFC 应为变更管理人员提供充足的信息资料,帮助他们在初始审查阶段准确快捷地评估变更事项,并在正式审核阶段决定受理或驳回。
  RFC 应使用标准格式编制,以确保变更发起人为变更管理人员提供充足的信息资料,进而间接帮助 CAB 做出变更实施决策。使用标准格式还可促使变更发起人对变更请求的范围、含意、风险以及在部署失败情况下的复原计划进行分辨并记录在案。在许多情况下,变更发起人将不会得知或完全了解变更事项内含。为此,所有 MOF 团队模型角色群体均应对 RFC 加以考虑,进而判断变更事项可能对 IT 操作运转产生的影响。
  RFC 将成为变更所涉及全部活动的参考重点。Microsoft Word 模板、Microsoft OutlookR 邮件表格、Microsoft InfoPath? 表单或 Web 窗体等标准格式的运用将允许各有关方面随时随地轻松调用所需信息,因而颇具裨益。
  为协助开展变更管理程序,RFC 表单可包含有效性验证、强制及可选字段,以确保尽快录入必要信息,并避免发生在提交审核前将 RFC 退还发起人补足所需信息的情况。
提出变更请求
  需要对变更管理程序所控制的 IT 基础架构任何部分进行调整的人员 (变更发起人) 均应首先完成 RFC 。导致 RFC 产生的事件通常包括:
• 针对事件或问题的解决方案提议。
• 通过客户联系渠道 (通常是服务台) 或服务级别管理评价指标获悉用户或客户要求改进服务质量的不满情绪。
• 关于引进或剔除配置项目 (CI) 的提议。
• 针对部分基础架构组件的升级提议。
• 影响 IT 需求的业务决策。
• 促使服务变更的新增或修订法规。
• 物理位置变更。
• 厂商或承包商所提供的产品或服务发生变更。

  虽然变更发起人可能是企业中具有变更请求提交权限的人员,但是,他们往往并不熟悉 IT 环境本身的操作运转。在这种情况下,应指派那些来自 IT 环境的变更拥有者负责提供与 RFC 变更技术特性相关的必要信息。
RFC 信息
变更发起人应在 RFC 编制过程中尽可能提供下列信息:
• 变更发起人的姓名、职位及联络信息。
• 变更拥有者的姓名、职位及联络信息。
• 变更描述信息,也就是对变更本质特征的完整说明。
• 根据可用信息提出的变更优先级与分类建议。
• 针对与变更请求事项相关的任何问题或事件出具的问题报告(PR) 数量(如果知道的话)。
• 与所需变更一切项目相关的说明和标识,包括 CI 识别信息。
• 变更理由。
• 变更事项成本收益分析和预算审批记录 (如果需要)。
• 不执行变更的潜在影响,包括可能导致 SLA 面临的任何风险。
• 影响与资源评估,也就是将受变更影响的用户以及这些用户所受影响程度。
• 变更发布位置和具有时间要求的建议实施计划。
• 包含触发条件和决策人详细联络信息的复原计划。
• 对业务连续性和应急规划的影响。
• 变更所蕴含的风险。

  变更管理人员与变更审核程序其他参与人员还可能要求变更发起人提供业务案例、成本效益分析或实施计划提议等支持文档。
  下文将对要求变更发起人提交上述清单中的两个 RFC 项目——变更优先级和分类提议——做进一步解释。
变更优先级
  人们往往对“优先级”这个定义存在某种模糊认识;字典对这个名词的定义是:“优先顺序,主要根据重要性或紧急程度确定。”
  在变更管理程序中,紧急程度取决于业务单位要求的变更实施速度。
针对优先级的设定提议共分四档:
• 紧急。 如不立即实施变更,将导致企业面临重大风险——例如,应用安全修补程序。
• 高。 对企业具有较高重要性的变更,必须尽快执行——例如,为适应最新法规要求而实施的升级。
• 中。 应当执行的变更,旨在通过调整支持服务谋求收益——例如,针对客户反馈服务应用不同升级版本。
• 低。 虽不紧迫但有价值的变更——例如,针对用户配置文件附加“建议选配”信息。

   这些优先级根据业界最佳实践经验定义。当然,企业可视自身规模大小、组织结构和 IT 部门与其所服务业务单位缔结的基础性 SLA 对优先级定义进行修订。例如,在某些企业中,如果就职于重要部门的人员希望在其所服务的用户配置文件中追加“建议选配”信息,那么,他所提出的变更请求将被赋予较高优先级。相反,如果同一变更请求来自即将被裁撤的业务部门,则很可能被赋予较低优先级。每家企业均应结合自身所处环境认真考虑这些优先级的正确使用方式,因为执行变更的时间和方式主要取决于变更请求被赋予的优先级。同时,优先级还决定着变更请求接受评审的先后次序。
  当然,还有一点需要特别注意:具有紧急优先级的变更请求之所以明显区别于具有其它优先顺序的变更请求,主要是由于前者为确保变更得到尽快实施而采取了不同的审批程序。这种优先级仅限应用于以下变更事项:如不尽快实施就会对服务水平构成严重影响或导致企业付出更大代价。由于实施紧急变更会导致风险增大,因此,应尽量避免提出紧急变更请求;对紧急变更请求的使用无法替代细致周密的计划工作。

变更类别
  变更的 优先级 表示执行某项变更的急迫程度,而变更的 类别 则用来定义变更对基础架构、用户乃至整个企业的影响程度。例如,变更所影响的是一个用户、一个部门或企业中的每个用户?变更是只涉及对单台交换机的更新,还是对整个网络系统的全面维检?变更所属类别取决于这类问题的答案。
  与优先级相似,对每类变更组成要素的界定将由组织机构视具体情况做出。在此,我们建议您采用已在其他企业中行之有效的分类方法。
• 主要。群体影响力巨大的变更——例如,涉及部门乃至企业的变更,亦或影响整个网络系统或服务体系的变更。
• 重要。能够产生广泛影响但规模相对有限的变更——例如,对部门或特定 CI 组合中的某个群体产生影响的变更。
• 次要。只对少数个体或 CI 构成影响的变更——例如,对人员较少的部门所使用的打印机进行调整。
• 标准。已被执行过并属于操作运转组成部分的变更——例如,对用户配置文件的更新。

  与变更优先级相似,变更类别也会与特定企业相关。影响某一特定部门的变更可能在某些企业中被视为重要变更,但在另一个企业中则可能被视为标准变更——因为相同部门在不同企业中所具有的重要性不同。这种情况同样出现在特定服务的提交或特写产品的使用环节。类别定义信息应该从“服务角色群体”、服务内容编录和服务级别管理 SMF 收集。
  然而,我们应对在这份指南中被称作 标准变更的变量类型给予特别关注。标准变更之所以在按类别区分的影响规模排序中位居最末,正是因为这种变更对用户或基础架构的影响很小。执行标准变更所需耗费的精力也相当小,而它为 IT 环境带来的风险相对较低。
  变更顾问委员会 (CAB) 通常会预先设定一系列标准变更和将它们付诸实现所需执行的一整套标准程序。这一系列标准变更可在无需 CAB 或变更管理人员进行表决的前提下得到自动核准,并因此踏上顺利通过变更审核程序的捷径。只有被纳入预定义标准集合中的变更事项方可归为此类。标准变更的范例包括定期执行的维护、经常执行的管理任务 (如配置文件变更) 和精简服务需求等。
将 RFC 提交审核
  变更发起人会详细记录用以描述变更提议的全部必要信息,并将 RFC 提交给变更管理人员。(变更管理人员这个角色是“ MOF 团队模型”中“发布角色群体”所包含的角色之一。如需进一步了解角色群体,请参阅 “MOF 运转团队模型” 白皮书 。 )为提供针对 RFC 的初级审查与“真实性”核查,应对具备 RFC 提交权限的组织中的用户数量加以限制。如果其他用户希望成为 RFC 发起人,则必须在正式提交并报送变更管理人员之前由其他人进行预先核准。
审查 RFC
  RFC 一经提交,就应立即接受审查。这个审查过程并不关注变更请求的有效性与核准状况,但可根据 RFC 所包含的信息与 RFC 所引用的资料判断能否做出授权或否决变更的决定。
这种初步审查必须由具备 RFC 审查权限或变更发起人主管资格的人员执行。这个环环相扣的预先核准程序应尽量保持简短——否则,就容易成为易于导致错误的管理和逻辑的负担。

这个审查程序应包括:
• 旨在确保 RFC 适当性的真实性审查。因为任何用户均可提出 RFC,这表示已被提出的 RFC 有可能:
• 与 IT 变更管理程序不相关。
• 不够详细。
• 因其复杂含意而未被完全理解。
• 因变更发起人缺乏变更管理程序知识而未能正确完成。
• 有助于评估人员全面理解变更影响力的补充信息(例如,源于变更管理数据库的影响力分析结果)。
• 在必要情况下对变更优先级和所属类别的重新界定。例如,如已将 RFC 作为标准变更提交,但 RFC 所具特征却不符合任何一种预先定义的标准变更类型,则必须进行重新分类。
  被指定从事 RFC 审查工作的人员负责在既定时段内根据变更请求优先级执行 RFC 审查及其他相关任务。紧急变更的审查时限应明显短于非紧急变更的审查时限。这些时间限制将由 SLA 约定。在变更管理人员无法执行 RFC 审查工作或无法在指定时间内完成 RFC 审查任务的情况下,应为其指派代理人,并授予代理人履行变更管理人员职责的权限。
  如果 RFC 未能在指定时限内接受审查,则应将其自动提交给事先指定的候补审查人员。这种通知可借助电子邮件发送。如无不妥,也可将这种电子邮件转发给 IT 执行委员会或通过另一条请求上报途径提交。这些详细信息还应被列示于每月提交的报告中,以期为管理当局提供更高水平的能见度。而未在规定时限内完成 RFC 审查任务的情况则应被纳入与 RFC 相关的变更日志。

  如果负责审查 RFC 的人员判定 RFC 未能提供赖以做出决策的必要信息,则应将 RFC 退还给变更发起人。变更管理人员将在变更日志中明确指定应予增补的信息和需要这些信息的理由。而 RFC 状态则被设为“待定”,变更发起人也将接到通知。于是,变更发起人会根据反馈意见将增补信息追加至 RFC ,并再次提交审查,而审查时限将从此时起重新计算。
  在将 RFC 退还并要求增补信息的情况下,变更发起人应及时重新提交,以防止出现处于“待定”状态的 RFC 继续等候重新提交或接受初步审查的情形。
  如果审查后认为 RFC 已包含据以研讨并核准变更事项的足够内容和支持信息,则应刷新变更日志并通知变更发起人,同时,将 RFC 提交变更分类阶段。
一旦 RFC 通过初步审查,变更管理人员就会为它设定一个用于跟踪目的的 ID ,并在变更日志中记录 RFC 已通过审查的情况。变更日志是变更管理的重要组成部分,旨在确保所有变更事项均可由变更管理人员控制并上报。变更日志就是保存所有变更事项历史记录的数据库——详细记录从 RFC 形成到变更得到发布或被否决的全过程——并将针对 RFC 的每次状态变化进行更新。企业可自主决定将变更日志作为独立数据库或纳入 CMDB 管理。
总之,变更请求程序主要由以下步骤组成:
  • 变更发起人以 RFC 形式编制并提交所需变更事项。
  • 指定审查人员判断 RFC 所含信息是否足以支持 RFC 审批决策。
  • 如果 RFC 未能提供足够信息,审查人员就会将其退还变更发起人,并要求增补必要详情。
  • 这个循环过程可确保 RFC 通过初审并具备进入变更分类程序的条件。

变更分类
  在此阶段,变更请求虽未被核准,但已通过初步审查。接下来的要求就是为变更赋予优先级和类别。即使变更发起人已事先录入优先级和分类信息,变更管理人员及其指定代理人仍会对这些信息进行复核,并有权视需要对优先级和分类进行调整。
设定 RFC 优先级
  变更管理人员将审核变更发起人建议采用的 RFC 优先级,并做出采纳或调整决定。RFC 优先级不仅影响到 CAB 审批变更请求的速度,而且决定着变更请求得到核准后的执行速度。变更管理人员将对已经提交的所有变更实施监控,因此,可立足于全局角度将当前 RFC 的优先级同其它 RFC 的优先级进行对比。
  由于优先级直接影响到审查和实施过程的先后顺序及时间安排,因此,排定优先级具有极其重要的意义。尤为重要的是,如果为急需付诸实施的变更赋予“紧急”优先级分类属性,则可大大缩短整个变更流程的行进路径。这也是将先前未被正确排定优先级的 RFC 重新提交变更管理人员再次评估的最佳时机。如果变更管理人员认为变更发起人所建议的优先级欠妥,亦或 CAB 应急委员会(CAB/EC)未对具有紧急优先级的变更请求给予必要重视,则可对优先级做出相应调整。
  如果变更管理人员调整优先次序,则应在变更日志中记录所做调整及相关理由。无论如何,变更日志均应记录针对变更优先级所进行的调整和做出相关决定的变更管理人员姓名及联络信息。
变更优先级的划分
  如前所述,优先级源于对变更要求的迫切程度。优先级的确定直接关系到变更接受评估并得以实施的速度。虽然每个企业均可结合自身具体情况定义相应的优先级水平,但我们仅在此通过以下表格进一步阐述曾在变更请求阶段简要介绍的四档分类体系。
小结
  总之,变更分类程序将:
• 根据业务需求确定 RFC 部署紧急程度,并在此基础上划定变更优先级。
• 根据 RFC 要求执行的变更事项本质特征界定 RFC 所属类别。
• 确定紧急变更的申报途径,即直接报送 CAB/EC。
• 确定已经预先授权的标准变更执行路径。
• 确定将其它变更事项报请变更管理人员、CAB 或 CAB/EC 审核的途径。

变更授权
  在合理排定变更优先级并进行适当分类的基础上,变更管理人员必须对变更事项进行授权。变更请求授权过程主要取决于变更所属类别和优先级:
• 已被赋予紧急优先级的变更将直接上报 CAB/EC 立即核准。
• 标准变更将得到自动核准,并直接进入变更开发与发布阶段。
• 次要变更将由变更管理人员审核,无需报送 CAB。
• 其他全部变更均须由 CAB 审核。

  下文将深入研讨这些审核程序。在每种具体情况下,都将由适当人员或主体根据 RFC 所提供的信息决定是否应将变更事项付诸实施。
  如果 RFC 遭到否决或变更未获核准,就应对 RFC 做结案处理并将决定通知变更发起人,而 RFC 遭到否决的原因则应被载入变更日志。 RFC 一旦结案,便不得重新提起。如果变更发起人希望再次提交该项变更请求,则应参考已被否决的初始 RFC 另外编制新的 RFC ,并在此基础上追加有助于变更请求获得批准的必要信息。针对初始 RFC 记载的否决原因应明确指出可能需要的额外信息。由于 RFC 已得到全面更新,因此,针对变更过程不同阶段定义的所有 SLA 时限(如初审完成时间)都将重新开始计算。如果 RFC 具有时间限制,则应为再次提交的 RFC 指定高于初始 RFC 的优先级,以弥补在初始变更请求的受理过程中形成的延迟。
  变更授权范围内的“MOF 团队模型”角色群体活动主要取决于变更事项的规模和实质。表4举例说明了每种角色在变更授权过程中的参与情况:
  标准变更是遵循既定途径实施的基础架构变更事项,具有较高的通用水平,并且是针对某一特定需求或一系列需求提供的广为接受的解决方案。标准变更的典型实例包括密码变更和专用文档模板更新。标准变更要素包括:
• 相关任务广为人知且历经实践检验。
• 变更事项已由 CAB 预先核准。
• 变更程序通常由服务台发起。
• 预算审核往往得到预先通过或可由发起人控制。
  标准变更将得到自动审批,并直接进入变更管理程序的变更部署阶段 (请参阅“变更开发与发布”小节)。由于人们普遍认同已被预先核准为标准变更的变更类型将对环境产生轻微影响或带来较低风险,因此,并不要求 CAB 甚至变更管理人员再次审核。而这恰恰意味着必须在初审过程中保持高度谨慎,以确保被认定的标准变更请求真正属于已经预先核准的变更类型。
审核次要变更
  次要变更是一种接近分类等级末端的变更——即影响和风险都很低的变更。次要变更与标准变更的差别在于,虽然前者风险较低,但从未付诸实施,因而必须经过核准方可执行。组成次要变更的实际内容主要取决于企业选择的标准。因为次要变更的影响程度和风险水平较低,而且执行变更的资源需求也很低,所以,次要变更无需报经 CAB 审核,只需由变更管理人员负责核准或否决。如果变更管理人员认为确有必要,仍可将 RFC 上报 CAB 核准。

本词条对我有帮助0
参考资料:
贡献者(共 1 名):
天下无人不识君(1)
如果您认为本词条还需进一步完善,e-works辞海欢迎您也来参与编辑词条 在开始编辑前,您还可以先学习如何编辑词条

词条统计

浏览次数:
编辑次数:1
最近更新:2009/2/3 10:32:32
创建者:天下无人不识君