Microsoft Fabric 採用路線圖：使用者支援

備註

本文是＜Microsoft Fabric 採用藍圖＞系列文章的一部分。 如需系列的概觀，請參閱 Microsoft Fabric 採用藍圖 (機器翻譯)。

本文主要針對使用者支援。 它主要著重於解決問題。

本文的前半部分聚焦於您在組織內部可掌控的使用者支援面向。 最後的主題聚焦於可用的外部資源。

關於相關主題的說明，包括技能指導、培訓、文件撰寫，以及提供給內部 Fabric 使用者社群的共同開發協助，請參閱 指導與使用者賦能 條目。 這些活動的成效能大幅減少正式用戶支援請求的數量，並提升整體使用者體驗。

使用者支援類型

如果使用者遇到問題，他們知道有哪些解決方法嗎？

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

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

類型	Description
	團隊內部支援（內部） 非常非正式。 支持發生在團隊成員在日常工作中自然而然地彼此學習時。
	內部社群支持（內部 ）可以以非正式、正式或兩者兼具的方式組織。 當同事通過內部社群管道相互交流時，就會發生。
	技術支援中心支援 (內部) 會處理正式的支援問題和要求。
	內部延伸支援 涉及處理由客服中心升級的複雜問題。
	Microsoft 支援（外部） 包括對授權使用者及 Fabric 管理員的支援。 同時也包含 完整的文件。
	社群支援（外部） 包括全球專家社群、 Microsoft 最受重視專業人士（MVP）及參與論壇並發表內容的愛好者。

在某些組織中，團隊內部及內部社群支援對於自助式資料與商業智慧（BI）最為重要——內容由去中心化業務單位的創作者與擁有者擁有與管理。 相反地，客服台與延伸支援則保留給技術問題、企業資料與商業智慧（內容由集中式智慧團隊或 卓越中心擁有與管理）。 在某些組織中，這四種支援類型都可能適用於任何類型的內容。

小提示

欲了解更多關於企業主導自助服務、管理自助服務，以及企業資料與商業智慧概念的資訊，請參閱 內容所有權與管理 條目。

上述六種使用者支援類型，本文將有更詳細說明。

隊內支援

團隊內部支持 指的是團隊成員在日常工作中互相學習並互相幫助。 成為你 支持 者的自助內容創作者，往往是自願承擔這類非正式支援角色，因為他們有內在的幫助慾望。 雖然這是一種非正式的支持模式，但絕不應被低估。 有些估計顯示，工作中很大比例的學習來自同儕學習，這對於正在打造領域特定分析解決方案的分析師尤其有幫助。

備註

團隊內部支援對於部門中唯一的資料分析師來說並不理想。 對於組織中尚未有太多人脈的人來說，這也無效。 當沒有親密的同事可依靠時，本文所述的其他支持類型就變得更為重要。

內部社群支援

來自社群成員的協助，通常以討論頻道或專為 實務社群設立的論壇形式出現。 舉例來說，有人發訊息說他們在 DAX 計算上遇到困難，或是在找合適的 Python 模組來匯入。 接著他們會收到組織內某人的回覆，提供建議或連結。

小提示

內部 Fabric 社群的目標是自我維持，這能降低正式支援的需求與成本。 它也能促進在更廣泛範圍內進行的管理式自助內容創作，而非純粹集中式的方式。 然而，監督、管理和培育內部社群的需求始終存在。 以下是兩個具體建議：

• 務必培養多位在較困難主題如 T-SQL、 Python、 資料分析壓縮（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 文件。 這是一個權威資源，可以幫助排除故障並搜尋資訊。 你可以優先考慮來自文件網站的結果。 例如，在您的網路搜尋引擎中輸入一個針對網站的搜尋請求，例如 power bi gateway site:learn.microsoft.com。

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

授權使用者有資格 向 Microsoft 提交支援工單。

小提示

向你的內部使用者社群明確表示，你是否希望技術問題被回報給內部客服。 如果你的客服台能處理這些工作量，設立一個集中式的內部區域收集用戶問題，能提供比每個用戶各自解決問題更優越的使用者體驗。 具備透明度並能夠分析支援問題的能力對 COE 也很有幫助。

管理員支援

Fabric 管理員有多種支援選項可供選擇。

對於擁有 Microsoft 統一支援 合約的客戶，請考慮授權客服台及 COE 成員使用 Microsoft Services Hub。 Microsoft Services Hub 的一大優點是，您的客服台與 COE 成員可以設定提交 並查看支援請求。

全球社群支持

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

當問題可以被不具備領域知識的人輕易理解，並且不涉及機密資料或敏感內部流程時，全球社群非常有用。

公開社群論壇

有多個 公開的社群論壇 ，使用者可以在這裡發表問題並獲得全球任何用戶的回應。 從任何人、任何地方獲得答案，都非常有力量且非常有幫助。 然而，和任何公開論壇一樣，驗證論壇上發布的建議和資訊非常重要。 網路上發布的建議可能不適合你的情況。

公開討論區

在社群媒體平台上，常常看到有人發表 Fabric 技術問題。 你可能會看到討論、公告發布，以及用戶互相幫助。

社群文件

Fabric 全球社群充滿活力。 每天都有大量的 Fabric 部落格文章、文章、網路研討會和影片被發布。 在依賴社群資訊進行故障排除時，請注意：

• 這些資訊是多麼新穎。 試著確認它發布或最後更新的時間。
• 你在線上找到的解決方案是否真的適合你的情境。
• 所呈現資訊的可信度。 依靠有信譽的部落格和網站。

注意事項和關鍵措施

檢查清單 ——以下是你可以採取的使用者支援考量與關鍵行動。

提升團隊內部支持：

• 提供認可與鼓勵：如 實務社群 文章中所述，提供激勵措施給你的推動者。
• 獎勵努力：當你看到有意義的基層努力時，要表揚並讚揚。
• 建立正式角色：如果非正式的團隊內部努力不足，可以考慮將你想在此領域中扮演的角色正式化。 在適當的時候，請在人力資源職務說明中包含預期的貢獻與責任。

提升你內部社群的支持：

• 持續鼓勵提問：鼓勵用戶在指定的社群討論頻道提問。 隨著習慣逐漸累積，將此作為第一選擇會變得很正常。 隨著時間推移，它會演變成更自給自足的狀態。
• 積極監控討論區：確保適當的 COE 成員積極關注此討論頻道。 如果問題仍未得到解答，他們可以介入、改進答案或在適當時進行更正。 他們還可以張貼其他資訊的連結，以提高對現有資源的認識。 雖然社群的目標是自給自足，但仍需專屬資源來監控與培育。
• 溝通可用選項：確保你的用戶群知道內部社群支援區的存在。 它可能包括顯著的連結展示。 你可以在定期與使用者社群的溝通中附上連結。 你也可以自訂 Fabric 入口網站中的 說明選單連結 ，引導使用者前往你的內部資源。
• 設定自動化：確保所有有授權的使用者都能自動存取社群討論頻道。 透過群組 授權，可以自動化授權設定。

提升內部客服支援：

• 確定客服台的職責：決定客服台將處理的 Fabric 支援主題的初始範圍。
• 評估準備程度：判斷您的客服中心是否準備好處理 Fabric 支援。 辨識是否存在需要解決的準備缺口。
• 安排額外培訓：舉辦知識轉移課程或培訓課程，以準備客服人員。
• 更新客服資料庫：將已知的問題與答案納入可搜尋的知識庫。 確保有人負責定期更新知識庫，以反映隨時間更新新功能與增強功能。
• 建立工單追蹤系統：確保有良好的系統來追蹤提交給客服的請求。
• 決定是否有人會因 Fabric 相關問題待命：如適用，確保對 24/7 支援的期望明確。
• 確定將存在哪些服務等級協議（SLA）：當有特定的服務水準協議（SLA）存在時，請確保對回應與解決的期望被清楚記錄並傳達。
• 準備迅速行動：準備好迅速處理特定常見問題。 支援回應緩慢會導致使用者找到解決方法。

提升內部 COE 延伸支援：

• 確定升級支援的運作方式：決定客服無法直接處理的請求的升級路徑。 確保COE（或同等人員）在需要時能隨時介入。 明確界定客服台職責的結束與 COE 延伸支援職責的起點。
• 鼓勵 COE 與系統管理員之間的協作：確保 COE 成員與 Fabric 管理員有直接升級管道，能直接聯繫 Microsoft 365 與 Azure 的全球管理員。 當出現超出 Fabric 範圍的廣泛問題時，擁有溝通管道至關重要。
• 建立一個回饋循環，從 COE 回饋到客服台：當 COE 得知新資訊時，應更新 IT 知識庫。 目標是讓主要客服人員未來能持續提升處理更多問題的能力。
• 建立從客服台到核心中心的回饋循環：當支援人員發現冗餘或效率低下時，可以將資訊傳達給核心中心，中心可能會選擇改善知識庫或介入（尤其是與治理或安全相關的）。

要思考的問題

請使用以下這些問題來評估使用者支持度。

• 誰負責支援企業資料與商業智慧解決方案？ 自助服務方案呢？
• 如何識別出問題的業務影響與緊迫性，以有效偵測並優先處理關鍵問題？
• 是否有明確的流程讓商業用戶能夠回報資料與商業智慧解決方案的問題？ 企業級和自助式解決方案之間有什麼不同？ 升級的路徑是什麼？
• 內容創作者和消費者通常會遇到哪些類型的問題？ 例如，他們是否會遇到資料品質問題、效能問題、存取問題等問題？
• 有沒有未解決便被關閉的問題？ 現在的資料項目或報告中有「已知問題」嗎？
• 是否有流程允許資料資產擁有者將自助商業智能解決方案的問題反映給如同 COE 這樣的中央團隊？
• 資料和現有解決方案中出現的問題頻率如何？ 這些問題中有多少比例是在影響業務終端用戶之前被發現的？
• 通常問題需要多久才能解決？ 這個時機對商業用戶來說足夠嗎？
• 近期問題的具體例子是什麼？這些問題對企業有具體影響？
• 企業團隊和內容創作者知道如何向 Microsoft 回報 Fabric 問題嗎？ 企業團隊能否有效運用社群資源來解構關鍵問題？

謹慎

在評估使用者支援並描述風險或問題時，請謹慎使用中立的語言，避免將責任歸咎於個人或團隊。 確保每個人的觀點在評估中都能被公平呈現。 專注於客觀事實，以準確理解並描述背景。

成熟度層級

以下的成熟度等級將幫助你評估 Power BI 使用者支援的現況。

Level	使用者支援狀態
100：初始	• 各業務單位尋找有效的方式互相支持。 然而，這些策略和做法分散且不一致。 • 提供內部討論頻道。 不過，這並沒有被嚴格監控。 因此，使用者體驗不一致。
200：可重複	• COE積極鼓勵團隊內部支持及冠軍網絡的成長。 • 內部討論頻道逐漸受到關注。 它已成為提問與討論的預設場所。 • 客服台處理少數最常見的技術支援問題。
300：已定義	• 內部討論頻道受歡迎且大致自給自足。 COE 積極監控並管理討論頻道，確保所有問題都能快速且正確地回答。 • 設有客服追蹤系統，監控支援頻率、回應主題及優先事項。 • 中心在需要時提供適當的延伸支援。
400：能力	• 客服中心受過完整訓練，能處理更多已知及預期的技術支援問題。 • SLA已制定，定義客服支援的期望，包括延伸支援。 期望事項會被記錄並溝通，讓所有相關人員都能清楚知道。
500：高效率	• 客服台與 COE 之間存在雙向回饋迴路。 • 關鍵績效指標衡量滿意度與支持方式。 • 自動化系統已實施，使客服能更快反應並減少錯誤（例如使用API與腳本）。

相關內容

在 Microsoft Fabric 採用路線圖系列的 下一篇文章 中，將了解系統監督與管理活動。