数据采集是否算作业务过程

“数据采集（爬虫）”是否算作业务过程，取决于你治理的边界和对象。

根据你的初衷（治理入库后的业务系统数据），我的建议是：不建议将“爬虫采集”列入核心业务域，但需要将其作为“数据源头”进行元数据管理。

以下是针对你这种情况的逻辑梳理和架构建议：

1. 为什么“爬虫”通常不作为业务过程？

在数据治理的规范中，“业务过程”通常指企业内部价值链上的活动。

• 业务系统数据： 是由企业内部员工、客户或系统自动触发的逻辑（如：销售下单、客户签约）。
• 爬虫采集数据： 属于外部支撑数据。爬虫本身是一个技术动作，而不是一个创造业务价值的闭环流程。

如果你把爬虫逻辑（如：模拟登录、翻页、解析HTML）写进业务过程，会导致你的业务地图变得非常“重”，且混淆了业务逻辑与技术实现。

2. 推荐的治理路径：从“公海池”开始

既然你想做的是“采集入库之后”的治理，那么你的起点应该是这些数据进入数据库后的第一个业务节点。

你可以参考以下划分方式：

• 业务域： 市场营销域 或 获客域（公海数据本质上是为了转化）。
• 业务过程： 潜在客资入库（Lead Ingestion）。
• 关键活动：
  • 数据清洗/去重： 爬虫数据入库后的第一步校验。
  • 线索分配： 将公海数据分配给具体的销售或战区。
  • 线索转正： 客户从公海池进入私海池。

3. 如何定义“爬虫数据”与“库表”的关系？

虽然爬虫不是业务过程，但它是**数据血缘（Data Lineage）**的起点。在你的 ODS 资产记录中，可以这样处理：

1. 定义“数据来源”属性： 在你的 ODS 表元数据中，增加一个字段标注“来源系统 = 爬虫抓取”。
2. 建立映射关系： * 业务层： “公海客户管理”业务过程。
   • 逻辑层： “企业基本信息实体”。
   • 物理层： ods_spider_company_info（这就是你采集入库后的表）。

4. 实际操作建议

如果你一定要体现“采集”这个动作，建议将其定义为**“数据供给”层**，而不是“业务执行”层。

你的治理框架可以调整为：

• 源头（Source）： 爬虫采集（标记数据口径、频率、目标网站）。
• 业务域（Domain）： 市场公海。
• 业务过程（Process）： 线索孵化/客资管理。
• 关键活动（Activity）： 自动入库、标签加工、冲突检查（检查是否与现有存量客户重复）。

总结： 既然你关注的是“业务系统发生的事”，那就把爬虫看作一个**“外部供应商”**。你不需要治理“供应商是怎么生产零件的”（爬虫怎么爬的），你只需要治理“零件进库后怎么分类、怎么使用”（数据入库后的流转）。

这样划分，你的业务域、业务过程会非常清晰，直接指向你公司核心的业务运作。