39、解决方案展示与辩护：从整体介绍到项目策略

解决方案展示与辩护：从整体介绍到项目策略

在完成了第二个完整的场景解决方案后，我们需要通过一场出色的展示来为方案争取尽可能多的分数。展示分为结构化部分和补充部分，结构化部分包括整体解决方案介绍、业务流程说明、LDV 缓解和数据迁移策略描述；补充部分则是检查是否遗漏了之前未覆盖的需求。下面我们将详细介绍展示的各个环节。

整体解决方案和工件介绍

1. 开场自我介绍与公司业务简述
   • 开场用简短的一段话介绍自己，例如：“我是[你的名字]，今天来为[场景中的公司名称]介绍我们提出的解决方案。”
   • 接着简要描述公司业务，如：“这是一家欧洲电力公用事业公司，服务于德国、意大利、法国、葡萄牙、比利时和英国的多个城市，在 40 个城市开展业务，为 B2C（居民）和中小型 B2B 客户提供服务。”这部分应在一分钟内完成。
2. 公司关键需求说明
   • 阐述公司的关键需求，如：“该公司多年来一直受现有 CRM 解决方案的困扰，作为一项新的战略举措，决定转向 Salesforce，希望利用新的 CRM 系统推出一套全球统一的销售和服务流程。”
3. 当前和未来架构说明
   • 公司使用六个不同的 ERP 系统，用于服务履行、客户入职、切换和激活。计划保留所有这些系统，并通过 API 将新解决方案与之集成，但比利时的 ERP 系统没有 API。
   • 为了实现可扩展和灵活的架构，需要在 Salesforce 和 ERP 系统之间建立统一的通信接口，MuleSoft 中间件可以提供这种能力，还能协调系统间的数据流并处理异常。
   • MuleSoft 可以通过内置连接器直接与比利时 ERP 基于的平面文件数据库通信，由于不会传输大量数据，所以选择 ESB 而非 ETL，但仍建议使用 ETL 进行数据迁移。
   • 公司使用高度定制的 CPQ 解决方案并计划保留，通过 MuleSoft 暴露的细粒度 API 与之集成，在适当阶段调用 Power Sales 计算自定义报价。
   • 公司依赖的电表和燃气表需要支持，MuleSoft 作为统一集成中间件发挥关键作用。
   • 提议的解决方案将取代目标国家的一系列旧 CRM 解决方案，使用 ETL 工具（如 Informatica）进行数据迁移。
   • 解决方案基于单个 Salesforce 组织，考虑到公司最近收购的使用 Salesforce 作为核心 CRM 的新公司，由于业务不同且预计新公司将独立运营几年，所以先从单个组织开始满足需求，收购的 Salesforce 组织继续独立运行，通过 MuleSoft 与其他系统连接。
   • 解决方案还将利用 Marketing Cloud 进行客户细分、电子邮件和移动通信，使用 AppExchange 上的第三方应用（如 DocuSign）。
   • 已经创建了所需集成接口和认证机制的完整列表，以及数据模型图，后续会详细解释。
4. 许可证说明
   • 不同角色需要不同类型的许可证：
     | 角色 | 所需许可证 | 原因 |
     | ---- | ---- | ---- |
     | 现场销售代理 | Sales Cloud 许可证 | 管理客户的新业务和续约机会 |
     | 服务代理 | Service Cloud 许可证 | 处理 Case 对象（代表事件和查询），使用 Salesforce Omni - Channel 分配案件，使用 Service Console 和 Salesforce Service Cloud Voice 接听支持电话 |
     | SVPs | 访问所有团队可访问对象的许可证及 CRM Analytics 许可证 | 访问团队可访问的所有对象，获取依赖非 Salesforce 标准或自定义对象数据的趋势报告 |
     | 关键客户经理 | Sales Cloud 许可证 | 使用 Opportunity 对象管理与关键客户的交易 |
     | 营销团队 | Sales Cloud 和 Marketing Cloud 许可证 | 在两个系统中创建和培育潜在客户，执行营销活动和发送大量电子邮件 |
     | 现场服务团队 | Service Cloud 和 Salesforce Field Service 许可证 | 访问 Salesforce Field Service 的功能，如移动应用、数据模型和优化调度功能 |
     | 维护合作伙伴 | Partner Community 许可证 | 处理能源供应事件，需要高级共享功能和部分机会可见性 |
     | 客户 | Salesforce Customer Community Login 许可证 | 公司有近六百万客户，该许可证适合大量用户，可通过共享集管理访问权限 |

整体高级解决方案展示应在五到六分钟内完成，要注意控制速度，确保涵盖所有必要信息。

业务流程端到端解决方案展示

接下来进入展示的重要部分，解释解决方案如何解决共享的业务流程，以客户服务业务流程为例：
1. 客户服务流程概述
- 客户可以通过在线门户或拨打客服中心电话提出咨询和投诉，这些将使用标准的 Case 对象建模。
- 使用 Salesforce Omni - Channel 根据所需技能（如语言）将 Case 记录分配给合适的代理，因为需要评估多种技能，所以选择 Omni - Channel。
- 使用 Salesforce 社区创建在线门户，客户使用 Customer Community Login 许可证。
- 使用 Salesforce Service Cloud Voice 设置客服中心电话号码，它还能与 Service Cloud Console 集成，为代理提供软电话来接听电话和创建案件。
- 使用案件升级规则，将七天内未解决的投诉升级，服务副总裁将在投诉升级时收到电子邮件。
2. 电表读数处理
- 系统需要根据前一个月的读数自动生成下个月的电表预测读数。考虑到系统中的客户和电表数量，以及每月每个电表需要记录的预测和实际消耗两个数据，预计需要约 1.46 亿条记录来存储这些数据，这会影响目标对象的 CRUD 操作性能和数据存储，还可能因查找偏差产生其他性能影响。
- 将电表读数存储在自定义非规范化对象（Meter_Reading__c）中，可显著减少记录数量。
- 使用保存前流程，在前一个月的实际消耗记录更新后，自动填充下个月的预测消耗，如更新 Jan_Actual__c 字段后，自动填充 Feb_Forecasted__c 字段。
- Meter_Reading__c 对象通过主 - 明细关系与 Asset 对象关联，拥有 Asset 记录访问权限的用户可以查看相关的 Meter_Reading__c 记录，客户社区用户可以查看与其账户相关的资产的 Meter_Reading__c 记录。
3. 发票和支付处理
- 假设发票和支付信息存储在 ERP 系统中，通过 Salesforce Connect 将其暴露给客户。MuleSoft 连接所有 ERP 系统，检索发票并聚合为 OData 接口供 Salesforce 订阅，在数据模型中添加了相关外部对象（Payment__x、Invoice_Header__x 和 Invoice_Line_Item__x）。
- 每月通过 MuleSoft 批量作业从 ERP 系统检索发票详细信息，传递给 PDF 生成系统生成发票 PDF 文件，MuleSoft 再从 SFTP 检索文件并传输到 Salesforce，使用特定的文件命名约定（包含账户 ID）将文件附加到正确的账户记录，PDF 文件使用 Salesforce Files 存储。
4. 能源故障处理
- 在能源故障时创建关键事件（另一种 Case 记录类型），根据物业地址使用案件分配规则将其分配给合适的维护合作伙伴。
- 确定受影响地区的所有客户并发送 SMS 通知，由于 Salesforce 平台本身不具备此功能，所以使用 Marketing Cloud 的 Transactional Messaging API 实现。
- 创建关键事件案件后，从 Salesforce 向 MuleSoft 触发平台事件，MuleSoft 查询 Salesforce 找出受影响客户，然后调用 Marketing Cloud 的 Transactional Messaging API，整个过程由 MuleSoft 协调，确保可扩展性和性能。
- Salesforce 和 MuleSoft 之间的所有通信通过双向 TLS 保护，并使用 OAuth 2.0 网络服务器流程（初始阶段）和刷新令牌流程进行认证。

客户服务业务流程展示应在五到六分钟内完成，其他业务流程所需时间可能更短。在展示过程中，可以将假设融入其中，这种方式更自然和吸引人。

这个流程图展示了客户服务业务流程中从客户提出咨询或投诉到最终处理完成的主要步骤：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;

    A(客户提出咨询/投诉):::process --> B(使用 Case 对象建模):::process
    B --> C(Salesforce Omni - Channel 分配案件):::process
    C --> D(服务代理处理案件):::process
    D --> E{案件是否解决}:::process
    E -->|是| F(案件关闭):::process
    E -->|否| G(案件升级规则触发):::process
    G --> H(服务副总裁收到邮件):::process
    B --> I(电表读数处理):::process
    I --> J(存储在 Meter_Reading__c 对象):::process
    J --> K(自动填充预测读数):::process
    B --> L(发票和支付处理):::process
    L --> M(通过 MuleSoft 集成 ERP 数据):::process
    M --> N(生成并存储发票 PDF):::process
    B --> O(能源故障处理):::process
    O --> P(创建关键事件案件):::process
    P --> Q(分配给维护合作伙伴):::process
    Q --> R(通知受影响客户):::process

解决方案展示与辩护：从整体介绍到项目策略

项目开发和发布策略展示

在完成前面的展示环节后，可能已经用掉了大部分结构化展示的时间，接下来要进行简洁的项目开发和发布策略介绍。

公司希望尽快实现价值，因此建议采用 MVP（最小可行产品）概念来定义每个版本包含的功能。MVP 能让企业无需等到项目结束就能开始获得收益，有效降低整体风险，因为用户可以快速开始使用新系统，并在后续的增量版本中获得更多功能。

在这个项目中，识别出了至少三个潜在风险及相应的缓解策略：
1. MVP 解决方案的设计和治理风险 ：使用由两部分组成的治理机构来缓解。一个是卓越中心（CoE），确保战略决策能让所有利益相关者参与；另一个是设计权威（DA），负责应对日常项目挑战，并根据最佳实践提出合理且可行的解决方案。
2. ERP 系统较慢的发布周期与 Salesforce 快速发布周期的协调风险 ：采用多层开发环境，并将其与合适的 ERP 环境集成。通过 MuleSoft 建立系统间的松散耦合集成，利用双速架构概念，使集成系统能够以各自的节奏发展，减少相互依赖。同时，在项目中设置透明的待办事项列表，确保每个人都了解正在开发的功能，CoE 会确保为正确的版本选择合适的功能。
3. 从桌面应用切换到基于云/浏览器的解决方案时管理用户期望和性能的风险 ：确保有正确的变更管理流程，包括沟通活动、培训、定义开拓者/超级用户以及获得执行团队的持续支持。使用性能与桌面应用相近的工具。

采用源代码驱动的开发方式，使用多层开发环境。这种开发方式可以维护可追踪的审计轨迹，显示项目生命周期中任何给定时间开发的功能。以下是开发环境的设置：
- 开发流 ：最初有一个开发流，团队在开发沙箱中开发新功能，在另一个开发者沙箱中测试开发的功能，避免开发活动的干扰。还有一个沙箱用于持续合并所有流中最新开发的功能。
- 其他环境 ：测试团队管理一个 QA 环境沙箱，此外还有一个预生产环境和一个生产环境。热修复可以在单独的沙箱中进行，然后部署到持续集成（CI）、预生产和生产环境。这种设置允许未来的开发流并行工作，确保所有团队始终使用最新的代码库，避免冲突。

建议使用自动化部署和发布管理工具（如 Copado）以及自动化测试管理套件（如 Provar）。除了使用基于 UI 的自动化测试无法测试的功能外，还会使用 Apex 单元测试来测试所有关键功能。

下面的表格总结了项目开发和发布策略的要点：
| 策略要点 | 详情 |
| ---- | ---- |
| 开发理念 | 采用 MVP 概念，尽快实现价值并降低风险 |
| 风险及缓解 | 设计和治理：使用 CoE 和 DA；周期协调：多层开发环境与 MuleSoft 集成；用户期望和性能：变更管理流程和匹配性能的工具 |
| 开发方式 | 源代码驱动，多层开发环境 |
| 工具使用 | 自动化部署和发布管理工具 Copado，自动化测试管理套件 Provar，Apex 单元测试 |

这个流程图展示了项目开发和发布的主要流程：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;

    A(项目启动):::process --> B(定义 MVP 功能):::process
    B --> C(开发流开发新功能):::process
    C --> D(测试开发功能):::process
    D --> E(合并新功能):::process
    E --> F(QA 环境测试):::process
    F --> G(预生产环境准备):::process
    G --> H(生产环境部署):::process
    I(热修复):::process --> J(单独沙箱处理):::process
    J --> K(部署到 CI、预生产和生产):::process
    C --> L(识别和缓解风险):::process
    L --> M(CoE 和 DA 参与):::process
    L --> N(多层开发环境协调):::process
    L --> O(变更管理流程):::process

通过以上对整体解决方案、业务流程以及项目开发和发布策略的展示，我们全面地呈现了为公司提出的解决方案。在展示过程中，要注意时间管理，确保每个部分都能在规定时间内清晰、准确地传达关键信息。同时，对于可能出现的问题，要做好充分的准备，在问答环节能够有力地为解决方案进行辩护和解释。