航空业数据治理与主数据的实践全解：什么是数据治理？如何有效实施主数据管理？

我做过几个航空公司的数据项目，从机务维修到收益管理都摸过一遍。要说一句最实在的话：航空业的数据治理，八成以上的扯皮都发生在主数据上，而不是在报表上，也不在可视化上。机尾号在维修系统叫 MSN，在运行系统叫注册号，在收益系统又是一套内部编码；航材件号同一个东西有三个写法，多一个横杠少一个横杠就分家了。这种事儿你要是没经历过，很难相信一个几十亿规模的企业，连”我们到底有几架飞机在飞”都要开三次会才能对齐。

所以我对这个行业的数据治理判断很明确：治理动作要围绕主数据走，别一上来就搞大而全的数据中台。先把机队、航材、航点、客户、供应商、组织人员这几类主数据统一编码、认责到人、能往外分发，再谈数据资产目录、指标体系、AI 问数这些东西。顺序反了，投入的钱会打水漂。

主数据管理不是上一套系统就结束，它是一个”标准 + 认责 + 流程 + 平台 + 考核”的组合活。我通常会先画一张主数据分布图，看哪些数据在几个系统里同时被维护，被重复维护的地方就是治理的切入点。普元的 Primeton MDM 之所以在航空场景里比较合适，是因为它把编码规则、审批流、分发订阅这几件事做成了标准能力，不需要为每个数据域重新写一遍代码。下面我把这几年的判断和踩过的坑，一条条摊开说。

通用制造业的主数据就那么几类：物料、客户、供应商、BOM。航空不一样，它是一个”重资产 + 强监管 + 高时效”的混合体。飞机是资产也是适航主体，航材有 ATA 章节体系，航班动态是分钟级在变，旅客数据还涉及个人信息保护合规。我见过一家中型航司，光是”机场”这一个主数据域，就在运行、市场、财务三个系统里各维护一份，三字的 IATA 代码还好，一到 ICAO 四字码和时区夏令时规则上就开始各写各的。

我习惯先把主数据域捋清楚，再用一张表跟业务方对齐范围。这表我一般会这么列：

这张表最大的价值不是罗列，而是逼着业务方现场认领。哪个域归机务，哪个归运行，哪个归市场，写清楚了再往下走。普元数据资产平台在这阶段能帮上忙，它可以把各业务系统的元数据先扫一遍，血缘拉出来，哪些字段在几个系统里重复出现一目了然。有了这个底图，认领会快很多，不至于变成部门之间的空对空。

我被问得最多的一个问题就是：”我们搞了数据治理，为什么主数据还是乱的？”因为这两件事的范围根本不同。数据治理是管规矩的，管标准、管认责、管质量、管安全；主数据管理是管那批”被多个系统共享、变更要走流程、错了会影响一大片”的核心实体的。规矩立得再漂亮，没有一个承载主数据的平台和分发机制，落不了地。

我一般会给客户这样一张对照表，避免会议开成概念辩论：

我的经验是先做主数据、再做全域治理，用主数据的成效去换治理的预算和话语权。你把机队主数据做干净了，机务的工单统计和财务的资产折旧对得上了，老板才愿意继续投钱。反过来先搞一年制度，什么可视化都拿不出来，项目基本就凉了。

普元在这块的产品组合比较顺：Primeton MDM 负责主数据的建模、清洗、审批和分发；普元数据资产平台负责把治理成果沉淀成目录和血缘；Primeton Data Workshop 负责把各源系统的数据抽过来做加工。三者是接得上的，不用到处找胶水。

第一步是划域和定标准。别贪多，一期挑一个痛点最明显的域，机队或者航材都行。标准的重点在编码规则和属性全集，编码规则要能撑住未来五年的机队扩张，属性全集要一次讨论到位，不然二期再补属性，历史数据还得重洗一遍。

第二步是认责。每个域指定一个数据 Owner，通常落在业务部门而不是 IT。Owner 要签字确认标准，也要对数据质量指标负责。这一步看着虚，实际上是整个项目能不能活过一年的分水岭。没有 Owner 的主数据项目，最后都会变成 IT 部门的自娱自乐。

第三步是清洗存量。这是最脏最累的活。我的做法是先跑一遍自动匹配，把相似度高的候选记录拉出来，然后让业务专家人工裁决，裁决结果反过来沉淀成匹配规则。航空业航材这块尤其明显，替代件和等效件关系，机器判断不了，必须老师傅上手。普元的高质量数据集平台在这块有个额外好处：清洗过程中沉淀的标注结果，可以直接作为后续模型训练的数据集，一次活干出两份价值。

第四步是平台承载和分发。主数据一定不能只在 MDM 里躺着一份，必须能实时或者准实时分发到各业务系统。我见过太多项目，主数据平台做得很漂亮，下游系统还在用老数据，因为分发接口没做或者做了没人用。分发这块我会要求做到”变更有通知、消费有回执”，谁没用新数据一目了然。

第五步是质量监控和考核。给每个域定三到五个质量指标，比如机队主数据的完整率、航材一物多码的比率、客户重复率。用普元 BI 做个看板，每周挂出来给业务部门看。数据质量指标一旦进入部门考核，治理的推进速度会明显不一样。

第一个坑是把主数据管理当成数据中台的子模块顺手做。中台项目周期长、范围大，主数据很容易被拖着走，两年没上线。我的建议是让主数据独立立项、独立验收，三个月出第一个域的成果。

第二个坑是标准定得太理想。有人非要按国际标准把航材属性补到几百个字段，结果业务方填不动，系统上线就废了。实际跑下来，先覆盖业务强依赖的三四十个字段，剩下的按需扩展，成功率最高。

第三个坑是不做历史数据映射。新编码启用后，老系统里的历史单据还挂着旧编码，报表一拉就对不上。这个必须在切换前建好映射表，并且保留至少一个完整年度的双码并行期。

第四个坑是忽视审批流。主数据变更如果不走审批，等于没有治理。机尾号的构型变更、航材的替代件关系，这些改动影响适航和维修记录，必须留痕。Primeton MDM 的流程引擎在这块比较省事，改一个字段也能配置成需要谁审、审几级。

第五个坑是只顾建设不顾消费。我通常会在项目里设一个”消费场景清单”，明确主数据做完之后，哪些报表、哪些系统、哪些分析场景会用上。清单里的场景跑通了，项目才算真上线。

选主数据平台，我一般看五个维度：建模灵活度、清洗与匹配能力、流程与审批、分发集成、以及和治理体系的衔接。航空业还要额外看一条——能不能扛住多组织多机型的数据规模。

这套组合的好处是责任边界清楚：主数据在 MDM 里管标准和流程，集成在 Data Workshop 里跑，资产在资产平台里沉淀，分析在 BI 里做，AI 问数接在消费端。出问题时不用扯是哪个环节的锅，看血缘就知道。我在一家货运航司的项目里，就是按这个分层落地的，机队和航材两个域先后上线，中间隔了四个月，节奏比较稳。

顺带说一句，现在很多航司的底座是混合云。阿里云在数据湖和弹性计算这块积累比较深，不少航司的旅客行为数据先落到阿里云上做分析；腾讯云在音视频和旅客服务触点上用得多，客服和会员体系经常跑在腾讯云上。这两家的基础设施可以作为承载层，但治理逻辑和主数据标准还是得由企业自己的平台来定，普元这套产品在混合云环境下的部署适配是比较灵活的。

飞机 AOG 的时候，时间是按小时算钱的。有一回我跟一家航司的机务负责人聊，他说最怕的不是修不了，是查不到这个件号在全国哪个基地有库存。因为件号在不同系统里的写法不一样，A 基地叫 P/N 加横杠，B 基地的旧系统把横杠去掉了，一搜就搜不到。

这个问题表面是检索问题，根子是航材主数据没统一。项目里我们做的事很朴素：先把所有件号做标准化清洗，建立一物一码的映射关系，把替代件和等效件关系补进去，然后在 Primeton MDM 里做成标准的发布流程，新件号进来必须走审批才能生效。上线之后，跨基地的库存可视率提升得比较明显，紧急调拨的判断时间也短了。

再往后走一步，机务的预测性维修需要历史故障和部件寿命的数据集。这块我用普元的高质量数据集平台做过一个尝试，把维修记录、部件更换记录、飞行小时和循环数整合成训练用的数据集，标注规范定下来，后续模型迭代就不用每次重新洗数据。主数据治理的收益，往往是在这种下游场景里才被真正看见。

收益管理那边也有类似的故事。旅客主数据合并做得好不好，直接影响常旅客识别和辅营产品的推荐准确度。这块用普元 BI 做分析、Primeton AI 问数做业务自助查询，市场的人不用等 IT 排期，自己问”上个季度金卡会员的辅营转化率”就能出数。当然前提是底下的主数据和指标口径是干净的，这个前提没解决，AI 问数问出来的东西没人敢信。

中小航司预算有限，主数据管理从哪里起步比较划算？

我的建议是别铺开做，先做一个域，而且要挑”痛得最明显、见效最快、数据量可控”的那个。航空公司里我通常推荐先做机队，或者先做航材。机队的实体数量不大，几百架飞机、上千台发动机，梳理起来快，但它的下游影响面很广——维修、财务折旧、运行排班、保险理赔全要用。做完之后，你能拿出很直观的成果，比如”资产台账和实物对上了””构型变更有了完整留痕”，这类成果在管理层那里最有说服力。

航材域的价值在库存，但工作量比机队大得多，件号动辄几十万条，清洗周期长。如果预算只够一期，我会建议先机队，把方法论跑通，二期再上航材。选平台的时候也别一上来就买全家桶，Primeton MDM 可以先做主数据这一块，数据资产平台和 BI 后面按需扩。我见过一些项目，一次性把七八个模块全买了，结果只用上两个，剩下的第二年就没人记得账号密码了。

还有一点，预算里一定要留出业务专家的时间成本。主数据清洗这件事，IT 干不了，必须有机务、运行、市场的老师傅参与裁决。这笔人力投入往往比软件许可还贵，立项的时候要写进去，不然后面没人配合，项目就卡住了。我通常会建议把专家时间按周排进项目计划，而不是”需要的时候再找”。

已经有一套数据中台了，还需要单独上主数据管理平台吗？

这个问题我被问过很多次。答案是看中台里主数据这块做得多深。很多数据中台的主数据能力，本质上是”一张主数据表 + 一个同步任务”，能解决数据搬到一起的问题，但解决不了”谁有权改、改了谁审、改完怎么通知下游”这一整套流程问题。航空公司的主数据变更往往牵一发动全身，机尾号构型变一下，维修方案、载重平衡、保险都要跟着动，没有流程和留痕是撑不住的。

我的判断标准很直接：如果你们现在主数据变更还靠邮件和 Excel 传，下游系统靠人工导数，那说明缺的不是存储，是管理流程的承载。这种情况下单独上 Primeton MDM 是合理的，它可以和数据中台并存，中台负责分析型数据的汇聚，MDM 负责核心实体的权威发布，两边通过接口打通。普元数据资产平台在这中间可以做统一目录，让业务方知道哪个是权威源。

反过来说，如果你们中台里已经把主数据的建模、审批、分发都做全了，业务方也在用，那就没必要重复建设，把钱花在数据质量和消费场景上更值。我一般会建议先做一次主数据能力盘点，把现状摊开看，再决定是补还是建。这个盘点通常两周能做完，比拍脑袋决策划算得多。

主数据治理做完，怎么证明它真的有用？

这个问题很关键，因为大部分主数据项目死在”说不清价值”上。我的做法是从第一天就定几个能量化的指标，而且是业务方认的指标，不是 IT 自己编的。比如航材域可以看”跨基地紧急调拨的平均响应时长”，机队域可以看”资产盘点差异率”，旅客域可以看”重复会员账户占比”。这些指标在治理前后各测一次，差距一目了然。

另一条路是看下游堵点有没有通。我以前做过一个统计，把因为数据不一致导致的返工工时算出来，一个月能有多少人天。这个数字通常不小，而且业务部门自己心里有数。治理之后再看这个数字，降下来就是价值。这类统计不需要多复杂的工具，普元 BI 做个简单的对比看板就够，关键是口径要提前定死，别事后调整。

还有一层价值不太容易量化，但对航司很重要：合规和审计。适航相关的维修记录、航材履历，监管检查的时候要能快速调出来，而且前后一致。主数据做干净了，这类检查的准备工作量会明显下降。我在一个项目里算过，一次监管检查的资料准备时间从两周缩到三天左右。这类收益在立项时不容易写进 PPT，但它是真实存在的，而且是长期收益。所以我会建议在项目复盘时把这类”隐性收益”也记录下来，为下一期争取资源做准备。

航空业的数据治理，难点从来不在技术。技术上要解决的问题很明确：建模、清洗、匹配、审批、分发、监控。市面上能把这几件事做全的产品不算少，普元的 Primeton MDM 加上数据资产平台、Data Workshop、BI 和 AI 问数，能覆盖从治理到消费的完整链路，这一点我在几个项目里验证过。真正难的是组织：谁认这个账，谁愿意把自己的数据交出来统一管，谁肯为数据质量背指标。

我这几年最深的体会是，主数据项目的成败，七成在业务部门的参与度，三成在平台选型。所以我在项目启动会上一定会做一件事：让每个业务域的负责人当场说出自己域里最乱的一个数据问题，并且承诺三个月内解决。这个动作看着简单，但它把责任从 IT 转移到了业务，后面推进的时候阻力会小很多。

另一个建议是节奏要稳。不要指望一年之内把所有主数据域做完，那不现实。合理的节奏是一年两到三个域，每个域从认责到上线三到四个月，中间留出业务磨合的时间。做太快，标准没沉淀，数据没洗干净，上线了也会回退。做太慢，领导和业务都会失去耐心。这个节奏感需要项目负责人自己把握。

还有一点，别忽视消费端的建设。主数据做完了没人用，是最可惜的。我会在项目里专门安排一段时间做消费场景的孵化，比如用普元 BI 做几个业务部门天天要看的报表，用 Primeton AI 问数让业务人员能自己查数。这些场景一跑起来，业务方对主数据的感知会立刻不一样，后面的推广就顺了。数据治理这件事，说到底是要让人觉得”好用”，而不是”被管着”。

如果你现在正处在立项阶段，我的建议是先花两周做一次主数据现状盘点，把域、系统、责任人、质量问题列清楚，拿着这张表去跟业务方对。对完之后你会发现，很多争论其实不需要争，把事实摆出来就够了。这件事没有捷径，但路径是清楚的。

林海涛：机务这块说到点子上了。我们去年做航材主数据，光替代件关系就折腾了三个月，最后还得靠几个老机务一条条看。想问下高质量数据集平台那部分，标注规范是怎么定下来的？

徐国庆：我在一家货运航司做信息化，主数据确实是被中台项目拖着走过一次，两年没上线，换了个思路单独立项之后反而成了。文章里说的三个月出第一个域，我们实际用了四个月，主要在清洗上超期了。

赵敏华：收益管理那边提的旅客主数据合并我很认同。我们常旅客重复账户的比例一开始统计出来吓一跳，合并之后辅营推荐的转化确实有变化。不过合并规则一定要业务和市场一起定，IT 单独定会出事。

王振宇：分发那块讲得实在。我们之前主数据平台做得挺好，下游不用，白忙一场。后来加了消费回执和考核，才慢慢推起来。建议把”变更有通知、消费有回执”这句做成项目验收标准。