本帖最后由 monicazhang 于 2015-7-7 16: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 目标解决时间机制目标时间机制主要针对变更生命周期的关键步骤，广州地铁变更管理流程目标时间机制规定了几个关键步骤所应该完成的时间。 注：[等待审批-已批准]指第一次等待审批至最后一次对RFC批准完成的时间。
3.1.3.5 前导时间机制前导时间是指从提交变更到变更实施之前所需要进行评估、审核等准备活动的最少时间。前导时间是基于变更影响度而定的。实施变更需要适当的前导时间进行评估和制定计划。前导时间原则必须与变更窗口及目标时间机制结合来考虑制定。 前导时间定义见下表，在流程运行一段时间后，可以根据实际情况进行调整： 详细定义的变更前导时间见下表，在流程运行一段时间后，可以根据实际情况进行调整：
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 变更信息项变更请求单可以包含如下可选的变更信息项，广州地铁服务团队可以在此基础上进行扩充： [td]序号 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 变更的初步方案，包括实施方案、测试方案、回退方案和CMDB更新方案等 | | | | | | | | | | | | | | | | | | | | | | | | |
3.1.4.2 变更状态代码下列状态码表示变更请求单的生命周期中的不同阶段： 变更状态代码 | | | | | | | 变更主管提交变更及初步评估计划内容至变更经理及变更顾问委员会等待审批 | | | | 变更主管准备变更发布的日程计划，并得到变更经理的确认 | | | | | | | | | | |
3.1.4.3 变更分类在本项目中，将使用三级（CTI）分类来对变更进行分类： 类别（Category） 类别是CTI分类方法的最高层。它将被用作对变更进行分组的第一层。例如：硬件、系统软件、网络、应用软件、数据库。 子类（Type） 子类用来区分每个“系统”的基本组成模块。它将被用作对变更进行分组的第二层。例如：对类别“硬件”来说，可以分为服务器、打印机和监视器等“子类”。 项目（Item） 这个层次体系中第三层是项目。项目这一层能够获得更详细的信息和更准确的搜索。 初定的变更分类如下，可待流程运转一段时间后进行调整： 变更分类表如下： 请参考“附件-变更分类表”
3.1.4.4 变更关闭代码变更结束代码用来表示变更实施的结果，如下表所示：
本帖关键字：ITSS
| 
转播
分享
淘帖
()