20151118 淡然

续上

2.7.6.1.3       考核关键指标

目前一般变更流程暂时没有定义相应的绩效考核指标。

2.7.6.1.4       已有优势

经过问卷、访谈和调查分析，可以发现某公司现有的变更管理流程存在以下的优势：                 ITSS考试

Ø  清晰定义服务和架构变更的范围，并形成文件；

Ø  变更请求被批准和检查，并以受控方式实施；

Ø  定义了变更实施的日期；

Ø  具备与变更相关方沟通的机制；

Ø  变更实施后，评审了变更是否成功。

2.7.6.1.5       需求与期望   

1.        随着业务的发展，IT相关的需求也越来越复杂。目前尚没有清晰的流程来界定新需求和变更的范围。因此有必要对变更管理进分类，并设置一系列的流程和职责，保证变更需求可以成功的转化映射到应用系统的建设和维护上。

2.        2012年某公司将新上线30多个系统，这些新系统及项目的启动、测试、上线、推广等全过程都需要运维服务的支持，因系统涉及服务面广、用户量大，随之带来大量的服务请求和变更，如何优化当前的服务资源，高效支持更多的服务请求是运维服务部需要着重解决的挑战之一。经需求调研访谈了解到：要做好IT运维服务的容量管理，对升级改造做决策，这样调配资源就有依据。

2.7.6.1.6       流程评估

通过问卷，我们得出目前的变更流程的成熟度如下图：

图 39变更管理成熟度

由成熟度图可以看出，虽然有成文的变更管理文档，但是对变更管理要更多的体现在对变更的审核上面，但是对于变更的过程控制等后续的活动并没有过多的考虑，所以在质量控制、管理信息和外部整合度都稍微差一些。主要体现在以下方面：

Ø  没有定义一个规范用于触发并登记变更过程；

Ø  没有定期做完整的变更管理报告；

Ø  仅对重大变更进行记录和评估，分析范围需要进一步拓展；                            ITSS认证

Ø  没有对变更进行客户满意度调查。

2.7.6.2              差距分析及改进建议

编号	现状	改进建议
CHM1	目前OA和变更流程无接口，造成OA流程审批完成后还需要在ITSM的变更流程中再次流转审批	开发ITSM和OA相应功能，将OA与ITSM平台审批节点进行联动，满足总公司和运营总部各级的审批流程需要，并减少流程总体审批节点数量
CHM2	目前变更流程没有明确的分级准则	优化变更管理的分类、分级、分流审批流程
CHM3	目前审批流程过于繁琐，各级部门均采用串行审批的流程，造成变更审批时间延长	改进审批流程和规范，展开专题研究，对于有关岗位实行并联审批，节省审批时间
CHM4	系统建设项目组自行负责变更测试，运维团队无法把握测试效果和准确把握变更影响，造成安全风险和隐患	建立规范，在项目测试阶段，运维人员参与测试评估工作，保证变更成功有效，控制变更风险。建议项目建设部门在制定项目方案时，同时计划IT运维服务部相关测试人员参与项目测试的时间节点及工作量要求
CHM5	重大变更集体讨论变更对业务连续性、可用性、容量、安全等方面的风险的机制还有待改善	建立变更委员会（CAB），以便讨论重大变更的审批；同时建立紧急变更委员会（ECAB)
CHM6	尚未制定成文的标准变更管理流程，一些可以预授权审批的变更走一般变更流程，造成多走一些不必要的审批节点，延长审批时间	制定标准变更审批流程和实施规范                     ITSS培训
CHM7	用户需求评审规范有待改进	建立用户需求管理规范（SLR），建立用户需求评审委员会制度，以便准确把握用户需求，对业务及时支撑又不会盲目开发新功能
CHM8	目前变更管理无绩效考核指标	KPI设定：变更成功率、被拒变更的数量、未授权的变更数量、按时完成的变更百分比、变更次生事故数量、紧急变更数量、变更数量、失败变更的数量

2.7.7      日常运维管理

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

本帖关键字：ITSS

20151118 淡然

续上

2.7.6.1.3       考核关键指标

目前一般变更流程暂时没有定义相应的绩效考核指标。

2.7.6.1.4       已有优势

经过问卷、访谈和调查分析，可以发现某公司现有的变更管理流程存在以下的优势：                 ITSS考试

Ø  清晰定义服务和架构变更的范围，并形成文件；

Ø  变更请求被批准和检查，并以受控方式实施；

Ø  定义了变更实施的日期；

Ø  具备与变更相关方沟通的机制；

Ø  变更实施后，评审了变更是否成功。

2.7.6.1.5       需求与期望   

1.        随着业务的发展，IT相关的需求也越来越复杂。目前尚没有清晰的流程来界定新需求和变更的范围。因此有必要对变更管理进分类，并设置一系列的流程和职责，保证变更需求可以成功的转化映射到应用系统的建设和维护上。

2.        2012年某公司将新上线30多个系统，这些新系统及项目的启动、测试、上线、推广等全过程都需要运维服务的支持，因系统涉及服务面广、用户量大，随之带来大量的服务请求和变更，如何优化当前的服务资源，高效支持更多的服务请求是运维服务部需要着重解决的挑战之一。经需求调研访谈了解到：要做好IT运维服务的容量管理，对升级改造做决策，这样调配资源就有依据。

2.7.6.1.6       流程评估

通过问卷，我们得出目前的变更流程的成熟度如下图：

图 39变更管理成熟度

由成熟度图可以看出，虽然有成文的变更管理文档，但是对变更管理要更多的体现在对变更的审核上面，但是对于变更的过程控制等后续的活动并没有过多的考虑，所以在质量控制、管理信息和外部整合度都稍微差一些。主要体现在以下方面：

Ø  没有定义一个规范用于触发并登记变更过程；

Ø  没有定期做完整的变更管理报告；

Ø  仅对重大变更进行记录和评估，分析范围需要进一步拓展；                            ITSS认证

Ø  没有对变更进行客户满意度调查。

2.7.6.2              差距分析及改进建议

编号	现状	改进建议
CHM1	目前OA和变更流程无接口，造成OA流程审批完成后还需要在ITSM的变更流程中再次流转审批	开发ITSM和OA相应功能，将OA与ITSM平台审批节点进行联动，满足总公司和运营总部各级的审批流程需要，并减少流程总体审批节点数量
CHM2	目前变更流程没有明确的分级准则	优化变更管理的分类、分级、分流审批流程
CHM3	目前审批流程过于繁琐，各级部门均采用串行审批的流程，造成变更审批时间延长	改进审批流程和规范，展开专题研究，对于有关岗位实行并联审批，节省审批时间
CHM4	系统建设项目组自行负责变更测试，运维团队无法把握测试效果和准确把握变更影响，造成安全风险和隐患	建立规范，在项目测试阶段，运维人员参与测试评估工作，保证变更成功有效，控制变更风险。建议项目建设部门在制定项目方案时，同时计划IT运维服务部相关测试人员参与项目测试的时间节点及工作量要求
CHM5	重大变更集体讨论变更对业务连续性、可用性、容量、安全等方面的风险的机制还有待改善	建立变更委员会（CAB），以便讨论重大变更的审批；同时建立紧急变更委员会（ECAB)
CHM6	尚未制定成文的标准变更管理流程，一些可以预授权审批的变更走一般变更流程，造成多走一些不必要的审批节点，延长审批时间	制定标准变更审批流程和实施规范                     ITSS培训
CHM7	用户需求评审规范有待改进	建立用户需求管理规范（SLR），建立用户需求评审委员会制度，以便准确把握用户需求，对业务及时支撑又不会盲目开发新功能
CHM8	目前变更管理无绩效考核指标	KPI设定：变更成功率、被拒变更的数量、未授权的变更数量、按时完成的变更百分比、变更次生事故数量、紧急变更数量、变更数量、失败变更的数量

2.7.7      日常运维管理

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

本帖关键字：ITSS