新知|HR應該先做知識管理，再做人才培養！

來自專欄 穆勝

雷景華是一家國內軟體企業——奔雷公司的創始人，最近的他火有點大。一年一度的「劫數」又觸動了他那顆敏感的心。

時值開年，頭年獎金髮放完畢後，一般都是跳槽的高峰期，而奔雷公司盤子不大，薪酬水平最多處於50分位，成熟人才自然被同行企業大量「收割」。軟體行業的流失率本來就高，小企業甚至超過50%，奔雷公司的流失率在30%-35%之間，應該處於正常值。

雷景華知道避不開「劫數」，但他怕的是，每年的「劫數」後，奔雷公司往往要恢復半年左右，運營才能恢復原有水平。奔雷公司是處於初生期的企業，這幾年為了搶佔市場份額，在營銷上四處出擊，全力接單，根本不可能考慮內部資源（人才）是否跟得上。

此時，員工頻繁往返於各個項目，基本上是各自為戰。而一旦有員工流失，項目就基本癱瘓，新人要接替工作，又只有從頭學起，如此一來，復原期自然過長。

復原期長的問題也只是冰山一角，市場的壓力早就倒逼到了奔雷公司。市場營銷部就多次指責軟體開發部門產品不力，引來客戶投訴。客戶一來埋怨產品交貨期長，二來埋怨產品維護升級不力。

開發和維護人員不變還好，一旦人員流動，為老客戶開發或維護產品都必須由新技術員重新溝通獲得對方信息。市場營銷部罵得最凶的還是產品的開發成本。沒有強勢品牌，自然希望從價格上找優勢，無奈奔雷的產品開發成本實在太高，銷售根本沒有市場操作的空間。

每次這些問題拿到檯面上，雷景華都是批評軟體開發部門，但這一年裡，EMBA課程和外部諮詢機構的啟發逐漸讓他明白，所有問題的癥結是知識管理。正因為員工的個人知識沒有被組織提取，形成可以被所有人分享利用的「組織知識」，人人只有自起爐灶，知識沒有標準化，管理知識的規模效應沒有發揮出來，才會有這一系列的問題。

正當雷景華開始思量如何解決，「劫數」就如期而至。不能再等了！他叫來人力資源部門經理姚松，不由分說地分下了任務。

癱瘓的知識管理

作為資深HR，姚松明白知識管理的工作實際就是「兩化」。一是「標準化」，即用一個標準模板把員工的各類「知道但無法表達」的隱性知識提煉出來；二是「聯動化」，就是發掘知識片段之間的關係，設置方便知識分享和利用的「線索」。被「線索」串起來的標準化知識片段就形成了企業的「知識庫」。

雷景華給了姚松3個月的項目周期。姚松苦不堪言，知識管理本來就是一個長周期的事，不僅知識庫里的知識片段需要積累，要上規模才能見效益，而尋找串聯知識的線索也需要時間，更何況提煉出的知識也需要檢驗……他理解民企老闆「不見兔子不撒鷹」的習慣，雷景華要立竿見影，他也只有「摸著石頭過河」。

姚松冥思苦想，想到用「案例庫建設」來暗度陳倉。這樣做也有他的道理，要軟體開發部門重新去構架自己的知識，這麼大的工程，人家忙於業務哪裡會搭理你？況且，所有部門儘管對接不同行業和專業的客戶，但他們的知識中有很大一塊是公用部分，針對這塊知識，大家提交上來的東西如果五花八門，又該聽誰的？知識管理的規範流程就是要組織專家反覆討論、設計，但雷景華顯然沒有給他姚松這個時間。

還是做案例好！姚松的邏輯是，案例是最直觀，最能夠被模仿的，實際上就是大量知識的載體，關鍵是，按照標準模板上報的案例，根本就不用進行二次處理和檢驗，直接就可以快速聚合形成「知識庫」，根本不用考慮他們之間的關係（因為都是平行的），至於「線索」，設置簡單的「關鍵詞」進行聯動即可。

奔雷業務模塊的組織結構是由幾個開發部門直接對接幾個行業，於是，姚鬆開始督促他們按照模板提交「標準化知識」。而模板是人力資源部在訪談了幾個技術人員後制定的。

不料，模板下發後卻遭遇了各開發部門的強烈不滿，雖然考慮做案例可以減少軟體開發部門的負擔，但大家還是紛紛埋怨自己忙於業務的同時還要完成人力資源部的「作業」，有的開發部門還直接扔回了狠話，「要交你們的作業也可以，耽誤了訂單交貨，你們要負責任！」

碰上一些願意配合的，也老是反饋說模板不對，用起來彆扭。好不容易在多次溝通後回收了幾個開發部門的「作業」，姚松趕緊組織下屬進行編號，並上傳到了公司的內網上。而後，人力資源部又在公司內進行了宣傳，號召大家多多利用「知識庫」降低開發成本。

從此，姚松就天天關注「知識庫」的下載量。頭幾天，下載量還比較大，可幾天一過，下載量急劇走低，直到門可羅雀。姚松心有不甘，連忙打親自電話到每個開發部門詢問原因。

原來，上傳「知識庫」的案例雖然直觀，但其背後卻包括了大量的專業知識（如人力資源管理、財務管理軟體）和行業知識（如銀行業、移動通訊業），不同的組合呈現出不同的解決模式，再加上軟體工程師們自己的開發習慣，案例變得過於獨特看，根本不能模仿。

想使用關鍵詞搜索，截取能夠利用的知識片段，但一個關鍵詞反饋回來幾個案例，個個自成一派，走的是不同路徑，根本不兼容，到底模仿哪個？等把這些案例都讀通了，黃花菜都涼了！更有部門反饋，有的案例根本是繞了彎路，模仿等於是自討苦吃。

打造「知識雲」

姚松前思後想，自己發動開發部門貢獻知識肯定沒錯，只是自己提供的「案例模板」好像反而限制了他們，但如果不加限制，大家提交的東西又怎麼整合呢？換個思路，如果放開限制，讓他們自由互動呢？

姚松突然想到，自己最近在某商業雜誌上看到過一個Moo博士撰寫的案例，某企業創新了一種管理模式，發動員工一起「維基」完成工作。「維基」本來就是網路上的知識管理模式，用到企業里應該也可以吧！

於是，姚松聘請了Moo博士作為項目顧問。Moo博士為他分析了項目：「你的項目走入了兩個誤區。第一，知識管理不等於『案例庫建設』，知識管理的目的是使知識庫里的知識片段能夠最大程度上被廣泛使用，這裡，就需要提煉出『元知識』。『元知識』是最基礎的流程、方法、技巧等，再特殊的項目也是由一個個單位的『元知識』組成的。

所以，提煉『元知識』，並建立『元知識』之間的『線索』才是關鍵。你們做案例庫，並沒有提煉『元知識』，反而讓『元知識』包裹在特殊的項目環境里，變得不可利用。第二，你們設置了自上而下的『知識庫』建設模式，如你所見，這種模式中，知識上規模慢，無法糾錯，難以設置串聯的「線索」……所以，新模式必須雙向互動，而且能夠隨時互動。」

「就是說做在知識管理上做『維基』是可行的？」姚松忍不住接話。「對，最好的『知識庫』應該是朵『知識雲』，由大量的『線索』串聯起眾多的『元知識』，而『維基』是打造這朵『知識雲』的必由之路……

Moo博士與姚松一番交流後，奔雷公司很快就上線了「知識管理平台」軟體，開始打造「知識雲」。

首先，從頂層設計「知識構架」。姚松在各開發部門分別抽調了業務尖子組成了項目小組，並賦予他們「知識體系構架師（設計師）」的職責。「知識系統構架師」經過研究，搭建出橫向和縱向的知識構架，橫向上是專業知識，縱向上是行業知識。這些構架比較開放，維基貢獻者可以自由上傳任意形式的知識片段，而後再並為不同知識貼上標籤，這些知識可以來自親自操作的項目，也可以來自自己查閱文獻，甚至可以來自從別人學到的經驗……

其次，在平台上設置「運行規則」。技術尖子被賦予了第二個身份——「平台管理者（裁判員）」。在平台上，當兩個以上的維基貢獻者針對同一知識點上傳了不同內容時，這就形成了一次「衝突」，這是後續操作的基礎。

一是「平台管理者」可以根據「衝突」找出正確的知識，實現糾錯。二是平台管理者還可以根據「衝突」提取出「元知識」。有的知識包裹在不同的解決方案里，具有不同的項目特徵，但是「元知識」都是一樣的，倘若不同的解決方案都運用了「某塊知識」，那麼這些知識就是相對解決方案更基礎知識，多次的「衝突」後，就可以提煉出「元知識」。

三是維基貢獻者上傳知識後提出的「標籤建議」也存在「衝突」，加上知識使用者在使用平台過程中留下的瀏覽痕迹（由平台軟體記錄分析），就可以實現「聯動化」，確保使用者在搜索知識時的精確性。

這些操作中，「平台管理者」主要履行的就是對上傳知識進行審核編輯的工作。由於搭建的是一個開放平台，「平台管理者」僅僅需要匯總分析「維基」上來的信息，並基於自身的技術儲備進行甄別，「審核編輯」的工作自然變得更加容易。

更有意思的是，由於「知識管理平台」是一個可以溯源的系統，維基貢獻者在每段貢獻的知識下都會留下自己的身份痕迹。於是，在知識使用者需要對一段知識進行更加深入的了解時，其就可以根據平台提供的信息，直接找到知識的維基貢獻者。

最後，奔雷為知識上傳和知識使用都設計了激勵機制。維基貢獻者上傳知識、糾正知識、提取標籤、解答問題等行為都被設置了相應的激勵政策。在這些行為之外，根據知識的使用頻率、標籤的搜索頻率、使用知識後的評價和解答問題的評價也會有相應的激勵措施。所有的激勵措施都很實在，直接與薪酬和晉陞相關。

對於知識使用者來說，則是在績效指標中鎖定了「交貨期」和「開發成本」兩個指標，道理很簡單，越多使用「知識庫」也就越能減少開發時間和成本。

隨後，在奔雷的「知識管理平台」上，已經不用姚松求爹爹告奶奶地催促大家「交作業」了，員工們紛紛維基上了各類知識，居然在1個月之內就基本搭建了完整的知識體系。

另一方面，藉由「知識雲」，軟體開發者也接收到了強大的支持，接到開發訂單後，其可以直接選擇合適的專業知識和行業知識以形成開發框架，再加入少部分項目的特有調整，一個定製軟體就很快形成了，這大大提高了交貨速度，降低了開發成本。

而因為這朵「知識雲」，奔雷在這次人員流失的「劫數」後，似乎也沒有經歷太長的復原期。更有意思的是，隨著「知識管理平台」的持續運行，幾個月後，員工已經越來越離不開這根「拐杖」。姚松以前的一項重要工作是盯緊重點人才，避免「挖角」，現在卻發現這些人越來越被「知識管理平台」粘住。一個和他私交甚密的技術精英告訴他，現在工作輕鬆了，完成的業務量卻更多了，收入漸長，哪有必要挪來挪去的？

另外，就算挪到其他地方，沒了這個「知識管理平台」，也很難保證有現在的工作效率……看著奔雷的變化，聽到了一個個利好，雷景華的臉上露出了久違的笑容……

知識立方的邏輯

現有知識管理的模式多半是自上而下構建體系，即由知識管理的責任部門制定一個企業整體知識構架的框架，並根據框架同時下發模板，並由員工提交知識片段。這種模式存在兩個弊端。

其一，知識體系的構建是單向的，這就意味著無法糾錯和更新。無法糾錯，是因為知識管理的權威方不具備縱覽全局的知識，正如姚松和人力資源部在收集了知識後並不能進行審核和甄別。無法更新，是因為這種模式搭建的知識庫是依靠管理者的命令，擁有知識的業務部門並沒有強大內驅力去更新知識，結果自然是把上傳知識看作是「交作業」，能躲就躲。

其二，知識缺乏體系性，僅僅是知識片段的無序聚合。正如姚松收集了一些知識片段，並為這些知識片段編號入庫，但各種知識片段之間的關係仍然是模糊的，A知識片段與B知識片段之間的關係可能是包含，可能是被包含，可能是交叉，可能是根本沒有關係，但究竟如何，誰也說不清楚。而且，知識片段是仍然孤立的，相互之間的聯繫被忽略了。

所以，傳統的知識管理模式除了耗時耗力，是一個循序漸進的過程，而且還存在自身無法克服的弱點。姚松的第一次嘗試失敗就是這些缺陷的生動註解。還好，雷景華急於馬上出成績，見效果，這反而逼得姚松走向了「維基打造知識雲」的新模式！

奔雷公司打造「知識雲」的過程是一種快速高效的知識管理新模式，我把這種模式稱為「知識立方」，這種模式克服了傳統模式的兩個固有缺陷。

第一，這種模式依靠一個互動式的企業Web3.0平台，在員工的互動中收集了知識。除了快速，其更大的意義在於通過員工的互動和「平台管理者」的審核，能夠實現平台上知識的自我糾錯，員工互動越頻繁，在同一類知識上的衝突就越多，也越有利於「平台管理者」甄別出正確的知識。另外，由於設置了與薪酬和晉陞直接相關的激勵制度，更加強了員工為平台貢獻知識的內驅力，而一旦員工具備了內驅力，就保證了「雲端知識」是「隨時迭代」的。

第二，這種模式為知識片段之間建立了聯繫。一方面先是通過頂層設計為整體知識進行系統構架，劃分大的模塊，再由員工在互動中（由「平台管理員」）把大模塊分解成小模塊，以此類推，直到提煉出不能分解的「元知識」。

另一方面是依靠「標籤管理」為知識片段甚至「元知識」之間建立了聯繫，形成了使用知識的「線索」。「標籤」同樣是在互動中產生，一是標籤建議的互動，二是知識使用者的瀏覽回饋，這確保了對於知識片段或者「元知識」的定位能夠越來越精準。

知識立方是一種為打造「雲端知識」而建立的開放、靈動的立體知識構架，其本質上是一個方便所有員工隨時貢獻、分享知識的構架。構架上，對於知識的貢獻會被拆解精鍊為一個個知識片段或「元知識」，這些單元好似「小方塊」，共同搭建成為「大立方」。

而藉由「標籤管理」，知識的使用者可以使得「小方塊」在立方上以一定的軌跡運動，形成相互之間的新組合，並被輕易搜索使用。如果說，在這個時代里，知識是企業發展的最大能量，那麼，知識立方就相當於打造了一個「靈動的能量大廈」！

「知識立方」的模式貫徹了「雲」的特徵。首先，員工之間形成了一朵「人力資源雲」。員工打破了組織邊界，形成了以立體網路式的構架自由協作的可能，而激勵政策的注入相當於一種「演算法」，導向了「雲」上的員工開始協作，貢獻知識。

其次，知識片段之間形成了一朵「知識雲（屬於培養資源或支持資源，讓員工『有能力干』）」。知識片段形成了立體的網路構架，並可以藉由優化後的「演算法」，通過精確定位的標籤被輕易獲取。無論是從貢獻知識的效率，還是從使用知識的效率上說，這種模式都是知識管理的未來！