灣區喝茶故事——航司的數字化困局_風聞
李及李-李及李数据分析公司创始人-数据驱动，分析导向， 为航空和汽车竭尽全力。2021-09-22 09:22
文 | 李瀚明一李及李
除了家旁邊豐富的美食選擇之外，在粵港澳大灣區生活的其中一個好處，就是在我居住的地方兩百公里範圍內的航空公司和機場密度很高，具有廣泛的多樣性。
這一週因緣際會和六家總部設在大灣區的航空公司就數字化這一議題進行了或長或短、或多或少、或線下或線上的溝通。這些溝通圍繞着一個共同的問題——定製化的需求。即使機隊、員工規模差距十倍以上，這些航空公司卻同樣為自身獨特的需求的數字化解決方案而感到苦惱。我們在這裏將舉幾個例子。
# 小型航空公司：誰來滿足我的個性化需求？
灣區有不少在利基市場發展的小型航空公司。以澳門為基地的澳門航空是一個非常典型的例子——每年赴澳門旅遊觀光的各地遊客，足以將澳門航空的航班塞得滿滿當當。
對於內地旅客而言，澳門航空在各地的代表處事實上承擔着「澳門旅遊局代表處」的職權——他們能夠方便地將酒店、購物、飲食、交通等澳門的各項產品介紹給內地各大中城市的消費者，掌握着關鍵的旅客流量。
因此，對銷售部門而言，不斷想出「機票 + 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 表格對此的支持明顯偏弱。換言之，無論是採購自帶接口的第一方軟件，或者使用加載項性質的第三方解決方案，或是自己開發加載項，甲方都需要考慮數據平台和分析平台的兼容性問題。
在權限方面，將集中渠道的數據導入分散的平台的主要問題，在於如何建立流線化的員工賦權體系。集中化數據管理使得數據集中在一個地方，使得權限管理的安全性和員工分析的自由度之間的平衡成為了議題。如果過於強調安全性，則員工分析的自由度受限，員工對集中數據管理的興趣降低，集中數據庫不能充分發揮預期效益；但如果員工分析自由度過大，則會導致可能的數據泄漏問題。
這是擺在大型航空公司面前最大的困擾——業務部門員工的能力和權限，是否能讓他們充分發揮大型數據庫的威力？