Microsoft Fabric 採用藍圖：使用者支援

文章
07/30/2024

注意

本文是 [Microsoft Fabric 採用藍圖] 系列文章的一部分。如需系列的概觀，請參閱 [Microsoft Fabric 採用藍圖]。

本文說明使用者支援。其主要著重於問題解決。

本文的第一節著重於您在組織內部控制的使用者支援層面。最後的主題著重於可用的外部資源。

如需相關主題的說明，包括技能指導、訓練、文件以及提供給內部 Fabric 使用者社群的共同開發協助，請參閱指導和使用者啟用一文。這些活動的有效性可大幅減少正式使用者支援要求的數量，並提升整體使用者體驗。

使用者支援的類型

如果使用者遇到問題，他們是否知道解決該問題的選項有哪些？

下圖顯示組織成功採用的一些常見使用者支援類型：

圖表顯示四種類型的內部 Fabric 使用者支援，以及下表所述的兩種外部支援類型。

上圖中顯示的六種使用者支援類型包括：

型別	描述
	內部團隊支援 (內部) 非常非正式。當小組成員在工作的自然過程中相互學習時，就會產生支援。
	內部社群支援 (內部) 可以透過非正式和/或正式方式組織。當同事通過內部社群管道相互交流時，就會發生。
	技術支援中心支援 (內部) 會處理正式的支援問題和要求。
	延伸支援 (內部) 牽涉到處理技術支援中心呈報的複雜問題。
	Microsoft 支援服務 (外部) 包含授權使用者和 Fabric 系統管理員的支援。它也包含完整的文件。
	社群支援 (外部) 包括全球專家社群、Microsoft 最有價值專家 (MVP)，以及參與論壇和發佈內容的愛好者。

在某些組織中，內部小組和內部社群支援與自助資料和商業智慧 (BI) —內容最相關，是由分散式商務單位中的建立者和擁有者所擁有和管理。相反地，技術支援中心和延伸支援專門用於解決技術問題和企業資料和 BI (內容是由集中式 BI 小組或卓越中心所擁有和管理)。在某些組織中，所有四種類型的支援都與任何類型的內容相關。

提示

如需商務導向自助、受控自助和企業資料和 BI 概念的詳細資訊，請參閱內容擁有權和管理一文。

本文會進一步詳細說明上述六種使用者支援類型。

內部小組支援

內部小組支援是指小組成員在日常工作中相互學習和互相協助的時候。作為您擁護者的自助內容建立者，往往自願承擔這種類型的非正式支援角色，因為他們有內在的協助願望。雖然這是非正式的支援模式，但不應該被低估。一些估計值指出，工作中大部分的學習是對等式學習，這對建立領域特定分析解決方案的分析師特別有幫助。

注意

對於部門內唯一的資料分析師來說，內部小組支援效果不佳。對於那些在組織中還沒有太多聯繫的人來說，這也是無效的。當沒有任何親密的同事依靠時，如本文所述，其他類型的支援變得更加重要。

內部社群支援

來自社群成員的協助通常以討論頻道中的訊息或專門為實踐社群設立之論壇的形式提供。例如，有人張貼訊息，表示他們在進行 DAX 計算時遇到問題，或正在尋找合適的 Python 模組來匯入。然後，他們會收到組織中有人提供建議或連結的回應。

提示

內部 Fabric 社群的目標是自我維持，這可能會導致正式支援需求和成本降低。與純粹的集中式方法相比，它還可以促進更廣泛範圍內的受控自助內容建立。但是，您總會需要監視、管理和培養內部社群。以下是兩個特定提示：

請務必在 T-SQL、Python、Data Analysis eXpressions (DAX) 和 Power Query M 公式語言等較困難的主題中培養多名專家。當社群成員成為公認的專家時，他們可能會因為過多的協助請求而感到負擔過重。
許多社群成員可能會輕易回答特定類型的問題 (例如，報表視覺效果)，而少數成員會回答其他問題 (例如，複雜的 T-SQL 或 DAX)。對於 COE 來說，讓社群有機會做出回應，同時也願意及時處理未解決的問題，這一點很重要。如果使用者反覆提出問題而沒有得到答案，則會大幅阻礙社群的成長。在此情況下，如果使用者未收到任何問題回應，則可能會離開，並且永遠不會回來。

內部社群討論頻道通常會設定為 Teams 管道或 Yammer 群組。選擇的技術應該反映使用者已運作的位置，以便活動發生在他們的自然工作流程中。

內部討論通道的其中一個優點是，回應可能來自原始要求者從未見過的人員。在大型組織中，社群實踐會根據共同利益將人員聚集在一起。它可以提供取得協助和學習的不同視角。

使用內部社群討論通道可讓卓越中心 (COE) 監視人們所詢問的問題種類。這是 COE 能夠了解使用者遇到的問題之一 (通常與內容建立相關，但也可能與取用內容相關)。

監視討論通道還可以發現 COE 以前不知道的其他分析專家和潛在擁護者。

重要

最佳做法是不斷發現新興的擁護者，並與他們互動，以確保他們有能力支援其他同事。如社群實踐文章所述，COE 應積極監視討論通道，以查看誰在提供協助。 COE 應刻意鼓勵和支援社群成員。適當時，請他們加入擁護者網路。

討論通道的另一個重要優點是可搜尋，可讓其他人探索資訊。然而，人們在公開論壇而不是私人訊息或電子郵件中提問是一種習慣的改變。請注意，有些人不願意以這種公開方式提出問題。這公開承認他們不知道的事情，可能會令人尷尬。透過促進友好、鼓勵和有益的討論通道，這種不情願的狀況可能會隨著時間而減少。

提示

您可能會想要建立機器人來處理社群中一些最常見、最直接的問題。機器人可以處理簡單的問題，例如「如何要求授權？」或「如何要求工作區？」在採用這種方法之前，請考慮是否有足夠的例程和可預測的問題，讓使用者體驗變得更好，而不是更糟。通常，建立良好的 FAQ (常見問題) 的運作效果更好，並且開發速度更快且更易於維護。

技術支援中心支援

技術支援中心通常以共用服務的形式運作，由 IT 部門負責。可能依賴更正式支援通道的使用者包括：

經驗不足的使用者。
較新的組織。
不願向內部討論社群張貼訊息。
組織內部缺乏聯繫和同事。

還有一些技術問題在沒有 IT 參與的情況下無法完全解決，例如電腦由 IT 管理時的軟體安裝和升級要求。

忙碌的技術支援中心人員通常致力於支援多種技術。因此，最容易支援的問題類型是那些具有明確解決方案並且可以記錄在知識庫中的問題。例如，軟體安裝先決條件或取得授權的要求。

某些組織會要求技術支援中心只處理非常簡單的協助修正問題。其他組織則讓技術支援中心參與任何可重複的工作，例如新的工作區要求、管理閘道資料來源，或要求新的容量。

重要

您的 Fabric 治理決策將直接影響技術支援中心要求的數量。例如，如果您選擇在租用戶設定中限制工作區建立權限，這將導致使用者提交技術支援中心票證。雖然這是合法的決策，但您必須非常快速地滿足要求。可能的話，請在 1-4 小時內回應這種類型的要求。如果您延遲太久，使用者將會使用他們已經擁有的內容，或尋找方法來應對您的要求。這可能不是理想的案例。及時性對於某些技術支援中心要求至關重要。請考慮使用 Power Apps 和 Power Automate 來自動化，有助於讓某些流程更有效率。如需詳細資訊，請參閱租用戶層級工作區規劃。

經過一段時間後，當技術支援中心人員擴充其知識庫和支援 Fabric 的經驗時，疑難排解和解決問題技能會變得更有效。最好的技術支援中心是那些對使用者需要完成的工作有充分把握的人。

提示

純粹的技術問題，例如資料重新整理失敗，或需要將新使用者新增至閘道資料來源，通常涉及與服務等級協定 (SLA) 相關聯的直接回應。例如，可能會有 SLA 在一小時內回應封鎖問題，並在八小時內加以解決。通常更難定義 SLA 來針對問題進行疑難解答，例如資料差異。

延伸支援

由於 COE 深入了解 Fabric 在整個組織中的使用情況，因此，如果發生複雜的問題，這是延伸支援的絕佳選項。應透過呈報路徑讓 COE 參與支援流程。

將要求純粹作為來自技術支援中心的呈報路徑進行管理變得難以執行，因為 COE 成員通常為商務使用者所熟知。為了鼓勵透過適當通道的習慣，COE 成員應該重新導向使用者以提交技術支援中心票證。這也會改善分析技術支援中心要求的資料品質。

Microsoft 支援服務

除了本文所討論的內部使用者支援方法外，還有寶貴的外部支援選項直接提供給使用者和 Fabric 系統管理員，而不應忽略。

Microsoft 文件

請查看 Fabric 支援網站，以取得影響所有客戶的高優先順序問題。全域 Microsoft 365 系統管理員可以存取 Microsoft 365 入口網站中的其他支援問題詳細資料。

請參閱完整的 Fabric 文件。這是一種權威資源，可協助進行疑難排解和搜尋資訊。您可以從文件網站排定結果的優先順序。例如，在 Web 搜尋引擎中輸入網站目標搜尋要求，例如 power bi gateway site:learn.microsoft.com。

Power BI Pro 和 Premium Per User 終端使用者支援

已授權的使用者有資格使用 Microsoft 來記錄支援票證。

提示

請向內部使用者社群清楚說明您是否偏好將技術問題回報給內部技術支援中心。如果您的技術支援中心能夠處理工作負載，那麼擁有集中式內部區域來收集使用者問題可以提供卓越的使用者體驗，而不是每個使用者都嘗試自己解決問題。了解並分析支援問題對於 COE 也很有幫助。

系統管理員支援

Fabric 系統管理員提供數個支援選項。

對於擁有 Microsoft 統一支援合約的客戶，請考慮授與技術支援中心和 COE 成員存取 Microsoft 服務中心的權限。 Microsoft 服務中心優點之一是，您的技術支援中心和 COE 成員可以設定為提交和檢視支援要求。

全球社群支援

除了本文所述的內部使用者支援方法，以及先前所述的 Microsoft 支援選項之外，您還可以利用全球 Fabric 社群。

當沒有領域知識的人可以輕鬆理解問題，並且不涉及機密資料或敏感的內部流程時，全球社群就會很有用。

公開可用的社群論壇

有數個公開社群論壇，使用者可以在其中張貼問題並接收來自世界各地任何使用者的回應。從任何地方獲得任何人的答案可能非常強大，而且非常有幫助。但與任何公共論壇一樣，驗證論壇上發佈的建議和資訊非常重要。張貼在網際網路上的建議可能不適合您的情況。

公開可用的討論區域

人們通常會在社交媒體平台上發佈 Fabric 技術問題。您可能會發現討論、張貼公告，以及使用者互相協助。

社群文件

Fabric 全球社群充滿活力。每天都會發佈大量的 Fabric 部落格貼文、文章、網路研討會和影片。當您依靠社群資訊進行疑難排解時，請注意下列事項：

資訊的更新程度。嘗試確認發佈或上次更新的時間。
在網路上找到的解決方案情況和內容是否真的符合您的情況。
所提供資訊的可信度。依賴信譽良好的部落格和網站。

注意事項和關鍵措施

檢查清單 - 您可以針對使用者支援採取的考量和重要動作。

改善內部小組支援：

提供認可和鼓勵：提供獎勵給擁護者，如實踐社群文章所述。
獎勵辛勞：當您看到有意義的基層努力工作發生時，予以認可和讚揚。
建立正式角色：如果非正式的內部小組不夠努力，請考慮將您想要在此領域制定的角色正規化。適當時，請在 HR 工作描述中包含預期的貢獻和責任。

改善內部社群支援：

持續鼓勵提問：鼓勵使用者在指定的社群討論通道中提出問題。隨著一段時間的習慣建立，將其作為第一選擇將變得常態化。經過一段時間後，它將變得更加自給自足。
主動監視討論區域：確定適當的 COE 成員會主動監視此討論通道。如果問題仍未得到解答，他們可以介入、改進答案或在適當時進行更正。他們還可以張貼其他資訊的連結，以提高對現有資源的認識。儘管社群的目標是實現自我支援，但它仍然需要專門的資源來進行監視和培育。
可用的通訊選項：確保您的使用者群體知道內部社群支援區域存在。其可以包含連結的醒目顯示。您可以在與使用者社群的定期通訊中包含連結。您也可以在 Fabric 入口網站中自訂協助功能表連結，以將使用者導向內部資源。
設定自動化：確保所有授權的使用者都可以自動存取社群討論通道。您可以使用群組型授權，將授權設定為自動化。

改善內部技術支援中心支援：

判斷技術支援中心的責任：決定技術支援中心將處理之 Fabric 支援主題的初始範圍。
評估整備等級：判斷技術支援中心是否準備好處理 Fabric 支援。識別是否有需要解決的整備程度差距。
安排其他訓練：進行知識轉移課程或訓練課程，讓技術支援中心做好準備。
更新技術支援中心知識庫：在可搜尋知識庫中包含已知問題和解答。請確保有人負責定期更新知識庫，以反映一段時間的新功能和增強功能。
設定票證追蹤系統：確定有良好的系統可以追蹤提交給技術支援中心的要求。
決定是否有人隨時待命解決與 Fabric 相關的任何問題：如適當，請確保全天候支援的期望可明確提供。
判斷 SLA 是否存在：存在特定服務等級協定 (SLA) 時，請確保明確記錄和傳達對回應和解決方案的期望。
準備快速採取行動：準備好快速解決特定的常見問題。支援回應緩慢將導致使用者找到因應措施。

改善內部 COE 延伸支援：

判斷呈報支援的運作方式：決定技術支援中心無法直接處理之要求的呈報路徑。請確保 COE (或同等人員) 已準備好在需要時介入。明確定義技術支援中心責任的結束位置，以及 COE 延伸支援責任的開始位置。
鼓勵 COE 與系統管理員之間的共同作業：確定 COE 成員和 Fabric 系統管理員具有直接呈報路徑，可聯絡 Microsoft 365 和 Azure 的全域管理員。當出現超出 Fabric 範圍的廣泛問題時，建立通訊通道至關重要。
建立從 COE 到技術支援中心的意見反應迴圈：當 COE 了解到新資訊時，應該更新 IT 知識庫。目標是讓主要技術支援中心持續變得更好，能夠在未來處理更多問題。
建立從技術支援中心到 COE 的意見反應迴圈：當支援人員發現冗餘或效率低下時，他們可以將此資訊傳達給 COE，COE 可能會選擇改善知識庫或參與其中 (特別是與治理或安全性相關)。

要思考的問題

使用以下問題來評定使用者支援。

誰負責支援企業資料和 BI 解決方案？自助式解決方案呢？
如何識別問題的商務影響和緊迫性以有效偵測關鍵問題並確定其優先順序？
商務使用者是否有明確的流程可報告資料和 BI 解決方案的問題？企業與自助解決方案之間的差異為何？什麼是呈報路徑？
內容建立者和取用者通常會遇到哪些類型的問題？例如，他們是否遇到資料品質問題、效能問題、存取問題等？
是否有任何問題在未解決的情況下就已結案？今天的資料項目或報表中是否存在「已知問題」？
資料資產擁有者是否有將自助 BI 解決方案的問題呈報給 COE 等中央團隊的流程？
資料和現有解決方案中出現的問題有多頻繁？在這些問題影響商務終端使用者之前，已發現多少比例的問題？
解決問題通常需要多久的時間？這個時間對商務使用者來說足夠嗎？
最近出現的問題以及對商務的具體影響有哪些？
企業小組和內容建立者是否知道如何向 Microsoft 回報 Fabric 問題？企業小組是否可以有效地利用社群資源來解決關鍵問題？

警告

在評估使用者支援和描述風險或問題時，請小心使用中性語言，不要將責任歸咎於個人或小組。確保每個人的觀點在評定中得到公平體現。專注於客觀事實，以準確了解和描述內容。

成熟度等級

下列成熟度層級可協助您評定 Power BI 使用者支援的目前狀態。

等級	使用者支援的狀態
100：初始	• 個別商務單位會尋找相互支援的有效方式。然而，這些戰術和實踐是孤立的，沒有得到一致的應用。 • 可供使用的內部討論通道。然而，它並沒有受到密切監視。因此，使用者體驗不一致。
200：可重複	• COE 積極鼓勵內部小組支援和擁護者網路的成長。 • 內部討論通道受到重視。它已成為提問和討論的預設場所。 • 技術支援中心會處理少數最常見的技術支援問題。
300：已定義	• 內部討論通道很受歡迎，而且基本上可自我維持。 COE 會主動監視及管理討論通道，以確保所有問題都能快速且正確回答。 • 已建立技術支援中心追蹤系統，以監視支援頻率、回應主題和優先順序。 • COE 會在需要時提供適當的延伸支援。
400：能力	• 技術支援中心經過全面培訓，並準備處理更多已知和預期的技術支援問題。 • SLA 用於定義技術支援中心支援期望，包括延伸支援。會記錄並傳達這些期望，以便所有相關人員都能清楚了解。
500：高效率	• 技術支援中心與 COE 之間存在雙向意見反應迴圈。 • 關鍵效能指標會衡量滿意度與支援方法。 • 自動化已就緒，可讓技術支援中心快速回應並減少錯誤 (例如，API 和指令碼的使用)。