本帖最后由monicazhang于2015-9-214:43编辑
20150902淡然 续上
3变更管理流程设计3.1流程执行原则3.1.1.流程常规原则ITSS考试q在某公司B2B所管理的生产环境中，将采用统一的变更管理流程处理各种请求，以控制变更所带来的风险。 q在所有外部用户提出及内部平台自身更新维护的过程中，涉及到某公司B2B服务的变更都应遵守变更管理流程。 q在变更管理流程中应充分考虑“风险”和“效率”的平衡，通过对变更的充分评估和审核控制变更的风险，但对不同类型的变更在流程或审批路径上区别对待，以达到高效的目标。 q应定期（每月）产生管理报表并进行检查，在流程开始运行的初期阶段，建议每半月进行一次报表检查。 q应定期（每半年）进行流程检查，以改进变更管理流程，在流程开始运行的初期，建议每季度进行一次流程检查。
3.1.2.责任制原则责任制原则用来确保在变更的任何时段都有适当的人员负责，从而保证变更处理的及时性及有效性。 q根据变更类型不同区分责任人，紧急/重大变更由变更经理及CAB（或CAB-EC）为责任人；一般变更由变更主管为责任人；标准变更由变更实施者为责任人，确保该变更的实施结果达到变更请求人或用户的期望。
3.1.3.审批原则所有RFC必须经过审批之后方可实施，但不同类型的变更对应的执行路径和审批人员不尽相同。下表描述了变更的执行途径及相应的审批人员。 表3‑1变更审批路径 变更类型
| | 紧急变更（P=1）
| | 重大变更（P=2）
| | 一般变更（P=3）
| | 标准变更（P=4）
| |
当CAB或CAB-EC中有多个审批人员时，原则上建议以召开CAB会议或紧急CAB会议的方式进行沟通、评估和决策，以提高审批环节的效率。如采用逐级审批方式，则审批的先后次序按照行政级别自下而上逐层审批，前一级别的管理人员若未完成审批，则不转给高一级管理人员审批。
3.1.4.通知原则通知政策用于确定当流程中的某些关键步骤发生时，应当通知相关人员以获其关注。ITSS认证 表3‑2变更通知矩阵 变更状态
| | | | | | | | 等待审批
|
|
|
| |
|
| 已批准
| |
| |
| |
| 已拒绝
| |
| |
| |
| 计划中
|
|
| |
| |
| 已排程
| | | |
| | | 构建测试中
|
|
|
|
| |
| 挂起
|
|
| |
| |
| 实施中
|
|
|
|
| |
| 已完成
| | | |
| |
| 已关闭
| | |
|
|
|
|
3.1.5.变更窗口原则变更窗口原则用于确定实施变更的日程。变更窗口通常能够减小对服务的影响。 变更窗口的制定需要考虑下列因素： q对业务的影响 q个别客户的特定业务需求 q变更实施和回退的时间 变更窗口原则应当形成书面文件并公布，供所有参与变更人员使用。 基于以上考虑，某公司B2B的基准变更窗口初步定义如下为： -对于可能造成服务中断的阿里巴巴B2B平台变更，窗口初步定义为周五20：00-周六8：00。 -对于涉及用户方的变更，窗口遵守用户方对变更的控制政策。
3.1.6.变更中断原则变更中断分为计划性（Planned）中断和非计划性（Unplanned）中断两种。 计划性中断 计划性中断的时间安排应当与用户进行协商，并且应至少在中断执行前2个工作日达成一致意见。 非计划性中断 对于处理事件或者问题时引起的非计划性中断。如非紧急变更，应至少在中断执行前1个工作日通知用户，并与用户达成一致意见；如为紧急变更，应至少保证在中断执行前通知用户，确保用户在知情并完成必要准备后才予以执行。
3.1.7.回退原则当变更实施失败或者无法在规定的时间内完成时，需要进行变更回退操作。任何回退的变更将作为变更失败而关闭。在下一次实施前，变更请求者必须重新提交新的变更请求单(RFC)，以便重新进行审批。
3.1.8.变更日历原则需要引入变更日历机制，协助某公司B2B查看对未来一段时间将要进行的变更，了解潜在变更冲突，进行合理的变更规划和安排。 该机制最好能在变更管理流程工具中实现，以提高变更排程的效率。ITSS培训
| 
转播
分享
淘帖
()