專利名稱：用于知識管理系統的性能儀表盤監(jiān)測的制作方法
技術領域：
本發(fā)明總體上涉及知識管理領域，更具體地說，發(fā)明的實施例涉及用于提供生產 支持信息的綜合系統的系統、方法和計算機程序產品。
背景技術：
企業(yè)以分散的方式橫跨各業(yè)務范圍(“L0B”)來存儲應用、信息和數據。通常，每 個LOB內的特定部門負責以在每個部門內工作的同事認為合適的最有效方式(如果真要這 樣做的話)來對他們的知識進行編輯、分類、存儲和訪問。應用、信息和數據既不存儲在中 心場所，而且對于部門和LOB之間的知識轉移和一般教育來說也不可搜索或使用。而且，當 發(fā)生生產事故時，被指定去支持生產事故的每個同事并不都掌握正確的處理和修復。因此， 當同事有他/她自身的專業(yè)知識所不能解決的問題時，這個同事通過呼叫或電子郵件向企 業(yè)自身的呼叫中心或其它支持系統發(fā)出詢問，以尋找合適的答案或聯絡人參考。通常將詢 問轉發(fā)給負責將它們上報至合適的企業(yè)團隊的團體。為了解釋系統構架、上游和下游系統、 以及客戶影響，還可以將業(yè)務專家拉入上述詢問。當事故涉及小問題時，需要進行診斷并修 復該問題的人員僅僅會被短暫占用，但是用更有效的系統可避免這樣的時間。當事故重大 時，這一過程可能會花費數周來得以解決，并且，為了解決這些事故，人員需要會花費相當 多的時間與同事進行實地交流或電話通信。這種耗時的過程長期使得關鍵同事不能從事其 日常責任。每當事故被上報到更高的支持水平，都會花費寶貴的時間并負面地影響到企業(yè)的 客戶。通常的知識管理系統是基于個人的，因為這些知識管理系統取決于各個團體中的某 些同事的知識水平。因此，無論何時發(fā)生事故去聯絡特定同事都是低效率的，遠不是最佳的 手段。使用這些系統的員工作為對任何事故的反應而進行響應，并且使大量團隊中的同事 遠離他們的正常角色，這樣轉化為成本增加。而且，當在企業(yè)內進行審計核查時，必定需要大量的人工任務去收集數據和以有 意義的方法組織該數據。在這種數據收集和組織之后是冗長的面對面的會議，以詳細地核 查和分析各個數據。審計團隊必須逐個L0B、逐個部門地這樣做，因為大部分的LOB和部門 以不同的方式組織和存儲它們的數據和文檔。因此，如果測量度量(measuring metrics) 和處理以分散的方式被組織并在整個企業(yè)重沒有被標準化，則在組織內審計不同的部門變 得特別昂貴、費時。隨著企業(yè)規(guī)模增大，這種問題成指數地增加。沒有為了系統文檔管理、統計和其它分析、提高同事技術水平和教育等目的而容 納企業(yè)的所有重要數據的中心位置。分散方法可能使同事重復勞動，因為他們不知道，其他 同事可能已經獨立地開發(fā)了處理圖(process map)、程序、數據分析等。在不能先在集中位 置搜索信息的情況下，同事們決不會知道他們的努力實際上是否是浪費時間以及是否可以 將他們的努力更好地投放在別的問題。當前沒有這樣的系統在該系統下，企業(yè)能夠以無縫的方式通過一個集成系統來 存儲、生成、分發(fā)、評分和跟蹤由企業(yè)中同事創(chuàng)造的所有知識。

發(fā)明內容
本發(fā)明的實施例通過提供用于創(chuàng)建知識管理系統的方法、系統、計算機程序產品 或前述的組合來解決了上述需要和/或實現其它的優(yōu)點，該知識管理系統包含在整個組織 的通道和子通道中被標準化和集中化的性能儀表盤監(jiān)測系統。性能儀表盤監(jiān)測系統用來跟 蹤、測量和解決在整個組織的通道、子通道、系統和應用發(fā)生的事故。本發(fā)明的一個實施例是用于跟蹤和解決在企業(yè)中發(fā)生的事故的監(jiān)測系統，該監(jiān)測 系統包括用戶界面、存儲器裝置、通信裝置和處理器。處理器與通信裝置、用戶界面和存儲 器裝置可操作地耦合。處理器被配置為執(zhí)行計算機可讀程序代碼，以接收與兩個或更多個 事故有關的信息，其中，每一個事故與一個或多個企業(yè)通道、子通道或應用相關。處理器還 配置為執(zhí)行計算機可讀程序代碼，以將信息存儲在存儲器裝置中。處理器還配置為執(zhí)行計 算機可讀程序代碼，以跟蹤至少一個事故在事故的發(fā)生和解決之間的狀態(tài)。處理器還配置 為執(zhí)行計算機可讀程序代碼，以在用戶界面上顯示在通道、子通道、應用或各個事故級別上 的與事故有關的信息。此外，根據本發(fā)明的一個實施例，用戶界面顯示與所述兩個或更多個事故有關的 信息，所述信息例如是打開的事故單的數量；打開得比特定響應時間長的事故；每小時、 每天和每周的每一個通道、子通道和應用的事故的數量；由于事故引起的失敗的客戶交互 的數量；事故的根本原因；或者由于與其它通道、子通道或應用有關在通道、子通道或應用 中的失敗的客戶交互的數量。在本發(fā)明的另一個實施例中，處理器可操作用來執(zhí)行在計算機可讀介質中存儲的 計算機課可讀指令，以在用戶界面上顯示與每一個企業(yè)通道、子通道或應用相關的事故的數量。在本發(fā)明的另一個實施例中，處理器可操作用來執(zhí)行在計算機可讀介質中存儲的 計算機課可讀指令，以在用戶界面上顯示與每一個企業(yè)通道、子通道或應用相關的性能分 數。在本發(fā)明的另一個實施例中，處理器可操作用來執(zhí)行在計算機可讀介質中存儲的 計算機課可讀指令，以在用戶界面上顯示一個或多個圖形圖表。所述圖形圖表圖示與事故 相關的下述因素中的一個或多個包括事故的響應時間、事故或失敗的客戶交互的強度、事 故的根本原因或者解決事故失敗，或者每一個通道、子通道或應用的事故或失敗的客戶交
互的比率。在本發(fā)明的另一個實施例中，處理器可操作用來執(zhí)行在計算機可讀介質中存儲的 計算機課可讀指令，以在用戶界面上顯示由于事故引起的失敗的客戶交互。本發(fā)明的一個實施例是用于跟蹤和解決在企業(yè)中發(fā)生的事故的監(jiān)測系統，該監(jiān)測 系統包括用戶界面、存儲器裝置、通信裝置和處理器。處理器與通信裝置、用戶界面和存儲 器裝置可操作地耦合。處理器被配置為執(zhí)行計算機可讀程序代碼，以接收與一個或多個事 故有關的信息，其中，所述一個或多個事故與兩個或更多個企業(yè)通道、子通道或應用的相 關。處理器還配置為執(zhí)行計算機可讀程序代碼，以將信息存儲在存儲器裝置中。處理器還 配置為執(zhí)行計算機可讀程序代碼，以在用戶界面上一起顯示所述兩個或更多個通道、子通 道或應用以及關于和每一個企業(yè)通道、子通道或應用相關的所述一個或多個事故的信息。
在本發(fā)明的另一個實施例中，處理器可操作用來執(zhí)行在計算機可讀介質中存儲的 計算機課可讀指令，以在用戶界面上顯示在通道、子通道、應用或各個事故級別上與所述一 個或多個事故有關的信息。在本發(fā)明的另一個實施例中，處理器可操作用來執(zhí)行在計算機可讀介質中存儲的 計算機課可讀指令，以跟蹤至少一個事故在事故的發(fā)生和解決之間的狀態(tài)。在本發(fā)明的另一個實施例中，用戶界面顯示與所述一個或多個事故有關的信息， 所述信息例如是打開的事故單的數量；打開得比特定響應時間長的事故；每小時、每天和 每周的每一個通道、子通道和應用的事故的數量；由于事故引起的失敗的客戶交互的數量； 事故的根本原因；或者由于與其它通道、子通道或應用有關在通道、子通道或應用中的失敗 的客戶交互的數量。在本發(fā)明的另一個實施例中，處理器可操作用來執(zhí)行在計算機可讀介質中存儲的 計算機課可讀指令，以在用戶界面上顯示關于與事故相關的性能是否可接受的信息。在本發(fā)明的另一個實施例中，處理器可操作用來執(zhí)行在計算機可讀介質中存儲的 計算機課可讀指令，以在用戶界面上顯示一個或多個圖形圖表。所述圖形圖表圖示與事故 相關的下述因素中的一個或多個事故的響應時間、事故或失敗的客戶交互的強度、事故的 根本原因或者解決事故失敗，或者每一個通道、子通道或應用的事故或失敗的客戶交互的 比率。在本發(fā)明的另一個實施例中，處理器可操作用來執(zhí)行在計算機可讀介質中存儲的 計算機課可讀指令，以在用戶界面上顯示到各個事故的鏈接，用于查看與各個事故有關的 分析和細節(jié)。本發(fā)明的一個實施例是用于監(jiān)測系統的計算機程序產品，該計算機程序產品包括 具有在其中實施的計算機可讀程序代碼部分的至少一個計算機可讀介質，該計算機可讀程 序代碼部分包括多個可執(zhí)行部分。一個可執(zhí)行部分被配置為通過使用處理器，接收與兩個 或更多個事故有關的信息，其中，每一個事故與一個或多個企業(yè)通道、子通道或應用相關， 并且，處理器與存儲器裝置、通信裝置、用戶界面和計算機可讀程序代碼可操作地耦合。另 一個可執(zhí)行部分被配置為將信息存儲在存儲器裝置中。另一個可執(zhí)行部分被配置為跟 蹤至少一個事故在事故的發(fā)生和解決之間的狀態(tài)。另一個可執(zhí)行部分被配置為在用戶界 面上顯示在通道、子通道、應用或各個事故級別上與事故有關的信息。此外，根據本發(fā)明的一個實施例，用戶界面顯示與所述兩個或更多個事故有關的 信息，所述信息例如是打開的事故單的數量；打開得比特定響應時間長的事故；每小時、 每天和每周的每一個通道、子通道和應用的事故的數量；由于事故引起的失敗的客戶交互 的數量；事故的根本原因；或者由于與其它通道、子通道或應用有關在通道、子通道或應用 中的失敗的客戶交互的數量。在本發(fā)明的另一個實施例中，計算機程序產品包括可執(zhí)行部分，該可執(zhí)行部分被 配置為在用戶界面上顯示與每一個企業(yè)通道、子通道或應用相關的事故的數量。在本發(fā)明的另一個實施例中，計算機程序產品包括可執(zhí)行部分，該可執(zhí)行部分被 配置為在用戶界面上顯示與每一個企業(yè)通道、子通道或應用相關的性能分數。在本發(fā)明的另一個實施例中，計算機程序產品包括可執(zhí)行部分，該可執(zhí)行部分被 配置為在用戶界面上顯示一個或多個圖形圖表。所述圖形圖表圖示與事故相關的下述因素中的一個或多個包括事故的響應時間、事故或失敗的客戶交互的強度、事故的根本原因 或者解決事故失敗，或者每一個通道、子通道或應用的事故或失敗的客戶交互的比率。在本發(fā)明的另一個實施例中，計算機程序產品包括可執(zhí)行部分，該可執(zhí)行部分被 配置為在用戶界面上顯示由于事故引起的失敗的客戶交互。本發(fā)明的一個實施例是用于監(jiān)測系統的計算機程序產品，該計算機程序產品包括 具有在其中實施的計算機可讀程序代碼部分的至少一個計算機可讀介質，該計算機可讀程 序代碼部分包括多個可執(zhí)行部分。一個可執(zhí)行部分被配置為通過使用處理器，接收與一個 或多個事故有關的信息，其中，所述一個或多個事故與兩個或更多個企業(yè)通道、子通道或應 用的相關，并且，處理器與存儲器裝置、通信裝置、用戶界面和計算機可讀程序代碼可操作 地耦合。另一個可執(zhí)行部分被配置為將信息存儲在存儲器裝置中。另一個可執(zhí)行部分被 配置為在用戶界面上一起顯示所述兩個或更多個通道、子通道或應用以及關于同每一個 企業(yè)通道、子通道或應用相關的所述一個或多個事故的信息。此外，根據本發(fā)明的一個實施例，計算機程序產品包括可執(zhí)行部分，該可執(zhí)行部分 被配置為在用戶界面上顯示在通道、子通道、應用或各個事故級別上與所述一個或多個事 故有關的信息。在本發(fā)明的另一個實施例中，計算機程序產品包括可執(zhí)行部分，該可執(zhí)行部分被 配置為跟蹤至少一個事故在事故的發(fā)生和解決之間的狀態(tài)。在本發(fā)明的另一個實施例中，用戶界面顯示與所述一個或多個事故有關的信息， 所述信息例如是打開的事故單的數量；打開得比特定響應時間長的事故；每小時、每天和 每周的每一個通道、子通道和應用的事故的數量；由于事故引起的失敗的客戶交互的數量； 事故的根本原因；或者由于與其它通道、子通道或應用有關在通道、子通道或應用中的失敗 的客戶交互的數量。在本發(fā)明的另一個實施例中，計算機程序產品包括可執(zhí)行部分，該可執(zhí)行部分被 配置為在用戶界面上顯示關于與事故相關的性能是否可接受的信息。在本發(fā)明的另一個實施例中，計算機程序產品包括可執(zhí)行部分，該可執(zhí)行部分被 配置為在用戶界面上顯示一個或多個圖形圖表。所述圖形圖表圖示與事故相關的下述因 素中的一個或多個包括事故的響應時間、事故或失敗的客戶交互的強度、事故的根本原因 或者解決事故失敗，或者每一個通道、子通道或應用的事故或失敗的客戶交互的比率。在本發(fā)明的另一個實施例中，計算機程序產品包括可執(zhí)行部分，該可執(zhí)行部分被 配置為在用戶界面上顯示到各個事故的鏈接，用于查看與各個事故有關的分析和細節(jié)。已經論述的特征、功能和優(yōu)點可以在本發(fā)明的各個實施例中獨立地實現，或者，可 以與其它的實施例結合，可以參考下面的描述和附圖來了解其它實施例的進一步的細節(jié)。


已經這樣籠統地描述本發(fā)明的實施例，現在將參考附圖，這些附圖并不一定是按 比例繪制的，其中圖1提供根據本發(fā)明實施例的企業(yè)內的通道和知識管理系統之間的交互的概要；圖2提供圖示根據本發(fā)明實施例的知識管理系統中的各個系統的交互的系統圖；圖3提供根據本發(fā)明實施例的圖示生產支持內的事故的概要的知識管理系統的主頁；圖4a提供根據本發(fā)明實施例的知識管理系統的儀表盤系統的處理流程；圖4b提供根據本發(fā)明實施例的圖示生產支持內的事故的通道概覽的知識管理系 統的儀表盤；圖5提供根據本發(fā)明實施例的圖示生產支持內的事故的子通道概覽的知識管理 系統的另一儀表盤；圖6提供根據本發(fā)明實施例的圖示生產支持內的事故的事故等級概覽的知識管 理系統的另一儀表盤；圖7提供根據本發(fā)明實施例的圖示生產支持內的特定事故的事故概覽的知識管 理系統的另一儀表盤；圖8提供根據本發(fā)明實施例的圖示用于響應于特定事故的事故恢復處理的搜索 和顯示功能的知識管理系統的實用手冊界面；圖9提供根據本發(fā)明實施例的圖示用于解決的事故單的搜索和顯示功能的知識 管理系統的知識庫界面；圖10提供根據本發(fā)明實施例的圖示用于物理、邏輯和交易處理圖的搜索和顯示 功能的知識管理系統的處理圖界面；圖11提供根據本發(fā)明實施例的圖示物理、邏輯或交易處理圖的示例的知識管理 系統的處理圖顯示；圖12提供根據本發(fā)明實施例的從客戶角度圖示流程圖的示例的知識管理系統的 流程圖顯示；圖13a提供根據本發(fā)明實施例的知識管理系統的操作可靠性指標系統的處理流 程；圖13b提供根據本發(fā)明實施例的圖示每個通道的可靠性分數的知識管理系統的 操作可靠性指標主頁；圖14a提供根據本發(fā)明實施例的圖示通道內的每個子通道、應用和類別的可靠性 分數的知識管理系統的操作可靠性指標評分界面；圖14b提供根據本發(fā)明實施例的圖示兩個類別的評分度量的知識管理系統的操 作可靠性指標評分模板；圖14c提供根據本發(fā)明實施例的圖示兩個類別的評分度量的知識管理系統的另 一操作可靠性指標評分模板；圖14d提供根據本發(fā)明實施例的圖示兩個類別的評分度量的知識管理系統的另 一操作可靠性指標評分模板；圖14e提供根據本發(fā)明實施例的圖示兩個類別的評分度量的知識管理系統的另 一操作可靠性指標評分模板；圖15提供根據本發(fā)明實施例的圖示用于與知識管理系統的一個部分有關的層次 結構和聯絡的搜索和顯示界面的知識管理系統的聯絡人界面；圖16提供根據本發(fā)明實施例的圖示用于在系統中報告事故的請求表的知識管理 系統的事故報告請求界面；圖17提供根據本發(fā)明實施例的圖示特定事故的報告概覽的知識管理系統的事故報告；圖18提供根據本發(fā)明實施例的圖示事故通知處理流程的知識管理系統的處理流 程；圖19提供根據本發(fā)明實施例的圖示打開事故的列表的知識管理系統的事故主 頁；圖20提供根據本發(fā)明實施例的圖示處于事故單內的信息的一部分的知識管理系 統的事故通信界面的一部分；圖21提供根據本發(fā)明實施例的圖示處于事故單內的信息的另一部分的知識管理 系統的事故通信界面的另一部分；圖22提供根據本發(fā)明實施例的圖示處于事故單內的信息的另一部分的知識管理 系統的事故通信界面的另一部分；圖23提供根據本發(fā)明實施例的圖示處于事故單內的信息的另一部分的知識管理 系統的事故通信界面的另一部分；圖24提供根據本發(fā)明實施例的圖示處于事故單內的信息的另一部分的知識管理 系統的事故通信界面的另一部分；圖25提供根據本發(fā)明實施例的圖示處于事故單內的信息的另一部分的知識管理 系統的事故通信界面的另一部分；圖26提供根據本發(fā)明實施例的圖示事故響應處理流程的知識管理系統的處理流 程；圖27提供根據本發(fā)明實施例的圖示用戶可用的認證和模塊的知識管理系統的學 術主頁界面；圖28提供根據本發(fā)明實施例的圖示用戶可用的認證和模塊的知識管理系統的擴 展的學術主頁界面；圖29提供根據本發(fā)明實施例的圖示關于用戶的模塊顯示的知識管理系統的學術 模塊界面；以及圖30提供根據本發(fā)明實施例的知識管理系統的學術系統的處理流程。
具體實施例方式現在，將在下文中參考附圖更全面地描述本發(fā)明的實施例，在這些附圖中示出了 本發(fā)明的一些實施例，但是沒有示出本發(fā)明的所有實施例。當然，可以用諸多不同的形式來 實施本發(fā)明，并且本發(fā)明不應該被解釋為局限于本文中所闡述的實施例，提供這些實施例， 使得本公開將滿足適用的法律要求。相同的附圖標記始終是指相同的元件。盡管在本文中 描述的本發(fā)明的實施例通常被描述為涉及“銀行”，但是本領域的技術人員將會理解，本發(fā) 明的其它實施例可以涉及其它企業(yè)或金融機構，這些企業(yè)或金融機構代替銀行或與銀行合 作來執(zhí)行本文描述的銀行正執(zhí)行的處理或步驟中的一個或多個。本發(fā)明的其它實施例可以 完全地涉及金融行業(yè)之外的其它企業(yè)。如本領域的技術人員根據本公開所理解的，本發(fā)明可以被實施為一種方法或設備 (系統、計算機程序產品、裝置等)或前述的組合。因此，本發(fā)明的實施例可以采用全部硬件 實施例、全部軟件實施例(包含固件、駐留軟件、微代碼等)、或者組合軟件和硬件方面的實施例的形式，其中，所述組合軟件和硬件方面的實施例在本文中通常被稱為“系統”。而且， 本發(fā)明的實施例可以采用計算機程序產品的形式，該計算機程序產品包括計算機可用存儲 介質，該計算機可用存儲介質具有在該介質中實施的計算機可用程序代碼/計算機可讀指 令?？梢岳萌魏魏线m的計算機可用介質或計算機可讀介質。計算機可用介質或計算 機可讀介質可以是，例如，但不限于，電子、磁、光、電磁、紅外或半導體系統、設備或裝置。計 算機可讀介質的更具體的示例(非窮盡的列表)將包括以下具有一條或多條布線的電連 接；或者實存的存儲介質，例如，便攜式計算機磁盤、硬盤、隨機存取存儲器(RAM)、只讀存 儲器(ROM)、可擦除可編程只讀存儲器(EPR0M或閃存)、壓縮盤只讀存儲器(CD-ROM)、或者 其它的實存的光存儲裝置或磁存儲裝置。用于執(zhí)行本發(fā)明的操作的計算機程序代碼/計算機可讀指令可以用諸如Java、 Perl、Smalltalk, C++等的面向對象、腳本或非腳本編程語言寫成。然而，用于執(zhí)行本發(fā)明 的操作的計算機程序代碼/計算機可讀指令還可以用諸如“C”編程語言或類似的編程語言 的常規(guī)的程序設計語言寫成。在下面，將參考方法或設備(系統、計算機程序產品、裝置等)的流程圖和/或框 圖來描述本發(fā)明的實施例。將會理解，流程圖和/或框圖中的每一塊、以及流程圖和/或框 圖中的塊的組合可以通過計算機程序指令來實現。可以將這些計算機程序指令提供給通用 計算機、專用計算機或其它可編程數據處理設備的處理器，以產生特定機器，從而使得通過 計算機或其它可編程數據處理設備的處理器執(zhí)行的指令形成用于實現在流程圖和/或一 個或多個框圖塊中指定的功能/動作(act)的機構。還可以將這些計算機程序指令存儲在計算機可讀存儲器中，從而使得存儲在計算 機可讀存儲器中的指令產生包含實現在流程圖和/或一個或多個框圖塊中指定的功能/動 作的指令的制造制品，其中，計算機可讀存儲器可以指導計算機或其它可編程數據處理設 備以具體的方式運行。還可以將計算機程序指令加載到計算機或其它可編程數據處理設備上，使得要在 計算機或其它可編程設備上執(zhí)行一系列的操作步驟，以產生計算機實現處理，從而在計算 機或其它可編程設備上執(zhí)行的指令提供用于實現在流程圖和/或一個或多個框圖塊中指 定的功能/動作的步驟?？商鎿Q地，為了實現本發(fā)明的實施例，可以將計算機程序實現的步 驟或動作與操作者或人實現的步驟或動作結合。圖1圖示根據本發(fā)明實施例的知識管理系統1。知識管理系統1是被配置為管理 整個銀行的全部通道或至少多個通道、以及這些通道內的子通道的知識的系統。在圖示的 實施例中，這些通道包括，例如，電子商務通道2、銀行中心技術(“BCT”)通道3、自動取款 機(ATM)通道4、抵押、家庭資產和保險技術(“MHEIT”)通道5、卡服務通道6、存款聯絡中 心(“DCC”)通道7、以及其它附加通道8。然而，在本發(fā)明的其它實施例中，知識管理系統 1可以為任何一種企業(yè)的不同的L0B、部門或者通道提供相同或相似的支持。圖2提供圖示根據本發(fā)明實施例的知識管理系統1中的各個系統的交互的系統圖 100。如圖2所述，用戶計算機系統110通過網絡102與知識管理服務器120、一個或多個銀 行數據庫130和一個或多個銀行計算機系統140可操作地耦合。以這樣的方式，用戶計算 機系統110的用戶104可以從知識管理服務器120、銀行數據庫130和銀行計算機系統140接收電子信息。網絡102可以是諸如因特網的全球區(qū)域網絡(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將表示在所有通道的同事的知識的信息聚集到一個應用中，并且除 其它以外，存儲用于解決在各個通道內發(fā)生的生產事故問題的信息。通常為銀行職員的用 戶104使用知識管理應用125作為他們的尋找所有企業(yè)相關信息參考的位置的源，如下面 更詳細的論述。如圖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，但是重要的是，請注意，存在一個或多 個系統，每個系統具有進行收集、存儲和分發(fā)知識管理系統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，但是重要的是，請注意，可存在一個或多個數據庫，每個數據庫具有進行捕獲、存儲和/ 或分發(fā)知識管理系統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，但是重要的是，請注意，可存在一個或多 個系統，每個系統具有進行捕獲和分發(fā)知識管理系統1的信息的相似部件。圖3圖示知識管理應用主頁50。這是這樣的頁面在本發(fā)明的一個實施例中，當 用戶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，以便監(jiān)測、診斷和修復任何生產事 故、實現新的生產應用，以及存儲與生產支持有關的所有知識。在本發(fā)明的一個實施例中，可以使用知識管理系統1來跟蹤在銀行內發(fā)生的事 故。事故是在銀行系統和應用內發(fā)生的正常操作程序以外的事件。如果在事故發(fā)生時或在 事故發(fā)生之后的時間點客戶受事故的影響，則該事故可以導致客戶交互失敗(“FCI”)。對 于每個事故，事故還可以導致降低的客戶交互(“DCI”)、損失的人小時(PHL)和損失的代 理分鐘(“AML”)。通過知識管理應用125，知識管理系統1跟蹤用于銀行計算機系統140 和銀行應用145的事故診斷和分析的這些度量中的所有度量。傳統上，當發(fā)生事故時，存儲這些事故的細節(jié)，并且，員工根據需要核查這些事故。 而且，不是在集中化的位置建立或維護與事故有關的系統信息和精確的聯絡人團體。因此， 當員工將開始隊列中的下一個事故時，或者當管理層催促解決某一特定事故，并且員工不 知道聯絡哪些處理專人去解決事故時，核查這些事故。這種跟蹤和解決的方法花費比核查 事故的影響和使適當的資源來解決這些事故所需的時間長的時間。這種系統將允許由于相 同的原因反復地發(fā)生多次FCI。部分地以減少FCI為目標而設計了知識管理系統1的實施例。一般來說，事故的 數量和持續(xù)時間直接對應于FCI的數量。這樣，知識管理系統1的實施例關注減少事故的 數量和持續(xù)時間，于是也就減少對客戶的負面影響。為了按照優(yōu)先級或其它類別來組織事故，可以給事故指定不同的嚴重性級別。在 一個實施例中，當在銀行計算機系統140中發(fā)生事故時，將這些事故編組為三個嚴重性級 別。嚴重性一(1)事故是導致對客戶和/或同事完全中斷服務或者停工的高影響重大事件。這些類別的事故表示最高的評定等級(rating)。通常，在嚴重性一(1)事故中沒有回避方 法，并且，立即解決這些事故，以防止對客戶和/或同事進一步中斷服務或者停工。嚴重性 二(2)事故是導致對客戶和/或同事部分中斷服務或者停工的中等影響事件。通常，這些 事件可以使用回避方法或處理變化，銀行可以利用此來防止在實現永久性修復之前的時間 內進一步中斷服務或停工。嚴重性三(3)事故是對客戶和/或同事具有最少影響的低影響 或非普遍事件。這些類別的事故由銀行根據需要來修復。在本發(fā)明的一些實施例中，知識 管理系統1僅僅跟蹤嚴重性一(1)和二(2)事故。圖4a圖示知識管理系統1用來通過儀表盤500跟蹤和顯示在銀行發(fā)生的事故的 儀表盤處理流程1500。如塊1502所示，當發(fā)生事故時，知識管理應用125通過推或拉從銀 行計算機系統140接收與在各個銀行計算機系統140和相關銀行應用145發(fā)生的事故有關 的信息。其后，如圖4a中的塊1504所示，知識管理應用125按照狀態(tài)、描述、開始日期、結 束日期、持續(xù)時間、嚴重性級別、受影響的通道(即，電子商務2、BCT 3、ATM 4等)、受影響 的子通道(即，在線銀行、dot com、小企業(yè)等)、出故障的客戶交互等來組織事故，并將數據 存儲在銀行數據庫130上，以供用戶104分析。如塊1506所示，知識管理應用125與用戶 計算機系統110通信，以便通過使用儀表盤500顯示在總體、通道、子通道和各個事故級別 上與事故有關的數據。如塊1508所示，為了通過儀表盤500核查和分析在銀行發(fā)生的在所 有通道、子通道和各個事故級別上的事故，用戶104利用web瀏覽器115或類似的應用來訪 問知識管理應用125。如圖3、4b至7所示，在各個儀表盤上顯示由知識管理系統1聚集和顯示的事故信 息。如圖3所示，知識管理應用主頁50提供與跟蹤當前在各個通道級別打開的事故的數量 有關的數據。對于每個通道，知識管理應用主頁50顯示當前的事故狀態(tài)部分60和日常性 能部分70。當前事故狀態(tài)部分60顯示儀表62，在一些實施例中，該儀表圖示打開的嚴重性 級別一⑴違章事故64的數量和打開的嚴重性級別二(2)違章事故66的數量。在一個實 施例中，儀表62用綠色、黃色或紅色顯示讀數，以便圖示每個通道中的所有事故的一般狀 態(tài)級別。當用戶104瀏覽知識管理應用125的其余部分時，知識管理應用125的用戶104 可以選擇分離按鈕52，并且當前事故狀態(tài)框60在用戶的屏幕上保持為頂級視圖。知識管理應用主頁50是上層管理層通過提供與通道級別的嚴重性一(1)和嚴重 性二(2)失敗的客戶事故有關的數據的概要來了解系統的整體健康狀態(tài)的工具。在一些實施例中，知識管理應用125的日常性能部分70以一千(K)為增量圖示對 于每個通道的一天內已經發(fā)生的事故的總數72。日常性能部分70還在標尺74出示總概 要，從而向用戶104提供對正常(用綠色)或非正常(用紅色)的事故的數量的視覺顯示。 員工(尤其是執(zhí)行者)使用儀表62和標尺74來跟蹤高級別上的正在發(fā)生的事故的數量和 生產支持團隊的響應。如果存在示出高級別的事故的特定通道，則用戶104可以掌握附加 數據分析工具，以診斷和跟蹤什么因素正導致這些事故。用戶104通過選擇儀表盤500標簽來瀏覽知識管理應用125中的附加工具。如圖 4B所示，選擇儀表盤500標簽呈示儀表盤500，與主頁50 —樣，儀表盤500顯示日常性能部 分70，并且包括事故的總數72和圖示事故數量正常還是不正常的標尺74。然而，儀表盤 500還圖示通道狀態(tài)部分502。通道狀態(tài)部分502以大量的圖表提供每個通道上的事故的影響的視圖。用戶104可以通過選擇日常性能部分70中的通道名鏈接或圖標來查看分開 的通道信息。例如，圖4b圖示與電子商務通道2有關的圖表。通道狀態(tài)部分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 和小企業(yè)524子通道的電子商務通道2d的子通道中的事故的視圖。在通道視圖部分503 中針對每個子通道顯示事故，基本上與在圖4b的日常性能部分70中針對通道級別顯示事 故的方式相同。如圖5所示，在子通道狀態(tài)部分504中顯示這些子通道中的每個的事故概 覽。子通道狀態(tài)部分504顯示在圖4b的通道部分502中顯示的相同的圖表和信息，但是， 當用戶104在通道視圖503中選擇相關的子通道名或圖標時，這些圖表示出每個子通道的 事故的發(fā)生。如果用戶104想要檢查任何子通道內的特定事故，則用戶104通過例如選擇(雙 點擊)圖5中所示的儀表盤500的子通道名或圖標來在儀表盤500中下鉆到圖6中所示的 值班管理者(“MOD”)事故列表530。在一個實施例中，MOD是銀行的負責最終解決特定通 道、子通道或應用級別中的事故的管理者。MOD事故列表530具有事故狀態(tài)部分540和客戶 登錄量532。事故狀態(tài)部分540列出事故單(incident ticket)數541、狀態(tài)542、事故的描 述543、開始日期544、結束日期545、持續(xù)時間546、嚴重性547、受影響的通道548，以及每 個事故的FCI 550,DCI 55UPHL 553和AML 554。這種儀表盤允許用戶104檢查系統中的 每個未解決的事故和檢驗每個事故的狀態(tài)。如圖6所示，用戶104可以按月、周和天查看事 故，以及改變在該頁面上同時查看的事故的數量。如圖6所示的客戶登錄視圖532允許用戶查看已經登錄到銀行的相關通道、子通 道和應用的客戶的數量。例如，如圖6所示的客戶登錄視圖532提供已經登錄到電子商務 通道2的在線銀行子通道的客戶的數量。該圖表提供對要登錄到通道、子通道或應用的客 戶的數量的一般測量，所以可以將其與已經在該通道、子通道或應用中發(fā)生的事故的數量 進行比較。在很多情況下，事故的數量與客戶登錄的數量成比例，但是并不總是這樣?？蛻?登錄視圖532僅僅提供幫助跟蹤和診斷在銀行發(fā)生的任何事故的另一工具。如圖7所示，儀表盤500還允許用戶104查看關于每個單獨的事故的細節(jié)。用戶 104可以選擇MOD事故列表530中的事故單號541，以查看詳細報告560。詳細報告560包 含在下面詳細地論述的事故單中包含的重要信息的概覽。詳細報告560具有四個部分，即， 一般信息部分562、因果信息部分564、影響信息部分570和概覽信息部分580。如果解決方 案滿足服務水平協議、相關實用手冊、以及最近更新的時間和日期，則一般信息部分562列 出描述、開始日期、結束日期、持續(xù)時間、根本原因來源、事故單號、問題單號、嚴重性。因果 信息部分564列出在何處發(fā)生故障、什么事件導致故障、以及什么問題使故障影響更加復雜。影響信息部分570包含受影響的通道548、受影響的技術執(zhí)行者572、受影響的子通道 573、地理位置574、FCI 550,DCI 55UPHL 552和AML 553。概覽信息部分580包含事故的 恢復、原因和解決的概覽，如它當前的那樣。在詳細報告560中完成的字段的數量取決于解 決事故有多難、事故在生產支持過程內發(fā)生多久、以及已經將多少細節(jié)添加到事故單，如針 對ICI部分800的進一步詳細的論述。詳細報告560允許用戶104檢查和跟蹤該用戶104感興趣的特定事故的事故進 展。通過檢查打開的事故單或完成的事故單，具有相似的或者相同的問題的用戶104可以 減少他/她自己或者涉及特定事故的其他人的工作量。如果過去已經發(fā)生相同或相似的問 題，則該事故的解決方案可以幫助解決本事故。詳細報告560和事故單提供與每個生產事 故有關的處理、人員和修復的詳細概要。而且，因為詳細報告560列出了要處理事故的最后 一個人和查看事故單的最后時間，所以，用戶104還可以利用詳細報告560來識別事故狀態(tài) 和確定解決事故過程中的下一個步驟。在圖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列出產生事 故的錯誤(例如，如果在線銀行監(jiān)測器正顯示登錄失敗)或者事故本身。癥狀/事故152 的可能原因153指示過去已經產生錯誤或者將要產生錯誤的常見原因。受影響的可能通道 154向用戶104指示錯誤可能會影響到的不同的通道或子通道。整治領導155列出MOD和 基礎設施領域的知識淵博者(“IDG”)。MOD提供對生產支持環(huán)境的高層責任制，但是具有 對嚴重事件的MOD的IDG伙伴關注服務恢復，并從事建立的根本原因分析。最初治療尋呼 團體156是為了解決事故而可能必須包含在事故恢復處理中的團體的列表。注釋部分156 還被包含在內，從而向起草事故恢復指南150的人提供列出任何建議或特殊指令的地方。事故恢復指南150還具有事故恢復指南顯示部分160。該部分列出每個事故恢復 指南150的所有處理步驟162。處理步驟162包含進一步定義事故恢復指南150處理和給 知識管理應用125內的其它區(qū)域和數據提供交叉參考的鏈接和注釋164。鏈接和注釋164 可以將用戶104帶到知識管理應用125內的其它標簽。因此，在特定步驟的過程中，在恢復 處理中，用戶104可以在到“process map”的鏈接上點擊，并且，可以將用戶帶到Map 300 部分中的相應處理圖。另外，用戶104可以對這些步驟中的一個步驟有問題，并且，可能需 要與合適的聯絡人就此進行討論。用戶104可以選擇“聯絡人”鏈接，并且可以被帶到聯絡 人700標簽中的正確的聯絡人名單，其概括了誰是該具體步驟的合適的聯絡人。而且，事故 恢復指南150被鏈接到稍后討論的知識庫200標簽中的特定事故單，使用該具體事故恢復指南150已經解決了這些特定事故單。為了識別使用事故恢復指南150如何解決前面的事 故，用戶104可以查看在事故恢復指南150鏈接的事故單。在一個實施例中，實用手冊100包含用于在企業(yè)內發(fā)生的每個生產事故的事故恢 復指南150。如果在還沒有事故恢復指南150的情況下發(fā)生了事故，則指定去修復該事故的 團隊創(chuàng)建事故恢復指南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被直接發(fā)送給整個知識管理應用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。在本 發(fā)明的其它實施例中，map 300的界面的左邊列出每個通道和子通道的可用的處理圖。當 在左邊選擇處理圖名時，在map 300界面的右邊，以窗口顯示處理圖。在一個實施例中，這 些處理圖中的所有程序和系統都被交叉鏈接到其它的處理圖，并且，通過知識管理應用125 中的其它標簽部分可以直接訪問。圖11圖示來自map 300標簽的物理處理圖的示例。在本發(fā)明的一個實施例中，map 300部分具有反轉(roll over)特征，S卩無論何時光標位于處理圖中的要素上，都顯示更 多的信息。當處理圖中的要素被反轉時，將對象下鉆到下一級，從而提供與該要素有關的更 多的信息，例如，解釋處理圖的該要素的附加圖片或文本。在一個實施例中，當點擊或滾動特定圖中的圖標時，在界面顯示上呈現彈出窗口 350。窗口 350具有與該要素的屬性相關的標簽和列表。這些標簽涉及每個標簽的屬性列表信息和圖標的不同方面。在一些實施例中，出于組織目的，每個標簽可以具有搜索功能、層 次結構下鉆樹、和/或信息列表。每個標簽中的屬性涉及的信息包括，但不限于，文檔管理、 性能度量、到其它處理圖的鏈接、知識管理應用中的數據、以及對與窗口 350相關的處理圖 中的各要素的系統要求。在一個實施例中，使用在每個map的頁面的頂部的導航圖標360， 用于鏈接到知識管理系統1的其它區(qū)域和用于創(chuàng)建和編輯位于彈出窗口 350中的數據。物理圖310顯示關于系統的硬件和物理細節(jié)。它們包含正在調查的系統的硬件部 件、部件的位置、數據庫、服務器等。物理圖310捕獲與以下有關的信息框(box)(或者銀行 中的物理硬件)；傳輸協議(通過因特網傳送音頻和視頻數據的標準化格式)；網絡裝置； 數據庫；服務提供者；框的位置；IP地址；系統需要的容量；服務器角色識別(例如，主體、 故障轉移、激活與非激活狀態(tài))；框來源(負責物理硬件的組織)；對象編排服務(“00S”) (用于將不同類別的硬件捆綁在一起)；以及與其它系統、應用和/或要素的交互信息。可以通過在map中的圖標上滾動或點擊來訪問物理圖310中的特定要素的信息。 例如，當在處理圖中包含服務器時，用戶可以點擊或滾動服務器圖標，并且窗口 350彈出顯 示標簽的數量和下面在標簽中列出的服務器的屬性。在一些實施例中，物理圖310可以具 有帶信息的標簽，該信息包括，但不限于，監(jiān)測總結文檔(“MSD” )、改變記錄、服務器信息、 以及性能和容量信息。MSD信息的標簽提供到整個知識管理應用125的文檔和數據的鏈接，但是，所述文 檔和數據不限于與該特定服務器相關的知識庫200中的事故。服務器還可以包含到特定事 故恢復指南150的鏈接，該特定事故恢復指南150用于對與服務器相關的事故的修復。到 儀表盤500的鏈接還可以被包含在MSD標簽中。用戶可以快速地評估服務器如何使用儀表 盤500正在執(zhí)行以查看與該服務器或應用相關的打開的事故。用于改變記錄信息的標簽提供對服務器進行的所有改變(例如，對主機名的改 變)的列表、以及在特定時間段內提供給服務器的服務。服務器信息的標簽可以包含操作系統信息、服務水平協議數據、以及用于服務器 的其它系統信息，例如，應用清單工具(“AIT”)，其用來跟蹤與應用、主機名、框來源、框可 用性時間和IP地址有關的清單。這些標簽還可以包含到負責維護服務器的聯絡人的鏈接， 并且，通過點擊該鏈接，將用戶104帶到聯絡人700標簽，以看見關于聯絡人的聯絡信息。用于性能和容量信息的標簽圖示實時性能度量和容量，該實時性能度量指示服務 器正工作得如何好，該容量指示服務器如何可以控制和存儲更多的信息，例如，服務器的停 機時間和任何開機或關機的時間。邏輯圖320顯示所有交互應用、應用結構和界面、以及它們之間的鏈接。邏輯圖 320捕獲沒有任何硬件細節(jié)的應用信息，該應用信息包含前端應用、幫助應用、web服務器 信息，包含簡單對象訪問協議(“SOAP”)(在實現計算機網絡中的web服務中的協議說明書 或交換結構信息)、《eb邏輯、web領域(通過多個計算平臺來安設、操作和集成電子商務應 用)、中間件工具、web方法和在線支持系統(“0SS”)交互。在一個實施例中，以與物理圖310界面相同的方式安設邏輯圖320界面。用戶104 通過滾動圖標或選擇圖標來查看關于特定應用或應用的一部分的信息。窗口在屏幕上彈出 顯示具有下面列出的標簽的屬性的標簽的數量。標簽部分可以具有物理圖310的相同標簽 和/或不同標簽中一些。這些標簽可以包含關于改變控制的信息、工具和處理圖核查信息。改變控制信息列出對于特定時間段內的特定應用的所有改變記錄，例如，對應用的更新。工 具信息捕獲諸如監(jiān)測工具、日志文件、路由工具和從應用發(fā)起的任何其它種類的工具的工 具。map核查信息示出，map是否被標志為核查、何時進行了核查、誰已經核查了、以及它在 何時被創(chuàng)建。在一些實施例中，標簽提供了搜索功能的設施，該搜索功能允許用戶104根據 正在核查什么處理圖而在知識管理應用125中搜索與特定應用、系統或交易有關的信息。交易圖330示出特定交易如何流入或流出應用和系統。該處理圖捕獲與包含應用 和硬件二者的不同界面的終端到終端的交易流程通信或交互。交易圖330捕獲諸如不同應 用之間的交易流程、來自每個應用的輸入和輸出、處理系統流程、企業(yè)功能、排序不同企業(yè) 功能、和對到其它處理的交易的影響的信息。用戶104通過滾動圖標或選擇map中的圖標 來查看關于特定交易圖330的信息。窗口在屏幕上彈出顯示具有下面列出的標簽的屬性的 標簽的數量。交易圖330的標簽部分可以具有物理圖310和邏輯圖320的相同標簽中的一 些和/或不同標簽。一般來說，處理圖還包含指示誰負責維護處理圖的支持團隊信息。在一個實施例 中，用戶104能夠向支持團隊指出在處理圖中需要的改變，該支持團隊通過map 300界面從 用戶104接收對于請求改變的通知。在一個實施例中，如圖12所示，流程400標簽從客戶界面的角度提供流程圖402。 應當理解，在其它實施例中，流程400標簽可以從銀行或企業(yè)的角度提供圖表。流程圖402 提供對客戶與整個銀行界面連接的應用的高級概述。通過在搜索字段404中搜索、使用下 鉆菜單406、或者在某些情況中選擇流程圖402內的圖標，用戶104還可以下鉆到下一級流 程圖402或者查看關于其它應用和系統的其它流程圖402，該下一級流程圖402提供與客戶 界面應用和系統有關的更多的細節(jié)。對于銀行內的每個通道和子通道，可以存在多個流程圖402。如針對map 300部分 所述，流程圖402與其它客戶流程圖402，物理310、邏輯320和交易330處理圖，以及知識 管理應用125的標簽內的其它部分交叉鏈接。如針對處理圖所述，用戶104滾動或選擇流 程圖402中的圖標，以接收關于流程圖402中的該要素的更多的信息。此外，在具有標簽和 每個標簽內的屬性的彈出窗口中顯示信息?？梢栽谥R管理應用125中更新與處理圖和流程圖402中的每個有關的要素和信 息。對處理圖和流程圖402中的這些要素和信息進行的改變自動更新任何其它處理圖和流 程圖402或與改變的要素和信息交叉鏈接的其它信息。例如，可以在銀行實現對服務器的 更新。為了顯示新的服務器容量信息，用戶104更新與一個處理圖中的服務器有關的信息。 結果，如果服務器出現在任何其它的處理圖中，則將與該服務器有關的信息自動更新為包 含新的容量信息。ORI 600標簽是多級企業(yè)性能記分牌。它允許用戶下鉆到通道、子通道、應用、類別 和可預測性因素級別視圖，以評估應用的可靠性和穩(wěn)定性，因為它們與每個類別、子通道和 通道有關。給每個可預測性因素、類別、應用、子通道和通道指定加權平均值，該加權平均值 與每個在對上述級別的可靠性進行評分時的重要性有關。因此，可以將來自可預測性因素 級別的這些分數積累成用于類別、應用、子通道和通道級別中的每個的一個分數。圖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級別?；诳深A測性因素分數612計算 各分數，然后，使用加權平均值來計算類別分數614、影響應用分數616、子通道分數618，最 后計算通道分數603。如圖14b至14e所示，通過使用ORI分數單620來為每個應用606計算分數。分 數單具有類別列622、FCI可預測性因素列624、答案列626、子類別加權列628、源列630、格 式列632、比例列634和通道類別加權列636。類別列622中的類別608覆蓋生產支持的管理區(qū)域的范圍。它們是使用用于生 產支持中的任何應用606解決的主管理類別608?；诿總€類別608，在知識管理應用125 中對每個應用606進行評分?；趯υ谡麄€生產支持過程中何地、何時、如何發(fā)生FCI的分析，確定關于ORI 600的類別608。在一個實施例中，最重要的類別608被識別為改變管理 611、可用性管理612、服務持續(xù)性管理613、知識轉移管理614、基礎設施和風險管理615、容 量管理616、服務級別管理617和系統管理618。然而，應當理解，在其它實施例中，可以將 標準分成任何數量的不同類別608。每個類別608具有在可預測性因素列624中圖示的大量的相關可預測性因素610。 可預測性因素610是關于每個特定類別608的問題、數據值、量度或與如何在銀行內發(fā)生 FCI有關的其它因素。在每個類別608內，關于每個可預測性因素610對導致在應用606的 類別608內發(fā)生的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 properIyscheduled 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 ( "SP0F，，)(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 availabilityO with a view to identify SPOF ？O 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 ？
21
# 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 ？
0152]如圖14c所示，服務持續(xù)性管理613類別的FCI可預測性因素610可以包含
0153]# Is the business continuity plan in standard format ？
0154]O What is the date of the last test ？
0155]# Have all outstanding issues identified as a result of testingbeen resolved or is an approved business continuity remediation planin place ？
0156]· Is there a documented and known recovery plan in place foreach service area, in the event of an unforeseen issue ？
0157]# Are there regular backups of critical data taken and storedsecurely ？
0158]· Are critical backups of information tested on a regular basis ？
0159]· Is testing performed for quality attributes such as reliability, usability, and maintainability ？
0160]如圖14c所示，知識轉移管理614類別的FCI可預測性因素610可以包含
0161]# Has handover/takeover meeting conducted with initial team ？
0162]# Has necessary documentation been completed ？
0163]· Rate the quality of on-boarding new resources(bank andstrategic partner)
0164]
0165] place ？
0166]如圖14d所示，基礎設施和風險管理615類別的FCI可預測性因素610可以包含
0167]· 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))
0168]〇 If yes, how many instances of NP technology exist ？
0169]〇 Does application have remediation plan for any non-permitted technologies ？
0170]# Does application have a control plan ？
0171]〇 Was the control plan updated within past calendar year ？
0172]# Does the business impact analysis exist ？
0173]如圖14d所示，容量管理616類別的FCI可預測性因素610可以包含
0174]· On average how close are current processing volumes to thevolume ceiling of the application ？
0175]· Are there any known initiatives that will increase rate ofgrowth ？ Initiative, Sales campaigns，etc.)
0176]·Are threshold alarms in place for individual services thatalert staff
Rate the quality of training documentation and schedules
Are workarounds documented/new changes tested withworkarounds inabout 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 1/0， Network 1/0, Local Disk 1/0, Remote Disk 1/0)#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(AlIComponent 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手動地輸入?？商鎿Q地，通 過從知識管理系統1或銀行計算機系統140中的其它應用接收信息自動地填充這些分數。 如格式列632和比例列634所示，這些分數可以是基“yes”或“no”響應、比例、計數值、百 分率、數值范圍、通過或失敗、高中低響應或某一其它相似評定系統。具有諸如比例的多個 評定值的項目可以具有定義用于對可預測性因素610的最佳實踐的相關文本。在一些實施 例中，分數單620可以具有注釋字段，允許用戶104填充為什么對特定可預測性因素610賦 予特定分數，以證實該評定。文本和注釋字段幫助在整個通道的評分中創(chuàng)建一致性。根據對可預測性因素610的答案，在一個實施例中，可預測性因素在答案列626中 接收百分之零(0% )至百分之百(100% )的分數。應用606的特定類別608的分數基于 在該類別中的每個可預測性因素610的分數之和與在子類別加權列628中列出的因素權重 相乘。在本發(fā)明的一些實施例中，當確定應用分數時，并且，在使用應用分數計算子通道 和通道分數之前，與每個類別的可預測性因素610—起使用其它分數。例如，在一些實施例 中，利用應用風險和控制評價工具(“ARCAT”)來確定ARCAT風險分數和ARCAT控制分數。 ARCAT風險分數與固有的應用風險有關。通過考慮與諸如企業(yè)影響分析、下游應用、上游應 用、交易率、數據量、恢復時間要求、相關硬件和軟件、以及隱私數據的應用有關的風險，確 定ARCAT風險分數。ARCAT控制分數是一個應用對于各種其它系統或應用所具有的控制度 量。基于應用如何與業(yè)務持續(xù)性、技術構架、平臺或環(huán)境、生產穩(wěn)定性、法規(guī)遵從、業(yè)務處理 和信息安全有關，計算ARCAT控制分數。每個應用的ORI分數可以被減少至總分數的一個 百分率，并且，ARCAT風險分數和ARCAT控制分數可以與最終的ORI分數相加。例如，可以 將一個實施例中的特定應用的ORI分數乘以百分之八十(80%)?？梢詫⑺玫姆謹蹬c基 于零(0)至十(10)測量的ARCAT風險分數和基于零(0)至十(10)測量的ARCAT控制分數 相加。最后分數仍然是超出了 100%，但是現在包含ARCAT風險分數和ARCAT控制分數的附 加因素。而且，如類別加權列636中所示，對每個通道，在某些情況中是每個子通道，指定 類別權重，該類別權重與每個應用的類別608如何影響同該應用內的其它類別608有關的 每個通道和子通道中的FCI的發(fā)生有關。例如，如圖14b所示，電子商務通道2的改變管理 權重是百分之二十五(25%)，而BCT通道3的權重是百分之二十(20%)，等等。此外，對 于可用性管理類別，電子商務的類別權重是百分之十五(15% )，而BCT通道的權重是百分 之二十(20%)。對于一個通道中的每個類別，每個加權平均值之和等于百分之百(100%) 的總數。因此，每個應用的類別分數614與每個子通道和通道的加權平均值相乘并然后對 其求和，所以，每個應用具有關于它如何影響每個子通道和通道的分數。因此，如前所述，類別分數614是在答案列626中列出的可預測性因素分數610的 加權平均值。對于每個子通道或通道的該應用，子通道或通道的應用分數616是類別分數 614的加權平均值。在其它實施例中，子通道分數618是該子通道的應用分數616的加權平 均值。最后，通道分數603可以是該通道的子通道分數618或應用分數616的加權平均值?？梢詫崟r地、在定期的間隔期間、或按需地更新每個應用的分數單620，以檢查通 道、子通道和應用的置信度分數。在一些實施例中，特定應用或類別的分數按各種間隔通過 電子郵件發(fā)送到業(yè)務專家或應用管理者，以提醒該負責人及時地填充該字段。在本發(fā)明的其它實施例中，跟蹤測量時間，并且，將對可預測性因素610的警報和更新請求發(fā)送到正確 的員工，以確保每個應用的評分保持不斷地更新。對可預測性因素610、相關分數或加權平 均值進行改變的訪問可以僅僅被限制為已經獲準清算。在一個實施例中，對每個評分級別應用彩色編碼評分，以使得用戶104能夠快速 識別可接受的、存在失敗危險的或失敗的通道602、子通道604、應用606、類別608或可預測 性因素610。對大于75%的分數指定綠色代碼，指示相關度量已經通過并且是可接受的。對 50%至70%之間的分數指定黃色代碼，指示相關度量存在失敗的危險并且應該得以密切的 監(jiān)測。對低于50%的分數指定紅色代碼，指示相關度量已經失敗并且需要立即分析以確定 修復。如圖15所示的聯絡人700部分是用于尋找關于團隊、伙伴、聯絡點、層次結構級 別、通知聯絡以及其它聯絡參考的必要信息的參考標簽。與整個知識管理應用125的其它 標簽一樣，在一個實施例中，為了核查各個員工的聯絡信息，用戶104可以從通道級別下鉆 到子通道級別，下鉆到應用級別。通過在不同通道、子通道或應用級別中選擇各個員工的姓 名或職位，用戶104可以下鉆到各級別?？商鎿Q地，用戶104可以使用聯絡人搜索特征702 或下拉菜單703來尋找特定的聯絡人。圖15圖示對于電子商務通道2的在線銀行子通道的聯絡人700標簽中的聯絡人 顯示界面704的示例。聯絡人顯示界面704具有兩個部分，即，執(zhí)行者聯絡人710和管理者 聯絡人720。執(zhí)行者聯絡人710部分列出層次結構點712 (或職位)和每個層次結構點的聯 絡點714。在一個實施例中，執(zhí)行者聯絡人710部分中的層次結構點712列出技術執(zhí)行者、 生產支持執(zhí)行者、電子商務生產支持執(zhí)行者、以及技術構架和操作執(zhí)行者。本示例中的管理者聯絡人720部分顯示包括內部銀行生產支持伙伴的共享服務 的聯絡人。管理者聯絡人720部分列出與執(zhí)行者聯絡人710部分相同的信息，但是在下一 級層次結構上列出。管理者聯絡人720部分還具有層次結構點722和每個層次結構點722 的聯絡點724。在管理者聯絡人720部分的一個實施例中，層次結構點722列出一級、二級 和三級生產支持管理者，websphere, unix，分布性能和容量支持管理者，域管理者，優(yōu)秀管 理者中心，測試伙伴，以及大量的其它管理者和在這些管理者領導下工作的員工。知識管理應用125的事故恢復指南150、事故單或其它區(qū)域指示，聯絡特定層次結 構點722，以解決特定事故。提供鏈接，以將用戶104發(fā)送到正確的聯絡人700標簽。例如， 如果事故恢復指南150指示應該使共享服務的三級生產支持管理者注意該事故，則鏈接將 用戶104帶到圖15所示的管理者聯絡人720部分。然后，用戶可以將事故單發(fā)送到聯絡點 724列中列出的正確的三級生產支持管理者。在一些實施例中，可以提供層次結構點鏈接，所以用戶104可以通過在層次結構 點鏈接上選擇來查看層次結構圖。在其它實施例中，用戶104可以通過在聯絡點724列中 列出的姓名上點擊來查看聯絡點的電話號碼和電子郵件。如圖16所示的報告750標簽允許用戶能夠從在知識管理應用125中跟蹤的事故 中提取報告。用戶104可以通過報告750標簽來創(chuàng)建、接收和發(fā)送現成或自定義的報告。如 圖16所示，可以填寫事故信息報告生成器751，以創(chuàng)建自定義或現成的報告。報告750標簽 包含用于通過輸入事故單的標題752、開始日期754或結束日期756來生成關于特定事故單 的報告的字段。用戶104還可以填充他們想要報告的事故單號760或問題單號762。用戶104還可以基于一級、二級或三級的嚴重性評定級別763，事故的狀態(tài)764，事故的根本原因 所有者766，以及消費者和小企業(yè)銀行技術和操作受托人768 (僅列舉幾個)來創(chuàng)建報告。圖17圖示在報告750標簽中輸入請求之后自定義或現成的報告770看起來怎樣。 在報告770的概述部分772中，該報告包含在事故信息報告生成器751中輸入的信息。因 果信息780部分圖示事故如何發(fā)生，包括源系統781、因果事件782和失敗影響783。影響 信息790部分展示受影響的通道791、受影響的技術執(zhí)行者792、受影響的子通道793、影響 的地理位置794，以及FCI 795、DCI 796、PHL797和AML798的數量。報告770還列出事故 的問題784、受影響的客戶785、恢復786信息、原因787和解決方案788。報告770通常為 高層執(zhí)行者管理報告生成并且每日被核查。報告770還可以用于度量收集和分析，該度量 收集和分析用于驅動銀行的戰(zhàn)略目標。如圖19所示的ICI 800標簽是從首次識別事故的時候起跟蹤事故的地方。圖18 圖示當首次發(fā)現事故時處理該事故的通知程序。當在生產過程期間或者在生成系統上發(fā)生 生產事故時該程序中的第一步驟是，發(fā)送具有事故信息的錯誤記錄，以便存儲在諸如銀行 數據庫130的數據庫中，如塊1810所示。在一些實施例中，通過表明已經發(fā)生錯誤的電子 郵件或者某些其它通信，用戶104接收通知。在接收到通知之后，或者，在執(zhí)行主動監(jiān)測時， 用戶104搜索數據庫中是否有新事故，如塊1812所示。在用戶104識別新事故之后，用戶 104通過檢查數據庫中的錯誤報告來識別與事故相關的問題，如塊1814所示。一旦識別了 該事故的問題，用戶104就在知識庫200中搜索是否有在過去已經解決相同問題的任何相 關事故，如菱形塊1816所示。如果用戶104發(fā)現事實上有相關事故，則用戶104下鉆到事 故報告，以了解是否解決了該特定相關事故，如菱形塊1818所示。如果解決并關閉了該事 故單，則用戶遵循在知識庫200事故單中概括的程序，以解決當前的事故，如塊1820所示。 當解決了事故時，用戶104可以關閉問題，如塊1840所示。此外，如前所述，為了幫助后續(xù) 的用戶面對相同或相似的事故，用戶104可以在關閉當前事故報告的過程期間使用發(fā)現的 任何附加信息來更新在知識庫200中找到的事故單。如菱形塊1816和1818所示，如果用戶104不能找到相關事故單或者該事故沒有 得以解決，則用戶104將新事故單登錄到ICI800，如塊1822所示。圖19圖示事故單的事故 主頁。用戶104可以通過在ICI 800主頁中選擇“新事故”按鈕801來輸入事故，如塊1822 所示。在打開新事故之后，將用戶104帶到事故單屏幕810，如圖20至25所示。在一些實 施例中，根據存儲在銀行數據庫130中的錯誤報告中的數據，例如問題單號811、嚴重性812 或開始日期813、以及可以在該錯誤報告中找到的任何其它信息，知識管理應用125可以將 數據拉入到新事故單。然而，用戶104還具有編輯或刪除事故單中的任何信息的能力。因 此，在用戶104創(chuàng)建新單之后，他/她可以輸入或改變問題單，該問題單的嚴重性812、主單 號814 (在首次識別生產事故時用于識別它的第一錯誤報告的數量)、客戶端影響815和狀 態(tài)809。而且，當用戶104填充事故單時，他們可以通過選擇starttime 813、L2 awareness 816,MOD engaged 817,restored 818和finished 819按鈕，來選擇各個按鈕，以對事故單 加時間戳，該時間戳標出用戶何時接收到該事故單，或者在該程序中該事故單何時到達特 定的關鍵點。在用戶104將新單登錄到ICI 800之后，用戶104查看用于上報的尋呼指南，如塊 1824所示。基于發(fā)生什么類別的事故、需要向誰通知該事故，尋呼指南告知用戶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發(fā)生833進一步圖示在每個通道和子通道內如何發(fā)生 FCI和DCI。用戶104還填寫受影響的應用和功能部分834，更詳細地概括事故如何影響每 個通道和子通道的應用。用與事故正如何影響客戶以及該事故對客戶有什么影響有關的信 息填充客戶經驗部分835。用戶104還指示事故正在影響的地理位置836，這樣可以幫助將 根本原因識別為特定系統或服務器。在影響部分830末端結算(tally)總事故影響837，并 且，該總事故影響837列出了每個通道和子通道的總的FCI、DCI、AML和PHL。事故單的描述部分840保持試圖去解決該事故單的用戶104之間的通信的運行標簽。用戶104在通信細節(jié)841部分中輸入標題和描述，指示與解決事故單有關的信息。通 信運行標簽842保持在描述部分840中，并且，當調查該事故時，可以編輯或刪除通信運行 標簽842。此外，在描述部分840中可用的是回避方法843部分，該回避方法843部分允許 用戶104描述在識別和修復根本原因之前如何能臨時修復問題。還有恢復和解決844、以及 原因描述845部分，用戶104使用用于識別和修復事故單的根本原因的信息填充這些部分。如菱形塊1862所示，如果在初始級別上沒有識別根本原因，則將事故上報到關于 事故團隊的更多專門技能的更高級別，如塊1864所示。其后，該團隊再次分析和研究事故 單，直到識別根本原因。在識別根本原因之后，事故團隊實現解決根本原因失敗的修復，如 塊1866所示。如果該修復包含用于改變系統、硬件或處理的改變請求表(“RFC”)JURFC 號846被包含在事故單內。此外，填充事故持續(xù)時間847，指示從用戶將事故登錄到知識管 理應用125時到識別對事故單的修復所花費的時間。還提供到RFC單848和MOD聯絡信息 的鏈接，以便供用戶104隨后查詢。在實現修復之后，用戶為MOD撰寫稿件，指示團隊如何解決事故單，如塊1868所 示。用戶104填寫事故單的其它細節(jié)部分850和根本原因部分860。其它細節(jié)部分850具 有用于問題概述851、單指定852和永久性解決方案853的數據輸入區(qū)域。用指示如何發(fā)生 問題、用戶怎樣診斷問題和診斷分析的結果的信息填充問題概述851部分。單指定852部 分描述負責永久性解決方案的技術團隊。永久性解決方案853部分描述對事故修復的最終 結果。其它細節(jié)部分850還識別用來解決事故的工具854。對利用的工具的識別包括，但 不限于，使用的實用手冊855，用戶104是否查閱知識庫856，以及創(chuàng)建或者用來修復事故的 任何文件857的附件區(qū)域。此外，在一些實施例中，在事故單中包含將用戶104帶到利用的 工具的鏈接，所述工具包括，但不限于，從實用手冊100使用的事故恢復指南150、從知識庫 200使用的事故單等。在確定事故修復之后，用戶104還填充根本原因部分860。在根本原因部分860中， 用戶104通過回答下述問題來描述原因/失敗細節(jié)861 故障起源于哪里861 ；什么事件導 致故障866 ；以及什么問題使初始故障870的影響復雜？在故障起源于哪里861的問題下，用戶填充描述初始故障點863、第二故障點864 和最終故障點865。在什么事件導致故障866的問題下，用戶填充原因867、事件888和描 述869部分。在什么問題使初始故障870的影響復雜的問題下，用戶104填充影響871、根 本原因來源872、以及消費者和小企業(yè)銀行技術和操作受托人873。用戶104還填寫動作項目部分880，該動作項目部分880概括了需要做什么來完成 事故的修復。此外，事故單還具有通信歷史部分890，該通信歷史部分890對于事故單中的 所有新的編輯和刪除的信息保持列表和時間戳。然后，將事故細節(jié)保存在銀行數據庫130中，如塊1870所示。然后，驗證在系統中 事實上已經修復事故，如塊1872所示。其后，用戶104可以關閉問題，如塊1874所示。將 關于事故的最后一次通信發(fā)送到具有事故概述的MOD，如塊1876所示。當MOD批準報告時， MOD將事故報告提交給知識庫200，事故報告被存儲在數據庫200中，以便供將來搜索和診 斷相關的事故。具有訪問權和想要編輯特定事故單中的信息的任何用戶104可以上拉至ICI 800主頁，如圖19所示。用戶104可以搜索特定日期范圍802、時間段803、嚴重性804內或按 照單號805的事故單。主頁列出與搜索標準匹配的所有事故單號806、以及相關問題描述 807和關于每個事故單號的嚴重性808。用戶104通過在事故單號806列中的事故單號上 點擊來查看編輯的事故單。知識管理系統還具有學術900標簽，如圖27所示。學術900是對生產支持同事的 跨職能的培訓論壇。在其它實施例中，學術900可以用來存儲和跟蹤對銀行的所有員工或 者任何其它企業(yè)中的所有員工的所有培訓。學術900向知識管理應用125的用戶104提供 在線培訓，所述用戶包括銀行人員，例如生產支持員工和MOD。學術900提供對包含針對銀 行內的特定職位的培訓模塊的認證程序的訪問。在其它實施例中，模塊可以是與特定認證 程序不相關的奇異模塊。圖27圖示學術900主頁，包括關于學術主頁902、查看所有學習 904、搜索學習906和查看成績單908部分的標簽。可以按照許多不同的格式向用戶104提 供培訓模塊。這些模塊可以是滑動式演示、視頻、純音頻或者交互顯示(僅舉幾個例子)。學術主頁902標簽包含被用戶104工作所在的銀行、L0B、部門或團體認為是必要 的任何需要的認證912。狀態(tài)指示器914記錄認證程序是否可用、認證程序是否在處理中、 或者認證程序是否已經完成。還提供記錄圖標916來作出與認證有關的筆記，并且提供書 簽918來將用戶帶到與認證程序相關的特定鏈接。學術主頁902標簽還具有下鉆按鈕920，以允許用戶104查看與認證程序相關的特 定模塊和要求中的每個，如圖28所示。對認證的下鉆列出需要的每個模塊，以及模塊是否 可用、是否正在處理中、是否完成或鎖定922(這說明，在鎖定模塊變成可用之前，用戶必須 完成其它模塊)。每個模塊可以具有在允許用戶移動到下一個部分或模塊之前用戶104完 成的多個部分。在允許用戶104進入其它模塊之前，或者在對特定程序的認證被批準之前， 還可以在模塊結束時要求測試或測驗，以確定用戶104對業(yè)務的熟練程度。此外，狀態(tài)指示 器914顯示每個模塊的狀態(tài)。查看所有學習904標簽允許用戶瀏覽銀行可用的所有學習模塊，并且將它們或者 任何認證程序添加到用戶104的學術主頁902。根據對于特定職位空缺或者團體、部門、子 通道或通道內的職位的要求，可以組織認證程序和模塊。用戶104可以將要求用戶104進 行的認證程序或模塊與用戶104可用的任何認證程序或模塊一起相加，以增進用戶104對 銀行內的其它團體、部門、子通道或通道的一般了解。此外，負責團體、部門等的某些用戶 104可以具有指定特定認證程序或模塊給在該團體、部門等中工作的其他用戶104的能力。 這些認證程序或模塊可以由團體、部門等的老板加載到該特定團體、部門等中的所有用戶 104，作為需要的培訓或者對老板的團體、部門等中的用戶104感興趣的領域。搜索學習906標簽允許用戶104對于用戶104可能想要進行的任何認證程序或模 塊執(zhí)行關鍵幀、日期、團體、部門、子通道、通道等搜索。搜索結果顯示銀行的所有認證程序 或模塊。如果允許用戶104訪問認證程序或模塊，則用戶104可以將在搜索學習906標簽 中找到的任何程序添加到用戶104的學術主頁902標簽。查看成績單908標簽允許用戶查看用戶104的認證程序或模塊歷史，該認證程序 或模塊歷史概括了用戶104已經完成和通過哪些程序和模塊。此外，它列出用戶進行或者 要求用戶進行的任何測試或測驗的分數。查看成績單908標簽不僅對用戶104跟蹤各種認 證程序和模塊是非常有幫助的，而且對于管理者和執(zhí)行者以及審計組織和監(jiān)管機構也是非常有幫助的。管理者和執(zhí)行者可以容易地將模塊加載到員工的學術主頁902標簽，并且在 查看成績單908標簽中跟蹤哪些員工完成了這些模塊。此外，審計團隊不必花費時間去查 明銀行應用的用戶104在特定應用中是否得到了妥善的評估和培訓，因為他們可以查看成 績單908標簽，以立即了解所有用戶104是否都完成了需要的培訓。另外，如果監(jiān)管機構 想要知道銀行是否已經將聯邦規(guī)定中的改變告知員工，則可以向監(jiān)管機構顯示查看成績單 908標簽，該查看成績單908標簽概括了已經完成相關培訓模塊的用戶104。在學術900中的模塊內，用戶104可以通過鏈接來瀏覽內容頁面，尋找知識管理應 用125中的其它地方的信息。用戶104還可以添加、編輯和刪除每個模塊的特定頁面上的 記錄，如果他們將來有問題，可以返回到模塊或記錄部分。在知識管理應用125內訪問到的 特定區(qū)域的書簽可以被添加到這些模塊內或者被去除，以幫助將用戶104引導到與這些模 塊相關的區(qū)域。在本發(fā)明的其它實施例中，用戶104可以在與模塊有關的學術900中玩游戲。學 術900還包含術語表，所以對這些模塊內的某些術語不熟悉的用戶104能夠查閱該術語表， 以提供對模塊的更好的理解。圖29圖示交互顯示模塊界面950的示例。圖標952用于諸如在知識管理應用125 內改變主題、計時、對不同模塊或區(qū)域作書簽的全局功能。提供窗口按鈕954，用于關閉、最 小化和縮放顯示。顯示模塊界面950還具有用于與知識管理應用125主頁鏈接的主鏈接 956。工具欄958包含關于在交互顯示內到各個區(qū)域的鏈接的圖標，所述區(qū)域例如是，但不 限于，主頁、詞匯功能、資源頁面、幫助頁面、記錄頁面、打印功能、交互游戲、測驗和測試頁 面、實用手冊100標簽等。用戶104可以通過在工具欄958中提供的鏈接上點擊來查看這 些部分中的任何部分。還提供課程退出按鈕959，以便用戶104在模塊完成期間或者在模塊 完成之后退出課程。如果在模塊期間退出交互顯示模塊界面950，則在退出模塊之前保存用 戶104的進程。在一個實施例中，交互顯示模塊界面950的主內容區(qū)域960具有標題962、用于在 整個模塊移動的瀏覽路徑區(qū)域964、以及用于在整個模塊前進和后退的前進966和后退968 特征。內容顯示970顯示用戶正在工作的模塊的特定頁面，并且，音頻成績單區(qū)域972提供 音頻內容的文本。最后，角色動畫980使其看起來和聽起來好像該角色正在教課，并且包含 用于控制角色的音頻和動畫的角色動畫控制982。圖30圖示知識管理系統1使用的學術處理流程1900，該學術處理流程概括了該 知識管理系統1如何跟蹤和顯示關于銀行的每個用戶104的培訓模塊和認證程序。如塊 1902所示，知識管理應用125通過用戶計算機系統110從用戶104或者通過銀行計算機系 統140自動地將培訓模塊和認證程序以及相關的測試、測驗、視頻文件、音頻文件等一起接 收，并且將它們存儲在銀行數據庫130中。用戶104可以將這些模塊和認證程序創(chuàng)建和加 載到知識管理應用125，或者，知識管理應用125可以將這些模塊和認證程序隨著它們被創(chuàng) 建而推或拉到學術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 等人的美國專禾丨J 申請 No.12/428,337,題 目 為"Incident Communication Interface for the Knowledge ManagementSystem”;以及Grace 等人的美國專利申請No. 12/428，340，題目為"Academy for the Knowledge Management System，，。本文描述本發(fā)明的具體實施例。本發(fā)明所屬領域的技術人員在受益于前面的描述 和相關附圖中提出的教導的情況下，將會想到本文闡述的本發(fā)明的許多變形例和其它實施 例。因此，將會理解，本發(fā)明并不局限于公開的具體實施例，并且，本發(fā)明的變形例、其它實 施例、以及實施例的組合應當被包含在所附權利要求的范圍內。盡管本文利用了特定術 ， 但是僅僅在一般的描述性的意義上使用它們，而不是出于限制的目的來使用它們。
權利要求
一種用于跟蹤和解決在企業(yè)中發(fā)生的事故的監(jiān)測系統，該監(jiān)測系統包括用戶界面；存儲器裝置；通信裝置；和處理器，該處理器與通信裝置、用戶界面和存儲器裝置可操作地耦合，并包括用于接收與兩個或更多個事故有關的信息的裝置，其中，每一個事故與一個或多個企業(yè)通道、子通道或應用相關；用于將信息存儲在存儲器裝置中的裝置；用于跟蹤至少一個事故在事故的發(fā)生和解決之間的狀態(tài)的裝置；以及用于在用戶界面上顯示在通道、子通道、應用或各個事故級別上的與事故有關的信息的裝置。
2.根據權利要求1所述的系統，其中，用戶界面顯示與所述兩個或更多個事故有關的 信息，所述信息包括打開的事故單的數量；打開得比特定響應時間長的事故；每小時、每 天和每周的每一個通道、子通道和應用的事故的數量；由于事故引起的失敗的客戶交互的 數量；事故的根本原因；或者由于與其它通道、子通道或應用有關在通道、子通道或應用中 的失敗的客戶交互的數量。
3.根據權利要求1所述的系統，其中，處理器包括用于在用戶界面上顯示與每一個企 業(yè)通道、子通道或應用相關的事故的數量的裝置。
4.根據權利要求1所述的系統，其中，處理器包括用于在用戶界面上顯示與每一個企 業(yè)通道、子通道或應用相關的性能分數的裝置。
5.根據權利要求1所述的系統，其中，處理器包括用于在用戶界面上顯示一個或多個 圖形圖表的裝置，所述圖形圖表圖示與事故相關的下述因素中的一個或多個事故的響應時間；事故或失敗的客戶交互的強度；事故的根本原因或者解決事故失??；或者每一個通道、子通道或應用的事故或失敗的客戶交互的比率。
6.根據權利要求1所述的系統，其中，處理器包括用于在用戶界面上顯示由于事故引 起的失敗的客戶交互的裝置。
7.一種用于跟蹤和解決在企業(yè)中發(fā)生的事故的監(jiān)測系統，該監(jiān)測系統包括 用戶界面；存儲器裝置； 通信裝置；和處理器，該處理器與通信裝置、用戶界面和存儲器裝置可操作地耦合，并包括 用于接收與一個或多個事故有關的信息的裝置，其中，所述一個或多個事故與兩個或 更多個企業(yè)通道、子通道或應用的相關；用于將信息存儲在存儲器裝置中的裝置；以及用于在用戶界面上一起顯示所述兩個或更多個企業(yè)通道、子通道或應用以及關于和每 一個企業(yè)通道、子通道或應用相關的所述一個或多個事故的信息的裝置。
8.根據權利要求7所述的系統，其中，處理器包括用于在用戶界面上顯示在通道、子通道、應用或各個事故級別上與所述一個或多個事故有關的信息的裝置。
9.根據權利要求7所述的系統，其中，處理器包括用于跟蹤至少一個事故在事故的發(fā) 生和解決之間的狀態(tài)的裝置。
10.根據權利要求7所述的系統，其中，用戶界面顯示與所述一個或多個事故有關的信 息，所述信息包括打開的事故單的數量；打開得比特定響應時間長的事故；每小時、每天 和每周的每一個通道、子通道和應用的事故的數量；由于事故引起的失敗的客戶交互的數 量；事故的根本原因；或者由于與其它通道、子通道或應用有關在通道、子通道或應用中的 失敗的客戶交互的數量。
11.根據權利要求7所述的系統，其中，處理器包括用于在用戶界面上顯示關于與事故 相關的性能是否可接受的信息的裝置。
12.根據權利要求7所述的系統，其中，處理器包括用于在用戶界面上顯示一個或多個 圖形圖表的裝置，所述圖形圖表圖示與事故相關的下述因素中的一個或多個事故的響應時間；事故或失敗的客戶交互的強度；事故的根本原因或者解決事故失敗；或者每一個通道、子通道或應用的事故或失敗的客戶交互的比率。
13.根據權利要求7所述的系統，其中，處理器包括用于在用戶界面上顯示到各個事故 的鏈接，用于查看與各個事故有關的分析和細節(jié)的裝置。
14.一種用于監(jiān)測系統的方法，包括通過使用處理器，接收與兩個或更多個事故有關的信息，其中，每一個事故與一個或多 個企業(yè)通道、子通道或應用相關； 將信息存儲在存儲器裝置中；通過使用處理器，跟蹤至少一個事故在事故的發(fā)生和解決之間的狀態(tài)；以及 在用戶界面上顯示在通道、子通道、應用或各個事故級別上與事故有關的信息。
15.根據權利要求14所述的方法，其中，用戶界面顯示與所述兩個或更多個事故有關 的信息，所述信息包括打開的事故單的數量；打開得比特定響應時間長的事故；每小時、 每天和每周的每一個通道、子通道和應用的事故的數量；由于事故引起的失敗的客戶交互 的數量；事故的根本原因；或者由于與其它通道、子通道或應用有關在通道、子通道或應用 中的失敗的客戶交互的數量。
16.根據權利要求14所述的方法，包括在用戶界面上顯示與每一個企業(yè)通道、子通道或應用相關的事故的數量。
17.根據權利要求14所述的方法，包括在用戶界面上顯示與每一個企業(yè)通道、子通道或應用相關的性能分數。
18.根據權利要求14所述的方法，包括在用戶界面上顯示一個或多個圖形圖表，所述圖形圖表圖示與事故相關的下述因素中 的一個或多個事故的響應時間；事故或失敗的客戶交互的強度；事故的根本原因或者解決事故失敗；或者每一個通道、子通道或應用的事故或失敗的客戶交互的比率。
19.根據權利要求14所述的方法，包括在用戶界面上顯示由于事故引起的失敗的客戶交互。
20.一種用于監(jiān)測系統的方法，包括通過使用處理器，接收與一個或多個事故有關的信息，其中，所述一個或多個事故與兩 個或更多個企業(yè)通道、子通道或應用相關； 將信息存儲在存儲器裝置中；以及在用戶界面上一起顯示所述兩個或更多個企業(yè)通道、子通道或應用以及關于和每一個 企業(yè)通道、子通道或應用相關的所述事故的信息。
21.根據權利要求20所述的方法，包括在用戶界面上顯示在通道、子通道、應用或各個事故級別上與所述事故有關的信息。
22.根據權利要求20所述的方法，包括通過使用處理器，跟蹤至少一個事故在事故的發(fā)生和解決之間的狀態(tài)。
23.根據權利要求20所述的方法，包括用戶界面顯示與所述一個或多個事故有關的信息，所述信息包括打開的事故單的數 量；打開得比特定響應時間長的事故；每小時、每天和每周的每一個通道、子通道和應用的 事故的數量；由于事故引起的失敗的客戶交互的數量；事故的根本原因；或者由于與其它 通道、子通道或應用有關在通道、子通道或應用中的失敗的客戶交互的數量。
24.根據權利要求20所述的方法，包括在用戶界面上顯示關于與事故相關的性能是否可接受的信息。
25.根據權利要求20所述的方法，包括在用戶界面上顯示一個或多個圖形圖表，所述圖形圖表圖示與事故相關的下述因素中 的一個或多個事故的響應時間；事故或失敗的客戶交互的強度；事故的根本原因或者解決事故失??；或者每一個通道、子通道或應用的事故或失敗的客戶交互的比率。
26.根據權利要求20所述的方法，包括在用戶界面上顯示到各個事故的鏈接，用于查看與各個事故有關的分析和細節(jié)。
全文摘要
本發(fā)明的實施例通過提供用于創(chuàng)建知識管理系統的方法、系統、計算機程序產品或前述的組合來解決了上述需要和/或實現其它的優(yōu)點，該知識管理系統包含在整個組織的通道和子通道中被標準化和集中化的性能儀表盤監(jiān)測系統。性能儀表盤監(jiān)測系統用來跟蹤、測量和解決在整個組織的通道、子通道、系統和應用發(fā)生的事故。該系統接收與兩個或更多個事故有關的信息，其中，每一個事故與一個或多個企業(yè)通道、子通道或應用相關。該系統將信息存儲在存儲器裝置中。該系統跟蹤至少一個事故的在事故的發(fā)生和解決之間的狀態(tài)。該系統在用戶界面上顯示在通道、子通道、應用或各個事故級別上與事故有關的信息。
文檔編號G06Q10/00GK101923674SQ20101016781
公開日2010年12月22日 申請日期2010年4月22日 優(yōu)先權日2009年4月22日
發(fā)明者B·R·埃利奧特, C·羅奇, D·A·桑斯伯里, D·D·格雷斯, E·N·亨薩克, G·M·拉韋列, M·J·施雷德, R·R·龐德拉帕加達, R·維斯瓦納坦, S·達爾加 申請人:美國銀行公司