企业数字化转型的范围控制：变更走审批，上线分批次

企业数字化转型做到中途变味的很常见。系统一开始只是管订单，做着做着客户管理、考勤、报销全要塞进来，工期拖长一倍，预算翻番，原定上线的业务反而迟迟没跑起来。范围失控是转型项目烂尾的头号原因，问题不在需求多，在没人给需求设闸。

需求变更要走审批，口头加需求最危险

项目启动时就要定一条规矩：所有新需求走变更申请，写明提出人、要解决什么问题、影响哪些模块、要改多少工期和预算，由业务负责人和技术负责人共同审批。审批通过的进下一批迭代，没通过的记录在案，等二期再说。

最危险的是口头加需求。会议上随口一句"顺便把这个也做了"，开发照做了，工期和成本没人记账，到验收时双方对"当初说的范围"各执一词。变更单不是为了卡业务，是为了让每一次范围扩张都有据可查、有代价可见。

分批次上线：先跑通一段，再铺开一片

转型项目最忌讳一次性全量切换。稳妥的顺序是先选一个业务环节做试点，比如仓储或订单履约，把流程跑通、问题修完，再逐步推广到其他部门。试点期新旧系统并行一两个月很常见，两边数据对得上、人员用顺手了，再停旧系统。

批次之间留出复盘时间。每一批上线后收集操作反馈，解决真实使用中的问题，再启动下一批。跳过复盘连轴转，问题会像滚雪球一样堆到收尾阶段一并爆发，届时返工成本远高于慢慢来。

验收跟着里程碑走，别等全部做完才验收

付款和验收要绑定里程碑，而不是等项目结束一次性验收。每一批功能交付后，按事先约定的验收标准逐项核对：功能对不对、数据准不准、性能达不达标，确认无误再付该笔款项。

验收标准要在实施前写清楚，而不是交付后现定。口径模糊的指标（比如"系统好用"）等于没有标准，双方对是否通过各说各话。把"订单录入后 5 秒内生成单据""月结报表次日可查"这类可验证的表述写进合同附件，验收才有着落。指标定得太软，供应商交差时怎么说都有理，付款节奏就被拖着走。

范围、节奏、验收三件事管住，数字化转型大概率跑不偏。管不住，再贵的软件也救不回来。