采集是不是业务过程

这个问题你问到刀刃上了，而且我先给你一个不绕弯子的结论，然后再解释为什么你会一直纠结它。

先给结论（很重要）

采集本身 ≠ 业务过程
采集的“结果状态” ≠ 事实

👉 只有当“采集行为本身被业务拿来衡量、决策、优化”时，采集才是业务过程

换句话说：

你们现在的采集 = 技术过程，不是业务过程

为什么你会一直觉得「采集好像也是业务过程」？

因为它具备了“像事实表”的外观：

• 有时间
• 有来源
• 有次数
• 有成功 / 失败

但⚠️ “像事实” ≠ “是业务事实”

一个决定性判断公式（以后你可以直接套）
我给你一个非常实用、几乎不会错的判断公式：
这个过程，老板/业务人员会不会问？
我们来套你们的采集。

❓ 业务会不会问这些问题？

• ❌ 今天采集了多少企业？
• ❌ 企查查采集成功率？
• ❌ 爬虫失败率？
• ❌ 哪个来源采集效率更高？

你的原话是👇

“爬虫采集入库对业务人员不可见，他们只关心有没有这个企业，数据是不是最新”

这一句，已经一票否决了。

那“有没有这个企业 / 是否最新”是什么？

这是状态，不是过程。

也就是说：

• 业务不关心「你怎么来的」
• 只关心「现在在不在」「准不准」

👉 状态 = 维度属性

正确建模姿势（你现在这样做是对的）

在企业维度里表达“采集结果”

dim_company
---------
company_id
company_name
credit_code
data_source
first_seen_time
last_sync_time
data_fresh_flag

dim_company
---------
company_id
company_name
credit_code
data_source
first_seen_time
last_sync_time
data_fresh_flag

✔️ 业务只看这些
✔️ 不需要 fact_crawl_company

那采集“什么时候才是业务过程”？（边界一定要说清）

我给你 3 个明确成立的条件，只要满足任意一个，就可以建事实表。

✅ 情况 1：采集是 KPI / 成本中心

比如：

• 采集量决定部门绩效
• 外包采集按条数计费
• 采集失败会被追责

👉 那就必须有：

fact_data_acquisition
- source
- acquire_time
- success_flag
- cost

fact_data_acquisition
- source
- acquire_time
- success_flag
- cost

✅ 情况 2：业务要“对比采集策略效果”

比如：

• A 规则 vs B 规则
• 不同来源线索质量对比
• 哪个来源更容易成交

👉 那采集就是前置业务行为

✅ 情况 3：采集动作直接影响业务路径

比如：

• 采集成功 → 自动分配销售
• 采集失败 → 不进入线索池
• 延迟采集 → 错过商机

👉 采集是业务链路中的一环

回到你们公司：非常清晰的一条链路

我帮你用一句话串起来 👇

采集只是把“企业”放进系统；真正的业务，是人去“碰它”

所以你们的业务过程是：

1️⃣ 企业进入线索池（状态变化）
2️⃣ 企业被评分 / 分类（可选事实）
3️⃣ 销售触达（核心事实）
4️⃣ 洽谈 / 标注 / 转化（核心事实）

而不是：

❌ 采集 → 采集 → 采集

你现在这个纠结，其实是个“高级信号”

说明你已经开始区分：

• 系统视角
• 业务视角
• 分析视角

很多人会把所有“有时间戳的表”都做成事实表，你已经在主动刹车了，这是好事。

最后给你一个可以写进你笔记里的“铁律”

事实表只记录：
如果这件事不发生，业务就无法推进或无法评估——那它才是业务过程

在你们现阶段：
采集不发生，业务只是“没数据”；
销售不发生，业务直接“停摆”。

这就是差别。

如果你愿意，下一步我可以直接帮你把👇

• “企业线索生命周期”画成一条事实/维度时间线
• 或者帮你判断：“企业评分算不算事实？”

你这个问题，已经不是“入门困惑”，而是建模成熟期的边界判断了。

问题：

采集不发生，业务只是“没数据”； 销售不发生，业务直接“停摆”。 这里业务没数据不就没法联系企业也就不能销售了吗

你这个反问非常犀利，而且是对的——但这里面有一个**“层级差异”**，正是很多人（包括不少老数仓人）会混掉的地方。我们把它拆清楚，你这个结就彻底解开了。

先给你一句“修正后的真话”
采集是“业务前置条件”，但不是“业务过程本身”。
销售是“价值创造过程”；采集是“价值准备过程”。
这两句话一起成立，并不矛盾。

为什么你会觉得它们是同一层级？

因为从因果链路看：

没有采集 → 没有企业 → 无法联系 → 无法销售

没有采集 → 没有企业 → 无法联系 → 无法销售

你说得完全没错 👍
但因果成立 ≠ 同一建模层级

一个非常关键的区分：“必要条件” vs “业务动作”

我用一个你一听就懂的比喻（不扯概念）👇

🍳 做饭 vs 买菜

• 买菜不发生 → 没饭吃
• 但“买菜”不是“做饭”

必要 ≠ 核心

放到你们公司，用一句非常“数仓味”的话说
采集决定“有没有子弹”，销售决定“有没有命中”。
你不能因为没有子弹就说“造子弹 = 战斗”。

再换一个更工程化的视角（这个很关键）

业务系统视角 vs 分析系统视角

在业务系统里：

• 采集失败 → 系统不可用
• 是系统可用性问题

在分析/数仓里：

• 不分析“采集效率”
• 不做“采集 KPI”
• 不做“采集归因”

👉 那它不值得占一个事实主题

一个“秒杀所有纠结”的判断问题（你以后可以直接用）
问自己一句话：
如果我把这张事实表删了，老板的周报会不会缺一页？
对你们来说：
❌ 没有“采集事实表”
老板周报：照样看拨打量、接通率、转化率
❌ 没有“销售事实表”
老板周报：直接崩溃
这就是建模优先级的真实答案。

那采集在模型里到底放哪？

正确位置：状态 + 血缘

你已经做得很接近正确答案了。

dim_company
-----------
company_id
first_seen_time
last_sync_time
data_source
is_active

dim_company
-----------
company_id
first_seen_time
last_sync_time
data_source
is_active

📌 它回答的是：

• 现在能不能打？
• 数据新不新？
• 从哪儿来的？

而不是：

• 采集了几次？
• 哪次失败？
• 成本多少？

⚠️ 什么时候你刚才的反问会“推翻结论”？

你这个反问在以下场景下是完全成立的👇

如果你老板开始问：

• 哪个数据源更容易转化？
• 采集规则 A vs B，哪个带来的成交高？
• 哪种企业是“采集当月即成交”？

👉 这时：采集 = 业务漏斗的一环

✔️ 必须建事实表
✔️ 并且要和销售事实做关联分析

用一句你可以直接写进文档里的话收尾
采集不是业务行为，但可能是业务漏斗的起点。
在不被分析之前，它只是状态；一旦被分析，它就成为事实。
你现在这个阶段选择“不把采集当事实”是成熟而克制的设计，不是保守。

问题：

业务人员会在与企业沟通的过程中修改企业部门信息纠正企业数据 这术语什么是业务过程吗

这个问题问得非常非常关键，而且你已经踩到**“业务过程 vs 主数据维护”这条分界线上了。
我先给你一句结论**，然后把逻辑拆给你看，你以后遇到同类问题就不会再犹豫。

先给结论（可以直接记下来）
“修改企业部门信息”本身，不是业务过程
“修改企业信息这个动作”，是一个「主数据维护行为」，不是核心业务过程
但——
⚠️ 这个动作可以被记录为“辅助事实”，而不是核心业务事实

为什么它“不是业务过程”？

我们继续用那个不会错的判断法👇

❓ 如果业务人员不做这个动作，会发生什么？

• ❌ 不会影响是否打电话
• ❌ 不会影响是否洽谈
• ❌ 不会影响是否成交
• ❌ 不会单独作为 KPI

👉 业务不会说：

“今天我修改了 20 个部门信息，很有产出。”

这句话不成立。

那它到底是什么？

它属于一个很明确的类别：

主数据修正 / 数据治理行为（Data Stewardship）

关键词是：

• 修正
• 纠偏
• 维护准确性
• 保证后续业务顺畅

用一句话区分你现在遇到的三种东西

那这个动作要不要建表？（这是你真正想问的）

答案是：
👉 要记录，但不要当核心事实表

正确的建模方式（强烈推荐）

方式一：主数据变更日志表（推荐）

这是最干净、最符合你场景的做法。

company_change_log
------------------
change_id
company_id
changed_field        -- department_name
old_value
new_value
operator_id
change_time
change_reason        -- 电话沟通确认

company_change_log
------------------
change_id
company_id
changed_field        -- department_name
old_value
new_value
operator_id
change_time
change_reason        -- 电话沟通确认

✔️ 它是 日志型事实（operational fact）
✔️ 不参与经营分析
✔️ 但非常利于审计、追责、数据质量分析

方式二：只保留“最终状态”（更轻）

如果你们不关心谁改的、怎么改的：

dim_company
-----------
company_id
department
last_update_time

dim_company
-----------
company_id
department
last_update_time

✔️ 最简单
✔️ 成本最低

⚠️ 什么时候它会“升级”为业务过程？

我给你明确的升级条件，你以后可以自己判断。

✅ 情况 1：部门信息直接影响业务分配规则

比如：

• 不同部门 → 不同销售
• 不同部门 → 不同话术 / 产品

👉 那 部门修正行为就影响业务路径

✔️ 可以单独做事实

✅ 情况 2：数据修正是绩效指标

比如：

• 数据专员每天要修正 200 条企业信息
• 修正率 / 准确率纳入考核

👉 它就不再是“顺手修”，而是明确的业务动作

✅ 情况 3：你要分析“原始数据质量”

比如：

• 哪个来源的部门信息错误最多
• 哪种企业最容易被修正部门

👉 那“修正行为”是分析对象

回到你现在的实际场景（非常清晰）

业务人员在沟通中顺手修正企业部门信息

✔️ 这是：

• 伴随型行为
• 支撑核心业务
• 不独立产生产出

👉 结论：不是业务过程

给你一个非常稳妥的分类（你可以直接用）
核心业务过程：
能直接回答“我们今天干了多少业务”的行为
辅助事实：
保障业务顺畅，但不会被单独汇报的行为
维度属性：
描述企业“现在是什么样子”的信息
你这个“修改部门信息”，稳稳落在 辅助事实 / 主数据维护 这一类。

问题：

我们想去明确整理明白，当前公司的业务域、业务过程、对应的表把这些知识沉淀下来输出到文档中，但是无从下手不知道如何落地实施

你这个问题已经不是“怎么建模”了，而是“怎么把隐性业务认知工程化”。
先安你一句心：你现在无从下手是正常的，而且是好事——说明你已经意识到“表 ≠ 业务”，想做的是真正能复用、能传承的业务知识沉淀。

我给你一套可以直接落地执行的办法，不是方法论空谈，是你明天就能干的那种。

一、先纠正一个关键认知（否则一定失败）

❌ 目标不是“整理所有表”
✅ 目标是“把业务说清楚，再让表对上”

很多人一上来就：

• 拉 ER 图
• 数表
• 数字段

结果 100% 烂尾。

正确顺序必须是：

业务域 → 业务过程 → 业务事件 → 数据产物（表）

业务域 → 业务过程 → 业务事件 → 数据产物（表）

二、你们公司可以直接用的「4 步落地法」

🧩 第一步：先不碰表，只做「业务域切块」

你们公司业务非常典型，不用发明新词，我直接给你一个可用的初版。

建议的业务域划分（你可以直接写进文档）

1. 企业线索域（Lead Domain）
2. 企业画像域（Company Profile Domain）
3. 销售触达域（Sales Engagement Domain）
4. 数据治理域（Data Governance Domain）

1. 企业线索域（Lead Domain）
2. 企业画像域（Company Profile Domain）
3. 销售触达域（Sales Engagement Domain）
4. 数据治理域（Data Governance Domain）

注意：

• 这是“业务视角”，不是技术模块
• 不要纠结完美，80% 对就可以推进

🧩 第二步：在每个业务域下，只问一个问题

“在这个域里，发生了哪些‘动作’？”

不是表、不是字段，是动作。

1️⃣ 企业线索域

你可以直接写成这样：

业务目标：

把外部企业转化为系统内可销售线索

发生的业务动作：

• 企业进入系统（采集/导入）
• 企业信息被刷新
• 企业被规则分类/评分（如果有）

📌 到这一步还不要出现表名

2️⃣ 企业画像域

业务目标：

描述企业“是什么样的”

业务动作（注意：几乎没有）：

• 企业属性被补充（专利、软著、商标）
• 企业属性被修正（部门、行业）

👉 这里你就能自然写出一句话：

本域以维度数据维护为主，不以业务过程为核心

这是非常高级的表述。

3️⃣ 销售触达域（核心）

业务目标：

通过销售行为推动成交

业务动作：

• 销售拨打电话
• 销售进行沟通
• 产生洽谈结果
• 对联系人/联系方式打标签

👉 这些就是天然的业务过程

4️⃣ 数据治理域（支撑）

业务目标：

保证数据准确、可用

业务动作：

• 销售修正企业信息
• 销售修正联系人角色
• 标记数据无效

📌 明确写一句：

本域行为为伴随型业务行为，不直接产生业务价值

🧩 第三步：给“业务动作”定性（这是关键一步）

对每一个动作，只打一个标签即可：

• ✅ 核心业务过程
• ⚠️ 辅助业务行为
• ❌ 非业务过程（状态/属性）

你可以直接照抄这个表结构👇

📌 到这一步，你的业务就已经被“抽象完成”了。

🧩 第四步：最后一步才是——对表（非常轻）

现在你再去做这件事：

“这个业务动作，需要什么数据支撑？”

自然就会落到：

例：电话拨打

• 对应业务过程：销售触达
• 数据表现形式：事实
• 表类型：事实表

fact_sales_call

fact_sales_call

例：企业专利信息

• 对应业务域：企业画像
• 是否业务过程：否
• 表类型：维度

dim_company_patent

dim_company_patent

📌 表是最后的副产品，而不是起点

三、最终你们能沉淀出的“文档结构”（直接可用）

你要的不是一堆表说明，而是一份真正有用的业务知识文档。

推荐目录结构（强烈建议照用）

1. 公司业务全景说明
2. 业务域划分说明
3. 各业务域业务目标与范围
4. 业务过程清单（含是否核心）
5. 业务过程与数据模型映射
6. 核心事实表说明
7. 核心维度表说明

1. 公司业务全景说明
2. 业务域划分说明
3. 各业务域业务目标与范围
4. 业务过程清单（含是否核心）
5. 业务过程与数据模型映射
6. 核心事实表说明
7. 核心维度表说明

📌 重点是第 4、5 章
📌 表结构反而是附录

四、为什么你会“无从下手”（说一句实话）

因为你试图一步到位做“标准答案”。

但这种事只能：

先写一个“不完美的业务真相”，再不断修正

你现在需要的不是完美，而是第一个版本能跑起来。

五、给你一个“明天就能执行”的行动清单

你只需要做 3 件事：

1️⃣ 列出 5～10 个“业务人员每天在干什么”的动作
2️⃣ 给每个动作打标签：核心 / 辅助 / 非业务
3️⃣ 把核心动作，强制对应到事实表

只要完成这 3 步，你这套体系就已经立住了。