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