AdvancedITIL: 服务支持度量标准

服务支持度量标准

配置管理

第 9 章

配置通常被认为是 ITIL 服务管理的核心，因为其他所有流程均需要使用配置管理数据库 (CMDB)。因此，CMDB 的准确性和及时更新至关重要。考虑到 CMDB 的重要性，发现配置管理具有管理报告和 KPI 就不足为奇了。在查看推荐的度量标准之前，我们应该提醒自己配置项 (CI) 是 CMDB 中的一项。首先，我们先从管理信息谈起：

  • 配置审核的结果。
  • 已检测到的所有未注册或未准确注册 CI 的信息和纠正措施。
  • 按 CI 的种类、类型和状态（也可能按位置或其他 CI 属性）细分的注册 CI 数量和 CI 版本的有关信息。
  • 增长和容量信息。
  • CI/CMDB 和 DSL（留存软件库）的变化率信息。
  • 因配置管理活动造成的配置管理工作的任何工作积压或任何延迟的详细信息以及提出的补救措施。
  • 配置管理人员配备原则。
  • 其他 IT 服务人员在上班时间之外完成的授权工作量。
  • 效率/效益复查、增长复查和配置管理系统审核的结果以及解决实际或潜在问题的建议。
  • 按数据类型（例如，服务、服务器、路由器、集线器、软件许可证、台式机等）分类的 CI 数量的有关数据和分析。
  • CI（或资产）值。
  • 按业务部门、支持小组或服务分类的 CI 位置。

正如您所见，管理信息主要涉及三个方面：CMDB 的准确性、CMDB 内容的分析和 CMDB 的维护人员。接下来我们了解一下各个度量标准。

配置审核的结果。ITIL 建议经常对 CMDB 进行审核，验证其内容是否符合实际。例如，如果一个部门有 50 个工作站，那么 CMDB 中就应有 50 个工作站，而且每个工作站的全部详细信息都应准确。ITIL 建议下述情况需要进行审核：

  • 实施新的配置管理系统之后不久。
  • 对 IT 基础设施进行重大变更之前或之后。
  • 软件发布或安装之前以确保环境满足预期要求。
  • 灾难恢复之后和“恢复到正常”之后（此审核应包含于意外事故计划中）。
  • 按照随意间隔审核。
  • 针对所有检测到的未授权 CI。
  • 按照固定间隔审核。

许多公司通过滚动式 审核计划来执行“快照”审核。这涉及到按计划的日程安排执行 CMDB 的“部分”审核，例如，1 月份审核服务器，2 月份审核电信，3 月份审核桌面软件。另外，如果有自动审核工具，ITIL 建议每周执行一次 CMDB 审核。在执行此审核时，您还应对事故数据库和故障数据库进行分析，确定是否所有记录都是由于一个 CMDB 问题而创建的。

另外，服务台应该立即报告服务台代理程序检测到的任何差异，例如，在故障分析时代理程序发现工作站实际安装的软件版本与 CMDB 中记录的版本不同。审核有助于确保 CMDB 保持准确。这是高质量服务管理的基本要素。另外，Sarbanes-Oxley 法案将 CMDB 准确性的重要性提升到了一个前所未有的高度。因此，在分发该报告之前，一定要突出显示审核中发现的任何不匹配的情况。将该审核结果分发给所有的 IT 经理。

  • 业务取向指标 — 根据 Sarbanes-Oxley 法案的规定，这可能是所有的 ITIL 服务管理流程中最重要的业务调整点。所有审核结果都应分发给有责任遵守 Sarbanes-Oxley 法案规定的关键业务经理，例如 IT 审核或内部审核团队的成员。审核结果也应分发给那些审核突出显示存在差异的业务经理。此外，业务经理应该能够对自己拥有或在其管理下的所有 IT 基础设施项进行审核。要执行自己的审核，业务经理必须能够查看与环境相关的所有 CI。

已检测到的所有未注册或未准确注册 CI 的信息和纠正措施。此度量标准衍生于前一度量标准中的审核。此处的关键不仅仅是提供数据，重要的是该度量标准还指定纠正措施。在编制该报告时，一定要记住将缺少的配置项 (CI) 包含在内。报告应该说明 CMDB 不准确的原因，以及避免同样不准确性重复发生应采取的措施。在编制该报告时，您还应对事故数据库和故障数据库进行分析，确定是否所有记录都是由一个 CMDB 问题引起的。此外，应该立即报告服务台代理程序检测到的任何差异，例如，在 CI 上而不是 CMDB 中出现需要解决的问题时。该报告的结果应该分发给关键业务经理，如有责任遵守 Sarbanes-Oxley 法案规定的审核团队成员，至少应该分发给报告中突出显示存在差异的业务经理。

  • 业务取向指标 — 根据 Sarbanes-Oxley 法案的规定，这是 ITIL 服务管理过程中另一个重要的业务调整点。确保负责遵守 Sarbanes-Oxley 法案的业务经理（如首席财务官）获得一份报告。

按 CI 种类、类型和状态（也可能按位置或其他 CI 属性）细分的注册 CI 数量和 CI 版本的有关信息。列有 CMDB 内容的报告中提供了该信息。您可以通过在线或打印方式提供报告。除了种类、类型和状态之外，按照该度量标准的陈述您可以利用符合您要求的其他种类进一步细分报告。您应该与其他所有的 IT 部门协商，确定他们是否需要按特定分组列出 CMDB，以及他们喜欢打印报告形式还是在线查看。此外，出于制定计划的目的，他们对整体信息要比详细信息更感兴趣。因此，您需要与其他 IT 部门协商，确定他们是需要详细的细分信息还是整体信息。所有 IT 部门都应该能获取该报告，同时有相应权限的所有人员都应该能够在线查看。

  • 业务取向指标 — 业务经理拥有自己环境中的 IT 设备，或者负责对其进行管理。总之，业务经理应该收到一份报告，或能够在线查看自己的 CI，这样他们才能够跟踪自己的配置项。确保所有的业务经理都可以看到该报告。

增长和容量信息。如果由于容量不足而导致 CMDB 不准确，这是不可原谅的。显而易见，容量管理应该负责计算和模型化 CMDB 的容量。这需要有指示当前 CMDB 大小、CMDB 可用空间数量的增长和容量信息，以及已知计划的新 CI 列表。确保为容量管理小组提供该信息。您还应将该信息提供给配置管理小组，以使他们能够跟踪日常容量，确保不出现令人不快的意外情况。您应在给定的时间内用图绘出 CMDB 的大小，说明 CMDB 的增长率。例如，您可以创建一个图形，显示过去 12 个月中数据库每个月的大小情况。除了容量管理和配置管理之外，其他 IT 经理都不可能需要该数据。不过，您需要与其他 IT 经理协商，确定他们是否对该报告感兴趣。

  • 业务取向指标 — 业务经理不太可能需要此报告。不过，他们可以提供有助于计算将来 CMDB 增长的数据。您应该要求所有的业务经理提供与将来增长相关的数据，或他们环境中的重大变更。

CI/CMDB 和 DSL（留存软件库）的变化率信息。因为该信息很大程度上取决于具体情况，因此可能很难确定为什么需要它。例如，如果您正在所有的工作站上安装新版本软件，您知道要进行许多变更。那么，为什么需要该信息呢？下面既是原因：将有关变更的信息（由变更管理提供）与 CMDB 中的变更信息进行比较，便可发现异常或不准确。配置管理通常会使用该信息，但变更管理也可以使用。该信息仅提供一个可用于管理参考的变化率列表，或者可用于突出显示变更问题。

  • 业务取向指标 — 除了已确定不准确变更所涉及的业务经理之外，其他业务经理不太可能需要该信息。

因配置管理活动造成的配置管理工作的任何工作积压或任何延迟的详细信息以及提出的补救措施。该度量标准十分重要；因为 CMDB 必须保持准确并反映 IT 基础设施的当前状态。该度量标准包含两个部分：因配置管理活动引起的配置管理工作积压和其他 IT 部门的延迟。

接下来我们了解一下第一部分 — 工作积压。引起更新 CMDB 延迟的原因可能多种多样，如管理决策有缺陷、事故解决延迟、变更迟缓和财务计算错误等。这正是及时报告配置管理工作积压的重要性所在，否则可能导致 CMDB 更新延迟。

该度量标准的第二部分是由于配置管理活动导致的延迟。例如，由于其他 CMDB 活动造成 CMDB 无法更新或仍未更新，这将导致该变更不得不延迟。另一方面，及时报告由于配置管理活动造成的任何延迟也十分重要。必须及时通知可能受延迟影响的 IT 经理。另外，及时将工作积压或延迟通知高级 IT 管理人员也十分重要。所提出补救措施的最后一项也十分重要。重要的是对报告的工作积压或延迟提出补救防止其再次发生。

  • 业务取向指标 — 您可能认为受到配置管理工作积压或活动所引起的延迟影响的业务经理应该了解该报告。此外，业务经理可能由于没有发布更新 CMDB 所需的信息而造成工作积压。因此，重要的是及时通知所有受延迟影响或由其造成延迟的业务经理。

配置管理人员配备原则。这是一个难题，因为它并没有明确定义“配置管理人员配置原则”度量标准。由于没有任何其他信息，我们必须假设它可以评估配置管理部门是否有足够数量的训练有素的员工。如果这种假设成立，该报告将成为一个显示已完成工作、计划的工作和可用人员数量的定期报告。根据该报告，可确定人员配备原则。该报告专供负责配置管理的高级 IT 经理使用。

  • 业务取向指标 — 只有负责配置管理的业务经理会对该报告感兴趣。

其他 IT 服务人员在上班时间之外完成的授权工作量。除了 IT 服务人员之外，其他人员可以定期更新 CMDB，作为配置项管理周期的一部分。例如，采购人员可在下订单时更新 CMDB；设备接收人员可在接收交付的新工作站时更新 CMDB；桌面服务人员可在安装工作站时更新 CMDB。正如前面提到的，总是存在可能造成短期内需要额外人员的异常：

  • 实施新的配置管理系统之后不久。
  • 对 IT 基础设施进行重大变更之前或之后。
  • 软件发布或安装之前为确保环境满足预期要求。
  • 灾难恢复之后和“恢复到正常”之后（此审核应该包含于意外事故计划中）。

上述所有情况都可能需要在短时间内完成对 CMDB 的大量更新。因此，CMDB 的维护人员可能需要在有限的时间内得到一些援助。理想情况下，IT 服务人员或其他经授权的人员应在工作时间内完成所有工作。因此，对“工作时间之外”完成的额外工作必须仔细跟踪，并采取措施确保将来所有的工作都能在工作时间内完成。您应该为工作时间之外完成的工作编制一份定期报告，然后将其发送给所有的 IT 经理，尤其是负责维护 CMDB 的 IT 经理。

  • 业务取向指标 — 任何负责更新 CMDB 的员工的经理一定会需要该报告。

效率/效益复查、增长复查和配置管理系统审核的结果以及解决实际或潜在问题的建议。这是先前许多管理信息度量标准的综合。理想情况下，您应该建立一个所有感兴趣方都能查看到此处所列全部项目结果的中心点，如企业内部网位置。

  • 业务取向指标 — 所有的业务经理应及时在线访问这一有价值信息的来源。

按类型（例如，服务、服务器、路由器、集线器、软件许可证、台式机等）分类的 CI 数量数据和分析。该管理报告中的信息似乎必须早已包含在其中，但此处的主要差异是“分析”这个词。之前我们讨论了“列表”和“整体信息”。接下来我们将讨论 CMDB 的分析。您应进行两类分析：定期计划分析和独特环境（如发布计划信息）所需的随即分析。您只能决定如何按照定期计划分析自己的 CMDB。您还必须建立一种 IT 部门可利用其请求对 CMDB 进行随即分析的方法。定期计划报告应该分发给所有的 IT 经理。即席报告只应分发给提交临时请求的经理指定的 IT 经理。

  • 业务取向指标 — 所有业务经理都应该获得一份定期计划报告。即席报告只应分发给由提交临时请求的经理指定的那些经理。

CI（或资产）值。此度量标准可能会由另一个称为 IT 服务财务管理的 ITIL 流程处理。如果您确实是在 IT 部门生成该报告，则必须根据该配置项中包含的财务属性生成报告。如果 CI 记录中已经包含财务属性，则可生成各种财务报告。不过，该要求仅涉及 CI 值和资产值。在您可以生成仅提供全部资产总值的报告时，更有价值的是提供一份展示各种 CI 类型总值的报告，如工作站值、膝上电脑值和台式机软件值。这可以生成更有意义的报告，提供有用的预算数据。该报告应该是定期报告，并应分发给所有负责 IT 资产管理的 IT 经理。

  • 业务取向指标 — 财务部门当然会对该报告感兴趣，或许其他某些部门（如采购部）也会对其感兴趣。如果报告按业务领域（如部门或分公司）显示资产值，则其也可能会引起业务经理的兴趣。与业务经理讨论他们喜欢哪种格式的报告，以及他们期望的报告周期。

按业务部门、支持小组或服务分类的 CI 位置。这是为计划和资产管理提供重要信息的简明报告。该报告应该是一份简单的报告，需要您的 CI 中有必需的属性，以便按位置列出 CI。请注意 CI 的设计，这样便可为该报告生成符合要求的详细信息。该报告是应该分发给所有 IT 经理的定期报告，尤其是在审核到期时。

  • 业务取向指标 — 这对所有业务经理来说是另一个很重要的报告。他们应该提供自己所负责管理的全部资产的定期报告。

这样，我们的配置管理就可以有一系列综合性管理报告，其中不仅有重要的 IT 和业务数据，而且还包含有助于公司履行法律义务的基本信息。这些报告中的许多数据将用于确定和验证关键绩效指标：

  • “配置”未经授权的场合。
  • 可以追溯到错误变更根源的事故和问题。
  • >由于影响评估较差、CMDB 中数据错误或版本控制较差而没有成功完成的变更请求 (RFC)。
  • 批准和实施变更的周期时间。
  • 已废弃或没有在特定位置投入使用的许可证。
  • 配置审核期间报告的异常。
  • 检测到的正在使用的未授权 IT 组件。

上述这些是清楚的 KPI，如果配置管理数据库要作为决策和管理计划的准确资源，就必须达到所有这些 KPI。接下来我们了解一下各个指标：

“配置”未经授权的场合。每次发现不准确的配置时，都说明未达到该 KPI。我们先前讨论的某些管理报告突出显示了配置不准确的场合。

  • 业务取向指标 — 每个业务经理都应该能够在需要时查看自己的配置，或至少能够查看自己的资产。如果发现他们的配置未经授权，您应该通知他们。只需要通知采用了未经授权配置的经理，除非您认为将此通知所有的业务经理可以提醒他们注意各自同样的配置问题。

可以追溯到错误变更根源的事故和问题。按照说明，此 KPI 似乎属于变更管理，但我们在这里讨论的是配置管理。如果我们添加“由于配置务管理问题”这几个字，陈述就会变得更合理。该 KPI 的目标是零事故和零问题。如果两者都不为零，则必须调查“原因”并采取措施防止事故和问题再次发生。

  • 业务取向指标 — 因错误变更引起的事故和问题而遇到不便的所有业务经理可能都已了解这个问题。然而，为了进一步确定，您应该通知受影响的业务经理，说明问题和事故的性质，最重要的是要采取措施防止问题和事故再次发生。

由于影响评估较差、CMDB 中数据错误或版本控制较差而没有成功完成的变更请求 (RFC)。如果所有的 RFC 由于配置管理问题都没有成功完成，届时这个问题就将成为一个严重问题，需要进行详细分析并采取推荐的措施。这是一个至关重要的 KPI，对高级 IT 管理人员来说，无法满足该指标意味着重大配置管理失败。该度量标准的目标必须是所有的 RFC 全部成功完成，而且未出现配置管理问题。

  • 业务取向指标 — 当然，任何因为配置管理问题而没有成功完成 RFC 的业务经理都知道该问题。然而，为进一步确定，您应该通知受到困扰的业务经理，说明 RFC 没有成功完成的原因，最重要的是要采取措施防止问题的再次发生。

批准和实施变更的周期时间。很难确定该 KPI 具体需要什么。每个变更都是唯一的，因此，各变更的周期时间也是唯一的。不过，每个变更周期的各个阶段都应该已计划好时间。必须满足这些周期时间。为使该 KPI 合理，我们将其诠释为“配置管理造成的批准和实施变更周期时间的延迟”。现在，我们有一个可以测定并且其成功率为零延迟的 KPI。您应该实施计划并采取措施，以便消除任何可能延迟变更周期的配置管理源。请注意，计划不周密不仅是配置管理中的弱点，而且可能会造成延迟。当 CMDB 需要大量更新以及误算工作量时通常会出现这种情况。在计划所有变更的过程中充分考虑配置管理，确保计划的时间和工作量切合实际。

  • 业务取向指标 — 在这种情况下，业务经理可能既是“受害者”，又是“犯错者”。如果业务经理的变更被延迟，那么他们就可能成为受害者。如果他们负责某些配置管理活动（如更新 CMDB），却无法兑现自己的承诺，那么他们就可能成为犯错者。有趣的是，一个业务经理可能因为另一个业务经理而延迟变更。例如，由于采购部门没有及时输入购买新设备的 CMDB 数据，因此财务部门提交的变更被延迟。通知所有受延迟影响的业务经理。

已废弃或没有在特定位置投入使用的许可证。因为许可证管理是发布管理的一部分，因此这个 KPI 似乎属于其他领域。那么，此处为什么需要这个 KPI 呢？因为配置管理的错误可能是造成许可证废弃或未使用的原因。例如，在某个审核过程中发布管理可能发现某些许可证没有使用，原因是配置管理没有正确更新 CMDB。另一个例子是，配置管理添加了工作站而没有通知发布管理，这将造成许可证不一致。我们可以再次添加“由于配置管理中的失败”这几个字使该 KPI 更贴切。该 KPI 应该为零；如果这个 KPI 不为零，那么您必须采取措施防止问题再次发生。

  • 业务取向指标 — 这是业务经理可能成为“受害者”和“犯错者”的另一种情况。如果他们不使用所有购买的许可证，那么他们就可能成为受害者。如果他们负责某些配置管理活动（如更新 CMDB），却无法兑现自己的承诺，那么他们就可能成为犯错者。这是某个业务经理可能对另一业务经理产生负面影响的另一个 KPI。通知所有受未充分使用许可证影响的业务经理，并与这些业务经理一起决定是否中止这些许可证以便节省预算资金。

配置审核期间报告的异常 — 该 KPI 没有说明我们应该寻找什么样的异常。但是，由于 CMDB 应该始终保持准确，因此我们可以安全地假设此处应注意出现的所有异常。该 KPI 应该为零，并应采取各种措施防止所报告的异常再次出现。

  • 业务取向指标 — 发现异常时应及时通知所有受其影响的业务经理，这样就不必将所有的业务经理都牵涉到该 KPI 问题中了。但是，您应该通知负责进行配置管理的业务经理以及导致异常发生的业务经理。这些业务经理也必须达到该 KPI。

检测到的正在使用的未授权 IT 组件。本节前面讨论的审核已经强调了所有使用的未经授权的 IT 组件。因此，此处不再进行分析，但必须报告检测到的任何使用的未经授权的 IT 组件。该 KPI 应为零。

  • 业务取向指标 — 只有受到影响的业务经理需要该 KPI 反馈，除非使用未经授权的 IT 组件时经过了他们的允许。这是一个严肃的问题，因为在基础设施和配置中引入未经授权的组件可能会引发严重的问题和延迟。此外，有些组件需要从 Internet 下载，因此可能引发安全问题，如病毒或黑客攻击等。因此，必须立即通知批准在配置中使用未经授权的 IT 组件的业务经理。

在配置管理章节的结束，ITIL 还介绍了其他可能有关的 KPI：

  • 服务台每月接到的电话中，涉及到用户拨打电话时问题即可解决而无需进一步拨打的电话所占的比率的变化。
  • 事故和问题在数量和严重性方面的变化。
  • 对无法立即解决的服务台电话进行诊断和解决的平均时间和成本的变化。
  • 当违反服务水平协议时（所犯的问题可追溯到出现错误的变更管理、配置管理、发布管理或服务台等功能），出现的问题的数量和严重性所发生的变化。
  • 由于错误可以在 CMDB 中确定，因此 CMDB 每月都有大量的变化。

正如您所见，这些 KPI 比以前讨论的 KPI 更具普遍性，但它们仍很重要。如果您最初只能处理少数几个 KPI，那么应该在开始时就实施上述的各 KPI。

现在，让我们看一下其他的配置管理 KPI：

服务台每月接到的电话中，涉及到用户拨打电话时问题即可解决而无需进一步拨打的电话所占的比率的变化。该 KPI 成功的标准是服务台可以连续接更多的电话，因为在用户拨打时问题即得到解决，无需进一步拨打电话。这意味着该 KPI 应逐月增长。理论上来讲，CMDB 越准确、越有综合性，服务台就越容易解决问题，从而有助于提高一级问题解决能力。如果水平降低，则应该进行调查。

有趣的是，水平降低并不总表示出现了问题。例如，一个问题导致了大量事故，消除该问题后的情形既是如此。帮助台的工作人员能够在第一次接到电话时就解决这些事故，因为他们有解决办法。消除问题会避免这些事故出现，同时也减少了第一次电话中要解决的事故数量。因此，一级解决问题的百分比将有所下降，但遇到问题的客户因问题及时解决会很高兴。

  • 业务取向指标 — 前面已经提到，服务台和业务群体通常赞成他们 SLA 中的“一级电话解决”标准。如果事情的确如此，那么业务经理就应该已经收到该 KPI。如果没有收到，那么您应该将其作为定期报告发给他们。

事故和问题在数量和严重性方面的变化。该 KPI 并没有说明变化应该增加还是应该减少。如果增加则需要调查，如果减少，通常不需要调查，除非是减少的幅度很大。对事故和故障数据库进行分析，确定事故和问题在数量和严重性方面的变化。如果您发现事故或故障数据库有变化，那么您应该立即开始调查，并采取措施以恢复到现状。在进行分析时，请记住这是针对配置管理所做的分析，因此任何与配置管理无关的数量和严重性增加都应该报告给相应的流程负责人，以便进一步调查和采取措施。如果增加与配置管理有关，那么您应该找出增加的原因并采取措施消除它。这是您应该定期监视的 KPI，最少每周一次。当然，任何变化都意味着未达到该 KPI。

  • 业务取向指标 — 大多数业务经理都不需要查看该分析结果，除非出现了数量增加或严重性变化。您应将该 KPI 分发给受影响的业务经理并与他们进行协商。

对无法立即解决的服务台电话进行诊断和解决的平均时间和成本的变化。这是另一个没有说明变化应该增加还是应该减少的 KPI。如果增加则需要调查，如果减少，通常不需要调查，除非是减少的幅度很大。人们通常对 IT 服务支持的批评是，事故无法在第一次拨打电话时解决而要花很长时间才能解决。这正是该 KPI 之所以重要的原因。

通常，事故数据库或服务台数据库会提供该信息，因此您应该每天都监视相应的数据库。在进行分析时，请记住这是针对配置管理所做的分析，因此任何与配置管理无关的数量和严重性增加都应该报告给相应的流程负责人，以便进一步调查和采取措施。不过，如果增加与配置管理有关，那么您就应该调查造成问题的原因并采取措施消除它。此处的任何变化都意味着未达到该 KPI。

  • 业务取向指标 — 大多数业务经理都不需要查看该分析结果，除非由于对无法立即解决的服务台电话进行诊断和解决的平均时间和成本发生变化，使他们受到了直接影响。您应将该 KPI 发送给受影响的业务经理并与他们进行协商。

当违反服务水平协议时（所犯的问题可追溯到出现错误的变更管理、配置管理、发布管理或服务台等功能），出现的问题的数量和严重性所发生的变化。这是适用于大多数服务支持流程的通用 KPI。立即调查各 SLA 故障，随时采取措施，防止故障再次发生。不过，该 KPI 需要有关数量和严重性发生的变化，由于可能已经调查了违背原因，因此变化可能不是非常相似。该 KPI 需要对数量和严重性进行定期比较，同时可能结合对将来的趋势分析。如果确定了一个趋势，那么应该立即对其进行调查。数量或严重性的任何变化都意味着未达到该 KPI。

  • 业务取向指标 — 当然，任何导致违背 SLA 的变化都必须报告给受影响的业务经理，说明原因和所有防止变更再次发生要采取的措施。

由于错误可以在 CMDB 中确定，因此 CMDB 每月都有大量的变化。许多 IT 人员和业务人员将 CMDB 用作参考源和决策工具。因此，保持 CMDB 的准确性至关重要。由于 CMDB 中可确定的错误应该保持在最低程度，因此可以确保 CMDB 每月有大量的变化，并且可以立即对任何数量增加进行调查。该 KPI 应该至少每周跟踪一次，最好是每天都跟踪。如果您进行定期检查并采取措施防止造成数量增加错误的再次发生，那么变化量会随着时间降低。如果数量增加，说明未达到该 KPI。如果降低，说明已经达到该 KPI。如果其保持不变，那么您必须判断是否达到该指标。

  • 业务取向指标 — 如果 IT 部门对 CMDB 执行全部更新和变更，那么大多数业务经理不会对该 KPI 感兴趣。不过，如果某些业务经理更新或使用 CMDB，那么他们一定需要该 KPI。

正如我们在配置管理章节一开始所做的讨论，管理该流程需要许多管理信息和 KPI。其中有些似乎重复，但准确的 CMDB 对技术和业务前提都至关重要。在技术领域，其为 IT 部门提供了关键的决策工具。在业务领域，不准确将导致严重的财务和法律处罚。这正是快速确定和纠正错误的本质。