ISO20000中的ITSS变更流程介绍
本帖最后由monicazhang于2015-7-716:12编辑20150707淡然
3内容
3.1流程介绍
3.1.1流程解释变更管理是指采用标准统一的方法和步骤来管理、控制所有对IT生产环境有影响的变更活动。通过执行变更流程，对所有操作进行正确评估和实施，从而维护IT生产环境的完整性，减少由于准备不当等原因出现的对IT环境造成的风险。ITSS培训
3.1.2业务价值
变更管理是一个关键流程，通过规范的控制和管理，增加变更过程的可控性，减少或者消除在执行变更工作任务时对关键生产服务带来的风险和影响。§使变更决策的制定和规划更为有效§通过实施到企业中，提高变更的沟通和可视性§通过减少实施变更的周期加速业务需求投放市场的时间§减少浪费，使仅能够提升业务收益的变更才能被批准§变更按照优先级和变更类型得以合理规划，避免冲突§增强变更控制回退到以前状态的能力§减少了变更实施时间
3.1.3流程政策§在广州地铁所管理的生产环境中，将采用统一的变更管理流程处理各种请求§变更管理负责对系统的变更进行管理，以控制变更所带来的风险§变更管理流程应有适当的灵活性，以满足例外的需求§在广州地铁所管理的生产环境中，所有的变更请求均应采取集中式管理§所有涉及技术、流程、操作步骤等可能影响服务能力的变更将遵循变更管理流程§应该明确标准变更和相应预授权§应定期（每月）产生管理报表并进行检查§通过变更管理会议对变更活动进行跟踪、沟通和协调§应定期（每半年）进行流程检查，以改进管理流程
3.1.3.1变更类型变更类型代表了变更执行的审批路径，可分为重大变更和标准变更两类。§重大变更–重大变更指的是涉及影响范围较大、实施风险较大（实施的失败会带来重大后果）、实施较复杂（例如需要集成开发，多部门协同实施处理）的变更。§标准变更–标准变更指的是日常发生、影响范围小、有标准操作流程、实施风险小（不会带来重大后果）的预授权的变更。–标准变更需要预先制定出相应的变更清单，涉及客户部分且需要与客户确认。
3.1.3.2责任人机制§责任制机制用来确保在变更的任何时段都有适当的人员负责，从而保证变更处理的及时性及有效性。§根据变更类型不同区分责任人。–重大变更由变更经理及CAB（或CAB-EC）为责任人；–标准变更由变更实施者为责任人，确保该变更的实施结果达到变更请求人或用户的期望。
3.1.3.3审批机制所有RFC必须经过审批之后才方可实施，但不同类型的变更对应的执行路径和审批人员也不尽相同。下表描述了变更的执行途径及相应的审批人员。
变更类型审批路径
重大变更赵翔/刘航
标准变更变更主管
3.1.3.4目标解决时间机制目标时间机制主要针对变更生命周期的关键步骤，广州地铁变更管理流程目标时间机制规定了几个关键步骤所应该完成的时间。
目标时间受理变更审批变更关闭变更
测量准则[新建-等待审批]*[等待审批-已批准]*[已完成-已关闭]
重大变更30个工作日1-3个工作日30个工作日
标准变更1个工作日N/A1个工作日
注：[等待审批-已批准]指第一次等待审批至最后一次对RFC批准完成的时间。
3.1.3.5前导时间机制前导时间是指从提交变更到变更实施之前所需要进行评估、审核等准备活动的最少时间。前导时间是基于变更影响度而定的。实施变更需要适当的前导时间进行评估和制定计划。前导时间原则必须与变更窗口及目标时间机制结合来考虑制定。前导时间定义见下表，在流程运行一段时间后，可以根据实际情况进行调整：
变更类型最少前导时间
重大变更1个月
标准变更3天
详细定义的变更前导时间见下表，在流程运行一段时间后，可以根据实际情况进行调整：
类别子类项目准备时间
硬件内存添加/更换/拆卸1月
硬件硬盘添加/更换/拆卸1月
硬件服务器添加/更换/撤回1-2周
硬件交换机添加/更换/撤回1月
硬件网线添加/更换/拆卸1周
硬件主板更换3天
硬件电源更换3天
硬件RAID和DRAC卡更换3天
网络带宽汇聚/添加/减少1-2月
软件固件版本更新1周
3.1.3.6通知机制通知机制用于确定当流程中的某些关键步骤发生时，应当通知人员以获其关注。
变更状态根据角色通知
变更请求者变更对象变更经理变更审批者变更主管变更实施者
等待审批√
已批准√√√
已拒绝√√√√
计划中√√
已排程√√√√√
构建测试中√
挂起√√
实施中√
已完成√√√√
已关闭√√
3.1.3.7回退机制当变更实施失败或者无法在规定的时间内完成，则需要进行回退。变更回退是为了满足所承诺的服务水平。任何回退的变更将作为变更失败而关闭，在下一次实施前，变更请求者必须重新提交新的变更请求单(RFC)，以便重新进行审批。
3.1.3.8关闭机制变更实施完毕并且得到确认后，将由变更经理关闭RFC。变更之后如果引发了其他问题，将更新变更单的信息。ITSS认证
3.1.3.9流程关联原则与事故管理的关联§事故管理与变更管理的关系是通过问题管理间接联系起来的。变更管理通过实施变更降低了事故发生的频率和事故产生的影响。与问题管理的关联§问题管理在对事故产生的原因进行调查和分析后，可能向变更管理提交变更请求。变更管理负责对这些变更请求进行评审、批准、实施和监控，以确保实施的变更能够从根本上解决问题，并保证变更对业务的影响被减小到最低程度。与配置管理的关联§变更管理需要根据配置管理提供的配置数据分析某项变更对IT服务运作的影响，而配置管理则负责对变更的结果作出详细的记录。与发布管理的关联§在变更管理将某项变更导入实际的运作环境之前，需要发布管理对这些变更项目进行发布和分发，以加强业务方和IT部门的信息沟通，尽量减少变更对业务运作的影响。
3.1.4流程相关定义
3.1.4.1变更信息项变更请求单可以包含如下可选的变更信息项，广州地铁服务团队可以在此基础上进行扩充：
序号信息项说明
1变更单号变更请求单的唯一流水号
2变更状态参与“变更状态代码”定义
3变更登记时间变更登记时间，系统自动生成
4变更登记人变更请求的登记人信息
5变更涉及设备变更涉及的设备信息
6变更描述变更内容的描述说明
7变更原因发起变更的原因说明
8变更期望完成时间变更请求者对变更实施完毕的期望时间点
9变更类型参与“变更类型”定义
10变更分类参见“变更分类”定义
11变更紧急度变更的紧急程度
12变更影响度变更的影响程度
13变更优先级变更评审、测试和实施的优先级
14变更方案变更的初步方案，包括实施方案、测试方案、回退方案和CMDB更新方案等
15变更评审人员变更评审人员信息
16评审意见变更评审人员对变更的评审意见
17变更实际完成时间变更实施结束的实际时间点
18关联事件单变更关联的事件单
19关联问题单变更关联的问题单
20关联工作单变更关联的工作单
21请求人反馈信息变更请求者对变更实施效果的反馈信息
22变更失败原因导致变更失败的主要原因描述，变更失败时填写
3.1.4.2变更状态代码下列状态码表示变更请求单的生命周期中的不同阶段：
变更状态代码状态说明
新建变更请求单新建并提交至变更经理
初步评估及计划中变更主管对变更进行初步评估和方案准备
等待审批变更主管提交变更及初步评估计划内容至变更经理及变更顾问委员会等待审批
已批准RFC经过风险及影响评估后得到批准
已排程变更主管准备变更发布的日程计划，并得到变更经理的确认
构建测试中变更主管对变更进行构建和测试
实施中变更实施和上线
挂起由于供应商采购等原因将变更挂起
已完成等待变更经理对变更进行回顾
已关闭变更经理关闭变更单
3.1.4.3变更分类在本项目中，将使用三级（CTI）分类来对变更进行分类：类别（Category）类别是CTI分类方法的最高层。它将被用作对变更进行分组的第一层。例如：硬件、系统软件、网络、应用软件、数据库。子类（Type）子类用来区分每个“系统”的基本组成模块。它将被用作对变更进行分组的第二层。例如：对类别“硬件”来说，可以分为服务器、打印机和监视器等“子类”。项目（Item）这个层次体系中第三层是项目。项目这一层能够获得更详细的信息和更准确的搜索。初定的变更分类如下，可待流程运转一段时间后进行调整：变更分类表如下：请参考“附件-变更分类表”
3.1.4.4变更关闭代码变更结束代码用来表示变更实施的结果，如下表所示：
关闭代码描述
成功变更成功实施完毕
未成功变更实施失败
取消在实施前取消了变更ITSS考试
待续：http://www.ITILxf.com/thread-51391-1-1.html
本帖关键字：ITSS
页:
[1]