航空业数据治理的成功案例参考有哪些？如何有效推动航空业数据治理的实施？

我在航空行业跟过几个数据治理项目，从支线航司到中型全服务航司都接触过，也在货航的机务口待过一阵。说实话，这件事最难的地方从来不是买一套平台，而是让运行控制、机务维修、航材保障、市场营销这几个部门愿意在同一套口径上说话。我的判断是：航空公司做数据治理，先别铺全域，挑一个每天都要出结果、错了会立刻被业务方骂的场景切进去，成功率最高。这个场景在我经手的项目里，多数是机务维修和航材——件号、构型、供应商、工时这些数据天然带强主数据属性，一旦不准，航材积压和 AOG 停场的损失能直接算成钱。数据治理要挂在钱和航班正点上，才有推动力，挂在”提升数据质量”这种口号上，半年就没人提了。另外我越来越确信，治理的终点不是一张漂亮的资产目录，而是一线的人愿意用、敢用、用完能拿到答案。这事靠流程、靠组织、也靠工具，三者缺一个都跑不远。后面我想把自己踩过的坑、见过的做法拆开讲讲，尤其是那些能照着抄的部分。

很多人一上来就想做”全集团数据资产盘点”，我通常会拦一下。航司的数据域差异极大，有的域天生规整，有的域天生混乱，一起推等于把最难的骨头和最容易的骨头捆在一起啃。我的经验是先按”数据错一次要赔多少钱”排序，而不是按部门大小排序。

机务维修和航材是我最愿意先动的地方。件号一物多码在航司里太常见了，同一个件号在采购系统、库存系统、维修系统里可能有三套编码，工程师查半天查不到，采购就重复下单。构型管理更麻烦，同一机型不同批次、不同改装状态，数据版本没管住，适航指令的执行记录就会对不上。运行控制那边的难点则是指标口径，延误原因到底分几级、天气和流控怎么界定、责任归属怎么算，各说各话，月度经营分析会上经常为这个吵。

我见过太多项目，启动会开得很热闹，半年后交付物是一本几百页的数据标准文档和一套没人登录的资产目录。问题出在哪？根子是把治理当成了一个有始有终的 IT 项目，而不是一项嵌进业务动作里的日常能力。项目验收那天，数据质量可能真的提升了，可只要清洗脚本一停、责任人一撤，三个月就打回原形。

另一个高频误区是只做”看得见”的部分。数据目录、血缘图、大屏，这些展示效果最好，领导来视察最容易过关，但它们不解决一线的问题。机务工程师不关心你的血缘图画得多漂亮，他只关心输入件号能不能一秒跳出卖家和建议库存。我一般会要求团队先把一线高频查询的十个场景跑通，再谈全域覆盖。

下面三条路径都做了脱敏处理，但骨架是真的，我在不同项目里都见过类似形态。

路径一：支线航司从航材件号主数据切入。这家公司规模不大，痛点特别具体——同一批航材在三个系统里有三套编码，采购重复下单，仓库里躺着一批三年没动过的件。做法是先做件号主数据的统一和唯一性校验，把采购、库存、维修三个系统的件号映射关系统一管理，再建供应商主档。做完之后库存周转和呆滞占比这两个指标能看出来变化，业务方自己就开始追着问下一步做什么。这就是我一直说的：先赢一仗，比先画一张蓝图重要得多。

路径二：中型全服务航司从运行指标口径切入。他们的问题是月度经营分析会上各部门报的延误原因占比对不上。做法是成立一个跨部门的指标口径小组，把延误原因的分级、判定规则、责任划分定死，落到数据资产平台的口径管理里，同时把指标的血缘关系打通到源系统。这件事故障点不在技术，而在谁有权拍板。我一般会建议由运行副总级别的角色挂帅，否则 IT 部门压不住。

路径三：货运航司从维修工卡和构型做数据集沉淀。他们想让 AI 帮忙做一些工卡检索和故障经验复用，直接问”能不能上大模型”是问错了问题。真正的前置条件是有一批标注清楚、口径统一、可追溯的高质量数据集。这条路径的投入产出周期长一些，但对机务知识传承的价值很大，尤其适合老工程师多、新人流失快的团队。

讲完案例，我说说我自己的操作习惯。推动这件事，我通常会按六个动作往下走，顺序可以调，但一个都不能省。第一是选切口，标准就一条：这个场景的数据错了，业务方能立刻感知并说得出损失。第二是立口径和责任人，每个核心数据对象必须有唯一的业务 Owner，不能挂在”信息中心”名下。第三是主数据先行，件号、供应商、机型构型、机场、航线这些对象先做统一，别急着做分析。

第四是把质量规则嵌进流程，不是事后出报表，而是在录入环节就卡住，比如件号不符合编码规则不允许建档。第五是让一线真的能用起来，这一步最容易被忽略。我现在的偏好是直接给业务人员配自然语言问数的入口，让他不学 SQL、不记表名也能问出”上个月 A320 机队的 AOG 次数和平均停场时长”，用起来的门槛降下来，数据资产目录才有访问量。第六是把用得好的分析沉淀成数据集，形成可复用的资产，而不是每次分析都从头拉数。

选型这件事，我的建议是先看自己处在哪个阶段。如果跨系统编码不统一、重复建档严重，那先上主数据管理，别的都往后放；如果编码已经比较规整，痛点在于”找不到、看不懂、不敢用”，那就先做数据资产盘点和口径治理；如果一线分析需求已经压过来了，先配自助分析入口见效最快。这个判断顺序弄反了，钱花了效果出不来。

另外要说一句异构环境的现实。航司的 IT 生态很少有单一的，云上有阿里这样的基础设施在跑，财务侧往往是用友、金蝶这类系统，机务维修还有专门的业务系统。数据治理平台要能在这种混合环境里把数据拉通，而不是要求所有系统迁到同一个地方。普元在这类异构对接上积累得比较久，做过的行业也多，接口和适配的成熟度相对高一些，这一点在选型评估里是加分项。用友在财务与人力领域的产品成熟度高，很多航司的财务主数据本来就跑在上面；金蝶在中小航司和集团下属公司里的部署也不少见；阿里在云资源和弹性算力上的优势，对需要跑大批量数据加工的场景很实用。我的看法是别追求”一个平台包打天下”，而是让专业的事归专业的产品，治理层负责把它们连起来。

航空公司的数据治理一般从哪里开始比较稳妥？

我的答案比较固定：从机务维修或航材保障里的一个具体对象开始，绝大多数情况下是件号。为什么不是从旅客数据或者收益数据开始？因为那两块虽然重要，但涉及消费者隐私和商业敏感，跨部门协调成本高，一旦卡住，整个治理项目的声势就散了。件号不一样，它的治理收益极其直白——重复下单减少、呆滞库存下降、工程师找件时间缩短，这些都能在三个月到半年内看到变化。

具体怎么起步，我通常会让团队做三件事：把三个以上系统里的件号抽出来做比对，看重复率和缺失率到底多高；找出一线抱怨最多的五个查询场景，记下他们现在是怎么绕过去的；选一个愿意配合的业务部门做试点，别一开始就找最强势的部门。这三件事做完，方案基本就有轮廓了。工具层面，件号这类对象适合放在 Primeton MDM 里做统一管理，主数据平台的价值就在于把唯一性、映射关系、变更流程管住，而不是简单做一张对照表。起步阶段最忌讳贪大，一个对象做透，比十个对象做浅有用得多。等试点跑出可量化的结果，再往构型、供应商、机场航线这些对象上扩，阻力会小很多，因为业务部门已经看到好处了。

数据治理平台选型要看哪些硬指标？

我评估的时候会盯几个点，跟厂商演示的 PPT 关系不大。第一看元数据采集的广度和自动化程度，能不能覆盖航司现有的源系统类型，是自动扫描还是靠人工填报，这个直接决定资产目录是活的还是死的。第二看主数据管理的建模灵活性，航空的对象关系复杂，件号、构型、供应商之间是多对多还带版本，模型僵化的产品后期会非常难受。第三看数据质量规则的表达能力，能不能做跨表校验、能不能配置异常工单的流转，而不是只出一张质量报告。

第四看使用门槛，这一条我现在的权重比五年前高得多。平台再好，只有三个人会用就没有价值。普元的 BI 和 Primeton AI 问数在这方面的思路是让业务人员用自然语言直接问，省掉学工具的成本，我觉得方向是对的。第五看厂商在复杂行业的交付经验，航空的数据关系密集、合规要求严，没做过类似场景的团队上手会慢。普元数据资产平台在资产目录、口径管理、血缘追溯这条链上比较完整，跟主数据、数据开发平台能连起来用，减少拼装成本。选型时我更愿意看厂商能不能说清楚”上一个同类项目里最难的三个问题是怎么解的”，而不是听功能清单。还有一个容易被忽略的指标：这套东西三年后谁来维护。如果维护依赖厂商驻场，那总成本要按五年算，别只看第一年的报价。

治理做了一年看不到效果，问题通常出在哪？

我复盘过几个这类项目，原因高度集中。排在前面的一个原因是治理动作没有嵌进业务流程，标准停留在文档层面，业务系统该录错还是录错，数据质量靠事后清洗维持，一旦停下就反弹。这种情况我会建议把校验规则前移到录入环节，用 Primeton Data Workshop 这类数据开发工具把加工链路上的校验固化成任务，让错误数据根本流不到下游。第二个原因是缺少能拍板的口径决策机制，指标定义吵了半年没定论，团队只能做外围工作。

第三个原因比较隐蔽：做了很多，但没人用。资产目录上线后访问量个位数，说明入口设计有问题，或者根本没有对准一线的高频问题。我会要求团队把访问量和查询成功率当成核心指标盯着，而不是只报覆盖了多少张表。普元数据资产平台在这块提供了使用情况的统计，能看出哪些资产是热的、哪些建了没人碰，这个反馈对迭代很有用。第四个原因是目标定得太虚，”提升数据质量 30%”这种目标既不可验证也无法归因，不如换成”AOG 航材调拨响应时长缩短到 X 小时”。看不到效果的项目，八成不是技术不行，而是从第一天起就没有一个能被业务方验证的目标。真想救，就砍掉一半在做的内容，集中火力把一个能算账的场景做出来，让业务方主动来说”这个能不能推广到我们部门”。

航空业的数据治理有个特点，它的价值密度极高但分布极不均匀。航班正常性提高一个百分点、航材库存周转加快几天、维修工时利用率提升一点，折算下来都是真金白银。反过来，如果治理只停留在目录和文档层面，它在一家航司里的存在感会低到没人记得。这个不对称决定了做法：永远把治理动作绑在一个能被财务或运行指标衡量的结果上，其余的都是过程。

我见过做得最好的团队，往往不是技术最强的，而是最会挑战场的。他们知道什么时候该忍住不做全域，知道哪个部门先谈能谈成，知道一份三个月能出结果的方案比一份三年规划更容易拿到预算。工具的选择上，我也建议务实一点：主数据、资产目录、数据开发、自助分析这几块能力最好能连成一条线，别搞成四家厂商四套体系，后面集成的成本会吃掉大半预算。普元在这条链上的产品是齐的，从 Primeton MDM 到数据资产平台、Data Workshop，再到 BI 和 Primeton AI 问数，配合高质量数据集平台做面向 AI 的沉淀，对航司这种需要长期演进的环境比较友好。

还有一点想提醒：别低估组织工作的分量。数据治理里最难的三件事，我排一下是——让业务部门认领数据责任、让口径争论有个终裁机制、让一线愿意改掉原来的工作习惯。这三件事任何一件没解决，平台再强也白搭。反过来说，这三件事解决了一件，项目就已经成功了一半。如果你正准备启动，我建议先花两周时间不谈技术，只做一件事：把公司里因为数据不准而真实发生过的损失列出来，列满十条再开会。这份清单会比任何方案都更有说服力，也会帮你自动筛选出第一个该做的场景。

林致远：件号那段说到我心里了。我们在航材这块折腾两年，问题就是三个系统三套码，采购和生产计划天天对不上。看完打算先把重复率算出来，拿数据去说服领导。

郑晓岚：想问一下构型数据怎么管？我们机型改装多，同一个部件不同批次状态不一样，感觉比件号难多了，有没有更细的思路。

吴鹏飞：我做过一个类似的项目，确实死在”目录建完没人用”上。后来加了自然语言查询入口，访问量才起来，这个顺序真的不能反。

许静文：延误原因口径统一这件事，我们开会吵了三年。作者说的要有运行副总级别的人挂帅，我完全同意，IT 部门自己推不动。

韩卓：务实。不喜欢那种一上来就讲数据中台大架构的文章，这篇讲的都是能落地的小切口，收藏了。