Через какую хитро закрученную схему вы получаете авиабилет

Через какую хитро закрученную схему вы получаете авиабилет

Так в Сирене выглядит бронирование по маршруту Москва (Внуково) — Краснодар и обратно

Внешне продажа билетов выглядела очень просто: сначала у авиакомпаний были бумажные журналы, в которых можно было отмечать, какие места на какой рейс заняты. Кассир авиакассы говорил диспетчеру, куда хочет полететь пассажир, а тот в свою очередь звонил в авиакомпанию, где отмечали, что место продано. Пассажиру давали в руки билет. На самом деле всё чуть сложнее: например, нужно было сопоставить номер бланка билета (купон) с местом, а значит где-то достать бланки и получить диапазон номеров для конкретной авиакассы.

Учёт билетов в тетрадке всё ещё ведётся в некоторых авиакомпаниях (последний раз такое мы видели буквально в прошлом году в Латинской Америке). В СССР же он вёлся до 1972 года, когда появилась первая сеть из авиакасс в четырёх сотнях городов, соединённых с центральным компьютером. Женщину вынули, автомат поставили. Там, где компьютеров не было, диспетчер связывался с ближайшим центром, где компьютер был.

Эти прекрасные романтические времена, когда Аэрофлот фактически повлиял на изобретение советских сетевых протоколов — первая Сирена работала на аналоге UDP с 97% доставкой. Прогресс советских баз данных и прочих технологий, которые сейчас воспринимаются как антураж Фаллаута, — через несколько витков эволюции превратился в связку из нескольких систем, которые, собственно, и выписывают вам билет.

• Авиакомпании выгружают свои тарифы, расписания и доступные билеты в инвенторные системы (собственные «хранилки»).
• GDS соединяют инвенторные системы разных компаний и позволяют искать билеты в них. К этим системам подключаются продавцы и берут в них билеты для своих клиентов.
• В мире есть несколько больших GDS, и одна из них — отечественная Сирена.

Инвенторная система (CRS)

Основа распределения мест авиакомпании — это инвенторная система. По сути, это расширенный аналог тетрадки с записями мест. В инвенторной системе как минимум хранится расписание рейсов и наличие мест на них, а также занятые места связываются с пассажирами.

Билеты перед вылетом проверяются по спискам, которые выгружаются из инвенторной системы на аэропорт отбытия.

Вход и выход простые: вы можете получить из инвенторной системы расписание и наличие мест либо указать, что одно из свободных мест нужно занять вот таким-то пассажиром. Конечно, современные инвенторные системы обладают чуть более широким функционалом, чем просто хранение данных и два внешних API-вызова, но про это дальше.

Инвенторные системы обычно объединяются с какой-то инфраструктурой в контур, который сертифицируется для хранения персональных и банковских данных, прочих чувствительных материй. Всё это вместе обычно называется хостом авиакомпании.

Поднять хост — это целый бизнес, потому что вам нужно развернуть ЦОД, в него натаскать своих серверов, всё это сертифицировать по российским стандартам и множеству зарубежных (начиная с PCI DSS и заканчивая…). Также сверху поставить решение, которое обеспечит совместимость со всеми мировыми системами продажи билетов. И ещё нужно это всё поддерживать. Получается достаточно дорого, поэтому хосты обычно строятся и группируются теми, кто способен один раз отработать процесс создания инфраструктуры под них и поддержки ПО.

Собственно, Сирена (та самая система резервирования авиабилетов) эволюционировала, в частности, в Сирену-Трэвел, которая поддерживает хосты для российских авиакомпаний. Вообще, держать хост у кого-то — общемировая практика. Насколько я знаю, собственные хосты (не SaaS и не аутсорс) поддерживают Эмирейтс и Туркиши. В России вообще нет ни одной авиакомпании, имеющей хост не в виде SaaS.

Глобальная распределительная система (GDS)

Представим, вы хотите полететь из Магадана в Москву. Ещё несколько десятков лет назад вы бы пошли на аэровокзал и стали бы обходить кассы каждой авиакомпании для того, чтобы сравнить стоимость билета. Возможно, авиакомпании предложили бы вам варианты с пересадками на свои же рейсы (внутри хоста). Но вот на задаче пересадок между двумя авиакомпаниями можно было уже сломаться.

Очевидно, был запрос на систему, которая собирала бы все данные со всех хостов и давала возможность решить задачу коммивояжёра на полном графе. Чтобы пассажиру можно было полететь из Нового Уренгоя в Париж с какими угодно пересадками так, как ему нравится: быстрее всего, дешевле, с остановкой в Стамбуле на сутки, без Лондона (потому что там у него нет визы) и так далее.

Появились агентства, которые имели несколько пультов разных авиакомпаний, и кассиры запускали запросы сразу на нескольких ЭВМ. Это выглядело жутким костылём, и нормальное решение виделось достаточно очевидным: нужно было просто уговорить все авиакомпании держать хосты в одной системе.

Но суперхост — идея нежизнеспособная.

Во-первых, исторически это было невозможно. Из-за технических ограничений тех лет просто нельзя было держать базу данных такого размера. Для понимания — первая советская Сирена была разделена на региональные подсистемы, в которых кластеризовались рейсы по авиакомпаниям нескольких схожих направлений. Примерно до середины 1990-х это было около 60 разных «дробных» баз в разных регионах, и нужна была какая-то связка между ними.

Во-вторых, организационно гораздо проще воспользоваться обычным запросом расписания из хоста, чтобы опросить все хосты подряд и составить общее расписание. Это если вы вспомните, что авиакомпании вообще-то бывают в разных странах, а в разных странах — разные стандарты, договорное право и желание хранить свои данные у себя.

В итоге понадобилась надстройка, умеющая собирать расписания и доступность мест с хостов.

Системы, которые опрашивали хосты таким образом, стали современными GDS.

Упрощённо, GDS умеет собирать всё подмножество расписаний хостов, делать поиск на нём и показывать пассажиру (или кассиру) варианты, как добраться из точки А в точку Б, а потом отправлять в инвенторную систему запрос на занятие мест.

То есть это такая обёртка поверх CRS, ставшая, по сути, интерфейсом к хостам.

Соответственно, в случае Советского Союза и России дальше появилась интеграция ГРС Сирена с Сиренами-2000 (региональными инстансами и хостами авиакомпаний). С единого терминала можно было заказывать любой рейс.

Поисковая нагрузка

Инвенторные системы по своей архитектуре очень часто легасевые либо просто не предназначенные для высоких нагрузок. В них нужно отправлять целевой запрос: «Дайте расписание конкретного рейса в определённый день. Фиксируем: есть свободные места, вот эти два займите вот этими пассажирами». Поиск по десяткам разных дат и сотням рейсов они не выдержат в силу своего устройства. А как раз GDS стали прослойкой, которая вполне может отдавать тысячи комбинаций, то есть делать поиск по запросам типа «что у вас вообще есть в Магадан?» или искать с гибкими датами. Для рейса, например, в Эквадор с плавающей датой отбытия нужно было бы сделать от 50 до двух–трёх тысяч запросов в хосты, если бы не было GDS. Соответственно, GDS ещё обеспечивает синхронизацию своих расписаний с хостами, обращаясь в них не каждый раз, а только по изменению на хосте.

Тарифы

Любой тариф должен быть представлен в некотором универсальном виде, позволяющем понять, как он применяется и при каких условиях. В итоге сейчас для нас на практике есть два набора стандартов: общемировой и отечественный. Они совместимы, конечно, но правила тарифной сетки хранятся в двух разных компаниях. У нас это центр расписания и тарифов (ЦРТ). GDS использует базу данных ЦРТ для того, чтобы понять, как и какую услугу считать.

Исторически было так: сначала авиакомпания просто говорила, сколько стоит перелёт и это записывалось в билет в графу «тариф». Затем по ряду причин из тарифа стали выделять сборы: аэропортовый сбор за услуги воздушной гавани и терминала, топливный сбор, госпошлина и дистрибутивный сбор.

Соответственно, для каждого предложения клиенту цены надо очень точно знать: из чего складывается цена на билет, кто из участников цепочки сколько получит.

Этим всем занимается система взаиморасчётов (СВВТ), а ЦРТ — часть СВВТ.

Расчёт тарифа перед продажей билета

Усложнение GDS

Представьте, что вам нужно пересадить человека между двумя авиакомпаниями — сделать connected flight, то есть с гарантией доставки. Опять же, в первом приближении выглядит просто: нужно посмотреть, есть ли у компании А и компании Б соглашение, а потом сформировать один билет из двух сегментов по этому соглашению. Но тут необходимо учесть множество деталей. Например, укладывается пересадка в MCT или нет (это минимальное время от прибытия самолёта до конца посадки другого, зависит от особенностей аэропорта: по проверкам, расстоянию, досмотрам ручной клади и багажа). А если на одном рейсе пассажиру можно 7 кг ручной клади в одной сумке, а на другом 10 кг в любых рекомбинациях — какое правило применять и показывать в тарифе?

И это только стыковки М1. Последние годы развиваются стыковки М2 — новое поколение, когда GDS объединяет две несвязанные соглашениями авиакомпании (или даже авиакомпанию с железнодорожными и автобусными перевозчиками). А иногда система продажи авиабилетов вообще продаёт вам билет на поезд и автобус в М2-стыковке.

В случае Сирены М2 стыковки делались с Deutsche Bahn для доставки по Германии сначала рейсом Аэрофлота в страну, а потом поездами по ней. Сейчас их по понятным причинам уже нет.

Опять же, когда вы начинаете собирать в GDS железнодорожные билеты из АСУ Экспресс (из более консолидированной GDS железных дорог), подтягивать автобусные билеты из аналогов хостов автобусных перевозчиков или их аналогов GDS, то возникает непреодолимое желание интегрировать в систему вообще всё. Сирена в какой-то момент торговала даже билетами на концерты, раз уж инфраструктура имеется. Но поскольку это был не их бизнес, довольно скоро пришли профильные игроки вроде Партера и написали более специализированные и более конкурентные системы.

Следующая задача для GDS — код-шер и интерлайн-перелёты. Например, летит один физический самолёт, но в нём два рейса: один, скажем, S7, а второй — Air France. Формально его выполняет одна из авиакомпаний, а вторая включила его в свою сетку расписания как собственный. Технически можно хранить все такие рейсы в хостах как свои, то есть загружать расписания вообще всех авиакомпаний, с которыми есть соглашения. На практике обычно такое решение используется редко из-за роста базы (и стоимости содержания хоста), и такие рейсы очищает и склеивает между собой уже GDS.

Оплаты

Проще всего продать билет прямо с хоста, в собственной кассе авиакомпании или на своём сайте. Подключаете эквайринг, отправляете в него сумму списания с клиента за тариф, как только получено подтверждение оплаты — записываете клиента в инвенторную систему. Это прямое движение денежных средств.

Чуть сложнее, если у вас прямой договор с агентством. Там фактическое поступление денег займёт слишком много времени, поэтому обычно есть договорённость уровня «агентство записывает клиента в инвенторную систему, и мы рассчитываемся в конце месяца» или на подобном уровне. Нюанс в том, что турагентство может внезапно разориться (что регулярно и случается) и тогда деньги за цикл могут не дойти до авиакомпании, поэтому используется система депозитов или банковских гарантий.

GDS в итоге должна иметь ещё какой-то сервис, который позволяет заплатить за билет, а не просто его найти и выписать. У нас в России это транспортная клиринговая палата (ТКП). Фактически это компания, которая заключает договоры с каждым из участников, обеспечивает их деятельность банковскими гарантиями или депозитами и делает так, что деньги от клиента в конечном итоге поступят продавцу. Поскольку она ещё и К, там происходит взаимозачёт, и только потом движение денег.

Что получается

• Авиакомпании держат свои расписания и наличие мест в хостах.
• Хосты обычно находятся на инфраструктуре компаний, делающих GDS.
• GDS объединяет хосты, добавляет тарифные правила, делает стыковки, обеспечивает взаиморасчёты через клирингового партнёра.
• Один хост может быть подключён к нескольким разным GDS.
• Хосты могут синхронизироваться с другими хостами партнёрских авиакомпаний, используя GDS как шину.
• GDS может стыковаться с другой GDS или аналогом на другом виде транспорта.
• GDS не видна пассажиру, он видит TA или OTA — конечных продавцов билетов.

Теперь про комиссии. В России Сирена преимущественно берёт комиссию с агентств за выписанный билет. Западная практика — GDS платят агентствам как дистрибьюторам, а авиакомпании, соответственно, платят GDS сбор (11 евро) за каждый сегмент. Сирена — первоисточник контента с билетами. Уже агентствам интересно подключаться к ней и получать от неё сервис.

Ещё один отличный вопрос: откуда тогда тут иностранные компании, которые как-то влияют на наших перевозчиков? В силу определённых особенностей, до появления 153-ФЗ про «приземление» персональных данных, авиакомпании с международными полётами часто сотрудничали с иностранными GDS-операторами для содержания у них хостов. К примеру, Аэрофлот раньше покупал эту услугу у Sabre (и ещё покупает формально, но могу ошибаться), а S7 — у Amadeus. Хост, соответственно, соединялся с несколькими разными GDS, включая Сирену. GDS выступала в роли дистрибьютора билетов, например, у Сирены сейчас 15 тысяч точек продажи и 800 агентств-партнёров (включая нас и других онлайн-продавцов билетов, например, но мы случай немного особый, поскольку сотрудничаем с четырьмя разными GDS и имеем ещё прямые договоры с рядом перевозчиков). Есть страны СНГ, где большинство точек продажи Amadeus, например, поэтому если хочется продавать билеты из этой страны — партнёрство с ними как с GDS становится почти обязательным.

Когда стало невозможно сотрудничать с западными компаниями, возникла необходимость переноса хостов. Был норматив, который требовал переносить хосты в РФ, но перевозчики откладывали сколько могли. В феврале наступил дедлайн. Например, недавний переезд Победы из Navitaire в Сирену — как раз перенос хоста.

Теперь перейдём к вопросу, почему при проблемах с GDS может пострадать продажа билетов у самой авиакомпании. Ещё более интересным следствием того, что GDS фактически выступают умным интерфейсом к хостам, стало то, что напрямую через хост продавать не очень удобно. Даже когда авиакомпания создаёт свой сайт, ей часто удобно продавать не впрямую, а через GDS, пользуясь уже готовыми сервисами код-шера, интерлайна, подключением к ТКП и так далее. Единственное исключение — оформление продаж услуг вроде бортового питания. В итоге, если вдруг из-за санкций с вами перестаёт работать GDS, нужно быстро поменять систему, через которую сделан магазин на сайте, иначе отвалятся и собственные продажи тоже.

Следующий этап развития Сирены — биржа всех возможных услуг партнёров с возможностью их комбинировать под страховку риска, а продаваться это будет агентствам как ИТ-инструмент для получения оптимального билета.

Это ещё не всё, погодите!

У OTA вроде нас могут быть собственные средства, которые обогащают всю эту историю. Во-первых, для ускорения поиска, чаще всего используются объёмные кеши сопоставления данных GDS по расписаниям, тарифным правилам и дополнительным услугам. Чтобы показать клиенту информер со стоимостью билетов по его хитрому маршруту на ближайшую плюс-минус неделю, используются именно собственные кеши, иначе GDS сложились бы под шквалом запросов. Собственные кеши нужны и для того, чтобы опрос GDS занимал не 5–10 минут, а секунды — просто проверить даты обновлений хостов и получить инкремент.

Прямые договоры с авиакомпаниями требуют работы с их инвенторными системами. Поскольку они очень часто немного легаси, нужно либо учить оператора работе с консолью, либо делать собственную обвязку с автоматизацией (или не заключать прямой договор и работать через интерфейсы GDS).

Кроме основных вещей, описанных в стандартах, нужно постоянно поддерживать ещё множество подсистем: например, учитывать, куда и с какими документами можно лететь, где какие правила провоза багажа (вроде габаритов или допустимого веса, что важно для интерфейсов выдачи по билетам), знать время на дорогу между терминалами и аэропортами (чтобы не пытаться продать два разных билета при поиске сложного маршрута без учёта того же MCT) и так далее.

Добавьте к этому собственную юридическую обвязку прямых договоров, иностранных банковских гарантий, депозитов и т.п. — и только тогда получите примерное и очень поверхностное представление, как это работает.

• бронирование авиабилетов
• gds
• сирена

• Блог компании Туту.ру
• Управление проектами
• Транспорт

Бронирование авиабилетов: Как было и как это работает сейчас

Развитие современных информационных технологий значительно влияет на методы работы предприятий в сфере услуг. Стремительное развитие информационных технологий, безусловно, затронуло крупную и динамичную отрасль мирового хозяйства – туризм. Эти технологии представлены в туристской индустрии во всем многообразии. От специализированных программных продуктов управления отдельной туристской фирмой до применения глобальных компьютерных систем.

Наряду со сбытовой функцией информационные технологии предоставляют самую разнообразную информацию о фирме и ее услугах. В настоящее время в сфере реализаций туристских услуг активно используется компьютерная техника. Сейчас уже трудно представить, как могло производиться бронирование авиабилетов компаниями при отсутствии систем компьютерного бронирования.

Как все начиналось

Еще на заре пассажирской авиации авиакомпании, их клиенты и посредники столкнулись с вопросом: как искать, бронировать и отменять авиабилеты быстро и безошибочно. Первые авиакомпании хранили сведения о проданных билетах и свободных местах используя бумагу, доски и мел. Офисы чаще всего располагались прямо в аэропортах. Каждый офис хранил информацию по своим рейсам, ведя записи в так называемых «полетных картах».

В 1930-е, когда даже у крупнейших авиакомпаний было всего несколько десятков рейсов и самолеты почти никогда не летали загруженными под завязку, эта неудобная система кое-как работала. Но менеджерам авиакомпаний уже тогда становилось очевидно, что в будущем обмен данными может стать серьезным препятствием для развития бизнеса.

«Резервизор» – прародитель автоматического бронирования авиабилетов

Первой решать проблему начала компания American Airlines – и для этого она наняла менеджера Чарльза Аммана. В 1939 году продавцам на местах разрешили продавать билеты на рейсы без одобрения главного офиса до тех пор, пока загрузка не достигнет 75%. Также ввели более удобную систему выдачи полетных карт.

В 1946 году Амман представил первую в мире автоматизированную систему под названием Reservisor. Она была впервые установлен в бостонском офисе American Airlines. Система представляла собой матрицу, в которой ряды кнопок обозначали направления, а ряды из десяти лампочек – дни. У работников на столах тоже были установлены похожие устройства, соединенные с центральным «резервизором». При нажатии кнопки система показывала им наличие мест сразу на десять дней вперед.

Следующим детищем American Airlines стала улучшенная и дополненная магнитным барабаном машина Magnetronic Reservisor. Магнитный «Резервизор» умел держать в памяти данные о наличии билетов от 1000 до 2000 направлений на десять дней вперед. Магнитный барабан позволял хранить больше информации, и American Airlines начала собирать статистику запросов, бронирований и отмен по каждому работнику.

«Резеррайтер» – машина, которая стала хранить данные пассажиров

Reserwriter – машина, которая в дополнение стала сохранять данные пассажира в системе. Эта машина умела записывать данные на перфокарты, которые передавались далее. Имя, фамилия и маршрут каждого пассажира стали доступны всем офисам, где были установлены «Резеррайтеры».

Эти новшества безусловно делали работу по бронированию более простой, но это все еще был ручной труд. В процесс было вовлечено множество живых людей и потому были неизбежны ошибки. Стало ясно, что работы по обмену данными в ближайшие годы станет больше в разы. Было необходимо срочно ее автоматизировать.

Эпоха компьютеров

SABRE – это система бронирования, используемая многими авиакомпаниями до сих пор. Разработка новой системы стоила $30 млн, зато она задействовала настоящие компьютеры. SABRE была была крупнейшей в мире коммерческой системой обработки данных в реальном времени. К системе были подключены полторы тысячи терминалов из разных офисов по всей стране. Она умела обрабатывать 7000 запросов в час, не совершая, в отличие от людей, ни одной ошибки.

Компания IBM, поняв, что за авиацией будущее и в скором времени создала другой успешный продукт – PARS, который продавала в Америке и за рубежом. Крупнейшие авиакомпании мира стали обзаводиться своими компьютерными системами резервации (CRS) на основе PARS. Так в мире появились десятки разных подобных систем. было

Переход от CRS к GDS

Начиная с 1970-х в мире появилось несколько глобальных систем дистрибуции GDS, накрывших собою, как зонтики, локальные CRS. Процесс стал следующим. Клиент приходил в агентство и просил билет, например, из Лондона в Лос-Анджелес. Работник агентства со своего офисного компьютера отправлял запрос, например, в Amadeus, и тот раздавал информацию двум CRS (одну для перелета до Нью-Йорка в авиакомпанию А, вторую – для рейса до Лос-Анджелеса в авиакомпанию Б). Работник печатал билеты, и когда счастливый путешественник прибывал в аэропорт Лондона, авиакомпания А из того же Amadeus уже знала, что конечная его цель – не Нью-Йорк, а Лос-Анджелес. Сегодня такое кажется естественным процессом.

Золотая эпоха GDS

Со временем сила GDS возрастала, при этом рынок весьма слабо контролировался. В результате нескольких слияний и поглощений к началу 2000-х три GDS контролировали 95% рынка. И в целом эта ситуация не меняется последние 20 лет. Расчеты устроены так, что в менее выигрышном положении уже много лет находятся авиакомпании, которые отчисляют комиссию GDS. В более выигрышном же – агентства, которым начисляется комиссия от GDS. Попытки создать альтернативные платформы для дистрибуции приводили к тому, что крупные игроки их просто покупали.

Что может произойти в будущем

Вероятно, события последних двух лет и последовавшие за ними перемены изменят мировое бизнес-сообщество. Это безусловно повлияет на рынок дистрибуции: люди будут реже ездить в командировки и больше общаться в Zoom. Может быть, и роль агентств в организации досуга станет меньше, чем сегодня. Если люди будут больше бронировать онлайн, это приведет к сокращению объема бронирований через глобальные системы.

Материал подготовила Парада Анна, гр. ДГС, 3 курс

Это может быть интересно:

Источник https://habr.com/ru/companies/tuturu/articles/673848/

Источник https://fcti.by/2022/10/09/%D0%B1%D1%80%D0%BE%D0%BD%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5-%D0%B0%D0%B2%D0%B8%D0%B0%D0%B1%D0%B8%D0%BB%D0%B5%D1%82%D0%BE%D0%B2-%D0%BA%D0%B0%D0%BA-%D0%B1%D1%8B%D0%BB%D0%BE-%D0%B8-%D0%BA/

Источник