数字化项目的范围失控，通常不是因为需求太多，而是因为项目一开始没有建立“什么必须完成、什么明确不做、什么留待后续”的边界。很多企业先看供应商演示，再按产品菜单补写需求，结果把“系统有什么”误当成“业务需要什么”，上线后才发现发货对账、库存准确和重复录入等核心问题仍未解决。
先定义业务结果，再讨论功能
需求不能停留在“提升效率”“实现数据驱动”这类无法验收的表述。更有效的写法是把业务问题转化为可观察的差距：当前流程哪里耗时、谁在重复操作、错误造成什么影响，项目完成后需要发生什么变化。
例如，订单从销售确认到仓库可执行的时长，可从约4小时压缩到1小时以内；销售每天手工汇总日报的时间，可从约1.5小时降至0.5小时以内。每项指标还要明确测量口径和达成时限，否则到了验收阶段，业务、供应商和项目组会各自解释“完成”。
用场景锁定范围
“支持订单管理、库存管理、客户管理”只是功能清单，无法约束实施。应改写为业务场景：谁在什么条件下执行什么操作，系统应返回什么结果，异常时如何处理。
例如，销售确认某个SKU的可售库存时，系统需要返回可用库存、最近可发货仓库和预计到货日期；库存不足时，还应提示可替代SKU，并支持发起锁库申请。这样的场景既能约束供应商演示，也能直接转化为测试用例。核心需求至少覆盖高频、高风险和跨部门环节，如退货、审批驳回、库存不足和对账不一致。
用“不做清单”守住边界
范围管理不仅要写“本期必须”，还要写“本期不做”和“后续评估”。例如，本期完成销售订单到发货确认的线上化，但不开发供应商门户、不替换现有财务系统、不做生产排程；移动端价格审批则放入后续评估。
同时要明确数据迁移、双方责任和验收条件。验收不能只看系统是否上线，而要验证核心场景是否跑通、真实业务周期是否达到目标、关键用户是否真正使用新系统。演示应放在需求之后，并要求供应商按核心场景说明哪些是标准功能、哪些需要配置、哪些涉及二次开发。只有这样，项目范围才会从“不断加功能”变成一组可比较、可实施、可追责的业务承诺。