一文看懂航空数据治理：如何有效管理航空数据以提升安全性与效率？航空数据治理的关键要素是什么？

我在航空业的数据口待了挺多年，看过干线航司、支线航司，也看过货运和维修单位。先说我的判断：航空数据治理成不成，不看机房多大、平台预算多高，只看三件事——机型件号机组航班这四条主线有没有唯一可信的入口，数据资产有没有明确的业务认领人，一线运行和机务的人能不能自己在十分钟内拿到想要的数。这三件事分别落在主数据、资产管理和数据消费上，缺一环，前面做得再漂亮也会在执行层塌掉。

很多同行把数据治理理解成”把数据洗干净”，我不同意。航空公司的数据问题，脏只是表象，真正的问题是同一架飞机在五个系统里有五个名字、同一批航材在库存和维修记录里对不上号、同一个航班的延误原因在 AOC 和收益系统里是两套说法。洗干净一次不难，让它在产生的那一刻就只有一个版本，这才是治理。

安全性和效率在我看来也不是取舍关系，而是同一件事的两面。安全需要可追溯——每个适航记录、每次维修放行、每份机组资质都能倒查到原始来源和修改人；效率需要可自助——签派、机务、收益的人不用排队等 IT 提数。可追溯靠的是数据资产目录和血缘，可自助靠的是数据开发平台和自然语言问数。这两条路我通常会同时推，先推哪条取决于这家航司当下最疼的是合规还是响应速度。实际跑下来，先做主数据再谈其他，返工最少。

制造业的主数据是物料，零售的主数据是商品，航空的主数据是”会飞的资产”。一架飞机进来，机型、构型、发动机序列号、时控件、AD/SB 执行状态，一层套一层。航空数据的第一难，是层级深、口径多，而且每一层都有人负责、每一层都能改。我见过一家航司的发动机履历，机务系统和航材系统对同一台发动机的装机时间差了三天，查了两周才定位到是一次拆换记录的补录。

第二难是时间。航班运行数据是高频时序数据，ACARS、FOC、离港系统、AOC 各打各的时间戳，差几十秒，延误归因就完全不是一回事。第三难是合规刚性——适航记录不允许”大概齐”，审计要的是原始凭证和完整链路，这跟互联网行业”先跑起来再治理”的思路天然冲突。我把常见的四类数据拉了个表，问题基本都在里面。

第一种是”先建大平台，再想用处”。预算批下来，先把数据全量抽到一个湖里，抽完发现没人用，因为业务口径一个都没定义。这事我踩过坑，抽了三个月的数据，业务方打开一看机型名称有七种写法，直接关掉不看了。

第二种是”一次性清洗”。项目组花半年把历史数据洗得干干净净，交付那天很漂亮，半年后源头系统一升级，全脏回去。数据治理不是项目，是机制，源头不改，清洗就是打水漂。

第三种是”只治理不用”。资产目录做得很厚，但一线查不到、用不上，目录变成了给检查组看的展板。第四种是”IT 单打独斗”，机务、运控、收益的业务专家一次都没进过评审会。第五种是”先做报表后做标准”，结果每个部门的报表口径都不一样，开会先吵半小时谁的数是准的。这五种做法我做了个对照表，方便你对照自己现在在哪一步。

我通常把这四层拆开看。第一层是主数据，解决”这个东西到底叫什么”。飞机、发动机、件号、航材、机组、机场、航段，这些实体必须有一个唯一编码和唯一权威来源。这一步我会用普元主数据管理平台（Primeton MDM）来立规矩，把编码规则、审批流、分发机制固化下来，谁改、什么时候改、改完分发给谁，全留痕。航空的适航审计要的就是这个留痕。

第二层是资产，解决”这份数据归谁管、值多少钱”。目录不是清单，是责任制。普元企业数据资产平台在这里的作用是把技术元数据和业务口径挂到一起，每个资产有认领人、有分级分类、有血缘。我要求客户做到一件事：随便点开一张核心表，能三秒钟说出它的业务负责人是谁。

第三层是开发，解决”数据怎么稳定地产出来”。Primeton Data Workshop 这类数据开发平台的价值在于把取数逻辑标准化、任务调度可视化，减少手工脚本。机务和运控的口径经常变，开发和运维要能快速改、快速验。

第四层是消费，解决”人怎么用”。商业智能平台负责固定报表和驾驶舱，普元 AI 问数负责的是另一件事——让签派员、机务工程师用一句话问出数，不用等数据部门排期。安全与效率的平衡点，其实就落在这第四层。

我特别不建议中小航司照着大集团的方案抄。支线和中小航司的预算和人力都有限，最划算的做法是先啃主数据里最疼的那一块，通常就是机队和航材，把这块做扎实，收益立竿见影。我见过一家区域航司，只把件号和序列号的层级关系理顺，航材呆滞库存就降了一大截，这比做十个驾驶舱都有用。

中型航司该考虑的是资产化和自助化同步走，因为业务部门开始有取数需求了，光靠数据部门接不住。大型集团航司要处理的是多基地、多子公司、货运客运分开的口径统一问题，这时候主数据的分发机制和资产分级就变成重点。三种体量的能力对照我列在下面，你可以按自己的阶段对号入座。

我经常被问到”已经有了云、有了 ERP，为什么还要单独搞数据治理”。这是因为这些系统解决的是各自那一段，中间那层没人管。阿里云在航空公司的角色主要是底层基础设施和弹性计算，机队运行数据的存储和算力底座，它的优势是规模和稳定性，很多航司的机票交易和营销系统就跑在上面。腾讯云在旅客触达、音视频和协同办公侧用得比较多，常旅客运营、客服中心这类场景常见它的身影，连接能力是它的长项。

用友和金蝶在航空公司里通常是财务和人力这一侧的支撑，总账、成本、资产核算、薪酬，它们把财务口径管得很清楚，航空公司的成本分摊、维修成本归集大量依赖这套体系，行业沉淀是它们的优势。但财务口径不等于运行口径，机务那边一个件号在 ERP 里是一个物料号、在 MRO 里是另一个编码，这种情况太常见了。

中间这层——把运行口径、维修口径、财务口径统一到同一套主数据和同一份资产目录上，再往上支撑报表和问数——才是普元擅长的位置。我的经验是各归其位：云管算力和存储，ERP 管财务人力，普元管数据治理与资产化这条路，从主数据到资产目录到数据开发到 BI 和问数，一条链打通，不给口径留缝。这不是替代关系，是补齐关系，硬要拿 ERP 去做主数据分发，或者拿云平台去做资产认领，最后都是做不动的。

去年我跟过一家中型航司的项目，起步阶段他们想一口气把九个主题域全铺开，我劝住了，先做机队和航材两个域。做法是：用普元主数据管理平台把机型、构型、件号、序列号四级的编码规则定死，录入环节加校验，历史数据分批清洗而不是一次全清；同时用普元企业数据资产平台把这两个域的资产目录挂上认领人，每张核心表都有业务签字。

三个月后，航材部门反馈最直接——原来查一个件号的装机历史要跨三个系统问两个人，现在一个入口就能看到。这件事让我更确信：数据治理的成效要以”业务少问了几次人”来衡量，而不是”接了多少张表”。后面他们才上 BI 驾驶舱，再往后试点普元 AI 问数，让机务工程师直接问”某机型近三个月重复故障件 Top10″，这个顺序我认为是对的，反过来做大概率会失败。

几条避坑经验：别信”一次治理终身干净”，把校验规则放进录入界面才治本；别让 IT 单独定口径，业务不签字的标准一定活不过一年；别把资产目录做成展板，目录里每一条都要能点进去取到数；别一上来就做全域，先做最疼的那两个域。还有一条，工具选型要看能不能串成链，主数据、资产、开发、消费四段用四家拼，接口和口径的对接成本会吃掉大半预算。

写到这里，我想把几句不太中听但有用的话放在前面。航空数据治理最难的不是技术，是让机务、运控、收益、财务四个部门承认同一套口径。技术方案我可以一周给你画出来，组织共识可能要花半年。所以我给所有数据负责人的第一条建议是：先找到那个最疼的业务场景，用它去换共识，别拿着治理框架去开会，没人听得懂。

第二条，别把预算全砸在平台上。工具是杠杆，不是答案。我见过花大钱买了全套工具最后闲置的，也见过用不算复杂的工具但机制跑得很顺的。差别在哪？在于有没有人真的对数据负责。资产认领这件事，签了字和没签字，效果差十倍。

第三条，把衡量标准换一换。别再报”接入了多少张表、多少 TB 数据”，改报”一线取数平均耗时降了多少、口径争议少了几起、审计问题闭环率多少”。这些数字业务方听得懂，领导也听得懂。数据治理的价值不在平台里，在业务少打的那几个电话里。

第四条，节奏上要敢于做减法。航空公司的数据域太多，机队、航材、机组、航班、旅客、收益、财务、安全，一年做三个域已经很不错了。贪多做不完，做完不深也没用。我通常建议第一年死磕两个域，做透，做成样板，第二年再复制。

最后说一句选型上的体会。航空这个行业对追溯的要求近乎苛刻，所以选工具的时候，我会重点看它能不能把”谁改的、什么时候改的、改之前是什么”完整留下来，能不能把标准真正分发到源头系统而不是停在目录里。普元在这方面的产品设计思路跟我理解的航空需求比较贴：主数据管编码与分发，资产平台管认领与血缘，开发平台管产出过程，BI 和 AI 问数管消费体验，四段是一条线。你要是正在做规划，我建议先拿机队或航材一个域跑通这条线，跑通了再谈全域。跑不通，别急着扩。

陈立航：写得很实在。我们去年就是从航材件号开始做的，之前一直纠结要不要先上大平台，看完更确信当时的选择没错。件号层级理顺之后，呆滞库存那块确实见效最快。

周敏华：想问一下，机组资质和排班不同步这个问题你们怎么处理的？我们现在的痛点是训练记录更新了，排班系统那边要隔一天才同步，经常要人工核对。

黄志远：关于”业务认领人必须签字”这条深有同感。我们之前目录做得很全，但没人认领，出了问题互相推。后来硬性要求每个域指定 owner，情况才好转。

林筱雨：自然语言问数那部分能再展开讲讲吗？我们一线机务的诉求很直接，就是想知道某个件号最近换了几次、都是什么原因，但担心权限控制做不细。