能不能先只上一个模块试试，后面再补？这个问题几乎每次售前都会被问到。想答清楚，光说「可以」没用，因为同样叫先上一个模块，有的项目半年后顺顺当当接上第二期，有的第一期上线就卡在那儿，补也不是、推倒也不是。
差别不在选了哪个模块，在划出来的这一段是不是一条能自己走完的链路。
一、判断标准：这一段能不能闭环
所谓闭环，是从发起到结果，中间不需要靠系统外的表格或口头补一段。比如把订单到领料这一段做进来，订单能下、物料能算、领料能记、领完能对上，这一段的输入和输出都在系统里，就立得住。
反过来，如果只把某几张单据搬进系统，关键判断还得在群里问一句、结果还得手工抄回另一张表，那不叫一个模块，叫半截流程。半截流程上线后，现场会同时维护两套东西，比全用纸还累。
所以第一步不是挑模块，是拿一张真实单据走一遍，看从哪儿到哪儿刚好能收口。收口的地方，就是第一期的边界。
二、边界要写成几件具体的事
- 哪些单据进系统，哪些明确留在系统外，留在系统外的怎么跟系统里的数对上。
- 主数据谁维护：物料、客户、供应商这些编码，第一期就得有归属，不能等第二期再补。
- 这一段的结果交给谁、以什么形式交：是报表、是导出，还是直接给下一环用。
- 第二期接进来时，接口大致落在哪张单据上，先留个位置，不必现在就开发。
这几条写下来，第一期才有个能验收的说法。否则「先上一个模块」会变成一个谁都能解释的口头约定，验收时各说各的。
三、主数据别放到第二期
最常见的失误，是把主数据整理当成后续工作。第一期先用着现有编码，等上第二期再统一。问题是第二期一来，发现两期编码对不上，要么改第一期的历史数据，要么长期挂一张对照表。
编码规则、单位、谁有权新增，这些在第一期就要定。数量可以慢慢补，规则不能等。
四、什么情况下不适合分期
如果业务链本身很短，几步就走完，拆开反而多一道交接；或者几块数据强耦合，缺一块系统就算不出结果。这类情况硬分期，第一期会做出一个谁也用不上的半成品。
还有一种：现场正处在组织或流程调整期，规则本身没定。这时候先上任何一段，都是在给还没稳定的做法固化系统。先等等比先上更省事。
可以先上一段，但那一段得能自己走到结果。走不到，就只是把断点挪了个地方。
