WEBVTT

00:00.150 --> 00:01.050
教师：在本课中,

00:01.050 --> 00:04.530
我们将讨论故障排除方法的最后一步,

00:04.530 --> 00:07.470
即第六步, 文档｡

00:07.470 --> 00:09.960
现在, CompTIA称这份文件为调查结果,

00:09.960 --> 00:18.600
行动和结果, 这实际上是关于记录错误的地方, 你做了什么, 以及将来可以做些什么来防止它｡

00:18.600 --> 00:26.730
现在, 每个组织在处理公司内部所有不同问题和问题的文档方面都有所不同｡

00:26.730 --> 00:29.340
现在, 在我的公司, 我们使用一个专门的故障记录系统,

00:29.340 --> 00:31.230
它允许我们记录所有的问题,

00:31.230 --> 00:37.410
它被分配给谁, 他们做了什么来修复它, 以及解决方案是什么｡

00:37.410 --> 00:38.280
除此之外, 我们还有自己的内部知识库,

00:38.280 --> 00:46.470
在那里我们可以收集所有的故障排除步骤, 以及我们过去在解决不同问题时学到的所有知识｡

00:46.470 --> 00:50.700
除此之外, 我们还有一个名为“常见问题解答”的区域,

00:50.700 --> 00:57.330
该区域根据我们每天从最终用户那里获得的问题提供了一系列不同的支持文章｡

00:57.330 --> 01:01.080
我们花了很长时间来建立我们的知识库和常见问题解答,

01:01.080 --> 01:08.460
但这确实很有帮助, 特别是对于新加入团队的技术人员, 因为他们可以查看我们的常见问题解答和知识库,

01:08.460 --> 01:11.970
了解我们如何开展业务以及如何解决问题｡

01:11.970 --> 01:13.440
当您作为技术人员工作时,

01:13.440 --> 01:21.630
您的组织可能有也可能没有知识库､ 常见问题解答或故障单系统, 这取决于您的组织的规模｡

01:21.630 --> 01:26.340
这些天来, 虽然, 即使是小组织可以得到一个很大的麻烦票务系统非常低的成本,

01:26.340 --> 01:29.820
甚至在某些情况下是免费的｡

01:29.820 --> 01:32.340
有很多这样的人, 包括Freshdesk,

01:32.340 --> 01:36.840
Jira, Help Scout, Intercom, 还有很多很多其他的人｡

01:36.840 --> 01:38.880
现在, 你用哪一个真的不重要,

01:38.880 --> 01:40.710
但想法是一样的｡

01:40.710 --> 01:42.570
你希望能够记录你的发现､

01:42.570 --> 01:44.760
你的行动和你的结果｡

01:44.760 --> 01:45.960
另一个原因是,

01:45.960 --> 01:49.770
你也不想等到最后再做这件事｡

01:49.770 --> 01:52.650
当您被分配了一张工单并正在识别问题时,

01:52.650 --> 01:54.750
您应该返回故障工单系统并记录您所识别的内容,

01:54.750 --> 01:58.740
您看到的症状是什么, 您认为此问题的可能原因是什么,

01:58.740 --> 02:04.890
然后随着您继续执行这些步骤, 您希望不断更新此信息｡

02:04.890 --> 02:07.980
如果你正在处理一个可以一次性解决的小问题,

02:07.980 --> 02:11.310
你可能不需要为每一步更新票证｡

02:11.310 --> 02:13.560
但是如果你正在处理一个更大的问题,

02:13.560 --> 02:17.820
那么在故障单系统中记录这个问题就非常重要了｡

02:17.820 --> 02:19.530
故障单系统如此重要的另一个原因,

02:19.530 --> 02:24.990
特别是在大型组织中, 是它允许您进行趋势分析｡

02:24.990 --> 02:31.110
这将使您能够找出您的组织正在遭受的共同主题或问题｡

02:31.110 --> 02:33.690
例如, 在我所在的一个组织中,

02:33.690 --> 02:39.510
我们发现90%的麻烦电话都与需要重置密码的人有关｡

02:39.510 --> 02:44.580
现在, 我们花了大量的时间来重置人们的密码｡

02:44.580 --> 02:46.890
所以我们决定, 作为一种趋势, 这不是一个我们喜欢的趋势,

02:46.890 --> 02:50.220
我们最终与我们的开发人员和我们的系统工程师合作,

02:50.220 --> 02:55.620
创建了一个密码重置选项, 人们可以重置自己的密码｡

02:55.620 --> 03:00.420
系统一上线, 我们的故障单负载就下降了90%｡

03:00.420 --> 03:07.110
因此, 这些文档在确定组织的持续改进领域方面也非常重要｡

03:07.110 --> 03:09.690
这个故障记录系统的另一个用途是,

03:09.690 --> 03:11.970
你可以用它来记录你的发现､

03:11.970 --> 03:16.350
行动和结果, 你可以记录你所做的工作量｡

03:16.350 --> 03:18.330
现在, 这可能是一件好事, 也可能是一件坏事,

03:18.330 --> 03:22.950
这取决于你做了多少工作, 但我个人可以告诉你, 作为一名IT总监,

03:22.950 --> 03:25.380
并运行一个有150人的帮助台, 支持超过15,

03:25.380 --> 03:35.400
000名用户, 我们一直使用我们的故障单系统来帮助证明我需要更多的人来支持这15, 000名用户的事实｡

03:35.400 --> 03:38.970
这是因为我们开始看到我们的门票数量上升｡

03:38.970 --> 03:40.560
当我们开始研究它时,

03:40.560 --> 03:42.840
我们发现这是因为有新系统正在安装,

03:42.840 --> 03:45.030
而且通常, 组织会花钱购买新系统,

03:45.030 --> 03:48.540
但他们不会花钱培训其用户, 因此导致更多的服务台呼叫,

03:48.540 --> 03:55.020
只要我们能让更多的人接听这些电话, 这就很好｡

03:55.020 --> 03:58.110
否则, 整个系统将开始陷入停顿｡ 

03:58.110 --> 03:59.280
所以请记住这一点｡ 

03:59.280 --> 04:05.970
您可以记录的越多, 您就越能证明您作为技术人员所做的工作以及您所在的大型帮助台工作人员的合理性,

04:05.970 --> 04:14.070
这可以帮助您确定何时需要向服务台系统投入更多资源, 以便能够雇用更多人员或提高人员的技能水平, 以便能够以更好､

04:14.070 --> 04:18.070
更高效的方式接听这些电话｡