30、需求分析与端到端解决方案草案创建

需求分析与端到端解决方案草案创建

1. 理解当前情况

在开始解决问题之前，我们需要对当前的情况有一个清晰的认识。这包括了解相关组织的活动范围、地理分布以及各种关键数据。

1.1 组织信息

相关组织在美洲（AMER）、欧洲、中东和非洲（EMEA）以及亚太地区（APAC）开展业务，覆盖10个国家的50个城市。组织内有销售代理、支持代理、办公室技术人员、办公室经理和区域高管等角色，同时还有客户和合作伙伴。

1.2 关键数据

• 拥有5000辆汽车。
• 每个城市有10个办公室。
• 全球有100万注册用户。
• 每年平均有1000万次汽车租赁。

这些数据在后续的解决方案设计中非常重要，因为它们可能会带来一些数据挑战，例如大对象（LDV）问题。

1.3 角色层次结构和参与者与许可证图

根据目前的信息，我们可以创建一个初步的角色层次结构和参与者与许可证图。在角色层次结构中，可能会包含一些未在场景中明确提及但有助于使结构更清晰的角色，如销售总监。在参与者与许可证图中，对于不太明确的主题可以留下问号，以便后续识别差距。

以下是角色层次结构的示例：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A(区域高管):::process --> B(销售总监):::process
    A --> C(办公室经理):::process
    B --> D(销售代理):::process
    C --> E(支持代理):::process
    C --> F(办公室技术人员):::process
    D --> G(客户):::process
    D --> H(合作伙伴):::process

参与者与许可证图的示例：
| 参与者 | 可能的许可证 |
| ---- | ---- |
| 销售代理 | 待定 |
| 支持代理 | 待定 |
| 办公室技术人员 | 待定 |
| 办公室经理 | 待定 |
| 区域高管 | 待定 |
| 客户 | 客户社区许可证 |
| 合作伙伴 | 待定 |

2. 分析业务流程需求

接下来，我们将分析组织共享的五个关键业务流程，包括客户注册、汽车预订、汽车入住、汽车退房以及汽车状态更新和罚款结算。

2.1 客户注册

客户注册过程有五个关键要求，并且可能会受到可访问性和安全要求部分的额外影响。

2.1.1 客户自助注册

客户应能够使用在线门户和移动应用程序进行自助注册。这可以在Salesforce社区中轻松实现，但会引发两个主要问题：
- 需要哪种类型的社区许可证？鉴于目前没有明确指向客户社区增强版许可证的可访问性要求，暂时选择客户社区许可证。
- 移动应用的正确策略是什么？考虑到开发和部署的便捷性，建议使用Salesforce Mobile Publisher来创建和部署品牌移动应用。

2.1.2 销售代理注册

销售代理可以为走进办公室的新客户进行注册。这是Salesforce的开箱即用功能，销售代理可以为客户创建个人帐户，并启用客户社区用户。

2.1.3 信息收集

注册客户时，必须收集特定信息，其中驾驶执照值需要作为自定义字段引入。建议将所有自定义字段添加到数据模型中，以确保在评审中不会遗漏相关分数。

2.1.4 隐私条款接受

客户必须接受组织的隐私条款和条件。可以使用Salesforce引入的标准同意管理对象来满足这一要求，如个人对象、接触点类型同意对象和数据使用目的对象。

2.1.5 驾驶执照有效性检查

需要实时检查驾驶执照的有效性。这需要设计与国家机构服务的集成接口，采用远程过程调用 - 请求和回复模式。对于在线自助注册，可以在提交按钮点击时调用远程服务；对于销售代理，可以引入自定义验证驾驶执照操作来触发Salesforce屏幕流。中间件（如MuleSoft）可以处理重试机制，并提供统一的接口。

客户注册业务流程的示例如下：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A(客户访问注册页面):::process --> B{选择注册方式}:::process
    B -->|在线门户| C(填写信息):::process
    B -->|移动应用| C
    C --> D(提交信息):::process
    D --> E{是否为自助注册}:::process
    E -->|是| F(验证驾驶执照):::process
    E -->|否| G(销售代理处理):::process
    F --> H(接受隐私条款):::process
    G --> H
    H --> I(完成注册):::process

2.2 汽车预订

汽车预订过程有三种模式：在线服务（在线门户和移动应用）、呼叫中心和走进PPA分支机构。

2.2.1 选择车辆

客户应能够输入取车地点（城市）以及开始和结束日期，系统应显示该地点和时间可用的汽车列表。这需要一个自定义的Visualforce页面或Lightning组件。可以使用产品对象来表示汽车，通过价格手册对象按位置分组汽车。产品和价格手册需要对客户可见，可以通过手动共享价格手册对象来实现。

2.2.2 价格计算

系统应计算并显示每辆汽车的租赁价格。需要与组织的价格计算应用程序集成，采用远程过程调用 - 请求和回复模式。

2.2.3 在线支付

客户应选择所需的汽车并进行在线支付。建议使用提供支付功能的现成产品，如Bluefin和Chargent。支付完成后，会创建一个支付记录，并触发Salesforce流来更新订单状态并发送电子邮件通知。

2.2.4 支持代理操作

支持代理可以使用为客户创建的Visualforce页面或Lightning组件搜索可用汽车，并口头告知客户相关信息。电子邮件确认和激活码的发送逻辑与客户操作相同。

汽车预订业务流程的示例如下：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A(客户/支持代理输入信息):::process --> B(系统查询可用车辆):::process
    B --> C(显示可用车辆和价格):::process
    C --> D(客户选择车辆):::process
    D --> E(进行在线支付):::process
    E --> F(创建支付记录):::process
    F --> G(更新订单状态):::process
    G --> H(发送电子邮件通知):::process

2.3 汽车入住

汽车入住过程有两个要求。

2.3.1 客户操作

每个办公室有多个平板电脑，客户可以使用预订时收到的激活码进行入住。平板电脑上的应用程序应向Salesforce进行身份验证，查找订单记录并更新其状态。在解决方案中，需要解释所使用的集成模式（远程调用）、身份验证机制（OpenID Connect用户代理流）以及数据传输的安全措施。

2.3.2 销售代理操作

客户入住后，销售代理可以交出汽车钥匙并更新预订状态。这个过程可以手动完成，但在问答环节可能会要求进一步自动化。

汽车入住业务流程的示例如下：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A(客户输入激活码):::process --> B(平板电脑应用验证):::process
    B --> C(查找订单记录):::process
    C --> D(更新订单状态):::process
    D --> E(销售代理交出钥匙):::process
    E --> F(再次更新订单状态):::process

2.4 汽车退房

汽车退房过程相对简单，客户必须亲自将汽车归还到租赁办公室。

2.4.1 车辆检查

销售代理应收集钥匙并快速检查车辆。为了存储检查细节并通知技术人员处理重大损坏，可以使用Case对象。销售代理可以创建一个案例，将其与客户的订单关联，并在满足特定条件时自动分配给技术人员的队列。

2.4.2 数据传输和发票生成

检查信息应发送到ERP，ERP在72小时后生成客户发票。建议使用中间件（如MuleSoft）来实现数据传输，选择合适的集成模式和身份验证机制，并确保数据传输的安全性。

2.4.3 发票通知

发票生成后，应向客户发送通知，包含发票金额和结算余额的说明。可以选择将发票信息存储在与订单相关的自定义对象中或作为订单的属性。

汽车退房业务流程的示例如下：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A(客户归还汽车):::process --> B(销售代理收集钥匙):::process
    B --> C(检查车辆):::process
    C --> D(创建案例):::process
    D --> E(关联订单):::process
    E --> F(分配给技术人员队列):::process
    F --> G(发送电子邮件通知):::process
    G --> H(数据传输到ERP):::process
    H --> I(ERP生成发票):::process
    I --> J(发送发票通知):::process

2.5 汽车状态更新和罚款结算

汽车配备了跟踪设备，用于定期发送汽车的GPS坐标和其他信息，如急刹车或超速事件。这些设备属于物联网（IoT）设备，会产生大量数据。

2.5.1 数据接收和处理

考虑到数据量巨大，Salesforce Core不是接收和处理这些数据的理想平台。建议使用Salesforce Heroku和一些附加产品，如Heroku上的Apache Kafka、Postgres和Redis。

2.5.2 驾驶员行为分析

组织希望收集描述驾驶员行为的信息，这需要一个商业智能（BI）工具，如Microsoft Power BI、Tableau或Salesforce CRM Analytics。

2.5.3 车辆盗窃检测

使用GPS跟踪设备检测可能的车辆盗窃需要引入自定义逻辑。考虑到各种因素，建议使用托管在Heroku上的自定义开发应用程序。

2.5.4 违规数据库检查

每天需要检查三个违规数据库，并执行统一的逻辑。可以使用MuleSoft批量作业来完成这个任务。

汽车状态更新和罚款结算业务流程的示例如下：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A(跟踪设备发送数据):::process --> B(Heroku接收和处理):::process
    B --> C(分析驾驶员行为):::process
    B --> D(检测车辆盗窃):::process
    D --> E(创建Salesforce案例):::process
    E --> F(分配队列并通知):::process
    C --> G(数据传输到BI工具):::process
    H(每天检查违规数据库):::process --> I(MuleSoft处理):::process
    I --> J(数据传输到ERP):::process
    J --> K(生成新发票):::process

通过以上对业务流程的分析和解决方案的设计，我们已经满足了大部分的需求。在后续的工作中，我们可以进一步完善解决方案，并创建一个有说服力的演示文稿。

3. 总结与展望

3.1 已完成工作回顾

我们已经对组织的业务流程进行了全面的分析，并针对每个流程设计了相应的解决方案。具体来说：
- 客户注册 ：实现了客户自助注册和销售代理注册两种方式，解决了社区许可证选择、移动应用策略、信息收集、隐私条款接受和驾驶执照有效性检查等问题。
- 汽车预订 ：支持在线服务、呼叫中心和走进分支机构三种预订模式，完成了车辆选择、价格计算、在线支付和支持代理操作等功能。
- 汽车入住 ：客户可使用激活码在平板电脑上完成入住，销售代理可进行后续的钥匙交接和状态更新。
- 汽车退房 ：销售代理检查车辆并创建案例，数据传输到ERP生成发票，最后通知客户。
- 汽车状态更新和罚款结算 ：利用物联网设备收集数据，通过Heroku进行处理，实现了驾驶员行为分析、车辆盗窃检测和违规数据库检查等功能。

3.2 关键技术点总结

业务流程	关键技术点
客户注册	远程过程调用 - 请求和回复模式、自定义字段、Salesforce社区、MuleSoft中间件
汽车预订	产品对象、价格手册对象、远程过程调用 - 请求和回复模式、支付网关集成
汽车入住	远程调用、OpenID Connect用户代理流、数据传输安全措施
汽车退房	Case对象、中间件数据传输、集成模式和身份验证机制
汽车状态更新和罚款结算	Salesforce Heroku、商业智能工具、自定义开发应用程序、MuleSoft批量作业

3.3 后续工作建议

虽然我们已经满足了大部分需求，但仍有一些工作需要进一步完善：
1. 解决方案优化 ：对现有的解决方案进行性能测试和优化，确保系统在高并发情况下的稳定性和可靠性。
2. 演示文稿创建 ：根据已完成的解决方案，创建一个清晰、有吸引力的演示文稿，用于向相关人员展示。
3. 应对挑战准备 ：考虑可能出现的挑战，如计算器应用程序被移除、需求变更等，并准备相应的应对策略。
4. LDV策略制定 ：针对大对象（LDV）问题，制定详细的策略，确保数据的高效处理和存储。

3.4 整体架构概述

经过一系列的设计和优化，最终的整体架构如下：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A(客户/合作伙伴):::process --> B(在线门户/移动应用):::process
    B --> C(Salesforce社区):::process
    C --> D(Salesforce Core):::process
    D --> E(MuleSoft中间件):::process
    E --> F(ERP系统):::process
    E --> G(全局跟踪系统):::process
    E --> H(违规数据库):::process
    I(汽车跟踪设备):::process --> J(Salesforce Heroku):::process
    J --> K(商业智能工具):::process
    J --> D
    D --> L(Case对象):::process
    L --> M(技术人员队列):::process

3.5 总结

通过对组织业务流程的深入分析和解决方案的设计，我们已经建立了一个全面的端到端解决方案。在后续的工作中，我们需要不断完善和优化这个解决方案，以满足组织的需求，并在面对各种挑战时能够灵活应对。同时，我们也需要准备一个出色的演示文稿，向相关人员展示我们的解决方案的价值和优势。希望通过这些努力，能够为组织带来更好的业务效益和用户体验。