知识管理系统 技术领域 本发明总体上涉及知识管理领域， 更具体地说， 发明的实施例涉及用于提供生产 支持信息的综合系统的系统、 方法和计算机程序产品。
背景技术 企业以分散的方式横跨各业务范围 (“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 tbe 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 andstoredsecurely ？
● 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,333， 题目为 “Performance Dashboard Monitoring for theKnowledge Management System” ； Grace 等 人 的 美 国 专 利 申 请 No.428,337/428,335， 题目为 “Incident Communication Interface for theKnowledge Management System” ； Grace 等 人 的 美 国 专 利 申 请 No.12/428,337， 题目为 “Incident Communication Interface for theKnowledge Management System” ； 以及 Grace 等人的美 国专利申请 No.12/428,340， 题目为 “Academy for the KnowledgeManagement System” 。
本文描述本发明的具体实施例。 本发明所属领域的技术人员在受益于前面的描述和相关附图中提出的教导的情况下， 将会想到本文阐述的本发明的许多变形例和其它实施 例。因此， 将会理解， 本发明并不局限于公开的具体实施例， 并且， 本发明的变形例、 其它实 施例、 以及实施例的组合应当被包含在所附权利要求的范围内。 尽管本文利用了特定术语， 但是仅仅在一般的描述性的意义上使用它们， 而不是出于限制的目的来使用它们。