呼叫中心,统一通信,融合通信专业资讯网
首页>>>技术>>>人工服务台

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

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

关键定义

下面是基于ITIL的帮助台事件管理流程中的使用的关键术语:

  事件——不属于标准服务运作的一部分并且导致或可能导致服务中断或服务质量降低的任何事件。

  初始支持小组——为处理事件和服务请求提供一级支持的小组。初始支持小组负责尽量在一线解决事件 — 通过确定已知解决办法、使用诊断脚本或他们自己的知识。在许多组织中,服务台充当初始支持小组。

  已知错误——已知其根源并且已确定临时的解决办法或永久的替代方案的事件或问题。如果存在业务案例,则会引发 RFC,但是在任何情况下,它都保持为已知错误,除非通过某个变更永久地解决。

  重大事件——具有高度影响或潜在的高度影响的事件,这样的事件需要的响应超出为常规事件所提供的响应。通常,这些事件需要整个公司的协调、管理上报、动员附加资源和加强沟通。

  问题——一个或多个事件的未确诊根源。

  问题解决小组——致力于解决初始支持小组自身无法解决的事件和服务请求的专家小组。支持小组结构因组织而异,有些使用分层结构(第二、第三层,等等),而其他使面向用平台或应用程序的小组(大型机小组、桌面小组、网络小组或数据库小组)。

  服务台——提供客户、用户、IT 服务和第三方组织之间至关重要的日常联系点的功能。服务台不仅协调事件管理流程,而且提供进入其他 IT 流程的接口。

  服务请求——针对新的或改动后的服务的请求。服务请求的类型因组织而异,不过常见的服务请求包括变更请求 (RFC)、信息请求 (RFI)、采购请求和服务宽限。

  解决方案——也称为永久解决。已确定的解决事件或问题的手段,它提供根本原因的解决。

  替代方案——已确定的解决特定事件的手段,它允许恢复正常服务,但是并未从源头实际解决导致事件的根本原因。

如下图所示,事件管理中的主要流程包括:


  检测、自助服务和记录。该流程通过各种不同的方法处理事件的初始检测。事件可由通过电话、传真或电子邮件联系服务台的人员报告。其他事件可能因为来自事件管理系统的警报而引发。用户可以利用自助服务功能引发自己的事件,检查现有事件的进度,以及访问自助信息。所有事件都要进行记录,以便能够在它们的整个生命周期中跟踪、监视和更新它们。然后可将该信息用于问题管理、报告、流程优化和规划。


帮助台工具在企业事件管理中的检测、自助服务和记录环节(子流程)的应用场

1)检测

  若要管理事件,必须首先检测它们。传统上,绝大多数事件都是由在尝试执行日常任务时遇到问题的用户报告的。服务台通过充当用户和 IT 之间的单一联系点在这其中发挥了关键作用。该单一联系点帮助确保一致地处理所有报告的事件和服务请求,同时还最小化对支持团队的干扰,从而允许他们更有效地发挥功能。

  事件也可能由 IT 团队、合作伙伴和供应商检测到。报告这些事件的方式可以是通过电话、传真、电子邮件、Internet、浏览器,或者只是由走进服务台办公区域的人员所报告。

  事件管理系统的广泛使用现在提供了被检测到的事件的另一个来源。这些系统连续地监视系统和网络基础结构,并且能够在超出预先确定的阈值或组件不可用时进行识别。然后事件管理系统向事件管理流程发出警报。

  比如天汇帮助台可以接收来自电话、传真、电子邮件、Internet及来自网关系统等事件管理系统的报告。

2)自助服务

  自助服务功能为 IT 客户提供增强的灵活性和对如何以及何时联系支持部门的控制。在自助服务的环境中,客户能够使用各种方法联系服务台和经营业务。该选择可能包括传统的电话设备、无线设备和传统的键盘设备,并使用浏览器技术或对服务台工具中嵌入的查询功能的访问。不管使用哪种方法,都需要准备好相关控制以确保一致的服务质量级别。存在一些需要在处理不同的访问方法时识别并为之作计划的差别,并且要使概念可行,仔细的设计是必不可少的。

  为了使这成为有效的策略,服务台需要识别他们处理的请求的类型,决定哪些请求类型适合自助服务解决方案,然后开发该解决方案。如果进展顺利,组织能够将技术资源解放出来,使之集中在更复杂或特殊的问题上。
例如,如果接收到的请求的 30% 是针对密码重置,那么开发一个允许用户回答身份验证问题然后重置他们自己的密码的功能是值得的。下图为天汇自助服务模块中的密码重置功能,客户可以输入自己的编号,系统会自动将密码发送到其注册的邮箱中。


  如果随后发现其余的大部分请求都是“如何做”类型的问题,则可以着手开发一个常见问题 (FAQ) 信息功能。关键是要确定那些当前正在占用大量初始支持资源,但是通过自助服务解决方案也可以很好地自助解决的请求类型。这样允许将资源集中在其余的请求类型上(例如服务器或网络问题)。下图为天汇帮助台模块的常见问题 (FAQ) 信息功能:



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

表 1 自助服务矩阵

请求类型 占总请求量的百分比 通过自助方式解决(层级 0) 通过初始支持解决 由二级问题解决小组解决 由三级问题解决小组解决
密码重置 30% 0% 25% 5% 0%
“怎么办?FAQ” 18% 0% 9% 8% 1%
进度更新 17% 0% 15% 2% 0%
办公套件问题 13% 0% 5% 5% 3%
个人计算机问题 12% 0% 3% 7% 2%
服务连接问题 5% 0% 0% 2% 3%
其他 5% 0% 3% 1% 1%
总计 100% 0% 60% 30% 10%

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

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

请求类型 占总请求量的百分比 通过自助方式解决(层级 0) 通过初始支持解决 由二级问题解决小组解决 由三级问题解决小组解决
密码重置 30% 0% 2% 5% 0%
“怎么办?FAQ” 18% 10% 7% 1% 0%
进度更新 17% 15% 2% 0% 0%
办公套件问题 13% 0% 10% 3% 0%
个人计算机问题 12% 0% 7% 5% 0%
服务连接问题 5% 0% 1% 3% 1%
其他 5% 0% 4% 1% 0%
总计 100% 53% 33% 13% 1%

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

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

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

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

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

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

要收集的关键数据包括:

  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 的变更管理系统),而其他请求(例如唯一的批处理作业请求)不大可能有特定的存储库,因此应该作为事件记录进行记录以用于跟踪目的。下图为客户通过天汇帮助台的自助模块填报采购申请:


  应该根据客户数据库中保存的记录检查请求发起人身份信息(例如姓名、部分、位置和联系详细信息),最好将该数据库作为配置管理数据库 (CMDB) 的构成部分。该过程允许包含客户详细信息的记录保持最新。取决于环境,该过程还可以包括提及关于商业详细信息(例如合同号)和安全验证的问题以确认身份。

  每个事件或服务请求都应该被赋予一个唯一的参考 ID。应该为请求发起者提供此 ID,如果发起者再次请求更新该记录或检测进度,该 ID 可用于轻松定位正确的记录。当事件是由事件管理或监视工具中的事件或警报引发的时候,应该将事件或警报参考号包括在事件记录中。这样允许调查事件的人员识别和查看最初的事件或警报。

  服务台负责最初从请求发起者那里获得所有必需的信息。可能存在还需要某些澄清或附加信息的情况。在这些情况下,服务台应该联系请求发起者以获得该信息。

  在整个事件生命周期中,事件记录在最后终结之前可能经历许多不同的状态。事件记录上的状态字段用于快速识别事件的当前状态。



上图为天汇帮助台中的状态自定义窗口,比如你可以自定义的状态类别为:

  新收到。事件已记录,但是可能还需要澄清。
  已接受。事件已完全记录,现在已开始初始支持。
  已分配。事件已分配给问题解决小组,并正在等待解决。
  活动或进行中。解决事件的操作正在进行中。
  等待证据。操作已在等待获得附加证据时临时停止。
  已计划。在到达计划的时间之前不能执行进一步的操作。
  挂起或中断。操作已临时停止,直至某个事件或时间的到来。
  已解决。事件被认为已解决。服务台需要在终结事件之前与请求发起者确认解决方案。如果请求发起者对解决方案不满意,则将状态重置为“已分配”或“活动”。
  已终结。请求发起者已验证事件得到解决,因此该事件已被终结

  事件记录在整个事件生命周期中保持最新是很重要的,如天汇帮助台的事件明细日志可以使所有支持人员都能看到当前正在发生的事情、谁当前正在处理该事件,支持人员可以使用预先定义的服务动作来快速记录及先前曾尝试过什么和发现了什么。如下图:


服务动作预定义窗口

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

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

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

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

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

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

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

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

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

CTI论坛编辑



相关链接:
NET平台下开发HelpDesk应用前景分析 2008-06-18
确保自助服务成功的六大因素 2008-04-16
面壁ITIL之服务台管理实战 2007-06-19
“帮助台”软件概念、功能和市场分析 2007-05-31
Unisys演绎如何实践ITIL 2006-08-01

分类信息:     技术_人工服务台_文摘
电话:010-82012787,82079677 传真:010-62041062 呼叫中心建设及运营管理咨询服务:010-82079677
京ICP证030771号 Copyright Ctiforum.com All rights reserved