如何利用基于ITIL的帮助台软件工具支持企业快速实施ITIL
事件管理之检测、自助服务与记录

联合智业公司 王伟 2007/09/05

　　必须了解请求的概况才能正确地瞄准自助服务解决方案。应该构造一个类似如下的矩阵。

表 1 自助服务矩阵

　　从上面显示的矩阵中可以观察到，用于密码重置、FAQ 和进度更新的自助解决方案是值得的投资。这样允许初始支持资源有更多的时间尝试解决当前正在传递给二级或三级问题解决小组的一些更复杂的事件。在实施和推广新的自助服务功能之后，更新后的矩阵可能如下所示：

表 2 新的自助服务功能矩阵

　　该矩阵表明自助服务功能现在已经从支持团队那里取走了很大一部分请求。这样允许每一层将更多的时间集中于以前由于缺乏资源而需要上报的更复杂的事件。注意由初始支持资源所解决的请求百分比降低了；这是因为他们现在处理比简单的进度更新或密码重置花更长时间的请求类型。将时间花在更复杂的事件上提高了团队的工作满足感，同时还降低了对更高层资源的日常影响。这样允许团队将精力集中在更战略性的问题上。

　　有些类型的请求不适合自助服务方法。由于其性质，请求或者需要来自专家支持人员的响应，或者需要进行跟踪并收集其指标。

　　高优先级事件通常不应该通过自助服务机制进行报告，而是应该直接向服务台分析员报告。这样有助于确保正确地对所有高优先级事件进行分类，并从事件发源地收集必要的详细信息。

　　由于通过使用自助服务功能收集关于正在解决的请求的指标更加困难，因此在大多数情况下，这些指标的内容应该针对回答“如何做”类型的请求而不是解决故障。

　　若要使自助服务解决方案取得成功，它必须易于使用，以便用户有信心使用它，并相信它会提供一种通过其他途径联系服务台的替代办法。

　　不管客户如何进入自助服务环境，他们的进入需要接受验证并且需要收集相关指标。这包括进行的查询的趋势分析（同时包括成功和失败）、进行的联系的容量、自助服务环境的性能以及联系方法方面的更改。该信息有助于识别服务方面的改进，但是也证明了服务的有效性，并提供关于投资回报的信息。

要收集的关键数据包括：

　　a)进入方法或模式
　　b)进入日期和时间
　　c)用户身份
　　d)所提的问题和访问的功能

　　取决于环境，可能需要进行各种授权检查以确保请求者有权访问功能和数据。对于支持许多客户的外包组织尤其是如此，这些客户不应该能够查看彼此的支持请求。授权检查可能涉及正确回答一个或多个安全问题（例如密码或母亲的娘家姓）。需要建立用于收集、安全地存储然后维护该安全验证信息的过程。

　　进入自助服务系统的模式确定了对查询者可用的功能。如天汇帮助台应提供标准 Web 界面和搜索引擎。
如果进入模式是电话样式的键盘，则需要部署更明确和基于脚本的交互，并且可能需要语音识别技术。还需要考虑和适应其他进入模式，例如电子邮件，其中预定义的任务表格可能适合用于登记新的服务请求或请求进度更新。这种沟通方法对于提供动态帮助可能不太成功。

　　典型的高容量但是相对简单的请求可能涉及密码重置。使用基于脚本的自助服务解决方案，服务台分析员不再需要卷入密码重置。需要重置其密码的员工可以访问某个自助服务功能，回答若干身份验证问题，并通过一个引导流程继续重置他们自己的密码。在执行密码更改时，向请求者发送咨询电子邮件作为安全预防措施始终是明智的。

　　在天汇帮助台系统中，通过其自助服务功能模块进行的新请求可以在服务台系统中捕获，并像其他所有请求一样被分配一个事件编号，以提供审核跟踪和启用后续的进度监视。当自助服务允许请求者更改数据或密码时，与服务台的这种联系尤为重要。然后它可以确保自动将自助服务包括在趋势分析中。该数据的明确分析允许改进服务，并使趋势分析尽可能全面。

　　可用的信息取决于查询的样式。如果查询基于计算机或基于 Web，则对各种数据源的访问是可能的，其中包括：

a)事件和问题跟踪
b)转发变更日程安排
c)供应商支持说明
d)培训材料
e)软件更新
f)FAQ 信息
g)服务目录
h)价格列表

　　信息的内容、准确性和和时间性需要谨慎管理。需要定义并一致同意清楚的角色和职责以确保没有歧义。通过任何形式的自助服务功能可用的信息需要密切监视和审核，以确保符合地区法规 — 尤其要注意数据保护和保密协定。

　　如果用户选择使用自助功能，应该为其提供快速查找答案的每个机会，并且尽可能具有最少的混淆。如果用户发现该体验并不愉快，他们今后就可能不会使用它。与其他任何产品一样，用户需要“喜欢”它，然后才会“购买”它。

　　自助系统通常是有用信息和经验的数据库。用户向该系统提供某个信息，希望能找到与他们的问题“匹配”的信息。该信息可以是错误代码、错误消息或任意格式的问题描述。

　　如果找到匹配的信息，该信息通常以和最初的查询相同的格式返回。但是，用户也可能要求打印的响应。例如，用户可能希望获得某个 FAQ 的副本，因此可能需要提供包括向请求者发送自动化的电子邮件的响应选项。

　　一旦返回请求的信息，用户需要有机会根据当前查询优化请求，以选择附加菜单选项或开始新的请求。在设计脚本时，执行完整测试以确保决不会使用户无有效或适当的选择可做是至关重要的；其中包括在任何时候返回到非自助选项的能力。

　　如果用户希望进行第二个请求，该流程应该为用户提供输入另一个查询而不必再次注册的机会。需要对这里可用的选项进行仔细评估，因为可能存在要考虑的安全问题。虽然自动化的系统一般可能受到更多的控制，因为必须准确满足安全验证，但是通过个人联系处理对应用程序的增加的访问请求也许更为可取。

　　如果用户无法找到他们正在寻找的内容，或者已到达可用选项的结尾，应该询问他们是否希望联系服务台。与服务台的联系包括从简单地留个话到针对所需信息的完整请求的范围。需要考虑用于监视和管理此类沟通的方法，但是记录该请求已经经历失败的自助请求是必需的，以便能够在可能的情况下对自助服务环境进行改进。

　　与事件和问题管理的紧密联系在这里明显是必需的，如果自助服务功能的重点是减少简单的常见支持请求（例如更换打印机墨粉盒）的数量，则情况尤其是如此。主要重点应该放在提供高效的、面向客户的查询功能上，这样的功能允许在不卷入服务台的情况下得到处理。必需经常检查该信息以确保它准确并反映支持（服务）信息的当前状态。

　　自助服务解决方案的可伸缩特性允许组织在遇到快速增长时实现非常灵活的响应。通常，可能要花数周时间招募和培训服务台团队才能适应增加的要求，例如企业合并所产生的要求。但是，自助服务技术能够满足增加的服务的许多要求而没有这样的时间限制，但是所使用的系统能够扩展以满足未来要求是很重要的。

　　由于所需要的人员，基于电话接线员的服务是提供支持的最昂贵方法。技术和设备的安装和维护也很昂贵，但是可能始终存在对基于电话接线员的服务的需要，以便处理例外而不是日常的支持请求。将自动化的响应作为主要响应方法需要重大的初始投资，但是也提供了快速和可实现的投资回报。当前的评估表明，设计良好的基于 Web 的自助服务的成本要比等效的传统支持低 5%。

图：天汇帮助台的自助服务系统功能界面

　　大多数科学研究表明，人们宁愿与非人类的界面进行有限的交互（意味着很短的持续时间），而大多数人更喜欢人与人的接触。但是，正确定位、设计和销售的自助服务解决方案可能被客户视为是有利的 — 银行自动取款机 (ATM) 就是这样的例子。ATM 成功的关键原因是它们方便和易于使用，通过全天候的可用性延长常规服务，并且通常比排队等待人类出纳员提供更快的替代方法。引入自助服务的组织应该从这个例子中学习，并旨在提供同样方便和易于使用的解决方案，提供延长的服务，并且至少像等待与人接触一样快。

　　但是，随着组织转向自助服务，对复杂维护过程的需要将随之出现。如果要采用自助服务，必须从一开始就做得很好。上图为人性化的天汇帮助台系统的自助服务功能界面设计。

3)记录

　　所有检测到的事件和服务请求都需要记录，以便能够跟踪它们以确保没有任何遗漏。记录所有联系还提供了开始操作和减少特定类型的请求所需要的信息。例如，服务台可能发现很大比率的传入请求都来自只是询问电话号码的人。调查可以发现内部电话目录本已经严重过时。然后可以做出在 intranet 上公布内部电话目录的决定，在 intranet 上可以更容易地维护电话目录。这种主动性不仅减少了针对服务台的请求数量，而且通过允许职员容易地访问最新信息提高了业务效率。如果没有记录电话号码请求，则问题的规模就难于确定，并且可能无限期的继续存在而未得到解决。

　　应该将事件详细信息记录在服务台工具中的数据库中。对于每个事件，应该使用下列信息填充事件记录：

a)唯一参考号
b)记录日期和时间
c)记录事件的人员的身份
d)报告事件的人员的身份（包括姓名、部门、位置和联系详细信息）
e)联系方法
f)受影响的配置项 (CI) 的详细信息
g)症状描述和任何错误代码
h)重现该问题所需要的步骤

　　对于服务请求，上面的许多基本信息仍然需要，不过应该将症状描述替换为所请求的服务的详细信息。有些类型的服务请求可能有自己的用于记录请求的工具（例如用于 RFC 的变更管理系统），而其他请求（例如唯一的批处理作业请求）不大可能有特定的存储库，因此应该作为事件记录进行记录以用于跟踪目的。下图为客户通过天汇帮助台的自助模块填报采购申请：

图：添加事件明细来记录采取的服务支持动作

　　最新的记录还允许任何被联系的人员为请求发起者提供进度更新。让客户了解最新的进度情况是直接影响客户满意度的重要因素。更新应该定期提供，具体取决于事件的优先级。例如，高优先级事件可能需要每小时的更新，而中优先级事件每日接收更新，低优先级、长时间处理的事件需要每周甚至每两周的更新。

　　在记录流程之后，事件将经过分类和初始支持流程，而服务请求则被传递到“服务请求处理”流程。

　　事件记录应该在某个服务台工具中记录和跟踪，该工具最好是作为集成的服务管理工具集的构成部分。该工具应该在引发新的事件时提供最基本的事件记录。比如为了帮助提高效率，当你在天汇帮助台的用于记录事件的事件窗口中输入请求发起者的姓名时，利用客户数据库可以自动填充诸如位置、部门和联系详细信息等字段。天汇帮助台还支持使用计算机电话集成 (CTI)技术来根据传入的电话号码自动填充字段。即使是在已经使用这些技术的情况下，仍然应该在事件记录期间与客户核对诸如联系号码和位置等详细信息这样提供了对 CMBD 中保存的数据的例行审核，并给出了可能需要进一步调查或检查的区域的指示。

图：天汇帮助台的事件记录窗口

　　服务台工具应该使用必填的字段或脚本确保引发新的事件记录的人捕获所有必需的基本详细信息。

　　服务台工具可能允许与网管系统等事件管理系统集成，以便能够在生成警报时自动引发事件。这种自动化从支持团队那里取走了手动填写事件记录的任务，从而提高效率。在警报之后手动或自动创建的事件记录需要包含足够的信息，以允许支持团队识别生成该警报的事件。如果事件或警报具有唯一的参考 ID，则应该将它们与受影响的配置项 (CI) 的详细信息一起包括在事件记录中。

　　在事件的生存其中，服务台工具可能根据事件优先级和组织的更新策略，在客户更新到达时自动向服务台分析员发出警报。该警报可能具有多种形式：

　　a)查看事件队列时事件旁边的时钟或感叹号图标。
　　b)查看队列时事件以某种颜色（例如红色）显示。
　　c)弹出式对话框。
　　d)发送到指定的别名的消息或电子邮件。
　　e)定期（每天两到三次）运行的报告的输出。

CTI论坛编辑