早在20世紀80年代，以美國麻省理工學院教授彼得•聖吉（Peter M．Senge）為代表的學者，開始致力於學習型組織的研究。以此為起點，屈指算來，知識管理也已經走過了20多年的漫長曆程。雖然隨著知識管理理論在實踐中不斷昇華，同時IT技術的匯入又大大提升了知識管理的可操作性，但一直無法得到大面積的成功推廣。

造成以上局面並不是由於對知識管理的重要性缺乏認識：研發經理們也明白其重要性。他們也知道，對研發知識與經驗更好的利用會帶來巨大的回報，結合對國內眾多科技型企業的知識管理現狀的分析，認為國內企業到目前為止研發知識管理失敗的原因主要歸結為以下兩點：

1) 缺陷有效的知識分享的文化；

2) 沒有將知識管理與主幹業務很好的結合；

在談具體怎麼實施知識管理前，我們有必要對研發中的有價值的經驗與知識的種類進行初步的瞭解，與研發相關的CBB(共用技術模組)、模板、準則、檢查單、經驗、教訓、方法論、參考檔案、專利資訊等都屬於知識管理的範疇，尤其是專案實際運作的經驗教訓對其他後續專案有很大的借鑑價值，而實際我們發現很多研發類的企業專案的經驗教訓伴隨專案的結束而消失，同時在其他專案還在繼續著同樣的錯誤，怎有效管理和重複使用這些知識，直接關係到產品開發的成本、質量和進度。

要構建情境化的知識管理體系，首先，需要培養公司的流程意識和知識共享的文化，作為研發企業可以借鑑其他標竿企業的經驗教訓，但不同企業的實際情況，產品領域都有所不同，我們自身企業內部知識的持續積累才是我們應該關注的核心; 知識管理推行的最大阻力來自公司內部全體員工；其最大的障礙來自於缺乏分享的意願、動機和習慣。人們花許多時間發展個人知識，以凸顯自己，這自然地引發所謂“知識即權力”的態度。傳統上，員工擔心自己辛苦獲得或因時間累積而得的知識與人分享後，職務將被取代或工作朝不保夕，害怕變成“教了徒弟，沒了師傅”，因此，不願對別人分享自己的知識。成功的知識管理需透過企業文化的改造，改變員工的思維模式並培養“知識分享”的文化。

知識分享不是一個可以自行發展的過程，需要讓員工切實認識到知識的共享會對每個員工自身能力提升的意義，高層需要帶頭做知識分享的工作，高層的支援不能只停留在語言上，而應該有切實的行動，例如高層對員工的培訓就是參與知識管理的具體行動；知識共享文化的形成過程中，必要的制度和適當的物質、精神激勵也是必須的，例如研發經驗教訓案例獎勵就是一種很值得推廣使用的方法，鼓勵研發人員將實際專案中遇到的問題以書面的形式總結出來，然後由評價專家團隊對提交的案例進行評價，根據評價得分作者可以獲得不同數量的獎勵；如果起初確實沒有任何人願意提交案例怎麼辦？必要的強制分配也是必須的，例如可以根據部門、專案團隊人員的不同每月強制分配不同數量的經典案例提案指標。

知識管理要想保持持續的生命力就需要和公司的主業務保持一致，不能為了知識管理而進行知識管理，業務的需求是知識管理的指南針，具體怎麼將知識管理與公司的主體業務進行融合呢？這就需要構建情境化知識管理體系，具體什麼是情境知識管理體系呢？我們不妨先看一下目前一些公司的知識管理的方法，他們也建立起來了知識管理系統，利用資料夾與資料夾命名規則組織知識檔案，然後指望開發人員到那些資料夾中找他們所需的檔案，但不幸的是，這種方案很難生效，一方面是堆積如山的知識檔案，另一方面卻是具體的開發人員進行一項開發活動時不知道需要什麼知識檔案來支撐，即使知道也發現很難快速找到相應的知識檔案；為了解決這個問題，我們可以借鑑軟體的API的思想，將具體的知識檔案依附於具體的專案開發活動，透過適當的IT系統或專案管理工具（例如：PROJECT）我們可以知道具體開發人員即將從事什麼開發活動，這時知識管理系統就類似軟體呼叫API一樣，將與該活動相關的知識檔案自動展現在開發人員面前，這樣很好地解決了日常開發活動和知識管理的融合問題，這就是情境式知識管理體系的核心概念，要想建立這樣的情境知識管理體系，首先需要將我們的產品研發流程進行固化，產品研發流程本身就可以成為我們知識持續積累的平臺，正是因為不同專案遵從相同的研發流程，歷史專案的經驗教訓才對後續的專案有借鑑價值，同時透過流程就可以明確每個活動需要什麼樣的知識檔案來支撐，實現研發日常活動與知識管理的融合。

20世紀90年代的中後期到現在是知識管理的“實踐推動型”階段。這一時期的主要推動者是IBM、惠普、微軟等跨國IT企業，它們為知識管理的推行進行了大量的實踐，開發了一系列的知識管理工具。同時一些國際知名企業（如通用和福特）知識管理的成功實踐經驗所產生的“標杆效應”也成為了知識管理發展的強大推動力，情境式知識管理體系的提出，使我們的知識管理更具有針對性，同時實現了知識管理與主業務的融合，相信未來將會更大程度地推動知識管理的發展。
[@more@]

構造情境化知識管理體系（轉）

相關文章