大多数项目卡在"想"和"跑"之间
客户常说"我们想上系统"，但真正难的不是买系统，是从"想"走到"每天有人在用"。我们见过太多项目，合同签了、服务器买了、Demo 也做了，半年后系统还在测试环境里"即将上线"。卡住的原因通常不是技术，而是没人把"想"翻译成"一步步跑起来"的路径。
我们把这条路拆成四段，每段都有明确出口——所谓出口，就是"这段结束的标志是什么"，没有出口的阶段永远走不完。
四段落地路
第一段：诊断与边界（2–4 周）
不碰代码。先把三件事写清楚：为什么上、不上会怎样、哪些绝对不能动。我们常在这一段劝客户"先别急着定功能"，因为功能清单往往掩盖了真实顾虑。出口是一份双方签字的范围书——它不完美，但它是后面所有决策的共同锚点。这一阶段最常见的失败，是客户把范围书写成"尽量满足"，等于没写。
第二段：最小闭环试点（4–8 周）
挑一条最痛的业务线，做能跑起来的最小版本。目标不是全功能，是让一拨人先"离不开它"。比如生产场景，我们先把报工和异常上报跑通，哪怕暂时不接 ERP、不画看板。判断试点成功的标准很朴素：当班的人如果今天系统宕了，会不会主动找我们修——会，就说明闭环成了。
第三段：推广与集成（按业务节奏）
试点跑顺了，再横向铺开、纵向接 ERP、设备与第三方系统。这一步最容易贪快——客户一看试点好用，恨不得下周全厂上线。我们坚持"接一个稳一个"，每接一个外部系统，先并行跑一周再切主用。跳这一步的代价我们见过：一次性切全厂，结果一个接口异常拖垮整条产线。
第四段：持续运营（长期）
上线不是终点。巡检、权限复盘、版本演进，写进运维约定，而不是交付即失联。我们给每个长期客户配一张"运营日历"：每月权限复核、每季度数据归档检查、每半年架构回顾。系统会老，但运营让它慢点老。
为什么非要"最小闭环"先行
| 路径 | 一次性全上 | 最小闭环先行 |
|---|---|---|
| 风险暴露 | 上线日集中爆发 | 试点期小步暴露 |
| 用户接受 | 被迫适应 | 主动依赖 |
| 返工成本 | 全盘返 | 局部返 |
| 决策可撤回性 | 难 | 易 |
第四行是很多人忽略的——最小闭环最大的隐性价值，是让每一步都还能回头。一次性全上一旦方向错，沉没的是整盘；小步试错，错的只是一段。
给客户的一句话
别问"系统什么时候做完"，要问"这周谁已经在用了"。用得起来，才算落地。
金兰信息——把"上线"定义成"每天有人用"，而不是"部署完成"。