ITIL 4 fundation --宝典

ITIL 4 fundation --思维导图宝典，包括：服务管理的关键概念、ITIL管理实践之一般管理实践、ITIL管理实践之服务管理实践、ITIL管理实践之技术管理实践、服务管理的四个维度。

ITIL 4 fundation

服务管理的关键概念

价值和价值共创

价值与价值共创（Value and co-creation） 价值的定义：价值是感知到的利益，有效性（有用）和某物（某事）的重要性。 价值共创：以前，服务提供方交付服务，消费者接收价值。在这种模式下，消费者自己并没有在创造价值中发挥作用。现在，很多组织发现价值应该是服务提供方和消费者之间通过协作的活动来共创的，其中可能还包括别的组织，这就构成了服务关系。

组织、服务提供方、服务消费者和其它利益相关者

组织、服务提供方、服务消费者和其他它益相关者 组织的定义：一个人或一群人，他们有自己的职责、权力和关系来实现它的目标。 服务提供方：当提供服务的时候，一个组织就扮演了服务提供方的角色。服务提供方可能位于消费者组织的外部，也可能是消费者组织的一部分。 服务消费者：当接受服务的时候，一个组织就扮演了服务消费者的角色。在实践中，还有更多的特定角色包含在服务的消费中，例如客户（Customer）、用户（User）和赞助方/发起人（Sponsor）。 其它利益相关者：服务提供方的员工、社团和社区、慈善组织、等等。

产品和服务

产品和服务（Products and services) 服务的定义：一种通过促进客户想要达到的结果来实现价值共创的方法，客户不必管理特定的成本和风险。 产品的定义：为消费者提供价值的组织资源配置。 服务供给/交付物（Service offerings）的定义：一个或多个服务的描述，用于满足目标消费群体的需求，服务供给/交付物可能包括商品（Goods）、资源访问（Access to resources）和服务行动（Service actions）。

服务关系

服务关系（Service relationships) 服务关系的定义：服务提供方和服务消费者之间的合作。服务关系包括服务提供、服务消费和服务关系管理。 服务关系模型：当服务由提供者交付时，它们为服务消费者创建新资源，或者修改现有资源。

价值：结果/成果、成本和风险

价值：结果、成本和风险(Value：Outcome,costsand risks） 输出（output）的定义：一个活动的有形或无形的交付物。 结果（putcome）的定义：为利益相关者所用的、由一个或多个输出支持的成果。 成本（cost)的定义：花费在某一特定活动或资源上的钱, 风险（risk）的定义：可能造成伤害或损失，或使目标更难实现的事件。风险也可以定义为结果的不确定性，可以用于衡量积极结果和消极结果的概率。

价值：结果、成本和风险（Value： outcome,costs and risks） 功用和功效（Utility and Warranty) 功用（Utility）：产品或服务为满足特定需求而提供的功能。 功用可以总结为“服务做什么”，可以用来确定服务是否“适合于用途（Fit for purpose）” 功效(Warranty)：保证产品或服务符合约定的要求（结果）。功效可以总结为“服务技务如何执行”，并可用于确定服务是否“适合使用（Fit for use）" 【特别提示：在ITIL4中，表达产品或服务的价值时，除了“功用”和“功效”之外，还得加上“体验（Experience）”】

ITIL管理实践之一般管理实践

架构管理

架构管理(Architecture,management) 架构管理实践的目的是提供对构成组织的所有不同元素以及这些元素如何相互关联的理解。 这些元素跨越所有体系结构域：业务、服务、信息、技术和环境。 如果没有适当的架构管理实践所提供的可见性和协调，组织可能会变成一个由第三方契约、跨不同组织简仓的不同流程、针对不同客户和遗留基础设施进行不必要的定制的产品和服务组成的迷宫。

持续改进

持续改进概述

持续改进概述 持续改进（Continual improvement) 持续改进实践的目的是通过持续识别和改进服务、服务组件、实践或产品和服务的有效管理中涉及的任何元素，使组织的实践和服务与不断变化的业务需求保持一致。 对持续改进的承诺和实践必须嵌入到组织的每一根纤维中。如果不是这样，那么每天的运营问题和主要的项目工作将会掩盖持续改进工作的真实风险。 持续改进实践的主要活动包括： 鼓励整个组织的持续改进； 确保持续改进的时间和预算； 识别和记录改进机会； 评估和优先考虑改进机会； 制定改进行动的商业论证（Business Case）； 计划和实施改进； 度量和评估改进结果； 协调整个组织的改进活动；

持续改进的方法

持续改进方法 有许多方法、模型和技术可以用来进行改进。不同类型的改进可能需要不同的改进方法。例如，一些改进可能最好组织到一个多阶段的项目中，而另一些改进可能更适合作为一个简单的快速工作。 虽然有许多可用的方法，但是组织不应该试图正式地采用达多不同的方法，而是应该 选择一些适合于组织通常处理的改进类型的关键方法并培养它们。 持续改进是每个人的责任。虽然可能有一群全职的工作人员专注于这项工作，但是组织中的每个人都应该理解积极参与持续改进活动是他们工作的核心部分，这一点是至关重要的。 组织的最高级别需要负责和持续改进嵌入到人们思考和工作的方式中。没有他们的领导和对持续改进的明确承诺，态度、行为和文化就不会发展到在所有各级所做的每件事都考虑改进的程度。

持续改进其它注意事项

持续改进（3） 当第三方供应商构成服务环境的一部分时，他们也应该成为改进工作的一部分。 为了跟踪和管理从识别到最终行动的改进思想，组织使用一个称为持续改进登记册(CIR)的数据库或结构化文档。 随着新想法被记录下来，CIRs被用来不断地重新确定改进机会的优先级。CIRs的使用提供了额外的价值，因为它们有助于使事物可见。

信息安全管理

信息安全管理实践目的

信息安全管理（Information security management ) 信息安全管理实践的目的是保护组织开展业务所需的信息。这包括理解和管理信息的机密性、完整性和可用性的风险，以及信息安全的其它方面，如身份验证（确保某人是他们所声称的人)和不可抵赖性（确保某人不能否认其所采取的行动)。 要求的安全是透过政策、过程、行为、风险管理及控制等方法建立，而这些方法必须维持以下各点的平衡： √预防（Prevention）—确保安全事件不发生 √检测（Detection）一快速、可靠地检测无法预防的事件 √纠正（Correction）一在检测到事件后进行纠正和恢复

信息安全管理的意义

在保护本组织不受伤害和允许它进行创新之间取得平衡也是重要的。过于严格的信息安全控制可能弊大于利，或者可能被试图更轻松地工作的人所规避。信息安全控制应该考虑组织的所有方面，并与其风险偏好保持一致。 信息安全管理与其它实践相互作用。它创建了每个实践在计划如何完成工作时必须考虑的控制。它还依赖于其它实践来帮助保护信息。 信息安全管理必须基于清晰理解的治理需求和组织策略，从组织的最高层驱动。 信息安全严重依赖于整个组织的人员行为。受过良好培训，并注意信息安全政策和其它控制的员工，可以帮助发现、预防和纠正信息安全事件。训练不足或缺乏积极性的工作人员可能是一个重大的弱点。

信息安全管理流程或程序

信息安全管理（3） 支持信息安全管理需要许多流程和程序，这些包括: √ 信息安全事件/故障管理流程 √ 风险管理流程 √控制评审和审核流程 √身份和访问管理流程 √渗透测试、漏洞扫描等程序 √管理信息安全相关变更的程序，如防火墙配置变更

知识管理

知识管理(Knowledge management) 知识管理实践的目的是维护和提高整个组织对信息和知识的有效、高效和方便的使用。 重要的是要明白“知识”不仅仅是信息，知识是在特定环境中对信息的使用。这需要理解知识的使用者和相关的情况。 需要一个获取知识的过程，包括开发、获取和收获非结构化的知识，无论是正式的、文档化的还是非正式的、隐性的知识。

度量和报告

度量和报告实践的目的

度量和报告(Measurement and reporting) 度量和报告实践的目的是通过减少不确定性水平来支持良好的决策和持续改进。 这是通过收集各种托管对象的相关数据，并在适当的上下文中对这些数据进行有效的评估来实现的。 对于设定的目标，可以定义运营的关键成功因素(CSFs)。在这些CSFs的基础上，可以就一组相关的关键绩效指标(KPI)达成一致，从而衡量成功与否。

度量和报告的实践方法

·关键成功因素（CSF）的定义：达到预期结果的必要先决条件。 关键绩效指标（KPI）的定义：一种重要的度量标准，用于评估是否成功地达到预先设定的绩效目标。 > · KPIs与行为(KPIs and behavior) √个人KPI可以作为一种竞争激励因素发挥作用，如果KPI被设置为满足明确的业务目标，那么这将推动积极的结果。然而，为个人设定目标也有消极的一面，导致不适当或不恰当的行为。如果过多地关注单个KPl，通常会发生这种情况。例如，服务台的工作人员可能会被迫缩短通话时间，但这实际上会对客户满意度产生负面影响，如果问题没有得到妥善处理，甚至会影响解决时间。 √理想情况下，应该为团队设置运营的KPl，而不是过于关注个人。这意味着在整个团队所允许的目标和行为中可以有一些灵活性。当然，个人仍然需要一些特定的绩效指导方针，但是这应该清楚地在团队和组织的目标之内，并且所有的目标仍然应该在为组织提供价值的上下文中设置。

组织变更管理

组织变更管理实践目的

组织变更管理(Organizational change management) 组织变更管理实践的目的是确保组织中的变更顺利、成功地实施，并通过管理人的方面的变更(managing the human aspects of the changes）来实现持久的利益。 改进总是要求人们改变他们的工作方式、行为，有时甚至改变他们的角色。无论变更是针对实践、组织结构、技术，还是引入新的或变更的服务，人员都是变更成功的关键。 组织变更管理实践的目的是确保每个受变更影响的人都接受并支持它。这是通过消除或减少对变更的阻力、消除或处理不利影响，以及通过提供培训、认知和确保成功过渡到变更状态的其它方法来实现的。

组织变更管理实践方法

组织变更管理（2） 组织变更管理有助于SVS的每一个部分，只要涉及到的人，合作，参与和热情就是必要的。 要使变更行动成功，无论变更的程度或范围如何，都有某些要素是处理人的因素所必不可少的。组织变更管理工作必须确保在整个变更过程中建立和维护以下内容： √清晰及相关的目标 √强大而坚定的领导 √有意愿、有准备的参与者 √持续改进

组合管理

组合管理实践的目的

组合管理(Portfolio management） 组合管理实践的目的是确保组织拥有正确的项目集（programme）、项目（project）、产品（product）和服务（service）的组合，以在其资金和资源限制范围内执行组织的战略。 组合管理在整个组织中如何分配、部署和管理资源方面扮演着重要的角色。作为ITIL@ SVS中战略执行的一部分，这有助于资源和功能与客户结果的一致性。 组合管理包括许多不同的组合，包括 √产品/服务组合 √项目组合 √客户组合

敏捷组合管理

敏捷组合管理（Agile portfolio management) √传统的组合管理关注于自顶向下的计划，工作在更长的时间内被安排但是敏捷组合管理采用了由单个敏捷团队使用的构建-度量-学习周期的概念，并在组织范围内应用它。团队一起工作，使用模块化设计，并共享发现。这导致了巨大的灵活性，从而将重点从继续执行不灵活的计划转移到根据业务策略和目标交付价值和取得实际进展。 √ 实践敏捷组合管理的组织尽可能多地跨业务进行沟通。他们分享知识，打破组织筒仓之间的障碍。

项目管理

项目管理实践的目的

项目管理(Project management ) 项目管理实践的目的是确保组织中的所有项目都成功交付。这是通过计划、委派、监控和保持对项目所有方面的控制，以及保持项目参与者的积极性来实现的。 项目是向组织引入重大变更的方法之一。它们可以定义为“为了按照协定的商业论证（business case）交付一个或多个输出(或产品)而创建的临时组织”。 一个项目可以是一项独立的倡议，也可以是一个项目集的一部分与其它相互关联的项目一起进行更复杂的改革。然而，即使是独立的项目也应该在组织的项目组合上下文中考虑。

项目管理实践的方法

项目管理（2） 项目交付的方法有所不同，最常见的是瀑布式方法和敏捷方法。 瀑布式方法在这样的环境中工作得很好：需求是预先知道的(并且不太可能发生重大变化）并且工作的定义比交付的速度更重要。 在需求不确定且可能随时间快速发展的情况下(例如，随着业务需求和优先级的变化或支持创新的开发)，以及交付速度经常优先于精确需求定义的情况下，敏捷方法最有效。 成功的项目管理是重要的，因为组织必须平衡其需要： √有效地维护当前的业务运作 √改变这些业务运作，以便在市场上生存和竞争 √持续改进产品和服务 项目和“照常营业”之间的这种平衡可能会影响许多领域，包括资源(人员、资产、财务)、服务级别、客户关系和生产力，因此组织的容量和能力必须作为项目管理方法的一部分来考虑。

关系管理

关系管理实践目的

关系管理(Relationship management) 关系管理实践的目的是在战略和战术层面(strategic and tactical levels ）上建立和培养组织与其利益相关者之间的关系。它包括识别、分析、监控和持续改进利益相关者之间的关系。 关系管理实务确保： √理解利益相关者的需求和驱动因素，适当地确定产品和服务的优先级； √利益相关者满意度高，组织与利益相关者之间建立并保持建设性关系； √客户对新产品或变更的产品和服务的优先级与期望的业务结果相一致，被有效地建立和表达； √任何利益相关者的投诉和升级都可以通过一个同情(但正式)的流程得到很好的处理； √产品和服务有助于为服务消费者和组织创造价值； √组织促进所有利益相关者的价值创造，符合组织的战略和优先级； √对冲突的利益相关者需求进行适当的协调。

关系管理注意事项

关系管理（2） 服务提供方很自然地将大部分精力集中在与服务消费者（赞助方、客户和用户)的关系上。它是一个非常重要的利益相关者群体，然而，组织应该确保他们理解和管理他们与内部和外部的各种利益相关者的关系。 关系管理实践应适用于所有相关方。这意味着实践可以为所有服务价值链活动和多个价值流做出贡献。

风险管理

风险管理实践目的

风险管理（Risk management ) 风险管理实践的目的是确保组织理解并有效地处理风险。 管理风险对于确保组织的可持续性和为客户创造价值至关重要。风险管理是所有组织活动的组成部分，因此是组织SVS的核心。 风险的定义：可能造成伤害或损失，或者使目标更难实现的事件。风险也可以定义为结果的不确定性，可以用于测量积极结果和消极结果的概率。

风险管理实践注意项

风险通常被认为是可以避免的，因为它与威胁有关。虽然这是普遍正确的，但风险也与机会有关。没有抓住机会本身就是一种风险。 为了使风险管理有效，风险需要: √确定在特定组织活动范围内影响目标实现的不确定性，必须考虑这些不确定性，然后对其进行描述，以确保达成共识。 √评估单个风险的概率、影响和接近性，必须进行评估，以便对其进行优先排序，并了解与组织活动相关的总体风险水平(风险敞口)。 √应对风险的适当反应必须进行计划，分配所有者和执行人，然后实施、监视和控制这些反应。

风险管理原则

风险管理（3） 以下原则特别适用于风险管理实务： √风险是业务的一部分 √风险管理必须在整个组织中保持一致 √风险管理文化和行为是基础

服务财务管理

财务管理目的、主要活动与新技术

服务财务管理(Service financial management) 服务财务管理实践的目的是通过确保组织的财务资源和投资得到有效利用来支持组织的服务管理战略和计划。 服务财务管理支持组织管理层关于在何处最佳分配财务资源的决策，并对与产品和服务有关的预算、成本和会计活动提供可见性。 为了在SVS的上下文中有效，这个实践需要与组织的组合管理、项目管理、关系管理和其它的策略和实践保持一致。 财务是一种通用的语言，它允许组织与利益相关者进行有效的沟通。 服务财务管理（2） 服务财务管理站在服务提供方和服务消费者的角度，负责管理组织的预算、成本、会计和收费活动。 服务财务管理包括三个主要活动: √预算/成本（Budgeting/costing） √核算（Accounting） √收费（Charging） 服务财务管理（3） 财务管理与新技术 √数字技术：主要金融机构现在正在分析和使用最新的技术，如云计算、大数据、人工智能(Al)，以获得甚至只是为了保持在市场上的竞争优势。 区块链：区块链技术用于管理公共数字账簿。这些数字账簿记录许多全球分布的计算机之间的交易。记录的分发确保在不更改所有后续记录(也称为块）和不经过整个分布式分类账(也称为网络）的一致同意的情况下，不能更改每个记录。 √ IT预算和支付模型：传统上，IT资源是通过预付资本支出(CAPEX)获得的。然而，在云模型下，IT基础设施、平台和软件是“作为服务”提供的。该模型通常使用基于订阅或随用随付的收费机制，这些机制由运营费用(OPEX)支付。

战略管理

战略管理实践目的

战略管理(Strategy management) 战略管理实践的目的是制定本组织的目标，并采取实现这些目标所需的行动方针和资源分配。战略确定组织的方向，集中精力，定义或澄清组织的优先级，并为响应环境的变化提供一致性或指导。 战略管理的起点是理解组织的上下文并定义期望的结果。组织的战略建立了标准和机制，这些标准和机制有助于决定如何最好地对资源、能力和投资进行优先排序，以实现这些结果。 战略管理通常被视为一个组织的高级管理者和管理机构的责任。

战略管理的方法

战略管理（2） 战略必须能够为组织创造价值。组织的战略应该包括使其服务和产品对客户具有独特价值的方法。 客户希望解决方案能够突破性能障碍，在成本很少或没有增加的情况下获得更高质量的结果。这些解决方案通常通过创新的产品和服务提供。战略应该平衡组织需要交付高效和有效的业务与创新和面向未来的活动。 高绩效战略是指在不同的时间、不同的业务周期、不同的行业事件和不同的领导方式下，使组织始终能够超越竞争对手。

供应商管理

供应商管理实践目的

供应商管理（Supplier management） 供应商管理实践的目的是确保组织的供应商及其绩效得到适当的管理，以支持提供无缝、高质量的产品和服务(seamless,quality products and services）。这包括与关键供应商建立更加紧密、更多合作的关系，以发现和实现新的价值，并减少失败的风险。 供应商管理实践的核心活动包括： √维护供应商战略、策略和合同管理信息 √谈判、同意合同和安排 √管理内部和外部供应商的关系和合同 √管理供应商的绩效

供应商管理方法

供应商管理（2） 采购、供应商战略及关系(Sourcing、supplier strategy and relationships ) 供应商战略，有时也称为采购战略，定义了组织如何利用供应商在实现其整体服务管理战略中的贡献； 有些组织可能采取一种战略，规定只在非常具体和有限的情况下使用供应商，而另一个组织可能选择在产品和服务供应方面广泛使用供应商。 组织与其供应商之间存在不同类型的供应商关系，需要将其视为组织采购策略的一部分。 这些包括： □内包（Insourcing） □外包（Outsourcing ） □ 单一来源或合作伙伴（Single source or partnership ） □多来源(Multi-sourcing）

供应商评估和选择

供应商管理（3） 供应商的评估和选择 组织应根据以下条件评估和选择供应商： □重要性和影响：供应商提供的服务对业务的重要性。 □风险：与使用服务相关的风险。 □成本：服务及其提供的成本。

服务集成

服务集成（Service integration) 服务集成商（service integrator )负责协调所有参与产品和服务的开发和交付的供应商。它关注端到端的服务提供，确保控制来自供应商的所有接口和结果，并促进供应商之间的协作。 组织可以自己执行服务集成商的角色，也可以使用第三方服务集成商。开发一个混合模型是可能的，其中组织负责一些服务集成商功能，并使用外部服务集成商的功能来使其增强。 服务集成商功能也可以由主供应商来操作。服务集成商负责供应商的协调和保证。这包括绩效管理和报告、界定角色和责任以及在所有各方之间维持关系、领导定期论坛和指导委员会处理问题、商定优先事项和作出决定。

SIAM（服务集成与管理）简介

SIAMw（服务集成与管理）简介 SIAM生态系统（右图）； SIAM生态系统与多供应商管理办法的主要不同就是引进了“服务集成商”的概念

人力和人才管理

人力和人才管理实践目的

人力和人才管理(Workforce and talent management ) 人力和人才管理实践的目的是确保组织拥有具有适当技能和知识以及通过正确角色的合适人员来支持其业务目标。 通过帮助组织主动了解和预测未来的服务需求，人力和人才管理在建立组织速率方面起着至关重要的作用。它还确保具有必要能力的适当人员能够在适当的时间提供所需的服务。

人力和人才管理关键术语

人力和人才管理（2） 管理和开发组织的人力和人才的想法并不新鲜。然而，随着第三方供应商使用的增加和可重复工作自动化的快速采用，传统角色正在发生巨大变化。因此，人力和人才管理应该是整个组织各级领导和经理的责任。 关键术语和定义： √胜任力(Competencies）：可观察和可测量的知识、技能、能力和态度的结合，有助于提高员工的绩效，并最终导致组织的成功。 □技能（Skills）：在思想、语言交流或身体动作方面的熟练程度或灵巧程度。 □能力（Ability）：从事与某一职业或行业有关的体力或脑力活动的能力或才能。 □知识（Knowledge）：对一个人通过经验或教育获得的事实或信息的理解，对一门学科的理论或实践的理解。 □态度（Attitude）：对某一特定对象、人、事物或事件的一系列情感、信念和行为。

人力人才管理活动

人力和人才管理（3） 人力和人才管理活动 √这一实践的活动涉及广泛的领域，并为具体目的由各种角色执行，包括: □战略人力资源规划 □人才招聘 □绩效管理 □个人能力发展 □学习与发展 □指导和继任计划

ITIL管理实践之服务管理实践

可用性管理

可用性管理概述

可用性管理实践的目的是确保服务交付商定的可用性级别，以满足客户和用户的需求 可用性的定义：IT服务或其它配置项在需要时执行其约定功能的能力。

可用性管理活动内容

可用性管理（2） 可用性管理的活动包括： √谈判并达成可用性的可实现目标 √ 设计能够交付所需可用性级别的基础设施和应用程序 √ 确保服务和组件能够收集测量可用性所需的数据 √监控、分析和报告可用性 √计划改善可用性

可用性管理实践一

可用性管理（3） 简单地说，服务的可用性取决于服务失败的频率和失败后恢复的速度。这些通常表示为故障间隔的平均时间(MTBF)和恢复服务的平均时间（MTRS): √MTBE：度量服务失败的频率。例如，MTBF为4周的服务平均每年失败13次。 √MTRS：度量故障后恢复服务的速度。例如，一项服务的MTRS时间为四小时，平均而言，将在四小时内从故障中完全恢复。这并不意味着服务总能在四小时内恢复，因为MTRS是很多故障的平均值。

可用性管理实践二

可用性管理（4） 旧的服务通常使用非常高的MTBF进行设计，因此它们很少会失败。近些年来，我们已转向优化服务设计，以尽量减少（缩短）MTRS，使服务能迅速恢复。要做到这一点，最有效的方法是设计抗脆弱的解决方案，这些解决方案能够自动且非常快速地恢复，几乎不会对业务产生任何影响。对于某些服务，即使是非常短的故障也可能是灾难性的，对于这些服务，更重要的是集中精力加大MTBF。 许多组织根据MTBF和MTRS来计算可用性百分比，但是这些百分比很少与客户的经验相匹配，并且不适用于大多数服务。其它应考虑的事项包括: √哪些重要的业务功能受到不同应用程序故障的影响 √在什么情况下，缓慢的性能会导致服务无法有效使用 √服务什么时候需要可用，什么时候服务提供方可以进行维护活动

可用性管理实践三

可用性管理（5） 对某些服务有效的度量包括： 用户中断时间：计算方法是将事件持续时间与受影响的用户数量相乘，或将每个用户受影响的分钟数相加。 丢失交易数量：通过从预期在此期间发生的事务数中减去事务数来计算。 丢失商业价值：通过度量支持服务的失败对业务生产力的影响来计算。 用户满意度：服务可用性是服务最重要和最明显的特征之一，对用户满意度有很大的影响。

业务分析

业务分析实践概述

业务分析（Business analysig]) 业务分析实践的目的是分析业务或业务的某些元素，定义其相关的业务需求，并推荐解决方案来处理这些需求和/或解决业务问题，这必定促进为利益相关者创造价值。 分析和解决办法应以全面的方式进行，包括审议流程、组织变更、技术、信息、政策和战略规划。业务分析的工作主要由业务分析人员（BA)执行，尽管其他人也可能会做出贡献。 在IT中，业务分析实践经常应用于软件开发项目中，但是这种实践的工作通常也适用于更高层次的体系结构、服务和组织的服务价值系统。

业务分析要点

业务分析（2） 业务需求可以是功能性需求（Utility），也可以是非功能性需求（Warranty）。 非功能性需求的定义：典型的非功能性需求是从关键利益相关者和其它实践中获取的输入。组织的目标应该是管理一个预先定义的保证验收标准库，以便在项目管理、软件开发和管理等实践中使用。 功能性需求的定义：由客户定义的、特定产品特有的功能需求。

容量和(性能/绩效)管理

容量和性能/绩效管理概述

容量和性能/绩效管理（Capacity and performance management) 容量和性能/绩效管理实践的目的是确保服务达到商定和预期的绩效以成本效益高的方式满足当前和未来的需求。 绩效的定义对系统、人员、团队、实践或服务实现或交付的成果的度量。

容量和性能/绩效管理要点

容量和性能/绩效管理（2） 服务绩效通常与在一个时间框架中执行的服务数量以及在给定的需求级别上完成服务活动所需的时间相关联。服务绩效取决于服务容量，服务容量定义为配置项或服务可以交付的最大吞吐量。 容量和绩效管理实践通常涉及服务绩效和支持资源(如基础设施、应用程序和第三方服务)的绩效。在许多组织中，容量和绩效管理实践也包括人员的容量和绩效。 服务绩效和容量依赖于服务的组件，即应用程序、基础设施和其它服务的组件。

容量和性能/绩效管理补充

成本与容量；提供与需求；两个平衡 被动活动 √监视(Monitoring）√度量(Measuring） 主动活动 √预测将来的需求(Predicting future requirement) √预测趋势（Predicting trends）

变更实施管理

变更实施概述

变更实施（Change enablement） 变更实施实践的目的是通过确保风险得到了适当的评估（assessed,），授权（ authortzing）进行变更，并管理变更日程（schedule），从而最大化IT变更的成功率。 变更的定义：添加、修改或删除（ addition, modification, or removal）任何可能对服务产生直接或间接影响的内容。

变更实施注意事项

变更实施（2） 变更实施的范围由每个组织定义。它通常包括所有T基础设施、应用程序、文档、流程、供应商关系以及可能直接或间接影响产品或服务的任何其它内容。 区分变更实施和组织变更管理是很重要的。组织变更管理管理人员方面的变更，以确保成功地实施了改进和组织转换活动。变更实施通常集中在产品和服务的变更上 变更实施必须平衡进行有益的变更以交付额外价值的需求和保护客户和用户不受变更的不利影响的需求。所有变更都应该由能够理解风险和预期收益的人员进行评估，然后在部署之前进行授权。然而，这项评估不应造成不必要的拖延。

变更窗口

变更窗口（Change windows ) √一个规则的、协商好的时间，在这个时间实施变更或发布对服务的影响最小。

补救计划

补救计划（Remediation planping)_ 没有补救计划的变更是不应该被授权的： “补救”可能包括回滚（Back-gt），调用服务连续性计划或其它设许好的活动莱保近业务流程的持续；

变更实施的分型

变更实施（3） 授权变更的人或小组称为变更授权体（ authority）。为每一种类型的变更分配正确的变更授权体是至关重要的，以确保变更实施的有效性和高效性。在高速率的组织中，分散变更授权是一种常见的实践。 有三种类型的变更分别以不同的方式管理 标准变更（Standard change）：这些都是低风险的、预先授权的变更，这些变更都是易于理解的、文档完整的并且可以在不需要额外授权的情况下实现。 正常变更（Normal change）：这些变更需要按照标准流程进行计划、评估和授权。 紧急变更（Emergency change）：这些变更必须尽快实施，例如，解决故障或实施安全补丁。

变更日程

变更实施（4） 变更日程用于帮助计划变更，协助沟通、避免冲突和分配资源，在部署了变更之后，还可以使用它来提供故障管理、问题管理和改进计划所需的信息。 无论变更授权体是谁，他们都可能需要在整个组织中进行广泛的沟通。例如，风险评估活动可能需要他们从具有专业知识的许多人那里收集输入。此外，通常需要就变更进行沟通，以确保T人员和业务人员在部署更改之前做好充分准备。

变更实施补充

变更顾问委员会（Change Advisory Board-CAB) √在变更的评估、排定优先级和日程安排等方面向变更经理提建议的一群人（小组），这个委员会的人员通常由来自IT服务供应商、业务部门和第三方合作伙伴的代表组成；√ CAB也可以是有权利的那种，他们要批准变更，而不只是提建议。 没有无风险的变更（No change is without risk ) 补充PPT4（来自ITIL2011版） 紧急变更授权 Emergency CAB（ECAB) √紧急流程（Emergency processes） √ 由ECAB批准变更，而不是等待CAB会议； √ 测试可能减少，或者在极端情况下完全放弃测试； √ 归档，也就是更新变更记录和配置数据。但这个事情可能要延后做，一般是服务恢复正常后再做。

事件/故障管理

事件管理概念

事件/故障管理的目的是通过尽快恢复正常的服务运行，将故障的负面影响降到最低。 事件/故障的定义：服务的意外中断或服务质量的下降。

事件管理活动要点

故障管理可以对客户和用户满意度以及他们对服务提供方的看法产生巨大影响。应该记录和管理每个故障，以确保在满足客户和用户期望的时间内解决它们。 组织应设计其故障管理实践，为不同类型的故障提供适当的管理和盗源分配。必须有效地管理影响小的故障，以确保它们不会消耗太多的资源。影响较大的故障可能需要更多的资源和更复杂的管理。管理重大故障和管理信息安全故障通常有不同的流程。 有关故障的信息应存储在适当工具中的故障记录里。理想情况下，此工具还应该提供到相关配置项、变更、问题、已知错误和其它知识的链接，以支持快速有效的诊断和恢复。

事件管理的“补充”

原则和基本概念 √重大故障（ Major incidents） 就是一些优先级高的故障，需要单独的程序去处理，它的时间表会更短，紧急度会更高。 √ 故障状态跟踪（Incident status tracking) 开放（Open）—故障已经被识别，但还没有分派资源去解决它；” 进行中（In progress）一故障正在调查和解决中； 解决（Resolved）针对故障的解决方案已经提供，但正常的服务运营状态还没有得到业务或最终用户的确认： 关闭（Closed）一业务或用户已经认可故障已解决，正常的运营状态已经恢复。

故障升级（Incident escalation ) √ 职能性升级（Functional escalation ） 一旦服务台明确他们不能解决这个故障，就必须立即升级这个故一步的支持。 √层次性升级（Hierarchic escalation） 加果故障是一个严重故障（比如优先级是1的故障），那么适当级别的IT经理必须要通知到。如果故障的解决时间会比较长或者难度很大，也需要进行权力升级。

调查和诊断(Unvestigation and diagnosis) √弄清到底是哪里出了错； √理解故障的先后顺序； √确认故障的全部影响，包括所影响的用户的数量和范围； √ 识别可能触发了这个故障的任何事件； √通过搜索故障问题记录、KEDB或厂商/供应商的知识库来获得天于故障的详细知识。

解决和恢复（Resolution and recovery） √要求用户在他们的桌面或远程设备上直接采取行动； √服务台通过集中的或远程的方式实施解决方案； √要求专家支持小组去实施特定的恢复行动（例如重新配置一台路由器）； √要求第三方的供应商或维护人员去解决故障。

故障关闭(Incident closure） √关闭分类(Closure categorization）; √用户满意度调查（User satisfaction survey）; √故障归档(Incident documentation）; √目前还存在或可能再次出现的问题(Ongoing or recurring problem ）; √正式关闭（Formal closure）。

事件管理要点一

事件/故障管理 处理故障的人员要及时提供高质量的更新。这些更新应该包括关于症状、业务影响、受影响的配置项、完成的操作和计划的操作等信息。 根据故障的类型和复杂性，故障可以由许多不同组的人诊断和解决； √一些故障将由用户自己解决，使用自助； √一些故障将由服务台解决； √更复杂的故障通常会升级到一个支持团队来解决； √故障可能升级到供应商或合作伙伴，他们为其提供的产品和服务提供支持； √最复杂的故障，以及所有重大故障，通常需要一个临时的团队一起工作来确定解决方案； √在一些极端情况下，可能会调用灾难恢复计划来解决故障。

事件/故障管理 有效的故障管理常常需要团队内部和团队之间的高度协作。这些团队可能包括服务台、技术支持、应用程序支持和供应商。协作可以促进信息共享和学习，也可以帮助更有效地解决故障。 应该有一个记录和管理故障的正式流程。这个流程通常不包括如何诊断、调查和解决故障的详细程序，但可以提供使调查和诊断更有效的方法。 处理故障在每个价值链活动中都是可能的，尽管最具可见性的(由于对用户的影响)是运行环境中的故障。

IT资产管理

IT资产管理目的

IT资产管理实践的目的是计划和管理所有IT资产的完整生命周期，以帮助组织： √价值最大化 √控制成本 √管理风险 √支持资产的购买、重用和退役决策 √满足法规和合同要求

IT资产管理范围

IT资产的定义：任何有助于交付IT产品或服务的有价值的组件。 IT资产管理的范围通常包括所有软件、硬件、网络、云服务和客户端设备。在某些情况下，它还可能包括非IT资产，如具有财务价值的建筑物或信息，并且与交付IT服务有关。

监控和事态（Event）管理

监控和事态管理目的

监控和事态管理实践的目的是系统地观察服务和服务组件，并记录和报告所选的状态变化，这些变化被识别为事态。此实践确定基础设施、服务、业务流程和信息安全事态的优先级，并建立对这些事态的适当响应，包括对可能导致潜在错误或故障的条件的响应。 事态的定义：事态可以定义为对配置项(CI)或T服务的管理具有意义的任何状态改变。事态通常通过IT服务、CI或监视工具创建的通知进行识别。

监控和事态管理概述

监控和事态管理实践在整个生命周期中管理事态，以防止、最小化或消除它们对业务的负面影响。 实践中的监控部分聚焦在系统地观察服务和CIs，以发现可能具有潜在意义的情况。监控应该以高度自动化的方式执行，并且可以主动或被动地执行。实践中的事态管理部分着重于记录和管理那些被组织定义为事态的状态改变，确定它们的重要性，并识别和启动正确的控制行动来管理它们。 并非所有事态都具有相同的意义或需要相同的响应。事态通常分为信息性事态、警告性事态和异常性事态。

监控和事态管理活动一

信息事态在识别时不需要采取行动，但是在以后分析从它们收集的数据时，可能会发现对服务有益的、主动的步骤。 警告事态允许在业务实际经历任何负面影响之前采取行动，而异常事态则表明已经识别了对既定规范的违反，例如对服务级别协议的违反。 异常事态需要采取行动，即使业务影响可能尚未出现。

监控和事态管理活动二

自动化是监控和管理成功的关键。一些服务组件具有内置的监控和报告功能，可以对其进行配置以满足实践的需要，但有时需要实现和配置专门构建的事态监控工具。 监控可以是主动的，也可以是被动的。在主动监视中，工具将轮询检查CIs，查看其状态，以便在确定异常条件时生成警报。在被动监视中，CI本身生成运行警报。 还应该使用自动化工具来关联事态。这些特性可以由监控工具或其它工具(如ITSM工作流系统)提供。

问题管理

问题管理目的

问题管理(Problem management） 问题管理的目的是通过识别故障的实际和潜在原因，管理临时方案/度通方案（Workarounds）和已知错误（Known errors）来减少故障的可能性和影响。 问题和已知错误的定义： √问题是一个或多个故障的原因或潜在原因； √已知错误是一个已经分析但尚未解决的问题； 原则和基本概念 √问题（Problem） 一个或多个故障的原因 √变通方案（Work-around） 在一个完全的解决方案还没有开发出来之前，先用一个临的办法来降低和消除故障或问题的影响。 √ 已知错误（Known Error） 一个找到了根本原因，并给出变通方案或永久解决方案的问题

问题管理概述

问题管理（2） 每个服务都有可能导致故障的错误、缺陷或漏洞。在服务上线之前，会识别并解决许多错误。然而，有些问题仍未得到确认或解决，可能会对服务上线造成风险。在ITIL中，这些错误称为问题，由问题管理实践来解决。 问题与故障有关，但应加以区分，因为它们以不同的方式处理。 故障会对用户或业务流程产生影响，必须加以解决，以便能够进行正常的业务活动。 问题是故障的起因，它们需要调查和分析，以确定原因，制定临时方案，并建议更长期的解决方案。这减少了未来故障的数量和影响。 原则和基本概念 √故障Vs 问题 故障是一个IT服务非计划的停止或质量下降； 问题是从另外一个角度去看故障，它要查找故障的根本原因，而这个根本原因也可能造成了别的故障； 故障不会“变成”问题； 故障管理聚焦在把服务恢复到正常运营的状态； 问题管理聚焦在寻求一种方法去阻止故障的发生。

问题管理活动

问题管理涉及三个不同的阶段 9Problem identification);（Problem control）（Error control） 问题识别活动：识别并记录问题。 问题控制活动：包括问题分析，记录临时方案和已知错误。 错误控制活动：管理已知错误。已知错误是初始分析已经完成的问题，这通常意味着有缺陷的组件已经被识别出来。

问题管理活动说明

问题管理、风险管理、变更实施、知识管理和持续改进之间也有接口。 许多问题管理活动依赖于工作人员的知识和经验，而不是遵循详细的程序。

发布管理

发布管理目的

发布管理实践的目的是使新的和变更的服务和特性可用 一个发布可能包含许多不同的基础架构和应用程序组件，它们一起工作以交付新的或变更的功能。它还可能包括文档、培训（针对用户或IT人员）、更新的流程或工具，或任何其它必需的组件。

发布管理概述

发布的规模可以是非常小的(只涉及一个小的变更特性)，也可以是非常大的(涉及许多交付全新服务的组件)。在这两种情况下，发布计划都将指定要提供的新组件和已更改组件的确切组合，以及它们发布的时间。 发布计划用于记录发布的时间。这个时间表应该与客户和其他利益相关者协商并达成一致。 在某些环境中，几平所有的发布管理工作都是在部署之前进行的并且计划好了在特定的发布中部署哪些组件。

发布管理活动

发布管理通常是阶段性的，可以先向小规模的用户进行实验性的发布。以确保在向其它用户组发布之前所有的工作都是正确的。 发布阶段的实现通常使用蓝/绿发布或特性标志: √ 蓝/绿发布使用两个镜像生产环境。可以使用将用户连接到正确环境的网络工具，将用户切换到已经更新的环境。 √ 特性标志（Feature flags）允许以受控的方式向单个用户或组发布新的特性。新功能在没有发布的情况下部署到生产环境中。然后，用户配置设置根据需要将新功能发布给单个用户(或用户组)。

服务目录管理

服务目录管理目的

服务目录管理(Service catalogue management) 服务目录管理的目的是提供关于所有服务和服务提供的一致信息的单一来源，并确保相关受众可以获得这些信息。 服务目录中的服务列表表示当前可用的服务，是服务提供方的服务组合中跟踪的服务总列表的子集。 服务目录管理确保为目标众清晰地表达服务和产品描述，以支持利益相关者参与和服务交付， 服务目录可以采用多种形式，如文档、在线门户或工具，以便将当前的服务列表传达给受众。

服务目录管理活动

服务目录管理活动 √服务目录内的完整服务列表可能不适用于所有客户和/或用户。同样，服务的各种属性（如技术规范、产品、协议和成本）并不适用于所有服务使用者类型。这意味着服务目录应该能够向不同的利益相关者提供不同的视图和详细级别。例子的观点包括: □ 用户视图：提供有关可请求的服务的详细信息。 □ 客户视图：提供服务级别、财务和服务绩效数据。 □ IT客户视图：提供用于服务交付的技术、安全和流程信息。

服务管理（3）

要让客户组织认为服务目录是有用的，它必须做的不仅仅是为发布关于IT服务的信息提供一个静态平台。许多组织对服务目录的看法都集中在服务提供的可消费或可排序元素上，这些通常称为请求目录。

服务配置管理

服务配置管理目的

服务配置管理(Service configuration management) 配置项的定义：为了交付T服务而需要管理的任何组件。 服务配置管理实践的目的是确保在需要的时候和地方可以获得关于服务配置以及支持服务的CIs的准确和可靠的信息。这包括CIs如何配置以及它们之间的关系的信息。 服务配置管理收集和管理关于各种CIs的信息，通常包括硬件、软件、网络、建筑物、人员、供应商和文档。

服务配置管理活动

配置管理系统（CMS）的定义：用于支持服务配置管理的一组工具、数据和信息。 配置信息应该以受控的方式共享。一些信息可能是敏感的。例如，它可能对试图违反安全控制的人有用，或者它可能包括用户的个人信息，比如电话号码和家庭地址。 配置信息可以存储在整个组织的单个CMDB中并发布，但是更常见的是跨多个源分布配置信息。在任何一种情况下，维护配置记录之间的链接都很重要，这样人们就可以看到他们需要的全部信息，以及各种CIs如何协同工作。

服务连续性管理

服务连续性管理目的

服务连续性管理(Service continuity management) 服务连续性管理实践的目的是确保在发生灾难时，服务的可用性和绩效保持在足够的水平。 服务连续性管理通过确保在灾难或危机发生后，所需的信息技术和服务能够在所需的和商定的业务时间范围内恢复，从而支持全面的业务连续性管理(BCM)和规划能力。 当服务中断或组织风险的规模超过组织处理正常响应和恢复实践(如故障和重大故障管理)的能力时，将触发此实践。这种规模的组织故障通常被称为灾难。每个组织都需要了解在自己的环境中什么是灾难。在组织级和服务级使用业务影响分析（BIA），在触发事件之前必须考虑并定义灾难的含义。

服务连续性管理概述

服务连续性管理（2） 业务连续性协会（BCI）将灾难定义为：“……对一个组织造成巨大损害或严重损失的突然的、计划外的事件。”它导致一个组织无法在预定的最短时间内提供关键的业务功能。 触发灾难响应和恢复的来源是多种多样和复杂的，利益相关者的数量和潜在组织影响的不同方面也是如此。与表5.3中的示例相关的复杂风险管理条件要求全面考虑服务连续性管理实践，为灵活性而设计，并定期进行测试，以确保以业务生存所需的速度恢复服务。

服务连续性管理补充

？？恢复时间目标（RTO）的定义：恢复点目标（RPO）的定义： 灾难恢复计划（DRP）的定义 业务影响分析（BIA）的定义：

服务连续性管理对比故障管理

服务连续性管理 服务连续性管理Vs故障管理 √服务连续性管理关注于那些业务认为重要到足以被视为灾难的故障。次要故障将作为故障管理或重大故障管理的一部分来处理。灾难、重大故障和故障之间的区别需要预先确定、商定和记录，并有明确的阈值和触发器，以便在没有不必要的延误和风险的情况下，促使下一层的反应和恢复采取行动。 √随着组织越来越依赖于技术驱动的服务，对高可用性解决方案的需求已经成为组织弹性和竞争力的关键。组织通过业务规划、技术架构弹性、可用性规划、主动风险和信息安全管理以及故障管理和问题管理的组合来实现高可用性。

服务设计

服务设计的目的

服务设计（Service design) 服务设计实践的目的是设计适合于功用和功效，并且可以由组织及其生态系统交付的产品和服务。这包括计划和组织人员、合作伙伴和供应商、新产品和服务的信息、通信、技术和实践，以及组织和客户之间的交互。 如果产品、服务或实践不是设计出来的，它们不一定能满足客户的需求或促进价值创造。如果它们在没有适当的体系结构、接口或控制的情况下发展，那么它们就不能交付组织及其内部和外部客户的总体远景和需求。 在缺乏正式的服务设计的情况下，产品和服务的运行成本可能过高，并且容易出现故障，导致资源被浪费，并且产品或服务没有以客户为中心或没有进行整体的体系结构设计。

服务设计活动

服务设计（2) 服务设计实践还应确保客户从需求到价值实现的过程尽可能愉快和顺利，并尽可能交付最佳的客户结果。这是通过关注CX（客户体验）和UX（用户体验）实现的。 采用及推行以CX及UX为重点的服务设计实务，会: √以客户为中心的产品和服务，包括设计活动中的利益相关者 √包括考虑产品或服务的整个环境 √导致更高数量的成功变更 √让人们更容易采用和遵循设计方法 √允许跨项目和服务共享和重用服务设计资产

服务设计中的风险与风险管理

服务设计（3） 风险识别、评估和处理是所有设计活动的关键要求。因此，必须将风险管理纳入服务设计的一个集成方面。这将确保在提供产品和服务以及实践、技术和测量方法的操作中所涉及的风险与组织风险和影响相一致，因为风险管理是嵌入到所有设计过程和活动中的。

服务台

服务台实践目的

服务台（Service desk ) 服务台实践的目的是捕获对故障解决和服务请求的需求。它还应该是服务提供方与其所有用户的单一联络点（SPOC）。换句话说，它应该充当IT或服务组织的入口点/单一联系人。 服务台为用户报告问题（lssues）、查询和请求提供了一条清晰的路径，并将其确认、分类、拥有和执行。这种实践的管理和交付方式可能有所不同，从一个轮班工作的物理团队，到一个虚拟连接的分布式人员组合，或者自动化技术和机器人。无论模型如何，功能和价值都保持不变。 随着自动化程度的提高和技术债务的逐步消除，服务台的重点是为“人和业务”提供支持，而不仅仅是解决技术问题。

服务台要点

需要理解的关键一点是，无论服务台及其人员的效率有多高，总有一些问题（Issues）需要其他团队的升级和支持。 服务台可能不需要很高的技术含量，尽管有些是。然而，即使服务台相当简单，它仍然在服务的交付中扮演着重要的角色，并且必须得到它的对等组的积极支持。 好的服务台的另一个关键方面是它对更广泛的组织、业务流程和用户的实际理解。服务台应该是服务提供方与其用户之间具有同理心（empathy）和知情（Informed）的链接。

服务台活动

随着自动化程度的提高，人工智能、机器人流程自动化(RPA)和聊天机器人（Chatbots）的出现，服务台正逐步转向通过门户网站和移动应用程序提供更多的自助日志和解决方案。对服务台的影响是电话联系更少，低层次的工作更少，当需要个人联系时，更有能力专注于优秀的CX。 服务台提供了各种通道。这些包括: √电话通话，其中可以包括VR、电话会议、语音识别等专业技术 √服务门户和移动应用程序，由服务和请求目录以及知识库支持 √聊天，通过实时聊天和聊天机器人 √电子邮件可用于记录和更新，以及跟踪调查和确认 √免约式（walk-in）服务台在一些行业正变得越来越普遍，比如高等教育，那里的活动高峰要求员工亲自到场 √文本和社交媒体消息，在发生重大事件时用于通知和联系特定的利益相关者 √公共和企业社交媒体和论坛，用于联系服务提供商和对等支持

服务台活动具体呈现

一些服务台有一个有限的支持窗口，可以提供服务，例如08:00-20:00，周一至周五。因此，工作人员应按轮班方式工作，以提供一致的支持水平。 在某些情况下，服务台是一个有形的团队，在一个单独的位置工作。集中式服务台需要配套技术，如: √智能电话系统，集成了计算机电话系统、交互式语音响应和自动呼叫分发 √用于路由和升级的工作流系统 √劳动力管理和资源规划系统 √知识库 √电话记录和质量控制 √远程访问工具 √仪表板和监控工具 √配置管理系统（CMS ）

服务台活动其它

服务台（5） 另外，虚拟服务台允许代理从多个地理上分散的位置工作。虚拟服务台需要更复杂的支持技术，允许从多个位置访问，以及更复杂的路由和升级。这些解决方案通常是基于云的。 服务台的工作人员需要在许多广泛的技术和业务领域接受培训并具备相应的能力。特别是，他们需要展示优秀的客户服务技能，如同理心、故障分析和优先排序、有效沟通和情商。他们需要的关键技能是能够充分理解和诊断业务优先级方面的特定故障，并使用可用的技能、知识、人员和流程采取适当的行动来解决它。

服务级别管理

服务级别管理的实践目的

服务级别管理(Service level management) 服务级别管理实践的目的是为服务绩效制定明确的基于业务的目标，以便根据这些目标对服务的交付进行适当的评估、监控和管理。 服务级别管理提供组织服务的端到端的可见性。为此，服务级别管理: √ 建立与客户共享的服务视图和目标服务级别 √通过收集、分析、存储和报告已识别服务的相关指标，确保组织满足已定义的服务级别； √执行服务评审，确保当前的服务集继续满足组织及其客户的需求； √获取并报告服务问题，包括已定义的服务级别的绩效

服务级别管理要求

服务级别管理的技能和能力包括关系管理、业务联络、业务分析和商业/供应商管理。 这种实践需要实际地关注整个服务，而不仅仅是它的组成部分，因此，不应该使用简单的单个度量（例如系统可用性的百分数）来表示整个服务。

服务级别管理补充一

服务级别协议( Service Level Agreement -SLA) √是IT服务提供商（IT部门）与客户（用户）签署的一个协议。 SLA的架构 Service-based SLA（基于服务的SLA）；Customer-based SLA（基于客户的SLA）； Multi-level SLAs（多级SLA） 运营级别协议(Operational Level Agreement -OLA) √是IT服务提供商（IT部门）与内部其他部门（小组）签署的一项协议。 支持合同（Underpinning Contract-UC） √是IT服务提供商（IT部门）与第三方机构（厂商）签署的一个合同。

服务级别管理三

在许多情况下，使用单一的基于系统的指标作为目标可能导致服务伙伴之间的不一致和断开连接，从而影响服务交付和用户体验。例如，如果SLA仅基于服务正常运行时间的百分比，那么提供者可以认为它是成功的，但仍然会错过对使用者很重要的业务功能和成果。这就是所谓的“西瓜SLA”效应。

服务级别管理要点

服务级别管理需要专注和努力，参与并倾听客户的要求、问题、关注和日常需求： √需要参与来理解和确认来自客户的实际持续需求和要求，而不仅仅是服务提供方的解释或几年前达成的协议。 √倾听（Listening）作为一种关系构建和信任构建活动非常重要，可以向客户展示他们的价值和理解。这有助于使供应商摆脱总是处于“解决方案模式”，并建立新的更有建设性的合作关系。 这项工作是一个很好的机会来建立改善的关系，并把重点放在真正需要交付的东西上。它还为服务交付人员提供了基于经验的对使用其技术完成的日常工作的理解，使他们能够交付更侧重于业务的服务。

服务请求管理

服务请求管理目的

服务请求管理(Service request management) 服务请求管理实践的目的是通过以有效和用户友好的方式处理所有预定义的、由用户发起的服务请求，以支持商定的服务质量。 服务请求的定义：用户或用户的授权代表发出的请求，该请求发起已被商定为服务交付的正常部分的服务活动。

服务请求管理活动

服务请求管理（2） 每项服务请求可包括下列一项或多项: √对服务交付活动的请求(例如，提供报告或更换墨盒)； √信息请求(例如，如何创建文档或办公时间）； √请求提供资源或服务(例如，为用户提供电话或笔记本电脑，或为开发团队提供虚拟服务器)； √请求访问资源或服务(例如，提供对文件或文件夹的访问); √反馈、赞美和抱怨(例如，对新界面的怨或对支持团队的赞美)。 服务请求的履行可能包括对服务或其组件的变更，通常这些都是标准变更。

服务请求管理概述

服务请求管理（3） 服务请求是服务交付的正常组成部分，而不是由故障管理实践处理的服务故障或服务降级(Degradation）。 一些服务请求需要根据财务、信息安全或其它策略进行授权，而其它服务请求可能不需要任何授权。要成功处理服务请求，服务请求管理应遵循以下准则: √服务请求及其履行应该尽可能地标准化和自动化； √应制定关于在有限或甚至不需要额外批准的情况下将满足哪些服务请求的政策，以便简化履行工作； √用户对完成时间的期望应该基于组织实际交付的内容进行明确的设置； √应该确定和实施改进的机会，以更快地完成工作，并利用自动化的额外优势； √应该包括策略和工作流，用于记录和重定向作为服务请求提交的任何请求，但实际上应该作为故障或变更进行管理。

服务请求管理补充

服务请求管理（4） 一些服务请求可以通过从提交到关闭的自动化完全实现，从而实现完全的自助服务体验。示例包括客户端软件的安装或虚拟服务器的提供。 服务请求管理依赖于设计良好的流程和程序，这些流程和程序通过跟踪和自动化工具进行操作，以最大限度地提高实践的效率。 不同类型的服务请求具有不同的实现工作流，但是如果能够识别有限数量的工作流模型，那么效率和可维护性都会得到提高。 当需要将新的服务请求添加到服务目录中时，应该尽可能利用现有的工作流模型。

服务验证和测试

服务验证和测试目的

服务验证与测试(Service validation and testing ) 服务验证和测试实践的目的是确保新的或变更的产品和服务满足定义的需求。 服务验证(Service validation） √服务验证着重于建立部署和发布管理验收标准(产品准备就绪必须满足的条件)，这些标准通过测试进行验证。 √验收标准可以是通过理解客户、法规、业务、风险和安全需求而定义的功用或功效为重点的需求。 √本实践中的服务验证活动建立、验证和记录以功用和功效为重点的服务保证标准，并形成测试活动的范围和重点的基础。

服务验证与测试二

服务验证与测试（2） 测试（Testing） √ 测试战略定义了测试的总体方法。它可以应用于环境、平台、一组服务或单个服务。测试应该在内部开发的系统和外部开发的解决方案上平等地进行。 √ 典型地测试类型包括： 功用/功能测试（Utility/functional tests）：单元测试、系统测试、集成测试、回归测试等。 功效/非功能测试（Warranty/non-functional tests）：绩效和容量测试、合规测试、运营测试、保证需求测试、用户验收测试等。

ITIL管理实践之技术管理实践

部署管理

部署管理目的

部署管理( Deployment management) 部署管理实践的目的是将新的或变更的硬件、软件、文档、流程或任何其它组件移动（Move）到生产环境中，还可以将组件部署到其它环境中进行测试或展现。 部署管理与发布管理和变更实施紧密合作，但它是一个单独的实践。在一些组织中，术语“服务开通（ provisioning）”用于描述基础设施的部署，而“部署（deployment）”仅用于表示软件部署，但在这里，术语“部署（deployment）”用于同时表示这两种部署。

部署管理特征

部署管理（2） 可用于部署的组件应该在一个或多个安全位置进行维护，以确保在部署之前不修改它们。这些位置统称为软件和文档的最终介质库（DML），以及硬件组件的备件库。 支持部署的工具多种多样，它们通常与配置管理工具集成在一起，可以为审计和变更管理提供支持。大多数组织都有用于部署客户端软件的工具，这些工具通常与服务门户集成，以支持请求管理实践。 在单独的部署被发布之前，用户和客户通常不会对它们感兴趣。

部署管理活动要点

部署管理（3） 如果基础设施是作为服务提供的，则新服务器或变更的服务器、存储或网络的部署通常由组织管理，通常将基础设施视为代码（Infrastructure as a code），以便组织能够自动部署。 大多数组织都有一个用于部署的流程，这通常得到标准工具和详细过程的支持，以确保以一致的方式部署软件。对于不同的环境，使用不同的流程是很常见的。例如，可能有一个用于部署客户端应用程序软件的流程，以及一个用于部署服务器操作系统补丁的完全不同的流程。

基础架构和平台管理

基础架构和平台管理目的

基础架构和平台管理（ Infrastructure and platform management) 基础架构和平台管理实践的目的是监督组织使用的基础设施和平台。如果执行得当，这种做法可以监控组织可用的技术解决方案，包括外部服务提供商的技术。 IT基础架构是一种物理和/或虚拟技术资源，例如服务器、存储、网络、客户端硬件、中间件和操作系统软件，它们提供交付IT服务所需的环境。 基础架构和平台管理还可能包括组织用于运行其IT基础架构的建筑物和设施。 基础架构和平台管理实践包括提供支持为组织及其利益相关者创造价值的活动所需的技术。

云模式基础架构和平台分类

云服务模式（ Cloud service models） 软件即服务(Saas)：使用者可以使用在云基础设施中运行的应用程序，而不必控制甚至管理底层云基础设施。 平台即服务(Paas）：使用者可以部署到使用供应商支持的编程语言、服务、库和/或工具创建的云应用程序上，而无需控制甚至管理底层云基础设施。 基础设施即服务(laas)：使用者可以获得处理、存储和/或任何其它计算资源，而无需控制底层基础设施。

基础架构和平台管理活动

基础架构和平台管理（3） 云服务部署模式（ Cloud service deployment models) √每个服务模型都可以以多种方式部署，可以独立部署，也可以混合使用以下几种 方法： 私有云（Private cloud）：这种类型的云可能位于组织的内部或外部。它是一个云基础设施或平台，只由特定的组织使用。同时，可以有一个或多个使用者。 公有云（Public cloud）：这种类型的云位于云提供商那里。它是供开放使用的，并且可以由任何对使用它感兴趣的组织类型拥有、管理和操作。 社区云（Community cloud）：社区云可能由社区中的一个或多个利益相关者拥有、管理和操作，它可能存在于组织的场所内或场所外。 混合云（Hybrid cloud）：这个云基础设施是两个或多个不同的云基础设施(私有、社区或公有)的组合，它们仍然是唯一的实体，但是通过支持数据和应用程序可移植性的标准化或专有技术绑定在一起。 基础架构和平台管理（4） ITIL@实践与云计算（ITIL@ practices and cloud computing) √数十年来，云的出现一直是IT界最大的挑战和机遇之一。 √IT服务的管理和控制是IT部门的一项关键技能，无论这些服务在物理上位于何处，ITIL提供的流程和控制都很容易适应这些云服务的管理。 √除了基础架构和平台管理实践之外，基于云的服务的运营和管理还涉及许多其它实践。应当指出，这不是一份全面的清单。 基础架构和平台管理（5） 服务财务管理(Service financial management) √IT部门经常不得不为云计算做出的调整之一是改变他们的财政计划，这通常同时使用传统的资本支出(CAPEX)和运营支出(OPEX)。随着云计算的出现，人们现在更倾向于使用OPEX而不是CAPEX，因为云服务通常作为实用工具使用，并从运营预算中支付。 供应商管理（Supplier management) √ 这种实践的重点是要从简单地选择供应商并管理它们到让它们充当完整发布管理流程的前端。这将确保在新云产品上线之前，对T安全、数据保护和法规遵从性等领域进行常规评估。 基础架构和平台管理（6） 容量和性能/绩效管理（Capacity and performance management) √结合财务管理，这种做法应该建立和监控预算，跟踪阈值，并在需求上升导致云服务成本上升时发布警告。 变更实施(Change enablement) √这种实践的边界将不得不重新定义，因为云服务提供商通常在客户参与最少、几乎没有客户批准的情况下进行更改。 基础架构和平台管理（7） 事件/故障管理(Incident management) √这种实践的重点将从知道如何修复内部问题，转变为知道哪个云提供商支持哪个服务，以及它们需要什么信息来解决问题。需要更多地投入来支持受影响的客户和团队。 部署管理(Deployment management) √这个实践对IT部门来说将是持续重要的，但是能够安全地引入和去除云提供商将成为IT部门的常见需求。部署管理将是成功的IT组织的一项关键功能，可以确保快速部署新的云功能并将其嵌入到内部服务产品中。

软件开发管理

软件开发管理实践目的

软件开发和管理（Software development and management) 软件开发和管理实践的目的是确保应用程序在功能、可靠性、可维护性、合规性和可审核性方面满足内部和外部利益相关者的需求。 术语“软件”可用于描述从单个程序(或程序套件）到大型构造(如操作系统、运行环境或数据库)的任何内容，在这些构造上可以运行各种较小的应用程序、流程或工作流。因此，该术语包括但不限于桌面应用程序或移动应用程序、嵌入式软件(控制机器和设备）和网站。 软件应用程序，无论是由内部开发的，还是由合作伙伴或供应商开发的，对于在支持技术的业务服务中交付客户价值来说都是至关重要的。因此，软性开发和管理是每个现代T组织中的关键实践，确保应用程序的功用和功效。

软件开发和管理活动

软件开发和管理（2） 软件开发和管理实践包括以下活动: √解决方案架构 √解决方案设计（用户界面、CX、服务设计等) √软件开发 √软件测试（可以包括多个组件，如单元测试、集成测试、回归测试、信息安全测试和用户验收测试) √管理代码库，以维护产品的完整性创建包，以有效地部署应用程序 √小块代码的版本控制、共享和持续管理 软件开发和管理（3） 两种被广泛接受的软件开发方法被称为“瀑布”和“敏捷”方法。 软件管理是一种更广泛的实践，包括正在进行的设计、测试、运行和改进软件应用程序的活动，以便它们继续促进价值的创造。软件组件可以使用一个生命周期进行持续评估，该生命周期跟踪组件从构思到持续改进，最后是退役。

服务管理的四个维度

组织和人员

组织和人员 组织的复杂性正在增加，重要的是要确保组织的结构和管理方式，以及它的角色、职责、权限和沟通系统获得良好的定义，并支持它的总体战略和运营模型； 包含角色和职责、正式的组织结构、文化、以及组织需要的人员和能力； 都与服务的创建和交付改进相关； 组织的每个角色都清楚他们在为组织、客户和其它利益相关者，创造价值方面的贡献；

信息和技术

信息和技术 支持服务管理的技术包括但不限于工作流管理系统、知识库、 库存系统、通信系统和分析工具等； 服务管理从技术发展中取得进步； 使用云平台、云解决方案、远程协作、自动化测试和部署，已经成为服务提供者的共同实践； 信息管理的挑战，例如安全性和法规遵从性需求所带来的挑战， 也是这个维度的重点； 组织的文化和性质可能对其选择使用的技术产生重大影响。一些组织更感兴趣的是在技术进步的前沿。同样，一些组织的文化可能集中在更传统的工作方式上。

合作和伙伴和供应商

合作伙伴和供应商 每个组织和每个服务在某种程度上都依赖于其他组织提供的服务； 这些组织参与服务的设计、开发、部署、交付、支持 和/或持续改进； 它还包括本组织与其合作伙伴或供应商之间的合同和其他协议； 服务集成和管理是组织用来解决伙伴和供应商方面的问题的一种方法。

价值流和流程

价值流和流程 价值流和流程既适用于SVS。也适用于特定的产品和服务； 服务价值链运营模式具有通用性。概括了通过产品和服务的创建与管理，来响应需求和促进价值创造中所需的关键活动； 价值流：组织为创造和向消费者提供产品和服务而采取的一系列步骤； 流程：将输入转换为输出的一组相互关联或相互作用的活动。一个流程需要一个或多个已定义的输入，并将它们转换为已定义的输出。流程定义活动的顺序以及它们的依赖关系.； 组织应该检查它们如何执行工作，并映射它们能够识别的所有价值流。这将使它们能够分析它们的当前状态，并确定工作流和非增值活动(即浪费)的任何障碍。应该消除浪费的活动以提高生产力；

外部因素

外部因素 PESTLE是政治、经济、社会、技术、法律和环境的缩写，代表了制约或影响服务提供商运营的因素； 服务提供方不是独立运行的，受到许多外部因素影响，在动态复杂的环境中工作；外部的高度波动和不确定性，对服务工作者的工作方式施加约束； 数据保护法律、法规改变了企业必须收集、处理、访问和存储客户的数据的方式，以及他们与外部供应商或合作伙伴的合作方式。

ITIL 服务价值系统

服务价值系统概述

概念：①ITIL SVS描述了这个服务管理系统的输入、系统内元素以及输出; ②描述了所有组件和组件的活动，如何作为一个系统一起工作，并创造价值； ③SVS的输入是机会和需求。输出是价值，即感知到的利益、或有用的和重要的东西;

SVS组件： 指导原则：能够在任何情况下对组织提供指导，而不考虑其目标、战略、工作类型或管理结构的变化； 治理：一个组织被指导和控制的手段; 服务价值链：一种运营模式，通过产品或服务创建与产品或服务的管理，来响应需求和促进价值实现的关键活动； 实践：为执行工作或完成目标而设计的一组组织资源的“过程或活动” 持续改进：在所有级别上重复执行的组织活动，以确保组织的绩效持续满足利益相关者的期望。

机会、需求和价值

机会和需求触发ITIL SVS中的活动，这些活动导致价值的创造； 机会和需求总是进入系统，但是组织并不会自动接受所有的机会或需求所有的需求： 机会代表利益相关方增加价值或以其它方式改进组织的选项或可能性，同时，目前组织可能还没有对这些机会的需求，但仍然可以触发系统内的工作； 需求代表来自内部和外部客户对产品和服务的需要或者愿望；

ITIL的指导原则

指导原则的概述 ①指导原则任何情况下对组织提供指导，而不考虑其目标、战略、工作类型或管理结构的变化；指导原则是通用的、持久的； ②普遍适用于几乎所有的计划和所有与利益相关的群体间的关系； 指导原则（指导七原则）： ①关注价值；②从你所在的位置做起；③有反馈地迭代进展；④协作并提升可见性；⑤整体的思考和工作；⑥保持简单和实用；⑦优化和自动化；

指导七原则的描述 关注价值 组织所做的一切都需要直接或间接地映射到利益相关者的价值。 关注价值原则包含了很多视角，包括客户体验和用户体验。 从你所在的位置开始 不要从零开始，不考虑已经可用的东西就构建新的东西，当前的服务、流程、项目集、项目和人员很有可能被用来创建渴望的成果，应该直接调查和观察当前的状态，以确保充分了解它。 有反馈的迭代式进展 不要试图一次做所有的事情，即使是巨大的计划也必须迭代地完成。 在每次迭代之前、期间和之后使用反馈，将确保行动是聚焦的和合适的，即使环境在变化。 协作并提升可见性 跨界合作产生的结果更容易被接受，与目标更相关，并增加了长期成功的可能性； 达成目标要求的信息、理解和信任。避免隐藏的议程，并在最大程度上共享信息。 整体地思考和工作 没有服务或用于提供服务的元素是独立的。除非组织把服务作为一个整体来看待（而不是局部），服务提供者和服务消费者才能达成他们想要的成果。 结果通过有效和高效的管理和动态的集成（信息、技术、组织、人员、实践、合作伙伴和协议）传递给内部和外部客户，它们一起合作去提供定义的价值。 保持简单和实用 如果流程、服务、行动或指标不能提供价值或产生有用的结果，消除它。在一个流程或程序中，使用最少的必要步骤去达成目标。总是使用基于结果的思维来产生实际的解决方案去交付成果。 优化和自动化 所有类型的资源，尤其是人力资源，都应该得到最好的利用。消除任何真正浪费的东西，利用技术实现它所能实现的一切。人工干预应该只发生在真正有价值的地方。

治理

治理或治理体 每一个组织都是由一个治理体指导的， 治理体（一个人或一组人）对组织的绩效和合规性负有最高级别责任； 所有规模和所有类型的组织都在执行治理活动； 治理机构可能是董事会，或者在执行治理活动中扮演治理角色的执行经理； 组织（开展）治理是指导和控制组织的系统； 治理是通过评估、指导、监视实现的；

评估：对组织的战略、项目组合、以及其它各方关系的评估； 指导：治理体分配责任，并引导组织战略和政策的准备与实施； 监视：治理体监控组织及其实践、产品和服务的绩效。这样做的目的是 确保业绩符合政策和方向。

服务价值链

服务价值链概述： SVS的核心元素是服务价值链，这是一种运行模式，概述了通过，产品、服务的创建和管理，来响应响应需求及促进价值创造，所需的关键活动 。 六个价值链的活动是：①计划；②改进；③参与/联络；④设计和转换；⑤获取/构建；⑥交付和支持；

六个价值链描述 计划：这个价值链活动的目的是确保对组织中所有四个维度以及所有产品和服务的愿（远）景、当前状态和改进方向的共识； 改进：此价值链活动的目的是确保在所有价值链活动和服务管理的四个维度上持续改进产品、服务和实践； 参与/联络：这个价值链活动的目的是提供对利益相关方需求的良好理解、透明度以及所有利益相关方的持续参与和良好关系； 设计和转换：这个价值链活动的目的是确保产品和服务持续满足利益相关方对质量、成本和上市时间的期望； 获得/构建：这个价值链活动的目的是确保服务组件在需要的时候和地方是可用的，并且满足约定的规范； 交付和支持：这个价值链活动的目的是确保按照商定的规范和利益相关方的期望交付和支持服务；

持续改进

①发生在组织的所有领域和级别，从战略到业务运营都不断改进。为服务的效益最大化，每一个为提供服务作出贡献的人都应牢记不断改进， 并应始终寻找改进的机会； ②持续改进模型用与整个SVS，以及组织的所有产品、服务、服务组件和关系； ③ITIL 持续改进模型可以做为高级别指南

实践

实践是为执行工作或为实现目标而设计的一种资源组织 包含14个一般管理实践，17个服务管理实践，3个技术实践；

ITIL 4概述

现代世界的服务管理

服务是组织为自己和客户创造价值的主要方式

IT成为重要的业务驱动力和竞争优势的来源

IT服务管理定位成一个关键的战略能力

关于ITIL 4

ITIL 4框架的结构和收益

ITIL 服务价值系统（SVS）

四个维度模型

ITIL 4的相关知识

ITIL与ITSM

ITIL V2 简介

ITIL V3 简介（2011）

Lean（精益）

DevOps（开发运维一体化）

Agile（敏捷）

Smmary(小结)