现场和系统一冲突，让步的为什么总是系统

我做过的项目里，现场和系统一冲突，最后让步的几乎都是系统。原因不复杂：到了那时候，硬件早就装好了。动硬件，花钱多、周期长；改系统，时间和钱都少得多。

例外也有。验收以后，一整座立库搬了位置，重新谈商务、谈周期，前后 3 个月。

这个系列，我想把这些改方案的事，一件一件讲出来。

一、立库和 AGV 一到位，能改的就只剩系统

先讲一次最典型的。

试上线之前，我们发现订单发不下去。系统要自动下发订单，前提是计划提前 7 天定下来，关键物料提前 3 天到货。现场的计划呢，当天还在改；单子发下去了，BOM 还在变。

我们没去改现场，改的是系统：把「下发」这一步交回给计划员，按工序提前 1 天发。后面的备货、分配、出库，照旧自动。

为什么总是系统让步？到了这个时候，规划布局早就定了，立库、输送线、AGV 都装好了。动硬件，花钱多，周期长。改系统，改个配置、改段逻辑、改一步流程，时间和钱都少得多。

所以现场一冲突，大家先问的往往不是谁对，而是改哪一头更便宜。

系统让步，人也得跟着动。人工作业那会儿，管物料的材料员和下订单的计划员是同一个人。上了系统就得拆开：计划员先在系统里下计划，材料员才能备货、发配送任务。活分细了，责任也清楚了，该加人就得加人。

上一个系列，我从立项走到验收，一站讲一条规则。比如定制那篇，我写的是：标准功能配得出来的，不算定制。

到了现场是什么样？客户在报表系统里提了几条「特殊定制」。我们一看，不用开发，按他要的字段和维度配一下就行。业务对系统还不熟，把本来就有的功能当成了定制。

规则人人都懂，现场为什么还会走偏，得看一件件具体的事。两个系列可以对着读：一个讲这一站该怎么做，一个讲这一站在现场发生过什么。

每篇我都讲一件事：当时的方案、现场哪里对不上、最后怎么改、花了什么代价，还有如果再来一次，我会在哪一站先做点什么。

每篇结尾，我会用一句话写明它对应上一系列哪一篇，是哪种关系：案例说明，是那篇讲的规则在现场真的发生了；补充，是那篇没讲到的一块；深化，是那篇讲到了，这一篇往下多挖一层。

我按项目阶段排，从实现、上线准备、试运行，一直讲到验收以后。

第一条，交回给人的，往往只是需要人判断的那一步。订单下发交回给人，退料处理交回给人，搬运还是 AGV 在跑。

第二条，很多改方案，最后都回到了上线前那几张数据表。开仓数据、物料配送表，有一张没填对，现场就要改一次。

第三条，变更怎么处理，立项和签合同时没写下来，后面就只能一次次重新谈。换一个领导、搬一座立库，钱和时间都得从头算。

下一篇从实现阶段讲起：蓝图签完，开发已经在做，甲方换了一位领导。

你们项目上，现场和系统冲突的时候，有没有哪一次，最后是现场让步的？