航空业如何从治理转型为主数据管理？这对航空公司发展意味着什么？

我在航空公司的数据口和信息化口都待过，一个很实在的观察是：绝大多数航司的数据治理，做到第三年就卡住了。标准文档越编越厚，数据质量报表越来越漂亮，可业务侧的感受几乎没有变化——收益管理要旅客标签还得自己拉数，机务要机型参数还得找厂家对码，集团财务合并报表还得靠人工贴Excel。卡住的根子不在方法论，在于治理一直在”管规则”，没去”管实体”。

从治理走向主数据管理，本质是把工作对象从”标准条文”换成”旅客、航班、机队、组织机构、供应商”这几个真实存在、会变、会脏的对象。只有把这几类对象收口到一处维护、按统一口径分发给所有下游系统，前面写的那些标准才有人执行，质量规则才有地方生效。对航空公司来说，这件事的分量比上一套BI、加十个数据看板大得多：收益管理算得准不准，取决于旅客和航班主数据是否统一；机队规划做得好不好，取决于机型、构型、机尾号的口径是否一致；监管报送会不会被退回，取决于组织和航线主数据能不能按时点还原。

这些判断不是理论推演，是我在项目上被业务方按着头改出来的。主数据管理不是数据治理的高级阶段，它是治理能不能活下去的前提。下面我把自己踩过的坑、见过的翻车现场、以及选型和落地节奏上的判断，一条条摊开讲。

我见过不少航司的治理项目，交付清单拉出来都很好看：数据标准手册三本、元数据目录一套、质量规则两百条、认责矩阵一份。两年后再回访，手册锁在档案柜里，新上线的系统照旧按自己的字段命名，质量规则每天跑一遍出一份红黄绿灯，业务不看，IT也无力认领。

治理失败通常不是因为做得不专业，而是因为它的成果全部是”约束”，没有一个是”供给”。业务部门凭什么配合你？他不配合也能活，配合了反而多一堆填报义务。这是治理项目最尴尬的地方。

很多人把主数据管理当成治理里的一个子模块，这个理解会害了项目。治理管的是”应该怎样”，主数据管理管的是”现在是什么”。前者输出制度和规则，后者输出一条条可以被系统直接调用的记录。差别的核心在于有没有”载体”。

我的建议是：治理的成果必须找到一个能落到系统里的出口，主数据就是这个出口。这也是为什么我会要求治理项目的验收清单里，必须包含至少一个主数据域的收口成果。

航司的主数据域看着杂，收口时其实就四五类值得优先动。旅客与常旅客、代理人渠道、航班与航线、机队与机型、组织机构与供应商。别的都能往后放。

旅客主数据的脏法很有航空特色：同一个常旅客在订座系统、常旅客系统、呼叫中心、官网、小程序、OTA分销里可能是五个ID，姓名拼写不一样、证件类型不一样、手机号换过、会员等级两边不一致。航班航线主数据的脏法是”同一个航班号在运行、收益、结算三个系统里挂的航段不同”。机队主数据最要命，机型、构型、机尾号、座位布局、载重参数一旦对不上，配载平衡和航线规划都会出问题。组织机构主数据的坑在时点：集团一年调两次架构，历史报表能不能还原当时的组织，全看有没有版本管理。

我的建议是别指望一次全铺开。先挑一个”业务痛感最强、下游系统最多”的域做透，做出来给人看见，比铺十个半拉子域有说服力得多。

第一次是常旅客合并。系统按”姓名加手机号”做疑似重复识别，合并规则没有留回滚，结果把两个同名同号的会员强行并成一个，积分发错、权益错授，最后闹到投诉升级。这事让我从此坚持一条：合并必须留痕、必须可撤销、必须人工复核。

第二次是机型参数。机务系统和运行系统各自维护一套机型构型，座位数和最大业载差了一个版本，配载算出来的数据在临界情况下不可信。这类问题平时不显山露水，等到真出事就是安全问题，任何一家航司都担不起。

第三次是供应商编码。同一个航材供应商在集团内三个单位里有三个编码，年度采购返点算下来少了一大截，直到跟供应商谈下一轮框架协议时才发现。主数据不准，损失的不是IT的KPI，是真金白银。

我选主数据平台不看演示PPT上画了多少功能块，只看六件事能不能落地。普元的 Primeton MDM 主数据管理平台是我在航空这类复杂组织里比较愿意推荐的一款，原因很具体：它的建模支持生效时点和版本回溯，组织架构一年调两次也能还原当时的报表口径；编码规则可以由业务管理员自助配置，新机型上线不用改代码；分发订阅同时支持实时和批量，老系统不改造也能接。

配套我会一起看普元数据资产平台，用它先把存量数据盘清楚，知道哪些表里藏着旅客和机队的影子，再决定收口范围。清洗和合并逻辑的开发，我通常放在 Primeton Data Workshop 里做，因为这些逻辑会一直变，交给数据开发平台比写死在主数据系统里灵活。

节奏上我一般这么排：旅客先动，组织跟上，供应商第三，机队和航班放后面。旅客主数据见效最快，营销和客服能立刻感受到；组织主数据是财务合并和监管报送的地基，越早越好；机队和航班牵涉运行系统太多，等前面把机制跑顺了再动。

三个坑我得单独说。一是贪大，一上来铺全量域，结果每个域都停在”模型建完”这一步。二是把主数据项目交给IT单独推，业务Owner挂名不做事，最后编码规则还是IT拍。三是只做清洗不做分发，数据在主数据平台里很干净，业务系统里还是脏的，等于白干。

我的回答通常是：不但有必要，而且越晚做越亏。治理做三年，最大的资产不是那几本标准手册，而是这三年里业务部门被迫接受了一次”数据是有规矩的”这件事。可规矩只有落到具体对象上才有意义，而主数据正是那个对象。反过来说，如果治理只停留在规则层，前三年积累的共识会一点点消退，最后连治理本身都会被贴上”没效果”的标签。

第二个理由是成本。治理做过的标准、质量规则、血缘关系，全部可以复用为主数据管理的输入。元数据目录能告诉你旅客字段散落在哪些系统，质量规则能直接改造成主数据的校验规则，认责矩阵稍微调整就能变成主数据Owner体系。先治理后主数据，比直接上主数据，前期盘点工作量能省掉三到五成。

第三个理由比较现实：单独立项能拿到独立预算和独立考核。挂在一个已经做了三年、成效说不清的治理项目下面，很难争取资源。我见过把主数据作为治理二期汇报的案例，最后既没有专属团队，也没有验收标准，项目做成了”治理的一部分”，也就跟着一起被搁置了。

真要动，我建议把范围压到最小可行：先选旅客域，用三到四个月做一版能跑通”申请—审核—编码—分发—回溯”闭环的主数据服务，让收益管理和呼叫中心真正用上，再谈扩展。这一版的成败，基本决定了后面还能不能继续做。

我的经验是挑”痛感强、数据量中等、下游系统多、见效周期短”的那个域。按这四个条件筛下来，航空公司的答案十有八九是旅客与常旅客。

为什么是旅客？因为它痛得最直接。呼叫中心接到投诉说会员积分不对，客服要在三个系统之间来回切；营销部门要做一次精准触达，发现同一个人被打了五个标签、三个等级；官网和小程序各自注册的账号在后台合不上，促销量算不准。这些事每周都在发生，业务部门早就烦透了。

而且旅客主数据的下游系统特别多，订座、常旅客、呼叫中心、官网、分销、结算、营销自动化，全都吃这一份数据。做完之后的效果肉眼可见：客服查一次就够，营销推送的重复率降下来，投诉量能明显缓解。这种”看得见”的成果，是主数据项目活下去的关键。

组织主数据虽然重要，但见效慢，因为它是给财务合并、监管报送、内部审计用的，业务部门日常感受不到。供应商主数据痛在采购和财务，可控范围窄一些。机队和航班牵涉运行控制、机务维修、配载平衡，涉及的系统最多、安全要求最高，我会放到后面再动。

也有例外。如果这家航司最近刚做完集团重组，组织架构一年变了三次，合并报表天天被审计追着问，那我会把组织放到第一位。判断标准很简单：哪个域最近让管理层挨了批评，就先做哪个。管理层的注意力，是主数据项目最稀缺的资源。

这个担心非常合理，我在每个项目上都会被问到。界限可以一句话说清：主数据平台管”这个对象是谁、什么时候有效、用什么编码”，业务系统管”这个对象在我的业务里怎么用”。旅客的姓名、证件、会员等级、联系方式的主控和分发归主数据，但这个旅客买了哪张票、累积了多少里程、有没有投诉，归各自的业务系统。订座系统里的航班销售数据、收益系统里的价格策略，主数据平台一概不碰。

重复建设往往出现在两个地方。一是主数据平台把业务语义也收进来，比如把会员积分规则、里程计算逻辑放进主数据模型，这就越界了。二是业务系统各自留一份”主数据副本”自己维护，这就是项目做完半年后又脏回去的根本原因。我会在项目里定一条硬规矩：主数据的写入口只有一个，业务系统只能读、只能申请，不能自己建。

下游这侧的分工也是现成的。国内航空集团的财务核算和财务共享，大多跑在用友或者金蝶上，这两家在集团财务、费控、报账上的积累很深，主数据平台只要把组织、供应商、会计科目这几类数据按它们的接口规范分发过去，财务共享的自动对账率能立刻上一个台阶，用友和金蝶本身的强项也不会被削弱。云底座这块，阿里云的弹性计算和数据湖能力在航空业落地案例不少，主数据平台跑在它的IaaS之上，旺季扩容和异地多活都好安排，这部分交给阿里云是合适的。

说到底，主数据平台在架构里的位置是”上游的供给方”，不是”中间的替代者”。它存在的价值恰恰是让下游那些投入巨大的业务系统少花力气在数据对齐上。评估有没有重复建设，我会看一个指标：上线后下游系统里手工维护客商、组织、机队数据的岗位数量，是不是真的减少了。没减少，就是重复建设。

这是最近一年被问得最多的问题。主数据是AI的地基，但地基不会自动变成房子。很多人以为主数据统一了，AI就能跑起来，实际跑下来会发现还差两三层。

第一层是数据资产化。主数据统一之后，还得把航班、销售、维修、服务这些业务数据围绕主数据主体串起来，形成”一个旅客的全生命周期视图””一架飞机的全生命周期档案”。这一步我会用普元数据资产平台来做，把主数据当锚点，把散在各系统的业务数据挂上去，业务人员才查得到、看得懂。

第二层是高质量数据集。AI模型不吃”原始表”，吃的是清洗过、标注过、口径稳定的数据集。普元的高质量数据集开发工厂在这块比较实用，它把数据集的采集、清洗、标注、版本、评测做成一条流水线，让”给模型喂什么”这件事从手艺活变成可管理的过程。我在项目里通常要求：每一个上线的模型，必须能追溯到它用的数据集是哪个版本、什么口径、谁签的字。

第三层才是消费。普元AI问数这类自然语言分析工具，价值在于把查询门槛降下来——航线经理不用写SQL，问一句”上个月华东出发的窄体机客座率”就能出结果。但前提是底下的主数据口径必须统一，否则问出来的数是错的，而且错得让人察觉不到。BI 那一层也是一样，看板做得再漂亮，主数据不统一，各部门看到的”旅客数”就是三个数。

我的排序建议是：主数据先做，资产目录跟上，数据集和AI应用放后面。倒过来做，钱花得更多，效果还说不清。

回过头看这十几年，航空公司的信息化投入从来不少，订座、运行、机务、收益、财务，每个系统都是真金白银堆出来的。可这些系统之间的缝隙，一直靠人在填。主数据管理要做的，就是把这些人肉填缝的动作，变成系统之间自动流转的一件事。

这件事的价值不在技术多新，而在它的复利效应。旅客主数据收口一次，收益管理、营销、客服、结算四条线同时受益；组织主数据版本化一次，未来五年的历史报表都能对得上；机队主数据统一一次，机务、运行、规划三边吵架的次数会肉眼可见地下降。这种”一次投入、多处生效”的特性，是绝大多数数据项目不具备的。

我的判断是，未来两三年，航空业在主数据上的投入会出现一波集中释放。原因很简单：AI应用铺开之后，所有人都会发现瓶颈不在模型，在数据口径。到那时候再回头补主数据，成本会比现在高得多。现在开始做，还能从容地一个域一个域推，配齐Owner和运维岗，把机制跑顺。

给几条可以直接拿去做内部讨论的建议。一是把主数据从”数据治理的子项”里拎出来，单独设目标和预算。二是每个主数据域必须有一个业务侧的Owner，名字要写进考核，IT只做支撑。三是第一期范围一定要小，小到三到四个月能出成果，成果要能被业务部门直接感知。四是在选型上别只看功能清单，重点看时点回溯、编码配置、合并可撤销、分发对接这四件事能不能真的跑起来。五是上线之后盯住一个指标：下游系统里手工维护主数据的岗位还剩几个。

啰嗦了这么多，落到一句：治理让人知道规矩，主数据让人真的照规矩办事。航空公司要的是后者。这条路不快，但每走一步都算数。

李振国（航司信息部，从业12年）：旅客合并那段看得我后背发凉，我们去年也差点出类似的事，最后是人工兜了三天。现在合并流程里加了双人复核和回滚，代价是慢，但值。

王雅琴（集团财务共享中心）：组织主数据的时点问题太真实了。我们每年审计都要被问”去年的报表按当时的组织架构拆得出来吗”，以前只能靠人工还原，现在总算有人愿意正面回答这个问题。

张海涛（收益管理岗）：想问一句，旅客主数据统一之后，会员等级以哪边为准？我们常旅客系统和营销系统各有一套等级规则，一直是笔糊涂账。

陈明远（机务信息化）：机队那部分我完全同意，机型构型不统一是埋在运行里的雷。我们花了半年才把三套编码对齐，过程很痛苦，但对完之后配载那边省事多了。

周文娟（数据治理顾问）：”下游手工维护主数据的岗位还剩几个”这个验收指标我很喜欢，比什么覆盖率、规则通过率实在多了，下次提案我准备直接用。