管理學的理論指出：『很多的組織都有會議太多的病症』。這類病症主要有兩種形式：

首先，有一些會議的主要用途是用來滿足管理階層的自我感覺 (ego) 之用，這類型的會議刪去的話，損害的只有主管的心理健康，但是對於組織的整體效能會極有幫助。

再來，也有一些會議是跨不同工作團隊的會議，而且一旦召開了第一場之後，就會引發無數場後續的會議。這種情況是因為要進行的工作在不同的工作團隊之間有緊密交錯依賴的特性，因此永遠會有開不完的會議。對於這類型的會議，解決方案是：『重新編組工作團隊、或是甚至重新規畫工作流程，以讓需要溝通的資訊大為減少。』

BI 的工作常引發無數的會議

以商業智慧報表 (BI dashboard) 的工作為例，特別容易有無止盡的溝通問題。在許多公司，最初要做出銷售預測、 業績歸因之類的報表，公司規模小的時候，就直接先用試算表軟體 (spread sheet) 來做。到了公司有一定的規模了， 或是資料量很大了，超過試算表軟體的極限時，就會改成使用資料倉儲來做。一旦改成使用資料倉儲，分工就開始複雜了起來，通常會有三種角色與任務：

• 管理階層對資料分析師提出問題。
• 資料分析師分析資料、以回答管理階層的提問。
• 資料工程師寫 ETL(Extract、Transform、Load)，把資料從原始資料來源(data source)搬移並做資料轉換，最後存放到資料倉儲，將可供分析的資料備齊。

實務中的工作流程的順序往往是：

1. 管理階層提出問題。
2. 問題經過資料分析師的分析之後，很可能會發現既有的資料不足夠回答，需要引入新的資料。
3. 需要新資料，這就一路把工作延伸到了資料工程師 一端。資料工程師尋找了所需的原始資料來源，並且在資料倉儲中設計了合理的資料表，並且開發對應的 ETL 程式，將資料灌入資料倉儲。
4. 新資料備齊後、交給資料分析師之後，卻常常發現問題還是無法回答；因為新資料的缺值太嚴重，需要再做一些處理、又或是必須再引入新的資料。於是又回到了步驟 3。反覆在 3 與 4 之間不斷輪迴數次之後，才終於可以回答管理階層提出的問題。

上述工作流程的每項環節的速度並不一致：步驟 1 的速度最快、步驟 2 的速度次之，而步驟 3 則是瓶頸。上述的工作流程就像戰爭中拉得過長的補給線：資料分析師不斷在管理階層與資料工程師間來回溝通需求，疲於奔命。同時，後方支援的資料工程師忙得焦頭爛額。

新的工作流程 ELT 做為解決方案

有一種新的分工方式，可以大幅改善上述的問題：「用 ELT 取代 ETL。」

什麼是 ELT 呢？ELT 是指：資料在原始資料來源與資料倉儲間的移動，只保留取出 (Extract) 與存入 (Load) ，捨棄了資料轉換 (Transform) 。 資料轉換，也就是資料形狀轉換與資料清理，改成在資料倉儲內部透過 SQL 來完成。

採用新的分工方式之後，會有兩種正面的效應：

1. 資料轉換的部分因為可以透過門檻較低的 SQL 來進行，所以可以讓資料分析師自行完成，這就消除了 針對資料轉換工作的會議需求。另一種分工方式，資料轉換交由專門的分析工程師 (Analytic Engineer) 來撰寫，由於分析工程師負擔的程式設計工作只佔所有工作的小部分、他們通常是多數時間與管理階層密切合作，而非歸屬於工程團隊，一樣可以消除資料轉換工作的會議需求。
2. 資料工程師的工作量會因為從寫 ETL 變成了只寫 EL ，因而大幅下降，於是就減少了資料分析師與管理階層的等待時間。

工作的流程與分配重新設計之後，不僅減少了會議 (緊密交錯依賴)，還提高了效能。

其它資源

1. 對 dbt 或 data 有興趣 👋？歡迎加入 dbt community 到 #local-taipei 找我們，也有實體 Meetup 請到 dbt Taipei Meetup 報名參加
2. 歡迎訂閱 PruningSuccess 電子報，主要談論軟體開發、資料處理、資料分析等議題。