雷景华是一家国内软件企业——奔雷公司的创始人，最近的他火有点大。一年一度的“劫数”又触动了他那颗敏感的心。

　　时值开年，头年奖金发放完毕后，一般都是跳槽的高峰期，而奔雷公司盘子不大，薪酬水平最多处于50分位，成熟人才自然被同行企业大量“收割”。软件行业的流失率本来就高，小企业甚至超过50%，奔雷公司的流失率在30%-35%之间，应该处于正常值。

 

　　雷景华知道避不开“劫数”，但他怕的是，每年的“劫数”后，奔雷公司往往要恢复半年左右，运营才能恢复原有水平。奔雷公司是处于初生期的企业，这几年为了抢占市场份额，在营销上四处出击，全力接单，根本不可能考虑内部资源（人才）是否跟得上。此时，员工频繁往返于各个项目，基本上是各自为战。而一旦有员工流失，项目就基本瘫痪，新人要接替工作，又只有从头学起，如此一来，复原期自然过长。

　　复原期长的问题也只是冰山一角，市场的压力早就倒逼到了奔雷公司。市场营销部就多次指责软件开发部门产品不力，引来客户投诉。客户一来埋怨产品交货期长，二来埋怨产品维护升级不力。开发和维护人员不变还好，一旦人员流动，为老客户开发或维护产品都必须由新技术员重新沟通获得对方信息。市场营销部骂得最凶的还是产品的开发成本。没有强势品牌，自然希望从价格上找优势，无奈奔雷的产品开发成本实在太高，销售根本没有市场操作的空间。

　　每次这些问题拿到台面上，雷景华都是批评软件开发部门，但这一年里，EMBA课程和外部咨询机构的启发逐渐让他明白，所有问题的症结是知识管理。正因为员工的个人知识没有被组织提取，形成可以被所有人分享利用的“组织知识”，人人只有自起炉灶，知识没有标准化，管理知识的规模效应没有发挥出来，才会有这一系列的问题。

　　正当雷景华开始思量如何解决，“劫数”就如期而至。不能再等了！他叫来人力资源部门经理姚松，不由分说地分下了任务。

　　瘫痪的知识管理

　　作为资深HR，姚松明白知识管理的工作实际就是“两化”。一是“标准化”，即用一个标准模板把员工的各类“知道但无法表达”的隐性知识提炼出来；二是“联动化”，就是发掘知识片段之间的关系，设置方便知识分享和利用的“线索”。被“线索”串起来的标准化知识片段就形成了企业的“知识库”。

　　雷景华给了姚松3个月的项目周期。姚松苦不堪言，知识管理本来就是一个长周期的事，不仅知识库里的知识片段需要积累，要上规模才能见效益，而寻找串联知识的线索也需要时间，更何况提炼出的知识也需要检验……他理解民企老板“不见兔子不撒鹰”的习惯，雷景华要立竿见影，他也只有“摸着石头过河”。

　　姚松冥思苦想，想到用“案例库建设”来暗度陈仓。这样做也有他的道理，要软件开发部门重新去构架自己的知识，这么大的工程，人家忙于业务哪里会搭理你？况且，所有部门尽管对接不同行业和专业的客户，但他们的知识中有很大一块是公用部分，针对这块知识，大家提交上来的东西如果五花八门，又该听谁的？知识管理的规范流程就是要组织专家反复讨论、设计，但雷景华显然没有给他姚松这个时间。

　　还是做案例好！姚松的逻辑是，案例是最直观，最能够被模仿的，实际上就是大量知识的载体，关键是，按照标准模板上报的案例，根本就不用进行二次处理和检验，直接就可以快速聚合形成“知识库”，根本不用考虑他们之间的关系（因为都是平行的），至于“线索”，设置简单的“关键词”进行联动即可。奔雷业务模块的组织结构是由几个开发部门直接对接几个行业，于是，姚松开始督促他们按照模板提交“标准化知识”。而模板是人力资源部在访谈了几个技术人员后制定的。

　　不料，模板下发后却遭遇了各开发部门的强烈不满，虽然考虑做案例可以减少软件开发部门的负担，但大家还是纷纷埋怨自己忙于业务的同时还要完成人力资源部的“作业”，有的开发部门还直接扔回了狠话，“要交你们的作业也可以，耽误了订单交货，你们要负责任！”碰上一些愿意配合的，也老是反馈说模板不对，用起来别扭。好不容易在多次沟通后回收了几个开发部门的“作业”，姚松赶紧组织下属进行编号，并上传到了公司的内网上。而后，人力资源部又在公司内进行了宣传，号召大家多多利用“知识库”降低开发成本。

　　从此，姚松就天天关注“知识库”的下载量。头几天，下载量还比较大，可几天一过，下载量急剧走低，直到门可罗雀。姚松心有不甘，连忙打亲自电话到每个开发部门询问原因。原来，上传“知识库”的案例虽然直观，但其背后却包括了大量的专业知识（如人力资源管理、财务管理软件）和行业知识（如银行业、移动通讯业），不同的组合呈现出不同的解决模式，再加上软件工程师们自己的开发习惯，案例变得过于独特看，根本不能模仿。想使用关键词搜索，截取能够利用的知识片段，但一个关键词反馈回来几个案例，个个自成一派，走的是不同路径，根本不兼容，到底模仿哪个？等把这些案例都读通了，黄花菜都凉了！更有部门反馈，有的案例根本是绕了弯路，模仿等于是自讨苦吃。

　　打造“知识云”

　　姚松前思后想，自己发动开发部门贡献知识肯定没错，只是自己提供的“案例模板”好像反而限制了他们，但如果不加限制，大家提交的东西又怎么整合呢？换个思路，如果放开限制，让他们自由互动呢？姚松突然想到，自己最近在某商业杂志上看到过一个发动员工一起“维基”完成工作的例子，这种现象被作者称为“人力资源云转型”。“维基”本来就是网络上的知识管理模式，用到企业里应该也可以吧！

　　姚松聘请了长期研究“人力资源云转型”现象Moo博士作为项目顾问。Moo博士为他分析了项目：“你的项目走入了两个误区。第一，知识管理不等于‘案例库建设’，知识管理的目的是使知识库里的知识片段能够最大程度上被广泛使用，这里，就需要提炼出‘元知识’。‘元知识’是最基础的流程、方法、技巧等，再特殊的项目也是由一个个单位的‘元知识’组成的。所以，提炼‘元知识’，并建立‘元知识’之间的‘线索’才是关键。你们做案例库，并没有提炼‘元知识’，反而让‘元知识’包裹在特殊的项目环境里，变得不可利用。第二，你们设置了自上而下的‘知识库’建设模式，如你所见，这种模式中，知识上规模慢，无法纠错，难以设置串联的“线索”……所以，新模式必须双向互动，而且能够随时互动。”

　　“就是说做在知识管理上做‘维基’是可行的？”姚松忍不住接话。“对，最好的‘知识库’应该是朵‘知识云’，由大量的‘线索’串联起众多的‘元知识’，而‘维基’是打造这朵‘知识云’的必由之路……

　　Moo博士与姚松一番交流后，奔雷公司很快就上线了“知识管理平台”软件，开始打造“知识云”。

　　首先，从顶层设计“知识构架”。姚松在各开发部门分别抽调了业务尖子组成了项目小组，并赋予他们“知识体系构架师（设计师）”的职责。“知识系统构架师”经过研究，搭建出横向和纵向的知识构架，横向上是专业知识，纵向上是行业知识。这些构架比较开放，维基贡献者可以自由上传任意形式的知识片段，而后再并为不同知识贴上标签，这些知识可以来自亲自操作的项目，也可以来自自己查阅文献，甚至可以来自从别人学到的经验……

　　其次，在平台上设置“运行规则”。技术尖子被赋予了第二个身份——“平台管理者（裁判员）”。在平台上，当两个以上的维基贡献者针对同一知识点上传了不同内容时，这就形成了一次“冲突”，这是后续操作的基础。一是“平台管理者”可以根据“冲突”找出正确的知识，实现纠错。二是平台管理者还可以根据“冲突”提取出“元知识”。有的知识包裹在不同的解决方案里，具有不同的项目特征，但是“元知识”都是一样的，倘若不同的解决方案都运用了“某块知识”，那么这些知识就是相对解决方案更基础知识，多次的“冲突”后，就可以提炼出“元知识”。三是维基贡献者上传知识后提出的“标签建议”也存在“冲突”，加上知识使用者在使用平台过程中留下的浏览痕迹（由平台软件记录分析），就可以实现“联动化”，确保使用者在搜索知识时的精确性。

　　这些操作中，“平台管理者”主要履行的就是对上传知识进行审核编辑的工作。由于搭建的是一个开放平台，“平台管理者”仅仅需要汇总分析“维基”上来的信息，并基于自身的技术储备进行甄别，“审核编辑”的工作自然变得更加容易。

　　更有意思的是，由于“知识管理平台”是一个可以溯源的系统，维基贡献者在每段贡献的知识下都会留下自己的身份痕迹。于是，在知识使用者需要对一段知识进行更加深入的了解时，其就可以根据平台提供的信息，直接找到知识的维基贡献者。

　　最后，奔雷为知识上传和知识使用都设计了激励机制。维基贡献者上传知识、纠正知识、提取标签、解答问题等行为都被设置了相应的激励政策。在这些行为之外，根据知识的使用频率、标签的搜索频率、使用知识后的评价和解答问题的评价也会有相应的激励措施。所有的激励措施都很实在，直接与薪酬和晋升相关。对于知识使用者来说，则是在绩效指标中锁定了“交货期”和“开发成本”两个指标，道理很简单，越多使用“知识库”也就越能减少开发时间和成本。

　　随后，在奔雷的“知识管理平台”上，已经不用姚松求爹爹告奶奶地催促大家“交作业”了，员工们纷纷维基上了各类知识，居然在1个月之内就基本搭建了完整的知识体系。另一方面，借由“知识云”，软件开发者也接收到了强大的支持，接到开发订单后，其可以直接选择合适的专业知识和行业知识以形成开发框架，再加入少部分项目的特有调整，一个定制软件就很快形成了，这大大提高了交货速度，降低了开发成本。而因为这朵“知识云”，奔雷在这次人员流失的“劫数”后，似乎也没有经历太长的复原期。更有意思的是，随着“知识管理平台”的持续运行，几个月后，员工已经越来越离不开这根“拐杖”。姚松以前的一项重要工作是盯紧重点人才，避免“挖角”，现在却发现这些人越来越被“知识管理平台”粘住。一个和他私交甚密的技术精英告诉他，现在工作轻松了，完成的业务量却更多了，收入渐长，哪有必要挪来挪去的？另外，就算挪到其他地方，没了这个“知识管理平台”，也很难保证有现在的工作效率……看着奔雷的变化，听到了一个个利好，雷景华的脸上露出了久违的笑容……

　　知识立方的逻辑

　　这是又一个我观察到的真实案例。

　　现有知识管理的模式多半是自上而下构建体系，即由知识管理的责任部门制定一个企业整体知识构架的框架，并根据框架同时下发模板，并由员工提交知识片段。这种模式存在两个弊端。

　　其一，知识体系的构建是单向的，这就意味着无法纠错和更新。无法纠错，是因为知识管理的权威方不具备纵览全局的知识，正如姚松和人力资源部在收集了知识后并不能进行审核和甄别。无法更新，是因为这种模式搭建的知识库是依靠管理者的命令，拥有知识的业务部门并没有强大内驱力去更新知识，结果自然是把上传知识看作是“交作业”，能躲就躲。

　　其二，知识缺乏体系性，仅仅是知识片段的无序聚合。正如姚松收集了一些知识片段，并为这些知识片段编号入库，但各种知识片段之间的关系仍然是模糊的，A知识片段与B知识片段之间的关系可能是包含，可能是被包含，可能是交叉，可能是根本没有关系，但究竟如何，谁也说不清楚。而且，知识片段是仍然孤立的，相互之间的联系被忽略了。

　　所以，传统的知识管理模式除了耗时耗力，是一个循序渐进的过程，而且还存在自身无法克服的弱点。姚松的第一次尝试失败就是这些缺陷的生动注解。还好，雷景华急于马上出成绩，见效果，这反而逼得姚松走向了“维基打造知识云”的新模式！

　　奔雷公司打造“知识云”的过程是一种快速高效的知识管理新模式，我把这种模式称为“知识立方”，这种模式克服了传统模式的两个固有缺陷。

　　第一，这种模式依靠一个互动式的企业2.0平台，在员工的互动中收集了知识。除了快速，其更大的意义在于通过员工的互动和“平台管理者”的审核，能够实现平台上知识的自我纠错，员工互动越频繁，在同一类知识上的冲突就越多，也越有利于“平台管理者”甄别出正确的知识。另外，由于设置了与薪酬和晋升直接相关的激励制度，更加强了员工为平台贡献知识的内驱力，而一旦员工具备了内驱力，就保证了“知识库”是“活水”。

　　第二，这种模式为知识片段之间建立了联系。一方面先是通过顶层设计为整体知识进行系统构架，划分大的模块，再由员工在互动中（由“平台管理员”）把大模块分解成小模块，以此类推，直到提炼出不能分解的“元知识”。另一方面是依靠“标签管理”为知识片段甚至“元知识”之间建立了联系，形成了使用知识的“线索”。“标签”同样是在互动中产生，一是标签建议的互动，二是知识使用者的浏览回馈，这确保了对于知识片段或者“元知识”的定位能够越来越精准。

　　知识立方是一种为打造“知识云”而建立的开放、灵动的立体知识构架，其本质上是一个方便所有员工随时贡献、分享知识的构架。构架上，对于知识的贡献会被拆解精炼为一个个知识片段或“元知识”，这些单元好似“小方块”，共同搭建成为“大立方”。而借由“标签管理”，知识的使用者可以使得“小方块”在立方上以一定的轨迹运动，形成相互之间的新组合，并被轻易搜索使用。

　　“知识立方”的模式贯彻了“云”的特征。首先，员工之间形成了一朵“人力资源云”。员工打破了组织边界，形成了以立体网络式的构架自由协作的可能，而激励政策的注入相当于一种“云计算法则”，导向了“云”上的员工开始协作，贡献知识。其次，知识片段之间形成了一朵“知识云”。知识片段形成了立体的网络构架，并可以通过优化后的“云计算法则”，即便于精确定位的标签，被轻易获取。无论是从贡献知识的效率，还是从使用知识的效率上说，这种模式都是知识管理的未来！