.webp)
在本期中，本·韦马克深入探讨了基于订单的交付模式中的关键难题：如何管理服务生命周期状态、解决系统间冲突、在不依赖PNR时代队列的情况下处理中断事件，以及在混合航空环境中实现首日运营所需的条件。
在本系列服务交付常见问题解答的前三期中，我们探讨了从基于PNR的运营向基于订单的服务交付的转变，阐释了"订单驱动交付"的实际意义及其相较传统模式的优势。我们分析了航空公司如何在保留传统PSS系统的情况下启动转型，"就绪状态"如何从DCS流转至订单系统，以及服务如何传递至运营系统。 我们深入剖析了行李处理、临时联运、购票流程中的富媒体应用，以及航空公司已获得的实际效益——从提升客户服务质量到实现实时可视化管理，再到加速附加服务销售。同时探讨了航空公司在跨航线联程旅程中如何管理服务交付状态，确保各航司视图一致性，而无需直接系统集成。
现在我们正着手解决更棘手的问题：当事情出错时，如何保持掌控？当系统出现分歧时，如何定义真相？以及从第一天起，真正实现以秩序为导向的交付需要什么？
每个订单项的交付生命周期是什么，以及哪些状态转换是不可协商的？
每个订单项都包含一项服务（航班、座位、行李、餐食等），该服务遵循既定的交付生命周期。该生命周期通过订单管理系统（OMS）、交付管理系统（DMS）——出发控制系统（DCS）是DMS的功能模块——以及交付供应商之间交换的状态更新进行追踪。 我们需要建立一个涵盖所有关键阶段的实用状态模型——包括：办理登机手续、登机完成、交付完成、交付失败、替代服务、退款处理、补偿处理及部分履行。
目前，国际航空运输协会对此尚未作出明确定义，但理想情况下，我们需要朝着类似以下方向推进：
创建：该订单中的权益已保留，但尚未交付。
准备就绪：客户有资格使用该服务（例如，他们可以办理入住或寄存行李）。
已办理登机手续：出发控制台确认登机手续已完成。座位已分配，行李已接收，等等。
登机：乘客 实际登机，服务（如航班）开始。
已完成：服务已提供。乘客已抵达，行李已运送，餐食已供应。
配送失败：服务未能完成（例如：未到场、技术问题、包裹被拒收）。
替换：原定服务被其他服务替代（例如：更换座位类型、改签航班）。
退款：未交付 的服务已取消并退款。
补偿：服务故障时将给予金钱或服务形式的补偿。
部分完成： 服务已交付部分内容 （例如：行程部分完成，或两个行李箱中仅装载了一个）。
这些状态转换应体现在ServiceStatusChangeNotif消息中，并记录在订单的审计轨迹中。该模型支持丰富的故障处理机制，无需通过重新签发凭证来实现。
当配送、订单管理和合作伙伴意见相左时，真相归谁所有？
当涉及多个系统时，冲突在所难免。因此我们需要明确：哪些事件源自哪个系统、冲突如何解决、审计记录呈现何种形态。
在订单主导的模式中：
- OMS是权益及其状态的记录系统。它确定了哪些权益已被提供、确认、取消、替换或退款。
- DMS/离港控制系统会触发诸如值机、登机和装载状态等运营事件。这些事件通过ServiceStatusChangeNotif进行反馈。
- 运输服务商（如地面服务商）也会提供状态更新，例如：贵宾室使用权限已交付或行李重量已确认。
- 配送管理系统（DMS）将提供出发控制功能，并同步显示这些配送服务商的状态。
冲突解决遵循以下层次结构：
- 若某项服务在OMS中未标记为已交付，则无论出发控制系统（DC/DCS）日志如何显示，该服务均视为未交付。
- 如果OMS从可信来源（域控制器或合作伙伴）接收到了状态更新，该更新即成为权威事实。
- 差异将被记录并标记，以便通过人工或自动工作流进行处理。
审计记录集中存储于订单系统中，包含所有状态更新信息，涵盖源系统、时间戳及事件详情。这确保了完整的可追溯性与争议管理能力。
在无PNR时代队列的订单驱动交付模式中，中断管理如何运作？
让我们通过一个完整的端到端场景，来了解实际操作中的运作流程。我们将涵盖行李问题导致的误接航班、重新安排住宿、座位重新分配、附加服务延续以及客户通知等环节，并追踪每个步骤中的更新情况。
- 误接：乘客 迟到导致错过转机航班。DC向OMS 发送ServiceStatusChangeNotif 通知：航班未登机。
- 重新安排：OMS 通过OrderReshop触发重新预订流程，提供新的航线选项。客户选择新的航班。
- 座位重新分配： 新座位 属于重新安排方案的一部分，并将通过订单变更在订单中更新。
- 附加项目结转：有效的附加项目（如预付餐食）将根据映射逻辑进行重新分配或退款。
- 行李：该行李 已装载至原定航班。行李追踪系统更新了OMS系统，该系统随即标记出不匹配情况。
- 客户消息推送：OMS 通过推送通知或客服工作流发起消息，发送新的行程安排及更新信息。
- 补偿（如需）：若客户降级或取消服务，订单变更或报价单将反映相应调整，并发放退款或代金券。
所有更新均实时反映在订单中。票务、预订或库存系统之间无需排队或手动同步。
如何在不重新创建票证和电子机票的情况下处理部分交付、服务替代及补偿事宜？
关键问题在于如何在订单中直接体现履行、失败和补救措施，而避免以其他名称创建新凭证。
无需重新创建票证或电子票证。订单记录将处理所有事宜：
- 部分交付：每项 订单商品均有独立的交付状态。若行程部分段落采用航空运输，或服务仅被部分使用，则会分别记录。
- 替换：该 指令显示被替换的服务及其替代方案。例如：12A座位替换为14C座位，若价值存在差异则予以退款。
- 补偿：以新订单项目（如代金券）、已付总额调整或附加于订单的价值存储的形式体现。
所有事件均通过状态更新（ServiceStatusChangeNotif）、审计记录条目及适用的订单变更操作进行日志记录。退款、罚款或善意补偿直接嵌入订单中，无需创建重复的工件。
在混合型航空公司中实施订单驱动交付所需的最低集成和控制措施有哪些？
对于采用混合模式运营的航空公司（前端基于订单处理，后端保留传统系统），需定义最小可行接口与控制集。这包括事件采集、权限验证、异常处理以及共享的"飞行就绪"语义。
具体效果如下：
事件采集：您的OMS系统 必须通过 ServiceStatusChangeNotif接口接收来自DCS、行李系统、贵宾室、餐饮服务及值机系统的事件 。
权限验证：交付 系统需要查询OMS（或接收推送的ServiceDeliveryNotif消息 ）来验证应交付的内容。
异常处理：您的 订单管理系统（OMS）应处理错误响应和冲突标记（例如当包裹已送达但订单已被取消时）。
共享的"即飞"语义：所有交付系统必须 统一采用订单驱动的"签入"、"登机"和"交付"定义。
回退流程：您 需要能够通过代理工具手动记录或覆盖状态，同时保持订单审计的完整性。
此架构使您能够在现有基础设施上支持NDC和ONE订单履行，同时逐步摆脱对PSS的依赖。
作者
