Case Study 05 — Enterprise Data Integration（企业数据集成 / Customer 360）

知识库位置：FDE Knowledge Base/06 Case Studies/05-Enterprise-Data-Integration.md

Case Metadata（案例元数据）

Case ID: CS-005

Industry（行业）:
Cross-industry（跨行业，多并购企业集团）

Primary Domain（主要领域）:
Data Integration（数据集成）

Case Type（案例类型）:
Reference Scenario（参考情景）

Complexity（复杂度）:
High（高）

Primary Technologies（主要技术）:
ETL（抽取-转换-加载）
Identity Resolution（实体识别）
Canonical Model（规范化模型）
Data Platform（数据平台）

Business Function（业务职能）:
Data Management（数据管理）

Delivery Stage（交付阶段）:
End-to-End（端到端）

Status: Core
Version: v0.1

本案例为 Reference Scenario（参考情景）：用于教学和方法论说明的综合案例，并非某个真实客户项目。参见 Case Studies README（案例域使用说明）。

1. Customer Background（客户背景）

客户通过多年并购（M&A，Merger & Acquisition）拥有大量系统：

CRM（Customer Relationship Management，客户关系管理系统）
ERP（Enterprise Resource Planning，企业资源计划系统）
Billing（计费系统）
Support（客服系统）
Marketing（市场系统）
Legacy Database（遗留数据库）

不同部门都有自己的客户数据。

2. Business Problem（业务问题）

客户提出：

我们想做一个 Customer 360（客户 360 视图）。

真正问题：

销售、客服、财务看到的是不同版本的客户。

例如：

CRM:
Acme Corporation

ERP:
ACME Corp

Billing:
Acme Inc.

没有统一 Customer ID（客户唯一编号）。

3. Discovery（客户调研）

发现：

不同系统拥有不同 Customer ID（客户编号）
同一客户存在重复记录
字段定义不同
更新频率不同
Source of Truth（唯一事实来源）不明确

因此真正问题不是：

把数据搬到一个 Warehouse（数据仓库）。

而是：

建立统一业务实体和数据责任。

4. Scoping（范围界定）

第一阶段只统一：

Customer（客户）
Account（账户）
Contact（联系人）

不处理：

Product（产品）
Invoice（发票）
Support Ticket（支持工单）
Marketing Attribution（市场归因）

5. Architecture Design（架构设计）

CRM ─────┐
ERP ─────┤
Billing ─┤
Support ─┤
         ↓
Ingestion Layer（摄取层）
         ↓
Standardization（标准化）
         ↓
Identity Resolution（实体识别）
         ↓
Canonical Customer Model（规范化客户模型）
         ↓
Data Platform（数据平台）
         ↓
Analytics / Applications（分析 / 应用）

Key Decision 1（关键决策一）：Batch vs Streaming（批量 vs 流式）

Customer 360 第一阶段允许：

Hourly Refresh（每小时刷新）

因此使用 Batch / Incremental Pipeline（批量 / 增量管道）。

没有直接引入 Streaming（流式处理）。

关联：Decision Guide：Batch vs Streaming（批量 vs 流式）

Key Decision 2（关键决策二）：Source of Truth（唯一事实来源）

不是简单选一个系统作为所有字段的 Source of Truth。

采用字段级 Ownership（字段级所有权）。

例如：

Customer Legal Name（客户法定名称）→ ERP
Sales Owner（销售负责人）→ CRM
Billing Status（计费状态）→ Billing System
Support Tier（支持等级）→ Support System

6. Engineering Implementation（工程实现）

Canonical Model（规范化模型）

定义统一：

customer_id（客户唯一编号）
legal_name（法定名称）
display_name（显示名称）
billing_status（计费状态）
sales_owner（销售负责人）
support_tier（支持等级）

并维护：

source_system（来源系统）
source_record_id（来源记录编号）
last_updated（最后更新时间）

Identity Resolution（实体识别）

采用：

Exact Match（精确匹配）
+
Business Rules（业务规则）
+
Human Review for Ambiguous Cases（模糊案例人工复核）

不一开始就使用复杂 ML Matching（机器学习匹配）。

7. Prototype（原型）

选取 10,000 个客户记录。

发现：

约一部分客户可以自动匹配。

但部分大型集团拥有：

Parent Company（母公司）
Subsidiaries（子公司）
Regional Entities（区域实体）

简单名称匹配会错误合并。

Fix（修复）

加入：

Legal Entity ID（法定实体编号）
Tax ID（税号）
Domain（域名）
Address（地址）
Parent-child Relationship（母子关系）

并将不确定匹配送人工 Review（复核）。

8. Pilot（试点）

先服务：

Sales Operations（销售运营团队）

他们使用 Customer 360 Dashboard（客户 360 看板）。

Pilot（试点）发现：

数据整合技术上正确，但业务用户不信任。

原因：

不知道字段来自哪里。

因此增加：

Field Value（字段值）
+
Source System（来源系统）
+
Last Updated（最后更新时间）

建立 Data Lineage（数据血缘）。

9. Production（生产）

Production（生产）增加：

Reconciliation（对账）
Data Quality Monitoring（数据质量监控）
Ownership（数据责任制）
SLA（Service Level Agreement，服务等级协议）
Incremental Sync（增量同步）
Failure Recovery（故障恢复）
Audit（审计）

10. Business Outcome（业务结果）

衡量：

Duplicate Customer Records（重复客户记录数）
Manual Reconciliation Time（人工对账耗时）
Reporting Consistency（报表一致性）
Data Availability（数据可用性）
Sales / Support Cross-system Lookup Time（跨系统查询耗时）

11. Challenges（挑战）

12. Key Decisions（关键决策）

Decision（决策）	Options（选项）	Choice（选择）	Why（原因）
数据时效	Streaming vs Batch/Incremental	小时级批量/增量	第一阶段允许小时级刷新
实体归属	单一权威系统 vs 字段级 Ownership	字段级 Ownership	各系统各管最擅长的字段
实体识别	复杂 ML Matching vs 规则+人工	Exact Match + 业务规则 + 人工复核	先建立信任，再逐步自动化
用户信任	只给结果 vs 展示来源	字段级 Data Lineage	让用户知道数据来自哪里

13. Reusable Lessons（可复用经验）

数据集成不是单纯 ETL（Extract, Transform, Load，抽取-转换-加载）。
Source of Truth（唯一事实来源）需要业务 Ownership（所有权）。
Entity Resolution（实体识别）是 Customer 360 核心问题。
Lineage（数据血缘）能显著提高用户信任。
先从关键实体开始，不要一次统一所有数据。
Data Quality（数据质量）必须长期运营，而不是一次性清洗。