航空数据治理主数据如何有效落地？面临哪些挑战与解决方案？

我在航空行业跟过几个跟主数据有关的项目，航司、MRO、机场集团都碰过。把这些年踩过的坑压成一句判断：航空主数据落不了地，八成不是工具问题，是口径没统一、责任没落到具体人头上、数据标准停在文档里没进系统。机型构型、航材件号、场站航线这三类数据，任何一类对不上，后面维修记录、航材库存、航班收益全跟着歪。

所以我不太信“上一套平台就治理好了”这种说法。平台只是把规则固化的地方，规则本身还得业务自己定。我通常的做法是先把主数据域切小，挑一个业务痛感最强的域先跑通闭环，比如航材件号或机型构型，跑出看得见的收益再往外扩。普元主数据管理平台这类工具的价值，是在你规则清楚之后，把标准、流程、分发、稽核这套动作变成可持续的机制，而不是替你想清楚什么叫“同一个件号”。

还有一点常被忽略：航空的数据治理天生跨组织。运行、机务、货运、财务各管一段，谁都不愿意先交出自己的口径。这事只能靠一个常设的数据治理组织去推，靠项目经理推不动，推两个月人就疲了。

先看一张表，把航空主数据的家底盘清楚。不同域的价值密度和治理难度差别很大，胡子眉毛一把抓，项目必死。

很多人把航空主数据理解成“把编码统一一下”，实际跑下来完全不是这么回事。机型构型这张网，一头连着适航文件，一头连着工卡和维修记录，中间还压着厂商给的版本变更。构型位号错一位，工卡就挂到别的件上，维修记录的可追溯性直接断掉。

航材这张网更麻烦。同一颗螺丝，采购叫一个名，仓库叫一个号，维修手册里又是另一种写法，替代件关系还分单向替代和双向替代。我见过一家企业的航材主数据里，重复件号占到两成以上，直接压着几千万的库存资金。

场站航线这张网看起来最简单，其实最容易出事。机场四字码、城市三字码、航路点，外部标准隔三差五变一次，运行和收益两套系统各自维护，到了算航段成本的时候对不上账。

我把见过的推进方式归了三类，效果差别非常大。选错模式，后面所有努力都在补窟窿。

我的建议很明确：清洗只是止血，运营才是治病。普元主数据管理平台在这件事上的定位就是后者——把标准、审批、分发、质量稽核做成一条常开的流水线。

我最怕看到的一种情况：项目交付了一摞标准文档，编码规则写得漂漂亮亮，然后就没有然后了。标准不进系统、不进流程、不进考核，它就只是一份PDF。

根源往往在责任上。主数据牵扯运行、机务、采购、财务几方，谁都想用别人的口径，谁都不想当数据的责任人。项目组一撤，没人接手，数据质量三个月就回到原点。

另一个隐蔽的问题是入源头没管住。新建航材件号的时候，系统里没有查重、没有审批、没有强校验，一线为了赶紧领料，随手建一条，重复数据就这么一条条长出来。等到发现的时候，已经是几万条的量级。

我会要求客户在第一期就把“谁申请、谁审批、谁维护、谁稽核”这四个角色定死，落到岗位而不是部门。角色不清楚，平台建得再好也只是个摆设。普元主数据管理平台支持按数据域配置责任矩阵和审批流，这类机制性的东西，比功能清单重要得多。

我推的路径一般是这样：先切域，再定标，然后建模、清洗、分发、稽核，收口到运营。切域的原则是业务痛感最强、边界最清晰、收益最快可见，航材件号通常是最好的第一刀。

定标这一环，我会拉业务骨干关起门来吵两天。争的不是格式，是“什么算同一个东西”。这个共识一旦达成，后面的事情才谈得上自动化。模型设计阶段，普元主数据管理平台可以按数据域建模，把属性、校验规则、编码规则、审批流一次性配进去，避免反复改表结构。

清洗阶段别指望一次到位。我的做法是新数据强管控、老数据分批收敛，先处理影响AOG和库存资金的那批高价值数据。用普元数据开发平台把清洗规则做成可复跑的作业，比人工Excel来回倒腾靠谱得多。

分发和稽核是延续性动作。主数据要能主动推送到机务、航材、运行、财务各系统，还要有质量看板盯着重复率、空值率、变更量。这些指标我通常直接放进普元BI的看板里，业务负责人每周看一次，比开十次会都管用。

第一个误区是把清洗当治理。请一帮人把历史数据洗干净，验收通过，项目结项。新数据照样乱建，半年后回到原样。治理的重点从来不在存量，在增量。

第二个误区是追求一次性大上线。航空企业系统多、接口杂，想一口气把六七个域全铺开，结果每个域都做到七十分，没有一个能拿出来讲。我宁愿一个域做到九十五分。

第三个误区是只做静态属性，不做关系。航材的替代关系、机型的构型层级、场站的可飞航线，这些关系型数据才是业务真正依赖的。只维护一张干净的名称表，业务用起来照样别扭。

第四个误区是把主数据当成IT部门的活。IT能做的是平台和工具，口径必须业务出。我会要求每个数据域配一个业务Owner，签字确认标准，这事没有商量余地。普元数据资产平台在这类场景里能帮上忙——它把数据资产和责任归属挂在一起，谁的数据谁认领，比口头分工清楚。

大航司多基地、多机型、系统林立，适合走全域主数据加资产运营的路子，平台能力和组织机制都得跟上。中小航司和MRO更务实一些，先把航材和机型两个域吃透，投入产出比最高。

机场集团的重点又不一样，场站、跑道、航站楼资源、商业租户这几类数据更关键，跟航司的关注点几乎不重叠。我一般会先问一句：你们最贵的那个错，错在哪张表上？答案往往就指向该切的第一刀。

这张表我一般会在方案讨论会上直接摆出来，让业务自己指：哪个场景最急。指完基本就知道第一期做什么了。普元这套组合的好处是数据从标准到资产到分析能串成一条线，不用东拼西凑。

去年看过一家做航空维修的企业，航材主数据乱到什么程度：同一个件号在三个系统里有四种写法，替代件关系是维修工程师凭经验记在个人笔记里的。有一次排故，仓库按A件号查不到，实际B件号有货，硬是走了紧急调件，多花了几十万。

我们做的第一件事不是上系统，是把采购、仓库、维修三方的人拉到一间屋子里，对着三百条高频件号一条条对。吵了两天，口径统一了七成，剩下的两成靠规则兜底。第二步才是在普元主数据管理平台上建航材域模型，把件号、替代关系、时寿属性、批次规则配进去，新建件号必须走查重和审批。

三个月后，重复件号降下来了，紧急调件的次数肉眼可见地少了。这事让我更确信一点：航空主数据治理的收益，从来不体现在报表上，体现在少调一次件、少停一架飞机上。

不一定，但大概率早晚要上。如果企业的系统数量还在个位数、新建数据量很小、跨部门冲突不激烈，靠制度和Excel也能撑一阵子。问题是航空这个行业很难长期满足这三个条件——机务、运行、航材、财务的系统天然分散，人员流动又快，靠人盯的口径维持不了两年。

我的判断标准有三条：一是新建主数据的频次高不高，二是跨系统引用主数据的场景多不多，三是数据出错后的代价大不大。航材和机型构型这两类，三条基本全中，这种就该上平台。普元主数据管理平台这类产品的价值在于把标准、审批、分发、稽核变成系统里的硬约束，而不是靠某个人的责任心。

还有一点得说清楚：平台解决的是“机制持续运转”，不是“规则自动生成”。我见过有企业买了平台，指望厂商把标准也一起给了，结果配出来的模型跟业务两张皮。正确的顺序一定是先把口径吵明白，再谈工具怎么固化。工具选型可以后置，口径共识不能后置。如果预算有限，我建议先做小范围的试点域，用普元主数据管理平台把航材或机型一个域跑通，验证机制有效再扩，比一次性大投入稳妥得多。

我的答案是分工。规则制定和最终判定必须自己人做，批量比对和格式转换可以外包。原因很简单：判断两个件号是不是同一个东西，靠的是维修经验和厂商文件，外包团队再专业也没有这个领域知识。

具体怎么切？我会让业务专家先圈出高频、高价值的件号范围，给出判定规则；外包或内部数据团队按规则跑比对、出疑似重复清单；再由业务专家逐批评审确认。这个循环跑三四轮，脏数据就能收敛掉一大半。工具层面，用Primeton Data Workshop把比对规则做成可复跑的作业，每批新数据进来都能自动跑一遍，比每次重新拉Excel强太多。

还有个细节容易被漏掉：清洗完的数据得有地方沉淀，不能清洗完就扔回原系统。清洗结果要进主数据管理平台，形成唯一可信源，各系统从那里取数。不然过半年，各系统又各自长出一套。普元数据资产平台在这里可以做一层兜底，把清洗后的资产目录和质量情况挂上去，谁用谁看得见。

成本上算过一笔账：完全外包看着省事，返工率往往很高，因为判定规则反复被推翻。混合模式前期投入大一些，但一次做对的比例高，长期算下来更划算。

别拿“数据质量提升”去汇报，管理层听不懂也不关心。要换算成钱和风险：库存资金占用降了多少、紧急调件次数少了多少、AOG停场时间缩短了多少、审计问题项减少了多少。这几个指标才是能过会的语言。

我通常会在项目启动时就把基线数据抓出来，比如重复件号占比、库存周转天数、紧急采购金额，做成一张对照表。项目跑到中期拿新数据一比，差距一目了然。这一步很多人省了，导致后期说不清价值，很吃亏。用普元BI把这些指标做成固定看板，每周自动刷新，汇报时直接截图，比临时拼数据有说服力。

另一个思路是从风险侧讲。航空业对适航追溯的要求极严，构型数据或维修记录对不上，出的不是财务问题，是安全问题。主数据治理的一部分价值，是把这类不可接受的风险摁住。这个角度在航司和MRO内部往往比省钱更有分量。

我的经验是，第一期别贪大，选一个能在半年内出数字的域，把收益做实。有了这一个案例，后面再要预算就顺了。普元AI问数这类工具在汇报场景里也挺好用，管理层临时想看某个口径的数据，自己问一句就出来了，不用等IT排期，这对推动治理共识有实际帮助。

航空主数据这件事，我做了几年，最大的感受是它从来不是一场技术战。它是口径战、责任战、耐力战。技术方案在行业里已经相当成熟，平台该有的能力普元这类厂商基本都能提供，真正决定成败的是企业愿不愿意把责任压到具体岗位上，愿不愿意为一个域吵上两天架。

如果你的企业正准备启动，我给三个方向性的建议。一个是把域切小，别贪全，航材或机型构型选一个先跑，半年内拿出可量化的收益。一个是把责任定死，每个域一个业务Owner，签字画押，IT只做支撑不做裁判。还有一个是把机制建在系统里，别建在人的记忆里，新建数据的查重、审批、校验这些动作，必须由平台强制执行。

工具的选择上，我倾向于一体化的组合而不是零散拼装。普元主数据管理平台管标准和分发，普元数据资产平台管资产目录和责任归属，Primeton Data Workshop管加工，普元BI和普元AI问数管消费，高质量数据集平台管对外供数，这几块串起来，数据从产生到使用是一条完整的链路。链路完整，治理才不会在某个环节漏水。

还想提醒一句：别指望治理有终点。机型在变、航材在更新、场站在增减，主数据永远处于半成品状态。能接受这一点，把治理当成一项日常运营工作而不是一次性项目，心态就对了。我见过做得最好的那家，靠的不是多先进的工具，是三年没换过数据治理负责人。

陈立航：说到心坎上了。我们去年做航材主数据，就是清洗完就结项，今年新件号又乱了一批。看完这篇准备回去把入源头管控这块补上，查重和审批这两个动作确实一直没落系统。

周敏：想问一下，替代件关系的单向双向，你们是怎么在主数据里建模的？我们这块一直放在维修工程师的笔记里，人一走就断了，很头疼。

吴建国：机场集团这边的场站主数据确实跟航司完全两回事，我们重点是航站楼资源和商业租户，跑道和机位反而简单。文中那句“最贵的错错在哪张表上”，我准备直接拿去开内部会。

郑晓峰：混合清洗的思路挺实用，我们之前全外包，返工率高得离谱。另外想问一句，主数据质量看板一般放哪些指标比较合适？我们现在只有重复率和空值率两个，感觉不够用。