以本體論為基礎之支援日常營運的知識管理系統架構(2/2)

(1)

行政院國家科學委員會專題研究計畫成果報告

以本體論為基礎之支援日常營運的知識管理系統架構(2/2)

計畫類別：個別型計畫計畫編號： NSC92-2416-H-004-005- 執行期間： 92 年 08 月 01 日至 93 年 07 月 31 日執行單位：國立政治大學資訊管理學系計畫主持人：楊亨利計畫參與人員：郭展盛、林青峰、鄭秀華報告類型：完整報告處理方式：本計畫涉及專利或其他智慧財產權，2 年後可公開查詢

中華民國 93 年 11 月 4 日

(2)

行政院國家科學委員會補助專題研究計畫完整報告

※※※※※※※※※※※※※※※※※※※※※※※※※

※ ※

※

以本體論為基礎之支援日常營運

※

的知識管理系統架構 ( 2 / 2 )

※

※ ※

※※※※※※※※※※※※※※※※※※※※※※※※※

計畫類別：個別型計畫

計畫編號：NSC 92-2416-H-004-005

執行期間： 92 年 8 月 1 日至 93 年 7 月 31 日

計畫主持人：楊亨利教授

計畫參與人員：郭展盛、林青峰、鄭秀華

成果報告類型：完整報告

處理方式：二年後可公開查詢

執行單位：國立政治大學資訊管理學系

中華民國 93 年 10 月 15 日

(3)

行政院國家科學委員會專題研究計畫成果報告

以本體論為基礎之支援日常營運的知識管理系統架構(2/2)

計畫編號：NSC 92-2416-H-004-005

執行期限：92 年 8 月 1 日至 93 年 7 月 31 日

主持人：楊亨利教授國立政治大學資訊管理學系

計畫參與人員：郭展盛、林青峰、鄭秀華

中文摘要 知識管理近年來已成為企業界及學術界相當重要的議題。然而，知識管理系統在企業中造成使用不高的部分原因，是因其會造成使用者額外輸入的負擔與缺乏一個標準的知識結構來幫助使用者之間的知識分享。本研究為一個兩年期計畫，在這第一年，我們結合一些熱門的資訊技術，如本體論、智慧代理人、資料發掘等技術，以及組織記憶等觀念，提出一套完整的知識管理架構。本架構含括知識管理之產生、模式化、儲存、使用的階段，且提供一個整合的環境，容許公私知識存放的空間，可讓使用者搜尋必要知識以協助日常營運，同時也收集一些新知識，減輕使用者額外輸入知識的負擔。在第二年，我們以銀行信用卡部門的客戶服務中心為例，在網路上實際製作一套知識管理系統，來驗證本架構的可行性。關鍵詞：知識管理、組織記憶、本體論、 智慧代理人、資料發掘 Abstract

In recent years, knowledge management has been a hot topic in both practical and academic fields. However, it is not easy to promote actual knowledge management system in business partly because users must need extra inputs and there is no standard knowledge structure to help knowledge sharing. This study is a two-year project. In the first year, we have combined different prevailing techniques or ideas, such as ontology, intelligent agent, data mining and organizational memory to propose an integrated knowledge management framework. This framework covers generation, modeling, storage, and

usage phases of knowledge management. It can provide an integrated environment to allow public and private knowledge storage spaces, help users search necessary knowledge to facilitate daily operations. In the meantime, it will also collect some new knowledge and alleviate the unnecessary input burden. In the second year, we take the bank call center as a domain example to implement a prototype to test the feasibility of this framework.

Key Words: Knowledge Management, Organizational Memory, Ontology, Intelligent Agent, Data Mining

第一章研究背景與目的

隨著全球知識經濟體系的逐步形成，組織知識已經變成一項很重要的經濟資源和企業競爭優勢的來源。組織知識是指包含語意(Semantic)和插曲式(Episodic)的資訊，其中的語意資訊，包含標準操作程序、規範手冊、報表文件等；插曲式的資訊則包含經驗、工作心得、情境相關的工作決策與其所得的結果等 (Stein & Zwass, 1995)，並且組織知識在市場上是很難去複製、模仿及替代的 (Brown & Duguid, 1998)。企業在面臨快速變遷的環境，需要不斷地創造、彙整和應用組織知識，來增加日常營運的生產力及創新能力，並進而保持自己本身的競爭優勢與能力(Alavi & Leidner, 2001 ； Drucker,1995 ； Nissen,1999)。因此，「知識管理」的觀念逐漸獲得企業界與學術界的重視。所謂的「知識管理」就是運用管理的知識及相關的資訊技術，有效的創造、儲存、整合和運用組織知識的過程，進而能促成或達成企業的目標，也就是讓散佈在組織內的核心及重要知識被保存下來，適

(4)

時的提供組織中的相關人員來使用，透過這些被分享的組織知識，可用來支援組織的日常營運，提昇企業內的創造力，進而能達成企業的目標，加強組織的績效，創造出新的價值和增強對外的競爭力 (Davenport & Prusak, 1998 ； Nonaka & Takeuchi, 1995 ； Cohen, 1998 ； Teece, 1998：Wiig, 1997；Woods & Sheina, 1999； Alavi & Leidner, 2001 ； Lee & Choi, 2003)。隨著資訊技術(如：Internet、本體論(Ontology)、智慧代理人(Agent)、資料發掘 (Data Mining) 等 ) 的日漸成熟與進步，有些企業已經將這些資訊技術應用到知識管理上，並進而建立知識管理系統 (Nissen, 1999 ； Fernandez-Breis & Martinez-Bejar, 2000 ；黃國禎、李依峻 , 2000)。知識管理系統是以資訊技術為基礎，應用於管理組織知識的資訊系統，其主要的目的為支援及增強組織中管理知識的流程，包括知識的創造、儲存/擷取 (Retrieval)、轉移與應用(Alavi & Leidner, 2001)。

對於組織知識的創造、擷取和運用，應該圍繞著組織程序，才能更有效的協助組織的日常營運。因此，知識管理系統在設計及規劃時，應以組織程序(Process)為核心(Kwan & Balasubramanian, 2003)。 Sowa & Zachman(1992) 認為一個資訊系統架構，在分析一個程序時，應該從六個角度來看，分別是：誰(Who)、什麼(What)、何時(When)、哪裡(Where)、為什麼(Why)、如何(How)。Lai & Chu(2000)提出一個知識管理的整合架構，由知識資源、知識管理活動(發起、產生、模式化、儲存、分配及轉移、使用、評估)、及知識影響三方面組成，並探討為什麼 (Why) 、是什麼 (What)、及如何(How)三方面的不同。知識管理系統中很重要的部份是知識庫的使用，Kwan & Balasubramanian(2003)提到組織中的知識庫不常使用，導致知識管理系統績效不彰的兩個主要原因是：(1) 要額外輸入文件知識到知識庫中，造成使用者額外的工作負擔；(2) 缺乏一個標準的知識結構，幫助使用者來分享不同角度的知識。本研究結合本體論(Ontology)、智慧代理人(Agent)與資料發掘(Data Mining)的資訊技術，以及組織記憶的觀念，提出一個完整的知識管理系統架構。本研究的系統架構，解決上述兩個問題的方式：（1）透過工作流程整合的方式，支援擷取使用者正在進行的組織知識（包含使用者新創和使用知識的部份），使得使用者不需要再額外的去輸入處理過的組織知識，減輕使用者的工作負擔；（2）提出一個標準的知識結構，儲存於知識庫中，幫助組織中的使用者分享不同角度的知識。本研究是針對組織作業程序(Process) 的 What、How、 Who、Why 四個構面來組成知識，簡言之，就是組織作業程序所對應的某一「處理的問題」的 What、How、Who、Why 四個構面，來組成及表達ㄧ個作業程序知識。本研究的目的是提出一個完整的知識管理系統架構，可以用來（1）支援組織的日常營運；（2）解決使用者額外輸入工作負擔的問題；（3）解決缺乏一個標準知識結構，來分享不同角度知識的問題；（4）提供使用者組織知識的教育訓練。本研究是應用在金融業信用卡部門的客戶服務中心(Call Center 系統)，並在網路上實際製作一個知識管理系統，以驗證本架構的可行性。

(5)

第二章文獻探討

本研究的文獻探討，主要是針對「知識管理」、「知識管理系統」、「本體論」、「組織記憶」、「智慧代理人」、「資料發掘」、「客戶服務中心」七方面加以探討，以下將所牽涉到的相關文獻，作深入探討。 1. 知識管理知識是一種流動性質的綜合體；其中包括結構化的經驗、價值、以及經過文字化的資訊，此外，也包含專家獨特的見解，為新經驗的評估、整合與資訊等提供架構。在組織中，知識不僅存在文件與儲存系統中，也蘊涵在日常例行工作、過程、執行與規範中 (Davenport & Prusak, 1998) 。知識依其特質可分為內隱知識（Tacit Knowledge）和外顯知識（Explicit Knowledge）兩種類型。企業中的內隱知識和外顯知識互動，是企業組織中知識創造的原動力，可以不斷地產生新的知識。對於知識移轉的過程可分為四類，分別是：「由內隱知識至內隱知識」、「由內隱知識至外顯知識」、「由外顯知識至內隱知識」與「由外顯知識至外顯知識」四類（Nonaka & Takeuchi,1995）。

Cohen(1998) 定義知識管理為「知識的蒐集、傳遞與衡量」。 Woods & Sheina(1999)定義知識管理為「一種發展、開發組織內有形及無形知識資源的任務，它包含了組織面及技術面的議題」。 Teece(1998)定義知識管理為「組織創造、移轉、組合與整合知識資產的過程」。 Wiig(1997)認為知識管理是一組定義清楚的程序或方法，用來發掘和管理不同作業的關鍵知識，確認新產品和策略，或是強化人力資源管理以達成企業的目標。綜合多位學者的觀點，可將知識管理的定義為：有系統、有組織、有目的地擷取、轉換及儲存組織內部重要的知識，適時及適當地提供給組織中的成員使用，並與其產生互動，進而創造出新的知識，最後達成企業的目標。Alavi & Leidner(2001)提出資訊技術應用到組織中的知識管理，有三種主要應用，分別是：將組織最佳實務編碼 (Coding) 和分享、創造合作式知識目錄 (Directories)與創造知識網路(Networks)。 2. 知識管理系統知識管理系統是以資訊技術為基礎，應用於管理組織知識的資訊系統，其主要的目的為支援及增強組織中管理知識的流程，包括知識的創造、儲存 / 擷取 (Retrieval) 、轉換與應用 (Alavi & Leidner,2001)。知識管理系統的主要功能有五項，分別是（1）把資料及文字轉變成知識、（2）把個人和群體的知識轉變成可接受的知識、（3）連結某些人的知識到其他人的知識、（4）在不同群體間的資訊溝通、（ 5 ）創造對組織有用的知識 (Fernandez-Breis & Martinez-Bejar,2000； O’Leary,1999)。知識管理系統應該圍繞著組織程序(Process)，來組織知識。對於每一個程序，程序的設計、程序的例子 (Instance)和知識資源都能夠由儲存處來擷取、儲存和萃取。Sowa & Zachman(1992) 認為一個資訊系統架構，在分析一個程序時，應該從六個角度來看，分別是：誰 (Who)、什麼(What)、何時(When)、哪裡 (Where)、為什麼(Why)、如何(How)。 Curtis 等(1992)則建議在程序模式中，應該從四個角度來看，分別是：功能面、行為面、組織面、及資訊面。Lai & Chu(2000)提出一個知識管理的整合架構，由知識資源(人類資本、結構資本、顧客資本)、知識管理活動(發起、產生、模式化、儲存、分配及轉移、使用、評估)、及知識影響三方面組成，並探討為什麼(Why)、是什麼(What)、及如何(How)三方面的不同。目前的知識管理系統可以概分為以下三類：(1) 純粹的知識管理系統；(2) 組織記憶資訊系統；(3) 輔助營運的知識管理系統。第一類系統是建立一個獨立的知識管理系統，以支援組織中知識的創造、擷取、轉換和應用，此類系統並未和公司中其他系統整合在一起，又可分為支援組織及個人的知識管理系統。在支援組織方面的知識管理，比較具

(6)

代表性的系統是 Nissen(1999)提出一個知識管理系統，稱為 KOPeR，應用於美國海岸巡防隊之決策工具。其以知識庫為基礎，主要目的是透過流程的再設計，支援知識工作的活動，並將其自動化。 Fernandez-Breis & Martinez-Bejar(2000) 提出一個知識管理系統，稱為 OntoInt，來幫助作知識管理及支援本體論(Ontology) 建立的程序。黃國禎與李依峻(2001)以網路代理人及知識庫為基礎，加入資料發掘與搜尋引擎技術，建構了一個符合企業所需的知識管理系統。張泊皓(2000) 期望能夠協助企業分析研發體系，定義符合企業需求的模式規格，建構一個研發知識管理模式系統。在支援個人方面的知識管理，比較具代表性的系統是高政汗(2000) 提出一個具自動建構本體論 (Ontology) 能力之個人化資訊分類系統。在網際網路盛行、資訊爆炸的時代，提供一般大眾一個自動化的機制，對來自於網際網路的大量電子文件予以分門別類，並且讓使用者能基於其使用上之方便及習性，正確地從系統中取得使用者所需要的資訊。朱毓君(2001) 提出一資訊整合系統，透過包裝器、資料清理與資訊整合等相關技術，來提供高品質且有意義的資訊給使用者。第二類系統其實並無知識管理系統之名，但卻有知識管理之實。以 OMIS (Organizational Memory with Information Systems)為代表，主要是利用資訊技術作為主要工具，來強化組織記憶，並支援組織活動，讓組織擁有更多的效能(Stein & Zwass,1995)。OMIS 之架構分為兩階層，第一層是達到組織效能的四個子系統，分別是整合性、調適性、目標達成、及典範維護子系統；第二層記憶功能的設計(知識獲取、保留、維護、搜尋、及擷取)，是支援第一層的四個效能子系統，以增強組織處理資訊的能力。Weiser & Morrison(1998) 提出一個專案記憶系統 (Project Memory)，能夠捉取及儲存專案的歷史資料，以便於以後的擷取和應用於遇到的問題。Malone 等(1999)提出流程手冊系統 (Process Handbook)，能夠捉取組織流程的設計 ( 如：流程知識 ) 。 Jablonski & Bussler(1996)提出工作流管理系統(WFMS) 可以同時抓取流程設計(如：工作流模板) 和流程案例 (Instances) 的歷史資料。 Conklin & Begelman(1988)提出 gIBIS，可以支援組織整個設計流程的基本原理 (Rationale) 有條理，且可以捉取設計流程的內容(Content)(如：參與的角色、工作項目等)。Balasubramanian et al.(1999)提出 Thoughtflow，以支援組織流程原理有條理，且可以捉取決策的前後脈絡環境 (Context)(如：角色、資源、排程等)。第三類系統可支援日常營運系統的運作，它提供一個整合的環境，可讓使用者搜尋必要知識以協助日常營運，同時也收集一些知識，減輕使用者額外輸入知識的負擔。其實在知識管理的口號還未熱門前，組織建模（Organizational Modelling）是與此有關的研究。如 Bose(1995)提出 CMS(Collaboration Management System)，它是一個智慧型的物件導向系統，將企業的採購流程加以建模，系統會半自動地與使用者合力完成採購。不過，那系統還無法容易地儲存新創造的知識，還稱不上是個知識管理系統。近年來，屬於這類且真正是個知識管理系統者，比較具代表性的是 Kwan & Balasubramanian(2003)所提出的知識管理系統，稱為 KnowledgeScope，實際應用於美國電訊公司 Comco 不動產授權信件(Real Estate Authorization Letter) 知識管理程序的處理。它提供一個整合的工作流支援能力，在企業流程進行中，擷獲並存取知識（也就是在流程進行時，創造與使用知識）；此外，它提供一個彙總模式(Meta-Model)，來組織與儲存企業的知識與其脈，進而改善知識倉儲缺乏標準知識結構的問題。本研究屬於第三類，也是要建立一個支援日常營運的知識管理系統，而與 KnowledgeScope 的主要差異是，本研究加入一些目前已成熟的資訊技術，如 Ontology、智慧代理人、資料發掘等技術，藉由使用這些資訊技術，可使所建立的輔助知識管理系統更容易、更完整、更有效率的擷取企業流程中所產生的知識、且進一步地將新創造的知識或更新的知識以標

(7)

準的結構存在知識庫中，以期蓄積組織記憶，幫助組織學習，也同時達成第二類的目的。以下，再將一些相關文獻加以列述。 3. 本體論 (Ontology) 本體論源自哲學領域中的形而上學， 乃是討論萬物的存有。後來被引用到人工智慧的領域中，用來表示概念和專用名詞的集合，而這個集合則被用來描述某個知識領域或建立知識的呈現。本體論可以是非常高階的，例如組成知識基礎的上層部份；也可以是特定領域的呈現，例如研發管理的本體論(Swartout & Tate,1999)。

在人工智慧領域中，Ontology 分析技術能使用於特定知識領域，藉由提供概念與說明來充分的加以描述，如：有關於物件種類、特性、與在物件間的關係的知識理論。透過 Ontology 分析可以讓我們知道知識的結構與各知識概念間的關連。 Ontology 就像是字彙(Vocabulary)，提供了一組措詞 (Terms)，來描述在一些領域 (Domain)上的事實。Ontology 也像是一種內容理論(Content Theory)，因為主要貢獻是去分辨認明存在於一些領域中，特定的物件種類與關係。為了要表達概念的 Subtype，Ontology 通常用一種概念的分類樹 (Taxonomic tree) 來顯示。對於 Ontology 來說，在表達上不僅只使用分類樹，而是會更進一步地使用更正規的系統，如結合一般結構化的描述、限制以及邏輯(Gruber,1992)。本體論是一種可分享的概念化協定，包括產業知識模式化的架構和呈現特定領域理論的協定。對資訊系統或網際網路來說，它可以藉由保留關鍵字與資料庫的表格和欄位的語意關係，組織關鍵字和資料庫的概念，對使用者感興趣的領域來說，這些語意關係提供資訊空間的摘要觀點 (Huhns & Singh,1997)。本體論可以根據「概念化架構的數量和種類」及「概念化的主題」這兩個向度作分類，可以分成術語本體論(Terminological Ontology)、資訊本體論(Information Ontology)、知識模型本體論(Knowledge Ontology)；若只以「概念化的主題」這個向度作分類，可以分成應用本體論(Application Ontology)、領域本體論(Domain Ontology)、一般本體論(Generic Ontology) 、陳述本體論 (Representation Ontology)(Van Heijst et al.,1996)。

本體論在知識基礎系統 (Knowledge Base System，KBS)的設計與發展思考上有顯著影響，在以往的資管領域，本體論的觀點有很多應用，如 Storey (1992)以本體論出發，提出 Naive Business Model，以協助資料庫設計工具之智慧判斷。使用本體論的優點有：促進系統間的知識分享、促進新系統的知識再利用、幫助人們取得知識、領域理論的發展、改善知識基礎系統的驗證與確認。本體論的重要性可以從兩個部份來談。首先，由於本體論構成特定領域知識的核心，若沒有知識論或知識的概念化過程，就沒有用來呈現知識的字彙。因此，創造有效知識呈現系統或字彙的第一步，要先對特定領域作有效的存在性分析，不充分的分析將會使知識基礎前後無法連貫。其次，本體論讓知識可以被分享，因為分析之後的結果包含特定領域的專有名詞、一般名詞和描述行為名詞，這些名詞是建立知識呈現系統的基礎。藉由分享這些知識呈現，其他需要類似知識呈現的人，就可以省去重複分析知識的過程(Chandrasekaran et al.,1999)。 4. 組織記憶 由於知識散佈於每一個企業的成員身上以及單位部門之中，組織之中並沒有一個功能部門足以承擔知識取得、分享、整合、發展、創新的任務，甚至組織也沒有人清楚到底有多少知識的存量，以及何謂未來知識發展的方向與策略。然而，我們可經由「組織記憶」的方式，保留一些可用的資訊，若將這些資訊加以整合與分析，便能轉換成組織的知識以茲利用。因此，組織記憶不失為一個知識管理的立基點－協助知識的創造。所謂組織記憶，便是將組織過去的歷史及知識，運用到組織現行的活動中，以提高組織的效能。組織記憶主要目的是：提供組織過往經歷與知識以支持組織或個人的決策制定，成為組織共享資源

(8)

(Huber,1991 ； Walsh & Ungson,1991 ； Robey,1994)，以達到組織效能(Duncan & Weiss,1979；Stein & Zwass,1995)。Walsh & Ungson(1991)提出組織記憶有五個主要保留處，分別是個體 (Individual) 、文化 (Culture) 、移轉 (Transformations) 、結構 (Structures)、生態(Ecology，即工作地點之周遭配置)等。Walsh & Ungson (1991)認為組織記憶在組織裡的主要功能為資訊分享、控制作用、政策宣導。Robey (1994) 認為組織記憶包含三大要素：組織常規、因果圖及身份(Identity)，其主要作用是組織學習互動的對象。El Sawy et al(1986)認為組織記憶包含語意 (Semantic) 和插曲式 (Episodic)的資訊，其中的語意資訊，包含章程手冊、標準操作程序、報表文件等；插曲式的資訊則包括與情境相關的工作決策及其所得的結果(Stein & Zwass,1995)，也就是加註過後活的知識。 Jessup & Valacich(1993)進一步指出組織記憶能夠提供資訊為所有成員們共享，除了過去的種種經歷外，也包括現今的認知以及未來的期望(如：組織結構、組織文化等)。因此，組織記憶嚴然成為組織以及個體之資訊供應集散地，也是引發個人創造知識之重要來源。學習與記憶是現代心理學的一個分支，學習是指藉助經驗獲得知識，而其中經驗則是指用感官直接認知事務；記憶是一種保持或想起過去經驗的一種回憶能力。因此，記憶是學習的基礎，學習行為是產生在整個記憶的運作過程上，因為透過記憶內容的重整、動態的儲存與讀取等程序，可使得所採取的行動更具效能，這就是所謂的學習。Shrivastava(1981)認為組織學習是指組織的知識基礎被發展和形塑的過程。Huber(1991)認為組織學習是透過資訊處理的程序，使得行為潛能的範圍發生改變。Cook & Yanow(1993)認為組織學習的定義是指透過表達和傳播的人為工具媒介，以及透過團體的集體行為來獲得、維持或改變多數人瞭解的意義。在探討組織學習時，可以由組織記憶的觀點切入探討，從中發掘出組織記憶裡的內容，並透過記憶轉換的機制設計，得知哪些的行為內容可以幫助組織學習(吳美勳，1999)。 5. 智慧代理人 在智慧代理人（ Agent ）方面， Fitzmaurice (1991)認為智慧代理人設計理念為目標導向，只要給予智慧代理人一個 “目標“，透過智慧代理人內建的規則與智慧，不須教導其何時與如何去做，智慧代理人即可完成任務。智慧代理人（Agent）主要是能夠模擬人類的行為，替人類處理一些耗時、煩瑣、規律性的事情，具有智慧（Intelligent）並且能夠自發性的處理所接收的工作(鄭文豪，1998)。Etzioni & Weld (1995)則認為一個智慧代理人，必須要具有的特性有：自主性(Autonomy)、連續性 (temporal continuity) 、人性化 (Personality) 、溝通能力 (communication ability) 、適應力 (Adaptability) 、機動性 (Mobility)等。透過上面對智慧代理人代理人定義及特性的說明，可以了解智慧代理人最主要的特性，就是具有智慧，能夠自主性的處理一些經常性、例行性、決策性的工作，另外還具有機動性的特質。智慧代理人可促進知識管理之各項必要活動之自動與順利進行。現今在智慧代理人技術之研究已獲致不錯成果，但很少能充分整合應用於知識管理領域中。在常見相關應用領域方面，包括主管資訊系統 (Turban,1998)、電子商務(Hedberg,1995； Brown et al.,1995) 、與決策支援系統 (King,1999；Turban,1998)等。與知識管理較相關之智慧蒐集代理人 (Information Gathering Agents)，此乃為使用者蒐集其所關心之資訊，以個人化(Chen et al.,1998) 及合作 (Lesser et al.,1998 ； Decker et al.,1995)的方式為使用者蒐集資訊。部份學者提出將 Agent 的架構整合於知識管理系統中，在這種架構中，企業內每個員工都是使用者，透過個人化的 Agent 可以搜尋並儲存各個領域的專業知識於知識庫 (Knowledge Base)中，而讓其他員工可以透過 Agent 來分享知識，且有助於企業內員工的溝通(Wang,1997)。 6. 資料發掘(Data Mining) 知識管理的知識來源可來自各方，而在資料庫領域中，由資料庫發掘知識就是

(9)

一個相當重要的研究方向。自 1991 年開始就有人研究如何從龐大的資料中，找尋所需的資訊，此一研究稱為知識發現 (Knowledge Discovery in Databases ； KDD)。資料發掘的領域可說是由“知識發現”相關研究延伸而來。主要的目的在於模擬人類專家對於資料中隱藏的知識挖掘的能力與行為模式。根據 Frawel et al.(1991) 的定義，資料發掘是由資料庫中挖掘那些隱含的、以前並不知道但卻可能有用的資訊過程。Grupe 和 Owrang(1995)定義是指由現存的資料庫中挖掘出新的事實或新的關係。Fayyad(1996)指出資料庫中之知識發現為自資料庫中選擇適當的資料，經過處理、轉換、資料挖掘及結果評估等一連串的過程，而資料挖掘僅是知識發現一連串步驟之一。由於資料挖掘是一個極富實用的研究領域，因此吸引了許多不同領域中學者的興趣，不同領域的學者希望能將自己的理論應用於資料挖掘中，因此針對不同的狀況提出了許多應用於資料挖掘的方法，如財務分析(Rathburn,1997)、決策支援系統(Madan et al.,1997)、市場分析 (Berry,1994)、電子商務(Cabeba et al.,1998) 等。也有人應用到了計畫資料庫，來發掘常用的計畫型態（Han, et al., 1997）。至於資料發掘與知識管理的關係，資料採擷技術則是運用在知識的擷取與分析上。 Bonora & Revang(1991)發展了兩個構面：知識儲存方式（機械式/有機式）以及知識的協調度（整合的/分散的），來說明知識的建構及維持，可用來說明資料發擷如何運用在知識的擷取與分析上，以利於知識的取得。黃國禎和李依峻(2001)則指出資料發掘在知識管理中，扮演一個不可或缺的重要角色，且使用資料發掘技術，建構了一個知識管理系統。AMS 公司是一家全球性資訊科技的顧問公司，應用資料發擷技術於知識管理系統中，使 AMS 公司的顧客服務品質大大提升，並降低了成本（Marquardt & Kearsley,1998）。在知識管理系統的開發上，資料發掘是一項相當重要的技術，因為資料發掘能夠協助知識的擷取與分析，因此結合資料發掘技術於知識管理系統中，將是重要的研究議題。本人在過去也已相繼在國科會中從事全球資訊網下資料發掘、企業內網路中使用記錄資料發掘之兩項研究。本研究將結合資訊技術，如 Ontology、智慧代理人、Data Mining 等技術，以及組織記憶等觀念，提出一套完整的知識管理架構，並未來將在網路上實際製作一套知識管理系統，以驗證本架構的可行性。本研究初步的構想，是想將本架構應用在金融業中信用卡部門的客戶服務中心，以支援日常營運系統的運作。本研究所開發的知識管理系統，預期除了能夠加速知識的傳遞、擴展知識的共享及知識的儲存量，更方便使用者的擷取及使用知識外，並且在知識的擷取、儲存、傳遞及共享上，能有效的管理知識。相信在社會及經濟環境不斷快速變化的情況下，企業唯有仰賴此知識管理系統的協助，方可在時代的潮流中，以穩健的步伐適應環境，並尋求突破。以下將對客戶服務中心的觀念演進稍作介紹。 7. 客戶服務中心(Call Center) 客戶服務中心是企業直接服務與接觸 客戶的第一線，隨著客戶服務中心的演進，其定位也發生變化。在過去，客戶服務中心只提供一些簡單的服務，如查詢、技術支援等。然而，由於資訊科技的協助與支援，客戶服務中心的功能應用方面大量增加，因而逐漸發展出自己新的定位。就服務定位來看，目前企業將客戶服務中心視為提供客戶服務主要通路的原因有二：第一是客戶服務中心可以直接與客戶進行對話，適時反應市場狀況與消費者者意見，以確保並確保客戶對服務的滿意度。第二是客戶服務中心透過人員與客戶的互動聯繫，較易掌握客戶需求並可立即回應(Bradshaw,1999)。設立的客戶服務中心基本上可用三種不同的構面來描述，分別是功能面、應用面和資訊傳輸面。在功能方面，客戶服務中心主要可分為來電 (Inbound) 、去電 (Outbound) 、項目管理 (Account Management)等；在應用方面，一般可以提供各種與行銷、銷售、服務、調查等相關的應用；資訊傳輸方面，除了傳統的電

(10)

話、傳真方式，還包括新增的自動語音系統、電子郵件、網路線上留言、網路電話等(吳欣穎，1999)。設立客戶服務中心的產業，依據不同的產業各有不同的功能與應用，在金融業(銀行、信用卡機構、證卷或信託基金公司、保險業等)方面，主要的應用為客戶金融、電話行銷、帳款催收、關係維繫等(林琬儒，2000)。客戶服務中心要發揮預期的效益，事前的妥善規劃與正確的發展步驟是不可缺少的。吳欣穎(1999)認為客戶服務中心的建置會對企業內各部門造成一定的衝擊，所以在規劃時，必須就業務面與組織面加以考量。另外，江銓祥(2000)從功能規劃的角度，認為客戶服務中心規劃必須考量硬體、軟體、人力資源部份。Cleveland & Minnucci(2000)認為客戶服務中心是一個由策略、人員、流程、科技所組成的系統，這個系統能夠有效率的將企業的資源整合起來以與客戶互動，以滿足客戶需求。由於這是對客戶的第一線，其服務人員應需要足夠的知識，也可由服務的過程中累積相當的知識，包含客戶需求、處理方式等，故將選為本研究之雛形應用領域。

(11)

第三章研究架構

第一節研究架構內容設計及定義 一、系統概念架構設計：本研究提出一個知識管理輔助系統的整體概念架構，如圖 3-1 所示。基本上，它是某個日常營運系統上所附加的知識管理支援系統，原日常營運系統的功能不變，只需要在其主程式中呼叫本支援系統，並將所傳回的知識展現出來即可。以下依系統架構圖中各符號代號，分別解釋之。 a. 員工：此為企業的內部員工。當其為 顧客服務時，可能會連到某個日常營運系統（如信用卡 Call Center 系統），搜尋相關的資訊與知識，並回報給顧客。 b. 某個日常營運系統：此為企業的某個 日常營運系統（如信用卡 Call Center 系統）。主要協助內部員工處理日常營運的工作，及提昇內部員工的工作能力且可協助搜尋相關資訊。 c. 其他日常營運系統；此為企業的其他 日常營運系統（如銀行的信用卡核放、帳務系統、存、放款系統）可協助「某個日常營運系統」（如 Call Center 系統）處理一些有相關聯的事務。 d. 公司資料庫：此為企業日常營運系統 （如信用卡 Call Center 系統）所會用到的所有公司內部資料庫，如信用卡持卡人資料（User Profile）、每月交易明細、繳款記錄、甚至其存、放款資料。同時，此日常營運系統儲存之使用記錄也會自動留存一筆 Log 記錄於公司資料庫。Log 的記錄是採用人員和事件分開記錄的方式。 e. WWW Server：此為本架構中的網站 伺服器。雖然本架構僅繪出一個網站伺服器，但即使有多個，或有代理伺服器，也可適用於本架構。只是在那種情況下，另外須加上調整各伺服器負荷及維持內容一致的工作。 f. 處理情境模組：此處可提供處理情境 知識的功能，主要是處理搜尋關鍵字、觀看處理情境、觀看整個流程及觀看子流程等四個部份。其中在處理搜尋關鍵字的部份，系統可將員工輸入的關鍵字，經由「Ontology 存取模組」，搜尋「Ontology 知識庫」。此時有兩種情形：（1）當 Ontology 知識庫之相對某概念的葉節點有存在此員工個人的超連結時，會先直接連往「個人知識庫」，那表示有其個人新創或更新的經驗知識。（2）若 Ontology 之葉節點無其個人的超連結時，會直接連往「企業處理規定經驗知識庫」。最後，「日常營運系統」（如信用卡 Call Center 系統）會自動留存一筆記錄於公司資料庫的 Log，而本系統也會透過「輔助資訊保留模組」，自動將為顧客服務中所使用到的知識記錄於「管理輔助資料 庫」。 g. 創造更新知識模組：此模組主要是用 來服務顧客所新創的個人處理知識。使用的時機有兩個，其一是內部員工在服務完顧客時，想新創個人的處理知識；其二是想新創企業的處理規定及經驗所沒有的部份，此兩個使用時機皆都可透過此模組，去創造或更新個人的處理規則與經驗知識。實際的運作方式，如當員工詢問顧客相關問題並加以處理後，「日常營運系統」（如信用卡 Call Center 系統）會自動留存一筆記錄於公司資料庫的 log，而本系統也會判斷是否有未結束的部份(為顧客服務是否有未結束的部份)，如果有，則系統會透過「輔助資訊保留模組」及「儲存知識模組」，將員工為顧客服務中所創造或更新的知識，分別儲存於「管理輔助資料庫」及「個人知識庫」。相反的，如果沒有未結束的部份，系統也會將個人新創或更新的知識透過「儲存知識模組」，儲存於「個人知識庫」中。 h. 訓練模組：此為幫助員工自我訓練。 此「訓練模組」可以區分為兩種使用模式，第一種是有系統引導的「情境模擬」，第二種則是沒有系統引導的「自

(12)

由查詢」。第一種方式是適用於資淺人員或新進人員的訓練。第二種方式是適用於較資深人員或較熟悉系統人員的訓練。系統經由此模組，透過「Ontology 存取模組」搜尋「Ontology 知識庫」、連結「企業處理規定經驗知識庫」，並 將找到的相關的知識回報給內部員工。 i. Data Mining 模組：此為系統利用此一 模組，從「管理輔助資料庫」結合公司資料庫的 log 中，發掘出一些規則知識（如「在某解決某種問題時，常採取的程序」、「常問某類特定問題的顧客特性」等），並將發掘的結果儲存於「發掘出的規則知識庫」中。 j. Ontology 存取模組：此為系統利用此 一模組，來搜取「Ontology 知識庫」，並將搜尋到的知識回傳給「處理情境模組」。另外，也會利用此模組來維護 Ontology。 k. 儲存知識模組：如上所述，系統利用此一模組，將「創造更新知識模組」所創造及更新的知識規則，儲存於「個人知識庫」中。並要求此服務人員加上如 (o)中所述之「處理理由進一步說明」的註解，以利日後參考。 l. 輔助資訊保留模組：系統利用此一模組，將「處理情境模組」、「創造更新知識模組」所搜尋、創造及更新的知識規則，儲存過程及結果於「管理輔助資料庫」，以輔助原日常營運系統之 Log。 m. 更新 Agent：此為系統定時(如每週)自 動觸發的模組。此模組將檢查企業內所有的「個人知識庫」，將創造出的新知識、與更新的知識彙總列出（其間可能個人的知識還會有衝突），並結合經由 Data Mining 模組所「發掘出的規則知識庫」，一起通知知識管理人員（Chief Knowledge Officer，CKO），由其進一步判斷，是否需要更新到「企業處理規定經驗知識庫」中。 n. Ontology 知識庫：此為本系統的核心， 基本上它包含本特定應用的知識領域（如信用卡）中，所有概念（如物件種類、特性、與在物件間的關係）描述，透過它可以讓我們知道知識的結構與各知識概念間的關連。同時，它也包含這個領域內的企業運作模式（Business Model）。圖 3-2 為本應用領域之實體關係圖（Entity-Relationship Diagram）。其更細的觀念可用資料抽象化（Data Abstraction）的觀念中，一般化/特殊化的樹 (Generalization / Specialization Hierarchy) 來表達概念間的分類層級（Type- Subtype）關係；或用聚集化（Aggregation）觀念，來表達概念間的包含層級（Part-of）關係（楊亨利，1997 年）。如圖 3-3 為一棵特殊化的樹，圖 3-4、3-5、3-6 為聚集化的樹。基本上，這可視為 Ontology 「企業處理規定經驗知識庫」的 Meta Data，我們要透過這才知道企業內部存有多少種類的規則與經驗。系統可透過「Ontology 存取模組」去搜尋此一知識庫，並可由此超鏈結到一些服務人員之「個人知識庫」及「企業規則經驗知識庫」中，找到相關的個人知識或企業規則與經驗知識。此一知識庫的資料結構，共包含六個部份，分別是：節點名稱、同義字、相關節點、父節點(Parent)、子節點(Children) 及關鍵字。若為葉節點，則還儲存連至一些服務人員「個人知識庫」之個人的超連結，和連至「企業處理規定經驗知識庫」之超連結。前者其實是提供對「個人知識庫」的 Meta Data 功能。 o. 企業處理規定經驗知識庫：此為儲存整 個公司的企業規則與經驗知識，這塊其實存放著「組織記憶」。此一知識庫分為三部份，分別是企業處理的作法、參考規定及經驗規則。信用卡參考規定，是把參考法條予以編號，當內部員工查詢到相關法條時，予以呈現出來。經驗規則知識庫其實是以資料庫方式來儲存一條規則之 IF 與 Then 的部分 (例如一條企業判斷規則如下：「IF 刷卡次數異於過去刷卡次數 Then 信用卡號碼被盜用」) （由於不作推理，只來展現，如此的結構已適用）。而企業處理的作法知識庫則為其內部累積而來的

(13)

處理的經驗，予以編號，並包含對某一「處理的問題」的 What、How、Who、 Why 四個構面，以及子流程及細流程說明，其資料結構的四個構面說明如下：What 牽涉到資料的欄位（Data）； How 說明相關流程（Process）；Who 是指牽涉到的組織角色（Role）；Why 是指為什麼要這樣做（Reasons）。對於 Sowa 與 Zachman (1992) 之 When 的部分，其實已在前述公司資料庫 Log 的發生日期中表達；而 Where 部分只有在此企業為分散處理或分權式結構才有必要（如有各地的服務人員，其各自負責各地的顧客，此時，其知識可能有因地制宜的必要），本研究的企業為集中處理及集權式結構，因此並未將 Where 的部份納入探討。 p. 管理輔助資料庫：這其實是以知識管理 觀點來輔助原日常營運系統留存於公司資料庫之 Log。此處的資料結構主要包含對某一「處理的問題」的 What、 How、Who、Why 四個構面，與前述「企業處理規定經驗知識庫」裡的企業處理作法的結構相同。 q. 發掘出的規則知識庫：此為儲存某個公 司的透過「Data Mining 模組」，從「管理輔助資料庫」這一堆歷史的處理記錄中，發掘出的規則知識。此一規則結構包含對某一「處理的問題」的 What、 How、Who、Why 四個構面，與前述「企業處理規定經驗知識庫」裡的企業 處理作法的結構相同。 r. 個人知識庫：此為儲存企業內的個人知 識，而且是以經驗知識為主。其資料結構包含對某一「處理的問題」的 What、 How、Who、Why 四個構面，與前述「企業處理規定經驗知識庫」裡的企業處理作法的結構大部份相同，其不同之處是除了四個構面所存放的是只有服務人員所新增的部份之外(並不存放「企業處理規定經驗知識庫」已有的部份，本研究主要的考量是避免重複，且如需要企業已有的部份，可參考到「企業處理規定經驗知識庫」裡相關的欄位去找尋及擷取即可)，還新增了四個表格，分別是：個人對應的自訂流程、個人對應的經驗規則、對公司 How 的修改及個人新增的經驗規則。這四個新增的表格說明如下：「個人對應的自訂流程」主要是儲存了個人新增加的流程編號與其所屬的流程編號及起始子流程編號，本研究是採用員工編號加上流程編號，來擬取代公司處理規定的編號；「個人對應的經驗規則」主要是儲存了個人新增的經驗規則編號，其可以參考到「個人新增經驗規則」的 IF 及 Then 說明；「對公司 How 的修改」主要是儲存了新增子流程與原流程的關係及說明，本研究是針對「一對一取代子流程」、「一對多取代子流程」及「插入子流程」三方面進行探討；「個人新增的經驗規則」主要是儲存了個人新增經驗規則的 IF 及 Then 說明，本研究是允許個人新增自己的經 驗規則，以幫助其累積處理經驗。 個人知識庫是提供每位服務人員的公務知識存放「私空間」，其理由在於體認到企業內每位服務人員其實有自己對公司日常事務創新的處理方式，那可能異於整個組織，組織也鼓勵創新。本系統架構下，將容許其存在。但整個「組織的記憶」是否要隨著一、二人來修改，還需有進一步的確認動作。另一方面，由於這些會 Override 組織記憶。我們也不希望此知識庫太大，或甚至取代整個公司的企業規則與經驗知識。所以，須定時再由更新 Agent 提醒知識管理人員（CKO）檢討是否整個企業處理規定經驗知識庫應予更新，才會讓處理的更有效率與效益。 第二節系統架構之演算流程 一、系統架構的的運作流程本系統架構的主要目的是支援公司內部員工的日常營運作業及留下員工處理作業的作法，以增進公司的知識記憶。本研究的整體演算法流程如圖 3-7 所示，整個流程可以區分為如下三個不同的階段：

(14)

（一）階段 A 運作流程

在本系統架構下運作之整體演算法除了較獨立之 Data Mining 與更新 Agent 外，如圖 3-8 所示。目標在於選擇某種系統應用功能，及按照所選擇的功能執行其所對應的程序，並作為知識呈現的來源。在登錄某個日常營運系統(如 Call Center 系統)時，系統會要求員工輸入其 ID 及密碼，此時系統會判斷使用者資歷，是屬於資淺人員(服務年資未滿三個月者) 或資深人員(服務年資已滿三個月者)。如果是資深人員則此系統功能全部開放使用。相對的，如果是資淺人員，則系統會限制其只能使用某些功能(「選擇訓練方式」的情境模擬、必須觀看「處理情境知識方式」及「處理情境知識方式」的觀看處理情境作法，剩下的其餘功能皆不能使用)。在「選擇系統功能」方面，此系統架構有三種主要的系統功能(處理情境知識方式、選擇訓練方式、創造更新知識)可供選擇，若員工欲觀看知識，可選擇直接輸入情境編號，(1)來先觀看其對應之整個靜態的流程圖第一層的組成，或(2)隨著系統的引導，來看詳細的整個流程、子流程、細流程及其各相關維度，或(3)選擇只看其中某個特定的子流程。若其不知情境編號，可輸入關鍵字，系統將會搜尋 Ontology 樹，與其對話找到適合的情境。其相關的演算法說明如下： Sub A1 主程序( ) /*處理觀看「處理情境知識方式」系統功能的主程序*/ Input 使用者是否觀看處理情境知識 IF 觀看處理情境知識 = No 結束選擇系統功能 Call B1-2 子程序 /* B1-2 子程序：傳入「不觀看處理情境知識」。進入 B1 階段，以處理使用者不觀看處理情境知識的情況*/ End IF Input 處理情境知識方式 /*觀看處理情境知識內容*/ Switch(處理情境知識方式) Case 觀看詳細處理情境作法： Input 選擇觀看的情境編號系統判斷是否有個人的作法 /*系統根據個人知識庫中「個人對應自訂流程」表格的「員工編號」及「對應公司流程」兩個欄位，可查詢「流程編號」欄位，以判斷是否有個人的作法*/ IF 有個人的作法 /*系統選取個人的作法*/ 個人作法的 Flag = true 系統擷取個人知識庫 Else /*系統選取企業的作法*/ 個人作法的 Flag = false 系統擷取企業知識庫 End IF 系統呈現觀看子流程的方式 Input 選擇「循序觀看」或是「中間切入觀看」 Call B1-1 子程序 /* B1-1 子程序：傳入情境編號、個人作法 Flag 及觀看子流程方式。進入 B1 階段，以呈現所欲觀看的情境知識*/ Case 搜尋關鍵字： Input 一個或多個關鍵字 /*多個關鍵字之間的關係為 And*/ 系統擷取使用者輸入的所有關鍵字 /*如「客戶刷卡」、「商店消費刷卡異常」等關鍵字*/ Call S1 子程序 /* S1 子程序：傳入系統擷取的所有關鍵字；傳回葉節點名稱。藉由輸入的關鍵字，搜尋 Ontology 樹，並找到相對應的葉節點*/ 系統擷取葉節點名稱對應的情境編號系統判斷是否有個人的作法 IF 有個人的作法 /*系統選取個人的作法*/ 個人作法的 Flag = true 系統擷取個人知識庫 Else /*系統選取企業的作法*/ 個人作法的 Flag = false 系統擷取企業知識庫 End IF 系統呈現觀看子流程的方式 Input 選擇「循序觀看」或是「中間切入觀看」 Call B1-1 子程序 /* B1-1 子程序：傳入情境編號、個人作法 Flag 及觀看子流程方式。進入 B1 階段，以呈現所欲觀看的情境知識*/ Case 觀看特定子流程： Input 特定子流程編號 Call B1-3 子程序 /* B1-3 子程序：傳入特定子流程編號。進入 B1 階段，以呈現所欲觀看的特定子流程知識*/ Case 觀看整個流程圖： Input 使用者欲觀看的情境編號系統擷取情境編號所對應的流程編號系統呈現對應的整個流程圖 /*根據使用者輸入的流程編號*/ Input 是否進一步觀看整個流程圖的子流程名稱對應表 IF 進一步觀看子流程名稱對應表 = Yes 系統呈現整個流程圖的子流程名稱對應表 End IF 指定回到「使用者判斷是否觀看處理情境知識」 End Switch End Sub Sub A2 主程序( ) /*處理觀看「選擇訓練方式」系統功能的主程序*/ 系統呈現訓練方式的子功能 Input 選擇訓練方式 Switch(選擇訓練方式) Case 情境模擬： Input 使用者欲觀看的情境課程系統引導觀看情境課程 /*根據使用者選擇的情境課程(如申請信用卡業務處理、消費金額與實際不符處理、客戶轉帳處理等)，以播放影音檔的方式，由系統引導整個處理過程，期間不需要使用者再輸入任何資訊*/ Case 自由查詢： /*系統不引導使用者觀看整個處理過程，期間需要使用者輸入資訊*/ Call A1 /*處理觀看「處理情境知識方式」的程序，有觀看詳細處理情境作法、搜尋關鍵字、觀看特定子流程、觀看整個流程圖等四種 */ End Switch End Sub Sub A3 主程序( ) /*處理「創造更新知識」系統功能的主程序*/ Input 選擇新創知識所對應的情境編號系統擷取情境編號所對應的流程編號系統呈現子流程表單 /*對企業 How 修改的表單*/ Input 欲創造更新的子流程 /*包括子流程編號、與原流程關係及說明*/ 系統呈現 How 表單 /* How 之流程說明、自訂子流程的組成*/ Input 欲創造更新的子流程結構更新、子流程的組成 /*包括新增子流程的說明、與後續子流程的關係、細流程編號、說明及順序*/ 系統呈現 What 表單 Input 欲創造更新細流程所牽涉到的資料欄位 /* 包括 Table 名稱及欄位名稱 */ 系統呈現 Who 表單 Input 欲創造更新細流程所牽涉到的組織角色 /*包括組織及人員*/ 系統呈現 Why 表單 Input 欲創造更新細流程的處理理由 /*包括參考法條或經驗規則編號、處理理由分類碼、處理理由進一步說明*/ 系統呈現個人新增經驗規則表單 Input 欲創造更新細流程所參考的個人經驗規則 /*包括 IF 及 Then*/ End Sub

(15)

Sub S1 子程序(系統擷取的所有關鍵字) /* S1 子程序：傳入系統擷取的所有關鍵字；傳回葉節點名稱。藉由輸入的關鍵字，搜尋 Ontology 樹，並找到相對應的葉節點*/ Call S1a 子程序 /*S1a 子程序：傳入系統擷取的所有關鍵字；傳回所有節點及其權重值。主要是計算所有節點的權重值*/ 系統排序節點的權重值系統呈現權重值最大的葉節點 Input 使用者判斷是否滿意找到的葉節點 IF 使用者判斷未找到葉節點 /*使用者不滿意找到的葉節點*/ 使用者不滿意的 Flag = true Call S1b 子程序 /*S1b 子程序：傳入所有節點及其權重值,使用者不滿意的 Flag；傳回葉節點名稱。主要是讓使用者選擇滿意的葉節點*/ End IF 系統傳回 A1，找到的葉節點名稱，且結束 S1 End Sub Sub S1a 子程序(系統擷取的所有關鍵字) /*S1a 子程序：傳入系統擷取的所有關鍵字；傳回所有節點及其權重值。主要是計算所有節點的權重值*/ For 系統擷取的每一個關鍵字系統搜尋節點的關鍵字 /*根據關鍵字，由上往下搜尋*/ IF 找到節點的關鍵字找到節點的權重值加 1 系統檢查是否存在下一層的節點 While (存在下一層的節點) 下一層所有子節點的權重值加 1 Loop Else /*未找到相對應的節點*/ 系統輸出找不到相對應的節點關鍵字 End IF Next 系統傳回 S1，所有節點及其權重值，且結束 S1a End Sub Sub S1b 子程序(所有節點及其權重值, 使用者不滿意的 Flag) /*S1b 子程序：傳入所有節點及其權重值,使用者不滿意的 Flag；傳回葉節點名稱。主要是讓使用者選擇滿意的葉節點*/ Do 系統展示葉節點的相關葉節點及建議搜尋的優先順序 /*展示的優先順序是根據葉節點的權重值*/ Input 使用者選擇葉節點 Input 使用者判斷是否滿意找到的葉節點 IF 使用者滿意找到的葉節點系統傳回 S1，找到的葉節點名稱，且結束 S1b End IF 系統找尋使用者所選擇葉節點的相關葉節點 /*相關葉節點是指葉節點的兄弟節點(有共同的父節點或相同的祖先節點)*/ While (使用者不滿意的 Flag = true)

End Sub S1 子程序的搜尋過程說明如下：(說明例子一，如下圖) (a) 系統擷取使用者輸入的關鍵字，如本例中的（C,G,H）。 (b) 系統根據關鍵字(如下圖中的 A,B,C,D 等皆是關鍵字)，由上往下搜尋節點。搜尋關鍵字，並計算節點的權重值，直到搜尋完關鍵字，接著系統排序節點 (小括弧為其權重值)並呈現權重值最大的葉節點，接著系統要求使用者輸入是否滿意找到的葉節點，如果使用者輸入「是」，就傳回葉節點的名稱，並結束 S1 的搜尋。如本例中，系統會呈現 (G,H)的葉節點名稱(如「多出一筆國外交易」、「消費金額與實際不符」等)，因為其權重值最大，接著使用者輸入滿意找到的葉節點，所以系統傳回找到的葉節點名稱，並結束此一搜尋程序。 A, B(0) C, D, E(1) F(0) G, H(3) I, M(1) J(1) K, L(1) S1 子程序的搜尋過程，例子二的說明如下(如下圖)： (a) 系統擷取使用者輸入的關鍵字，如本例子二的（A,C,D,G,I,H,K） (b) 系統根據關鍵字(如下圖中的 A,B,C,D 等皆是關鍵字)，由上往下搜尋節點。搜尋關鍵字，並計算節點的權重值，直到搜尋完關鍵字，接著系統排序節點 (小括弧為其權重值)並呈現權重值最大的葉節點，接著系統要求使用者輸入是否滿意找到的葉節點，如果使用者輸入「是」，就傳回葉節點的名稱，並結束 S1 的搜尋，否則就進入下一搜尋程序。如本例中，系統會呈現(K,L)的葉節點名稱(如「多出一筆國外交易」、「消費金額與實際不符」等)，因為其權重值最大，接著使用者輸入「不滿意」找到的葉節點，所以系統就進入下一搜尋程序。 (c) 系統會展示葉節點的相關葉節點及建議搜尋的優先順序(是根據葉節點的權重值)，讓使用者挑選，直到使用者挑選到滿意的葉節點，就傳回葉節點的名稱，並結束 S1 的搜尋。如本例中，系統會呈現(J) 的葉節點名稱，接著使用

(16)

者輸入「不滿意」找到的葉節點，系統接著呈現(J)葉節點的相關葉節點(I) Æ (R, S)( 因為有兩個以上的相關葉節點，所以系統會根據其權重值，排其優先順序，因而讓使用者可以較先挑選相關性較高的葉節點)，接著使用者挑選 (I) 這個葉節點，並輸入「滿意」找到的葉節點，所以系統就傳回找到的葉節點名稱(I)，並結束此一搜尋程序。 A, B(1) C, D, E(3) F(0) G, H(5) M(3) J(5) K, L(6) P(0) R, S(3) T(0) U(0) I(4) （二）階段 B 運作流程階段 B 的運作流程，目標在於呈現某種系統應用功能的知識，並作為知識儲存的來源。在圖 3-7 中，共分成三個部份，分別是 B1、B2 及 B3 程序。B1 是呈現「處理情境知識方式」的結果；B2 是呈現「選擇訓練方式」的結果；B3 是呈現「創造更新知識」的結果。觀看處理流程可分成循序或中間切入觀看處理情境之流程內容、或觀看某特定子流程的方式。觀看處理流程時，由於流程可能有分歧，在呈現第一層的所有子流程時，系統會要求使用者邊看邊決定所有子流程的執行順序。在這期間也可點選想觀看的子流程之下的細流程 (第二層)；或進一步點選想觀看細流程的 What、Who、Why 部份(第三層)。其相關的演算法說明如下： Sub B1-1 子程序(情境編號，個人作法 Flag，觀看子流程方式) /* B1-1 子程序：傳入情境編號、個人作法 Flag 及觀看子流程方式。呈現所欲觀看的情境知識*/ 系統擷取情境編號所對應的流程編號系統擷取流程編號的起始子流程編號系統記錄流程編號及子流程編號到 How 臨時表格中 Call B1a 子程序 /* B1a 子程序：傳入流程編號；傳回子流程結構(為循序結構或分歧結構)*/ Switch(觀看子流程的方式) Case 循序觀看：系統呈現第一個子流程名稱，並且 Call B1c 子程序 /* B1c 子程序：傳入個人作法 Flag,流程編號及子流程編號儲；無傳回值。儲存於 How 之流程說明、子流程的組成、What、Who、Why 等臨時表格*/ Case 中間切入觀看： IF 存在循序的子流程的 Flag = true Input 使用者欲觀看的子流程編號系統呈現使用者欲觀看的子流程名稱，且把子流程編號與上一個子流程編號的判斷關係（－）記錄到 How 之流程說明表格中的「判斷」欄位，並且 Call B1c 子程序系統自動擷取流程編號所組成的第一個子流程編號至使用者欲觀看的子流程編號之間的每一個子流程編號 Else /*存在分歧的子流程結構*/ 系統呈現第一個分歧的子流程名稱，且把子流程編號與上一個子流程編號的判斷關係（－）記錄到 How 之流程說明表格中的「判斷」欄位，並且 Call B1c 子程序 /*判斷關係（－）：是代表為循序關係*/ 系統自動擷取流程編號所組成的第一個子流程編號至第一個分歧子流程編號之間的每一個子流程編號 End IF IF 系統擷取的子流程編號是起始子流程編號系統把起始子流程編號記錄到 How 之流程說明表格中的「子流程編號」欄位 End IF For 除起始子流程編號之外，系統擷取的每一個子流程編號系統把子流程編號與上一個子流程編號的判斷關係（－）記錄到 How 之流程說明表格中的「判斷」欄位，並把此一子流程編號記錄到 How 之流程說明表格中的「後續子流程」欄位系統把此一子流程編號再寫入一筆新的記錄，並記錄到 How 之流程說明表格中的「子流程編號」欄位 Next End Switch

While (存在循序的子流程的 Flag = true And 子流程不是 END) Input 按 Next 以觀看下一個子流程系統呈現所選擇的子流程名稱，且把子流程編號與上一個子流程編號的判斷關係（－）記錄到 How 之流程說明表格中的「判斷」欄位，並且 Call B1c 子程序 Input 使用者判斷是否繼續觀看細流程 IF 使用者要觀看細流程 Call B1b 子程序 /* B1b 子程序：傳入個人作法 Flag 及子流程編號；無傳回值。主要是呈現細流程編號、細流程說明及其對應的 What、Who、Why 等表格的相關欄位 */ End IF Loop

While (存在分歧的子流程的 Flag = true And 子流程不是 END) 系統判斷與下一個子流程的關係判斷

/*其關係有兩組，一組是 Yes or No ，另一組是 Next*/ Switch(關係判斷)

Case Yes or No：

Input 與下一個子流程的關係判斷 Switch(與下一個子流程的關係判斷) Case Yes：系統呈現所選擇的 Yes 方向子流程名稱，且把子流程編號與上一個子流程編號的判斷關係（Y）記錄到 How 之流程說明表格中的「判斷」欄位，並且 Call B1c 子程序 /*判斷關係（Y）：是代表判斷關係為 Yes*/ Input 使用者判斷是否繼續處理細流程 IF 使用者要觀看細流程 Call B1b 子程序 End IF Case No：系統呈現所選擇的 No 方向子流程名稱，且把子流程編號與上一個子流程編號的判斷關係（N）記錄到 How 之流程說明表格中的「判斷」欄位，並且 Call B1c 子程序 /*判斷關係（N）：是代表判斷關係為 No*/ Input 使用者判斷是否繼續觀看細流程 IF 使用者要觀看細流程 Call B1b 子程序 End IF End Switch

(17)

Case Next： Input 按 Next 以觀看下一個子流程系統呈現所選擇的子流程名稱，且把子流程編號與上一個子流程編號的判斷關係（－）記錄到 How 之流程說明表格中的「判斷」欄位，並且 Call B1c 子程序 Input 使用者判斷是否繼續觀看細流程 IF 使用者要觀看細流程 Call B1b 子程序 End IF End Switch Loop IF 個人作法的 Flag = true 系統選取所牽涉的經驗，到個人知識庫中的「個人新增的經驗規則」表格抓取，並儲存在「經驗規則」的臨時表格中 End IF 系統選取所牽涉的法條及經驗，到企業知識庫中的「信用卡參考規定」及「經驗規則」表格抓取，並儲存在「信用卡參考規定」及「經驗規則」的臨時表格中 End Sub Sub B1a 子程序（流程編號） /* B1a 子程序：傳入流程編號；傳回子流程結構，為循序結構或分歧結構*/ 系統判斷流程編號所對應的子流程結構 Switch(子流程結構) Case 循序結構：

回傳「存在循序的子流程」的 Flag = true /*結束 B1a 子程序*/ Case 分歧結構：

回傳「存在分歧的子流程」的 Flag = true /*結束 B1a 子程序*/ End Switch End Sub Sub B1b 子程序（個人作法 Flag,子流程編號） /* B1b 子程序：傳入個人作法 Flag 及子流程編號；無傳回值。主要是呈現細流程編號、細流程說明及其對應的 What、Who、Why 等表格的相關欄位 */ Switch(個人作法 Flag) Case true： /* 呈現個人作法*/ 系統根據子流程編號到個人知識庫中「自訂子流程組成」表格，抓取其所對應的細流程編號、細流程說明 While(存在細流程編號) 系統呈現子流程編號對應的所有細流程編號及其說明 Input 使用者點選所欲觀看的細流程編號系統呈現使用者點選的細流程編號及其說明 Input 使用者判斷是否觀看細流程編號所對應的 What、Who、Why IF 使用者要觀看 What、Who、Why 系統根據細流程編號到個人知識庫中 What、Who、Why 等表格，抓取其所對應的 What(Table 名稱、欄位名稱)、Who(組織、人員)、 Why(參考法條或經驗規則編號、處理理由分類碼、處理理由進一步說明)等相關欄位系統呈現細流程編號所對應的 What、Who、Why 等表格的相關欄位 End IF Input 使用者判斷是否繼續觀看其他細流程編號及其說明 IF 使用者判斷不要繼續觀看其他細流程編號及其說明結束 B1b 子程序 End IF Loop Case false： /*呈現企業作法*/ 系統根據子流程編號到企業知識庫中「子流程組成」表格，抓取其所對應的細流程編號、細流程說明 While(存在細流程編號) 系統呈現子流程編號對應的所有細流程編號及其說明 Input 使用者點選所欲觀看的細流程編號系統呈現使用者點選的細流程編號及其說明 Input 使用者判斷是否觀看細流程編號所對應的 What、Who、Why IF 使用者要觀看 What、Who、Why 系統根據細流程編號到企業知識庫中 What、Who、Why 等表格，抓取其所對應的 What(Table 名稱、欄位名稱)、Who(組織、人員)、 Why(參考法條或經驗規則編號、處理理由分類碼、處理理由進一步說明)等相關欄位系統呈現細流程編號所對應的 What、Who、Why 等表格的相關欄位 End IF Input 使用者判斷是否繼續觀看其他細流程編號及其說明 IF 使用者判斷不要繼續觀看其他細流程編號及其說明結束 B1b 子程序 End IF Loop End Switch End Sub Sub B1c 子程序（個人作法 Flag,流程編號,子流程編號） /* B1c 子程序：傳入個人作法 Flag,流程編號及子流程編號儲；無傳回值。儲存於 How 之流程說明、子流程的組成、What、Who、Why 等臨時表格*/ IF 是起始子流程編號系統把起始子流程編號記錄到 How 之流程說明表格中的「子流程編號」欄位 Else /*不是起始子流程編號*/ 系統把子流程編號記錄到 How 之流程說明表格中的「後續子流程」欄位，並把此一子流程編號再寫入一筆新的記錄，並記錄到 How 之流程說明表格中的「子流程編號」欄位 End IF Switch(個人作法 Flag) Case true： /* 儲存個人作法*/ 系統根據子流程編號到個人知識庫中「自訂子流程組成」表格，抓取其所對應的細流程編號、細流程說明及順序號系統儲存子流程組成的臨時表格系統根據細流程編號到個人知識庫中 What、Who、Why 等表格，抓取其所對應的 What(Table 名稱、欄位名稱)、Who(組織、人員)、Why(參考法條或經驗規則編號、處理理由分類碼、處理理由進一步說明) 等相關欄位系統儲存 What、Who、Why 等臨時表格 Case false： /* 儲存企業作法*/ 系統根據子流程編號到企業知識庫中「子流程組成」表格，抓取其所對應的細流程編號、細流程說明及順序號系統儲存子流程組成的臨時表格系統根據細流程編號到企業知識庫中 What、Who、Why 等表格，抓取其所對應的 What(Table 名稱、欄位名稱)、Who(組織、人員)、Why(參考法條或經驗規則編號、處理理由分類碼、處理理由進一步說明) 等相關欄位系統儲存 What、Who、Why 等臨時表格 End Switch End Sub Sub B1-2 子程序(不觀看處理情境知識) /* B1-2 子程序：傳入「不觀看處理情境知識」。主要是處理使用者不觀看處理情境知識的情況*/ Input 選擇處理情境編號系統擷取情境編號所對應的流程編號系統擷取流程編號的起始子流程編號系統記錄流程編號及子流程編號到 How 臨時表格中系統判斷是否有個人的作法 IF 有個人的作法 /*系統選取個人的作法*/ 個人作法的 Flag = true End IF 系統判斷流程編號所對應的子流程結構 Switch(子流程結構) Case 循序結構：系統自動擷取流程編號所組成的每一個子流程編號 Case 分歧結構：存在分歧的子流程的 Flag = true 系統自動擷取流程編號所組成的第一個子流程編號至第一個分歧子流程編號之間的每一個子流程編號 End Switch IF 系統擷取的子流程編號是起始子流程編號系統把起始子流程編號記錄到 How 之流程說明表格中的「子流程編號」欄位 End IF For 除起始子流程編號之外，系統擷取的每一個子流程編號系統把子流程編號與上一個子流程編號的判斷關係（－）記錄到 How 之流程說明表格中的「判斷」欄位，並把此一子流程編號記錄到 How 之流程說明表格中的「後續子流程」欄位系統把此一子流程編號再寫入一筆新的記錄，並記錄到 How 之流程說明表格中的「子流程編號」欄位 Next

(18)

While (存在分歧的子流程的 Flag = true And 子流程不是 END) 系統判斷與下一個子流程的關係判斷

/*其關係有兩組，一組是 Yes or No ，另一組是 Next*/ Switch(關係判斷)

Case Yes or No：

Input 與下一個子流程的關係判斷 Switch(與下一個子流程的關係判斷) Case Yes：系統呈現所選擇的 Yes 方向子流程名稱，且把子流程編號與上一個子流程編號的判斷關係（Y）記錄到 How 之流程說明表格中的「判斷」欄位，並且 Call B1c 子程序 /*判斷關係（Y）：是代表判斷關係為 Yes*/ Case No：系統呈現所選擇的 No 方向子流程名稱，且把子流程編號與上一個子流程編號的判斷關係（N）記錄到 How 之流程說明表格中的「判斷」欄位，並且 Call B1c 子程序 /*判斷關係（N）：是代表判斷關係為 No*/ End Switch Case Next： Input 按 Next 以觀看下一個子流程系統呈現所選擇的子流程名稱，且把子流程編號與上一個子流程編號的判斷關係（－）記錄到 How 之流程說明表格中的「判斷」欄位，並且 Call B1c 子程序 End Switch Loop IF 個人作法的 Flag = true 系統選取所牽涉的經驗，到個人知識庫中的「個人新增的經驗規則」表格抓取，並儲存在「經驗規則」的臨時表格中 End IF 系統選取所牽涉的法條及經驗，到企業知識庫中的「信用卡參考規定」及「經驗規則」表格抓取，並儲存在「信用卡參考規定」及「經驗規則」的臨時表格中 End Sub （三）階段 C 運作流程階段 C 會儲存某營運 Session 之處理作法。不管其在階段 B 是否曾觀看過處理情境知識，均需將其對顧客之服務作法記錄下來。若其在階段 B 是由系統引導或輸入關鍵字所搜尋到的情境，系統假設其所觀看的即是其實際的作法，系統將自動記錄於管理輔助資料庫。若在階段 B 未曾觀看過，或只直接看某個子流程，系統需判斷其所處理的情境所對應的流程組成是否有分歧，若有，則員工應演練一次告知系統各分叉點之選擇。若員工有新創作法，應先去創造知識。對更新創造之知識，系統將其儲存在個人知識庫。若純為訓練，則不儲存。階段 C 的運作流程，可分為 C1 階段 (如圖 3-11)及 C2 階段。C1 階段目標在於儲存員工實際作法的知識，並鼓勵員工能多新創個人知識(B1 階段)。進入此階段系統會要求使用者判斷，是否要更新公司知識(新創個人知識)，如果使用者選擇不要更新公司知識，系統則將員工的實際處理作法(管理輔助資訊)，儲存在「管理輔助資料庫」；否則(使用者要更新公司知識) 系統會先儲存員工的實際作法於「管理輔助資料庫」中，並且會進入到創造更新知識的系統功能中，去更新公司知識(新創個人的處理作法)。這樣設計的目的，是要鼓勵員工能多新創個人知識，並期望能蓄積有效益的組織記憶。 C2 階段目標在於儲存更新公司知識的作法 ( 個人新創的處理作法 )(B3 階段)，進入此階段，系統會將員工更新或新創的個人處理作法(個人知識)，儲存在「個人知識庫」中。其相關的演算法說明如下： Sub C1 階段主程序( ) 使用者判斷是否要更新公司知識 Switch(是否更新公司知識) Case 要更新公司知識：儲存管理輔助資訊，並進入創造更新知識系統功能(呼叫 A3 主程序) Case 不要更新公司知識：儲存管理輔助資訊 End Switch End Sub 第三節系統架構之資料結構說明 在本架構下的資料結構中，「企業處理規定經驗知識庫」、「Ontology 知識庫」都是屬於公司制式的部份，不能加以修改；「個人知識庫」對應企業知識庫則是屬於個人的部份，可由員工去創新或更改知識。「公司資料庫的 Log 檔」是公司日常營運系統原本就有的部份；「管理輔助資料庫」則是輔助性 log，將員工的實際處理作法，全都記錄下來。在此架構下的資料結構包含如下：一、企業處理規定經驗知識庫 1.企業處理的作法此處假設以服務人員「查詢消費金額，發現帳單總額不符」為例，來說明「企業處理規定經驗知識庫」裡企業處理作法的資料結構，如下所述。在公司資料庫「交易明細」的 Table 中，可能尚有包括其他欄位，如：日期、交易品項、交易金額和帳單總額等。但此處處理的 What 只牽涉到帳單總額。How 是其如何處理的，在螢幕上展現的是一文字串表達，但其實它進一步，可會細分成為一些個別的子流程及細流程來儲存。此處的流程編號是假設指到企業內部的一個處理規定。Who 是指牽