入职半年，对平台的业务逻辑还不是很熟，领导安排了一个任务：从零搭建公司内部的BI 数据系统，V1.0。目标很明确——让业务方能自己看数据做分析，不用每次都找研发导出。听起来不复杂，但真正上手之后，发现难点不在"做报表"，而在搞清楚数据本身。

做 BI 系统的第一个版本，我犯了一个顺序上的错误

为什么要做这个系统

当时业务方要数据的方式很简单——提需求给研发，研发写 SQL导出来。问题是这个过程很慢，而且业务方自己对数据的计算口径也不统一，同一个指标不同人算出来的结果可能都不一样。

所以这个 BI 系统要解决的，不只是”让业务方自己看数据”，还得把数据的计算逻辑统一起来。

一上来就做报表，踩了第一个坑

一开始我的思路是直接做报表。业务方说想看商户数据、产品数据、销售数据，那我就按这个方向去设计。但很快发现推不动，因为底层的计算逻辑没理清。

平台的订单类型很多：平台自营、租户分销平台代发、租户分销租户发货、租户自营，还有跨境订单。每种类型的金额计算方式都不一样，再加上售后退款、重发，责任方还分工
厂、平台、租户，排列组合下来非常复杂。

我当时就是卡在这里——报表的框架画出来了，但数据怎么算对，还没搞明白。

转向：先啃数据源

后来我想明白一件事：报表只是数据的呈现方式，真正要啃的是数据源。

于是我开始梳理订单基础表。先把每种订单类型的金额组成搞清楚——产品收入、物流收入、服务费、成本，这些字段分别从哪来、怎么算。再把售后场景逐个拆解，退款和重发分别怎么影响各项金额，责任方不同计算逻辑又有什么区别。

这个过程很痛苦，但理清楚之后，发现一个关键点：只要订单基础表的金额算对了，后面不管是商户报表、产品报表还是销售报表，都是从这张表的字段进行二次计算，逻辑是通的。

上线之后发生了什么

系统上线交付给业务方之后，最直接的变化是业务方不用再频繁找研发导数据了，自己就能在系统里看。

还有一件让我印象深刻的事：业务方用了一段时间之后发现，之前自己算的一些数据其实不太准。因为以前是各人各算，口径不统一，现在通过 BI 系统有了统一的计算逻辑，数据反而更可信了。

我学到的

回头看这个项目，最大的收获不是做出了一个系统，而是搞懂了一件事：做数据类产品，顺序很重要。

正确的做法分三步：

第一步，梳理数据源的计算逻辑。每张表的字段从哪来、怎么算，先搞清楚，不要急着做展示。

第二步，建一张基础表。把最底层的数据算对，这张表是整个系统的地基。

第三步，其他报表从基础表派生。有了地基，上面的报表怎么拼都顺。

如果一上来就想做报表，就像盖房子先搭屋顶，迟早要塌。

另外，这个项目让我对平台的订单模块有了更深的理解。入职半年时接到这个任务，某种程度上也是被逼着快速补课。从订单类型、售后流程到跨境的金额组成，很多之前模糊的东西，这次都搞清楚了。

写在最后

如果你也在做数据类的产品，或者正在从零搭建一个 BI 系统，记住一件事：先别急着画报表，先把数据源的计算逻辑捋清楚，建好基础表，再往上搭。