Перевага API: підключайтеся, автоматизуйте та процвітайте

Golden Dayz / Shutterstock.com

AeroTime раді вітати Енн Седерхолл як нашого оглядача. Викладач IATA зі стратегії дистрибуції авіакомпаній і Aeroclass з роздрібної торгівлі авіакомпаніями, Енн часто є доповідачем і учасником дискусії на галузевих заходах. Вона є автором численних високо оцінених статей і офіційних документів для туристичної преси. Як один із власників консалтингової фірми LeapShift , Енн має великий послужний список надання бізнес-цінності на посадах управління проектами та продуктами по всьому світу.   

Погляди та думки, висловлені в цій колонці, належать виключно автору та не обов’язково відображають офіційну політику чи позицію AeroTime. 

Багато хто дивується, коли я кажу їм, що більшість авіакомпаній у світі не орієнтуються на API (інтерфейс прикладного програмування). Це, як правило, розглядається як «ще одна функція» в їхній PSS (системі обслуговування пасажирів), а не як пріоритет основного бізнесу. Коли керує PSS, комерційні умови є звичайними.  

Ще більш дивним є те, скільки авіакомпаній навіть не мають API; вони не розробляли веб-сервіси для прямого спілкування. Це дуже далеко від наративів ініціатив Міжнародної асоціації повітряного транспорту (IATA) NDC і ONE Order . 

Я постійно повторюю, що дуже важливо контролювати свій розподіл, і тому API має значення.   

Але навіть для тих авіакомпаній, які мають API, дивно, як вони не мають можливості обмінюватися даними та надсилати їх продавцям. Продавцю потрібна інформація на квитку (або запис про покупку) та оновлення змін. Як завжди, лідерами є недорогі авіакомпанії (LCC), їхні прямі продажі мають найбільше значення, тому наявність API є обов’язковою умовою, а також спілкування з іншими постачальниками та продавцями. 

Дивно, що так багато авіакомпаній кажуть: «Ми дозволяємо нашому постачальнику PSS керувати нашим API, як нашим API NDC». Я також вважаю дивовижним те, що авіакомпанії говорять про конкретних турагентів онлайн і навіть називають їх у контрактах. У світі, що постійно змінюється, де придбання відбувається зліва направо і в центрі, уникати вузьких визначень – це хороший крок. 

Було цікаво спостерігати, як Ryanair йде ва-банк з усіма партнерами, з якими хоче працювати. Впроваджуючи API, перевізник повністю контролює, хто продає його вміст. Але, звичайно, є недолік – впровадження API займає багато часу.   

Час для впровадження складних туристичних API виникає не лише через технічну складність, а й через складність бізнес-процесів. Давайте розберемо це. Отримання комерційних угод може зайняти тижні та місяці електронних листів, дзвінків і особистих зустрічей. А як щодо власне інженерних робіт? Я звернувся до співробітників Trapi, які провели дослідження користувачів, опитавши понад 100 інженерів з інтеграції API для подорожей, і середній термін інтеграції типового API для подорожей становить 59 робочих днів, тобто 11,8 тижнів, або приблизно три місяці. 

А тепер ти думаєш, що все готово, чи не так? Ні... наступний крок, можливо, один із найболючіших: сертифікація. На це можуть знадобитися тижні та місяці додаткових електронних листів, дзвінків і зустрічей, щоб постачальник API перевірив і переконався, що інтеграція, здійснена його клієнтом, відповідає стандартам і містить усі обов’язкові вимоги, встановлені постачальником API. 

Коли ви працюєте з API, подорож тільки починається. Поглиблення інтеграції за допомогою додаткових/нових функцій або оновлення до нових версій API може зайняти дуже багато часу та займати значний відсоток пропускної здатності ваших інженерних команд. 

Найважливішим питанням для авіакомпанії є те, чи є вона експлуатаційною компанією, туристичною технологічною компанією чи обома? Дуже небагато є тим і іншим.  

Для ІТ-магазину вам потрібні архітектори, інженери API, менеджери з продуктів, технічні менеджери з успіху клієнтів (CSM), щоб побудувати та справді масштабувати бізнес на основі API. Якщо у вас немає ресурсів, вам потрібно знайти постачальників, з якими можна працювати, але важливо розуміти, що ви повинні брати участь і допомагати постачальнику. Коли ви порівнюєте постачальників, вам потрібно зрозуміти їхній досвід інтеграції.  

Якщо ви продавець, як-от TMC (компанія з управління подорожами) або онлайн-агент, вам потрібно віддати пріоритет найважливішому. Чи має сенс використовувати агрегатор, який пропонує кілька з’єднань, наприклад GDS (Global Distribution Systems), LCC, вміст NDC? Вам потрібно порівняти комерційні рішення з прямими підключеннями, які пропонують набагато вищу маржу, але передбачають вищу складність.  

Лише в туристичних технологіях існує понад 2000 API, що робить цю галузь однією з найбільш щільних галузей API. Існують API для пошуку рейсів, бронювання, з’єднань з GDS, прямих з’єднань авіакомпаній, оптових рейсів, прямих готелів, готелів GDS, оптових готелів, автомобілів, залізниці, наземного транспорту. Інструменти, які вам потрібно інтегрувати, наприклад управління витратами та аудит, тури, враження, оплата. І я не охопив їх усіх. У нас також є API для автоматизації. 

GDS, чесно кажучи, був чудовим інструментом для агрегування даних і обробки цих даних, але він був побудований на основі PNR-орієнтованої технології 1960-х, 70-х і 80-х років із використанням телетайпу, EDIFACT і обміну повідомленнями типу B. Це нерентабельно і бореться з усім, що не визначено в середовищі PNR. Те саме стосується більшості PSS – стандарти обміну повідомленнями залишають місце для вдосконалення. Наразі ми бачимо, як GDS конкурує з власним бізнесом і пропонує рішення NDC, але ми бачимо незначну модернізацію обміну повідомленнями чи зв’язку PSS API.  

Я не сумніваюся, що з часом ми перейдемо до сучасного світу продажу подорожей, що означатиме агрегацію вмісту або, радше, полегшення пошуку та вказівки на вміст. У майбутньому, можливо, нам навіть не знадобиться агрегувати, лише використовувати покажчики. Є так багато вмісту, до якого я хотів би легко отримати доступ, наприклад, порівняння приватних чартерних рейсів із регулярними рейсами. Створити величезний всеохоплюючий ринок — це велика амбіція, але, можливо, нереальна. не знаю Але я знаю, що спілкування за допомогою API — це шлях вперед. 

Модернізація може стосуватися не лише перших стратегій API, а й змін у пошуку. Чи дозволять більші можливості обробки даних покращити пошук? Я завжди запитую, чому нам потрібно обробляти всі тарифи між парою міст, а потім фільтрувати результати. Чи не слід застосовувати фільтри з самого початку? 

Але давайте повернемося до вимог авіакомпанії. З чого почати?  

Ось питання, які ви повинні поставити собі: 

• Чи бажаєте ви поширювати напряму та кому? Агенти? Корпоративним клієнтам? Туристи? Щоб зважитися на це, потрібен бізнес-кейс.  

• У вас є API чи ні? І чи є у вас якісь обмеження щодо його використання? Якщо ви так, вам потрібно спланувати, як ви вносите зміни. Наприклад, якщо ви перебуваєте в угоді про повний вміст, то вам, швидше за все, не потрібне пряме розповсюдження.  

Вам також потрібно спланувати всередині (люди, процес, технологія), щоб здійснити перше розповсюдження API. Дуже багато авіакомпаній, яких я зустрічаю, кажуть: «Нам просто потрібен API схеми NDC». Вибачте, це проста частина. Решта набагато складніше.  

Найбільшою перешкодою для NDC є нездатність авіакомпаній масштабувати свої продукти API. У них немає ні ресурсів, ні процесів, ні технологій. Я чув, як компанії середнього розміру, які займаються продажем подорожей, розповідали мені, що існує список очікування від 12 до 18 місяців, щоб потрапити на їхній API, і це навіть не включає фактичний графік інтеграції. Це означає, що авіакомпанія де-факто обмежує доступ агентства.   

Також дуже важливо добре подумати, чому вам потрібна стратегія прямого розподілу. Моєю негайною відповіддю на це буде зниження витрат і продаж вмісту так само, як на вашому веб-сайті. Вам потрібно порівняти постачальників і мати чітке уявлення про структуру витрат. Ви можете стверджувати, що, конкуруючи з самими собою, GDS повинні знизити витрати та покращити вміст і процеси, але це вам потрібно оцінити.  

Незалежно від прямого розповсюдження, вам потрібно визначити, які API потрібно реалізувати. Я завжди рекомендую вам використовувати оркестровку (OMS – систему керування замовленнями), оскільки це значно полегшує роботу.