FDE 实战（二）：从 Excel 现场到可执行的业务模型

“我们一直用 Excel。”

这是企业数字化项目里最常听到的一句话。它通常不是在说客户不想用系统，而是在提醒你：真实业务已经存在，只是规则分散在表格公式、群消息和人的经验里。

在这家制造工厂的项目里，计划人员先在多个分表中记录不同产品，再汇总到总表，人工判断库存、在途、包装规格和效期，最后给采购一张“建议采购表”。它看起来像一张表，实际是一套业务模型的外壳。

访谈不要问“你想要什么页面”

我们把访谈问题收成五个维度。这样问，讨论会立刻从“页面长什么样”转向“规则到底是什么”：

1. 这条数据从哪里来，谁负责确认。

2. 什么时候可以进入下一步，什么情况必须停下来。

3. 哪些字段是计算输入，哪些只是展示结果。

4. 不同状态怎么处理，谁有权批准。

5. 这条记录最后要被谁追溯、打印或导出。

比如“采购数量”不是一个输入框就能解决的问题。计划给出的是建议数量，采购会结合最小包装、效期、供应商报价和市场变化调整实际数量。系统应该同时保存建议值和实际值，而不是用采购人员的最终输入覆盖计划结果。

用对象和事件替代部门菜单

会议里每个人都按自己的部门描述流程，很容易得到“销售模块、采购模块、仓库模块”这样的菜单，却看不见它们之间的关系。

我们把内容重新整理成业务对象：订单、产品、配方、物料、采购合同、库存批次、生产批次、取样记录、出库记录、对账单。然后把会议中的动词映射成事件：确认、计算、采购、入库、取样、放行、排产、领料、报工、发货、收款。

这样会发现几个关键关系：

• 订单是需求的来源，但采购合同不直接归属于订单。

• 配方是计算物料需求的依据，同时需要保留历史版本。

• 入库批次连接采购价格和后续领料成本。

• 生产批次可以对应多个订单，财务需要在对账和成本分析时再次分摊。

• 取样和质量结果都会改变库存可用性。

这比“给每个部门做一个页面”更接近系统真正要表达的东西，也更方便后续做追溯和对账。

计算规则要写出边界

需求文档里最容易被低估的是计算。我们把物料需求拆成三层：订单数量乘以配方中的单位用量，得到毛需求；毛需求减去可用库存，得到净需求；净需求再结合包装、效期、替代物料和采购策略，形成建议采购量。

这段公式还不够，因为“可用库存”并不等于库存表里的总数量。待检、已锁定和不合格批次都不能直接使用；排产后库存还需要冻结，避免两个订单重复占用。

因此，访谈记录里每一个“通常”“有时候”“看情况”，都应该追问它对应的状态和责任人。没有边界的计算，最终只能靠人工修正，系统也就无法解释自己的结果。

先画一张可验收的最小闭环

我们把首期闭环定义为：一张销售订单，经过配方和物料需求计算，驱动采购与入库，经过质量放行后进入生产，成品按批次发货，最后生成对账和成本数据。业务方可以拿真实单子来走，工程团队也能更快看到跨模块问题。

这条链路里，每个模块只做完成闭环所需的最小能力。比如通知中心先覆盖到料、取样、领退料和审批提醒；培训考试、维修工单和更深的报表留到后续。

演示是需求工具，不是汇报工具

第一版演示时，讨论很快从“页面长什么样”转向“谁来发起销售出库”“检验未完成时能否先打印单据”“一个生产批次对应多张订单怎么对账”。这些问题在文字需求里往往不会主动出现，因为用户只有看到可操作的流程，才会意识到原来的口头约定需要被系统记录。

我们把每次演示反馈分成三类：规则错误，是状态或计算不符合业务，必须修正；信息缺失，是页面、导出单或通知没有呈现关键字段；流程取舍，是业务希望保留人工判断，系统只提供辅助。这样分类之后，团队不会把所有反馈都变成字段，也不会把所有人工判断都硬编码。

这套方法适用于更多企业

1. 先收集原始材料，但不要急着写需求。

2. 再抽取对象、事件、状态、角色和计算规则。

3. 然后标记冲突与未决项，回到业务现场确认。

4. 接着选一条能产生真实结果的最小闭环。

5. 用演示验证边界，再决定哪些规则进入系统。

6. 对已实现、规划中和暂不处理的内容保持明确区分。

“把 Excel 搬进网页”只是表面工作。真正的工作，是把表格背后的判断变成团队都看得见的规则，同时给不确定性留下人工确认的位置。