虚构样例

项目、公司、人名和数字全部是虚构的，用来演示一次体检能交付什么。不来自任何真实项目或公司材料。

报告里出现的“北辰汽车零部件”“衡远信息”都不存在。

知行有光 · WMS / LES 实施

上线前方案体检报告 · 样例

签合同、冻结蓝图、定上线日期之前，把实施方案里还没着落的地方找出来。每一条都附了它是怎么查出来的。

项目（虚构）: 北辰汽车零部件 · 二号工厂 WMS / LES 实施
被检材料: 衡远信息（虚构）实施方案 rev.B 与项目计划，§1–§5
体检日期: 2026-10-06
体检人: Pascal · 大型制造业 WMS/LES 项目集经理

一页结论

这份方案现在不建议签。

问题不在于实施方一定做不好，而在于方案里有几处关键安排目前没有着落：范围没有前提，变更会一条一条地吵；蓝图只有正常流程；数据准备把设备字段交给了填不出来的人；接口、切换和验收都没写到能检查的程度。这些是上线以后最贵的返工来源。

12
高风险：签合同前必须关闭: 8
中风险：写进合同条款或上线计划: 5
份文件要乙方在签字前补齐: 18
条追问，可以直接发给乙方

签合同前，先让乙方回答这 5 件事

1
立项书补「前提和假设」：答复时限、签字代表、数据责任、变更流程。范围外的需求现在没有依据可查，每加一条都要重新争。→ A1
2
黑盒调度的三条写进合同：格子级回传、改规则的时限和价格、规则文档随交付。尾款付完，这些就只能花钱买了。→ A3
3
蓝图补逆向流程：回滚、取消、退货、任务取消、设备异常，每条写到岗位。现在 4 条主流程之外，系统里没有路径。→ B1
4
货位表按信息来源拆成两张；物料编码用三条抽检代替「推进中」。这两件事不先定，上线日期就是悬空的。→ C1、C2
5
接口给出过账场景清单（含冲销），上线方案写清切换前提和回滚条件。这两块是上线当天最容易炸的地方。→ D1、D2

一、实施方案与上线准备度

每一条都对照坑库规则和《WMS / LES 项目上线检查清单》逐条查：方案里有没有写、写到什么程度、由谁负责。每条写清三件事：方案现在还不能宣称什么、要找乙方补什么、补到什么程度才算关闭。每条右侧的旁注写明规则编号、看了哪里、用的什么方法、不能证明什么；判定标准不公开。

A. 范围与合同

节选 3 条

A1高风险经验判断 · 坑库 L1

立项书没有「前提和假设」：每加一条需求，都要重新争算不算变更

方案原文: §1 范围：按附件功能清单实施，工期 6 个月，合计 1,240 人天。
现在不能宣称: 范围和工期是定死的。没有写下答复时限、签字代表、数据由谁负责这些前提，前提一变，多出来的人天和时间没人认。
找乙方要: 在立项书里补一章「前提和假设」：业务方几个工作日内答复、逾期视同确认；签字代表和授权人；源数据由业务方负责；范围外的需求走变更流程。
怎样算关闭: 这一章写进立项书，双方签字。

这一条是怎么查出来的

看了哪里: §1 范围与工期
用的方法: 对照坑库 L1「立项要定死的 8 样」：立项书里有没有前提和假设、有没有变更控制条款。
规则编号: SCP-01 前提缺失
不能证明什么: 不能证明一定会超支，只证明出了范围争议时没有依据可查。

A2中风险经验判断 · 坑库 L1

功能清单 86 项没标「标准」还是「定制」：1,240 人天说不清是怎么估出来的

方案原文: §1 附件功能清单：86 项，合计 1,240 人天。
现在不能宣称: 工时是按功能拆出来的。标准功能主要花配置和实施人天，定制的才吃开发人天；不标出来，后面谈变更、核工时都没有底。
找乙方要: 功能清单每行加一列「标准 / 定制」，定制的行附开发经理按前端、后端、接口拆的工时，并登记进定制清单。
怎样算关闭: 清单每一行都有标注，定制项有编号、提出人和工时拆分。

这一条是怎么查出来的

看了哪里: 附件功能清单（86 行）
用的方法: 逐行看有没有区分标准功能和定制开发，定制行有没有单独的工时依据。
规则编号: SCP-02 标准定制未标
不能证明什么: 不能证明人天估多了，只证明现在没法核。

A3高风险经验判断 · 坑库 L2

立库调度是黑盒方案，合同里没有规则回传、改规则的价和规则文档

方案原文: §1 立库调度由设备集成商负责，WMS 下发任务到库区。
现在不能宣称: 验收以后，工厂能自己看清格子级的库存、自己掌握规则。现在 WMS 只记到区，格子那本账在集成商手里，改一条规则要多久、多少钱都没写。
找乙方要: 合同补三条：格子级库存和任务状态回传；改一条规则的时限和计费；规则清单、参数表、配置文档随交付。
怎样算关闭: 三条写进合同或补充协议，尾款支付和这三条挂钩。

这一条是怎么查出来的

看了哪里: §1 系统边界的一句话；合同草稿的交付物清单
用的方法: 对照坑库 L2「黑盒白盒」：黑盒方案在付尾款前必须写进合同的三条，逐条查有没有。
规则编号: CTR-01 黑盒三条
不能证明什么: 不能证明集成商会不配合，只证明验收以后工厂说了不算。

B. 蓝图与需求

节选 2 条

B1高风险经验判断 · 坑库 L1b

蓝图只画了 4 条正常流程：取消、回滚、退货一条都没有

方案原文: §2 蓝图初稿：入库、出库、配送、盘点 4 条主流程。
现在不能宣称: 蓝图已经完整。逆向流程一周才碰上几次，调研时没人主动提；上线后碰上，系统里没有路径，只能找 IT 改数据。
找乙方要: 补一章逆向流程：收货回滚、取消上架、波次取消、少拣多拣、超量发货退回、采购退货、任务取消和设备异常，每条按正常流程的格式画图、写到岗位。
怎样算关闭: 逆向流程逐条有流程图和岗位，跟主流程一起过终审。

这一条是怎么查出来的

看了哪里: §2 蓝图初稿的功能清单与流程图
用的方法: 在功能清单里检索「取消」「回滚」「退」，再对照坑库 L1b 的逆向流程清单逐条核对。
规则编号: BLP-01 逆向流程缺失
不能证明什么: 不能证明这些场景一定会发生，只证明发生了没有路径。

B2中风险经验判断 · 坑库 L3

需求变更写成「开发评估后实施」：没经过项目经理

方案原文: §2 需求变更：业务方提出，开发评估后实施。
现在不能宣称: 工时和节点可控。需求直接进开发，没评估、没排期、没记录，一条看着小，加多了工时表就不准了。
找乙方要: 开发期间的新需求一律先交项目经理评估：接不接、算不算变更、插在哪、挤掉什么；线停的紧急问题可以先修、事后补登记。
怎样算关闭: 变更流程改成项目经理入口，并有一张需求登记表。

这一条是怎么查出来的

看了哪里: §2 需求变更的一句话
用的方法: 对照坑库 L3「需求与工时」：新需求的入口是不是项目经理，有没有评估和排期这一步。
规则编号: REQ-01 需求入口
不能证明什么: 不能证明会出现需求蔓延，只证明出现了没人拦。

C. 数据准备

节选 2 条

C1高风险经验判断 · 坑库 L6 / 清单 F1、F3、F5

「客户按模板提供货位主数据」：立库那 8 列，客户填不出来

方案原文: §3 客户按我方模板提供物料、货位主数据（一张表）。
现在不能宣称: 货位数据会一次收齐。巷道、单双伸、远近端、关联货位、上架和拣货路线顺序这几列，出处在设备排布图和调度配置里，只有设备方才有。表收回来看着是满的，那几列却整列为空。
找乙方要: 把表按「谁有这个信息」拆成业务表和设备表两张，货位编码规则最先定；回收后逐列数填充率。
怎样算关闭: 设备表由设备方出，按货位编码和业务表合并，整列为空的字段逐个确认。

这一条是怎么查出来的

看了哪里: §3 数据准备：一张货位表给客户填
用的方法: 对照坑库 L6 与清单 F1、F3、F5：每个字段由谁掌握，填表人和信息来源对不上就标记。
规则编号: DAT-01 字段来源
不能证明什么: 不能证明这个客户一定填不出，只证明模板没按来源拆。

C2高风险经验判断 · 坑库 L15

物料编码「推进中」，上线日期已经定了

方案原文: §3 物料编码：客户数据治理项目推进中，上线前完成。
现在不能宣称: 上线时编码是干净的。「推进中」没有范围，也没有验收方式；日期定了，清编码就会被挤到上线之后，而它在上线之后做不了。
找乙方要: 用三条判定代替「推进中」：随机抽 100 个物料，同一实物在采购、仓库、生产三个口径下重复叫法为 0；被复用的老编码清空；单位换算规则写进系统。
怎样算关闭: 三条抽检结果出来，再定上线日期。

这一条是怎么查出来的

看了哪里: §3 物料编码的一句话；§5 上线日期
用的方法: 对照坑库 L15「上线前 3 句」：编码有没有可检查的判定标准，日期是不是定在判定之前。
规则编号: DAT-02 编码判定
不能证明什么: 不能证明编码现在不干净，只证明现在没法判断。

D. 接口、上线与验收

节选 3 条

D1高风险经验判断 · 坑库 L13 / 清单 J3

「ERP 标准接口，联调 2 周」：没列过账场景，也没提冲销

方案原文: §4 WMS 与客户 ERP 走标准接口对接，联调 2 周。
现在不能宣称: 2 周够用。ERP 是接口最宽的一个：采购入库与退货、调拨、领料、盘点、线边退料……十几类过账场景，每一类都要单独确认冲销。只验了正向、没验冲销，是上线后账对不上的头号原因。
找乙方要: 一份过账场景清单，每类标明是否含冲销，作为联调完成的验收依据。
怎样算关闭: 每一类冲销都跑过一遍联调，有记录。

这一条是怎么查出来的

看了哪里: §4 联调计划里的一句话
用的方法: 对照坑库 L13 与清单 J3：过账场景是否列出、是否含冲销。
规则编号: ITF-01 冲销
不能证明什么: 不能证明 2 周一定不够，只证明没列场景，所以没法判断够不够。

D2高风险经验判断 · 坑库 L15 / 清单 K1–K5、L2

「周末一次性切换」：没写回滚条件，也没写切换前提

方案原文: §5 上线计划：周末一次性切换。
现在不能宣称: 周末切换是安全的。五条切换前提要全部满足才能切：上下游系统同步上线、期初盘点完成、采购和调拨数据到位、工单 / 质检 / 过账三条链路通、自动化设备联调通。
找乙方要: 写清回滚触发条件、回滚时间窗，以及过了哪个点就只能往前。
怎样算关闭: 上线方案里有切换前提清单和回滚预案，上线前一周逐条打勾。

这一条是怎么查出来的

看了哪里: §5 上线计划里的切换方式
用的方法: 对照清单 K1–K5 与 L2：切换前提是否逐条写明，回滚条件是否存在。
规则编号: GOL-01 回滚
不能证明什么: 不能证明切换会失败，只证明出了事没有退路。

D3中风险经验判断 · 坑库 L17

验收写成「稳定运行 3 个月后验收」：5 个指标没有一个有门槛

方案原文: §5 验收：系统稳定运行 3 个月后验收。
现在不能宣称: 3 个月后能顺利验收。门槛立项时不定，到验收时每一方都按对自己有利的口径算，最容易争的是问题关闭率和功能完成率。
找乙方要: 把 5 个指标的门槛写进立项文件：单据和配送准确率、系统可用率、出库效率或节拍达成、问题清单关闭率、功能完成率，连同「什么算问题」「什么算已确认功能」的口径。
怎样算关闭: 门槛和口径写进立项文件，三方签字。

这一条是怎么查出来的

看了哪里: §5 验收条款
用的方法: 对照坑库 L17「试生产验收」：5 个指标有没有门槛、口径有没有写清。
规则编号: ACC-01 验收门槛
不能证明什么: 不能证明验收会拖，只证明到时候没有依据可查。

这份体检的边界

只看了方案和项目计划的文字，没有见过现场或系统。
只查 WMS / LES 实施和项目管理：范围、合同、蓝图、需求、数据、接口、上线和验收。不评价设备选型，也不复算设备能力。
全部是对照坑库与上线检查清单的经验判断，每条标注规则编号。不打总分，不给概率。
样例节选了 10 条发现，完整样例共 20 条。

想知道你自己的项目，哪几站会亮红灯？

5 分钟自评