雷景華是一家國內軟件企業——奔雷公司的創始人，最近的他火有點大。一年一度的“劫數”又觸動了他那顆敏感的心。
時值開年，頭年獎金發放完畢后，一般都是跳槽的高峰期，而奔雷公司盤子不大，薪酬水平最多處于50分位，成熟人才自然被同行企業大量“收割”。軟件行業的流失率本來就高，小企業甚至超過50%，奔雷公司的流失率在30%-35%之間，應該處于正常值。
雷景華知道避不開“劫數”，但他怕的是，每年的“劫數”后，奔雷公司往往要恢復半年左右，運營才能恢復原有水平。奔雷公司是處于初生期的企業，這幾年為了搶占市場份額，在營銷上四處出擊，全力接單，根本不可能考慮內部資源（人才）是否跟得上。此時，員工頻繁往返于各個項目，基本上是各自為戰。而一旦有員工流失，項目就基本癱瘓，新人要接替工作，又只有從頭學起，如此一來，復原期自然過長。
復原期長的問題也只是冰山一角，市場的壓力早就倒逼到了奔雷公司。市場營銷部就多次指責軟件開發部門產品不力，引來客戶投訴。客戶一來埋怨產品交貨期長，二來埋怨產品維護升級不力。開發和維護人員不變還好，一旦人員流動，為老客戶開發或維護產品都必須由新技術員重新溝通獲得對方信息。市場營銷部罵得最兇的還是產品的開發成本。沒有強勢品牌，自然希望從價格上找優勢，無奈奔雷的產品開發成本實在太高，銷售根本沒有市場操作的空間。
每次這些問題拿到臺面上，雷景華都是批評軟件開發部門，但這一年里，EMBA課程和外部咨詢機構的啟發逐漸讓他明白，所有問題的癥結是知識管理。正因為員工的個人知識沒有被組織提取，形成可以被所有人分享利用的“組織知識”，人人只有自起爐灶，知識沒有標準化，管理知識的規模效應沒有發揮出來，才會有這一系列的問題。
正當雷景華開始思量如何解決，“劫數”就如期而至。不能再等了！他叫來人力資源部門經理姚松，不由分說地分下了任務。
癱瘓的知識管理
作為資深HR，姚松明白知識管理的工作實際就是“兩化”。一是“標準化”，即用一個標準模板把員工的各類“知道但無法表達”的隱性知識提煉出來；二是“聯動化”，就是發掘知識片段之間的關系，設置方便知識分享和利用的“線索”。被“線索”串起來的標準化知識片段就形成了企業的“知識庫”。
雷景華給了姚松3個月的項目周期。姚松苦不堪言，知識管理本來就是一個長周期的事，不僅知識庫里的知識片段需要積累，要上規模才能見效益，而尋找串聯知識的線索也需要時間，更何況提煉出的知識也需要檢驗……他理解民企老板“不見兔子不撒鷹”的習慣，雷景華要立竿見影，他也只有“摸著石頭過河”。
姚松冥思苦想，想到用“案例庫建設”來暗度陳倉。這樣做也有他的道理，要軟件開發部門重新去構架自己的知識，這么大的工程，人家忙于業務哪里會搭理你？況且，所有部門盡管對接不同行業和專業的客戶，但他們的知識中有很大一塊是公用部分，針對這塊知識，大家提交上來的東西如果五花八門，又該聽誰的？知識管理的規范流程就是要組織專家反復討論、設計，但雷景華顯然沒有給他姚松這個時間。
還是做案例好！姚松的邏輯是，案例是最直觀，最能夠被模仿的，實際上就是大量知識的載體，關鍵是，按照標準模板上報的案例，根本就不用進行二次處理和檢驗，直接就可以快速聚合形成“知識庫”，根本不用考慮他們之間的關系（因為都是平行的），至于“線索”，設置簡單的“關鍵詞”進行聯動即可。奔雷業務模塊的組織結構是由幾個開發部門直接對接幾個行業，于是，姚松開始督促他們按照模板提交“標準化知識”。而模板是人力資源部在訪談了幾個技術人員后制定的。
不料，模板下發后卻遭遇了各開發部門的強烈不滿，雖然考慮做案例可以減少軟件開發部門的負擔，但大家還是紛紛埋怨自己忙于業務的同時還要完成人力資源部的“作業”，有的開發部門還直接扔回了狠話，“要交你們的作業也可以，耽誤了訂單交貨，你們要負責任！”碰上一些愿意配合的，也老是反饋說模板不對，用起來別扭。好不容易在多次溝通后回收了幾個開發部門的“作業”，姚松趕緊組織下屬進行編號，并上傳到了公司的內網上。而后，人力資源部又在公司內進行了宣傳，號召大家多多利用“知識庫”降低開發成本。
從此，姚松就天天關注“知識庫”的下載量。頭幾天，下載量還比較大，可幾天一過，下載量急劇走低，直到門可羅雀。姚松心有不甘，連忙打親自電話到每個開發部門詢問原因。原來，上傳“知識庫”的案例雖然直觀，但其背后卻包括了大量的專業知識（如人力資源管理、財務管理軟件）和行業知識（如銀行業、移動通訊業），不同的組合呈現出不同的解決模式，再加上軟件工程師們自己的開發習慣，案例變得過于獨特看，根本不能模仿。想使用關鍵詞搜索，截取能夠利用的知識片段，但一個關鍵詞反饋回來幾個案例，個個自成一派，走的是不同路徑，根本不兼容，到底模仿哪個？等把這些案例都讀通了，黃花菜都涼了！更有部門反饋，有的案例根本是繞了彎路，模仿等于是自討苦吃。
打造“知識云”
姚松前思后想，自己發動開發部門貢獻知識肯定沒錯，只是自己提供的“案例模板”好像反而限制了他們，但如果不加限制，大家提交的東西又怎么整合呢？換個思路，如果放開限制，讓他們自由互動呢？姚松突然想到，自己最近在某商業雜志上看到過一個發動員工一起“維基”完成工作的例子，這種現象被作者稱為“人力資源云轉型”。“維基”本來就是網絡上的知識管理模式，用到企業里應該也可以吧！
姚松聘請了長期研究“人力資源云轉型”現象Moo博士作為項目顧問。Moo博士為他分析了項目：“你的項目走入了兩個誤區。第一，知識管理不等于‘案例庫建設’，知識管理的目的是使知識庫里的知識片段能夠最大程度上被廣泛使用，這里，就需要提煉出‘元知識’。‘元知識’是最基礎的流程、方法、技巧等，再特殊的項目也是由一個個單位的‘元知識’組成的。所以，提煉‘元知識’，并建立‘元知識’之間的‘線索’才是關鍵。你們做案例庫，并沒有提煉‘元知識’，反而讓‘元知識’包裹在特殊的項目環境里，變得不可利用。第二，你們設置了自上而下的‘知識庫’建設模式，如你所見，這種模式中，知識上規模慢，無法糾錯，難以設置串聯的“線索”……所以，新模式必須雙向互動，而且能夠隨時互動。”
“就是說做在知識管理上做‘維基’是可行的？”姚松忍不住接話。“對，最好的‘知識庫’應該是朵‘知識云’，由大量的‘線索’串聯起眾多的‘元知識’，而‘維基’是打造這朵‘知識云’的必由之路……
Moo博士與姚松一番交流后，奔雷公司很快就上線了“知識管理平臺”軟件，開始打造“知識云”。
首先，從頂層設計“知識構架”。姚松在各開發部門分別抽調了業務尖子組成了項目小組，并賦予他們“知識體系構架師（設計師）”的職責。“知識系統構架師”經過研究，搭建出橫向和縱向的知識構架，橫向上是專業知識，縱向上是行業知識。這些構架比較開放，維基貢獻者可以自由上傳任意形式的知識片段，而后再并為不同知識貼上標簽，這些知識可以來自親自操作的項目，也可以來自自己查閱文獻，甚至可以來自從別人學到的經驗……
其次，在平臺上設置“運行規則”。技術尖子被賦予了第二個身份——“平臺管理者（裁判員）”。在平臺上，當兩個以上的維基貢獻者針對同一知識點上傳了不同內容時，這就形成了一次“沖突”，這是后續操作的基礎。一是“平臺管理者”可以根據“沖突”找出正確的知識，實現糾錯。二是平臺管理者還可以根據“沖突”提取出“元知識”。有的知識包裹在不同的解決方案里，具有不同的項目特征，但是“元知識”都是一樣的，倘若不同的解決方案都運用了“某塊知識”，那么這些知識就是相對解決方案更基礎知識，多次的“沖突”后，就可以提煉出“元知識”。三是維基貢獻者上傳知識后提出的“標簽建議”也存在“沖突”，加上知識使用者在使用平臺過程中留下的瀏覽痕跡（由平臺軟件記錄分析），就可以實現“聯動化”，確保使用者在搜索知識時的精確性。
這些操作中，“平臺管理者”主要履行的就是對上傳知識進行審核編輯的工作。由于搭建的是一個開放平臺，“平臺管理者”僅僅需要匯總分析“維基”上來的信息，并基于自身的技術儲備進行甄別，“審核編輯”的工作自然變得更加容易。
更有意思的是，由于“知識管理平臺”是一個可以溯源的系統
時值開年，頭年獎金發放完畢后，一般都是跳槽的高峰期，而奔雷公司盤子不大，薪酬水平最多處于50分位，成熟人才自然被同行企業大量“收割”。軟件行業的流失率本來就高，小企業甚至超過50%，奔雷公司的流失率在30%-35%之間，應該處于正常值。
雷景華知道避不開“劫數”，但他怕的是，每年的“劫數”后，奔雷公司往往要恢復半年左右，運營才能恢復原有水平。奔雷公司是處于初生期的企業，這幾年為了搶占市場份額，在營銷上四處出擊，全力接單，根本不可能考慮內部資源（人才）是否跟得上。此時，員工頻繁往返于各個項目，基本上是各自為戰。而一旦有員工流失，項目就基本癱瘓，新人要接替工作，又只有從頭學起，如此一來，復原期自然過長。
復原期長的問題也只是冰山一角，市場的壓力早就倒逼到了奔雷公司。市場營銷部就多次指責軟件開發部門產品不力，引來客戶投訴。客戶一來埋怨產品交貨期長，二來埋怨產品維護升級不力。開發和維護人員不變還好，一旦人員流動，為老客戶開發或維護產品都必須由新技術員重新溝通獲得對方信息。市場營銷部罵得最兇的還是產品的開發成本。沒有強勢品牌，自然希望從價格上找優勢，無奈奔雷的產品開發成本實在太高，銷售根本沒有市場操作的空間。
每次這些問題拿到臺面上，雷景華都是批評軟件開發部門，但這一年里，EMBA課程和外部咨詢機構的啟發逐漸讓他明白，所有問題的癥結是知識管理。正因為員工的個人知識沒有被組織提取，形成可以被所有人分享利用的“組織知識”，人人只有自起爐灶，知識沒有標準化，管理知識的規模效應沒有發揮出來，才會有這一系列的問題。
正當雷景華開始思量如何解決，“劫數”就如期而至。不能再等了！他叫來人力資源部門經理姚松，不由分說地分下了任務。
癱瘓的知識管理
作為資深HR，姚松明白知識管理的工作實際就是“兩化”。一是“標準化”，即用一個標準模板把員工的各類“知道但無法表達”的隱性知識提煉出來；二是“聯動化”，就是發掘知識片段之間的關系，設置方便知識分享和利用的“線索”。被“線索”串起來的標準化知識片段就形成了企業的“知識庫”。
雷景華給了姚松3個月的項目周期。姚松苦不堪言，知識管理本來就是一個長周期的事，不僅知識庫里的知識片段需要積累，要上規模才能見效益，而尋找串聯知識的線索也需要時間，更何況提煉出的知識也需要檢驗……他理解民企老板“不見兔子不撒鷹”的習慣，雷景華要立竿見影，他也只有“摸著石頭過河”。
姚松冥思苦想，想到用“案例庫建設”來暗度陳倉。這樣做也有他的道理，要軟件開發部門重新去構架自己的知識，這么大的工程，人家忙于業務哪里會搭理你？況且，所有部門盡管對接不同行業和專業的客戶，但他們的知識中有很大一塊是公用部分，針對這塊知識，大家提交上來的東西如果五花八門，又該聽誰的？知識管理的規范流程就是要組織專家反復討論、設計，但雷景華顯然沒有給他姚松這個時間。
還是做案例好！姚松的邏輯是，案例是最直觀，最能夠被模仿的，實際上就是大量知識的載體，關鍵是，按照標準模板上報的案例，根本就不用進行二次處理和檢驗，直接就可以快速聚合形成“知識庫”，根本不用考慮他們之間的關系（因為都是平行的），至于“線索”，設置簡單的“關鍵詞”進行聯動即可。奔雷業務模塊的組織結構是由幾個開發部門直接對接幾個行業，于是，姚松開始督促他們按照模板提交“標準化知識”。而模板是人力資源部在訪談了幾個技術人員后制定的。
不料，模板下發后卻遭遇了各開發部門的強烈不滿，雖然考慮做案例可以減少軟件開發部門的負擔，但大家還是紛紛埋怨自己忙于業務的同時還要完成人力資源部的“作業”，有的開發部門還直接扔回了狠話，“要交你們的作業也可以，耽誤了訂單交貨，你們要負責任！”碰上一些愿意配合的，也老是反饋說模板不對，用起來別扭。好不容易在多次溝通后回收了幾個開發部門的“作業”，姚松趕緊組織下屬進行編號，并上傳到了公司的內網上。而后，人力資源部又在公司內進行了宣傳，號召大家多多利用“知識庫”降低開發成本。
從此，姚松就天天關注“知識庫”的下載量。頭幾天，下載量還比較大，可幾天一過，下載量急劇走低，直到門可羅雀。姚松心有不甘，連忙打親自電話到每個開發部門詢問原因。原來，上傳“知識庫”的案例雖然直觀，但其背后卻包括了大量的專業知識（如人力資源管理、財務管理軟件）和行業知識（如銀行業、移動通訊業），不同的組合呈現出不同的解決模式，再加上軟件工程師們自己的開發習慣，案例變得過于獨特看，根本不能模仿。想使用關鍵詞搜索，截取能夠利用的知識片段，但一個關鍵詞反饋回來幾個案例，個個自成一派，走的是不同路徑，根本不兼容，到底模仿哪個？等把這些案例都讀通了，黃花菜都涼了！更有部門反饋，有的案例根本是繞了彎路，模仿等于是自討苦吃。
打造“知識云”
姚松前思后想，自己發動開發部門貢獻知識肯定沒錯，只是自己提供的“案例模板”好像反而限制了他們，但如果不加限制，大家提交的東西又怎么整合呢？換個思路，如果放開限制，讓他們自由互動呢？姚松突然想到，自己最近在某商業雜志上看到過一個發動員工一起“維基”完成工作的例子，這種現象被作者稱為“人力資源云轉型”。“維基”本來就是網絡上的知識管理模式，用到企業里應該也可以吧！
姚松聘請了長期研究“人力資源云轉型”現象Moo博士作為項目顧問。Moo博士為他分析了項目：“你的項目走入了兩個誤區。第一，知識管理不等于‘案例庫建設’，知識管理的目的是使知識庫里的知識片段能夠最大程度上被廣泛使用，這里，就需要提煉出‘元知識’。‘元知識’是最基礎的流程、方法、技巧等，再特殊的項目也是由一個個單位的‘元知識’組成的。所以，提煉‘元知識’，并建立‘元知識’之間的‘線索’才是關鍵。你們做案例庫，并沒有提煉‘元知識’，反而讓‘元知識’包裹在特殊的項目環境里，變得不可利用。第二，你們設置了自上而下的‘知識庫’建設模式，如你所見，這種模式中，知識上規模慢，無法糾錯，難以設置串聯的“線索”……所以，新模式必須雙向互動，而且能夠隨時互動。”
“就是說做在知識管理上做‘維基’是可行的？”姚松忍不住接話。“對，最好的‘知識庫’應該是朵‘知識云’，由大量的‘線索’串聯起眾多的‘元知識’，而‘維基’是打造這朵‘知識云’的必由之路……
Moo博士與姚松一番交流后，奔雷公司很快就上線了“知識管理平臺”軟件，開始打造“知識云”。
首先，從頂層設計“知識構架”。姚松在各開發部門分別抽調了業務尖子組成了項目小組，并賦予他們“知識體系構架師（設計師）”的職責。“知識系統構架師”經過研究，搭建出橫向和縱向的知識構架，橫向上是專業知識，縱向上是行業知識。這些構架比較開放，維基貢獻者可以自由上傳任意形式的知識片段，而后再并為不同知識貼上標簽，這些知識可以來自親自操作的項目，也可以來自自己查閱文獻，甚至可以來自從別人學到的經驗……
其次，在平臺上設置“運行規則”。技術尖子被賦予了第二個身份——“平臺管理者（裁判員）”。在平臺上，當兩個以上的維基貢獻者針對同一知識點上傳了不同內容時，這就形成了一次“沖突”，這是后續操作的基礎。一是“平臺管理者”可以根據“沖突”找出正確的知識，實現糾錯。二是平臺管理者還可以根據“沖突”提取出“元知識”。有的知識包裹在不同的解決方案里，具有不同的項目特征，但是“元知識”都是一樣的，倘若不同的解決方案都運用了“某塊知識”，那么這些知識就是相對解決方案更基礎知識，多次的“沖突”后，就可以提煉出“元知識”。三是維基貢獻者上傳知識后提出的“標簽建議”也存在“沖突”，加上知識使用者在使用平臺過程中留下的瀏覽痕跡（由平臺軟件記錄分析），就可以實現“聯動化”，確保使用者在搜索知識時的精確性。
這些操作中，“平臺管理者”主要履行的就是對上傳知識進行審核編輯的工作。由于搭建的是一個開放平臺，“平臺管理者”僅僅需要匯總分析“維基”上來的信息，并基于自身的技術儲備進行甄別，“審核編輯”的工作自然變得更加容易。
更有意思的是，由于“知識管理平臺”是一個可以溯源的系統
