ISO20000国际标准体系是业界公认的IT服务管理标准,通过了ISO20000认证被行业认为其提供的IT服务具有相当的质量保证。本次项目,我们将会在调整人员岗位和职责、实施八大ITIL流程、实施 SM平台工具的前提下,将IT运维服务的各方面要素都统一到遵循ISO20000标准而建立起来的IT服务管理体系的框架之下,以便让这些要素协调发展,整体上提高IT运维的成熟度,从根本上保证IT运维工作的安全稳定、效率和质量。
本期项目的最终目标是建立IT服务管理体系并通过ISO20000认证,因此本期项目的目标除了需要满足各级领导和公司战略上提到的管理目标外,还要符合ISO20000体系规定的要求。
除此之外,对照ISO20000体系的要求,我们将按照标准指引,建立发布管理、可用性管理、容量管理、IT财务管理、服务报告、供应商管理、业务关系管理、安全管理共8个流程的初步框架,达到ISO20000合规性标准,同时也为将来这些流程在未来的5年内逐步实施打好理论上的基础。
Ø 本项目IT服务管理体系文件整合为一套文件体系,分为四个层次。四个层次为:管理手册(第一层)、管理规定和管理办法(第二层)、实施细则和操作手册等(第三层)、表单模板和运行记录等(第四层)。计划中需要完善的具体文档清单请见本文2.4。
在组织和人员方面,我们将从组织岗位的梳理、人员能力模型的建立及人员配备标准等方面来着手改进,组织方面将采用与各IT运维管理流程逐一建立映射的办法来重新清理岗位责任,通过建立通用的人员能力评价模型来保证IT运维人力资源的素质,并通过摸底以往岗位工作负荷的历史数据来建立岗位人员配备模型的办法,建立岗位人员配比标准。具体改进方案如下:
编号
| | | | | |
| | 目前某公司处于IT建设高峰期,新系统建设后转交运维时没有很好地考虑运维人员的配备问题,造成运维压力增加 | 策划和实施服务管理
ISO20000 4.1
策划服务管理,管理角色和职责的框架 | 参考新系统建设时项目规划中制定好的运维人员配备要求。新系统建设和移交时参考该方法向HR申请相应的资源 | |
| | 流程活动在流转到各个职能部门时有时会由于分工不够明确造成工作难以开展,影响效率。例如:当前的应用系统尚未完善备份管理员制度 | 策划和实施服务管理
ISO20000 4.1
策划服务管理,服务提供方的服务管理范围 | 指导梳理各岗位工作职责,尤其需要梳理新系统建设转交运维各个关键流程节点的职责 ITSS认证 | |
| | | 策划和实施服务管理
ISO20000 4.1
策划服务管理,管理角色和职责的框架 | | |
| | | 管理体系要求
ISO20000 3.2
编制并保持每个过程或过程集合的策略、计划和定义 | 按照ISO20000标准要求建立文档和记录管理规范 | |
| | IT服务管理体系的策划、运行方面具有一定的成熟度,检查、改进的机制尚待完善 | 监视、测量和评审
ISO20000 4.3
服务提供方应提供文件和记录,以确保有效地策划、运维和控制服务管理 | 建立PDCA持续改进机制,保证组织不断提升IT服务质量 | |
| | | | | |
| | 内部组织部门之间职责待进一步梳理,对于某些中间服务(比如: 系统错误引致的应用错误,桌面级网络端口损坏等)无法正确的分配事件 | 策划和实施服务管理
ISO20000 4.1
策划服务管理,管理角色和职责的框架 | 梳理组织部门之间的职责和关系,清晰定位中间服务职责 | |
| | 因为服务台对应用系统的支持能力不足,无法正确通过客户的描述记录问题,导致客户会直接打电话到应用运维部门请求协助 | 管理体系要求
ISO20000 3.3
能力、意识和培训 | 加强服务台工作水平,严格要求服务台绝对不能允许直接让客户联系二线工程师寻求帮助 | |
| | 二线的非运维有关的会议和其他非运维工作太多,严重干扰运维水平 | 策划和实施服务管理
ISO20000 4.1
策划服务管理,管理角色和职责的框架 | 梳理定义运维二线工作规范,保证二线在运维时间内不会被非运维事件所干扰 | |
| | 运维部门直接参与新上线系统的测试过程,而且运维部门也没有太多人手参与新上线系统的测试 | 策划和实施服务管理
ISO20000 4.1
策划服务管理,管理角色和职责的框架 | | |
| | 在总公司的绩效考核中,整个运维工作的KPI占5分,而配合一个新项目的KPI就有2.5分 | 策划和实施服务管理
ISO20000 4.1
策划服务管理,管理角色和职责的框架 | 加大运维工作的KPI分值,提高运维人员对本职工作的积极性,保证运维工作的顺利进行 ITSS培训 | |
| | 当应用管理部门寻求供应商支持时,无法得到供应商的积极响应 | | | |
| | | | | |
| | 目前外包供应商仅仅只是在硬件的更换上提供服务。没有响应更高层次的技术服务。而且重大故障时刻会由于假日的原因而拒绝。例如:脚本编写服务,应用及网络排错服务 | | 在UC中明确指出供应商服务范围,并定义响应时间及服务内容 | |