KPI Miran技术支持

他问道：“你碰巧遇到这样一个红脸，三只眼睛和一条头骨项链的朋友吗？”
“谁在篝火之间跳舞？” ?？ 这样还高吗？ 挥舞着军刀曲线？
他礼貌地说：“也许有，我不明白你在说谁。” 您知道，非常常见的功能。 任何人都可以。

维克托·佩列文（Victor Pelevin），《恰帕夫与虚空》

哈Ha！ 我叫Alexander Solovyov，我负责Miran数据中心的技术支持。

不久前，我参加了一个有趣的会议，专门讨论KPI技术支持。 通常，就分享经验而言，这是一个有用的事件。 但是，尽管如此，仍然存在一些“不完整性”。 原因首先是活动的参与者分享了他们的经验，我和他们都没有总结任何概括甚至结果。

该活动由SUPNET技术支持社区组织，根据其官方页面上2018年9月的最新出版物“进入了必杀技”。

因此，我自由地分享了我的最佳实践，并尝试根据我的经验总结当时的看法。

因此，如果我们将技术支持视为“黑匣子”，那么我们可以这样说：该箱子执行有用的功能，将非正式的支持请求转换为正式的完整应用程序。 包装盒具有一定的性能，完成的订单对应于给定的质量水平，包装盒的操作对我们来说非常昂贵。

通常，这是您需要了解的有关KPI技术支持的全部信息，但是，如果您对详细信息感兴趣，欢迎来到Kat。...我在那里被邀请向所有人开放，我承诺向他们介绍知识水平指数。

因此，KPI分为三组：

• 绩效指标-反映达到一定结果的成本效益，例如工程师的平均工资。
• 绩效指标-实际上是“进度条”，例如，报告期内违反对应用程序的反应时间的百分比。
• 绩效指标-业务活动的重要指标，例如，报告期内技术支持请求的数量。

绩效指标

我将从效率开始。

1. 技术支持工程师的平均工资；
   
2. FRT-首次响应应用程序的平均时间；
   
3. ART-平均提前期；
   
4. MTTR是平均修复时间。
   

工程师的平均工资

因为我们的工资是计件工资，所以该指标的意思是向管理层表明，以我们总的话来说，是技术支持工程师的工资资金。 在通过非财务动机实现薪资资金的“平衡”后，该指标已变得不那么重要了，但总体上仍在考虑之列。 我将补充说，指标值是针对每个技术支持线计算的，这使我可以随时掌握最新信息，并在必要时调整下个月的计件工资率。

FRT /艺术

这两个指标均从SLA（服务水平协议）中“增长”。 根据SLA，如果超过了FRT / ART，则客户有权重新计算降级服务的付款金额。 我认为这些指标的含义与医院的平均温度相似。 实际上，指数的好处并不多，唯一的好处是它们使公司管理层了解SLA中规定的指标已基本实现。 违反反应时间/应用程序执行的百分比更为有用；这些指标使您可以在技术支持下快速而清晰地评估处理应用程序的动态。

MTTR

该指标在狭窄的范围内广为人知（又名IRT-事件解决时间），在我们的情况下，该指标的平均使用时间很小，因为我们公司提供的服务性质上存在很大差异。 也许将来我们会针对每种产品分别考虑MTTR。 但是，由于这是一个非常知名的指标，因此我们考虑一下。

绩效指标

让我们继续前进。

1. EKi-员工知识指数；
   
2. CSi-客户对服务的满意度指数；
   
3. FRTR-违反治疗反应时间的百分比；
   
4. ARTR-违反提前期的百分比。
   

CSI

客户满意度指数是数字化的客户反馈，即 客户对收到的服务质量的意见。 指数的计算完全基于我们在完成每份申请后收到的客户的主观评估。 CSi是最重要的指标，对于每个人来说都是最易懂和最相关的指标。 与以前的指标不同，其计算方法很明显，我将详细介绍我们的CSi计算方法。

索引值取决于三个参数：

1. 循环反应时间，t ₁ ；
   
2. 申请决定时间，t ₂ ；
   
3. 应用程序决策的质量，q。

计算CSi的公式如下：

$$

$$CSi = \ frac {3} {（{t_1} ^ {t_1} + {t_2} ^ {t_2} + {q ^ q}）}$$

下表中列出了可能的参数值范围。

根据下表解释结果值。

ki

员工知识水平指数显示员工的知识是否对应于技术支持工程师可接受的最低可接受水平。 使您可以不停地谈论工程师的不完整，以向公司管理层展示技术支持工程师的能力和准备工作。 该指数不太适合工程师，但适合管理人员和我们的PR专家。

指标的计算基于通过定期检查工程师知识所获得的客观数据，这些数据是通过模拟建模的方法（即称为用户案例的典型情况的解决方案）进行的。 谁在乎，我在KnowledgeConf 2019上谈到了更多技术支持中的知识管理。
在我们公司中，EKi计算为该期间成功完成的用户案例与用户案例总数之比。

$$

$$EKi = \ frac {U_w} {U_a}$$

在哪里
U _w-在报告期内工程师成功解决的用户案例数量；
U a-报告期内工程师确定的用户案例总数。

根据下表解释结果值。

由于我们在管理技术支持工程师的知识方面有两年以上的经验，因此我们通过实验专业地获得了0.85和0.95的水平。

违反反应时间/运行时间的百分比

我上面提到的违反反应时间/运行时间的百分比的指标。 实际上，它们显示了技术支持在反应时间和交货时间方面违反SLA的频率。

绩效指标

好吧，最后，生产指标：

• 报告期内技术支持处理的申请数量：
  
  • 其中的电话；
  • 监视系统中的哪些消息；
  • 其中拒绝；
  • 其中有客户；
• 报告期内与产品运行相关的应用程序数量：
  
  • 其中有事件；
  • 其中有上诉；
  • 报告期内所有产品客户的“拒绝服务”总时间。

有一条规则确定用于评估整体绩效的KPI比率。 根据此规则，指标应按比例10/80/10 =绩效指标/生产指标/绩效指标进行分配。

因此，有很多生产指标，从我的角度来看，我将只关注最重要的指标。

技术支持电话数量

当然，致电技术支持的次数是一个重要的指标，在​​组织工作和反映技术支持的绩效时都必须予以考虑。 来到所有人）

由于对上诉的上诉是不同的，因此可以根据上诉来源的总数和上诉的“实质”来区分上诉的一般流程。 在我们的例子中，它们是监视系统，传入电话，错误呼叫以及最终的客户呼叫。

与产品操作相关的应用数量

另一方面，将与我们的每个产品（服务）相关的申诉整合到相同名称的组中是有意义的。 例如，在我们的案例中，建议将与计算能力的租赁服务相关的呼叫与与数据中心中的设备放置相关的服务进行分组。 最好的做法是将组内的呼叫除以呼叫总数，产品中包含的服务的“拒绝服务”次数和总停机时间。

结论

当为时已晚时，要进行重大更改的方法与往常一样，写完我搜索了KPI以获得技术支持的文章后，我搜索了一些有趣的文章，以下是其中的一些：

• 您应该跟踪哪些IT帮助台KPI？
• 8个关键服务台指标和KPI

我理解了所阅读的内容，并没有改变文章中的任何内容，因为在我看来，它看起来更加诚实和自然。 如果需要，读者可以检查我们的技术支持有多大趋势。

也许我从阅读中学到的主要内容是，在我们的技术支持中，我们应该有两个附加索引：

1. FCR-在第一个支持申请中解决的申请数量；
2. FTFR-作为第一个支持申请的一部分而解决的应用程序的百分比。