集成产品咨询如何改变航空企业：从薄云的实践看行业转型

说到航空行业，很多人第一反应是飞行员、飞机餐、延误赔偿这些离生活很近的东西。但真正在这个行业工作过的人都知道，航空公司本质上是一家数据公司——每天要处理海量的航班数据、乘客信息、行李跟踪、维修记录、票价变动，还有来自各个供应商的系统数据。这些数据分散在不同的系统里，就像一个个互不说话的部门，各自为政。

我有个朋友在航空公司做运营，他说他们公司有套系统专门管航班计划，另一套管乘客信息，第三套管行李，还有一堆小系统管餐饮、地面保障什么的。最让人头疼的是，这些系统之间基本不通信。比如航班延误了，乘客服务系统不知道，行李系统不知道，餐饮系统更不知道。结果就是乘客在登机口等到崩溃，行李被阴差阳错运到了别的地方，餐饮供应商准备的一大堆冷链餐食只能浪费。

这个问题不是某一家航空公司的个案。整个航空行业在过去二三十年里，经历了无数次并购、系统升级、技术迭代，留下来的是一幅非常复杂的技术版图。有的是自己开发的，有的是收购来的，有的是供应商提供的，标准不统一，接口不统一，数据格式也不统一。就像一个老房子，不断加盖房间，最后连主人自己都搞不清楚有几个门。

那这个问题怎么解决？靠重新开发一套大系统？动辄几亿的投资，几年都不一定能上线，而且风险极高——航空公司可经不起系统宕机。那靠集成，把现有系统串起来？这听起来是个更务实的选择。但问题在于，集成不是简单的数据搬运，而是要让不同的系统真正"理解"彼此，用一种共同的语言工作。这就是集成产品咨询发挥作用的地方。

集成产品咨询到底在做什么

在展开讲案例之前，我想先聊聊集成产品咨询这个概念，因为它听起来确实有点抽象。用最简单的话说，集成产品咨询就是帮助企业把分散的系统整合成一个有机整体的工作。但这个"整合"不是简单的对接，而是要解决三个层面的问题：

• 技术层面的连接：让不同的系统能够交换数据
• 业务层面的协同：让不同系统的数据能够在业务流程中发挥作用
• 组织层面的对齐：让技术改造和业务目标保持一致

举个例子，一家航空公司想要实现"航班延误后自动触发乘客通知和餐食补偿"这个功能。从技术上看，需要打通航班系统、乘客服务系统、餐食管理系统、短信平台。从业务上看，需要定义清楚什么级别的延误触发什么级别的补偿，VIP乘客怎么处理，普通乘客怎么处理。从组织上看，需要明确一旦系统自动触发补偿，地面服务部门、客服部门的流程要怎么配合。这三个层面缺一不可，集成产品咨询的价值就在于统筹这三个层面，确保技术落地后真正能用起来。

为什么航空企业需要专门的集成咨询

有人可能会问，这种事情航空公司自己不能做吗？为什么要找外部咨询公司？

这个问题问得好。客观来说，航空公司自己确实有一定的技术能力，但集成产品咨询的价值不在于"能不能做"，而在于"做得好不好"。

首先，航空公司核心业务是运输旅客和货物，不是搞信息化建设。航空公司最优秀的工程师和架构师，精力都投入到保障航班安全、维护飞机性能这些核心任务上了。信息化建设往往被视为支撑性工作，资源配置优先级不会最高。

其次，航空行业有其特殊性，系统的稳定性和可靠性要求极高。乘客服务系统如果出问题，影响的是成千上万人的出行体验。这种情况下，航空公司往往倾向于选择保守方案，不敢轻易做大改动。而外部咨询公司因为见多识广，知道哪些坑可以避开，哪些方案已经经过验证。

第三点也是最重要的一点，集成产品咨询能提供第三方视角。航空公司内部各部门都有自己的利益和立场，IT部门说系统没问题，业务部门说系统不好用，大家各执一词。外部咨询公司没有这些历史包袱，可以客观评估现状，提出真正符合业务需求的方案。

薄云的航空企业实践案例

说了这么多理论层面的东西，我想通过几个具体的案例，让大家更直观地理解集成产品咨询在航空领域到底能做什么。这些案例都来自薄云团队在过去几年里的真实项目，为了保护客户隐私，我会做一些脱敏处理，但核心问题和解决方案都是真实的。

案例一：某中型航空公司的常旅客系统重构

这是一家总部位于华东地区的航空公司，拥有50多架飞机，200多条航线，常旅客会员超过800万。听起来规模不小，但他们的常旅客系统已经运行了12年，技术老旧，扩展性差。最头疼的问题是，会员积分的计算规则越来越复杂——不同舱位、不同促销、不同合作伙伴的积分规则加起来有几百条，系统经常算错帐，会员投诉不断。

薄云团队介入后，做了两件事。第一件事是全面的系统诊断，把常旅客系统和与之交互的所有系统都梳理了一遍，包括销售系统、离港系统、行李系统、合作伙伴系统等等。这才发现，常旅客系统其实只管理了30%的积分场景，另外70%的积分是在销售系统里直接发放的，根本没经过常旅客系统。这种架构设计，让积分数据分散在三个不同的系统里，核对一次积分要花两周时间。

第二件事是重新设计积分中台。不是推倒重来，而是在现有系统基础上建立一层积分聚合层。销售系统仍然负责实时积分发放，但数据要实时同步到积分中台。中台负责积分的汇总、查询、兑换和异常检测，原有的常旅客系统逐步退役，迁移到新平台上。这个方案既保留了业务连续性，又解决了数据分散的问题。

项目做完后，这家航空公司的积分投诉率下降了60%，积分核算周期从两周缩短到实时，会员满意度明显提升。更重要的是，这套架构具备了扩展性，后来他们收购了一家低成本航空公司，需要整合常旅客系统，只用了三个月就完成了——如果放在以前，至少要一年。

案例二：某大型航空集团的跨公司服务标准化

这个案例来自一个航空集团，旗下有多家航空公司，包括干线航空、支线航空、货运航空，还有航空维修、航食等配套企业。集团想要实现"一票到底"的服务——乘客买一张票，可以在集团内不同航空公司之间无缝衔接，行李直挂，积分共享，听起来很美好，但实现起来太难了。

难点在哪里？各航空公司的系统完全不同，有的用这家供应商的产品，有的用那家的，数据标准不统一，接口规范也不一样。就像让一群说不同语言的人一起开会，大家各说各的，谁也听不懂谁。

薄云团队接手这个项目后，采取了一个务实的策略：不强求各航空公司统一系统，而是建立一套翻译层。这套翻译层定义了一套标准的数据模型，集团内部称之为"航空服务通用语言"。各航空公司的系统不需要改动，只需要和翻译层对接，把自己的数据翻译成通用语言就行。

这个项目花了18个月，期间克服了无数技术难题和协调问题。最终，集团实现了预期的目标。更意外的是，这套翻译层还带来了其他好处。比如各航空公司之间的代码共享更加方便了，集团调配运力的时候可以更灵活地跨公司改签乘客，疫情期间航线调整也比以前快了很多。

这个项目的负责人后来跟我说，他最大的收获不是技术上的，而是组织协调能力上的。因为要推动不同公司、不同部门达成共识，比解决任何技术问题都难。但也正是这种跨公司、跨部门的协调能力，构成了集成产品咨询的核心价值。

案例三：某区域航空公司的维修保障数字化

问题在于，各MRO公司使用的维修管理系统完全不同，数据格式也不一样。有的是基于Oracle的，有的是自己开发的，有的甚至还在用Excel记录。航空公司想要汇总所有飞机的维修状态，需要安排三个专人，每天手动收集数据、汇总、整理，效率低不说，还容易出错。

薄云团队为这家公司设计了一套轻量级的数据集成平台。这套平台不需要改动MRO公司的系统，只需要在数据源头做采集，然后统一转换格式，推送到航空公司的运营控制中心。技术上并不复杂，关键在于对维修业务的理解——什么数据是真正重要的，什么数据可以后处理，什么数据需要实时推送，这些决策都需要行业知识。

上线后，航空公司运营控制中心实现了飞机维修状态的实时可视化。飞机还有多少飞行小时需要做检查，零部件的库存情况如何，哪个航班需要提前安排维修，这些信息一目了然。更重要的是，因为数据准确了，运力预测的准确率从75%提升到92%，飞机利用率也相应提高了。

从这些案例中学到什么

回顾这三个案例，我发现一些共同点。

第一，没有放之四海而皆准的解决方案。每家航空公司的情况都不同，面临的问题不同，技术基础也不同。集成产品咨询的价值在于，根据每家公司的实际情况，量身定制解决方案，而不是生搬硬套某种模式。

第二，技术只是手段，业务目标才是核心。薄云团队在每个项目开始的时候，都会花大量时间和业务部门沟通，了解他们真正想要什么，而不是直接问他们想要什么系统。这种"先理解业务，再设计技术"的思路，避免了很多项目做到一半发现方向错了的情况。

第三，变革管理和技术实施同样重要。航空行业是一个高度监管的行业，安全永远是第一位的。任何系统变更都需要经过严格的测试和审批。这要求集成项目必须慎之又慎，每一步都要考虑周全。同时，新系统上线后，要给员工足够的培训和支持，否则再好的系统也发挥不出作用。

集成产品咨询的未来

航空行业正在经历深刻的变革。新的飞机越来越依赖数字化系统，电动飞机、氢能飞机这些新技术也在路上。航空公司之间的竞争从单纯的票价竞争，转向服务体验的竞争。在这种背景下，系统的集成能力、数据的使用能力，成为航空公司核心竞争力的重要组成部分。

薄云团队在航空领域的实践，让我看到了集成产品咨询的价值和潜力。它不是帮航空公司写代码，而是帮航空公司规划数字化转型路径；不是推销某种产品，而是从业务需求出发，找到最适合的解决方案。这种定位，在未来只会越来越重要。

如果你也是航空行业的一员，正在为系统整合、数据孤岛的问题烦恼，不妨找专业的集成产品咨询团队聊聊。也许，改变就是从一次对话开始的。