Интернет сервисы для бронирования услуг путешественнику становятся все изощреннее.
Один из последних трендов — это единая корзина. Смысл корзины (единой / мульти, читатель может добавить определения исходя из своих предпочтений) простой — создать возможность, для путешественника, бронировать (оплачивать) бронировать, как авиауслуги, так и всяческие не авиа (аренда авто, проживание, трансфер и т.д.), накидывая их, как в интернет магазине, в единую корзину.
Я вам расскажу, про камни о которые спотыкается развитие данных технологий
Для авиаперевозок (технологическом лидере отрасли) все началось примерно 10 лет назад, когда American Airlines пытался продавать с online полный набор услуг; препятствий возникло множество:
Год 2014, IATA (международная организация, устанавливающая стандарты в авиации) анонсирует в привычном месте проведения авиафорумов, в отеле Авиастар (там я услышал, впервые в публичном пространстве, данный термин) переход на новый стандарт NDC. И показывает картинку — корзинка, в которую сложены самые разнообразные услуги. Именно так в индустрию путешествий пришла корзина покупателя из e-commerce.
Комментарий: NDC — глобальная инициатива всемирной организации авиации, технологическая основа — переход от использования телеграмм к xml протоколу обмены данных. XML конечно упрощает интеграцию. Но основная цель — это рынок дополнительных услуг, его потенциал $150 млрд в год, а главное — билеты приносят очень маленькую маржу, а дополнительные услуги от 5 % (что уже выше доходности билетов), до 50 %. По словам владельца одного из американских туристических агентств — в их бизнесе авиабилет, это как молоко в супермаркете, денег не приносит, но должно присутствовать на полке, деньги же в другом.
Год 2017, запускаем первую единую систему дистрибуции товаров для путешественника, с единой корзиной — к авиабилету в корзинку можно положить: проживание, аренду авто, трансфер, Аэроэкспресс, страховки (а так же дополнительные сервисы к каждой из этих базовых услуг).
Год 2018, готовлюсь к презентации на авиафоруме в Казани, делаю картинку, про то, как удобно устроено у нас: накидал услуг в корзинку и заплатил одним платежом, и как неудобно в S7, где каждая услуга, это отдельная покупка. Иду на сайт S7, перепровериться, не был на сайт пару месяцев, а там то же самое — можно купить единой корзиной сразу несколько услуг. Пришлось, в качестве плохого примера, использовать сайт Внуково.
Год 2019, все начали работать по такому же стандарту, проектов завершённых пока немного, но только лично я знаю 4 проекта, которые в работе. Самое крупное — проект построения импортозамещающей GDS (какой не скажу, их две, запрещает всемогущий NDA).
Говоря просто: продажа через единую корзину — тренд. И тот, кто сегодня не научится работать с корзиной, завтра вынужден будет искать другую работу.
И вот тут то мы подошли к интересному — а как реально происходит переход к единой корзине.
Комментарий: персонажами выступят сотрудники крупной и уважаемой ИТ компании. Это знающие и неглупые люди. Все нелепости, описанные в статье, происходят из обычной зашоренности мышления.
На первый взгляд все хорошо — GDS переходят на xml, меняют структуры бронирования, проекты плодятся, всё чтобы жить по современному. Есть конечно аутсайдеры, вроде Leonardo PSS (Passenger Service System — это система в которой авиакомпания хранит все свои ресурсы: борта, рейсы, места; а хорошая PSS еще много что имеет), системы свежей, всего 5 лет ей. И тем не менее построенной на допотопных телеграммах, и про изыски NDC совсем не знающей. Это творение наших дней даже выгрузку расписания не умеет выполнять в автоматическом режиме, отгружают в ручную и зачастую кнопку нажать забывают и расписание не приходит, и тут включается ручная процедура созвона.
Но это аутсайдеры, живущие с импортозамещения. В целом… И тут не все хорошо. Этой осенью мне довелось задать вопрос главному технологу большого проекта построения российской системы бронирования (современной, даже с претензией на инновационность), какой подход они собираются использовать — GDS или маркетплейс. И тут напоролся на ответ: что в отрасли все уже есть и не надо тут ничего выдумывать. Первая мысль была: неудачно / не вовремя спросил. Но после нескольких подобных столкновений и после моих безуспешных объяснений, что дают современные подходы (это были столкновения не с одним сотрудником) я осознал глубину закостенелости отрасли.
И поэтому излагаю пару кейсов, для чего нужны подходы маркетплейса и что они дают (намеренно в корзине оставляю только авиауслуги, с тем что бы примеры были ярче, но глобальные масштабы это приобретает при наличии не авиауслуг). В примерах используются кейсы агентской схемы продаж.
Заходим на один из самых распространенных поисковиков — aviasales (простите ребята, я вас уважаю, это не камень в ваш огород) и ищем Москва-Стамбул, туда и обратно. Находим пачку предложений, но ни одно из них нас не удовлетворяет. Тут же мне хочется, как путешественнику, комбинировать перелеты самому. Но не дают. Почему? Очень просто.
Для туда и обратно GDS требует сформировать бронь RT – (round trip ticket) – авиабилет в обе стороны, т. е туда и обратно. Это не всегда возможно. Самый простой пример — вы агентский сайт и у вас несколько источников получения предложений на перелет. И Москва — Стамбул у вас в одном источнике. А Стамбул- Москва, у вас, в другом источнике. GDS говорит- ну что тут поделаешь… Но у нас то корзина маркетплейса и мы формируем нужный нам набор туда и обратно, и создаем две брони с типом OW – (one way ticket) – авиабилет в одну сторону, и присылаем пассажиру 2 маршрут квитанции. Все удобно, платиться одним взмахом.
Соответственно в заказе (для перелета туда и обратно), в нашей системе мы должны сформировать запись в таблицу orders: Заказы. В качестве основного идентификатора у нас используется не традиционный PNR, а order_n — номер заказа. И две записи в таблицу services: Услуги, обе с ссылкой через order_id на orders. В поле type_flight, для заказа, сформированного по правилам GDS, мы ставим признак типа перелета rt, не по правилам ow, в поле PNR в первом случае один идентификатор, во втором другой идентификатор. Тоже самое с ссылками на электронный билет и маршрут квитанцию.
Вот такая нехитрая конструкция позволяет, не нарушая правила отрасли, работать так, как нам нужно.
Отдельная история в данном случае с обеспечением того, что бы наверняка забронировать оба плеча. Тут похитрее, так как запросы в GDS платные. Но все зависит уже от того, какие именно источники получения предложений на авиауслуги вы используете, поэтому оставим данную тему.
Эта технология позволяет комбинировать перелеты различных авиакомпаний даже при отсутствии между ними соглашения и единых тарифов. Комбинировать, в смысле сформировать предложение на перелет, который выполняется с пересадками, т.е. если нет устраивающего вас прямого рейса и нет интересных пересадок, соберите себе предложение сами и получите вариант, который вас устраивает.
В этой схеме имеется засада, а именно обеспечение размещения пассажира при задержке рейса. Кто разместит пассажира, если задержат один из рейсов и кто возместит потери, если пассажир прилети Москва-Лондон, рейс Лондон-Эр-Риад задержат, и пассажир не успеет на рейс Эр-Риад-Джида, авиакомпании знать не знают про все эти стыковки и ничего пассажиру не должны. Но это уже бизнес технологии, а у нас тут ИТ ресурс.
Виртуальный интерлайн особенно интересен для аэропортов, имея подобную систему, можно расширить свою маршрутную сеть, включив перелеты фактически по всему миру. Но и конечно, наш любимый, агентский сайт (или просто агентство).
Правило — каждое полетное плечо это отдельная услуга, с точки БД, отдельная запись в таблице services. И с точки зрения сервисной модели, это разные услуги, которые могут независимо друг от друга обрабатываться, влияя, в основном сами на себя. И тип перелетов у них ровно тот, что передается в PSS, в основном OW. И PNR у каждого плеча свой. При кейсе, когда мы бронируем стандартный многосегментный перелет, т.е. по интерлайн соглашению, то записи в таблице на каждое плечо, а вот service_id у них общий, т.е. это единая услуга (как и PNR), а записи, ну так мы добиваемся стандартизации + мало ли что мы потом на придумываем на радость путешественнику, нужно атомизировать перелеты, с тем, что бы потом легче манипулировать данными. И не забудьте, в поле segment_number вписать номер полетного сегмента. И соответственно — если комбинировали сами, то билет выпускаем каждому сегменту; если же по интерлайн соглашению выпускаем единый билет, так сказать по количеству уникальных service_id.
Но это только записи в БД. Дальше интереснее, а именно — БАГАЖ, это на самом деле повод для отдельной статьи. Но поскольку тут мы не проектируем, а рассказываем, как про текущий тренд в одном из веточек великого дерева IT-технологий, то с нас хватит сказать, что самое сложное в данном деле — что делать с багажом.
Комментарий: только не в Шарль-де-Голле, тот очень большой, я ровно так опоздал на пересадку, хвала а…, в смысле толстой негритянке, которая меня всучила на борт, прямо на взлетной полосе.
Не вдаваясь в детали, скажем: надо интегрироваться с несколькими системами управления багажом, для обеспечения автоматизированной перегрузки багажа. Но тут опять явно выходим за рамки небольшой статьи. Укажем только, что в ныне действующих системах, после первого полетного сегмента, необходимо будет получить багаж в аэропорту, а потом сдать его снова на следующий сегмент. Что увеличивает минимальное время стыковки (грубо говоря, вам нужен не час на перегрузку багажа, а час на получение + час на сдачу), и вообще не use friendly.
Пример третий — корзина с добавление не авиауслуг
Читайте в следующей статье…
Один из последних трендов — это единая корзина. Смысл корзины (единой / мульти, читатель может добавить определения исходя из своих предпочтений) простой — создать возможность, для путешественника, бронировать (оплачивать) бронировать, как авиауслуги, так и всяческие не авиа (аренда авто, проживание, трансфер и т.д.), накидывая их, как в интернет магазине, в единую корзину.
Я вам расскажу, про камни о которые спотыкается развитие данных технологий
Для авиаперевозок (технологическом лидере отрасли) все началось примерно 10 лет назад, когда American Airlines пытался продавать с online полный набор услуг; препятствий возникло множество:
- От сопротивления конкурентов — толи 200, толи 300 туристических агентств (с рассказа участника написания петиции) писали жалобу в сенат США (на тему гибели бизнеса туристических агентств);
- Но самое главное, на пути начинания American Airlines встала технологическая неготовность отрасли.
Путь к единой корзине
Год 2014, IATA (международная организация, устанавливающая стандарты в авиации) анонсирует в привычном месте проведения авиафорумов, в отеле Авиастар (там я услышал, впервые в публичном пространстве, данный термин) переход на новый стандарт NDC. И показывает картинку — корзинка, в которую сложены самые разнообразные услуги. Именно так в индустрию путешествий пришла корзина покупателя из e-commerce.
Комментарий: NDC — глобальная инициатива всемирной организации авиации, технологическая основа — переход от использования телеграмм к xml протоколу обмены данных. XML конечно упрощает интеграцию. Но основная цель — это рынок дополнительных услуг, его потенциал $150 млрд в год, а главное — билеты приносят очень маленькую маржу, а дополнительные услуги от 5 % (что уже выше доходности билетов), до 50 %. По словам владельца одного из американских туристических агентств — в их бизнесе авиабилет, это как молоко в супермаркете, денег не приносит, но должно присутствовать на полке, деньги же в другом.
Год 2017, запускаем первую единую систему дистрибуции товаров для путешественника, с единой корзиной — к авиабилету в корзинку можно положить: проживание, аренду авто, трансфер, Аэроэкспресс, страховки (а так же дополнительные сервисы к каждой из этих базовых услуг).
Год 2018, готовлюсь к презентации на авиафоруме в Казани, делаю картинку, про то, как удобно устроено у нас: накидал услуг в корзинку и заплатил одним платежом, и как неудобно в S7, где каждая услуга, это отдельная покупка. Иду на сайт S7, перепровериться, не был на сайт пару месяцев, а там то же самое — можно купить единой корзиной сразу несколько услуг. Пришлось, в качестве плохого примера, использовать сайт Внуково.
Год 2019, все начали работать по такому же стандарту, проектов завершённых пока немного, но только лично я знаю 4 проекта, которые в работе. Самое крупное — проект построения импортозамещающей GDS (какой не скажу, их две, запрещает всемогущий NDA).
Говоря просто: продажа через единую корзину — тренд. И тот, кто сегодня не научится работать с корзиной, завтра вынужден будет искать другую работу.
И вот тут то мы подошли к интересному — а как реально происходит переход к единой корзине.
Комментарий: персонажами выступят сотрудники крупной и уважаемой ИТ компании. Это знающие и неглупые люди. Все нелепости, описанные в статье, происходят из обычной зашоренности мышления.
На первый взгляд все хорошо — GDS переходят на xml, меняют структуры бронирования, проекты плодятся, всё чтобы жить по современному. Есть конечно аутсайдеры, вроде Leonardo PSS (Passenger Service System — это система в которой авиакомпания хранит все свои ресурсы: борта, рейсы, места; а хорошая PSS еще много что имеет), системы свежей, всего 5 лет ей. И тем не менее построенной на допотопных телеграммах, и про изыски NDC совсем не знающей. Это творение наших дней даже выгрузку расписания не умеет выполнять в автоматическом режиме, отгружают в ручную и зачастую кнопку нажать забывают и расписание не приходит, и тут включается ручная процедура созвона.
Но это аутсайдеры, живущие с импортозамещения. В целом… И тут не все хорошо. Этой осенью мне довелось задать вопрос главному технологу большого проекта построения российской системы бронирования (современной, даже с претензией на инновационность), какой подход они собираются использовать — GDS или маркетплейс. И тут напоролся на ответ: что в отрасли все уже есть и не надо тут ничего выдумывать. Первая мысль была: неудачно / не вовремя спросил. Но после нескольких подобных столкновений и после моих безуспешных объяснений, что дают современные подходы (это были столкновения не с одним сотрудником) я осознал глубину закостенелости отрасли.
И поэтому излагаю пару кейсов, для чего нужны подходы маркетплейса и что они дают (намеренно в корзине оставляю только авиауслуги, с тем что бы примеры были ярче, но глобальные масштабы это приобретает при наличии не авиауслуг). В примерах используются кейсы агентской схемы продаж.
Пример первый — подбор перевозки туда и обратно
Заходим на один из самых распространенных поисковиков — aviasales (простите ребята, я вас уважаю, это не камень в ваш огород) и ищем Москва-Стамбул, туда и обратно. Находим пачку предложений, но ни одно из них нас не удовлетворяет. Тут же мне хочется, как путешественнику, комбинировать перелеты самому. Но не дают. Почему? Очень просто.
Для туда и обратно GDS требует сформировать бронь RT – (round trip ticket) – авиабилет в обе стороны, т. е туда и обратно. Это не всегда возможно. Самый простой пример — вы агентский сайт и у вас несколько источников получения предложений на перелет. И Москва — Стамбул у вас в одном источнике. А Стамбул- Москва, у вас, в другом источнике. GDS говорит- ну что тут поделаешь… Но у нас то корзина маркетплейса и мы формируем нужный нам набор туда и обратно, и создаем две брони с типом OW – (one way ticket) – авиабилет в одну сторону, и присылаем пассажиру 2 маршрут квитанции. Все удобно, платиться одним взмахом.
Соответственно в заказе (для перелета туда и обратно), в нашей системе мы должны сформировать запись в таблицу orders: Заказы. В качестве основного идентификатора у нас используется не традиционный PNR, а order_n — номер заказа. И две записи в таблицу services: Услуги, обе с ссылкой через order_id на orders. В поле type_flight, для заказа, сформированного по правилам GDS, мы ставим признак типа перелета rt, не по правилам ow, в поле PNR в первом случае один идентификатор, во втором другой идентификатор. Тоже самое с ссылками на электронный билет и маршрут квитанцию.
Вот такая нехитрая конструкция позволяет, не нарушая правила отрасли, работать так, как нам нужно.
Отдельная история в данном случае с обеспечением того, что бы наверняка забронировать оба плеча. Тут похитрее, так как запросы в GDS платные. Но все зависит уже от того, какие именно источники получения предложений на авиауслуги вы используете, поэтому оставим данную тему.
Пример второй — виртуальный интерлайн
Эта технология позволяет комбинировать перелеты различных авиакомпаний даже при отсутствии между ними соглашения и единых тарифов. Комбинировать, в смысле сформировать предложение на перелет, который выполняется с пересадками, т.е. если нет устраивающего вас прямого рейса и нет интересных пересадок, соберите себе предложение сами и получите вариант, который вас устраивает.
В этой схеме имеется засада, а именно обеспечение размещения пассажира при задержке рейса. Кто разместит пассажира, если задержат один из рейсов и кто возместит потери, если пассажир прилети Москва-Лондон, рейс Лондон-Эр-Риад задержат, и пассажир не успеет на рейс Эр-Риад-Джида, авиакомпании знать не знают про все эти стыковки и ничего пассажиру не должны. Но это уже бизнес технологии, а у нас тут ИТ ресурс.
Виртуальный интерлайн особенно интересен для аэропортов, имея подобную систему, можно расширить свою маршрутную сеть, включив перелеты фактически по всему миру. Но и конечно, наш любимый, агентский сайт (или просто агентство).
Перейдем к технической части
Правило — каждое полетное плечо это отдельная услуга, с точки БД, отдельная запись в таблице services. И с точки зрения сервисной модели, это разные услуги, которые могут независимо друг от друга обрабатываться, влияя, в основном сами на себя. И тип перелетов у них ровно тот, что передается в PSS, в основном OW. И PNR у каждого плеча свой. При кейсе, когда мы бронируем стандартный многосегментный перелет, т.е. по интерлайн соглашению, то записи в таблице на каждое плечо, а вот service_id у них общий, т.е. это единая услуга (как и PNR), а записи, ну так мы добиваемся стандартизации + мало ли что мы потом на придумываем на радость путешественнику, нужно атомизировать перелеты, с тем, что бы потом легче манипулировать данными. И не забудьте, в поле segment_number вписать номер полетного сегмента. И соответственно — если комбинировали сами, то билет выпускаем каждому сегменту; если же по интерлайн соглашению выпускаем единый билет, так сказать по количеству уникальных service_id.
Но это только записи в БД. Дальше интереснее, а именно — БАГАЖ, это на самом деле повод для отдельной статьи. Но поскольку тут мы не проектируем, а рассказываем, как про текущий тренд в одном из веточек великого дерева IT-технологий, то с нас хватит сказать, что самое сложное в данном деле — что делать с багажом.
Комментарий: только не в Шарль-де-Голле, тот очень большой, я ровно так опоздал на пересадку, хвала а…, в смысле толстой негритянке, которая меня всучила на борт, прямо на взлетной полосе.
Не вдаваясь в детали, скажем: надо интегрироваться с несколькими системами управления багажом, для обеспечения автоматизированной перегрузки багажа. Но тут опять явно выходим за рамки небольшой статьи. Укажем только, что в ныне действующих системах, после первого полетного сегмента, необходимо будет получить багаж в аэропорту, а потом сдать его снова на следующий сегмент. Что увеличивает минимальное время стыковки (грубо говоря, вам нужен не час на перегрузку багажа, а час на получение + час на сдачу), и вообще не use friendly.
Пример третий — корзина с добавление не авиауслуг
Читайте в следующей статье…
