本帖最后由 monicazhang 于 2015-9-2 14: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培训
| 
转播
分享
淘帖
()