3. 主数据治理工程的组织与角色

药物研发主数据治理不是IT部门单独能完成的项目，它横跨临床、注册、生产、质量、供应链和IT多个职能。一个化合物编号在早期发现阶段由研发人员创建，进入临床阶段后被临床数据管理员引用，申报时又被注册事务人员映射到法规术语，上市后还要与生产批号、供应链物料编码对齐。如果没有清晰的组织与角色分工，主数据就会在跨部门传递中不断被“本地化改写”，最终形成同一对象多个版本的局面。本节围绕治理委员会、数据所有者、数据管理员以及IT与业务的协同模式展开，并给出RACI矩阵在药物研发场景中的落地方法。

三层治理组织：决策、拥有、执行

主数据治理组织通常分为三层。最上层是数据治理委员会，由研发、注册、质量、生产、IT等职能的负责人或授权代表组成，职责是批准主数据标准、裁定跨域争议、分配治理资源、审批重大变更。委员会不处理日常数据问题，它解决的是“标准该不该改、由谁负责、优先级如何排”这类决策问题。中间层是数据所有者（Data Owner），通常是某一主数据域的业务负责人，例如化合物主数据的所有者可能是发现研究负责人，临床受试者主数据的所有者可能是临床运营负责人。数据所有者对本域主数据的完整性、准确性和合规性负最终责任，负责审批本域的数据标准与关键变更。最下层是数据管理员（Data Steward），是日常执行角色，负责数据创建、审核、清洗、去重、映射维护和问题上报。数据管理员可以是专职，也可以由业务骨干兼任，但必须有明确的时间投入和考核依据。

三层之间不是简单的上下级关系，而是决策权、所有权和执行权的分离。委员会拥有标准审批权，所有者拥有业务裁定权，管理员拥有日常操作权。这种分离避免了“谁都能改、谁都不负责”的常见困境。

IT与业务的协同模式

在药物研发主数据治理中，IT与业务的关系容易走向两个极端：要么IT主导，业务被动配合，结果标准脱离实际；要么业务主导，IT只做工具支持，结果数据模型无法支撑系统集成。合理的协同模式是业务定标准、IT建能力、共同管质量。业务侧负责定义主数据的业务含义、必填字段、编码规则、审批路径和生命周期状态；IT侧负责将这些规则落地为数据模型、校验规则、工作流引擎、接口和权限控制；双方共同定义数据质量指标和监控方式。

具体协同可以落在几个机制上。第一，联合需求工作坊：每个主数据域启动时，业务和IT共同梳理字段清单、来源系统、消费系统和变更场景。第二，标准双签：数据标准文档由数据所有者和IT架构师共同签署，业务确认语义正确，IT确认可实现和可集成。第三，变更联合评审：任何主数据标准变更都经过业务影响分析和IT影响分析，避免单方面修改导致下游系统断裂。第四，质量联合运营：数据管理员和IT运维共同查看质量报表，业务判断数据是否可用，IT判断规则是否失效。

RACI矩阵在药物研发中的落地

RACI矩阵用四种角色描述每项活动的责任分配：R（Responsible）是实际执行者，A（Accountable）是最终负责人且每项活动只能有一个，C（Consulted）是事前被咨询者，I（Informed）是事后被通知者。在药物研发主数据治理中，RACI不能只停留在项目启动文档里，而要嵌入到具体的数据管理活动中。

以“化合物主数据新建与变更”为例，可以这样分配：数据管理员是R，负责在MDM系统中录入结构、活性、来源等字段并提交审核；化合物数据所有者是A，对数据的科学准确性和合规性负最终责任；IT数据架构师是C，在字段映射、系统接口和编码规则上提供咨询；临床数据管理员、注册事务代表和供应链计划员是I，在化合物主数据发布后获得通知，以便更新各自系统中的引用。再以“主数据标准变更”为例：数据所有者是R，提出变更申请并说明业务理由；治理委员会是A，审批是否变更；IT架构师和下游系统代表是C，评估技术影响；所有数据管理员是I，接收变更后的操作规范。

落地RACI时最常见的错误是把A分配给多人，导致无人真正负责；或者把C和I混用，造成要么过度打扰、要么关键方不知情。建议每个主数据域维护一张活动级RACI表，并在MDM工作流中把R、A、C、I映射为具体的审批节点、通知节点和咨询任务。这样RACI就不是一张静态表格，而是系统里可执行的责任链。

关键角色的能力要求与常见误区

数据管理员是治理体系中最容易被低估的角色。一个合格的药物研发数据管理员需要同时具备三方面能力：理解本域业务语义，例如能区分化合物盐型、游离碱和母核的关系；熟悉主数据管理工具的操作，包括批量导入、匹配规则配置和变更单处理；具备跨部门沟通能力，能在临床、注册和生产之间协调字段口径。如果只把数据管理员当作“录数据的”，治理体系就会在源头失去质量控制能力。

数据所有者的常见误区是“挂名不履职”。所有者必须真正参与标准审批和争议裁定，否则委员会就会被迫处理本应在业务层解决的问题。建议为每个主数据域设定所有者例会机制，例如每月一次，审议数据质量报表、待决变更和跨域映射问题。IT侧的常见误区是“先建系统再谈标准”，正确顺序是先明确业务语义和编码规则，再设计数据模型和接口，否则系统上线后仍需大量返工。

从组织到执行：一个可运行的治理节奏

组织角色确定后，还需要配套的运行节奏。建议采用“周度执行、月度审议、季度决策”的三级节奏。周度由数据管理员处理日常数据创建、清洗和问题工单，IT运维监控接口和校验规则运行状态。月度由数据所有者主持本域治理例会，审议数据质量指标、未关闭问题和变更申请。季度由治理委员会召开跨域会议，审批标准修订、资源投入和优先级调整。每个层级都有明确的输入、输出和决策权限，避免所有问题都向上堆积。

在药物研发场景中，还可以把主数据治理与项目里程碑绑定。例如在IND申报前完成化合物、靶点、适应症主数据的冻结和一致性检查；在临床数据库锁库前完成受试者、研究中心、访视主数据的核对；在NDA/BLA申报前完成注册术语、生产场地、物料编码的映射验证。这样治理就不是额外负担，而是嵌入研发流程的质量控制点。

最后需要强调，RACI矩阵和三层组织不是一次性设计文档，而是需要持续维护的治理资产。每当新增一个主数据域、引入一个新系统或发生组织调整，都应重新审视角色分配和RACI表。只有让责任链与业务变化同步演进，主数据治理才能真正支撑药物研发的跨域协同和数据可信。