【培训】【ITIL_V3】【Foundation】许.pptx

itil v3 foundation,课程安排,自我介绍,丁劲松 高级咨询师 上海天帷企业管理咨询有限公司 上海交通大学mba itsmf 授权iso/iec 20000主任审核员课程培训讲师 iso 9001, iso/iec 20000, iso/iec 27001 注册主任审核员 mail: 1ding msn: 1ding mobile:课程纪律 | 八荣八耻,以手机静默为荣，以铃声乱响为耻； 以无烟建议为荣，以吞云吐雾为耻； 以遵守时间为荣，以迟到早退为耻； 以服从纪律为荣，以目无章法为耻；,以积极参与为荣，以消极观望为耻； 以团队作战为荣，以各自为政为耻； 以笃学善问为荣，以不懂装懂为耻； 以学以致用为荣，以脱离实践为耻。,基本概念,1,服务战略,2,服务设计,3,服务转换,4,服务运营,5,课程模块,服务改进,6,1.1 itil 简介,1.2 服务的基本概念,1.3 服务与价值,1.4 什么是服务管理,1.5 it服务生命周期,1.6 其他基本概念,1.1 itil 简介 | it部门/人员常常面临的问题,你对it部门在公司中所处的地位觉得满意吗？,你对你目前的工作方式觉得满意吗？,工具,1.1 itil 简介 | it服务管理（itsm）的含义,一个领域, 它将,文化,进行有效而合理的整合，以提供高质量的it服务。,1,2,4,it服务管理是一套通过sla来保证it服务质量的协同过程。它融合了系统管理、网络管理、系统开发管理等管理活动以及变更管理、资产管理、问题管理等许多过程理论和实践。 gartner,it服务管理是一种以过程为导向、以客户为中心的方法。它通过整合it服务与企业业务，提高了企业的it服务的能力和水平。 itsmf,1.1 itil 简介 | itil是什么?,itil是: it infrastructure library的英文字头缩写 由英国商务部（ogc）制定的一套由最佳实践所构成的it服务管理标准，该标准主要为 it服务运作和管理提供指导,itil 2011,1.2 服务基本概念 | 什么是服务?,什么是服务,?,1.2 服务基本概念 | 什么是it服务?,？,这里有it服务吗？,1.2 服务基本概念 | 服务包,service package （服务包） 对可提供给客户的 it 服务的详细描述。服务包包括一项或多项核心服务和支持服务。,core service （核心服务） 提供满足一个或多个客户期望的基本结果的 it 服务。,supporting service （支持服务） 推动或增强核心服务的服务。例如目录服务或备份服务。 支持服务也包括technical support service,辅助物品,支持性 设施,辅助物品,支持性 设施,1.2 服务基本概念 | it服务关系图,自2011版服务设计.p51.f3.7,1.2 服务基本概念 | 对it服务的理解,1.2 服务基本概念 | 服务的定义(1),service （服务）,为客户提供价值的一种手段，使客户不用承担特定的成本和风险就可方便获得希望的结果。,it service （it 服务）,由 it 服务提供商向一个或多个客户提供的服务。it 服务利用信息技术并支持客户的业务流程。it 服务由人员、流程和技术组合而成，应该在服务级别协议中定义。,1.2 服务基本概念 | 服务的定义(),业务服务 business service,基础设施服务 infrastructure service 技术服务 technical service,技术支持服务 technical support service,不直接为业务使用而是 it 服务提供商需要的，以便他们可以提供其它 it 服务。例如目录服务、命名服务或通信服务。,直接支持业务流程的 it 服务，与基础设施服务相反（被 it 服务提供商在内部使用，对于业务通常不可见）。,针对it系统或设备的设计、开发、部署、运行和维护等相关活动。,1.3 服务与价值 | 从客户的最终效果来看待服务,?,1.3 服务与价值 | 功用与功效,自2011版服务战略.p19.f2.2,1.3 服务与价值 | 功用与功效的效果,自2011版服务战略.p84.f3.14,1.3 服务与价值 | 服务功用与服务功效示例,1.4 服务管理 | 服务管理的定义,服务管理 （sm）,服务管理是一套专门的组织能力，以服务的形式为客户提供价值。,it服务管理（itsm）,实施和管理优质 it 服务，满足业务的需要。 it 服务管理由 it 服务提供商通过人员、 流程和信息技术的适当组合而进行。,1.4 服务管理 | 资产与管理,自2011版服务战略.p39.f3.9,1.4 服务管理 | 软件开发与服务管理,自2011版服务战略.p120.f5.11,1.5 it服务生命周期 | 生命周期的导入,？,it系统建设中有推倒重来的现象存在吗？,？,it系统崩溃是系统维护人员的责任吗？,1.5 it服务生命周期 | 模型,服务战略为 it 服务和 it 服务管理确定总体战略。 服务战略 制定服务战略 服务经济 服务组合管理 需求管理 财务管理,1.5 it服务生命周期 | 服务战略,1.5 it服务生命周期 | 服务设计,服务设计为服务和服务管理流程的设计和开发提供指导。 服务目录管理 服务级别管理 容量管理 可用性管理 it服务连续性管理 信息安全管理 供应商管理,1.5 it服务生命周期 | 服务转换,服务转换为如何将新的和变更的服务导入到运营环境的能力开发和改进提供指导. 变更管理 服务资产和配置管理 发布和部署管理 知识管理 转换计划和支持 服务评价 服务测试,1.5 it服务生命周期 | 服务运营,服务运营指导如何达到服务交付和服务支持的效果和效率，从而确保客户和服务提供者的价值得以实现。 事件管理 故障管理 问题管理 服务请求履行 访问控制,1.5 it服务生命周期 | 持续服务改进,持续服务改进负责管理对 it 服务管理流程和 it 服务的改进。 服务测量 7步改进过程 服务报告,1.6 其他基本概念 | raci模型 定义,raci模型用于帮助定义角色和职责 r（responsible） 谁执行 a（accountable） 谁负责（批准） c （consulted） 咨询谁，决策前 i （informed） 告知谁，决策后,参与的角色,1.6 其他基本概念 | 角色 流程负责人,process owner 流程负责人 负责确保流程达到目的的角色。 流程所有者的责任包括赞助、设计、变更管理和不断改进流程及其指标。这个角色经常被指定给具有流程管理者角色相同的人员，但在较大的组织中，两个角色可以分开。,1.6 其他基本概念 | 角色 流程经理,process manager 流程经理 负责流程运行管理的角色。 流程经理的责任包括规划和协调执行、监督和报告流程所需的所有活动。一个流程可以有多位流程经理，例如，每个数据中心可以有区域变更经理或 it 服务连续性经理。流程经理的角色经常被指定给具有流程负责人角色的人员，但在较大的组织中，两个角色可以分开。,1.6 其他基本概念 | 角色 流程执行人,process practitioner 流程执行人 负责执行一个或多个流程的活动。 在组织中，流程执行者角色可以结合流程经理角色；在大量的执行过程中会有不同类型的从业人员。,1.6 其他基本概念 | 角色 服务负责人,service owner 服务负责人 负责提供特定 it 服务的角色。,1.6 其他基本概念 | 过程,process 过程（流程） 用于实现特点目标的一系列有组织的活动,1.6 其他基本概念 | 职能,function 职能 职能是专门执行某种类型的工作，并对所产生的特定结果负责的组织单元。,1.6 其他基本概念 | 降低服务过程影响,自2011版服务战略.p442.f7.2,1.6 其他基本概念 | 能力与技能,服务管理的能力与技能 提供服务的成功取决于参与服务的管理有适当的教育，培训，技能和经验。人们需要了解自己的角色和他们如何有助于整体的组织，服务和流程是有效的激励。变化时，工作要求，角色，责任和能力应该是必要的更新。 能力与技能的框架 规范的角色和职责，可以简化服务管理和人力资源管理。许多服务供应商使用的能力和技巧来支持活动，如技能审核参考一个通用的框架，规划未来的技术要求，组织发展计划和资源分配。例如，资源和成本模型是简单和更容易使用，如果工作和角色的标准。,1.5 其他基本概念 | itil v3 认证机制,基本概念,1,服务战略,2,服务设计,3,服务转换,4,服务运营,5,课程模块,服务改进,6,2.1 概览,2.2 服务战略,2.3 服务组合管理,2.4 需求（量）管理,2.5 财务管理,2.6 业务关系管理,2.1 概览 | 服务战略目标 (1),it部门最大的挑战是什么,2.1 概览 | 服务战略目标 (2),让自己变成不可或缺的,2.1 概览 | 服务战略目标 (5),然后把对的事情做对 选对事情,2.1 概览 | 服务战略目的 (5),为谁提供什么服务?,如何与竞争对手产生差异化？,如何真正地为客户提供价值？,如何为利益相关者（stakeholders）寻找价值？,如何实现财务管理价值创造的可视化和控制？,如何定义服务质量?,如何选择改进服务质量的不同途径？,为谁提供什么服务?,下来想一想为什么 在想怎么干之前先停,2.1 概览 | 服务经济,经济性不依赖于怎样节约，而是怎样明智的花钱选对事情,2.1 概览 | 服务战略流程关系,46,2.1 概览 | 服务价值的组成,47,自2011版服务战略.p70.f3.6,2.1 概览 | 客户期望的服务价值,48,自2011版服务战略.p71.f3.7,2.2 制定服务战略 | 概要,客户 我们需要非标准的运送服务,客户 需要鲜花,大量 用户,ems business,ems it,2.2 制定服务战略 | 服务战略的示例,2.2 制定服务战略 | 服务战略的示例 - 评估,2.2 制定服务战略 | 战略评估,我们的哪些服务是最为出色的? 我们那些服务的收益是最好的? 我们哪些客户和相关放最为满意？ 那些客户/渠道或购买通道的收益最好? 在价值链或价值网中，我们的哪些活动时最为不同和效益最好？,2.2 制定服务战略 | 服务战略的4p,自2011版服务战略.p56.f3.25,2.2 制定服务战略 | 价值链 与价值网,自2011版服务战略.p49.f3.18,2.2 制定服务战略 | 服务提供方,服务提供方: 向一个或多个内部或外部客户提供服务的组织。 类型i 包含在 业务部门（单元）内部的服务提供方 类型ii 向多个业务部门（单元）提供共享it服务的内部服务提供方 类型iii 向外部客户提供it服务的服务提供方,2.3 服务组合管理 | 目标,服务组合以业务价值的方式描述服务提供方所提供的服务。它清晰描述业务需求以及服务提供方对这些需求的应对。 服务组合直接或者有助于澄清以下战略问题： 客户为什么会购买这些服务？ 他们为什么会从我们这里购买服务？ 采用什么样的收费和计费模式？ 我们有哪些优点、缺点、机会和风险？ 我们应该怎样分配资源和能力？,2.3 服务组合管理 | 服务组合的构成,自2011版服务战略.p74.f4.11,2.3 服务组合管理 | 管理过程,自2011版服务战略.p124.f5.17,2.3 服务组合管理 | 服务组合流程,自2011版服务战略.p220.f4.14,2.3 服务组合管理 | 服务生命周期,自2011版服务设计.p34.f3.7,2.4 需求管理 | 目标,理解和影响客户的服务需求和所提供的容量以满足需求 在战略层面影响业务活动模式和用户组合 在战术层面利用不同的收费机制， 鼓励客户使用非繁忙时间在 it服务,2.4 需求管理 | 业务活动模式 （pba）,业务活动会影响服务需求的模式,自2011版服务战略.p130.f5.23,2.4 需求管理 | 用户档案（user profile）,2.5 财务管理 | 概要,管理it服务提供方的预算、决算和收费需求 从财务的视角，提供业务、it服务、it资产以及运营的成本和价值,管理过程： 预算 核算 计费,2.5 财务管理 | 管理过程,自2011版服务战略.p97.f5.1,2.5 财务管理 | 业务影响与业务目标,自2011版服务战略.p141.f3.41,自2011版服务战略.p140.f3.40,2.6 业务关系管理 | 管理过程,自2011版服务战略.p348.f4.34,2.6 业务关系管理 | 业务关系与服务级别的区别,基本概念,1,服务战略,2,服务设计,3,服务转换,4,服务运营,5,课程模块,服务改进,6,3.1 概览,3.3 服务目录管理,3.4 服务级别管理,3.5 容量管理,3.6 可用性管理,3.7 服务连续性管理,3.8 信息安全管理,3.9 供应商管理,3.1 设计协调,3.1 概览 | 目的,服务设计的目的在于： 设计新的或变更的服务导入到生产环境中； 确保设计的各方面都得到全盘考虑，使服务设计的所有活动和过程是整个it 提供端到端的，与业务相关的职能和质量。 当变更或补充设计的任一独立元素时，都要综合考虑有关职能、管理和运营层面。 服务设计的范围包括以下五个方面： 新的或变更的服务； 服务管理体系和工具； 技术架构和管理系统； 需要的过程； 测量方法和指标,3.1 概览 | 对业务的价值,降至整体成本 (tco) 提高服务质量 提供服务的一致性 使得更容易实施新的或者变更的服务 提高服务与业务的相关性 更为有效的服务绩效 改进it治理 更为有效的服务管理和it过程 使得能够进行更好的决策和持续改进,3.1 概览 | 流程总图,自2011版服务设计.p60.f4.2,3.1 概览 | 服务设计包,3.2 设计协调 | 目标,目标 协同设计过程的目的是保证服务设计阶段的目标的达成，提供和维护的所有活动和过程的协调和控制，贯穿整个服务生命周期。 范围 协同设计过程的范围包括所有设计活动，特别是所有新的或变更的服务，这些服务被设计为转换到服务解决方案（除了下线的服务）的生产环境。 对业务的价值 协同设计过程的业务的主要价值是生产一套一致的质量解决方案的设计和sdp，将提供预期的业务成果。,3.2 设计协调 | 管理过程,自2011版服务设计.p108.f4.2,3.3 服务目录 | 目标,目标 通过管理服务目录内的信息，确保其信息能够反映所有运行环境中正在提供或准备提供的所有服务的信息、状态、接口和关联关系 范围 服务目录管理流程的范围是提供和维护所有被转换或已演变为生产环境的服务中的信息。 对业务的价值 业务领域可以准确地获知it服务的准全和一致的整体信息 使客户了解服务所支持的业务过程、可以怎样使用以及可以期望的服务质量和级别,3.3 服务目录 | 结构,自2011版服务设计.p62.f4.3,3.3 服务目录 | 与服务组合管理的关系,自2011版服务设计.p34.f3.7,3.4 服务级别管理 | 目标,通过商定、监视和报告it服务质量的持续循环消除服务的不足来维护和改进it服务质量 - 基于业务要求以及合理的成本 定义、文件化、商定、监视、测量、报告和评审所提供服务的级别 提供和改进与业务和客户之间的关系和沟通渠道 确保为所有的服务定义要求以及可测量的目标 监视和提高客户对所交付服务质量的满意度 确保it与客户之间对所交付服务的服务级别的期望有清晰的理解 确保对所交付服务的质量主动测量措施得以实施,3.4 服务级别管理 | 术语,服务级别需求（slr） slr包括客户需求的详细定义，它可被用来开发、修改和启动服务； slr可作为设计一项服务及其相关的sla的一个蓝本。 服务级别协议（sla） 由it部门和客户之间签订的描述将要提供的一项或多项服务的一份协议； 用非技术语言进行描述； 在协议期间它可作为评价和调整it服务的标准。 运营级别协议（ola） 与it部门内部某个具体的职能或岗位就某项it服务所签订的协议； 支持it部门提供各种服务； 是对sla的细化。 支持合同（uc） 与外部提供商就某项服务的供应所签订的合同； 通常是正式的合同，而sla和olas通常不是法律文本。,3.4 服务级别管理 | 框架的设计,基于服务的服务级别协议（service-based sla） 基于客户的服务级别协议（ customer-based sla） 多层次的服务级别协议（multi-level sla）,自2011版服务设计.p135.f4.7,3.4 服务级别管理 | 过程,自2011版服务设计.p68.f4.6,3.5 容量管理 | 目标,容量管理的意图是为容量和性能相关的所有问题（包括服务和资源方面的）提供集中的管理 主要目标包括： 制定和维护及时更新的容量计划以反映当前和将来的业务需求 为所有业务和it关于容量和性能方面的问题提供建议和指南 通过管理服务和资源的性能和容量， 确保服务性能满足或超过商定的性能指标 帮助诊断和解决与性能和容量相关的问题和故障 评估所有变更给容量计划、服务和资源的容量和性能所带来的影响 确保通过采取主动（预防）措施以合理的成本来提高服务的性能,3.5 容量管理 | 平衡理念,平衡成本和资源 平衡需求和供应,3.5 容量管理 | 管理过程,3.5 容量管理 | 主要支持活动,容量管理的主要支持活动 阈值管理和控制 性能调整和优化活动 需求管理 短期需求管理 长期需求管理 建模和趋势分析 应用选型,3.6 可用性管理 | 目标,以经济合理的方式确保所有交付的服务可用性满足或超越业务当前或将来的需求 目标 制定和维护及时更新的可用计划以反映当前和将来的业务需求 为所有业务和it关于可用性方面的问题提供建议和指南 通过管理服务的可用性， 确保服务可用性满足或超过商定的性能指标 帮助诊断和解决与性能和容量相关的问题和故障 评估所有变更给可用性计划所带来的影响 确保通过采取主动（预防）措施以合理的成本来提高服务的可用性,3.6 可用性管理 | 基本概念（1）,可用性 (availability) 定义：可用性是指一个组件或一种服务在设定的某个时刻或某段时间内发挥其应有功能的容量。表示方法： 用绝对数来表示，如可用时段为8:00到18:00； 用相对数来表示，如平均可用性级别最低为99； 两者的结合，如在开放时间内平均可用性级别为99。 决定因素： (a) it基础架构的复杂程度；(b) 快速有效地对故障作出反应的容量； (c) 组件的可靠性；(d) 运营级管理过程的质量和范围； (e) 由支持部门和供应商提供的维护的质量。,3.6 可用性管理 | 基本概念（2）,3.6 可用性管理 | 基本概念（3）,平均修复时间（mttr） 平均修复时间（mean time to repair ）是指事件发生到服务恢复之间的平均间隔时间，又称为停机时间（downtime）。它由检测时间和解决时间两部门组成。这项指标与服务的可维护性和适用性有关。 平均无故障时间（mtbf） 平均无故障时间（mean time between failures ）是指从某次事件修复到下次事件发生之间的平均间隔时间，又称为正常运作时间（uptime）。这项指标与服务的可靠性有关。 平均系统事件间隔时间（mtbsi） 平均系统事件间隔时间（mean time between system incidents ）是指连续两次事件发生之间的平均间隔时间。平均系统事件间隔时间等于平均修复时间（mttr）和平均无故障时间（mtbf）之和。 平均无故障时间（mtbf）和平均系统事件间隔时间（mtbsi）之比可以表明，服务运作中是存在许多小的故障，或者仅仅是比较少的大故障。,3.6 可用性管理 | 可用性计算,自2011版服务设计.p159.f4.8,3.6 可用性管理 | 可用性计算,对于单个部件的可用性计算公式 可用性 （ast dt）/ ast 100 其中： ast： agreed service time，协商后的服务可用时间 dt：actual downtime during 串行组件的可用性计算 服务的可用性 = host network server workstation 即：= 0.98 0.98 0.975 0.96 = 0.8989 并行部件的可用性计算 先计算两个主机的可用性 = 1-(1host)(1host) = 1-(10.98)(10.98)= 0.9996 然后，再按照串行情况的公式来计算总的可用性 = 0.9996 * 0.98 * 0.975 * 0.96 = 0.9169 最终的可用性是91.69%,3.6 可用性管理 | 过程,自2011版服务设计.p99.f4.13,3.7 服务连续性管理 | 灾难的不同应对方式,汶川大地震中最牛的小学 北川希望小学 一流硬件设施,汶川大地震中最牛的校长 安县桑枣中学校长 叶志平 一流的应急管理,3.7 服务连续性管理 | 目标,目标： 确保业务运作所需的it基础架构和和it服务在灾难发生后的限定时间内能够得到恢复，从而对组织的总体业务连续性管理（bcm）提供支持。 负责预防灾难、增强it基础架构的弹性（resilience）和容错容量（fault tolerance）的过程; 它需要确保组织在发生灾难后有足够的技术、财务和管理资源来确保it服务的连续性运作。 范围： 重点关注那些支持关键业务过程的it服务项目； 对具体的it技术和服务需求提供支持。,3.7 服务连续性管理 | 基本概念,定义： 灾难（disaster）是指可以对一项服务或一个系统造成影响从而需要付出很大的努力来恢复初始绩效水平的事件。 灾难 vs. 事件： “灾难”比“事件”要严重得多； 在一次灾难发生后，全部或部分业务不能正常运作； 常见的灾难包括火灾、雷击、水灾、失窃以及暴力破坏等。 意外事件规划 vs. it服务连续性管理： 传统的意外事件规划是反应式的，通常是被it部门作为用来免除其责任的一种形式； it服务连续性管理过程侧重于预防，即避免灾难的发生。,3.7 服务连续性管理 | 管理过程,自2011版服务设计.p127.f4.21,3.7 服务连续性管理 | 管理指标,3.7 服务连续性管理 | 恢复等级,逐渐恢复（gradual recovery） 冷备支持（cold stand-by）； 可以不用立即恢复业务过程和重建所有it设施，能在72小时或更长的时间内继续保持运行； 要求提供装备了以下设施的未使用的场所：电力、环境控制措施、局域网集线器、通信连接。 中度恢复（intermediate recovery） 温备支持（warm stand-by）； 通常是指在24小时到72小时内重建关键系统和服务的方法； 用于在预定时间内恢复it设施，避免其对业务过程造成影响。 立即恢复（immediate recovery） 发生不可挽回的事件后立即恢复有关服务； 紧急恢复不同于热支持(hot stand-by)，热支持通常是指在较短的时间内（如24小时内）恢复服务的可用性，而紧急恢复指发生事件后立即恢复服务的可用性。,3.8 信息安全管理 | 目标,有效管理所有服务以及服务管理活动中的信息安全 目标： 保证信息的保密性（confidentiality ）， 完整性（integrity ），可用性（availability ） 另外也可包括诸如真实性（ authenticity ）， 可核查性（accountability ）， 不可否认性（ non-repudiation）和可靠性（ reliability ）等特性。,3.8 信息安全管理 | 风险管理,风险 事态的概率及其结果的组合 iso guide 73：2002 风险管理 指导和控制一个组织相关风险的协调活动 注：风险管理一般包括风险评估、风险处 理、风险接受和风险沟通 iso guide 73：2002,3.8 信息安全管理 | 管理过程,自2011版服务设计.p145.f4.27,3.9 供应商管理 | 目标,管理供应商及其所提供的服务，确保向业务提供一致的服务质量 主要目标： 管理与供应商的关系 管理供应商的绩效 确保与供应商的支持和同符合业务要求，与sla/slr所约定的目标相一致 管理/商定供应商合同 维护供应商策略以及管理供应商数据库,3.9 供应商管理 | 管理过程,自2011版服务设计.p151.f4.30,3.9 供应商管理 | 供应商分类,自2011版服务设计.p274.f4.28,3.9 供应商管理 | 角色和界面,自2011版服务设计.p150.f4.29,基本概念,1,服务战略,2,服务设计,3,服务转换,4,服务运营,5,课程模块,总结考试,6,4.1 概览,4.2 发布管理,4.3 变更管理,4.4 资产和配置管理,4.5 知识管理,4.6 服务检验和测试,4.7 服务评价,4.8 转换规划和支持,4.1 概览 | 目标,服务转换的目标是： 驱动业务变更项目或客户整合发布到业务流程和服务中； 减少估计中的变化，以及转换服务的实际绩效； 减少已知错误和在将新的或变更的服务导入到生产环境时的风险； 确保在特定的约束下，确保服务使用符合服务需求。,4.1 概览 | 流程示意总图,自2011版服务转换.p16.f2.3,4.2 发布管理 | v模型,自2011版服务转换.p92.f4.21,4.2 发布管理 | 发布与部署,自2011版服务转换.p181.f4.23,4.2 发布管理 | 发布单元,发布：实施一个或多个已批准的 it 服务的变更所需的一组软硬件、文档、流程或其它组件。每个发布的内容作为一个单独实体进行管理、测试和部署。 发布单元：通常一起发布的 it 服务组件。发布单元通常包括执行有用的功能的全部组件。例如，一个发布单元可以是台式机，包括软硬件、许可、文档等。发布单元可以是完整的工资应用，包括 it 运营程序和用户培训。 发布包：一个发布单元或者多 个发布单元的组合。,自2011版服务转换.p85.f4.15,4.2 发布管理 | 发布选项,分布选项： big bang 和 phased, push and pull automated or manual. 发布类别： 重大发布 小型发布 紧急发布,自2011版服务转换.p86.f4.16,4.3 变更管理 | 目的,服务变更是指对已授权的、计划的、支持的服务或服务组件及其相关文档的添加、修改和移除。 变更管理流程的目标为： 对客户业务需求的变化做出快速响应，同时确保利润的最大化，尽可能减少突发事件、中断或返工； 对业务和 it 请求做出响应，使服务与业务需求相吻合。 变更管理的范围包括了生命周期过程中对基准的服务资产和配置项的变更。每个组织都存在服务变更流程之外的变更，如组织变更，或维修打印机操作层面的变更。当然，这些变更会对服务变更产生不同程度的影响，服务变更管理应当管理与这些变更之间的接口。,4.3 变更管理 | 分类/分级,normal change standard change emergency change,自2011版服务转换.p57.f4.5,4.3 变更管理 | 常规变更管理过程,自2011版服务转换.p49.f4.2,4.3 变更管理 | 标准变更管理过程,自2011版服务转换.p50.f4.4,4.3 变更管理 | 变更模型,变更模型包括： 应采取步骤处理的变更，包括处理问题和突发事件。 这些应采取步骤的顺序，任何依赖或协调处理定义。 责任谁应该做什么。 变更时间和变更阈值的活动需要完成。 变更升级应该联系谁。,4.3 变更管理 | 纠正方案,定义： 变更或发布失败后采取的恢复整治行动。整治包括背出来，业务连续性计划的调用，或采取其他行动，旨在使业务活动继续下去。 变更实施计划应包括里程碑和其他触发器为整治实施以确保有足够的时间在同意改变窗口退出或其他修复必要时。,4.3 变更管理 | 变更7r,对于所有的变更来说，接下来的问题都必须回答。没有这些信息，影响评估将不可能完成，对现有服务的风险和收益的平衡将不能得到理解。这可能导致变更不能交付业务期待的收益，甚至产生对现有服务的有害、不可预期的影响。 谁提出(raised)的变更？ 变更的理由(reason)是什么？ 变更带来的回报(return)是什么？ 变更涉及的风险(risk)是什么？ 交付变更需要什么资源(resource)？ 谁负责(responsible)构建、测试和实施变更？ 这次变更与其它变更的关系(relationship)如何？,4.4 服务资产和配置管理 | 目的,服务资产和配置管理的目标为： 对业务和客户的控制目标及需求提供支持； 提供正确的配置信息，让使用者能够在正确的时间做出决策， 从而维持高效的服务管理流程。例如，对变更和发布进行授权后，能够更快地解决事件和问题； 降低由不合适的服务或资产配置导致的质量和适应性问题； 实现服务资产、it 配置、it 能力和it 资源的最优化。 服务资产和配置管理的范围囊括了整个服务生命周期中的各种服务资产。它提供了一份完整的资产目录，方便对各种资产进行管理。 对 it 资产和服务资产进行全面生命周期管理，从购买初期延续到最终报废； 维护资产目录。,4.4 服务资产和配置管理 | 配置项模型,自2011版服务转换.p67.f4.7,4.4 服务资产和配置管理 | dml,自2011版服务转换.p70.f4.9,4.4 服务资产和配置管理 | 管理过程,自2011版服务转换.p71.f4.10,4.4 服务资产和配置管理 | 与变更管理的关系,自2011版服务转换.p63.f4.6,4.5 知识管理 | 什么是知识?,自2011版服务转换.p147.f4.37,4.5 知识管理 | 知识管理系统,自2011版服务转换.p147.f4.38,4.5 知识管理 | 知识管理系统,自2011版服务转换.p147.f4.36,4.6 服务检验和测试,负责检验和测试新的或变更 it 服务的流程。服务检验和测试确保 it 服务符合其设计规范，并满足业务的需要。,自2011版服务转换.p133.f4.32,4.7 服务评价,负责评估新的或变更的 it 服务 的流程，确保风险已得到管理， 并有助于确定是否继续进行变更。 评价还用于表示实际结果与预期 结果的比较，或者各种选择的比 较。,自2011版服务转换.p141.f4.34,4.8 转换规划与支持,转换规划与支持负责规划所有服务转换流程 和协调它们所需资源的流程。这些服务转换 流程是变更管理、服务资产和配置管理、发 布和部署管理、服务检验和测试、评价和知 识管理。 建立转换策略 准备转换 计划和协调服务转换,基本概念,1,服务战略,2,服务设计,3,服务转换,4,服务运营,5,课程模块,服务改进,6,5.1 概览,5.2 事件管理,5.5 故障管理,5.5 请求履行,5.5 问题管理,5.6 访问管理,5.7 服务台,5.8 服务运营职能,5.1 概览,add slide 131,5.2 事件管理 | 适用范围/目的,目标 事件管理是检测事件，找出事件发生原因并根据原因提供适当的控制措施的过程。 范围 事件管理可以应用于任何方面的服务管理，那些要求需要控制、按照流程进行的服务管理。,5.2 事件管理 | 基本概念,发现/检测有意义的现象，以确定对其应采取的行动，事件管理是运行和监视的基础。 事件（event) 提醒（warning） 告警 （alert）,5.2 事件管理 | 管理过程 - 记录和过滤,5.2 事件管理 | 管理过程 - 信息和提醒,5.2 事件管理 | 管理过程 - 例外管理,5.3 故障管理 | 适用范围/目的,目标 故障管理流程的主要目标是恢复正常服务，尽快减少对业务的不利影响，从而保证服务质量和可用性的最佳水平。“正常服务活动”在这里定义为符合sla的服务。 范围 故障管理包括任何中断、或可能中断服务的情况。这包括由用户直接提报的事件，无论是通过服务台或通过事件管理工具接口而来。,5.3 故障管理 | 基本概念 定义,故障管理的主要目标是尽快恢复为用户提供的 it 服务。 故障：it 服务的意外中断或 it 服务质量的下降。尚未影响服务的配置项失效也是故障。例如镜像组中一块磁盘的失效。 规避措施：在还没有完全的解决方法时，减少或消除故障或问题的影响。例如重新启动发生故障的配置项。问题的规避措施记录在已知错误记录中。没有相关问题记录的故障规避措施记录在故障记录中。,5.3 故障管理 | 优先级,影响度： 影响度指就所影响的用户或业务数量而言，故障偏离正常服务级别的程度； 紧急度： 解决故障时，对用户或业务来说可接受的耽搁时间； 优先级： 处理事件和问题的先后顺序； 优先级影响度 () 紧急度,5.3 故障管理 | 升级,目的 如果某一故障不能在规定的时间内由一线支持小组解决，那么更多的有经验的人员和有更高权限的人员将不得不参与进来，这就是升级。它可能发生在事件解决过程的任何时间和任何支持级别。 职能升级（functional escalation） 需要具有更多时间、专业技能或接入特权（技术机构）的人员来参与事件的解决。 这种升级可能会超越部门界限而且可能会包括外部支持者。 垂直升级（hierarchical escalation） 当经授权的当前级别的机构不足以保证故障能及时、满意的得到解决时，需要更高级别的机构参与进来； 一般情况下应优先使用职能升级，只有当在某些故障不能得到及时解决时才考虑使用管理升级； 如果是后一种方式，最好尽可能早于服务级别协议规定的时间开始有关行动，比如外聘专家。,5.3 故障管理 | n线支持,第1线支持通常由服务台来提供； 第2线的支持则由服务部门提供； 第3线的支持由软件开发人员和 系统结构人员提供； 第4线的支持由供应商提供。,5.3 故障管理 | 管理过程,5.4 请求履行 | 目标,对于某些预定义的申请和需求，为用户提供一个渠道来获得这些标准服务； 为客户和用户提供服务请求管理流程服务和程序信息； 获得和交付请求的标准服务组件； 协助处理一般信息、抱怨或者投诉。 该流程主要针对“服务请求”类事件，指的是it 部门向用户提供的一系列不同种类的普通的需求，这些请求大部分可以分为几类，一类是低风险、经常发生且成本低的微小变更；比如重置口令，对某个特殊的工作站进行额外软件安装的请求等；另一类为信息咨询请求。因为这些请求是经常发生、低风险，因而需要采取一个单独的流程来进行管理，而不是混杂于正常的事件和变更管理流程，变成一种累赘和障碍。,5.4 请求履行 | 主要活动,菜单选择：提供标准服务请求清单，供用户选择，不在清单中的项目不属于本流程管理的范围； 财务审批：如果该服务请求的实现涉及到成本问题，则需要走财务审批环节； 其他审批：在某些特殊情况下，需要更进一步的审批，比如业务审批； 请求实现：服务请求的满足取决于该请求的性质，某些简单的服务请求可能直接由服务台一线支持人员执行，而其他的可能需要更进一步交给专家团队或者供应商进来处理和满足。在某些组织，可能需要组建专门的请求实现团队或者外包给第三方供应商； 请求关闭：用户的服务请求实现后，必须反馈给服务台来关闭。服务台在关闭前可能发起客户回访和满意度调查并输出。,5.5 问题管理 | 目标,问题管理： 问题管理的主要目的是防止发生故障，同时尽量减少无法避免的故障带来的影响。 通过调查和分析it基础架构的薄弱环节、查明故障产生的潜在原因并制定解决故障的方案和防止故障再次发生的措施，将由于问题和事件对业务产生的负面影响减小到最低的服务管理过程。,5.5 问题管理 | 适用范围,范围 问题管理包括对事件的根本原因和确定解决这些问题的活动。它还负责确保结果是通过适当的控制程序执行，特别是变更管理和发布管理。 业务价值 问题管理与事故管理和变更管理来确保it服务的可用性和质量的提高。当事件被解决，对结果信息记录。随着时间的推移，这些信息被用来加快解决时间和识别永久性解决方案，减少事件的数量和完成时间。这导致更少的停机时间和关键业务系统中断。,5.5 问题管理 | 基本概念,问题： 一个或多个故障的原因。在创建问题记录时，通常不知道原因，由问题管理流程负责进一步的研究。 已知错误： 已经记录了根本原因和规避措施的问题。已知错误由问题管理在其整个生命周期中创建和管理。已知错误也可以在开发过程中或由供应商确定。 已知错误数据库 包含所有已知错误记录的数据库。此数据库由问题管理创建，并由故障和问题管理使用。已知错误数据库是服务知识管理系统的一部分。,5.5 问题管理 | 主要活动,反应式问题管理（reactive problem management） 根本原因的分析 属于“服务运营”的一部分 主动式问题管理（proactive problem management） 防止问题的发生 属于“持续服务改进”的一部分,5.5 问题管理 | 管理过程,5.6 访问管理,访问管理流程是授权给合适的用户合理的使用服务，同时也限制未授权用户的访问。在某些组织中，访问管理也被称为权限管理或者身份管理。,5.6 访问管理 | 主要活动,访问请求： 人力资源系统产生的标准请求，这通常发生在新进人员、人员转岗或离职的时候； 变更请求； 服务请求管理流程产生的服务请求； 预先定义的已经授权的脚本或者行动，比如从某个服务器下载某个应用的请求。 验证，需要对客户的访问请求进行两方面的验证： 用户身份，验证提出访问请求的用户身份； 权限验证，是否具有对所请求的服务的适当权限。 权限提供 监控身份状态，典型的身份状态变更发生在： 工作变更；升职或者降职；转岗；离职/辞职；解雇。 记录和跟踪访问 移除或限制权限,5.7 服务台 | 目标,定义： 报告事件和请求提供用户支持的中心，它主要关注操作层次的用户支持。 目标： 为客户和用户提供单一联系点； 协调客户（用户）和it部门之间的关系，为it服务运作提供支持，从而提高客户的满意度； 作为首次联系点，服务台通过截取不相关问题和容易回答的问题减轻了其他it部门的工作量。 “路由器”、“应答机”、“灭火器”、“传声机”,5.7 服务台 | 服务台的技术分类（1）,呼叫中心 只负责记录呼叫请求而不提供解决； 呼叫请求被转发到相应的专家部门； 在有些情况下，呼叫请求的记录和转发可以通过语音响应系统自动进行。 非技能型服务台 呼叫请求被记录下来，并用通用的术语进行描述； 大多数被立即转发至相应的支持人员； 在很大程度上只是一个调度部门 优点在于事件记录被标准化了，并且是代表着用户的利益对事件进行监控和管理的； 其缺点是响应时间更长，首次呼叫解决率要远低于技能型服务台。,5.7 服务台 | 服务台的技术分类（2）,技能型服务台 比前面的几种服务台具有更多的技能和经验； 通过使用文档化的解决方案，它可以解决许多事件，虽然有些事件还是要转发给相关的支持小组； 首次呼叫解决率通常都要远远高于非技能型服务台。 专家型服务台 具有关于全部it基础架构的专家知识以及独立地解决大部分事件的专门技术。,5.7 服务台 | 服务台的形式分类（1）,定义： 每个地区或分部都创建了自己的服务台以支持自己的业务运作。 优点： 便于提供本土化、个性化的服务，响应速度快。 缺点： 当用户很多且需要的服务比较 相似时，这种模式容易造成重 复建设，浪费人力和物力，增 加服务台运作的总体成本。,自2011版服务运营.p111.f6.2,5.7 服务台 | 服务台的形式分类（2）,定义： 由一个物理上的服务中心集中处理所有的服务请求，为用户提供了单一联系点。 优点： 降低总体运营成本； 管理控制上得到了加强； 提高了资源利用率。 缺点： 灵活性较差，难以针对各地用户的 特殊情况提供个性化的服务。,自2011版服务运营.p112.f6.3,5.7 服务台 | 服务台的形式分类（2）,定义： 和用户保持单点联系的一种特殊的分布式服务台。 优点： 降低了运营成本； 加强了统一管理； 提高了资源利用率。 缺点： 难以提供现场支持； 实施要点： 统一接入方式，包括过程、规程和术语； 统一数据输入语言； 保持客户和用户的单点联系，如利用虚拟桌和呼叫自动转移技术实现全球或地区统一电话号码； 适当安排服务专家或工程师出现在客户服务现场； 使用统一的事件处理和管理过程。,自2011版服务运营.p112.f6.4,5.7 服务台 | 角色,服务台经理 服务台工作人员 服务台分析人员 超级用户 技术主管 技术分析人员 技术操作人员,5.8 服务运营职能,5.8 服务运营职能 | 技术管理,技术管理是指提供专业技术和it基础设施的整体管理的团体、部门或小组 技术管理的目标是通过以下活动，帮助规划、实施和维持一个稳定的技术基础设施，以支持该组织的业务流程： 精心设计和高弹性，成本效益的技术拓扑 有足够的技术技能，以保持技术基础设施在最佳状态 快速利用技术技能来迅速诊断和解决任何发生的技术故障,5.8 服务运营职能 | 应用管理,应用管理职能是负责管理和支持业务应用系统的团队、小组或部门 应用管理负谁应用全生命周期的管理 应用管理也在设计、开发和改进应用系统中扮演重要角色,5.8 服务运营职能 | 运营管理,目标: 保持运行状态，以保证日常流程和活动的稳定性 定期审查和改进，以达到在降低成本，改善服务，同时保持稳定 快速应用运营技能以诊断和解决任何it运营中的故障 控制和设备管理 运营控制负责对t基础设施中操作活动和事件的执行和监控。 设备管理是指物理it环境