Power BI 實作規劃：BI 解決方案規劃
注意
本文是 Power BI 實作規劃系列文章的其中一篇。 此系列主要著重於 Microsoft Fabric 中的 Power BI 體驗。 如需有關此系列的簡介，請參閱 Power BI 實作規劃。
本文可協助您規劃支援商業智慧 (BI) 策略的解決方案。 本文的主要目標讀者為：
- BI 和分析主管或經理：負責監督 BI 計劃和策略重要 BI 解決方案的決策者。
- 卓越中心 (COE)、IT 和 BI 小組：為組織設計及部署企業 BI 解決方案的小組。
- 主題專家 (SME) 和內容擁有者以及建立者：擁護部門分析的小組和個人，以及設計和部署自助服務、部門 BI 或小組 BI 使用案例的解決方案。
BI 策略是實作、使用及管理資料和分析的計劃。 您可以從 BI 策略規劃開始定義 BI 策略。 策略規劃可協助您識別 BI 焦點區域和目標。 若要判斷走向 BI 目標的路徑，您可以使用戰術規劃來描述特定的關鍵結果。 然後，您可以規劃及部署 BI 解決方案，以取得這些關鍵結果的進度。
注意
在目標與關鍵結果 (OKR) 架構中，目標清楚、高階描述您想要達成的目標。 相反地，關鍵結果是特定且可達成的結果，可測量其中一個目標的進度。
此外，行動方案或解決方案是程序或工具，建置目的是為協助您達成一或多個關鍵結果。 解決方案可解決使用者的特定資料需求。 解決方案可以採用許多形式，例如資料管線、資料湖存放庫或 Power BI 語意模型或報表。
如需 OKR 的詳細資訊，請參閱了解 OKR (Microsoft Viva Goals)。
有許多方法可規劃及實作 BI 解決方案。 本文說明一種方法，您可以採取這種方法來規劃及實作支援 BI 策略的 BI 解決方案。
下列高階圖表描述如何進行 BI 解決方案規劃。
您可以採取下列步驟來執行 BI 解決方案規劃。
| Step | 說明 |
|---|---|
| 1 | 召集專案小組，以收集需求並定義解決方案的設計。 |
| 2 | 執行工具和程序的初始設定來規劃解決方案部署。 |
| 3 | 進行解決方案概念證明 (POC)，以驗證設計的相關假設。 |
| 4 | 使用反覆的開發與驗證週期來建立及驗證內容。 |
| 5 | 將解決方案發行至實際執行環境之後，部署、支援及監視解決方案。 |
如需詳細資訊，請參閱 Power BI 移轉系列。 雖然系列與移轉有關，但關鍵動作和考量與解決方案規劃有關。
步驟 1：收集需求
您可以先收集需求並定義解決方案設計，以開始規劃解決方案。
注意：策略和戰術規劃是由一個工作小組所主導，該小組也主導行動方案。 相反地，方案規劃是由專案小組所主導，其中包含內容擁有者和建立者。
收集正確的需求，對於達成成功的解決方案部署和採用至關重要。 收集需求的有效方式是識別並納入正確的專案關係人、共同定義要解決的問題，以及使用對於問題的共同了解來建立解決方案設計。
以下是使用共同作業方法來收集需求的一些優點。
- 使用者輸入會產生更實用的設計：您可以讓使用者參與聚焦討論來收集需求，以更有效地擷取商務資料需求。 例如，使用者可以向內容建立者示範他們使用現有解決方案的方式，並提供關於這些解決方案所感知到有效性的意見反應。
- 避免假設並減輕變更要求：與使用者的討論通常會顯示細微差別、例外狀況和隱藏的複雜性。 這些深入解析可降低後期要求的可能性，這些要求可能需要耗費大量成本才能解決。
- 上線使用者會增加解決方案採用率：您可以讓使用者參與設計和早期開發，讓他們有機會影響最終的結果。 參與也可以讓使用者感受智慧擁有權和解決方案的責任感。 高度參與的使用者將更有可能背書解決方案，並引導其實務社群有效地使用解決方案。
- 設計會設定專案關係人和商務使用者的期望：您可以產生解決方案設計的模擬或圖例，清楚地向專案關係人顯示解決方案將提供的內容。 其也有助於建立對於預期專案結果的互相理解。 此程序也稱為設計思維，其可以是一種處理及了解複雜問題的有效方法。
您可以採取不同的方法來讓使用者參與並收集需求。 例如，您可以使用商務設計和技術設計來收集需求 (本文稍後章節將詳細說明)。
商務設計是收集商務需求的方法。 其著重於讓商務使用者參與商務設計工作階段，以共同作業設計解決方案。 商務設計的輸出包含解決方案模擬和描述性設計文件。
技術設計是將商務需求轉譯為技術需求，以及解決設計假設的方法。 技術設計著重於驗證商務設計，並定義要使用的技術方法。 為了驗證設計，內容建立者通常會在必要時與技術專家進行聚焦討論，稱為技術設計研討會。
重要
收集錯誤的需求是實作失敗的常見原因。 小組通常會收集錯誤的需求，因為他們與錯誤的專案關係人互動，例如對於所要建置的解決方案提供由上而下要求的決策者。
使用商務設計之類的共同作業方法吸引商務使用者，可協助您收集更好的需求。 較佳的需求通常會導致較有效率的開發及較健全的解決方案。
注意
對於某些小組而言，採用結構化需求收集程序是一項重大變更。 請確定您妥善管理這項變更，而不會中斷解決方案規劃。 建議您找到調整這些方法的方式，以配合小組的運作方式。
準備解決方案規劃
您應該先考慮下列各節中所述的因素來準備解決方案規劃。
- 識別將進行解決方案規劃的人員：在 BI 戰術規劃過程中，工作小組建立了優先處理的解決方案待辦項目。 在解決方案規劃中，專案小組負責從待辦項目設計、開發及部署一或多個解決方案。 針對待辦項目中的每個解決方案，您應該召集負責解決方案的專案小組。 除了執行 BI 解決方案規劃之外，專案小組也應該：
- 定義解決方案規劃的時程表和里程碑。
- 識別並讓適當的專案關係人參與來收集需求。
- 設定通訊、文件和規劃的集中式位置。
- 讓專案關係人參與以收集需求。
- 與專案關係人和商務使用者溝通與協調。
- 與商務使用者協調反覆開發和測試週期。
- 記錄解決方案。
- 定義並制定訓練計劃，將使用者上線至解決方案。
- 提供部署後解決方案支援。
- 解決合理的使用者要求，以在部署後變更或更新解決方案。
- 如有必要，在部署後進行解決方案交接。
- 集中通訊和文件：專案小組務必集中溝通和文件，以進行 BI 解決方案規劃。 例如，專案小組應集中需求、專案關係人通訊、時程表和交付項目。 請考慮將所有文件儲存在集中式入口網站中。
- 計劃需求收集：專案小組應從規劃商務設計研討會開始收集商務需求。 這些研討會採用互動式會議的形式，且可以遵循與策略規劃研討會類似的格式。
提示
請考慮在需求收集程序中，儘早識別並讓負責解決方案的支援小組參與。 為了有效支援解決方案，支援小組必須對於解決方案、其用途和使用者有全面的了解。 當專案小組僅由外部顧問組成時，這會特別重要。
收集商務需求
收集正確的商務需求，對於設計正確的解決方案至關重要。 為了收集正確的需求並定義有效的解決方案設計，專案小組可以與商務使用者一起進行商務設計研討會。
商務設計研討會的目的是為：
- 確認初始解決方案範圍。
- 定義並了解解決方案應解決的問題。
- 識別解決方案的正確重要專案關係人。
- 收集正確的商務需求。
- 準備符合商務需求的解決方案設計。
- 準備支援的設計文件。
下圖說明如何收集商務需求，並使用商務設計方法來定義解決方案設計。
此圖表描述下列步驟。
| 項目 | 說明 |
|---|---|
 |
專案小組會確認第一個記載在戰術規劃中的解決方案範圍，藉此開始進行商務設計。 其應該釐清解決方案將包含的商務領域、系統和資料。 |
 |
專案小組會從使用者社群識別將參與商務設計研討會的主要專案關係人。 主要專案關係人是具備足夠知識和可信度的使用者，可代表解決方案的主題領域。 |
 |
專案小組會規劃商務設計研討會。 規劃包括通知專案關係人、組織會議、準備交付項目，以及與商務使用者互動。 |
 |
專案小組會收集並研究商務使用者目前用來解決現有商務資料需求的現有解決方案。 為了加速此程序，專案小組可以使用 BI 策略規劃的相關研究，其已記載於通訊中樞。 |
 |
專案小組會與專案關係人執行商務設計研討會。 這些研討會是小型互動式會議，其中專案小組會引導專案關係人了解商務資料需要和需求。 |
 |
專案小組會向專案關係人和其他使用者呈現方案設計草稿，以取得意見反應及核准，藉此總結商務設計。 當專案關係人同意設計可協助他們達成其營運目標時，商務設計就成功。 |
商務設計以下列交付項目做為總結。
- 草稿解決方案設計：模擬、原型或線框圖表說明解決方案設計。 這些文件會將需求轉譯為具體的設計藍圖。
- 商務計量清單：解決方案中預期的量化欄位，包括商務定義和預期的彙總。 可能的話，請依使用者的重要性來將其排名。
- 商務屬性清單：解決方案中預期的相關屬性和資料結構，包括商務定義和屬性名稱。 可能的話，請包含階層，並依使用者的重要性來排名屬性。
- 補充文件：重要功能或合規性需求的描述。 本文件應盡可能精確，但盡可能簡潔。
商務設計交付項目會用於技術設計，並由技術設計進行驗證。
提示
解決方案模擬、原型或線框圖表可讓開發人員和終端使用者清楚了解預期的結果。 建立有效的模擬不需要藝術技能或天賦。 您可以使用簡單的工具，例如 Microsoft Whiteboard、PowerPoint，甚至是畫筆和紙張來說明設計。
收集技術需求
完成商務設計之後，專案小組會使用技術設計來驗證其結果。 技術設計是類似於商務設計的方法。 雖然商務設計著重於商務資料需求，但技術設計則著重於解決方案的技術層面。 技術設計的主要成果是解決方案計劃，其描述最終解決方案設計，並告知預估實作方案的投入量。
注意
不同於商務設計，技術設計主要是對內容建立者和擁有者所執行來源資料和系統進行獨立調查。
技術設計的目的是為：
- 驗證商務設計的結果。
- 解決目前設計中的技術假設。
- 識別範圍中的相關資料來源，並定義每個資料來源的欄位計算和欄位來源對應。
- 將商務需求轉譯為技術需求。
- 產生實作所需的投入量估計。
專案小組會以有限的聚焦技術設計研討會，與技術或功能專案關係人互動。 這些研討會是與功能專案關係人的互動式會議，可收集技術需求。 專案關係人負責解決方案有效運作所需的特定功能領域。
技術設計中專案關係人的範例可能包含：
- 安全性和網路小組：負責確保資料的安全性與合規性。
- 功能小組和資料管理人：負責策劃來源資料。
- 架構設計人員：特定平台、工具或技術的擁有者。
專案小組與專案關係人參與技術設計研討會，以解決解決方案的技術層面。 技術層面可能包括：
- 資料來源連線：如何連線及整合資料來源的詳細資料。
- 網路和資料閘道：私人網路或內部部署資料來源的詳細資料。
- 欄位來源對應：商務計量和屬性的資料對應至資料來源欄位。
- 計算邏輯：將商務定義轉譯為技術計算。
- 技術功能：支援商務需求所需的特性或功能。
提示
進行商務設計的專案小組也應該進行技術設計。 不過，基於實際原因，不同的人員可能會主導技術設計。 在此情況下，請檢閱商務設計的結果，以開始技術設計。
在理想情況下，主導技術設計的人員應該能徹底了解結果和商務使用者。
下圖說明如何使用技術設計，將商務需求轉譯為技術需求。
此圖表描述下列步驟。
| 項目 | 說明 |
|---|---|
|
專案小組會根據商務設計的結果定義資料來源範圍，以開始技術設計。 資料來源範圍會宣告建置解決方案所需的資料。 為了識別正確的資料來源，專案小組會洽詢商務和功能中小企業。 |
|
專案小組會識別稍後要參與技術設計研討會的技術或功能專案關係人。 |
|
專案小組會規畫有限的聚焦會議，與功能專案關係人討論解決方案的技術層面。 規劃包括通知專案關係人、組織會議以及準備交付項目。 |
|
專案小組會研究技術需求。 研究包括定義欄位計算和資料來源對應，以及使用技術分析和文件來解決商務設計假設。 |
|
專案小組會視需要讓專案關係人參與技術設計研討會。 研討會著重於解決方案的特定技術層面，例如安全性或資料來源連線。 在這些課程中，專案小組會收集專案關係人和中小企業的質化意見反應。 |
|
專案小組會使用向專案關係人和決策者呈現的解決方案計劃來準備其結果。 此計劃是商務設計成果的反覆項目和延伸，包括最終設計、估計和其他交付項目。 |
 |
技術設計應與專案關係人和決策者進行最後一次會議做為總結，以決定是否繼續進行。 此會議提供資源在認可開發解決方案之前，評估解決方案規劃的最後機會。 |
注意
根據目前的資源可用性或組織整備程度，技術設計可能會顯示非預期的複雜性，使得解決方案規劃變得不可行。 在此情況下，應在後續的戰術規劃期間重新評估解決方案。 視商務資料需求的緊迫性而定，決策者 (例如執行發起人) 可能仍需要繼續進行概念證明，或只有一部分的計劃解決方案。
技術設計以解決方案計劃做為總結，其中包含下列交付項目。
- 工具和技術：實作解決方案所需的相關技術工具清單。 此清單通常包含相關的新授權選項 (例如 Fabric 容量或 Premium Per User)、功能和工具。
- 已定義商務計量清單：所有範圍內資料來源商務計量的計算和欄位來源對應。 為了產生此交付項目，專案小組會使用商務設計中建立的商務計量清單。
- 定義商務屬性清單：所有範圍內資料來源商務屬性的欄位來源對應。 為了產生此交付項目，專案小組會使用商務設計中建立的商務屬性清單。
- 修訂的設計：根據對商務設計所做的變更或無效的假設，修訂解決方案設計。 修訂的設計是商務設計中產生的模擬、原型或線框圖表的更新版本。 如果不需要修訂，請傳達技術設計會驗證商務設計。
- 預估投入量：預估開發、支援和維護解決方案所需的資源。 估計值會告知是否要繼續實作解決方案的最終決定。
重要
請確定專案小組會向專案關係人通知技術設計中的任何變更或非預期的探索。 這些技術設計研討會仍應讓相關的商務使用者參與。 不過，請確定不會向專案關係人不必要地公開複雜的技術資訊。
提示
因為營運目標日新月異，所以預期需求會有所變更。 請勿假設 BI 專案的需求是固定不變。 如果您難以應付瞬息萬變的需求，則可能表示您的需求收集程序無效，或您的開發工作流程無法充分納入一般意見反應。
檢查清單：收集需求時，主要決策和動作包括：
- 釐清擁有解決方案規劃的人員：針對每個解決方案，請確定專案小組會清楚說明角色和責任。
- 釐清解決方案範圍：解決方案範圍應已在 BI 戰術規劃中有所記載。 在開始解決方案規劃之前，您可能需要花費額外的時間和投入量來釐清範圍。
- 識別並通知專案關係人：識別商務設計和技術設計的專案關係人。 向他們事先告知專案，並說明商務設計的範圍、目標、所需的時間投資和交付項目。
- 規劃和執行商務設計研討會：仲裁商務設計研討會，以向專案關係人和商務使用者取得資訊。 要求使用者示範他們使用現有解決方案的方式。
- 記錄商務計量和屬性：使用現有解決方案和專案關係人的輸入，建立商務計量和屬性的清單。 在技術設計中，將欄位對應至資料來源，並描述量化欄位的計算邏輯。
- 解決方案設計草稿：根據專案關係人輸入建立反覆的模擬，以可視化方式反映預期的解決方案結果。 請確定模擬能正確呈現並解決商務需求。 與商務使用者溝通，模擬項目在技術設計期間仍必須經過驗證 (且可能經過修訂)。
- 建立解決方案計劃：研究來源資料和相關技術考量，以確保商務設計可達成。 如有相關，請描述設計的主要風險和威脅，以及任何替代方法。 如有必要，請準備解決方案設計的修訂，並與專案關係人討論。
- 建立投入量估計值：在最終解決方案計劃中，預估建置及支援解決方案的投入量。 以商務設計和技術設計研討會期間收集到的資訊來合理化這些估計值。
- 決定是否繼續進行計劃：若要總結需求收集程序，請向專案關係人和決策者提出最終計劃。 本次會議旨在決定是否要繼續進行解決方案開發。
步驟 2：規劃部署
當專案小組完成收集需求、建立解決方案計劃並接收核准以繼續進行時，即可規劃解決方案部署。
部署規劃工作會因解決方案、開發工作流程以及部署程序而有所不同。 部署計劃通常關於涉及規劃和設定解決方案的工具和程序的許多活動。
規劃解決主要領域
專案小組應規劃解決方案部署的主要領域。 一般而言，規劃應該處理下列領域。
- 合規性：確定特定動作會解決需求收集中識別到的所有合規性準則。 將每個動作指派給特定人員，並清楚定義傳遞時間範圍。
- 安全性：決定要管理不同層級解決方案的存取方式，以及任何資料安全性規則需求。 檢閱解決方案安全性較租用戶中的標準內容更嚴格或是更不嚴格。
- 資料閘道：評估解決方案是否需要資料閘道才能連線到資料來源。 判斷是否需要特定的閘道設定或高可用性叢集。 規劃能夠透過閘道安全性角色管理閘道連線的人員，以及監視閘道的方式。 如需詳細資訊，請參閱佈建閘道存取。
- 工作區：決定設定和使用工作區的方式。 判斷解決方案是否需要 Git 整合和部署管線等生命週期管理工具，以及是否需要使用 Azure Log Analytics 進行進階記錄。
- 支援：建立負責在生產環境部署後支援及維護解決方案的人員。 如果負責支援的個人與專案小組不同，請讓這些人員參與開發。 請確定支援解決方案的任何人員都了解解決方案設計、解決方案設計應該解決的問題、應該使用解決方案設計的人員，以及使用方式。
- 使用者訓練：預測訓練使用者社群所需的投入量，讓他們能夠有效地使用解決方案。 請考慮是否需要任何特定的變更管理動作。
- 治理：識別解決方案的任何潛在治理風險。 預期讓使用者能夠有效地使用解決方案所需的投入量，同時降低任何治理風險 (例如，使用敏感度標籤和原則)。
進行初始設定
專案小組應執行初始設定以著手進行開發。 初始設定活動可能包括：
- 初始工具和程序：針對開發、測試及部署所需的任何新工具和程序執行第一次設定。
- 身分識別和認證：建立將用來存取工具和系統的安全性群組和服務主體。 有效且安全地儲存認證。
- 資料閘道：為內部部署資料來源 (企業模式閘道) 或私人網路 (虛擬網路或 VNet、閘道) 上的資料來源部署資料閘道。
- 工作區和存放庫：建立及設定用來發佈和儲存內容的工作區和遠端存放庫。
注意
部署規劃會根據解決方案和您慣用的工作流程而有所不同。 本文僅說明高階規劃和可採取動作的項目。
如需部署規劃的詳細資訊，請參閱規劃部署以移轉到 Power BI。
檢查清單：規劃解決方案部署時，關鍵決策和動作包括：
- 規劃主要領域：規劃解決成功開發及部署解決方案所需的程序和工具。 解決技術領域 (例如資料閘道或工作區) 並且採用 (例如使用者訓練和治理)。
- 進行初始設定：建立開發及部署解決方案所需的工具、程序和功能。 記錄安裝程式，以協助未來需要進行首次設定的其他人員。
- 測試資料來源連線：驗證適當的元件和程序已就緒，以連線到正確的資料，開始概念證明。
步驟 3：進行概念證明
專案小組會進行解決方案概念證明 (POC)，以驗證未完成的假設，並示範商務使用者的早期優點。 POC 是一種初始設計實作，其範圍和成熟度有限。 執行良好的 POC 對於大型或複雜的解決方案來說特別重要，因為其可以識別並解決技術設計中未偵測到的複雜度 (又稱例外狀況)。
建議您在準備 POC 時考慮下列事項。
- 目標和範圍：描述解決方案 POC 的用途及其將解決的功能領域。 例如，專案小組可以決定將 POC 限制為單一功能領域，或一組特定的需求或功能。
- 來源資料：識別 POC 中將使用哪些資料。 根據解決方案，專案小組可能會決定使用不同類型的資料，例如：
- 生產 (實際) 資料
- 範例資料
- 產生的綜合資料，類似於實際資料量和實際執行環境中觀察到的複雜度
- 示範：描述專案小組向專案關係人和使用者示範 POC 的方式和時機。 可在一般更新期間提供示範，或在 POC 符合特定功能準則時提供示範。
- 環境：描述專案小組將建置 POC 的位置。 理想的方法是針對 POC 使用不同的沙箱環境，並在開發環境準備就緒時，將其部署至開發環境。 沙箱環境具有更具彈性的原則和流暢的內容，並著重於產生快速結果。 相反地，開發環境會遵循更結構化的程序來啟用共同作業，並著重於完成特定工作。
- 成功準則：定義 POC 成功時間，以及應移至下一個反覆項目並進入正式開發時間的閾值。 開始 POC 之前，專案小組應該先識別 POC 成功時間的明確準則。 專案小組會事先設定這些準則，以定義 POC 開發結束的時間，以及反覆開發和驗證週期開始的時間。 根據 POC 的目標，專案小組可以設定不同的成功準則，例如：
- 專案關係人 POC 核准
- 特性或功能的驗證
- 在固定的開發時間之後，由同儕對 POC 進行有利的檢閱
- 失敗：確定專案小組可以識別 POC 失敗。 儘早找出失敗有助於調查根本原因。 其也有助於避免對部署至生產環境時無法如預期運作的解決方案進行進一步投資。
警告
當專案小組進行 POC 時，應該對假設和限制提高警覺。 例如，專案小組無法使用一組小型資料，輕鬆地測試解決方案效能和資料品質。 此外，請確定 POC 的範圍和用途對商務使用者而言明確清楚。 請務必傳達 POC 是第一個反覆項目，並強調其並非生產解決方案。
注意
如需詳細資訊，請參閱進行概念證明以移轉至 Power BI。
檢查清單：建立 POC 時，關鍵決策和動作包括：
- 定義目標：確定 POC 的目標對所有參與者都明確清楚。
- 定義 POC 的範圍：確定建立 POC 不會花費太多開發投入量，同時仍會提供價值並示範解決方案設計。
- 決定將使用哪些資料：識別您將用來進行 POC 的來源資料、合理化決策，並概述潛在風險和限制。
- 決定 POC 的示範時間和方式：計劃向決策者和商務使用者呈現 POC 來顯示進度。
- 釐清 POC 結束的時間：確定專案小組決定 POC 的明確結論，並描述其提升為正式開發週期的方式。
步驟 4：建立和驗證內容
POC 成功時，專案小組會從 POC 轉向建立和驗證內容。 專案小組可以使用反覆開發和驗證週期來開發 BI 解決方案。 這些週期是由反覆發行所組成，其中專案小組會在開發環境中建立內容，並將其發行至測試環境。 在開發期間，專案小組會逐漸在試驗程序中將使用者社群上線至測試環境中早期 (beta) 版本的解決方案。
提示
反覆傳遞鼓勵早期驗證和意見反應，以減輕變更要求、提升解決方案採用，並在正式版本之前實現優點。
反覆開發和驗證週期會繼續進行，直到專案小組抵達預先定義的結論為止。 一般而言，開發會在沒有其他功能可實作或使用者意見反應時總結。 當開發和驗證週期總結時，專案小組會使用最終正式版本，將內容部署到實際執行環境。
下圖描述專案小組如何使用開發和驗證週期反覆提供 BI 解決方案。
此圖表描述下列步驟。
| 項目 | 說明 |
|---|---|
|
專案小組會向使用者社群傳達每個版本，並描述變更和新功能。 在理想情況下，溝通包括解決方案示範和問答，讓使用者了解版本中的新功能，而且他們可以提供口頭意見反應。 |
|
在驗證期間，使用者會透過中央工具或表單提供意見反應。 專案小組應定期檢閱意見反應，以解決問題、接受或拒絕要求，並告知即將推出的開發階段。 |
|
專案小組會監視解決方案的使用方式，以確認使用者正在對其進行測試。 如果沒有使用方式，專案小組應該與使用者社群互動，以了解原因。 低使用量可能表示專案小組需要採取進一步啟用和變更管理動作。 |
|
專案小組會立即回應使用者意見反應。 如果專案小組花費太多時間來處理意見反應，使用者可能會很快失去提供意見反應的意願。 |
|
專案小組會將已接受的意見反應納入解決方案規劃中。 如有必要，他們會檢閱規劃優先順序，以在下一個開發階段開始之前釐清及委派工作。 |
|
專案小組會繼續開發下一個版本的解決方案。 |
|
專案小組會逐一查看所有步驟，直到其達成預先定義的結論，且解決方案已準備好進行生產部署。 |
下列各節說明使用反覆開發和驗證週期來提供 BI 解決方案的重要考量。
建立內容
專案小組會遵循其一般開發工作流程來開發解決方案。 不過，在建立內容時，他們應該考量下列幾點。
- 在每個開發週期期間，更新文件以描述解決方案。
- 總結每個開發週期，並宣告給使用者社群。 公告應該張貼到集中式入口網站，且應該在每個版本中提供變更和新功能的簡短描述。
- 考慮以每個版本來組織研討會，向使用者社群示範變更和新功能，並回答任何口頭問題。
- 定義反覆開發和驗證週期何時總結。 請確定有清楚的程序將解決方案部署至實際執行環境，包括轉換以支援和採用活動。
驗證內容
每個反覆的開發週期都應該以內容驗證做為總結。 針對 BI 解決方案，通常有兩種驗證。
- 開發人員驗證：解決方案測試是由內容建立者和同儕完成。 開發人員驗證的目的是要在解決方案可供商務使用者使用之前，先識別並解決所有重要且顯而易見的問題。 問題可能與資料正確性、功能或使用者體驗有關。 在理想情況下，內容是由未開發內容的內容建立者進行驗證。
- 使用者驗證：解決方案測試是由使用者社群完成。 使用者驗證的目的是為稍後的反覆項目提供意見反應，並識別開發人員未找到的問題。 正式使用者驗證期間通常稱為使用者驗收測試 (UAT)。
重要
請確定在開發人員驗證期間 (在 UAT 之前) 處理任何資料品質問題。 這些問題可以快速削弱對解決方案的信任，且可能會損害長期採用。
提示
進行使用者驗證時，請考慮偶爾與主要使用者進行簡短通話。 使用解決方案時，請對其進行觀察。 記下他們認為難以使用的內容，或解決方案中哪些部分無法如預期般運作。 這種方法可能是收集意見反應的有效方法。
在專案小組驗證內容時，請考慮下列考量事項。
- 鼓勵使用者意見反應：在每個版本中，要求使用者提供意見反應，並示範他們如何有效地這樣做。 請考慮定期共用導致最近變更和新功能的意見反應和要求範例。 您會共用範例來示範已認可並受到重視的意見反應。
- 隔離較大的要求：某些意見反應項目需要更多投入量來處理。 請確定專案小組可以識別這些項目，並討論是否會實作這些項目。 請考慮記錄較大的要求，以在稍後的戰術規劃研討會上進行討論。
- 開始變更管理活動：訓練使用者如何使用解決方案。 請務必在新程序、新資料和不同的工作方式上花費額外的投入量。 投資變更管理對於長期解決方案採用有正面的回報。
當解決方案達到預先定義的完整性和成熟度等級時，專案小組就準備好將其部署至生產環境。 部署之後，專案小組會從反覆傳遞轉換為支援及監視生產解決方案。
注意
開發和測試會根據解決方案和您慣用的工作流程而有所不同。
本文僅說明高階規劃和可採取動作的項目。 如需反覆開發和測試週期的詳細資訊，請參閱建立內容以移轉至 Power BI。
檢查清單：建立和驗證內容時，關鍵決策和動作包括：
- 使用反覆程序來規劃及指派工作：針對每個版本的解決方案規劃並指派工作。 請確定規劃和指派工作的程序具有彈性，並納入使用者意見反應。
- 設定內容生命週期管理：使用工具和程序來簡化及自動化解決方案部署和變更管理。
- 建立工具以集中處理意見反應：使用您和使用者認為簡單的解決方案，自動收集意見反應。 建立直接的表單，以確保意見反應簡潔而可採取動作。
- 排程會議以檢閱意見反應：開會以簡短檢閱每個新的或未完成的意見反應項目。 決定是否要實作意見反應、將負責實作的人員，以及要採取哪些動作來關閉意見反應項目。
- 決定反覆傳遞總結時間：描述反覆傳遞週期何時總結的條件，以及何時將內容發行至實際執行環境。
步驟 5：部署、支援和監視
準備好時，專案小組會將已驗證的解決方案部署到實際執行環境。 專案小組應採取關鍵採用和支援動作，以確保部署成功。
若要確保部署成功，您可以執行下列支援和採用工作。
- 傳達最終版本：執行發起人、經理或其他擁有足夠授權和信譽的人員應向使用者社群宣布發行。 通訊應清楚、簡潔，並包含相關解決方案和支援通道的連結。
- 對內容取用者進行訓練：在發行至生產環境的第一週內，應為內容取用者提供訓練。 訓練應著重於釐清解決方案範圍、回答使用者問題，以及說明如何使用解決方案。
- 處理意見反應和要求：請考慮為使用者提供頻道，以向專案小組提交意見反應和要求。 請確定已討論合理的意見反應和要求，並適時在部署後支援期間進行實作。 在正式版本之後對意見反應和要求採取行動至關重要。 其指出敏捷式解決方案，可回應瞬息萬變的業務需求。
- 規劃與使用者社群連線：即使在部署後支援期間結束之後，確保解決方案擁有者會定期與使用者社群會面。 這些會議是修改 BI 策略的重要意見反應來源。 此外，他們也可透過啟用使用者來協助支援解決方案採用。
- 交接動作：專案小組的成員可能不負責維護解決方案。 在此情況下，小組應識別負責並執行交接的人員。 在發行至生產環境之後，交接應該會很快發生，且應該同時處理解決方案和使用者社群。
警告
若無法進行有效的交接，可能會導致解決方案支援和採用在其生命週期期間發生可預防的問題。
部署之後，專案小組應該規劃繼續進行優先處理的解決方案待辦項目中的下一個解決方案。 請確定您收集任何新的意見反應和要求，並視需要對戰術規劃進行修訂，包括解決方案待辦項目。
檢查清單：考慮解決方案部署時，關鍵決策和動作包括：
- 建立通訊計劃：規劃如何溝通發行、訓練和其他解決方案支援或採用動作。 請確定傳達並立即解決在部署後支援期間的任何中斷或問題。
- 遵循訓練計劃：訓練使用者以使用解決方案。 請確定訓練在發行後的幾週內同時包含即時和錄製的訓練課程。
- 進行交接活動：如有必要，請準備從開發小組交接給支援小組。
- 進行解決方案工作時間：在部署後支援期間之後，請考慮定期舉行工作時間研討會，以回答問題，並收集使用者的意見反應。
- 設定持續改善程序：排程解決方案的每月稽核，以檢閱一段時間內的潛在變更或改進。 集中使用者意見反應，並定期檢閱各稽核之間的意見反應。
相關內容
如需更多考量、動作、決策準則和建議，以協助您進行 Power BI 實作決策，請參閱 Power BI 實作規劃。