2009年4月1日 星期三

案例三專家1:周龍鴻

形成分享的習慣

「在一股導入知識管理的熱潮下,企業也漸漸意識到,導入知識管理只是一項暫時性的專案。終究,企業得形成員工日常的分享習慣,才能解決最根本的知識議題。」

這個案例所面臨最根本的問題是,知識管理專案尚未完成便失去執行的焦點。事實上,這家個案公司只作了知識管理專案中的變革管理。儘管個案公司成功地導入「探索者」這套知識分享系統,順利地建立分享的文化,公司也盡全力地改善知識內容,並於每週固定舉辦知識分享會議。在一般人眼中看似非常成功的案例,卻不知背後工程師竟會有如此負面的評價,其實我並不感到十分地意外。以我個人在日月光推動知識管理的實務經驗來看,儘管個案公司這些變革的努力相當成功,也普遍獲得工程師的讚許與認同,但這都僅是知識管理專案中的冰山一角,
嚴格說起來,半導體器材公司的知識管理專案只完成三分之一。

讓我從目前所提供的案例,來檢視知識管理部門對「該如何繼續執行知識管理專案?」的爭議。我認為永梅希望加強組織變革、龍嘯天建議繼續強化系統的功能,以及漢斯希望用虛擬社群的方式,進行工程師內隱知識的分享,這三大方向都對,但都尚不足以解決工程師對知識分
享系統的不滿。真正核心的問題是,要將知識管理的概念融入組織的新管理制度。同時,他們也必須結合工程師每日實際的作業流程,才能解決工程師在實務上所碰觸的棘手問題。

因此,我才會說,這個案例中知識管理工作只完成三分之一。知識管理專案要成功必須包含知識管理模式(Knowledge Management Model)、組織管理模式(Management Model)與企業流程模式(Process Model),知識管理才會完整、才算成功。業界許多公司投入大量的資源進行e 化、導入知識分享系統。但嚴格說起來,這只能算是建立知識管理模式。若這些努力未能結合組織管理模式與企業流程模式,儘管這些專案身著美麗的糖衣,終究得步上失敗一途,此章便是一個出師未捷身先死的實際案例。

以我的經驗為例。當時日月光集團正處在變革中,我便順勢把知識管理的活動融入新的組織管理制度中。趁著原本三家企業(日月光、福雷、日月宏)具有相似功能的部門進行整合之際,於人員磨合期便將知識管理的觀念帶入其中。再來,就是當三家企業於2003 年開始推動「TS16949」系統(一套企業作業流程系統),和新部門成立的契機,將知識管理落實於組織的管理制度之中,讓總體組織體質提升,更重要的是,可以加速知識管理的推動並展現其成效。

以下是我的看法與建議。誠如我之前所言,知識管理必須整合知識管理、組織管理與企業流程等三大模式。在日月光我們關心的是:工程師如何藉助BKM (Best Known Method ,最佳實作方法)活動累積我們的核心能力,即知識管理模式?這些BKM 又如何與TS16949 流程串聯,即流程模式?又該如何將這些BKM 與流程納入平日管理的事務當中,即管理模式?

以下是我對這三大模式的說明與看法:
知識管理模式。這是一般企業導入知識管理所最關注的模式,也是最直接與知識產生關聯的模式。許多企業認為導入知識管理系統就是將隱性知識編碼,建立知識庫,以有效的分享外顯知識。或者,企業可以利用知識社群,建立人際網絡,以分享彼此的內隱知識。因此,組織的變革管理顯得格外重要,這包括塑造分享的文化、資訊科技的運用,以及激勵員工樂意分享他們的核心知識等。事實上,以本案為例,永梅、龍嘯天或漢斯的建議都只是強化知識管理模式而已,並不能真正解決工程師所面臨的實際問題。

組織管理模式。成功的知識管理要結合組織日常管理,這包括了員工績效考核與人才培訓。如此一來,知識管理與組織管理兩個模式才會形成所謂的「水幫魚、魚幫水」的綜效。將個人的升遷與知識管理活動連結起來,員工也才會更積極地奉獻出知識,願意花心思去吸收這些內
隱及外顯的知識。

企業流程模式。最後該公司還需將知識管理與流程管理串起來,才能將知識管理融入工程師的實務作業中,而漸漸成為工程師的日常習慣,達到「讓工程師自然地分享知識,卻不知他們正在分享知識」的境界。一方面,工程師依照企業流程,依規範主動執行知識管理的相關活動;另一方面,工程師也可以在組織管理模式的相互影響下,很自然地分享知識。

完善的知識管理必須整合知識管理、組織管理與企業流程三大模式。在知識管理的熱潮下,企業也需意識到,導入知識管理只是暫時性的。終究,企業得讓員工養成分享的習慣,才是解決最根本的知識議題。

2 意見:

Jamey aung 提到...

周龍鴻先生所提到的組織管理模式,就是提供誘因讓工程師分享知識,方法包括員工績效考核與人才培訓。不過此個案中已提到,工程師每發表一件「最佳實務」就能獲得300~500美元的獎金。所以不能說只完成了三分之一。

另外,現場工程師不是不想分享知識,只是其認定結果(知識或最佳實務)對其他人沒有用,所以才會產生抗拒。

相較於設備工程師,現場工程師所面對的環境是動態的、流程間是交互影響的,因此對知識的認定是不能與設備工程師相提並論。

對現場工程師而言,最重要的是如何解決問題,而問題牽涉到不同的製程,因此他需要找到對的人(key man)來為他指引方向,如此他才能進行下一個步驟的維修與檢驗。因此與其記錄動態性較高的實際知識,倒不如記錄問題解決的過程,例如對外找哪個部門的製程工程師,對內需要向誰請教等的程序,而非具體的知識。也許這樣會提供現場工程師如facebook一樣的網絡,縮短其搜尋的時間。

而周龍鴻先生並沒有考慮到工程師的差異,而只是簡單地套其認定的三大模式,我想這樣可能只會增加現場工程師對「探索者」的反感。

強英

chia2 提到...

這次的案例和上次同樣的提到了知識管理上面的問題,在組織上可能因為職務的關係,可能會造成對同一個知識系統的喜愛和厭惡。根據周龍鴻先生的觀點,完整的知識管理應該包括了知識管理模式、組織管理模式和企業流程模式,由三方面下手,才可以有系統的解決知識在組織間要流通傳達的效率。
如果只是導入一個知識系統或知識庫,只是知識管理的一面,如果組織面沒有跟著變更,設立培訓和分享的機制,那就像只給新的西式廚具卻沒有教中國廚師們西式餐點的做法;在配合企業流程上的控管,確保知識在流通的實務上也可以保持順暢與執行力。
因為知識有三種,物件型也許比較容易傳達流通,經驗型和實踐型也許就特別需要深入的流程與組織管理的配合了。

張貼留言