第一代BI時期

每個月底，小A總有那么幾天重復著下面的工作：

1. 從ERP系統的財務模塊中下載發票數據到Excel

2. 從CRM系統下載顧客數據到Excel

（...此處省略多個其他維度...）

3. 將這幾個表用vlookup 和 sumif給連起來

...安靜的等待Excel計算幾十分鐘...

...如果死機，那一定是天意讓我coffee break 然后再重復以上步驟，...

4. 形成數據透視圖

5. 截圖粘貼到ppt, 發給老總

老總已經不是當年那個歲月靜好的老總，看看靜態的ppt已經不能滿足他的需求。

“小A啊，整體銷售情況不錯，幫我分析下蘇錫常的具體情況”

于是小A重新打開那200MB的Excel工作簿，當然，打開的時候少不了那十來分鐘的數據加載和重新計算。

小A耐著性子再篩選工具中選擇“蘇錫?！贝髤^，發現文件還是很大，不得不在數據層刪除了非蘇錫常的數據，好歹讓Excel文件大小降低到了100MB. 但還是沒法以附件的方式發給老總啊。折騰了大半天，最后U盤給了老總。

老總又提出了讓小A懷疑人生的世紀難題 “小A啊，能不能把蘇錫常和京津冀對比下？然后數據文件發給北京的同事？”

這樣的場景相信大家并不陌生，那繁瑣的數據處理與合并步驟（vlookup, sumif）, 龜速的數據引擎的性能（等待Excel計算十幾分鐘），單一的數據分享機制（U盤）和稻草人一般的企業安全制度（誰都可以轉發郵件中的Excel數據文件）。

第二代BI時期

小A正在使用第二代BI工具探索為什么京津冀地區的銷售有季節性的變化，想下鉆到產品層面。很遺憾產品的字段都不在上游的數據倉庫中，需要IT團隊將改字段從數據庫同步到數據倉庫，才能再將該字段添加到展現層分析。一般逃不了下面幾個流程：

1.業務部門提出需求添加/修改字段

2.IT分析需求，做出變更

3.測試

4.交付

5.業務部門在實際場景分析中想想覺得這次變更不能佐證之前的假設，又提出新需求....

第三代BI時期