20150829淡然

续上

5变更记录和区分

当提交变更请求的时候，必须填写变更请求者信息，如姓名和联系方式等，同时记录该发起变更的原因，以及变更的时间安排。

5.1变更类型

在金禧，变更主要分为四类：标准变更、常规变更、紧急变更和项目变更。具体定义如下：

Ÿ紧急变更，定义系统出现严重的突发事件、高服务级别对象的专项任务、影响极其重大的突发事件，为解决这些突发事件而提出的变更，遵循紧急变更管理流程。ITSS认证

Ÿ常规变更，定位为风险很小或者没有风险的那些变更，且执行这些变更的步骤和方法已经很成熟，这些变更事先已经得到审批并记录在案，遵循简化的常规变更管理流程。单个的常规变更发生时，无须送至变更经理处进行审批，直接进行变更的执行。

Ÿ项目变更，指那些重大的变更，如合同的修改、管理人员的更换、引入新的系统或发生重大变更的系统，这些变更涉及面广，通常会涉及原合同的修改审批、管理人员的选择、软硬件的采购、供应商的选择、测试、上线等过程。

Ÿ其他的不在常规变更、紧急变更和项目变更范围内的变更，定义为标准变更，遵循标准变更管理流程。

以上标准变更、常规变更和紧急变更都在运维系统中进行了实现，借助运维系统可以提高变更管理流程的效率。这三类变更对应着发布管理中的紧急发布、常规发布和标准发布，且在变更管理流程中涵盖了发布的执行。

5.2变更分类

在区别变更的时候，除了辨别标准变更、常规变更和紧急变更之外，还需要区分该变更的技术类型，如：软件、硬件、参数。

5.3变更优先级

另外还需要判定变更优先级，以决定处理变更请求的先后次序。优先级主要由影响度和紧急性两个因素共同决定。在金禧，变更优先级与影响度和紧急性的关系见以下二维表：

优先级	紧急性
影响度		低	中	高
	低	低	中	高
	中	中	中	高
	高	中	高	紧急
	高	高	紧急	紧急

紧急性主要考虑执行该变更的时间要求。

序号	代码	描述
1	低	该变更不紧急，可以以后安排执行。
2	中	该变更不紧急，但也不可以安排到下次执行。
3	高	该变更时间要求紧，需要优先进行审批。
4	紧急	该变更要求马上进行审批。

影响度主要从以下几个方面考虑

Ø业务被影响的程度

Ø评价被影响的程度

Ø所需资源（人力、财力）

序号	代码	描述
1	低	变更对业务没有影响，仅影响单个用户，且所需人力财力也不多
2	中	变更使得业务性能下降，影响一个部门
3	高	变更使得业务不可用，出现大范围的负面评价，影响大部分或所有部门，且需要大量的人力财力资源

5.4发布计划

发布计划必须跟随变更管理相关流程，与相关项目、支持人员进行商讨，并获得签字确认。

每一个发布必须提供具体的发布计划，定义目标和范围，阶段和时间表。发布计划还包括以下内容：

Ÿ发布时间和交付物；

Ÿ相关RFC，问题和已知错误；

Ÿ风险评估，考虑对资产和配置项的威胁和弱点、可能的业务影响、失败可能性及成本。

在发布过程中所发现的问题或已知错误，以及相应的变通方案等，必须让突发事件管理人员获知。

除此之外，还必须考虑发布的回退措施或恢复措施。ITSS认证

同时在发布计划中还必须根据发布的内容定义发布接受标准，通常接受发布需要确保所有的文档都齐全，尤其是测试报告，且需要得到相关人员的签字确认。

在评估新的变更请求时，需要评估其对现有的发布计划的影响。项目类变更在评估和审批通过后，进入项目发布管理流程，制定发布计划、进行测试和上线。标准变更、常规变更和紧急变更流程中在审批后所进行的计划和测试、执行变更等动作就是标准发布、常规发布和紧急发布。发布结束后需要更新配置管理数据库，并关闭变更请求。

6评估与审批

对于标准变更，需要对其进行评估和审批。评估主要从以下几个方面进行：

Ÿ变更请求的风险；

Ÿ影响，需要分析变更对可用性和连续性的影响，即以变更对其他变更和发布的影响；

Ÿ成本和商业收益;

在对变更进行评估完后，变更及发布经理需要对变更进行审批。变更及发布经理根据需要征求CAB成员的意见。在金禧，CAB成员包括公司总经理室成员、各部门经理，相关技术人员等。变更经理根据具体变更，征求相关CAB成员的意见，并最终审批变更请求。当变更请求得到审批后，需要进行标准发布的进程。

对于紧急变更，变更发起者需要获得变更及发布经理的口头授权，然后才能执行紧急变更。变更经理在授权后，需要在《紧急变更列表》文档中进行记录，并检查变更发起者是否有进行补单。变更实施、实施后评审及改进。当紧急变更进行的同时，必须由变更及发布经理进行紧急发布的进程。

在变更审批通过后，需要制定实施计划。还必须包括变更的回退计划。实施完后需要修改相关配置项，在运维系统中，通过分派修改配置项任务单给配置项责任人的方式，来实现与配置管理的接口，包括记录配置基线和配置项更新。

已审批变更的实施日期安排必须作为新的变更和发布实施调度安排的基础。进度计划表包含所有被批准进行实施的变更和它们预期实施日期，在运维系统中已经自动实现。所有信息技术中心的技术人员能够在运维系统中查询进度计划，并且根据进度计划来安排新的变更或发布。

在变更实施完成后，变更及发布经理需要对其进行评审，评审主要从以下三个方面进行：

Ÿ变更是否达到目的；

Ÿ客户满意度；

Ÿ有无负面影响。

除了评审这些影响之外，对于标准变更，变更及发布经理还需要检查相关配置项是否记录了基线，配置项是否进行了更新。

对于标准变更和紧急变更，在每一个变更执行完毕后，都需要马上进行评估，并针对可能的问题制定应对措施。对于常规变更，无须每次变更执行完毕后马上进行评估，而由变更经理定期对前一周期内的常规变更进行回顾。如果发现某些常规变更发生的问题较多，则需要把该类常规变更变为标准变更，加强控制。（for9.25th）

变更记录必须每个月进行分析，以发现变更增长的水平、频繁的变更类型、趋势和其它相关信息。变更分析的结果和结论必须被记录。根据金禧变更及发布管理需求，定义需要分析数据：

Ÿ变更及发布类型统计

Ÿ变更及发布类型趋势

Ÿ变更及发布回退统计

Ÿ变更及发布分类统计

Ÿ变更及发布优先级统计

Ÿ根据变更及发布优先级的趋势统计变更信息

通过以上这些变更及发布分析报告，来帮助发现变更及发布的趋势、变更及发布增长的水平。

在变更及发布分析和审计过程中识别的问题，必须进行记录，并制定相应改进计划。

7变更及发布管理办法

Ÿ常规变更及常规发布，各项目按照公司现有的流程处理日常用户服务请求，并在运维系统中详细记录。

Ÿ标准变更及标准发布，各项目应通过邮件、电话等手段向总部说明需要变更及发布的服务组件以及具体的变更及发布内容，由总部发起变更及发布，统一进行变更及发布的计划、实施和控制，各项目根据工作任务单执行具体的变更及发布。

Ÿ对于紧急变更基金及发布，各项目应立即与公司联系，由总部统一安排。

Ÿ对于项目变更及项目发布，由公司统一发起，CAB成员审核通过后进行统一安排。

8流程持续改进

改进的原因：

Ÿ流程执行过程中发现的不足；

Ÿ流程自检过程中发现的不足；

Ÿ内部审核及外部审核中，发现的与ISO20000服务管理体系标准的不符合项；

Ÿ管理评审过程中发现的服务/流程改进点。

改进方法：

Ÿ由变更及发布经理组织流程改进讨论会议，与各方就改进需求、改进目标、改进方案沟通讨论；

Ÿ组织人员根据讨论结果提出服务管理改进计划及方案；

Ÿ服务管理体系负责人审批改进计划；

Ÿ对服务改进过程进行监控，对人事和资源做出合理安排；

Ÿ向管理体系负责人汇报改进结果；

Ÿ根据服务改进结果安排相应的知识转移工作，包括文档的更新发放、培训课程的安排等。

流程负责人的责任：

Ÿ负责在服务管理过程中识别服务管理改进需求并与客户沟通；

Ÿ负责制定具体的服务改进目标和方案，报服务管理体系负责人审批；

Ÿ负责管理和控制服务管理改进项目的实施；ITSS培训

Ÿ负责定期组织改进回顾，巩固服务改进成果；

Ÿ负责在服务改进项目完成后进行知识转移。

9流程详述

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

本帖关键字：ITSS

20150829淡然

续上

5变更记录和区分

当提交变更请求的时候，必须填写变更请求者信息，如姓名和联系方式等，同时记录该发起变更的原因，以及变更的时间安排。

5.1变更类型

在金禧，变更主要分为四类：标准变更、常规变更、紧急变更和项目变更。具体定义如下：

Ÿ紧急变更，定义系统出现严重的突发事件、高服务级别对象的专项任务、影响极其重大的突发事件，为解决这些突发事件而提出的变更，遵循紧急变更管理流程。ITSS认证

Ÿ常规变更，定位为风险很小或者没有风险的那些变更，且执行这些变更的步骤和方法已经很成熟，这些变更事先已经得到审批并记录在案，遵循简化的常规变更管理流程。单个的常规变更发生时，无须送至变更经理处进行审批，直接进行变更的执行。

Ÿ项目变更，指那些重大的变更，如合同的修改、管理人员的更换、引入新的系统或发生重大变更的系统，这些变更涉及面广，通常会涉及原合同的修改审批、管理人员的选择、软硬件的采购、供应商的选择、测试、上线等过程。

Ÿ其他的不在常规变更、紧急变更和项目变更范围内的变更，定义为标准变更，遵循标准变更管理流程。

以上标准变更、常规变更和紧急变更都在运维系统中进行了实现，借助运维系统可以提高变更管理流程的效率。这三类变更对应着发布管理中的紧急发布、常规发布和标准发布，且在变更管理流程中涵盖了发布的执行。

5.2变更分类

在区别变更的时候，除了辨别标准变更、常规变更和紧急变更之外，还需要区分该变更的技术类型，如：软件、硬件、参数。

5.3变更优先级

另外还需要判定变更优先级，以决定处理变更请求的先后次序。优先级主要由影响度和紧急性两个因素共同决定。在金禧，变更优先级与影响度和紧急性的关系见以下二维表：

优先级	紧急性
影响度		低	中	高
	低	低	中	高
	中	中	中	高
	高	中	高	紧急
	高	高	紧急	紧急

紧急性主要考虑执行该变更的时间要求。

序号	代码	描述
1	低	该变更不紧急，可以以后安排执行。
2	中	该变更不紧急，但也不可以安排到下次执行。
3	高	该变更时间要求紧，需要优先进行审批。
4	紧急	该变更要求马上进行审批。

影响度主要从以下几个方面考虑

Ø业务被影响的程度

Ø评价被影响的程度

Ø所需资源（人力、财力）

序号	代码	描述
1	低	变更对业务没有影响，仅影响单个用户，且所需人力财力也不多
2	中	变更使得业务性能下降，影响一个部门
3	高	变更使得业务不可用，出现大范围的负面评价，影响大部分或所有部门，且需要大量的人力财力资源

5.4发布计划

发布计划必须跟随变更管理相关流程，与相关项目、支持人员进行商讨，并获得签字确认。

每一个发布必须提供具体的发布计划，定义目标和范围，阶段和时间表。发布计划还包括以下内容：

Ÿ发布时间和交付物；

Ÿ相关RFC，问题和已知错误；

Ÿ风险评估，考虑对资产和配置项的威胁和弱点、可能的业务影响、失败可能性及成本。

在发布过程中所发现的问题或已知错误，以及相应的变通方案等，必须让突发事件管理人员获知。

除此之外，还必须考虑发布的回退措施或恢复措施。ITSS认证

同时在发布计划中还必须根据发布的内容定义发布接受标准，通常接受发布需要确保所有的文档都齐全，尤其是测试报告，且需要得到相关人员的签字确认。

在评估新的变更请求时，需要评估其对现有的发布计划的影响。项目类变更在评估和审批通过后，进入项目发布管理流程，制定发布计划、进行测试和上线。标准变更、常规变更和紧急变更流程中在审批后所进行的计划和测试、执行变更等动作就是标准发布、常规发布和紧急发布。发布结束后需要更新配置管理数据库，并关闭变更请求。

6评估与审批

对于标准变更，需要对其进行评估和审批。评估主要从以下几个方面进行：

Ÿ变更请求的风险；

Ÿ影响，需要分析变更对可用性和连续性的影响，即以变更对其他变更和发布的影响；

Ÿ成本和商业收益;

在对变更进行评估完后，变更及发布经理需要对变更进行审批。变更及发布经理根据需要征求CAB成员的意见。在金禧，CAB成员包括公司总经理室成员、各部门经理，相关技术人员等。变更经理根据具体变更，征求相关CAB成员的意见，并最终审批变更请求。当变更请求得到审批后，需要进行标准发布的进程。

对于紧急变更，变更发起者需要获得变更及发布经理的口头授权，然后才能执行紧急变更。变更经理在授权后，需要在《紧急变更列表》文档中进行记录，并检查变更发起者是否有进行补单。变更实施、实施后评审及改进。当紧急变更进行的同时，必须由变更及发布经理进行紧急发布的进程。

在变更审批通过后，需要制定实施计划。还必须包括变更的回退计划。实施完后需要修改相关配置项，在运维系统中，通过分派修改配置项任务单给配置项责任人的方式，来实现与配置管理的接口，包括记录配置基线和配置项更新。

已审批变更的实施日期安排必须作为新的变更和发布实施调度安排的基础。进度计划表包含所有被批准进行实施的变更和它们预期实施日期，在运维系统中已经自动实现。所有信息技术中心的技术人员能够在运维系统中查询进度计划，并且根据进度计划来安排新的变更或发布。

在变更实施完成后，变更及发布经理需要对其进行评审，评审主要从以下三个方面进行：

Ÿ变更是否达到目的；

Ÿ客户满意度；

Ÿ有无负面影响。

除了评审这些影响之外，对于标准变更，变更及发布经理还需要检查相关配置项是否记录了基线，配置项是否进行了更新。

对于标准变更和紧急变更，在每一个变更执行完毕后，都需要马上进行评估，并针对可能的问题制定应对措施。对于常规变更，无须每次变更执行完毕后马上进行评估，而由变更经理定期对前一周期内的常规变更进行回顾。如果发现某些常规变更发生的问题较多，则需要把该类常规变更变为标准变更，加强控制。（for9.25th）

变更记录必须每个月进行分析，以发现变更增长的水平、频繁的变更类型、趋势和其它相关信息。变更分析的结果和结论必须被记录。根据金禧变更及发布管理需求，定义需要分析数据：

Ÿ变更及发布类型统计

Ÿ变更及发布类型趋势

Ÿ变更及发布回退统计

Ÿ变更及发布分类统计

Ÿ变更及发布优先级统计

Ÿ根据变更及发布优先级的趋势统计变更信息

通过以上这些变更及发布分析报告，来帮助发现变更及发布的趋势、变更及发布增长的水平。

在变更及发布分析和审计过程中识别的问题，必须进行记录，并制定相应改进计划。

7变更及发布管理办法

Ÿ常规变更及常规发布，各项目按照公司现有的流程处理日常用户服务请求，并在运维系统中详细记录。

Ÿ标准变更及标准发布，各项目应通过邮件、电话等手段向总部说明需要变更及发布的服务组件以及具体的变更及发布内容，由总部发起变更及发布，统一进行变更及发布的计划、实施和控制，各项目根据工作任务单执行具体的变更及发布。

Ÿ对于紧急变更基金及发布，各项目应立即与公司联系，由总部统一安排。

Ÿ对于项目变更及项目发布，由公司统一发起，CAB成员审核通过后进行统一安排。

8流程持续改进

改进的原因：

Ÿ流程执行过程中发现的不足；

Ÿ流程自检过程中发现的不足；

Ÿ内部审核及外部审核中，发现的与ISO20000服务管理体系标准的不符合项；

Ÿ管理评审过程中发现的服务/流程改进点。

改进方法：

Ÿ由变更及发布经理组织流程改进讨论会议，与各方就改进需求、改进目标、改进方案沟通讨论；

Ÿ组织人员根据讨论结果提出服务管理改进计划及方案；

Ÿ服务管理体系负责人审批改进计划；

Ÿ对服务改进过程进行监控，对人事和资源做出合理安排；

Ÿ向管理体系负责人汇报改进结果；

Ÿ根据服务改进结果安排相应的知识转移工作，包括文档的更新发放、培训课程的安排等。

流程负责人的责任：

Ÿ负责在服务管理过程中识别服务管理改进需求并与客户沟通；

Ÿ负责制定具体的服务改进目标和方案，报服务管理体系负责人审批；

Ÿ负责管理和控制服务管理改进项目的实施；ITSS培训

Ÿ负责定期组织改进回顾，巩固服务改进成果；

Ÿ负责在服务改进项目完成后进行知识转移。

9流程详述

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

本帖关键字：ITSS