Персонализация не бесплатна. Сколько на самом деле стоит собрать такую систему внутри авиакомпании

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

Цифры выглядят приятно. Но есть один вопрос.

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

Мы с MBA-командой попробовали посчитать эту сторону задачи. И опять девушки стали задавать вопросы:

И здесь экономика становится заметно менее красивой.

Мы не стали оценивать абстрактный «ИИ-проект».

Пошли снизу вверх: что действительно понадобится авиакомпании, если она решит собрать собственный сервис персонализации?

Схема довольно приземлённая.

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

Для шестимесячной разработки у нас получилась такая основная команда

Получается 12,5 FTE основной команды. Но этим дело не заканчивается. Кусочками нужны архитектор по безопасности, Data Governance, Legal/Privacy и эксперты по программе лояльности, бронированию и продаже дополнительных услуг.

И здесь возникает первый неприятный вопрос:

Мы не использовали ни дешёвый оффшор, ни зарплаты конкретной авиакомпании. За основу взял рыночные ориентиры UAE 2025 года.

Только труд команды на этапах разработки и эксперимента даёт около 3,31 млн AED.

На этом месте финансовую модель очень легко сделать красивой.

Берём зарплаты. Умножаем на FTE. Получаем стоимость разработки.

Мы решили так не делать.

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

Последняя строка мне особенно нравится. Потому что её можно либо забыть совсем, либо написать в Excel что-нибудь вроде корпоративные накладные расходы = 25%.

Мы попробовали разложить её руками.

Наверняка в конкретной авиакомпании цифра будет другой. Но по крайней мере теперь понятно, что именно мы считаем.

Вот здесь получилось почти смешно.

Мы заложили Claude для всей основной команды: девять интенсивных пользователей на более дорогом тарифе и пять — на стандартном.

Разработчики, Integration, Data, QA и DevOps получают максимальный доступ. Product, Delivery, Architect и аналитики — стандартный.

За девять месяцев получается примерно 49,6 тыс. AED.

На фоне нескольких миллионов стоимости команды — почти погрешность. Можно долго спорить, даст AI разработчику 10%, 20% или 40% производительности. Но у меня после расчёта появился немного другой вопрос.

Мне кажется, это уже интереснее дискуссии о стоимости токенов.

Следующий кандидат на огромную статью расходов — инфраструктура.

Но здесь есть ловушка.

Если проект запускается внутри большой авиакомпании, у неё уже существуют хранилища данных, BI, контейнерная платформа, мониторинг, Service Desk и другие корпоративные системы.

Покупать их второй раз специально для персонализации в финансовой модели странно.

Поэтому мы считали только дополнительное потребление, вызванное проектом.

На разработке — около 2,5 тыс. AED в месяц.

На эксперименте — 4,5 тыс.

Здесь уже есть production decisioning/API, среды разработки и тестирования, пакетный скоринг, служебная БД, хранение данных, мониторинг, сетевой трафик и некоторый запас.

За девять месяцев получается всего 28,5 тыс. AED.

И возникает довольно забавная картина. Мы называем это ИИ/ML-персонализацией.

Но основные деньги уходят не в ML и не в cloud.

Первую фазу мы заложили на шесть месяцев. И это не шесть месяцев работы Data Scientist над красивым notebook.

Нужно собрать сервис принятия решений, интеграции, конвейер данных, модели propensity, экспериментальный контур, интеграцию с Web и Mobile, мониторинг и основу дальнейшей эксплуатации.

С учётом команды, найма, оборудования, корпоративных расходов, AI и инфраструктуры этап разработки получается примерно 3,97 млн AED.

Вот первая действительно неприятная цифра. И, на наш взгляд, полезная. Потому что после неё фраза:

Следующие три месяца — эксперимент.

Полная команда разработки уже не нужна.

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

Стоимость трёх месяцев эксперимента получается около 746 тыс. AED.

Итого до перехода в нормальную эксплуатацию:

Теперь можно вернуться к тем самым 182 и 406 тысячам дополнительной выручки. И посмотреть на них ещё раз.

На двух пилотных маршрутах при +10% к доле покупателей модель даёт около 589 тыс. AED дополнительной выручки за три месяца.

У платного выбора места дополнительная себестоимость очень небольшая: пассажир всё равно летит и всё равно получает кресло.

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

Поэтому в рабочей модели мы пока используем маржинальность 95% для выбора места и 70% для дополнительного багажа.

Это именно модельные предположения, а не раскрытая экономика Emirates.

На фоне 4,72 млн первоначальных затрат выглядит скромно. Но здесь очень легко задать неправильный вопрос.

Мы считаем НЕТ.

DXB–RUH и DXB–BOM нужны не для того, чтобы за три месяца вернуть разработку.

Они нужны, чтобы проверить главное:

Потому что настоящий актив здесь — не два маршрута.

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

После эксперимента экономика меняется. Начинается Run.

После завершения эксперимента мы ещё раз пересобрали команду.

Теперь деньги.

Вот эта цифра мне уже нравится гораздо больше.

Сопоставим две цифры. Маржинальный вклад DXB–RUH и DXB–BOM при нашем базовом сценарии: ≈471 тыс. AED за три месяца. Стоимость эксплуатации: ≈586 тыс. AED за те же три месяца.

Получается, что два пилотных маршрута покрывают примерно 80% Run.

Если очень грубо пересчитать эффект в «эквивалентные маршруты», operational break-even находится примерно на уровне 2,5 маршрута масштаба нашей текущей пары.

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

На DXB–RUH в модели около 60,8 тыс. пассажиров Economy за три месяца, базовая склонность к покупке выбора места — 20%, багажа — 8%. На DXB–BOM — около 108,4 тыс. пассажиров, а рабочая гипотеза по склонности к покупке выше в 1,25 раза: 25% и 10%. Поэтому Mumbai даёт не просто больше пассажиров.

Здесь есть важное ограничение модели. Сейчас мы считаем экономику проекта: какая доля ресурсов действительно занята созданием и эксплуатацией продукта. Например, если после Build архитектор нужен продукту только на 0,1 FTE, именно эту долю мы относим на Run. Но есть и более жёсткий взгляд финансового директора. Если 14 человек были наняты исключительно потому, что мы решили запустить этот продукт, компания физически платит им полную зарплату, даже когда продукт использует только часть их времени. Это уже другой взгляд — корпоративный денежный поток, а не аллокация стоимости проекта. И его мы ещё отдельно посчитаем. Поэтому называть нынешние цифры ROI, IRR или сроком окупаемости пока рано. До них мы ещё не дошли.

Сейчас у нас появились три опорные цифры. Build + Experiment — 4,72 млн AED. Run — около 195 тыс. AED в месяц.

Маржинальный вклад двух пилотных маршрутов — около 471 тыс. AED за три месяца при базовом сценарии.

Дальше начинаются вопросы, которые нам как раз интереснее всего.

И наконец:

Вот туда мы пойдем дальше. Потому что считать NPV персонализации на двух маршрутах сейчас действительно рано.

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