先拆一个具体业务
从“客服服务”开始。
师傅
“客服处理配送异常，用的是谁的数据？”
小白
“会员的数据。”
师傅
“从哪里来？”
小白
“门店订单和会员系统。”
师傅
“为什么处理？”
小白
“为了确认订单和完成配送。”
【 第 4 步 】
业务分析室
师傅：“访谈拿到了很多信息，现在不能把‘会员系统’笼统写成一条记录，而要按具体业务功能拆开。今天我们用九问分析法逐项分析数据处理活动：谁的数据、从哪里来、为什么处理、处理什么、怎样处理、谁能使用、流向哪里、保存多久、如何保护。
比如会员注册、门店下单、客服处理、配送和营销分析虽然都使用会员系统，但处理目的、字段和操作并不一样。评估时还要检查字段必要性和保存期限：某个字段即使已经存在于数据库，也不代表每一个业务功能都需要使用；
主系统规定了期限，也要继续看导出、备份和其他副本是否跟着执行。”
01 · 现场对话
业务分析室的知识任务
继续问处理什么
字段要和目的对应。
小白
“客服现在能看到姓名、手机号、详细地址、生日和会员等级。”
师傅
“配送异常需要生日吗？”
小白
“通常不需要。”
师傅
“那就把它列为字段必要性检查项。”
再看谁能使用
同一数据不代表人人都能访问。
小白
“普通客服能查询，主管还能批量导出。”
师傅
“再看权限是否和岗位目的匹配。”
小白
“如果普通客服也能导出全部会员数据，就要继续评估。”
最后看流向和期限
处理活动一直跟到副本。
小白
“配送信息还会发给物流公司。”
师傅
“这就是数据流向。”
小白
“保存期限还要看主库、导出文件和备份？”
师傅
“对。不要只看一个系统。”
02 · 小白做现场笔记
重要概念及注释
数据处理活动
- 正式含义
- 围绕具体业务目的，对数据进行收集、存储、查询、加工、导出、共享、删除等操作。
- 面包厂场景
- 同一个会员系统可以包含：会员注册 门店下单 客服售后 配送 营销分析这些功能的目的和字段都可能不同。
评估不是只看“哪个系统”，还要看“这个系统正在做什么业务”。
业务分析九问
- 每个具体业务都问九个问题：
- 谁的数据？ ↓ 从哪里来？ ↓ 为什么处理？ ↓ 处理什么字段？ ↓ 怎样处理？ ↓ 谁能使用？ ↓ 流向哪里？ ↓ 保存多久？ ↓ 怎样保护？这是第五模块最核心的业务分析框架。
一项数据处理活动，最终都要回答九个问题。
数据主体
- 正式含义
- 与数据相关的个人、组织、设备或其他对象。
- 面包厂场景
- 会员资料 → 数据主体主要是会员 员工账号和日志 → 数据主体可能涉及员工 供应商联系人 → 数据主体可能涉及供应商人员
数据主体回答：这份数据到底和谁有关。
处理目的
- 正式含义
- 组织为什么需要执行某项数据处理活动。
- 面包厂示例
- 配送业务目的：把面包送到客户指定地址那么需要检查：姓名 手机号 配送地址是否与这个目的相关。
先知道为什么用数据，才能判断应该用多少数据。
字段必要性
- 正式含义
- 检查每一个数据字段是否与当前具体业务目的直接相关。
- 面包厂场景
- 客服处理配送异常：订单号 手机号 地址可能有业务需要。
但：生日 完整会员画像 其他历史营销信息就需要继续确认。
系统里已经有这个字段，不代表当前业务一定要用这个字段。
保存期限
- 正式含义
- 检查数据为什么需要继续保存、保存多久、什么时候触发删除或其他处置。
- 评估路线
- 为什么保存 ↓ 系统设置多久 ↓ 什么时候开始计算 ↓ 什么时候触发到期 ↓ 到期怎样处理 ↓ 备份和导出副本是否一起处理教材明确要求同时检查数据库、日志、文件、备份和导出副本。
主数据库期限正确，还要继续看其他副本是不是一样。
使用人员与权限
- 正式含义
- 检查不同角色处理数据的业务需要与实际可访问范围是否一致。
- 面包厂场景
- 普通客服 → 订单 + 脱敏手机号 数据分析人员 → 汇总或去标识化数据 数据库管理员 → 技术维护权限数据库管理员拥有技术管理权限，并不自动表示其业务上需要查看全部会员内容。
有系统权限，还要继续问：业务上真的需要看到这些数据吗？
03 · 经验和难点
小结
这一站，小白使用九问分析法把客服业务拆成数据主体、来源、目的、字段、动作、人员、流向、期限和保护措施。最值得记住的经验是：评估数据处理活动要按具体业务功能分析，而不是把整个系统写成一条模糊记录。初学者最容易遇到的难点，是因为某个字段“系统里已经有”，就默认所有业务岗位都可以继续使用。