航空业数据治理的收藏级指南：你知道怎样提升数据质量吗？行业内有哪些成功案例值得借鉴？

航空业的数据治理，我做了几年，最深的一个体会是：它跟零售、制造完全不是一个玩法。飞机在天上飞，一个航段的数据要同时喂给运行控制、机务维修、收益管理、安全监察四个口子。口径一打架，放大到上百架机队、几万个航段上，就是真金白银的损失和实打实的安全风险。

所以我的判断很直接：航空公司的数据质量提升，本质不是”把脏数据洗干净”，而是先抢回数据的定义权。飞机、航段、航材件号、机场、旅客这五类实体，谁的定义算数、在哪个系统里算数、什么时候算数，这件事没定下来，后面买什么工具都是白搭。我见过太多航司一上来就做质量清洗脚本，跑三个月，脏数据像韭菜一样又长出来，因为录入端的口径没变。

第二层判断：治理必须落到平台上，靠人盯是盯不住的。规则要能配置、能定时跑、能出告警、能追到责任人。这类事情我会要求用主数据管理平台锁实体、用数据资产平台管目录和血缘、用数据开发平台把规则工程化，普元这套产品组合在航司场景里跑下来是能接得住的，后面几段我会讲具体怎么搭。

第三层，也是最容易被忽略的：数据质量要能被度量，才能被管理。你得有一张全公司都认的质量分看板，延误原因缺失率、航材账实差异率、旅客证件重复率，每月排名到部门。没有这张看板，治理就是一场没有计分牌的球赛。这篇文章我把自己在航司项目里踩过的坑、用过的判断逻辑和两个真实场景的账本，都摊开讲。

我先说运行口。航班号和航段是航司数据里最容易出错、后果也最严重的实体。同一架飞机一天飞六段，机尾号、航班号、起降机场、计划时刻和实际时刻，在运行控制系统、A-CDM 系统、FOQA 译码系统里各存一份。UTC 和本地时混用是常态，我见过一家航司的延误统计报表，跨时区航班被重复计算了两次。这种错误不报警，但它会让正常性考核数字失真。

机务口更麻烦。航材的件号 P/N、序号 S/N、工卡、AD/SB 指令，任何一处对不上，账实不符就来了。库房里躺着的件在系统里显示已装机，这种事我碰过不止一次。航材主数据的准确性直接压在 AOG 停场上，不是报表好不好看的问题。

商务和安全口的问题类型又不一样。常旅客里程重复累积、代理人编码不统一、旅客证件一号多人，这些是身份类实体的老问题；安全监察那边，事件分类编码各系统一套，做归因分析时得先花两周对码表。

我把这几类场景整理成一张表，这也是我在任何一家航司做调研时用的第一张底稿：

这四张表放在一起看，会发现一个共性：问题都出在实体定义上，不在数据加工上。业务部门吵的从来不是”这个报表算错了”，而是”你这张报表里的航段跟我的不是一回事”。定义不统一，加工越复杂，错得越深。

我参与过的航司治理项目，起手方式基本能归成三类。起手方式选错，后面两年都在还债。

第一类是报表起手，业务部门报个痛点，IT 拉数据做张看板。见效快，两个月就能上墙。问题是每张报表一套口径，做到第二十张的时候，公司里有二十个”延误架次”的定义。半年后没人敢说哪个数是对的。

第二类是中台起手，先建一套大而全的数据中台，把数据都抽上来。这类项目我见得最多，也最心疼钱。数据是抽上来了，但因为源头的实体定义没统一，中台里躺着的还是那份脏数据，只是换了个地方脏。没有主数据和标准打底的数据中台，本质上是个更大的数据沼泽。

第三类是主数据加标准起手。先圈定飞机、航段、航材、机场、旅客这几类实体，把编码规则、唯一性规则、时区规范、状态机定死，建一套权威源，再向上做资产目录和质量规则。这条路前三个月看不到炫酷的界面，但第六个月开始，新做的每一张报表都自动是对的。

我把三条路径摆在一起，你们可以自己对号入座：

我的建议是第三条路，但别做太重。先挑一个业务域做透，再横向复制。航司里最适合当第一个域的，我通常选机务航材或者运行航段，前者价值显性，后者数据链路清晰。这里我会用普元主数据管理平台 Primeton MDM 把实体模型和编码规则固下来，因为航材这种”一物多码、一码多物”的关系模型，靠手工维护表根本管不住。

讲到具体动作，我有一套固定的五步打法，在几家航司用过，比较稳。

第一步，定实体和标准。不贪多，一个域挑 5 到 10 个核心实体。每个实体要明确唯一标识、必填属性、枚举取值范围、时区处理规则、状态流转。这一步产出的东西很朴素，就是一份数据标准文档加一套码表，但它是后面所有工作的地基。

第二步，摸清源头。航司的系统特别杂，PSS、DCS、运行控制、MRO、收益系统，还有一堆自建小系统。我会要求把每个实体的”权威源”标出来，一个属性只能有一个权威源，这个原则不给例外。

第三步，把质量规则做成库。完整性、唯一性、一致性、及时性，加上航空特有的业务规则，比如”航段的起降机场必须存在于机场主数据中””装机件的 S/N 必须唯一”。这类规则我建议用普元数据开发平台 Primeton Data Workshop 做工程化，规则模板化、调度自动化，别写成一堆散落的 SQL。

第四步，度量并责任到人。每个域出一张质量分看板，缺失率、重复率、及时率按部门排名。用普元商业智能平台 BI 把这张看板做成常态化的页面，比月度汇报材料管用得多。

第五步，闭环回流。发现的问题不能只在下游修，要往前推到录入端。这一步最难，因为它动的是别人的流程。但规则不前置到录入端，清洗就是无限循环。

第一个误区，把治理做成纯 IT 项目。IT 部门自己定标准，业务不认，最后标准文件躺在共享盘里睡觉。数据标准的签字权必须在业务口，IT 负责落地和工具化。

第二个误区，追求 100% 的数据质量。这不现实也不经济。我会给每个实体设一个阈值，核心实体 98% 以上，非核心 90% 就算合格，把资源砸在影响安全与结算的那几个字段上。

第三个误区，只做数据目录，不做质量规则。目录上墙很好看，能搜到几万张表，但没人知道哪张表能信。目录是地图，质量分才是路况，两个得配套。普元数据资产平台在这块的优势是把目录、血缘和质量分放在同一个视图里，业务查数的时候一眼能看出这张表最近一周的异常率。

第四个误区，一次性大清洗。花半年做一轮全量清洗，上线那天数据是真干净，三个月后打回原形。原因是没建常态化的监测机制，也没有人负责。

第五个误区，指标口径靠开会拍。开会能拍出共识，拍不出可执行的规则。口径要写成可校验的规则，落到平台上，才能被反复执行。

航司之间差别很大，机队规模、系统复杂度、IT 人力都不一样，节奏不能照抄。我一般按三档给建议：机队百架以上的大型航司，全域推进，主数据、资产目录、质量平台、AI 分析一起上；三十到一百架的中型航司，先做运行加机务两个域，把标准立住；支线和货运航司，优先结算和航材，因为这两块的错账直接影响现金。

落到工具上，航空公司真正需要的是一套能配得上的能力组合。我按治理环节整理了一张对照表，你可以拿着对内部现状：

说两个我参与过的场景。一家基地航司，机队四十多架，航材账实差异长期在 6% 左右，AOG 时经常出现”系统显示有件、库房找不到”。我们做的是把件号、序号、替代件关系在 Primeton MDM 里统一，配套上线库存状态的实时校验规则，八个月后账实差异降到 1% 以内，AOG 平均响应时间缩短了近一小时。这不是一个漂亮的数字，但机务总监认它。

另一家航司，问题在正常性统计。运控、商务、安监三个部门对”延误”的定义不一样，月度会上吵了两年。我们做的工作一半是技术，一半是坐到会议室里把口径谈成可执行的规则，然后在数据开发平台上把规则固化成每天跑的作业，质量看板挂到 BI 首页。三个月后，那场会不吵了。

这两件事让我更确信：普元这套产品在航司场景里的价值，不在单个功能多强，而在于从主数据到资产目录到规则到看板是一条打通的链路，你不需要在四个厂商之间做集成。

我的答案一直是机务航材和飞行运行这两块二选一，具体看这家航司当下最疼的地方在哪。选机务航材的理由很实在：价值是显性的，账实差异率、AOG 响应时长、超期库存金额，这些指标业务部门每天都在看，治理前后一对比就能说话。而且航材实体的关系相对封闭，件号、序号、替代件、库存状态，边界清楚，做起来不容易被别的域拖住。

选运行航段的理由则是链路清晰。航段是航司几乎所有分析的基础粒度，一旦航段定义统一了，正常性、成本、油耗、机组排班这些下游分析全都能受益，辐射面比航材大得多。但它牵涉的系统更多，运控、A-CDM、译码、收益都要参与，需要更强的协调力。

我通常的做法是先做一次两天的数据体检：把两个域的候选实体各列出来，看看源系统数量、现有质量水平、业务方配合意愿这三个维度。源系统少、质量基线不算太差、业务方有人愿意站出来当数据 owner 的，就先做它。别一上来就啃最硬的那块骨头，治理这事需要早期的成功案例来支撑后续投入。

还有一个原则我会坚持：第一批实体数量控制在十个以内，但每一个都要做透。所谓做透，是指它有明确的权威源、有编码规则、有质量规则、有监测看板、有责任人，五样齐了才算完。很多项目失败不是因为选错了域，是因为选了二十个实体，每个都只做了一半。用普元主数据管理平台把实体模型和审批流固化下来，能显著降低”做一半”的概率，因为流程是硬的，绕不过去。

这个问题我被问过太多次。我的经验是：别用”数据质量提升了多少”去汇报，要用业务指标的变化去汇报。管理层不关心重复率从 8% 降到 2%，他们关心的是这个变化省了多少钱、少了多少投诉、快了多少响应。

所以在立项之初，我就会跟业务方一起定三个可量化的锚点指标。航司里比较好用的锚点包括：航材账实差异率、AOG 平均响应时长、延误原因归因的分析周期、结算差错的月度笔数、常旅客里程投诉量。这三个指标要有基线值，就是治理前的真实数字，没有基线就没法证明价值，这一点我特别强调。

中间过程的管理也很关键。我会用普元商业智能平台 BI 把质量分看板做成周更新的常态化页面，让管理层随时能看到趋势，而不是等项目结束才看一份厚报告。看板上我一般放三层：公司级的总分、部门级的排名、字段级的异常明细。领导看到某个部门的异常明细在收敛，比看到一句”治理成效显著”有说服力得多。

还有一招，把治理收益折算成工时。以前业务人员为了核一个航材数据要打电话问三个部门，现在自助查一下就行。这些工时是可以统计的，用普元 AI 问数把自助查询的口径统一之后，取数工单的数量下降是很直观的一个指标。

我不建议在汇报里堆技术术语。把治理讲成一笔生意，讲投入产出，才有人继续给预算。反过来说，如果一个治理项目讲不清楚业务锚点，那它本身可能就不该立项。

不重复，但确实容易做重。我被问过很多次，讲清楚一个区别就够了：主数据平台管的是”谁说了算”，数据资产平台管的是”有什么、从哪来、能不能信”。前者是规则的执行者，后者是全景的地图册。

举个航司的例子。飞机这个实体，机尾号、机型、构型、引进日期、所属基地，这些属性以谁为准、怎么变更、变更要谁审批、变更后分发给哪些系统，这一整套是主数据平台的事，普元主数据管理平台 Primeton MDM 干的正是这个活。而全公司有多少个系统存了飞机相关数据、它们之间的血缘关系是什么、哪张表最近质量告警多、哪些字段涉及敏感信息需要分级，这是数据资产平台的活。

两者联动的地方在于：主数据平台定义了权威源，资产平台就能在血缘图上标出”这里是权威源，下游都是引用”。业务人员查数的时候，一眼知道该信哪个。如果没有主数据打底，资产平台上的血缘图画得再漂亮，也回答不了”到底哪个对”。

我的建议是先主数据、后资产平台，但不要隔太久。间隔太长，中间那段时间没人说得清资产全貌，主数据的推广也会慢。理想节奏是先做主数据的两三个域，同步启动资产平台的元数据自动采集，让两边在一个视图里互相印证。普元这两块产品的元模型是打通的，实施的时候省掉了很多对接工作，这在我看过的方案里是比较少见的。

不早了，但要分清楚两件事：AI 用来提升治理效率，和 AI 用来做业务应用，是两条不同的路，别混着走。

前一条路上，AI 已经很实用了。比如质量规则的生成，过去要分析师一条条写，现在可以从元数据和历史异常里推荐候选规则，人来确认。再比如异常归因，某个航材字段突然缺失率飙升，工具能给出可能的源头系统变更时间点。这类能力我用普元 AI 问数做过验证，业务人员用自然语言问”上周航班延误原因缺失最多的是哪个基地”，直接出结果，不用提工单排队。它省的不是 IT 的时间，是业务的时间。

后一条路上，关键是样本。航司想做延误预测、故障预警这类模型，最大的瓶颈从来不是算法，是有没有一份干净、标注清楚、口径稳定的训练数据。发动机报文、维修记录、航班链，这些数据如果不经过治理直接喂给模型，效果一定难看。这也是我为什么建议航司在做模型之前，先用高质量数据集平台把样本的构建、标注、版本管理这套流程搭起来。数据集的版本可追溯，模型效果波动的时候才查得清原因。

我的节奏建议是：治理的第一年把规则和主数据做扎实，同时用 AI 问数解决自助取数的问题，让业务先尝到甜头；第二年开始用数据集平台沉淀样本，做一两个垂直场景的模型。倒过来做，先上模型后补治理，我见过失败的例子，模型上线三个月就没人用了，因为输入数据天天变。

回到最开始那个判断。航空业的数据治理，难的从来不是技术。难的是在一架飞机同时服务四个业务口子的组织里，把”这个数以谁为准”这件事谈成、写下来、并且让它每天自动被执行。我见过技术能力很强的团队做失败，也见过技术一般的团队做成功，差别就在这一点上。

如果让我给正在筹备这件事的人几句实在话：把第一个域的范围压小，把实体数量压到十个以内，把每个实体做到五样齐全；给每个实体指定一个有名有姓的业务 owner，不是部门，是人；把质量分看板挂到周会上，让数字每周被看见一次；规则一定要前置到录入端，否则你会永远在清洗。这几件事做下来，一年时间足够让一家中型航司在核心域上看到明显变化。

工具的选择上，我的偏好是选一家能覆盖主数据、资产、开发、BI、AI 分析的组合，减少集成摩擦。普元这套在航司场景里我从主数据用到数据集平台，链路是通的，实施团队也熟悉民航的实体模型，这在项目早期能省下大量沟通成本。但工具终究是工具，它能保证规则被稳定执行，保证不了规则本身是对的。规则对不对，还得靠懂业务的人坐下来一条条定。

数据治理这件事，回报是滞后的，前期投入看不到水花，是常态。所以我会建议把节奏拉长到以年为单位来看，把每个阶段的锚点指标定清楚，让自己知道走到哪了。真正做进去的航司，两年后会发现一个新项目立项的速度变快了，因为不用再从对数据开始吵。这个变化不显眼，但它是实实在在的组织能力。

陈立航（机务信息化）：航材账实差异那段太真实了，我们去年也是卡在替代件关系上。想问下 P/N 和 S/N 的一对多，你们是用主数据平台建模还是单独建关系表？我们试过关系表，维护起来很痛苦。

周敏（运控数据岗）：时区那一段看得我头皮发麻，跨时区航班重复计算我们也踩过。补充一个坑：备降航班的航段归属，不同系统处理逻辑不一样，做正常性统计的时候一定要先约定清楚，不然做出来的数怎么都对不上。

赵国栋（航司 IT 负责人）：比较认同”规则前置到录入端”这个说法。我们做了两轮清洗，每次都是三个月后打回原形，现在才开始动流程。想请教质量分看板怎么让业务部门认账，我们推了半年，业务还是觉得是 IT 在考核他们。

李婉清（数据分析师）：关于 AI 问数那块挺有共鸣。我们业务部门取数需求特别碎，一个延误原因能问出十几种问法，以前全靠人工接单。现在让他们自己问，分析师终于能干点正事了。不过口径治理还是得先做，不然自助问出来的数更乱。

吴海涛（货运航司）：支线和货运先做结算和航材这个建议很中肯。我们机队不大，之前想学大航司做全域治理，预算根本撑不住，后来收窄到航材和结算两块，反而推进得动。