4、数据资产分类体系:业务域划分、数据主题分类、数据资产分级、标签体系设计

数据资产分类,说白了就是给企业数据做「户口本」。

我见过太多团队,一上来就埋头建表、写ETL,结果数据越堆越多,最后谁也找不到想要的东西。你想想看,一个没有分类体系的资产目录,跟一个没有书架的图书馆有什么区别?

这一章,我们就来拆解分类体系的四个核心环节。嗯,这也是我在多个项目中反复打磨出来的套路。

核心观点:分类体系不是一次性的「贴标签」动作,而是一个持续演进的「数据地图」骨架。业务域决定边界,主题分类决定内容,资产分级决定权重,标签体系决定检索效率。

数据资产分类体系全景图 数据资产分类体系 业务域划分 数据主题分类 数据资产分级 标签体系设计 按业务线切分 如:营销域、供应链域 财务域、人力域 按数据内容归类 如:客户主题、产品主题 交易主题、组织主题 按敏感度/价值分级 如:L1公开、L2内部 L3敏感、L4绝密 按检索维度打标 如:业务标签、技术标签 管理标签、安全标签 四层递进:边界 → 内容 → 权重 → 检索

4.1 业务域划分:先画边界,再谈治理

业务域划分,是分类体系的第一步。它的核心逻辑很简单:数据从哪里来,就归到哪里去。

我个人习惯,先跟业务部门聊一圈,搞清楚他们到底在做什么。比如营销部管获客、供应链部管采购和物流、财务部管核算和预算。每个部门就是一个天然的业务域。

我的经验:业务域划分不要超过10个。太多就碎掉了,太少又不够精细。一般企业6-8个域比较合适。我曾经见过一个客户分了22个域,结果数据目录比数据本身还难维护。

常见的业务域划分参考:

业务域 典型数据范围 数据所有者
营销域 线索、活动、渠道、投放 CMO / 营销总监
销售域 客户、商机、合同、订单 销售VP
供应链域 采购、库存、物流、供应商 供应链总监
财务域 预算、核算、应收应付、税务 CFO
人力域 员工、组织、薪酬、考勤 HR VP
产品域 产品定义、BOM、版本、定价 产品总监

这里有个坑,我提醒一下:跨域数据怎么办?比如「客户订单」既涉及销售域,又涉及财务域。我的做法是:主数据归主域,引用数据通过关联关系打通,不要重复归属。

4.2 数据主题分类:把数据装进「抽屉」

业务域划分完了,接下来要解决的是:每个域里的数据,到底长什么样?

数据主题分类,就是把同一类业务含义的数据归到一个主题下。比如「客户」主题下面,可以有客户基本信息、客户信用信息、客户联系记录等等。

关键原则:主题分类是「面向业务」的,不是「面向系统」的。不要按数据库表名来分,要按业务概念来分。比如「客户」主题,不管数据存在CRM还是ERP里,都归到同一个主题下。

我建议的主题分类结构:

  • 一级主题:客户、产品、交易、组织、资产、事件……(6-8个)
  • 二级主题:在一级下细分,比如「客户」下分「个人客户」「企业客户」「潜在客户」
  • 三级主题:按数据实体细分,比如「个人客户」下分「基本信息」「联系方式」「行为偏好」

举个例子,一个零售企业的主题分类可能是这样:

客户主题
  ├── 个人客户
  │   ├── 基本信息
  │   ├── 联系方式
  │   └── 消费行为
  ├── 企业客户
  │   ├── 工商信息
  │   └── 合作记录
  └── 潜在客户
      ├── 线索来源
      └── 跟进记录

产品主题
  ├── 商品信息
  │   ├── 基础属性
  │   └── 库存信息
  └── 价格体系
      ├── 定价策略
      └── 促销活动

嗯,这里要注意:主题分类的层级不要太深。我一般控制在三级以内,超过三级,业务人员就记不住了。

4.3 数据资产分级:给数据贴上「安全锁」

数据资产分级,说白了就是回答一个问题:这份数据丢了,公司疼不疼?

我在项目中遇到过,有些团队把所有数据都标成「绝密」,结果等于没分级。分级一定要有区分度,让不同敏感度的数据得到不同级别的保护。

避坑指南:我曾经见过一个金融客户,把客户姓名和身份证号都标为L3,但把交易金额标为L2。结果审计时发现,交易金额才是洗钱风险最高的数据。分级一定要结合业务风险,不能只看数据本身。

通用的四级分级模型:

级别 定义 典型数据 访问控制
L1 公开 可对外公开 产品介绍、公司地址 无需认证
L2 内部 仅限内部使用 内部报表、组织架构 员工认证
L3 敏感 泄露有负面影响 客户联系方式、交易明细 按需授权
L4 绝密 泄露有重大风险 身份证号、银行卡号、密码 严格审批+加密

分级不是一成不变的。我建议每半年做一次分级复审,因为业务场景在变,数据的敏感度也在变。

4.4 标签体系设计:让数据「好找」才是硬道理

分类和分级解决了「数据是什么」「数据多重要」的问题,但用户找数据时,往往需要更灵活的检索方式。这时候,标签体系就派上用场了。

标签和分类的区别是什么?分类是树状的,标签是网状的。一个数据资产只能属于一个分类,但可以打多个标签。

我的习惯:标签体系分四类来设计——业务标签、技术标签、管理标签、安全标签。每类标签解决一个维度的检索需求。比如业务人员想找「最近三个月创建的客户数据」,就可以通过「业务标签=客户」+「管理标签=2024Q4」来快速定位。

标签设计的原则:

  • 原子化:每个标签只表达一个含义,不要搞复合标签。比如「高价值客户」不如拆成「客户等级=高」+「客户类型=个人」
  • 可枚举:标签值尽量用枚举,不要用自由文本。比如「数据来源」标签的值可以是「CRM」「ERP」「外部采购」,而不是随便填
  • 动态更新:标签不是一成不变的。比如「数据质量=高」这个标签,应该随着数据质量监控结果自动更新

一个实际的标签体系示例:

业务标签
  ├── 所属业务域: {营销, 销售, 供应链, 财务, 人力, 产品}
  ├── 业务场景: {客户分析, 库存盘点, 财务核算, 绩效考核}
  └── 数据用途: {报表, 分析, 模型训练, 接口服务}

技术标签
  ├── 存储类型: {MySQL, Hive, HBase, Elasticsearch, 对象存储}
  ├── 更新频率: {实时, 小时级, 天级, 周级, 月级}
  └── 数据格式: {结构化, 半结构化, 非结构化}

管理标签
  ├── 数据所有者: {张三, 李四, 王五}
  ├── 创建时间: {2024Q1, 2024Q2, 2024Q3, 2024Q4}
  └── 数据状态: {在用, 归档, 待清理}

安全标签
  ├── 分级: {L1, L2, L3, L4}
  ├── 脱敏要求: {需要, 不需要}
  └── 合规类型: {GDPR, 个人信息保护法, 无特殊要求}

最后说一句:标签体系一定要有自动化支撑。纯靠人工打标,第一天还行,三个月后就没人维护了。我建议在数据采集或入湖阶段,通过元数据自动抽取规则来生成技术标签和管理标签,业务标签和安全标签可以走半自动——系统推荐,人工确认。

总结一下:业务域划分是「地图的边界」,数据主题分类是「地图上的区域」,数据资产分级是「区域的重要性标注」,标签体系是「地图的搜索引擎」。四者缺一不可,共同构成企业数据资产目录的完整骨架。