第4章 IT服务规划设计
4.1 概述
规划设计处于整个IT服务生命周期中的前端,可以帮助IT服务供方了解客户的需求,并对其进行全面的需求分析,然后通过对服务要素(包括人员、资源、技术和过程)、服务模式和服务方案的具体设计,最终形成服务级别协议(Service Level Agreement, SLA),包括服务的内容、连续性、可用性、服务能力和服务费用等。
如果未进行有效的规划设计,那么仓促而就的IT服务难以满足客户的真正需求,很可能造成客户满意度低下、IT服务可用性低、预算超支或IT系统功能丧失。
规划设计的范围不仅包括新的服务,还包括服务连续性保障、服务水平的满足和对标准、规则的遵从,以及在服务生命周期过程中为了保持和增加服务价值所做的必要变更。
规划设计的主要目的在于:
(1)设计满足业务需求的IT服务。
(2)设计SLA、测量方法和指标。
(3)设计服务过程及其控制方法。
(4)规划服务组织架构、人员编制、岗位及任职要求。
(5)识别风险,并定义风险控制措施和机制。
(6)识别和规划支持服务所需的技术及资源。
(7)评估IT服务成本,制订服务预算,控制服务成本。
(8)制订服务质量管理计划,以全面提高IT服务质量。
优秀的规划设计会为IT运维服务、数据处理和存储服务及运营服务带来如下益处。
(1)减少总体拥有成本(Total Cost of Ownership, TCO):通过对人员、过程、技术和资源的规划与设计,可实现有效的服务成本控制,并在成本上做出有效的分析。如果没有实现规划设计,那么突发的灾难、意外的资源超标都会造成不可挽回的经济损失。
(2)使新的或变更的服务的实施更便利:在传统的组织中,一旦有了新的服务需求,许多重担便压在系统规划与管理师身上,系统规划与管理师除了对项目本身负责外,还需要大量的时间去分析与新的或变更的服务相关事宜,包括与其他组织的沟通等。有效的规划设计方法将指导系统规划与管理师从更全面的角度去思考这些规划层面的事宜,提升效率。
(3)改进服务流程:规划设计模块中提供了有效的服务过程设计建议,为服务过程的改进奠定了基础。
(4)服务执行更有效:缘于有效的整体规划设计,服务的执行更明确,也意味着服务执行力更强。
(5)提升IT服务管理:指标不仅让服务的执行更明确,对于管理者来说,绩效考核也要有依据。这里不仅包括对人员的管理规划,还包括对过程、技术和资源的管理规划与设计。
(6)服务管理更有效:有了具体的方向和指导,服务管理除了具有明确的目标性外,还具备了可审计、可追溯、可改进、可视性等多重效率性提升。
4.2 IT服务规划设计活动
4.2.1 规划设计的活动
规划设计流程中的主要活动包括:服务需求识别、服务目录设计、服务方案设计(含服务模式设计、服务级别设计、人员要素设计、过程要素设计、技术要素设计、资源要素设计)、服务成本评估和服务级别协议设计。
整个规划设计流程中的各项主要活动如图4.1所示。规划设计从服务需求出发,终点为设计出符合业务需求和成果的服务方案。在需求阶段,客户结合服务目录的定义和自身要求,提出服务级别需求,服务供方根据服务需求,进行服务模式设计、服务级别设计、服务要素设计等关键活动,同时兼顾成本控制和定价,最终形成服务级别协议、运营级别协议和支持合同。
4.2.2 关健成功因素
要确保规划设计的有效实施,需充分考虑如下内容:
(1)确保规划设计考虑全面,使规划设计包含IT服务的所有活动及与业务相关的接口。
(2)当服务变更或补充规划设计的任一独立元素时,都要综合考虑有关职能、管理和运营等层面的问题。
(3)明确重点,充分沟通。
(4)策划、实施、检查和改进(Plan-Do-Check-Act, PDCA)。
规划设计是一个不断循环的过程,服务供方在IT服务规划设计过程中应对服务进行整体策划,提供必要的人员、资源、技术和过程支持并实施服务内容,保证交付质量满足SLA的要求,对IT服务规划设计的过程和结果进行监视、测量、分析和评审,并实施改进,如表4.1所示。
表4.1 规划设计之PDCA
目的 | 内容 | |
---|---|---|
策划 | 对规划设计过程进行整体策划,提供必要的资源支持 | 根据业务定位和能力,策划针对特定服务对象的服务内容与安全要求,设定服务目标、服务模式、服务目录;对服务资源进行规划,建立相适应的指标体系和服务保障体系;策划如何管理、审核并改进规划设计内容和结果(包括SLA、OLA和UC),并建立内部审核评估机制 |
实施 | 设计服务方案,保证交付产品的质量满足服务需求 | 与客户就服务需求达成共识,明确SLA或质量要求;按照服务需求、标准和法律法规的标注进行规划设计,确保规划设计的过程可追溯和结果可计量;提交满足服务需求的交付物 |
检查 | 检查规划设计的结果是否符合服务需求和质量目标 | 按进度安排评审规划设计过程交付物及相关管理体系,以确保其适宜性和有效性 |
改进 | 改进规划设计过程和交付方案的不足,以持续提升服务质量 | 不断总结经验和教训,修改和优化规划设计过程和服务目录;对不符合策划要求的行为进行总结分析;对未达成的服务需求的指标进行调查分析;根据分析结果确定改进措施,制订服务改进计划 |
在进行规划设计时,只有充分考虑上述内容,才会看到成效——客户满意度的不断提升,IT服务稳定、实用性强,IT服务与业务之间便能建立真正的良性循环。
4.3 服务目录管理
服务目录是梳理服务产品和管理客户期望的重要工具,是服务供方为客户提供的IT服务集中式的信息来源,以确保业务领域可以准确地看到可用的IT服务及服务的细节和状态,如图4.2所示。
服务目录是公开的,不论是客户还是服务供方都应该能方便地查阅这些资料,在某些场合下甚至会由一个专门的内部网站来完成这项任务。服务目录一般会利用一些来自质量控制系统的信息和文档(这些质量信息需要进行定期回顾),及时做出调整,以适应客户或者业务的具体需求。
服务目录定义了服务供方所提供服务的全部种类和服务目标,但是在很多情况下,由于涉及的内容很可能已经在其他文档(如SLA)中被提及,为了避免文档的重复,服务目录往往不再单独列出。
虽然不同的服务供方的服务目录及相关文档和方式会有所不同,但是有一个大家都应遵守的原则,即服务目录要避免信息处理过程中产生的冗余,要得到妥善管理,而且方便查阅。
服务目录主要有两种:业务服务目录和技术服务目录。业务服务目录包含提交给客户的所有IT服务细节,并将其关联到依靠IT服务的业务单元和业务流程,是客户视角的服务目录。技术服务目录包含提交给客户的所有IT服务细节,并将其关联到提供给业务的必需的支持服务、共享服务、组件和配置项,支撑业务服务目录,是技术视角的服务目录,通常客户不关注技术服务目录。
4.3.1 设计服务目录的目的
服务目录设计的目的是为所有商定的服务提供单一、连贯的信息来源,并且确保所有获准使用相关服务的人能够知道这些信息。服务目录管理中的核心信息的主要输入,来自服务组合和通过业务关系管理(BRM)或服务级别管理(SLM)流程了解到的业务情况。
促使IT服务目录制订的原因有很多,其中最重要的一点是,它能促使IT部门与客户之间建立起一种长期稳固的关系。实施一套正规IT服务目录时,所获取的总体效益会随部门的不同而不同,潜在效益应包括:
(1)促进部门同外部及内部沟通。
(2)对业务要求和挑战有更好的理解。
(3)能有效地把适当的成本分配给某个具体的业务部门、单位。
(4)服务供方能积极、有效地改变终端用户的消费量及其消费行为。
(5)增强客户的需求意识,提高IT服务供方的市场可视性。
(6)提高IT服务和流程的效率。
(7)把IT资源重新分派到核心业务系统中。
(8)降低服务提供的出错率。
(9)降低IT部门的操作成本。
4.3.2 服务目录设计活动
设计一套巧妙而有效的IT服务目录需经过深思熟虑,因为这样可以确定服务目录应当包含哪些服务及特征,并分出优先级。IT服务目录的设计一般按照如下步骤进行,这都需要与服务供方的总目标和服务能力相一致。
(1)确定小组成员:参与人员至少应包括需方业务代表、系统规划与管理师、IT服务工程师,以确保制订服务目录时的视角是全面的。
(2)列举服务清单:小组应当列出一个包括所有IT服务在内的清单,不管它们是否真的被包括在现有的IT服务内。
(3)服务分类与编码:对服务清单中的内容,按服务对象的技术维度或服务性质维度进行分类,如硬件、软件、环境、响应支持、例行操作、优化改善、调研评估等。
(4)服务项详细描述:详细描述各服务项包括的内容、价值、目标、服务级别指标、技术实现方法等。
(5)评审并发布服务目录:服务目录在经修改、评审、定稿后,就可正式在供方组织内部发布,作为服务交付和服务管理的基准。
(6)完善服务目录:根据客户服务需求或行业要求,继续改进服务目录,包括服务时间、服务方式、服务人员、服务定价等,并保持与需方服务需求或供方服务能力的一致性。
在服务目录使用的过程中,如果服务需方的反馈结果与服务目录有差别,可以有针对性地对服务进行选择性修改,从而制订正规的SLA。
不同的组织针对IT服务目录的制订成本、复杂性及实施难度会有所不同,这完全取决于最终存档的服务目录的服务项数量。因此,只有在服务目录中的服务项逐一实施并被客户认同之后,服务目录的条款才能最终确定。
服务目录包含众多条款和变量,可以为IT组织和部门创造更多、更有意义的附加价值。以下是服务目录中可能包含的一些变量及促进因素:
(1)对服务进行统一收费(如针对每个服务传递者、人员或业务单位)。
(2)确定服务使用费或基于服务能力的收费额(如根据服务呼叫数量来确定费用情况)。
(3)增加循环过程中服务消费的数量或单元。
(4)确定相似服务提供时的优先次序。
(5)获取新的服务或添加附加客户的流程及程序。
4.3.3 关键成功因素
(1)确保向需方提供的每个服务都是独立的,而不是某个大服务的一部分。
(2)可以根据客户的需求和内部情况,对服务内容进行控制和衡量。
(3)服务成本可以根据客户需求的不同而进行改变。
(4)客户容易认可和感受对服务成本有较大影响的服务。
4.3.4 参考实例
参考实例如表4.2所示。
表4.2 参考实例
服务代码 | 服务名称 | 服务内容 | 服务描述 | 服务方式 | 服务时间 | 服务级别 |
4020101 | 网络设备应急响应服务 | 包括故障排查服务、设备维修服务、重大事件保障服务。通过该服务能有效地诊断并发现故障情况,及时定位故障位置,对故障进行处理,直到故障解决,快速有效地恢复网络系统的正常运行 | 故障排查:可提供各类网络设备的故障排查及处理解决服务 | 现场+远程 | 5X8 7X9 7X24 | 响应时间10/30分钟,到达现场时间 2/4/8/24小时,故障解决时间4/8/24/48小时 |
4020102 | 设备更换:可提供各类网络设备及其配件更换服务 | 现场 | 5X8 | 响应时间10/30分钟,到达现场时间2/4/8/24小时,故障解决时间4/8/24/48小时 | ||
4020103 | 重大事件保障:可提供警卫任务、节假日或其他重大任务时,指派网络系统运维服务工程师到客户指定现场进行值守,保证重大事件活动期间网络系统的正常运行 | 现场 | 5X8 7X9 7X24 | 响应时间10/30分钟,到达现场时间2/4/8/24小时,故障解决时间4/8/24/48小时 | ||
4020104 | 网络设备例行维护服务 | 包括日常工作值守服务、巡检服务、清洁服务。通过该服务能有效预防故障的发生,降低故障发生概率,大幅度提升网络正常稳定运行的平均时间,提供更可靠、更及时的保障,延长设备使用寿命,节约资源成本 | 巡检:可提供网络类设务告警信息及日志查询和诊断、系统配置参数校对、风扇运行状态检查、设名运行状态检查、基础环境温湿度检查等服务;巡检过程中发现有故障设备,可及时进行备件更换恢复业务 | 现场+远程 | 5X8 | 响应时间10/30分钟,到达现场时间2/4/8/24小时,故障解决时间4/8/24/48小时 |
4020105 | 实时监测:可提供网络设备安放基础环境温湿度等指标、设备运行状态指标传输网络拓扑连通性、出口带宽、数据转发速率设备温度、设备硬件资源占用情况等性能指标的实时监测服务 | 驻场+远程 | 5X8 7X9 7X24 | 响应时间10/30分钟,到达现场时间2/4/8/24小时,故障解决时间4/8/24/48小时 | ||
4020106 | 清洁保养:各类网络设备的清洁及养护服务 | 现场 | 5X8 | 响应时间10/30分钟,到达现场时间2/4/8/24小时,故障解决时间4/8/24/48小时 | ||
4020107 | 网络设备优化改善服务 | 包括隐患排查服务、性能优化服务通过该服务能升级设备软件系统配置功能,精简配置有效发挥网络系统的最佳性能 | 系统升级:可提供各类网络设备的系统软件版本升级服务 | 现场+远程 | 5X8 | 响应时间10/30分钟,到达现场时间2/4/8/24小时,故障解决时间4/8/24/48小时 |
4020108 | 性能调优可提供各类网络设备的系统配置优化服务 | 现场+远程 | 5X8 | 响应时间10/30分钟,到达现场时间2/4/8/24小时,故障解决时间4/8/24/48小时 |
4.4 服务级别协议
4.4.1 服务级别协议介绍
服务级别协议(Service Level Agreement, SLA)是在一定成本控制下,为保障IT服务的性能和可靠性,服务供方与客户间定义的一种双方认可的协定。
一个完整的SLA也是一个合法的文档,包括涉及的当事人、协定条款(包含应用程序和支持的服务)、违约的处罚、费用和仲裁机构、政策、修改条款、报告形式和双方的义务等。同样,服务供方可以对客户在工作负荷和资源使用方面进行规定。
运营级别协议(Operational Level Agreement, OLA)是与某个内部IT部门就某项IT服务所签订的后台协议,OLA在IT内部定义了所有参与方的责任,并将这些参与方联合在一起提供某项特别服务。各方就所提供服务的质量和数量等级达成一致。例如,如果SLA中包含了一个针对恢复某个具有高优先事件的总目标,则OLA中就应该包括针对整个支持链的每个环节的具体目标(如针对服务台响应呼叫、进行事件升级的目标,针对网络支持人员启动调查和解决网络相关事件的目标等)。OLA支持IT部门提供各种服务。
支持合同(Underpinning Contract, UC)是指组织与外部服务供应商之间签订的有关服务实施的正式合同,是SLA中的重要部分。如果IT服务不由内部部门提供,而由外部服务供应商提供,那么这一环节相当重要,因为SLA只是内部或对客户的协议,不具有法律效力,UC则是与外部服务供应商或组织签订的合同,是正规的、具备法律效力的协议。从内容上看,UC主要由依据SLA的内容加上法律条文中的责任、权利和义务构成。
4.4.2 服务级别协议内容
服务级别协议框架如表4.3所示。
表4.3 服务级别协议框架
要素 | 说明和示例 |
---|---|
需方 | 需方单位名称 |
供方 | 供方单位名称 |
第三方 | 第三方单位名称 |
项目名称 | IT服务项目全称 |
生效时间 | 协议生效时间 |
终止时间 | 协议终止时间 |
服务简介 | 提供项目的背景,项目的目标和项目的重要性等 |
服务范围 | 如设备清单等 |
服务时间 | 约定可提供服务的时间,需明确例外时间段以及对例外时间段提供服务的协商方式,如5X8、7X24等 |
服务受理渠道 | 客服热线电话,客服邮箱、网上问题提交地址等;如有必要可增加非工作时间服务通道及方式等 |
投诉渠道 | 投诉热线等 |
服务交付计划 | 启动会时间、巡检时间、总结时间等 |
服务交付方式 | 现场交付要求,远程交付要求等 |
服务交付内容 | 例行操作、响应支持、优化完善、调研评估等具体服务交付内容 |
供方人员 | 需明确参与服务的人员岗位、职责、姓名和联系方式等,如客户经理、系统规划与管理师、信息技术支持工程师等 |
需方接口 | 需明确接口服务的人员岗位、职责、姓名和联系方式等,如系统规划与管理师、责任工程师等 |
第三方接口 | 需明确接口服务的人员岗位、职责、姓名和联系方式等,如系统规划与管理师、责任工程师等 |
供方服务流程 | 故障申报流程、巡检流程、升级上报流程等 |
第三方服务流程 | 第三方支持流程等 |
服务交付成果 | 需明确服务阶段中需要提交的各类交付成果等,如故障报告、总结报告、巡检记录等 |
保密要求 | 相关信息严禁透露,服务人员应签署保密协议等要求 |
服务考核要求 | 服务质量考核的时间周期、考核的关键要素、考核好坏对应的奖惩条款等 |
协议变更控制 | 协议内容变更的流程和要求等 |
各方代表签字 | 供需双方代表签字,如需要第三方签字,可增加签字方;需提供姓名、职务和签署时间等 |
参考示例如下。
本协议经过甲方: 乙方: 友好协商达成。 | |||
本协议涉及由乙方向甲方提供和支持的服务(服务名称)。 | |||
本协议自 年 月 日起到 年 月 日止,有效期为 年。 | |||
服务描述 | XXX服务包括…(全面描述服务包括业务职能、功能、性能、容量和其他相关信息,用于描述该服务及其规模等) | ||
服务时间 | 描述议定的服务提供时间方面的描述(如7X24X365或周一至周五09:00~17:30等,如需考虑节假日等根据应用环境适当描述) | ||
服务可用性 | 议定服务时间内的可用性目标,通常以百分比表示,应规定计算周期、计算方法,通常采取统计服务不可用数据来计算不可用性,再得出可用性 | ||
服务可靠性 | 议定计算周期内可容忍的服务中断次数或平均故障间隔时间等,应定义“服务中断”并描述如何对此监控和记录 | ||
服务支持 | 客户支持 | 评价指标 | 特殊情况说明 |
描述如何联系服务台、服务台可用时间、可用于提供支持的时间及在这些时间外要获得帮助应该怎么做,定义 “响应”的具体方式(如电话反馈、发送响应确认信息等) | 议定可接受的响应时间性指标(如5分钟内响应,响应及时率达到90%, 2小时内到达现场等) | 议定应考虑特殊处理的异常情况时,如恶劣天气、需要借助第三方支持等,应做如何调整 | |
投诉渠道 | 描述投诉受理方式(如热线、邮件、传真等)、投诉升级流程等 | ||
服务交付 | 描述服务交付方式(如现场交付、远程交付等)、交付地点(交付地点的详细信息)、交付物(如软件、硬件、文档等) | ||
服务费用 | 描述收费期、引入的收费方案文档、收费公式、发票开具程序和支付条件等详细信息 | ||
责任和义务 | 描述服务各阶段双方各自应承担的责任、各自责任限制(如甲过错导致损失不应乙方承担责任)、可免除责任(如不可抗力)、应履行的义务等 | ||
补偿 | 描述若服务目标未达到,将支付或返还的经济赔偿的详细信息 | ||
服务报告 | 描述服务报告内应呈报的内容、报送时间、报送频率、报送范围和分发方式等 | ||
审查 | 描述对SLA和相关服务目标进行审查、审查频率、修改方法和时间,可能涉及时间、对象、容量等 | ||
保密条款 | 定义保密信息、非保密信息,议定双方保密义务、保密条款的有效期限等 | ||
备注 | 备注其他需要说明的信息 | ||
本协议每年将进行审查,如需变更应遵循本协议约定的变更管理流程。 签署人: 姓名: 职位: 日期: 年 月 日 姓名: 职位: 日期: 年 月 日 |
4.5 服务需求识别
考虑提供一个新的IT服务时,首先需要了解客户对于IT服务的需求。那么,站在客户的角度来看,他们对于IT服务究竟会有什么需求呢?通过对客户业务和IT服务需求的了解,可以划分为可用性需求、连续性需求、能力需求、信息安全需求和价格需求;然后对IT服务进行具体的设计,包括连续性设计、可用性设计、能力设计、收费模式和定价、IT服务报告设计,最终形成IT服务方案。图4.3描述了IT服务需求与规划设计的关系。
4.5.1 服务需求识别的目的
(1)了解客户的基本需求,分析潜在客户的不同需求,为IT服务方案设计打下基础。
(2)了解客户对系统可用性和连续性的需求。
(3)进行合理的IT服务资源配置。
(4)为预算IT服务成本、设计定价和收费模式奠定基础。
4.5.2 服务湍求识别的活动
-
IT服务可用性需求识别
在进行可用性需求识别的过程中,要将客户的业务需求转化为IT可用性需求,内容如下。
(1)IT服务不可用对业务的影响,即客户可以承受多长的停机时间。
(2)从业务角度分析,IT服务不可用(或质量下降)时造成的成本损失。
在SLA中明确规定可用性要求,并传递下去,如涉及运营级别协议或支持合同,需要将相关的可用性要求传递下去,以保证客户的可用性需求被满足,如表4.4所示。
表4.4 可用性指标(示例)可用性指标 标杆 备注 平均无故障时间 5.0小时 平均无故障时间=系统运行时间/系统在运行时间的故障次数
平均无故障时间越长,系统的可靠性越高平均故障修复时间 0.5小时 平均故障修复时间=系统故障耗时/故障次数
平均故障修复时间越短,表示易恢复性越好平均故障间隔 5.5小时 平均故障间隔=平均无故障时间十平均故障修复时间
平均故障间隔越长,表示可靠性越高场景1: 在某电子交易平台的IT服务规划设计过程中,客户对于该平台的运行时间有明确的要求,要求7X24小时不间断运行,任何短暂的系统宅机都会给客户业务带来很大的影响和商业损失。
-
平均无故障时间(Mean Time Between Failures, MTBF):从一次事件中恢复到下一次事件发生之间的平均间隔时间,也称为正常运行时间。该指标与IT服务的可靠性有关。
-
平均修复时间(Mean Time To Repair, MTTR):故障发生和IT服务恢复之间的平均时间,是检测时间与解决时间之和,也称为宕机时间。该指标与IT服务的可恢复性和可服务性相关。
-
平均系统事件间隔时间(Mean Time Between System Incidents, MTBSI):两次相邻事件之间的间隔时间。平均系统事件间隔时间(MTBSI)等于平均修复时间(MTTR)与平均无故障时间(MTBF)之和。
-
-
业务连续性需求识别
组织业务是由多种业务流程和信息系统的支撑组成的,信息系统的连续可用是业务作为整体得以存活的关键。在系统运行过程中,灾难发生比突发事件更严重,因此必须考虑信息系统的连续性需求,并编制灾难恢复计划,以应对灾难发生。
在进行连续性需求识别的过程中,可以通过风险评估找出那些潜在的威胁,然后引入风险降低的措施或恢复等手段达成这个目的,同时为了确保其有效性,必须持续维护恢复能力。
进行风险评估可以确定可能造成信息系统中断、灾难的潜在威胁,包括具有负面影响的事件、存在安全隐患的环境因素等。风险评估可以预测这些威胁可能造成的损失, 并且评估控制措施是否能有效防止威胁的发生,是否能有效防止威胁发生后造成的损失。表4.5为某信息系统的风险评估表。
表4.5 风险评估表(示例)风险 服务器硬件 网络设备 系统软件 应用软件 服务 断电 高 高 - - - 火灾 高 高 - - - 水灾 中 中 - - - 人为错误 - - - 中 - 无法登录 - - - 低 高 病毒攻击 - 高 高 - - -
IT服务能力需求识别
IT服务能力是指保证信息系统的性能和IT服务能力可以以最及时、最有效的方式满足服务级别协议(SLA)中所有当前和未来的需求。IT服务能力需求分析要对客户的业务需求、客户现状和信息系统有清晰的了解,保证所有对能力的需求都以合理的成本加以满足,尤其是对于未来能力需求的把握,从某种程度上来说,这是能力管理对于组织的竞争力产生积极作用的主要体现。 -
信息安全需求识别
越来越多的组织对于IT服务的需求会包含信息安全要求。通常来看,信息安全需求主要包括如下3方面。
(1)机密性(或保密性):信息仅可以被授权的人访问和使用。
(2)完整性:保护信息防止未授权的修改。
(3)可用性:在协议规定的时间内,信息都应该是可获取且可用的。这些信息安全需求的优先级和重要性一般由信息系统的数据和其包含的业务内容所决定。 -
价格需求识别
在考虑IT服务需求和相应解决方案时,对成本和价格的考虑是必不可少的一个环节。在价格问题上,双方往往会进行反复沟通和确认。因此,在IT服务需求阶段,对IT服务内容确认后,估算IT服务成本并进行IT服务定价会变得尤为重要。从IT服务供方的角度来看,IT服务成本主要包括如下几部分:设备成本、系统与应用、软件成本、人力成本、第三方支持成本、管理成本和其他成本等。 -
IT服务报告需求识别
为了有效沟通和制定决策,在IT服务需求识别过程中需要对IT服务过程中提供的各类IT服务报告的需求进行识别。
IT服务报告需求识别要素包括:
(1)需要对客户的具体业务需求和局部情况进行分析和考虑。
(2)在进行服务报告设计时,要明确服务报告产生的前提条件和服务报告内容的要素。不同环境下的典型服务报告包括如下内容。
(1)按照既定服务水平目标衡量的服务绩效。
(2)主要工作的绩效报告,如定期的服务概况、事件、变更汇报。
(3)工作的特点和工作量信息,如突发事件、问题、变更和任务、分类、位置、客户、季节性趋势、优先级的混合以及要求帮助的数量。
(4)某段时间的趋势信息,如一天、一周、一个月或其他长度的一段时间。(5)报告中要包含未来计划工作的信息。
4.5.3 关他成功因素
(1)明确服务范围、服务内容和服务目标。
(2)识别客户对于可用性、连续性、信息安全、服务能力、价格和服务报告方面的需求,以便对规划设计进行规划。
(3)与需方进行充分的沟通,全面了解明示的和隐含的服务需求。
4.6 服务方案设计
在识别出需方的IT服务需求后,就可以开始设计相应的IT服务方案,IT服务方案的设计需求同时考虑服务模式的选择,服务级别的设定和人员、过程、技术、资源要素的管理策略。IT服务方案设计是整个规划设计阶段的核心工作,系统规划与管理师需要综合考虑IT服务供需双方以及第三方的能力和要求,设计出让各方满意的IT服务方案。
4.6.1 服务模式设定
根据用户实际需求,IT服务供方应提供各类不同模式的IT服务,结合IT服务需求分析的结果,对IT服务模式进行分类设计,根据客户需求和IT服务内容,做到随需而变。
目前,常见的IT服务模式划分方法如下:
⓵是将IT服务模式划分为远程支持(电话或邮件)、现场服务(上门技术支持、常驻现场)、集中监控等多种技术支持服务模式,如表4.6所示;
⓶是将IT服务模式分为IT外包(ITO)、业务流程外包(BPO)和知识流程外包(KPO)等外包服务和新兴服务模式,如Saas (Software as a Service)、云计算 (Cloud Computing)等。
表4.6 IT服务模式的分类(示例)
分类 | IT服务内容 |
---|---|
远程支持 | 通过电话、远程登录,在客户配合下进行IT服务请求的处理和系统故障的排除,包括呼叫中心、远程帮助台等技术支持 |
现场服务 | (上门技术支持) 远程技术支持不能成功而必须现场服务时,提供上门的技术支持,包括到客户现场进行巡检工作 |
现场服务(长驻现场) | 指派专人常驻客户现场,和客户IT人员一起工作,随时响应客户服务请求,处理系统故障 |
集中监控 | 通过特定的监控平台,对客户信息系统进行实时监控,如发生任何异常,及时介入处理或告知客户 |
-
IT服务模式设计的目的
IT服务模式设计的目的是为了更好地满足客户需求,提升客户满意度。 -
IT服务模式设计的活动
IT服务模式的设计与客户需求的匹配。在IT服务模式的设计过程中,需要充分考虑IT服务需求识别中客户对于可用性、连续性、安全、能力等方面的需求。
例如,客户对于系统的可用性需求是每天24小时不间断运行,提供的IT服务模式就可以选择常驻现场的服务。当然,需要考虑的因素还有IT服务价格等方面。
(1)根据客户需求和IT服务供方的自身业务能力,对客户服务模式进行设计,主要包括IT服务的可用性、连续性设计。
(2)可用性设计是IT服务模式设计的重要内容之一,它确保IT服务的可用性级别可以得到满足。
(3)连续性设计,一般会考虑到风险控制和灾难应对措施。
(4)针对设计的IT服务模式与客户进行讨论、改进。(5)针对不同的IT服务模式进行匹配。
-
关键成功因素
(1)选择的IT服务模式与客户需求一致。
(2)跟踪客户需求的变化,及时调整IT服务模式。
(3)IT服务供方具备同时提供多种IT服务模式的能力。
(4)IT服务供方人员配置和资源配置与IT服务模式匹配。
4.6.2 服分级别设定
服务级别(Service Level)是指服务供方与客户就服务的质量、性能等方面所达成的双方共同认可的级别要求。
服务级别设定是服务供方与需方一起协商适度的目标,经商定后进行文档记录,以便在服务运营期进行监测,把服务交付实际情况和商定的服务级别进行比较,衡量服务质量与价格。服务级别设定的结果在确认后通常会形成服务级别协议,如图4.4所示。
服务级别设定的目标是确保对服务供方所有运营中的服务及其绩效以专业一致的方式进行衡量,并且服务过程和生成的报告符合业务和客户的需要。
-
服务级别设定的目的
(1)通过对IT服务绩效的协商、监控、评价和报告等一整套相对固定的运营流程,来维持和改进IT服务的质量,使之既符合业务需求,又满足成本约束的要求。服务级别的设定有助于IT服务供方更好地对其服务水平做出正确的决定,还能够通过调整客户对更高服务水平的需求而对成本产生影响,限制用户需求的膨胀。
(2)采取适当的行动来消除或改进不符合级别要求的IT服务。设定服务级别的另外一个辅助作用就是避免期望蔓延,即对客户未成文要求的服务进行有效管理和限制。对于用户来说,对现状提出更高要求是很正常的。服务级别协议(Service Level Agreement, SLA)一旦制订,协议将成为文档。虽然用户会不断地提出更高的服务要求,但是协议只能在规定的范围内发挥作用。服务级别中规定承担的义务可以进行变更,但是每次变更都需要重新进行协商。
(3)提高客户满意度,以改善与客户的关系。进行服务级别设定最主要的目的是明确客户的期望、满足客户的需要。首先要在IT服务供方和客户之间建立一个对话途径,这就需要服务供方必须了解客户到底需要哪些服务,同样,客户也须阐明其需要或希望得到哪些服务。当IT服务供方与客户之间达成某种共识之后,就建立了一个衡量IT服务质量的标准,IT服务供方也就有了明确的目标,以满足客户的需要。
(4)督促IT服务供方。只要把服务级别设定得恰当,无论是客户、IT服务供方,还是与他们相关的组织,都会从中受益。服务级别的设定能够调整用户需求和高水平服务之间的关系;反之,服务级别能够督促IT服务供方必须提供承诺的义务,为客户提供目标明确的服务。 -
服务级别设定的活动
(1)了解服务内容:服务供方充分了解自己所能提供的各种服务,以及相关优先权和业务重要程度。
(2)确定服务范围、服务对象和服务内容:可以参考服务目录,但是对于不同用户,具体的服务级别设定又要有针对性和独立性。
(3)定义服务级别目标:在服务级别设定的过程中,服务供方和客户需要仔细地推敲指定合适的服务目标,既要考虑到客户的需求,又要兼顾到经济效益和成本因素,力求服务级别可行。一般来说,SLA中最关注的是关键服务的关键指标。
(4)明确双方职责:服务本身并不是单方面的工作,服务级别设定后在许多服务实施过程中的失败,其原因就是因为忽略了客户在服务提供过程中的角色,以及相应的权利、义务、职责等。经过双方确认,除了在服务供方任命专人对口客户,在客户方亦需要有专人负责,对服务供方进行监督。
(5)识别风险:充分识别实现服务级别的技术能力、资源配置、信息安全、服务成本等风险。
(6)对服务级别设定的评审和修改:服务级别设定后需要在IT服务供方内部进行评审,评审过程除应召集服务过程相关方外,还应有质量管理人员,必要时需邀请法务人员和财务人员进行评审。
(7)服务级别谈判和沟通:在最终形成文档的SLA中,每个细节都是经过谈判、双方同意并被记录在案的;及时沟通服务级别设定的每项内容,对整个服务级别管理过程有着重要的作用。 -
关键成功因素
(1)重视服务级别设定,投入足够的资源和时间。
(2)在服务级别设定过程中,服务级别应尽可能地获得多数人的同意和认可,以获得必要的支持。
(3)充分考虑客户需求,服务级别是根据IT与业务需求的结合面设定的。(4)验证服务目标是否可实现,在签约SLA前对这些服务目标进行核实。
(5)正确识别供方服务能力,得到足够的运营级别协议或支持合同的支持。
(6)在设定服务级别过程中各方的责任定义明确。
参考实例:表4.7列举了常规服务级别说明书中所包含的内容。
表4.7 常规服务级别说明书的内容
服务名称 桌面支持服务 描述 提供桌面支持服务,包括软件安装、计算机配置、病毒防护、网络配置和硬件支持,提供现场、电话或在线服务 负责人 提供负责服务的负责人姓名 用户 包括客户方的财务部和人力资源部的人员 详细细节
输入 客户联系信息、全面的问题描述,包括需要的任何错误信息 输出 问题被解决或按照需要升级,结果将关系到客户的满意度,必要时需要提供相关服务报告 服务时间 桌面支持服务时间为:周一~周五,08:00~17:00 性能标准 响应时间10分钟到达现场时间2小时故障解决时间4小时,要求90%的服务可以在上述时限内完成 启动、变更或终止服务的客户规程 用户可以通过拨打客服电话提出需求,号码为400-123-4567 费用 支持服务不产生任何费用,如果服务过程中涉及硬件设备更换,则需要另外计费。另外,软件的许可由客户提供
4.6.3 人员要素设计
在规划设计过程中,服务人员配置是必不可少的一个环节。服务供方要根据客户的需求或潜在需求适当地配置服务人员,以最大限度地满足客户需求,提高客户满意度。服务供方在选择人员和配置人员时,需要对人员能力和服务工作量进行评估。首先,IT服务人员能力评估应结合客户需求和客户特点,选取符合IT服务工作要求的评价指标,知识、技能和经验是主要要素。其次,评估IT服务人员能力素质现状,用以衡量IT服务人员能力素质水平;识别IT服务人员能力素质差距,用以指导IT服务人员能力素质培养方向。例如,在配置桌面现场服务人员时,需要选取的人员不仅应具备一定的基础知识和技能,面对客户的服务态度和语言表达也是人员配置时要衡量的内容。服务工作量的评估不仅关注IT人员的绩效指标,还从服务人员工作岗位的职责等方面进行评估,也会影响成本方面的设计。
-
人员要素设计的目的
(1)确保服务团队组织架构与业务需求和服务模式相适应。(2)确保配置的服务人员数量能同时满足服务和成本两方面的需求。
(3)确保服务人员的能力持续满足服务的需求。
(4)保持服务人员稳定的工作状态。
(5)保持服务人员的连续性。
-
人员要素设计的活动
(1)人员岗位和职责设计。一个完整的IT服务团队应包括管理岗、技术支持岗、操作岗等主要岗位。
管理岗:
-
管理IT服务的人员可以是供方的人员或需方相关人员。
-
规划、检查IT服务的各过程,负责IT服务的策划、实施、检查、改进的范围、过程、信息安全和成果。
技术支持岗:
-
在IT服务中负责技术支持的人员,包括网络、操作系统、数据库、中间件、应用开发、硬件、集成、信息安全等方面的专业技术人员。
-
基于专有的对IT服务过程中的请求、事件和问题做出响应,保障信息安全并对处理结果负责。
操作岗:
-
在IT服务中负责日常操作实施的人员。
-
根据规范和手册,执行IT服务各过程,并对其执行结果负责。
-
系统规划与管理师需根据具体服务项目结合客户需求设计相应的人员岗位、职责及工作规范。在职责及工作规范设计上,除要定义各岗位本身的职责和工作规范外,还需定义为配合服务交付需要的流程衔接、信息传递及反馈等工作规范要求。如对于7X24小时轮班的工作岗位,工程师须在岗位交接时就未完成工单或需后续跟进的内容进行交接说明;操作岗需要技术支持岗提供技术支持与解决的信息,还需要向技术支持岗提供相应的信息,避免重复询问用户。
(2)人员绩效方案设计。为建立公平、公正、公开的绩效考核文化,应定期对人员绩效进行考核评估,以达到积极高效的工作绩效的目的。
人员绩效设计主要包括以下活动:
-
人员绩效指标的识别及定义:依据IT服务人员岗位、工作职责的不同定义不同的绩效管理目标,如一线支持岗位与问题解决专家团队工作职责不同,绩效指标也不相同。因此,人员绩效指标的设定要符合SMART原则。
-
明确人员绩效指标的计算考核方法:依据SMART原则设立人员绩效指标后,需进一步详细说明指标的计算及考核说明。
-
定义考核信息来源:确定考核信息的采集方式,如系统故障日志、服务系统中记录的客户满意度反馈等。
-
定义人员绩效考核周期:绩效指标的定义要有一定的期限,一般IT服务人员的考核周期为每季度1次,高级别IT服务管理人员可定义为每半年或一年评价1次。
-
设计绩效考核策略:针对IT服务人员绩效指标及可能的达成情况,设计绩效考核和策略,以确保绩效考核方案能实现人员的正向激励。
【实例】人员绩效指标考核。
公司针对热线工程师设定了服务投诉次数1次/季度的指标,并进一步明确说明了投诉必须是客户通过投诉信箱、投诉热线进行的投诉,其他非直接表达的投诉不计为投诉,且给予热线工程师面向客户投诉进行申诉的机会,如客户同意,可撤销投诉。工程师被投诉次数超过1次,就要受到相应的惩罚,且每超1次扣除当季奖金的10%,最高扣除当季奖金的50%。
SMART原则:-
明确的(Specific):清楚地说明要达成的行为标准。很多团队不成功的重要原因之一就是因为目标定得模棱两可,或没有将目标有效地传达给相关成员。如“增强客户服务意识”的描述就很不明确,有很多增强客户服务意识的方法,且增强客户意识到底要达到什么样的程度,这里都没有具体定义,不明确就没有办法评判、衡量。
-
可以衡量的(Measurable):指目标是量化的,且验证这些目标的数据或信息是可以获得的,无法量化就无法衡量和考核。如热线服务满意度大于85%,就是一个可衡量的指标,而将KPI定位为服务效率高,就不是合理的指标,其没有具体量化,无法测量和考核。
-
可以达到的(Attainable):指目标在付出努力的情况下可以实现,避免设立过高或过低的目标。如要求客户满意度为100%,那么该指标订立得很不现实,虽然服务质量本身是一致的,但不同的客户在不同的情形下,服务感知不同,因而很难达到100%的满意。
-
可实现的(Relevant):指在现实条件下是否可行、可操作。如希望将到场时间由2小时降低为30分钟,这在既定的成本、资源约束上是不现实的,为了达成这个指标,在投入比实际收益要多很多的情况下,KPI指标订立得就不现实。
-
时限性(Time-bound):指标的订立要有明确的时间期限说明。如将在2015年5月31日之前完成某事,5月31日就是一个确定的时间限制。没有时间限制的目标没有办法考核,或带来考核的不公正。
无论是制订团队的工作目标还是员工的绩效目标都须符合上述原则,五个原则缺一不可。
(3)人员培训方案设计。为保障服务人员持续具备满足SLA要求的服务能力,需要通过培训来辅助IT服务人员的技术能力持续满足IT技术发展的需要,确保IT服务管理能有效实施,并满足IT服务人员的成长需求。人员培训方案设计主要包括以下活动。
培训需求分析
-
调查:没有调查就没有发言权,通过各层面的调查获取培训需求,通过内部调查了解各层面员工需要什么培训、什么时候需要、对培训的关切程度、需要什么形式的授课。
-
管理层访谈:通过高层访谈和参与管理层会议的形式,了解管理层所需要收获的知识,如何提高IT服务管理水平、开拓管理层事业,如何提高IT服务的效益,如何提升管理层自身价值的认可与企业归属感等。
-
数据分析:分析、整理前期人员服务过程数据,培训调研的数据,历次课程、培训考试的数据,最终获取当期培训的真实需求。
培训内容设计
-
管理培训:企业IT服务的生存和发展,从一定意义上讲取决于IT服务管理人员对于IT服务的管理水平和能力,做好管理培训是IT服务发展的有力保证。IT服务中的管理培训主要培养执行IT服务过程的管理人员,应该具备优秀的沟通能力、执行能力、合理规划能力、过程管理能力、IT服务管理过程中良好的承上启下的能力等。
-
技术培训:技术是IT服务活动中质量保障的一个重要前提,IT服务人员技术培训重在学习专业技能尤其是专业领域的技术,要求每位IT服务人员有扎实的专业技能,以解决IT服务过程中的请求、事件和问题为契机,不断提升其专业技能和实践能力,进而全面提升其IT服务能力。
-
工具培训:生产力的提升离不开工具,IT服务能力的提升更离不开工具的使用。在IT服务活动中往往重视各种工具的建立,而忽略工具在改造、升级、人员交接过程中造成的使用和规范性问题。所以,关于IT服务工具的培训无论是监控工具、过程管理工具还是专业工具,基本的使用问题是工具培训中必不可少的要素,还应该考虑到工具使用的规范性培训。
-
过程培训:过程管理是IT服务能力计划制定后到IT服务执行前的一系列管理工作,主要对象是IT服务活动中的操作人员以及与之相关的其他人员。过程培训包括IT服务活动中各个过程的规范、与SLA相关的指标、考核制度等。
-
交付和应急培训:通过对交付岗位人员培训,使交付人员明确交付职责、分工、指标及关键管理节点,减少交付人员错误、提高质量。在交付过程中,为了降低设备在运行维护过程中发生的故障,制订应急预案,并组织应急培训,包括对各环节应急预案的响应规范、故障发生频率和周期性知识、风险意识、应急演习等,使人员能够在IT服务过程中领会交付和应急管理的重要性,提升岗位人员的交付、应急素质和处理能力。
设计培训计划
-
培训计划:根据企业一定时期的IT服务发展需要,将培训需求进行客观分析并转变为企业IT服务培训的总体计划。培训计划和经营计划一样是企业实施经营的必要保证,没有计划的培训会导致培训秩序重叠、效果差、成本高,所以实施培训的前提是需要一份培训计划。例如,结合企业IT服务的目标,了解员工知识、技能的现状及未来发展的愿望;将IT服务目标分解到培训的指标体系中,确定培训内容及要求;初步制订培训计划,上报审批;执行过程中定期检查发现的问题,及时修正培训计划;阶段性总结,结合培训效果,提出新的要求并及时修正。
-
培训形式:在IT服务活动中,培训要想达到好的效果,形式的选择非常重要。根据课程目标的需要选择不同的培训形式,合理利用企业资源优势、员工特点和需求以及培训内容,选择适合所需的培训形式,达到最终的培训目的。通常的培训组织形式有授课式培训、实操示范、研讨会、在线视听学习、讨论等。
-
培训纪律:良好的纪律是培训质量的有力保证,在培训体系建设过程中往往局限于设计好的培训课程,实际培训纪律才是培训本身有序进行的前提。除了从培训设计本身吸引员工注意力,还创造良好的氛围,因为员工的学习习惯各有差异,保证培训质量要从培训纪律规范性上加以管理。
设计培训效果评价方法
-
评价的形式和方法:培训效果评价有助于完善培训制度,改进培训质量,从而提升整个IT服务团队的绩效。IT服务活动中培训的形式一般包括调查问卷、考试、课堂表现和实际操作,如表4.8所示。
表4.8 IT服务活动中的培训形式
-
调查问卷 | 用于评价讲师、课程安排、组织者在对学习过程中的执行情况以及学员的认可度 |
---|---|
考试 | 用于测试对知识的掌握情况,以及叙述技能的操作要点与程序 |
课堂表现 | 用于测试对知识或技能的学习情况,以及在互动教学中的技能测试情况 |
实际操作 | 用于测试对技能的操作熟练程度,以及实际环境的应变能力 |
- 评价的内容:主要包括课程内容、课程安排、讲师、个人收益,如表4.9所示。
表4.9 培训评价的内容
课程内容 | 与岗位业务需求的匹配程度 |
---|---|
课程安排 | 课程的时间、教材、环境、设施、组织以及组织方的工作情况 |
讲师 | 讲解思路、表达、积极性、控场能力 |
个人收益 | 对培训内容的掌握情况 |
- 关键成功因素
(1)是否具有成熟的知识管理体系。
(2)岗位培训是否充足且适用。
(3)进行服务意识及沟通能力培训。
(4)团队内人员能力的互备性。
(5)人员考核指标设定是否符合SMART原则。
(6)人员考核结果应用是否真正落地有效。
(7)建立良好的沟通协作机制。
(8)设计有效的人员储备管理措施。
(9)引导积极向上的团队文化,举行团队活动或其他方式进行团队建设。
4.6.4 资源要素设计
在规划设计过程中,根据已经识别的服务需求和设定的服务级别,IT服务供方需要进行服务资源配置,确保服务供方具备提供足够资源的能力,以满足与需方约定的及需方未来的IT服务需求,包括对服务工具、服务台、备件库、知识库的设计。
-
资源要素设计的目的
(1)确保服务供方具备提供足够资源的能力,以满足客户的服务需求。
(2)确保服务供方可以使用有效手段和方法受理客户的服务请求,及时跟踪服务请求的处理进展,确保达到SLA要求。
(3)分析当前的业务需求并预测将来的业务需求,确保这些需求有足够的服务资源进行保障。
(4)确保当前的服务资源能够发挥最大的效能,提供最佳的服务品质。 -
资源要素设计的活动
1)服务工具选择
随着IT资源规模不断增加、业务复杂度的不断深入,IT服务人员只通过人工手段来维护已不能满足业务的需求,因此需要借助自动化的工具和手段来提高自己工作的有效性和效率。常见IT服务工具包括监控类工具、过程管理类工具和其他工具,工具间的关系如图4.5所示。
(1)监控类工具:监控对象的状态数据,为过程管理提供数据支撑,在基于硬件/软件平台、虚拟化、业务、用户感知以及基础设施等这些监控对象的基础上,实现诸如事件管理、性能管理、视图管理、告警管理、统计分析、日志管理等功能。通过此类工具,IT服务人员能够对组织IT环境中的资源进行监控,及时了解IT资源的基础信息、动态信息、告警信息。(2)过程管理类工具:IT服务过程管理(简称过程管理)实现了从技术管理到服务过程的流程化管理,解决了传统IT管理以技术管理为中心的问题。过程管理以“流程”为主线,以标准化为框架,以管理为核心,有机结合了流程、人员和技术三要素。过程管理类工具提供了面向最终用户的服务台及IT服务运营层次的流程,即服务级别管理、服务报告管理、事件(故障)管理、问题管理、配置管理、变更管理和发布管理等。
(3)其他工具:通过此类工具,IT服务人员能够进行重复或批量工作的自动化管理,提高IT服务效率和效果。包括应用程序进程管理工具、补丁管理工具、软件分发工具、远程桌面管理工具、网络访问管理工具、接入安全管理工具、桌面设置管理工具、外设管理工具、预警管理工具、知识管理工具和安全管理工具等。
系统规划与管理师应根据实际需求、服务成本等相关因素,判断是否需要服务工具。如果需要,在选择时需注意以下儿点。
(1)根据服务内容:所有的IT服务项目都需要建设使用一些同类的工具,但不同的IT服务项目所需要的工具会稍有差别,IT服务项目经理应根据项目的特点选择重点建设的内容,如下所示。-
所有IT服务项目:服务台、配置管理平台、过程管理工具、知识管理工具、文档管理工具。
-
咨询项目:知识管理、文档管理。
-
桌面运维服务项目:服务台、配置管理、防病毒管理、补丁管理平台。
-
数据中心场地服务项目:服务台、环境监控、闭路监控、网络监控。
-
应用系统运维服务项目:服务台、网络监控、操作系统监控、业务应用服务监控。
(2)考虑成本:现在市场上有很多的工具可供选择,当由客户出资时,必须根据客户可接受的成本选择不同的工具(不同行业的企业可接受成本不同)。例如,政府、金融行业因为资金充足,会以采购市场上已成熟的产品为主,要求高可用性、高稳定性、良好的技术支持;互联网公司为节省资金,会以采购开源工具为主,要求低费用、可自我二次开发。若是全外包的项目,则需要重点考虑成本,此时工具的投资已是IT服务项目本身的成本。
(3)考虑客户的期望:根据客户关注的重点服务或关键应用选择成熟度高、实用性高的工具。
(4)考虑工具的技术架构及团队的技术水平:系统规划与管理师都希望所选择的工具能够切实提高IT服务支持的水平,能够持续满足在管理制度建设方面的发展需求,服务管理平台类的工具应该高于当前的项目管理需求而建立。基于B/S结构的工具易用性较高,在访问方式上灵活,契合当前的互联网时代,同时在同一界面中包含尽可能多的功能和信息,操作简单。因此,在工具选型中应考虑尽可能选择B/S架构的工具。同时,应将IT服务团队自身的技术水平列入考虑范围之内,团队技术水平高可选择开源等需要大量维护开发工作的产品。
(5)考虑工具的通用性和集成性:除非一个项目十分特殊,否则一般在工具选择时要考虑工具的通用性。例如,选择过程管理平台时要考虑工具对IT服务过程的支持力度,以及对项目现有流程制度体系的支持力度。工具对流程制度体系的支持越高,工具带来的效益越明显。IT服务管理离不开软件工具的集成性,这种集成性主要体现在:服务管理工具与项目管理工具的集成,服务管理工具与监控预警工具、配置管理工具的集成, 以及与项目相关的办公自动化(OA)系统的集成。
2)服务台设计
服务台也称为帮助台(Helpdesk)或呼叫台(Service Desk),其概念起源于传统服务业,当信息技术大规模应用于服务行业后,服务台概念也被引入。
服务台不是一个服务过程,而是一个服务职能,目的是为用户和IT服务组织提供一个统一联系点。如一名普通技术支持人员完全可以利用从该系统中获得的信息,协助用户解决简单的数据库问题,而不一定要将用户转交给专门的数据库工程师。
在规划设计阶段,一旦设定了服务级别和服务内容,服务供方就需要在服务台中配置相关的服务信息,包括相关的客户信息、服务内容和服务级别等基础信息,以便于服务提供。图4.6描述了服务台在整个IT服务过程中的位置。供方应使用有效手段和方法受理需方的运行维护服务请求,及时跟踪服务请求的处理进展,确保实现服务级别协议要求,包括:
(1)设置专门的沟通渠道作为与需方的联络点,沟通渠道可以是热线电话、传真、网站、电子邮箱等。
(2)设定专人负责服务请求的处理。
(3)针对沟通渠道整合服务过程,建立管理制度,包括服务请求的接收、记录、跟踪和反馈等机制,以及日常工作的监督和考核。
3)备件及备件库设计
备件库主要是为IT服务的客户提供设备备件。一般来说,IT服务供方应具备自己的备件库,或者有外部备件支持方来保证备件资源。
一旦确认IT服务需求和服务级别,就需要及时地配置备件资源,主要是配置备件响应方式和级别定义。另外,从IT服务供应方整体来看,规范备件采购流程、出入库管理流程也是在备件库配置前期需要考虑的内容。应具备并有效管理运行维护服务活动所需的备件资源,为所运行维护的设备或系统提供备件服务,按照SLA要求恢复设备或系统的正常运行。对备件库的管理设计包括:
(1)备件响应方式和级别定义,能够满足SLA所约定的备件支持。
(2)备件供应商管理,能够规范备件的采购过程,对供应商进行选择和评价。
(3)备件出入库管理,能够对入库备件进行标识,规范备件的使用和核销,备件物品的账务管理。
(4)备件可用性管理,能够定期对备件状态进行检测,以确保其功能满足运行维护需求。
在备件库管理中,要注意以下指标:备件库信息真实性、备件运作管理规范性、备件库出入库账务管理制度完备性、备件可用率。
4)知识库设计
应具备IT服务活动相关的知识积累,以保证在整个组织内收集、共享、重复使用所积累的知识和信息,包括:
(1)针对常见问题的描述、分析和解决方法建立知识库。
(2)确保整个组织内的知识是可用的、可共享的。
(3)选择一种合适的知识管理策略。
(4)知识库具备知识的添加、更新和查询功能。
(5)针对知识管理要求制定相关管理制度,并进行知识生命周期管理。
-
-
关键成功因素
(1)服务人员能力达标,能正确使用各种服务工具。
(2)服务台的职能明确、服务过程规范。
(3)备件管理规范与SLA中的条款相一致。
(4)有效的监控平台能提高主动发现事故或事件的概率,提前做好预防工作。
(5)及时根据服务级别和服务需求的变更调整服务资源的配置。
(6)如备件库由第三方提供,第三方的支持服务级别充分满足服务需求。
4.6.5 技术要素设计
技术是为保证IT服务的正常交付所应具备的关键技术,或者提供IT服务过程中所必需的分析方法、架构和步骤。
在提供IT服务过程中,可能面临各种问题、风险以及新技术和前沿技术应用所提出的新要求,服务供方应根据需方要求或技术发展趋势,具备发现和解决问题、风险控制、技术储备以及研发、应用新技术和前沿技术的能力。
根据服务对象的技术特征和客户的业务特征,识别出服务中需要使用的关键技术,并且根据设计的服务模式识别出服务中的常见活动,对识别出的关键技术和常见活动安排人员研发标准作业程序(Standard Operating Procedure, SOP)、应急预案、监控指标及阈值、解决方案、技术规范等。在部署实施阶段应不断识别新的关键技术或常见活动,持续新增或变更技术研发活动,并积极使用研发成果。
-
技术要素设计的目的
技术是IT服务中的核心要素之一,也是完成IT服务的必要条件,任何IT服务都有相应的核心技术的支撑,只有掌握了这些核心技术,才可能完成IT服务,从而才有可能提供IT服务的质量。通过技术管理系统的建立,能够对技术管理的成效进行总体评价,帮助IT服务管理层分析技术管理不善的原因,制订改进措施,不断提高IT服务的技术水准,从而提高IT服务水平。
技术要素的设计在IT服务中的目的包括:(1)提高服务质量。
(2)减少人员流失带来的损失。
(3)提高IT服务的效率。
(4)降低服务成本。
(5)对各类IT服务所需的技术进行统一管理,可以做到对成熟技术及时进行推广,并随时研发新的技术。
(6)给IT服务供方和需方提供一致的技术标准。
(7)对技术和方法进行说明,可根据自身需求挑选IT服务项目所需的技术。
-
技术要素设计的活动
1)技术研发
编制技术研发预算:IT服务供方要根据业务和市场分析,针对快速发现问题、快速解决问题、提高业务效率的新方法等制订研发规划,并配备与规划相适应的研发环境和相适应的研发队伍。系统规划与管理师应估算技术研发的成本情况,编制技术研发预算,为运营阶段的技术研发活动提供资金方面的保障。2)发现问题的技术
(1)识别监控对象,制订设备监控指标及阈值表编制计划:根据组织业务和IT服务需求识别出各类监控对象的监控指标和阈值,是监控工具能提供有效监控的基本要求,系统规划与管理师应识别出需要被监控的各种设备,为后期能制订和变更设备监控指标及阈值表制订编制计划,并投入资源保障计划的实施。
(2)制订测试环境建设计划:仿真测试环境通过模拟真实应用系统环境中的场景,为各类测试和分析提供必要的条件,以验证技术的可行性和可靠性。系统规划与管理师应根据服务内容,在考虑服务成本和客户期望的前提下制订仿真测试环境建设计划,为IT服务运营阶段的问题分析和技术管理提供技术保障,规避IT服务的潜在缺陷,增加客户和服务提供方的信心。3)解决问题的技术
(1)识别常用技术,制订常用技术活动标准操作步骤编制计划:技术活动标准操作步骤就是将某一事件的标准操作步骤和要求以统一的格式描述出来,用来指导和规范日常的工作,系统规划与管理师应识别出IT服务可能涉及的技术活动,根据技术活动的频率和影响程度,列出需要标准化操作的技术活动,制订技术活动标准操作步骤编制计划,以保障在IT服务实施和运营阶段建立起标准化的技术操作规程,指导IT服务人员进行标准化的操作,以降低风险、提高效率。
(2)识别突发事件类型和等级,制订应急预案编制计划:由自然灾害、基础设施故障、核心应用故障、安全事件等引发的重大突发事件,将对IT服务的运营产生严重影响,为了避免出现这些事件或出现后及时恢复,应建立相关的应急预案并演练。系统规划与管理师应在IT服务规划设计阶段识别出重大突发事件的类型和等级,制订风险评估和应急预案编制计划,并确保在IT服务实施和运营阶段有足够的能力实施该计划。
(3)识别知识转移需求,制订知识转移计划:完备的知识可提高IT服务技术支撑能力,降低风险,缩减成本,提升效率。系统规划与管理师应别识过往IT服务中产生和使用的历史运维资料、基础架构资料、应用系统资料、业务资料等,以便完整地转移到现有的服务团队中,并为实现知识转移提供支持和保障。
-
关键成功因素
(1)服务人员技术能力达到岗位要求。
(2)正确识别服务需方要求或技术发展趋势。
(3)重视技术方面的使用、管理和维护,建立发现和解决问题的技术体系。
4.6.6 过程要素设计
-
过程管理模型
1)过程/规程管理
过程是指为达到某个目的或目标,而以确定的方式执行或发生的一个或一系列有规律的行动或活动。
规程,也称为标准作业程序(Standard Operation Procedure, SOP),是指将某一事件的标准操作步骤和要求以统一的格式描述出来,用来指导和规范日常的工作。简单地说,规程可理解为”规则+过程”。
过程是较宽泛的概念,描述层级相对较高,而SOP是过程的细化和落地,除约定活动执行的方式和顺序外,更强调了各活动的具体标准、执行条件、执行规范等。SOP的精髓是将细节进行量化,即对某一程序中的关键控制点进行细化和量化。一套好的SOP是确保产品或服务质量的必要条件。SOP不仅是一套技术性范本,更重要的是涵盖了管理思想、管理理念和管理手段。
过程管理是指为了使过程活动更有效,对过程采取的测量、考核、计划和控制措施。客户IT服务需求是通过一个个过程及相关活动实现的,过程要素是IT服务需求实现的保障,过程活动的贯穿使服务更加轨道化、标准化、规范化,进而服务产出更加标准、稳定。
过程的产出是由客户需求决定的,过程产出是否符合约定的客户服务目标表明过程是否有效,过程投入的多少表明过程的工作效率。
2)过程管理模型
过程通常定义了活动、关系、顺序、产出标准等信息,如图4.7所示。
过程管理模型包括一下特征。
(1)有明确的目标:过程存在的原因是为了交付特定的结果,结果必须具有独立性和可计量性,如可统计客户支持事件的个数。
(2)可重复性:过程不是一次性的,过程通常为解决具有重复性特征的服务需求而定义,这样可以确保发挥过程持续性的应用效用。
(3)可衡量性:过程除了可依据交付目标衡量外,还可以根据管理控制需求对过程活动的成本、质量、持续时间进行衡量;同时,过程还可以对重复性事件进行统计衡量与评估,如各活动及跨活动持续的平均时间、活动执行的时间方差、过程在特定时间段内的产出率等。
(4)明确的服务提供者和服务对象:过程是为最终客户服务的,没有客户的过程是没有意义的,是对服务组织资源的浪费。过程在为最终客户服务的同时,其每个活动都有自身的客户,活动的客户可能是IT服务团队成员,也可能是最终客户,在一定程度上,活动是未进行更细致展开的子过程。
(5)对特定事件的响应:虽然一个过程可能是持续性的或重复性的,但其都有相应的驱动原因,如客户对平台稳定性的要求等。
(6)本身的执行需要相应的信息输入:包括过程执行结果的反馈及既有知识、操作规程、数据信息等。
-
过程识别和定义
过程作为IT服务的核心要素之一,与其他要素相比具有一定的独特性,在多数情况下,过程不是显性的,通常看不见、摸不着,甚至说不清、道不明。但在面向客户的服务过程中是实实在在存在的,为了交付特定的IT需求,如未明确定义和说明具体过程,服务组织、第三方、客户之间通常会“滋生”相应的过程去实现交付目标。
过程及过程管理的优劣直接关系服务效率和效益。未明确识别定义的过程在服务实践中难以标准化,服务质量难以把控,也无法准确衡量,因此需要对过程进行识别和明确定义。
1)目标
过程识别和定义的目标主要包括:
(1)过程符合可行性、适用性。
(2)过程稳定,可重复使用。
(3)过程符合效率要求。
(4)过程符合效益要求。
(5)过程可被监控和管理。
(6)过程可追溯、可审计。
(7)过程可被衡量和评价。
2)活动
(1)识别客户服务内容、范围、目标、管理要求过程的最终目标是交付合格的服务结果,过程的识别和定义要围绕客户服务内容、范围、目标、管理要求而展开。
(2)识别需要的过程及过程目标常用过程包括需求管理、事件管理、问题管理、变更管理、发布管理等管理过程。不同的服务协议需要配套不同的过程来实现。在具体IT服务项目中,应选择合适的过程服务去实现相应的目标。如客户协议中仅需要提供电话方式给予远程技术支持,则只需要建立配套的事件管理过程即可。选择合适的过程,同时要识别出合适的过程衡量标准,这些标准一般在服务协议中有着明确的定义,如热线接通率、热线解决周期、满意度等。
(3)定义角色和职责对应选择的过程定义相应的角色,如服务台支持工程师、现场工程师、二线支持专家、后台工程师等,并对各角色的职责进行详细的职责描述。
(4)识别过程的活动,定义活动的相互关系、顺序、活动目标、活动的资源限制及管理要求,在实践中,应根据客户管理要求和服务协议的不同而进行细致的定义,包括识别过程需要的活动、各过程需要的输入/输出目标、活动间的关系及执行顺序。其中涉及与客户互动的活动环节,需要参考客户的意见来共同定义。
(5)定义相关活动详细操作规程及衡量标准过程活动的定义是相对高级别的操作汇总,为保障过程活动的目标达成,需要选择和定义更细致的操作规程,如服务器系统安装操作规程、服务器重启作业操作规程等。具体操作规程依据服务实践中对风险的管理和接受要求来定义,如在无相关操作规程描述的情况下,风险仍在可控范围,则无须对所有场景都制订出严格的操作规程。最佳的服务实践靠行为模式文化引导,而不是严格的过程和制度,所有的过程都细化到SOP是不经济的,也是不可取的。
(6)定义过程的表单及信息记录保存要求。过程定义应包括详细描述过程各活动的信息记录,一是标准化过程的输入、输出及处理,二是确保过程具有可追溯性和可审计性。
(7)定义过程评价、评估及改进机制对过程的评价衡量可结合服务协议约定的报告周期进行。但过程定义后,在服务实践中会因客户需求变化、过程本身设计等原因致使过程不再适用,需要对过程进行重新评估和改进。过程本身需要一定的稳定性,所以评估和改进的周期可以是半年或一年进行一次。
【实例】 桌面系统重置操作规程。
来源:客户热线电话派单、客户现场等。
步骤1:礼貌问候。
步骤2:询问客户故障现象,进行故障识别判断,如可通过维护解决,与客户协商直接维护,若客户坚持,则进入系统重置流程。
步骤3:与客户确认桌面设备外观状态(避免外观有损等现象导致后期出现争议)。
步骤4:与客户确认备份内容,必须提示用户备份邮件、通信录、常用网址、文档、输入法字库等;如客户需要支持或备份空间,给予备份空间协助;备份确认状态,获取客户签字确认。
步骤5:与客户确认需要安装的操作系统并签字后,方可进行。
步骤6:使用DSL最新GHOST文件恢复系统,重置过程中,按顺序严格填写《桌面系统重置操作进度表》。
步骤7:系统重置完成后,依据《XX装机标准》中相关内容进行配置和检验。
3)参考示例
A公司为解决日常大量的重复性客户桌面支持问题,将桌面支持服务外包给了B服务商。B在服务实践中,建立了统一标准的IT服务台,经与客户的磨合沟通,确立了如图4.8所示的三级客户支持体系。
B公司分别就服务台工程师、二线专家、厂商定义了其角色及职责描述,其中服务台工程师职责定义为:
-
服务呼叫的接受、记录、跟踪和优先级排序。
-
已注册呼叫或投诉的处理状态跟进。
-
及时通知用户事件或请求的状态和处理进展。
-
对用户的请求做出评估,尝试解决或将其指派给合适的人加以解决,保持服务级别。
-
监控客户支持事件并进行事件处理的升级管理全过程必须满足服务协议的要求,才能根据此升级管理全过程来管理用户需求,包括记录、处理、结束和检查;根据实际情况,就服务级别的任何变动及时与用户沟通。
-
与二线人员和第三方支持组织进行合作。
-
服务总结,为服务水平的改进提供参考和建议。
-
为问题管理提供相关的事件信息。
-
安排用户/服务台培训计划。
-
在获得用户的确认后关闭客户支持事件。
-
在操作规程方面,对服务台工程师设定了以下要求。
支持前
- 应了解需要支持的内容、支持时间要求、SLA、之前的支持情况及遗留问题,并与需方确认。
- 如果工作较复杂或存在风险,应提前做好预案经过审核后再实施。
- 应确保支持所需的工作条件满足安全、稳定和可用的要求。
支持过程中
- 应严格按照服务台客户用语规范要求。
- 应按照约定的时间要求提供远程支持。
- 应与需方保待沟通。
- 应严格遵守需方的管理制度。
- 应根据交付实施的安全要求提供远程支持服务。
- 应只完成确认的工作内容。
- 如果遇到无法解决的问题或需方提出额外要求,应及时通知上级获取支持,得到授权后再处理。
结束支持前
- 应就遗留问题的处理建议和需方达成共识。
- 应做必要的安全检查,如清除临时账号、避免数据未授权复制等。
- 应在获得需方许可后才能结束远程支持工作。
结束支持后
- 应调查交付服务的规范情况。
- 应调查交付服务的客户满意度。
- 应更新交付服务记录。
- 应就遗留问题寻找解决方案,跟踪解决。
客户支持服务表单及信息记录至少包括以下信息。
- 事件单据号、事件状态。
- 创建人信息:创建人、创建时间、登录账号。
- 申请人信息:申请人、申请人邮箱、联系电话、所在公司、服务级别、办公工位。
- 事件总体信息:事件标题、事件描述、事件来源、事件重要程度、事件紧急程度、解决方案、事件解决人、解决时间、解决方式。
- 事件处理历史信息:转移人、处理人、诊断及补充信息、所采取的支持及操作、开始时间、解决时间。
-
过程KPI设计
1)目的
通过KPI的设计,实现对过程及其活动的监控与衡量,进而保障过程目标的达成。过程KPI设计的目标包括:
(1)通过分层细化过程KPI,确保过程可管理性、可衡量性。
(2)控制风险,消除因未明确定义而引发的潜在风险。
(3)对过程进行定期评价与衡量,改进调整KPI设计,保持过程的有效性。
2)原则
过程KPI指标应符合SMART原则。
3)活动(过程KPI设计方法)过程KPI设计通常采用如下过程。
(1)确定过程KPI指标。通常在与客户的服务协议中已有明确的指标说明,在服务实践中,服务团队为了保障服务质量,自身会补充设置更多关联性的KPI指标,这些指标未写进服务协议中,但对服务协议各项目标的达成起到了实际的操作级保障,可以采用如图4.9所示的分解法进行KPI指标设计。
-
定义整体过程KPI:可直接将服务协议中的指标作为过程的KPI指标进行转换定义,如服务协议中的工作时间、客户满意度、解决周期、稳定率等。
-
定义各过程角色KPI:如定义一线问题解决率、一线错误转移的事件比率、一线未解决30分钟内实现转移比例等。
-
定义活动及子过程KPI:同角色KPI设计,为更有效地保障最终客户服务协议目标的达成,需要在各活动风险点设定相应的KPI指标,以确保各环节的风险在可控的范围内。针对活动的指标可定义为:Linux系统装机周期小于3小时,设备送外修时间小于1周等。
(2)明确KPI计算方法。KPI指标的计算方法应明确定义,避免产生争议,如客户满意度计算,客户未填写反馈信息的服务事件是否纳入统计中,是否列入满意范围等,以及客户投诉的界定,是否拨打投诉电话都界定为投诉,是否给予申述机会等。
(3)明确KPI信息来源。KPI考核指标的衡量需要获得供需双方共同信任的信息来源,如满意度来自于系统平台的客户满意度反馈、故障解决周期基于系统的时间记录等。
(4)定义KPI考核周期。依据SMART原则,指标的制订要有明确的时间期限说明,时间期限即KPI考核周期,不同过程的KPI的考核周期不同,日常监控管理要求越高,统计数量级越大,考核的频度要求越高,如热线平均解决周期可以周为单位进行考核。反之,日常监控管理要求低,且数量级很小,KPI考核周期相对设置较长,如对投诉,可以季度为单位。
(5)定义过程KPI评价、评估及改进机制。按协议约定的报告周期对过程KPI进行评价和评估。在服务实践中会因客户需求变化、过程KPI本身设计、过程各级活动及子过程的管理控制要求不同等原因,引发过程KPI设计的调整,需要对过程KPI进行重新评估和改进。
4)参考实例
客户支持过程KPI(示例)如表4.8所示。注:
VIP客户:指经A公司正式发文任命的总裁、高级副总裁、副总裁、助理总裁人员。
重要客户:指经A公司正式发文任命的总经理、副总经理、总监人员。
普通客户:不属于VIP及重要客户的A公司正式员工。
-
-
过程监控设计
过程定义完成后,需要在控制管理下才能正常发挥作用,处于良好控制下的过程可以持续发生效用,可管理性更强。没有控制的过程会流于形式、形同虚设,无法真正发挥效用。
1)目标
(1)确保过程执行的规范性、有效性,进而确保服务质量的达成。
(2)及时发现过程执行中的问题,采取应对及改进措施。
(3)对过程本身进行评估,持续改进优化过程。2)活动
(1)过程监控的执行,并及时采取干预应对措施。在办公过程电子化的今天,IT服务过程KPI通常设定到电子流程中,如数据中心核心交换机报警信息在5分钟内仍无人处理,将自动短信升级通告到上级主管。
(2)过程审计。通过事后审计的方式也可加强IT服务过程执行的约束力,如对于核心应用故障处理流程,可按照核心应用故障处理过程中的约定,面向业务方应用管理员调研、查阅故障处理报告、应用系统日志、邮件及网络发日志等了解是否严格执行了处理过程。
(3)过程KPI考核。通过对单一事件或一定周期内事件处理进行综合统计分析,以便确认KPI指标是否达成,如服务协议约定事件解决周期不超过4小时,但每月有3个事件解决周期可超过4小时,但最长不能超过8小时,通过对当月所有事件的统计分析,可考察整体过程目标是否达成。 -
常见IT服务管理过程设计
1)服务级别管理过程设计
目的:设计服务级别管理过程,明确角色与职责,梳理过程活动和顺序,设计过程管理指标和改进机制,该过程须确保供方通过定义、签订和管理服务级别协议,满足需方对服务质量的要求。
(1)过程中应当充分考虑以下事项。
-
建立服务目录。
-
需方签订服务级别协议。
-
根据需方的考核评估要求,建立SLA考核自评估机制,包括SLA完成情况、达成率等;在SLA评估后制订改进内容及改进措施。
(2)服务级别的关键指标至少应包括以下内容。
-
服务目录定义的完整性。
-
签订服务级别协议文件的规范性。
-
SLA考核评估机制的有效性和完整性。
2)服务报告管理过程设计
目的:设计服务报告管理过程,根据服务需求和项目干系人的需要,设计报告内容和频度,特别是报告中的数据来源和计算公式,以及数据准确性的校验机制。
该过程须确保供方应通过及时、准确、可靠的报告与需方建立有效的信息沟通,为双方管理层提供决策支持。(1)过程中应充分考虑以下内容。
-
与服务报告过程一致的活动,包括建立、审批、分发、归档等。
-
服务报告计划,包括提交方式、时间、需方接收对象等。
-
服务报告模板,包括格式、提纲等。
(2)服务报告的关键指标至少应包括以下特性。
-
服务报告过程的完整性。
-
服务报告的及时性、准确性。附服务报告分类及模板。
3)事件管理过程设计
目的:设计事件管理过程,根据服务对象的技术特性和工具配备情况设计事件发生分类和分级,设计处理各类事件的活动和顺序(应包括合理的事件升级机制),根据SLA的要求设计各类事件的考核指标,设计事件处理情况的定期回顾机制,通过数据分析发现服务改进机会,并为服务报告提供信息支持。该过程须确保供方具有检测事件、尽快解决事件的能力。
(1)供方应根据事件管理的过程要求建立以下活动机制。
-
与事件管理过程一致的活动,包括事件受理、分类和初步支持、调查和诊断、解决、进展监控与跟踪、关闭等。
-
事件分类、分级机制。
-
事件升级机制。
-
满意度调查机制。
-
事件解决评估机制,包括事件解决率、事件平均解决时间等。
(2)事件管理的关键指标至少应包括以下特性。
-
事件管理过程的完整性、有效性。
-
事件解决评估机制的有效性。
4)问题管理过程设计
目的:设计问题管理过程,根据客户业务的特性和服务人员的技能情况,定义什么是问题,什么情况下启动问题处理过程,设计问题分类和分级,重点关注事件与问题转换的处理方式,规划处理问题的人员与工作机制,设计必要问题管理过程和顺序,考核机制,在运营类服务中问题管理与研发、变更和发布的关联关系,考核机制应关注预防措施的实施比例。
该过程须确保供方通过识别引起事件的原因并解决问题,预防同类事件重复发生。
(1)供方应根据问题管理的过程要求建立以下活动机制。
-
与问题管理过程一致的活动,包括问题建立、分类、调查和诊断、解决、错误评估、关闭等。
-
问题分类管理机制,包括问题的影响范围、重要程度、紧急程度并确定优先级。
-
问题导入知识库机制。
-
问题解决评估机制,包括问题解决率、问题平均解决时间等。
(2)问题管理的关键指标至少应包括以下特性。
-
问题管理过程的完整性。
-
问题解决评估机制的有效性。
5)配置管理过程设计
目的:设计配置管理过程,根据提供的IT服务特性以及IT资产的管理权限,设计配置管理的范围和颗粒度,梳理IT资产的分类和分级,设计资产的状态属性和连接关系属性,根据工具的配备情况设计配置信息的收集方式,以及配置信息的增、删、改的活动过程,设计配置信息的考核指标和计算方式。
该过程须确保供方维护运行维护服务对象的必要记录,并保证配置数据的可靠性和时效性,关联支持其他服务过程。
(1)供方应根据配置管理的过程要求建立以下活动机制。
-
与配置管理过程一致的活动,包括识别、记录、更新和审计等。
-
配置数据库管理机制。
-
配置项审计机制。
(2)配置管理的关键指标至少应包括以下特性。
-
配置管理过程的完整性。
-
配置数据的准确、完整、有效、可用、可追溯。
-
配置项审计机制的有效性。
6)变更管理过程设计
目的:设计变更管理过程,根据服务模式的特征,定义变更管理的控制范围,定义变更的分类和分级设计变更控制活动和顺序,特别注意变更控制与事件和问题的关联关系,应与变更控制活动有机结合,关注由变更带来的连锁反应,当产生重大变更时可能要重新做服务规划设计,制订变更管理考核指标,持续优化过程。
该过程须确保供方通过管理、控制变更的过程,确保变更有序实施。
(1)供方应根据变更管理的过程要求建立以下内容。
-
建立与变更管理过程一致的活动,包括请求、评估、审核、实施、确认和回顾等。
-
建立变更类型和范围的管理机制。
-
对变更完成情况进行统计分析,包括未经批准变更数量及占比、不同类型的变更数量及占比、不成功的变更数量及占比、取消的变更数量及占比、变更关联的配置数。
(2)变更管理的关键指标至少应包括以下特性。
-
变更管理过程的完整性。
-
变更记录的完整性。
7)发布管理过程设计
目的:设计发布管理过程,根据变更管理的设计、工具的配置情况(如备件库、专用工具、最终软件库等)和对IT资产的管理权限,设计发布过管理的范围、分类、分级和活动顺序,如需外部资源协同发布的实施时,还需要设计与外部资源的沟通和约束机制,并写入OLA或UC中,设计发布管理考核指标、计算方式和回顾机制,关注发布管理与事件管理、问题管理、配置管理的关联。
(1)为确保一个或多个变更的成功导入,供方应根据发布管理的过程,要求如下。
-
建立与发布管理过程一致的活动,包括规划、设计、建设、配置和测试等。
-
建立发布类型和范围的管理机制。
-
制订完整的方案,包括发布计划、回退方案、发布记录等。
-
对发布完成情况进行统计分析,包括发布成功率、发布及时率、是否更新配置管理数据库等。
(2)发布管理的关键指标至少应包括以下特性。
-
发布管理过程的完整性。
-
发布过程记录的完整性、准确性。
8)信息安全管理过程设计
目的:设计信息安全管理过程,根据客户业务特征和服务管理要求,识别服务中的信息安全风险,定义信息安全管理范围,定义信息安全事件的特征和等级,分析信息安全风险,制订应对措施,如制度信息安全管理制度、对信息系统做安全加固、采用信息化手段防控、制订应急预案并定期演练等,并文件化、常态化。
(1)为确保供方提供符合信息安全要求的服务,供方应根据安全管理的过程要求建立:
-
建立与安全管理过程一致的活动,包括识别、评估、处置和改进等。
-
建立与运行维护服务要求一致的信息安全策略、方针和措施。
(2)安全管理的关键指标包括以下特性。
-
运行维护服务过程中信息的保密性。
-
运行维护服务过程中信息的可用性。
-
运行维护服务过程中信息的完整性。
-
【练习题】
一、单项选择题
- 下列不属于服务规划设计主要目的的是( )。
A.设计满足业务需求的IT服务
B.规划服务组织架构、人员编制、岗位及任职要求
C.识别和规划支持服务所需的技术及资源
D.服务方案设计
- 下列属于服务设计关键成功因素的是( )。
A.服务成本可以根据客户需求的不同而进行改变 B.确定相似服务提供时的优先次序
C.获取新的服务或添加附加客户的流程及程序 D.把IT资源重新分派到核心业务系统中
- 下列对服务级别协议(SLA)描述不正确的是( )。
A.要有一定的成本控制
B.保障IT服务的性能和可靠性
C.降低IT部门的操作成本
D.服务供方与客户间定义的一种双方认可的协定
- 下列不属于服务需求识别活动的是( )。
A.服务可用性需求识别 B.网络安全需求识别
C.价格需求识别 D.信息安全需求识别
- 服务级别设定的目标是( )。
A.确保对服务供方所有运营中的服务及其绩效以专业一致的方式进行衡量
B.对客户未成文要求的服务进行有效管理和限制
C.把服务级别设定得恰当,无论是客户、IT服务供方,还是与他们相关的组织,都会从中受益
D.正确识别供方服务能力,得到足够的运营级别协议或支持合同的支持
【参考答案】:D A C B A
二、案例分析题
某银行是中国第一家向社会公众公开发行股票并上市的商业银行。经过20年的快速发展,该银行综合实力日益增强,自身规模不断扩大,市场份额与品牌知名度得到不断提升,为公司客户搭建起跨时空、全方位的银行服务体系。
该银行建行以来,始终坚持狠抓信息化建设,大力开发综合业务处理系统,不断创新电子化服务手段,基本实现了业务处理电子化和网络一体化。在系列改革措施的推进下,该银行业务转型稳步进行,风险控制全面加强,资产质量明显提高,资本实力显著增强,使得信息化建设成为该银行自身建设的核心内容。
随着该银行业务的不断壮大与发展,客户服务请求事件数量的不断增多,给该银行
IT部门带来了极大工作量,由于缺乏统一的运维管理,一旦发生事故,IT内部人员像“救火队员”一样四处去“灭火",无法快速定位故障原因,故障不能及时解决,业务部门的意见很大,业务部门往往用影响业务生产与IT部门进行交涉,使IT服务非常被动。为改变IT现在被动局面,经领导决定通过招标的形式确定,“长远科技”为其提供IT咨询服务。
问题:
(1)如果你是“长远科技“负责该项目的项目经理,在服务规划设计阶段,服务目录设计应具有哪些活动。
(2)请根据案例介绍简要设计出该项目的服务目录。
(3)请根据案例介绍简要设计该项目的服务级别协议(需列出关键要素)。
(4)请根据案例介绍该项目应采取哪些服务模式,并写明原因和服务范围。