文 | 李瀚明一李及李

　　除了家旁边丰富的美食选择之外，在粤港澳大湾区生活的其中一个好处，就是在我居住的地方两百公里范围内的航空公司和机场密度很高，具有广泛的多样性。

　　这一周因缘际会和六家总部设在大湾区的航空公司就数字化这一议题进行了或长或短、或多或少、或线下或线上的沟通。这些沟通围绕着一个共同的问题——定制化的需求。即使机队、员工规模差距十倍以上，这些航空公司却同样为自身独特的需求的数字化解决方案而感到苦恼。我们在这里将举几个例子。

　　# 小型航空公司：谁来满足我的个性化需求？

　　湾区有不少在利基市场发展的小型航空公司。以澳门为基地的澳门航空是一个非常典型的例子——每年赴澳门旅游观光的各地游客，足以将澳门航空的航班塞得满满当当。

　　对于内地旅客而言，澳门航空在各地的代表处事实上承担着「澳门旅游局代表处」的职权——他们能够方便地将酒店、购物、饮食、交通等澳门的各项产品介绍给内地各大中城市的消费者，掌握着关键的旅客流量。

　　因此，对销售部门而言，不断想出「机票 + n」的「金点子」非常重要：酒店、接送机、核酸检测等附加服务在为旅客旅行提供方便的同时，航空公司也能收获辅营收入。

　　但是，「金点子」的顺利实施，需要大量数字化能力的配合，才能顺利传递旅客的需求。例如，倘若将核酸检测纳入机票，就需要设计航空公司、澳门特区/内地政府和核酸检测机构之间的接口，以便传递旅客的姓名、港澳通行证号码和核酸检测结果。

　　可以预见的是，航空公司既然试图承担「生态圈内流量入口」的角色，也就有必要承担设计系统接口的责任——「能力越大，责任越大」。

　　但是，相互合作面临的一个问题是接口开发本身的成本。任何系统都具有成本和折旧周期，而这种接口类的应用，其折旧周期与合作协议密切相关：很难想象一个用于传输核酸检测阴性结果的接口可以编列十年的折旧周期；而当和酒店的合作停止的时候，和酒店的接口也就自然失去了价值。

　　因此，小型航空公司的业务需求现在被高额的固定成本严重制约。从身为旁观者的我的角度来看，as a Service（服务化）是其中一种解决方案：通过服务化将固定成本转为可以随业绩变化的浮动成本的想法，对这样的公司想必非常有吸引力。

　　但是，aaS 类的一个大前提，是这项东西的通用性。一般而言，

　　IaaS（基础架构 Infrastructure 等计算能力）最方便被服务化：例如现在流行的云主机，就降低了机房、服务器等的硬件成本；

　　PaaS（例如数据库、可视化工具之类的平台 Platform 工具）次之：数据库等也可以在云上运行，降低安装、配置、安防的成本；

　　SaaS（软件 Software 等应用程序）最难被服务化：现在被服务化的还在电子邮件、即时通信和 ERP 等各行各业都会用到的高度通用的软件上。

　　但是，这种接口不属于以上任何一类——它不是通用软件。因此，我们必须将需求进行一定程度的抽象，使得它具备复用的条件。例如，一个可以复用的典型接口，是旅客的身份信息——酒店和核酸检测等多个地方都要使用。通过平台抽象业务核心接口，使得航空公司可以和合作伙伴一起共担接口设计的成本。

　　换言之，一个给辅营提供商提供接口的「开放平台」是有必要的。但这也是目前的最大难题——谁愿意帮助设计这样的「开放平台」？

　　选择事实上不多。一方面，解决方案提供商不一定会配合「服务化」设想；而另一方面，互联网公司的 B2B 部门，面临来自 B2C 部门的压力——机加酒这样的业务，我为什么不自己做呢？

　　需要进行的一个工作是和业务合作伙伴的沟通——包括酒店这样的合作伙伴，必须以适当的形式参与到接口设计的过程中并共同承担成本。换言之，航空公司必须承担协调者的角色，平衡合作伙伴的需求。

　　# 中型航空公司：怎么将分散的需求集合化？

　　深圳航空是典型的中型航空公司。与小型航空公司相比，它们更大的规模使得一些问题开始浮现出来。

　　在小型航空公司的层面，较小的组织架构使得业务部门之间可以相对快捷地沟通，从而实现数据交流。但在中型航空公司的层面，以公司为级别架设一个数据库存在许多问题——例如成本、可靠性等诸多因素。因此，很多中型航空公司的数据库，以部门为级别架设，形成了许多「数据孤岛」。

　　这种做法并没有致命的问题——业务部门内部的数据交流需求，远大于业务部门之间的数据交流需求。因此，在大多数情况下，这种方法「能用」。但在复杂分析的场合，这一做法就会力不从心。

　　假设有一位领导希望统计分析「航班延误和旅客退票之间的因果关系」或者「航班延误和耗油之间的相关性」，在这些中型航空公司的数据孤岛中可能非常麻烦。他需要以航班号和日期为索引字段，逐一在销售部门的数据库（记录有销售退票数据）和运行部门的数据库（记录有航班延误数据）以及机务部门的数据库（记录有飞机航油消耗数据）之间来回匹配。这种做法显然是低效的，制约了业务部门的业务开展。

　　因此，在这些航空公司的数字化征程中，数据统合会是重中之重。但是，对既有系统进行数据统合并不容易。数据统合工作的其中一个关键点，是形成自身的数据标准——例如数据的保存格式、基础字段的定义、授权机制、存储要求等。

　　之所以要制定数据规范和标准，是因为这是航空公司在 IT 实践中摆脱「路径依赖」，从「乙方主导的被动」向「甲方主导的主动」的关键节点。在这一阶段，供各内部部门和各外部合作伙伴共同遵循的基础性的规范和标准，能够避免与单一 IT 供应商的强绑定，保持 IT 系统的互换性。

　　但是这对中型航空公司的数字化而言是一次不小的考验和挑战。

　　其中一个挑战是既有的信息化应用需要在数字化转型期间进行数据迁移——对于那些尚未达到折旧期的应用，可能还需要持续使用。因此，可以看到不少航空公司的数字化转型实践，是从 IaaS 或者 PaaS 级别开始的：这一点的典型案例是从自建 Oracle 数据库转向 RedShift for Oracle 等 PaaS 解决方案的流程。尽管有将民航软件 SaaS 化的尝试，但是「境内保存」、「竞争对手数据隔离」两大挑战，使得民航软件 SaaS 化的性价比并不高。

　　同时，在数据迁移期间进行数据规范化会导致错误溯源归因工作复杂化，使得工程师需要妥善而小心地处理数据。因此，在数字化工作的开头，对公司既有系统和数据进行梳理是非常有必要的——这有利于制定转型蓝图，明确哪些系统内的数据格式可以原样迁移，哪些系统的数据格式需要进行形式转换（例如枚举类数据的独热 One-Hot 化），哪些系统将在折旧后自然退役，对数据进行一次性转换后迁入新系统。

　　第三个挑战则是不同供应商之间的互操作性。这是航空公司业务复杂化带来的对系统的要求。例如，票务系统和运行系统之间的自动化互操作性，一方面可以帮助人员高效完成数据分析任务，一方面也能在动态定价等自动化业务系统中发挥巨大作用。

　　这种互操作性应该体现在「接口」层面而非「数据表」层面。一方面，数据表内的原始数据对于其它业务线的人来说如同天书，需要各业务线在内部加以初步分析、总结加工后，通过接口提供更容易为其它业务线理解的信息；另一方面，数据表开放本身也具有信息安全风险，权限管理功能不如接口层面开放容易、细致。

　　以上的这些工作，毫无疑问需要甲方、既有业务系统的供应商和数字化转型供应商三方之间的密切合作。如果没有甲方的参与，则「路径依赖」会继续持续；如果没有既有业务系统的供应商参与，则系统无法顺利迁移，无法享受到数字化的好处；如果没有转型供应商的参与，则工作成果难以在转型过程中具体落地。

　　# 大型航空公司：如何为员工进行赋权赋能？

　　在南航和国泰这样的大型航空公司上，问题进一步复杂化。

​　　大型航空公司更大的规模使得它们有足够的财力自行开发或采购大型数字化系统，并维护一个专职团队用于 IT 系统。在这类公司中，数据一般在公司级别的数据库和部门级别的数据库双重存储，因此业务部门在理论上具备了访问其它部门数据的条件。

　　但是，这些公司面临着一个更现实的问题——公司级别的数据库（及其配套的计算能力平台），是否与员工的数字能力相互匹配。公司级别的数据库可能在亚马逊 AWS（国泰 2017 年导入）或者阿里云（南航 2017 年导入）之上打造，具有 SageMaker、PAI 之类的的高度先进的计算功能；但是，业务部门的员工，却可能还在使用 Microsoft Excel 或者 WPS 表格等电子表格软件——对他们而言，Python 或者Tableau 已经是很厉害的工具了。

　　虽然 SageMaker 和 PAI 很好，但是这些玩意儿对日常员工而言还是太难了。正如他们的定义所言：这些工具是针对「数据科学家」、「开发者」打造的——顾名思义，并不是针对业务部门设计的工具。

　　Amazon SageMaker 通过整合专门为 ML 构建的广泛功能集，帮助数据科学家和开发人员快速准备、构建、训练和部署高质量的机器学习 (ML) 模型。

　　阿里云机器学习 PAI 面向企业及开发者，提供轻量化、高性价比的云原生机器学习平台。

　　因此，业务部门都希望尝试体验神器。但正如 IT 工程师一般不知道如何操纵航空器一样，飞行员等业务人员一般也不知道如何使用这样复杂的系统。因此，他们需要通过 IT 部门这一「内部乙方」，才能在神器上实现他们的业务需求——毕竟 IT 部门是航空公司内部对机器学习平台相对了解的人，「能力越大，责任越大」嘛。

　　但是，神器本身始终只是工具——顺利解决销售运行、飞行乘务、机务航材……等业务部门的需求，一方面需要高度的技术能力，一方面还要准确寻找、定位业务数据点。对 IT 部门的人而言，寻找业务、了解业务、分析业务的难度并不低。

　　雪片般飞向 IT 部门的需求一方面使得 IT 部门压力上升疲于奔命，另一方面业务部门也受累于长排期带来的进度落后。因此，业务部门仍然喜欢在部门数据库上进行数据分析。

　　像 Excel 这样的软件虽然功能可能不如神器，但它能够像「游乐场」一样使用，不会给用户带来压力的特点，显然能够帮助业务人员的灵感即时落地，并最终加入业务流程。部门级数据分析软件的另一个好处是分散化的执行环境——相对于集中式环境下数据分析任务需要等待资源不同，分散化的执行环境能够充分利用个人电脑的计算能力执行常见的简单数据分析任务。

　　因此，可以看到的是大型航空公司仍然需要采购包括 SAS、SPSS 和 Tableau 在内的成熟软件。在这样的背景下，对大型航空公司而言，保持适当的软件梯度和分工十分重要：在有了大型集中环境以后，能否通过包括插件、库等各种形式，使得业务员工习惯使用的数据分析软件能够充分使用集中环境内的海量数据，将是大型企业能否充分发挥集中环境数据存储和计算能力优势的要点。

　　这一要点可以分为两个部分：「能力」和「权限」。

　　在能力方面，分析软件是否提供接口是关键。例如，Microsoft Excel 支持从 Teradata、SQL Server、Oracle、Hadoop HDFS 等各种各样的渠道导入数据，但是 WPS 表格对此的支持明显偏弱。换言之，无论是采购自带接口的第一方软件，或者使用加载项性质的第三方解决方案，或是自己开发加载项，甲方都需要考虑数据平台和分析平台的兼容性问题。

　　在权限方面，将集中渠道的数据导入分散的平台的主要问题，在于如何建立流线化的员工赋权体系。集中化数据管理使得数据集中在一个地方，使得权限管理的安全性和员工分析的自由度之间的平衡成为了议题。如果过于强调安全性，则员工分析的自由度受限，员工对集中数据管理的兴趣降低，集中数据库不能充分发挥预期效益；但如果员工分析自由度过大，则会导致可能的数据泄漏问题。

　　这是摆在大型航空公司面前最大的困扰——业务部门员工的能力和权限，是否能让他们充分发挥大型数据库的威力？

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