第 2 章 · 企业第一次想看见自己：数据仓库与 BI

交易系统上线以后，企业很快会发现一件事：数据是有了，但问题不一定更好答。

电信运营商的计费系统可以记下每一次通话、每一条短信和每一笔扣费；客户系统知道用户是谁，营业系统知道他办过什么套餐，客服系统又留着投诉和处理记录。

如果问某个号码昨天扣了多少钱，沿着交易记录去查就行。

但管理层问的通常不是这个。

他会问：哪个区域的收入在掉？哪类客户最容易流失？一次促销到底拉来了新用户，还是给原本就会续费的人打了折？投诉增加，是网络质量、计费规则，还是营业厅解释不清？

这时，问题已经从“把一笔交易办完”，变成“把很多笔交易放在一起看”。

生产系统和分析系统，从一开始干的就不是同一种活。

一套系统负责办事，另一套系统负责回头看

交易系统最怕慢和错。

银行转账不能等分析跑完再记账，库存扣减不能让两个订单同时拿走最后一件货。它需要快速、准确地处理大量并发的小交易。这类工作后来通常被概括为 OLTP，也就是联机事务处理。

分析的脾气正好相反。

分析人员会一次读取几年数据，按地区、月份、产品、渠道来回切换，今天看汇总，明天追到明细。他很少修改原始交易，却会做很重的查询。这类工作一般归到 OLAP，也就是联机分析处理。

让同一个系统同时伺候两种脾气，理论上不是完全不行，代价却很高。IBM 对数据仓库的解释很直白：它主要为查询和分析设计，而不是为交易处理设计；它把多个来源的数据集中起来，也保存历史。

这就是数据仓库最初让人着迷的地方。

企业终于可以把散落在不同业务系统里的记录抽出来，清洗、转换，再装进一个适合分析的地方。这个过程后来被三个英文字母概括：ETL。

名字很技术，实际干的往往是脏活。

客户编号对不上，要找规则；同一个“收入”，财务按确认口径算，业务按下单口径算；昨天还叫华南区的组织，今天拆成两个大区，历史报表到底跟着新组织回算，还是保留当时样子？

代码只是最后那一步。前面最费时间的，是逼着不同部门承认自己嘴里的同一个词，可能根本不是同一个东西。

指标是一种临时停战

做 BI 久了，很容易产生一种错觉：只要把口径统一，企业就拥有了事实。

事情没这么简单。

比如“客户数”。市场部门可能把留下手机号的人算客户，销售只认进入商机池的，财务只认付过款的。三种定义各有用途，不能简单说谁错。

需要统一的，不一定是全公司只能保留一个数字，而是每个数字必须说清楚：算了谁，没算谁，用来回答什么问题。

这就是为什么指标体系从来不只是数据团队的工作。一个指标一旦进入考核，定义就会改变人的行为。

按订单额考核，销售可能愿意接回款很差的单；按收入考核，确认时点会变得敏感；按利润考核，成本分摊又会吵起来。技术团队以为自己在定义字段，业务部门知道他们其实在划分功劳和责任。

所以，所谓“统一口径”，很多时候是一场临时停战。

数据仓库把停战协议写进模型，ETL 每天照着协议跑。模型能保持一致，却不能保证协议永远合理。组织变了、业务变了、考核变了，昨天的统一口径可能就是今天的历史包袱。

为什么金融和电信较早走到这一步

中国早期的大型 BI 和数据仓库项目，经常出现在金融、电信等行业，不难理解。

这些行业每天产生大量结构化交易，业务天然依赖记账、计费和风险控制；组织规模大，跨区域经营，管理层也确实需要从海量明细里看到整体。与此同时，它们有能力承担昂贵的软件、硬件和实施成本。

还有一个常被忽略的原因：它们不能只靠“老师傅大概知道”。

账要对，费用要能解释，风险要留下依据。即使分析暂时没有直接增加收入，稳定、可追溯和可审计本身也有价值。

这与后来很多传统企业跟风建设 BI 的出发点并不完全相同。有的企业先看见了别人的驾驶舱，再回头问自己有什么数据可放；有的项目立项时就写着“辅助决策”，却没有说明要辅助谁做哪一个决定。

结果是，报表上线了，目标也算完成了。

BI 的理想，本来就不只是出报表

1958 年，IBM 研究员 Hans Peter Luhn 写过一篇题为《A Business Intelligence System》的论文。他讨论的是如何自动获取、编码、传播和检索信息，让组织中的“行动点”收到相关材料。

这个设想并不保守。它甚至已经碰到了今天大家关心的事：信息怎样流向该采取行动的人。

后来 BI 在商业落地中，更多时候被压缩成报表、查询和驾驶舱。不是这些东西没用，而是它们比较容易采购、建设和验收。

一个驾驶舱有多少张页面，能数；报表响应几秒，能测；数据每天几点更新，也能写进合同。

至于管理者看完以后有没有改变决定，业务部门有没有照着执行，利润是不是因此增加，通常已经超出 BI 项目的验收范围。

于是，系统给了企业一面越来越清楚的镜子。

镜子能告诉你库存积压、客户流失、成本上升，却不能替任何人决定接下来怎么办。它也不能解决一个尴尬的问题：有些人不是没看到，而是不想动；有些人想动，却没有权限。

报表越多，不代表共同事实越多

自助 BI 普及以后，做一张报表比以前容易了。这当然是进步。业务不用所有问题都排队等 IT，数据团队也不必天天改列宽和颜色。

可工具门槛一低，另一个问题冒出来了：每个人都能做出自己的答案。

同一场会议，销售带一张表，财务带一张表，运营打开在线仪表盘。数字不一样，大家先花半小时解释口径，再花半小时争谁的更接近老板想看的版本。

这不是回到了没有数据的时代。恰恰相反，这是数据太容易生产以后才会有的麻烦。

企业慢慢发现，它需要的不只是一个集中存放历史数据的仓库，还需要主数据、指标治理、血缘、权限和一整套服务。业务变化越来越快，数据团队如果每次都从源系统重新接、重新洗、重新建，队伍再大也追不上。

一张报表开始向一套共享能力膨胀。

接下来，大数据和数据中台登场了。

它们要解决的问题，不再只是“怎样看见”，而是“已经做过的东西，怎样不必每次重做”。

本章资料

场景说明：本章电信经营分析场景用于解释典型系统分工，不对应某个具体运营商项目。