CN101923674A - 用于知识管理系统的性能仪表盘监测 - Google Patents

Abstract

本发明的实施例通过提供用于创建知识管理系统的方法、系统、计算机程序产品或前述的组合来解决了上述需要和/或实现其它的优点，该知识管理系统包含在整个组织的通道和子通道中被标准化和集中化的性能仪表盘监测系统。性能仪表盘监测系统用来跟踪、测量和解决在整个组织的通道、子通道、系统和应用发生的事故。该系统接收与两个或更多个事故有关的信息，其中，每一个事故与一个或多个企业通道、子通道或应用相关。该系统将信息存储在存储器装置中。该系统跟踪至少一个事故的在事故的发生和解决之间的状态。该系统在用户界面上显示在通道、子通道、应用或各个事故级别上与事故有关的信息。

Description

用于知识管理系统的性能仪表盘监测

技术领域

本发明总体上涉及知识管理领域，更具体地说，发明的实施例涉及用于提供生产支持信息的综合系统的系统、方法和计算机程序产品。

背景技术

企业以分散的方式横跨各业务范围(“LOB”)来存储应用、信息和数据。通常，每个LOB内的特定部门负责以在每个部门内工作的同事认为合适的最有效方式(如果真要这样做的话)来对他们的知识进行编辑、分类、存储和访问。应用、信息和数据既不存储在中心场所，而且对于部门和LOB之间的知识转移和一般教育来说也不可搜索或使用。而且，当发生生产事故时，被指定去支持生产事故的每个同事并不都掌握正确的处理和修复。因此，当同事有他/她自身的专业知识所不能解决的问题时，这个同事通过呼叫或电子邮件向企业自身的呼叫中心或其它支持系统发出询问，以寻找合适的答案或联络人参考。通常将询问转发给负责将它们上报至合适的企业团队的团体。为了解释系统构架、上游和下游系统、以及客户影响，还可以将业务专家拉入上述询问。当事故涉及小问题时，需要进行诊断并修复该问题的人员仅仅会被短暂占用，但是用更有效的系统可避免这样的时间。当事故重大时，这一过程可能会花费数周来得以解决，并且，为了解决这些事故，人员需要会花费相当多的时间与同事进行实地交流或电话通信。这种耗时的过程长期使得关键同事不能从事其日常责任。

每当事故被上报到更高的支持水平，都会花费宝贵的时间并负面地影响到企业的客户。通常的知识管理系统是基于个人的，因为这些知识管理系统取决于各个团体中的某些同事的知识水平。因此，无论何时发生事故去联络特定同事都是低效率的，远不是最佳的手段。使用这些系统的员工作为对任何事故的反应而进行响应，并且使大量团队中的同事远离他们的正常角色，这样转化为成本增加。

而且，当在企业内进行审计核查时，必定需要大量的人工任务去收集数据和以有意义的方法组织该数据。在这种数据收集和组织之后是冗长的面对面的会议，以详细地核查和分析各个数据。审计团队必须逐个LOB、逐个部门地这样做，因为大部分的LOB和部门以不同的方式组织和存储它们的数据和文档。因此，如果测量度量(measuring metrics)和处理以分散的方式被组织并在整个企业重没有被标准化，则在组织内审计不同的部门变得特别昂贵、费时。随着企业规模增大，这种问题成指数地增加。

没有为了系统文档管理、统计和其它分析、提高同事技术水平和教育等目的而容纳企业的所有重要数据的中心位置。分散方法可能使同事重复劳动，因为他们不知道，其他同事可能已经独立地开发了处理图(process map)、程序、数据分析等。在不能先在集中位置搜索信息的情况下，同事们决不会知道他们的努力实际上是否是浪费时间以及是否可以将他们的努力更好地投放在别的问题。

当前没有这样的系统：在该系统下，企业能够以无缝的方式通过一个集成系统来存储、生成、分发、评分和跟踪由企业中同事创造的所有知识。

发明内容

本发明的实施例通过提供用于创建知识管理系统的方法、系统、计算机程序产品或前述的组合来解决了上述需要和/或实现其它的优点，该知识管理系统包含在整个组织的通道和子通道中被标准化和集中化的性能仪表盘监测系统。性能仪表盘监测系统用来跟踪、测量和解决在整个组织的通道、子通道、系统和应用发生的事故。

本发明的一个实施例是用于跟踪和解决在企业中发生的事故的监测系统，该监测系统包括用户界面、存储器装置、通信装置和处理器。处理器与通信装置、用户界面和存储器装置可操作地耦合。处理器被配置为执行计算机可读程序代码，以接收与两个或更多个事故有关的信息，其中，每一个事故与一个或多个企业通道、子通道或应用相关。处理器还配置为执行计算机可读程序代码，以将信息存储在存储器装置中。处理器还配置为执行计算机可读程序代码，以跟踪至少一个事故在事故的发生和解决之间的状态。处理器还配置为执行计算机可读程序代码，以在用户界面上显示在通道、子通道、应用或各个事故级别上的与事故有关的信息。

此外，根据本发明的一个实施例，用户界面显示与所述两个或更多个事故有关的信息，所述信息例如是：打开的事故单的数量；打开得比特定响应时间长的事故；每小时、每天和每周的每一个通道、子通道和应用的事故的数量；由于事故引起的失败的客户交互的数量；事故的根本原因；或者由于与其它通道、子通道或应用有关在通道、子通道或应用中的失败的客户交互的数量。

在本发明的另一个实施例中，处理器可操作用来执行在计算机可读介质中存储的计算机课可读指令，以在用户界面上显示与每一个企业通道、子通道或应用相关的事故的数量。

在本发明的另一个实施例中，处理器可操作用来执行在计算机可读介质中存储的计算机课可读指令，以在用户界面上显示与每一个企业通道、子通道或应用相关的性能分数。

在本发明的另一个实施例中，处理器可操作用来执行在计算机可读介质中存储的计算机课可读指令，以在用户界面上显示一个或多个图形图表。所述图形图表图示与事故相关的下述因素中的一个或多个：包括事故的响应时间、事故或失败的客户交互的强度、事故的根本原因或者解决事故失败，或者每一个通道、子通道或应用的事故或失败的客户交互的比率。

在本发明的另一个实施例中，处理器可操作用来执行在计算机可读介质中存储的计算机课可读指令，以在用户界面上显示由于事故引起的失败的客户交互。

本发明的一个实施例是用于跟踪和解决在企业中发生的事故的监测系统，该监测系统包括用户界面、存储器装置、通信装置和处理器。处理器与通信装置、用户界面和存储器装置可操作地耦合。处理器被配置为执行计算机可读程序代码，以接收与一个或多个事故有关的信息，其中，所述一个或多个事故与两个或更多个企业通道、子通道或应用的相关。处理器还配置为执行计算机可读程序代码，以将信息存储在存储器装置中。处理器还配置为执行计算机可读程序代码，以在用户界面上一起显示所述两个或更多个通道、子通道或应用以及关于和每一个企业通道、子通道或应用相关的所述一个或多个事故的信息。

在本发明的另一个实施例中，处理器可操作用来执行在计算机可读介质中存储的计算机课可读指令，以在用户界面上显示在通道、子通道、应用或各个事故级别上与所述一个或多个事故有关的信息。

在本发明的另一个实施例中，处理器可操作用来执行在计算机可读介质中存储的计算机课可读指令，以跟踪至少一个事故在事故的发生和解决之间的状态。

在本发明的另一个实施例中，用户界面显示与所述一个或多个事故有关的信息，所述信息例如是：打开的事故单的数量；打开得比特定响应时间长的事故；每小时、每天和每周的每一个通道、子通道和应用的事故的数量；由于事故引起的失败的客户交互的数量；事故的根本原因；或者由于与其它通道、子通道或应用有关在通道、子通道或应用中的失败的客户交互的数量。

在本发明的另一个实施例中，处理器可操作用来执行在计算机可读介质中存储的计算机课可读指令，以在用户界面上显示关于与事故相关的性能是否可接受的信息。

在本发明的另一个实施例中，处理器可操作用来执行在计算机可读介质中存储的计算机课可读指令，以在用户界面上显示一个或多个图形图表。所述图形图表图示与事故相关的下述因素中的一个或多个：事故的响应时间、事故或失败的客户交互的强度、事故的根本原因或者解决事故失败，或者每一个通道、子通道或应用的事故或失败的客户交互的比率。

在本发明的另一个实施例中，处理器可操作用来执行在计算机可读介质中存储的计算机课可读指令，以在用户界面上显示到各个事故的链接，用于查看与各个事故有关的分析和细节。

本发明的一个实施例是用于监测系统的计算机程序产品，该计算机程序产品包括具有在其中实施的计算机可读程序代码部分的至少一个计算机可读介质，该计算机可读程序代码部分包括多个可执行部分。一个可执行部分被配置为：通过使用处理器，接收与两个或更多个事故有关的信息，其中，每一个事故与一个或多个企业通道、子通道或应用相关，并且，处理器与存储器装置、通信装置、用户界面和计算机可读程序代码可操作地耦合。另一个可执行部分被配置为：将信息存储在存储器装置中。另一个可执行部分被配置为：跟踪至少一个事故在事故的发生和解决之间的状态。另一个可执行部分被配置为：在用户界面上显示在通道、子通道、应用或各个事故级别上与事故有关的信息。

此外，根据本发明的一个实施例，用户界面显示与所述两个或更多个事故有关的信息，所述信息例如是：打开的事故单的数量；打开得比特定响应时间长的事故；每小时、每天和每周的每一个通道、子通道和应用的事故的数量；由于事故引起的失败的客户交互的数量；事故的根本原因；或者由于与其它通道、子通道或应用有关在通道、子通道或应用中的失败的客户交互的数量。

在本发明的另一个实施例中，计算机程序产品包括可执行部分，该可执行部分被配置为：在用户界面上显示与每一个企业通道、子通道或应用相关的事故的数量。

在本发明的另一个实施例中，计算机程序产品包括可执行部分，该可执行部分被配置为：在用户界面上显示与每一个企业通道、子通道或应用相关的性能分数。

在本发明的另一个实施例中，计算机程序产品包括可执行部分，该可执行部分被配置为：在用户界面上显示一个或多个图形图表。所述图形图表图示与事故相关的下述因素中的一个或多个：包括事故的响应时间、事故或失败的客户交互的强度、事故的根本原因或者解决事故失败，或者每一个通道、子通道或应用的事故或失败的客户交互的比率。

在本发明的另一个实施例中，计算机程序产品包括可执行部分，该可执行部分被配置为：在用户界面上显示由于事故引起的失败的客户交互。

本发明的一个实施例是用于监测系统的计算机程序产品，该计算机程序产品包括具有在其中实施的计算机可读程序代码部分的至少一个计算机可读介质，该计算机可读程序代码部分包括多个可执行部分。一个可执行部分被配置为：通过使用处理器，接收与一个或多个事故有关的信息，其中，所述一个或多个事故与两个或更多个企业通道、子通道或应用的相关，并且，处理器与存储器装置、通信装置、用户界面和计算机可读程序代码可操作地耦合。另一个可执行部分被配置为：将信息存储在存储器装置中。另一个可执行部分被配置为：在用户界面上一起显示所述两个或更多个通道、子通道或应用以及关于同每一个企业通道、子通道或应用相关的所述一个或多个事故的信息。

此外，根据本发明的一个实施例，计算机程序产品包括可执行部分，该可执行部分被配置为：在用户界面上显示在通道、子通道、应用或各个事故级别上与所述一个或多个事故有关的信息。

在本发明的另一个实施例中，计算机程序产品包括可执行部分，该可执行部分被配置为：跟踪至少一个事故在事故的发生和解决之间的状态。

在本发明的另一个实施例中，用户界面显示与所述一个或多个事故有关的信息，所述信息例如是：打开的事故单的数量；打开得比特定响应时间长的事故；每小时、每天和每周的每一个通道、子通道和应用的事故的数量；由于事故引起的失败的客户交互的数量；事故的根本原因；或者由于与其它通道、子通道或应用有关在通道、子通道或应用中的失败的客户交互的数量。

在本发明的另一个实施例中，计算机程序产品包括可执行部分，该可执行部分被配置为：在用户界面上显示关于与事故相关的性能是否可接受的信息。

在本发明的另一个实施例中，计算机程序产品包括可执行部分，该可执行部分被配置为：在用户界面上显示一个或多个图形图表。所述图形图表图示与事故相关的下述因素中的一个或多个：包括事故的响应时间、事故或失败的客户交互的强度、事故的根本原因或者解决事故失败，或者每一个通道、子通道或应用的事故或失败的客户交互的比率。

在本发明的另一个实施例中，计算机程序产品包括可执行部分，该可执行部分被配置为：在用户界面上显示到各个事故的链接，用于查看与各个事故有关的分析和细节。

已经论述的特征、功能和优点可以在本发明的各个实施例中独立地实现，或者，可以与其它的实施例结合，可以参考下面的描述和附图来了解其它实施例的进一步的细节。

附图说明

已经这样笼统地描述本发明的实施例，现在将参考附图，这些附图并不一定是按比例绘制的，其中：

图1提供根据本发明实施例的企业内的通道和知识管理系统之间的交互的概要；

图2提供图示根据本发明实施例的知识管理系统中的各个系统的交互的系统图；

图3提供根据本发明实施例的图示生产支持内的事故的概要的知识管理系统的主页；

图4a提供根据本发明实施例的知识管理系统的仪表盘系统的处理流程；

图4b提供根据本发明实施例的图示生产支持内的事故的通道概览的知识管理系统的仪表盘；

图5提供根据本发明实施例的图示生产支持内的事故的子通道概览的知识管理系统的另一仪表盘；

图6提供根据本发明实施例的图示生产支持内的事故的事故等级概览的知识管理系统的另一仪表盘；

图7提供根据本发明实施例的图示生产支持内的特定事故的事故概览的知识管理系统的另一仪表盘；

图8提供根据本发明实施例的图示用于响应于特定事故的事故恢复处理的搜索和显示功能的知识管理系统的实用手册界面；

图9提供根据本发明实施例的图示用于解决的事故单的搜索和显示功能的知识管理系统的知识库界面；

图10提供根据本发明实施例的图示用于物理、逻辑和交易处理图的搜索和显示功能的知识管理系统的处理图界面；

图11提供根据本发明实施例的图示物理、逻辑或交易处理图的示例的知识管理系统的处理图显示；

图12提供根据本发明实施例的从客户角度图示流程图的示例的知识管理系统的流程图显示；

图13a提供根据本发明实施例的知识管理系统的操作可靠性指标系统的处理流程；

图13b提供根据本发明实施例的图示每个通道的可靠性分数的知识管理系统的操作可靠性指标主页；

图14a提供根据本发明实施例的图示通道内的每个子通道、应用和类别的可靠性分数的知识管理系统的操作可靠性指标评分界面；

图14b提供根据本发明实施例的图示两个类别的评分度量的知识管理系统的操作可靠性指标评分模板；

图14c提供根据本发明实施例的图示两个类别的评分度量的知识管理系统的另一操作可靠性指标评分模板；

图14d提供根据本发明实施例的图示两个类别的评分度量的知识管理系统的另一操作可靠性指标评分模板；

图14e提供根据本发明实施例的图示两个类别的评分度量的知识管理系统的另一操作可靠性指标评分模板；

图15提供根据本发明实施例的图示用于与知识管理系统的一个部分有关的层次结构和联络的搜索和显示界面的知识管理系统的联络人界面；

图16提供根据本发明实施例的图示用于在系统中报告事故的请求表的知识管理系统的事故报告请求界面；

图17提供根据本发明实施例的图示特定事故的报告概览的知识管理系统的事故报告；

图18提供根据本发明实施例的图示事故通知处理流程的知识管理系统的处理流程；

图19提供根据本发明实施例的图示打开事故的列表的知识管理系统的事故主页；

图20提供根据本发明实施例的图示处于事故单内的信息的一部分的知识管理系统的事故通信界面的一部分；

图21提供根据本发明实施例的图示处于事故单内的信息的另一部分的知识管理系统的事故通信界面的另一部分；

图22提供根据本发明实施例的图示处于事故单内的信息的另一部分的知识管理系统的事故通信界面的另一部分；

图23提供根据本发明实施例的图示处于事故单内的信息的另一部分的知识管理系统的事故通信界面的另一部分；

图24提供根据本发明实施例的图示处于事故单内的信息的另一部分的知识管理系统的事故通信界面的另一部分；

图25提供根据本发明实施例的图示处于事故单内的信息的另一部分的知识管理系统的事故通信界面的另一部分；

图26提供根据本发明实施例的图示事故响应处理流程的知识管理系统的处理流程；

图27提供根据本发明实施例的图示用户可用的认证和模块的知识管理系统的学术主页界面；

图28提供根据本发明实施例的图示用户可用的认证和模块的知识管理系统的扩展的学术主页界面；

图29提供根据本发明实施例的图示关于用户的模块显示的知识管理系统的学术模块界面；以及

图30提供根据本发明实施例的知识管理系统的学术系统的处理流程。

具体实施方式

现在，将在下文中参考附图更全面地描述本发明的实施例，在这些附图中示出了本发明的一些实施例，但是没有示出本发明的所有实施例。当然，可以用诸多不同的形式来实施本发明，并且本发明不应该被解释为局限于本文中所阐述的实施例，提供这些实施例，使得本公开将满足适用的法律要求。相同的附图标记始终是指相同的元件。尽管在本文中描述的本发明的实施例通常被描述为涉及“银行”，但是本领域的技术人员将会理解，本发明的其它实施例可以涉及其它企业或金融机构，这些企业或金融机构代替银行或与银行合作来执行本文描述的银行正执行的处理或步骤中的一个或多个。本发明的其它实施例可以完全地涉及金融行业之外的其它企业。

如本领域的技术人员根据本公开所理解的，本发明可以被实施为一种方法或设备(系统、计算机程序产品、装置等)或前述的组合。因此，本发明的实施例可以采用全部硬件实施例、全部软件实施例(包含固件、驻留软件、微代码等)、或者组合软件和硬件方面的实施例的形式，其中，所述组合软件和硬件方面的实施例在本文中通常被称为“系统”。而且，本发明的实施例可以采用计算机程序产品的形式，该计算机程序产品包括计算机可用存储介质，该计算机可用存储介质具有在该介质中实施的计算机可用程序代码/计算机可读指令。

可以利用任何合适的计算机可用介质或计算机可读介质。计算机可用介质或计算机可读介质可以是，例如，但不限于，电子、磁、光、电磁、红外或半导体系统、设备或装置。计算机可读介质的更具体的示例(非穷尽的列表)将包括以下：具有一条或多条布线的电连接；或者实存的存储介质，例如，便携式计算机磁盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或闪存)、压缩盘只读存储器(CD-ROM)、或者其它的实存的光存储装置或磁存储装置。

用于执行本发明的操作的计算机程序代码/计算机可读指令可以用诸如Java、Perl、Smalltalk、C++等的面向对象、脚本或非脚本编程语言写成。然而，用于执行本发明的操作的计算机程序代码/计算机可读指令还可以用诸如“C”编程语言或类似的编程语言的常规的程序设计语言写成。

在下面，将参考方法或设备(系统、计算机程序产品、装置等)的流程图和/或框图来描述本发明的实施例。将会理解，流程图和/或框图中的每一块、以及流程图和/或框图中的块的组合可以通过计算机程序指令来实现。可以将这些计算机程序指令提供给通用计算机、专用计算机或其它可编程数据处理设备的处理器，以产生特定机器，从而使得通过计算机或其它可编程数据处理设备的处理器执行的指令形成用于实现在流程图和/或一个或多个框图块中指定的功能/动作(act)的机构。

还可以将这些计算机程序指令存储在计算机可读存储器中，从而使得存储在计算机可读存储器中的指令产生包含实现在流程图和/或一个或多个框图块中指定的功能/动作的指令的制造制品，其中，计算机可读存储器可以指导计算机或其它可编程数据处理设备以具体的方式运行。

还可以将计算机程序指令加载到计算机或其它可编程数据处理设备上，使得要在计算机或其它可编程设备上执行一系列的操作步骤，以产生计算机实现处理，从而在计算机或其它可编程设备上执行的指令提供用于实现在流程图和/或一个或多个框图块中指定的功能/动作的步骤。可替换地，为了实现本发明的实施例，可以将计算机程序实现的步骤或动作与操作者或人实现的步骤或动作结合。

图1图示根据本发明实施例的知识管理系统1。知识管理系统1是被配置为管理整个银行的全部通道或至少多个通道、以及这些通道内的子通道的知识的系统。在图示的实施例中，这些通道包括，例如，电子商务通道2、银行中心技术(“BCT”)通道3、自动取款机(ATM)通道4、抵押、家庭资产和保险技术(“MHEIT”)通道5、卡服务通道6、存款联络中心(“DCC”)通道7、以及其它附加通道8。然而，在本发明的其它实施例中，知识管理系统1可以为任何一种企业的不同的LOB、部门或者通道提供相同或相似的支持。

图2提供图示根据本发明实施例的知识管理系统1中的各个系统的交互的系统图100。如图2所述，用户计算机系统110通过网络102与知识管理服务器120、一个或多个银行数据库130和一个或多个银行计算机系统140可操作地耦合。以这样的方式，用户计算机系统110的用户104可以从知识管理服务器120、银行数据库130和银行计算机系统140接收电子信息。网络102可以是诸如因特网的全球区域网络(GAN)、广域网(WAN)、局域网(LAN)、或者任何其它类型的网络或网络的组合。网络104可以提供网络中的装置之间的有线通信、无线通信、或者有线和无线通信的组合。

如图2所示，用户计算机系统110通常包括通信装置111、处理装置112和存储器装置113。如本文所使用的，术语“处理装置”通常包括用于实现特定系统的通信和/或逻辑功能的电路。例如，处理装置可以包含数字信号处理器装置、微处理器装置、各种模拟数字转换器和数字模拟转换器、以及其它支持电路，和/或前述的组合。系统的控制和信号处理功能根据其相应的能力被分配在这些处理装置之间。处理装置可以包含基于其计算机可读指令来操作一个或多个软件程序的功能，该计算机可读指令可以存储在存储器装置113中。

用户计算机系统110的处理装置112与通信装置111和存储器装置113可操作地耦合。处理装置112使用通信装置111通过网络102与知识管理服务器120、银行数据库130和银行计算机系统140通信。这样，通信装置111通常包括用于与网络102上的其它装置通信的调制解调器、服务器或其它装置，以及用于与一个或多个用户104通信的显示器、鼠标、键盘、传声器和/扬声器。如图1中进一步所示，用户计算机系统110包括存储在存储器装置113中的计算机可读指令114，该存储器装置113包括web浏览器115的计算机可读指令114，或者允许用户计算机系统110与网络102上的一个或多个其它装置通信的其它类似的应用。web浏览器115允许用户104访问知识管理服务器120中的知识管理应用125。知识管理应用125将表示在所有通道的同事的知识的信息聚集到一个应用中，并且除其它以外，存储用于解决在各个通道内发生的生产事故问题的信息。通常为银行职员的用户104使用知识管理应用125作为他们的寻找所有企业相关信息参考的位置的源，如下面更详细的论述。

如图2所示，知识管理服务器120通常包括通信装置121、处理装置122和存储器装置123。处理装置122与通信装置121和存储器装置123可操作地耦合。处理装置122使用通信装置121通过网络102与用户计算机系统110、银行数据库130和银行计算机系统140通信。这样，通信装置121通常包括用于与网络102上的其它装置通信的调制解调器、服务器或其它装置。如图2进一步所示，知识管理服务器120包括存储在存储器装置123中的计算机可读指令124，该存储器装置123包括知识管理应用125的计算机可读指令124。尽管图2图示作为一个系统的知识管理服务器120，但是重要的是，请注意，存在一个或多个系统，每个系统具有进行收集、存储和分发知识管理系统1的信息的相似部件。

银行数据库130通常包括通信装置131、处理装置132和存储器装置133。处理装置132与通信装置131和存储器装置133可操作地耦合。处理装置132使用通信装置131通过网络102与用户计算机系统110、知识管理服务器120和银行计算机系统140通信。这样，通信装置131通常包括用于与网络102上的其它装置通信的调制解调器、服务器或(一个或多个)其它装置。如图2进一步所示，银行数据库130包含存储在存储器装置133中的计算机可读指令134，该存储器装置133包括知识管理应用135的计算机可读指令134。对于知识管理应用125，使用数据存储应用135来从各种银行计算机系统140和知识管理服务器120捕获和存储信息。例如，在一个实施例中，银行数据库130存储与知识管理系统1的实用手册、知识库、图、流程、操作可靠性指标、联络人、报告、事故通信界面和学术有关的数据，所有这些都在下面被详细地论述。尽管图2图示作为一个系统的知识管理服务器130，但是重要的是，请注意，可存在一个或多个数据库，每个数据库具有进行捕获、存储和/或分发知识管理系统1的信息的相似部件。

银行计算机系统140通常包括通信装置141、处理装置142和存储器装置143。处理装置142与通信装置141和存储器装置143可操作地耦合。处理装置142使用通信装置14通过网络102与用户计算机系统110、知识管理服务器120和银行数据库130通信。这样，通信装置141通常包括用于与网络102上的其它装置通信的调制解调器、服务器或(一个或多个)其它装置，以及用于与一个或多个用户104通信的显示器、鼠标、键盘、传声器和/扬声器。如图1进一步所示，银行计算机系统140包含存储在存储器装置143中的计算机可读程序指令144，该存储器装置143包括银行应用145的计算机可读指令144。部分地使用银行应用145来与为其它银行系统提供支持一同捕获知识管理应用125所需的信息。尽管图2图示作为一个系统的银行计算机系统140，但是重要的是，请注意，可存在一个或多个系统，每个系统具有进行捕获和分发知识管理系统1的信息的相似部件。

图3图示知识管理应用主页50。这是这样的页面：在本发明的一个实施例中，当用户104自动或手动地在该页面上登录时，将用户104带到知识管理系统1。知识管理应用主页50具有用于知识管理系统1内的各种应用的标签。知识管理应用主页50包含用于playbook(实用手册)100、knowledgebase(知识库)200、map(图)300、flow(流程)400、dashborad(仪表盘)500、ORI(操作可靠性指标)600、contact(联络人)700、report(报告)750、ICI(“事故通信界面”)800和academy(学术)900部分的标签。所有生产支持团队和具有访问权的其他员工均使用知识管理应用125，以便监测、诊断和修复任何生产事故、实现新的生产应用，以及存储与生产支持有关的所有知识。

在本发明的一个实施例中，可以使用知识管理系统1来跟踪在银行内发生的事故。事故是在银行系统和应用内发生的正常操作程序以外的事件。如果在事故发生时或在事故发生之后的时间点客户受事故的影响，则该事故可以导致客户交互失败(“FCI”)。对于每个事故，事故还可以导致降低的客户交互(“DCI”)、损失的人小时(PHL)和损失的代理分钟(“AML”)。通过知识管理应用125，知识管理系统1跟踪用于银行计算机系统140和银行应用145的事故诊断和分析的这些度量中的所有度量。

传统上，当发生事故时，存储这些事故的细节，并且，员工根据需要核查这些事故。而且，不是在集中化的位置建立或维护与事故有关的系统信息和精确的联络人团体。因此，当员工将开始队列中的下一个事故时，或者当管理层催促解决某一特定事故，并且员工不知道联络哪些处理专人去解决事故时，核查这些事故。这种跟踪和解决的方法花费比核查事故的影响和使适当的资源来解决这些事故所需的时间长的时间。这种系统将允许由于相同的原因反复地发生多次FCI。

部分地以减少FCI为目标而设计了知识管理系统1的实施例。一般来说，事故的数量和持续时间直接对应于FCI的数量。这样，知识管理系统1的实施例关注减少事故的数量和持续时间，于是也就减少对客户的负面影响。

为了按照优先级或其它类别来组织事故，可以给事故指定不同的严重性级别。在一个实施例中，当在银行计算机系统140中发生事故时，将这些事故编组为三个严重性级别。严重性一(1)事故是导致对客户和/或同事完全中断服务或者停工的高影响重大事件。这些类别的事故表示最高的评定等级(rating)。通常，在严重性一(1)事故中没有回避方法，并且，立即解决这些事故，以防止对客户和/或同事进一步中断服务或者停工。严重性二(2)事故是导致对客户和/或同事部分中断服务或者停工的中等影响事件。通常，这些事件可以使用回避方法或处理变化，银行可以利用此来防止在实现永久性修复之前的时间内进一步中断服务或停工。严重性三(3)事故是对客户和/或同事具有最少影响的低影响或非普遍事件。这些类别的事故由银行根据需要来修复。在本发明的一些实施例中，知识管理系统1仅仅跟踪严重性一(1)和二(2)事故。

图4a图示知识管理系统1用来通过仪表盘500跟踪和显示在银行发生的事故的仪表盘处理流程1500。如块1502所示，当发生事故时，知识管理应用125通过推或拉从银行计算机系统140接收与在各个银行计算机系统140和相关银行应用145发生的事故有关的信息。其后，如图4a中的块1504所示，知识管理应用125按照状态、描述、开始日期、结束日期、持续时间、严重性级别、受影响的通道(即，电子商务2、BCT 3、ATM 4等)、受影响的子通道(即，在线银行、dot com、小企业等)、出故障的客户交互等来组织事故，并将数据存储在银行数据库130上，以供用户104分析。如块1506所示，知识管理应用125与用户计算机系统110通信，以便通过使用仪表盘500显示在总体、通道、子通道和各个事故级别上与事故有关的数据。如块1508所示，为了通过仪表盘500核查和分析在银行发生的在所有通道、子通道和各个事故级别上的事故，用户104利用web浏览器115或类似的应用来访问知识管理应用125。

如图3、4b至7所示，在各个仪表盘上显示由知识管理系统1聚集和显示的事故信息。如图3所示，知识管理应用主页50提供与跟踪当前在各个通道级别打开的事故的数量有关的数据。对于每个通道，知识管理应用主页50显示当前的事故状态部分60和日常性能部分70。当前事故状态部分60显示仪表62，在一些实施例中，该仪表图示打开的严重性级别一(1)违章事故64的数量和打开的严重性级别二(2)违章事故66的数量。在一个实施例中，仪表62用绿色、黄色或红色显示读数，以便图示每个通道中的所有事故的一般状态级别。

当用户104浏览知识管理应用125的其余部分时，知识管理应用125的用户104可以选择分离按钮52，并且当前事故状态框60在用户的屏幕上保持为顶级视图。

知识管理应用主页50是上层管理层通过提供与通道级别的严重性一(1)和严重性二(2)失败的客户事故有关的数据的概要来了解系统的整体健康状态的工具。

在一些实施例中，知识管理应用125的日常性能部分70以一千(K)为增量图示对于每个通道的一天内已经发生的事故的总数72。日常性能部分70还在标尺74出示总概要，从而向用户104提供对正常(用绿色)或非正常(用红色)的事故的数量的视觉显示。员工(尤其是执行者)使用仪表62和标尺74来跟踪高级别上的正在发生的事故的数量和生产支持团队的响应。如果存在示出高级别的事故的特定通道，则用户104可以掌握附加数据分析工具，以诊断和跟踪什么因素正导致这些事故。

用户104通过选择仪表盘500标签来浏览知识管理应用125中的附加工具。如图4B所示，选择仪表盘500标签呈示仪表盘500，与主页50一样，仪表盘500显示日常性能部分70，并且包括事故的总数72和图示事故数量正常还是不正常的标尺74。然而，仪表盘500还图示通道状态部分502。通道状态部分502以大量的图表提供每个通道上的事故的影响的视图。用户104可以通过选择日常性能部分70中的通道名链接或图标来查看分开的通道信息。例如，图4b图示与电子商务通道2有关的图表。通道状态部分502图示电子商务通道2的响应和恢复图表510、FCI强度图表512、根本原因图表514和FCI比率图表516。响应和恢复图表510指示正在进行生产支持以解决特定一天内的任何严重性级别一(1)和严重性级别二(2)事故的平均时间。FCI强度图表512图示在几周、几天或几个小时的时间段在正确的响应时间内没有被修复的事故的数量。根本原因图表514是以诸如生产释放改变、一切正常(“BAU”)改变、BAU故障、未经核准的改变或者杂项改变的各种改变的百分率来图示事故的根本原因的饼图。最后，FCI比率图表516图示对于每个通道的与银行内的其它通道有关的FCI的百分率。

用户104可以通过选择(双击)日常性能部分70中的对于通道的链接或图标来查看与每个通道的特定子通道相关的事故。例如，图5图示诸如在线银行520、dotcom 522和小企业524子通道的电子商务通道2d的子通道中的事故的视图。在通道视图部分503中针对每个子通道显示事故，基本上与在图4b的日常性能部分70中针对通道级别显示事故的方式相同。如图5所示，在子通道状态部分504中显示这些子通道中的每个的事故概览。子通道状态部分504显示在图4b的通道部分502中显示的相同的图表和信息，但是，当用户104在通道视图503中选择相关的子通道名或图标时，这些图表示出每个子通道的事故的发生。

如果用户104想要检查任何子通道内的特定事故，则用户104通过例如选择(双点击)图5中所示的仪表盘500的子通道名或图标来在仪表盘500中下钻到图6中所示的值班管理者(“MOD”)事故列表530。在一个实施例中，MOD是银行的负责最终解决特定通道、子通道或应用级别中的事故的管理者。MOD事故列表530具有事故状态部分540和客户登录量532。事故状态部分540列出事故单(incident ticket)数541、状态542、事故的描述543、开始日期544、结束日期545、持续时间546、严重性547、受影响的通道548，以及每个事故的FCI 550、DCI 551、PHL 553和AML 554。这种仪表盘允许用户104检查系统中的每个未解决的事故和检验每个事故的状态。如图6所示，用户104可以按月、周和天查看事故，以及改变在该页面上同时查看的事故的数量。

如图6所示的客户登录视图532允许用户查看已经登录到银行的相关通道、子通道和应用的客户的数量。例如，如图6所示的客户登录视图532提供已经登录到电子商务通道2的在线银行子通道的客户的数量。该图表提供对要登录到通道、子通道或应用的客户的数量的一般测量，所以可以将其与已经在该通道、子通道或应用中发生的事故的数量进行比较。在很多情况下，事故的数量与客户登录的数量成比例，但是并不总是这样。客户登录视图532仅仅提供帮助跟踪和诊断在银行发生的任何事故的另一工具。

如图7所示，仪表盘500还允许用户104查看关于每个单独的事故的细节。用户104可以选择MOD事故列表530中的事故单号541，以查看详细报告560。详细报告560包含在下面详细地论述的事故单中包含的重要信息的概览。详细报告560具有四个部分，即，一般信息部分562、因果信息部分564、影响信息部分570和概览信息部分580。如果解决方案满足服务水平协议、相关实用手册、以及最近更新的时间和日期，则一般信息部分562列出描述、开始日期、结束日期、持续时间、根本原因来源、事故单号、问题单号、严重性。因果信息部分564列出在何处发生故障、什么事件导致故障、以及什么问题使故障影响更加复杂。影响信息部分570包含受影响的通道548、受影响的技术执行者572、受影响的子通道573、地理位置574、FCI 550、DCI 551、PHL 552和AML 553。概览信息部分580包含事故的恢复、原因和解决的概览，如它当前的那样。在详细报告560中完成的字段的数量取决于解决事故有多难、事故在生产支持过程内发生多久、以及已经将多少细节添加到事故单，如针对ICI部分800的进一步详细的论述。

详细报告560允许用户104检查和跟踪该用户104感兴趣的特定事故的事故进展。通过检查打开的事故单或完成的事故单，具有相似的或者相同的问题的用户104可以减少他/她自己或者涉及特定事故的其他人的工作量。如果过去已经发生相同或相似的问题，则该事故的解决方案可以帮助解决本事故。详细报告560和事故单提供与每个生产事故有关的处理、人员和修复的详细概要。而且，因为详细报告560列出了要处理事故的最后一个人和查看事故单的最后时间，所以，用户104还可以利用详细报告560来识别事故状态和确定解决事故过程中的下一个步骤。

在图8中图示实用手册100标签。实用手册100数据库允许用户访问事故恢复指南150。事故恢复指南150包含如何可以解决事故的信息和解决事故所采用的步骤。提供实用手册搜索部分170，其中，用户104选择他/她需要事故恢复指南150的通道和应用。可替换地，用户104可以使用实用手册搜索部分170来搜索事故恢复指南150。在一些实施例中，实用手册搜索部分170可以是显示关于用户104选择的应用、子通道或通道的所有事故恢复指南150的特定页面。

事故恢复指南150是用于识别事故的根本原因和解决这个问题的分步骤的过程。事故恢复指南150包含关于如何可以解决事故的信息和解决所采用的步骤。在图8中图示示例的事故恢复指南150。事故恢复指南150具有概要部分151，该概要部分151列出症状/事故152、可能原因153、受影响的可能通道154、整治领导155、最初治疗(triage)寻呼团体156、以及关于事故恢复指南150的任何相关注释。例如，症状/事故152列出产生事故的错误(例如，如果在线银行监测器正显示登录失败)或者事故本身。症状/事故152的可能原因153指示过去已经产生错误或者将要产生错误的常见原因。受影响的可能通道154向用户104指示错误可能会影响到的不同的通道或子通道。整治领导155列出MOD和基础设施领域的知识渊博者(“IDG”)。MOD提供对生产支持环境的高层责任制，但是具有对严重事件的MOD的IDG伙伴关注服务恢复，并从事建立的根本原因分析。最初治疗寻呼团体156是为了解决事故而可能必须包含在事故恢复处理中的团体的列表。注释部分156还被包含在内，从而向起草事故恢复指南150的人提供列出任何建议或特殊指令的地方。

事故恢复指南150还具有事故恢复指南显示部分160。该部分列出每个事故恢复指南150的所有处理步骤162。处理步骤162包含进一步定义事故恢复指南150处理和给知识管理应用125内的其它区域和数据提供交叉参考的链接和注释164。链接和注释164可以将用户104带到知识管理应用125内的其它标签。因此，在特定步骤的过程中，在恢复处理中，用户104可以在到“process map”的链接上点击，并且，可以将用户带到Map 300部分中的相应处理图。另外，用户104可以对这些步骤中的一个步骤有问题，并且，可能需要与合适的联络人就此进行讨论。用户104可以选择“联络人”链接，并且可以被带到联络人700标签中的正确的联络人名单，其概括了谁是该具体步骤的合适的联络人。而且，事故恢复指南150被链接到稍后讨论的知识库200标签中的特定事故单，使用该具体事故恢复指南150已经解决了这些特定事故单。为了识别使用事故恢复指南150如何解决前面的事故，用户104可以查看在事故恢复指南150链接的事故单。

在一个实施例中，实用手册100包含用于在企业内发生的每个生产事故的事故恢复指南150。如果在还没有事故恢复指南150的情况下发生了事故，则指定去修复该事故的团队创建事故恢复指南150并将其添加到实用手册100。

知识库200是知识管理应用125中的第二标签。如上所述，无论何时存在需要检查的事故，都可以使用ICI 800标签来填写事故单。在解决事故之后，将完成的单存储在知识库200中。因此，对解决事故有问题的同事可以在知识库200中搜索相似事故的解决方案。

图9图示包含搜索部分210和结果部分220的知识库200标签的界面的一个示例实施例。在知识库搜索部分210中，用户104可以通过关键字212、应用214、事故单号216和日期范围218来搜索任何的可用单。应用214搜索寻找和显示与用于生产支持的特定应用有关的任何单。结果部分220列出在搜索中寻找到的每个事故，并且列出事故单号222、开始日期224、结束日期226、问题描述228、事故原因230和解决方案232。

在搜索特定事故的知识管理应用125的用户104必须将事故上报到其他同事以便解决之前，这些用户可以搜索相关事故并寻找对相关事故的解决方案。这样防止银行的其他同事必须撇开他们的日常工作量去对他们过去已经处理的事故进行诊断。用户104可以利用其他同事的知识来自行诊断事故，而不必联络那些特定的同事。

知识管理应用125的用户104在可选择的事故单号222链接上点击，以打开概括事故单的历史的全部事故报告。在描述ICI 800标签时，在下面描述事故单的内容。事故单内的链接允许用户104被直接发送给整个知识管理应用125中的其它标签，例如，实用手册100标签。例如，如稍后对ICI 800标签的更加详细的描述，检查事故单的历史的用户104可以选择与正查看的特定事故有关的事故恢复指南150并被带到实用手册100标签中的相关事故恢复指南150。为了允许用户104了解随着时间的流逝如何修改事故报告，可以存储不同版本的事故单。如稍后对ICI 800标签的更加详细的描述，用户104在解决事故时能够查看随着时间的流逝的事故单的改变，以检查处理、失败和成功。

图10图示Map 300标签，其包括用于诊断事故的三种主要类别的处理图：物理310、逻辑320和交易330处理图。用户104可以选择(点击)图10中的任何名的map 300，以访问特定的map 300。用户104还可以通过关键字搜索功能340来搜索map 300。在本发明的其它实施例中，map 300的界面的左边列出每个通道和子通道的可用的处理图。当在左边选择处理图名时，在map 300界面的右边，以窗口显示处理图。在一个实施例中，这些处理图中的所有程序和系统都被交叉链接到其它的处理图，并且，通过知识管理应用125中的其它标签部分可以直接访问。

图11图示来自map 300标签的物理处理图的示例。在本发明的一个实施例中，map 300部分具有反转(roll over)特征，即：无论何时光标位于处理图中的要素上，都显示更多的信息。当处理图中的要素被反转时，将对象下钻到下一级，从而提供与该要素有关的更多的信息，例如，解释处理图的该要素的附加图片或文本。

在一个实施例中，当点击或滚动特定图中的图标时，在界面显示上呈现弹出窗口350。窗口350具有与该要素的属性相关的标签和列表。这些标签涉及每个标签的属性列表信息和图标的不同方面。在一些实施例中，出于组织目的，每个标签可以具有搜索功能、层次结构下钻树、和/或信息列表。每个标签中的属性涉及的信息包括，但不限于，文档管理、性能度量、到其它处理图的链接、知识管理应用中的数据、以及对与窗口350相关的处理图中的各要素的系统要求。在一个实施例中，使用在每个map的页面的顶部的导航图标360，用于链接到知识管理系统1的其它区域和用于创建和编辑位于弹出窗口350中的数据。

物理图310显示关于系统的硬件和物理细节。它们包含正在调查的系统的硬件部件、部件的位置、数据库、服务器等。物理图310捕获与以下有关的信息：框(box)(或者银行中的物理硬件)；传输协议(通过因特网传送音频和视频数据的标准化格式)；网络装置；数据库；服务提供者；框的位置；IP地址；系统需要的容量；服务器角色识别(例如，主体、故障转移、激活与非激活状态)；框来源(负责物理硬件的组织)；对象编排服务(“OOS”)(用于将不同类别的硬件捆绑在一起)；以及与其它系统、应用和/或要素的交互信息。

可以通过在map中的图标上滚动或点击来访问物理图310中的特定要素的信息。例如，当在处理图中包含服务器时，用户可以点击或滚动服务器图标，并且窗口350弹出显示标签的数量和下面在标签中列出的服务器的属性。在一些实施例中，物理图310可以具有带信息的标签，该信息包括，但不限于，监测总结文档(“MSD”)、改变记录、服务器信息、以及性能和容量信息。

MSD信息的标签提供到整个知识管理应用125的文档和数据的链接，但是，所述文档和数据不限于与该特定服务器相关的知识库200中的事故。服务器还可以包含到特定事故恢复指南150的链接，该特定事故恢复指南150用于对与服务器相关的事故的修复。到仪表盘500的链接还可以被包含在MSD标签中。用户可以快速地评估服务器如何使用仪表盘500正在执行以查看与该服务器或应用相关的打开的事故。

用于改变记录信息的标签提供对服务器进行的所有改变(例如，对主机名的改变)的列表、以及在特定时间段内提供给服务器的服务。

服务器信息的标签可以包含操作系统信息、服务水平协议数据、以及用于服务器的其它系统信息，例如，应用清单工具(“AIT”)，其用来跟踪与应用、主机名、框来源、框可用性时间和IP地址有关的清单。这些标签还可以包含到负责维护服务器的联络人的链接，并且，通过点击该链接，将用户104带到联络人700标签，以看见关于联络人的联络信息。

用于性能和容量信息的标签图示实时性能度量和容量，该实时性能度量指示服务器正工作得如何好，该容量指示服务器如何可以控制和存储更多的信息，例如，服务器的停机时间和任何开机或关机的时间。

逻辑图320显示所有交互应用、应用结构和界面、以及它们之间的链接。逻辑图320捕获没有任何硬件细节的应用信息，该应用信息包含前端应用、帮助应用、web服务器信息，包含简单对象访问协议(“SOAP”)(在实现计算机网络中的web服务中的协议说明书或交换结构信息)、web逻辑、web领域(通过多个计算平台来安设、操作和集成电子商务应用)、中间件工具、web方法和在线支持系统(“OSS”)交互。

在一个实施例中，以与物理图310界面相同的方式安设逻辑图320界面。用户104通过滚动图标或选择图标来查看关于特定应用或应用的一部分的信息。窗口在屏幕上弹出显示具有下面列出的标签的属性的标签的数量。标签部分可以具有物理图310的相同标签和/或不同标签中一些。这些标签可以包含关于改变控制的信息、工具和处理图核查信息。改变控制信息列出对于特定时间段内的特定应用的所有改变记录，例如，对应用的更新。工具信息捕获诸如监测工具、日志文件、路由工具和从应用发起的任何其它种类的工具的工具。map核查信息示出，map是否被标志为核查、何时进行了核查、谁已经核查了、以及它在何时被创建。在一些实施例中，标签提供了搜索功能的设施，该搜索功能允许用户104根据正在核查什么处理图而在知识管理应用125中搜索与特定应用、系统或交易有关的信息。

交易图330示出特定交易如何流入或流出应用和系统。该处理图捕获与包含应用和硬件二者的不同界面的终端到终端的交易流程通信或交互。交易图330捕获诸如不同应用之间的交易流程、来自每个应用的输入和输出、处理系统流程、企业功能、排序不同企业功能、和对到其它处理的交易的影响的信息。用户104通过滚动图标或选择map中的图标来查看关于特定交易图330的信息。窗口在屏幕上弹出显示具有下面列出的标签的属性的标签的数量。交易图330的标签部分可以具有物理图310和逻辑图320的相同标签中的一些和/或不同标签。

一般来说，处理图还包含指示谁负责维护处理图的支持团队信息。在一个实施例中，用户104能够向支持团队指出在处理图中需要的改变，该支持团队通过map 300界面从用户104接收对于请求改变的通知。

在一个实施例中，如图12所示，流程400标签从客户界面的角度提供流程图402。应当理解，在其它实施例中，流程400标签可以从银行或企业的角度提供图表。流程图402提供对客户与整个银行界面连接的应用的高级概述。通过在搜索字段404中搜索、使用下钻菜单406、或者在某些情况中选择流程图402内的图标，用户104还可以下钻到下一级流程图402或者查看关于其它应用和系统的其它流程图402，该下一级流程图402提供与客户界面应用和系统有关的更多的细节。

对于银行内的每个通道和子通道，可以存在多个流程图402。如针对map 300部分所述，流程图402与其它客户流程图402，物理310、逻辑320和交易330处理图，以及知识管理应用125的标签内的其它部分交叉链接。如针对处理图所述，用户104滚动或选择流程图402中的图标，以接收关于流程图402中的该要素的更多的信息。此外，在具有标签和每个标签内的属性的弹出窗口中显示信息。

可以在知识管理应用125中更新与处理图和流程图402中的每个有关的要素和信息。对处理图和流程图402中的这些要素和信息进行的改变自动更新任何其它处理图和流程图402或与改变的要素和信息交叉链接的其它信息。例如，可以在银行实现对服务器的更新。为了显示新的服务器容量信息，用户104更新与一个处理图中的服务器有关的信息。结果，如果服务器出现在任何其它的处理图中，则将与该服务器有关的信息自动更新为包含新的容量信息。

ORI 600标签是多级企业性能记分牌。它允许用户下钻到通道、子通道、应用、类别和可预测性因素级别视图，以评估应用的可靠性和稳定性，因为它们与每个类别、子通道和通道有关。给每个可预测性因素、类别、应用、子通道和通道指定加权平均值，该加权平均值与每个在对上述级别的可靠性进行评分时的重要性有关。因此，可以将来自可预测性因素级别的这些分数积累成用于类别、应用、子通道和通道级别中的每个的一个分数。

图13A图示知识管理系统1用来跟踪和显示应用、子通道和通道的可靠性的ORI处理流程1600。如块1602所示，知识管理应用125接收关于每个可预测性因素如何影响每个类别的加权值。用户104通过用户计算机系统110可以手动地指定加权值，或者，可以通过银行计算机系统140基于由知识管理应用125采集的数据来自动确定加权值。指定加权平均值的用户104可以是应用管理者、MOD、或者负责对于银行内的特定应用确定每个可预测性因素如何影响每个类别的其它银行员工。

如块1604所示，知识管理应用还接收关于每个类别如何影响每个应用、子通道或通道，每个应用如何影响每个子通道和通道，以及/或者每个子通道如何影响每个通道的加权值。此外，用户104可以通过用户计算机系统110手动地指定加权值，或者，可以通过银行计算机系统140基于由知识管理应用125采集的数据来自动确定加权值。

如块1606所示，知识管理应用125接收关于用于每个银行应用145的可预测性因素的可靠性数据。如块1608所示，然后，知识管理应用125将可靠性数据转换为每个可预测性因素的分数。例如，对于“if an application has a control plan”的可预测性因素，接收到的可靠性数据是yes或no。在一些实施例中，如果答案是yes，则知识管理应用125将yes转换为100％的分数，并且，如果答案是no，则将no转换为50％。在其它实施例中，接收不同的可靠性数据，将这些可靠性数据转换为不同的分数，稍后对此进行更详细的讨论。此外，用户104可以通过用户计算机系统110手动地指定可靠性数据和分数，或者，可以通过银行计算机系统140基于由知识管理应用125采集的数据来自动确定可靠性数据和分数。

如块1610所示，知识管理应用125获取关于每个类别中的每个可预测性因素的分数，并且基于每个通道内的可预测性因素、类别、应用和子通道的加权值，来计算类别分数、应用分数、子通道分数和通道分数。

图13b图示ORI 600主页的一个实施例。图13B图示关于每个主通道602：电子商务通道2、BCT通道3、DCC通道7、卡通道6、MHEIT通道5和ATM通道4的顶级ORI分数。每个通道602具有图标601，并且，图标601列出每个通道602的通道分数603。用户104可以通过点击一个通道图标601来查看关于通道602内的每个子通道604的ORI 600分数。在其它实施例中，用户104可以通过点击通道名或者使用搜索功能640或下拉菜单642来查看关于每个子通道604的ORI 600分数。

图14a图示关于电子商务通道2的ORI 600的一部分。关于每个通道602的ORI 600包含通道602内的所有子通道604、影响子通道604的每个应用606、以及对每个应用606的影响进行评分的类别608。没有示出用于每个类别608的可预测性因素610，这将在后面详细说明。使用下钻按钮605按指标从子通道604级别下钻到影响应用606级别，下钻到类别608级别，以及下钻到可预测性因素610级别。基于可预测性因素分数612计算各分数，然后，使用加权平均值来计算类别分数614、影响应用分数616、子通道分数618，最后计算通道分数603。

如图14b至14e所示，通过使用ORI分数单620来为每个应用606计算分数。分数单具有类别列622、FCI可预测性因素列624、答案列626、子类别加权列628、源列630、格式列632、比例列634和通道类别加权列636。

类别列622中的类别608覆盖生产支持的管理区域的范围。它们是使用用于生产支持中的任何应用606解决的主管理类别608。基于每个类别608，在知识管理应用125中对每个应用606进行评分。基于对在整个生产支持过程中何地、何时、如何发生FCI的分析，确定关于ORI 600的类别608。在一个实施例中，最重要的类别608被识别为改变管理611、可用性管理612、服务持续性管理613、知识转移管理614、基础设施和风险管理615、容量管理616、服务级别管理617和系统管理618。然而，应当理解，在其它实施例中，可以将标准分成任何数量的不同类别608。

每个类别608具有在可预测性因素列624中图示的大量的相关可预测性因素610。可预测性因素610是关于每个特定类别608的问题、数据值、量度或与如何在银行内发生FCI有关的其它因素。在每个类别608内，关于每个可预测性因素610对导致在应用606的类别608内发生的FCI贡献多少，来对可预测性因素610进行加权，如列628所示。加权的百分率基于对过去导致FCI的可预测性因素610的历史数据分析。每个类别608内的可预测性因素610的总百分率合计为百分之百(100％)。

如图14b所示，改变管理611类别的FCI可预测性因素610可以包含：

●Are the procedures for initiating，approving，verifying andscheduling changes always adhered to？

●Is there a clear distinction between a change request(e.g.upgrade application，change router configuration，update firewallpolicies，etc)and a service request(e.g.resetting a password)？

●Are there regular reviews(i.e.at least quarterly)onperformance of changes implemented against documented keyperformance indicators(“KPIs”)for this application？

●Are multiple related changes grouped and then properlyscheduled and communicated to minimize the impact to the businessusers including last minute schedule changes(e.g.unforseen delaysduring implementation)？

如图14b所示，可用性管理612类别的FCI可预测性因素610可以包含：

●Are there any single points of failure(“SPOF”)(If notknown，please answer yes)？

○If yes，criticality to environment of SPOF？

●Are availability impact information(including the detail ofthe impact of proposed changes)communicated to the changemanagement process area？

●Is there a regular(e.g.at least every 6-months)review ofcurrent infrastructure against required availability

○with a view to identify SPOF？

○with a view to optimizing equipment(lowering cost)？

●Do you have procedures for monitoring，analyzing，andforecasting service availability？

●Are there audit procedures in place to validate the ongoingaccuracy and appropriateness of the monitoring and forecastingprocedures？

●Do you have defined targets for the availability，reliabilityand maintainability of IT infrastructure components(including 3rdparty vendors)relied upon by the application？

●Do you carry out monitoring and trend analysis of theavailability，reliability and maintainability of IT infrastructurecomponents(including 3rd party vendors)to help identify potentialfuture bottlenecks？

如图14c所示，服务持续性管理613类别的FCI可预测性因素610可以包含：

●Is the business continuity plan in standard format？

○What is the date of the last test？

●Have all outstanding issues identified as a result of testingbeen resolved or is an approved business continuity remediation planin place？

●Is there a documented and known recovery plan in place foreach service area，in the event of an unforeseen issue？

●Are there regular backups of critical data taken and storedsecurely？

●Are critical backups of information tested on a regular basis？

●Is testing performed for quality attributes such as reliability，usability，and maintainability？

如图14c所示，知识转移管理614类别的FCI可预测性因素610可以包含：

●Has handover/takeover meeting conducted with initial team？

●Has necessary documentation been completed？

●Rate the quality of on-boarding new resources(bank andstrategic partner)

●Rate the quality of training documentation and schedules

●Are workarounds documented/new changes tested withworkarounds in place？

如图14d所示，基础设施和风险管理615类别的FCI可预测性因素610可以包含：

●Does the application use any non-permitted(“NP”)technologies？(consider software level：non permitted score byenterprise technology and delivery(“ET&D”)(can be more than 1 perapplication))

○If yes，how many instances of NP technology exist？

○Does application have remediation plan for any non-permitted technologies？

●Does application have a control plan？

○Was the control plan updated within past calendar year？

●Does the business impact analysis exist？

如图14d所示，容量管理616类别的FCI可预测性因素610可以包含：

●On average how close are current processing volumes to thevolume ceiling of the application？

●Are there any known initiatives that will increase rate ofgrowth？(Initiative，Sales campaigns，etc.)

●Are threshold alarms in place for individual services thatalert staff about approaching maximum capacity limits？

●Are key components(resources)monitored for capacity load？(e.g.Hard disk，memory，CPU，etc.)

●Is capacity data constantly analyzed to help in resolution ofincidents and problems？

●Are changes to the capacity of the application handledthrough a formal change management process？

如图14e所示，服务级别管理617类别的FCI可预测性因素610可以包含：

●Do service level agreements(“SLA”)exist between LOB andconsumer and small business bank technology and operations？

●Is risk rating assigned by LOB？

●Does the current application design support the LOB riskrating/SLA？

●Are agreements with vendors documented and reflected inthe SLA′s？

●Does the SLA structure include features such as reliability，security，service hours，support，response times，turnaround times，performance criteria？

●Are there mechanisms in place to monitor and measure allitems in existing SLAs？

●Do SLAs have clearly identified key targets for service hours，availability，reliability，support，response times and change handling？

如图14e所示，系统管理618类别的FCI可预测性因素610可以包含：

●Are tools and processes in place to automate or quickly reactto customer/agent impacting events to provide operational relief？

●Are component based technology monitoring tools available？(e.g.Introscope，PerfMon，NetScout，SiteScope，Mqueue CommandCenter，etc.)

●Is the operating system(on which the applicationcomponents are installed)monitored on server and client machines？(Paging，File I/O，Network I/O，Local Disk I/O，Remote Disk I/O)

●Are application performance trends monitored andprojected forward to indicate when thresholds will break andprojected breaks that are alerted with sufficient time to alter theapplication/system to avoid service breaks from happening？

●Are component/Application interfaces monitored(AllComponent Boundaries，Framework Interfaces)

●Are customer experience monitoring tools available？(e.g.Topaz、Online Banking Monitor，Compuware Vantage AgentlessMonitoring(Measure transaction response time，transactionvolume))

在子类别加权列628中对上面列出的每个可预测性因素610指定特定权重，其与每个可预测性因素610如何对产生FCI作出贡献相关。每个可预测性因素610的分数可以由在列630中列出的源、其他员工、或者负责核查评分的用户104手动地输入。可替换地，通过从知识管理系统1或银行计算机系统140中的其它应用接收信息自动地填充这些分数。如格式列632和比例列634所示，这些分数可以是基“yes”或“no”响应、比例、计数值、百分率、数值范围、通过或失败、高中低响应或某一其它相似评定系统。具有诸如比例的多个评定值的项目可以具有定义用于对可预测性因素610的最佳实践的相关文本。在一些实施例中，分数单620可以具有注释字段，允许用户104填充为什么对特定可预测性因素610赋予特定分数，以证实该评定。文本和注释字段帮助在整个通道的评分中创建一致性。

根据对可预测性因素610的答案，在一个实施例中，可预测性因素在答案列626中接收百分之零(0％)至百分之百(100％)的分数。应用606的特定类别608的分数基于在该类别中的每个可预测性因素610的分数之和与在子类别加权列628中列出的因素权重相乘。

在本发明的一些实施例中，当确定应用分数时，并且，在使用应用分数计算子通道和通道分数之前，与每个类别的可预测性因素610一起使用其它分数。例如，在一些实施例中，利用应用风险和控制评价工具(“ARCAT”)来确定ARCAT风险分数和ARCAT控制分数。ARCAT风险分数与固有的应用风险有关。通过考虑与诸如企业影响分析、下游应用、上游应用、交易率、数据量、恢复时间要求、相关硬件和软件、以及隐私数据的应用有关的风险，确定ARCAT风险分数。ARCAT控制分数是一个应用对于各种其它系统或应用所具有的控制度量。基于应用如何与业务持续性、技术构架、平台或环境、生产稳定性、法规遵从、业务处理和信息安全有关，计算ARCAT控制分数。每个应用的ORI分数可以被减少至总分数的一个百分率，并且，ARCAT风险分数和ARCAT控制分数可以与最终的ORI分数相加。例如，可以将一个实施例中的特定应用的ORI分数乘以百分之八十(80％)。可以将所得的分数与基于零(0)至十(10)测量的ARCAT风险分数和基于零(0)至十(10)测量的ARCAT控制分数相加。最后分数仍然是超出了100％，但是现在包含ARCAT风险分数和ARCAT控制分数的附加因素。

而且，如类别加权列636中所示，对每个通道，在某些情况中是每个子通道，指定类别权重，该类别权重与每个应用的类别608如何影响同该应用内的其它类别608有关的每个通道和子通道中的FCI的发生有关。例如，如图14b所示，电子商务通道2的改变管理权重是百分之二十五(25％)，而BCT通道3的权重是百分之二十(20％)，等等。此外，对于可用性管理类别，电子商务的类别权重是百分之十五(15％)，而BCT通道的权重是百分之二十(20％)。对于一个通道中的每个类别，每个加权平均值之和等于百分之百(100％)的总数。因此，每个应用的类别分数614与每个子通道和通道的加权平均值相乘并然后对其求和，所以，每个应用具有关于它如何影响每个子通道和通道的分数。

因此，如前所述，类别分数614是在答案列626中列出的可预测性因素分数610的加权平均值。对于每个子通道或通道的该应用，子通道或通道的应用分数616是类别分数614的加权平均值。在其它实施例中，子通道分数618是该子通道的应用分数616的加权平均值。最后，通道分数603可以是该通道的子通道分数618或应用分数616的加权平均值。

可以实时地、在定期的间隔期间、或按需地更新每个应用的分数单620，以检查通道、子通道和应用的置信度分数。在一些实施例中，特定应用或类别的分数按各种间隔通过电子邮件发送到业务专家或应用管理者，以提醒该负责人及时地填充该字段。在本发明的其它实施例中，跟踪测量时间，并且，将对可预测性因素610的警报和更新请求发送到正确的员工，以确保每个应用的评分保持不断地更新。对可预测性因素610、相关分数或加权平均值进行改变的访问可以仅仅被限制为已经获准清算。

在一个实施例中，对每个评分级别应用彩色编码评分，以使得用户104能够快速识别可接受的、存在失败危险的或失败的通道602、子通道604、应用606、类别608或可预测性因素610。对大于75％的分数指定绿色代码，指示相关度量已经通过并且是可接受的。对50％至70％之间的分数指定黄色代码，指示相关度量存在失败的危险并且应该得以密切的监测。对低于50％的分数指定红色代码，指示相关度量已经失败并且需要立即分析以确定修复。

如图15所示的联络人700部分是用于寻找关于团队、伙伴、联络点、层次结构级别、通知联络以及其它联络参考的必要信息的参考标签。与整个知识管理应用125的其它标签一样，在一个实施例中，为了核查各个员工的联络信息，用户104可以从通道级别下钻到子通道级别，下钻到应用级别。通过在不同通道、子通道或应用级别中选择各个员工的姓名或职位，用户104可以下钻到各级别。可替换地，用户104可以使用联络人搜索特征702或下拉菜单703来寻找特定的联络人。

图15图示对于电子商务通道2的在线银行子通道的联络人700标签中的联络人显示界面704的示例。联络人显示界面704具有两个部分，即，执行者联络人710和管理者联络人720。执行者联络人710部分列出层次结构点712(或职位)和每个层次结构点的联络点714。在一个实施例中，执行者联络人710部分中的层次结构点712列出技术执行者、生产支持执行者、电子商务生产支持执行者、以及技术构架和操作执行者。

本示例中的管理者联络人720部分显示包括内部银行生产支持伙伴的共享服务的联络人。管理者联络人720部分列出与执行者联络人710部分相同的信息，但是在下一级层次结构上列出。管理者联络人720部分还具有层次结构点722和每个层次结构点722的联络点724。在管理者联络人720部分的一个实施例中，层次结构点722列出一级、二级和三级生产支持管理者，websphere，unix，分布性能和容量支持管理者，域管理者，优秀管理者中心，测试伙伴，以及大量的其它管理者和在这些管理者领导下工作的员工。

知识管理应用125的事故恢复指南150、事故单或其它区域指示，联络特定层次结构点722，以解决特定事故。提供链接，以将用户104发送到正确的联络人700标签。例如，如果事故恢复指南150指示应该使共享服务的三级生产支持管理者注意该事故，则链接将用户104带到图15所示的管理者联络人720部分。然后，用户可以将事故单发送到联络点724列中列出的正确的三级生产支持管理者。

在一些实施例中，可以提供层次结构点链接，所以用户104可以通过在层次结构点链接上选择来查看层次结构图。在其它实施例中，用户104可以通过在联络点724列中列出的姓名上点击来查看联络点的电话号码和电子邮件。

如图16所示的报告750标签允许用户能够从在知识管理应用125中跟踪的事故中提取报告。用户104可以通过报告750标签来创建、接收和发送现成或自定义的报告。如图16所示，可以填写事故信息报告生成器751，以创建自定义或现成的报告。报告750标签包含用于通过输入事故单的标题752、开始日期754或结束日期756来生成关于特定事故单的报告的字段。用户104还可以填充他们想要报告的事故单号760或问题单号762。用户104还可以基于一级、二级或三级的严重性评定级别763，事故的状态764，事故的根本原因所有者766，以及消费者和小企业银行技术和操作受托人768(仅列举几个)来创建报告。

图17图示在报告750标签中输入请求之后自定义或现成的报告770看起来怎样。在报告770的概述部分772中，该报告包含在事故信息报告生成器751中输入的信息。因果信息780部分图示事故如何发生，包括源系统781、因果事件782和失败影响783。影响信息790部分展示受影响的通道791、受影响的技术执行者792、受影响的子通道793、影响的地理位置794，以及FCI 795、DCI 796、PHL797和AML798的数量。报告770还列出事故的问题784、受影响的客户785、恢复786信息、原因787和解决方案788。报告770通常为高层执行者管理报告生成并且每日被核查。报告770还可以用于度量收集和分析，该度量收集和分析用于驱动银行的战略目标。

如图19所示的ICI 800标签是从首次识别事故的时候起跟踪事故的地方。图18图示当首次发现事故时处理该事故的通知程序。当在生产过程期间或者在生成系统上发生生产事故时该程序中的第一步骤是，发送具有事故信息的错误记录，以便存储在诸如银行数据库130的数据库中，如块1810所示。在一些实施例中，通过表明已经发生错误的电子邮件或者某些其它通信，用户104接收通知。在接收到通知之后，或者，在执行主动监测时，用户104搜索数据库中是否有新事故，如块1812所示。在用户104识别新事故之后，用户104通过检查数据库中的错误报告来识别与事故相关的问题，如块1814所示。一旦识别了该事故的问题，用户104就在知识库200中搜索是否有在过去已经解决相同问题的任何相关事故，如菱形块1816所示。如果用户104发现事实上有相关事故，则用户104下钻到事故报告，以了解是否解决了该特定相关事故，如菱形块1818所示。如果解决并关闭了该事故单，则用户遵循在知识库200事故单中概括的程序，以解决当前的事故，如块1820所示。当解决了事故时，用户104可以关闭问题，如块1840所示。此外，如前所述，为了帮助后续的用户面对相同或相似的事故，用户104可以在关闭当前事故报告的过程期间使用发现的任何附加信息来更新在知识库200中找到的事故单。

如菱形块1816和1818所示，如果用户104不能找到相关事故单或者该事故没有得以解决，则用户104将新事故单登录到ICI800，如块1822所示。图19图示事故单的事故主页。用户104可以通过在ICI 800主页中选择“新事故”按钮801来输入事故，如块1822所示。在打开新事故之后，将用户104带到事故单屏幕810，如图20至25所示。在一些实施例中，根据存储在银行数据库130中的错误报告中的数据，例如问题单号811、严重性812或开始日期813、以及可以在该错误报告中找到的任何其它信息，知识管理应用125可以将数据拉入到新事故单。然而，用户104还具有编辑或删除事故单中的任何信息的能力。因此，在用户104创建新单之后，他/她可以输入或改变问题单，该问题单的严重性812、主单号814(在首次识别生产事故时用于识别它的第一错误报告的数量)、客户端影响815和状态809。而且，当用户104填充事故单时，他们可以通过选择starttime 813、L2 awareness 816、MOD engaged 817、restored 818和finished 819按钮，来选择各个按钮，以对事故单加时间戳，该时间戳标出用户何时接收到该事故单，或者在该程序中该事故单何时到达特定的关键点。

在用户104将新单登录到ICI 800之后，用户104查看用于上报的寻呼指南，如块1824所示。基于发生什么类别的事故、需要向谁通知该事故，寻呼指南告知用户104。在一个实施例中，寻呼指南位于实用手册100标签的事故恢复指南150中。接下来，用户104警告事故的二(2)级寻呼列表，如块1826所示。在一个实施例中，一(1)级寻呼列表是向其首先通知事故的人员组。一(1)级寻呼列表基本上充当用于诊断任何基本问题的第一服务台水平。在一个实施例中，二(2)级寻呼列表是使其知道事故并通常被分派去确定根本原因和修复事故或提供回避方法的下一个人员组。最后，三(3)级寻呼列表是当需要改变软件代码以修复特定事故时联络的人员组。在二(2)级寻呼完成之后，用户打开寻呼列表上的与员工的知识管理桥线(或电话线)，以便开始使用知识管理应用104去解决事故，如块1828所示。

然后，用户104开始对事故作出响应以评价该问题，如图26中提供的响应处理的块1850所示。用户104通过流程图400核查图300标签，以及受影响的上游和下游系统和客户，如块1852所示。此外，如块1854所示，用户还检查关于帮助解决事故的处理的实用手册100标签中的知识库200和事故恢复指南150、以及相关事故单的现有的数据和历史。这些标签帮助用户104从每个组找到合适的资源，并且为当前的事故单确定客户影响。

如块1856所示，用户给事故单指定严重性级别。严重性级别812帮助确定解决事故所采用的处理、以及要知道该事故的适当的个人。如果严重性级别812在整个事故单的解决过程中改变，则用户可以在事故单的生命期中进行严重性升级或降级820(如果有的话)。在严重性升级或降级历史字段821中记录任何严重性改变的历史。用户104还将简要描述820和问题描述821输入到事故单，如图21所示。简要描述822是概括一般问题的标题或短句，并且，问题描述824是对问题的更详细的描述。

在确定严重性级别812之后，MOD确定该事故应该告知的人和将事故单上报到什么级别，如块1858所示。其后，MOD将事故单上报到这些级别，如块1859所示。

在MOD确定上报的同时，用户104和MOD已经向其上报单的任何人开始这样的步骤：通过利用在知识管理应用125中包含的资源来分析和研究与该事故单相关的问题，如块1860所示。用户104和被告知事故单的任何人可以填写描述问题、跟踪事故单解决的进程、识别错误源等的字段。ICI 800具有存储对事故单的改变的历史和存储来自前面的事故单的每个字段的信息的能力。因此，用户104通过预存储的下拉数据填写事故单中的合适的字段，或者，如果没有相关数据，则用户104可以手动地填写需要的字段。鼓励用户104利用预存储的事故数据，因为它对在事故单的整个通道使用的语言进行标准化。这样允许用户104以更及时的方式更好地理解事故单的问题和解决方案。

当用户104正在分析事故时，他们可以将信息添加到事故单。在图21中所示的事故影响部分830内，用户104使用子通道影响按钮832来选择受影响的通道831并且下钻到特定的子通道。在这些通道831中的每个内，用户104可以输入每个通道和子通道的FCI、DCI、AML和PHL的数量。FCI和DCI发生833进一步图示在每个通道和子通道内如何发生FCI和DCI。用户104还填写受影响的应用和功能部分834，更详细地概括事故如何影响每个通道和子通道的应用。用与事故正如何影响客户以及该事故对客户有什么影响有关的信息填充客户经验部分835。用户104还指示事故正在影响的地理位置836，这样可以帮助将根本原因识别为特定系统或服务器。在影响部分830末端结算(tally)总事故影响837，并且，该总事故影响837列出了每个通道和子通道的总的FCI、DCI、AML和PHL。

事故单的描述部分840保持试图去解决该事故单的用户104之间的通信的运行标签。用户104在通信细节841部分中输入标题和描述，指示与解决事故单有关的信息。通信运行标签842保持在描述部分840中，并且，当调查该事故时，可以编辑或删除通信运行标签842。此外，在描述部分840中可用的是回避方法843部分，该回避方法843部分允许用户104描述在识别和修复根本原因之前如何能临时修复问题。还有恢复和解决844、以及原因描述845部分，用户104使用用于识别和修复事故单的根本原因的信息填充这些部分。

如菱形块1862所示，如果在初始级别上没有识别根本原因，则将事故上报到关于事故团队的更多专门技能的更高级别，如块1864所示。其后，该团队再次分析和研究事故单，直到识别根本原因。在识别根本原因之后，事故团队实现解决根本原因失败的修复，如块1866所示。如果该修复包含用于改变系统、硬件或处理的改变请求表(“RFC”)，则RFC号846被包含在事故单内。此外，填充事故持续时间847，指示从用户将事故登录到知识管理应用125时到识别对事故单的修复所花费的时间。还提供到RFC单848和MOD联络信息的链接，以便供用户104随后查询。

在实现修复之后，用户为MOD撰写稿件，指示团队如何解决事故单，如块1868所示。用户104填写事故单的其它细节部分850和根本原因部分860。其它细节部分850具有用于问题概述851、单指定852和永久性解决方案853的数据输入区域。用指示如何发生问题、用户怎样诊断问题和诊断分析的结果的信息填充问题概述851部分。单指定852部分描述负责永久性解决方案的技术团队。永久性解决方案853部分描述对事故修复的最终结果。

其它细节部分850还识别用来解决事故的工具854。对利用的工具的识别包括，但不限于，使用的实用手册855，用户104是否查阅知识库856，以及创建或者用来修复事故的任何文件857的附件区域。此外，在一些实施例中，在事故单中包含将用户104带到利用的工具的链接，所述工具包括，但不限于，从实用手册100使用的事故恢复指南150、从知识库200使用的事故单等。

在确定事故修复之后，用户104还填充根本原因部分860。在根本原因部分860中，用户104通过回答下述问题来描述原因/失败细节861：故障起源于哪里861；什么事件导致故障866；以及什么问题使初始故障870的影响复杂？

在故障起源于哪里861的问题下，用户填充描述初始故障点863、第二故障点864和最终故障点865。在什么事件导致故障866的问题下，用户填充原因867、事件888和描述869部分。在什么问题使初始故障870的影响复杂的问题下，用户104填充影响871、根本原因来源872、以及消费者和小企业银行技术和操作受托人873。

用户104还填写动作项目部分880，该动作项目部分880概括了需要做什么来完成事故的修复。此外，事故单还具有通信历史部分890，该通信历史部分890对于事故单中的所有新的编辑和删除的信息保持列表和时间戳。

然后，将事故细节保存在银行数据库130中，如块1870所示。然后，验证在系统中事实上已经修复事故，如块1872所示。其后，用户104可以关闭问题，如块1874所示。将关于事故的最后一次通信发送到具有事故概述的MOD，如块1876所示。当MOD批准报告时，MOD将事故报告提交给知识库200，事故报告被存储在数据库200中，以便供将来搜索和诊断相关的事故。

具有访问权和想要编辑特定事故单中的信息的任何用户104可以上拉至ICI 800主页，如图19所示。用户104可以搜索特定日期范围802、时间段803、严重性804内或按照单号805的事故单。主页列出与搜索标准匹配的所有事故单号806、以及相关问题描述807和关于每个事故单号的严重性808。用户104通过在事故单号806列中的事故单号上点击来查看编辑的事故单。

知识管理系统还具有学术900标签，如图27所示。学术900是对生产支持同事的跨职能的培训论坛。在其它实施例中，学术900可以用来存储和跟踪对银行的所有员工或者任何其它企业中的所有员工的所有培训。学术900向知识管理应用125的用户104提供在线培训，所述用户包括银行人员，例如生产支持员工和MOD。学术900提供对包含针对银行内的特定职位的培训模块的认证程序的访问。在其它实施例中，模块可以是与特定认证程序不相关的奇异模块。图27图示学术900主页，包括关于学术主页902、查看所有学习904、搜索学习906和查看成绩单908部分的标签。可以按照许多不同的格式向用户104提供培训模块。这些模块可以是滑动式演示、视频、纯音频或者交互显示(仅举几个例子)。

学术主页902标签包含被用户104工作所在的银行、LOB、部门或团体认为是必要的任何需要的认证912。状态指示器914记录认证程序是否可用、认证程序是否在处理中、或者认证程序是否已经完成。还提供记录图标916来作出与认证有关的笔记，并且提供书签918来将用户带到与认证程序相关的特定链接。

学术主页902标签还具有下钻按钮920，以允许用户104查看与认证程序相关的特定模块和要求中的每个，如图28所示。对认证的下钻列出需要的每个模块，以及模块是否可用、是否正在处理中、是否完成或锁定922(这说明，在锁定模块变成可用之前，用户必须完成其它模块)。每个模块可以具有在允许用户移动到下一个部分或模块之前用户104完成的多个部分。在允许用户104进入其它模块之前，或者在对特定程序的认证被批准之前，还可以在模块结束时要求测试或测验，以确定用户104对业务的熟练程度。此外，状态指示器914显示每个模块的状态。

查看所有学习904标签允许用户浏览银行可用的所有学习模块，并且将它们或者任何认证程序添加到用户104的学术主页902。根据对于特定职位空缺或者团体、部门、子通道或通道内的职位的要求，可以组织认证程序和模块。用户104可以将要求用户104进行的认证程序或模块与用户104可用的任何认证程序或模块一起相加，以增进用户104对银行内的其它团体、部门、子通道或通道的一般了解。此外，负责团体、部门等的某些用户104可以具有指定特定认证程序或模块给在该团体、部门等中工作的其他用户104的能力。这些认证程序或模块可以由团体、部门等的老板加载到该特定团体、部门等中的所有用户104，作为需要的培训或者对老板的团体、部门等中的用户104感兴趣的领域。

搜索学习906标签允许用户104对于用户104可能想要进行的任何认证程序或模块执行关键帧、日期、团体、部门、子通道、通道等搜索。搜索结果显示银行的所有认证程序或模块。如果允许用户104访问认证程序或模块，则用户104可以将在搜索学习906标签中找到的任何程序添加到用户104的学术主页902标签。

查看成绩单908标签允许用户查看用户104的认证程序或模块历史，该认证程序或模块历史概括了用户104已经完成和通过哪些程序和模块。此外，它列出用户进行或者要求用户进行的任何测试或测验的分数。查看成绩单908标签不仅对用户104跟踪各种认证程序和模块是非常有帮助的，而且对于管理者和执行者以及审计组织和监管机构也是非常有帮助的。管理者和执行者可以容易地将模块加载到员工的学术主页902标签，并且在查看成绩单908标签中跟踪哪些员工完成了这些模块。此外，审计团队不必花费时间去查明银行应用的用户104在特定应用中是否得到了妥善的评估和培训，因为他们可以查看成绩单908标签，以立即了解所有用户104是否都完成了需要的培训。另外，如果监管机构想要知道银行是否已经将联邦规定中的改变告知员工，则可以向监管机构显示查看成绩单908标签，该查看成绩单908标签概括了已经完成相关培训模块的用户104。

在学术900中的模块内，用户104可以通过链接来浏览内容页面，寻找知识管理应用125中的其它地方的信息。用户104还可以添加、编辑和删除每个模块的特定页面上的记录，如果他们将来有问题，可以返回到模块或记录部分。在知识管理应用125内访问到的特定区域的书签可以被添加到这些模块内或者被去除，以帮助将用户104引导到与这些模块相关的区域。

在本发明的其它实施例中，用户104可以在与模块有关的学术900中玩游戏。学术900还包含术语表，所以对这些模块内的某些术语不熟悉的用户104能够查阅该术语表，以提供对模块的更好的理解。

图29图示交互显示模块界面950的示例。图标952用于诸如在知识管理应用125内改变主题、计时、对不同模块或区域作书签的全局功能。提供窗口按钮954，用于关闭、最小化和缩放显示。显示模块界面950还具有用于与知识管理应用125主页链接的主链接956。工具栏958包含关于在交互显示内到各个区域的链接的图标，所述区域例如是，但不限于，主页、词汇功能、资源页面、帮助页面、记录页面、打印功能、交互游戏、测验和测试页面、实用手册100标签等。用户104可以通过在工具栏958中提供的链接上点击来查看这些部分中的任何部分。还提供课程退出按钮959，以便用户104在模块完成期间或者在模块完成之后退出课程。如果在模块期间退出交互显示模块界面950，则在退出模块之前保存用户104的进程。

在一个实施例中，交互显示模块界面950的主内容区域960具有标题962、用于在整个模块移动的浏览路径区域964、以及用于在整个模块前进和后退的前进966和后退968特征。内容显示970显示用户正在工作的模块的特定页面，并且，音频成绩单区域972提供音频内容的文本。最后，角色动画980使其看起来和听起来好像该角色正在教课，并且包含用于控制角色的音频和动画的角色动画控制982。

图30图示知识管理系统1使用的学术处理流程1900，该学术处理流程概括了该知识管理系统1如何跟踪和显示关于银行的每个用户104的培训模块和认证程序。如块1902所示，知识管理应用125通过用户计算机系统110从用户104或者通过银行计算机系统140自动地将培训模块和认证程序以及相关的测试、测验、视频文件、音频文件等一起接收，并且将它们存储在银行数据库130中。用户104可以将这些模块和认证程序创建和加载到知识管理应用125，或者，知识管理应用125可以将这些模块和认证程序随着它们被创建而推或拉到学术900。

如块1904所示，当用户104通过用户计算机系统110选择培训模块或认证程序时，知识管理应用125允许用户104访问该模块或认证程序。如块1906所示，当用户104完成培训模块或认证程序和相关的测试、测验等时，知识管理应用125从用户计算机系统110接收完成的通知，并且将该进程存储在银行数据库130中。此外，如块1908所示，当用户104完成培训模块或认证程序时，知识管理应用125为用户104解锁附加的培训模块或认证程序。如块1910所示，知识管理应用125还跟踪任何测试、测验、培训模块或认证程序的结果，并且将这些结果存储在银行数据库130的成绩单部分中。

下面的美国专利申请与本申请同时在2009年4月22日提交并且以引用的方式并入本文：Grace等人的美国专利申请No.12/428,330，题目为“Knowledge Management System”；Grace等人的美国专利申请No.12/428,335，题目为“IncidentCommunication Interface for the Knowledge ManagementSystem”；Grace等人的美国专利申请No.12/428,337，题目为“Incident Communication Interface for the Knowledge ManagementSystem”；以及Grace等人的美国专利申请No.12/428,340，题目为“Academy for the Knowledge Management System”。

本文描述本发明的具体实施例。本发明所属领域的技术人员在受益于前面的描述和相关附图中提出的教导的情况下，将会想到本文阐述的本发明的许多变形例和其它实施例。因此，将会理解，本发明并不局限于公开的具体实施例，并且，本发明的变形例、其它实施例、以及实施例的组合应当被包含在所附权利要求的范围内。尽管本文利用了特定术语，但是仅仅在一般的描述性的意义上使用它们，而不是出于限制的目的来使用它们。

Claims (26)

1.一种用于跟踪和解决在企业中发生的事故的监测系统，该监测系统包括：

用户界面；

存储器装置；

通信装置；和

处理器，该处理器与通信装置、用户界面和存储器装置可操作地耦合，并包括：

用于接收与两个或更多个事故有关的信息的装置，其中，每一个事故与一个或多个企业通道、子通道或应用相关；

用于将信息存储在存储器装置中的装置；

用于跟踪至少一个事故在事故的发生和解决之间的状态的装置；以及

用于在用户界面上显示在通道、子通道、应用或各个事故级别上的与事故有关的信息的装置。

2.根据权利要求1所述的系统，其中，用户界面显示与所述两个或更多个事故有关的信息，所述信息包括：打开的事故单的数量；打开得比特定响应时间长的事故；每小时、每天和每周的每一个通道、子通道和应用的事故的数量；由于事故引起的失败的客户交互的数量；事故的根本原因；或者由于与其它通道、子通道或应用有关在通道、子通道或应用中的失败的客户交互的数量。

3.根据权利要求1所述的系统，其中，处理器包括用于在用户界面上显示与每一个企业通道、子通道或应用相关的事故的数量的装置。

4.根据权利要求1所述的系统，其中，处理器包括用于在用户界面上显示与每一个企业通道、子通道或应用相关的性能分数的装置。

5.根据权利要求1所述的系统，其中，处理器包括用于在用户界面上显示一个或多个图形图表的装置，所述图形图表图示与事故相关的下述因素中的一个或多个：

事故的响应时间；

事故或失败的客户交互的强度；

事故的根本原因或者解决事故失败；或者

每一个通道、子通道或应用的事故或失败的客户交互的比率。

6.根据权利要求1所述的系统，其中，处理器包括用于在用户界面上显示由于事故引起的失败的客户交互的装置。

7.一种用于跟踪和解决在企业中发生的事故的监测系统，该监测系统包括：

用户界面；

存储器装置；

通信装置；和

处理器，该处理器与通信装置、用户界面和存储器装置可操作地耦合，并包括：

用于接收与一个或多个事故有关的信息的装置，其中，所述一个或多个事故与两个或更多个企业通道、子通道或应用的相关；

用于将信息存储在存储器装置中的装置；以及

用于在用户界面上一起显示所述两个或更多个企业通道、子通道或应用以及关于和每一个企业通道、子通道或应用相关的所述一个或多个事故的信息的装置。

8.根据权利要求7所述的系统，其中，处理器包括用于在用户界面上显示在通道、子通道、应用或各个事故级别上与所述一个或多个事故有关的信息的装置。

9.根据权利要求7所述的系统，其中，处理器包括用于跟踪至少一个事故在事故的发生和解决之间的状态的装置。

10.根据权利要求7所述的系统，其中，用户界面显示与所述一个或多个事故有关的信息，所述信息包括：打开的事故单的数量；打开得比特定响应时间长的事故；每小时、每天和每周的每一个通道、子通道和应用的事故的数量；由于事故引起的失败的客户交互的数量；事故的根本原因；或者由于与其它通道、子通道或应用有关在通道、子通道或应用中的失败的客户交互的数量。

11.根据权利要求7所述的系统，其中，处理器包括用于在用户界面上显示关于与事故相关的性能是否可接受的信息的装置。

12.根据权利要求7所述的系统，其中，处理器包括用于在用户界面上显示一个或多个图形图表的装置，所述图形图表图示与事故相关的下述因素中的一个或多个：

事故的响应时间；

事故或失败的客户交互的强度；

事故的根本原因或者解决事故失败；或者

每一个通道、子通道或应用的事故或失败的客户交互的比率。

13.根据权利要求7所述的系统，其中，处理器包括用于在用户界面上显示到各个事故的链接，用于查看与各个事故有关的分析和细节的装置。

14.一种用于监测系统的方法，包括：

通过使用处理器，接收与两个或更多个事故有关的信息，其中，每一个事故与一个或多个企业通道、子通道或应用相关；

将信息存储在存储器装置中；

通过使用处理器，跟踪至少一个事故在事故的发生和解决之间的状态；以及

在用户界面上显示在通道、子通道、应用或各个事故级别上与事故有关的信息。

15.根据权利要求14所述的方法，其中，用户界面显示与所述两个或更多个事故有关的信息，所述信息包括：打开的事故单的数量；打开得比特定响应时间长的事故；每小时、每天和每周的每一个通道、子通道和应用的事故的数量；由于事故引起的失败的客户交互的数量；事故的根本原因；或者由于与其它通道、子通道或应用有关在通道、子通道或应用中的失败的客户交互的数量。

16.根据权利要求14所述的方法，包括：

在用户界面上显示与每一个企业通道、子通道或应用相关的事故的数量。

17.根据权利要求14所述的方法，包括：

在用户界面上显示与每一个企业通道、子通道或应用相关的性能分数。

18.根据权利要求14所述的方法，包括：

在用户界面上显示一个或多个图形图表，所述图形图表图示与事故相关的下述因素中的一个或多个：

事故的响应时间；

事故或失败的客户交互的强度；

事故的根本原因或者解决事故失败；或者

每一个通道、子通道或应用的事故或失败的客户交互的比率。

19.根据权利要求14所述的方法，包括：

在用户界面上显示由于事故引起的失败的客户交互。

20.一种用于监测系统的方法，包括：

通过使用处理器，接收与一个或多个事故有关的信息，其中，所述一个或多个事故与两个或更多个企业通道、子通道或应用相关；

将信息存储在存储器装置中；以及

在用户界面上一起显示所述两个或更多个企业通道、子通道或应用以及关于和每一个企业通道、子通道或应用相关的所述事故的信息。

21.根据权利要求20所述的方法，包括：

在用户界面上显示在通道、子通道、应用或各个事故级别上与所述事故有关的信息。

22.根据权利要求20所述的方法，包括：

通过使用处理器，跟踪至少一个事故在事故的发生和解决之间的状态。

23.根据权利要求20所述的方法，包括：

用户界面显示与所述一个或多个事故有关的信息，所述信息包括：打开的事故单的数量；打开得比特定响应时间长的事故；每小时、每天和每周的每一个通道、子通道和应用的事故的数量；由于事故引起的失败的客户交互的数量；事故的根本原因；或者由于与其它通道、子通道或应用有关在通道、子通道或应用中的失败的客户交互的数量。

24.根据权利要求20所述的方法，包括：

在用户界面上显示关于与事故相关的性能是否可接受的信息。

25.根据权利要求20所述的方法，包括：

在用户界面上显示一个或多个图形图表，所述图形图表图示与事故相关的下述因素中的一个或多个：

事故的响应时间；

事故或失败的客户交互的强度；

事故的根本原因或者解决事故失败；或者

每一个通道、子通道或应用的事故或失败的客户交互的比率。

26.根据权利要求20所述的方法，包括：

在用户界面上显示到各个事故的链接，用于查看与各个事故有关的分析和细节。

Images