搜索
知識管理系統生命週期Chapter3Chapter3：知識管理生命週期3-2OVERVIEW建立知識管理系統的挑戰傳統與知識管理系統生命週期知識管理系統生命週期知識管理的涵義Chapter3：知識管理生命週期3-3建立知識管理系統的挑戰文化—群聚人們分享知識知識評估—評估知識對公司的價值知識處理—如何達成決策的文件化知識執行—以處理最後部署的策略組織與整合知識Chapter3：知識管理生命週期3-4傳統與知識管理系統生命週期差異處1/2主要差異：系統分析者處理從使用者取得資料與資訊。對於分析者系統主要的介面，是已經知道問題但不知道解決方法的使用者。傳統系統開發主要是連續的；是增值且互動的。在傳統資訊系統的開發中，測試是發生在系統已經建立後的生命週期尾端。在知識管理系統生命週期(KMSLC)，知識開發者從週期的一開始測試(核對與確認)此演進系統。Chapter3：知識管理生命週期3-5傳統與知識管理系統生命週期差異處2/2系統開發與系統維護的規則對於傳統資訊系統比起知識管理系統生命週期是更加廣泛。傳統系統生命週期是以過程為主且為文件化導向，強調資料流及成果系統。知識管理系統生命週期是結果導向。強調的是「慢慢開始並持續成長」的漸進過程。傳統系統開發不支援像是快速雛型開發法的工具，因為其是按照一連串的步驟。Chapter3：知識管理生命週期3-6傳統VS知識管理系統Chapter3：知識管理生命週期3-7快速雛型化流程Chapter3：知識管理生命週期3-8傳統與知識管理系統生命週期相似處主要相似處：兩者均是因為問題而開始，也因為解決方案而結束。在確定策略規劃後，傳統的系統生命週期初期是先蒐集資訊以確定瞭解問題及使用者的需求。知識管理系統的核對及確認類似傳統系統的測試。無論是知識開發者或是系統分析者都需要選擇適當工具來設計其系統。Chapter3：知識管理生命週期3-9使用者VS知識工作者Chapter3：知識管理生命週期3-10知識管理系統開發生命週期評估現有基礎建設知識管理團隊的形成知識擷取設計知識管理藍圖(總圖計畫)測試知識管理系統導入知識管理系統管理變革與獎勵結構後系統評估Chapter3：知識管理生命週期3-11評估現有基礎建楚系統判斷：歷經專家退休、調單位與離職後，目前的知識正確否？知識管理系統需要放在許多不同的地點嗎？是否找得到專家且願意協助建立知識管理系統？問題的疑點需要長久的經驗和認知的推論來解決嗎？Chapter3：知識管理生命週期3-12系統判斷(續)當進行知識擷取時，專家能清楚說出將如何解決問題嗎？知識擷取的重要性為何？應用系統的重要性必須與公司的生存及生產力的重要性一起結合。所有的任務都沒有規則可尋嗎？公司裡有重要引導者嗎？知識管理系統的成功需要整個組織的支持。Chapter3：知識管理生命週期3-13圖3.4在問題解決上計算與判斷觀點Chapter3：知識管理生命週期3-14範疇要素就規範範疇的因素而言，必須注意以下的要點：公司現有的技術準備就緒。這包括企業內部網路、區域網路、企業外部網路(公司延伸的網路系統以連接供應商、顧客及銷售員)，以及決策支援工具和其他資訊科技工具。確認落差及需要改善現有科技的部門，以觀察此科技要如何符合計畫中知識管理系統的技術需求。全面性檢視並瞭解知識管理系統工具及構成要素的好處和限制，這會成為可行性研究的一部分。Chapter3：知識管理生命週期3-15可行性問題可行性研究方向的問題如下：計畫可否執行？是否能在一個合理的時間內完成？可否負擔？系統潛在的好處是否囊括開發成本？是否適當？究竟廠商能期待可以從中獲得什麼？是否實用？系統多久要維護一次且花費的成本為何？Chapter3：知識管理生命週期3-16可行性問題(續)可行性的領域：經濟一般為人所知的就是成本/效益分析藉由公司資訊科技的基礎建設之架構評估硬體與支援性軟體，可以決定技術上的可行性。行為的可行性包括訓練管理階層及員工使用知識管理系統。Chapter3：知識管理生命週期3-17可行性問題(續)進行可行性研究的傳統方式：成立知識管理團隊準備主計劃針對建議的知識管理的成本/績效評估量化系統標準與成本取得整個過程裡使用者的支持Chapter3：知識管理生命週期3-18策略規劃的角色沒有策略規劃就投入，風險性很高。以下方面值得思考：願景。你的企業想要達成什麼？將如何實行？知識管理系統將如何實現這個目標？你將如何衡量成功與否？資源。你的企業能負擔多少支出來建立適合的知識管理系統？有多少能力可供利用而且保證你的願景可以實現？文化。你的企業願意配合，以努力協調與支持知識分享的新方式嗎？誰將擁有知識管理系統內容和使用者回應的最終控制權？Chapter3：知識管理生命週期3-19與知識管理相符的經營策略Chapter3：知識管理生命週期3-20知識管理團隊的形成確認關鍵單位、部門、子公司或是分公司在未來知識管理系統的主要負責人。團隊的成功需要依賴：團隊成員的才能團隊的規模專案的複雜度領導與團隊動機承諾比實際可以達成的多Chapter3：知識管理生命週期3-21知識擷取外顯知識從許多媒介取得並儲存。內隱知識從利用工具與方法的公司專家擷取。知識開發者從專家擷取知識以建立知識庫。知識擷取與一專長常透過整過團對執行而非個人。Chapter3：知識管理生命週期3-22團隊的知識擷取的移轉Chapter3：知識管理生命週期3-23選擇專家知識庫應該呈現專業知識而非專家知識開發者面臨的問題：如何知道所謂的專家事實上真的是專家？這個專家會跟著這個專案直到結束嗎？當專家對系統開發失去興趣、決定離開或只是不再有專家的時候，有什麼備案？知識開發者如何知道什麼是或什麼不是專家的專業知識領域？Chapter3：知識管理生命週期3-24知識開發者的角色系統建築師具備極好的溝通技巧、知識擷取工具技巧、技術的熟悉度、模糊性的接受度，以及與包括專家、概念思想家等專業人士一起工作的能力，另具有在團隊裡可以驅使大家一起工作的人格特質。與公司的支持者密切聯繫。與高階管理階層關係密切。Chapter3：知識管理生命週期3-25知識開發者的核心角色Chapter3：知識管理生命週期3-26知識管理藍圖的設計知識管理藍圖(用來作為知識管理系統的設計)出幾個重要問題。其中之一是用來創造下一步要實際一起放置的知識管理系統。著重於現有公司內資訊科技基礎的相互操作性與可衡量性。以心目中已知的淨利來決定規劃中的知識管理系統範疇。決定所需的系統元件，如使用者介面的選擇、知識目錄及資料探勘工具。Chapter3：知識管理生命週期3-27知識管理藍圖的設計（續）開發知識管理架構的關鍵層級已符合公司的需求。如同圖3.8所示，主要的關鍵層級如下：使用者介面是讓使用者瞭解及操作知識庫及其他的儲存槽。認證/安全性層級監測具有安全性目的傳送的要求。協同性代理人及過濾是設計用來提供接近個人化的知識呈現，或是使資訊符合使用者的需求。應用層是用來與實際應用時溝通使用的。傳輸網路層是知識管理網路系統最重要的部分。實體層是訊息從源頭傳送到終點的最底層。知識庫(repository)是存有外顯及內隱知識的硬碟或是儲存裝置，且其間存有脈絡可循的規則。Chapter3：知識管理生命週期3-28圖3.8KM系統架構Chapter3：知識管理生命週期3-29知識管理系統的測試核對程序：確定系統是正確的確認程序：確認系統是正確的系統知識管理系統的確認並不是安全無比的Chapter3：知識管理生命週期3-30導入知識管理系統轉換新知識管理系統到實際操作這個階段包括資料或是檔案的轉換這個階段包含使用者訓練品質確認是主要的，其中要檢查以下問題：推理錯誤模擬兩可不完整錯誤的呈現(正面錯誤與負面錯誤)Chapter3：知識管理生命週期3-31變革的抗拒專家。一般員工（使用者）。麻煩製造者。心胸狹窄的「超級明星」。Chapter3：知識管理生命週期3-32抗拒的反應抗拒。逃避。侵略。Chapter3：知識管理生命週期3-33後導入階段的問題知識管理系統如何改變決策的精確度及時效性？新系統是否已經導致組織的變革？這些變革的建設性程度為何？新知識管理系統如何影響最終使用者的態度？需以什麼方式？值得嗎？新的知識管理系統如何影響企業經營的成本？其重要性如何？新系統以什麼方式影響在組織裡最終使用者之間的關係？源自於新系統的解決方案是否衡量了投資成本？