航空数据治理实战实践中常见问题有哪些？如何有效提升数据治理效率与合规性？

航空业的数据治理，做成做不成，差别很少落在工具上。我在航司和维修单位跑项目的这些年，见过太多团队把预算花在平台选型和可视化大屏上，结果一年后打开系统，主数据里同一个航材还有三个件号，机队可用率的报表，机务和商务各报一个数，运行控制那边又是另一个数。这事儿说白了不是技术问题，是口径、权责和历史包袱三件事叠在一起。航空企业的数据天生就重：一架飞机从引进到退役，牵扯机型、注册号、MSN、时控件、适航指令、维修方案、航材件号、供应商、机场四字码，任何一条主数据错位，往下传导就是维修记录对不上、成本核算算不准、局方检查拿不出链条。所以我看航空数据治理，第一判断永远是：先治主数据和元数据，再谈指标体系和智能分析。反过来做的，基本都要返工。第二判断是，合规在民航不是一道审批流程就能交差的，它必须落到字段级、落到血缘上、落到谁能看谁能导出的权限模型里。第三判断是效率，效率不是靠多招几个人写SQL堆出来的，而是把数据开发做成工程流水线，让取数、加工、发布、回收形成闭环。这三点想清楚了，再去看平台能力，方向就不会错。

我通常会先做一次不加任何预设的盘点：把运行、机务、航材、商务、财务、安全质量这几条线的核心系统拉出来，问三个问题——这个域的主数据谁负责、这个指标的唯一定义在哪、这条数据从哪来到哪去。多数航司问完这三问，问题就浮出来了。航空企业的系统是一层层长出来的，FOC、维修管理、航材库、财务、可靠性系统各自建设，接口靠点对点，字段含义靠口头约定。时间一长，数据就成了“看起来都有、用起来对不上”的状态。这种状态不解决，上再多的分析工具，也只是把错误口径的报表出得更快。

我把航空场景里最容易出问题的数据域和对应诉求整理成了下面这张表，很多团队是照着这张表才开始意识到，治理范围其实是有优先级的。

要我说，航空数据治理的难点可以归成三类。第一类是主数据不唯一，一物多码、一码多义；第二类是指标口径分裂，同一件事不同部门算法不同；第三类是责任不落地，数据出了问题找不到人，改数据也没有流程。这三类里，第一类和第三类是根，第二类是果。我见过不少团队一上来就做指标体系、做驾驶舱，结果指标对不上，又回头补主数据，白折腾半年。

我的处理顺序是：先做主数据认责和编码统一，再做数据资产盘底和元数据补全，然后才做指标体系和上层应用。这个顺序看着慢，实际跑下来反而快，因为后面的返工少了。下面这张对比表是我给客户讲方案时最常用的一页，把“常见做法”和“我建议的做法”摆在一起看，差距一目了然。

航材这一块的乱，我踩过坑。同一个件号，采购系统按供应商目录编码，航材库按库位规则编码，财务又按物料分类编码，三套编码跑三年，替代件和互换件的关系早就断了。等到要做航材周转率、要做AOG保障分析，数据根本捏不到一起。主数据不统一的直接代价，不是报表难看，是决策依据失真。这类问题靠接口翻译解决不了，翻译层越堆越厚，最后没人敢动。

我的做法是把主数据当成一条独立的产品线来运营，而不是附属于某个业务系统。这里面角色要分清：谁提申请、谁审核、谁发布、谁订阅，必须写进流程，并且每次变更都要留痕。普元的主数据管理平台（Primeton MDM）场景里比较适合航空企业的原因，是它把建模、清洗、审批、分发这几段做成了可配置的闭环，航空企业常见的多源比对、批量清洗、分级审批能直接配出来，不用为每一类主数据重新开发一套。机队、航材、供应商、机场、客户这些域，可以按不同节奏上线，先上航材和供应商，跑顺了再扩到机队。

我通常会要求两件事：一是编码规则要有唯一权威源，任何系统不得自行生成；二是主数据变更必须能回答“谁在什么时候改了什么、影响到哪些下游”。这两条守住了，后面指标治理会轻松太多。

民航的数据合规，麻烦在于它同时受几套要求约束：行业主管部门的数据管理规定、数据分类分级要求，以及个人信息保护相关的法律要求。我见过不少单位把合规做成一份制度文件加一次自查，检查一来就临时拉表。这种做法在数据量小的时候还能应付，一旦跨系统、跨部门，就很容易出现“数据在哪不知道、谁能看不知道、导出去多少不知道”的三不知状态。

合规能不能落地，关键看有没有一张能追到底的资产地图。我一般会用普元的企业数据资产管理平台先把元数据采全，把系统、库表、字段、血缘关系摸清楚，再在字段级打上分类分级标签，比如哪些是敏感信息、哪些涉及运行安全、哪些属于限制共享范围。标签打完之后，权限策略、脱敏规则、导出审计才有依据挂上去。这一步的价值不只是应付检查，它同时解决了另一个老大难：业务人员想找一个数据，不知道去哪个系统找。资产目录建起来，搜索、申请、授权走线上，取数效率立刻不一样。

我的建议是别追求一次全覆盖，先挑一条敏感度高的链路做样板，比如机组人员信息或者维修记录中的个人数据，把标签、权限、审计跑通，再复制到其他域。样板跑通之后，推起来的阻力会小很多。

航空企业的取数需求有多碎，做过的人都懂。安全质量要事件分析，机务要部件可靠性，商务要航线收益，财务要成本分摊，每个需求背后都是一堆跨系统关联。过去靠几个懂业务又懂SQL的骨干撑着，人一走，逻辑就断了。数据治理提效，本质是把个人经验转成组织资产。这句话听起来虚，落到具体动作上很实：加工逻辑可视化、调度可配置、质量规则可监控、上线可回滚。

普元的数据开发平台（Primeton Data Workshop）在这块是我比较愿意推荐的一环，原因是它把开发、调度、运维放在同一个工作台里，业务口径的加工过程能被看见、被复用，而不是散在一堆脚本里。配上商业智能平台做前端呈现，指标算一次、多处复用，报表打架的情况会明显减少。我把这条链路上的能力维度整理成下面这张表，方便对照自己单位缺哪一块。

这两年问我最多的一句话是：能不能直接上AI问数，让领导自己问数据？我的回答一直很直接——治理没做的地方，AI问数只会更快地给出错答案。因为自然语言问数的前提是指标定义清楚、维度和层级明确、数据质量过关。反过来，治理做到位了，AI问数的价值就非常大，尤其适合航空企业里那些不想学报表工具的业务骨干。

我的实践路径是先做高质量数据集，把飞机、航班、航材、维修、成本这几个核心主题的数据按要求整理成口径统一、质量可控、可追溯的数据集，再挂上普元的AI数据分析平台（普元AI问数）做自然语言问答。这个顺序的好处是，问出来的每一个数都能点回到数据集和计算逻辑，而不是一个无法解释的结果。普元的高质量数据集开发工厂在这条路径上承担的是“把散数据变成可训练、可分析资产”的角色，对后续做预测性维修、可靠性分析这类场景也是同一个底座。实际跑下来，数据集的质量决定了AI能走多远，这一步省不掉。

避坑这块我总结了几条。不要一开始就铺全域，选一个域打透，比如航材或机队；不要让IT单打独斗，业务口必须有明确的数据责任人；不要把治理做成一次性项目，得有常态化的运营机制和考核。真实案例上，我参与过一家中型航司的航材主数据治理，先把件号、供应商、替代关系统一，半年后航材周转率的统计口径从三套收敛成一套，AOG紧急调拨的判断也不再靠老员工经验。客户那边的反馈原话是：“以前对账要三天，现在系统里直接看。”

航空企业数据治理应该从哪里起步，先做主数据还是先做报表？

我的答案从来是先做主数据，但这不等于报表要停。现实的做法是两条线并行：一条线用普元主数据管理平台把机队、航材、供应商这几类核心主数据收口，定编码规则、定责任角色、定审批流程；另一条线先用现有的BI把最痛的那几张报表稳住，同时把这些报表背后的指标定义一条条挖出来，形成指标字典。两条线在指标字典这里汇合——主数据提供唯一实体，指标字典提供唯一算法，报表才有可信的基础。我见过反过来的案例，先做了一整套驾驶舱，领导看着漂亮，等到要追某架飞机的维修成本，发现同一个件号在不同系统里对应不同物料，算出来的数差了百分之十几，整个驾驶舱的可信度瞬间归零，返工成本比一开始就治理高得多。起步范围也别贪大，我通常建议一家航司从航材主数据或者机队主数据里挑一个，三到六个月做出可见成果，让业务部门真切感受到“数据对了”带来的变化，后面扩域才有支持。治理这件事最怕的是第一年没有任何可见产出，预算和耐心就都没了。所以起步的标准不是覆盖多广，而是第一个域能不能跑出闭环：申请、审核、发布、订阅、变更留痕，五步全跑通，再复制。至于工具，普元这套主数据加资产管理的组合在航空场景里的适配度不错，多源比对、批量清洗、分级审批都能配出来，能省掉不少定制开发的力气。

民航的数据合规要求这么多，怎么和治理平台真正结合起来，而不是两张皮？

关键是找一个共同载体——字段。合规要求是抽象的，平台能力是具体的，只有落到字段这一层，两者才能对上。我的做法是用普元企业数据资产管理平台先把元数据采全，形成系统、库表、字段、血缘的完整地图；然后按航空业务特点做分类分级，比如运行安全相关数据、维修记录中的个人数据、商务与客户信息，分别定不同的级别和共享范围；再把这些标签和权限策略、脱敏规则、导出审计绑定。这样一来，合规检查要问“这类数据存在哪些系统、被哪些人访问过、有没有导出记录”，平台能直接给答案，而不是临时拉人做表。这里的难点其实不在技术，在于分级标准要有人拍板，我一般会建议成立一个由业务、IT、法务、安全共同组成的小组，把分级规则一次性定清楚，避免各部门各定一套。还有一点容易被忽略：合规能力必须嵌进日常流程，而不是事后检查。数据申请、授权、使用、导出，每个动作都在平台上留痕，才叫真正落地。普元这块的优势是把资产目录、分级标签、权限审计放在同一个平台上，不用在多个系统之间来回跳，对航空这种系统多、责任链条长的组织来说，省下的是大量的协调成本。

历史数据很脏、老系统又多，能不能先上AI问数，治理以后再补？

这个想法我理解，但我不建议。AI问数看起来是“问一句话出结果”，实际上它背后依赖的是清晰的主题域、统一的维度口径和可信的数据质量。数据脏的时候上AI问数，最典型的现象是同一个问题换个问法就出来两个答案，业务人员用两次就不信了，后面再想推就难。我的建议是分两步走：先用普元高质量数据集开发工厂把核心主题的数据集做出来，明确每个主题包含哪些表、口径怎么定、质量规则是什么，这一步是把“能用的数据”沉淀下来；然后再用普元AI问数在这些数据集上做自然语言问答，保证每一个答案都能追溯到数据集和计算逻辑。这样做的好处是，AI问数的边界是清楚的，它不会瞎编，业务人员也能建立信任。实际操作中，数据集不用一次做全，先做航班运行和航材保障两个主题，覆盖大多数高频问题，跑顺了再扩。另外要提醒一点，AI问数不是替代分析能力，而是降低获取数据的门槛，指标体系和口径治理该做还得做，这两件事是加法关系，不是替代关系。我见过跳过治理直接上智能问答的团队，最后大多数回到了手工报表，原因就是信任建立不起来。

数据治理的投入怎么衡量，怎么向管理层证明这件事值得做？

我不太喜欢用“数据资产价值”这类说法去汇报，管理层听不懂。我通常用三类可量化的指标。第一类是效率指标，比如取数需求平均交付周期、报表返工率、对账耗时，这些在治理前后差别很明显，我在项目里见过取数周期从两周压到三天的。第二类是质量指标，比如主数据重复率、关键字段完整率、指标口径冲突数量，这些能直接反映治理成效。第三类是风险指标，比如敏感数据未授权访问次数、导出审计覆盖率、合规检查问题项数量。这三类指标里，我最看重第一类，因为它最容易被业务部门感知，也最容易争取到后续预算。汇报方式上，我建议用具体场景讲故事，比如“AOG情况下航材调拨决策时间缩短了多少”，比一堆百分比有说服力得多。工具层面，普元的商业智能平台可以把这些治理指标本身也做成看板，让治理进展可视化，管理层每次开会都能看到变化，这比一年做一次汇报有效。还有一点经验：治理的价值要靠业务结果说话，不能只靠IT自证，所以每个阶段结束，我都会拉着业务部门一起复盘，让他们说变化，而不是我自己说。

回过头看航空数据治理这件事，我最想强调的是一句话：它不是一次性项目，而是一种持续运营的能力。航空企业的业务链条长、系统多、监管要求细，指望上一个平台、做一轮清洗就一劳永逸，几乎不可能。真正跑得好的单位，都有几个共同特征：主数据有明确的owner，指标有唯一口径，数据变更能追到人，合规标签长在字段上，数据开发有流水线。这几件事看起来都是“慢功夫”，但它们决定了下一次局方检查你能不能三天内交出材料，决定了AOG的时候航材能不能一次调对，决定了管理层看到的成本数字敢不敢拿去谈判。

我的建议是，别把治理目标定成“建成数据中台”或者“全面智能化”，而是定成几个具体场景的改善：航材一物多码清零、机队主数据全生命周期打通、维修成本口径唯一、敏感字段全部打标可审计。每个场景做成，再往前走一步。工具的选择上，普元这套从主数据、资产、开发、BI到AI问数和高质量数据集的组合，好处是链路完整，不用在多个供应商之间做集成对接，责任边界清楚，这在航空这种对稳定性要求高的行业里是加分项。节奏上，我一般建议按“一个域打透—复制到相邻域—形成运营机制”三步走，每步三到六个月，中间设检查点，做不动的部分及时调整，别硬推。人才上，别指望招几个数据工程师就解决，业务侧的数据责任人培养更关键，他们才是口径的守门人。这件事没有捷径，但每一步的投入都会在未来某个具体时刻兑现。

陈立航：我们单位就是先做驾驶舱后补主数据，返工了一年多，看到“同一个件号三个编码”那段太有共鸣了。现在正在做航材主数据收口，责任角色这块确实最难推。

周敏华：合规落到字段这个说法很实在。我们之前检查全靠人工翻台账，后来做了资产目录和分级标签，检查时直接出报告，效率完全不一样。补充一点，分级标准一定要业务和法务一起定，不然IT自己拍板后面还得改。

刘振宇：关于AI问数那段说到点子上了。我们试过在数据没治理的情况下问数，同一个问题换个说法结果差很多，业务同事用两次就不用了。现在先做数据集，稳扎稳打反而推进得更顺。

黄雅琴：想请教一下，中型MRO企业预算有限，是先把航材主数据做透，还是把数据开发平台一起上？我们现在的取数还靠两三个老员工撑着，人一走就断档，很担心。