Microsoft Fabric 采用路线图：卓越中心

  • 项目

注意

本文是 Microsoft Fabric 采用路线图系列文章的一部分。 有关该系列文章的概述，请参阅 Microsoft Fabric 采用路线图。

数据或分析卓越中心 (COE) 是由技术和业务专家组成的内部团队。 该团队将积极协助组织内处理和使用数据的其他人。 COE 构成了一个更大规模社区的核心，旨在推进实现与数据文化愿景一致的采用目标。

COE 也称为资质中心、功能中心或专家中心。 一些组织会使用“小分队”这个术语。 许多组织通过其数据、分析或商业智能 (BI) 团队行使 COE 职责。

注意

建议在组织结构图中正式确立 COE 团队，但这不是必需的。 最重要的是确定 COE 角色和职责、对权限分级并进行分配。 中央数据或分析团队通常会承担许多 COE 职责；一些职责也可能由 IT 团队行使。 为简单起见，在此系列文章中，COE 指“特定一组人员”，但也可以采用不同方式来实现该职责。 实现范围超出 Fabric 或 Power BI 自身的 COE 也很常见：例如 Power Platform COE、数据 COE 或分析 COE。

COE 的目标

COE 的目标包括：

  • 宣传数据驱动的文化。
  • 促进分析的采用。
  • 培养、启导、指导、和教育内部用户，提高其技能和独立完成任务的能力。
  • 协调工作并跨组织边界传播知识。
  • 为用户社区创建一致性和透明性，这可减少与相关数据和分析内容的查找相关的分歧和难点。
  • 最大限度地提高自助式 BI 的优势，同时降低风险。
  • 通过帮助用户做出提高一致性和减少低效的良好决策来减少技术债务。

重要

COE 最强大的方面之一是跨部门深入了解组织如何使用 Fabric 等分析工具。 由此获取的相关见解可以揭示哪些做法有效，哪些不可行，这可以推进自下而上的治理方法。 COE 的主要目标是了解哪种做法非常有效、广泛共享这一信息和跨组织复制最佳做法。

COE 职责范围

不同组织的 COE 职责范围可能会有很大差异。 在某种程度上，可将 COE 视为一项咨询服务，因为团队成员会例行向用户内部社区提供专家建议。 大多数 COE 也处理实际工作，只是处理的量会有所不同。

常见的 COE 职责包括：

为 COE 配备人员

好的 COE 成员候选人往往具备以下特征：

  • 了解组织的分析愿景。
  • 希望持续改进组织的分析做法。
  • 对 Fabric 等分析工具抱有浓厚兴趣并具有该方面的专业知识。
  • 对在整个组织中有效使用和成功采用 Fabric 深感兴趣。
  • 主动持续学习、适应和成长。
  • 乐于与他人分享自己的知识。
  • 对可重复流程、标准化和治理感兴趣，且重点关注用户支持。
  • 热切专注于与他人的协作。
  • 很适应敏捷的工作方式。
  • 在参与协作和帮助他人方面有着天然的兴趣。
  • 能有效将业务需求转换为解决方案。
  • 与技术和业务同事保持良好沟通。

提示

如果你所在组织中的自助服务创建者不断突破可实现目标的边界，他们可能就是公认的冠军最佳候选人，或者甚至可能成为 COE 的外围成员。

聘用 COE 人员时，应确保这些人员同时具备互补的分析技能、技术技能和业务技能。

角色和职责

下面列出了 COE 中的常规角色。 许多人存在职能重叠是很常见的，这在备份和交叉培训方面非常有用。 同一人员具有多个职能也很常见。 例如，大多数 COE 成员还担任指导员或导师。

角色 说明
COE 领导 管理 COE 的日常运营。 必要时与执行倡导人和其他组织团队（如数据治理委员会）沟通交流。 有关其他角色和职责的概述，请参阅《治理》一文。
指导员 通过办公时间（社区参与）、最佳做法评审或联合式开发项目为其他人提供有关数据和 BI 技能的指导和教育。 监督并参与内部社区的讨论渠道。 与冠军网络交流并提供支持。
培训师 开发、策划并提供内部培训资料、文档和资源。
数据分析师 特定于领域的主题专家。 充当 COE 与业务单位之间的联络人。 业务单位的内容创建者。 协助内容认证。 参与共同开发项目和概念证明相关事务。
数据建模工程师 创建和管理数据资产（例如之前称为数据集的共享语义模型和数据流），以支持其他自助服务内容创建者。
报表创建者 创建和发布报表、仪表板和指标。
数据工程师 规划部署和体系结构，包括与其他服务和数据平台的集成。 发布在整个组织中广泛使用的数据资产（如湖屋、数据仓库、数据管道、数据流或语义模型）。
用户支持 协助解决数据差异问题和升级的技术支持问题。

如前文所述，COE 的职责范围在组织间可能会有很大差异。 因此，为 COE 成员确定的角色也会有所不同。

构建 COE 架构

选定的 COE 架构因组织而异。 单个大型组织内也可能存在多个结构。 当存在子公司或发生收购时，情况尤其如此。

注意

以下术语可能不同于为组织定义的术语，尤其是术语“联合”的含义，它往往有许多其他与 IT 相关的含义。

中央 COE

集中式 COE 由一个共享服务团队组成。

优点：

  • 由单个团队集中管理标准、最佳做法和端到端交付，有一个集中的问责点。
  • 从组织架构图的角度来看，COE 是一个团队。
  • 使用这种模式很容易展开和推进业务，之后可以逐渐过渡为统筹式或联合模式。

缺点：

  • 中央团队可能会有专权倾向，更偏好一刀切的决策制定模式，而这种模式并不总是对所有业务单位都有好的效果。
  • 可能会倾向于发展 IT 技能，而非业务技能。
  • 由于其中央特性，COE 成员可能难以充分了解所有业务单位的需求。

统筹式 COE

统筹 COE 是一个集中式共享服务团队，其规模已扩展为包含了嵌入式团队成员。 嵌入式团队成员专职为特定功能领域或业务单位提供支持。

优点：

  • 单个团队职能中包括了嵌入式 COE 团队成员的跨职能参与，有一个集中的问责点。 将嵌入式 COE 团队成员分配到各个业务领域。
  • 从组织架构图的角度来看，COE 是一个团队。
  • 得益于具有领域专业知识的专用成员，COE 能够更深入了解各业务单位的需求。

缺点：

  • 专职于特定业务单位的嵌入式 COE 团队成员的组织架构图职责与他们在业务单位内服务的人员不同。 组织结构可能会导致复杂性、优先级差异，或者需要管理层倡导者的参与。 理想情况是执行倡导人的权限范围涵盖了 COE 和所有涉及的业务单位，以帮助解决冲突。

联合式 COE

联合式 COE 由共享服务团队成员（核心 COE 成员）和负责每个职能领域或主要业务单位的外围成员组成。 联合式团队以协同方式办公，即使其成员位于不同的业务单位中。 通常，外围成员主要从事开发活动以支持其业务单位，而共享服务人员则为整个社区提供支持。

优点：

  • 存在外围 COE 成员的跨职能参与，这些成员代表其特定的职能领域并具有领域专业知识。
  • 在核心和外围 COE 成员之间存在集中代表和分散代表的平衡。
  • 如果存在分布式数据所有权（业务单位直接负责数据管理活动时），这会是一个有效的模式。

缺点：

  • 由于核心和外围成员跨越了组织边界，因此联合式 COE 模式需要强大的领导力、卓越的沟通、可靠的项目管理和清晰的期望。
  • 联合式结构遇到竞争性优先级事务的风险更高。
  • 这种模式通常涉及兼职人员和/或虚线组织架构图问责，从而带来时间上的竞争压力。

提示

某些组织通过使用轮换计划取得了成功。 它包括加入核心 COE 一段时间（例如六个月）的联合成员。 这种类型的计划允许联合成员了解最佳做法，并更深入地了解操作的完成方式和原因。 尽管每个联合成员仍然专注于其特定业务单位，但可以更深入地了解组织面临的挑战。 这种更深入的理解会随着时间的推移而建立更高效的合作关系。

分散式 COE

分散式 COE 由业务单位独立管理。

优点：

  • 有专门性的数据文化，专注于各自业务单位，这使文化更易于被了解和进行调整。
  • 每个业务单位有各自的定制策略和做法。
  • 各业务单位有各自侧重的敏捷性、灵活性和优先级。

缺点：

  • 分散式 COE 存在各自孤立运作的风险。 他们可能不会在其业务单位外共享最佳做法和经验教训。
  • 与中央团队的协作可能较为随意和/或不一致。
  • 不同业务单位创建和应用的策略不一致。
  • 分散式模式较难扩展。
  • 为了使一个或多个分散式 COE 与组织范围内的策略一致，可能会发生重复性工作。
  • 拥有较多资金的较大业务单位可能获取更多资源，从整个组织的角度来看，这可能产生与成本优化目标的冲突。

重要

高度中央化的 COE 会有“专权”倾向，而高度分散的 COE 会有“孤岛”倾向 。 每个组织都需要权衡这些模式的利弊，以确定最佳选择。 对于大多数组织而言，最有效的模式往往是统筹式或联合式，因为这些模式可跨越组织边界。

COE 融资

COE 可通过多种方式获得其运营预算：

  • 成本中心。
  • 包含项目预算的利润中心。
  • 成本中心和利润中心的结合。

当 COE 作为成本中心运行时，可消减运营成本。 通常，它涉及批准的年度预算。 有时将其称为“推动式”参与模式。

当 COE 作为利润中心运行时（至少就其预算的一部分而言），它可以根据来自其他业务单位的资金支持，全年接受项目。 有时将其称为“拉入式”参与模型。

融资非常重要，因为它会影响 COE 与内部社区沟通和接洽的方式。 随着 COE 取得越来越多的成功，它们可能会收到更多来自业务单位的求助。 随着整个组织中相关认知的增强，情况会益发如此。

提示

所选的融资模式可以决定 COE 如何主动扩大其影响力和增强其施助能力。 融资模式还会对施加权威的位置和决策制定的方式产生重大影响。 此外，它还影响 COE 可以提供的服务类型，例如共同开发项目和/或最佳做法审查。 有关详细信息，请参阅启导和用户支持一文。

一些组织会根据 Fabric 的使用目标，通过向业务部门退款来支付 COE 运营成本。 对于共享容量，这可能基于活跃用户数量。 对于高级容量，可根据使用容量的业务单位来分配退款。 理想情况下，退款与所获得的商业价值直接相关。

重要

有时本文指的是 Power BI Premium 或其容量订阅 (P SKU)。 请注意，Microsoft 目前正在合并购买选项并停用 Power BI Premium Per Capacity SKU。 新客户和现有客户应考虑改为购买 Fabric 容量订阅 (F SKU)。

有关详细信息，请参阅 Power BI Premium 许可即将进行的重要更新和 Power BI Premium 常见问题解答。

注意事项和主要措施

清单 - 建立或改进 COE 时的注意事项及可采取的关键措施。

  • 定义 COE 的职责范围：确保清楚 COE 可以支持哪些活动。 确定职责范围后，应确定履行这些职责所需的技能和能力。
  • 确定执行能力方面的差距：分析 COE 是否具备满足其目标和职责范围所需的系统和基础结构。
  • 确定最佳 COE 结构：确定哪个 COE 结构最适合（集中式、统筹式、联合式或分散式）。 确认人员配备、角色和职责以及适当的组织架构图关系（人力资源报表）是否已到位。
  • 未来增长计划：如果最开始使用的是集中式或分散式 COE，应考虑如何通过使用统筹式或联合式方法来随着时间的推移扩展 COE。 规划当前可以采取的有利于将来发展的任何措施。
  • 确定客户：确定 COE 要服务的所有内部社区成员和任何外部客户。 确定 COE 通常如何与这些客户互动，无论是推送模型、拉取模型还是两者结合模型。
  • 验证 COE 的资金模型：确定 COE 是纯粹的具有运营预算的成本中心、还是在一定程度上作为利润中心运营，以及/或是否需要向其他业务单位退款。
  • 创建沟通计划：创建沟通策略，以向内部用户社区宣传 COE 提供的服务，以及如何与 COE 互动。
  • 创建目标和指标：确定如何衡量 COE 的有效性。 创建 KPI（关键绩效指标）或 OKR（目标和关键结果），以验证 COE 始终为用户社区提供价值。

应考虑的问题

使用如下所示的问题评估 COE 的有效性。

  • 是否组建了 COE？ 如果已组建，谁是 COE 的成员，以及 COE 的结构如何？
  • 如果未组建，是否存在执行类似功能的中心团队？ 组织中的数据决策者是否了解 COE 的作用？
  • 如果没有 COE，组织是否希望创建一个？ 为什么是或为什么不是？
  • 由于企业和部门解决方案的混合，是否存在建立联合式或分散式 COE 模型的机会？
  • COE 是否缺少任何角色和职责？
  • COE 在多大程度上参与了用户社区互动？ 他们是否指导用户？ 它们是否策展了集中式门户？ 它们是否维护集中式资源？
  • COE 在组织中是否得到认可？ 用户社区是否认为他们可信且有用？
  • 业务用户认为中心团队是支持还是限制了他们的数据使用？
  • 什么是 COE 资金模型？ COE 客户是否以某种方式为 COE 做出财务贡献？
  • COE 与其沟通的一致性和透明性如何？

成熟度级别

以下成熟度级别有助于评估 COE 的当前状态。

级别 卓越中心的状态
100：起步 • 存在一个或多个 COE，或是在数据团队、BI 团队或 IT 团队内执行相关活动。 没有明确的具体目标和职责期望。

• 将以计划外方式处理对 COE 的协助请求。
200：可重复 • COE 已就位，且根据特定章程来指导、引导和教育自助服务用户。 COE 旨在最大限度地增加数据和 BI 自助式方法的优势，同时降低风险。

已确定 COE 的目标、职责范围、人员配备、结构和资金模型。
300：已定义 • COE 在所有业务单位的积极参与下，以统一或联合模式运营。
400：有能力 • COE 的目标与组织目标保持一致，并定期重新评估。

• COE 在整个组织中众所周知，并持续向内部用户社区证明其价值。
500：高效 • 定期评审 KPI 或 OKR，以可衡量的方式评估 COE 有效性。

• 敏捷性和通过吸取经验教训来实现持续改进（包括有效的横向扩展方法）是 COE 的首要任务。

相关内容

在 Microsoft Fabric 采用路线图系列文章的下一篇文章中，了解如何实现治理准则、策略和流程。