Power BI 完整指南：從 Excel 資料整理、DAX 分析到企業決策儀表板實戰

本文適用於想了解 Power BI、親手完成第一份報表，或評估企業導入商業智慧工具的讀者。產品功能及授權條件依 2026 年 10 月 21 日可查核的 Microsoft 官方資料整理；授權價格與雲端功能可能調整，採購前請再次確認。文章中的公司、訂單、金額與成效檢核資料，如未特別指明來源，均為教學用模擬情境，不代表真實企業績效。

一份營運會議資料，可能在開會前已經被整理了三次。財務部從會計系統匯出收入，業務部從 CRM 匯出訂單，電商部從購物平台取得銷售明細。每個部門都很認真，但會議中出現的三個「營收」仍可能不同。主管問：「這個月到底賺了多少？下降是哪些商品造成的？明天要先處理哪一個問題？」於是會議開始花時間對帳，而不是做決策。

這不是再多做一張圖就會解決的問題。真正麻煩的地方是資料從哪裡來、哪些交易該算進來、哪些人能看到結果，以及下一次更新時能否維持同一個口徑。Power BI 的價值正位於這幾個問題的交會處：把分散資料轉成可重複的分析模型，讓不同使用者基於相同定義探索績效，並藉由報表與權限管理，把數字交付給需要採取行動的人。[S01]

然而，工具本身不會替企業決定「營收」的意思，也不會知道退款、取消訂單、稅額和跨月認列該如何處理。Power BI 導入失敗的常見原因，往往不是做不出圖，而是沒有先定義資料責任與決策問題。本文從第一性原理出發：先確認要改善哪個決策，再處理資料、模型、計算、畫面與交付。讀者可以只做個人練習，也可以把後半部當成部門導入與驗收的藍圖。

一、Power BI 是什麼？先看它如何改變工作，而不是先看圖表

Power BI 是 Microsoft 的商業分析平台，能將 Excel、資料庫及其他來源的資料連接、整理、建模、分析與分享。官方把它放在 Microsoft Fabric 的分析體驗之中，但一般使用者不必先買一整套資料平台，才能在 Power BI Desktop 開始製作報表。正確的入門順序是先理解 Desktop、Power BI 服務以及語意模型各自負責什麼，再決定需要哪些附加能力。[S01][S02]

Power BI Desktop 是報表開發的 Windows 應用程式，主要用來連接來源、進行 Power Query 轉換、建立資料關聯與 DAX 度量值，以及排版互動式報表。它可以免費下載，適合個人學習、原型製作與報表設計。這不等於企業內部任何分享情境都免費。Power BI 服務（Power BI Service） 是瀏覽器中的雲端協作環境，用來管理工作區、發佈報表、設定重新整理、授權存取及提供應用程式。語意模型（Semantic Model） 則位於資料與視覺之間，定義表格、關聯、度量值與計算邏輯，讓多張圖共享一套指標語言。[S01][S02][S06]

還有兩個容易混淆的名詞。Power BI 的「報表（Report）」通常包含一頁或多頁，可用切片器篩選、交叉醒目提示及向下探索；Power BI 服務中的「儀表板（Dashboard）」則是一個單頁畫布，可以彙集來自不同報表或語意模型的視覺磚。日常中文常把兩者統稱為儀表板，但若要管理正式產品與權限，不能將這兩個物件視為同一種東西。[S07]

將它想成一個組織裡的分工會更直觀：資料來源提供原始交易，Power Query 負責可重複的前處理，語意模型負責一致的商業定義，報表讓人探索問題，而 Power BI 服務讓資訊在正確時間送到正確的人手裡。少了其中一層，也許仍能做出畫面；可是當檔案變多、部門增加或責任轉交，維護成本就會開始浮現。

Excel 和 Power BI，應該選哪一個？

許多人搜尋 Power BI，是因為 Excel 報表已經越做越大。Excel 並不是過時工具，它擅長臨時計算、人工檢視、財務試算、一次性的資料修訂，以及把分析結果轉成可操作的工作表。相對地，Power BI 適合在資料來源較多、更新需要重複、同一套指標要給不同角色檢視時，建立可控的報表體驗。兩者不是二選一；企業往往同時需要 Excel 的彈性與 Power BI 的一致性。

上表是編輯部依功能特性製作的使用情境判斷，不是 Microsoft 宣告的絕對分界。若企業還無法說清楚核心指標與來源，先用 Excel 整理好資料字典，可能比立刻投入新的平台更有效。若每週都在複製貼上、合併多個檔案、反覆核對同一數字，才是值得檢驗 Power BI 的訊號。

另一項入門現實是設備。Power BI Desktop 的正式桌面應用程式以 Windows 為執行環境；使用 macOS 的學習者可以在瀏覽器使用 Power BI 服務，但不能假設所有 Desktop 功能都直接存在於 macOS 原生應用程式。若課程指定 Desktop 實作，應先安排符合官方支援條件的 Windows 環境，而不是上課才發現無法操作。[S02]

營運會議到底需要哪種報表？

先不要把所有能取得的數字放上首頁。假設一位營運主管每週只需要回答三個問題：本月銷售有沒有達標、毛利下降從哪裡來、哪個通路需要優先介入。那第一版報表只要能回答這三件事，價值就可能超過一張有十五種圖表的展示頁。

一個有效的 Power BI 專案，起點應該是「決策清單」，不是視覺物件清單。決策清單必須包含決策者、決策頻率、觀察的指標、可採取的動作及行動期限。這會反過來決定資料細緻度、更新頻率與報表布局。例如每月策略會議通常不需要每分鐘重新整理；即時配送監控則需要另外評估資料管線、查詢能力和成本。把所有情境都叫做「即時 Dashboard」，只會在技術與預算上製造不必要的承諾。

二、為什麼報表數字經常對不起來？先制定指標契約

真正會讓主管失去信任的，通常不是圖表太難看，而是同一個數字換了人、換了時間或換了資料來源就改變。想像一份業績表把已下單未付款的訂單列入營收，另一份表只計已收款交易；財務部則依會計認列月份入帳。三份資料都可能在自己的工作情境中合理，但不能都叫「本月營收」。

要解決這個問題，企業先需要一張簡單但嚴格的「指標契約」。它不等於建立龐大的資料治理委員會，而是把最常被討論的數字定義為可被檢驗的規則。對每個指標，至少寫下業務意義、來源、計算範圍、排除條件、日期依據、更新責任與驗收方式。若涉及多個幣別，還要確認匯率日期與換算規則；涉及跨期交易，則需定義退款、折讓與調整分錄處理原則。

這樣的表格看起來比圖表不起眼，但它有一個關鍵效果：當兩個部門的數字不同，大家可以問「差異來自日期還是交易範圍」，而不是相互懷疑對方資料有錯。Power BI 的 DAX 度量值可以固化計算邏輯，卻不能代替人決定邏輯是否符合業務目的。

第一步不是清資料，而是確認資料粒度

「粒度（Grain）」是每一筆資料究竟代表什麼。銷售資料一列可以是一張訂單、一個訂單明細、一筆付款，或一個每天的商品彙總。這些不是可以任意交換的定義。若一張訂單含三種商品，而資料每列代表一個品項，直接用列數計算訂單數會把一張訂單算成三張。若同一張訂單又有兩筆付款，與付款表直接合併還可能讓金額倍增。

因此，資料盤點時應先把以下問題寫在同一頁：唯一識別碼是什麼？是否有重複？取消、退貨與換貨用什麼狀態表示？同一來源的日期有時區差異嗎？是否混用新台幣和外幣？如果這些問題無法回答，先不必急著新增視覺效果。模型若在粒度上錯了，後面任何精緻的 DAX 都可能只是把錯誤算得更快。

從決策倒推資料，而不是從資料倒推所有可能的圖

最容易失控的導入方式，是 IT 或分析師一次匯入所有資料，再期待主管看到後提出需求。資料越多，討論越發散，模型複雜度與授權爭議也越高。較好的方式是選一個高頻決策，例如「每週哪些商品在拖累毛利」，接著確認回答這個問題所需的最小資料集：訂單日期、商品、數量、售價、折扣、成本以及取消狀態。這些欄位足以支援第一版探索，其他來源等需求成立再接。

在規劃會議中，可以把每個需求寫成一句可以驗收的話：「營運主管能在每週一檢視上週各區域毛利率，選出需要追查的三個品項，並能回到訂單明細確認異常。」這一句話同時約束報表、資料、權限與業務流程。相反地，「做一套完整 BI 平台」沒有定義完成條件，很難判斷是否值得投資。

三、Power Query：讓每次更新不再重新複製貼上

使用 Power BI Desktop 開啟 Excel 檔案後，新手最容易直接按載入，接著開始拉圖。這樣做能快速看到成果，卻可能將來源資料中的錯誤一起放大。Power Query 是 Microsoft 的資料連接與前處理技術，可在 Power BI、Excel 等產品中處理匯入和轉換工作；它讓資料清理成為可以重複執行的步驟，而不是散落在每個人的手工修改記錄。[S03]

假設某家公司每個月都會收到三個區域業務的 Excel 檔案。欄位名稱不一致：北區叫「訂單日期」，中區叫「交易日」，南區叫「Date」；某個月份商品代碼有前導零，另一個月份日期被存成文字。若每次都人工貼入總表，再修改公式，檔案數量增加後必然難以追溯。如果先建立固定資料規格，在 Power Query 中依序變更欄名、型別、欄位、狀態與資料格式，下一次資料進來時就能沿用同一套流程。前提是來源結構仍符合規格，並且例外資料有被記錄而不是靜默丟棄。

一次可重複的資料清理，應該包含哪些步驟？

先保留一份不可覆寫的原始資料，並確認來源版本與取得時間。接著在 Power Query 檢視欄位型別，將日期欄轉成日期、數量轉成整數、金額轉成合適的數值型別。再清理空白、明顯非法值與編碼差異。涉及客戶編號、商品代碼、統一編號或帶前導零的識別碼，通常不應隨意轉成整數，否則 00123 可能變成 123，日後再也無法可靠地與原系統對接。

合併資料時，要分清楚 Append（附加查詢） 與 Merge（合併查詢）。附加是將欄位結構相容的資料上下接成更長的表，例如合併各月交易；合併是依鍵值把另一張表的欄位帶入，例如依 ProductID 加上商品類別。後者若沒有先驗證鍵值唯一性，容易產生一對多展開，導致交易列數和金額被重複放大。任何資料合併完成後，至少應比較合併前後列數、唯一交易識別碼數與關鍵金額總計。

Power Query 也不是萬能的錯誤修復器。若原始資料的付款欄位被錯誤覆寫，即使轉換步驟全數成功，報表仍會依錯誤來源產生結果。資料品質應採分層處理：源頭改善輸入規則，Power Query 處理可重現的型別與欄位轉換，語意模型負責一致的分析計算，驗收程序則以獨立核對確認結果。把所有責任推給報表開發者，是企業無法長期維持信任的原因之一。

大資料量時，為什麼「Query Folding」重要？

當資料來源是支援查詢的資料庫，Power Query 可能將部分轉換下推給來源執行，這稱為 Query Folding。它使資料庫先過濾或彙整需要的資料，再交回 Power Query，通常比把整張表搬回本機再處理更有效率。Microsoft 也提醒，是否支援取決於連接器、來源與轉換步驟；Excel 和 CSV 這類來源通常沒有可供下推的查詢引擎。因此不能把「某一步驟看起來很簡單」等同於「一定有下推」。[S04]

實務上，若連接 SQL Server 等來源，可以先篩選無關資料、移除不需要的欄位，再檢查 Query Folding 與重新整理效能。若資料源只是幾個部門的 Excel，優先工作則是規範檔案結構與資料更新位置，不必為了追求不存在的 Folding 而增加架構複雜度。當資料量大到 Power Query 本身已難以維持，Microsoft 的資料建模指引也建議考慮在上游資料倉儲和 ETL 流程先完成重工作，而不是把每件事塞進單一 Power BI 模型。[S05]

常見的五種清理錯誤

第一，日期混有不同文化格式，像 03/04/2026 究竟是三月四日還是四月三日，不能只靠自動推斷。第二，文字形式的商品編號被轉成數字，與主檔關聯失敗。第三，直接刪除空白交易，卻未區分無效記錄與尚未完成的業務狀態。第四，將退款當負值與一般銷售相加，但沒有說明退款日期應按原交易日還是退款日認列。第五，將多個來源直接合併，沒有驗證交易識別碼的唯一性。五種錯誤都可能讓圖表看起來正常，只有業務驗收時才暴露。

一個成熟的清理流程，最後應產生的不只是一張乾淨資料表，還應包括欄位對照、轉換步驟、異常數量、例外處理方式與來源版本。這些成果在資料量不大時也值得保留，因為它們決定報表能否交接。下個月同仁離職時，企業是否能正常重新整理，正是判斷這套系統是否真正完成的標準。

四、資料模型：從會算數字，走向每個部門都算出同一個數字

當資料完成初步清理，下一個決定 Power BI 品質的工作是建模。許多人以為「把所有來源合成一大張表」最簡單，因為拉圖表時不用想關聯。但當同一商品名稱在每一筆交易反覆出現，商品主檔一旦更名，資料一致性、查詢效率和歷史紀錄都可能變得難以維護。相反地，如果每一張表都按其業務角色設計，模型就能用更少的重複資料回答更多問題。

Microsoft 建議 Power BI 語意模型參考 星狀結構（Star Schema）：事實表（Fact Table）記錄發生過的業務事件或可彙總數值；維度表（Dimension Table）提供商品、客戶、地點、日期等描述資訊。維度表通常用來篩選和分組，事實表則提供可被彙總的交易明細。它的價值不在造型，而是讓「用哪個欄位切分、加總哪個數字」變得清楚。[S05]

假設一份訂單資料每列代表一個品項交易，可以把它整理成 Sales 事實表，包含訂單編號、日期、商品鍵、區域鍵、銷售數量、單價、折扣及狀態。另有 Products 維度表，包含不重複的商品鍵、商品名稱、類別與單位成本；Regions 維度表包含區域鍵與名稱；Date 日期表則提供完整連續的日期欄位。建立關聯後，使用者選擇「北區」，模型會透過區域與交易間的關聯，讓多個圖表回應相同篩選條件。

要特別注意，這個範例的每一筆 Sales 是訂單的一個品項列。若企業實際來源一張訂單包含多個品項，就不該假設每張訂單只有一列。訂單數應用唯一訂單識別碼計算，而不是加總列數。更複雜的情況包括同一商品具有不同歷史成本、同一客戶跨區移轉，以及退貨需要回扣原始銷售。這些不是增加一個 DAX 函數就能解決，必須先定義歷史資料應保留「當時的屬性」還是依「目前的主檔」重新分類。

一對多關聯，並非只是介面上的一條線

在典型星狀模型裡，維度表的鍵值必須能唯一識別一筆維度資料，事實表則可以重複使用該鍵。例如 Products[ProductID] 一個商品一列，Sales[ProductID] 同一商品可以出現在很多交易。這通常是從維度端的一，連到事實端的多。如果主檔同一商品出現兩行，你就不能合理地期待系統知道要選哪一個類別或成本。

在 Power BI 建模畫面，請逐一檢查關聯的基數、交叉篩選方向與啟用狀態。初學時優先維持容易解釋的單向維度到事實過濾，只有當業務規則真的需要，才考慮雙向過濾。因為過多的雙向與多對多關聯會讓過濾路徑更難推論，也增加「改了一張圖，另一張圖出現意外結果」的風險。這是模型可預測性的問題，不只是效能問題。

建立模型時，可以把直接供報表選取的欄位整理為清楚的商業名稱。例如把 DiscountRate 顯示為「折扣率」，但仍在資料字典保留原始欄位名稱，讓業務和工程人員能互相核對。索引鍵等欄位則可適度隱藏，以免一般報表使用者誤把商品代碼加總。隱藏欄位只是整理使用介面，不代表資料保密。真正在乎存取控制時，必須另外規劃模型與服務的權限。[S05][S09]

日期表不是多一個欄位，而是共同的時間座標

主管常問本月與去年同月差多少、年初累積到現在的成長如何、這一季是否偏離預算。如果每個來源只有自己的日期文字，而且有些月份沒有任何交易，這類比較很容易出現不一致。建立日期維度可以讓不同指標使用共同時間軸，並明確控制年、季、月的分析範圍。Microsoft 文件說明了自訂日期表的條件；若採用傳統時間智慧（Classic time intelligence）函數，通常應正確標記日期表，其日期欄需符合唯一、非空且連續等條件。新版 Calendar-based time intelligence 有不同設定方式，因此不要把某個舊版操作畫面當成所有版本的唯一作法。[S08]

若分析對象涉及台灣財務管理，還要注意曆年與會計年度不一定相同。企業有些管理報表按自然月，有些按結帳日或零售週次。日期維度可以提供財務年度、財務月份、週次、工作日等屬性，但這些欄位的規則必須來自企業實際制度，不能僅憑通用的 MONTH() 或 YEAR() 函數猜測。

何時不該把一切做進 Power BI？

Power BI 擅長分析與展示，但並非所有企業資料轉換都適合放在單一報表檔案中。若資料來自數百萬筆以上的原始事件、需要保留嚴格的歷史主檔版本、跨系統交易清洗牽涉大量複雜邏輯，先在上游資料庫、資料倉儲或 Fabric 的適當工作負載準備資料，往往更可管理。這也符合 Microsoft 對大型模型的建議：當 Power Query 很難處理進階建模要求時，應評估先使用資料倉儲與 ETL。[S05]

對小型團隊而言，這不表示第一天就要建立資料湖。相反地，從幾張可靠且責任清楚的表格起步，隨分析需求和資料規模擴張再拆分架構，通常比較容易驗收。評估的標準不應只有資料筆數，還要看更新頻率、來源變動率、資料品質、使用者人數與誰有能力維護。

練習範例說明：本文 DAX 使用合成資料，已核對獨立算術與公式邏輯，尚未在 Power BI 引擎執行。請依資料字典建立模型，並用下載包中的預期結果核對；正式採用前需於自己的 Power BI 環境驗證。

五、DAX 實作：讓「營收、訂單數、毛利率」真正具備分析意義

資料模型建立之後，許多人遇到第二個門檻：明明 Excel 公式很熟悉，到了 Power BI 卻不理解為什麼加總出現變化。關鍵是 DAX 不只在計算數值，也在處理篩選脈絡。當使用者按下某個區域、選擇某個月份或點擊圖表中的一個商品，度量值會在當時的篩選條件下重新求值。[S10][S11]

這種設計非常適合管理分析，因為同一個「毛利率」度量值可以在整體公司、北區、某個產品類別或單一月份下被重複使用。不過，這也意味著對分子、分母與篩選條件沒有理解的報表，會在看似合理的畫面中傳播錯誤。例如「各商品毛利率的簡單平均」通常不等於「公司整體毛利率」；公司毛利率應把所有相關交易毛利加總，再除以相同範圍的銷售淨額。

DAX、計算資料行與 Power Query 的分工

遇到一個新計算時，先問它屬於哪一種需求。若要將來源字串切分、修正型別或合併欄位，這通常是 Power Query 的工作。若要替每個交易建立穩定的分類、且該值不需隨切片器改變，可以視模型情況評估計算資料行。若要計算會隨月份、區域、商品條件變動的 KPI，則優先考慮 DAX 度量值（Measure）。

舉例來說，「商品類別」應由商品維度提供，而不是每個圖表重寫條件判斷。「本月已完成訂單銷售額」則是一個依時間及狀態篩選後的加總，適合用 Measure。不要因為 Power BI 支援複雜 DAX，就把所有可在來源處理的清理工作搬進 DAX；不同層級的邏輯混在一起，長期很難維護。

實際練習：從三張 CSV 建立可重現的零售模型

下載 Power BI 練習資料（CSV／資料字典／驗算結果）。資料皆為虛構教學範例，請先下載再依本文步驟操作。

下載的練習 ZIP 解壓後提供 Sales.csv、Products.csv、Regions.csv 與 data_dictionary.md。它們由教學程式生成，所有訂單和金額均為合成資料，不代表真實零售市場，也不適合用來預測營業額。這份資料包含 2025 年與 2026 年 1 月到 9 月的模擬交易，刻意保留一部分已取消訂單，方便驗證計算時的排除規則。三張表有明確鍵值，能用來練習合併、星狀關聯、日期維度與 DAX。

操作時，先在 Windows 版 Power BI Desktop 選擇「取得資料」，匯入三張 CSV。在 Power Query 確認 Sales[OrderDate] 是 Date 型別，Quantity 是整數，UnitPrice 與 DiscountRate 是數值；Products[UnitCost] 也是數值。不要把 ProductID 和 RegionID 不小心變成不同型別。完成載入後，在模型檢視中確認 Products[ProductID] 到 Sales[ProductID]、Regions[RegionID] 到 Sales[RegionID] 的關聯均為適當的一對多。

在建模中新增以下日期表作為此範例的共同時間座標：

Date = CALENDAR(DATE(2025, 1, 1), DATE(2026, 12, 31))

它會產生連續的日期，不只是原始訂單曾經出現過的日子。接著建立 Date[Date] 與 Sales[OrderDate] 的關聯。若使用本文示範的傳統時間智慧函數，請依目前使用版本的 Microsoft 官方操作指引將 Date 標記為日期表，並確認相關欄位是 Date 型別。此處示範的模型會以 Date 表的日期來篩選交易，而不是拿視覺物件自動建立的日期階層與原始訂單日期混合使用。[S08]

下面是第一個度量值，已完成訂單的銷售淨額：

銷售淨額 =
SUMX(
    FILTER(Sales, Sales[OrderStatus] = "Completed"),
    Sales[Quantity] * Sales[UnitPrice] * (1 - Sales[DiscountRate])
)

FILTER 先依目前查詢與報表篩選條件，保留狀態為 Completed 的交易；SUMX 則對這些交易逐筆計算折扣後銷售額並加總。與 SUM(Sales[UnitPrice]) 相比，這個公式才符合本文的交易定義，因為它考慮了數量、折扣和取消狀態。範例沒有另外記錄退貨、運費、稅額或信用卡手續費，因此不應把「銷售淨額」宣稱為會計報表認列後的營業收入。

下一個度量值是產品成本。本範例在 Products 主檔保存固定單位成本，並已建立正確的一對多關聯，因此可以在迭代交易時用 RELATED 取得對應商品成本：

產品成本 =
SUMX(
    FILTER(Sales, Sales[OrderStatus] = "Completed"),
    Sales[Quantity] * RELATED(Products[UnitCost])
)

毛利 = [銷售淨額] - [產品成本]

毛利率 = DIVIDE([毛利], [銷售淨額])

DIVIDE 比直接使用除法運算子更適合分母可能為零的指標情境；未指定替代結果時，除數為零會傳回空白值。這能避免在沒有銷售的區域產生誤導性百分比。展示時請將毛利率度量值格式設定為百分比；不要自行把結果乘以一百又設定百分比，造成數字放大。[S12]

這裡有一個重要的商業限制。若商品成本隨時間變動，把最新單位成本放在 Products 主檔中，可能改變過去所有月份的毛利。本文範例為降低初學門檻，刻意採用固定教學成本；真實導入應依會計管理需求，將交易當時成本或有效期間成本規則放到適當表格，不可把這個示範公式直接視為正式財務毛利計算。更不用說採購成本、物流成本、退款認列、存貨評價與營業成本口徑還可能存在差異。這些問題必須由財務或業務資料負責人共同簽認。

計算完成訂單數可以這樣寫：

完成訂單數 =
CALCULATE(
    DISTINCTCOUNT(Sales[OrderID]),
    KEEPFILTERS(Sales[OrderStatus] = "Completed")
)

平均訂單金額 = DIVIDE([銷售淨額], [完成訂單數])

DISTINCTCOUNT 依不同訂單編號計數，避免一張訂單有多列時錯把列數當訂單數。CALCULATE 的核心是改變度量值求值時的篩選脈絡，這也是 DAX 能支援跨維度分析的重要原因。若未來要把「完成訂單」的判斷改成包含特定付款狀態，應回到指標契約修改一致定義，而不是每張報表各寫不同版本。[S11]

這裡特別使用 KEEPFILTERS，讓「完成訂單數」與前述使用 FILTER(Sales, ...) 的銷售淨額，遵守相同的既有篩選脈絡。原先直接把 Sales[OrderStatus] = "Completed" 當作 CALCULATE 的篩選參數，可能覆寫報表切片器已設定的同欄位條件；例如只選取 Canceled 時，訂單數可能仍計入 Completed，但銷售淨額卻不會。加入 KEEPFILTERS 可避免兩者在這個邊界情境的口徑不一致。若企業希望指標完全忽略「訂單狀態」篩選器，則應讓所有相關度量值採用同一個明確的忽略篩選規則，不應只修改其中一個。[S24]

再往前一步：去年同期、年增率與「沒有可比資料」

管理者常希望看年增率，但真正重要的是比較的期間必須一致。若今年只有 1 月至 9 月資料，卻把今年 9 個月與去年整年比較，所得到的百分比沒有相同期間基礎。以下是基於本文示範日期表的傳統 DAX 時間比較方式：

去年同期銷售額 =
CALCULATE(
    [銷售淨額],
    SAMEPERIODLASTYEAR('Date'[Date])
)

同期年增率 =
DIVIDE(
    [銷售淨額] - [去年同期銷售額],
    [去年同期銷售額]
)

把月份或特定區間放入篩選器後，度量值會將目前日期脈絡往前移一年，再依相同邏輯計算銷售。請確認日期表及關聯正確，而且去年確實有相應完整資料。沒有去年資料時，空白不是成長率為零。同樣地，跨年累積分析需要考慮資料是否已更新到相同的截止日；在報表上標示「截至日期」會比直接放一個綠色百分比更有責任感。

檢驗自己的 DAX：先算一個小範圍，再看整體

不要只看 DAX 沒有報錯，就認為數字正確。最有效的自我檢查方式，是先選一張你可以用計算機核對的交易，例如一筆數量 2、單價 1,000、折扣 10％、單位成本 600 的已完成訂單。依本文定義，銷售淨額應為 1,800，產品成本 1,200，毛利 600，毛利率約 33.33％。這只是算術示例，不代表任何實際商品利潤。

完成單筆檢查後，才依商品、月份、區域逐層核對總額與交易筆數，確認篩選結果符合預期。尤其要測試四種特殊情境：沒有交易的月份、全部取消的區域、同一訂單包含多個品項，以及商品主檔缺漏。這四個情境比只看「總銷售額長得像合理數字」更能發現模型設計缺陷。

六、Power BI 報表設計：讓主管看得懂，才能讓數據產生行動

很多 BI 專案花大量時間研究圖表外觀，卻沒有回答一個基本問題：讀者在看完這張圖後應該做什麼。資料視覺化不是把資訊變漂亮，而是降低找出差異、辨認異常與確認下一步的成本。一張圖可能適合探索，卻不適合決策。營運團隊真正需要的，通常是從整體狀況出發，逐步找到問題發生在哪個時間、區域、商品與流程。

想像每週營運會議的第一頁只放五個元素。頂端是「已完成訂單銷售淨額」、「毛利」、「毛利率」三個關鍵指標；中間以月份顯示銷售趨勢，並標記目標線是否達成；下方顯示區域的毛利貢獻與需關注的商品。這樣的布局，讓主管先回答「有沒有偏離」，再回答「偏離在哪裡」。若需要進一步確認，點選區域或商品後進入明細頁，而不是把全部資料一次堆滿。

Microsoft 的 Power BI 報表支援切片器、交叉篩選與多頁探索，但這些功能應服務於讀者任務。建立第一頁時，可以要求每張圖都通過三個檢查：它回答哪個具體問題？目前的時間與篩選範圍是否清楚？看到異常之後，使用者能採取什麼行動？如果第三個問題沒有答案，這張圖可能只是一個漂亮的統計摘要。[S07]

選圖表之前，先辨認問題類型

如果要看時間趨勢，折線圖通常能呈現方向與轉折；若要看少數類別間的差異，長條圖通常比一系列餅圖更容易比較；若要比較實際與目標，可以用明確的差距值或目標標記；若要追查金額差異，瀑布圖可能有助於說明各因素貢獻，但必須先確保因素可被合理分解。當需要核對交易時，詳細表格仍不可取代。這些是基於認知任務的編輯建議，不代表某種圖型在所有情境都優越。

必須避免一種常見的呈現陷阱：當分類數量太多，圓餅圖看似色彩豐富，實際上很難比較相鄰占比。另一種陷阱是把兩個量級不同的數字放在同一張圖上，沒有明確標示座標與單位。若使用雙軸，更應說明不同尺度的關係，不然視覺上會暗示不存在的同步變動。

一頁報表的資訊層級，應和主管的思考順序一致

首頁以摘要為主，第二頁再做分群比較，第三頁保留交易驗證。這並不是要求每個專案固定做三頁，而是把「發現問題」、「解釋原因」和「追查證據」分層。若每次主管只想確認某個固定 KPI，摘要頁可以極簡；若分析師需要自主探索，則可增加切片器和鑽研功能。重要的是知道誰在使用，不要期待一個畫面同時滿足所有角色。

每個頁面建議標示資料截至日期、適用範圍與幣別。與其在角落寫一行模糊的「最後更新」，不如區分「交易資料截至日期」與「模型重新整理時間」。兩者可能不同：來源系統昨晚才完成日結，但 Power BI 今天早上已成功重新整理；系統更新時間很新，不代表交易一定完整。這個差別對財務、物流與訂單管理特別重要。

色彩不應代替文字傳達關鍵訊息

許多管理報表採紅色代表不佳、綠色代表良好，但對部分色覺障礙使用者，這些色彩未必容易區分。Microsoft 的無障礙設計指引強調對比度、替代文字、明確標題、鍵盤操作與合理的 Tab 順序。實際設計時，除了顏色，應搭配「高於目標」、「低於目標」、「較上期增加」等可讀文字，並避免把重要資訊只放在滑鼠移入才出現的提示框裡。[S16]

一個容易落地的原則是：每張圖只有一個主訊息，次要元素退到背景。當所有卡片都使用最大字級、所有圖線都高彩度、每個區塊都加上陰影，反而沒有真正的視覺焦點。這也解釋為什麼商業報表未必需要誇張動畫；主管需要的是可信賴的比較，而不是參觀數位展演。

如何驗收報表是否真的可用？

請找一位沒有參與製作的部門主管，給他一個具體任務：「找出上個月銷售額下降最多的區域，再查出該區域的前五個商品。」不要在旁邊指示按哪裡；觀察他能否在合理時間內找到答案，是否看懂日期與幣別，以及是否誤把百分比變化當成金額變化。另一位使用者可以測試手機瀏覽、鍵盤操作或放大字級。這比只讓製作者對照設計稿檢查排版更能發現問題。

若報表打開速度很慢，先別急著升級電腦或購買更大容量。Microsoft 提供 Performance Analyzer，可檢查每個視覺物件的載入時間與 DAX 查詢耗時。先找出慢的圖，再判斷是資料模型、DAX、視覺物件數量還是來源查詢造成瓶頸。對 DirectQuery 模型而言，來源系統與連線狀況也會直接影響使用體驗。[S17]

七、Power BI Service：報表做出來之後，如何安全分享和更新？

個人分析與企業協作的最大分界，往往發生在按下「發佈」之後。Power BI Desktop 可以在本機免費建立報表，但當報表要分享給其他同事、建立共用工作區、讓他人持續查閱時，就必須檢查 Power BI 服務的授權與容量條件。這是導入預算經常被低估的地方，也是本文將平台選型與授權分開說明的原因。[S06][S13]

在 Power BI 服務中，工作區（Workspace）可以視為內容協作與管理的主要容器。報表製作者會將語意模型和報表發佈到合適工作區，資料管理者設定認證與重新整理，管理員控管可分享的方式，最後由需要閱讀的人取得存取權。對大量相對穩定的讀者，可以考慮透過 Power BI App 發送經整理的內容，而不是把所有人加入可編輯的工作區。[S06]

分享連結，不等於公開網頁

Power BI 支援依權限分享給具名使用者，也能整合 Teams 等企業協作場景。分享時需要確認：使用者是否具有所需授權？所在工作區和語意模型是否位於合適的容量？使用者取得的是唯讀、建置還是編輯權限？若資料包含客戶、薪資、價格或其他敏感資訊，更不能只看圖表上的內容有沒有被隱藏。Microsoft 明確提醒，單純隱藏欄位、表格或報表頁面不是安全措施；需要時應使用適當的存取權及模型層安全性。[S06]

最需要注意的是 Publish to web（發佈至網頁）。它提供公開嵌入網址，方便在外部網站展示互動報表，但 Microsoft 明確警告，任何網路使用者都可能在無需驗證的情況下存取已發佈內容，甚至可能取得報表未直接呈現的模型細節。這種功能只適合經確認可公開的資料，絕對不能當成企業內部安全分享的替代方案。將含有員工薪資、客戶資料或營運機密的報表設定為 Publish to web，可能造成嚴重資訊外洩。[S14]

RLS：同一份報表，不同主管看到不同資料

假設北區與南區主管使用同一個報表，但各自只能看見所屬區域交易。如果為每個主管維護獨立的報表檔，數量一多就容易版本分歧。Power BI 的 資料列層級安全性（Row-level security，RLS） 可以在語意模型中定義角色與篩選規則，依使用者身分限制可讀的資料列。這需要在模型中定義規則、發佈後配置角色成員，再以測試功能驗證。[S09]

有一個常被忽略的細節：Microsoft 文件指出，RLS 對工作區的 Viewer 角色有效，並不適用於具有 Admin、Member 或 Contributor 等編輯權限的使用者。換句話說，若企業為了「方便閱讀」而把區域主管都加入可編輯角色，即使模型設了 RLS，也可能沒有達到預期的限制。權限驗收應使用真實角色測試，並檢查相關語意模型是否另有授權路徑，而非只用開發者帳號查看。[S09]

排程重新整理，為什麼還需要資料閘道？

Power BI 服務能排程重新整理，但雲端報表不會憑空讀到藏在公司內網電腦或資料庫裡的內容。若資料來源無法由雲端直接存取，通常需要本機資料閘道（On-premises data gateway）作為橋接。Microsoft 將標準模式、個人模式以及虛擬網路閘道列為不同使用情境；企業多人共享資料來源時，一般應優先評估集中管理與可維運的方案。[S15]

這裡的關鍵不是安裝成功，而是之後能不能持續成功。公司電腦關機、資料庫密碼更換、閘道未更新或來源路徑變動，都可能讓排程失敗。正式營運要為資料閘道設定明確的管理人、備援與異常通知。若某張主管報表今早其實沒有成功更新，頁面不能因為仍顯示漂亮圖表就假裝資料是最新的。

依 Microsoft 官方重新整理文件，Power BI Pro 的排程重新整理上限為每日最多 8 次；PPU 與適用的 Premium／Fabric 容量情境可達每日最多 48 次。這些是排程次數的產品條件，不代表每個資料來源都支援相同頻率、也不保證每次都能準時完成。若經營需求是分鐘級監控，應重新評估資料連接方式、來源負載、容量和自動頁面更新規則，而不是把每小時一次的快照稱為真正即時。[S18]

Import、DirectQuery 與更進階的資料架構

Power BI 一般使用者最常遇到的兩種資料連線方式是 Import 與 DirectQuery。Import 將資料複製進模型，視覺互動通常以匯入資料進行，資料來源異動後要重新整理才能反映。DirectQuery 在互動時對來源發送查詢，不必先把資料全部匯入模型，但效能與可用功能也會受到來源及查詢設計影響。Microsoft 官方特別提醒，DirectQuery 並非所有連接器都支援，且有相應限制。[S19]

兩者不是單純的「快與慢」比較。小型零售團隊每日更新一次，Import 可能已足夠；某個需要高頻資料的作業控制中心，才值得深入評估 DirectQuery 或其他 Fabric 架構。Microsoft Fabric 另有 Direct Lake 等情境，但不應在第一次導入時把各種名詞一起堆到提案裡。正確做法是用資料量、延遲容忍度、治理需求與預算，逐步決定架構。[S01][S19]

八、Power BI 費用怎麼算？從讀者與權限回推，不要只看製作帳號

授權問題是「Power BI 免費嗎？」這個搜尋問題最容易得到不完整回答的地方。Power BI Desktop 是免費 Windows 應用程式，但企業內部分享與協作有不同授權條件。以 Microsoft 台灣官方定價頁於 2026 年 10 月 21 日可檢視的標示為準，Power BI Pro 為 NT$450／使用者／月，Premium Per User（PPU）為 NT$770／使用者／月，兩者均以年付方式呈現，且未含營業稅。官方亦列出 Embedded 與 Fabric 容量等依方案計價的選項；價格、稅額、合約、既有企業授權和地區條件都應在正式採購時重新核對。[S13]

Microsoft 的授權文件指出，若內容和其語意模型位於 F64 或更高的適用 Fabric 容量，符合條件的免費使用者可以用 Viewer 角色消費 Power BI 內容；低於 F64 的 F SKU 一般不能僅憑免費授權完成這種觀看情境。作者與具有其他工作區角色的人仍須依具體權限和工作負載確認授權。這項門檻常與 Copilot 所需容量被混淆，兩者不可互相替代。[S20][S06]

對第一次導入的中小企業，不需要立刻推算哪個 SKU 理論上最便宜。先盤點「會製作與維護的人」、「只閱讀的人」、「需要臨時共用的人」和「外部合作對象」，再列出實際使用的工作區與存取路徑。其次核對公司是否已持有包含 Pro 權益的適用 Microsoft 365／Office 365 E5 授權，避免重複購買。最後再決定採個別使用者授權還是容量方案，並把管理維護、資料閘道、資料倉儲和訓練成本一起放入預算。僅比較每月授權費，無法反映全部導入成本。[S13][S20]

一個示意的授權決策，不是假想的最低報價

假設一家企業有少數報表製作者與數十位每週閱讀主管。若沒有合適的 Premium／F64 以上容量，而且所有人都需要透過 Power BI 服務閱讀分享內容，就應逐一評估每位使用者是否需 Pro 或 PPU。若企業已採 E5，先確認權益與帳號指派；若希望大量讀者僅使用免費 Viewer，則應評估對應容量的總持有成本及其他必要條件。此處不以自行估算的「損益兩平使用者數」下結論，因為 Fabric 容量價格、使用量、工作負載與授權條件會隨方案改變。

還需要提醒主管，帳號授權只是使用權利，不等於資料安全制度。若報表顯示的人事資料與合約價格具有保密需求，即使是公司付費帳號，也必須設定適當的工作區權限、必要的 RLS／OLS 與資料存取政策。授權買對了，不代表敏感資料就自動被正確保護。

Power BI Copilot 會把所有 DAX 都寫好嗎？

Microsoft 已將 Copilot 功能整合至部分 Power BI 體驗，可協助自然語言探索、報表建立及 DAX 產生等任務。但官方文件明確指出，Power BI Pro 或 PPU 單獨持有並不足以啟用 Copilot；還需要符合條件的付費 Fabric 容量（文件列為 F2 以上）或 Premium 容量，以及租用戶設定和支援地區等條件。部分 Copilot 體驗可能仍處於預覽階段，功能可用性也會依環境不同。[S21]

因此，「買了 Power BI Pro 就有 AI 助理」不是可靠的採購承諾。更重要的是，即使 Copilot 能協助產生 DAX，也無法替公司定義客戶的營收認列、退貨條件、敏感資料分類與管理責任。先有可靠模型與資料語意，AI 產生的摘要才有被驗證的基礎。對企業來說，這也是避免讓生成式 AI 擴大錯誤資料的治理原則。

九、跟著做一次：30 分鐘原型不是終點，而是驗證資料與畫面的起點

前面已說明模型與計算概念，接下來把它轉成一套可以在課堂、部門會議或自學中重現的任務。這一段的目的不是宣稱每個人都能在固定時間內熟練 Power BI，而是把第一版原型的範圍縮到可以測試的程度。若環境與檔案已準備好，可以先完成骨架，再逐項改善資料品質、報表設計與分享機制。進度快慢取決於個人的資料背景和實際設備。

步驟一：先做資料稽核，不做任何圖表

使用封包提供的 Sales.csv、Products.csv 和 Regions.csv 匯入 Power BI Desktop。開啟 Power Query 後，先檢查三張表的資料型別，確認日期沒有變成文字，折扣率介於零和一之間，已完成與取消狀態符合資料字典。再用商品鍵、區域鍵對照維度主檔，檢查是否存在沒有對應商品的交易。最後記錄原始交易列數與唯一訂單數，供後面核對。這一個步驟表面上沒有任何視覺成果，但其實已建立第一個品質基準。

不要為了「讓圖表快點出來」而直接刪除所有異常值。假設出現 ProductID 查不到商品名稱，它可能是合法新品尚未同步，也可能是手動輸入錯誤；兩者應採取的修正動作完全不同。最好先保存異常清單，與資料擁有者確認是否要修正來源。若未經確認就用「其他商品」取代，分析師可能無意間掩蓋真正需要管理的資料問題。

步驟二：設定關聯與最小指標集合

回到模型檢視建立商品、區域與日期關聯。核對商品與區域主檔鍵值唯一，再按照前述 DAX 建立銷售淨額、產品成本、毛利、毛利率、完成訂單數和平均訂單金額。將數值格式設定為新台幣、百分比或整數，並統一呈現小數位數。由於教學資料只使用新台幣，不需進行幣別轉換。正式企業資料若混合幣別，必須先完成匯率規則再彙總。

完成後先把六個指標放進一張表格，依年份、月份和區域切分。這張表是驗證表，不是最終管理儀表板。它能讓你快速發現例如北區 2026 年某個月份的毛利率異常、完成訂單數與預期差異，以及切換產品時度量值是否跟著正確調整。正式設計之前先保留這張驗證表，可以節省大量後續查錯時間。

步驟三：用一句管理問題建立第一頁

第一頁的標題不要只寫「Dashboard 1」，可以寫成「截至 2026 年 9 月的區域銷售與毛利概況」。頁首放三張卡片：銷售淨額、毛利和毛利率。中間放依月份排列的銷售趨勢，下方放區域貢獻長條圖，再加上商品類別切片器。這個版本刻意不追求大量圖型，因為第一個驗收目標只有兩個：能否識別差異，能否用一致的篩選脈絡深入追查。

設定互動後，用至少三個測試情境檢查。例如選擇北區時，所有相關 KPI 是否都只呈現北區？同時選擇一個商品類別時，毛利是否仍由相同的已完成訂單計算？取消所有切片器後，總額能否回到驗證表的整體數字？若圖表間互動不一致，先查視覺互動設定和模型關聯，而不是調整畫面顏色。

步驟四：建立「異常追查」第二頁

第二頁可以放排序後的商品銷售與毛利、完成訂單數、平均訂單金額以及交易明細。當主管在首頁點選某個區域，就能沿著相同的分析範圍，判斷是商品組合、折扣或交易數量造成差異。這裡的重點是讓每個數字都有回到明細的路徑，並非讓所有員工都能看見交易層級資料。正式企業使用時，頁面與資料存取仍需遵循角色權限。

追查時還要留意統計解釋。某商品本月毛利率極高，可能是因為只賣出一筆，並不代表值得全面提高採購量；某區域銷售突然下降，可能源於資料尚未匯入，而非市場需求下滑。因此，報表除了百分比，還應提供分母、樣本數、交易數或資料完整度。數據分析不是找出最驚人的數字，而是分辨值得行動的真訊號與資料造成的假訊號。

步驟五：做交叉驗證，再決定是否上傳服務

將第一頁與第二頁的加總結果，對照 expected_results.json 所列的示範資料核對值。這個檔案由同一批合成交易按照已完成訂單、折扣後銷售與固定產品成本規則獨立計算，方便確認常見 DAX 實作錯誤。若結果不同，先查型別、關聯與狀態，再查公式。尤其不要把驗證值直接填入度量值，因為那會讓報表失去真正的計算功能。

確認本機報表正確後，才是考慮發佈的時機。若只是個人練習，沒有必要為了展示成果就開通不需要的企業分享權限。若要提供給同事，先確認公司帳號、工作區、授權、資料敏感性與服務設定。這也是個人學習與正式導入的實際分界：前者要能算對，後者除了算對，還必須能安全、穩定、持續地被他人使用。

十、四種企業應用情境：不同管理目的，需要不同的 Power BI 設計

同樣是 Power BI，財務、業務、營運與人資的資訊需求不一樣。導入前如果不辨認決策場景，最後可能會有一套每個部門都能看到、但沒有任何部門真正依賴的共通報表。以下四個情境均為教學示例，用來說明需求如何轉成可交付的模型與報表，不代表已執行的客戶專案或可保證的成效。

情境一：財務與管理會計，最困難的是認列口徑

管理者希望每月第五個工作天就能查看各部門實績、預算差異與費用結構。乍看之下，只需匯入總帳、預算表和部門代碼即可作圖。但實際難題往往是「會計科目」與「經營管理分類」不一致，部分費用跨部門分攤，而預算可能按季編列、實績按月入帳。若直接依來源科目繪圖，數字看起來精準，卻無法回答管理會計真正關心的責任中心績效。

比較穩健的做法是由財務負責人先定義費用分類映射表、預算版本、分攤規則與關帳時間。Power BI 再以一致的維度連接實際與預算資料，設計「總體差異、部門差異、科目追查」三個層次。資料更新後，透過異常差距與明細溯源協助主管判斷是否超支。這種報表不能取代會計審核與制度，卻可以把差異發現和追查的流程變得更有系統。

另一個務必區分的地方是財務報表與管理報表。本文的銷售淨額示範按訂單日期計算，不能直接稱為符合會計認列規定的營業收入。若企業要在同一套 BI 中展示財務報表數字，必須由會計專業人員審定來源與認列規則，必要時接入已關帳的財務數據，而不是拿電商訂單完成金額替代。

情境二：業務與行銷，先分清名單、商機、訂單與實收

業務主管想要知道成交進度，行銷主管關心來源品質。資料可能來自官網表單、CRM、活動名單、電話記錄與訂單系統。困難不在於連接資料，而是同一位客戶會在不同系統出現多個識別碼；詢價、報價、簽約、付款又是不同階段。如果把「填表」當成「成交」，儀表板看起來會比真實業績樂觀很多。

比較好的方法是先定義業務漏斗與狀態轉移。譬如「有效詢問」需要符合特定聯繫資訊與需求條件，「合格商機」需經業務確認，「成交」則需符合公司採用的合約或訂單規則。再設計每個階段的數量、轉換比例、停留時間與下個負責人。Power BI 的價值不是只顯示轉換率，而是協助判斷哪一段流程最值得改善。若大量詢問停在報價後，應追查報價內容、追蹤時間與客戶適配性，而不是一律要求行銷增加更多流量。

這種情境還應避免將小樣本轉換率過度解釋。某個來源只有兩筆商機、成交一筆，轉換率是 50％，但不能直接宣稱它優於有數百筆商機的其他來源。正式報表需要同時揭露分母、期間、資料完整性與可能重複名單，才能支持預算配置。

情境三：零售與營運管理，從銷售額走向供需與毛利

連鎖門市可能每天都看銷售排行榜，但高銷售不一定帶來高毛利，缺貨也可能讓需求訊號被誤判。若資料來源包含 POS 交易、商品主檔、庫存與採購記錄，就可以把分析拆成銷售、獲利與供給三個面向。主管先看各區域銷售與毛利，再沿商品類別追查折扣變化，最後用庫存週轉與補貨資料確認是否需要行動。

這裡有一項模型設計上的挑戰：銷售交易通常是訂單明細粒度，庫存可能只有每日每品項庫存快照，採購又可能是採購單明細。若把三種不同粒度的表直接互相合併，庫存數量和銷售金額很容易被放大。應透過一致的日期、門市與商品維度，分別保留各自的事實表，在符合業務定義下建立度量值。並且確認同一商品的成本變化、折扣活動、退貨與缺貨判斷方法，不應只因圖表可以交叉篩選就認為商業邏輯正確。

這類導入的驗收方式不必先承諾「增加多少營收」。可以先要求每週例會能產出一份異常商品名單，記錄每項異常由誰追查、是否確認問題根源、採取什麼行動。Power BI 對管理的貢獻，只有在數字能夠進入工作流程時，才會轉化成可觀察的效益。

情境四：人資與培訓成效，先解決隱私與權限

HR 常想追蹤各單位受訓率、技能缺口與人才流動，但人事資料可能涉及薪資、績效、個人評價與其他敏感資訊。即使管理者對員工分析有合理業務需求，也不代表所有主管都應看到完整個人紀錄。導入之前應先盤點用途、必要欄位、資料保留及可存取對象，並配合公司政策與適用法規評估。

如果目的只是讓部門主管確認團隊參訓進度，第一版可能只需要部門層級的應完成課程數、已完成數與待追蹤人數，無需在全公司共享個人績效明細。模型可以依部門或角色限制可見範圍；當資料具有小群體再識別風險時，還需要另行評估彙總門檻和資料揭露方式。RLS 是模型中的一項控制工具，不能取代個資治理、契約義務或資料目的限制。[S09]

更重要的是，受訓率不等於能力提升。若要評估企業培訓成效，應另外定義實際工作成果，例如受訓前後完成固定報表任務所需的時間、資料錯誤率、主管是否開始使用新的決策流程等。沒有基準與追蹤方法，只看出席人數無法判斷培訓是否改善業務能力。

如何從四種情境選出第一個試點？

四種情境並不需要同時啟動。可依「決策頻率、資料可得性、可驗證程度、責任人是否明確、敏感性與技術風險」評估。最適合作為第一個 Power BI 試點的，不一定是影響金額最大的題目，而是可以在有限範圍內建立可信數字、讓特定主管反覆使用、並證明工作流程確有改善的題目。第一個試點的責任是建立可複製的方法，不是先做出覆蓋全公司的巨大畫面。

十一、企業導入 Power BI 的 30 天試點：不是每天交一張圖，而是每天降低一種不確定性

正式採購前最值得回答的問題不是「Power BI 好不好」，而是「我們能否用最小成本驗證某個決策流程被改善」。Microsoft 的 BI 實施規劃文件將策略規劃、戰術規劃、目標與衡量分開處理，並強調使用業務背景來定義資料需求。這對中小企業同樣有參考價值，只是規模應適度精簡：不需要先成立龐大專案辦公室，但必須有人負責商業指標、來源資料、報表交付及權限。[S22]

以下是一套可供企業調整的 30 天試點建議。它是方法論與進度範例，不代表任何組織能保證在 30 天完成全公司 Power BI 導入。其前提是已選定單一場景、資料來源可合法取得、關鍵人員能參與驗收，而且不需要先處理大型基礎架構遷移。

第 1 至 5 天：把管理困境改寫成可驗收的需求

先由需求發起人提出一個真實、頻繁、可採取行動的決策，例如「每週一能找出毛利變動最大的商品」。分析師訪談使用者，寫出指標清單、資料來源清單、資料敏感程度及需要做的決策。此階段不用急著討論圖表顏色，也不需要蒐集所有可能的資料欄位。真正的產出是一份只有數頁的《BI 決策任務書》，由業務負責人確認：這個報表完成後，誰會在什麼會議使用它，根據哪個結果採取什麼動作。

其中至少要有一個可被否證的假設。例如原本每週有三位同仁反覆手工整理報表，導入後希望相同資料更新不必每次重新複製貼上。此時可以測量手工作業時間與錯誤次數。若原本作業已相當簡單，Power BI 建置與維運成本可能超過節省時間；能夠得出「暫時不導入」也是成功的評估結果，而不是專案失敗。

第 6 至 10 天：確認資料責任、範圍與品質

清查來源資料，先確認有哪些系統、欄位、唯一鍵、更新方式與權限限制。將來源欄位映射到指標契約，找出缺少的欄位和不可比較的口徑。若財務把月份定義為關帳月份，業務把月份定義為下單月份，應決定是否需要兩種指標，而不是偷偷把其中一個覆蓋。資料擁有者應正式簽認來源範圍、例外處理與數據可用性。

此階段的產出包含《資料字典》、《指標契約》、《來源與責任清單》及《異常處理紀錄》。建議至少選取兩個歷史期間來核對，不要只用最新月份，因為跨月、取消、折讓與資料來源調整往往在歷史資料中才暴露。若來源本身不可靠，應啟動修復，而不是用報表掩飾缺陷。

第 11 至 17 天：建立最小資料模型與一份可操作的報表

分析師開始製作 Power Query、關聯和必要的 DAX 度量值；業務負責人提供可核對的參考數字。這時可以先完成一張功能樸素、但指標正確的驗證表，再製作能回答核心決策問題的首頁。IT 或資料管理者同時檢查預定資料位置、認證方式與權限架構。凡是涉及員工、客戶或商業機密的資料，必須在試點階段就進行必要的存取限制，而不是等正式上線才補救。

這個階段的產出不是「畫了幾張圖」，而是《資料模型》、《度量值清單》、《第一版報表》和《核對結果》。如果主管尚無法用現有畫面做出示範決策，應回到需求檢查，而不是盲目增加圖表。好的試點要願意刪掉不必要的東西，才能留下真正有用的核心。

第 18 至 24 天：用真實角色與真實流程做驗收

請未參與開發的人員操作報表，讓他們依自己的工作習慣找出一項異常、追到一筆交易並說明打算如何處理。記錄操作耗時、誤解發生的位置、找不到的資訊及是否需要重新詢問分析師。若主管希望增加指標，要先確認這個需求是否屬於試點核心，否則一個月的試點很容易變成無限期的需求清單。

同時測試重新整理失敗、來源欄位改名、商品資料缺漏以及授權不足等例外情境。真正可靠的系統不能只在資料完美、使用者有管理員權限、開發者坐在旁邊時才能運作。也應安排備援操作人員依文件重新整理一次資料，驗證是否存在單點人員依賴。

第 25 至 30 天：決定擴張、修正或暫停

試點結束時，不應只問「大家覺得好不好看」，而應回到第一天的決策任務：同一個問題現在能否更快回答？數字是否有一致定義？來源與責任是否清楚？是否能安全分享？更新失敗能否被發現和處理？是否需要額外的授權與基礎架構費用？若答案仍不完整，先修正再擴張。

最後形成《驗收報告》與《後續擴充路線》。通過的試點可以成為下一個部門的模型與治理範本；尚未解決的問題則應明確記錄。最需要避免的是把第一版報表強行宣稱已完成數據轉型。報表只是工具交付，管理方式改變才是導入成效。

建議的角色分工與驗收交付物

一個最低限度可交付的專案包，應同時保留三種資產。第一是可以使用的報表與模型；第二是可以重現的資料與計算文件；第三是可以維護的更新、權限與異常處理說明。若只有第一項，即使短期看起來漂亮，也可能在下一次組織調整或人員交接時失效。

十二、正式上線前的品質檢核：資料正確，不等於系統可用

報表品管應比「圖有沒有跑出來」更嚴格。本文建議以六個面向驗收：資料、指標、視覺、效能、權限與維運。每一項都需有證據，而非只用「完成」兩字。尤其在跨部門使用時，只要一項重大條件未通過，就應限制發佈範圍或退回修正。

資料檢核：能否回溯到來源？

選幾個有代表性的期間和業務單位，將來源交易明細、Power Query 結果和模型度量值逐層核對。針對取消、空值、負值、重複訂單與主檔缺漏建立例外測試。至少保留一份可以獨立重算的數字，不要把 Power BI 本身既當計算系統又當唯一驗證系統。當系統自己證明自己正確時，檢核的獨立性不足。

指標檢核：同一名稱是否只有一個受控定義？

檢查每個頁面是否都使用共用度量值，而不是同名但不同邏輯的計算欄位。若同時有「下單金額」和「入帳營收」，名稱要明確，來源與日期依據也要分開。對毛利率、成交率、平均單價等比率，應核對分子分母的過濾範圍是否一致。比率尤其容易發生「圖表看起來合理，但加總方式錯了」的問題。

視覺檢核：使用者是否讀得懂？

確認標題、單位、日期、幣別、負數與缺漏值有正確顯示。圖表若按降冪排序，要確認排序欄位是預期的度量值；若設定色彩條件，要確認正負方向與商業定義一致。若使用者無法區分資料未更新與數字真的為零，應調整文字與狀態說明。對敏感資訊，還需注意截圖或匯出行為與組織管理規定，不把「只在畫面顯示一個摘要」誤認為底層細節已經安全。

效能檢核：從使用者操作看瓶頸

用相同頁面、相同資料量和典型篩選行為比較載入時間。必要時使用 Performance Analyzer 檢視各視覺與 DAX 查詢的耗時，而不是靠感覺判斷。測試至少應涵蓋最常使用的入口頁、資料量最大的月份，以及多個篩選器同時使用的情境。若效能下降，先判斷模型是否過度複雜、是否載入不需要的欄位、是否出現昂貴的計算或來源查詢，再決定升級容量是否值得。[S17]

權限檢核：以角色而不是以開發者帳號測試

使用 Viewer、報表製作者以及必要的外部帳號情境分別測試。若有 RLS，確認區域主管看不到其他區域交易；確認具編輯權的人知道自己是否不受 RLS 限制。若使用者無法開啟報表，要辨別授權不足、工作區權限不足與底層語意模型存取不足，而不是為了排除錯誤就把所有人加為管理員。[S06][S09]

維運檢核：資料出問題時誰會收到通知？

至少記錄重新整理排程、來源帳號擁有者、閘道管理者、異常通知對象、備援操作步驟及停用權限程序。若資料來源密碼更新會導致連線失效，應能在正式例會之前知道並處理。若模型建立者離職，企業應具備必要的存取與移轉程序。沒有這些基本運作機制，專案只是一次性展示，而不是可靠的管理資訊服務。

一個實際可用的驗收表，應讓每項測試都有「測試情境、預期結果、實際結果、負責人、證據與處理狀態」。本篇封包提供 acceptance_checklist.md，可作為第一次試點的起始版本；企業應依資料敏感程度與正式需求加嚴。不要將示範資料的檢核通過誤當成真實系統的驗收通過。

十三、十個常見錯誤：學會 Power BI 之後，更要知道何時不該這樣做

錯誤一：把所有 Excel 欄位直接匯入。 資料越多不代表洞察越多。未使用欄位可能增加模型負擔，也可能把不應暴露的欄位帶入共享模型。應先根據需求盤點欄位，留下必要欄位與驗收所需識別資訊，再判斷是否需要進階資料倉儲。

錯誤二：把報表上的數字直接當作財務報表。 電商訂單金額、發票金額、實收金額及會計營收可能採不同日期與認列基準。報表可以並列這些指標，但必須命名與說明。財務管理需要的是可靠的差異解釋，而不是在多套系統中選一個看起來最好的數字。

錯誤三：不用關聯，全部依靠查詢合併。 每一次合併都可能產生重複列或主檔版本問題。若分析問題涵蓋時間、商品、地區等共同維度，應優先評估適當的事實與維度建模。需要真正展平的資料也可以展平，但應能說明為何這樣做及如何維護。[S05]

錯誤四：拿每個商品的毛利率做簡單平均。 公司整體毛利率應用整體毛利除以同範圍銷售額。若商品 A 銷售額非常大、商品 B 非常小，簡單平均兩者比率會過度放大小商品的影響。任何會進入管理報告的比率，都應先檢查其分子、分母與權重。

錯誤五：把隱藏欄位當成權限控管。 模型欄位即使沒有出現在報表頁面，也不等於其他有權限的人無法接觸。應用適當的工作區角色、模型安全性、匯出與分享政策。若資料不能讓某群人讀取，就不應只靠畫面隱藏來管理。[S06][S09]

錯誤六：看見「即時」兩字就選 DirectQuery。 DirectQuery 仍受來源效能、連線、快取與功能限制影響。使用者希望資料「夠新」不代表一定要每次查詢都打回正式交易系統。先確認業務能容忍的延遲，再衡量查詢負載與部署成本。[S19]

錯誤七：只測試自己是管理員時的畫面。 開發者看得到所有資料，不代表一般 Viewer 能看到該看的內容，也不代表不該看的資訊被適當限制。權限測試應用不同角色完成，尤其要驗證 RLS、工作區角色與底層模型權限。[S09]

錯誤八：以為排程成功就代表來源最新。 模型重新整理可能成功，但來源系統還沒完成當日資料同步。應分別標示模型更新時間與來源資料截止日，必要時加入資料完整度檢查與異常提示。對需要快速判斷的主管，資料品質訊號可能比多一張 KPI 卡片更重要。

錯誤九：用增加圖表數量回應所有需求。 使用者抱怨找不到答案時，原因可能是視覺層級與互動路徑設計不佳。先觀察使用者操作，刪掉重複圖表，讓每一頁的問題更明確。報表頁面越複雜，無障礙與效能問題也可能增加。[S16][S17]

錯誤十：沒有定義專案結束之後由誰維護。 專案如果只有原製作者懂得來源、轉換與 DAX，日後修改就會產生組織風險。最低限度要有資料字典、模型說明、指標契約、更新程序及實際負責人。最好的 Power BI 報表，不是只能由原作者操作，而是能夠交接後持續被信任。

如何衡量 Power BI 是否值得繼續投資？把成本與管理成果放在同一個觀察期

即使技術驗收通過，企業仍需要回答「這套報表值得長期維護嗎」。對多數小型試點而言，最容易衡量的不是營收成長，而是固定分析工作的時間、品質和使用情況。先找出原本每週要花多少時間做資料匯出、轉檔、合併和核對；再記錄引入新流程後仍需花多少時間維護來源、修改模型、處理更新失敗與回應主管問題。只計算節省下來的製表時間，卻忽略報表維運與權限管理，會高估投資效益。

資料品質可以用不同層次衡量。第一層是來源完整度，例如應收到的檔案與實際收到數量是否一致；第二層是計算核對差異，例如同一期間 Power BI 結果與業務系統在相同口徑下能否一致；第三層才是管理行動，例如主管從發現異常到指定負責人、完成追查所需時間。這些指標應在試點前先定義測量方法，否則完成後只選對自己有利的數據，很難知道是否真正進步。

還有一項不容易量化但必須考慮的價值是交接性。當關鍵同仁請假、職務調整或離職時，新接手者能不能根據文件完成資料更新？當新商品加入、來源欄位增加或管理維度調整，系統能否在可預測的工作量下改版？若答案是否定的，即使第一個月節省了時間，也可能只是把人工依賴轉換成另一種技術依賴。可複製的查核程序、清楚的責任分工與標準化語意模型，才是逐步降低這種風險的資產。

試點成果宜分成「已證實」、「初步觀察」和「尚待驗證」三類。已證實項目需要有前後一致的計算方法和可回溯紀錄；初步觀察可以保留主管回饋，但不要當成普遍績效結論；尚待驗證項目則列出下一次檢查時間與責任人。若資料更新還不穩定，寧可暫緩擴張，也不要為了證明專案成功而在不完整的基礎上增加更多部門。企業真正應採購的不是一次性的展示效果，而是能夠持續支援工作決策的能力。

最後還要辨別效率改善與決策品質改善。讓報表從三小時縮短至十分鐘，並不自動證明採購、訂價或人員配置的決定變得更好。若希望追蹤決策品質，可以在每次例會留下「使用哪個指標、提出什麼假設、交付哪位負責人、預計何時複查」的簡短紀錄。經過數個週期再回顧，哪些異常曾被提前發現，哪些判斷其實源於資料缺陷。這份行動紀錄能讓 Power BI 從觀看數據的工具，逐步成為管理學習與修正制度的一部分；它比一次性的滿意度問卷更能解釋系統是否值得保留。

十四、Power BI 常見問題 FAQ：從入門、費用到企業分享

Q1：Power BI 是什麼？一句話怎麼解釋？

Power BI 是 Microsoft 的商業分析平台，可把不同來源的資料整理成可互動的報表，並在適當授權與權限下分享給他人。它的用途不是只有繪圖，還包含資料前處理、語意模型與分析邏輯。對企業來說，真正的價值是讓大家在一致的數據口徑下比較績效並決定下一步。[S01]

Q2：Power BI Desktop 真的免費嗎？

Power BI Desktop 可以免費下載、建立模型與報表。不過，若需要在雲端工作區分享給同事，就必須依分享者、閱讀者、工作區容量與組織條件檢查授權。不要把 Desktop 免費與「全公司免費使用」畫上等號。[S02][S06]

Q3：沒有程式背景，能不能學 Power BI？

可以從匯入 Excel、整理欄位、建立基本圖表開始。不必先懂完整程式開發才能做出初步報表；但當需求涉及跨表關聯、精確的計算口徑與自動更新時，仍需要學習 Power Query、建模與一定程度的 DAX。真正的入門門檻往往是理解資料與業務規則，而不只是操作介面。

Q4：Excel 和 Power BI 最大差別是什麼？

Excel 比較適合彈性試算、人工資料檢查與一次性分析；Power BI 比較適合讓相同的資料模型持續支援跨部門的互動式報表與雲端協作。兩者可以並用。若來源只有一張小表，每月也不需要分享，未必有必要立即轉換。

Q5：Power Query 和 DAX 的差別是什麼？

Power Query 主要處理資料匯入與轉換，像是變更型別、清理欄位、合併來源與整理資料結構。DAX 常用於模型層的度量值與計算，會隨報表篩選脈絡改變。把固定資料清理與動態管理指標分開，可以提高模型的可理解性。[S03][S10]

Q6：DAX 很難嗎？第一個該學什麼？

先理解 SUM、SUMX、DISTINCTCOUNT、DIVIDE 與 CALCULATE 的用途，再學習度量值如何因月份、地區和商品篩選而變動。比背更多函數更重要的，是知道什麼資料被計入分子與分母。先完成一個能由來源交易核對的 KPI，再擴充複雜計算。[S10][S11][S12]

Q7：Power BI 可以自動更新 Excel 嗎？

如果資料位置、連線方式、認證與服務設定符合條件，可以讓已建立的 Power BI 模型依排程更新來源資料。但更新能否成功取決於來源位置及存取環境；位於公司內網且雲端無法直接連接的來源，可能需要資料閘道。也要留意是更新模型，而非自動修正原始 Excel 的錯誤。[S15][S18]

Q8：Power BI 能做即時報表嗎？

Power BI 有不同連接與更新方式，部分情境可以更接近即時分析，但不能將所有報表都視為零延遲。Import 模式會受模型重新整理影響；DirectQuery 在互動時查詢來源，但也存在效能、快取與功能限制。先定義業務能接受的資料延遲，再選擇適當架構。[S19]

Q9：買 Power BI Pro 後，同事也能免費看報表嗎？

不一定。一般共享容量情境下，接收共用報表的同事通常也需要符合規定的 Pro 或 PPU 授權。若內容和語意模型位於符合條件的 F64 以上 Fabric 容量，特定免費 Viewer 才可能觀看。需按實際工作區角色和授權條件確認。[S06][S20]

Q10：Premium Per User 和 Fabric 容量一樣嗎？

不一樣。PPU 讓單一使用者取得較多 Power BI 進階能力，卻不等於購買一份獨立的 Fabric F 容量。若企業需要 Lakehouse、Warehouse 或相關 Fabric 工作負載，應另外依官方容量與授權文件評估。[S20]

Q11：Power BI 中的 Copilot 需要另外付費嗎？

要依 Microsoft 最新服務條件評估。官方文件指出，一般 Pro 或 PPU 不足以單獨開通 Copilot；還需符合條件的付費容量、管理員設定及支援區域等要件。即使功能已開通，輸出的 DAX、摘要與報表仍需要使用者驗證業務定義。[S21]

Q12：Power BI 可以給不同主管看不同區域資料嗎？

可以評估使用 RLS。模型中的角色與篩選規則可限制特定使用者看到的資料列。不過，RLS 對工作區 Viewer 等角色的適用條件，與對具編輯權的成員不同；企業應用實際使用者角色測試，不應只以設計者帳號驗收。[S09]

Q13：可以把 Power BI 報表嵌到公司網站嗎？

存在不同的嵌入與分享方法，要先分清公開展示和需登入的內部內容。Microsoft 的 Publish to web 會讓內容在沒有使用者驗證的情況下向網際網路開放，因此只適合已確認可以公開的資料。內部機密或個資不應使用此方式展示。[S14]

Q14：Power BI 報表很慢，應該先升級方案嗎？

不一定。先檢查模型是否載入不必要欄位、關聯設計是否合理、DAX 是否過度昂貴、單頁視覺物件是否太多，以及 DirectQuery 來源是否有瓶頸。可以利用 Microsoft 的 Performance Analyzer 分析圖表與查詢耗時，再判斷是否需要容量升級。[S17]

Q15：中小企業開始導入 Power BI，第一步做什麼？

選定一個固定的管理決策，列出要回答的問題、負責使用的主管、每週或每月會採取的行動。接著制定三到五個核心指標契約，盤點資料來源和品質，再完成一份可以回到交易明細核對的原型報表。不要從「一次連接全公司所有系統」開始。

Q16：企業需要找外部顧問或安排教育訓練嗎？

依團隊資料基礎與導入風險而定。若只有少量報表、來源單純且已有資料分析能力，可以先讓內部人員自學和試作；若涉及跨部門指標定義、權限、財務口徑、資料閘道或長期維運，應評估更完整的導入支援。教育訓練的驗收不應只有出席人數，而是學員能否獨立清理資料、建立可信度量值與完成符合管理需求的報表。

十五、最後該帶走的不是一張漂亮報表，而是一套可被信任的決策流程

如果把 Power BI 視為美化 Excel 的工具，導入很容易停在「報表終於上線」的那一天。真正值得投資的，不是圖表本身，而是能否在下個月資料更新後，繼續用同一套數據定義討論問題；主管能否不靠原製作者，就看懂偏離目標的原因；當資料來源出錯或人員更替時，這套流程能否被清楚地修復與交接。

這篇指南採取一條從決策回推工具的路線。先確認業務問題與指標契約，接著用 Power Query 整理來源，以星狀模型建立可理解的關聯，再透過 DAX 讓數字在不同篩選脈絡下保持正確，最後用報表、服務、授權與權限把分析交給真正需要的人。若企業無法完成其中任何一個環節，就不應因為最後畫面漂亮而宣稱轉型成功。

對希望親手練習的讀者，建議先下載本文的合成資料練習，完成一頁銷售與毛利報表，親自驗證幾個計算結果。對考慮導入的企業，建議先安排小規模試點，讓財務、業務、資訊與管理層共同確認一份可以重複使用的指標契約。無論接下來選擇 Power BI、Excel 或其他分析平台，這份契約都會是值得保留的組織資產。

延伸學習與企業培訓

若已理解本文概念，想進一步演練 Power BI Desktop、Power Query、DAX 與資料視覺化，可參考天地人學堂目前提供的 Power BI Desktop 資料視覺化暨商務數據分析實戰班。課程內容、價格、觀看方式與開放狀態請以產品頁實際顯示為準；本文不把舊檔期或歷史價格當成目前保證。[S23]

對企業內部團隊而言，較有價值的下一步不一定是立即採購課程，而是先帶著自己的「指標契約、資料字典、現有報表與想改善的決策情境」討論內部能力缺口。若缺的是資料清理能力，就先安排 Power Query 實作；若缺的是一致計算，就強化模型與 DAX；若缺的是管理流程，則應把主管需求訪談、權限和維運列入培訓與導入規劃。課程只是能力建設的一部分，必須回到實際成果驗收。

原始研究來源與查核入口

以下優先列出 Microsoft 的英文原始文件；凡屬授權、容量、Copilot 或產品功能的時效性內容，應以閱讀當日的官方頁面為準。來源編號對應下列官方文件，供讀者逐項回查。網站自行編寫的做法、教學示例與導入建議，已在文中標明性質，不冒充官方政策。

[S01] Microsoft Learn，What is Power BI?

[S02] Microsoft Learn，Get started with Power BI Desktop

[S03] Microsoft Learn，Power Query documentation

[S04] Microsoft Learn，Query folding basics

[S05] Microsoft Learn，Star schema design for Power BI

[S06] Microsoft Learn，Share Power BI reports and dashboards

[S07] Microsoft Learn，Reports in Power BI

[S08] Microsoft Learn，Set and use date tables

[S09] Microsoft Learn，Row-level security with Power BI

[S10] Microsoft Learn，Learn DAX basics

[S11] Microsoft Learn，CALCULATE function

[S12] Microsoft Learn，DIVIDE function

[S13] Microsoft Taiwan，Power BI pricing

[S14] Microsoft Learn，Publish to web from Power BI

[S15] Microsoft Learn，On-premises gateways in Power BI

[S16] Microsoft Learn，Design reports for accessibility

[S17] Microsoft Learn，Performance Analyzer

[S18] Microsoft Learn，Configure scheduled refresh

[S19] Microsoft Learn，Use DirectQuery in Power BI Desktop

[S20] Microsoft Learn，Understand Fabric licenses and capacity

[S21] Microsoft Learn，Copilot for Power BI overview

[S22] Microsoft Learn，BI strategic planning

[S23] 天地人學堂，Power BI Desktop 課程頁

[S24] Microsoft Learn，KEEPFILTERS function