为什么多NB的知识管理软件和工具，都无法解决企业的知识管理问题
知识与信息同属一个连续体，但并非同一概念，且知识问题无法仅通过信息工具解决。
客户常常会向我们提出这样的需求：“我们存在知识管理方面的问题。项目团队无法获取完成项目所需的知识，希望你们能协助我们开发一个更完善的系统，用于存储和获取项目信息。”
他们面临的确实是知识问题，具体表现为无法获取项目知识。但他们认为这类问题可以通过分类法、元数据、门户平台和搜索功能等信息工具来解决，觉得只要能更便捷地获取项目文档，问题就能迎刃而解。然而，知识问题无法仅靠信息工具解决（我强调 “仅靠”，是因为这些工具最终会成为知识管理框架的一部分），原因如下：
首先，组织内部的大部分知识从未被转化为信息形式进行记录。
人们所知的远比能表达的多，能表达的又远比能书面记录的多。据估计，组织中高达 80% 的知识都未形成文档，只能通过人际网络、实践社区以及 “同行协助”“知识交流” 等对话式流程获取。信息工具无法触及这类知识。
其次，一个常见问题（也是前一点的必然结果）是，项目知识可能从未被记录在项目文档中。
项目团队可能从未产出过知识产品，因为工作计划中根本未包含相关任务，也没有专人负责此项工作，导致知识始终未被记录。有些项目或许会零散记录一些简短的经验教训，但由于缺乏对内容质量的管控，这些记录往往质量低下。要让这类知识首先得以记录，就必须引入团队反思和经验总结流程，并明确相关责任与质量管控机制。因此，即便能更便捷地获取项目文档，也可能出现以下情况：
- 能了解项目做了什么，却无法知晓团队从中学到了什么，或事后反思时认为本该采取哪些不同做法；
- 能看到项目的支出情况，却无法得知价值来源，也不明白超支的原因；
- 能找到演示文稿和报告，却看不到对成败原因的分析。
第三，（由前两点衍生出的）另一个问题是，绝大多数项目信息本身并不属于知识范畴。
若将项目文档作为知识来源，相当于依赖一种高度稀释的信息源 —— 其中冗余信息多，有效知识少。许多文档仅具备事务性用途（如报告、备忘录、发票、图表），即便搜索功能再强大，从中寻找知识内容也如同 “大海捞针”。若想留存和传递 “针”（指知识），“干草堆”（指普通项目文档）绝非合适的存放之处。
第四，即便项目文档中包含已整理成文的知识，这些知识也往往分散在众多文档和不同项目中。
比如，项目 A 可能在某个特定流程、产品或客户方面积累了少量经验，项目 B、C、E、Z 也可能有类似零散知识，但如果没有明确的责任分工和专门流程，这些零散知识就无法被整合、提炼为系统性的知识体系。管理零散知识与管理完整的知识体系，是截然不同的两件事。
最后，许多知识问题本质上与文化相关。
无论经验总结多么重要，员工的激励机制都倾向于让他们急于投入下一项工作，而非花时间反思经验教训；有些员工不愿分享知识，认为将知识据为己有有助于提升自身在组织内的地位和价值；还有员工存在 “非我发明综合征”，宁愿重新摸索，也不愿借鉴已有经验。如果员工本身没有获取知识的意愿，即便找到知识也不愿运用，那么整理项目信息便毫无意义。我常常用教孩子读书的例子来类比：首先要培养孩子对书籍的热爱，让他们渴望阅读故事，之后再去整理藏书 —— 整理是后续步骤。同理，在知识管理中，要让组织发挥信息整理的作用，第一步便是培养员工对知识的渴望。
只有当我们确保以下几点后，信息工具才能真正发挥出色的辅助作用（成为我上周提到的知识工作流程中的一部分）：项目知识得到收集、项目产出高质量的知识产品、这些知识产品被整合为系统性知识体系，并且组织内部存在对知识的需求、员工会主动去获取知识。
优化信息管理有助于解决知识问题，但无法仅凭信息管理独立解决。若存在知识问题，不仅需要信息管理，更需要知识管理。
来源：Nick Milton博客
原文标题：Why you can’t solve knowledge problems with information tools alone
相关链接
企业AI知识库搭建与运营培训课程
呼叫中心AI知识库培训课程
个人知识体系构建能力课程
