医药行业数据治理实战：网点分级管理规范方案

1. 数据治理实战：如何规范网点数据的分级管理

作为一名数据治理工程师，我最近刚完成了一个医药行业SAAS平台的网点数据重构项目。原始数据存在严重的分级混乱问题，经过两周的梳理和重构，最终形成了规范的两级分类体系。这个案例非常典型，相信对需要处理类似地域分类问题的同行会有参考价值。

先看原始数据的问题：所有网点被扁平化存储在一张表中，混杂了实际行政区划（如"重庆"）、特殊渠道（如"KA"）、线上平台（如"B端-药师帮"）和模糊分类（如"其他"）。更麻烦的是，部分分类存在业务数据关联，不能简单删除或合并。下面我会详细拆解整个治理过程的关键步骤和决策逻辑。

2. 原始数据分析与问题诊断

2.1 数据结构现状审计

原始数据采用单级编码结构，主要包含三个字段：

• 代码（如01、32、50等）
• 名称（如"重庆"、"香港"、"B端-药师帮"等）
• 简称（如"重庆市"、"海外"等）

通过抽样检查发现三个典型问题：

1. 分类维度混乱：同时包含地理行政区划（省市级）、销售渠道、客户类型等多种分类标准
2. 数据冗余："海外"分类下既有具体国家（美国、越南），又有笼统的"国外地区"
3. 业务耦合：异常分类如"第三终端部"在销售发票、订单等核心业务表中存在大量关联记录

关键发现：通过统计各异常分类在业务表中的引用次数，确认"KA"、"第三终端部"等特殊分类虽然逻辑不规范，但都是活跃业务数据，不能直接删除。

2.2 业务使用场景调研

与销售、财务部门沟通后，了解到这些"不规范"分类的实际用途：

• KA（Key Account）：指重点客户事业部管理的战略合作客户
• 第三终端部：专门负责基层医疗机构（社区医院、乡镇卫生院等）的销售团队
• 海外/国外地区：国际业务部使用的统一分类，实际业务中不需要细分到具体国家

同时发现报表系统已经存在大区划分（华东、华南等），但与行政区域存在包含关系冲突。例如：

• 福建同时出现在华东和华南大区
• 广西同时属于华南和华西
• 河南同时出现在华北和华西

3. 数据重构方案设计

3.1 分级标准制定

基于业务实际需求，确立两级分类体系：

• 一级分类（大区）：华北/华东/华南/华西/海外/线上/其他
• 二级分类（地区）：省级行政区划或特定业务单元

几个关键决策点：

1. 线上业务独立：将B端、C端电商平台从地域维度剥离，单设"线上"大类
2. 海外业务合并：不再区分具体国家，统一归为"海外"
3. 特殊业务保留："KA"、"第三终端部"等保留在"其他"类，避免影响历史业务数据

3.2 数据映射规则

建立新旧代码的转换对照表，核心规则包括：

实施要点：需要保留原始代码到新编码的映射关系，确保历史业务数据可追溯。

4. 技术实现过程

4.1 数据库结构调整

sql复制-- 新网点表结构
CREATE TABLE dim_network_node (
    node_id VARCHAR(6) PRIMARY KEY,  -- 新编码规则：1位类型+2位大区+2位顺序
    parent_id VARCHAR(3),           -- 所属大区代码
    node_name VARCHAR(50) NOT NULL,
    node_type CHAR(1) NOT NULL,     -- R地区/O线上/S特殊
    original_code VARCHAR(2)        -- 原始代码，用于数据追溯
);

-- 大区维度表
CREATE TABLE dim_region (
    region_id VARCHAR(2) PRIMARY KEY,
    region_name VARCHAR(10) NOT NULL
);

编码规则设计：

• 第一位：类型标识（1-地区，2-线上，9-特殊）
• 第二三位：大区代码（01华北，02华东等）
• 第四五位：顺序号

4.2 ETL处理流程

1. 数据清洗阶段：

   • 标准化省份名称（如"西藏自治区"→"西藏"）
   • 标记异常数据（如"部队"无业务关联）

2. 分类转换阶段：

   python复制def convert_category(old_code):
       if old_code in ONLINE_PLATFORMS:  # 电商平台
           return '2', 'ONLINE', old_code
       elif old_code in SPECIAL_UNITS:   # 特殊业务单元
           return '9', 'OTHER', old_code
       elif is_overseas(old_code):       # 海外地区
           return '1', 'OVERSEAS', '00'
       else:                             # 国内地区
           region = get_region_by_province(old_code)
           return '1', region, old_code
   

3. 数据验证阶段：

   • 检查每个原分类都有对应新编码
   • 验证业务关键字段（如销售区域）转换正确性
   • 对比转换前后数据总量和分布

5. 业务影响与迁移方案

5.1 历史数据处理

采用"双跑"过渡方案：

1. 保留原网点字段作为历史数据标识
2. 新增标准化网点字段用于新业务
3. 报表系统根据时间范围自动选择数据源

sql复制-- 订单表改造示例
ALTER TABLE sales_order ADD COLUMN std_region VARCHAR(6);
UPDATE sales_order SET std_region = 
    (SELECT new_code FROM network_mapping WHERE old_code = sales_order.region);

5.2 报表系统适配

主要修改点：

1. 大区汇总报表按新分类逻辑计算
2. 增加"线上/线下"分析维度
3. 历史数据查询增加原分类显示

踩坑提醒：财务部门的返利计算模块对"KA"分类有硬编码，需要单独处理兼容。

6. 经验总结与优化建议

6.1 关键注意事项

1. 业务连续性优先：对于存在活跃业务数据的"不规范"分类，不要强行合并或删除
2. 编码预留空间：新编码体系要预留足够扩展位，例如我们为线上平台预留了20个位置
3. 过渡期监控：上线后前三个月需每日核对新旧数据一致性

6.2 可优化方向

1. 属性扩展：增加GDP、人口等区域属性，支持更丰富的分析
2. 动态分级：考虑三级分类（大区-省-市），需评估业务实际需求
3. 自动化监控：建立数据质量检查规则，防止新增不规范数据

这次重构最大的体会是：数据治理不能纯粹追求理论上的规范，必须兼顾业务实际。比如"第三终端部"这个分类，从数据模型角度看应该拆分，但实际业务中它对应着独立的销售团队和考核体系，强行规范化反而会影响业务运作。好的数据治理方案应该像这件案例一样，在规范性和实用性之间找到平衡点。