两套报表并行两个月，同一个指标差了七个百分点

迁移工具这件事我们做了大半年，中间并行跑了两个月。合并那天，同一个毛利率指标，新报表显示十二个点，旧报表显示五个点。

分批迁移的意思是两个月里有两套

迁移按部门分。第一批三个部门搬过去，第二批等下个月。旧的平台上还有业务在用，报表明细都在，问题是没人维护了——口径改了没人通知，加了字段没人说，改错了也没人改。

新的平台上第一批迁的人是照着自己的理解接的，照的不是老口径。这个理解在接的过程里从来没人复核，各人各接各的，同一个指标五个人五种理解都不稀奇。

差的那七个百分点在哪

同一份底表，两个算法

合并那天的排查走了半天，最后定位到两处。

一处是退款。旧的报表把退款按发生月扣，新的报表按订单原始月扣，同一个三月的数据，差了两个月。

一处是头程。旧的报表用财务入账的单价，新的报表用运营下单时记的单价，两个单价之间差着一段汇率和一次调价。

两处都是口径不同，没有一处算错。

第三行是查的过程中顺带发现的，之前谁都没注意。这类差三行的东西最危险，因为它单项小到没人会去查，堆起来就是七个百分点。

二十三个同名指标对了一遍

合并那天下午我们还做了一件事：把两边所有同名指标列成一张对照表，一共二十三个，其中十一个有差异，十二个完全一致。这张表后来留在了文档里，迁移期间每次发数都要附一句哪套是活的。

对照表还顺手清掉一类问题：有两个指标名字一样但算法完全不同，只是业务上一直没人在用。这种是分叉最早的信号，两套系统各活一年就分叉成两个东西，等到有人发现的时候，已经没法凭名字判断该看哪个。

合并之后定下的规矩

这件事之后我改了做法：任何指标在迁移期间只能有一个活口径，旧平台的报表要么原样锁住不改，要么标注为归档，不允许顺手优化。

锁住不动的意思是旧平台那边的维护权限收掉，冻结在迁移前一天的状态。这样两边算的就真是同一件事，差异只可能来自工具本身，不会来自算法漂移。这条规矩后来又立了一次，那是换看板，同一批人，两周就迁完了。

差七个百分点这件事本身是好事

差的七个百分点暴露得不算晚——合并那天发现的，还在合并当天。真正亏的是另一种情况：两套报表并行，各发各的会，两个月里两个部门拿着不同的数开会，谁也没发现。

那时候没人报警，因为两边各自都自洽。工具迁移的风险不在搬家那几天，在搬家开始到旧系统关掉之间的那段日子。那段日子里没人说得清全公司一共有几套口径，也没人说得清自己看的那套是从哪来的。

那两个月里我做错的一件事是把它当成技术活来排期。排的是开发、测试、上线三段，没排口径对齐。后来再遇到类似的事，排期第一段固定是口径确认，哪怕技术上一行代码都不用动。