先说个场面。（合成场景，但"模型一行没写、全组在查数据"这个状态，我带过的项目都出现过。）
一家机械制造商，做售后备件需求预测。项目第 11 周，模型一行代码没写，全组在回答一个听起来很笨的问题：一台设备卖给谁了？
三个系统给出三个答案。ERP 里是客户编号，后面挂着一串曾用名；售后工单里是中文简称，同一个客户四种写法；计划员手里那张 Excel 里写着"老王家"。
计划员说了一句让我记到现在的话："这三个我都对过。所以我现在是自己手工做的。"
那次项目最后是成的，但我对它的记忆全在数据上。这一篇讲的就是这类东西。
体检顺序不能换
很多人拿到项目第一句话是"要做数据清洗"。我把顺序倒过来定，三步。
第一步：有没有。 字段存在吗、覆盖多久、从哪一年开始可信、谁在往里写。这步的产出是一张数据地图（后面给样式），不是代码。
第二步：敢不敢用。 判断线我定得很硬：任何一份数据，如果找不到一个能改它的人，它就不能作为生产输入。
这条线很省钱。数据质量问题九成不是技术问题，是责任问题。一份没人敢署名的数据，你把它洗得再干净，上线那天业务方一句话就能把你推翻------"这个数我一直不认"。
第三步：才轮到清洗。 前两步走完了你通常会发现，本来列出来的清洗任务有一大半不需要做了：要么那个字段根本没人认，要么这份数据今年就要被新系统替换，要么最省事的做法是换一个来源。
按我的经验，第三步之前淘汰掉一半以上的清洗需求很正常（经验值，不是统计）。
四类脏法
一、口径不一致。
同一个词在不同系统里指的是不同的事。"完成"在工单里是点了那个按钮，在财务里是回款到账；"销售额"含不含税，两个部门各有各的版本，而且都合理。
解法不是统一口径------你统一不了，每个口径背后是一个部门的考核办法。
做法是选一个锚定口径，让业务负责人签字，然后建一张对照表：这个字段用 A 口径，那个字段用 B 口径，两者相差大约多少，写清楚。项目期间所有汇报都用锚定口径说话。
这份对照表通常能省掉一半的争论。另一半争论，是有人想拿口径之争推翻结论，那张签字页就是你的盾。
二、老系统没接口。
客户那套核心系统用了十几年，厂商早散了，没人敢动。这是最常见的一类。
三条路，按我的偏好排：
读数据库视图或中间表。要一份带时间戳的快照就够，先别要写权限。这条路比申请接口快三个月，而且客户的 DBA 一般愿意配合，因为不改他任何东西。
定时导出文件。最丑，也最能活。要盯一个坑：导出的时间窗口。夜里两点导的数据，你早上八点用，这一天的判断都建立在过期几小时的数字上，业务方察觉不到，只会觉得"这东西不准"。
模拟点击抓页面。脆，页面一改版就断。只读可以接受，绝不要用这条路写数据。
三、字段躺在某个人的 Excel 里。
第 06 篇讲过，那些常年开在屏幕左侧的表格是组织的真实知识。备件预测那个项目里，"老王家"三个字背后是她五年攒下来的客户别名------那三个系统谁都没有。
正确的做法是把那张表变成系统的入口，让她继续维护，只是换个地方维护：给她一个有下拉选择的表单，字段还是她填，数据落到库里。她的权威不减，系统多了输入。
我干过一件蠢事：有一次我推动"取消那张 Excel，大家都用系统"，理由是数据源要唯一。两周后那份数据断了------因为她开始把该填的东西记在便签上，等月底再补。系统里全是空的，谁也没办法。
从那次以后我改了一条原则：不要消灭变通，把变通接进来。
四、数据出不了门。
这一类在金融、政务、医疗里最常见。第 09 篇讲过这一层的流程和签字，这里只讲技术上的取数形态。
三个方向：现场训练（模型进去、数据不动）；脱敏样本（几百条加规则，先够跑通评测，第 05 篇提过）；字段级最小化（问一句"这个问题真的需要身份证号吗"，多数时候答案是不需要）。
顺序我建议反过来走：先按"数据不出屋"设计架构，再选模型。先选好模型再发现跑不进客户机房，等于重做。
一张数据地图长这样
| 字段 | 在哪个系统 | 谁维护 | 口径出自哪份文件 | 多久更新 | 敢不敢用 |
|---|---|---|---|---|---|
| 客户名称 | ERP，T9 表 | 销售内勤 | 无文档，口头约定 | 实时 | 要人确认 |
| 设备序列号 | 售后工单 | 客服组长 | 《服务手册》第 4 章 | 实时 | 能用 |
| 备件出库量 | 库存系统 | 计划员 | 她那张 Excel 为准 | 每晚导出 | 别用（口径待她签字） |
最后一列我只允许三种取值：能用 、要人确认 、别用。
"要人确认"这一档最有用。它把模糊状态写实了：谁确认、什么时候确认、不确认会怎样。项目里大部分延期，都是本该落在这一档的字段被默认成了能用。
数据会自己变，这条最常被忽略
地图做完不是就完事了。数据在一个组织里会朝三个方向漂移，每一个都能把你上线好的系统悄悄废掉。
字段的意思会变。客户改了产品线，设备编码前两位从工厂号变成了大区号，系统里没人通知你。
写入量会变。新系统上线那年，老表停止更新，但还在被查询------你拿到一份"历史数据"，其实是半年的存量。
口径跟着考核变。这是最凶的一种。年底业绩口径一改，"完成"的定义当天就换了，你的模型还在按上半年的规则判。
我的对策很轻：数据地图再加一列"上一次变化是什么时候、谁改的"；每季度从生产里抽十条，和模型当时的判断对一遍。这是第 10 篇那套例行评测的一部分，不用另建流程，只需要在样本里留出"数据来源"这一栏。
漂移这件事没人能提前拦住，但发现它只要二十分钟。发现不了的代价是业务方慢慢不信你，而且他不会告诉你原因。
项目组里该有一个客户侧的取数人
这一摊活不该由你一个人啃。每个成的项目里都有一个客户侧的人：DBA、系统管理员，或者某个内勤。他们知道那张表其实没人写、这个字段是从别处复制来的。
我现在的做法是把这件事摆到明面上：项目表上写清"数据对接人"是谁、每周占他多少时间，并且在给客户的汇报第一页写明他的贡献。
这不是客气。数据这一层的信息只存在于他的记忆里，而一个人愿不愿意在两周一次的会议上说真话，取决于他在这件事里有没有名分。
三句谈判话术
客户说："数据都在 ERP 里，你们自己取。"
我接一句："那我需要一个人，两小时，带我走一遍取数路径。"
这句话把技术问题转回了人手问题。两小时之后你会知道哪些表其实没人写、哪个字段是从别处复制来的------这些东西在任何文档里都查不到。
客户说："先做个 POC，数据以后再说。"
我接："可以，但 POC 用哪批数据，写进合同。"
第 05 篇那个坑就是这么来的：隔离环境里一份三年前的旧数据，做了一个月效果漂亮，上线全崩。POC 的数据来源是合同条款，不是工程师的运气。
客户说："这个字段不能给，那个也不能给。"
我接："给我 200 条脱敏样本和一份字段字典，一周以后我告诉你，少了哪个字段会让结果不可用。"
要全量很难谈，要证据容易谈。一周后你手里有一份"缺 A 字段则合格率从 82% 掉到 40%"这类对照结果（这个数是合成的演示口径），拿它去谈，客户侧做决定的人换了，事情也能推进。
一句收尾
FDE 在数据这一层的价值，不是把数据洗干净，是把"这份数据谁负责"这件事逼到桌面上。洗数据是体力活，逼出责任人这件事才是让项目往下走的力气。
有一类客户我到现在没招：整个组织里找不到一个愿意对某份数据签字的人，谁都觉得自己的那部分是"临时的"。遇到这种我现在只做一件事------把方案范围缩到不依赖那份数据，然后明说哪部分因此做不了。这不是解决办法，这是止损。
下一篇讲客户说"不行"的时候你手里该有什么：安全与合规那一纸军令状，怎么读，怎么准备。