20150829 淡然

续上

2      流程详细说明2.1      指导方针

为了给某公司的变更管理流程提供方向，必须定义一些指导方针。这些方针可以为所有的流程活动服务，也可以仅仅服务于某一个动作。

指导方针的定义基于ITIL的最佳实践，同时根据某公司的具体情况进行调整，从而满足某公司的实际需求。

下面列出某公司变更管理流程的指导方针：                                 ITSS考试

方针 1:

每个影响一个或多个配置项的变更请求必须严格遵循变更管理流程

最佳实践：

§  变更管理流程必须覆盖所有提交的对于IT生产环境对象的变更。

§  变更请求必须被录入到统一的数据库，包括紧急变更。

§  鉴于一个变更请求可能涉及对于多个配置项的影响，变更与这些配置项之间的关系必须被明确定义。

启示：

§  必须准备标准的变更请求模板。

§  鉴于遵循变更流程可能会使得变更，特别是普通变更的过程显得比较长，因此特别应注意变更的快速回退。

§  必须为用户（即业务部门）与IT部门内部准备和提供相应的培训。

§  鉴于配置管理与变更管理的紧密联系，此二流程必须采用统一的后台信息库且可以实时交互。

§  所有生产环境中的配置项必须被辨识并保存其最新信息与状态。

§  生产环境中所有的新配置项的引进必须遵循变更管理流程。

方针 2:

所有的变更请求记录都应被记录和追踪

最佳实践：

§  记录所有变更请求以便日后回顾和优先级安排。

启示：

§  变更经理必须确认流程边界并作为变更管理与其他流程和部门组织的接口。

§  必须提供追踪、记录、批准、驳回和注销变更请求的流程步骤和平台系统。

方针 3:

变更管理流程必须保证流程和指导原则的正式文档化并且被严格遵循

最佳实践:

§  不同类型的变更的流程，根据其风险、潜在影响以及紧急程度，可以采用不同流程步骤。

§  变更管理流程涉及到的所有参与者都应该可以了解到流程进展和指导原则的详细情况。

§  有效的培训是变更管理流程成功的关键。

启示:

§  鉴于对不同变更类型采取不同处理步骤，变更必须被明确的分类和定义。

§  鉴于变更管理流程及其文档本身就是一个配置项，任何对于流程和文档的修改必须遵从变更管理的流程并得到批准。

方针 4:

变更管理流程负责处理相互关联应用及IT基础设施在变更执行时的日程冲突。

最佳实践:

§  上线的时间必须在结合系统关联分析、项目上线日程和业务部门需求的基础上决定。

§  如果没有由于系统之间依赖关系而需并行上线的要求，没有能够赶上生产测试的项目应该被推迟到下一个生产系统上线周期内。

§  当由于依赖关系必须进行并行上线时，变更管理应该通过协调工作保证所有必需的应用和设施同时部署到位。

启示:

§  为了满足服务等级承诺，项目可能需要更多的工作量。

§  变更管理流程应管理和保持IT组织内部对于并行项目和上线日程的了解，特别是在安排预定变更 (Forward Schedule of Changes) 时。

§  项目经理需要了解其在变更管理流程中的角色。

§  不同角色和部门之间应该保持良好的沟通与交流，可能的话，应该将这种交流制度化。

方针 5:

在整个变更生命周期中与配置项负责人应保持良好的沟通

最佳实践:

§  变更管理人员应与配置项负责人和服务负责人保持不间断的联系。

§  配置项负责人与服务负责人将为变更管理提供运行测试和结果回顾。

§  配置项负责人与服务负责人应为变更经理提供测试结果或报告。

启示:

§  需要准备一个标准的系统开发生命周期管理，变更管理应与之配合。

§  应该准备标准格式的系统测试结果报告。

方针 6:

一定要为生产环境的紧急变更实施提供快速实施处理的机制

最佳实践:

§  应为紧急变更的测试与实施准备特别的变更流程。

§  对于紧急变更，在实施之前仍需要测试，但是可以考虑部分功能测试而非全面测试。

§  在紧急变更实施完成后，变更经理和变更主管应该负责该变更相关文档的完成。

启示:

§  紧急变更很可能未经过全面测试就被导入到生产系统。                            ITSS认证

§  紧急变更总是伴随着风险。

方针 7:

被确认为是标准变更的实施将遵循标准变更模式流程

最佳实践:

§  应该准备判定是否为标准流程的准则，并且要随着流程的运行定期回顾与更新。

§  应该通过变更管理工具记录标准变更的类型。

§  应定期回顾标准变更的数量和类型，并持续更新。

§  应该创建和维护标准变更模式。

2.2      流程关系图

图2 变更管理流程与其他管理流程关系

变更管理可以从任何其他的服务管理流程接收到变更管理请求(RFC)，变更管理流程通过回顾审核RFC之后以任务工单的方式将工作指派给相应的人员，由变更负责人根据任务工单主导变更的实施。同时变更管理通过实时了解任务工单的状态来监控变更的实施。

§  突发事件管理

变更管理为突发事件管理提供变更的时间表，同时为了对应突发事件所采取的对于生产环境的变更，应受到变更管理的控制。

§  配置管理

配置管理提供配置项的属性及配置项之间的相互关系、所需变更的配置项与IT服务之间的关系等信息，从而帮助变更管理判断和估计变更的风险和影响，同时变更管理流程执行完成变更后更新变更记录、配置项属性和财务成本数据。

§  服务开发与测试流程/服务上线流程

变更管理通过开发测试流程与上线流程实现变更，同时开发测试流程与上线流程为变更流程提供变更时间表。

§  其他可能提交RFC的流程

包括可用性管理流程、问题管理流程、服务级别管理流程、连续性管理流程等一切可能需要变更来实现管理目标和目的的流程，如果需要，此类流程向变更管理流程提交RFC，由变更管理流程负责控制和协调变更的实施，并及时反馈变更状态和结果。

2.3      变更管理总图

基本要点：

本变更指南所提供的流程参考，主要的目的是从变更管理的生命周期(从登记录入、评估、审批、安排、开发测试、实施到事后评估)角度着手提出对于变更流程的建议，因此无论是集团公司的变更、分公司的变更、还是涉及集团公司、分公司与中支公司的多方变更，从变更生命周期的角度，其流转的过程原则都是相同的，目前CPIC集团内部的IT系统的管理正处在从分散授权到全面集中的变化过程中，本变更指南主要从变更管理的共性着手，同时也对当前可能的具体情况提出建议。

本变更指南对于流程的描述主要包括以下几方面：

• 流程图
  

主要描述流程的走向和主要活动，通过分级的流程子图细致展示流程，本流程指南主要细化到第二级。

• 流程描述
  

针对流程图中出现的主要活动展开描述，每一活动的内容包括：

§  编号：唯一流程活动编号

§  管理活动：管理活动简述

§  输入/触发：流程活动输入和启动条件

§  描述：流程活动的具体描述

§  输出/完成标准：流程活动的输出成果与结束标准

§  变更状态：变更生命周期状态

§  适用性考虑：针对某公司的现状和发展方向的考量和建议

• 角色
  

角色是在流程中某些职责和权限的组合，并非代表特别的人或者位于特别的地域。

图3  变更管理流程总览

[td]

编号	管理活动	输入/触发	描述	输出/完成标准	变更状态	适用性考虑
6.3.1	变更登记与分类	输入：发现变更需要 变更请求	变更提交人提交变更请求至变更管理流程。主要活动包括变更请求的回顾、评估、接受、拒绝、记录、分类和优先级划定 ，及驳回变更请求的申诉仲裁。	变更的记录与分类； 紧急变更纪录	已登记/已驳回
6.3.2	变更风险与影响评估	已接受的变更请求	判断与分析大小变更对于生产环境与业务的风险和影响。	变更审批	已评估
6.3.3	变更审批	已完成评估正等待批准的变更	召开CAB会议（如果需要），讨论和回顾变更细节，审批或驳回变更，为变更的开发、测试和实施分配资源，并知会变更提交人。	变更的时间安排	已授权
6.3.4	变更日程安排	输入：标准变更；已审批的变更；	安排变更的日程并通知所有会受到变更实施影响的方方面面。	变更开发与测试日程	已计划
6.3.5	变更开发测试与确认	输入: 变更日程	计划、开发、测试变更、记录测试结果，并确认变更所需要的各因素符合要求。	协调变更实施	开发测试中
6.3.6	协调变更实施	输入：准备好的一般变更	生产环境中的变更实施。	变更实施后回顾 验证变更已经完成并注销	进行中
6.3.7	变更实施后回顾	输入：成功实施变更	与变更提交人回顾、记录和讨论，验证变更正确完成并关闭变更记录 。	关闭 RFC	已结束
6.3.8	紧急变更处理	输入：记录和识别的紧急变更	召开ECAB来批准变更并紧急实施变更。	变更回顾 验证紧急变更已完成并注销纪录
6.3.9	标准变更处理	输入：计划好的标准变更	实施标准变更并关闭变更纪录。	关闭变更纪录
6.3.10	变更回退	输入：实施失败的变更	执行变更回退计划。                   ITSS培训	恢复失败的变更对于生产环境的影响	已回退

待续http://www.ITILxf.com/thread-52355-1-1.html

本帖关键字：ITSS

20150829 淡然

续上

2      流程详细说明2.1      指导方针

为了给某公司的变更管理流程提供方向，必须定义一些指导方针。这些方针可以为所有的流程活动服务，也可以仅仅服务于某一个动作。

指导方针的定义基于ITIL的最佳实践，同时根据某公司的具体情况进行调整，从而满足某公司的实际需求。

下面列出某公司变更管理流程的指导方针：                                 ITSS考试

方针 1:

每个影响一个或多个配置项的变更请求必须严格遵循变更管理流程

最佳实践：

§  变更管理流程必须覆盖所有提交的对于IT生产环境对象的变更。

§  变更请求必须被录入到统一的数据库，包括紧急变更。

§  鉴于一个变更请求可能涉及对于多个配置项的影响，变更与这些配置项之间的关系必须被明确定义。

启示：

§  必须准备标准的变更请求模板。

§  鉴于遵循变更流程可能会使得变更，特别是普通变更的过程显得比较长，因此特别应注意变更的快速回退。

§  必须为用户（即业务部门）与IT部门内部准备和提供相应的培训。

§  鉴于配置管理与变更管理的紧密联系，此二流程必须采用统一的后台信息库且可以实时交互。

§  所有生产环境中的配置项必须被辨识并保存其最新信息与状态。

§  生产环境中所有的新配置项的引进必须遵循变更管理流程。

方针 2:

所有的变更请求记录都应被记录和追踪

最佳实践：

§  记录所有变更请求以便日后回顾和优先级安排。

启示：

§  变更经理必须确认流程边界并作为变更管理与其他流程和部门组织的接口。

§  必须提供追踪、记录、批准、驳回和注销变更请求的流程步骤和平台系统。

方针 3:

变更管理流程必须保证流程和指导原则的正式文档化并且被严格遵循

最佳实践:

§  不同类型的变更的流程，根据其风险、潜在影响以及紧急程度，可以采用不同流程步骤。

§  变更管理流程涉及到的所有参与者都应该可以了解到流程进展和指导原则的详细情况。

§  有效的培训是变更管理流程成功的关键。

启示:

§  鉴于对不同变更类型采取不同处理步骤，变更必须被明确的分类和定义。

§  鉴于变更管理流程及其文档本身就是一个配置项，任何对于流程和文档的修改必须遵从变更管理的流程并得到批准。

方针 4:

变更管理流程负责处理相互关联应用及IT基础设施在变更执行时的日程冲突。

最佳实践:

§  上线的时间必须在结合系统关联分析、项目上线日程和业务部门需求的基础上决定。

§  如果没有由于系统之间依赖关系而需并行上线的要求，没有能够赶上生产测试的项目应该被推迟到下一个生产系统上线周期内。

§  当由于依赖关系必须进行并行上线时，变更管理应该通过协调工作保证所有必需的应用和设施同时部署到位。

启示:

§  为了满足服务等级承诺，项目可能需要更多的工作量。

§  变更管理流程应管理和保持IT组织内部对于并行项目和上线日程的了解，特别是在安排预定变更 (Forward Schedule of Changes) 时。

§  项目经理需要了解其在变更管理流程中的角色。

§  不同角色和部门之间应该保持良好的沟通与交流，可能的话，应该将这种交流制度化。

方针 5:

在整个变更生命周期中与配置项负责人应保持良好的沟通

最佳实践:

§  变更管理人员应与配置项负责人和服务负责人保持不间断的联系。

§  配置项负责人与服务负责人将为变更管理提供运行测试和结果回顾。

§  配置项负责人与服务负责人应为变更经理提供测试结果或报告。

启示:

§  需要准备一个标准的系统开发生命周期管理，变更管理应与之配合。

§  应该准备标准格式的系统测试结果报告。

方针 6:

一定要为生产环境的紧急变更实施提供快速实施处理的机制

最佳实践:

§  应为紧急变更的测试与实施准备特别的变更流程。

§  对于紧急变更，在实施之前仍需要测试，但是可以考虑部分功能测试而非全面测试。

§  在紧急变更实施完成后，变更经理和变更主管应该负责该变更相关文档的完成。

启示:

§  紧急变更很可能未经过全面测试就被导入到生产系统。                            ITSS认证

§  紧急变更总是伴随着风险。

方针 7:

被确认为是标准变更的实施将遵循标准变更模式流程

最佳实践:

§  应该准备判定是否为标准流程的准则，并且要随着流程的运行定期回顾与更新。

§  应该通过变更管理工具记录标准变更的类型。

§  应定期回顾标准变更的数量和类型，并持续更新。

§  应该创建和维护标准变更模式。

2.2      流程关系图

图2 变更管理流程与其他管理流程关系

变更管理可以从任何其他的服务管理流程接收到变更管理请求(RFC)，变更管理流程通过回顾审核RFC之后以任务工单的方式将工作指派给相应的人员，由变更负责人根据任务工单主导变更的实施。同时变更管理通过实时了解任务工单的状态来监控变更的实施。

§  突发事件管理

变更管理为突发事件管理提供变更的时间表，同时为了对应突发事件所采取的对于生产环境的变更，应受到变更管理的控制。

§  配置管理

配置管理提供配置项的属性及配置项之间的相互关系、所需变更的配置项与IT服务之间的关系等信息，从而帮助变更管理判断和估计变更的风险和影响，同时变更管理流程执行完成变更后更新变更记录、配置项属性和财务成本数据。

§  服务开发与测试流程/服务上线流程

变更管理通过开发测试流程与上线流程实现变更，同时开发测试流程与上线流程为变更流程提供变更时间表。

§  其他可能提交RFC的流程

包括可用性管理流程、问题管理流程、服务级别管理流程、连续性管理流程等一切可能需要变更来实现管理目标和目的的流程，如果需要，此类流程向变更管理流程提交RFC，由变更管理流程负责控制和协调变更的实施，并及时反馈变更状态和结果。

2.3      变更管理总图

基本要点：

本变更指南所提供的流程参考，主要的目的是从变更管理的生命周期(从登记录入、评估、审批、安排、开发测试、实施到事后评估)角度着手提出对于变更流程的建议，因此无论是集团公司的变更、分公司的变更、还是涉及集团公司、分公司与中支公司的多方变更，从变更生命周期的角度，其流转的过程原则都是相同的，目前CPIC集团内部的IT系统的管理正处在从分散授权到全面集中的变化过程中，本变更指南主要从变更管理的共性着手，同时也对当前可能的具体情况提出建议。

本变更指南对于流程的描述主要包括以下几方面：

• 流程图
  

主要描述流程的走向和主要活动，通过分级的流程子图细致展示流程，本流程指南主要细化到第二级。

• 流程描述
  

针对流程图中出现的主要活动展开描述，每一活动的内容包括：

§  编号：唯一流程活动编号

§  管理活动：管理活动简述

§  输入/触发：流程活动输入和启动条件

§  描述：流程活动的具体描述

§  输出/完成标准：流程活动的输出成果与结束标准

§  变更状态：变更生命周期状态

§  适用性考虑：针对某公司的现状和发展方向的考量和建议

• 角色
  

角色是在流程中某些职责和权限的组合，并非代表特别的人或者位于特别的地域。

图3  变更管理流程总览

[td]

编号	管理活动	输入/触发	描述	输出/完成标准	变更状态	适用性考虑
6.3.1	变更登记与分类	输入：发现变更需要 变更请求	变更提交人提交变更请求至变更管理流程。主要活动包括变更请求的回顾、评估、接受、拒绝、记录、分类和优先级划定 ，及驳回变更请求的申诉仲裁。	变更的记录与分类； 紧急变更纪录	已登记/已驳回
6.3.2	变更风险与影响评估	已接受的变更请求	判断与分析大小变更对于生产环境与业务的风险和影响。	变更审批	已评估
6.3.3	变更审批	已完成评估正等待批准的变更	召开CAB会议（如果需要），讨论和回顾变更细节，审批或驳回变更，为变更的开发、测试和实施分配资源，并知会变更提交人。	变更的时间安排	已授权
6.3.4	变更日程安排	输入：标准变更；已审批的变更；	安排变更的日程并通知所有会受到变更实施影响的方方面面。	变更开发与测试日程	已计划
6.3.5	变更开发测试与确认	输入: 变更日程	计划、开发、测试变更、记录测试结果，并确认变更所需要的各因素符合要求。	协调变更实施	开发测试中
6.3.6	协调变更实施	输入：准备好的一般变更	生产环境中的变更实施。	变更实施后回顾 验证变更已经完成并注销	进行中
6.3.7	变更实施后回顾	输入：成功实施变更	与变更提交人回顾、记录和讨论，验证变更正确完成并关闭变更记录 。	关闭 RFC	已结束
6.3.8	紧急变更处理	输入：记录和识别的紧急变更	召开ECAB来批准变更并紧急实施变更。	变更回顾 验证紧急变更已完成并注销纪录
6.3.9	标准变更处理	输入：计划好的标准变更	实施标准变更并关闭变更纪录。	关闭变更纪录
6.3.10	变更回退	输入：实施失败的变更	执行变更回退计划。                   ITSS培训	恢复失败的变更对于生产环境的影响	已回退

待续http://www.ITILxf.com/thread-52355-1-1.html

本帖关键字：ITSS