雷景华是一家国内软件企业——奔雷公司的创始人，最近的他火有点大。一年一度的“劫数”又触动了他那颗敏感的心。
时值开年，头年奖金发放完毕后，一般都是跳槽的高峰期，而奔雷公司盘子不大，薪酬水平最多处于50分位，成熟人才自然被同行企业大量“收割”。软件行业的流失率本来就高，小企业甚至超过50%，奔雷公司的流失率在30%-35%之间，应该处于正常值。
雷景华知道避不开“劫数”，但他怕的是，每年的“劫数”后，奔雷公司往往要恢复半年左右，运营才能恢复原有水平。奔雷公司是处于初生期的企业，这几年为了抢占市场份额，在营销上四处出击，全力接单，根本不可能考虑内部资源（人才）是否跟得上。此时，员工频繁往返于各个项目，基本上是各自为战。而一旦有员工流失，项目就基本瘫痪，新人要接替工作，又只有从头学起，如此一来，复原期自然过长。
复原期长的问题也只是冰山一角，市场的压力早就倒逼到了奔雷公司。市场营销部就多次指责软件开发部门产品不力，引来客户投诉。客户一来埋怨产品交货期长，二来埋怨产品维护升级不力。开发和维护人员不变还好，一旦人员流动，为老客户开发或维护产品都必须由新技术员重新沟通获得对方信息。市场营销部骂得最凶的还是产品的开发成本。没有强势品牌，自然希望从价格上找优势，无奈奔雷的产品开发成本实在太高，销售根本没有市场操作的空间。
每次这些问题拿到台面上，雷景华都是批评软件开发部门，但这一年里，EMBA课程和外部咨询机构的启发逐渐让他明白，所有问题的症结是知识管理。正因为员工的个人知识没有被组织提取，形成可以被所有人分享利用的“组织知识”，人人只有自起炉灶，知识没有标准化，管理知识的规模效应没有发挥出来，才会有这一系列的问题。
正当雷景华开始思量如何解决，“劫数”就如期而至。不能再等了！他叫来人力资源部门经理姚松，不由分说地分下了任务。
瘫痪的知识管理
作为资深HR，姚松明白知识管理的工作实际就是“两化”。一是“标准化”，即用一个标准模板把员工的各类“知道但无法表达”的隐性知识提炼出来；二是“联动化”，就是发掘知识片段之间的关系，设置方便知识分享和利用的“线索”。被“线索”串起来的标准化知识片段就形成了企业的“知识库”。
雷景华给了姚松3个月的项目周期。姚松苦不堪言，知识管理本来就是一个长周期的事，不仅知识库里的知识片段需要积累，要上规模才能见效益，而寻找串联知识的线索也需要时间，更何况提炼出的知识也需要检验……他理解民企老板“不见兔子不撒鹰”的习惯，雷景华要立竿见影，他也只有“摸着石头过河”。
姚松冥思苦想，想到用“案例库建设”来暗度陈仓。这样做也有他的道理，要软件开发部门重新去构架自己的知识，这么大的工程，人家忙于业务哪里会搭理你？况且，所有部门尽管对接不同行业和专业的客户，但他们的知识中有很大一块是公用部分，针对这块知识，大家提交上来的东西如果五花八门，又该听谁的？知识管理的规范流程就是要组织专家反复讨论、设计，但雷景华显然没有给他姚松这个时间。
还是做案例好！姚松的逻辑是，案例是最直观，最能够被模仿的，实际上就是大量知识的载体，关键是，按照标准模板上报的案例，根本就不用进行二次处理和检验，直接就可以快速聚合形成“知识库”，根本不用考虑他们之间的关系（因为都是平行的），至于“线索”，设置简单的“关键词”进行联动即可。奔雷业务模块的组织结构是由几个开发部门直接对接几个行业，于是，姚松开始督促他们按照模板提交“标准化知识”。而模板是人力资源部在访谈了几个技术人员后制定的。
不料，模板下发后却遭遇了各开发部门的强烈不满，虽然考虑做案例可以减少软件开发部门的负担，但大家还是纷纷埋怨自己忙于业务的同时还要完成人力资源部的“作业”，有的开发部门还直接扔回了狠话，“要交你们的作业也可以，耽误了订单交货，你们要负责任！”碰上一些愿意配合的，也老是反馈说模板不对，用起来别扭。好不容易在多次沟通后回收了几个开发部门的“作业”，姚松赶紧组织下属进行编号，并上传到了公司的内网上。而后，人力资源部又在公司内进行了宣传，号召大家多多利用“知识库”降低开发成本。
从此，姚松就天天关注“知识库”的下载量。头几天，下载量还比较大，可几天一过，下载量急剧走低，直到门可罗雀。姚松心有不甘，连忙打亲自电话到每个开发部门询问原因。原来，上传“知识库”的案例虽然直观，但其背后却包括了大量的专业知识（如人力资源管理、财务管理软件）和行业知识（如银行业、移动通讯业），不同的组合呈现出不同的解决模式，再加上软件工程师们自己的开发习惯，案例变得过于独特看，根本不能模仿。想使用关键词搜索，截取能够利用的知识片段，但一个关键词反馈回来几个案例，个个自成一派，走的是不同路径，根本不兼容，到底模仿哪个？等把这些案例都读通了，黄花菜都凉了！更有部门反馈，有的案例根本是绕了弯路，模仿等于是自讨苦吃。
打造“知识云”
姚松前思后想，自己发动开发部门贡献知识肯定没错，只是自己提供的“案例模板”好像反而限制了他们，但如果不加限制，大家提交的东西又怎么整合呢？换个思路，如果放开限制，让他们自由互动呢？姚松突然想到，自己最近在某商业杂志上看到过一个发动员工一起“维基”完成工作的例子，这种现象被作者称为“人力资源云转型”。“维基”本来就是网络上的知识管理模式，用到企业里应该也可以吧！
姚松聘请了长期研究“人力资源云转型”现象Moo博士作为项目顾问。Moo博士为他分析了项目：“你的项目走入了两个误区。第一，知识管理不等于‘案例库建设’，知识管理的目的是使知识库里的知识片段能够最大程度上被广泛使用，这里，就需要提炼出‘元知识’。‘元知识’是最基础的流程、方法、技巧等，再特殊的项目也是由一个个单位的‘元知识’组成的。所以，提炼‘元知识’，并建立‘元知识’之间的‘线索’才是关键。你们做案例库，并没有提炼‘元知识’，反而让‘元知识’包裹在特殊的项目环境里，变得不可利用。第二，你们设置了自上而下的‘知识库’建设模式，如你所见，这种模式中，知识上规模慢，无法纠错，难以设置串联的“线索”……所以，新模式必须双向互动，而且能够随时互动。”
“就是说做在知识管理上做‘维基’是可行的？”姚松忍不住接话。“对，最好的‘知识库’应该是朵‘知识云’，由大量的‘线索’串联起众多的‘元知识’，而‘维基’是打造这朵‘知识云’的必由之路……
Moo博士与姚松一番交流后，奔雷公司很快就上线了“知识管理平台”软件，开始打造“知识云”。
首先，从顶层设计“知识构架”。姚松在各开发部门分别抽调了业务尖子组成了项目小组，并赋予他们“知识体系构架师（设计师）”的职责。“知识系统构架师”经过研究，搭建出横向和纵向的知识构架，横向上是专业知识，纵向上是行业知识。这些构架比较开放，维基贡献者可以自由上传任意形式的知识片段，而后再并为不同知识贴上标签，这些知识可以来自亲自操作的项目，也可以来自自己查阅文献，甚至可以来自从别人学到的经验……
其次，在平台上设置“运行规则”。技术尖子被赋予了第二个身份——“平台管理者（裁判员）”。在平台上，当两个以上的维基贡献者针对同一知识点上传了不同内容时，这就形成了一次“冲突”，这是后续操作的基础。一是“平台管理者”可以根据“冲突”找出正确的知识，实现纠错。二是平台管理者还可以根据“冲突”提取出“元知识”。有的知识包裹在不同的解决方案里，具有不同的项目特征，但是“元知识”都是一样的，倘若不同的解决方案都运用了“某块知识”，那么这些知识就是相对解决方案更基础知识，多次的“冲突”后，就可以提炼出“元知识”。三是维基贡献者上传知识后提出的“标签建议”也存在“冲突”，加上知识使用者在使用平台过程中留下的浏览痕迹（由平台软件记录分析），就可以实现“联动化”，确保使用者在搜索知识时的精确性。
这些操作中，“平台管理者”主要履行的就是对上传知识进行审核编辑的工作。由于搭建的是一个开放平台，“平台管理者”仅仅需要汇总分析“维基”上来的信息，并基于自身的技术储备进行甄别，“审核编辑”的工作自然变得更加容易。
更有意思的是，由于“知识管理平台”是一个可以溯源的系统
时值开年，头年奖金发放完毕后，一般都是跳槽的高峰期，而奔雷公司盘子不大，薪酬水平最多处于50分位，成熟人才自然被同行企业大量“收割”。软件行业的流失率本来就高，小企业甚至超过50%，奔雷公司的流失率在30%-35%之间，应该处于正常值。
雷景华知道避不开“劫数”，但他怕的是，每年的“劫数”后，奔雷公司往往要恢复半年左右，运营才能恢复原有水平。奔雷公司是处于初生期的企业，这几年为了抢占市场份额，在营销上四处出击，全力接单，根本不可能考虑内部资源（人才）是否跟得上。此时，员工频繁往返于各个项目，基本上是各自为战。而一旦有员工流失，项目就基本瘫痪，新人要接替工作，又只有从头学起，如此一来，复原期自然过长。
复原期长的问题也只是冰山一角，市场的压力早就倒逼到了奔雷公司。市场营销部就多次指责软件开发部门产品不力，引来客户投诉。客户一来埋怨产品交货期长，二来埋怨产品维护升级不力。开发和维护人员不变还好，一旦人员流动，为老客户开发或维护产品都必须由新技术员重新沟通获得对方信息。市场营销部骂得最凶的还是产品的开发成本。没有强势品牌，自然希望从价格上找优势，无奈奔雷的产品开发成本实在太高，销售根本没有市场操作的空间。
每次这些问题拿到台面上，雷景华都是批评软件开发部门，但这一年里，EMBA课程和外部咨询机构的启发逐渐让他明白，所有问题的症结是知识管理。正因为员工的个人知识没有被组织提取，形成可以被所有人分享利用的“组织知识”，人人只有自起炉灶，知识没有标准化，管理知识的规模效应没有发挥出来，才会有这一系列的问题。
正当雷景华开始思量如何解决，“劫数”就如期而至。不能再等了！他叫来人力资源部门经理姚松，不由分说地分下了任务。
瘫痪的知识管理
作为资深HR，姚松明白知识管理的工作实际就是“两化”。一是“标准化”，即用一个标准模板把员工的各类“知道但无法表达”的隐性知识提炼出来；二是“联动化”，就是发掘知识片段之间的关系，设置方便知识分享和利用的“线索”。被“线索”串起来的标准化知识片段就形成了企业的“知识库”。
雷景华给了姚松3个月的项目周期。姚松苦不堪言，知识管理本来就是一个长周期的事，不仅知识库里的知识片段需要积累，要上规模才能见效益，而寻找串联知识的线索也需要时间，更何况提炼出的知识也需要检验……他理解民企老板“不见兔子不撒鹰”的习惯，雷景华要立竿见影，他也只有“摸着石头过河”。
姚松冥思苦想，想到用“案例库建设”来暗度陈仓。这样做也有他的道理，要软件开发部门重新去构架自己的知识，这么大的工程，人家忙于业务哪里会搭理你？况且，所有部门尽管对接不同行业和专业的客户，但他们的知识中有很大一块是公用部分，针对这块知识，大家提交上来的东西如果五花八门，又该听谁的？知识管理的规范流程就是要组织专家反复讨论、设计，但雷景华显然没有给他姚松这个时间。
还是做案例好！姚松的逻辑是，案例是最直观，最能够被模仿的，实际上就是大量知识的载体，关键是，按照标准模板上报的案例，根本就不用进行二次处理和检验，直接就可以快速聚合形成“知识库”，根本不用考虑他们之间的关系（因为都是平行的），至于“线索”，设置简单的“关键词”进行联动即可。奔雷业务模块的组织结构是由几个开发部门直接对接几个行业，于是，姚松开始督促他们按照模板提交“标准化知识”。而模板是人力资源部在访谈了几个技术人员后制定的。
不料，模板下发后却遭遇了各开发部门的强烈不满，虽然考虑做案例可以减少软件开发部门的负担，但大家还是纷纷埋怨自己忙于业务的同时还要完成人力资源部的“作业”，有的开发部门还直接扔回了狠话，“要交你们的作业也可以，耽误了订单交货，你们要负责任！”碰上一些愿意配合的，也老是反馈说模板不对，用起来别扭。好不容易在多次沟通后回收了几个开发部门的“作业”，姚松赶紧组织下属进行编号，并上传到了公司的内网上。而后，人力资源部又在公司内进行了宣传，号召大家多多利用“知识库”降低开发成本。
从此，姚松就天天关注“知识库”的下载量。头几天，下载量还比较大，可几天一过，下载量急剧走低，直到门可罗雀。姚松心有不甘，连忙打亲自电话到每个开发部门询问原因。原来，上传“知识库”的案例虽然直观，但其背后却包括了大量的专业知识（如人力资源管理、财务管理软件）和行业知识（如银行业、移动通讯业），不同的组合呈现出不同的解决模式，再加上软件工程师们自己的开发习惯，案例变得过于独特看，根本不能模仿。想使用关键词搜索，截取能够利用的知识片段，但一个关键词反馈回来几个案例，个个自成一派，走的是不同路径，根本不兼容，到底模仿哪个？等把这些案例都读通了，黄花菜都凉了！更有部门反馈，有的案例根本是绕了弯路，模仿等于是自讨苦吃。
打造“知识云”
姚松前思后想，自己发动开发部门贡献知识肯定没错，只是自己提供的“案例模板”好像反而限制了他们，但如果不加限制，大家提交的东西又怎么整合呢？换个思路，如果放开限制，让他们自由互动呢？姚松突然想到，自己最近在某商业杂志上看到过一个发动员工一起“维基”完成工作的例子，这种现象被作者称为“人力资源云转型”。“维基”本来就是网络上的知识管理模式，用到企业里应该也可以吧！
姚松聘请了长期研究“人力资源云转型”现象Moo博士作为项目顾问。Moo博士为他分析了项目：“你的项目走入了两个误区。第一，知识管理不等于‘案例库建设’，知识管理的目的是使知识库里的知识片段能够最大程度上被广泛使用，这里，就需要提炼出‘元知识’。‘元知识’是最基础的流程、方法、技巧等，再特殊的项目也是由一个个单位的‘元知识’组成的。所以，提炼‘元知识’，并建立‘元知识’之间的‘线索’才是关键。你们做案例库，并没有提炼‘元知识’，反而让‘元知识’包裹在特殊的项目环境里，变得不可利用。第二，你们设置了自上而下的‘知识库’建设模式，如你所见，这种模式中，知识上规模慢，无法纠错，难以设置串联的“线索”……所以，新模式必须双向互动，而且能够随时互动。”
“就是说做在知识管理上做‘维基’是可行的？”姚松忍不住接话。“对，最好的‘知识库’应该是朵‘知识云’，由大量的‘线索’串联起众多的‘元知识’，而‘维基’是打造这朵‘知识云’的必由之路……
Moo博士与姚松一番交流后，奔雷公司很快就上线了“知识管理平台”软件，开始打造“知识云”。
首先，从顶层设计“知识构架”。姚松在各开发部门分别抽调了业务尖子组成了项目小组，并赋予他们“知识体系构架师（设计师）”的职责。“知识系统构架师”经过研究，搭建出横向和纵向的知识构架，横向上是专业知识，纵向上是行业知识。这些构架比较开放，维基贡献者可以自由上传任意形式的知识片段，而后再并为不同知识贴上标签，这些知识可以来自亲自操作的项目，也可以来自自己查阅文献，甚至可以来自从别人学到的经验……
其次，在平台上设置“运行规则”。技术尖子被赋予了第二个身份——“平台管理者（裁判员）”。在平台上，当两个以上的维基贡献者针对同一知识点上传了不同内容时，这就形成了一次“冲突”，这是后续操作的基础。一是“平台管理者”可以根据“冲突”找出正确的知识，实现纠错。二是平台管理者还可以根据“冲突”提取出“元知识”。有的知识包裹在不同的解决方案里，具有不同的项目特征，但是“元知识”都是一样的，倘若不同的解决方案都运用了“某块知识”，那么这些知识就是相对解决方案更基础知识，多次的“冲突”后，就可以提炼出“元知识”。三是维基贡献者上传知识后提出的“标签建议”也存在“冲突”，加上知识使用者在使用平台过程中留下的浏览痕迹（由平台软件记录分析），就可以实现“联动化”，确保使用者在搜索知识时的精确性。
这些操作中，“平台管理者”主要履行的就是对上传知识进行审核编辑的工作。由于搭建的是一个开放平台，“平台管理者”仅仅需要汇总分析“维基”上来的信息，并基于自身的技术储备进行甄别，“审核编辑”的工作自然变得更加容易。
更有意思的是，由于“知识管理平台”是一个可以溯源的系统
