注释
本文是 Microsoft Fabric 采用路线图系列文章的一部分。 有关该系列文章的概述，请参阅 Microsoft Fabric 采用路线图。
本文介绍用户支持。 它主要侧重于解决问题。
本文的第一部分重点介绍您在组织内部可以控制的用户支持方面。 最终主题侧重于可用的外部资源。
有关相关主题的说明，包括向内部 Fabric 用户社区提供的技能指导、培训、文档和共同开发帮助，请参阅 指导和用户启用 文章。 这些活动的有效性可以显著减少正式用户支持请求的数量，并增加整体用户体验。
用户支持类型
如果用户有问题，他们是否知道有哪些选项来解决问题？
下图显示了组织成功使用的一些常见用户支持类型：
上图中显示的六种类型的用户支持包括：
| 类型 | Description |
|---|---|
|
团队内部支持（内部） 非常非正式。 在团队成员在日常工作中相互学习时，便能得到支持。 |
|
内部社区支持（内部） 可以非正式、正式或同时进行组织。 当同事通过内部社区渠道相互交互时，会发生这种情况。 |
|
帮助台支持（内部） 处理正式的支持问题和请求。 |
|
扩展支持（内部） 指处理由服务台升级的复杂问题。 |
|
Microsoft支持（外部） 包括对许可用户和 Fabric 管理员的支持。 它还包括 全面的文档。 |
|
社区支持（外部） 包括全球专家社区、 Microsoft最有价值的专业人士（MVP）和参与论坛和发布内容的爱好者。 |
在某些组织中，团队内部和社区支持与自助服务数据和商业智能（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 应刻意鼓励和支持社区成员。 如果合适，请他们加入冠军网络。
讨论渠道的另一个关键好处是可搜索，这使其他人能够发现信息。 然而，这是人们在开放论坛而不是私人邮件或电子邮件中提问的习惯改变。 对于一些人来说，他们不习惯以如此公开的方式提问，请对此保持敏感。 它公开承认他们不知道的内容，这可能很尴尬。 随着时间的推移，通过促进友好、鼓励和有帮助的讨论渠道，这种不愿可能会减少。
小窍门
你可能想创建一个机器人来处理社区中一些最常见的直接问题。 机器人可以处理未复杂的问题，例如“如何请求许可证？”或“如何请求工作区？”在采用此方法之前，请考虑是否存在足够的例程和可预测的问题，以使用户体验变得更好，而不是更糟。 通常，一个精心创建的常见问题解答（常见问题解答）效果更好，开发速度更快，维护更简单。
帮助中心支持
技术支持通常作为共享服务运营，由 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 Services Hub 的访问权限。 Microsoft服务中心的一个优点是，可以设置技术支持和 COE 成员来 提交和查看支持请求。
全球社区支持
除了本文中所述的内部用户支持方法，以及前面所述的Microsoft支持选项，还可以利用全球 Fabric 社区。
当一个没有域知识的人可以轻松理解问题时，以及它不涉及机密数据或敏感的内部流程时，全球社区非常有用。
公开可用的社区论坛
有几个 公共社区论坛 ，用户可以发布问题，并接收来自世界上任何用户的回复。 无论何时何地获得他人的答案都非常有力且有益。 但是，与任何公共论坛一样，验证论坛上发布的建议和信息非常重要。 在 Internet 上发布的建议可能不适合你的情况。
公开可用的讨论区域
人们经常在社交媒体平台上发布 Fabric 技术问题。 你可能会发现讨论、发布公告和用户互相帮助。
社区文档
Fabric 全球社区充满活力。 每天都会发布大量 Fabric 博客文章、文章、网络研讨会和视频。 依赖社区信息进行故障排除时，请注意：
- 信息的最近程度。 尝试验证它何时发布或上次更新。
- 在线找到的解决方案的情况和上下文是否真正符合你的情况。
- 正在提供的信息的可信度。 依赖于信誉良好的博客和网站。
注意事项和关键措施
清单 - 可供用户支持参考的注意事项和可执行的关键动作。
改进团队内部支持：
- 提供认可和鼓励：根据 社区实践 文章中所述，为冠军提供奖励。
- 奖励努力：识别并赞扬有意义的基层努力，当你看到这些努力发生时。
- 创建正式角色：如果非正式团队内部工作不够充分，请考虑将想要在此领域制定的角色正式化。 在适当情况下，在 HR 工作说明中包括预期的贡献和职责。
改进内部社区支持：
- 不断鼓励问题：鼓励用户在指定的社区讨论渠道中提问。 随着习惯的形成，这将逐渐成为首选选项。 随着时间的推移，它将逐渐演变为更加自给自足。
- 主动监视讨论区域：确保适当的 COE 成员积极监视此讨论渠道。 如果问题仍未得到解答，他们可以介入、改进答案或在适当时进行更正。 他们还可以发布指向其他信息的链接，以提高对现有资源的认知。 虽然社区的目标是成为自我支持，但它仍然需要专门的资源来监视和培养它。
- 可用的通信选项：确保用户群体知道内部社区支持区域存在。 它可能包括链接的突出显示。 可以在定期与用户社区通信中包括链接。 还可以自定义 Fabric 门户中 的帮助菜单链接 ，以将用户定向到内部资源。
- 设置自动化：确保所有许可用户都自动有权访问社区讨论频道。 可以使用 基于组的许可自动设置许可证。
改进内部技术支持支持：
- 确定技术支持职责：确定技术支持将处理哪些 Fabric 支持主题的初始范围。
- 评估就绪级别：确定您的帮助台是否准备好处理 Fabric 支持。 确定是否存在要解决的就绪性差距。
- 安排其他培训：进行知识转移课程或培训课程，以准备技术支持人员。
- 更新技术支持知识库：在可搜索知识库中包含已知问题和答案。 确保某人负责定期更新知识库，以反映一段时间内新增和增强的功能。
- 设置票证跟踪系统：确保建立良好的系统来跟踪提交到技术支持的请求。
- 确定是否有人将就与 Fabric 相关的任何问题进行呼叫：如果合适，请确保对 24/7 支持的期望是明确的。
- 确定将存在哪些 SLA：当存在特定的服务级别协议（SLA）时，请确保明确记录和传达响应和解决的预期。
- 做好快速行动准备：准备非常迅速地解决特定常见问题。 支持响应缓慢将导致用户找到解决方法。
改进内部 COE 扩展支持：
- 确定升级的支持将如何工作：确定技术支持无法直接处理的请求的升级路径。 确保 COE（或等效人员）已准备好在需要时介入。 明确定义技术支持职责的结束位置，以及 COE 扩展支持责任的开始位置。
- 鼓励 COE 与系统管理员之间的协作：确保 COE 成员和 Fabric 管理员具有直接升级路径，以便访问 Microsoft 365 和 Azure 的全局管理员。 当出现超出 Fabric 范围的普遍问题时，必须有一个沟通渠道。
- 从 COE 创建反馈循环回到帮助台：当 COE 了解新信息时，应更新 IT 知识库。 目标是使主要技术支持人员在将来处理更多问题方面不断变得更有能力。
- 从技术支持到 COE 创建反馈循环：当支持人员观察冗余或效率低下时，他们可以将这些信息传达给 COE，他们可能会选择改进知识库或参与（特别是如果它与治理或安全相关）。
应考虑的问题
使用下面找到的问题来评估用户支持。
- 谁负责支持企业数据和 BI 解决方案？ 自助服务解决方案呢？
- 有效识别并检测和优先处理关键问题的业务影响和紧迫性是如何确定的？
- 业务用户是否有明确的流程来报告数据和 BI 解决方案的问题？ 企业解决方案与自助服务解决方案之间有何不同？ 什么是升级路径？
- 内容创建者和使用者通常会遇到哪些类型的问题？ 例如，它们是否遇到数据质量问题、性能问题、访问问题和其他问题？
- 是否有任何问题在尚未解决的情况下被关闭？ 数据项或报表中是否存在“已知问题”？
- 数据资产所有者是否有一个流程来将自助式 BI 解决方案中的问题上报给中心团队（如 COE）？
- 数据和现有解决方案中的问题有多频繁？ 在影响业务最终用户之前发现这些问题的比例是多少？
- 解决问题通常需要多长时间？ 此时间安排是否足够适合业务用户？
- 最近的问题和对业务的具体影响有哪些示例？
- 企业团队和内容创建者是否知道如何向Microsoft报告 Fabric 问题？ 企业团队能否有效地利用社区资源来解除阻止关键问题？
注意
评估用户支持并描述风险或问题时，请小心使用不对个人或团队负责的中性语言。 确保在评估中公平地呈现每个人的观点。 专注于客观事实，准确理解和描述上下文。
成熟度级别
以下成熟度级别将帮助你评估 Power BI 用户支持的当前状态。
| 级别 | 用户支持的状态 |
|---|---|
| 100：初始 | • 单个业务部门找到相互支持的有效方法。 但是，策略和做法是孤立的，而不是一致的应用。 • 提供了内部讨论渠道。 但是，不会密切监视它。 因此，用户体验不一致。 |
| 200：可重复 | • COE 积极鼓励团队内部支持和冠军网络的发展。 • 内部讨论渠道受到更多关注。 它被称为问题和讨论的默认位置。 • 技术支持处理少量最常见的技术支持问题。 |
| 300：已定义 | • 内部讨论渠道很受欢迎，基本上是自我维持的。 COE 主动监视和管理讨论渠道，以确保所有问题都快速正确回答。 • 支持人员跟踪系统已到位，用于监视支持频率、响应主题和优先级。 • COE 在需要时提供适当的扩展支持。 |
| 400：有能力 | • 支持人员经过全面培训，并准备处理更广泛的已知和预期的技术支持问题。 • SLA 已到位，用于定义技术支持支持预期，包括扩展支持。 期望被记录并传达，以便每个参与者都清楚这些期望。 |
| 500：高效 | • 技术支持和 COE 之间存在双向反馈循环。 • 关键绩效指标衡量满意度和支持方法。 • 自动化已到位，使技术支持能够更快地做出反应并减少错误（例如，使用 API 和脚本）。 |
相关内容
在 Microsoft Fabric 采用路线图系列 中的下一篇文章 中，了解系统监督和管理活动。