[Из песочницы] Сложности корзины интернет-сервиса
Интернет сервисы для бронирования услуг путешественнику становятся все изощреннее.
Один из последних трендов — это единая корзина. Смысл корзины (единой / мульти, читатель может добавить определения исходя из своих предпочтений) простой — создать возможность, для путешественника, бронировать (оплачивать) бронировать, как авиауслуги, так и всяческие не авиа (аренда авто, проживание, трансфер и т.д.), накидывая их, как в интернет магазине, в единую корзину.
Я вам расскажу, про камни о которые спотыкается развитие данных технологий
Для авиаперевозок (технологическом лидере отрасли) все началось примерно 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.
Пример третий — корзина с добавление не авиауслуг
Читайте в следующей статье…
