负责人 欧阳未　·　状态 初稿　·　覆盖 99 个标书单元　·　 批注 6

1、数据标准规划要求

1.1　现状与治理目标

甲方的信息化底座已经成型：设计与工艺、生产计划与工单、质量检验、库存与物流、公文与合同流转、设备过程参数采集、在役装备远程运维各有系统承载，业务数据长期留存。真正的困难不在于缺系统，而在于同一个物理对象在不同系统里有不同的名字、不同的编码规则、不同的填写习惯，跨系统追一件事仍要靠人工对账。

这个问题在本项目中有三处具体表现，它们直接决定了数据标准规划的落点。

一是同一工序在不同车间有不同叫法。板材备料的工序链共 28 道，总工艺路线之下各车间再编本车间的工艺卡片，同一道工序在备料车间的卡片上与在结构件车间的卡片上名称可能不同，工序代码也不成体系。工艺类数据集要以工序为检索键组织样本，工序名称不统一，样本就无法按工序聚合。

二是图纸与工艺卡的配对关系没有可计算的键。历史图纸约 63 万张，每一张历史上都配有一张已审核签发的工艺卡片，这在数据集建设上是天然成对的监督样本，但配对关系存在于文件目录与人的记忆里，没有稳定的图号—卡片号对应标准。

三是指标口径分散。同一个「库存周转」在供应链口与财务口的算法不同，分母取期初期末平均还是取时点值、是否扣除项目专用占用，各部门各有习惯。决策数据问答场景要基于九个业务域与一套决策指标体系作答，口径不统一，同一问题会得到两个都「正确」的答案。

数据标准规划要交付的不是一本术语词典，而是一套能把上述三类不一致收敛下来、并且在后续系统改造与数据加工中持续生效的标准体系。

1.2　标准体系的总体构成

本项目的数据标准分五类：业务术语标准、主数据标准、参考数据标准、数据元标准、指标标准。五类标准之上有一部《数据标准管理办法》规定标准的制定、评审、发布、变更与废止程序；五类标准之下有一张《标准映射对照表》把标准项落到具体系统的具体字段。这一结构与招标文件要求输出的六份成果物一一对应（b1286）（b1287）。

五类标准的关系可以用一句话概括：业务术语管概念，主数据与参考数据管实例，数据元管字段，指标管算法。概念层统一了「叫什么」，实例层统一了「有哪些」，字段层统一了「怎么存」，算法层统一了「怎么算」。四层缺一层，上层标准落地时都会卡住。

图 1-1　数据标准体系的四层构成与三条落地通道。数据来源：招标文件第五章 3.2.6.1.1.2.5 第（1）至（6）项。

1.3　业务术语标准

1.3.1 术语标准的编制范围与方法

业务术语标准覆盖九个业务域：人力资源、研发设计、生产制造、仓储物流、财务管理、设备管理、采购管理、营销管理、质量管理（b1336）。编制目标是形成公司统一的业务术语标准，厘清业务名词的定义、业务含义与同义词（b1276）。每个域的术语从三个来源汇集。

第一个来源是现行业务文档。工艺规程、作业指导书、检验规范、管理制度、合同模板里反复出现的业务名词构成术语的主体。我方以文档解析工具批量抽取候选名词，按词频与共现关系排序，再由业务域对口部门确认。采用当期能力评测领先的通用大模型经统一网关接入完成候选术语的定义初稿与同义词聚类，模型可替换、可评测、可随代升级；定义的最终确认权在业务部门，模型输出只作为编制底稿。

第二个来源是系统字段与数据字典。企业资源计划、制造执行、质量管理、产品全生命周期管理等系统的字段中文名、注释与下拉选项是术语的实际使用形态，也是术语与字段映射的起点。

第三个来源是国家标准与行业标准。煤矿用刮板输送机、矿用链条、钢材牌号、焊接工艺、热处理工艺等领域已有成文标准，标准中的术语优先采用，企业自定义术语仅在标准未覆盖处设立并注明「企业自定义」。

1.3.2 术语卡的结构

术语统一的难处不在于把名词列成清单，而在于判定两个叫法是不是同一件事、由谁说了算、落到哪个字段与哪个指标上。术语卡的字段结构即围绕这三个问题设置。

每条术语以一张术语卡承载，字段结构如表 1-1。中文名称、英文名称、业务定义、业务含义、同义词五项对应招标文件对业务术语标准提出的定义、业务含义与同义词要求；禁用词与易混术语两项取自现场实情——同一个量在工艺卡片上写「装炉量」、在报工界面上写「投料量」、在台账里写「单炉重量」，不把已停用的旧称与近义而不同义的术语分开记明，归一时就会把本不相同的两件事并到一起。归口部门一项解决解释权归属，关联数据元与关联指标两项是术语标准与数据元标准、指标标准的接合点。

判定一条术语能否发布，看的是业务定义与同义词两格是否填实；追溯一条术语的权威性，看的是归口部门与版本状态两格。结构本身就是评审的检查项：定义写不出来、同义词列不清、归属部门认不下的术语，不进标准正式发布版，先入待议清单。字段齐备的术语卡构成后续三个落地场合与术语覆盖率抽样验收的共同基础。

表 1-1　业务术语卡字段结构

1.3.3 术语在三个场合的落地

招标文件要求术语在业务文档、系统字段、指标说明中落地应用（b1277）。这三个场合的落地方式不同，不能用一条措施覆盖。

在业务文档中落地，办法是把术语表嵌入文档模板。工艺卡片、检验规范、不合格品票、改造方案等模板的填写指引中，涉及标准术语的字段给出术语标识与正式名称，禁用词在模板校验时提示。对已归档的历史文档不做回改，只在数据加工环节做术语归一映射，映射关系记录在标准映射对照表中。

在系统字段中落地，办法是分新建与存量两条路径。新建或改造的系统，在设计评审时核对字段中文名是否取自术语标准，不一致的须说明理由；存量系统不强制改字段名，改的是数据汇聚层的映射配置，由映射把源字段名归一到标准术语。这一取舍的理由很直接：改源系统字段名要动业务逻辑与界面，代价与风险都高于在汇聚层做映射，而数据集加工与指标计算取的是汇聚层的数据。

在指标说明中落地，办法是指标卡的维度与度量名称强制引用术语标识。指标卡中出现未登记的业务名词时，指标无法通过评审发布。

1.3.4 规模与验收口径

术语标准的首批发布规模按九个业务域各 60 至 120 条估算，合计不少于 600 条，其中生产制造域与研发设计域因工序与工艺术语密集，条目数高于其他域。第二批在数据汇聚与指标建设过程中滚动补充。

验收口径设三条，均以可核查的抽样方式检验：

一是术语覆盖率。从四类数据集加工所实际用到的业务字段中随机抽样 200 项，检查其对应业务名词是否已登记在术语标准中。首批发布时的基线按抽样覆盖不低于 75% 设定，随滚动补充逐步接近全覆盖；未覆盖项列入下一批编制清单，这是本指标的回退路径。该指标的招标值、承诺值与设计值见表 1-12，测量方法、样本量、测量频次、计算公式与未达标处置见表 1-13。

二是同义词归并有效性。对抽样术语检查其同义词清单是否包含该名词在现行系统中的实际称法，遗漏一条计一次不符合，单批不符合超过 10% 则该域术语退回复审。

三是指标卡引用合规性。发布的指标卡中，维度与度量名称引用术语标识的比例逐步接近全部；未引用的指标卡在发布前退回修改。

1.4　主数据标准与全生命周期审批流程记录

1.4.1 主数据域的识别

招标文件对主数据提出的要求是补齐全生命周期审批流程记录，形成 DCMM 评审可查阅的证据材料（b1278）（b1279）。这一要求的实质是：主数据不只要有标准，还要有「谁在什么时候按什么依据批准了这条主数据」的留痕，否则 DCMM 评审时拿不出证据。

本项目识别的主数据域及其与数据集建设的关系见表 1-2。识别原则是：被两个以上业务系统共同引用、且其变更会影响跨系统一致性的基础实体，纳入主数据管理。

表 1-2　主数据域清单与管理重点

工序主数据是本项目新增的管理重点。甲方现状是总工艺路线与各车间卡片并行、工序代码不成体系，而工艺类与制造过程类数据集都以工序为聚合维度，因此工序主数据的建立不是治理的附带产物，而是数据集加工的前置条件。

1.4.2 主数据全生命周期流程与留痕节点

数据管理能力成熟度评审考查的不是主数据台账当前是否干净，而是每一条主数据的产生与变化是否经过授权、依据是否留存。一份整洁却无法说明来历的台账，在评审中拿不到相应等级。主数据管理因此须把状态流转与留痕绑定，使证据随流程自然沉淀，不靠事后整理。

主数据的生命周期定义为申请、审核、发布、变更、停用五个状态。每一次状态迁移产生一条不可修改的流程记录，记录内容构成 DCMM 评审的证据材料。五个状态的划分依据是主数据实际发生的授权事件：申请与审核分离，保证提报方与核定方不是同一主体；发布单独成态，使主数据有明确的生效时点供历史引用对齐；变更不另建编码而是回到发布，保留同一编码下的版本连续性；停用保留历史引用，不做物理删除，否则引用该编码的历史工单与工艺记录会断链。

图 1-2 上排是五态主链与变更回到发布的回边，中部横条列出每次状态迁移必须写入的八项要素，下方是这些记录在评审中的用途。判断留痕是否合格，看的是中部八项是否齐备、记录是否只追加不修改；按主数据编码即可调出该条数据的全部历史迁移，这正是评审所需的证据形态。

图 1-2　主数据五态流程与审批留痕节点。数据来源：招标文件第五章 3.2.6.1.1.2.5 第（2）项主数据要求。

1.4.3 历史主数据的审批记录补齐

现存主数据绝大部分是历史沉淀下来的，当初并无规范审批流程，记录无法凭空补造。我方采取的办法是追认与补证两步，并且把两者在证据包里分开标识，不混为一谈。

追认是对现行有效的历史主数据，由归口部门按当前标准做一次性确认，形成《历史主数据追认清单》，清单本身即一条有审批人、审批时间与审批意见的流程记录，记录类型标为「历史追认」。补证是对有原始依据可查的主数据，把原始依据（立项文件、图纸签发记录、合同、入库单等）作为附件挂到主数据上，记录类型标为「依据补录」。

两类记录与新建主数据的「正常流程」记录在证据包中分列统计。DCMM 评审时呈现的是真实状况：哪些有完整流程、哪些是追认、哪些有原始依据，而不是一份看起来全部合规、实际无法回溯的台账。追认与补证的覆盖比例按主数据域分别设定目标，首年以物料、工序、设备三个与数据集加工直接相关的域为重点，逐步接近全部现行有效主数据；未完成的域在诊断报告中列明并排入下一阶段。

1.4.4 主数据编码规则

编码规则按「分类码＋流水码」设计，分类码表达稳定属性，流水码不承载含义。这样做的理由是：把可变属性编进码里，属性一变就要改码，改码会打断历史引用。规格、材质、供应商一类会变的属性放在属性字段里，不进编码。

编码规则的具体位数与分类层级在现状评估阶段依据甲方现行编码体系确定，原则是尽量沿用现行有效编码、减少换码带来的历史数据映射成本。需要换码的，在标准映射对照表中保留新旧编码对应关系，历史数据按对应关系归一，原码作为别名保留可查。

1.5　参考数据标准与代码值域字典

1.5.1 管理范围的界定

招标文件要求明确参考数据的管理范围并识别各类参考数据的取值范围（b1280）（b1281）。参考数据与主数据的区别在于：主数据是业务实体，参考数据是对实体属性取值的约束集合。物料是主数据，物料分类代码是参考数据；设备是主数据，设备状态代码是参考数据。

本项目将参考数据按来源分三类管理，管控强度不同。

第一类是国家标准与行业标准代码。例如钢材牌号、焊接方法代码、计量单位、行政区划、币种。这类代码直接采用标准发布版，企业不自行增删，标准更新时按版本替换，替换过程保留旧版映射。

第二类是行业通用但无强制标准的代码。例如煤矿工作面类型、刮板输送机机型档位、链条规格档位。这类代码由我方整理候选集合，由甲方技术部门核定后作为企业参考数据发布。

第三类是企业自定义代码。例如工序代码、缺陷类型代码、不合格品处置方式、炉型代码、班组代码。这类代码数量最多、变化最频繁，也是数据集标签体系的直接依据，管控要求最严。

表 1-3 列出参考数据的首批管理清单示例，实际清单在现状评估阶段依据系统字典盘点结果确定。

表 1-3　参考数据首批管理清单（示例，实际范围以现场盘点为准）

1.5.2 取值范围的识别方法

取值范围不是拍出来的，是从现存数据里查出来、再由业务核定的。我方对每一类参考数据执行三步。

第一步是字典抽取。从源系统的字典表、下拉选项、枚举常量中抽取已定义的码值集合。

第二步是实际取值扫描。对业务表中该字段的实际取值做去重统计，统计结果与字典对照，得到三类差异：字典中有但实际未使用的码值、实际使用但字典中没有的码值（多为自由文本或历史脏值）、实际使用频次极低的码值。第三类往往是录入错误，需要逐一判定。

第三步是业务核定。把三类差异提交归口部门，确认哪些码值保留、哪些归并、哪些废止。核定结论形成代码值域字典的正式版本，同时产生两项副产物：废止码值的归并映射关系进入标准映射对照表，自由文本到标准码值的映射规则进入数据加工的清洗逻辑。

缺陷类型代码是这一方法价值最明显的例子。甲方质量管理系统中缺陷描述为自由文本，未与工艺参数关联。按上述三步，先对历史缺陷描述文本做聚类，得到候选缺陷类型，再由质量部门核定为代码体系，然后把历史文本按映射规则归一到代码。归一之后，缺陷才能作为标签与焊接参数流、热处理炉次档案对齐，质量类数据集的标注才有依据。

1.5.3 代码值域字典的结构与维护

代码值域字典按表 1-4 的结构维护。字典与数据元标准通过「值域引用」关联：数据元标准中声明该数据元引用哪一张码表，码表更新时所有引用该码表的数据元同步生效，不必逐个修改。

表 1-4　代码值域字典字段结构

码表变更走数据标准管理办法规定的变更流程。变更申请须附影响评估：哪些系统字段引用了该码表、哪些质量规则以该码表为值域、哪些指标以该码值为维度。影响评估由治理平台依据映射对照表与元数据血缘自动生成初稿，由申请人补充业务影响后提交评审。

1.6　数据元标准

1.6.1 数据元的六项规范

招标文件要求针对核心业务域制定数据元定义标准，明确数据元标识、名称、定义、类型、格式、值域等规范（b1282）（b1283）。本项目的数据元标准按 GB/T 18391 数据元规范的思路组织，每个数据元的属性集合见表 1-5。

表 1-5　数据元标准属性集合

这张表里有三个字段是把数据元标准与其他治理域串起来的关键。敏感级别把数据元接到安全分级标准，使权限与脱敏策略可以按字段粒度下发。质量规则把数据元接到校验规则库，数据元一发布，与之绑定的规则即进入稽核调度。来源系统与字段把数据元接到标准映射对照表与元数据血缘。没有这三个字段，数据元标准就只是一本不生效的词典。

1.6.2 核心业务域的数据元范围

数据元不追求把所有字段都标准化，那样投入大而收效低。本项目按两条判据筛选核心数据元：被两个以上系统或两个以上场景共同使用的字段，以及四类数据集加工所直接依赖的字段。

表 1-6 按业务域给出数据元的重点范围与估算条目数。估算依据是各域主干业务表的字段规模与跨系统引用情况，实际条目数在现状评估的数据资产盘点完成后确定。

表 1-6　各业务域核心数据元重点范围与估算条目

合计约 1370 条。这个量级与九个业务域、十余套源系统的规模相称；若现状评估后实际筛出的条目数显著低于此，说明筛选判据执行偏严，须复核是否漏掉了跨场景共用字段。

1.6.3 数据元与物理字段的映射

一个数据元可以对应多个系统的多个物理字段，这是现状的常态而非例外。装炉量在热处理群控系统、物联网与设备数据平台、制造执行系统里可能各有一个字段，名称、单位、精度都未必一致。映射要记录的不只是对应关系，还有转换规则。

映射关系的记录结构见本章第 8 节标准映射对照表。需要在此说明的是三类转换：单位换算（吨与千克）、精度取舍（保留两位小数的规则是四舍五入还是截断）、口径差异（装炉量是否含工装夹具重量）。第三类最容易被忽略，而它导致的数值差异远大于前两类。映射评审时，口径差异必须由业务部门明确取哪一个口径为标准口径，其余口径的数据按换算规则归一或标记为不可比。

1.7　指标标准

1.7.1 指标的四项要素与分层

招标文件要求制定指标标准，明确指标业务含义、统计口径、计算逻辑、维度与数据来源（b1284）（b1285）。这四项要素对应指标卡的四组字段。本项目把指标按原子指标、派生指标、复合指标三层组织，分层的作用是把口径冲突收敛到最底层解决。

原子指标是不可再分解的度量，直接对应一个数据元的聚合，例如「入库数量」「报工工时」「检验不合格件数」。原子指标的口径由其引用的数据元与聚合方式唯一确定。

派生指标是原子指标加上限定条件与时间周期，例如「本月备料工序报工工时」「钢材类物料当期入库数量」。限定条件只能引用已登记的维度与码值。

复合指标是多个原子或派生指标的运算结果，例如「库存周转天数」「一次交检合格率」。复合指标必须写明分子、分母各自引用哪个下层指标，以及分母为零时的取值约定。

这样分层之后，「库存周转」口径之争就落到可以讨论的位置上：争的不是指标本身，而是分母引用的是「期初期末平均库存金额」还是「期末时点库存金额」，是否扣除「项目占用库存」。两个口径都可以保留，但必须是两个不同标识、不同名称的指标，不能共用一个名字。

图 1-3　指标三层结构与口径向下追溯路径。数据来源：招标文件第五章 3.2.6.1.1.2.5 第（5）项指标数据要求。

1.7.2 指标卡结构

表 1-7 给出指标卡的字段结构。一张指标卡填完，招标文件要求的业务含义、统计口径、计算逻辑、维度与数据来源四项要素即齐备。

表 1-7　指标卡字段结构

「质量约束」一组字段回应的是甲方数据质量不均的现状。各系统数据质量参差，指标不能假定输入一律可用。指标卡声明依赖的质量规则后，指标计算时若来源数据未通过对应质量门限，指标值随附置信标记，在决策数据问答一类场景中随答案一并呈现。这一机制的回退路径是：数据质量不足以支撑该指标时，指标状态置为「暂不发布」，而不是给出一个看不出问题的数。

1.7.3 决策指标体系的衔接

招标文件在数据治理服务的总体要求中提出同步构建决策数据指标体系（b1225），并在通用场景中说明决策数据问答助手基于九个业务域与一套决策指标体系作答（b1759）。指标标准是这套体系的规范基础：决策指标体系中的每一个指标都须有指标卡，口径可向下追溯到数据元与源字段。

决策指标体系的指标选取、分层设计与问答场景的交互设计，在技术方案「五个通用场景验证方案」一节论述。本节交付的是指标标准与指标卡规范，两者的接口是指标卡：本节定义卡的结构与评审发布流程，场景侧按结构填卡并提出指标需求。

1.7.4 指标标准的首批范围

首批指标按九个业务域核定，规模估算见表 1-8。估算口径是每个业务域的核心管理关注点对应 8 至 20 个复合指标，每个复合指标平均牵出 2 至 4 个派生指标与 1 至 3 个原子指标。

表 1-8　首批指标规模估算

首批指标的筛选以决策数据问答场景的实际问句为线索：场景侧整理高频业务问句，逐句判断回答该问句需要哪些指标，由此得到的指标清单比自上而下设计的指标体系更贴合实际使用。未被问句牵出但管理上必需的指标另行补充。

1.8　标准映射对照表与标准落地机制

1.8.1 映射对照表的结构

标准映射对照表是五类标准与物理数据之间唯一的连接件，也是招标文件要求的六份输出之一（b1286）（b1287）。结构见表 1-9。

表 1-9　标准映射对照表字段结构

「不可比」是一个必要的映射类型。有些源字段与标准项在业务口径上确实无法换算——例如某系统的装炉量含工装夹具重量而标准口径不含，且该系统未单独记录夹具重量。这种情况下不应强行换算，而应标记为不可比，使用方据此决定是否采用该来源。把不可比的数据强行归一，错误会沉默地传到数据集与指标里。

1.8.2 标准落地的四个入口

标准发布之后要真正生效，需要四个入口上的机制，缺一个标准就会停在纸面上。

第一个入口是新建与改造系统的设计评审。数据模型设计、接口契约设计提交评审时，核对字段是否引用已发布数据元、枚举字段是否引用已发布码表、指标是否有指标卡。不一致的须在评审意见中说明理由并记录为例外，例外清单定期复核。

第二个入口是存量系统的改造清单。现状评估识别出的标准不一致项按影响面与改造成本排序，形成分批改造清单。排序原则是：影响四类数据集加工的优先、跨系统关联所必需的优先、改造只涉及汇聚层配置的优先于需要改动源系统的。

第三个入口是数据加工的入口校验。数据汇聚与加工任务在读入数据时按数据元标准做类型、格式、值域校验，按码表做值域归一，不符合的记录进入质量问题台账并按规则严重级决定是阻断任务还是标记放行。这是标准生效最强的一个入口，因为它直接作用在数据流上。

第四个入口是质量规则绑定。数据元标准中的类型、格式、值域、允许空值、唯一性五项属性可直接生成对应的质量校验规则，由治理平台自动派生规则草案，由数据质量管理员确认后入规则库。标准一发布，规则即生效，两者不会脱节。

1.8.3 标准的变更与版本管理

标准会变，变更管理的要求是让变更可控、可追溯、可回放。

变更申请须附影响评估，评估内容由治理平台依据映射对照表与元数据血缘自动生成初稿：哪些系统字段、哪些质量规则、哪些指标、哪些数据集加工任务引用了待变更的标准项。申请人在初稿基础上补充业务影响与过渡安排。

变更按影响面分三级审批。只影响单一业务域、不改变值域的，由该域归口部门审批；跨业务域或改变值域的，由数据治理管理层审批；涉及主数据编码规则或指标口径的，由数据治理决策层审批。审批层级的组织设计在「数据治理一」一节论述。

标准发布采用版本与基线机制。每次发布形成一个版本，重要节点（如 DCMM 评审前、年度审计前）固化为基线。数据集加工与指标计算记录所依据的标准版本号，使历史结果可按当时的标准版本回放。这一点对数据集的可追溯性尤其重要：一份两年前加工的数据集，其标签体系依据的码表版本必须可查，否则无法解释标签含义的变化。

1.9　标准域的治理要素落位

五类标准要落到可执行的程度，每一类都须把六件事定下来：管哪些业务对象、这些对象的字段字典长什么样、校验规则怎么写、谁审批、在平台上怎么配置、出了异常怎么处置、版本怎么变。表 1-10 按标准类别逐项列出，表中各项即为《数据标准管理办法》的条款来源。

表 1-10　数据标准域的治理要素落位

表中「异常处置」一列遵循同一条原则：异常不以删除或覆盖的方式消解，而是以归并、映射、标注三种方式保留痕迹。历史数据的口径还原依赖这些痕迹，删掉旧码值或旧映射，三年前的样本就无法解释。

1.10　数据标准规划的交付物与验收口径

表 1-11 列出本章对应的交付物与验收口径，对应招标文件要求输出的六份成果（b1286）（b1287）。

表 1-11　数据标准规划交付物与验收口径

上述验收口径中，凡以比例表述的均为招标文件未规定的过程优化目标，一律配基线、分期目标与回退安排：基线为首批发布时的实测值，目标按期段逐级提高并写入项目质量计划，未达期段目标的在数据治理月度例会上列明缺口、责任部门与补齐计划，相关数据集加工任务按置信标记降级输出而非停止，避免治理进度直接阻断数据集交付。招标文件已明定的指标不在此列，按招标要求的原值承诺并纳入验收。

这些比例口径中带具体量值的是术语覆盖率一项，量值 75% 由我方设立。两类量值的处理方式在此一并写明：招标文件给定量值的，承诺值取条款值本身，口径不改写、量值不下调；条款未给量值的，由我方设立承诺值，并连同设立依据、测量方法与未达标处置一并给出，属对招标要求的补充量化，不替代、不改写招标文件的任何一条要求。表 1-12 定数，给出招标值、承诺值与设计值三列——承诺值是写入验收记录的判据，设计值是我方编制排期与资源配置所依据的内部目标，高于承诺值，为滚动补充留出余量。表 1-13 定判法，把「怎么测、多久测一次、怎么算、不达标怎么办」四件事逐列钉死，验收时照该行走一遍即可，不必临时商定算法。

表 1-12　术语覆盖率的招标值、承诺值与设计值（招标值抄录招标文件 b1277；承诺值与设计值为我方设立）

表 1-13　术语覆盖率的测量方法、频次与计算公式（测法、频次与处置口径为我方设立）

2、数据质量规划要求

2.1　现状与治理目标

甲方的数据质量状况可以概括为「量不少、关联少、口径散」，各系统之间的差别很大。企业资源计划系统录入规范相对严格，数据质量较好；制造执行系统中部分工单填写不完整，报工时点相对实际作业有滞后；设备运行数据存在测点缺失与噪声；质量管理系统新上线不久，缺陷描述为自由文本，未与工艺参数关联。

这些状况对四类数据集的影响是直接的，不是间接的。举三个例子。

工单报工时点滞后，意味着以报工时间推算的工序实际耗时不可靠，制造过程类数据集中与节拍、工时相关的样本会带入系统性偏差。缺陷描述未与工艺参数关联，意味着质量类数据集缺少可用的标签来源，焊接与热处理的参数—结果配对样本无法直接构造。测点缺失与噪声，意味着设备健康诊断类样本的输入通道本身需要先做可信度判别，否则学到的是传感器故障而不是设备故障。

所以数据质量规划在本项目中不是一个合规性动作。它要回答的问题是：哪些数据现在就能用、哪些要先修、哪些修不好只能标注为低置信并在数据集加工时降权或排除。这个判断要有规则、有分数、有台账，而不是靠加工人员临场感觉。

本章治理的是九个业务域内业务数据的质量——企业资源计划系统里的物料主数据是否完整、制造执行系统里的工单报工是否及时、质量管理系统里的缺陷描述能否与工艺参数对上。四类高质量数据集本身的质量评测依据《高质量数据集质量评测规范》开展，其指标体系与评测过程在服务方案「数据集质量评测方案」一节论述。两者是供料关系：业务数据的质量决定数据集加工的起点，数据集的评测结论反过来成为业务数据质量规则的修订线索，这条回流通道的接口规定见第 2.7.4 节。

2.2　质量治理的总体闭环

数据质量管理按需求、规则、检查、分析、提升五个环节构成闭环，每个环节有明确的输入输出与责任角色。闭环的驱动来源有两处：常态化的周期稽核，以及数据集加工与场景验证反馈回来的错样归因。第二处驱动是本项目特有的，它把数据集的使用效果变成业务数据质量规则的修订依据。

图 2-1　数据质量治理五环闭环与两处外部驱动。数据来源：招标文件第五章 3.2.6.1.1.2.6 第（1）至（4）项。

2.3　数据质量需求梳理

2.3.1 两个方向同时推进

招标文件要求梳理各业务域核心数据的质量诉求（b1289）。本项目从两个方向同时推进，单用一个方向都会漏。

自上而下是场景倒推。十一个智能化应用场景与四类数据集对数据各有要求，把这些要求逐条翻译成对具体字段的质量诉求。例如板材备料工艺智能设计场景要求按工艺特征检索可借用的历史工艺，这就要求图号、零件标识、材质、规格参数、工序代码五类字段的完整性与准确性达到可检索的程度；缺失这些字段的历史工艺记录检索不到，等于不存在。

自下而上是现状扫描。对已盘点的数据对象逐字段统计空值率、取值分布、格式符合度、跨系统一致率，把实测结果差的字段列为候选质量问题，再由业务部门判断该字段是否重要。有些字段空值率高但业务上确实不填，不构成问题；有些字段空值率只有百分之几，但它是关联键，缺一条就断一链，优先级反而最高。

两个方向汇合后形成数据质量需求清单。清单的优先级按三条判据排序：是否为跨系统关联键、是否为四类数据集加工的必需输入、问题的业务后果大小。

2.3.2 质量需求清单的结构

表 2-1　数据质量需求清单字段结构

清单中「现状实测」与「目标值」两列是后续质量评分的基线来源。目标值按两类分别确定并在清单中分列标注。招标文件已明定的指标按招标要求承诺，直接写入目标值列并纳入验收，不因基线尚未实测而下调、延后或改为区间；首轮扫描的实测值对这一类只用于安排补齐路径，不用于调整目标。招标文件未规定的过程优化目标，由现状调查与首轮基线测试确定分期值，确定后写入项目质量计划，按季考核并在月度例会通报达成情况。两类目标共用同一套评分口径与同一本整改台账，区别只在目标值的来源与可否调整。

2.4　六大维度与数据质量校验规则库

2.4.1 六个维度在本项目中的具体含义

招标文件明确遵循完整性、准确性、一致性、唯一性、及时性、有效性六大维度（b1290）。六个维度是通用的，但判定方法必须落到本项目的具体对象上才可执行。表 2-2 给出各维度的判定方法与本项目实例。

表 2-2　六大质量维度的判定方法与本项目实例

「准确性」一列中「与物理约束比对」这一条对本项目的设备与工艺数据特别有效，但物理约束不写成普适断言，而是按工艺阶段、测点位置、仪表量程与有效运行状态分别给出合理上下限，并为冷却、停机、检修与环境变化这类合法状态设定适用条件，否则正常工况会被大量误判。

以热处理炉温为例。规则只在该炉次处于加热段或保温段、且该测点在测点台账中标记为有效时启用；上限取该炉型的额定炉温并计入仪表允差，下限取该工艺阶段的工艺下限，两端均不超出仪表量程。炉次处于冷却段、停机状态，或测点标记为检修、失效、未接入时，规则不启用，改由分布与连续性检查判别该测点是否断链、卡死或漂移。读数低于环境温度时不直接判为数据错误，先比对同炉次相邻测点与同时段的环境温度记录：三者同向变化的按环境变化处理并记为正常，仅该测点偏离的才判为测点故障，标记可信度下降并进入测点整改清单。

链条安全系数、装炉量、焊接电流三类规则按同一办法设限。安全系数的下限取设计校核的许用值，上限取校核模型的适用范围；装炉量的上限取该炉型的额定装载量，下限按该炉次的最小经济装载量设定并允许试制炉次例外；焊接电流的上下限取该焊接工艺规程规定的参数窗口与设备输出能力的交集，引弧与收弧时段按瞬态窗口单独设限。三类规则均只在工艺执行记录标记为正常作业的时段内启用，试制、调试、空载与停机时段不参与判定。这类规则不依赖外部权威源，只依赖已登记的设备参数与工艺规程，编写成本低而捕获的错误往往是录入或采集通道的硬故障。规则所引的参照参数（额定值、量程、工艺窗口、许用值）作为规则元数据登记，与设备台账、工艺规程的版本绑定；参照参数或其版本变更时，引用它的规则自动进入复核队列，复核通过后随新版本生效，复核未完成期间按原版本继续运行并标注待复核。

2.4.2 规则的类型与模板

规则库按十类规则模板组织。模板化的作用是让规则编写不依赖编程能力：数据质量管理员选模板、填参数即可生成规则，复杂逻辑才写表达式。

表 2-3　校验规则十类模板

最后一类规则对设备时序数据不可缺。测点断链、漂移与失效在固定阈值下不会报警，但在分布与连续性检查下可以识别：采样间隔突然变长说明断链，取值长期恒定不变说明可能卡死，均值缓慢单向偏移说明可能漂移。识别结果不直接判为设备故障，而是标记为测点可信度下降，供设备健康诊断类样本的构造使用。

2.4.3 规则的元数据与严重级

表 2-4　校验规则元数据结构

严重级的三档区分很重要，它决定了规则对业务的影响程度。阻断级规则不通过则数据不进入加工链路，适用于关联键缺失、唯一性冲突一类会导致下游错误的问题。告警级规则不通过则数据带标记进入，适用于非关键字段缺失、取值分布异常一类问题。提示级规则仅记录，用于观察期的新规则。

新规则一律先进观察期。观察期内规则按提示级运行两到四周，统计其触发量与误报率，误报率高的规则回炉修改。这个安排的理由是：规则直接上阻断级会造成大量任务失败，运维成本高且会削弱业务部门对治理工作的配合意愿。

2.4.4 规则库的规模与分布

规则库的规模同时决定三件事：规则编制的工作量与排期、稽核任务的调度容量与执行窗口、数据质量管理岗的人力配置。因此在规则模板与元数据结构确定之后，先给出一份可据以排期的规模估算。

估算方法是自下而上折算，不取经验总数。以各业务域已识别的数据元条数为底，按六个维度对该域字段的适用比例逐项折算：完整性与有效性几乎对每个字段都适用，故两列数值最高；唯一性只对业务主键与编码类字段适用，及时性只对有时限约定的对象适用，故两列数值最低；一致性取决于该域有多少同一事实被两个以上系统并行记录。跨系统比对与物理约束两类规则不由单字段派生，按已识别的跨系统关联点与设备工艺参数条目单独计入。

表 2-5 的行给出各业务域的编制工作量与责任分摊，列给出该域的治理重点落在哪个维度，末行合计是首批建设的排期依据。表中数值为规划阶段的估算值，现状评估完成、数据元清单核定后按实际条数修订。

表 2-5　校验规则库首批规模估算

规则数量与数据元数量大体成一比一的量级关系：约 1370 条数据元派生出约 1156 条规则，再加上跨系统比对与物理约束一类不由单字段派生的规则。生产制造域规则最多，因为该域字段最多、时序数据与跨系统关联最密集。

2.5　数据质量检查

2.5.1 稽核的三种触发方式

招标文件要求基于规则库开展数据质量稽核、调度执行多源数据校验、快速定位质量异常数据（b1291）（b1292）。本项目的稽核按三种方式触发。

入口校验在数据汇聚与加工任务读入数据时同步执行，针对的是单条记录可判定的规则——空值、格式、值域、引用完整性。入口校验的优点是问题在进入加工链路前就被拦住，缺点是只能做记录级判断，跨系统比对与分布检查做不了。

周期稽核按调度计划批量执行，针对的是需要全量或大范围数据才能判定的规则——唯一性、跨系统比对、分布与连续性、及时性。周期稽核的频率按数据更新节奏设定：工单与报工类 T+1，库存三方比对每周，主数据一致性每月，设备时序连续性按日。

按需稽核由数据质量管理员或数据集加工人员手工发起，针对特定对象做专项检查。典型场合是数据集加工前对本批次取数范围做一次定向稽核，以及质量问题整改后的复核。

图 2-2　质量稽核的三种触发方式与异常定位链路。数据来源：招标文件第五章 3.2.6.1.1.2.6 第（2）项数据质量检查要求。

2.5.2 多源数据校验的实现

多源校验是本项目质量检查中技术含量最高、业务价值也最直接的部分。它要解决的是跨系统追一件事需要人工对账的现状。

多源校验的前提是关联键贯通。没有稳定的关联键，两个系统的数据无法自动比对。本项目的关联键按业务对象确定：施工号关联项目与工单，图号与版本关联设计与工艺，物料编码与批次关联库存与采购，工单号与工序代码关联制造与质检，设备编码与测点标识关联设备与时序数据，炉次号关联热处理与检验结果。关联键的贯通工作与主数据标准建设同步进行。

首批多源校验的对口关系见表 2-6。每一组对比都对应一个甲方现在要靠人工对账的场合。

表 2-6　首批多源数据校验对口关系

表中「焊接参数与焊道配对」与「服务工单与报警配对」两项，当前甲方尚不具备可配对的数据条件——焊接参数流与工件、焊道无对应，故障记录与数据段无配对。这两项校验在首期的作用不是发现偶发错误，而是度量配对覆盖率本身，作为相关数据集可构造样本量的前置判断依据。

2.5.3 异常的快速定位

招标文件要求快速定位质量异常数据（b1292）。定位分两个方向。

向下定位到记录。异常明细台账记录规则标识、检查对象、问题记录的业务主键、实测值与期望值。业务人员按主键可直接在源系统中找到该条记录，不需要由技术人员再查一遍。这一点决定了整改能否由业务部门自行完成。

向上定位到源头。沿元数据血缘回溯，判断问题是源系统录入产生的、接口传输产生的，还是加工逻辑产生的。回溯依据是加工链路上每个节点的输入输出校验结果：若某节点输入已有问题，责任在上游；若输入正常而输出有问题，责任在该节点的加工逻辑。元数据血缘的建设在「数据治理一」一节的元数据管理办法中规定，本节使用其成果。

2.6　数据质量分析

2.6.1 质量评估方案

招标文件要求制定数据质量评估方案，明确质量指标、质量评分与评估分析方法（b1293）。本项目的评估方案按三层设计：规则级通过率、对象级质量分、域级质量分。

规则级通过率是最底层的实测值，等于通过检查的记录数占被检查记录数的比例。对数据集合级规则（如跨系统比对），通过率按比对项计。

对象级质量分按六个维度加权汇总。某数据对象在某维度上的得分，等于该对象该维度下所有规则通过率按规则严重级加权的平均值；对象总分等于六个维度得分按维度权重加权之和。维度权重按业务域设定而非全局统一，理由是不同域的质量短板不同：设备管理域的及时性与准确性权重应高于唯一性，财务管理域的一致性与准确性权重应高于及时性。

表 2-7　质量维度权重设置（示例，实际权重经甲方数据治理管理层核定）

域级质量分按该域各数据对象的分数加权，权重取对象的业务重要度。全公司质量分按九个域加权，权重按域对数据集建设的贡献度设定。

评分结果按五档评级：优（90 分及以上）、良（80 至 90）、中（70 至 80）、需改进（60 至 70）、差（60 以下）。评级的用途不是打分排名，而是决定管控动作：需改进与差两档的数据对象，其涉及的数据集加工任务须附置信标记，且该对象进入下一季度的整改重点清单。

2.6.2 评估分析方法

评分只说明「有多差」，分析要回答「为什么差」和「先修哪个」。本项目用四种分析方法。

构成分析把质量问题按维度、按业务域、按源系统、按责任部门分解，找出问题集中的位置。实践中问题往往高度集中：少数几个字段贡献大部分问题量。

趋势分析按月对比质量分与问题量，区分三种情形：治理起效后的持续下降、整改后的反弹、因新增数据对象纳管带来的分数下降。第三种情形容易被误判为治理退步，须在月报中单独说明纳管范围变化。

根因分析对问题量靠前的规则做逐条归因，归因分类见表 2-8。归因结论决定治理动作，这是质量分析与质量提升之间的接口。

表 2-8　质量问题根因分类与对应治理动作

最后两类不能靠整改解决，必须作为已知缺口登记在册。把不可得的数据算进整改任务，会让整改率这个指标永远不达标，并在后续评审中掩盖真正能解决的问题。

2.6.3 常态化质量监控评估工作机制

招标文件要求建立常态化质量监控评估工作机制（b1294）。本项目的机制按日、月、季三个节奏运行。

日节奏是监控。稽核任务按调度执行，异常量与质量分在质量看板上实时更新，阻断级问题即时推送至责任部门。看板的最小粒度到数据对象与规则。

月节奏是分析与通报。出《数据质量分析报告》，内容包括质量分与问题量的构成、趋势、根因归因、整改进展、已知缺口变化。报告在数据治理月度例会上通报，会上确定下月重点整改清单。

季节奏是评估与调整。做一次完整的质量评估，输出域级与全公司质量分，复核维度权重与规则严重级设置是否仍然合理，复核质量需求清单的目标值与达成期。季度评估结论进入数据战略评估机制，相关安排在「数据治理一」一节论述。

质量目标的设定方式是：首轮全量扫描完成后确定基线，此后按季度设定提升目标，目标值以「相对基线的问题量下降幅度」表述而非绝对达标率。这样做的理由是不同对象的起点差别很大，统一的绝对达标率对起点差的对象不可达、对起点好的对象无约束力。全公司质量分的长期目标是逐步接近良级并保持，达不到期段目标时的处置是在月度例会列明缺口、调整整改资源投入，而非调低规则门限。

2.7　数据质量提升

2.7.1 五环闭环处置流程

招标文件要求设计数据质量问题闭环处置流程，明确上报、分派、整改、复核、归档的管理要求（b1295）（b1296）（b1297）。

稽核一旦常态运行，问题单便持续产生，治理成效取决于这些问题单能否逐条收口，而不取决于发现了多少条。闭环的设计因此有两个着力点：一是五个环节各有唯一的责任角色与完成标志，避免问题单停在无人认领的中间状态；二是为两类注定无法按常规整改的问题预留出口，否则它们会在分派与退回之间反复循环，既占用处置资源，又使关闭率失真。

图 2-3 的横向主链是常规路径——上报、分派、整改、复核、归档，复核不通过的退回整改，构成一次闭合。两个浅色方框是分流路径，其判定发生在整改环节的根因归类之后：根因为规则本身不当的，退回规则库修改或降级，不计为数据问题，以免规则误报推高问题基数；根因为源头不可得或历史遗留的，转入已知缺口清单按季复评。底部一行是闭环的沉淀去向，处置结论回写校验规则、质量需求目标值与维度权重，使同类问题再次发生的概率下降。

该流程支撑的是质量提升的可验证性：任一问题单在整改台账中均可查到责任部门、处置结论与关闭依据，复发的问题单可按根因追溯到上一次处置的不足之处。

图 2-3　质量问题五环闭环处置流程与两条分流路径。数据来源：招标文件第五章 3.2.6.1.1.2.6 第（4）项数据质量提升要求。

2.7.2 各环节的管理要求与时限

闭环流程要能运行，每一环还需两件东西：交付什么才算做完，以及多久之内要做完。缺前者，问题单会以已处理的状态关闭而无从复核；缺后者，告警级问题会被无限期顺延。

必填内容按「下一环需要什么」反推确定，取最小字段集而不求详尽：分派环节要用到上报环节记录的规则标识与严重级，复核环节要用到整改环节记录的涉及记录数与是否需要系统改造，归档环节要用到复核结论。字段每多一项即增加一次人工录入，故凡能由稽核结果自动带出的，不再要求人工填写。时限按严重级分档而非一刀切：阻断级问题直接拦住数据进入加工链路，其时限按数据集加工的排产节奏倒推；告警级问题不阻断流转，纳入月度清单统一排期，以免高频的轻微问题挤占处置资源。

表 2-9 中「必填内容」一列是各环节的完成判据，「时限要求」一列是处置及时率的统计口径，两列共同构成质量问题处置的考核依据。

表 2-9　质量问题处置各环节管理要求

时限要求的设定考虑了业务部门的实际承受能力。阻断级问题的整改时限定为 5 个工作日，是因为这类问题多为关联键缺失或唯一性冲突，通常由业务部门补录或更正即可完成，不需要系统改造。需要系统改造的问题单独标记，整改时限按改造排期另定，不占用常规时限统计。

2.7.3 质量问题整改台账

整改台账是招标文件要求的输出之一（b1298）（b1299），也是质量治理成效的主要证据。台账按问题单逐条记录，字段包括问题单号、发现日期、规则标识、业务域、数据对象、严重级、根因分类、责任部门、整改措施、涉及记录数、整改完成日期、复核结论、关闭日期、派生的规则或标准修订。

台账的统计口径须说清三件事，否则数字容易被误读。第一，问题单数与问题记录数是两个量，一个问题单可能涉及上万条记录。第二，关闭率的分母应剔除转入已知缺口清单的问题单。第三，重复出现的问题单须标记为复发，复发率比关闭率更能说明整改是否触及根因。

2.7.4 与数据集质检的接口

数据集质检与场景验证产生的错样，是业务数据质量问题的一个重要发现渠道。错样归因的结论若指向源数据问题，则按本节流程生成质量问题单，责任部门为源系统业务归口部门；若指向加工逻辑问题，则在数据集加工环节处置，不进本台账。

两边的界线以「问题是否存在于源数据中」划定。一条样本的标签错了，若源系统的检验结论本身就是错的，这是业务数据质量问题；若源系统结论正确而加工环节映射错了，这是加工质量问题。数据集质检的指标体系、质检方法与错样归因机制，在「数据加工生产二」与「数据集质量评测方案」两节论述。

2.8　质量域的治理要素落位

质量治理的五个环节各有其管理对象，表 2-10 按对象逐项给出字段字典、规则实例、审批、平台配置、异常处置与版本变化。

表 2-10　数据质量域的治理要素落位

五类对象的记录共同构成数据管理能力成熟度评审中「质量管理」能力域的执行证据。证据的价值在于连续，因此上述各表的历史记录一律只追加不覆盖，版本切换处标注断点而非重写历史。

2.9　数据质量规划的交付物与验收口径

表 2-11　数据质量规划交付物与验收口径

五份交付物的责任分工是固定的：管理办法与需求清单由项目组起草、归口部门核定、数据治理管理层批准发布；规则库由数据质量管理员维护并对规则的可执行性负责；分析报告与整改台账由数据质量管理员按期出具，责任部门对本域整改结果负责。验收时逐份核对发布文件、规则运行记录、月度报告与台账统计四类证据，缺证据的文档不计入已交付。

3、数据安全规划要求

本章与技术方案「安全方案」一节的分工如下：本章交付管理侧的规划成果——分类分级标准、合规管理制度、安全管理办法、权限管理规范，并提出防护与审计的管控要求；国密算法应用、等保 2.0 测评、信创适配、脱敏与去标识的技术实现、密码产品配置与第三方测评安排，在「安全方案」一节论述。两章的分级口径为同一套，本章定义的 L1 至 L5 分级标签是「安全方案」中技术管控策略的输入。

3.1　数据合规管理与分类分级

3.1.1 合规依据

数据合规管理的依据分三层。第一层是法律法规，包括数据安全法、个人信息保护法以及工业和信息化领域数据安全管理的相关规定。第二层是国家标准，包括个人信息安全规范、数据分类分级的通用要求、网络安全等级保护的基本要求。第三层是甲方现行的保密与信息安全制度。

本项目的做法是把第三层作为起点而非终点：先梳理甲方现行制度与前两层要求的差距，形成差距清单，再在差距清单基础上编制《数据合规管理制度》，而不是另起一套与现行制度并行的体系。制度并行会导致执行时无人知道该依哪一套。

3.1.2 五级分级标准

招标文件明确按 L1-公开、L2-内部、L3-重要、L4-敏感、L5-机密五个层级制定数据安全分级标准（b1301）（b1302）（b1303）。表 3-1 给出各级的判定依据与本项目的具体实例。实例是分级标准能否执行的关键：只给级别定义不给实例，分级工作一定做不下去。

表 3-1　数据安全五级分级标准与本项目实例

矿井位置与工作面地质条件参数定为 L4，理由是这类信息属于敏感地理信息范畴，且涉及矿方客户的生产安全信息。这一点对本项目有实际约束：选型类数据集的样本携带工作面工况参数，加工与流通时须按 L4 要求做去标识处理，具体技术手段在「安全方案」一节论述。

选型校核公式与关键工艺核心参数窗口定为 L5。这两类是甲方的核心技术秘密，也是数据集中价值最高的部分。L5 数据进入数据集加工链路须单独审批，加工环境与人员范围单独限定，加工产物的流通范围在数据卡中明确声明。

3.1.3 分类与分级的作业流程

分类按「业务域＋数据主题」二维组织。九个业务域为第一维，每个域下按数据主题细分，例如生产制造域下分工单与报工、工艺执行、热处理炉次、焊接过程、设备运行五个主题。分类的粒度到数据主题，分级的粒度到数据元。

分级作业按识别、定级、审批、标记、复核五步执行。

图 3-1　数据分类分级作业流程与两类定级输入。数据来源：招标文件第五章 3.2.6.1.1.2.7 第（1）项数据合规管理要求。

「聚合后敏感度升级」这条裁决规则在本项目中会反复用到。单条工艺卡片是 L3，但某一产品全部工序的工艺卡片聚合在一起，其技术秘密含量接近 L5；单个测点的温度读数是 L2，但某炉型全部炉次的完整温度曲线集合反映的是关键工艺参数窗口。因此数据集的级别不等于其成分数据元级别的最大值，须按聚合后的实际敏感度单独定级，定级结论记录在数据集的数据卡中。数据卡的结构在「四大数据集规模与数据卡」一节与附录佐证卷论述。

3.1.4 重要数据与敏感数据的识别

重要数据的识别按「泄露后是否可能影响行业运行与生产安全」判定。本项目识别的重要数据候选范围包括：矿用刮板输送机的关键结构参数与选型校核方法、关键工艺参数窗口、重大项目的产能与交付能力数据、矿方工作面地质条件参数。候选范围提交甲方确认并按相关管理要求履行必要的报备程序，报备的具体口径以甲方主管部门意见为准。

敏感数据的识别覆盖四类：个人信息、敏感地理信息、重要行业数据、企业秘密数据，这与招标文件在安全合规要求中提出的去标识化与脱敏处理范围一致。识别手段分规则与人工两步：先按字段名敏感词表与取值格式特征（证件号、手机号、坐标、银行账号）做机器预判，再由业务部门确认。预判的召回率目标是尽可能高，宁可多报由人工剔除，也不漏报；漏报的后果比误报严重得多。

3.2　数据安全防护要求

招标文件要求构建多维度安全控制能力，涵盖权限管控、敏感数据脱敏、数据水印、访问审批等防护手段（b1304）（b1305）。本节提出各手段的管理要求与分级对应关系，技术实现见「安全方案」一节。

3.2.1 权限管控

权限模型按角色与属性结合设计。角色定义岗位的基本权限集合，属性在角色之上做动态约束。属性包括数据级别、业务域、项目范围、时间范围、访问环境。这样设计的原因是单纯的角色模型在本项目中粒度不够：同一个工艺工程师角色，对本人负责产品的工艺卡片应可读写，对其他产品线的工艺卡片只应可读或不可见，纯角色模型要为此建大量角色。

权限授予遵循最小必要原则，具体落实为三条规则。权限申请须声明用途与期限，无期限的长期权限仅限岗位固有权限。L4 与 L5 数据的权限逐事项审批，不随角色自动获得。权限按季度复核，复核时核对实际使用情况，连续一个季度未使用的非固有权限自动进入待回收清单。

3.2.2 分级与管控措施的对应矩阵

分级若只落在标签上，而访问、导出、接口、加工环境的实际做法并无差别，分级就只是一次文档作业。表 3-2 把五个级别与各类管控措施对应起来，要回答的是：同一份数据定为 L3 还是 L4，在各类管控措施上究竟差在哪里。这张矩阵是《数据权限管理规范》的核心内容，也是技术侧下发策略的依据。

九类措施对应数据被使用的九个出口——授权、展示、导出、接口、加工环境、脱敏、水印、审计、留存，出口覆盖不全，级别就会从未覆盖处漏出去。各级强度有三个取值来源：涉及个人信息与敏感地理信息的，按数据安全法、个人信息保护法与矿方合同的保密约定取法定下限；涉及甲方工艺秘密与商业秘密的，沿用招标方现行保密制度的既有做法；其余按本项目数据加工的实际操作成本校准，避免管控强度高到业务无法执行。

横向一行是某一级别的完整管控包，可作为该级别的策略模板直接下发；纵向一列是同一类措施在五个级别之间的强度梯度，用于核查梯度是否单调、有无级别倒挂。L3 与 L4 之间是全表最关键的一道分界——授权由角色授予转为逐事项审批、展示由明文转为脱敏、导出件开始强制带水印，本项目多数工艺与质量数据落在这一分界附近。矩阵支撑的承诺是：管控强度随级别逐级提高且可逐条核对，管理侧的审批要求与技术侧的策略配置出自同一张表。

表 3-2　数据级别与管控措施对应矩阵

3.2.3 脱敏与去标识

脱敏按用途分静态与动态两种。静态脱敏用于数据集加工与对外提供场合，在数据落地时即完成变换，产物不可逆；动态脱敏用于查询展示场合，在返回结果时按访问者权限实时变换，底层数据不变。

脱敏规则按数据类型选择方法：个人身份与联系方式用部分遮蔽或泛化；矿方名称与矿井位置用代号替换并保留可追溯的映射表，映射表单独存放并按 L4 管控；地质条件参数用区间化处理，保留分布特征而去除精确定位能力；价格与成本用比例缩放或区间化，保留可比性而去除绝对值。

脱敏的一个边界须写清：脱敏会损失信息，损失到什么程度仍满足数据集的使用需求，须由场景侧确认。例如地质条件参数区间化后若区间过宽，选型类样本的工况区分度会下降。本项目的处理办法是对每一类脱敏规则记录其信息损失特征，由数据集加工与场景验证侧评估可用性，评估结论记入数据卡。

3.2.4 数据水印

水印有两个用途，对应两种形态。可见水印用于文档与报表导出件，标注使用者、时间与用途，作用是提示与心理约束。隐式水印用于数据集与批量导出的结构化数据，在不影响使用的前提下嵌入可追溯标记，作用是在发生外泄时判断来源批次。

隐式水印对数据集的流通尤其有意义：本项目的数据集将进入运营与流通环节，一份数据集被授权给多个使用方后，若出现未授权扩散，隐式水印是判断来源的依据。水印的嵌入方式、强度与抗攻击能力在「安全方案」一节论述；本节规定的是管理要求——L3 及以上级别的导出件须带水印，水印与导出审批记录关联，可由水印反查到审批单。

3.2.5 访问审批

访问审批的管理要求集中在三点。审批要素须完整：申请人、用途、数据范围、字段范围、级别、期限、使用环境、是否允许导出、是否允许二次提供。审批层级按级别设定，与表 3-2 的授权方式一致。审批记录与后续的访问日志关联，使「谁批准了这次访问」与「这次访问实际做了什么」可以对上。

第三点是本项目安排的一个检查机制：按季度抽取审批单，核对其授权范围与实际访问日志的一致性，对超出授权范围的访问追溯原因。抽查比例按级别设定，L4 与 L5 的审批单抽查比例高于 L3。

3.3　数据安全审计要求

招标文件要求完整记录数据查询、修改、删除、接口调用等全链路操作日志，操作留痕可追溯（b1306）（b1307）。

3.3.1 日志要素与覆盖范围

表 3-3　操作日志要素

覆盖范围包括治理平台与数据集运营平台自身的操作，以及经统一数据服务通道对源系统数据的访问。源系统内部的直接操作日志由源系统自身记录，本项目通过接口采集其可获取部分并在审计分析中合并；源系统日志能力不足的，在诊断报告中列为缺口并提出改造建议。这是一条责任边界：本项目不替源系统补建其内部审计能力。

3.3.2 审计分析与追溯

日志只记不看等于没记。审计分析按三类模型运行：阈值类（单位时间内查询量、导出量、失败次数超出基线）、行为模式类（非常规时段访问、非常规来源访问、首次访问高级别数据、权限变更后立即大量访问）、关联类（审批范围与实际访问范围不符、同一数据被多账号集中访问）。命中的事件生成审计告警，按级别推送至安全管理岗与归口部门。

追溯能力的验收采用抽样核验：从日志中抽取一定数量的高级别数据访问记录，逐条核验能否还原「谁、何时、通过什么通道、对哪些记录、做了什么、依据哪张审批单」。抽样可追溯率的目标是逐步接近全部，首次核验结果作为基线；未能还原的记录逐条分析原因（日志字段缺失、关联凭据未写入、源系统日志不可得），形成日志完善清单。核验不达期段目标时的处置是补齐日志字段与关联凭据，并对相应级别的数据暂时收紧授权方式，这是本指标的回退安排。

3.3.3 日志的保护与留存

日志自身须防篡改与防删除。管理要求是：日志写入后不可修改，删除须经安全管理岗与归口部门双人审批并留下删除记录；日志存储与业务数据存储分离；运维人员对日志存储的权限与对业务数据的权限分离。留存期限按级别与法规要求设定，不少于相关规定的最低期限，具体技术措施见「安全方案」一节。

3.4　安全域的治理要素落位

安全域的管理对象有六类：分级标签、权限策略、脱敏规则、水印策略、访问审批单、审计日志。六类对象的落位要素见表 3-4，表中内容即为《数据安全分级标准》与《数据权限管理规范》的条款来源。

表 3-4　数据安全域的治理要素落位

六类对象之间是单向驱动关系：分级标签驱动权限、脱敏与水印三类策略，三类策略的执行与审批单的签发共同产生审计日志，审计日志又作为分级与授权是否合理的复核依据。这条链路上任一环节的记录缺失，都会使后续环节失去判据，因此六类对象的记录完整性是安全域验收的首要条件。

3.5　数据安全规划的交付物与验收口径

表 3-5　数据安全规划交付物与验收口径（b1308）（b1309）

四份交付物中，合规管理制度与安全管理办法由合规责任岗与安全管理岗共同起草并经数据治理管理层批准；分级标准由安全管理岗牵头、各业务域归口部门逐域核定；权限管理规范由安全管理岗起草并经管理层批准。验收时核对三类证据：发布文件、纳管数据元的分级标签登记统计、L4 与 L5 定级与授权的审批记录。四份文档互为依据，分级标准未发布则权限规范无法执行，因此四份一并发布、一并验收，不分批通过。

4、数据生存周期规划要求

数据生存周期管的是过程规范。前三章定下了「什么是对的」「怎么判断对不对」「谁能看什么」，本章要把这些要求嵌进从需求提出到数据退役的每一个动作里，使标准与质量要求不是事后检查，而是过程中的检查点。

图 4-1　数据生存周期四阶段、阶段间交接物与嵌入的治理检查点。数据来源：招标文件第五章 3.2.6.1.1.2.8 第（1）至（4）项。

4.1　数据需求管理

4.1.1 需求的来源与分类

招标文件要求建立标准化数据需求管理流程，规范需求提交、评审、排期、反馈闭环，并完整留存流程记录（b1311）（b1312）。

本项目的数据需求有四类来源，处理方式不同。第一类是数据集建设需求，来自四类数据集的加工计划与十一个验证场景的数据要求，这类需求量最大且有明确的交付时点。第二类是指标与报表需求，来自决策指标体系与各部门管理需要。第三类是数据服务需求，来自应用系统对标准化数据接口的需要。第四类是数据质量整改需求，由质量问题闭环中需要系统改造的问题单转化而来。

四类需求统一进一个需求池，按统一流程处理，但排期时按来源区分优先级：带交付时点的数据集建设需求优先，阻断级质量整改需求优先，其余按业务价值与实现成本排序。

4.1.2 需求单与评审要素

表 4-1　数据需求单字段结构

评审从四个角度给结论。必要性看是否已有同类数据或指标可满足，避免重复建设；本项目预期这一项会筛掉相当一部分需求，因为部门各自提报时并不知道其他部门已有相同数据。合法性看数据来源是否合法、使用用途是否在授权范围内，这与数据来源合法性核查的要求一致。可行性看源数据是否存在、质量是否够用、接口是否可开通。安全合规看级别、脱敏要求与人员范围是否匹配。

四角度中「可行性」最常给出否定结论，原因通常是源数据不存在或源系统接口未开通。这类需求不是简单驳回，而是转为两条动作：若需要扩大采集范围，转入采集扩展清单；若需要源系统开通接口，转入接口协调清单。两张清单按月与甲方对接推进，这也是本项目需求管理与采集接入工作的接口。

4.1.3 流程记录的留存

流程记录是 DCMM 评审的证据之一，也是甲方后续自主运营的基础。留存要求是：需求单的每一次状态变更（提交、受理、评审、排期、开发中、交付、验收、关闭、驳回）产生一条记录，记录操作人、时间、意见与附件；驳回与未排期的需求同样留存，不删除；需求变更不覆盖原需求，以版本方式追加。

需求管理的运行指标按月统计：受理时效、评审时效、按期交付率、验收一次通过率、驳回原因构成。其中驳回原因构成最有诊断价值——若「已有同类数据」占比高，说明数据资源目录的宣传与检索不够好；若「源数据不存在」占比高，说明采集范围需要扩展。

4.2　数据设计与开发规范

招标文件要求制定数据设计开发统一规范，明确数据采集、数据加工、数据模型、接口开发等相关要求（b1313）（b1314）。

4.2.1 数据采集规范

本项目的数据来源形态差别很大，采集规范按五类分别规定，见表 4-2。

表 4-2　五类数据的采集规范要点

时序数据的时间基准对齐是一条容易被忽略而后果很大的要求。热处理炉控、物联网平台、制造执行系统的时钟若不同步，炉次与温度曲线、焊道与参数流的对齐就会错位，错位的样本在数据集中是污染而不是噪声。本项目要求纳入采集的所有数据源使用统一时间基准，不具备条件的须记录其时钟偏差并在加工时校正。

采集范围的扩展按场景优先级分批推进。甲方现有的数据采集与监控覆盖部分车间与部分设备，首期以试点炉型、试点产线与试点车间所需设备为准，扩展清单以现场勘察结论为准。这一安排的责任边界是：采集点位的布设与设备侧改造涉及甲方生产现场，须由甲方确认停机窗口与施工条件。

4.2.2 数据加工规范

加工规范的核心是四条可执行要求。

分层落地。加工任务按数据仓库分层写入，层间依赖单向，不跨层直连。分层架构的定义在「数据治理一」一节的数据模型分层架构中给出，本节规定的是执行要求：每个加工任务声明其读取层与写入层，违反单向依赖的任务不予上线。

幂等与可重跑。同一任务对同一输入批次重复执行，结果一致。实现要求是写入按业务主键与批次标识做覆盖而非追加，任务记录处理水位线并支持按指定水位线重跑。这条要求的实际价值在质量问题整改后的补数场合：没有幂等性，补数会产生重复记录，反而制造新的质量问题。

命名与注释。表名、字段名、任务名按统一命名规则，字段中文名引用数据元标准名称。加工逻辑中的业务判断须有注释说明依据，例如某字段取值被过滤的理由。

血缘登记。加工任务上线时登记输入输出对象与字段级映射关系，供质量问题溯源与标准变更影响评估使用。未登记血缘的任务不予上线。

4.2.3 接口开发规范

接口规范覆盖六项：契约定义（请求与响应结构、字段引用数据元标准、错误码表）、版本管理（新增字段向后兼容，不兼容变更须新版本并公告过渡期）、鉴权（按调用方登记，L3 及以上数据的接口须登记调用方与用途）、限流与配额（按调用方与数据级别设定）、幂等（写类接口须支持幂等键）、可观测（调用量、时延、错误率、数据量上报监控）。

接口的 SLA 分级与数据服务标准合并规定，见本节第 5 章第 4 节。

4.2.4 开发过程的评审检查点

表 4-3　数据开发过程评审检查点

最后一行的「回退上线」是本项目在数据开发上保留的回退机制。新上线的加工任务在首个运行周期内若出现质量规则大面积不通过或任务反复失败，先回退到上一稳定版本并限制下游使用，再定位问题，而不是在生产环境上反复修补。下游若已有数据集加工依赖该任务，则该批次数据集加工暂停并在数据卡中记录延期原因。

4.3　数据运维管理

招标文件要求制定数据运维管理制度，明确采集、加工、数据服务运维责任，针对任务失败、接口异常、数据延迟配置告警机制，建立运维故障闭环处置流程（b1315）（b1316）（b1317）。

4.3.1 运维责任的划分

数据链路由采集、加工、服务、平台四段构成，各段的故障现象相近而处置主体不同。运行期最常见的损耗并非技术上无法修复，而是故障发生后在归属判断上往返确认，响应时间消耗在协调而非处置。运维责任矩阵的作用，是把这一判断前置成一张随时可查的表。

五列的划分对应一次故障处置必经的五个角色：谁先看见（日常监控）、谁先动手（一线处置）、谁能改配置与代码（二线处置）、谁能让源头配合（源头协调）、谁确认恢复之后数据确已可用（业务确认）。少任何一列都会留下缺口——只分到一线，需要改动的问题就会悬置；不设业务确认，则会出现任务已恢复而数据仍不可用却已按结案处理的情形。表中「—」表示该对象不涉及该角色，例如加工任务与数据服务接口的源头在项目组可控范围内，无需外部协调。

按行查，可在告警到达时直接定位处置链路；按列查，可核对各岗位的责任覆盖是否有遗漏、同一对象是否出现多头负责。

表 4-4　数据运维责任矩阵

责任边界有一条须写明：源系统自身的故障、接口未按约定提供数据、源系统数据内容错误，其处置责任在源系统归口部门，项目组负责定位、通知与协调，并在数据服务侧按降级策略维持可用性。这条边界在实际运行中会经常用到，因为甲方的部分源系统由不同厂商维护。

4.3.2 三类告警的规则设计

告警设计的目标，是让异常在影响数据集交付之前被发现，而不是在交付延误之后用于复盘。招标文件明定的任务失败、接口异常、数据延迟三类，针对的是「停了」这一种失效；本项目在其上补充任务超时、数据量异常与质量规则大面积不通过三类，针对的是「没停但已经不对」这一种失效。后者在数据加工链路中更为常见，也更难在交付前察觉。

每类告警的判定规则取自可直接观测的运行量，不依赖人工巡检：执行状态、执行时长、接口错误率与时延、数据到达时间、批次记录数、阻断级规则不通过比例。阈值按对象自身的历史分布设定，而非全局统一取值，原因是各采集对象的数据量级与节奏差异很大，统一阈值会在高频对象上频繁误报、在低频对象上长期失灵。

级别一列决定通知范围与响应时限，凡影响数据集交付的一律定为一级。按行读取的是单类告警的完整配置模板，按级别、通知对象、响应时限三列对照读取，可核对响应资源是否与风险等级相匹配。

表 4-5　三类告警的判定规则与响应

「数据量异常」这一类告警在实践中捕获的问题往往比任务失败更隐蔽。任务成功执行但只取到平日十分之一的记录，多半是源系统接口变更或增量水位线错位，而任务状态是成功的，不设量级告警就发现不了。阈值按对象历史分布设定并按季度复核，新纳管对象在积累两个月基线后启用该告警。

4.3.3 故障闭环处置流程

图 4-2　数据运维故障闭环处置流程与三条定位分支。数据来源：招标文件第五章 3.2.6.1.1.2.8 第（3）项数据运维要求。

故障关闭的条件有两条，缺一不可：故障现象消除，以及受影响的数据批次已补齐并通过质量规则复跑。只恢复任务运行而不补数，会留下一段数据空洞，这段空洞在日后被数据集加工取用时无法察觉。

4.4　数据退役管理

招标文件要求制定数据退役管理规范，明确数据归档、销毁、审批处置流程，对到期闲置数据资产开展评估，区分归档与销毁处置路径（b1318）（b1319）。

4.4.1 退役的触发与资产评估

退役触发有四种情形：保留期限到期、业务下线导致数据不再产生且不再使用、系统替换后旧数据已迁移、数据资产评估判定为无保留价值。

到期闲置数据资产的评估按四个维度打分：使用热度（近一年的访问与引用次数）、业务价值（是否仍为某业务判断的依据）、合规义务（法规、合同、审计是否要求保留）、复建成本（销毁后若需要是否还能重新获得）。

四个维度中合规义务具有否决权：存在保留义务的数据不进入销毁路径，无论其使用热度多低。复建成本高的数据倾向归档而非销毁，这一条对本项目的历史数据尤为重要——历史图纸与配套工艺卡片构成天然成对的监督样本，这类数据即使当前使用热度低，复建成本实际上是不可复建，应归档保留。

图 4-3　数据退役的评估判定与归档、销毁双路径。数据来源：招标文件第五章 3.2.6.1.1.2.8 第（4）项数据退役要求。

4.4.2 归档与销毁的管理要求

归档的要求是「可检索、可复活」。归档台账记录数据对象、归档范围与时间区间、存储位置与介质、数据格式与解析说明、检索方式、复活流程与责任人、下次评估时点。格式解析说明这一项常被忽略，而它决定了十年后归档数据还能不能读——私有格式的归档数据须同时归档格式说明或转为通用格式。

销毁的要求是「可证明、不可恢复」。销毁方式按数据级别选择，L3 及以上须采用不可恢复的方式并由安全管理岗监督，销毁后出具销毁证明，证明记录销毁对象、范围、方式、执行人、监督人、时间。销毁范围须包含备份与副本，仅销毁主库而遗留备份不算完成销毁，这一点在销毁申请中须逐项列出副本清单并逐项确认。

退役处置须同步更新三处记录：数据资源目录中该对象的状态、元数据与血缘中的下游引用关系、相关质量规则的启用状态。下游仍有引用的数据对象不得直接退役，须先完成下游改造或确认下游可接受数据缺失。

4.5　生存周期域的治理要素落位

生存周期四个阶段各有其管理对象：需求阶段是需求单，设计开发阶段是采集与加工任务、接口，运维阶段是告警与故障工单，退役阶段是退役处置单。各对象的落位要素见表 4-6。

表 4-6　数据生存周期域的治理要素落位

五类对象串起来就是一条数据从提出到退出的完整轨迹。轨迹的可追溯性是数据管理能力成熟度评审「数据生存周期管理」能力域的核心证据，也是本项目数据集样本可溯源的底层保障。

4.6　数据生存周期规划的交付物与验收口径

表 4-7　数据生存周期规划交付物与验收口径（b1320）（b1321）

四份规范覆盖数据从需求到退役的全过程，责任分工按阶段划分：需求管理规范由数据管理岗执行，设计开发规范由开发侧执行并经数据管理岗评审，运维管理制度由运维值守岗执行，退役管理规范由数据责任人发起、安全管理岗与管理层审批。四份规范的执行记录——需求单、评审记录、故障复盘报告、退役处置单——是数据管理能力成熟度评审中生存周期管理能力域的主要证据，因此规范发布与记录积累同步推进，不等规范齐备再开始留痕。

5、数据应用流通规划要求

数据应用流通是治理工作的出口。前四个域把数据做对、做可信、管起来，本章决定这些数据以什么形态、按什么权限、向谁提供。本章与数据集运营平台的边界是：本章交付的是管理规范与服务标准，平台的功能模块、界面与操作流程在「数据集运营平台」一节论述。

5.1　数据应用

5.1.1 应用需求的梳理方法

招标文件要求梳理数据应用需求，明确数据范围及要求，为数据应用提供治理后的可靠数据（b1323）（b1324）。

本项目的数据应用需求有两个明确的来源：四类高质量数据集的加工需求，以及十一个验证场景的数据需求。两者不是一回事——数据集加工需要的是大批量、可标注、可追溯的原始与中间数据；场景验证需要的是能支撑具体业务判断的、口径明确的查询与指标。梳理时分开处理，否则会把两类要求混成一张含混的清单。

梳理按三步做。先按场景逐条列出其业务判断所需的数据对象与字段，形成《高质量数据集验证场景数据需求清单》，这份清单是现状评估阶段的输出之一，在「数据治理一」一节论述，其结论在本章使用。再按清单核对数据供给能力：该字段是否已纳管、质量是否达到清单要求、安全级别是否允许该场景使用。最后把差距项分流——质量不足的进质量需求清单，未纳管的进采集扩展或接口协调清单，级别不允许的提交安全审批或改用脱敏形态。

表 5-1 以几个代表性场景示意数据范围与要求的对应关系。完整清单在现状评估完成后交付。

表 5-1　场景数据需求与供给要求对应（示例）

5.1.2 「可靠数据」的交付口径

把治理后的数据交给应用，要说清可靠到什么程度。本项目对每一个供应用使用的数据对象给出三项声明。

一是质量状态声明，给出该对象当期的质量分与评级、各维度实测值、已知缺口清单。二是口径声明，给出该对象字段对应的数据元标准与版本、涉及指标的指标卡与版本。三是时效声明，给出数据更新频率、延迟与最近一次更新时间。

三项声明随数据一并提供，在数据资源目录中可查，在接口响应的元信息中返回。这样安排的用意是把「数据可不可靠」变成使用方可以自行判断的事实，而不是由供给方给一个笼统的保证。质量未达门限的数据对象，其输出带置信标记，由使用方决定是否采用或降权使用；标记规则在指标卡的质量约束字段中声明。

5.2　外部数据管理

招标文件要求建立外部数据引入管理制度，规范外部数据采购、接入、核验、评估流程，明确外部数据存储、加工、共享的使用边界与约束（b1325）（b1326）。

5.2.1 外部数据在本项目中的范围

本项目可能引入的外部数据有四类：国家与行业标准文本及其附带数据、市场行情与价格指数（供库存控制场景判断采购时机）、公开的地质与煤炭行业统计数据、供应商提供的材料质保书与检测数据。四类数据的来源合法性要求不同，管控强度也不同。

5.2.2 四阶段引入流程

图 5-1　外部数据引入四阶段流程与合法性核查要素。数据来源：招标文件第五章 3.2.6.1.1.2.9 第（2）项外部数据管理要求。

合法性核查是四阶段中不可简化的一环，理由与本项目的性质直接相关：本项目的产出是用于大模型训练的数据集，招标文件在安全合规要求中明确须核查项目建设过程中是否包含不可用于商业用途的建设内容，并承诺数据集来源的合法性。外部数据一旦混入数据集而其许可范围不覆盖训练与商业使用，整份数据集的合法性都会受牵连。因此核查结论须逐项记录在外部数据台账中，并在数据集的数据卡中声明所含外部数据的来源与许可范围。

5.2.3 使用边界与约束

表 5-2　外部数据使用边界约束要素

到期与退出两项须在引入时就约定清楚。许可到期后衍生数据集能否继续使用，不同供方的约定不同；没有事先约定，到期时会面对一个两难——继续使用可能越权，停止使用则已交付的数据集要召回。本项目的做法是在采购阶段即把「许可到期后衍生品的处置方式」列为合同必谈条款，并把约定结果写入台账与数据卡。

5.3　数据开放共享

招标文件要求制定数据开放共享流程，规范数据申请、审批、授权、回收等流程（b1327）（b1328）。

数据开放的对象分三层，管控强度依次提高：企业内部跨部门共享、面向甲方关联单位的共享、面向外部的数据集流通。第三层与数据集运营流通直接相关，其业务形态在「数据集运营平台」一节论述，本章规定其管理流程。

图 5-2　数据开放的申请、审批、授权、使用监测与回收流程。数据来源：招标文件第五章 3.2.6.1.1.2.9 第（3）项数据开放要求。

授权环节有三项要素须一并绑定，缺一则后续无法管控。授权凭据须与具体的数据范围、字段范围、时间范围绑定，不签发无范围限定的凭据。脱敏策略按受众与级别绑定在凭据上，同一数据对象对不同受众返回不同的脱敏结果。水印策略按级别绑定，L3 及以上的导出件带水印且水印可反查到授权凭据。

回收有五种触发情形：授权到期、申请用途变更、监测发现越权访问、发生违规事件、申请人岗位变动。回收执行后凭据立即失效，已导出的数据按约定处置方式处理并记录。回收记录与申请单关联，便于复核同一受众的历史授权情况。

5.4　数据服务标准

招标文件要求构建数据服务标准，面向数据应用提供标准化数据服务（b1329）。

5.4.1 服务形态与适用场合

表 5-3　数据服务的四种形态与适用场合

四种形态的选择由使用方式与数据级别共同决定，不由提供方单方指定：在线查询选接口服务，批量取数与数据集交付选文件服务，分析报表直连选视图服务，下游同步选订阅服务；L4 数据经接口服务提供时一律返回脱敏结果，L5 数据只经文件服务并逐事项审批。形态一经确定即写入服务契约，变更形态按服务变更流程重新审批，不在原契约上追加。

5.4.2 服务目录与 SLA 分级

每一项数据服务在服务目录中登记：服务标识与名称、提供的数据对象与字段、调用方式与契约、更新频率与延迟、质量状态声明、安全级别与脱敏策略、SLA 级别、责任部门与联系通道、版本与变更记录。服务目录与数据资源目录互相引用，使用方可以从数据对象找到可用服务，也可以从服务找到其数据来源。

SLA 按三级设定：一级服务供数据集加工与关键场景使用，可用性与时延要求最高，故障按一级响应；二级服务供常规业务查询使用；三级服务供分析探索使用，允许在资源紧张时降级。SLA 的具体指标值与系统非功能指标相关，在「非功能性」一节给出，本节规定的是分级原则与服务登记要求。

5.4.3 服务的计量与审计

每次服务调用记录调用方、时间、数据范围、返回量、授权凭据。计量数据有三个用途：按受众统计使用情况，作为数据资产价值评估的输入；识别异常调用，作为安全审计的输入；度量服务实际负载，作为容量规划的输入。资产价值评估办法在「数据治理一」一节论述，本章提供其所需的使用计量数据。

5.5　应用流通域的治理要素落位

流通域的管理对象有五类：数据服务、服务目录条目、外部数据台账、开放授权凭据、共享申请单。五类对象的落位要素见表 5-4。

表 5-4　数据应用流通域的治理要素落位

五类对象的共同约束是范围绑定：服务绑定字段范围，凭据绑定数据、字段、时间与用途四重范围，台账绑定许可范围。范围一旦不绑定，后续的监测、回收与合法性追溯都无从执行，这也是本项目把范围要素作为必填项而非建议项的原因。

5.6　数据应用流通规划的交付物与验收口径

应用流通域的管理动作可归为两个方向：数据进来，与数据出去。外部数据引入解决进来的合法性，数据开放共享解决出去的可控性，数据应用需求梳理与数据服务标准分别是这两个方向的输入与实现手段。交付物因此收敛为两份正式规范，而不按小节数拆成四份——规范拆得过细，跨文件的口径一致反而难以维持，执行时也容易出现同一事项依不同文件办理。

两条验收口径均取可核对的物证，不取主观评价。引入侧核的是台账与授权凭证是否与已引入的外部数据逐条对应，有数据而无授权链证据的即判不合格；开放侧核的是已签发凭据是否均带数据、字段、时间与用途的范围限定，以及回收动作是否留有记录。两项都可由奔牛数据智能平台直接导出清单比对，不依赖人工说明。

这两份规范发布并通过上述核对，即表明本项目的数据对外提供已具备合法性与可追溯性的制度基础，数据集与数据服务可以进入运营流通环节。

表 5-5　数据应用流通规划交付物与验收口径（b1330）

数据服务标准与服务目录作为《数据开放共享管理规范》的附件交付，数据应用需求的梳理结论以《高质量数据集验证场景数据需求清单》形式交付，该清单归属现状评估阶段成果，见「数据治理一」一节。

6、数据治理规划成果交付要求

数据治理规划文档是规划阶段的成果载体，也是数据管理能力成熟度评审与项目验收的主要书面证据。本章对招标文件列明的全部文档逐份确定编制依据、章节骨架、责任域、形成时点、签审层级、输入输出与验收证据，并在项目实施期按计划节点提交评审。各份文档的内容建立在现状评估结论与招标方现行制度体系的确认之上，确认完成即按本章规定的时点与签审流程出具，附录佐证卷同步提供标准规范清单与模板样例，供评审时核对交付粒度。

6.1　交付清单

招标文件要求至少交付不少于 25 份数据治理规划文档，并以表格列明 37 份具体名称与形态（b1332）。项目组按 37 份编制交付，高于不少于 25 份的要求。表 6-1 给出全部 37 份文档的形态、数量、所属规划域与计划提交节点，表 6-2 逐份给出编制输入、核心内容、输出去向、签审层级与验收证据，两表合起来即为每一份文档的交付约定。

表 6-1　数据治理规划文档交付清单（全 37 份）

提交节点按三个阶段安排：第一阶段为制度与标准的基础件，须在数据汇聚与首批数据集加工开始前发布，否则加工过程无规范可依；第二阶段为运营类规范与办法，在首批数据服务与资产运营启动前发布；滚动更新类的三份（数据资源目录、标准映射对照表、整改台账）与按期出具类的两份（质量分析报告、战略评估报告）随工作进展持续交付。

6.2　逐份成果的编制输入、核心内容与验收证据

每一份文档的交付约定由五项要素构成：编制输入（依据哪些已有成果起草）、核心内容（文档正文必须覆盖的条款范围）、输出去向（这份文档被谁、在哪个环节作为依据使用）、签审层级（谁审谁批）、验收证据（以什么材料证明这份文档已交付且已生效）。形成时点按表 6-1 的计划提交节点执行。表 6-2 逐份列出。

表 6-2　数据治理规划文档的编制输入、核心内容、输出去向、签审与验收证据

表 6-2 的「验收证据」一列是本章验收的落点。一份文档只写完正文不算交付：制度类须有发布文件，清单与台账类须有可核对的条目与统计，报告类须有审阅记录。三类证据与文档正文一并归入项目验收材料，也是数据管理能力成熟度评审的证据来源。

6.3　现状评估成果与规划成果的分别计数

现状评估阶段的成果与数据治理规划文档是两组材料，分别计数、分别验收，不相互顶替。招标文件列明的 37 份是规划阶段的成果；现状评估阶段另行出具评估类成果，它们是 37 份规划文档的编制输入，不计入 37 份之内。表 6-3 列出现状评估阶段成果及其与规划成果的关系，各成果的章节结构与验收口径在「数据治理规划（一）」一节给出。

表 6-3　现状评估阶段成果及其与规划成果的关系

两组材料的计数口径在项目验收清单中分列：规划成果按 37 份计，评估成果按实际出具份数单列。两者的内容若出现不一致，以评估成果为事实依据、以规划成果为管理依据，规划内容按评估结论调整并在阶段评审会上说明调整依据。

6.4　文档编制与评审发布

每份文档按统一体例编制：封面与版本页、适用范围、引用依据、术语、正文条款、附表与模板、生效与修订记录。制度类文档的正文条款须写明责任主体与可核查的动作，避免只写原则不写动作——「应加强数据质量管理」这类条款无法执行也无法检查，须改写为「某角色在某时点完成某动作并留存某记录」。

评审分三道。项目组内部评审核对体例、条款可执行性、与其他文档的一致性。甲方业务评审由各业务域归口部门核对条款与本域实际业务流程是否冲突。甲方管理层评审确认制度的责任分工与考核要求。三道评审均通过后由甲方按企业文件发布程序发布，发布后的制度即为项目实施的依据。

文档之间存在引用关系，须统一维护一张引用关系表，避免一份文档修订后其他文档的引用内容失效。引用关系表作为治理文档体系的索引随文档集一并交付。

6.5　滚动优化机制

招标文件明确交付文档的数量与名称可在实施阶段滚动优化（b1334）。本项目的滚动优化按三条规则执行。

数量只增不减。37 份是下限，实施过程中若发现某一主题需要单独成文（例如时序数据的采集与质量规范），增编文档并在引用关系表中登记。

拆分与合并须经甲方确认。若某份文档内容过多宜拆分，或两份文档内容高度重叠宜合并，须提交变更申请说明理由与对照关系，经甲方数据治理管理层确认后执行，并在交付清单中保留与招标文件原清单的对应关系，使验收时可逐项核对。

版本与基线。每份文档按版本管理，重要节点固化基线。DCMM 评审前固化一次评审基线，项目验收前固化一次验收基线。基线固化后的修订另起版本，不覆盖基线版本。

6.6　交付时点与评审安排

37 份文档按表 6-1 的计划提交节点分三批交付：第一批为制度与标准的基础件，在数据汇聚与首批数据集加工开始前发布；第二批为运营类规范与办法，在首批数据服务与资产运营启动前发布；滚动更新类与按期出具类随工作进展持续交付。每一批次提交时同时提交该批次的验收证据，按表 6-2 的「验收证据」一列逐份核对。

各份文档的正文内容以现状评估结论与招标方现行制度体系的确认为依据，确认完成即按本章规定的时点、签审层级与证据要求出具。附录佐证卷提供标准规范清单与模板样例，供评审时核对交付粒度；需要查看某份文档的详细样式的，按招标方要求另行提供样例。

7、数据治理实施要求

7.1　实施范围与落地矩阵

招标文件要求根据数据治理规划成果，对数据集生产加工相关的九个业务域，把数据汇聚、数据处理、元数据管理、数据资产管理、数据标准管理、数据质量管理、数据安全管理、数据指标管理、数据服务管理九项内容在数据治理开发工具平台上落地实施（b1336）。

九个业务域与九项治理内容构成一个 9×9 的落地矩阵。矩阵不是均匀的：不同业务域在不同治理内容上的工作量与优先级差别很大。表 7-1 给出各单元格的实施重点与优先批次，优先批次按三批划分，第一批为数据集加工的必需前提，第二批为治理能力成形所需，第三批为运营与优化所需。

表 7-1　九业务域 × 九项治理内容落地矩阵（单元格内为优先批次）

排序依据是业务域对四类数据集的贡献度：研发设计、生产制造、质量管理三个域直接产出工艺设计类、制造过程类、产品质量类数据集的主体样本，仓储物流与设备管理支撑供需计划类与设备诊断类场景，其余四个域主要支撑决策指标与通用场景。营销管理、财务管理、人力资源三个域的数据安全排在第一批，原因是这三个域集中了 L4 与 L5 数据（客户信息、价格与成本、人员信息），分级与权限须先行。

7.2　治理实施的平台载体与责任边界

招标文件要求九项内容在数据治理开发工具平台上落地实施（b1336）。治理平台作为奔牛数据智能平台的治理组件部署，承担元数据、标准、质量、安全策略、资产目录、指标、服务七类治理对象的集中管理，以及汇聚与加工任务的调度与监控。平台的功能模块划分、界面设计与操作流程在「数据集运营平台」一节论述；数据集加工生产的七个生产环节在「四大数据集加工生产总述」及其分节论述。本节讲的是治理实施在平台上的落地方式与各侧责任边界。

责任边界须一次说清，因为治理实施牵涉源系统、治理平台、加工链路、应用侧四方。

图 7-1　治理实施的四侧责任边界与数据流向。数据来源：招标文件第五章 3.2.6.1.2 实施要求与 3.2.6.1.1 规划成果。

四侧边界中有三条须在实施启动前与甲方书面确认，否则实施推进会反复停顿。

第一条是源系统接口的开通范围与配合责任。本项目所需的是按已授权数据域开放只读接口或数据库只读视图，不替换、不重建任何一套业务系统。接口开通涉及原厂配合的，配合方式与工作量须另行确认。

第二条是源头数据错误的处置责任。治理侧负责发现、定位、通知与在服务侧降级维持可用，数据内容的更正由业务归口部门执行。这条边界决定了质量问题整改台账中「责任部门」一列的填法。

第三条是采集范围扩展的现场条件。设备侧采集点位的布设与改造涉及生产现场，停机窗口与施工条件由甲方确认，扩展清单以现场勘察结论为准。

7.3　九项治理内容的落地实施

7.3.1 数据汇聚

数据汇聚解决「数据从哪来、怎么进来」。实施内容包括源清单确认、接入通道建设、增量机制配置、时间基准统一、接入质量入口校验。

源清单按九个业务域梳理，覆盖设计与工艺、物料与库存、工单与报工、检验与不合格品、采购与供应商、设备与测点、公文与合同、项目与商机、在役装备运维各类承载系统。各系统的具体接入方式、增量口径与对接推进安排在「数据资源采集接入」一节论述，本节不重复展开。

本节要落实的是汇聚环节的治理动作，共四项。接入对象登记进元数据，包括源系统、对象、字段、类型、更新频率、负责人；字段按数据元标准做映射登记，无对应数据元的新建数据元草案；按分级标准标注接入字段的安全级别，L4 与 L5 字段的接入须单独审批；接入任务配置入口校验规则与数据量异常告警。四项动作未完成的接入对象，不进入下一环节的加工。

对时序数据与图纸类数据，汇聚环节另有两项专门要求。时序数据须在接入时完成时间基准校正并记录各源的时钟偏差。图纸类数据的解析在内网就地进行，解析产物（图元、尺寸、标注、图层、线型、视图投影关系）作为新的数据对象登记元数据，与原始图纸建立血缘关系，使后续工艺类样本的每一个特征都可回溯到图纸上的具体图元。

7.3.2 数据处理

数据处理解决「数据怎么变得能用」。实施内容按四类处理动作组织。

结构化归一处理：按码表做值域归一，按映射规则做单位与口径换算，按主数据做关联键补全。关联键补全是本项目工作量最大的一项，因为甲方现状中图纸与工艺卡配对关系、焊接参数与焊道对应、热处理炉次与工件和材料批次关联、故障记录与数据段配对均未建立。补全的办法按对象分别设计：有确定性规则可依的（图号与版本对应卡片编号）按规则补全并抽样核验；只能按时间窗与设备位置推断的（焊接参数与焊道）按推断规则补全并标注置信度，置信度低的样本在数据集加工时降权或排除。

文档与图纸解析处理：按文档类型分流解析，输出结构化段落、表格、符号与图元。工艺规程中的粗糙度、坡口、倒角、公差等符号表达须解析为可计算的加工要求，这部分技术实现在「数据加工生产一」一节论述。

时序处理：重采样与对齐、缺段标注、异常点标注、工况分段。工况分段对设备诊断类数据特别重要，因为刮板输送机在井下被液压支架推移、被采煤机在机身上行走，测点信号含有来自其他设备的耦合干扰，不分段直接建模学到的是混合工况下的平均特征。

衍生计算处理：按确定性公式计算衍生字段，例如按中性层公式计算展开长与材料定额。这类计算的要求是同一输入与同一版本必得同一结果且过程可复算，计算所依据的公式版本记录在血缘中。

四类处理动作的共同治理要求是幂等、可重跑、血缘登记完整，见本节第 4 章第 2 节。

7.3.3 元数据管理

元数据管理解决「有什么数据、它从哪来、谁在用」。实施内容是业务元数据、技术元数据、管理元数据三类的采集与维护，以及血缘分析与变更管理。元数据管理办法在「数据治理一」一节交付，本节落实其执行。

业务元数据的采集靠标准建设带动：术语卡、数据元标准、指标卡本身就是业务元数据的主体。技术元数据从源系统字典、数据库目录、加工任务配置自动采集，采集频率按对象变化节奏设定。管理元数据包括责任人、安全级别、质量状态、生命周期状态，由各治理动作写入。

血缘的粒度要求到字段级。字段级血缘是三件事的前提：质量问题的向上溯源、标准变更的影响评估、数据集样本的来源追溯。其中第三件对本项目尤其关键——数据集要做到可溯源，每一条样本须能回答它的各个字段分别来自哪个源系统的哪条记录经过了哪些加工。表级血缘回答不了这个问题。

变更管理的实施要求是：源系统字段变更、加工逻辑变更、标准变更三类事件均触发影响评估，评估结果通知受影响对象的责任人。源系统字段变更的发现依赖技术元数据的周期采集比对，比对发现的未报备变更作为接口协调事项提出。

7.3.4 数据资产管理

数据资产管理解决「数据作为资产怎么登记、怎么作价、怎么被用起来」。实施内容是数据资源目录的建设与维护、权属登记、价值评估的执行、资产运营流程的落地。四项办法与规范在「数据治理一」一节交付，本节落实其执行。

数据资源目录按业务域与数据主题两级组织，条目到数据对象。每个条目呈现的信息包括：业务定义、字段清单与数据元引用、数据量级与时间跨度、更新频率与延迟、质量分与评级、安全级别、可用的数据服务、责任部门、申请方式。目录的价值在于让使用方自己能找到并判断数据能不能用，因此目录的质量状态与安全级别两项必须是实时的而非人工填报的——这两项由质量评分与分级标签自动带出。

权属登记须区分原始数据与治理后形成的数据资产。原始数据的来源与存储位置按源系统登记；治理后形成的数据资产，其所有权与使用权按甲方与项目的约定登记，涉及外部数据衍生品的按外部数据台账中的约定登记。

价值评估的执行依赖使用计量数据，计量来源是数据服务调用记录与数据集流通记录。首轮评估在首批数据服务运行满一个季度后开展，此前不作评估，理由是没有使用数据的价值评估只能靠主观打分。

7.3.5 数据标准管理

数据标准管理在平台上的落地形态是四件事：标准的在线维护与版本管理、标准到物理字段的映射登记、标准发布时的规则派生、标准变更时的影响评估。四件事的规范在本节第 1 章给出，此处说明平台落地要点。

标准在线维护要支持按业务域分权维护：各域归口部门维护本域术语与数据元草案，数据标准管理员审核发布。这一安排是为了让标准维护的工作量分散到业务侧，由项目组集中维护的标准体系在项目结束后往往难以持续。

映射登记支持两种来源：从技术元数据自动推荐（按字段名与类型相似度）与人工确认。自动推荐降低登记工作量，确认权在人。推荐的准确率在首批登记后统计并作为推荐规则调优依据。

规则派生与影响评估的机制见本节第 1 章第 8 节。

7.3.6 数据质量管理

数据质量管理在平台上的落地形态是规则库维护、稽核调度、异常台账、评分看板、问题工单五个部分，对应本节第 2 章的五环闭环。实施要点有三。

规则的分权维护与标准同理：各域业务人员可提报规则需求并参与阈值设定，数据质量管理员审核入库。阈值由业务参与设定这一点很重要，技术侧定的阈值往往与业务容忍度不符，导致大量误报。

稽核调度与加工调度解耦。质量稽核作为独立任务运行，不嵌在加工任务内部，这样稽核规则的调整不需要改动加工任务，稽核失败也不会直接导致加工任务失败——由入口校验按严重级决定是否阻断。

评分看板按三个视角呈现：业务域视角给管理层看趋势，数据对象视角给数据责任人看明细，规则视角给质量管理员看规则有效性。三个视角用同一套底层数据，避免出现口径不一的几张报表。

7.3.7 数据安全管理

数据安全管理在平台上的落地形态是分级标签维护、权限策略配置、脱敏规则配置、审批流程、审计日志与分析五个部分，对应本节第 3 章。实施要点有三。

分级标签的落地粒度到数据元并向上汇总到数据对象与数据集。数据对象的级别取其字段级别的最高值作为默认值，数据集的级别按聚合后敏感度单独定级，不取最大值，理由见本节第 3 章第 1 节。

权限与脱敏策略由分级标签驱动自动生成默认策略，再由安全管理岗按业务需要调整。自动生成的作用是保证新纳管对象不会因为漏配策略而处于无保护状态——默认策略按级别从严，调整只能往宽且须记录理由。

审计日志的采集范围、分析模型与追溯核验要求见本节第 3 章第 3 节。平台侧落地要注意一点：日志量会很大，须按级别分别设定采样与留存策略，L3 及以上全量留存，L1 与 L2 可按采样留存，避免日志存储成本挤占数据存储资源。

7.3.8 数据指标管理

数据指标管理在平台上的落地形态是指标卡维护、指标计算配置、指标血缘、口径一致性校验四个部分。实施要点有二。

指标计算须与指标卡声明的计算逻辑一致，不允许在计算任务里写一套、在指标卡里写另一套。落地做法是指标卡的计算公式以指标标识书写并由平台翻译为计算逻辑，而不是由开发人员按文字描述自行实现。这是本项目防止口径漂移的主要手段。

口径一致性校验在指标发布前运行，检查三件事：是否存在同名不同口径的指标、维度取值是否全部引用已发布码表、来源数据元是否均已发布。三项任一不过则指标不予发布。

决策指标体系的指标选取与问答场景设计在「五个通用场景验证方案」一节论述。

7.3.9 数据服务管理

数据服务管理在平台上的落地形态是服务目录、服务发布与下线、契约与版本管理、鉴权与限流、调用计量与监控五个部分，规范见本节第 5 章第 4 节。实施要点有二。

服务发布须与资源目录联动：服务发布时自动在对应数据对象的目录条目上挂出可用服务，服务下线时同步撤出。两边脱节会出现目录里写着有服务、实际已下线的情况。

调用计量数据同时供三方使用——资产价值评估、安全审计、容量规划，因此计量记录的字段设计须一次满足三方需要，见本节第 5 章第 4 节。

上述九项的实施不停在原则层面。表 7-2 逐项给出平台上的配置步骤与一个本项目的数据处理实例，表 7-3 逐项给出常态运行记录与权限职责分工；验收用例与回退方法在第 7.8 节逐项给出。三张表与本节的九个小节一一对应，构成每一项治理内容从配置、运行到验收的完整约定。

表 7-2　九项治理内容的平台配置步骤与数据处理实例

表 7-3　九项治理内容的常态运行记录与权限职责

7.4　九个业务域的实施重点

九项治理内容是横向能力，九个业务域是纵向对象。横向能力在各域落地时的重点不同，下面逐域说明。各域的工作均包含汇聚、处理、元数据登记、标准映射、质量规则、分级标注六项基础动作，此处只写该域的特殊之处。

研发设计域。核心对象是图纸、物料清单、工艺文件与产品谱系。实施重点有三：建立图号与版本的唯一标识体系并打通与物料编码的对应；建立图纸与工艺卡片的配对关系，这是约 63 万张历史图纸形成成对监督样本的前提；把工作面工况参数（产量与作业制度、地质与煤质、截深截高推移步距等接口参数）结构化登记，这类参数在甲方现状中往往只存在于多方会商过程中而无规范电子留痕，实施时须与业务部门确定补录范围与补录方式。该域的质量重点是图号与版本的准确性和配对覆盖率；安全重点是选型校核公式与修订参数按 L5 管控。

生产制造域。核心对象是施工号、工单、工序、报工、工艺执行记录、热处理炉次、焊接过程参数。实施重点有四：建立工序主数据与工序代码体系，把 28 道备料工序及其余工序在总工艺路线与各车间卡片之间的名称差异归一；建立炉次与装炉工件清单、材料批次、设定程序、实际温度曲线、检验结论的串联关系；建立焊接参数流与工件标识、焊道标识的时间窗对齐机制；对报工时点相对实际作业的滞后做量化刻画，作为制造过程类样本时间字段可信度的依据。该域规则数量最多，质量重点是完整性、及时性与跨系统一致性；安全重点是关键工艺参数窗口按 L5 管控。

质量管理域。核心对象是检验项目与记录、交检拍照、质量报告、不合格品与返修票据。实施重点有三：建立检验项编码体系并与工艺标注的关键工序、重要尺寸建立对应，使工艺要求与检验执行可以逐项核对；把自由文本的缺陷描述按聚类结论归一为缺陷类型代码，这是质量类数据集标签体系的来源；把不合格品票与返修记录的流转结果回填到工件与工序上，形成可用的结果标签。该域的质量重点是准确性与配对完整性。

仓储物流域。核心对象是实物库存、批次、库位、物料流转。实施重点有二：打通企业资源计划库存账、仓储管理实物库存与项目占用三者的时点口径，这是库存三方比对与库存控制场景的前提；建立批次号在采购到货、入库、领用、热处理装炉之间的贯通，使材料来源可追溯。该域的质量重点是一致性与唯一性。

设备管理域。核心对象是设备台账、测点配置、时序数据、报警记录、维修工单与备件。实施重点有三：建立设备编码与测点标识体系，并把炉台、焊接产线、自动化产线设备、在役装备纳入同一编码空间；建立测点可信度评价机制，识别断链、漂移与失效测点，这是设备诊断类样本输入可信的前提；把服务工单与备件出库记录回填到报警事件上，逐步积累故障与数据段的配对样本。该域的质量重点是及时性与准确性；该域数据量级最大，须注意存储与计算成本。

采购管理域。核心对象是供应商、采购订单、到货批次、采购价格与周期。实施重点有二：建立供应商主数据并与材料批次来源关联；把采购价格与周期数据的口径统一，供库存控制场景的采购时机判断使用。该域的安全重点是价格与成本按 L5 管控。

营销管理域。核心对象是客户、矿方项目、商机、销售预测、合同与交付节点。实施重点有二：建立客户与项目主数据，并与施工号建立唯一对应；把销售预测与需求计划的口径对齐，供供需计划类数据集与库存控制场景使用。该域的安全重点是矿方客户信息与矿井位置按 L4 管控，去标识后方可进入数据集。

财务管理域。核心对象是科目、成本中心、物料价格、项目成本归集。实施重点有二：建立物料价格的权威源并解决企业资源计划与财务两侧价格不一致的问题；建立项目成本归集口径，供选型场景的参考报价核算使用。该域的安全重点是成本构成与项目报价按 L5 管控。

人力资源域。核心对象是组织、岗位、人员、技能资质、班组与排班。实施重点有二：建立组织与岗位编码，作为权限模型与责任留痕的基础，这一项是其他八个域的权限管理与操作留痕的前提，因此虽然该域在数据集贡献上权重最低，组织与岗位主数据的建设须排在第一批；按个人信息保护要求对人员数据做分级与去标识，人员数据原则上不进入数据集，确需使用的以去标识后的岗位与技能属性形式使用。

7.5　五条跨域处置流程

治理动作落在单一域内时流程清楚，跨域时容易停在无人裁决的状态。本项目把五类跨域情形写成固定流程，每一条都明确触发、定位办法、裁决人、执行动作与完成标志。五条流程共用同一条骨架：触发登记、定位影响面、裁决与处置、回写与验证。

图 7-2　五条跨域处置流程的共用骨架与各自的处置动作。数据来源：招标文件第五章 3.2.6.1.2 实施要求与 3.2.6.1.1.2.5 至 3.2.6.1.1.2.9 各域管理要求。

跨域规则冲突。同一数据对象被两个域的规则同时约束而结论相反，是规则库规模上来之后必然出现的情形。典型如：标准域要求物料编码一物一码，而仓储域的历史实物账中同一物料存在两条在用编码；安全域要求某字段对外服务一律脱敏，而质量域的跨系统比对规则需要该字段明文参与比对。处置办法是：冲突由稽核结果或配置校验自动识别并登记为冲突单，由数据标准管理员与数据安全管理岗联合定位涉及的规则、对象与业务流程，提交数据治理管理层裁决；裁决结论写入规则元数据的例外说明，涉及的规则同步更新并复跑一次稽核，复跑结果与裁决结论一并归档。裁决未出之前，按从严一方执行，不以任一方单独放行。

历史数据修复。标准发布、口径调整或规则修订之后，存量数据往往不符合新口径。不加区分地全量重算代价高且会打断在产的数据集加工，因此修复按影响面分级处理：由血缘定位受影响的物理字段、加工任务与已交付数据集，按三档确定范围——影响数据集样本标签的全量重算，影响统计口径的按期段重算，仅影响展示的不重算而在资源目录标注口径变更时点。重算结果标注修复批次号并在血缘中登记，已交付的数据集按版本追加修订说明，不覆盖原版本。修复期间原口径数据继续可用并标注口径标识，避免下游在两套口径之间无法分辨。

外部数据的共享限制传导。外部数据的许可范围是一组限制，这组限制必须传导到由它衍生出来的每一件产物上，否则限制在第一次加工之后就失效了。处置办法是：外部数据台账中的许可范围在引入时即写入数据卡，加工任务按血缘把限制标识传递给衍生对象与数据集；开放授权与服务发布时，平台按限制标识自动收紧可选的受众范围与交付形态，许可不覆盖的组合不出现在可选项中。许可条款发生变化的，按血缘反向定位全部衍生物并逐件复核，复核结论回写台账与数据卡。

退役清理。退役不只是删一份数据，而是要把这份数据在资源目录、元数据血缘、质量规则、服务目录、授权凭据五处的痕迹一并处理干净。处置办法是：退役处置单发起后，由血缘自动列出下游引用清单，下游仍有引用的挂起处置并生成下游改造任务；改造完成或下游书面确认可接受数据缺失后，按归档或销毁路径执行，销毁范围须逐项列出副本清单并逐项确认；执行完成后，资源目录条目置为退役、血缘节点置为历史态、相关质量规则停用、相关服务下线、相关授权凭据回收，五处回执齐备方可关闭处置单。

权利撤回的传播。外部数据供方撤回授权、个人信息主体撤回同意、合作方终止数据提供，三类情形的共同要求是撤回必须传播到全部副本与衍生品。处置办法是：撤回登记后立即冻结相关数据对象的全部授权凭据与在用服务，由血缘列出副本、衍生对象与已交付数据集；按撤回的法律效力确定处置方式——要求删除的，副本与衍生品按约定清除并出具处置回执；仅要求停止新增使用的，存量保留但标注停用并从后续加工中排除。涉及已交付数据集的，按数据卡中的回退约定执行并通知使用方。处置全过程留痕，回执作为合规证据归档。

五条流程的触发、定位办法、裁决人与完成标志汇总见表 7-4，表中各项即为跨域处置的作业约定。

表 7-4　五条跨域处置流程的触发、裁决与完成标志

五条流程的共同点是以血缘为定位手段。血缘登记不到字段级，五条流程的第二步都无法执行，这也是第 7.3 节把字段级血缘列为加工任务发布前提的原因。

7.6　五项专项规划的治理依赖与建设顺序

五项专项规划之间是单向依赖关系，依赖决定实施动作的先后与各项成果的发布时点。数据标准先行：数据元与值域一经发布，质量校验规则才有判定依据；标准未发布的对象，规则只能停在空值率一类浅层检查上。数据安全的分级标签是权限、脱敏、审计三类管控策略的输入；分级未定，防护策略只能按系统边界粗粒度下发。数据生存周期把标准与质量的要求嵌进需求、设计开发、运维、退役四个阶段的动作里，承接前两项的输出并把要求转为过程中的检查点。数据应用流通是出口，决定治理后的数据以什么形态、按什么权限、向谁提供，其服务标准与开放授权规则以前三项的成果为判据。规划成果交付贯通五项，按各项的发布时点出具文档并留存签审记录。

上游四个规划域为本章五项专项规划提供输入：现状评估给出数据资产盘点结论与能力差距清单，数据战略给出重点任务与资源投入，数据治理组织与制度给出归口责任与审批层级，数据架构与数据资产给出模型分层、数据流图与资源目录。四个域的规划成果在「数据治理规划（一）」一节交付，其发布时点先于本章首批标准的发布；上游成果未到位的业务域，本章按表 7-5 的过渡办法推进，不以等待为由停止该域的治理动作。

表 7-5　五项专项规划的依赖关系、输出与发布时点

图 7-3　五项专项规划的依赖链与数据安全域的贯穿关系。数据来源：招标文件第五章 3.2.6.1.1.2.5 至 3.2.6.1.1.2.9 各域输出要求。

依赖关系落到实施步骤上是五步：第一步按资产盘点清单确定首批纳管对象，第二步为纳管对象登记数据元并标注安全级别，第三步按已发布标准派生首批质量规则并投入稽核，第四步把标准、规则与分级要求配置为生存周期四阶段的检查点，第五步按服务标准发布首批数据服务并开通开放授权。五步之间以前一步的登记完整率为放行条件，未达放行条件的对象顺延至下一批，不跳步推进。三阶段的时间安排与阶段门禁见第 7.7 节。

7.7　实施路径与里程碑

实施按三个阶段推进，阶段划分的依据是数据集加工对治理成果的依赖顺序：第一阶段交付加工所必需的标准、分级与质量规则并完成重点域汇聚；第二阶段补齐治理能力的其余部分并支撑首批数据集与场景验证；第三阶段转入常态运营、DCMM 评审与优化。

图 7-4　数据治理实施的三阶段路径、阶段门禁与贯穿动作。数据来源：招标文件第五章 3.2.6.1.2 实施要求与第 3 章建设周期要求。

表 7-6 给出各阶段的主要工作项与完成标志。具体日期在合同签订后按项目总体计划排定，本表给出的是阶段顺序与完成标志，项目管理的进度计划与资源安排在服务方案「项目管理措施」一节论述。

表 7-6　实施阶段工作项与完成标志

7.8　实施的验收口径与回退安排

治理实施的验收不以「文档交齐」为唯一标志，而以可核查的运行状态为标志。表 7-7 逐项给出验收口径、可当场执行的验收用例与不达标时的回退方法。验收用例的作用是让验收有可重复的操作：按用例执行一遍，结果与口径一致即为通过，不以说明材料代替执行结果。

表 7-7　九项治理内容的验收口径、验收用例与回退方法

表中各项「约定水平」属招标文件未规定的过程优化目标，在实施启动阶段依据现状调查与首轮基线测试确定，确定后写入项目质量计划，按季考核并留存达成记录。招标文件已明定的指标按招标要求承诺并纳入验收，不随基线测试结果调整；两类目标的区分口径见第 2.3.2 节。

7.9　实施的前提条件与风险应对

治理实施的推进依赖若干外部前提，这些前提不成立时的应对安排须事先说清，而不是在实施中临时商议。

表 7-8　实施前提条件与风险应对

六项前提中，前两项是本项目推进节奏的主要变量。本节的处理方式是把它们明确为前提而非隐含假设，并给出过渡方案与量化口径的调整办法，使实施进度与数据集规模的关系可以随前提的落实情况被重新核算，而不是在交付时才发现差距。