【摘要】
场景：一家 6 英寸老厂，想上良率分析与自动预警。现有 MES 是 2011 年上线的老系统，EAP 是两家供应商拼起来的，客户自己说不清现状。销售希望两周内出报价。
FDE 只有一周时间。这篇文章拆解这一周怎么用：不是把所有系统都看懂，是抓住五个关键事实，用数据验证，最后给一个有条件的结论。
【核心要点】
- 一周的目标不是"搞懂"，是"识别哪些必须先解决、哪些可以绕过"
- 五个关键事实：系统版本与接口能力、数据完整性、设备通信覆盖率、停线与变更约束、客户内部决策链
- 数据质量必须自己验，不能听客户说"数据都有"
- 报告的结论要写成"有条件可行"，附条件清单——这是保护自己也是保护公司
- 报告写完先给客户 IT 和项目负责人各过一遍，再提交
---
一、第一天：不碰系统，先见人
第一天最忌讳直接要账号查数据库。先见三个人：
- 客户项目负责人：问目标（为什么要上这套系统）、问历史（之前失败过什么）、问决策链（谁拍板）
- 厂方 IT 负责人：问现状（系统清单、版本、接口）、问约束（网络策略、账号审批周期）
- 生产/工程一线班组长：问痛点（现在最烦什么）、问手工流程（哪些还在用 Excel）
第一天的产出是一页纸的假设清单：这家厂的瓶颈大概在哪、需要验证什么。
本例中，三个人的说法互相矛盾：负责人说"数据都有，就是没人分析"，IT 说"MES 接口只有报表导出"，班组长说"良率异常我们现在靠经验看片"。矛盾本身就是最重要的信息——说明数据在，但链路是断的。
二、第二天：系统清单与接口能力
拉一份完整的系统清单，逐项标注：
| 系统 | 厂商 | 上线年份 | 数据库 | 接口方式 | 是否可获取数据 |
|---|---|---|---|---|---|
| MES | A 公司 | 2011 | SQL Server 2008 | 报表导出/存储过程 | 需只读账号 |
| EAP | B 公司 + 自研 | 2015/2019 | Oracle 11g | 消息队列 + 私有协议 | 部分 |
| SPC | 无独立系统 | — | Excel | 人工录入 | 否 |
| QMS | 纸质/Excel | — | — | — | 否 |
这张表一出来，方案的基本形态就定了：没有独立 SPC，意味着预警要从 MES + EAP 的数据自己算；接口能力弱，意味着优先走数据库只读而不是 API。
三、第三天：数据质量必须自己验
客户说"数据都有"。FDE 要验三件事：
1. 完整性：随机取最近 30 天的生产记录，看关键字段缺失率。
-- 关键字段缺失率（示意）
SELECT
COUNT(*) AS total,
SUM(CASE WHEN eqp_id IS NULL THEN 1 ELSE 0 END) AS miss_eqp,
SUM(CASE WHEN recipe_id IS NULL THEN 1 ELSE 0 END) AS miss_recipe,
SUM(CASE WHEN start_time IS NULL THEN 1 ELSE 0 END) AS miss_start
FROM lot_history WHERE start_time >= DATEADD(day,-30,GETDATE());本例实测：recipe_id 缺失 18%，eqp_id 缺失 2%。这意味着"按 Recipe 分组的良率分析"做不了，必须先补数据采集。
2. 一致性：MES 报工数 vs 设备计数，差异多少。本例差异 3.7%，原因是手工补录。
3. 时间精度：三个系统的时间戳能否对齐。本例设备用本地时间，MES 用 UTC，差 8 小时——这类问题不发现，后面所有趋势分析全错。
四、第四天：设备通信覆盖与红线确认
覆盖率：全厂 68 台设备，支持 SECS/GEM 的 41 台，其余 27 台是早期设备（RS-232 或无数控接口）。
这决定了方案边界：设备状态自动采集只能覆盖 60%，剩余部分要么人工录入，要么加装采集卡（成本另算）。
红线确认：跟他 IT 聊清楚三件事——能不能开只读账号（能，2 周）、能不能放通跨网段（要走变更，1 个月）、能不能在设备网部署采集程序（不允许，只能部署在生产网）。
这三条直接写进报告的条件清单。
五、第五天：客户决策链与内部阻力
技术之外，最难的是组织。第五天要搞清楚：
- 谁是这个项目的真正推动者（本例是品质总监）
- 谁会因为这套系统而不舒服（本例是生产主管，担心被追责）
- 预算从哪出（品质部年度预算）
- 决策会什么时候开（每月一次）
这一步决定方案怎么写：给品质总监的方案要强调"异常闭环与追溯"，给生产主管的部分要强调"不增加操作负担，误报可控"。
六、第六天：写报告
报告结构（控制在 8–12 页，客户不会读长文档）：
1. 结论（1 页）：有条件可行 / 不建议 / 需要先做基础改造
2. 现状评估（2 页）：系统清单、数据质量、设备覆盖
3. 关键发现（2 页）：3–5 条，每条附数据证据
4. 建议方案（2 页）：分阶段，第一阶段只做最小闭环
5. 前提条件（1 页）：客户必须提供/批准的事项，带时间
6. 风险清单（1 页）：技术风险、组织风险、进度风险
7. 工作量估算（1 页）：按阶段给区间，不给单一数字本例结论写的是：
有条件可行。第一阶段（3 个月）可实现"良率异常自动预警 + 追溯查询"，覆盖 41 台 SECS 设备。前提条件：①MES 只读账号与存储过程权限（2 周内）②EAP 消息队列接入许可（1 个月）③Recipe 字段补录方案确认（客户工艺部）④设备网不部署采集程序，采用生产网代理采集。若上述条件在 4 周内未满足，建议推迟启动。
七、第七天：先给两个人看，再正式提交
报告不是直接发给客户老板的。先给两个人过：
- 厂方 IT：确认技术描述无误，避免他在正式会上挑错
- 客户项目负责人：确认结论和他的预期不冲突，让他提前准备
这一步叫"预沟通"，是 FDE 的基本功。正式会上第一次出现的反对意见，通常意味着预沟通没做。
八、这个案例的可复用点
- 一周的目标是识别约束，不是搞懂系统。老厂的系统永远搞不懂，但约束一周能摸清。
- 数据质量必须自己验。三个指标：缺失率、一致性、时间精度。
- 结论写成"有条件可行 + 条件清单"。这既保护公司（条件不满足可以推），也保护自己（后续延期有依据）。
- 报告先给关键人预审。会议上的意外，都是会前没沟通。
- 第一阶段只做最小闭环。老厂改造最容易死在"一次做全套"。
卷 1 到此结束。下一篇进入卷 2：需求治理——客户说"我要自动良率预警"，怎么把它收敛成能落地、能验收的方案。