顯示具有 案例3:〈如果大家都知道〉 標籤的文章。 顯示所有文章
顯示具有 案例3:〈如果大家都知道〉 標籤的文章。 顯示所有文章

2009年4月13日 星期一

案例三:〈如果大家都知道〉心得三

組員:陳治平、徐伊嫻、葉思妤、陳湘瑾

本次個案主要描述一家半導器材公司在導入知識管理系統時遭遇到了困難。一開始上課時,先由為我們介紹許多半導體公司在實行知識管理上真正的情形和限制,如:在無塵室的環境之下,設備工程師無法在現場直接紀錄解決問題的過程,下班又太累沒有心思寫。在初步討論過程中,曾在台積電工作的甘學長也一一釐清了我們的疑問,讓我們對半導體公司的實務運作更日解。


本組的思想方向是著重在:如何讓新手快速成為熟手的關鍵在於Sense making,目前實務上已有師徒制的實施,因此,我們建議讓新手跟著老手學習之外,下班之前要把當天所學習到的問題判斷與解決手法紀錄下來,並於論壇上分享。此外,這樣的紀錄會先經過資深工程師的確認及部門主管的審核,列入考績評核,論壇上也增加積點功能,若其他人覺得分享的知識有利於解決他手上的問題,便可以按「推薦」增加貼文者的積點,同樣列入考績評核。

然而經過課堂討論,系統設計上應要考慮人性的弱點,

例如:


真正的高手可能不會把知識全盤托出,而是提供大家模糊兩可的知識或是利用設定較一般性的關鍵字來增加文章被查閱的次數……等,這些都是在設計知識分享機制時需要考慮的部份。另外,我們更加認識知識的本質–從隱性知識到顯性知識的外化過程是相當棘手的難題,在系統設計上必須先了解使用者所需要的是什麼樣的知識型態,才能真正設計出使用者所需要的系統。


2009年4月8日 星期三

案例三:〈如果大家都知道〉心得二

組員: 陳維中、吳蔚宗、楊強英、劉芙妤、張駿義

在本次案例中我們的思考方向是,先找出一個key man,就是一個維修小組裡維修速度最快、品質最好的人,找到key man之後將他升為主管。Key man的績效就是他所帶領的維修小組的維修成果,以此來增加key man分享知識的誘因。而被key man帶領的小組成員的績效則是取決於他在KM系統上的貢獻度(也就是他從key man那邊學到什麼他就要發表在KM上)加上他維修的成果,希望能讓小組成員有使用KM的誘因。然而我們並沒有考慮到,維修小組人員難以用文字表達維修經驗,以及維修知識的迅速淘汰等問題,這個方案仍然不夠周延。

經過一堂課的討論下來,我們發現,如果能用類似病歷表的概念,將維修工程師在遇到維修問題時,尋找問題並處理的脈絡給紀錄下來,讓資淺的維修工程師能學到這樣推理的過程與邏輯,而不只是提供一個答案,這樣就可以解決維修之視訊素淘汰的問題了。

這幾堂課下來,大家往往會用獎勵或懲罰的方式來達到政策目的。但就像老師說的,獎勵是最好也是最壞,一間公司的領導人如果做什麼事都要靠獎勵來吸引員工的話,其實是管理能力的不足。未來我們在思考誘因的設計時,應當更加謹慎才是。

2009年4月7日 星期二

案例三:〈如果大家都知道〉心得一

組員:陳景威、劉宛婷、王思茜、古佳玉

這次的案例是有關半導體產業的知識系統管理。老師上課有提到許多半導體公司實行上真正的情形和它的限制,如:無法在現場有效的紀錄,讓我們更加了解個案。

我們這組想的方向是著重在:如何讓知識系統被工程師所接受,如何簡化記錄的流程但是還是保留效力?將記錄流程簡單化與表格化能讓工程師更易於接受填表分享,因為大部分的工程師不擅長長篇大論的文字書寫;而在作業中,就讓知識管理系統介入,並跟隨同一主題回覆的方式,可讓知識管理系統使用者串連解決問題的過程並找出曾經參與的人,方便使用者向「對的人」詢問。

然而經過課堂討論,我們發現許多實務的經驗也成為應該思考的方向,如:真正高手可能留下錯誤的知識、串連自己人互相吹捧、運用檢索技術(採用較一般性的用詞)增加文章被查閱的次數……等,這些都是在設計「鼓勵知識分享機制」時需要考慮的情境,不僅僅是讓使用者願意填表這麼簡單。

本周我們體會了知識的本質並予以分類,瞭解隱、顯性知識之間轉換的可能作法。隱性知識或經驗的傳播往往是一個棘手的難題,常常讓人有「可意會不可言傳」之感,同時,知識也必須透過「內化」才能轉變成能力。任何科技工具的使用最終目的仍是協助學習,如何有效的保存情境與訓練人員觸發性思考是該著重的重點,我們剛開始的思考不夠周全,這樣的互動還有進步的空間,也許透過workshop與web2.0結合的方式,可以讓知識系統更有效的也更快速的溝通交換。

2009年4月2日 星期四

案例三:2009.04.02 課堂討論實況







2009年4月1日 星期三

案例三專家1:周龍鴻

形成分享的習慣

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

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

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

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

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

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

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

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

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

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

案例三專家2:Cao Lin 博士

了解誰掌握知識

「為了挽救這個失敗的專案,半導器材公司的知識管理隊伍必須在知識探勘和回饋管道兩方面有所改善。他們必須了解用戶的需求——特別是現場工程師。現場工程師應該經常參與進來,為下一代Discover 的需求提出建議。」

半導器材公司的團隊在模仿博克門實驗室的K’Netix 知識管理模式時,犯了一些錯誤。他們不了解「探索者」和K’Netix 的本質是不同的,兩個行業(即化學和半導體)也差別很大。首先,在實施專案前,他們似乎未深入研究知識消費者的需求。根據我的經驗,如果你想導入一個重要的項目,首先你必須高度重視使用者的需求。誰是你的使用者?對專案的要求是什麼?很明顯地,知識管理團隊在這方面做得不好,因此知識分享的內容對現場工程師來說是不切實際、也毫不相關,雖然對設備工程師有一些用處。

第二,評估和選拔委員會的成員,似乎在廣度和深度上,都不了解現場工程師的知識。很可能,他們的評審方式無法選出好品質的知識內容。因此,即使現場工程師想回饋知識,這些知識內涵可能超出了委員會成員的知識範圍,導致提案被拒絕,打擊了現場工程師的信心。

第三,「最佳實務」的內容結構過度學術化,對於解決問題卻沒有意義。我認為現場工程師既不可能有耐心,也沒有具備足夠的技巧來寫這種「最佳實務」。要知道,知識消費者並不一定能勝任知識生產者。半導器材公司應該讓工程師用他們擅長的方式來闡述知識,而不是遵循僵化的、標準的形式。

為了挽救這個失敗的專案,半導器材公司的知識管理部必須了解知識消費者的需求——特別是現場工程師。現場工程師應該經常參與,為下一代「探索者」功能提供反饋意見。如此,系統才能夠更符合他們的需求。其次,知識管理部應該指派一個該領域的專家來領導知識內容的審
查,以避免不必要的審查疏失,從而沖淡了現場工程師的熱情。半導器材公司應該在委員會中選拔一位有資格的專家,從而改善「探索者」中知識內容的品質。另外,他們應該告訴現場工程師知識分享的重要性,以及分享知識後帶給他們自己的好處。他們應向現場工程師展示「探索者」的優越性,以吸引更多的現場工程師來使用系統。如此,半導器材公司也能樹立一些成功案例。

最後,知識管理部應該強化「探索者」的內涵,例如分配一些時間給現場工程師去寫出有價值的知識。公司不能期望現場工程師在業餘時間或下班後來寫文章。如果公司只是等工程師「方便的時候」才去貢獻知識,這是絕對行不通的。

案例三專家3:Chan Yong-Hee

知識分享前先要變革

「宣傳知識分享的重要性,主管必須透過培訓、傳播成功故事、獎勵、尊重知識分享者來實現。同時企業也需要在工作職責中加入『知識分享』這一條。這樣做的目的是使員工之間產生互相競爭的壓力,這也是保證企業文化變革成功的重要因素。」

根據我的經驗,知識管理系統成功的關鍵因素在於人。這包括激勵人們參與、執行變革等。知識管理不是只有伺服器、軟體和資料庫,而是獲取、發布和有效利用知識的過程。雖然一套精密的工具能為知識管理系統提供可靠的支援,但是這些工具不是知識產生的驅動力。資料的精確、完整和安全只是一套好的知識管理系統的重要基礎。

知識管理系統還包括變革管理,領導階層應該是變革的驅動者。領導人必須激勵員工,鼓勵員工分享知識。高層管理人員的示範與承諾能夠促使員工參與。持續的關注、回饋都是保證知識專案成功的關鍵因素。文化轉型是建立知識管理系統的成敗關鍵。這比應用新技術和重組新流程更重要。宣傳知識分享的重要性,主管必須透過培訓、傳播成功故事、獎勵、尊重知識分享者來實現。同時企業也需要在工作職責中加入「知識分享」這一條。這樣做的目的是使員工之間產生互相競爭的壓力,這也是保證企業文化變革成功的重要因素。

一個有效的知識管理系統已經成為企業運作的核心。我們是一個全球性公司,知識儲備和跨地域的知識交流非常重要。我認為一個成功的知識管理系統要能為企業帶來利益,這需要有系統的實施方式和大規模的投資。雖然公司內部有專人來推動系統,也必須有外部的專家提出改善意見。企業還需要有特別的專家團隊分析知識財產權的問題。像我們公司在每個區域都有一個技術專家,負責知識的管理工作。對知識管理專案的支持必須是自上而下的,問題要一部分一部分解決,在每個相關步驟都做記錄,而不是把所有問題都放到最後解決。在把工程師隱形知識轉變成顯形知識的過程中,最大的障礙是他們在工作了很久之後,不願意再花時間去記錄這些工作步驟。這個過程需要簡化,把整個維修過程分成階段性的報告。這項記錄工作最好有專家負責,並在最後提供一份終結報告。這樣知識管理才可以縮短工程師的作業時間,但這樣的記錄方式需要有專人來監督負責。

我發現半導器材公司的另一個問題是資訊共用機制(information sharing mechanism)。要使一個知識管理系統有效運作,應該有一個全球統一的資訊共享政策(information sharing policy)。知識也應該按照產品和服務的領域來合理分類,並提供索引。知識管理系統應該有大量的、有價值的內容,並且容易使用。一旦使用者對系統失望,他們一定不再信任「知識管理」這套觀念。

知識管理系統推廣的另一個困難是——知識內容品質與系統的便利性。我們大多數人會使用Google ,是因為它便於使用,而且檢索的結果相關度高。知識系統同樣需要考慮「知識消費者」,並在資料庫的查詢中加入知識消費者經常查詢的問題。資料庫查詢得到的結果必須是使用者需要的、相關度很高的資訊。

因此,半導器材公司需要針對不同的社群去創造知識分享的氛圍。半導器材公司也可以向員工公告知識系統每月的使用頻率與次數等資料。同時,如果半導器材公司要混合採用線上論壇和知識資料庫,我們也必須牢記,現場工程師所面臨的問題是動態的、多變的。我前面提到過,技術變革不應太快,人們總是需要一段時間來適應新技術。

總之,要想實施知識管理系統,我們必須首先考慮人的因素。要充分激勵員工來分享知識,領導階層必須推動變革,鼓勵員工參與,並給與必要的支持。雖然領導階層的承諾對於知識管理會有幫助,但是員工還是或多或少會拒絕分享知識,因為知識分享會與個人的利益產生矛盾。為了解決這種矛盾,公司需要調整獎勵機制,以鼓勵員工分享知識。這個機制能促進員工使用並適應知識管理系統。我認為,這些是知識管理系統成功的關鍵因素。

案例三專家4:Lee Nyen Kong 博士

將知識分解

「企業應該培育一種透過問問題,幫助他人解決問題來提高自身優勢的氛圍。這樣的氛圍可以由展現實際的效益來建立,例如:點出因避免重蹈覆轍而節省的時間。」

當我們談到知識管理時,首要的問題是:什麼是知識?知識不是資訊。我們每天都從討論、會議等管道獲得資訊。但什麼是知識?知識是可以重複利用的、存在於我們決策和學習過程中。知識就是人,組織的知識是存在公司內那些擁有特殊專才的人,是存在某一個領域展現傑出能力的人,他們對於影響組織文化有重要的作用。我認為,知識管理系統要能落實於實際的目標。知識管理除了要做到不斷蒐集、儲存公司中重要的資訊,還要建立一個環境,使人與人的聯繫更順暢,如此創新才出的來。

認識到這一點後,在一年前中央公積金局開始使用知識管理系統。我們建立了一個論壇,但是我們發現最大的挑戰是:如何激勵人們貢獻他們的知識。組織中的成員通常有惰性,可能是因為沒時間把經驗寫下來,可能是因為回憶起來有困難,也可能是不知道如何適當的編輯
資訊。

這些問題恐怕不能透過增加工作人員來解決。多一個人意味著成本的增加,而且你永遠不能確定,增加一個知識部門就能夠有效地記錄知識。員工在建立資訊系統和識別知識來源也會有困難。根本的解決辦法是,讓員工在實際操作流程中獲取知識。事實上,我們的員工已經在日常工作中,養成了儲存和記錄知識的好習慣。透過這種方法,我們能夠很快地找到學習的要點。

用同樣的邏輯來分析這個案例,我認為他們除了要記錄知識之外,還要找到知識。半導器材公司的員工不知道如何把實際經驗轉化為知識。我認為將工程師修理機器的經驗轉化為論壇上的知識分享文章,應該是一個很流暢的過程。工程師可以把操作過程分成多個小步驟,然後根據這些小步驟來記錄他們的操作過程,分享經驗。這樣記錄的過程應該會簡單很多。知識分享既可以使工程師的經驗價值最大化,也可以使他們獲得應得的報酬和認可。

企業應該培育員工學會提問題,並幫助他人解決問題,來提升競爭優勢。這樣的優勢可以由實際效益來展現,例如:衡量因避免重蹈覆轍而節省的時間等。新加坡中央公積金局最初建立了一個知識論壇(knowledge forum),它提供一個資料庫。透過這個論壇,我們把問題和
查詢結果放在這個資料庫。這些資料是顯性知識,可以被反覆運用。我們要注意,科技不能完全解決知識管理的問題。知識管理最大的困難是去改變人的行為。目前知識分享最大的障礙是文化。相比之下,克服技術限制並不重要。技術是用在克服時間和空間上的障礙,避免這些障礙成為限制性因素。引進知識分享系統,員工要先改變工作方式,善用新科技,才能在團隊中形成更有效的溝通。

案例三:〈如果大家都知道〉案情簡介



半導器材公司是一家跨國公司,總部在美國,專門提供生產設備給半導體生產廠,如英代爾、台積電、中蕊、聯電。陳永梅是半導器材公司在臺灣(新竹科學園區)的人力資源經理。最近,在參加了哈佛商學院高階經理人課程後,她對博克門實驗室(Buckman Lab ,一家美國著名的化工原料公司)的知識管理做法很感興趣r 。回到新竹後,永梅正在考慮怎樣把這種方法運用到公司。她組成了一個七人工作小組,成立「知識管理部」,積極導入一套知識庫。這個系統叫Discover(探索者),是為了幫助設備與現場工程師進行知識分享。

雖然永梅宣布系統的第一階段已經實施成功,也贏得了設備工程師的好評。但是,現場維修工程師並不認同這套系統。

一個工程師語帶諷刺地說:

「『探索者』這套系統完全是在浪費我的時間。你知道嗎,我修理的是最先進的設備,學習新機型的時間還不夠呢,怎麼還有時間記錄過去修理機型的經驗。再說,那些『探索者』系統中的評審,他們知道的東西可能早就過時了,比我知道的知識更落後不止三代呢。這些評審又怎麼可能有辦法來審核我提交的知識呢?」

另一位資深工程師則無奈地說:

「『探索者』系統中的『維修竅門』,頂多也只能說明維修問題的一小部分。通常,我們需要考慮到機臺在整個流程上的問題,不斷地和其他工程師溝通,才有可能找到真正故障原因。這有點像急診室裡的情況,我們就像為機器看病的醫生。當一切工作完成後,雖然我很清楚維修的全部過程,但是要叫我寫出這
個過程是很難的。」

永梅很擔心,因為如果現場工程師一直反對的話,總經理張仲彥將會停掉「探索者」專案,並解散「知識管理部」。龍嘯天是來自安德魯的顧問,他從一開始就參與「探索者」開發,該系統結案時還獲得臺灣經濟部頒獎。受永梅之託,他再次前來診斷這套知識管理系統的採納問題。

永梅對他說:
「我實在是無計可施了,我們絕對不可以失敗。部門能否繼續生存就取決於『探索者』系統能否被接受。我們一定要提出具體的成本效益來說服老總。無論如何,你一定要幫我向公司老總證明這套系統是可行的,否則,公司將不會再投入任何資金,也會解散知識管理部。說實在的,我真的不懂,這套系統可是找了第一流的顧問公司進行開發與導入,而且工程師也都參與設計,為什麼他們會不喜歡?」