【医药数据治理系列②】一张错误的患者表，让这家药企损失2亿——我们到底在哪里出了问题？

一个不是故事的故事

2019 年，某国内头部药企的商业团队在做一个关键决策：某个核心产品的区域推广资源要不要向华东倾斜。

依据是一份销售数据报告，显示华东的终端覆盖率在过去两个季度显著提升。

决策做了，资源倾斜了，结果第三季度华东达标率反而下滑。

复盘的时候，数据团队发现了问题：

那份报告里的"终端覆盖率"，在不同子系统里的定义不一样。

• 销售系统的口径：拜访过≥1次 = 覆盖
• CRM 系统的口径：有处方记录 = 覆盖
• 报告用的是两个系统数据拼接的，没有人注意到口径对齐问题

华东的数字好看，是因为那个季度华东区域加大了拜访频次（销售系统口径变好），但实际处方转化没有跟上（CRM 口径没变）。

这家公司为这次决策付出的机会成本，后来被内部估算为 2 亿出头。

这不是个例

在医药行业，这类问题比你想象中普遍。

我在和不同规模的药企打交道的过程中，见过各种版本的同一个问题：

数据有，但不可信；报告有，但结论错；系统有，但没人真正理解数据在哪里、经过了什么、到底代表什么。

这个问题有个正式的名字，叫数据治理（Data Governance）。

但这个词被讲烂了，开会的时候一提，大家就开始打哈欠。因为它通常被当成 IT 项目来讲，被当成技术债务来讲，被当成"花钱填坑"来讲。

我想换一种方式讲它：把数据治理讲成一个商业竞争力问题。

为什么医药行业的数据治理比其他行业难 3 倍

不是谦虚，是真的难。原因有三层。

第一层：数据源的碎片化程度极高

一家中等规模的药企，数据来源通常包括：

内部系统 ├── ERP（SAP / Oracle） → 财务、库存、采购 ├── CRM（Veeva / 国内定制） → 拜访、客户关系 ├── HIS 对接数据 → 医院处方（部分医院） ├── 经销商数据（月度上报） → 渠道库存、流向 ├── 市场调研（IMS/IQVIA） → 市场份额、竞品 └── 临床数据（EDC 系统） → 临床试验 外部数据 ├── 医保结算数据（部分省份） ├── 社交媒体舆情 └── 公开竞品数据

这些系统不是同一家供应商建的，不是同一年建的，不共享主数据，不共享 ID 体系。

一个"医院"，在 ERP 里是一个编码，在 CRM 里是另一个编码，在 IQVIA 数据里是第三个编码。

同一家医院，三个系统，三个 ID，没有映射表。

这就是为什么业务部门做跨系统分析，通常要等数据团队"清洗"两周——他们在手工做这件事。

第二层：监管要求的严格性是独特的

FDA 21 CFR Part 11（电子记录与电子签名），GxP 数据完整性规范，ICH E6 GCP 指南……

这些监管要求的本质，是要求数据在生命周期内可追溯、防篡改、有审计轨迹。

违反这些要求的后果不是罚款那么简单——是 Warning Letter，是临床试验数据不被认可，是上市申请失败。

2020年，FDA 对一家合同研究机构（CRO）发出 Warning Letter 的核心原因之一，就是数据完整性问题：原始数据被修改，但没有审计记录。

这个背景下，"数据治理"不是优化问题，是合规生死线。

第三层：数据使用者的多样性

同一份数据，可能同时服务于：

• 销售总监（要看 KPI 达成）
• 医学部（要看临床使用模式）
• 市场部（要看品牌表现和竞品对比）
• 注册部门（要看安全性信号）
• 财务（要看渠道库存和回款）

每一个用途对数据粒度、更新频率、口径定义的需求都不同。

没有治理的数据体系，结果就是：每个部门都有自己的 Excel，每个 Excel 里的数字都不一样，每次开会的前两个小时在对数。

数据治理到底是什么——用一张图说清楚

很多人第一次接触数据治理，会被各种框架图绕晕。

我把它简化成一个问题：一个数据资产，你能回答这 5 个问题吗？

┌─────────────────────────────────────────────────────────┐ │ 数据治理五问 │ ├─────────────────────────────────────────────────────────┤ │ 1. 它从哪里来？ （数据溯源 / Lineage） │ │ 2. 它代表什么？ （数据定义 / 元数据管理） │ │ 3. 它现在准确吗？ （数据质量 / 监控） │ │ 4. 谁有权用它？ （数据权限 / 安全） │ │ 5. 它变了吗？ （版本控制 / 变更管理） │ └─────────────────────────────────────────────────────────┘

文章开头那个故事里，"终端覆盖率"这个指标，第 2 问就答不上来——它到底代表什么？没有统一定义，没有人负责，没有文档。

这就是数据治理失败的最典型形态：不是数据丢了，是数据的意义丢了。

医药数仓建设的三个阶段

实际项目里，我把医药企业的数仓成熟度分成三个阶段。大多数企业在阶段一和阶段二之间。

阶段一：报表驱动期（大多数企业的现状）

特征：

• 数据分散在各业务系统，没有集中存储
• 数据团队的主要工作是写 SQL 拉数、做 Excel 报表
• 每次业务提新需求，数据团队从头抽数、手工处理
• 没有数据字典，口径靠"问人"
• 分析结果无法复现，换个人做出来数不一样

痛点体验：

“为什么上个月的数和这个月重新跑出来的不一样？”

“那个报表是小王做的，他离职了，没人知道逻辑。”

“这两个系统的数对不上，我也不知道以哪个为准。”

阶段二：数仓建设期

特征：

• 建立了分层的数据仓库（ODS → DWD → DWS → ADS）
• 有了统一的主数据（医院、医生、产品、区域）
• 核心指标有了口径文档
• BI 工具（Tableau、PowerBI、国内的帆软、永洪）上线
• 数据更新有了调度和监控

这个阶段最常见的坑：

把数仓项目当 IT 项目做，而不是当业务项目做。

结果是系统建好了，数据进去了，但业务不用。原因通常是：数据还是不准，或者指标定义业务看不懂，或者报表响应太慢，或者没有人推动业务习惯改变。

阶段三：数据资产运营期

特征：

• 数据有了"主人"（Data Owner），每个核心数据域有人负责准确性
• 数据质量有 SLA（Service Level Agreement），像对待软件系统一样对待数据
• 业务团队可以自助分析，不需要每次都提需求给数据团队
• 数据资产开始产生可量化的业务价值

这个阶段的标志性变化：

不再是"数据团队给业务提供数据"，而是"业务团队用数据做决策是常态，数据团队保障数据的可信度"。

一个真实的医药数仓分层设计

下面是一个我参与设计的、中等规模药企数仓的分层结构（脱敏）：

数仓分层架构（医药企业版） ┌────────────────────────────────────────────────────────────┐ │ ADS 应用数据层 │ │ 面向具体业务场景的宽表 / 指标 │ │ ├── ads_sales_performance 销售达成分析 │ │ ├── ads_market_share 市场份额报告 │ │ ├── ads_hcp_portrait 医生画像 │ │ └── ads_channel_inventory 渠道库存预警 │ ├────────────────────────────────────────────────────────────┤ │ DWS 数据汇总层 │ │ 轻度聚合，按主题域组织 │ │ ├── dws_sales_monthly_agg 月度销售汇总（产品×区域×渠道） │ │ ├── dws_visit_weekly_agg 周度拜访汇总（代表×客户×产品） │ │ └── dws_rx_daily_agg 日度处方汇总（医院×科室×产品） │ ├────────────────────────────────────────────────────────────┤ │ DWD 数据明细层 │ │ 清洗后的业务明细，口径统一 │ │ ├── dwd_sales_order_detail 销售订单明细（清洗后） │ │ ├── dwd_visit_record 拜访记录明细 │ │ ├── dwd_prescription_record 处方记录明细（脱敏） │ │ └── dwd_adverse_event 不良事件记录 │ ├────────────────────────────────────────────────────────────┤ │ DIM 维度层 │ │ 主数据，全局统一 │ │ ├── dim_product 产品主数据（含 ATC 分类） │ │ ├── dim_hospital 医院主数据（多系统 ID 映射） │ │ ├── dim_hcp 医生主数据（脱敏） │ │ ├── dim_territory 区域层级 │ │ └── dim_date 日期维度 │ ├────────────────────────────────────────────────────────────┤ │ ODS 原始数据层 │ │ 从源系统抽取，保留原始格式，不做业务加工 │ │ ├── ods_erp_sales ERP 销售流水（原始） │ │ ├── ods_crm_visit CRM 拜访记录（原始） │ │ ├── ods_distributor_flow 经销商流向（原始上报） │ │ └── ods_iqvia_market 市场数据（IQVIA 原始文件） │ └────────────────────────────────────────────────────────────┘

为什么分层？

最重要的原因不是技术原因，是责任归属。

• ODS 层坏了：是数据接入团队的问题
• DWD 层坏了：是数据清洗/口径定义团队的问题
• DWS/ADS 层坏了：是数据产品团队和业务团队共同的问题

没有分层，数据出问题的时候，你不知道在哪里出的，也不知道该找谁。

最难的不是技术：主数据治理的真相

在医药数仓项目里，技术通常不是最难的部分。最难的是主数据治理，尤其是医院和医生主数据。

举一个具体的例子。

"上海市第六人民医院"这家医院，在不同系统里可能叫：

ERP 系统： 上六院 CRM 系统： 上海六院 IQVIA 数据： Shanghai Sixth People's Hospital 经销商数据： 市六医院 医保数据： 上海市第六人民医院（金山分院） ← 这是另一家！

主数据治理的工作，就是把这些不同名字映射到同一个唯一标识，并且维护这个映射关系。

这件事没有一劳永逸的技术解法。模糊匹配、规则匹配、人工审核，三种手段必须结合。更重要的是，要有一个流程和人员配置，保证每次有新医院进系统、或者医院信息发生变化的时候，有人负责更新主数据。

这是组织问题，不是技术问题。

给业务负责人的 3 个具体建议

如果你是医药公司商业、医学或运营方向的负责人，以下三件事是你现在就可以推动的：

① 建立指标字典，把它当产品来维护

不是写一个文档放在网盘里。是像维护一个产品 PRD 一样，每个核心指标有：

• 中文名 + 英文名
• 口径定义（分子、分母、时间口径、地域口径）
• 数据来源（哪个系统、哪张表）
• 负责人（谁负责这个数字的准确性）
• 最后更新时间

这张表大概 30-50 个核心指标，每季度 review 一次。

② 下一次开会数字对不上，把它当 Bug 来追

大多数公司的现状是：开会数字对不上，然后大家说"这个下去再对一下"，然后就没有然后了。

建议换一种做法：像追 Bug 一样追数字差异——根因是什么？哪个环节出了问题？怎么防止下次再发生？

这个习惯，比上任何数据治理培训都有效。

③ 在数仓项目启动之前，先搞清楚三件事

很多公司在数仓项目启动的时候，直接跳到"选什么技术方案、选哪家供应商"。

建议先回答这三个问题：

1. 公司现在最痛的 3 个数据问题是什么？（具体的，不是"数据质量差"这种）
2. 这 3 个问题解决之后，哪个业务决策会被改善？
3. 谁来负责这些改善的落地？（不是 IT，是业务侧）

如果这三个问题答不清楚，建议不要急着立项。

附：代码视角——一个简单的数据质量检查器

（如果你是有技术背景的业务负责人，这段有用；纯业务背景可以跳过）

数据治理落地的第一步，通常是建立数据质量监控。以下是一个基础版的医药数据质量检查框架，可以直接用在日常数据流水线里：

importpandasaspdimportnumpyasnpfromdataclassesimportdataclass,fieldfromtyp