就我的觀察，在多數的企業裡，商業智慧的解決方案大概可以分成三個不同的階段，分別對應三種不同的作法：

1. 大表做為主要介面
2. 整合型 BI 軟體做為主要介面
3. 資料建模層 (data modeling layer) 做為主要介面

大表做為主要介面

一間公司無論有沒有專門的 IT 團隊，總之，工程人員最後就是想方設法，把需要分析的資料，整理成所謂的大表 (one big table)，又或是稱之為反正規化格式 (denormalization form) 。於是，這個大表對於資料的最終使用者來說，就是主要介面。一旦需要分析的資料整理成這種形式了，分析人員又或是資料的使用者可以簡單地理解資料、操作資料，也不需要什麼特殊的軟體，試算表就可以了。

大多數的公司停留在這個階段。然而，這個方式有一個明顯的缺點：「要新增資料，通常都要等。」要等的最主要原因，是在等 ETL 程式的開發。

要新增指標 (metrics)，有時都往往需要新增對應的 ETL (extract-transform-load)，而 ETL 只有工程人員有辦法寫，這時分析人員就得要等待。這個等待時間長短因公司而異，增加等待時間的原因有：

• 工程人員很有可能還要維護公司的其它軟體系統，而非專職負責只寫 ETL 。
• 產生新的資料分析需求的速度往往比開發 ETL 程式的速度快上許多。
• 舊的指標也很有可能很快地過期，於是又需要開發新的指標。

整合型 BI 軟體做為主要介面

目前最流行的整合型 BI 軟體是 Tableau 與 PowerBI 。

資料分析人員如果可以善用這類 BI 軟體的話，由於 BI 軟體可以直接介接資料倉儲 (Data Warehouse)，又或是直接匯入 csv 檔。有一些第三方的資料，分析人員已經可以依賴圖形化介面，拉一拉，就把指標拉出來，也因此，有機會大幅減少了等待開發 ETL 程式的時間。

這類的 BI 軟體由於功能強大，除了圖形化界面讓一般人比較容易上手基本的操作之外，往往還搭配一組強大的『領域專用語言』(Domain specific language)。以 PowerBI 來講，是 DAX (Data Analysis Expressions) 。在 Tableau 的話，則是 MDX (Multidimensional Data Expressions)

使用這種方式的話，主要的缺點是『指標定義容易不一致』：

考慮一間公司可能有業務團隊、生產團隊、行銷團隊，這三個團隊如果都要利用資料來輔助決策的話，很有可能三個團隊都各自有至少一位專門的資料分析人員，透過 BI 軟體來做出指標。然後，不幸的事就發生了，由於三組人是獨立運用 BI 軟體做出的指標，一間公司可能有好幾個名稱相近、定義略有差距的指標，於是三個團隊產出的報表，總是充滿互相矛盾，難以調合。

資料建模層 (data modeling layer) 做為主要介面

想象一下，我們大概會如何運用資料。比方說，看到一個銷售業績預測數字，覺得它有點不太合理時，我們會問什麼問題？

「這個數字怎麼來的？」

如果分析人員回答，『嗯，這個需要等一下，因為中間的運算過程很複雜。明天，我解釋給你聽。』這種答案應該讓人覺得緩不濟急。

資料建模層做為主要介面的這種方式，它的特性是：

• 除了提供最終的報表、最接近決策的高階指標之外，高階指標產生過程之中利用到的所有中間層資料 (intermediate data)，也會一一被清楚地記錄在資料倉儲裡。如此一來，資料的使用者，甚至可以不透過資料分析人員，直接查閱資料倉儲就可以得到答案。

上述的中間層資料與高階指標合起來，我們可以稱之為資料建模 (data modeling)。 由於資料建模都統一地存放在資料倉儲裡頭，資料分析人員要生成新的指標時，也會儘量地去複用既有資料建模，就像開發軟體時，軟體工程師會儘可能地複用已經模組化的程式碼一樣，既可以提高一致性、又可以減少重複的工作，而且全公司的資料分析人員也可以共用一組通用的資料建模。

資料建模層做為主要介面算是最現代化的作法，該作法也可以視為是把軟體工程累積的經驗與紀律，一一應用在資料分析領域。由於相對先進的關系，這個作法是目前最少公司採用的。

後續的文章也會繼續深入介紹這個作法。