在边缘和控制中

管理技术支持的复杂性

技术支持人员经常发现自己在日益复杂和异质的应用程序和硬件平台的未知水域中涉险。向客户推销的承诺是无论何时何地都能享受到便利;但很少有人考虑到我们如何支持这一承诺。

技术支持正淹没在窒息的网络流量中;融合的技术、数据和媒体争夺系统资源的海洋;以及每个客户的独特配置景观。技术支持处于价值链的尾端,在销售什么以及如何设计和实施方面没有什么发言权。

事件管理和故障排除活动可能成为 "他们的而不是我们的 "火拼的指责游戏,个人的最佳猜测,或被愤怒的客户升级的问题。问题的解决成为一种可能性,而不是一种确定性。

尽管客户的IT基础设施很复杂,但他们使用越来越多的互联但不同的技术,希望他们的业务能得到同质化的支持。那些对客户复杂的、相互关联的IT环境的现实情况视而不见的组织面临着风险--那些认为他们可以外包这一复杂性的组织也是如此。

在我们的客户中回荡的一个共同主题是,技术支持职能部门生活在边缘。他们能控制住吗?我们相信是的。

本文从关键任务支持功能的角度讨论了支持功能的弱点,并提出了一个可扩展的解决程序,可以应用于任何产品、平台和技术。

改善支持。不足的方法

好消息是,客户支持职能部门的经理和决策者现在意识到,支持世界越来越复杂:坏消息是,改进措施的成功是零星的。即使在最好的组织中,倡议的成功也会很快达到顶峰,投资回报率也会低于最初的承诺。

这里是效果不好的地方。

  1. 增加技术培训
  2. 依靠基于脚本的支持
  3. 植入更多的知识工具
  4. 使用业绩平均数作为衡量成功的关键标准

具有讽刺意味的是,这些看似 "正确的步骤 "遵循一个逻辑顺序,促使组织陷入无效的改革和新举措的无尽循环中,耗费资源并使客户失望。

1.技术培训对于支持过程的有效管理是至关重要的。一般来说,培训占支持中心预算的5-6%,支持中心的员工每年平均约有三个工作周的技能发展。大多数培训是在员工入职培训和新产品发布期间进行的。即使有最好的意图,由于人类的学习能力,培训也是不足的。一个支持人员可以获得两个、三个、甚至四个产品的认证,但这种认证并不能带来专业知识。没有任何技术培训手册可以模拟客户独特的IT基础设施的配置复杂性和动态性,分析人员只能随机应变。这导致了不一致的支持,是客户满意度评分的主要杀手。

技术支持人员在已知的水域中熟练地游泳,但当他们暴露在缺乏知识和经验的情况下,他们就会沉没。问问任何一个支持分析员--分析员今天面临的最大的工作危险是几乎可以肯定的是,下一个票据将超出他们的专业知识。

基于技能的路由是一种创可贴,而不是对分配和调度挑战的永久修复。路由规则通常将有关产品的问题分配给一个确定的专家。安装ACD(自动呼叫分配器)是为了促进这一过程。这往往会导致盛宴或饥荒的情况,烧掉 "好 "的资源,而 "其他 "的资源却没有得到充分利用。利用历史记录来安排合适的产品专家,以预测下一个关键任务的支持票据,缺乏效率和效果。尽管在技术和系统方面做出了努力,但积压的案件从未减少。而当复杂的问题出现时,路径选择就会失败。

2.基于产品的脚本被管理层用来提高绩效平均值,是外包模式的创始原则。要粉碎管理层对脚本的信念,只需听一听为解决关键任务的票据而进行的脚本尝试。

一线人员按照脚本行事是没有问题的,往往是有问题的。脚本对众所周知的或常规的情况有效。然而,一旦情况稍微偏离脚本,或者客户提出了一个复杂的问题,脚本就会崩溃。客户感觉到了脚本和失败的逻辑,认为这个问题超出了分析员的范围,并质疑服务台的真实性。信任就这样消失了。

随着支持的日益复杂化,一个脚本在创建的那天就已经过时了,它的效用也从此被稀释了。

对保修成本的分析也表明了脚本的失败。脚本的使用显示出与维修零件的运输量和现场服务的安排有近乎完美的关联。电话在服务台层面被关闭,给组织带来了巨大的成本,而且,在许多情况下,诊断是错误的。

3.知识管理(KM)工具在培训和知识共享不起作用以及服务成本不断上升的情况下提供了一个解决方案。管理层面临着压力,要尽量减少人为因素并安装知识管理工具。服务技术占支持中心预算的6-7%,每年有近70%的组织开展知识管理项目。知识管理很少能促进客户满意度的飞跃或减少平均解决问题的时间。相反,更多的技术会暴露并加速支持失败。

考虑一个典型的场景。分析师A解决了一个问题,并将解决方案放入知识管理解决方案数据库。分析师B遇到了一个类似的问题(也许是匹配的,也许不是),但没有使用A的解决方案或根本问题,因为B认为他或她的方式是正确的故障排除方式。所以,B增加了一个版本的解决方案。或者,分析师B认为这两个问题是一样的,找到了A的解决方案,并发送了同样的补丁,尽管它不是正确的,结果给客户带来了更多的问题。

知识管理工具,无论其复杂程度如何,都可能是支持组织中最被滥用的技术。

4.基于平均值的绩效衡量标准掩盖了脚本在提高满意度方面的失败,也掩盖了知识管理工具在填补这些差距方面的失败。一个组织可以报告一个相当好的MTTR(平均解决时间),但隐藏在这个统计数字之下的是极端的票据。这些问题拖拖拉拉,吞噬了精力和资源,并损害了客户满意度(被埋没在平均客户满意度分数中的极端分数)。

基于平均值的报告创造了一个循环,奖励了 "先修复,后解决问题 "的态度。一旦票据被打开,几乎没有人强调评估和过程--目标是满足SLA(服务水平协议)和降低情况的严重性,而不是将其故障排除。案件记录变成了无休止的电子邮件线程,要求提供日志文件,在没有做任何事情来解决案件的情况下,造成了浪费的死时间。

ITIL的事件管理流程有很大的潜力,但在不连贯的故障排除流程之上对事件管理流程进行标准化,不太可能产生可持续的结果。服务台和技术支持功能的长期解决方案是一个独立于技术、平台、语言或地理的明确流程。

在建立这个过程之前,我请你通过你的客户的眼睛来看待支持功能。

支持功能--为什么客户会升级

各个行业和地域的客户反馈研究显示,客户在支持方面有七个主要问题。

这些是。

  1. "我的业务需求没有得到解决。"当一个系统/软件/网络/服务失败时,客户的业务就会停止。你所支持的不仅仅是你的产品,你还在支持他们的业务。支持你的客户,而不是你的产品。
  2. "支持的质量是不一致的。"你的客户每次都要求同样的高标准。始终如一地提供服务。
  3. "我不知道你在我的问题上做什么。"当客户不知道发生了什么,或认为你不知道你要去哪里时,他们会变得不高兴。引导客户。
  4. "我的问题没有得到解决"。客户需要正确的解决方案。准确地排除故障。
  5. "你花了太长时间来修复它。"客户现在就需要他们的业务回来。要快。
  6. "我想要一个永久的解决方案,而不是一个变通方案"。客户需要他们的问题得到永久性的解决。证明这一点。
  7. "我为什么会遇到问题?"客户宁愿避免问题:预防胜于治疗。抢占先机。

客户关怀职能部门的所有举措都必须在任何时候都将这七个方面的关切放在前面和中心。这些客户关注的问题是建立关键任务支持流程的平台。

为什么平庸

抵抗。我们有一个程序;为什么我们需要另一个程序?

已经有一个故障排除过程的说法是由支持的一致性来检验的。按产品和支持人员绘制解决问题的时间图。正态曲线将突出变化性。这种变异性表明,如果确实有一个流程,它并没有被遵循。

通常情况下,分析师不相信他们所拥有的流程,而使用他们自己的方式来排除故障。这样的流氓程序不仅看不见,而且只要有任何不正常的情况,就会经常发生故障。

许多组织似乎不甘于平庸。他们需要一些根本上不同的东西来建立客户支持作为其业务战略的制胜要素。

一项为自我评估支持中心绩效而进行的全行业调查显示,许多组织似乎都甘于平庸。显然,有空间也需要一些根本上不同的东西,以建立客户支持作为其业务战略的制胜要素。

在边缘和控制中。过程

通过使用合理的过程方法,对客户问题及其解决的卓越知识和理解是可能的。要做到这一点,就要掌握结构化提问技术的技能,提高实时使用这些技能的能力,并通过反复使用培养能力。

这种结构化的提问成为客户互动的组成部分。通过创建一个鼓励在任何支持功能中使用合理流程的绩效系统,可以实现熟练程度。独立于平台、技术和支持系统,合理的流程方法可以扩展到管理服务台和客户关怀领域中最复杂的挑战。

这个过程建立在现有的知识和普遍的做法之上,因为它提高了个人和组织的效率。它支持并整合了任何良好的组织学习、系统和现有的客户管理实践。

问题解决逻辑流程

解决关键任务问题的合理过程方法从评估开始,即对客户的情况进行评估。评估使用逻辑来收集数据和定义问题。随后是解决,这是一个确定可能的原因的过程,根据问题规格对其进行测试,然后选择和测试最可能的原因。

在寻求尽可能快的解决方案和关闭故障单的紧迫性驱动下,评估往往是典型支持环境中缺少的部分。然而,正确的评估可以通过防止这些常见的陷阱来加速解决问题。

  • 过度归纳 - 大量的案件记录和数据转储中的信息过载,掩盖了后续行动有效性所需的具体内容。注意那些掩盖意图和现实的术语。假设因果关系--将事件按所希望的关系串联起来的冲动破坏了效率,导致了错误的道路。注意普遍存在的跳到原因的倾向,以及像 "由......引起的"、"由于......"、"......造成的 "这样的陈述。
  • 现实的困惑 - 由于支持人员以24×7的模式与来自地球上任何地方的客户一起工作,观念上的混乱导致了混乱。注意定义同一事件的多个版本。
  • 情感攫取理性 - 在每个故障排除步骤中的强烈感情会影响数据的解释。注意口头上和案例日志电子邮件中的非理性陈述,以及撅嘴的沉默。
  • 混乱的规模过大 - 一个问题变得太大,无法由一个人甚至一个小组来处理。注意参与人数和技术支持桥梁的频率。

评估不是一个成品:它是有效解决故障的基石。鉴定是客户与一线和后方支持之间的对话。它是一种合作,引导技术支持从一个复杂的、往往是模糊的现实到可操作的步骤。如果做得好,评估可以克服在适应性解决方案和有效解决的十字路口的困惑。

有效的评估帮助支持人员用有针对性的问题和技术来涉猎问题。

  • "你说的......是什么意思?","你说的......还有什么意思?"打破了概括化,使行动具体化。
  • "我们如何确定这是由于那个原因?","进行了哪些测试来证明?"避免假设因果关系。
  • "你有什么证据......?"将实际发生的事情与应该发生的事情区分开来。
  • "还有什么困扰着你......?"承认超负荷的感觉并鼓励反思。

在尽可能快地解决问题的驱动下,很容易跳到原因上。如果你能避免这些常见的陷阱,用过程的方法来解决就能加速故障排除。

  • 症状还是原因的两难选择 - 在一个或另一个方面采取立场。注意无意中忽略了客户的商业专业人士。
  • 对问题的定义不佳或不充分 - 太多不相关的数据或极少的事实。注意重复和模棱两可的数据要求,含糊地描述应该和实际表现,以及不断变化的事实。
  • 偏见凌驾于故障排除逻辑之上 - 证明但不检验支持预感的假设的冲动。注意那些有薄弱的、没有事实依据的、不合理的假设的可能原因。
  • 确认前结束 - 让MTTR指标驱动关闭。注意在没有首先向客户证明的情况下关闭票据。

合理的流程是如何指导升级的?升级通常发生在前线的知识和经验已经达到极限的时候。使用合理的流程方法,前线交出的票据,其结构正是后线的结构方式。这就减少了与客户的重复互动,避免了死亡时间。

客户。逻辑建立理解

人员通过这些逻辑驱动的问题和技术确定根本原因。

  • 以容易理解的对象/偏差格式说明问题
  • 通过收集遇到问题的物体和类似但未受影响的物体在识别、位置、时间和数量上的可比事实来说明问题。
  • 利用知识和经验,在已知的环境中产生原因。在未知的领域使用先进的技术。
  • 在重新创建环境之前,先测试可能的原因,了解事实。
  • 通过事实、观察、研究和实验确认真正的原因。
  • 应用逻辑驱动的评估和解决程序对客户互动有深刻的影响。

当客户认识到他们正在被倾听,而不是被编排,而且分析员问的是一组有逻辑的问题,这就建立了对分析员和组织的信心和信任。

在任何时候,服务台的任何成员,不仅仅是产品专家,都可以接听客户的电话,并按照同样的逻辑在正确的方向上取得重大进展。

过程应用。何时、何地、多少钱

故障排除过程可以全面应用,也可以以非正式的快速反应模式进行。

作为全面应用的主要候选者的关键任务支持情况可能是:。

  • 高优先级 - 高严重性
  • 重新开放的门票
  • 高度复杂的问题
  • 不寻常,没有明显的解决方案
  • 昂贵,需要投入大量的时间和资源

根据行业和产品的成熟度,5-10%的票据属于这个类别。然而,这些票据消耗了30-50%的组织资源。流程的全面使用会对满意度、解决率、更新率和成本指标产生很大影响。

绝大多数服务台的情况通常是。

  • 高度优先但熟悉
  • 需要立即回应
  • 只要有知识和经验就容易解决

通常情况下,15-50%的案件符合这个类别。非正式程序的应用可以使满意度得分、一致性和信誉建设得到严重改善。

结果

Kepner-Tregoe为故障排除提供了一个逻辑框架。通过培训、业务流程整合和性能系统改进,KT流程在Sun Microsystems、Dell、Cisco、EM C等公司的支持环境中取得了卓越的成果。代表性的指标包括。

  • 40%减少积压
  • 58%平均成交时间的减少
  • 41%首次修复率的提高
  • 25 % 减少向产品开发组提交的案件数
  • 每年减少12,000天的客户等待时间
  • 37% 降低事故/派遣率
  • $重要账户转介费用减少1000万。

想象一下,改进给客户带来的满意度。

准备好了 - 什么需要改变?

为了发展最佳实践的使用过程,需要发生一些哲学和结构上的变化。

在哲学上,我们需要一个范式的转变:服务台应该停止声称支持产品或应用程序。服务台是为了支持客户的业务。它是指在指导客户完成整个过程的同时,准确地排除故障,然后证明问题已经解决。

为了实现结构性的改变,要专注于识别和定义需要改进的关键--少数领域,而不是所有可以想象的。一个潜在的方法是关注那些需要较长时间才能解决的升级案件;或者那些由于其灾难性的严重性而通常能更快解决的案件,但需要组织方面付出过多的努力。建立针对这些领域的措施和因果因素,然后绘制你目前的流程。投入时间和资源来消除流程中的空白点或差距,同时不断消除无价值和低价值的步骤。当重点放在关键的几个步骤上时,客户支持功能就会迅速取得成果并开始实现持久的价值。

选择你的战斗

结论 - 这是一个旅程

最终的游戏是一个跨越三个维度的旅程。

技能发展 - 确保客户支持团队成员拥有成功所需的技能和辅导支持。

流程整合 - 确保获得的技能和业务流程之间有明确的联系。

性能系统集成 - 确保工作环境(期望、措施、工具/资源、后果和反馈)有利于使用新技能和过程。

一个独立于特定产品或技术的合理流程使客户关怀能够跨越产品、平台和技术。它提供了一个坚实的框架,通过管理日益复杂和不断变化的技术支持环境来支持客户的业务。

 

关于Kepner-Tregoe

Kepner-Tregoe是问题解决的领导者。六十多年来,Kepner-Tregoe通过更有效的根本原因分析和决策技能,帮助全球数以千计的组织解决了数百万个问题。Kepner-Tregoe与各组织合作,通过以下方式大大降低了成本并提高了运营绩效
解决问题的培训、技术和咨询服务。

相关的

保持控制力--设计仪表盘和指标以改善压力下的思维方式

客户宣言

我们是以下方面的专家:

联系我们

如需咨询、了解详情,或提出建议!