ITIL V3成熟度评估标准

参考ISO20000、ITIL、ITSS相关理论方法及最佳实践经验，较为完整的介绍ITIL-V3评估标准，包括服务策略（服务级别、财务管理、业务关系等）、服务设计（服务级别、容量、可用性、连续性、信息安全等）、服务转换（变更、发布）、服务运营（事件、服务请求、服务台）、持续改进（报告）等内容，购买版权后，导图将持续更新迭代丰富，敬请留意！

ITIL V3 成熟度评估标准

• 服务运营
  • 1、事件（故障）管理
    • 服务台是否有滿意度调查办法来度量服务的质量？
    • 具体的事件（故障）是否定被定义了不同的类型和优先级别？
    • 事件（故障）是否被定义了起始时间、受理时间和结束时间？
    • 有无对一线及二线支持范围进行明确的区分和定义？
    • 是否所有的事件（故障）都被记录。不存在有一些非正式的渠道使得用户能够绕过流程操作。比如，用户直接打电话给二线支持人员。
    • 用户是否被及时告知由其所提出的事件（故障）或服务请求的进展情况？
    • 当有无法达到服务级别协议要求（SLA）的时候，客戶是否被及时告知?
    • 所有参与事件（故障）管理的人员是否有权限存取相关的信息，包括已知错误和问题解決知识库等？
    • 在解决一个事件（故障）时，是否会先检查以前同样的事件（故障）是否发生过、如何解决的？是否与知识库关联？
    • 运营级别协议（OLA），以及具体的监控和升级办法
    • 当用户报告故障时，是否有用户等级，区分VIP用户，使VIP用户得到优先照顾？
    • 是否有适当的管理报表？比如：一线解决率等
    • 是否有专门机制处理影响度高的事件（故障），即重大故障处理流程？
    • 事件（故障）管理流程的关键绩效指标(KPI)有哪些？是否定期回顾？
    • 是否记录事件（故障）管理流程中需要改进的事项？采取改进措施并跟进，有服务改进计划或机制。
    • 是否区分事件（故障）管理和问题管理流程？从事件（故障）管理流程到问题管理流程是否有良好的信息流？
  • 2、问题管理
    • 所有已定义的问题是否已经开问题单并被详细记录?
    • 问题是否被定义了起始时间和结束时间？
    • 问题是否进行分类和优先级别？比如：类别、紧急程度、对业务的影响度和处理的优先级。
    • 是否有基于配置管理的问题影响度分析机制和办法
    • 是否定义了问题管理的范围，并和事件（故障）管理进行有效的区分？
    • 问题是否被发现造成问题的根本原因，并降低重复事件（故障）的比率？
    • 是否采取预防措施以降低潜在的问题？如日常巡检和帕累托图分析等
    • 是否定期推广问题分析方法（例如：5 Why分析法）和基于历史经验的知识分享？
    • 为了实现问题处理的有效性，是否对问题解決方法进行监控、审查和报告？
    • 是否建立问题解决后有效审核和关闭机制，如问题经理负责每个问题单的审核和关闭？
    • 运营级别协议（OLA），以及具体的监控和升级办法？
    • 是否有适当的管理报表？比如：问题按时解决率等
    • 有无对已知错误的管理及时控制？例如，把以前问题的解决办法放入运维知识库中，以备以后快速查询
    • 问题管理流程的关键绩效指标(KPI)有哪些？是否定期回顾？
    • 是否记录问题管理流程中需要改进的事项？采取改进措施并跟进，有服务改进计划或机制。
    • 问题管理与其它流程是否有必要的关联？例如，对已知错误的问题开变更请求，并把变更请求传递给变更管理流程？
• 服务转换
  • 3、变更管理
    • 是否清楚定义服务的范围，并形成必要的文件？(服务目录、SLA、CMDB的配置项和配置项的关系)
    • 变更管理的范围是否有明确的定义？例如，包括操作系统、应用、网络和设备的变更等。
    • 在变更提交前，是否检查和验证其完整性？
    • 是否所有的变更都有记录（包括被拒绝的变更）？
    • 是否对变更请求，就其风险、影响与商业利益进行评估? 如对系统容量、可用性和灾备的影响。是否对具体的变更的可行性分析与最终意见被有效的记录?
    • 变更是否按照其影响度和紧急程度分类？如定义重大变更和审批人员的级别
    • 是否所有的变更被成功执行，并有执行后的检查（Post Implementation Review）?
    • 变更单中是否包括在变更不成功时的回滚计划（Backout Plan）?
    • 是否对相应的政策来控制对紧急变更（Urgent Change）的授权与执行？
    • 是否清晰地区分正常变更请求（如：更新应用）与标准变更或服务请求（如：重置密码）之间的不同？对标准变更进行有效的范围定义
    • 变更记录是否被定期分析, 以侦测变更增加的程度、经常的反复的类型、紧急的趋势与其它相关联的信息?
    • 任何变更是否经过变更顾问委员会（Change Advisory Board）审批后方可执行？
    • 变更计划或变更窗口是否被有效定义？计划变更的日期是否作为真正制定变更时间表的基础？
    • 变更管理流程的关键绩效指标(KPI)有哪些？是否定期回顾？
    • 是否记录变更管理流程中需要改进的事项？采取改进措施并跟进，有服务改进计划或机制。
    • 是否与其他流程有信息交互？例如，与问题管理和配置管理的交互
  • 5、发布管理
    • 服务提供者是否与客户一起计划服务、系统、软件和硬件的发布？
    • 是否有效建立变更管理触发发布管理的机制？
    • 是否建立相关变更单和发布单的关联？
    • 发布管理流程是否包含当发布不成功时的回滚计划（Backout Plan）？
    • 发布管理流程是否包含对配置管理数据库（CMDB）中的配置项的变更？
    • 变更請求是否被评估其对于发布计划的影响？
    • 发布是否按照其影响度和紧急程度分类？制定不同发布的审批人员级别
    • 是否对相应的政策来控制对紧急变更（Urgent Release）的授权与执行？
    • 发布记录是否被定期分析, 以侦测发布增加的程度、经常的反复的类型、紧急的趋势与其它相关联的信息?
    • 任何发布是否经过发布评审委员会审批后方可执行？
    • 发布计划或发布窗口是否被有效定义？计划发布的日期是否作为真正制定发布时间表的基础？
    • 是否衡量在发布期间与该发布相关的异常事件所造成的影响？
    • 是否所有的发布被成功执行，并有执行后的检查（Post Implementation Review）?发布的成功与失败的条件是否可以被衡量？
    • 发布管理流程的关键绩效指标(KPI)有哪些？是否定期回顾？
    • 是否记录发布管理流程中需要改进的事项？采取改进措施并跟进，有服务改进计划或机制。
    • 发布管理流程是否与配置管理以及变更管理流程之间产生关联?
  • 4、配置管理
    • 是否清楚定义配置管理所管理的范围，并形成必要的文件？如服务目录和配置管理数据库（CMDB）的流程文档
    • 是否存放服务资产的配置项在配置管理数据库中？
    • 是否有一份明确定义的组件命名规范？是否所有相关的设备都有明确的标签？
    • 配置管理数据库的结构有能够预防重复输入的机制。确保配置信息的正确性和唯一性
    • 配置项与配置项之间的关系都被有效的定义
    • 配置管理是否提供对配置项的版本控制和追踪？
    • 是否配置项之变更遵循变更管理流程？对配置项之间的关系进行跟踪控制
    • 配置管理数据库是否被有效管理以确保配置数据的安全的、可靠性和正确性？
    • 被授权的有需要提取配置项信息的使用者是否可以取得配置项的状态、版本、位置和相关变更信息?
    • 是否有配置管理数据库的年度（或定期）稽核報告?
    • 配置稽核报告中是否记录任何配置项的缺陷、采取矫正措施和报告最终结果？
    • 是否应用配置管理自动发现工具和配置项变更的预审批机制？
    • 是否有一系列控制环节来保障配置管理流程不被绕开？
    • 配置管理流程的关键绩效指标(KPI)有哪些？是否定期回顾？
    • 是否记录配置管理流程中需要改进的事项？采取改进措施并跟进，有服务改进计划或机制。
    • 是否与其他流程有信息交互？例如，与事件（故障）管理、问题管理、变更管理和发布管理的交互
• 服务战略
  • 11、财务管理
    • IT服务提供商或组织是否清晰的理解这个流程？
    • 是否定期对这个流程的活动进行回顾？
    • 是否有电子化的工具提高此流程的执行效率？
    • 是否有足够的时间和成本来针对此流程进行培训？
    • 是否依据预算进行成本之监控与报告？定期对预算和成本进行比对。
    • 是否有成本模型（Cost Model）或其他机制很容易的给客户或业务部门展示IT的运营成本？
    • 任何成本变更是否经过变更管理流程进行成本分析与核准？
    • 是否定期举行财务审计？
    • 是否对不同成本类型进行有效区分，如固定成本、直接成本和非直接成本等。
    • 是否财务报表简单和容易理解？
    • 是否制定有效的服务收费策略和收费原则？
    • 是否财务数据被其他管理流程有效的利用，比如发布管理和变更管理流程等。
    • 是否理解成本中心和利润中心的区别？
    • 财务管理流程的关键绩效指标(KPI)有哪些？是否定期回顾？
    • 是否记录财务管理中需要改进的事项？采取改进措施并跟进，有服务改进计划或机制。
    • 财务管理的关键绩效指标(KPI)是否已经纳入服务级别管理的管理范畴?
  • 14、业务关系管理
    • 当有服务级别协议或合同有相关内容需变更的，是否有开变更单，并在客户同意下按照变更管理流程来跟进直至完成？
    • 客戶投诉的处理结果有没有及时告知客戶？
    • 是否有记录、调查、回应、报告并正式关闭所有的服务投诉或抱怨？
  • 15、管理体系
    • 管理者是否建立服务管理的方针、目标和计划？
    • 是否定义并保持所有服务管理者的角色和职责以及有效履行这些角色和职责所需的能力？
    • 是否评审管理人员的能力，以确保他们能够有效履行角色和义务？
  • 17、新服务变更后的服务管理
    • 是否有考虑由服务交付和管理所导致的成本，以及组织的、技术的和商业的影响？
    • 新的或变更服务的实施（包括服务中止），是否有进行策划并经过变更管理者的正式批准？
    • 是否有被服务提供方或客户所正式接受的流程?
    • 服务提供方应根据策划的安排。在新的或变更的服務实施后应及时报告所取得的效果
    • 是否有通过变更管理流程对计划的实施后的服务进行评审，即将真实的效果与计划相比较？
• 13、持续改进管理
  • 服务改进是否有记录、评估、授权和排定优先级顺序？
  • 是否有使用服务改进计划来控制服务改进活动？
  • 服务提供方实施过程改进，是否有纠偏和预防潜在问题的措施？
  • 是否有根据历史绩效数据应用控制图等工具推测未来绩效的趋势
  • 16、服务报告
    • 是否有满意度调查报告？是如何做到的？
    • 服务报告是否符合服务级别协议度量的需要，客戶的具体要求是否得到明确的回应和体现?
    • 服务报告是否包含对应服务级别协议所要衡量的绩效指标的度量结果？
    • 服务报告是否包含不符合服务级别协议的违背事项？
• 服务设计
  • 9、服务级别管理
    • IT服务提供商或组织是否清晰的理解这个流程？
    • 量化的KPI指标是否有在服务级别协议（SLA）中体现？
    • 是否定期对这个流程的活动及关键绩效指标（KPI）进行回顾？
    • 是否有标准的服务级别协议（SLA）合同模板并有效应用？
    • 是否第三方供应商的合同指标也被纳入服务级别管理的范畴并有效监控？
    • 是否服务目录被有效的定义来反映组织的服务范围？
    • 是否有电子化的工具提高此流程的执行效率？
    • 是否有足够的时间和成本来针对此流程进行培训？
    • 是否有定期的服务会议讨论服务级别的达成情况和未来可能的服务级别需要（SLR）？
    • 所有相关各方是否有定期评审服务级别协议文档的内容（一般每年一次），以确保服务级别协议的及时更新和持续有效?
    • 针对监控结果是否有报告反馈并评审不符合的原因?
    • 是否在客户或业务部门与IT部门之间建立有效的沟通渠道和沟通机制？
    • 是否所有的服务级别协议合同文档被客户或业务部门签署后执行？
    • 服务级别协议（SLA）的达成质量是否按照与客戶签订协议所应遵循的目标加以监控？
    • 是否记录以及识别需要改进计划（SIP）和改进的事项？并及时跟进
    • 任何新的服务很容易的被纳入服务级别管理的范畴？
  • 6、可用性管理
    • IT服务提供商或组织是否清晰的理解这个流程？
    • 是否定期对这个流程的活动进行回顾？
    • 是否有电子化的工具提高此流程的执行效率？
    • 是否有足够的时间和成本来针对此流程进行培训？
    • 任何对于可用性计划的变更，是否都经过变更顾问委员会评估其影响，并得到有效授权后方可变更？
    • 可用性的具体数据是否被衡量与记录，并作为服务报告的一部分来定期公布?
    • 可用性管理的是否提供变更影响分析的数据作为变更管理流程的输入？
    • 是否定期对当前基础架构的可用性进行评估和优化？
    • 是否对由于系统不可用而造成的直接或间接损失进行计算？
    • 是否对高可用性管理的成本花费与其带来的业务收益进行比较？
    • 定期的变更窗口是否已经被客户和业务部门所接受？
    • 是否有一个公认的流程来处理重大系统不可用所造成的根源分析？
    • 可用性的历史数据是否被用来做趋势分析来定位未来可能存在的可用性的问题？
    • 可用性管理流程的关键绩效指标(KPI)有哪些？是否定期回顾？
    • 是否记录可用性管理中需要改进的事项？采取改进措施并跟进，有服务改进计划或机制。
    • 可用性管理的关键绩效指标(KPI)是否已经纳入服务级别管理的管理范畴?
  • 10、容量管理
    • IT服务提供商或组织是否清晰的理解这个流程？
    • 是否定期对这个流程的活动进行回顾？
    • 是否有电子化的工具提高此流程的执行效率？
    • 是否有足够的时间和成本来针对此流程进行培训？
    • 监控报告有没有定期发送给使用人员？
    • 每月定期召开技术研讨会？
    • 是否容量管理相关的数据记录到容量管理数据库（CDB）中？
    • 是否有评估新的服务或现有服务的变更请求对服务容量的影响？任何针对IT环境的变更都需要走变更管理流程。
    • 是否能预测工作量和环境的变化？是否包含足以进行预测分析的资料与流程？
    • 是否有对改变IT服务环境以及商业需求预期影响的分析和应对机制，例如政府的法规，行业的规范等。
    • 是否有尝试影响用户的使用行为，使其更多的在非高峰时间段使用？
    • 是否每一个独立的服务的容量监控阀值被有效的设置和合理的监控？并帮助解决服务的故障或问题。
    • 是否对业务容量、服务容量和资源容量管理进行有效的区分和管理？
    • 容量管理流程的关键绩效指标(KPI)有哪些？是否有包含当前与预测的容量及绩效要求？是否定期回顾？
    • 是否记录信息容量管理中需要改进的事项？采取改进措施并跟进，有服务改进计划或机制。
    • 容量管理的关键绩效指标(KPI)是否已经纳入服务级别管理的管理范畴?
  • 7、服务连续性管理
    • IT服务提供商或组织是否清晰的理解这个流程？
    • 是否定期对这个流程的活动进行回顾？
    • 是否有电子化的工具提高此流程的执行效率？
    • 是否有足够的时间和成本来针对此流程进行培训？
    • 是否有定期的业务影响分析（BIA）评估服务中断对业务的影响范围和影响级别？
    • 服务连续性计划即灾难恢复计划（DRP）有有效的文档记录，并被所有涉及的服务部门熟知。以备未来不时之需。
    • 任何对于服务连续性计划或灾难恢复计划的变更，是否都经过变更顾问委员会评估其影响，并得到有效授权后方可变更？
    • 服务连续性计划或灾难恢复计划是非被有效测试以符合商业需要？
    • 是否重要的业务数据被定期的备份和安全的存放？
    • 是否对服务连续性管理的成本花费与其带来的业务收益进行比较？
    • 是否IT服务连续性管理（ITSCM）是业务连续性管理（BCM）的一部分？
    • 对不同的灾备方案是否有很清晰的理解和识别？比如热备和冷备方案等
    • 是否对服务连续性计划即灾难恢复计划（DRP）进行定期的演练和问题跟踪？如每半年做一次灾备演练
    • 服务连续性管理流程的关键绩效指标(KPI)有哪些？是否定期回顾？
    • 是否记录服务连续性管理中需要改进的事项？采取改进措施并跟进，有服务改进计划或机制。
    • 服务连续性管理的关键绩效指标(KPI)是否已经纳入服务级别管理的管理范畴?
  • 12、供应商管理
    • IT服务提供商或组织是否清晰的理解这个流程？
    • 是否定期对这个流程的活动进行回顾？
    • 是否有电子化的工具提高此流程的执行效率？
    • 是否有足够的时间和成本来针对此流程进行培训？
    • 供应商的资质和历史绩效信息是否记录到供应商管理数据库中
    • 是否对供应商的绩效进行评估，评估的依据是什么？
    • 对供应商评定等级的方式如何？如长名单和短名单供应商之分。
    • 是否有机制选择最适合或最优秀的供应商？并且有供应商淘汰机制。
    • 是否签订第三方供应商合同（UC）?
    • 对于与供应商签订的第三方供应商的协议指标是否能满足企业对客户的服务级别协议指标的要求？
    • 是否至少每年进行一次对供应商合约或正式协议的审查和续约（Renew）？
    • 若有合约和相应的第三方供应商合同或协议的变更，是否经由变更管理流程来管理？
    • 是否有处理合约争议的流程？
    • 供应商管理流程的关键绩效指标(KPI)有哪些？是否定期回顾？
    • 所识别的需要改善或跟进的措施是否被记录，并且作为服务改善计划的输入？
    • 供应商管理的关键绩效指标(KPI)是否已经纳入服务级别管理的管理范畴?
  • 8、信息安全管理
    • 是否制定安全策略标准？
    • 是否清晰的知道哪个部门负责IT安全管理？
    • 是否有机制阻止非授权的人员访问敏感的IT设备和关键数据？
    • 是否业务对安全的要求被有效的记录？
    • 是否高层管理团队及其员工有必要的承诺对组织的数据进行保密？如签署保密协议
    • 是否存在IT安全管理计划，并定期对此计划进行评审和改进？
    • 是否定期进行内部或外部的安全审计？
    • 是否有清晰的步骤来处理安全的违背行为？
    • 是否有电子防范设备有效的阻止电子攻击？如防火墙、IDS和IPS等
    • 组织成员是否意识到保护IT资产和信息安全的重要性，并有效遵守？
    • 安全的违背和攻击事件是否被记录到服务报告中？
    • 任何对于安全策略的变更，是否都经过变更顾问委员会评估其影响，并得到有效授权后方可变更？
    • 是否信息安全管理团队和服务连续性管理团队建立有效的沟通渠道？
    • 信息安全管理流程的关键绩效指标（KPI）有哪些？是否定期回顾？
    • 是否记录信息安全管理中需要改进的事项？采取改进措施并跟进，有服务改进计划或机制。
    • 信息安全管理的关键绩效指标（KPI）是否已经纳入服务级别管理的管理范畴?