Microsoft Fabric 採用藍圖：用戶支援

注意

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

本文說明用戶支援。 它主要著重於解決問題。

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

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

用戶支援的類型

如果用戶有問題，他們是否知道要解決的選項為何？

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

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

型別	說明
	小組內部支援（內部） 是非常非正式的。 當小組成員在工作的自然過程中相互學習時，就會發生支援。
	內部社區支持（內部） 可以非正式、正式或同時組織。 當同事通過內部社群管道相互交流時，就會發生。
	技術支援中心支援 (內部) 會處理正式的支援問題和要求。
	外延支援（內部） 牽涉到處理技術支持人員呈報的複雜問題。
	Microsoft 支援 （外部） 包含授權使用者和網狀架構系統管理員的支援。 它也包含 完整的檔。
	社群支援（外部） 包括全球專家社群、 Microsoft 最具價值專業人員（MPP）和參與論壇和發佈內容的愛好者。

在某些組織中，小組內部和內部社群支援與自助數據和商業智慧（BI）最相關—內容是由分散式業務單位中的建立者和擁有者所擁有和管理。 相反地，技術支援人員和擴充支援會保留給技術問題和企業數據和 BI（內容是由集中式 BI 小組或 卓越中心所擁有和管理）。 在某些組織中，所有四種類型的支援都與任何類型的內容有關。

提示

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

本文會進一步詳細說明上述六種用戶支持類型。

小組內部支援

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

注意

小組內部支援不適用於部門內唯一數據分析師的個人。 對於組織中還沒有非常多連線的人來說，這也不有效。 當沒有任何親密的同事相依時，如本文所述，其他類型的支援變得更加重要。

內部社群支援

來自您社群成員的協助通常採用討論頻道中的訊息形式，或專為 實踐社群設定的論壇。 例如，有人張貼訊息，指出他們有問題讓DAX計算能夠運作，或正在尋找要匯入的正確 Python 模組。 然後，他們會收到組織中有人提供建議或鏈接的回應。

提示

內部 Fabric 社群的目標是自我維持，這可能會導致正式支援需求和成本降低。 它也有助於在更廣泛的規模上建立受控自助內容，而不是純粹的集中式方法。 但是，您總會需要監視、管理和培養內部社群。 以下是兩個特定秘訣：

• 請務必在 T-SQL、Python、數據分析 eXpressions （DAX） 和 Power Query M 公式語言等較困難的主題中培養多個專家。 當社群成員成為公認的專家時，他們可能會因為太多請求而負擔過重。
• 許多社群成員可能會輕易回答特定類型的問題（例如報表視覺效果），而少數成員會回答其他問題（例如，複雜的 T-SQL 或 DAX）。 COE重要的是要讓社區有機會回應，但也願意及時處理未回答的問題。 如果使用者反覆詢問問題，且未收到答案，則會大幅阻礙社群的成長。 在此情況下，如果使用者未收到任何問題回應，則可能會離開，且永遠不會返回。

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

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

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

監視討論頻道也可以顯示其他分析專家和潛在冠軍，這些專家和以前對COE未知的擁護者。

重要

這是一個最佳做法，不斷識別新興的冠軍，並與他們接觸，以確保他們有能力支持他們的同事。 如練習社群文章所述，COE 應積極監視討論通道，以查看誰有説明。 COE 應刻意鼓勵和支援社群成員。 適當時，請他們加入冠軍網路。

討論頻道的另一個重要優點是可搜尋，可讓其他人探索資訊。 然而，人們在開放論壇上提出問題，而不是私人訊息或電子郵件，這是一種習慣的改變。 對一些個人不舒服以如此公開的方式提問的事實敏感。 它公開承認他們不知道什麼，這可能令人尷尬。 這種不願通過推廣友好、鼓勵和有用的討論管道，來縮短一段時間。

提示

您可能會想要建立 Bot 來處理社群中一些最常見的直接問題。 Bot 可以處理「如何? 要求授權？」或「如何? 要求工作區？」等不複雜問題在採用這種方法之前，請考慮是否有足夠的例程和可預測的問題，讓用戶體驗變得更好，而不是更糟。 通常，妥善建立的常見問題（常見問題）的運作效果更好，而且開發較容易且更容易維護。

技術支援中心支援

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

• 較不有經驗的使用者。
• 較新的組織。
• 不願向內部討論社群張貼資訊。
• 組織內缺少連線和同事。

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

忙碌的技術支援中心人員通常致力於支持多種技術。 因此，支援的最簡單問題類型是具有清楚解決方式且可記載於知識庫中的問題類型。 例如，取得授權的軟體安裝必要條件或需求。

某些組織會要求技術支持人員只處理非常簡單的中斷修正問題。 其他組織則讓技術支援中心參與任何可重複的工作，例如新的 工作區要求、管理 網關數據源，或要求新的容量。

重要

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

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

提示

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

外延支援

由於 COE 深入解析整個組織使用 Fabric 的方式，因此，如果發生複雜的問題，就適合延伸支援。 在支援程式中涉及 COE 應該是呈報路徑。

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

Microsoft 支援服務

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

Microsoft 檔

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

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

Power BI Pro 和 進階版 每位用戶支援

已授權的用戶有資格 向 Microsoft 記錄支援票證。

提示

請向內部使用者社群清楚說明您是否偏好將技術問題回報給內部技術支援中心。 如果您的技術支援中心能夠處理工作負載，則集中的內部區域收集用戶問題可以提供優越的用戶體驗，而每位嘗試自行解決問題的使用者。 擁有可見度和分析支援問題也有助於 COE。

管理員 istrator 支援

網狀架構系統管理員有數個可用的支持選項。

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

全球社群支援

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

當一個沒有領域知識的人可以輕鬆地理解問題，以及當問題不涉及機密數據或機密內部程式時，全球社群就很有用。

公開可用的社群論壇

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

公開可用的討論區域

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

社群檔

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

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

注意事項和關鍵措施

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

改善小組內部支援：

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

改善內部社群支援：

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

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

• 決定技術支援中心的責任： 決定技術支援人員將處理之 Fabric 支援主題的初始範圍。
• 評估整備程度層級： 判斷技術支援中心是否準備好處理網狀架構支援。 識別是否有要解決的整備差距。
• 安排其他訓練： 進行知識轉移課程或訓練課程，以準備技術支援中心人員。
• 更新技術支援中心知識庫： 在可搜尋的知識庫中包含已知問題和解答。 請確定有人負責定期更新知識庫，以反映一段時間的新功能和增強功能。
• 設定票證追蹤系統： 確定有良好的系統可追蹤提交至技術支援中心的要求。
• 決定是否有人會接聽任何與 Fabric 相關的問題： 如果適當的話，請確定對 24/7 支援的期望是明確的。
• 判斷 SLA 將存在什麼： 當特定服務等級協定 （SLA） 存在時，請確定已清楚記載並傳達回應和解決的期望。
• 做好快速行動的準備： 準備非常快速地解決特定常見問題。 支援回應緩慢會導致使用者找到因應措施。

改善內部 COE 擴充支援：

• 決定升級支持的運作方式： 決定技術支援人員無法直接處理的要求呈報路徑。 請確定 COE（或對等人員）已準備好在需要時介入。 明確定義技術支援中心責任的結束位置，以及 COE 延伸支援責任的開始位置。
• 鼓勵 COE 與系統管理員之間的共同作業： 確定 COE 成員和網狀架構系統管理員具有直接呈報路徑，可連線到 Microsoft 365 和 Azure 的全域管理員。 當發生超出 Fabric 範圍的普遍問題時，必須有通道。
• 從 COE 回到技術支援中心建立意見反應迴圈： 當 COE 瞭解新資訊時，應該更新 IT 知識庫。 目標是讓主要技術支援人員在未來處理更多問題時，不斷變得更有能力處理更多問題。
• 從技術支持人員到 COE 建立意見反應迴圈： 當支援人員觀察備援或效率低下時，他們可以將該資訊傳達給 COE，他們可能會選擇改善知識庫或參與其中（特別是與治理或安全性相關）。

要思考的問題

使用如下找到的問題來評估用戶支援。

• 神秘 負責支援企業數據和 BI 解決方案？ 自助解決方案呢？
• 識別出問題的業務影響和緊迫性如何有效偵測並排定重大問題的優先順序？
• 商務使用者是否有明確的程式可報告數據和 BI 解決方案的問題？ 企業與自助解決方案之間的差異為何？ 什麼是呈報路徑？
• 內容建立者和取用者通常會經歷哪些類型的問題？ 例如，他們遇到數據質量問題、效能問題、存取問題和其他問題嗎？
• 沒有任何問題已關閉，而不會解決嗎？ 數據項或報表目前是否有「已知問題」？
• 數據資產擁有者是否能夠將自助 BI 解決方案的問題呈報給 COE 等中央小組的程式？
• 數據和現有解決方案中的問題有多頻繁？ 在影響商務終端使用者之前，發現這些問題的比例為何？
• 解決問題通常需要多久的時間？ 此時間是否足以讓商務使用者使用？
• 最近的問題和對企業的具體影響有哪些範例？
• 企業小組和內容建立者是否知道如何向 Microsoft 回報網狀架構問題？ 企業小組是否可以有效地利用社群資源來解除封鎖重大問題？

警告

評估用戶支援並描述風險或問題時，請小心使用不會對個人或小組造成責任的中性語言。 請確定每個人的觀點在評量中都相當代表。 專注於客觀事實，以準確瞭解和描述內容。

成熟度等級

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

等級	用戶支援的狀態
100：初始	• 個別業務單位尋找相互支援的有效方式。 不過，策略和做法是孤立的，而且不會一致地套用。 • 有內部討論頻道可供使用。 不過，不會密切監視。 因此，用戶體驗不一致。
200：可重複	• COE 積極鼓勵小組內部支持和冠軍網路的成長。 • 內部討論通道獲得牽引力。 它被稱為問題與討論的預設位置。 • 技術支援中心會處理少數最常見的技術支持問題。
300：已定義	• 內部討論管道很受歡迎，基本上是自我維持。 COE 會主動監視及管理討論通道，以確保所有問題都能快速且正確回答。 • 技術支援中心追蹤系統已就緒，可監視支援頻率、回應主題和優先順序。 • COE 會在需要時提供適當的擴充支援。
400：能力	• 技術支援中心經過完整訓練，並準備處理更廣泛的已知和預期的技術支持問題。 • SLA 已就緒，可定義技術支援中心支援期望，包括外延支援。 期望會記錄並傳達，以便向參與的每個人清楚。
500：高效率	• 技術支援中心與 COE 之間存在雙向意見反應迴圈。 • 關鍵效能指標會測量滿意度和支援方法。 • 自動化已就緒，可讓技術支持人員更快回應並減少錯誤（例如，使用 API 和腳本）。

相關內容

在 Microsoft Fabric 採用藍圖系列中的 下一篇文章 中，瞭解系統監督和管理活動。