航空公司视角：NDC到底要做什么

二、NDC解决方案

航空公司系统的核心是PSS（Passenger Service System，旅客服务系统），问题的关键是如何通过NDC来增强PSS。

IATA提供了两种解决方案：

方案一：将NDC集成到PSS本身

大多数航司的PSS托管于Amadeus、Sabre、Travelport、Travelsky四家，航空公司如果想通过方案一来实现NDC，取决于这几家公司是否愿意去改动PSS系统，然而PSS系统庞大，承担职责也非常重要，任何一家公司都不会轻易的改动PSS。因此通过直接集成到PSS的方式实现NDC难度较大。

方案二：在PSS前端插入一个专门为NDC设计的集成层

方案二是在PSS前插入一个集成层，通过集成层连接不同的功能模块。方案二是一个独立于PSS的解决方案，可以更简单、更快速的部署NDC，更适用于大多数航司。

三、NDC参考架构解析

上图为IATA给出的NDC参考架构图，笔者认为可以从两个方面来理解这张架构图：

（一）根据NDC的各种角色，将架构图拆分为三个部分。

NDC的主要角色有Seller、Aggregator和Airline，对应的将架构图拆分为三个部分，简单介绍一下每个角色的职责：

·Seller（卖家）：根据客户的查询要求，直接向航空公司或者聚合商发起offer请求，在客户确认offer后，卖家还负责发起Order生成、支付以及后续的退改签等。卖家可以是代理人、OTA、TMC或者联运伙伴等。

·Aggregator（聚合商）：Aggregator上游对接各航空公司的搜索与预订NDC API，下游对接卖家。卖家通过Aggregator向各航司发起和接收查询、预订、支付、出票等信息，Aggregator在销售链条中起到了内容聚合和信息传递的作用，Aggregator可以由第三方承担或者卖家内部的部门承担。从长远来看，Aggregator将取代目前的GDS的角色，所以各大GDS也在做Aggregator的转型。

那么，既然航司可以通过NDC API直连卖家，为什么还需要Aggregator？

笔者认为Aggregator的存在主要有两方面的意义：

一是各家航司和各代理人只需与Aggregator通过一次对接，即可完成多对多互联互通，可以助力航司和代理人快速实现NDC规模销售和服务；

二是Aggregator负责不同NDC版本的“翻译”工作。

IATA每年3月和9月都会推出新版的NDC标准，面对这么多版本，各家航司无法实时更新每个新版本，不同的版本之间也无法相互兼容，这就造成了卖家需要进行不同版本的对接开发。这时，Aggregator就起到了重要的作用，Aggregator可以将各家航司不同版本的NDC API进行集成，但输入给卖家时，“翻译”成为统一的、更新的版本，从而使卖家获得更好的体验。

·Airline（航空公司）：航空公司无疑是NDC模型中最重要的角色，也是最受益的角色。航司的主要职责是Offer和Order管理，与传统分销模式相比，航空公司取代GDS承担offer的构建职责，航空公司可以根据用户的请求实时构建offer，offer的内容主要包括行程、运价规则、是否包含附加产品等，最终为客户提供一个或者多个offer。Order管理主要包括支付过程处理、出票、退改签售后服务等。通过实施NDC，航空公司将真正掌握分销的话语权，即卖什么产品、怎么卖均由航司控制，而不再是GDS。

（二）重点看航空公司的角色，了解航司OOMS架构

这张架构图中最大的部分是航空公司的角色，其实是提供了航司OOMS（Offer&Order Management System）的参考架构，个人理解航空公司的OOMS架构可以分为四层来看：

底层模块：航司NDC的建设往往是从已有底层模块基础上进行封装，这些底层模块主要包括Payment（支付平台）、CRM（客户关系管理）、Miscellaneous（附加产品）等。

集成层：如IATA的NDC解决方案二，在PSS前端插入一个专门为NDC设计的集成层。

核心模块：最核心的模块是Offer Management和Order Management，而Rich Media（富媒体）、Pricing（定价）、Airline Profile（航空公司配置平台）等模块都可以增强Offer的能力。其中，Pricing区别于现有的运价系统，更多的应该是基于CRM和数据分析所做的个性化定价或者动态定价。Airline Profile主要用于航司Offer请求的接收管理，即接收航司能响应的、有效的Offer请求，避免处理无效请求造成的处理能力和响应时间的浪费；而在联运销售时，Airline Profile也可承担联运Offer的分发与接收规则管理。

渠道层：集成了底层模块和核心模块的功能后，构建NDC XML API或者网站的方式输出。API的管理需要API Gateway（API网关），用于API接入管理、监控、权限控制等。

四、航空公司在做什么

上图为NDC标准17.2的一个参考用例，去掉中间“聚合商”层同样成立。其中，AirShoppingRQ/RS、OfferPriceRQ/RS等为IATA发布NDC标准的消息对。

目前，比较成熟的方案是，航空公司基于已有的功能模块和业务流程构建NDC标准的XML API，然后将NDC XML API提供给卖家或Aggregator使用。API的提供方式主要有：

1）自建API Portal（API门户），航司通过API Portal发布API，也可以提供开发辅助工具、测试系统、工单系统等，卖家可以自助申请API接入。英航、阿联酋航空、澳洲航空、法荷航等国外航司均采用此种方式，南航6月份发布的《NDC合作指南》也是这种方式。

2）接入Aggregator，由Aggregator负责集成开发，并提供网站或者API给卖家使用。这种方式对于IT技术、渠道获取能力相对较弱的航司来说可以较快的实现NDC部署。

也许有人会说，NDC标准无非也就是一套通过API交换XML信息的标准，仅需要将现有的接口封装为NDC XML API即可。

其实不然，虽然现阶段各航司的NDC API大多仅包含机票业务流程构建，但实际上通过NDC，航空公司既可以销售更多产品（包括行李、选座、餐食的航空附加产品；酒店、租车等非航产品），更可以实现航司多年以来动态打包、千人千面、差异化定价等想法。构建NDC API仅仅是一个开始，NDC的下半场必然是Offer能力的竞争，是基于NDC架构下的产品打包组合、动态定价、富媒体展示等个性化Offer的竞争。因此，NDC领先的系统架构和“零售”理念更值得航空公司关注。航空公司如果不从内部扩展架构，如何来踢“下半场”？

对于电商系统尚不完善的航空公司来讲，NDC提供了一个很好的追赶契机。首先，NDC提供了一套领先的、模块化的Schema（架构），航司可以参照其架构并结合自身情况全面规划建设自己的电商系统。同时，NDC也带来了全新Retail（零售）的理念，通过实施NDC，航司可以对自身的业务进行梳理，将业务理念与IT建设相结合，实现航司新零售的商业价值，这或许才是NDC更为重要的意义。（全文完）

更多NDC与One order文章请查看公众号菜单。

· 专业原创行业分析文章、行业热点评论、知识分享文章

· 独家原创文集返回搜狐，查看更多