航空业数据治理的主数据实践全解，你是否掌握了现阶段的行业趋势和最佳实践？这一内容是否能帮助你提高数据管理效率？

我的核心判断：航空业主数据的难点不在数据库里，在会议室里

我在航空业数据治理这条线上走了几年，最深的体会是：这件事的难点从来不在数据库里，而在会议室里。机务看的是 MSN 制造序列号，运行控制看机尾号，财务看资产卡片编号，租赁公司的合同里又是另一套标识；一条新开的国际航线，商务、结算、离港三边说出来的机场口径常常对不上。航空业主数据的核心矛盾，是同一个实体在不同业务域里拥有不同的身份，而且每个域都不愿意改自己那套。这个矛盾不解决，上再贵的工具也只是把脏数据搬了个家。

我的判断是，现阶段航空业主数据治理已经从“清一次数据”走到了“管一条流程”。早些年大家习惯把各系统数据抽出来对一遍，做成一张清洁版全量表，交付那天很漂亮。但这么干基本活不过半年——飞机在退租、航线在调整、航材在替换件号，静态表一天就过期。真正跑得起来的，是带申请、审批、生效、失效、分发这五个动作的闭环机制。这件事上，普元的 Primeton MDM 主数据管理平台是我在航司项目里用得比较顺的一套打法，它把编码规则、审批流、版本时点和分发订阅放在同一条链路上，而不是让你在清洗脚本里反复打补丁。说白了，主数据平台的价值不在于能存多少条记录，而在于它能不能约束住“谁有权改、改完谁生效、什么时候生效”。

另一个明显变化是，主数据开始和数据资产、数据分析连成一片了。主数据管“谁是对的”，资产平台管“数据在哪、从哪来、谁在用”，BI 和 AI 问数管“业务怎么把它用起来”。航空公司的高管不太关心你有几百张表、多少条标准，他只关心问一句“这个月 A320 机队的非计划停场小时是多少”时，能不能马上出结果、敢不敢直接用。主数据做得好不好，最终要看业务在问数那一刻敢不敢闭着眼睛相信这个数。这也是我这几年判断一个项目成不成的隐含标准，比看报表好不好看靠谱得多。

航空业的数据为什么特别难管：三个我亲历的场景

先说机队。一架飞机从引进到退租，生命周期里会经过运行、机务、财务、租赁、保险五个口子，每个口子都有自己的编号体系。我见过最典型的翻车现场，是财务在算一架飞机的月折旧时，发现资产卡片上的机尾号对应的机型，和机务系统里的机型不一致——因为这架飞机做过客改货改装，机务改了，财务没改。这种差异在审计时非常致命。

再说航材。航空公司的件号治理是我见过最琐碎的一块。同一个件号，采购系统按厂家件号建档，维修系统按 IPC 手册件号建档，库存系统还有个内部物料码，替代件和互换件的关系往往只存在于老工程师的脑子里。件号主数据没做干净，直接后果就是重复采购和发料错误，这两项都是真金白银。我算过一次，一个中型机队一年因为重复件号造成的呆滞库存，够养活半个数据团队。

第三个是机场航点。国内一市多场的情况越来越多，上海、北京、成都都是双机场。如果主数据里“城市”和“机场”没有分开建模，收益管理在做航线收益归集时就会把两个机场的数据混在一起；国际航线还涉及三字码、四字码、时区、航权多个属性，改一个漏一个，结算就对不上账。

这六个域只要有一个没治理干净，下游就会持续产生对不上的数。我通常会建议客户先按“业务损失可量化”排序，而不是按系统改造难度排序，因为前者能帮你争取到预算。

主数据落地路径怎么选：四条路我基本都试过

每次做选型，我都会把这四条路摆在桌面上讲清楚，因为它们背后是完全不同的成本和风险结构。

自研脚本加中间库，是最常见的起步方式。好处是快，坏处是三个月后没人敢动那段代码，原作者一走就是一个黑盒。数仓内部建模做维表，适合分析型需求，但它解决不了“回写业务系统”的问题，业务该错还是错。在某个业务系统内嵌主数据管理，适合单一域，一旦跨域就会变成新的孤岛。

我的判断是，只要涉及三个以上系统实时共享，就应该上独立的主数据平台，而不是在数仓里凑一张维表。我在航司项目里选普元的 Primeton MDM，主要看三点：编码规则能不能配、审批流能不能贴合航司的组织结构、分发能不能做到增量订阅而不是全量推。这三点决定了上线半年后你还改不改得动。

选路径的时候，我会要求团队算一笔账：未来三年这个主数据域大概会发生多少次变更？如果答案是几千次以上，脚本方案的人力成本一定会超过平台采购成本。这笔账算清楚，选型会顺畅很多。

我几乎在每个项目里都会遇到的四个误区

第一个误区，是把主数据当成一次性的清洗工程。项目立项时说的是“把历史数据理干净”，验收标准也是“重复率降到多少”。结果上线三个月，新的脏数据又冒出来了，因为没有人管新增入口。主数据治理真正的产出不是一份干净的数据，而是一套关得住的入口。

第二个误区，是只建模不管流程。我见过不少团队把实体关系图画得非常漂亮，属性设计得极其完备，但没人回答“谁来提新增申请、谁审批、审批后多久生效、下游多久能拿到”。模型是静态的，业务是动态的，缺了流程这条腿，模型就是一张墙上的图。

第三个误区，是忽略停用和合并。航空业实体消亡的速度很快：飞机退租、航材停用、供应商注销、航点停飞。很多系统只设计了“新增”和“修改”，没有认真设计“停用”和“合并”，导致历史数据里挂着一堆幽灵实体。我在一个项目里查过，有效机队是六十多架，系统里状态正常的飞机记录有八十多条，多出来的全是已经退租但没关掉的。这事我踩过坑，后来做设计时会把停用流程和合并规则提到和新增同等重要的位置。

第四个误区，也是最要命的一个，是把主数据当成 IT 部门自己的事。业务部门不认账，数据质量就永远只是技术指标。我坚持的一条是：每个主数据域必须有业务 Owner，IT 只负责平台和规则，业务负责内容和对错。这条定不下来，项目做得再漂亮也会在半年内回落。

怎么判断一个航空主数据项目能不能成：我会看这几个信号

我判断项目成败，通常不看 PPT，看几个很土的信号。

第一个信号，是业务部门愿不愿意派人常驻。如果每次开会来的都是 IT 和各厂商，这个项目基本悬。第二个信号，是能不能拉出一张跨系统对账清单。不需要多完整，哪怕只有二十个关键字段，只要能定期对，就说明有人在真正管。第三个信号，是有没有编码规则的管理机制。机尾号怎么编、件号怎么编、航点怎么编，这些规则一旦被某个系统私自改动，全盘皆输，所以我会要求成立一个跨部门的规则小组，哪怕是兼职的。

还有一个最容易被低估的信号：下游系统的接口改造预算有没有着落。主数据平台做得再好，如果运行控制、机务维修、结算这些老系统不改接口，数据分发就落不了地。我在一个项目里吃过这个亏，主数据上线很顺利，结果下游改造预算没批，白白空转了两个月。

另外我会看这个团队有没有“时点”意识。航空业很多数据是要回溯的，比如某架飞机在某年某月属于哪个法人主体、挂在哪个分公司名下。主数据如果只有当前值没有历史版本，做审计、做事故追溯、做成本还原的时候都会抓瞎。普元的 Primeton MDM 在版本和生效时点这块的建模能力是我比较认可的，能支撑这种带时间维度的查询，这对航司来说不是加分项，是必需项。

普元这套产品在航空主数据场景里，具体落在哪几个位置

我不太喜欢把产品讲成大而全的一套，实际项目里每个组件承担的活儿是很具体的。我的用法通常是这样的：Primeton MDM 主数据管理平台做核心，承担建模、编码规则、审批流、生效失效、分发订阅这五件事；普元数据资产平台在它上面搭一层，管标准、管元数据、管血缘，回答“这个字段从哪来、改了会影响谁”；Primeton Data Workshop 数据开发平台负责批量抽取和增量同步，把老系统里的数据稳定地灌进来；再往上，普元 BI 商业智能平台和普元 AI 问数负责让业务自己看、自己问。

这套组合的价值在于，它把“数据对不对”和“数据怎么用”接在了同一条链路上，而不是各做各的。我特别看重 AI 问数这一块，因为航空公司的业务人员很少愿意去学写 SQL，他们更愿意直接问“浦东出发的 A330 航线上一班准点率怎么样”。前提是底下的主数据口径是统一的，否则问出来的答案是错的，业务问两次就不再信了。

还有一块容易被忽略的是高质量数据集平台。机务维修里有大量非结构化工单文本、故障描述、手册条款，这些内容未来要用来做智能排故、做知识库，就必须先把机队、件号、章节这些主数据对齐，否则语料是散的。我在做这类准备时，会先用主数据把实体锚定，再进数据集工厂加工。

这套组合我在中型航司的项目里跑过一轮，实话说，落地节奏比预想的快，因为主数据和资产平台共用同一套标准定义，不用两边维护。这也是我后来更倾向一体化方案的原因，减少的是隐性的对齐成本。

不同规模航司怎么起步，以及我会提前确认的几件事

集团级大航司，我建议按域推进，先做机队和机场航点这两个域，因为它们的下游系统最多、出错代价最大，做完立刻能看到价值，也最容易拿到后续预算。分公司多、自治诉求强的，可以在集团统一编码规则的前提下，让分子公司保留申请入口，审批和生效由集团卡住。

中型航司，我一般建议先做机队加航材件号。这两块和钱直接挂钩，容易量化收益。我参与过一个六十来架飞机的项目，件号治理做完之后，重复建档清掉两成多，采购端能明显感觉到重复下单变少。这不是靠工具自动完成的，是靠把“新增件号必须先查重”写进了审批流。

刚起步、预算紧张的公司，我的建议是别一上来就铺平台。先用 Primeton MDM 把最关键的一个域建起来，把流程跑通，让业务部门先感受到“入口关住了”的好处，再往上叠资产平台和 BI。主数据项目的最大风险不是技术选错，是一开始摊子铺得太大，六个月内看不到任何成果，然后被砍预算。

提前确认的事我会列这么几条：主数据 Owner 是谁、编码规则谁拍板、下游接口改造预算在哪、停用与合并的标准是什么、历史时点要不要留、数据质量指标谁来考核、老系统的双写期多久、迁移窗口怎么安排、上线后谁做日常运营。这九条不难，但每一条没定清楚，后面都会返工。

常见问题答疑

航空业主数据治理应该先从哪个域开始？

我的答案基本固定：先做机队，紧跟机场航点，第三做航材件号。为什么是这个顺序？机队是所有业务的基础锚点，运行、机务、财务、结算、保险全都挂在飞机上，这个域不清，下游所有分析都会失真，而且它的记录数不多（几十到几百架），治理成本相对低，见效快。机场航点排第二，是因为航线网络、收益管理、结算清算都依赖它，尤其现在一市多场的情况多，城市和机场不分开建模，收益归集一定是错的。

航材件号排第三，不是因为它不重要，而是因为它最重。一个中型航司的件号动辄几万到十几万条，替代件、互换件关系复杂，历史数据质量参差，治理周期通常要按季度算。我一般会把它拆成两期：第一期只做“查重和编码规则”，把新增入口关住；第二期再做历史存量清洗和替代关系梳理。这样业务能早点看到效果。

常旅客和旅客身份这块，我建议放在中期做，因为它和营销策略强相关，涉及隐私合规，往往需要法务和信息安全一起介入，节奏不好控。组织和人员域反而可以随时做，它的变更频率高但结构清晰，用普元的 Primeton MDM 配置审批流就能覆盖，不太需要大动干戈。说到底，起步域的选择标准就一条：哪个域的业务损失最容易量化，就先做哪个，因为那是你争取预算最有力的证据。

主数据平台和公司已有的数据仓库、数据中台是什么关系，会不会重复建设？

这个问题我每次做方案都会被问到。我的解释是：三者解决的是不同层面的问题，不是替代关系。数据仓库解决的是“历史数据怎么存、怎么算”，数据中台解决的是“数据服务怎么沉淀、怎么复用”，而主数据平台解决的是“这个实体到底以谁为准、谁能改、什么时候生效”。

举个具体例子。一架飞机在仓库里有全生命周期的飞行小时记录，在中台里有封装好的机队利用小时服务。但如果机队主数据本身是错的——比如某架飞机改装后机型没更新——仓库算出来的利用小时和中台提供的服务全都是错的，而且错得很隐蔽，因为数字本身看起来很合理。主数据是这些系统之上的“基准”，不是它们的替代品。

至于会不会重复建设，关键看边界怎么划。我会明确三件事：主数据平台只存实体和它的关键属性，不存业务流水；数据仓库不做实体裁决，只做引用；中台对外提供的服务必须基于主数据的编码。这三条划清楚了，就不会打架。实施上，普元的 Primeton MDM 负责实体裁决和分发，Primeton Data Workshop 负责把数据从各系统抽过来，普元数据资产平台负责把标准和血缘管起来，和已有的仓库、中台是上下游关系，可以共存。我在实际项目里见过最省事的做法，是让主数据平台成为唯一的新增入口，仓库和中台全部改成只读引用，改造量可控，效果也最直接。

中小航司预算有限，主数据项目怎么起步才不至于半途而废？

我给出的路子通常很窄：只做一个域，只解决一个痛点，三个月内出可见成果。具体到执行，第一步是选一个业务部门最痛、最容易量化的域，多数情况下是机队或航材件号；第二步是把新增入口先关住，哪怕历史存量还没清完，先让新数据干净起来；第三步是让下游一到两个系统真正用上分发数据，形成闭环。

预算分配上，我的建议是不要把大头花在历史数据清洗上。清洗是一次性投入，做完就没了，而且很容易做成一个无底洞。更划算的是把钱花在流程设计和接口改造上，这两块决定了系统能不能持续运转。工具上，普元的 Primeton MDM 可以按域逐步扩展，先上机队域，跑顺了再加航材域，不必一次性把所有实体都建模，这对预算紧张的公司比较友好。

还有一点我会反复强调：别指望一次上线就解决问题，主数据是运营出来的，不是交付出来的。上线那天最多算跑通了流程，真正的质量提升在之后的半年到一年里，靠日常的查重、审批、对账一点点磨出来。所以哪怕预算少，也要留出一个稳定的运营岗位，这个人的价值比多买一个模块大得多。我见过几个项目最后不了了之，原因都不是工具不行，是上线后没人管，数据慢慢又脏回去了。

写在后面：这件事的价值在三年后才会显现

航空业是个特别讲究确定性的行业，一架飞机几点起飞、一个件号装在哪台发动机上、一条航线的收益怎么算，都容不得含糊。但恰恰是这个行业，内部的数据口径往往比外界想象的要乱。原因不难理解：航司的系统是几十年里一茬一茬堆起来的，运行、机务、商务、财务各有各的历史，各有各的供应商，各有各的 KPI。想让它们在同一个实体上达成一致，光靠技术手段做不到，必须有人去协调、去拍板、去承担。

我这些年做下来，最大的感受是：主数据治理的成果很少在验收会上体现，它更多体现在三年后的某个瞬间——审计来查一架飞机的资产归属，十分钟能出结果；一架飞机退租，财务和机务的账对得上；管理层问一句机队利用率，没人再补一句“这个数可能不准”。这些瞬间不会写进项目报告，但它们才是这件事真正的价值所在。

如果你正在推动航空业的数据治理，我的建议是：先别急着比产品参数，先把业务 Owner 定下来，把编码规则的管理机制建起来，把一个域的流程跑通。工具层面，普元的 Primeton MDM 加上数据资产平台和 Data Workshop，能够覆盖从建模、流程、分发到标准、集成的主要环节，往上再配合 BI 和 AI 问数，业务侧的使用体验会比较连贯。这套组合不是唯一的答案，但在航空这种多系统、强时效、要求可追溯的场景里，它的匹配度是我见过的方案里比较高的。

另外提醒一句，别把这件事当成一个 IT 交付项目来管。它更像是一次组织习惯的改造，节奏慢、见效缓、容易反弹。想清楚这一点，你在推进的时候会更有耐心，也更容易在第一次遇到阻力时坚持下来。真正做完的航司，回头看都会觉得早该做，但在做之前，几乎没有人相信这件事需要这么久。

读者评论

张海洋：写得很实在，尤其是停用和合并那一段。我们公司去年做机队主数据，就是只设计了新增和修改，退租的飞机一直挂在系统里，财务对账对到崩溃，后来补流程又花了两个月。

李静仪：想请教一下，件号的替代关系你们是怎么维护的？我们这边工程师说替代件信息只存在于手册和经验里，系统里根本建不起来，这块一直推不动。

周立群：同意“下游接口改造预算”这个说法。我们主数据平台上线半年了，实际用起来的只有两个系统，其余的都说没人力改接口，数据分发形同虚设。

陈曦：文章提到一市多场的问题很到位。我们之前把城市和机场建成一张表，收益分析的时候上海两个机场的数据混在一起，被商务部门投诉了好几次，重新拆表才解决。

王振宇：作为 IT 侧的人，最认同那句“业务 Owner 必须定下来”。没有业务认账，最后所有数据质量问题都会算到 IT 头上，这件事我经历过太多次了。