通过

数字化业务应用程序组

为了全面数字化像数字化转型平台（DTP）这样的 Microsoft大型组织，我们需要自动化数字反馈循环的所有四个方面。

数字反馈循环。

  • 转变 产品以增强我们的产品—例如，发布有关即将到来的发布波次可交付成果的发行说明。
  • 与客户和合作伙伴互动 以促进业务增长，例如，与客户互动以及从客户那里获取反馈和想法。
  • 赋予我们自己的员工权力 ，以提高我们组织的绩效。
  • 优化 业务运营以提高效率 - 例如，通过自动化业务审核。

下面是在成功中心上开发的应用示例；在我们的组织中实现数字反馈循环。

以数字方式转换 DTP。

工作流和人员

若要数字化反馈循环的所有四个方面，我们将应用划分为各种工作流。 每个工作流集中于特定人员，如下图所示。

显示集中于五个人员的工作流的图表：DevOps、ProductOps、Customers & Partners、Community 和 BizOps

下图显示了如何跨这五个工作流对 35 个应用进行建模。

跨工作流建模的应用。

应用使用其他应用共享的数据在 Microsoft Dataverse 中添加数据，以使用自动化和智能改进应用体验。 数据还可用于提供各种应用如何使用数据的成本节省方案。

产品开发方案

  1. Microsoft 与客户互动。 Customers & Partners 工作流中有许多应用，例如 Customer Engagement、执行参与、FastTrack 应用和 Power CAT。 每个应用都集中于特定人员。
  2. Microsoft 收集客户的反馈。 Customers & Partners 和 Community 工作流中有许多应用，例如创意、脉冲和检测信号（用于 FastTrack）。
  3. 在 ProductOps 工作流中使用 Fusion/One 反馈应用聚合反馈和任务并设置其优先级。
  4. 在 ProductOps 工作流中使用产品计划应用实施功能反馈和任务。
  5. 通过在 ProductOps 工作流执行审查中使用发布计划应用，向客户宣布计划。 使用 bedrock 门户自动化此操作，这是 BusinessOps 工作流的一部分。

可支持性方案

  1. 客户创建支持请求。 这是在 DevOps 工作流的 D4M 部分中完成的操作。
  2. 工程师将审查案例以防止未来发生。 使用案例审查应用完成此操作，这是 DevOps 工作流的一部分。
  3. 产品团队计划要完成的工作。 在 Product Ops 工作流中使用产品计划应用完成此操作。
  4. 在 Customers & Partners 工作流中使用应用关闭与遇到此问题的客户的循环。
  5. 在 Customers & Partners 工作流中使用应用关闭与提供了反馈的客户的循环。

成功中心联合开发模型

联合开发模型面临的挑战是，让每个人都能进行大规模联合开发，而不干扰其他应用。 为了使其可扩展，我们按工作流划分问题。 对于集中于应用开发的五个工作流的每一个，我们指定工作流潜在顾客。 他们的工作就是确保该工作流中的所有应用都遵循治理流程，此外还从成功中心团队获取正确的支持。

每当为应用请求任何重大更改时，它需要完成以下五个步骤才能进入生产。

  1. 范围对齐：查看高级用户体验和架构更改。
  2. 更新 Microsoft Azure DevOps：添加功能和用户案例，然后使用架构更改更新它们。
  3. 合作伙伴审批：发送给受影响利益干系人的审批邮件。
  4. 工作流潜在顾客注销：针对工作流潜在顾客的更改进行注销。
  5. 部署的更改：PR 审查和验证架构更改和工作项。

因为我们在平台上运行大约 35 个应用，因此我们无法进行扩展来审查所有更改。 某些更改（例如，为自定义表添加图标或为自定义表更改自定义视图中的排序）可能不会影响任何其他应用，这些更改将标记为小范围；应用团队可以选择与成功中心团队一起审查它们。 我们的主要重点是评估与表关联的任何更改。

我们有兴趣了解团队何时对表进行以下类型的更改：

  • 创建新表：很多时候，应用团队希望创建自己的表并独立处理数据。 但如果发生此情况，可能会为同一工作创建多个表，从而导致混乱。 与要求应用团队采用已提供的表或修改当前表以满足其（以及所有应用团队）需求相比，协调这些表将花费大量时间和精力。

  • 对共享表的更改：这些更改有两种类型：

    • 更改架构：这需要在已使用该表的应用程序之间对齐。
    • 更改数据（例如，分类法）：由于应用程序正在共享表中的数据，因此必须让单个团队管理该数据，或者至少为其创建治理规则。

部署和现场

成功中心将遵循每周部署周期，合作伙伴会议将审查 Microsoft Dataverse 组件，随后在每周三部署到测试环境。 合作伙伴团队有两天时间在测试环境中验证其应用以及解决方案更改。 验证后，我们获取合作伙伴团队的注销，并在下周一将这些组件部署到生产环境。

Microsoft Power Platform 还使我们能够自动化支持流程，在票证系统中跟踪支持别名的电子邮件。 每周在现场审查中审查这些项目，以了解成功中心的运行状况并标识修复项目以及用户查询的趋势。

若要监视组件的运行状况，我们使用以下内容：

  • 应用程序生命周期管理 (ALM) 模型，包含以下内容：
    • 开发环境（每个应用）
    • 测试环境（单个环境）
    • 用户验收测试 (UAT) 环境（单个环境）
    • 生产环境（单个环境）
    • 供团队试用其应用的概念证明环境
  • 使用 Power Platform Build Tools 通过 Azure DevOps 管理生成和发布管道。
  • 开发和测试环境每周通过每周生成以自动方式刷新一次。
  • 自动测试在测试环境和 UAT 环境中运行。 这有助于确保更顺利地进行联合开发。
  • 每个应用都是一个解决方案，并且正在变为托管解决方案。

安全性和符合性集成

完成安全性和符合性集成后，它可用于开发中的任何应用。 此集成具有以下特征：

  • 大量只读数据：在某些情况下，在成功中心中，我们只需将数据用作参考—例如租户的每日、每月和每周活动用户度量。 此数据用于了解使用情况，但永远不会在成功中心中进行修改。 我们使用虚拟表来呈现此类数据，数据通常量大并且只读。
  • 大量读写数据：当 Power Automate 流满足大部分集成需求时，在某些情况下（例如调用 Azure Functions）需要高级 Azure 功能。 对于这些情况，我们使用 Azure 逻辑应用。
  • 简单集成：流已大量用于生成集成以及组织中的业务逻辑。
  • 创建特定角色以遵循安全性。
  • 我们在成功中心进行常规符合性审查，因为成功中心存储大量敏感信息。
  • 如果应用团队使用现有数据表和集成，则无需进行符合性审查。

与其他数据源集成

对于业务应用，我们通常需要来自各种数据源的数据。 Microsoft Dataverse 使用虚拟表提供一种与其他数据源集成的良好方法。 我们集成以下类型的数据源：

  • Microsoft 客户、销售和合作伙伴数据（例如， Microsoft Sales Experience、Lifecycle Services、客户服务）
  • DevOps 和可服务性（例如，Azure DevOps 和 IcM 事件管理）
  • 组织层次结构和用户配置文件（Microsoft Entra 以及 Microsoft Graph）

支持和维护渠道

通过以下渠道，可以开发、支持和维护任何应用：

  • Wiki、指南和每周办公室时间（用于提出问题）
  • 维护（警报和监视）由单个团队（Microsoft Power Platform 工作流）完成
  • 遥测仪表板以跟踪性能和运行状况指标