软考教程第四章：IT服务规划设计

                                                                                                   |

| -------------------------------------------------------------------------------------------------------------------------------- |
| #### 1. 概述 |
| |
| ​ |
| |
| 1. 减少总体拥有成本 |
| 2. 使新有或变更 的服务实施更便利 |
| 3. 改进服务流程 |
| 4. 服务执行更有效 |
| 5. 提升IT服务服务管理 |
| 6. 服务管理更有效 |
| |
| 规划设计的主要目的 |
| |
| 1. ​ |
| 2. 设计SLA、测量方法和指标 |
| 3. 设计服务过程及其控制方法 |
| 4. 规划服务组织架构、人员编制、岗位及任职要求 |
| 5. 识别风险并定义风险控制措施和机制 |
| 6. 识别和规划支持服务所需的技术资源 |
| 7. 评估IT服务成本，制订服务预算，控制 服务成本 |
| 8. 制订服务质量管理计划，以全面提高It服务质量 |
| |
| #### 2.规划设计的主要活动 |
| |
| ​ 规划设计流程中的主要活动包括：服务需求识别、服务目录设计、服务方案设计（含有服务模式设计、服务级别设计、人员要素设计、过程要素设计、技术要素设计、资源 要素设计）、服务成本评估和服务级别协议设计。 |
| |
| ​ |
| |
| ​ |
| |
| 1. 确保规划设计考虑全面 |
| 2. 当服务变更 或补充规划设计的任一独立元素时，都要综合考虑有关职能，管理和运营等层面的问题 |
| 3. 明确重点，充分沟通 |
| 4. 策划，实施，检查 和改进（plan-do-check-act） |
| |
| 1. #### 服务目录管理 |
| |
| 服务目录是梳理服务产品和管理客户期望的重要工具，是服务供方为客户提供的IT服务集中式的信息来源，以确保业务领域可以准确地看到可用的IT服务及服务的细节和状态 |
| |
| ​ |
| |
| ​ |
| |
| 1. ​ |
| |
| 业务服务目录包含提交给客户的所有IT服务细节，，并将其关联到依靠IT服务的业务单元和业务流程，是客户视角的服务目录 |
| |
| 2. 技术服务目录 |
| |
| 包含提交给客户的所有IT服务细节，并将其关联到提供给业务的必需支持服务，共享服务，组件和配置项，支撑业务服务目录是技术视角的服务目录，通常客户不关注技术服务目录 |
| |
| ##### 服务目录设计目的 |
| |
| ​ |
| |
| ##### |
| |
| 1. 促进部门同外部及内部沟通 |
| 2. 对业务要求和挑战有更好的理解 |
| 3. 能有效地把适当的成本分配给某个具体的业务部门、单位 |
| 4. 服务供方能积极、有效地改变终端用户的消费量及其消费行为 |
| 5. 增加客户的需求意识，提高IT服务供方的市场可视性 |
| 6. 提高It服务和流程效率 |
| 7. 把IT资源重新分派到核心业务系统 中 |
| 8. 降低服务提供的出错率 |
| 9. 降低IT部门的操作成本 |
| |
| ##### 服务目录设计活动 |
| |
| 1. 确定小组成员 ：至少包括业务代表，系统规划与管理师，IT服务工程师 |
| 2. 列举服务清单：小组应该列出一个包括所有IT服务在内的清单，不管他们是否包括在现有的IT服务内 |
| 3. 服务分类与编码 |
| 4. 服务项详细描述 |
| 5. 评审并发布服务目录 |
| 6. 完善服务目录 |
| |
| 不同的组织针对IT服务目录的制订成本，复杂性，及实施难度会有所不同，这完全取决于最终 存档的服务目录的服务项数量。只有在服务目录中的服务项逐一实施并被客户认同之后，服务目录的条款才能最终确定 |
| |
| ##### 促进因素 |
| |
| 1. 对服务进行统一收费 |
| 2. 确定服务使用费或基于服务能力的收费额 |
| 3. 增加循环过程中服务消费的数量或单元 |
| 4. 确定相似服务提供时的优先次序 |
| 5. 获取新的服务或添加附加客户的流程及程序 |
| |
| ##### 关键成功因素 |
| |
| 1. 确保向需方提供的每个服务都是独立的，而不是某个大服务的一部分 |
| 2. 可以根据客户的需求和内部情况，对服务内容进行控制 和衡量 |
| 3. 服务成本可以根据客户需求的不同而进行改变 |
| 4. 客户容易认可和感受对服务成本有较大影响的服务 |
| |
| 2. #### 服务级别协议 |
| |
| ​ |
| |
| ​ |
| |
| ​ |
| |
| 支持合同（Underpinning contract,UC）是指组织与外部服务供应商之间签订的有关服务实施的正式合同，是SLA重要部分 |
| |
| ​ |
| |
| 服务级别协议框架 |
| |
| | 要素 | 说明和示例 | |
| | -------------- | ------------------------------------------------------------ | |
| | 需方 | 需方单位名称 | |
| | 供方 | 供方单位名称 | |
| | 第三方 | 第三方单位名称 | |
| | 项目名称 | IT项目名称 | |
| | 生效时间 | 协议生效时间 | |
| | 终止时间 | 协议终止时间 | |
| | 服务简介 | 提供项目的背景，项目的目标和项目的重要性等 | |
| | 服务范围 | 如设备清单等 | |
| | 服务时间 | 约定可提供服务的时间，需要明确例外时间段以及对例外时间段提供服务的协商方式如5X8，7X24等 | |
| | 服务受理渠道 | 客服热线电话，客服邮箱，网上问题提交地址等；如有必要可增加非工作时间服务通道及方式等 | |
| | 投诉渠道 | 投诉热线等 | |
| | 服务交付计划 | 启动会时间，巡检时间，总结时间等 | |
| | 服务交付方式 | 现场交付，远程交付要求等 | |
| | 服务交付内容 | 例行操作，响应支持，优化完善，调研评估等具体服务交付内容 | |
| | 供方人员 | 需明确参与服务人员的岗位，职责 ，姓名和联系方式等，如系统规划与管理师、责任工程师等 | |
| | 第三方接口 | 需明确接口服务的人员岗位、职责 ，姓名、和联系方式，如系统 规划与管理师，责任工程师 | |
| | 供方服务流程 | 故障申报流程，巡检流程，升级上报流程等 | |
| | 第三方服务流程 | 第三方支持流程等 | |
| | 服务交付成果 | 需明确服务阶段中需要提交的各类交付等，如故障报告，总结报告，巡检记录等 | |
| | 保密要求 | 相关信息严禁透露，服务人员应签署保密 协议等要求 | |
| | 服务考核要求 | 服务质量考核的时间周期、考核的关键要素、考核好坏对应的奖惩条款 | |
| | 协议变更控制 | 协议内容变更 的流程和要求等 | |
| | 各方代表签字 | 供需双方代表签字，如需要第三方签字，可增加签字方，需要提供姓名，职务，和签署时间 | |
| |
| |
| |
| 3. #### 服务需求 |
| |
| ​ 通过对客户业务和IT服务需求的了解，可以将需求划分为可用性需求，连续性需求，能力需求，信息安全需求和价格需求； |
| |
| 对IT服务进行具体的设计：包括连续性设计，可用性设计，能力设计，收费模式和定价，IT服务报告设计，最终形成IT服务方案 |
| |
| 需求识别的目的 |
| |
| 1. 了解客户的基本需求，分析潜在客户的不同需求，为IT服务方案设计打下基础 |
| 2. 了解客户对系统可用性和连续性的需求 |
| 3. 进行合理的IT资源配置 |
| 4. 为预算IT服务成本、设计定价和收费模式奠定基础 |
| |
| 需求识别的活动 |
| |
| 1. ​ |
| |
| 1. IT服务不可用对业务的影响，即客户可以承受多长的停机时间 |
| |
| 2. 从业务角度分析IT服务不可用时造成的成本损失 |
| |
| 平均无故障时间：MTBF(mean time between failures)从一次事件中恢复到一下次事件发生的平均间隔时间，也称正常运行时间该指标与IT服务可靠性有关 |
| |
| 平均无故障时间=系统运行时间/系统在运行时间内故障次数 平均无故障时间越长系统可靠性越高 |
| |
| 平均修复时间：MTTR(mean time to repair)故障发生和IT服务恢复之间的平均时间，是检测时间和解决时间之和，也称为空压机时间，该指标与IT服务的可恢复性和可服务性有关。 |
| |
| 平均修复时间=系统故障耗时/故障次数 平均修复时间越短表示易恢复性越好 |
| |
| 平均系统事件间隔时间：MTBSI（mean time between system incidents）两次相邻事件的间隔时间， |
| |
| 平均系统事件间隔时间=平均修复时间+平均无故障时间之和 |
| |
| 2. ##### 业务连续性需求识别 |
| |
| 在进行连续性需求识别的过程中，可以通过风险评估找出那些潜在的威胁，然后引入风险降低的措施或恢复等手段达成这个目的 |
| |
| 3. ##### IT服务能力需求识别 |
| |
| IT服务能力是指保证信息系统的性能和IT服务能力可以以最及时，最有效的方式满足服务级别协议中所有当前和未来的需求。 |
| |
| 所有对能力的需求都以合理的成本加以满足，尤其是对未来能力需求的把握。从某种程序上说，这是能力管理对于组织的竞争力产生积极作用的主要体现 |
| |
| 4. ##### 信息安全需求识别 |
| |
| 信息安全需求体三个方面 |
| |
| 1. 机密性信息仅可以被授权的人访问和使用 |
| 2. 完整性保护信息防止未授权的修改 |
| 3. 可用性在协议规定的时间内，信息都应该是可以获取且可用的。这些信息安全需求的优先级和重要性一般由信息系统的数据和其包含的业务内容所决定 |
| |
| 5. ##### 价格需求识别 |
| |
| IT服务成本主要包含以下几部分：设备成本，系统与应用，软件成本，人力成本，第三方支持成本，管理成本和其他成本 |
| |
| 6. ##### IT服务报告需求识别 |
| |
| IT服务报告需求识别要素包括 |
| |
| 1. 需要对客户的具体业务需求和局部情况进行分析和考虑 |
| 2. 在进行服务报告设计时，要明确服务报告产生的前提条件和服务报告内容的要素 |
| |
| 不同环境下典型的服务报告包括内容如下 |
| |
| 1. ​ |
| 2. 主要工作的绩效报告，如定期的服务概况，事件，变更汇报 |
| 3. 工作的特点和工作量信息 |
| 4. 某段时间的趋势信息 |
| 5. 报告中要包括未来计划的工作信息 |
| |
| 4. ##### 服务方案设计 |
| |
| ​ IT服务方案设计需求的同时考虑服务模式的选择，服务级别的设定和人员、过程、技术、资源要素的管理策略。IT服务方案设计是整个规划设计阶段的核心工作，系统规划与管理师需要综合考虑IT服务供需双方及第三方的能力和要求，设计出让各方满意的IT服务方案。 |
| |
| 1. 服务模式设定 |
| |
| 目前，常见的IT服务模式方法如下： |
| |
| 1. 将IT服务模式划分为远程支持（电话或邮件），现场服务（上门技术支持、常驻现场），集中监控等多种技术支持服务模式 |
| 2. 将IT服务模式分为IT外包（ITO），业务流程外包（bpo）和知识流程外包（kpo）等外包服务和新兴服务模式。 |
| |
| IT服务模式设计的目的是为了更好地满足客户需求，提升客户满意度 |
| |
| IT服务模式设计的活动 |
| |
| ​ |
| |
| 1. 根据客户需求和IT服务提供方的自身业务能力，对客户服务模式进行设计，主要包括IT服务的可用性、连续性设计 |
| 2. 可用性广场是IT服务模式设计的重要内容之一，它确保IT服务的可用性级别可以得到满足 |
| 3. 连续性设计，一般会考虑到风险控制和灾难应对措施 |
| 4. 针对设计的IT服务模式与客户霆讨论、改进 |
| 5. 针对不同的It服务模式进行匹配 |
| |
| 关键成功因素 |
| |
| 1. 选择的IT服务模式与客户需求一致 |
| 2. 跟踪客户需求的变化，及时调整IT服务模式 |
| 3. IT服务供方具备同时提供多种IT服务模式的能力 |
| 4. It服务供方人员配置和资源配置与IT服务模式匹配 |
| |
| 2. ##### 服务级别设定 |
| |
| 服务级别是指服务供方与客户就服务的质量、性能等方面所达成的双方共同认可的级别要求 |
| |
| ​ |
| |
| 服务级别设定的目的 |
| |
| 1. ​ |
| 2. 采取适当的行动来消除或改进不符合级别要求的IT服务。设定服务级别的另外一个辅助作用就是避免期望蔓延。 |
| 3. 提高客户满意度，以改善与客户的关系 |
| 4. 督促IT服务代言 |
| |
| 服务级别设定活动 |
| |
| 1. 了解服务内容 |
| 2. 确定服务范围 |
| 3. 定义服务级别目标 |
| 4. 明确双方职责 |
| 5. 识别风险 |
| 6. 对服务级别设定的评审和修改 |
| 7. 服务级别谈判和沟通 |
| |
| 关键成功因素 |
| |
| 1. ​ |
| 2. 在服务级别设定过程中，服务级别应尽可能 地获得多数人的同意和认可，以获得必要的支持 |
| 3. 充分考虑客户需求，服务级别是根据IT与业务需求的结合面设定的 |
| 4. 验证服务目标是否可实现，在签约SLA前对这些服务目标进行核实 |
| 5. 正确识别供方服务能力，得到足够的运营级别协议或支持合同的支持 |
| 6. 在设定服务级别过程中各方的责任定义明确 |
| |
| 3. ##### 人员要素设计 |
| |
| 服务供方在选择人员和配置人员时，需要对人员能力和服务工作量进行评估。首先 |
| |
| IT服务人员能力评估应结合客户需求和客户特点，选取符合IT服务工作要求的评价指标，知识，技能和经验的主要要素。其次，评估IT服务人员能力素质现状，用心衡量IT服务人员能力素质水平，识别IT服务人员能力素质差距，用以指导IT服务人员能力素质培养方向。 |
| |
| 人员要素设计的目的 |
| |
| 1. 确保服务团队组织架构与业务需求和服务模式相适应 |
| 2. 确保配置的服务人员数量 能同时满足服务和成本两方面的需求 |
| 3. 确保服务人员的能力持续满足服务的需求 |
| 4. 保持服务人员稳定的工作状态 |
| 5. 保持服务人员的连续性 |
| |
| **人员要素设计的活动 |
| |
| ** |
| |
| 1. 人员岗位和职责设计，一个完整的IT服务团队应该包括管理岗，技术支持岗、操作岗等主要岗位 |
| |
| 1. 管理岗：管理IT服务的人员可以是供方或需方的相关人员 |
| |
| ​ |
| |
| ​ |
| |
| 技术支持岗：在IT服务负责技术的人员包括网络，操作系统，数据 库，中间件，应用开发，硬件，集成，信息安全等方面的专业技术人员 |
| |
| 基于专有的对IT服务过程中的请求，事件和问题做出响应，保障信息安全并对处理结果负责 |
| |
| 操作岗：负责日常操作实施的人员 |
| |
| 2. 人员绩效方案设计：为建立公平，公正，公开的绩效考核文化，应定期对人员绩效进行考核评估，以达到积极高效的工作绩效的目的。 |
| |
| 人员绩效设计主要包括以下活动： |
| |
| 1. 人员绩效指标的识别及定义：不同岗位及职责不同定义不同的绩效管理目标 |
| 2. 明确人员绩效指标的计算考核方法：依据SMART原则设立人员绩效指标 |
| 3. 定义考核信息来源：确定考核信息采集方式：系统故障日志，服务系统中记录客户满意度反馈等 |
| 4. 定义人员考核周期，绩效指标的定义要有一个周期，一般IT服务人员的考核周期为每季度一次，高级别的IT服务管理人员可定义为每半年或一年评价1次 |
| |
| |
| |
| SMART原则 |
| |
| 明确的（Specific）:清楚地说明要达成的行为标准 |
| |
| 可衡量的（Measurable）指目标是可量化的且验证这些目标的数据或信息是可以获得的，无法量化就无法衡量和考核 |
| |
| 可以达到的（attainable）是指目标在付出努力的情况下可以实现，避免设立过高或过低的目标 |
| |
| 可以实现（relevant）指现实条件下是否可行，可操作。 |
| |
| 时限性（time-bound）指标的订阅要有明确的时间期限说明 |
| |
| 3. 人员培训方案设计 |
| |
| 人员培训方案设计主要包括以下活动 |
| |
| 1. ​ |
| |
| 1. 调查 通过调查了解各层面员工对培训内容，时间，形式及对培训的关切程度 |
| 2. 管理层访问通过对高层访谈和参与管理层会议的形式：了解管理层对培训内容及培训目的 |
| 3. 数据分析：分析、整理前期人员服务过程数据 ，培训调研数据，历次课程，培训考试数据 最终获得当期培训的真实需求 |
| |
| 2. 培训内容设计 |
| |
| 1. 管理培训 |
| 2. 技术培训 |
| 3. 工具培训 |
| 4. 过程培训 |
| 5. 交付和应急培训 |
| |
| 3. 设计培训计划 |
| |
| 培训计划：将培训需求进行客观分析并转变 为企业IT服务赋予客人总体计划 |
| |
| 确定培训内容及要求：初步制定培训计划，上报审批，执行过程中定期检查发现问题，及时修正培训计划，阶段性总结，结合培训效果提出新的要求并及时修正 |
| |
| 培训形式：通常培训形式有授课式培训，实操示范，研讨会，在线视听学习，讨论 |
| |
| 培训纪律： |
| |
| 4. 设计培训效果评价方法 |
| |
| ​ |
| |
| ​ |
| |
| 关键成功因素 |
| |
| 1. 是否具有成熟的知识管理体系 |
| 2. 岗位培训是否充足且适用 |
| 3. 进行服务意识及沟通能力培训 |
| 4. 团队内人员能力的互备性 |
| 5. 人员考核指标设定是否符合ＳＭＡＲＴ原则 |
| 6. 人员考核结果应用是否真正落地有效 |
| 7. 设计有效的人员储备管理措施 |
| 8. 建立良好的沟通协作 机制 |
| 9. 引导积极向上的团队文化，举行团队活动或其他方式进行团队建设 |
| |
| 4. ##### 资源要素设计 |
| |
| 资源要素设计包括:服务工具,服务台,备件库,知识库设计 |
| |
| 目的: |
| |
| 1. 确保服务供方具备提供足够资源的能力,以满足客户的服务需求 |
| 2. 确保服务供方可以使用有效手段和方法受理客户的服务请求,及时跟踪服务请求的处理进展 ,确保达到SLA要求 |
| 3. 分析当前业务需求并预测将来的业务需求,确保这些需求有足够的服务资源进行保障 |
| 4. 确保当前服务资源能够发挥最大效能,提供最佳的服务品质 |
| |
| 资源要素设计的活动 |
| |
| 1. 服务工具选择 ,常用服务工具包括监控类工具,过程管理类工具和其他工具 |
| |
| 1. 监控类工具:功能实现事件管理,性能管理,视图管理,告警管理,统计分析,日志管理等功能 |
| 2. 过程管理 以流程为主线,标准化为框架以管理为核心有机结合了流程,人员和技术三要素 过程管理类工具提供了面向最终用户的服务台及It服务运营层次的流程,即服务级别管理,服务报告管理,事件管理,问题管理,配置管理,变更管理和发布管理 |
| 3. 其他工具通过此类工具IT服务人员能够进行重复或批量工作的自动化管理,提高IT服务效率和效果. |
| |
| 选择工具时应该注意以下几占: |
| |
| 1根据服务内容 |
| |
| 2考虑成本 |
| |
| 3考虑客户期望 |
| |
| 4考虑工具的技术架构及团队的技术水平 |
| |
| 5考虑工具的通用性和集成性 |
| |
| 2. 服务台设计 |
| |
| 1. 服务台称为帮助台(helpdesk)或呼叫台(service desk)服务台不是一个服务过程而是一个服务职能,目的是为用户和It服务组织提供一个统一联系点 |
| |
| 2. 服务台使用的手机和方法: |
| |
| 1. 设置专门的沟通渠道作为与需方的联络点,沟通渠道可以是热线电话,传真,网站,电子邮件 |
| 2. 设定专人负责服务请求的处理 |
| 3. 针对沟通渠道整合服务过程,建立 管理制度,包括服务请求的接收,记录跟踪和反馈等机制,以及日常工作的监督和考核 |
| |
| 3. 备件及备件库设计 |
| |
| 备件库的管理设计包括: |
| |
| 1. 备件响应方式和级别定义, |
| 2. 备件供应商管理 |
| 3. 备件出入库管理 |
| 4. 备件可用性管理 |
| |
| 备件库管理中要注意:备件库信息真实性,备件动作管理规范性,备件库出入账务管理制度完备性,备件可用率 |
| |
| 4. 知识库设计 |
| |
| 应具备IT服务活动相关的知识积累,以保证在整个组织内收集,共享,重复使用所积累的知识和信息:包括: |
| |
| 1. 针对觉问题的描述分析和解决建立的知识库 |
| 2. 确保整个组织内知识是可用的可共享的 |
| 3. 选择一种合适的知识管理策略 |
| 4. 知识库具备知识的添加更新与查询功能 |
| 5. 针对知识管理要求制定相关管理制度,并进行知识生命周期管理 |
| |
| 关键成功因素 |
| |
| 1. 服务人员能力达标,能正确使用各种服务工具 |
| 2. 服务台职能明确,服务过程规范 |
| 3. 备件管理规范与SLA的条款一致 |
| 4. 有效的监控平台能提高主动发现事故或事件的概率,提前做好预防工作 |
| 5. 及时根据服务级别和服务需求的变更调整服务资源的配置 |
| 6. 如备件库由第三方提供,第三方的支持服务级别充分满足服务需求 |
| |
| 5. ##### 技术要素设计 |
| |
| 1. 技术要素设计的目的 |
| 1. 提高服务质量 |
| 2. 减少人员流失带来的损失 |
| 3. 提高IT服务的效率 |
| 4. 降低服务成本 |
| 5. 对各类IT服务所需的技术进行统一管理,可以做到对成熟技术及时推广,并随时研发新的技术 |
| 6. 给IT服务供方和需方提供一致的技术标准 |
| 7. 对技术和方法进行说明,要根据自身需求挑选IT服务项目所需的技术. |
| 2. 技术要素设计的活动 |
| 1. 技术研发编制技术研发预算,为运营阶段的技术研发活动提供资金方面的保障 |
| 2. 发现问题技术 |
| 1. 识别监控对象 |
| 2. 制订测试环境建设计划 |
| 3. 解决问题的技术 |
| 1. 识别常用技术制定常用技术活动标准操作步骤编制计划 |
| 2. 识别突发事件类型和等级制订应急预案编制计划 |
| 3. 识别知识转移需求,制订知识转移计划 |
| |
| 关键成功因素 |
| |
| 1. 服务人员技术能力达到岗位要求 |
| 2. 正确识别服务需方要求或技术发展趋势 |
| 3. 重视技术方面的使用,管理和维护,建立 发现和解决问题的技术体系 |
| |
| 6. ##### 过程要素设计 |
| |
| 1. 过程管理模型 |
| |
| 1. 过程/规程管理 |
| |
| ​ |
| |
| ​ |
| |
| ​ |
| |
| ​ |
| |
| 2. 过程管理模型 |
| |
| 过程管理模型有以下特性: |
| |
| 1. 有明确的目标交付结果必须具有独立性和可计量性 |
| 2. 可重复性过程通常为觖具有重复性特征的服务需求而定义 |
| 3. 可衡量性 指过程目标,成本质量持续时间可衡量, |
| 4. 明确的服务提供者和服务对象 |
| 5. 对特定事件的响应 |
| 6. 本身的执行需要相应的信息输入 |
| |
| 2. 过程识别和定义 |
| |
| 1. 目标过程识别和定义的目标包括 |
| 1. 过程符合可行性,适用性 |
| 2. 过程稳定可重复使用 |
| 3. 过程符合效率要求 |
| 4. 过程符合效益要求 |
| 5. 过程可被监控和管理 |
| 6. 过程可追溯,可审计 |
| 7. 过程可被衡量和评价 |
| 2. 活动 |
| 1. 识别客户服务内容,范围,目标,管理要求过程的最终目标是交付合格的服务结果,过程的识别和定义要围绕客户服务内容,范围,目标,管理要求而展开 |
| 2. 识别需要的过程及过程目标常用过程包括:需求管理,事件管理,问题管理,变更管理,发布管理等管理过程 |
| 3. 定义角色和职责 对应选择的过程定义相应的角色 |
| 4. 识别过程的活动,定义活动的相应关系,顺序,活动目标,活动的资源 限制 及管理要求 |
| 5. 定义相关活动详细操作规程及衡量标准过程的定义是相对高级别的操作汇总,为保障过程活动的目标达成需要选择和定义更详细的操作规程 |
| 6. 定义过程的表单及信息记录保存要求 |
| 7. 定义过程评价及改进机制对过程的评价衡量可结合服务协议的约定的报告周期进行. |
| |
| 3. 过程KPI设计 |
| |
| 过程KPI设计目标包括: |
| |
| 1. 通过分层细化过程KPI,确保过程可管理性,可衡量性 |
| 2. 控制风险,消除因未明确定义而引发的潜在风险 |
| 3. 对过程进行定期评价与衡量,改进调整KPI设计,保持过程的有效性 |
| |
| 原则 :过程KPI指标应符合SMART原则 |
| |
| 活动: |
| |
| 1. 确定KPI过程指标 |
| - 定义整体过程KPI |
| - 定义各过程角色KPI |
| - 定义活动及子过程KPI |
| 2. 明确KPI计算方法 |
| 3. 明确KPI信息来源 |
| 4. 定义KPI考核周期 |
| 5. 定义过程KPI评介评估及改进机制 |
| |
| 4. 过程监控设计 |
| |
| - 目标 |
| 1. 确保过程执行的规范性,有效性,进而确保服务质量的达成 |
| 2. 及时发现过程执行中的问题,采取应对及改进措施 |
| 3. 对过程本身进行评估,持续改进优化过程 |
| - 活动 |
| 1. 过程监控 |
| 2. 过程审计 |
| 3. 过程KPI考核 |
| |
| 5. 常见IT服务管理过程设计 |
| |
| 1. 服务级别管理过程设计 |
| |
| 目的:服务级别管理过程,明确角色与职责 ,梳理过程活动和顺序设计过程管理指标和改进机制,该过程须确保供方通过定义,签订和管理服务级别协议满足需方对服务质量的要求 |
| |
| 1. 过程中应该充分考虑以下事项 |
| - 建立 服务目录 |
| - 需方签订服务级别协议 |
| - 根据需方的考核评估要求,建立 SLA考核自评机制,包括SLA完成情况,达成率在SLA评估后制订改进内容及改进措施 |
| 2. 服务级别的关键指标至少包括以下内容: |
| - 服务目录定义的完整性 |
| - 签订服务级别协议文件的规范性 |
| - SLA考核评估机制的有效性和完整性 |
| |
| 2. 服务报告管理过程设计 |
| |
| 目的:设计服务报告管理过程,根据服务需求和项目干系人的需要,设计报告内容和频度,特别是报告中的数据来源和计算公式,以及数据 准确 性和校验机制 |
| |
| 该过程须确保供方应通过及时,准确,可靠的报告与需方建立 有效的信息沟通,为双方管理层提供决策支持 |
| |
| 1. 过程中应充分 考虑以下内容 |
| - 与服务报告过程一致的活动包括建立,审批 ,颁发,归档 |
| - 服务报告计划,包括提交方式,时间,需方接收对象等 |
| - 服务报告模板包括形式,提纲 |
| 2. 关键指标应该包括以下: |
| - 服务报告过程的完整性 |
| - 服务报告的及时,准确性,附服务报告分类及模板 |
| |
| 3. 事件管理过程设计 |
| |
| 目的:设计事件管理过程,根据服务对象的技术特性和工具配置的情况设计事件发生分类分级,设计事件的活动和顺序,该过程须确保供方具有检测事件,尽快解决事件的能力 |
| |
| 1. 供方应该根据事件管理的过程要求建立以下活动机制 |
| - 与事件管理过程一致的活动包括事件受理,分类和初步支持,调查和诊断,解决,进展监控与跟踪,关闭等 |
| - 事件分类,分级机制 |
| - 事件升级机制 |
| - 满意度调查机制 |
| - 事件解决评估机制,包括事件解决率,事件平均解决时间等 |
| 2. 事件管理关键指标应该有以下特性: |
| - 事件管理过程的完整性,有效性 |
| - 事件解决评估机制的有效性 |
| |
| 4. 问题管理过程设计 |
| |
| ​ |
| |
| 1. 供方应根据问题管理的过程要求建立 以下活动机制 |
| - 与问题管理过程一致的活动包括问题建立 ,分类,调查和诊断,解决,错误,评估,关闭等 |
| - 问题的分类管理机制,包括问题的影响范围,重要程度,紧急程度并确定优先级 |
| - 问题导入知识库机制 |
| - 问题解决评估机制,包括问题解决率,问题平均解决时间等 |
| 2. 问题管理的关键至少包括以下特征 |
| - 问题管理过程的完整性 |
| - 问题解决评估机制的有效性 |
| |
| 5. 配置管理过程设计 |
| |
| 目的:设计配置管理过程,该过程,该过程须确保供方维护运行维护服务对象的必要记录,并保证配置数据 的可靠性和时效性,关联支持其他服务过程. |
| |
| 1. 机制 |
| - 与配置管理过程一致的活动,包括识别,记录,更新和审计 |
| - 配置数据库管理机制 |
| - 配置项审计机制 |
| 2. 特性 |
| - 配置管理过程的完整性 |
| - 配置数据 的准确,完整,有效,可用,可追溯 |
| - 配置项审计机制的有效性 |
| |
| 6. 变更管理过程设计 |
| |
| ​ |
| |
| 1. 变更内容: |
| - 建立 与变更 管理过程一致的活动,包括请求,评估,审核,实施,确认和回顾 |
| - 建立 变更类型和范围的管理机制 |
| - 对变更完成情况进行统计分析,包括未经批准的变更数量及占比,不同类型的变更数量及占比,不成功的变更 数量及占比,取消的变更数量及占比,变更关联的配置数 |
| 2. 特性 |
| - 变更过程的完整性 |
| - 变更 记录的完整性 |
| |
| 7. 发布管事过程设计 |
| |
| 目的:设计发布管理过程 |
| |
| 1. 要求 |
| - 建立 与发布管理过程一致的很活动,包括规划,设计,建设,配置和测试 |
| - 建立发布类型和范围的管理机制 |
| - 制订完整的方案包括发布计划,回退方案,发布记录等 |
| - 对发布完成情况进行统计分析,包括发布成功率,发布及时率,是否更新配置管理数据 库等 |
| 2. 特性: |
| - 发布管理过程的完整性 |
| - 发布过程记录的完整性准确性 |
| |
| 8. 信息安全管理过程设计 |
| |
| 目的:设计信息安全管理过程 |
| |
| 1. 要求 |
| - 建立 与安全管理过程一致的活动包括识别,评估,处置和改进等 |
| - 建立 与运行维护服务要求一致的信息安全策略,方针和措施 |
| 2. 特性 |
| - 运行维护过程中信息的保密性 |
| - 运行维护过程中信息的可用性 |
| - 运行维护过程中信息的完整性 |
| |
| |
| |
| ​ |