文章
家庭聚餐映射业务场景
家庭聚餐类比文章：
非常好，你贴出来这个 “家庭聚餐”比喻经典且有用，我可以帮你把你当前企业申报业务 +数据建模 的场景，套回这个类似思路，理顺业务域 / 业务过程 /关键活动。然后结合你之前说的数据模型（维度、事实）建议做一个对照。这样你能更清晰地把“家庭聚餐”思维类比运用到业务建模里。
一、把“家庭聚餐”比喻映射到你们公司的业务场景
先回顾“家庭聚餐”这个类比：
- 家庭成员：妈妈买菜、爸爸做菜、其他人分工采购 /布置／结账
- 聚餐过程：买菜 → 做菜 → 布置餐桌 → 吃饭 →结账
- 关键活动：买菜（采购）、做菜（生产 /加工）、设置餐桌（布置）、结账（清算 /核账）
- 业务域（Domain）：家庭 +他们为了聚餐这个目标协同分工。
把这个比喻套到你们公司
- “家庭成员”：可以比作你们公司内部不同角色 /系统 /业务线（销售 /运营 /数据 /爬虫 /第三方采集）
- “聚餐目标”：帮助企业申报高企、软著、专利等 → 最终是成交（或业务付费 /签单）
- 聚餐过程（家庭做饭的流程） → 你们的业务过程可以拆分成几个阶段（业务域 + 关键过程 +活动）：
二、为你建模：业务域 + 业务过程 + 关键活动
1. 业务域 (Business Domain)
- 潜在客户获取域：抓取企业 +联系人 +联系方式（来自企查查等）
- 线索管理域：对企业 / 联系人做分级 (评分)、打标签 (有效 /无效 /负责人等)
- 销售 /洽谈域：业务人员拨打电话、做沟通、转化 (意向 /项目负责人 /成交)
- 客户价值 /运营域：如果客户最终成为付费客户 /项目客户，这部分可能是后续（你现阶段可能没涉及）
- 数据资产域：企业的第三方信息 (专利、软著、工商变更、商标) 属于长期的客户画像数据
2. 业务过程 (Business Process)
对应你业务场景的重要过程可以列出：
- 线索采集过程
- 从企查查等第三方平台爬虫 /采集企业 +联系人 +联系方式 +属性
- 数据导入 & 校验（是否重复、是否新的公司 /联系人）
- 企业评分 / 分级过程
- 业务规则 /模型对企业进行评分 /风险 /价值分类
- 标签 (分类) 赋予
- 打电话 /销售跟进过程
- 业务人员拨打电话给联系人
- 电话沟通、洽谈记录、对方结果 (接通、不接、标签更新)
- 对联系人 /电话 /企业贴标签 (负责人 /无效 /无意向等)
- 标签管理 / 更新过程
- 给联系人 /电话贴标签 (add/modify/remove)
- 标签历史记录 (谁、何时贴 /删除)
- 标签状态 (最新标签)
- 潜在客户转化 /成交过程（如果未来有）
- 洽谈成功成为项目负责人 /客户
- 生成合同 /订单 /项目
3. 关键活动 (Key Activities)
在上述业务过程中，每个过程又可以细化关键活动：
- 线索采集
- 爬虫抓取企业基础信息
- 抓取工商、专利、软著等补充数据
- 清洗和去重（对公司名 /信用代码去重）
- 新公司 /联系人写入数据库
- 企业评分
- 执行评分模型（可能是每天 /每周批量跑）
- 规则引擎 /模型输出分数
- 持久化评分结果 (score +等级)
- 拨打电话
- 业务人员拿到线索拨号
- 拨打记录 (打通 /未接 /拒接)
- 通话内容记录 /结果 (是否需要后续跟进)
- 更新联系电话状态 (无效 /有效)
- 标签贴标
- 业务人员 /系统标记联系人角色 (负责人 / 非负责人)
- 标记电话号码无效
- 删除或修改标签 (譬如之前标记错误)
- 记录标签操作历史
- 转化 /成交
- 确认对方是项目负责人 /有意向
- 生成转化记录
- 业务落地 (签单 /项目启动)
三、把这些业务域 /过程 /活动映射到你的数据模型 (维度 /事实)
结合你前面说你已经有 维度表 (企业 /联系人 /联系方式 /第三方数据) + 事实行为 (电话 +标签)：
- 线索采集过程：虽然是一个过程，但你这里更多把采集结果落成维度 (企业、联系人、第三方数据)。这个过程 不需要单独事实表（除非你要追踪每一次“爬虫行为”的统计 /失败 /成功）
- 评分 /分级 (Business Process) → 事实表 Fact_Scoring，记录每一次评分活动 (model version, 时间,分数)
- 拨打电话 → 事实表 Fact_Call (一次拨号一次记录)
- 标签贴标 → 事实表 Fact_Tag_Assignment (记录标签历史) + 最新标签状态维度 /宽表
- 转化 /成交 → 事实表 Fact_Conversion（如果有该业务阶段）
四、对比 “家庭聚餐”类比 + 实际建模对你的帮助
| 类比 (家庭聚餐) | 你业务建模 | 帮助 /启发 |
|---|---|---|
| 买菜 /做菜 /布置 /结账 | 线索采集 → 拨号 /洽谈 → 标签 → 成交 | 把复杂业务拆成阶段 (domain + process)，更容易设计数据模型 +分析指标 |
| 家庭成员分工 (妈妈 /爸爸 /孩子) | 不同系统 /角色 (爬虫 /数据人员 /业务 /销售) | 明确不同“角色”的责任 (谁采集、谁评分、谁打电话) → 明确数据拥有方和流程边界 |
| 聚餐目标 (吃 +社交) | 公司目标 (获客 +转化) | 明确最终 KPI (线索量、接通率、转化率) → 有针对性设计事实 &指标 |
五、基于这个理解，对你之前建模建议的小补充：
- 如果你愿意追踪采集质量：可以考虑给 “线索采集” 这个过程加一个事实表 (比如 Fact_Crawl)，记录每次爬虫跑批次、成功公司数、新增公司数、失败原因等。这样可以监控 “采集层面” 的健康和效率。
- 标签 “生命周期” 建模：正如你说标签定义表 + delete_flag +标签记录，你确实是做成一个“标签维度 +标签事实”体系，这完全符合 “业务域 +过程 +关键活动” 的思路。类比家庭聚餐就是 “贴标签”这一活动，就像 “布置餐桌” 是聚餐流程中的一个环节。
- 分等级 / 评分：这个是非常典型的 “周期性过程 (periodic snapshot)” — 定期给每个企业打分 /分类，这个过程是你业务分析、CRM 优先级、运营决策的重要基础。
六、小结 +建议
- 你拿 “家庭聚餐” 这个比喻本身思路是对的，把业务拆域、拆过程 + 拆关键活动非常清晰。
- 现在你可以 把这个类比具体映射回数据建模（如上面的表格所示），然后把它当做和业务人员 /管理层对齐的讲模型。
- 在这个基础上，你的数据事实 +维度设计 (评分事实、通话事实、标签赋值事实) 是非常合理、也是 “业务过程” 驱动型设计。
基于这个家庭聚餐类比 +你当前数仓阶段，画出一个完整的 逻辑 BPMN（或业务过程图） + 数据模型 ER 图，然后给出建模建议
一、逻辑业务流程（BPMN风格，文字版）
┌───────────────┐
│ 第三方数据采集 │ ← 企查查/专利/软著/工商数据
└───────┬───────┘
│
▼
┌───────────────┐
│ 数据清洗与去重 │ ← 校验公司名/信用代码，过滤重复
└───────┬───────┘
│
▼
┌───────────────┐
│ 企业 & 联系人导入 │ ← ODS 层，维度表初始数据
└───────┬───────┘
│
▼
┌───────────────┐
│ 企业评分/分级 │ ← 周期性调度
└───────┬───────┘
│
▼
┌───────────────┐
│ 分配给业务人员 │
└───────┬───────┘
│
▼
┌───────────────┐
│ 拨打电话洽谈 │ ← 业务过程核心事实
└───────┬───────┘
│
▼
┌───────────────┐
│ 标签更新 │ ← 联系人/电话标签，如无效/项目负责人/非本公司
└───────┬───────┘
│
▼
┌───────────────┐
│ 客户转化/成交 │ ← 后续可选
└───────────────┘
对应“家庭聚餐”类比：
- 第三方数据采集 = 买菜
- 数据清洗/导入 = 准备食材
- 企业评分/分级 = 配菜/切菜
- 拨打电话 = 做菜 /布置餐桌
- 标签更新 = 调味/摆盘
- 成交 = 聚餐完成/吃饭
二、ER图设计（核心维度 +事实）
┌────────────────────────┐
│ Dim_Company │
│ company_id PK │
│ name │
│ credit_code │
│ ...其他企业属性 │
└───────────┬────────────┘
│ 1
│
│ *
┌───────────▼────────────┐
│ Dim_Contact │
│ contact_id PK │
│ company_id FK │
│ name │
│ position │
│ ... │
└───────────┬────────────┘
│ 1
│
│ *
┌───────────▼────────────┐
│ Dim_Contact_Phone │
│ phone_id PK │
│ contact_id FK │
│ phone_number │
│ type (mobile/fixed) │
│ status (latest) │
└────────────────────────┘
┌────────────────────────┐
│ Dim_Tag │
│ tag_id PK │
│ tag_name │
│ tag_type │
│ is_deleted │
└────────────────────────┘
┌────────────────────────┐
│ Fact_Call_Record │
│ call_id PK │
│ phone_id FK │
│ contact_id FK │
│ company_id FK │
│ call_time │
│ result (接通/未接/拒绝)│
│ operator │
└────────────────────────┘
┌────────────────────────┐
│ Fact_Tag_Assignment │
│ assignment_id PK │
│ contact_id / phone_id FK │
│ tag_id FK │
│ action_type (add/update/remove) │
│ operator │
│ action_time │
└────────────────────────┘
┌────────────────────────┐
│ Fact_Scoring │
│ scoring_id PK │
│ company_id FK │
│ score_value │
│ score_grade │
│ model_version │
│ score_time │
└────────────────────────┘
┌────────────────────────┐
│ Fact_Conversion │
│ conversion_id PK │
│ company_id FK │
│ contact_id FK │
│ conversion_time │
│ amount │
└────────────────────────┘
ER图说明：
- 维度表（Dim）
- 企业、联系人、联系方式、标签
- 第三方数据（专利/软著/工商变更/商标）可建单独维度表，统一 company_id
- 标签维度表存放标签字典，删除逻辑用
is_deleted
- 事实表（Fact）
- 拨打电话 Fact_Call_Record
- 标签操作 Fact_Tag_Assignment
- 企业评分 Fact_Scoring（周期性快照）
- 成交 /转化 Fact_Conversion
- 事实表与维度表关系
- 联系人/电话/企业都通过 FK 关联
- 标签通过 tag_id 关联维度
- 分级/评分/转化通过 company_id FK
三、建模建议
- 维度表
- 企业/联系人/联系方式/标签/第三方采集信息
- 存最新状态，方便业务快速查询
- SCD（慢变维）1/2型可视情况使用
- 事实表
- 所有业务动作（评分、打电话、标签操作、转化）都做事实表
- 保留历史，可做趋势分析、漏斗分析、AI建模
- 标签管理
- 保留历史事实 + 最新状态维度
- delete_flag = 1 表示标签逻辑删除，但历史记录不删除
- 周期性事实
- 分级/评分属于周期性事实表（Periodic Snapshot Fact）
- 电话/标签属于事务型事实表（Transactional Fact）
- 指标设计思路
- 接通率 = Fact_Call_Record (接通数量 / 总拨打数量)
- 无效号码比例 = Fact_Tag_Assignment + Dim_Tag ("号码无效")
- 企业价值趋势 = Fact_Scoring
- 标签转化效果 = Fact_Tag_Assignment + Fact_Call_Record