组织中不宜提倡个人知识管理（PKM），尤其是和组织业务相关的个人知识管理。
几年前，我还在某设计院画图。那时候的自己是个新手，负责弱电部分的设计，原理什么的都难不倒我这个电子专业的高才生，但是画图却让我非常头疼。设计院的产品就是图纸，不管什么样的设计思路，最终都要反应到图纸上，画图是表现自己技术水平的最关键因素，尤其是速度。作为新手，没有什么经验和积累，只能一笔一笔地画，还要符合规范的要求。工作的质量在于如何在图纸上准确清晰并且尽量简单的表达自己的设计思想，头几周一直为此而烦恼。明明是非常简单的东西，自己的图纸就是不过关，而且画的特别慢，一张图纸要花人家几倍的时间。后来虚心向老同事求教，发现每人都有一套自己的技巧和工具，设计绘图看似复杂，其实多数是重复性的工作，可以通过建立多种通用模块来提高绘图速度。每个工作几年的同事都建立了自己的一套体系，用起来得心应手。在要求他们复制给自己时却遭到拒绝，理由是你应该通过积累建立一套自己的体系，别人的肯定不如自己的好用。
后来，没等自己的体系建立起来，就离开了画图岗位转到信息中心。当时设计院高层是比较重视员工和部门之间知识共享的，技术部每年都组织优秀设计人员制定绘图规范，开发新的工具软件，总结好的经验，称之为业务建设。但是在推广这些成果的时候却总是遇到障碍，每个人尤其是老的优秀员工都习惯了自己的一套东西，组织开发的各种优秀成果都以不好用为理由被放弃或者拒绝。最终是业务建设年年搞，就是成果没人用，几年下来连最基本的图层规定都没有贯彻下去，给后来的信息化造成了非常巨大的麻烦。
本来，自己总结日常工作中的经验是非常好的事情，可是我们为什么又说组织中不宜提倡个人知识管理呢？
在一个组织中，从事同样或类似工作的成员往往不只一个人，当每个人都在进行个人知识管理时，无疑会形成重复劳动造成资源的浪费。我们承认，每个人所做的个人知识管理都是个性化的，符合自己特点的，从这一点上我们尊重每个人的需求。但是，我们也应该看到，对于从事类似工作的成员来讲，不管其个性化如何，其整理的知识内容应该是大致一致的，也就是说还有大量共性化的东西，而且这种共性化和个性化遵循帕累托原则，就是80％的内容是共性的，20％是个性化的。那么现在我们所面对的问题是，是应该为了满足20％的个性化而进行80％的重复劳动呢，还是节省80％的重复劳动去做更有意义的事情？要知道知识管理的主要出发点可是为了减少重复劳动，充分利用资源。只记得原来设计院的同事都是以有自己的一套东西为荣的，这似乎成了他的资历和水平的一种证明，至于每个人所做的重复性的工作，似乎从来没有人关注过。
每个人通过个人知识管理形成自己的习惯后，会阻碍组织向更有效率的平台上迁移。也就是说，提倡PKM，会阻碍组织KM系统的实施和推广。据调查，无论新旧系统性能差异如何，组织从旧系统向新系统迁移初期，其成员的工作效率下降都会超过50％。初期的这种效率下降，很容易为使用者找到拒绝新系统的借口，造成推广新系统的障碍。我所工作的设计院正是遇到了这种情况，很多同事的各种模块，基本内容是一样的，区别只在于图层设置和一些颜色差别，正是这些差别成为设计院统一图层颜色的最大障碍，谁也不愿意为了满足院里的规定去修改自己多年来积累下的成果。而且不管新的平台如何，总是不如自己习惯的东西，自己的东西几乎可以记得每个模块的位置，包括模块名称都是自己熟悉的；而新的系统显然无法满足所有人的需求，需要相当长时间的熟悉，因此新的平台总是以不好用为理由被打入冷宫，这种消极抵抗使设计院在业务建设上的投入年年打了水漂。
成熟的个人知识管理也会给知识共享的激励带来障碍。当年复制各种现成模块的请求被同事拒绝后，心里非常不痛快，不就是一些文件吗，有什么大不了的？后来，我理解了，虽然自己是个新手，还没有什么竞争力，但是那毕竟是别人多年工作经验的总结，也是一种劳动成果，怎么能轻易的就共享给别人呢？再说了，免费得到的东西就不会珍惜，只有自己辛苦整理的东西才会去好好用努力发掘其中的价值呢。后来在设计院的业务建设中，也和一些技术水平比较高的同事商量过，以业务建设经费换取他们的个人成果。如果只有个别同事有自己的一套东西还好，组织大家用还算容易。但是，每个人都有自己优秀的东西，换谁的不换谁的？本来不大的差异，有的可以换来业务建设经费，有的什么都没有，某种程度上更加剧了对业务建设成果的抵触。本来就比较困难的知识管理激励机制又加入了人为的政治因素，看来是更难了。
很多组织KM的目的是希望能以一定的形式将组织员工头脑中的知识固化并保留下来，避免人才流动所带来的损失。但是PKM不能在这方面带来任何好处，个人的知识管理仍然是个人的劳动成果，人走了，成果也就带走了。提倡PKM能帮助个人固化自己的知识并进行保留，能够帮助组织，那就只有天知，地知，他知，你知了。
PKM对个人而言是非常有用的工具，但是在组织中，尤其是希望能在知识管理方面有所成就的组织中，提倡PKM不是一个好的策略。
本文作者:孙洪波
作者联系方式：hbsun@sina.com
|