Тема NDC активно обсуждается представителями тревел-индустрии уже несколько лет. Переход на единый стандарт, предложенный IATA еще в 2012-м, ознаменует «новую эру в дистрибуции авиауслуг», «оптимизирует продажу дополнительных сервисов авиакомпаний», позволит «воплотить персонализацию в жизнь», «улучшить опыт путешественника», NDC — «настоящая революция в авиационной отрасли», говорят игроки рынка. Так ли это на самом деле? Грач Мурадян, руководитель Группы внедрения программных решений Amadeus Россия, уже 25 лет работает в области технологий дистрибуции и продажи авиауслуг. И как эксперт в сфере IT рассматривает переход на NDC c практической стороны, то есть прежде всего — функционально
Тема NDC активно обсуждается представителями тревел-индустрии уже несколько лет. Переход на единый стандарт, предложенный IATA еще в 2012-м, ознаменует «новую эру в дистрибуции авиауслуг», «оптимизирует продажу дополнительных сервисов авиакомпаний», позволит «воплотить персонализацию в жизнь», «улучшить опыт путешественника», NDC — «шаг вперед», «настоящая революция в авиационной отрасли», «своего рода трехмерный конструктор, который дает возможность выбора», говорят игроки рынка. Так ли это на самом деле?
Грач Мурадян, руководитель Группы внедрения программных решений Amadeus Россия, уже 25 лет работает в области технологий дистрибуции и продажи авиауслуг. Сначала был на стороне авиаперевозчиков, позже — компаний-провайдеров PSS / GDS. За этот период он видел много изменений, которые происходили в отрасли. И как эксперт в сфере IT рассматривает переход на NDC c практической стороны, то есть прежде всего — функционально.
— Грач, что же такое NDC c технической точки зрения? И как переход на единый стандарт отразится или уже отражается на рынке?
— Функционально NDC — еще один из множества существующих форматов передачи данных, позволяющих отправить запрос — получить ответ. И к бизнес-процессу продажи авиауслуг, онлайн или офлайн, он имеет отношение не более, чем другие протоколы, используемые для межсерверного или терминального обмена данными!
Этот бизнес-процесс состоит из нескольких этапов. Первый — поиск вариантов перелета. Его можно осуществлять двумя способами: отталкиваясь от самого дешевого тарифа на заданные даты (диапазона) либо от расписания. По второму пути, как правило, идут корпоративные клиенты: да, у сотрудника есть ограничения по тревел-политике — скажем, рейс длительностью до четырех часов бронировать в экономическом классе, но выбирать самый дешевый билет ему необязательно, ведь главное — попасть на запланированную встречу. Возможна и комбинация этих методов.
Затем следуют процедуры бронирования и покупки самой услуги — внесение данных пассажира (через оператора или веб-сервисы), расчета тарифа (плюс таксы, сборы...), оплаты, тикетинга (хотя некоторые бюджетные авиакомпании перешли на технологию ticketless, отказались от создания записи об электронном билете на отдельном сервере) и другие, такие как продажа дополнительных сервисов или внесение изменений.
Каковы бы ни были средства реализации, сам бизнес-процесс продажи авиауслуг сохраняется. Встает вопрос о том, как именно мы его осуществляем технологически.
В случае традиционного подхода для онлайна каждый агрегатор создавал свой собственный API (Application Programming Interface). Речь идет, в частности, о веб-сервисах, включая средства управления ресурсами и продажами, системы DCS — Departure Control регистрации авиакомпании и многое другое. Они дают возможность отправить запрос в определенном формате и получить ответ. И у GDS, как и у авиакомпаний, API не стандартизированы и отличаются по структуре — хотя и передают весьма схожий контент. Поэтому агентству приходится адаптировать движок сайта под запросы разных агрегаторов, на базе которых оно работает. Идея NDC — ввести единый формат, в этом случае — на базе XML (который, в свою очередь, инкапсулируется, находится на вершине сложного стека протоколов — HTTP (SSL/TLS), IP/TCP и так далее).
Однако как формат передачи данных XML далеко не самый оптимальный c точки зрения объема трафика. К примеру, существует протокол EDIFACT (Electronic Data Interchange for Administration, Commerce and Transport), которым GDS и авиакомпании начали пользоваться еще до того, как интернет широко вошел в авиаиндустрию. Разнообразных протоколов было и есть великое множество... Помнится, году где-то в 1993 терминалы системы Gabriel «Трансаэро» в кассах Норильска обменивались данными с хостами SITA UNISYS в Атланте посредством протокола P1024C. А были еще и P1024B — для серверов IBM, позднее и MATIP... И до сих пор в авиационных IT для межсистемного обмена используется формат typeB (BATAP, Application-To-Application Protocol) — в том числе для передачи данных о расписании и сообщений AVS о наличии мест на рейсе по классам.
В формате EDIFACT нет бесконечных открывающих и закрывающих тегов, как в XML, а это значит, что объем передаваемых данных через него на порядок меньше — при том же контенте.
Существует гораздо более компактный, чем ХML, и похожий на него формат JSON (JavaScript Object Notation). И, в отличие от специфического для авиационной индустрии EDIFACT, он широко распространен в Сети — по некоторым данным, используется в два-три раза чаще, чем XML. Хотя правда и в том, что под XML в разных языках программирования создано немало методов обработки — сериализации, «распарсивания»... Но это справедливо и для JSON. Наконец, типы сообщений и поля в EDIFACT практически фиксированы, в то время как JSON и XML позволяют выстраивать гибкие иерархические структуры.
Как бы там ни было, когда агент реализовывает передачу данных через унифицированный формат один раз — для одной из авиакомпаний, теоретически он может обратиться с этим интерфейсом к любому перевозчику, который поддерживает данный стандарт IATA. Представьте, что NDC — это «квадратная розетка», к которой можно подключить любое устройство с соответствующим «штепселем».
— И онлайн-тревел агентству придется ходить со своей «вилкой» к каждой авиакомпании?
— В том-то и дело... К каждой авиакомпании отдельно. Если крупное OTA, такое как Expedia, придет к американской авиакомпании, его с радостью примут. А если к такой авиакомпании обратится небольшое агентство? Системам перевозчиков сложно работать с сотней тысяч агентов в индивидуальном порядке! Как и агенту со всеми авиакомпаниями по отдельности — только традиционных у нас около 500! То же крупное ОТА не будет делать прямой линк для небольшой региональной авиакомпании — в ассортименте будут лишь крупные провайдеры (если нужны и другие, лучше тогда использовать агрегаторов). То есть даже наличие единого индустриального протокола технологически еще не решает саму задачу получения всего контента. К тому же, стандартизация самого NDC еще не завершена окончательно.
Возьмем авиапутешествие из Москвы в Санкт-Петербург. Теоретически агент знает, что по этому направлению напрямую летают лишь несколько перевозчиков (и стыковки не актуальны) и, используя NDC, готов честно всех опросить. При этом он должен будет проверить наличие мест, сравнить цены и только тогда предложить клиенту выбор. Эта задача уже требует определенных усилий! А теперь перейдем к более сложному варианту: Москва — Лос-Анжелес и обратно. Веб-сервисы Amadeus, которые осуществляют подобный поиск, на первом этапе проверяют базу данных сотен авиакомпаний, чтобы узнать, какие из них осуществляют рейсы на запрошенные даты. В сумме до 1500 вариантов могут быть рассмотрены только на одном «плече» и еще столько же — на обратном пути. Ведь, помимо прямых перелетов, возможны бесчисленные стыковки — в Варшаве, Лондоне, Нью-Йорке и множестве других городов. Затем идет проверка расписания по конкретной дате, минимально допустимому стыковочному времени, максимальному суммарному времени перелета, наличия мест, доступных и применимых (к данному пассажиру и условиям тарифа / продажи) тарифов и так далее. Эту огромную по процессинговым потребностям задачу система, в зависимости от метода поиска (данные «вживую» или из кеша), решает либо за доли секунды, либо в пределах трех секунд. Кто же и как это будет делать, если по бизнес-процессу вы не используете агрегатора?
— Агентству в этом случае придется самому взять на себя функции агрегатора?
— Именно так! Иначе за сложным контентом ему все равно придется обращаться в GDS или к любому другому агрегатору контента. Выйти к нему агент может через тот же NDC — все дистрибутивные системы уже поддерживают эту «розетку». Amadeus, в частности, реализовал единый протокол еще в 2014-м году — в рамках проекта с одним из американских авиаперевозчиков. То есть NDC может быть использован как для выхода напрямую на поставщика, так и на агрегатора. Это надо четко осознавать — NDC дает формат обмена (безусловно, побуждая к переходу на прямые линки), но бизнес-процесс и сама топология сети (схема взаимодействия) — построение связей провайдеров и потребителей — могут быть при этом совершенно разными.
Между тем, помимо агрегации контента, роль таких IT-компаний, как Amadeus, заключается еще и в том, чтобы снять нагрузку с серверов авиаперевозчиков, оградить их от львиной доли прямых запросов потребителей — поллинга, как мы это называем.
В офлайне опытный специалист может подобрать вам перелет за три-четыре операции. В онлайне в сотни раз больше поисков часто дают на выходе один round trip (бронирование перелета туда-обратно). Ситуация усугубляется все большим распространением мобильных приложений, которые провоцируют пользователей поискать что-нибудь — в свободное время, пока они стоят в очереди или едут в метро. Это же практически бесплатно! Но каждый клик вызывает огромный процессинг. А если речь идет о метапоиске — например, в Aviasales, запрос транслируется сразу в целый пул агентств, которые участвуют в этом тендере, — скажем, Biletix, Ozon.Travel, OneTwoTrip.... Каждое из них, в свою очередь, посылает запрос в GDS. И мы одновременно отвечаем всем.
При этом большую часть запросов мы обрабатываем сами, не обращаясь в хост авиаперевозчика, потому что накапливаем трафик, создаем кэш и контролируем его качество. Например, из 100 запросов на взятие места (после поиска) 96 удачных и 4 отказа. К слову, bookability и не может быть 100%, потому что всегда остается 1-2% ситуаций, в которых авиакомпания откажет просто потому, что пока вы думали — между поиском и покупкой билета проходит, в среднем, несколько минут — это последнее место было продано по другому запросу.
— Информацию о доступных тарифах GDS запрашивают каждый раз у авиакомпании?
— Роль GDS и в том, чтобы агрегировать тарифную информацию различных авиакомпаний, включая соответствующие правила применения тарифа, в том виде, в каком они установлены авиакомпанией. Эта информация нейтрально дистрибутируется туристическим агентствам и другим пользователям, чтобы турагенты и пассажиры могли сравнивать различные опции путешествия и выбирать между ними.
Подобная агрегация и процессинг тарифной информации связаны и с существенными финансовыми затратами. Для модели коллективного агрегатора удельные расходы процессинга ощутимо снижаются — благодаря использованию совместных ресурсов. Совместное использование информации, процессинговых возможностей, как и самой IT-платформы, служит интересам всей индустрии, позволяя в том числе состыковывать перелеты различных авиакомпаний.
— То есть серверы компаний-разработчиков GDS еще хранят и ресурсы авиаперевозчиков?
— Да, раньше все крупные авиакомпании имели свои центры хранения и обработки данных, например British Airways в Heathrow, Air France — в Тулузе, и по сей день существует компания Lufthansa Systems. Для небольших перевозчиков были коллективные хосты, вроде SITA. Но с развитием технологий потребовалось менять систему бронирования, и тогда даже для крупных авиакомпаний стало дорого разрабатывать новое поколение систем. Amadeus еще к 2004 году разработал инвенторную систему ALTEA — хостинг, то есть базу данных, где лежат ресурсы полносервисных авиакомпаний. Позже мы инвестировали и в уже существовавший хост для лоукостеров Navitaire. Суммарно 189 перевозчиков держат свои ресурсы в коллективных хостах Amadeus Altéa и Navitaire New Skies. Для авиакомпаний хранение ресурсов в коллективном хосте более выгодно по затратам и оптимально с точки зрения технологий — перевозчики сами определят приоритеты (бюджета) развития новых продуктов. И все сообщество в рамках такой коллективной модели может рассмотреть применимость разработки для одной авиакомпании — к своим бизнес процессам. Доходы от хостинга уже не один год составляют большую долю в бюджете компании Amadeus.
Таким образом, подобная диверсифицированная бизнес-модель обеспечивает компании Amadeus устойчивость в долгосрочной перспективе. При этом со временем может происходить последовательное перераспределение доходов между дистрибутивным и хостинговым IT-бизнесом. К примеру, если растут доли прямых продаж, то, соответственно, увеличивается доход от хостинга, потому что переход на прямые линки приводит к дополнительному процессингу на серверах авиакомпаний.
— Любопытно, даже при рассмотрении технической стороны перехода на NDC всплывают вопросы коммерческого характера.
— Всегда важно, кто платит за праздник! Существующая модель предполагает, что агрегатор берет на себя расходы, связанные со всеми вычислительными процессами, передачей данных, технической поддержкой и так далее. Если из этой схемы он «выпадает», эти затраты будут нести агентства и авиакомпании. Но, казалось бы, при чем здесь именно переход на единый формат передачи данных?
Идею внедрения NDC часто привязывают к желанию авиакомпаний увеличить долю прямых продаж, снизить влияние GDS на рынке. Но, во-первых, прямой канал не значит бесплатный, он и сам требует немалых инвестиций — к примеру, над прямым каналом первого в истории сайта авиакомпании — лоукостера southwest.com — трудились порядка 60 опытных специалистов, не говоря уже и о немалых затратах на call-центр авиакомпании.
Во-вторых, возникают довольно серьезные вызовы по внешним рынкам. Исторически многие авиакомпании осуществляли только внутренние перевозки, их маршрутные сети изначально были географически весьма ограничены. Но при выходе на чужие рынки перед любой авиакомпанией встает непростая задача — как донести до клиента, конечного пассажира, свое предложение? Либо продвигать его в поисковой системе, вроде Google, либо через агрегатор контента, в некой дистрибутивной системе, которая нейтрально (по времени вылета) сортирует предложения всех, даже самых небольших авиакомпаний, если у них есть места и договор о дистрибуции в данной системе.
И еще одно важное замечание — непрямой канал позволяет авиакомпаниям выйти на более доходных клиентов. Агрегаторы дают доступ к корпоратам, которые (имея свои внутренние политики и определенные требования, включая отчетность) в гораздо меньшей степени пользуются публичными сайтами. Почему еще авиакомпании не могут отказаться от агрегаторов? Потому что они дают им больше половины всего трафика. Даже лоукостеры, которые изначально позиционировали только прямую дистрибуцию, поняли, что с такой маргинальной моделью они теряют часть потенциального бизнеса. При этом авиакомпания платит агрегатору только по факту продажи! Это модель имеет свою логику для бизнеса туриндустрии, поскольку агентства получают коммерческие преимущества, как, например, инсентивы от GDS.
— Но в то же время авиакомпании при переходе на прямые продажи через собственные сайты или агентов, связанных с ними напрямую через NDC, избавляются от посредников — а значит, экономят? Не ради этого ли все затевалось? И перевозчики уже оказывают давление на провайдеров технологий — вводят дополнительные сборы на билеты, продаваемые через GDS, непрямой канал.
— На эту тему много копий сломано. На практике получается своего рода коммерческий парадокс: авиакомпания перестает платить агрегатору, но у нее появляется дополнительная статья расходов — на то, чтобы стимулировать агента поменять каналы выхода на перевозчика, то есть как-то компенсировать его затраты. Ведь тогда, скажем, для работы своего сайта агенту нужен канал, который пойдет к авиакомпаниям по NDC, веб-сервисы, позволяющие осуществлять поиск и бронирование перелета, продажу дополнительных услуг, пост-продажное обслуживание — обмен и возврат билета — и так далее... Кто все это будет разрабатывать, поддерживать и развивать? И кто оплачивать?
В качестве «кнута» некоторые авиакомпании пытаются использовать не только дополнительный сбор за бронирование в непрямом канале. Чтобы заставить агента перейти на прямой канал — кстати, задолго до проекта NDC — многие перевозчики создавали и предлагали крупным агентствам свой API. И в этом канале, скажем, более дешевый тариф (или отсутствие сборов). Но перевозчик не может дискриминировать таким образом самого агрегатора, если между ними подписано соглашение о полном контенте. Запрещено также отказывать агрегатору в доступе к продаже дополнительных услуг, если их предлагают в прямом канале.
— Кстати, о дополнительных услугах. Действительно ли переход на NDC, как говорят, улучшает их продажу?
— Часто говорится, что авиакомпании якобы не могут донести до конечного клиента свое предложение, продавать свои дополнительные сервисы, используя непосредственно GDS. Это первый из расхожих мифов.
Между тем задолго до того, как придумали NDC, уже существовал индустриальный стандарт агрегатора тарифной информации ATPCO, в котором каталогизированы все возможные мыслимые и немыслимые услуги авиакомпаний. Они пронумерованы и имеют свои коды (и суб-коды) по типу сервисов. Дополнительный багаж, в зависимости от типа, веса и размеров, бизнес-ланч, доступ в интернет, перевозка животных, даже заказ носилок, кислорода — это «Optional Services Industry Sub Codes», всего список на данный момент включает более 650 опций, он в открытом доступе! Поэтому перевозчики уже давно имели возможность описать свои дополнительные услуги, используя эту таблицу. Все GDS с самого начала поддерживают каталог ATPCO. Но такую таблицу клиенту на сайте не покажешь, она понятна специалистам, поэтому индустрия для обмена использует специальные текстовые межсистемные форматы запросов SSR — Special Services Request. Все GDS разработали соответствующие веб-сервисы, мерчандайзинговые продукты, благодаря которым дополнительные услуги у ОТА могут быть представлены в наглядном виде, как и на сайте авиакомпаний. Веб-сервисы помогают также сделать upsell, то есть предложить вариант перелета подороже, уже включающий в себя определенные наборы услуг. Потребность в таких инструментах стала особенно острой после перехода полносервисных авиакомпаний от сетки тарифов, в которых все включено, к пакетам услуг — Airline Fare Families. Существующие технологии позволяют сразу показать клиенту не только самое дешевое, но и предложение следующего уровня — оно будет, к примеру, на 500 рублей дороже, но билет станет возвратным.
— Грач, вы упомянули, что мифов несколько...
— Да-да! Легенды и мифы древней Греции... И в публикациях, и на конференциях, рассчитанных на публику, которая не очень-то и разбирается в деталях, часто некоторые представители индустрии говорят, что с помощью NDC авиакомпании могут донести до клиента персонифицированное предложение. Хорошо, давайте разбираться. Что же такое — персонализация?
В моем понимании, существует два принципиальных подхода — уровня грануляции. Можно попытаться персонифицировать предложение с точностью до профиля клиента — Иванов, Петров, Сидоров. Если он часто летающий путешественник, некоторые его предпочтения, действительно, могут быть уже известны CRM авиакомпании. Но даже при бронировании на сайте авиаперевозчика, если оно не осуществляется сразу из личного кабинета, идентификация пассажира происходит не в момент поиска, а позднее — уже в момент бронирования и покупки билета. Но и в том нечастом случае, когда вы изначально идентифицировали клиента, нет никакой гарантии, что это поможет выдать персонифицированное предложение, соответствующее искомой им именно в данный момент поездке.
Скажем, по базе CRM перевозчика вы определили, что я — деловой путешественник, обычно выбираю эконом по своим корпоративным правилам (ограничительным политикам компании). Но вдруг в этот раз я отправляюсь в личную поездку и имею совершенно другие — уже личные критерии. Разумеется, можно строить догадки и по косвенным признакам поискового запроса: если, к примеру, один взрослый ищет перелет в понедельник из Москвы в Петербург и в этот же день обратно — то скорее всего это бизнес-поездка, а если семья на две недели в Бангкок — то leisure, а если билет в один конец — то... на ПМЖ? А если во Франкфурт на два-три дня или неделю? Поэтому даже персонификация предложения конкретного клиента на уровне экспертизы CRM весьма сомнительна. CRM — это вообще весьма цепкая и забавная штука: я как-то, лет десять назад, случайно забрел на сайт известного производителя небольших самолетов — и потом долго периодически получал предложения купить самолет и десять бочек бензина в качестве бонуса.
Другой — более общий способ персонификации заключается в том, что предложение выдается на основании категории (профиля) клиента. Обычно путешественников классифицируют по трем-четырем профилям. К примеру: бизнес-клиент — ему предполагается в первую очередь выдавать варианты прямого перелета, второй — семейный, третья категория — «рюкзачник», который готов взять билет подешевле с двумя пересадками (и ночевать две ночи в аэропортах). Сами эти категории тоже весьма условны. Но уже на этапе сопоставления запроса пассажира с тем или иным профилем начинаются танцы с бубнами. Вот зашел, скажем, на сайт известной авиакомпании — к какому типу меня отнести? Данных ведь для оценки очень мало — достоверно известен только маршрут и запрошенные даты. Можно, конечно, попросить клиента изначально поставить галочку — с какой целью, мол, сударь, путешествуете?
Между тем компания Amadeus даже для этой сложной задачки нашла решение, оно называется Value Search. В чем заключается его идея? Допустим, мы, условно, классифицировали-таки профиль клиента. В этом случае система выдаст не просто до 250 рекомендаций вариантов перелета по возрастанию цены. В верхушке все равно останется самый дешевый вариант (он нужен и для участия онлайн-тревел агентства в тендерах Метапоиска — чтобы клиент по этому варианту перешел с Мета на сайт ОТА), но вторым и третьим в выдаче будут персонифицированные для данного профиля клиента предложения — скажем, самый дешевый прямой перелет.
Но где здесь NDC? С форматом передачи данных такого рода персонификация вообще никак не связана. Это все уже о другом — бизнес-правила, big data, правильные профили клиента, наконец — корректная кастомизация поискового запроса и так далее.
Более того, как я отметил выше, есть весьма востребованный канал, где сама персонификация имеет мало смысла! Например, вы заходите на сайт Метапоиска — по сути, там тендер на самый дешевый вариант перелета. Если агент начнет вести игры с персонификацией и, считая, что пассажир, который летит из Москвы в Петербург на один день, — бизнесмен, выдаст в качестве своего предложения прямой перелет в бизнес-классе, он этот тендер просто проиграет, потому что его вариант будет в конце списка, отсортированного по цене.
— Каким же вы видите будущее дистрибуции и продажи авиауслуг в контексте дальнейшего перехода игроков рынка на NDC?
— NDC — это лишь еще один протокол, который при этом принципиально не решает задачи получения контента, персонификации предложения или экономии. Более того, он создает новые вызовы, в том числе — как, скажем, теперь быть со стыковками разных авиакомпаний и интерлайнами (это ведь тоже задачи, решаемы в рамках агрегирования)? Да ведь и прямые каналы никто никогда не запрещал. Без единого стандарта переходить на прямые каналы продаж сложнее, это правда. Но у этой модели есть, как мы видели, еще и обратная сторона, барьеры по бизнес-процессам, по коммерции.
Полагаю, возможен компромиссный вариант: для получения контента агенты будут с ограниченным рядом поставщиков иметь прямые каналы по NDC, но в то же время обращаться и к агрегаторам — все это технологически возможно по тому же самому протоколу. Если в какой-то момент все авиакомпании перейдут на NDC, то технологически это упрощает обмен данными между игроками индустрии — в том числе и для компании Amadeus. Время покажет — жизнь и сам бизнес все расставят по своим местам, как уже не раз бывало с различными техническими решениями в процессе эволюции протоколов передачи данных...
Беседовала Наталья Травова
