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