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

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

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

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

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

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

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

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

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

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

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