最近连着看了几个工厂拆分的方案，发现一个共性：技术方案写得很细，范围说明却只有两页纸。

问起来都说"范围后面再细化"。可范围不细，后面的验证就没有比对基准。今天把范围这块摊开聊聊，欢迎拍砖。

先说我的观点：拆分的难点不在迁移，在定义

工具能做的是执行。定义不了的是三件事：哪些数据必须跟着走、哪些必须留下、留下的那部分由谁继续负责。

这三件事定不下来，工具再好也只是把错误执行得更快。

三轴切分，我用得最多

组织轴：工厂代码、库存地点、公司代码。这里有个必答问题——一座工厂横跨多个公司代码怎么办？同一公司代码下有多座工厂又怎么办？两种情形都要先定最小拆分单元。

我见过的最小单元定义含糊的项目，范围说明改了四版还没定稿。

时间轴：财务要几年历史、业务要几个周期对标，取并集，其余归档。这条必须财务和审计一起定，IT 单方面拍没用。

状态轴：未清项整单迁移，已结清按年限。这条最容易在执行时变形。

未清项为什么不按比例切

有人问过：数据量太大，能不能按比例迁一部分未清订单。

不能。一张采购订单切一半，两边都不能收货——供应商发的货对不上任何一张完整的单。财务上也一样，未清项按比例切，账龄结构就散了。

这一条我建议直接写进范围说明，作为不可谈判项。

跨工厂往来，坑最深

跨工厂库存调拨、集中采购与集中付款、跨公司销售、共用成本中心与利润中心。

拆完要逐条判定：保留为内部往来，还是转成外部交易。

我的经验是这件事必须财务主导。IT 判不了——你以为的调拨，在财务眼里可能是销售；你以为的集中付款，可能涉及三个法人主体。

判定产物是一张映射表：原关系类型、拆分后类型、凭证类型与科目、责任人。没有这张表就切，问题会在第一次月结集中出现。切换当天一切正常，一个月后才发现对不平，那时候修复成本高得多。

切分日：能互推才算想清楚

财务要按切分日切出总账余额、未清项、存货金额，满足两个一致：总账与明细账一致、存货数量与金额一致。

我加一条自检标准：切分日的余额要能双向往返核对，从源推得出目标，从目标也推得回源。

只能单向推的，说明中间有环节没交代清楚。这条在评审时特别管用。

停机时长：不要拿别人的数字套

多数项目技术停机在 8 到 60 小时。有 30TB 用了 51 小时的，也有 260GB 用了 8 小时的。

差了 6 倍多。差异不在工具，在范围与复杂度：公司代码数量、工厂数量、自开发对象、接口数量。

所以看到"我们做过 XX 小时"的说法，下一句应该问：那个项目的范围和我们差多少。

顺序：先建结构，再灌数据

目标侧先把组织结构、会计科目表、工厂级主数据、编号规则建好，再接收数据。

这样拆出来的是能直接跑的系统。反过来做，会在上线后不断补配置。

这一步业界有个叫法是空壳转换，思路就是先有结构再有数据。我认同这个顺序。

两个问题，想听听大家的做法

第一，切分日选月末还是月中，你们实际怎么权衡？我们这边财务倾向月末（期初干净），但月结和切换撞车，运维压力很大。

第二，跨工厂往来的映射表，是财务出还是 IT 出？我坚持财务出，但实操里经常变成 IT 先列一版再让财务确认，效果差不少。

有踩过坑的欢迎补充。