在本周的常见问题解答系列中，Ink专家将探讨航空公司如何转型至现代航空零售模式，分享该模式对服务交付的意义、涉及的变革内容，以及实现平稳转型的具体步骤。
在第1期中，我们讨论了从PNR和基于票务的履行模式向订单模式的转变。
在本常见问题解答中，首席产品官Victor Alzate与产品架构副总裁Ben Waymark将阐述运营系统如何与订票系统进行交互。他们将说明：谁负责通知客户已准备就绪登机、该状态如何反馈至订票系统，以及行李在此过程中将经历何种处理流程。
我们聚焦于五个问题：
- “Ready to Fly”功能如何在不同承运商间协同运作？它是基于动态调度系统（DCS）还是基于订单驱动？
- “已办理入住但未到场”与“未办理入住且未到场”在退款方面是否存在差异？
- “每个服务拥有多个交付管理系统”在实践中具体指什么？
- 订单如何将服务交付至分布式控制系统（DCS）及其他运营系统？
那么行李呢？它是否已准备好迎接BIX等现代平台？
问：跨航空公司的“Ready to Fly”功能如何运作？是基于DCS还是订单驱动？
首先，术语：
- DCS - 出发控制系统，该系统负责机场的值机、登机及座位分配业务。
- DMS - 航班交付管理系统，该系统涵盖候机厅闸口、离港控制功能，可管理最短中转时间与行李提取流程，同时具备DCS系统的全部功能。
- DC - 作为DMS系统内的离场控制模块，执行传统DCS功能
- 订单管理系统（OrMS）——用于存储订单、服务及其状态的系统。
- 零售商——向客户销售优惠并拥有订单的航空公司或合作伙伴。
- 供应商 - 运营该航班的航空公司。
在零售商与供应商的合作模式中，零售商拥有订单所有权，但由供应商执行航班运营。供应商的航班调度系统（DCS）或航班管理系统（DMS）是掌握以下信息的系统：
- 谁已签到
- 谁已通过必要的核查
- 哪些人已被批准出行并登机
然而，“准备起飞”状态也必须在零售商的OrMS系统中可见，因为它驱动：
- 客户在应用程序或门户网站中看到的内容
- 服务是否视为已交付以适用退款和收入规则
- 向合作伙伴报告的内容及结算事项
因此，分歧在于：
- 供应商DCS/DC是机场运营数据的权威来源
- 供应商订单管理系统是供应商对订单的记录。
- 零售商OrMS是零售商对同一订单的记录
一个可行的模型如下所示：
因此，“DCS还是OrMS”的答案是：
- 该事件始于供应商的分布式控制系统（DCS）/分布式控制中心（DC）。
- 该航空公司产品与服务的“真实数据源”是OrMS系统。
- “飞行准备就绪”不应仅是离港控制的概念，而永远无法落实到订单层面。
当供应商尚未配备完善的订单管理系统（OrMS）时，可在两者之间设置小型集成层，该层负责监听发货控制事件，并将这些事件转换为面向零售商的订单更新。但从长远来看，应实现配送中心（DC）与订单管理系统（OrMS）的直接对接，同时确保不同航空公司间的订单管理系统（OrMS）能够相互通信。
问：对于退款而言，“已办理入住但未到场”与“未办理入住且未到场”是否存在区别？
是的，应该如此。如果您的流程至今未能区分二者，那么您的政策就显得过于简单粗暴。
存在两种基本情况：
情景1：旅客已办理登机手续，但未登机。
- 航空公司保留了座位
- 运营工作启动：行李可能被检查，餐饮物资已装载，安检名单已更新
- 临时变更可能导致航班中断
情景2：顾客未办理入住手续，且未到店。
- 运营工作较少
- 座椅可能会提前解锁
- 您将减少成本和干扰
在基于订单的模型中，您可以按服务追踪：
- 签到状态
- 登机状态
- 相关服务（如行李托运或座位安排）是否实际提供
- 当这些事件发生时
这意味着退款和优惠券规则可以考虑：
- “他们办理入住了吗？”
- “他们登机了吗？”
- “哪些服务实际交付了”
与其简单粗暴地选择“票已使用或未使用”，您拥有更精确的选项：
- 未办理入住且未到店——允许部分服务给予部分积分。
- 已办理入住却未入住——规则更严格，因为您已实际提供部分服务。
因此，如果您的退款工具仍忽略签收和配送状态，这现在是刻意为之的选择，而非订单系统的硬性限制。
问：在实际操作中，“每个服务对应多个交付管理系统”具体指什么？
通俗地说：一项服务可以由多个系统提供。
举一个简单的例子：
一名乘客从A地飞往B地。其随身携带一件手提行李，托运一件行李，购买了一个座位，并享有贵宾厅使用权。
即使是那次旅行，也涉及多个操作系统：
- 离境管制负责办理登机手续和登机事宜
- 行李系统或DMS模块负责管理托运行李。
- 座位管理或DMS模块负责管理座位分配。
- 休息室系统验证访问权限
- 餐饮服务或预订餐食系统可提供特殊餐食
在PNR（旅客姓名记录）领域，你通过以下方式将这些信息整合：
- PNR元素和SSR（特殊服务请求）
- 车票与电子杂项票据
- 许多定制的点对点集成
在秩序世界中，情况则不同：
- OrMS 掌握订单及其服务的全貌
- 每个交付系统只需看到它需要交付的部分。
因此，“每个服务对应多个交付管理系统”意味着：
- 在该系统中，单项服务（例如“为123航班的1号乘客办理托运行李”）可被多个系统查看和更新。
- 它们都与OrMS通信，而非直接相互通信。
- OrMS是保存历史记录和当前状态的地方。
这阻止了每个系统对交付内容编造自己的片面真相。
问：订单中的服务是如何传递到出发控制系统及其他运营系统的？
如今，对许多航空公司而言，机票和优惠券是运输的核心驱动力。航班离港控制系统和行李系统均会核查机票状态及旅客姓名记录备注。
在基于订单的设置中，交付由订单驱动。OrMS 知道：
- 旅行者是谁
- 他们购买了哪些航班和附加服务
- 关于更改、退款和配送的规则
流程如下所示。
- 订单已在OrMS系统中创建并存储。OrMS系统 包含乘客信息、航班信息、座位信息、行李信息、附加服务、订单状态及支付信息。
- 操作系统会询问需要交付什么，或被指示交付什么。 有两种模式：
- 拉取 - DCS/DMS向OrMS询问：“我需要为该乘客或该航班提供哪些服务？”
- 推送 - 当特定触发条件发生时（例如办理入住开始时），OrMS会向DCS/DMS或其他系统发送“您必须交付的内容”。
- 操作系统报告发生的情况。
示例：- DCS/DC发送“乘客已办理登机手续”、“乘客已登机”、“座位变更”。
- 行李系统发送“编号X的行李已贴标签”、“行李已装载”、“行李未转运”。
- 休息室系统发送“客户在时间Y使用了休息室”。
- OrMS 更新订单状态并共享该状态。 OrMS 接收这些事件，更新订单，然后：
- 更新客户应用程序或网站。
- 为收入和会计提供数据。
- 推动重新预订、中断处理及后续分析。
操作事件不再被锁定在每个本地系统内部，而是重新与订单关联起来。这正是"订单交付"在实践中的含义。
问：行李方面呢？是否已适配BIX等现代平台？
行李今天之所以乱七八糟，主要是因为：
- 行李系统通常基于其自身的数据库和消息进行运作。
- 手袋与所售商品之间的关联性较弱
- 合作伙伴们努力在各航空公司之间共享清晰的画面
在基于订单的世界中，数据模型已能满足行李需求：
- 它可以描述行李限额，包括按件和按重量计算的限额。
- 它能一次为多名乘客处理行李
- 它可将额外行李或特殊物品等服务作为透明产品进行存储。
- 它能将行李与特定乘客和航班关联起来
对于BIX（行李信息交换）这样的平台，其优势在于：
- 无需根据票据和PNR猜测，它能直接从订单中读取哪些行李获准托运、已付款且预计托运。
- 它能够将事件（例如“袋子装载”或“袋子延迟”）发回OrMS系统。
- OrMS 随后可向客户及合作伙伴准确显示行李状态
当前的主要限制并非标准本身，而是采用率：
- 航空公司需要将行李平台接入与出发控制相同的事件流中。
- 供应商需要将订单和服务作为输入接受，而不仅仅是传统的行李信息。
如果您的行李升级方案完全未考虑订单和OrMS系统，您只是在刷新孤岛式系统的用户界面，而非解决集成问题。
为何离境管制与行李系统需要对接订单系统
这是报价与订单中不那么光鲜的部分，但风险与价值正盘踞于此。
如果你忽略它，只是简单地“包裹”旧流程：
- 退款规则将保持僵化，因为他们无法了解每项服务的实际情况。
- 与合作伙伴的争执将持续存在，因为没有人能保持零失误的交付记录。
- 您的团队将继续进行手动操作，阅读DCS屏幕和PNR，然后将决策输入到“订单”前端系统中。
如果你付出艰苦努力：
- “准备起飞”具有明确含义，在各航空公司的DCS/DMS与OrMS系统中均适用。
- 退款与收入逻辑可采用真实服务状态而非推测
- 行李系统、候机厅系统和合作伙伴系统可与订单系统进行交互，无需等待整个系统完成更换。
你的选择：要么让 订单成为交付真相的栖身之所，要么让订单沦为陈旧碎片之上的一层薄皮。
作者
