早上遇到个数据问题，想到了这个点，关于数据出口的，这个数据出口就是泛指统计报表、数据展示等，详情往下看。
故事背景
故事是这样的，公司有十几套业务系统，开发小组也有6+以上，正常来说数据组应该统一制定指标定义、指标口径，一般也是统一的数据展示平台，但是吧，实际情况不是的。
各个业务团队相对独立，会开发各自的一些系统，有了系统之后还会做些统计监控，这就需要一些指标了，然后，他们首先是自己做，反正就几个sum，几个count，就按照自己的需求来做数据统计了（讲道理，这个需求也没问题，但是，这也暴露出各个团队之间的职责不清楚，遇到问题主要想自己解决，没有和负责该业务的团队沟通，同时暴露出扁平化管理的一个小漏洞吧，各个业务团队并行，没有中间人统一协调，各个团队各自为战）。
这个数据一般是开发团队自己看或者给对应的业务部门看。这会出现什么问题呢？有些指标，各个业务组都会看，每个组的逻辑还不一样，平时一开会一讨论就出现你的和我的不一样，公说公有理婆说婆有理。
后面这种情况有些好转，为啥呢？是因为有些指标业务逻辑复杂，要跨好多系统或者数据量比较大，他们做不了了，然后问题抛出来了，再然后就找到我们数据组了。
这虽然是个好机会去统一口径，但是人手的确有限，又要开发丰富数仓模型，又要配合测试验证，以至于一段时间每天加班到11点左右。
最后像CRM团队、门店团队、货架团队、TMS团队......都有自己的数据平台，一部分数据是数据组推送给他们的，一部分是他们自己算的或走接口调用其他业务方的。
隐患
这个问题其实我老早就和老大反映过，数据出口太多，公司没有办法站在一个角度看问题，很容易出问题，数据组一定要收紧出口，统一口径。也由于一些现实的问题，像人手不够，没法承接那么多需求，这个问题也是在一点一点去改变。
- 同一个指标，各个组定义不同，数据当然也不一样
- 各个小组浪费人力去开发各自的数据平台，浪费了人力成本、时间成本
- 业务同学产生混乱，不知道该相信谁
- 就算指标定义定义清楚，不同的人开发，还是会出现数据不一样的情况
- 如果指标逻辑要变更，要通知很多业务团队去改，这又会浪费很大的成本
总之，尽量避免这种情况出现，指标这种东西，有一个逻辑，一个出口就好了，数据的统计、展示平台有一个也够了
网友评论