使用者支援：持續的生產解決方案支援
以下章節將介紹 Microsoft Power Platform 解決方案 (例如應用程式、流程和聊天機器人) 支援使用者的正式和非正式方式。
此圖顯示組織成功採用的一般支援與升級架構：
| 輸入 | 描述 |
|---|---|
 |
當製作者支援自己的解決方案時，會出現自支援 (內部)。 解決方案的使用者知道要與製作者聯絡以取得支援，且 IT 或團隊通常無法了解製作者提供的支援等級或類型。 |
 |
當團隊成員在開發 解決方案時相互學習時，就會出現團隊輔助支援 (內部)。 Power Platform 團隊成員成為其團隊應用程式、流程和聊天機器人的共同負責人。 共同負責人可以支援使用者查詢，並可進行小型錯誤修正和變更。 雖然團隊協助支援有時是非正式的，但隨著您的採用和逐漸成長，將這個過程正式化會是一個好主意。 |
 |
技術支援（internal） 處理正式的支持問題和請求。 技術支援中心可能有助於解決問題，例如如何在行動裝置上存取應用程式，或如何要求存取後端資料來源的存取權。 他們會將與解決方案相關的問題重新導向至支援解決方案的管道。 |
 |
專門 Power Platform 支援（內部） 涉及處理由説明臺上報的複雜問題。 關鍵應用程式會移交給此團隊，他們能部署錯誤修復。 |
 |
合作夥伴支援（外部） 可以補充您的內部支援服務，並支援關鍵應用程式或與特定部門合作支援他們的應用程式。 深入了解：從 Power Apps合作夥伴取得專家協助 |
 |
Microsoft support（external） 可用於提出與平臺相關的技術問題。 根據您的支援方案，您可以使用不同的技術支援和諮詢服務。 深入了解：Microsoft Power Platform 的支援 |
根據您組織的規模以及低程式碼和專業程式碼技術的現有交付方法，您可能會選擇不同的方式來正式化您的支援。 如果您的 Power Platform 採用方式大部分是分散的方式，您將擁有跨組織的自治團隊來交付和控管 Power Platform 解決方案。 藉由這種模型，您也可以委派支援，而團隊協助支援可能是與使用者和製作者最相關的服務。
如果您的 Power Platform 採用方式大部分是集中的方式，您將擁有由產品負責人組成的中心團隊，他們擁有來自組織業務單位之部門解決方案的低程式碼交付。 藉由此模型，支援也將集中化，且會有中心支援團隊會回答查詢和問題。
在大多數組織中，混合交付模式是最好的，即使分散的團隊為其製作者提供解決方案，但技術問題、使用者查詢和第一層支援可能仍需要技術支援中心和中心支援團隊。
定義應用程式層級
當定義支援流程和升級路徑時，必須根據重要程度來分類解決方案，這能讓您設計程序，確保關鍵應用程式有必要的護欄來支援它們，又不會扼殺生產力案例創新。
| 特性和過程 | 生產力 | 重要 | 危急 |
|---|---|---|---|
| 用例 | 可能使用現有資料的個人生產力和小型團隊使用案例。 | 簡單的業務應用程式或團隊計劃。 小型獨立協作程序。 | 複雜的業務應用程式、企業級的計劃或任務關鍵性工作負載，會在停機期間對業務產生重大影響。 |
| 複雜性 | 簡單的程序。 | 中複雜度。 | 高複雜度。 |
| 使用者群 | 小型使用者群 – 個人使用者、直接同事或小型團隊。 | 適用於業務單位。 | 大型使用者群或企業級使用方式。 |
| 開發生命週期 | 高等級的反覆運算。 | 通常開發時間不到三個月。 | 更長的開發週期。 |
| 衝擊 | 業務影響小。 | 重要但不是業務關鍵 (中等影響)。 | 高業務影響。 |
| ALM | 不需要 ALM。 | 需要 ALM - 且可以透過手動解決方案匯入/匯入來達成。 | 需要強大的 ALM 程序 - ALM 是使用 Azure DevOps 或 GitHub 管線達成的。 |
| 環境策略 | 解決方案內建於預設或共用生產力環境中。 | 專用的開發環境，以及共用的測試和生產環境 (與其他解決方案共用，例如特定業務單位的解決方案)。 環境由業務單位 (分散) 或中心 IT (集中) 管理。 | 專用的開發/測試/生產環境。 環境由中心 IT 管理。 |
| 製作者許可權 | 製作者在環境中具有環境製作者資訊安全角色。 | 製作者在開發環境中具有環境製作者或系統自訂員資訊安全角色，但在測試和生產環境中僅具有終端使用者資訊安全角色。 解決方案可能由測試和生產中的服務帳戶或環境管理員擁有。 | 製作者在開發環境中具有環境製作者或系統自訂員資訊安全角色，但在測試和生產環境中僅具有使用者資訊安全角色。 解決方案部署會自動進行，解決方案由測試和生產中的服務主體擁有。 |
| IT 參與 | 反應式控款 - IT 可以看到正在組建的解決方案並監視使用情況。 | 解決方案或使用者等級的 IT 祝福。 製作者會提供解決方案詳細資料，例如潛在的解決方法和使用的資料來源。 | 生產環境由 IT 管理。 |
| 支援模型 | 自我支援。 | 團隊協助支援。 | 正式支援。 |
在定義支援模型時，也要考慮升級路，解決方案一開始可能只需要生產力等級的支援，但隨著功能或使用者群的增長，就會需要重要等級的支援。 定義製作者如何要求更正式的支援，並將解決方案轉換至支援的環境。
本文將詳細描述上述每一種使用者支援類型。
製作者支援 (自我支援)
製作者支援是指製作者支援自己的應用程式，和為自己、團隊或同事組建的流程。 這代表要回答使用者的查詢、修復錯誤和提出變更要求。 這是一種非正式的支援方式；使用者通常會知道製作者是誰，且會直接連絡他們。
重要
作為新製作者上線的一部分，請確保製作者了解支援、升級和升級路徑，因重要的業務解決方案支援而負擔過重的製作者將無法再創新和建立新的解決方案。 清楚地定義製作者如何將其解決方案升級到下一個等級的支援，並了解支援的情況。
除了這種主動與製作者溝通流程的方式之外，還要確保您有反應式控管，以找出對業務而言至關重要的高度共用和高度使用的解決方案，並連絡製作者以確保這些解決方案具有必要的支援護欄。 使用租用戶等級分析來了解應用程式使用情況的更多資訊，將遙測資料匯出至您自己的資料存儲體帳戶以組建自己的增強報表，或把 CoE 入門套件作為起點。
團隊協助支援
團隊協助支持是指團隊成員共同擁有為其團隊組建或由團隊使用的應用程式和流程，並在日常工作中協助支援解決方案。 這代表要回答使用者的查詢、修復錯誤和提出變更要求。 成為您的支持者的製作者傾向於自願承擔這種非正式的支援角色，因為他們有提供幫助的內在動機。
雖然這一開始通常是非正式程序，但許多組織會將團隊協助支持正式化，以擴展他們的 Power Platform 工作。 這涉及擁有其專用環境的業務單位，承擔環境管理員角色並在這些環境中支援解決方案。 在較大的組織中，每個業務單位都有專門的 Power Platform 團隊承擔此角色。
技術支援中心支援
IT 部門會將技術支援中心當做共用服務運作。
技術支援中心可以：
- 支援在沒有 IT 參與的情況下無法解決的技術問題，例如需要管理員在 Power Platform 系統管理中心中提交支援票證的 Power Platform 服務問。
- 回答使用者和控管相關的問題，例如如何要求存取應用程式，或在哪裡可以找到應用程式。
- 將關鍵應用程式的問題路由到正確的支援團隊。
專門的 Power Platform 支援小組
隨著採用的成長和製作者開發出更重要、更關鍵的業務解決方案，您可能需要專門的 Power Platform 支援小組。
此團隊應由能支援複雜問題的 Power Platform 技術專家組成。 應透過支援票證經定義的路徑來讓此團隊參與支援程序。
此團隊會將支援提供到專屬集中支援環境的關鍵任務 Power Platform 解決方案。
如果您的組織結構是分散的，您可能需要考慮將團隊協助支援正式化，以使其與本地區域或業務單位保持一致，而中心 Power Platform 支援小組僅幫助處理複雜的查詢或中心設定，例如 DLP 原則。
部分客戶會選擇將此等級的支援外包給合作夥伴。
由於這些 Power Platform 技術專家通常為商務使用者所熟知，因此將要求作為單純來自技術支援中心的升級路徑來管理變得很困難。 為了建立使用適當管道的習慣，此團隊應重新導向使用者以提交技術支援中心票證。 這也會改善分析技術支援中心要求的資料品質。
合作夥伴支援
許多客戶選擇與合作夥伴一起採用 Power Platform，包括支援。 這可以包括為製作者提供發展協助、幫助建立 CoE 和技術支援程序，以及對關鍵應用程式的全天候技術支援。
Microsoft 支援服務
Microsoft support 用於提出與平臺相關的技術問題。 根據您的支援方案，您可以使用不同的技術支援和諮詢服務。
小費
在提交支援票證之前，還要檢查 Power Apps 支援、 Power Automate 支持和支援 Microsoft Copilot Studio ，以解決廣泛影響所有客戶的高優先順序問題。
注意事項和關鍵措施
可用於改進自己和團隊協助支援解決方案的注意事項和關鍵措施：
- 認可並鼓勵您的製作者。
- 確保製作者了解升級程序，以便將他們的解決方案升級到更正式的支援管道。
- 為製作者提供辦公時間、指導機會、培訓課程，以繼續提高他們的技能。
- 為陷入困境的製作者提供連絡 Power Platform 技術專家的升級途徑。
- 為製作者建立包含在其應用程式中的範本元件，例如使用者連絡技術支援中心的表單。
- 根據工作負載和在特定業務領域需要支援的解決方案數量，評估正式的團隊協助支援。
可用於改進內部技術支援中心支援的注意事項和關鍵措施：
- 確定技術支援中心要處理的 Power Platform 主題初始範圍。
- 評估技術支援中心處理支援的整備程度。
- 根據整備程度的差距，為技術支援中心工作人員安排更多培訓內容。
- 確定技術支援中心無法直接處理之要求的升級路徑。
- 更新已知 Power Platform 主題的技術支援中心知識庫。 確保有人負責定期更新知識庫，以反映一段時間後的新功能和增強功能。 通過訂閱 Power Apps blog、 Power Automate blog 和 Microsoft Copilot Studio blog RSS feeds 來保持最新狀態。
- 確保建立良好的問題追蹤系統。 這通常是可以管理優先順序的票證系統。
- 確定是否有人隨時待命處理所有與 Power Platform 相關的問題。 如有需要，請確保能達成全天候支援。
- 確定會有哪些 SLA，並明確傳達對回覆和解決方案的期望。
- 做好準備，快速解決特定的常見問題。 例如，應快速處理使用新連接器的要求。 緩慢的支援回應可能會導致使用者尋找變通辦法。
- 確保您的説明台有一個資訊安全角色，允許他們 提出支援票證 Microsoft。 確定技術支援中心或專門的支援團隊是否會對這些問題進行分級。
可用於改進內部 Power Platform 專屬支援的注意事項和關鍵措施：
- 明確定義技術支援中心職責到哪裡結束，以及專屬支援職責從哪裡開始。
- 確保 Power Platform 專屬支援小組具有直接升級路徑來連絡 Microsoft 365 和 Azure 的全域管理員。 當出現超出 Power Platform 範圍的廣泛問題時，這就會非常重要。 這類問題可能與 Power Platform 解決方案中使用的使用者帳戶和權限、網路設定或資料來源有關。
- 建立從專屬支援小組到技術支援中心的意見反應迴圈，以便更新 IT 知識庫。 目標是要讓主要技術支援中心能更出色地持續處理未來的更多問題。
- 建立從技術支援中心到專門支援小組的意見反應迴圈。 當支援人員發現冗餘或效率低下時，他們可以將該資訊傳達給專屬支援小組，他們可能會選擇變更和改進內部流程。 範例：如果技術支援中心要建立和設定新的新 Power Platform 環境，則專屬團隊可能會考慮使用 CoE 入門套件中的環境要求管理元件自動化此程序。
- 建立從支援其解決方案的個人和團隊到專屬支援小組的升級路徑，這樣就算遇到無法自行解決的問題時，他們也可以暢行無阻。
- 建立從支持其解決方案的個人和團隊到專屬支援小組的移交路徑，以便轉換關鍵應用程式。
- 確定將解決方案轉換到專屬團隊的整體策略 - 隨著重要和關鍵解決方案數量增加，您是要增加專屬支援小組的人員，還是要讓業務單位增加其領域支援小組的人員？