云上的星星：航空公司 IT 的 SaaS 化

文丨李瀚明

年前和多家既有客户就过去的事情、现在的事情和未来的事情进行了深入、坦诚的沟通交流。仔细想想这些公司过去三年又和我们合作做了一些事情，因此我们也将一些经验向国内的同行进行介绍。

在过去的几年中，我们和 Amazon Web Services 和 Tata Consultancy Services 合作，为我们的客户构建数字基础架构。这种架构的主要目的是帮助各社降低成本，并减少对单一节点的依赖。

我们首先将内容放在了共通服务上。作为天天和飞机打交道的航空公司，无论其所在的国家如何，其商业模式和日常工作使用的工具链是大体相通的。读者倘若有心就可以发现，航空公司每天使用的一部分工具，其实可以 SaaS（Software as a Service）化——它们属于标准化的业务，对具体的航空公司的依赖程度低，在不同航空公司之间的迁移性强。

例如，飞行计划的制定是典型的 SaaS 化业务。飞行计划制定通常和具体航空公司无关——只需要输入机型及其性能要求（如 ETOPS）、天气情况（例如风向、风力）、航路情况（例如 NOTAM），大部分航空公司就能够得到令人满意的飞行计划及负载要求。因此，飞行计划制定是一个典型的可以SaaS化的软件。

SaaS 化带来的好处是显而易见的——无论是对于大型公司还是小型公司而言。对于大型航空公司而言，定价模式从既往的“按设备数”变成“按计划制定次数”，使得航空公司可以降低在软件上的固定资产投资；同时，由于购买模式从“投资设备”改为了“购买服务”，航空公司也可以享受软件开发商进行的软件更新带来的效率提升。而对于中小航司和公务机等小规模用户而言，它的最大优势则在于不用再为飞行计划系统软硬件的维护投入人力——SaaS 服务提供商会做好这一工作；当然，“用多少付多少”也使得每年费用明确化。

除了飞行计划软件以外，配载算法、排班软件等也是典型的可以 SaaS 化的业务软件。SaaS 化的另外一个特点，是软件的更新是无缝的——软件用户可以及时获得最新功能，而无需为更新软件而烦恼。同时，SaaS 往往也实现了 MVC 分离——航空公司可以通过 API 这一软件公司制定的控制协议（Controller）和飞行计划等模型（Model）进行自动化的交互（例如在夜间自动化地为大量航班生成飞行计划、配载和排班），而无需人工通过视图（View）参与。

当然，其它算法也可以被 SaaS 化——只要它们解决的是行业内具有标准性的问题。机票的税费计算是一个非常典型的场景：不同航空公司对税费没有影响。因此，各航空公司完全可以将税费计算交由服务提供商实施。

SaaS 化也使得一些模式成为可能——例如在行业内具有较多共性的客户服务。现在我们在我们的客户上导入了 CSaaS（客户服务即服务）的选择：航空公司等客户可以事先制定作业标准流程（或使用行业级的作业标准流程——如在航班延误时建议备选航班），之后无论是传统人工客服还是AI客服，都可以使用标准流程为不同的企业服务。

SaaS 化同时也方便企业聚集足够大的规模，从而实现由传统流程向AI流程的转型。刚刚所说的飞行计划、客户服务等，都是一个典型的例子——如果没有足够大的预期，企业就无法融到足够的资金；而如果没有足够规模的资金，研发投入就无从谈起。因此，SaaS 化几乎是 AI 企业的共通特征——从阿里云、腾讯云等大厂到商汤、云从等具体公司，都有规模不小的 AIaaS 业务。

我们另外一个正在进行的工作主要围绕 IoT（Internet of Things 物联网）进行。航空公司在其生产经营场所具有大量设备（从自助值机设备到行李车等），这些设备所构建的传感器和效应器网络也需要通过合适的方法加以处理，从而形成自动化的协作工作流。

“派单”是一个典型的 IoT 需求。为了让机场内部特种车辆能够执行合理的任务，我们需要一个任务分配系统。这一任务分配系统一旦开发成功，就会是全国所有机场共同的需求。因此，“特种车辆等 IoT 设备的管理”，也是一个典型的可以 SaaS 化的应用。

因此，我们和合作伙伴向客户们提交的方案，本质上是要依托星空联盟这一客户联盟，通过充分抽取共通服务实现 SaaS 化来改善客户们的成本架构。

对于国内的民航企业而言，SaaS 化还有另外一重意义——分摊信创国产化的巨大成本。某种意义上而言，国内各航空公司和机场之前使用的系统属于“搭便车”——外国企业已经负担了一部分研发成本，因此国内航司使用系统时，可以以较低的成本获得系统。但是，当启动信创国产化替代时，航空公司就会发现自己需要从头开始研发系统——正如当年 AA 孵化 Sabre 一样。

因此，在中国民航的研发工作中，以 SaaS 为代表的模式是必须要做的——航信本身就是一个最好的例子。航信很大程度上完成了销售、分销领域的数字化，但是它缺乏在运行等专属于航空公司本身的管理上的业务经验，因此无法完成这个任务。

事实上，大部分单纯的乙方都缺乏业务经验。笔者曾经和国内某“大厂”（之所以这里扩起引号，是因为对方实际上并无此行业的实绩）的工作人员就“民航领域的最佳实践”打过交道，发现对方的职员完全对民航业务一无所知，甚至连民航行业的术语都听不明白。Tata Consultancy Services 在这一方面和国内大厂面临着类似的问题——熟悉民航业务的专家实在太难找，而不熟悉民航业务的新手做出来的系统，民航一线用起来又不顺手。

这就是为什么航空公司会成立 Lufthansa Systems 或者 ANA Systems 这样的 IT 子公司——这种公司的作用在于积累一批既熟悉业务，又熟悉技术的综合性人才，避免不稳定雇佣（例如频繁切换乙方）带来的效率损失。因此，国内三大航的IT部门改制为独立子公司实在是大势所趋——看不到任何不做此类改动的理由。

但是，航空公司内部的 IT 子公司必然面临一个机会。服务一家公司也是服务，服务多家公司也是服务——分摊的公司越多，摊派下来每家企业负担的研发成本就越低（这对于国产化而言至关重要）。因此，无论是股东的要求也好，还是管理者的主动动力也好，内部IT子公司对外服务也是航空公司IT转型的一个必然。因此，我们可以看到南航去竞标青岛航的系统这样的做法。

不过，竞标做项目这个方法也有很多问题。由于每个项目的个性化程度都很高，乙方往往需要同时维护相同系统的多个版本。SaaS 化的另外一个好处就在这里——软件供应商可以及时释出软件更新，既降低软件的维护成本，也能够令客户及时享受性能提升和功能改进。

AWS 某种程度上是这种公司内部业务 SaaS 化的典型案例——对于亚马逊而言，管理一台服务器也是管理，管理二十台也是管理，因此公司内部的 IT 子公司确实可以对外服务；而亚马逊对外服务的最好方式，就是采用 IaaS 的形式，将基础设施（如 S3 存储、EC2 计算等），以服务的标准化形式提供给外部企业。当然，AWS 也顺利完成了从原先提供基础设施到如今提供 AI 能力的转变——SageMaker 就是一个典型的例子。

星空联盟和 AWS 和 TCS 的合作就是采用类似的合作模式——通过将大型航空公司内部的系统改进后上云，一方面联盟内的小型航空公司也能享受到类似的好处，另一方面各航司事实上达成了共同研发的体制，分摊了系统研发的成本。这种模式有点类似于智猪博弈——但有所不同的是，SaaS 机制确保了“小猪”也需要为服务的使用而付出相应的对价，从而提升了“大猪”的积极性。

最后让我们回到中国。信创国产化对于国内航司而言是一个 IT 系统的巨大变革。但是信创国产化所伴随的巨大的研发成本，必然需要合适的方式在各民航单位间分摊。因此，中国航司的 IT 部门必然需要经历一次商业模式的变革，才能找到适合未来的发展方向。

点击【李及李】阅读更多相关信息