雷景华是一家国内软件企业——奔雷公司的创始人，最近的他火有点大。一年一度的“劫数”又触动了他那颗敏感的心。时值开年，头年奖金发放完毕后，一般都是跳槽的高峰期，而奔雷公司盘子不大，薪酬水平最多处于50分位，成熟人才自然被同行企业大量“收割”。软件行业的流失率本来就高，小企业甚至超过50%，奔雷公司的流失率在30%-35%之间，应该处于正常值。然而此时，员工频繁往返于各个项目，基本上是各自为战。而一旦有员工流失，项目就基本瘫痪，新人要接替工作，又只有从头学起，如此一来，复原期自然过长。
作为资深HR，姚松明白知识管理的工作实际就是“两化”。一是“标准化”，即用一个标准模板把员工的各类“知道但无法表达”的隐性知识提炼出来；二是“联动化”，就是发掘知识片段之间的关系，设置方便知识分享和利用的“线索”。被“线索”串起来的标准化知识片段就形成了企业的“知识库”。雷景华给了姚松3个月的项目周期。姚松苦不堪言，知识管理本来就是一个长周期的事，不仅知识库里的知识片段需要积累，要上规模才能见效益，而寻找串联知识的线索也需要时间，更何况提炼出的知识也需要检验……他理解民企老板“不见兔子不撒鹰”的习惯，雷景华要立竿见影，他也只有“摸着石头过河”。
姚松前思后想决定换个思路，如果放开限制，让他们自由互动呢？姚松突然想到，自己最近在某商业杂志上看到过一个发动员工一起“维基”完成工作的例子，这种现象被作者称为“人力资源云转型”。“维基”本来就是网络上的知识管理模式，用到企业里应该也可以吧！
姚松聘请了长期研究“人力资源云转型”现象Moo博士作为项目顾问。Moo博士为他分析了项目：“你的项目走入了两个误区。第一，知识管理不等于‘案例库建设’，知识管理的目的是使知识库里的知识片段能够最大程度上被广泛使用，这里，就需要提炼出‘元知识’。‘元知识’是最基础的流程、方法、技巧等，再特殊的项目也是由一个个单位的‘元知识’组成的。所以，提炼‘元知识’，并建立‘元知识’之间的‘线索’才是关键。你们做案例库，并没有提炼‘元知识’，反而让‘元知识’包裹在特殊的项目环境里，变得不可利用。第二，你们设置了自上而下的‘知识库’建设模式，如你所见，这种模式中，知识上规模慢，无法纠错，难以设置串联的”线索“……所以，新模式必须双向互动，而且能够随时互动。”
“就是说做在知识管理上做‘维基’是可行的？”姚松忍不住接话。“对，最好的‘知识库’应该是朵‘知识云’，由大量的‘线索’串联起众多的‘元知识’，而‘维基’是打造这朵‘知识云’的必由之路……
首先，从顶层设计“知识构架”。姚松在各开发部门分别抽调了业务尖子组成了项目小组，并赋予他们“知识体系构架师（设计师）”的职责。“知识系统构架师”经过研究，搭建出横向和纵向的知识构架，横向上是专业知识，纵向上是行业知识。这些构架比较开放，维基贡献者可以自由上传任意形式的知识片段，而后再并为不同知识贴上标签，这些知识可以来自亲自操作的项目，也可以来自自己查阅文献，甚至可以来自从别人学到的经验……
其次，在平台上设置“运行规则”。技术尖子被赋予了第二个身份——“平台管理者（裁判员）”。在平台上，当两个以上的维基贡献者针对同一知识点上传了不同内容时，这就形成了一次“冲突”，这是后续操作的基础。一是“平台管理者”可以根据“冲突”找出正确的知识，实现纠错。二是平台管理者还可以根据“冲突”提取出“元知识”。有的知识包裹在不同的解决方案里，具有不同的项目特征，但是“元知识”都是一样的，倘若不同的解决方案都运用了“某块知识”，那么这些知识就是相对解决方案更基础知识，多次的“冲突”后，就可以提炼出“元知识”。三是维基贡献者上传知识后提出的“标签建议”也存在“冲突”，加上知识使用者在使用平台过程中留下的浏览痕迹（由平台软件记录分析），就可以实现“联动化”，确保使用者在搜索知识时的精确性。
这些操作中，“平台管理者”主要履行的就是对上传知识进行审核编辑的工作。由于搭建的是一个开放平台，“平台管理者”仅仅需要汇总分析“维基”上来的信息，并基于自身的技术储备进行甄别，“审核编辑”的工作自然变得更加容易。
更有意思的是，由于“知识管理平台”是一个可以溯源的系统，维基贡献者在每段贡献的知识下都会留下自己的身份痕迹。于是，在知识使用者需要对一段知识进行更加深入的了解时，其就可以根据平台提供的信息，直接找到知识的维基贡献者。
最后，奔雷为知识上传和知识使用都设计了激励机制。维基贡献者上传知识、纠正知识、提取标签、解答问题等行为都被设置了相应的激励政策。在这些行为之外，根据知识的使用频率、标签的搜索频率、使用知识后的评价和解答问题的评价也会有相应的激励措施。所有的激励措施都很实在，直接与薪酬和晋升相关。对于知识使用者来说，则是在绩效指标中锁定了“交货期”和“开发成本”两个指标，道理很简单，越多使用“知识库”也就越能减少开发时间和成本。
随后，在奔雷的“知识管理平台”上，已经不用姚松求爹爹告奶奶地催促大家“交作业”了，员工们纷纷维基上了各类知识，居然在1个月之内就基本搭建了完整的知识体系。另一方面，借由“知识云”，软件开发者也接收到了强大的支持，接到开发订单后，其可以直接选择合适的专业知识和行业知识以形成开发框架，再加入少部分项目的特有调整，一个定制软件就很快形成了，这大大提高了交货速度，降低了开发成本。而因为这朵“知识云”，奔雷在这次人员流失的“劫数”后，似乎也没有经历太长的复原期。而看着这一切，雷景华的脸上终于露出了久违的笑容……
奔雷公司打造“知识云”的过程是一种快速高效的知识管理新模式，我把这种模式称为“知识立方”，这种模式克服了传统模式的两个固有缺陷。
第一，这种模式依靠一个互动式的企业2.0平台，在员工的互动中收集了知识。除了快速，其更大的意义在于通过员工的互动和“平台管理者”的审核，能够实现平台上知识的自我纠错，员工互动越频繁，在同一类知识上的冲突就越多，也越有利于“平台管理者”甄别出正确的知识。另外，由于设置了与薪酬和晋升直接相关的激励制度，更加强了员工为平台贡献知识的内驱力，而一旦员工具备了内驱力，就保证了“知识库”是“活水”。
第二，这种模式为知识片段之间建立了联系。一方面先是通过顶层设计为整体知识进行系统构架，划分大的模块，再由员工在互动中（由“平台管理员”）把大模块分解成小模块，以此类推，直到提炼出不能分解的“元知识”。另一方面是依靠“标签管理”为知识片段甚至“元知识”之间建立了联系，形成了使用知识的“线索”。“标签”同样是在互动中产生，一是标签建议的互动，二是知识使用者的浏览回馈，这确保了对于知识片段或者“元知识”的定位能够越来越精准。
知识立方是一种为打造“知识云”而建立的开放、灵动的立体知识构架，其本质上是一个方便所有员工随时贡献、分享知识的构架。构架上，对于知识的贡献会被拆解精炼为一个个知识片段或“元知识”，这些单元好似“小方块”，共同搭建成为“大立方”。而借由“标签管理”，知识的使用者可以使得“小方块”在立方上以一定的轨迹运动，形成相互之间的新组合，并被轻易搜索使用。
“知识立方”的模式贯彻了“云”的特征。首先，员工之间形成了一朵“人力资源云”。员工打破了组织边界，形成了以立体网络式的构架自由协作的可能，而激励政策的注入相当于一种“云计算法则”，导向了“云”上的员工开始协作，贡献知识。其次，知识片段之间形成了一朵“知识云”。知识片段形成了立体的网络构架，并可以通过优化后的“云计算法则”，即便于精确定位的标签，被轻易获取。无论是从贡献知识的效率，还是从使用知识的效率上说，这种模式都是知识管理的未来！
