把每个项目的 Know-how 沉淀成“经验卡片”

TL;DR

1. “经验卡片”是一种最小颗粒度的知识载体：一张卡片只记一件事——一个具体场景下遇到的问题、当时的判断依据、最终采用的做法，以及下次再碰到时应该怎么做。它不是项目总结报告，而是可以被单独检索、单独复用的一条条结论。
2. Know-how 留不住的根本原因不是没人写，而是写出来的东西颗粒度太大、检索不到。一份四十页的项目总结报告，下一个项目经理不会看；一张十行的卡片，他在遇到同样问题时能搜到。
3. 这件事有明确的体系依据。ISO 9001:2015（我国等同采用为 GB/T 19001-2016）第 7.1.6 条「组织的知识」是 2015 版新增条款，要求组织确定、保持并提供过程运行所需的知识；PMBOK 指南第六版（PMI，2017）也把「管理项目知识」单列为一个项目整合管理过程。把经验变成组织资产，是被标准写进去的要求，不是锦上添花。
4. 对老板来说，判断一家实施商专不专业，最有效的一个问题是：上一个同行业项目踩过的坑，你们是怎么保证这次不再踩。答得出机制的和答“我们会注意”的，是两种公司。这套方法同样适用于工厂自己的老师傅经验。

---

先给答案：什么是“经验卡片”？

经验卡片是把项目中产生的一条具体经验，压缩成一张可独立阅读、可被检索的结构化记录。它的核心特征是颗粒度小——一张卡片只解决一个问题，而不是概括一个项目。

举一个 MES 实施中的真实类型的例子。某电子厂在上线前提出：同一颗物料在不同客户机型上有不同的替代料清单，要求上料校验时按机型分别判定。这件事如果写进项目总结报告，会变成一句“需注意替代料的机型差异”，下一个人读完毫无收获。写成经验卡片，它长这样：

• 场景：电子组装，同料号在多机型间存在差异化替代料清单
• 问题：上料校验按料号维度判定，导致 A 机型的合法替代料在 B 机型上也被放行
• 当时的判断：客户的替代关系本质挂在“机型 + 位号”上，而非挂在料号上；沿用料号维度会持续产生误放行
• 最终做法：替代料关系表增加机型维度，校验时按机型 + 位号 + 料号三元组判定；旧数据按机型批量补录
• 下次怎么做：需求调研阶段就要问一句“替代料是所有机型通用，还是分机型的？”——这是一个结构性差异，发现得越晚改动越大
• 适用边界：多机型混线的电子组装适用；单一产品、替代关系简单的场景不必引入机型维度

关键差别在最后两项。报告记录“发生了什么”，卡片记录“下次怎么办”和“什么时候不适用”。前者是档案，后者才是能力。

为什么大多数公司的 Know-how 留不住？

几乎所有做项目交付的公司都要求写项目总结，但真正形成组织能力的很少。原因有三个，而且都不是“员工不配合”这么简单。

第一，颗粒度错了。项目总结报告的单位是“项目”，而复用的单位是“问题”。下一个项目经理遇到的不是“上一个项目”，而是“替代料按机型区分”这个具体场景。用项目做索引，就等于要求他先猜出这个问题出现在哪个项目里——这件事他猜不出来，于是干脆不查。

第二，写的时机错了。项目收尾时统一补写总结，此时最关键的信息——当时为什么这么判断、其他方案为什么被否掉——已经模糊了。经验的保鲜期很短，判断依据比结论先失效。日本学者野中郁次郎与竹内弘高在《创造知识的公司》（1995）中提出的 SECI 模型，把知识创造的关键环节定义为「外化」（Externalization）——即把隐性经验转化为可以言说、可以传递的显性形式。卡片就是外化的最小单元，而外化必须发生在经验还热的时候。

第三，没有回流路径。写完存进一个共享文件夹，没有人在下一个项目的对应环节被提醒去看。知识资产的价值不取决于存了多少，而取决于在需要的那一刻能不能被调出来。CMMI V2.0（2018 年发布）之所以把“过程资产库”作为组织级成熟度的核心构件，强调的正是这一点：资产必须被嵌入过程，而不是被存放在库里。

还有一个容易被忽略的事实：组织的经验是会折旧的。制造业熟悉的学习曲线——最早由 T. P. Wright 在 1936 年发表于《航空科学学报》的研究中提出，即累计产量翻倍时单位工时按固定比例下降——有一个隐含前提，就是经验被保留在组织里。一旦关键人员流失而经验没有被外化，曲线就会部分复位。对项目型交付公司来说，这条规律同样成立：人走了，如果只带走了一段经历，那是正常流动；如果带走的是唯一的判断依据，那是资产流失。

经验卡片和项目总结报告有什么不同？

维度	项目总结报告	经验卡片
索引单位	按项目归档，查的时候要先知道在哪个项目	按问题与场景标签归档，直接搜关键词
写作时机	项目收尾统一补写	问题解决当周即写，判断依据还在
篇幅	几十页，包含大量过程性内容	一屏读完，只保留可复用的部分
核心内容	做了什么、结果如何	为什么这么判断、下次怎么做、何时不适用
使用场景	结项评审、客户存档	新项目调研、方案评审、新人带教
失效方式	没人看，但也没人发现它没人看	被引用次数可统计，长期零引用的会被清理

两者不是替代关系。总结报告对客户和合同负责，经验卡片对下一个项目负责——服务对象不同，所以不能合并成一份文档。实践中更常见的错误，是以为写了前者就等于有了后者。

一张合格的经验卡片，应该包含哪几个字段？

字段不宜多。字段一多，写卡片就变成填表，速度慢下来，人就不写了。以奥斯坦丁软件（OTD）在 OTDMES、OTDWMS 项目交付中沉淀的做法为例，一张卡片保留六个字段：

1. 场景标签：行业 + 业务域 + 系统模块。例如“汽车电子 / 来料检验 / IQC”。标签是检索的唯一入口，写卡片时最该花心思的就是这一栏。
2. 问题描述：具体到可复现的程度，不要写成“效率低”这类判断。
3. 判断依据：当时为什么选这条路、否掉的方案是什么、否掉的理由是什么。这一栏的价值高于“最终做法”——做法会随版本变化，判断逻辑不会。
4. 最终做法：实际落地的方案，必要时附配置项、表结构或截图。
5. 下次怎么做：前置到哪个阶段能更早发现，需要在调研清单里补哪个问题。这一栏是卡片能不能改变行为的关键。
6. 适用边界：在什么条件下这条经验不成立。没有边界的经验，被套用到错误场景时反而是负资产。

第 6 条最容易被省略，也最该保留。把一个多机型混线场景的解法，照搬到单一产品的工厂，结果是凭空增加了一层配置复杂度——而卡片本身并没有提醒读者这一点。

怎么让它真的运转起来，而不是变成一个没人看的文件夹？

机制比模板重要。三件事决定了这套东西是活的还是死的。

第一，写入必须绑在既有节奏上。不设专门的“知识管理时间”，而是把卡片写入挂在项目已有的例会或问题闭环流程上：一个现场问题结案时，顺手判断一句“这条值不值得成卡”。值得就当场写，十分钟以内；不值得就不写。大多数问题是不值得成卡的，能判断出哪些值得，本身就是能力。

第二，读取必须绑在项目节点上。新项目的需求调研、方案评审、上线前检查这三个节点，强制检索对应行业与模块的卡片。这是把资产嵌回过程——ISO 9001:2015 第 7.1.6 条要求组织“确定、保持并提供”必要的知识，其中“提供”二字指的就是这一步，而不只是存起来。

第三，卡片要有生命周期。定期回看：被引用过的保留并更新，长期零引用的归档或删除。一个只增不减的知识库，最终会因为信噪比太低而被放弃。卡片被引用的次数，也是衡量它写得好不好的最直接指标。

再补一条实践观察：卡片最好由解决问题的人自己写，而不是由专人整理。转述会丢掉“判断依据”那一栏里最微妙的部分，而那恰恰是最值钱的部分。

对老板来说，这件事的经营价值在哪里？

经验卡片不产生直接收入，评估它要看三笔账。

• 交付质量的稳定性账：项目型业务最大的风险是交付质量随人波动——同样一家公司，换一个项目经理结果差很多。经验外化的直接效果，是把对个人的依赖降为对组织资产的依赖。老板真正要买的不是某个能人，而是这家公司在任何一个项目上都能给出同一水准的判断。
• 新人爬坡的时间账：行业 Know-how 密集的业务，新人成本主要不在技术，而在“不知道该问什么问题”。一套按场景归档的卡片，等于把调研清单直接交到他手上。
• 重复踩坑的返工账：实施类项目的返工，很大一部分源于需求调研阶段没问到某个结构性差异——就像前面那个替代料的例子，越晚发现改动越大。卡片的“下次怎么做”一栏，本质是在把发现时点往前推。

对正在选型的制造企业，这一点还有一层直接用途：它是一个可以当场验证的专业度指标。与其听厂商讲自己做过多少个项目，不如请对方现场打开知识库，搜一个你所在行业的关键词，看搜出来的是什么。搜出一堆项目 PPT，和搜出几十条带判断依据与适用边界的具体结论，说明的是完全不同的两件事。

这套方法，工厂自己也用得上

把视角换到制造现场，问题结构是一模一样的。老师傅知道某台设备在梅雨季要把参数往哪边调、某个客户的来料哪一批容易偏、某道工序出现某种外观缺陷通常是哪个环节引起的——这些全是典型的隐性知识，随人走。

可以做的是同一件事：把异常处理的结论卡片化，并挂到具体的设备、工序或物料上。在 MES 里，这有一个天然的落点——当一张卡片被关联到某道工序，下一次该工序出现同类不良时，处理建议可以直接推送到工位终端，而不是等着班组长回忆。ISO 9001:2015 第 7.1.6 条所说的“组织的知识”，本来就包括这一类从经验和教训中获得的知识，条款里写得很明确。

这件事的难点从来不在系统，而在于有没有一个机制，让“这次是怎么解决的”被记下来时还带着“当时是怎么判断的”。

---

常见问题（FAQ）

问：我们人手很紧，写卡片会不会又是一项额外负担？

答：关键在于不要把它做成新增流程。卡片写入必须挂在已经存在的动作上——问题结案、周例会、上线检查，顺手完成。同时要接受一个前提：绝大多数问题不该成卡。一个交付团队一个月产出几条高质量卡片，远好过产出几十条流水账。如果写卡片的时间超过十几分钟，说明字段设计太重，该砍字段而不是该加考核。

问：用 Wiki、Confluence 或者飞书文档就够了吗，需要专门的系统吗？

答：载体不重要，能不能按场景标签检索、能不能在项目节点被强制调用才重要。用现成的文档工具完全可以起步，前提是标签体系一开始就定好——标签定得随意，半年后搜不到任何东西，换什么工具都救不回来。等到卡片需要和具体的工序、设备、物料关联，并推送到现场终端时，再考虑沉到业务系统里。

问：这些经验属于公司还是属于个人？会不会有人不愿意写？

答：现实地讲，如果写卡片对个人只有成本没有收益，就一定推不动。可操作的做法是让贡献可见：卡片记作者、统计被引用次数，并把它纳入技术序列的评价维度。当一条卡片被后续项目反复引用时，作者获得的是组织内的专业信用，这比强制考核有效。另一方面也要坦率承认，判断依据这类知识本身就有传授门槛，不可能百分之百外化——目标是把最关键的那部分留下来，不是追求完备。

问：选型时怎么快速判断一家实施商有没有这套能力？

答：问三个具体问题。第一，上一个同行业项目踩过的最大的坑是什么，这次怎么避免——答不出具体案例的，多半没有沉淀。第二，你们的需求调研清单里，有哪几条是被过往项目逼出来的——这能看出经验有没有回流到过程里。第三，请现场搜一个我们行业的关键词。这三个问题不需要任何技术背景就能问，区分度却很高。

写在最后

制造业信息化项目的交付质量，长期看拼的不是单个项目投入了多少人，而是这家公司有没有把前面几十个项目的判断力留存下来。把 Know-how 拆成一张张可检索、带判断依据、带适用边界的卡片，是目前最朴素也最有效的做法——它不需要新系统，只需要在问题还热的时候，多花十分钟把“当时为什么这么判断”写下来。

奥斯坦丁软件（OTD）为离散制造企业提供 OTDMES 制造执行系统与 OTDWMS 智能仓储系统的实施交付，服务覆盖电子制造、汽车电子、家电、陶瓷等行业。每个项目上遇到的行业差异与结构性判断，我们都按上面这套方式沉淀。如果你正在评估实施伙伴，不妨用文末那三个问题，去问问候选名单上的每一家。