# 制定针对性的改进计划基于评估中发现的薄弱环节，明确具体的改进目标和时间节点。分解改进目标为可操作的任务，并分配给相关责任人。
# 优化资源分配根据评估结果，重新调整人力投入。如果发现某个流程的人力不足导致效率低下，增加相应的人员配置。为重点改进领域分配更多的资金支持，用于技术升级、培训等。
# 培训与能力提升针对员工技能的不足，开展针对性的培训课程。假如员工在问题解决能力方面有待提高，组织相关的培训工作坊。鼓励员工自主学习和获取相关认证，以提升专业能力。
# 建立持续监测机制设定关键绩效指标（KPI）来跟踪改进措施的效果。例如，跟踪平均故障解决时间的变化。定期审查和更新 KPI，确保其与业务需求和改进目标保持一致。
# 沟通与协作在组织内部广泛传达评估结果和改进计划，确保全体员工理解工作的重点和方向。促进不同部门之间的协作，共同解决跨部门的 IT 服务管理问题。
# 与供应商合作如果评估结果表明某些服务依赖外部供应商，与供应商共同探讨改进方案。基于评估结果重新评估供应商的绩效和合同条款。
# 融入企业文化将 IT 服务管理的理念和要求融入企业文化，形成全员重视和参与的氛围。奖励在 IT 服务管理改进工作中表现出色的团队和个人，激励积极的行为。

*   1分：不知道*   2分：强烈不认同*   3分：部分认同*   4分：认同*   5分：强烈认同        通常国内公司和组织下信息中心部门的整体IT服务管理成熟度大于3，即所有评估的流程成熟度平均值大于3。    很多知名外企公司的整体IT服务管理成熟度甚至大于4.5。    通过此评估模型评测的公司可以这些优秀的公司作为标杆进行持续改进，尤其需要高度重视稽核项的条目打分为1或2的内容。

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