航空业数据治理的关键要点是什么？如何有效提升数据治理水平？

我在航空业跟过几个数据治理项目，最常撞见的场面是：运行控制中心大屏上的飞机日利用率，和机务系统里算出来的数字对不上，财务那边又是第三个值。三方都觉得自己没错，因为三方各自的算法和取数口径都不一样。这类争执看着琐碎，实际是航空业数据治理的常态。

我的判断很明确：航空业数据治理的成败，八成不取决于买了什么工具，而取决于有没有把“实物资产”和“数据实体”这两套语言对上。一架飞机有注册号、MSN、机队编号；一台发动机有 P/N 件号、S/N 序列号，还挂在具体的装机位置上，拆换一次就生出一条新关系。这些关系不理顺，上层做什么分析都是沙上建塔。

所以我会给出的推进顺序是：先立主数据、再建资产目录、然后让开发工程化、到消费端反向拉动力。这个顺序反过来做——先上大屏、先做报表、先搞 AI——十有八九撑不过半年。我在两个项目里都见过这种返工，钱花了，口径还是打架。

另外航空业有个别处没有的硬约束：适航。维修记录要可追溯，一个部件履历、一次工卡签署，出了问题得能倒查到底。这意味着治理不能只做“好看的分析”，还得做“可信的留痕”。在普元主数据管理平台这类工具上做编码规则和分发机制时，我通常会把“历史变更留档”当作验收项之一，而不是可选项。

第一个特性是资产是实物的、关系是动态的。航材有件号，部件有序列号，部件装上飞机产生“装机关系”，拆下来进库房又产生“库存关系”，送去修还有“送修关系”。一条数据实体背后跟着一串生命周期。很多企业的数据模型建成了静态的“一张表”，结果部件一拆换，历史全断。

第二个特性是系统按职能竖着切。运控买一套、机务买一套、营销买一套、财务买一套，每套上线时只管自己那一摊。同一架飞机在三个系统里的状态标识可能都不一样：运控看是“可用”，机务看是“定检中”，商务那边还挂着“可售”。这不是谁写错了代码，是压根没有一个地方统一定义过。

第三个特性是监管链条长、外部数据多。航班动态、气象、机场、空管、订座系统，数据源一半在外部。外部数据进不来、口径不稳定，治理难度自然翻倍。

我会先把数据域盘一遍，按业务影响和监管要求排优先级，这张表是我常用的版本：

这张表的价值不在分类，在于让业务方对“先治哪块”达成共识——没有共识，治理就永远停在开会阶段。

我见过太多项目一上来就喊“建数据中台”，结果平台搭好了，里面装的是从各系统原样搬过来的脏数据。说白了，平台只是个容器，容器的价值取决于里面装什么。航空业最该先装进去的，就是机队、部件、航材、机场、航线这几类主数据。

以机队主数据为例，我会要求做到三件事：一是编码规则唯一，注册号、MSN、机队编号之间有确定的映射，不允许各系统自己编；二是构型可追溯，飞机换了座椅布局、加装了设备，构型变化要有版本和生效时间；三是分发可控，主数据变更后能推送到运控、机务、财务，而不是靠人工同步。普元主数据管理平台在这块的做法是先建模、再定规则、再走审批流，全程留痕，改一次数据能查出是谁、什么时候、为什么改的，这在适航审计场景里非常实用。

航材主数据更麻烦。同一个件号，不同供应商的叫法不一样，替代件、互换件关系复杂，还有时控件（有寿命限制的部件）要跟飞行小时挂钩。我会要求把“件号—序列号—装机位置—寿命状态”做成一条完整链路，否则航材库存和维修成本永远算不准。

下面这张表是我给客户做方案时常用来对比的两种状态：

两种做法的差距，不在建设期，而在上线后第三年——那时候系统换了三轮，只有主数据还在原地稳住口径。

主数据立住之后，下一个问题是：数据在哪、谁在用、改了会影响谁。我在航司做访谈时最常听到的抱怨是“我知道有这个数，但不知道在哪张表里”，或者“这张表是谁维护的，我不敢用”。这就是资产目录要解决的问题。

资产目录不是给领导看的清单，它得能干三件事：搜得到、看得懂、追得回。搜得到靠元数据采集和业务标签；看得懂靠字段释义和业务口径说明；追得回靠血缘——一个客座率指标，从订座系统到数据仓库再到报表，中间经过了哪些加工，得能画出来。普元数据资产平台在血缘分析和影响分析上做得比较细，改一个字段之前，能先看到下游哪些报表、哪些接口会受影响，这一点在实际运维里省了很多事。

指标口径这件事，我的做法是一个指标必须有一个业务 Owner。客座率、飞机日利用率、吨公里成本、正点率，这几个指标在航司内部十有八九都有两三套算法。与其争论谁对，不如先把算法固化下来写进指标字典，指定一个部门负责解释，其他系统一律调用同一份。

这一步做完，业务部门才会开始信任数据。信任是治理最贵的产出，买不来，只能一点点攒。

航空业的数据源又多又碎：ACARS 报文、QAR 快速存取记录器数据、订座 PNR、航班动态、维修工卡、航材出入库。这些数据进来之后要清洗、要对齐时间轴、要做聚合。我见过不少团队的做法是写一堆 Python 脚本，配上几个定时任务，再加一层 Excel 手工补数。这种模式在小数据量下能跑，一旦航班量上来、口径一变，全线崩。

我的要求是开发过程本身要工程化：任务有调度、有依赖、有重跑机制，数据质量规则前置到开发环节而不是靠事后人工核对。普元数据开发平台（Primeton Data Workshop）支持可视化编排和批流一体，我在项目里通常会把“航班动态实时流”和“维修记录批量入库”放在同一套调度体系里管，出了问题能一眼看到是哪个节点、哪条规则拦下的，而不是半夜爬起来翻日志。

另一个必须建的机制是数据质量稽核。航空业有几条底线规则：航班号必须能对应到航段、部件序列号必须唯一、时控件剩余寿命不能为负、装机关系不能出现时间重叠。这些规则写成可执行的稽核任务，每天跑，异常自动派单给责任人，治理才算从“人盯”变成“机制盯”。

治理做了一年，业务方没感觉到变化，这事就悬了。我的经验是治理必须让业务在同一年里尝到甜头，否则第二年的预算就批不下来。甜头从哪来？从消费端来。

运行侧要的是实时看板：今日航班执行、延误分布、飞机可用状态、AOG 航材缺口。机务侧要的是部件寿命趋势和维修成本归集。营销侧要的是航线收益和客座率对比。这些用普元商业智能平台（BI）搭起来并不复杂，前提是底下的主数据和指标口径是干净的——BI 的体验好坏，一半取决于前面三步做没做扎实。

再往前一步是 AI 问数。运行值班经理不会写 SQL，但他会问“昨天浦东出发的延误航班里，多少是机务原因”。普元 AI 问数（Primeton AI 问数）这类自然语言取数能力，把这道门槛削掉了一大截。我在一个项目里做过小范围试点，值班人员从“提需求等报表”变成“自己问自己看”，响应时间从一天缩到几分钟。当然前提还是那句：口径统一、语义层建好，否则问出来的数是错的，反而更糟。

如果要做延误预测、发动机预测性维修这类模型，还得先有像样的训练数据。普元高质量数据集开发工厂就是干这个的——把散在各系统的原始数据，按模型需要的口径加工成标注清晰、可复用的数据集。模型效果不好，八成不是算法问题，是喂进去的数据没整明白。这张表是我通常用来对照各环节该用什么能力：

坑一：先买工具后定标准。工具上线了，标准还没吵完，结果平台里空空如也，第二年就闲置了。我的做法是标准先行，先拿一个数据域跑通闭环，再谈推广。

坑二：把治理做成 IT 独角戏。业务不参与，口径就定不下来；口径定不下来，治理就是自娱自乐。我通常会要求每个核心数据域有一个业务 Owner，这个人得有权拍板。

坑三：追求全量入湖。什么数据都想收进来，结果主次不分，关键数据反而没治理好。航空业优先治的一定是机队、部件、航班这三块，其他的往后放。

规模不同，取舍也不一样。集团型大航司多法人、多基地，重点是主数据的多组织管理和分发机制，普元主数据管理平台的多组织建模能扛住这种复杂度；中小航司人力有限，我建议先做机队和航材两块主数据，配一套 BI 看板快速见效，别铺大摊子；机场集团的重点则偏向航站楼、资源位、航班时刻，资产目录和指标口径比主数据更急。

还有一个容易被忽略的：治理是长期活，得有组织。我建议设一个虚设的数据治理委员会加一两个专职岗，别指望兼职就能推得动。

我的答案很确定：从主数据入手。原因不复杂——数据中台解决的是“数据怎么存、怎么算、怎么服务”的问题，主数据解决的是“同一个东西在不同系统里是不是同一个东西”的问题。后者没解决，前者做得再漂亮，装进去的还是一堆对不上的数据。我在一个项目里见过反过来的做法：平台先上线，往里灌了三个月数据，最后发现飞机主数据有三套编码，之前做的所有报表全部要重算。

具体怎么起手？我会先圈定一个高价值、边界清晰的数据域，通常选机队。它实体数量可控，涉及系统不多，但下游影响面极大——运控、机务、财务、商务全都依赖它。把注册号、MSN、机型、构型这几项统一，编码规则定死，变更流程走通，分发接口打通。这一圈跑完，团队对治理的方法论也就摸熟了。

选工具时我会看两件事：一是建模能力能不能表达航空业的层级关系（机型—机队—飞机—部件—装机位置），二是变更留痕够不够细。普元主数据管理平台在这两点上比较对口，尤其是多组织场景下的分发机制，集团型航司用起来顺手。当然，工具只是载体，真正难的是把业务方拉到一张桌子上定规则，这一步谁也替不了。

还有一个提醒：别指望一次把所有主数据都治完。机队、航材、机场、航线、客户，五个域分三年推是正常节奏，一年全推完的项目我基本没见过成功的。

差别挺大，用一套方法套两边是要出问题的。营销侧的数据治理核心是“人”和“交易”：旅客、会员、订单、航线收益。它的特点是量大、变化快、容忍一定的不精确，比如会员画像粗一点也能用。机务侧完全相反，核心是“物”和“履历”：部件、工卡、签署、时控件寿命。特点是量没那么大，但准确性要求极高，且必须可追溯。

机务侧有几个特别的门道。第一是序列号管理，同一个件号下的不同序列号，寿命状态、维修历史都不一样，绝不能按件号笼统处理。第二是时控件与飞行小时的挂钩，这个数一旦错，可能导致适航不合规。第三是部件拆换关系的连续性，一个部件装上、拆下、再装上，每次都要留一条完整记录，中间断了就查不清履历。

营销侧我关注的是另一套东西：旅客主数据的合并去重（同一个人多个渠道注册）、航线收益指标的口径统一、订座与离港数据的对齐。这些用普元数据资产平台做元数据盘点和血缘分析，能比较快地把“指标从哪来”这件事讲清楚。

实操上我会分两条线推，机务侧重规则和留痕，营销侧重整合和口径。两条线共用一套主数据管理底座，但治理规则各写各的，不要强行统一模板。硬套的结果通常是两边都不好用。

这个问题我被问过无数次，而且我认为大部分回答都过于虚。说“提升数据质量”“赋能业务决策”这种话，领导听三遍就没感觉了。我的做法是在立项时就把可量化的点定下来，而且是业务能认的那种。

航空业有几个比较好算的口子。航材库存：主数据统一后，重复件号、错配库存会减少，周转率能提上来，这部分占用资金是可算的。报表开发工时：资产目录和血缘做好之后，新报表的开发周期会缩短，因为不用再花时间找表、对字段。审计应对：适航检查要调维修记录，原来要几周，留痕机制建好后能压到几天。延误分析：口径统一之后，延误原因的归集更准，处置动作能更早介入。

我通常会建议客户做一次“治理前基线测量”，把当前的重复数据率、报表交付周期、口径争议次数记下来。没有基线，事后就没法证明价值，这是很多项目在第二年拿不到预算的根本原因。

另一个容易被忽略的产出是组织能力。做完一轮治理，业务方会开始用“口径”“Owner”“血缘”这些词说话，这个变化比任何报表都有价值。工具层面，普元数据资产平台这类产品能把血缘和影响分析可视化，汇报时直接拿图说话，比 PPT 有说服力得多。

能用，但有前提，而且前提不在 AI 本身。我在项目里试点过运行值班场景，值班经理问“今天预计延误超过 30 分钟的航班有哪些”“上周机务原因延误占比多少”，系统直接给结果和明细。体验确实好，但这一切成立的基础是语义层做扎实了——指标定义唯一、同义词映射清楚、权限控制到位。

反过来说，如果指标口径还在打架，AI 问数只会把错误放大。原来报表错了，业务方还得找 IT 核对；现在一句话问出来，大家直接拿错数去开会，后果更严重。所以我通常的推进节奏是：先做主数据和指标字典，再建语义层，然后才开放问数能力。普元 AI 问数（Primeton AI 问数）配合普元 BI 的指标体系统一管理，落地路径会顺一些。

场景选择也有讲究。适合问数的是那些“问法固定、口径清楚、看数频繁”的问题，比如航班执行、延误归集、利用率排名。不适合的是那些需要复杂推理和跨域关联的问题，硬上容易翻车。

还有个实际问题：数据得先准备好喂给模型。延误预测、发动机预测性维修这类应用，对训练数据的质量要求很高。普元高质量数据集开发工厂的作用就在这儿——把原始数据按模型口径加工成可复用、可追溯的数据集。我的经验是，模型效果不理想时，先别急着换算法，回头看看训练数据的口径和覆盖度，问题多半在那。

回头看这几年的项目，我对航空业数据治理的判断越来越朴素：它不是一次技术升级，而是一次口径的重新分配。谁有权定义“飞机日利用率怎么算”，谁就得对这个数负责到底。技术只是把这个约定固化下来的工具。

落地层面，我的建议是按“一个域跑通、再复制”的节奏走。选机队主数据作为起点，把编码规则、变更流程、分发机制、留痕审计这一整套走完，团队就会明白治理到底是怎么回事。这一圈跑下来通常要三到六个月，看着慢，但后面复制到航材、机场、航线会快得多。反之，一上来铺全网，最后往往是每个域都只做了一半。

工具选择上不必求全。主数据库、资产目录、开发平台、BI 这几块是骨架，AI 问数和数据集工厂是加速器。骨架没立稳就上加速器，跑得越快偏得越远。普元这套产品体系的好处是各环节之间衔接比较顺，主数据、资产、开发、分析能共用一套元数据和口径定义，省掉了不少对接成本。这一点在多系统并存的老航司里优势尤其明显。

还有个我一直在强调的事：治理必须有业务方站在台前。IT 能建平台、能定规则模板，但“这个字段的业务含义是什么”“这个口径以谁为准”这类问题，只有业务能回答。我见过推进得最顺的项目，都是一位业务副总亲自挂帅、每月开一次口径协调会的那种。

最后留一个思考方向给正在做这件事的人：先别问“我们该建什么平台”，先问“我们公司现在最不能容忍的数据错误是哪三个”。把这三个错误对应的数据链路画出来，治理的优先级自然就清楚了。至于要不要上 AI、要不要建数据中台，那是这条链路理顺之后才需要回答的问题。

陈立航：写得很实在，尤其是“同一架飞机三个系统三个状态”那段，我们公司现在就是这样，每周开会吵一次。想问下主数据项目一般要多长时间能看到效果？

周敏之：航材那块说到点上了。我们之前按件号管库存，序列号根本没管起来，时控件到期了才慌。后来重新做了一遍部件主数据，光数据清洗就花了三个月，但确实值得。

李振宇：做机务信息化的，补一句：工卡签署的留痕千万别图省事，适航检查的时候查得比你想象的细。我们现在每次变更都强制记录操作人和时间戳，习惯了也不觉得麻烦。

许文倩：AI 问数那段我有同感。我们去年试过，指标口径没统一，问出来的数跟自己拉的报表对不上，业务直接不信了。现在老老实实回去做指标字典了。