专家经验都在个人电脑里，人一调岗就带走了：怎么把经验留在公司
问题通常不在员工不愿分享，而在三件事没做：没有固定的沉淀入口、没有判断哪些经验值得收、收进来之后没有放在别人能找到的地方。这三个环节里，前面两个是管理动作，第三个才是工具问题。
为什么会"人走经验走"
经验实际以哪些形式存在
大部分经验并不在正式文档里。它散落在几处：个人电脑里的项目文件夹、邮件往来、聊天记录，以及处理具体问题时的口口相传。正式归档的往往是成果件，而过程中做过的判断、踩过的坑、联系过的外部资源，基本没有留在组织的资料里。
三个常见断点
一是没有固定入口。谁想把经验存下来，得先自己找地方，多数人就此作罢。二是没有筛选标准。要求所有人把一切都写下来，结果是谁都写不完，后来什么都没写。三是没有位置。经验存进了个人目录，人在的时候只是"别人看不见"，人一走就变成"彻底没有"。
哪些经验值得沉淀
值得收的三类
判断依据类的经验更值得收：同样是这个情况，为什么当时选了这个处理方式，排除了哪些选项。处理异常类的也值得：标准流程走不通时是怎么绕过去的，哪一步比较容易出问题。外部关系与流程节点同样重要：这件事要找谁、卡在哪一环、什么时间点必须推进。
不值得收的两类
能在正式资料里查到的内容重复收一遍，只会增加噪音。一次性事务，比如某次活动的临时安排，也没有沉淀价值。判断标准可以简化成一句话：这件事下次遇到，接手的人能不能靠现有资料独立处理完。处理不了的，才需要补。
沉淀不是让人写总结，而是把已有产物归位
项目结项时顺手归位
项目结束时，过程件和成果件本来就都在。与其另外写一份总结，不如在这一步把该留的留下：定版文件按目录归位，被否决的方案和关键修改说明一并保留，这些内容本身就是经验。
把异常处理的过程留下来
处理异常的记录通常存在于聊天和邮件里。可行的做法是事后再用一小段说明补进相关目录：什么问题、怎么判断、为什么这样处理。不必写成报告，一段话即可，重点是让后来的人知道当时不是随手决定的。
交接时补一份说明
人员调岗或退休前的交接，是沉淀经验成本较低的时点。这时不需要他回忆整理，只需要对照手上的目录，逐个说明哪些还在用、哪些已经作废、哪些只有他知道来龙去脉。补完这份说明，接手人才算真的接住了。
收进来之后要能被找到
先解决归属，再解决检索
一份经验放进哪个目录，决定了谁会看到它。归属不清的内容，检索再强也找不到。先把目录层级和归属规则定下来，让每一类内容有确定的家，是后面几步的前提。
给内容补上可检索的属性
文件名能表达的信息有限。补上标签和属性字段——所属项目、涉及的专业领域、适用岗位、生效时间——检索时就多出几条能对上的路径。这一步的投入不大，但对"以前有人处理过类似问题吗"这类提问，效果差别明显。
从哪里开始
先挑一个岗位，不要全公司铺开
经验沉淀比较怕一上来就要求全员参与。选一个人员流动相对频繁、经验密度又比较高的岗位，先把这一个岗位的沉淀路径跑通：目录怎么定、哪些内容进、谁负责补。跑顺之后再复制到第二个岗位，比一开始就定一套面向全公司的规则更容易落地。
以够快云库为例，这些动作落在系统里是什么样
以够快云库为例，企业文件集中存放在统一的树状目录结构下，不同部门与项目的资料各有归属；文件可以补充标签与元数据字段，检索时支持分词与模糊搜索，可按文件名、类型、时间、修改人定位；文件的历史版本会被保留，过程中被修改或否决的内容不会因为定版而消失；同事之间还能对文件直接添加评论，把"当时为什么这么定"留在文件上。人员变动时，成员个人数据移交可以把离职或调岗人员名下的文件交接给接手人，避免资料跟着账号一起失联。
常见问题
要求员工写经验总结，为什么执行不下去？因为它是额外工作。更可行的做法是把沉淀挂到已有的节点上——项目结项、异常处理完、人员交接时，这几处本来就有动作，顺手归位比另起一份总结容易坚持。
哪些内容算经验，边界怎么划？用一个问题判断：这件事下次遇到，接手的人能不能靠现有资料独立处理。能，就不必重复收；不能，就说明还有没留下的部分。
经验存进云盘之后，怎么保证别人找得到？两件事：归属清楚和属性齐全。内容放在哪个目录决定了谁会看到它，标签与属性字段则决定了能不能被检索命中。只做其中一件，效果都会打折。
老员工不愿意把经验交出来怎么办？先看是不是"交出来"这个动作本身太难。如果只是把已有的目录和文件按归属放好、再补一段说明，多数人是愿意做的。真正卡住的往往是没有明确要求、也不知道该交给谁。
要不要专门上一套知识管理系统？先跑通一个岗位再判断。如果问题集中在目录归属、检索路径和人员交接上，现有文件管理体系补齐即可；如果确实需要结构化的知识条目、问答式的检索，再考虑专门的系统。
