Последнее интервью a16z: считать SaaS умершим еще рано, а главной преградой внедрения ИИ уже не является интеллектуальный уровень моделей

Столкнувшись с крайней паникой на открытом рынке по поводу «разрушения SaaS ИИ», партнер a16z Алекс Рампел считает, что такие опасения проистекают из нереалистичного статического мышления, по сути встроенные в бизнес-процессы, которые обрабатывают реальную ситуацию, не исчезнут, а наоборот — ждут взрывного роста денежного потока.

6 марта известная инвестиционная компания a16z и генеральный директор Atlassian Майк провели глубокий разговор о текущем нарративе о «катастрофе SaaS», вызывающем сильное внимание на открытом рынке.

Участники считают, что, текущая паника несколько оторвана от реальности: ИИ не является концом SaaS, а скорее катализатором ускоренной дифференциации отрасли; будущее конкуренции в программном обеспечении зависит не только от возможностей моделей, но и от барьеров бизнес-логики и психологических аспектов ценообразования.

Большая дифференциация оценки SaaS: кто обнуляется, а кто получит взрывной рост денежного потока?

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

Первый — крайне опасные компании, связанные с аккаунтами и результатами, например Zendesk. Алекс говорит:

«Zendesk — это здесь ‘пациент номер один’. Если клиенты Zendesk сейчас используют Sierra, Decagon или выбирают собственные решения, их потребность в аккаунтах может быть равна нулю.»

Для таких компаний, если не перейти на результатно-ориентированное ценообразование и не полностью изменить текущую модель, «эта часть дохода полностью обнуляется».

Второй — это системы ядра бизнеса с очень сильными барьерами, такие как Workday. Эти системы, казалось бы, тоже взимают плату за аккаунты, но это лишь «умная стратегия ценообразования», а их настоящая защита — внутренние скрытые правила и «краевые случаи» (Edge cases), встроенные в систему на десятилетия. Алекс подчеркивает:

«Многие программы — это на самом деле набор определенных правил, накопленных за десятилетия обучения и опыта… А что делать, если сотрудник из Индианы уходит в декретный отпуск? Или если он уволился, а еще в отпуске? Пока вы лично не столкнетесь с этим, вы и не узнаете о таких краевых случаях.»

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

«Настоящие ядра бизнеса, с высокой привязкой, зависимые и встроенные в систему все краевые случаи — это будущее…Когда это действительно произойдет, денежный поток значительно возрастет, и это меня потрясло.»

Третий — продукты промежуточного типа, такие как Adobe. В эпоху ИИ спрос на эти продукты снизится, но ситуация не так экстремальна, как у Zendesk, и не так безнадежна, как у Workday. Воздействие на них — промежуточное.

Почему клиенты не любят «по результатам и по токенам»?

С распространением ИИ фронтенд-приложения и базы данных постепенно отделяются друг от друга, и модели ценообразования программного обеспечения сталкиваются с серьезными вызовами. В обществе растет спрос на переход к «по расходам (Token/Points)» или «по результатам» ценообразованию, но на практике сопротивление очень велико.

Майк остро отметил психологию клиентов:

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

Он объясняет, что, традиционное облачное хранение — управляемое, а мир токенов ИИ — черный ящик для клиента.

«Клиенты не понимают, что такое эти токены или жетоны… Я могу за ночь увеличить расход их лимита в десять раз, просто добавив функции вроде генерации отличных сводок. Клиенты почувствуют, что я этого не просил.»

Кроме того, оплата по результатам (например, по экономии затрат) в первый год — хорошая продажная аргументация, но со второго года клиенты считают, что база уже снизилась, и трудно продолжать измерять добавленную ценность ИИ. Поэтому Майк делает вывод:

«Когда вы говорите с клиентами, они все равно хотят платить за аккаунты (seats). Возможно, потому что сейчас им проще понять такую модель, и их уже обманули многими схемами оплаты по расходам.»

Vibe Coding не заменит ядро бизнес-процессов

В техническом сообществе популярна гипотеза «замещения», что с помощью AI-программирования (Vibe Coding) компании смогут писать код самостоятельно и полностью заменить все традиционные SaaS-инструменты. Майк прямо говорит, что эта идея нереалистична.

Майк отмечает, что ядро знанийных компаний — это координация тысяч ограниченных входов (например, юридические, клиентские одобрения) и ограниченных выходов (например, R&D, маркетинг).

«Лично я очень не люблю термин ‘ядро бизнес-системы’, потому что он звучит как статическая база данных… Для меня бизнес — это система, основанная на процессах, а не на записях.»

Истинное изменение, которое дает AI-программирование, — это не переписывание Workday с нуля, а возможность на базе этих систем быстро и с минимальными затратами создавать высоко кастомизированные приложения. Майк говорит:

«Например, я хочу приложение для бронирования конференц-залов для команды Майами… Раньше я бы не смог его сделать… А сейчас, возможно, легко. В основе — данные и правила Workday по всему миру.»

Это делает крупные SaaS-компании «более привязанными и ценными на корпоративном рынке».

Последний километр внедрения ИИ: не интеллект модели, а дизайн доверия

Обсуждая будущее продукта, интервью показывает, что перед реальным внедрением ИИ в доходы стоит преодолеть «пробел» в пользовательском опыте. Текущие модели превосходят реальную ценность, а узким местом является дизайн UI/UX и механизмы доверия.

Майк отмечает, что внедрение агента (AI-агента) в сложные бизнес-процессы — это не вопрос вычислительной мощности, а вопрос устранения эффекта «черного ящика». Если ИИ мгновенно обработает десятки писем, пользователь скорее испугается, чем обрадуется.

«Обещать ‘я сделаю для вас все, что угодно’, — это только запутает пользователя.»

Будущее взаимодействия с программным обеспечением — это эволюция от «скеуморфизма» к первичным принципам. Например, в документообороте традиционный набор — печатание, верстка — заменяется моделью «слева — документ, справа — чат». Это кардинально меняет привычки пользователей, и хотя это очень сложно, это не только парадигмальный сдвиг, но и путь превращения потенциала ИИ в реальные подписки. Как говорит Майк:

«Реальность такова, что не каждая SaaS-компания сможет процветать в течение следующих десяти лет… Но для нас это — лучшее, что случалось в бизнесе.»

Исходный текст интервью:

Алекс: С 1960 по 2022 год вся история программного обеспечения — это превращение файловых шкафов в базы данных. Первый пример — система SABRE, разработанная IBM и American Airlines в 1960 году. Она заменила бумажные записи, хранящиеся в сейфах и управляемые секретарями, и перенесла эти данные в ранние базы данных. В те времена 10 МБ жесткого диска стоили миллиарды долларов. Аналогично развитию электронных медицинских карт — Массачусетский госпиталь разработал первую систему MUMPS. Аналогично Salesforce и первой CRM-компании 1987 года — все они по сути превращали файловые шкафы в базы данных.

Такой подход действительно имел преимущества, но не сделал мир значительно эффективнее. Раньше, чтобы найти информацию о Эрике, нужно было просить сотрудника из HR достать ее из файла. Сейчас данные в Workday, но для защиты системы нужен главный специалист по информационной безопасности, и IT-специалисты настраивают аккаунты (seats) в системе единого входа. Только при межрегиональном сотрудничестве эффективность возрастает: люди могут работать вместе и выполнять сложные соединения в базе данных, что было невозможно в эпоху бумажных документов. Но по сути, с 1960 по 2022 год программное обеспечение оставалось статичным, потому что файловый шкаф сам по себе не умеет думать.

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

Эрик: Это действительно хороший пример. Сейчас все обсуждают «конец SaaS» или даже «катастрофу SaaS», что очевидно связано с происходящим на открытом рынке. У многих разные мнения о его значении. Хотел бы услышать ваше понимание: что именно происходит? И как это понять? Почему все так боятся?

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

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

Текущая паника несколько нереалистична. Все думают: «Если через два-три года ИИ сможет реализовать какую-то функцию, что это значит?» Я считаю, что это порождает очень статическое мышление, будто люди не смогут адаптироваться, мир не изменится, и только одна технология — ИИ — будет меняться, а все остальное останется как есть. Поэтому ситуация очень интересная: такие компании, как наша, показывают отличные результаты уже три квартала подряд. Хотя мы не защищаем весь софт, по нашим бизнесам мы очень оптимистичны, и это подтверждается данными и результатами.

Конечно, это не значит, что мы не должны адаптироваться. Мы, как и в последние годы, быстро и кардинально меняем способы работы. Многие думают, что мы не можем или не умеем, что неправда, хотя впереди много стратегических перемен. Реальность такова, что не все SaaS-компании смогут процветать в течение следующих десяти лет. Как в переходе от эпохи Windows к эпохе интернета — многие не смогли перейти в облако, так и сейчас не все смогут. Есть мнение, что софт в какой-то момент исчезнет или станет просто источником дохода. Но я скажу за нашу компанию: это — лучшее, что с нами случалось. Мы живем в мире знаний, у нас есть инструменты для исследования и действия на основе знаний, чтобы выполнять задачи клиентов. Это логично и идеально, но нам нужно доказать это на практике, чтобы рынок сохранил терпение.

Эрик: Алекс, а ты? Как ты реагируешь на происходящее или как понимаешь текущие события?

Алекс: Я надеюсь, что мое долгосрочное мнение верно, потому что все, что происходит сейчас, — очень безумно. Несколько недель назад я написал твит по этому поводу, и заметил, что на рынке примерно три типа SaaS-компаний, которые рынок не умеет различать. Одна из них — с аккаунтами, привязанными к результатам, где аккаунты (seats) принадлежат реальным пользователям системы, что похоже на тот самый файловый шкаф.

Перед тем как углубиться, я хочу сделать шаг назад и ответить на твой вопрос. Дан Ариели написал отличную книгу «Предубеждения и иррациональность». Я часто ее рассылаю менеджерам по продуктам, чтобы они поняли, как правильно взимать плату с пользователей. В книге есть классический пример: представьте, что в полночь вы заперты вне квартиры, вызываете слесаря. Он приезжает за минуту, за 30 секунд открывает дверь и берет 500 долларов. Вы думаете: «За 90 секунд работы — 500 долларов? Что за бред!» — и оставляете ему один звездный отзыв, не даете чаевых и даже можете оспорить списание с карты.

А теперь представьте параллельную реальность: слесарь пришел, потратил 9 часов, чтобы открыть дверь. Он возвращается в офис за инструментами, работает до 9:30 утра, и наконец-то вы входите. Тогда вы будете благодарны за 9,5 часов работы, дадите ему 200 долларов чаевых и оставите пять звезд.

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

Если вспомнить, как мы пришли к модели SaaS, например, по подписке за аккаунт (seats), то при бесплатном использовании расходы на цифровую настройку почти нулевые. Это не универсально, просто так кажется справедливым. Например, у вас 500 аккаунтов, и вы платите больше, чем за один, хотя механизмы работы одинаковы.

Поэтому я считаю, что SaaS можно условно разделить на три типа. Первый — компании, у которых раньше были аккаунты (seats) для выполнения определенных задач, а теперь они им не нужны. Zendesk — здесь «пациент номер один». Если клиенты Zendesk сейчас используют Sierra, Decagon или делают собственные решения, их аккаунтов (seats) может быть ноль. Для Zendesk речь идет о будущем денежном потоке — его настоящей стоимости. Они в опасности, потому что, если продолжать взимать плату за аккаунты (seats) по подписке, не меняя код и ценообразование, доход полностью исчезнет. Но если перейти на результатно-ориентированное ценообразование и отказаться от старой модели, доход может вырасти в 3-4 раза. Это все равно зависит от справедливости и предсказуемой иррациональности. Продукт типа Zendesk может как расти, так и падать, но без изменений — путь к нулю.

Второй — это модели ценообразования за аккаунт (seats), которые кажутся справедливыми, но аккаунты (seats) не связаны с результатом. Например, Workday взимает плату за 340 тысяч сотрудников по модели «за человека в месяц». Почему? Не знаю, просто кажется справедливым. Но эти сотрудники не используют Workday для достижения результатов. В целом, Workday хорошая система, и тут важно, что можно делать с ИИ. Например, при найме сотрудников HR должен просматривать документы в Workday и звонить трем компаниям для проверки, чтобы убедиться, что резюме — подлинное. ИИ может делать это автоматически, если это ядро системы. Сейчас IT-проекты упали на 45%, но никто не отказывается от QuickBooks. Эти два типа — платформа за аккаунт (seats) и привязка к рабочей нагрузке — — это умная стратегия ценообразования.

Третий — продукты промежуточного типа, такие как Adobe. Можно потреблять больше или меньше аккаунтов (seats), ситуация не так экстремальна, как у Zendesk, и не так безнадежна, как у Workday.

Вне этих категорий есть еще одна идея — что с помощью ИИ можно писать весь код. Как опытный разработчик, я считаю, что это абсурд. Хочу привести пример теории сравнительных преимуществ Дэвида Рикардо 1817 года: вы можете выращивать зерно или сваривать алюминий, но даже эти простые случаи не подходят. Это как в нашем подкасте: у меня есть сравнительное преимущество — я делаю его лучше и зарабатываю больше, даже если я более продуктивен, чем сантехник, я все равно должен заниматься подкастом.

Важнее всего — это скрытые краевые случаи. Теоретически, я могу с помощью ИИ автоматизировать некоторые процессы Workday, но что делать, если сотрудник из Индианы уходит в декрет? Или если он уволился, а в отпуске? Пока вы лично не столкнетесь, не узнаете.

Многие программы — это набор правил, накопленных за десятилетия, — не публичных, встроенных в систему. Их нельзя просто скопировать, нужно накапливать опыт. Если задача очень простая и без краевых случаев, ИИ справится.

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

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

Майк: Мне очень не нравится термин «ядро бизнес-системы», потому что он звучит как статическая база данных, куда что-то кладешь и извлекаешь. Это — взгляд на бизнес как на архив, что очень устарело, особенно в эпоху цифровых технологий.

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

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

Почему это важно? Потому что у нас есть разные типы процессов — входные и выходные. Например, служба поддержки Zendesk — это входной процесс: клиенты задают вопросы, и скорость их обработки влияет на эффективность, стоимость, скорость и качество. Если вы ускорите обработку в 10 раз, количество вопросов не увеличится, потому что клиентов — фиксированное число. Вопрос — как уменьшить их число или ускорить обработку? В бизнесе много таких входных процессов.

Я всегда привожу пример нашей юридической команды: их задача — не создавать работу, а реагировать и обрабатывать. Например, сколько у нас договоров аренды? NDA? стандартных контрактов? Это — фиксированный объем. Мы стараемся делать это максимально эффективно, это — входной процесс с полным циклом. Но есть и выходные процессы — креатив, маркетинг, разработка, технологии — там можно делать бесконечно.

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

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

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

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

Что такое продукт нецифровых, нефункциональных компаний? Их активы — знания, накопленные веками или десятилетиями. Мне нравится Япония: есть рестораны, которые работают с 1587 года, и их долгосрочная история — часть культуры, знаний и навыков. У них есть рецепт приготовления лапши, и хотя это проще, чем сложные системы, там тоже могут быть крайние случаи. Например, что делать, если закончилось мука? Как они пережили голод 1623 года? Они, вероятно, приняли меры, и эти знания — в секретной книге рецептов, а не в публичных источниках.

Майк: Вот что делает это настолько увлекательным — это заставляет нас переосмыслить бизнес. Это — не просто налоговая декларация, которую заполняет Intuit, а уровень их знания о налоговом законодательстве, который недоступен никому. Их ценность — помочь вам обработать жизненные данные, структурировать понимание, задавать правильные вопросы, и в этом смысле они больше похожи на McKinsey. Их особенность — уметь задавать правильные вопросы, а не просто заполнять формы.

Сейчас все компании вынуждены переоценить себя. Возможно, у меня внутри 50 процессов, которые я считал уникальными, а на самом деле — только 20 из них — действительно ключевые. Теперь я должен серьезно подумать, какие из них — действительно уникальные, а какие — нет, потому что раньше я так не думал.

Алекс: Это — в какой-то мере вопрос баланса. Стоит ли делать все самому или доверить сторонним инструментам? Сейчас я должен писать код на Claude Code? Если какая-то компания слишком дорого стоит или может привести к провалу моего бизнеса, и я могу сделать 99% работы сам и покрыть расходы, тогда — да, писать свой код имеет смысл. Но если этот софт стоит всего доллар в год, то — нет.

И не все ценности систем учета равны. Я склонен считать, что системы учета — это атомы бизнеса. Например, календарь — это учет времени, ERP — учет запасов. У вас есть все эти системы учета. Я приводил пример: у меня есть офис в Майами, который я редко посещаю, там есть система бронирования комнат, похожая на Google Calendar. Готов ли я тратить силы на его изменение? Очевидно, да, потому что я туда хожу раз в год, и мне все равно, насколько он стабилен.

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

Есть системы учета, которые более чувствительны к цене, потому что они — дорогие или содержат важную информацию. Например, Carta — это система учета долей акций для компаний. Как часто вы смотрите на структуру долей? Не очень часто, но очень важно — нельзя ошибиться. Поэтому я скорее буду продолжать использовать Carta, потому что они недороги, и это — не продукт с высокой частотой использования, и он не входит в список заменяемых.

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

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

Сейчас с помощью vibe code можно расширять и настраивать приложения под конкретные задачи. Например, я хочу приложение для бронирования конференц-залов для команды Майами. В Майами есть странные HR-политики, и это приложение для 20 человек должно постоянно получать данные из Workday и других систем. Раньше я бы не мог его сделать, потому что стоимость внутренней разработки была бы слишком высокой, а сейчас — легко. В основе — данные и правила Workday по всему миру, но интерфейс — очень кастомизированный, чтобы решать конкретные задачи Майами. Это очень мощно, но полностью заменить человека не может.

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

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

Алекс: Вот почему мне интересно, как различия между фронтендом и бэкендом влияют на справедливость ценообразования. Например, Salesforce взимает плату за лицензии. У нас в компании примерно 600 человек, и, скорее всего, купили 600 лицензий. Я никогда не входил в Salesforce, но уверен, что компания платит за меня, потому что это — наш учетный регистр. И я иногда использую его выводы, потому что он — наше хранилище данных. Не хочу злоупотреблять словом, но он хранит все наши бизнес-отношения, и я — часть таблицы базы данных, например, пользователь №422.

Каждый раз, когда я взаимодействую с компанией, это — как сопоставление в другой базе данных, и мы платим за один базовый источник. Сейчас мы живем в мире, где фронтенд и бэкенд постепенно отделяются, и это — реальность. Мне кажется, что Workday придумал очень умную стратегию ценообразования — это мощная и справедливая модель. Чем больше сотрудников, тем больше платишь, — почему это справедливо? Потому что прибыль GE явно больше, чем у компании из 10 человек, и GE должна платить больше, хотя эта сумма — ничтожна для них. Их цена — в золотой зоне, и я думаю, никто не возражает. В будущем они увеличат доходы от ИИ, но самое главное — их базовая цена кажется очень справедливой.

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

Для меня, если фронтенд перестанет быть синонимом бэкенда, это — более уязвимый и чувствительный к изменениям сценарий, чем тесное соединение. Например, QuickBooks используют малый бизнес, у них нет понятия аккаунтов (seats), и владельцы компаний просто заходят в систему. В этом смысле фронтенд — это часть бэкенда. В отличие от Salesforce, где, хотя никто не откажется полностью, они могут значительно сократить число аккаунтов (seats), потому что бэкенд остается важным, а потребность в дорогом фронтенде снижается. Они не удаляют бэкенд и не меняют его, а только оптимизируют фронтенд.

Майк: Я всегда считал, что справедливость ценообразования и восприятие клиентами — очень важны. Люди должны понимать, за что они платят, и чувствовать, что их расходы соотносятся с реальным использованием. Компания с 10 тысячами сотрудников, покупая Workday, скорее заплатит вдвое больше, чем маленькая, с учетом скидок за объем, потому что у них больше сотрудников и сложнее бизнес. Это — принцип, который кажется справедливым: я готов платить за HR по численности сотрудников.

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

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

Предположим, у Salesforce есть MCP-сервер, который не обращается напрямую к базе данных, а управляет бизнес-процессами и правилами. В чем сейчас спор? В том, нужны ли этим отделам, например, в маркетинге или работе с клиентами, тяжелые процессы, управление, контроль и правила? Например, система говорит, что в Японии мы предоставляем только X, а Y — только для других клиентов, и даже для этого нужен отдельный аккаунт (seats). А справедливо ли такое? — вопрос открытый.

Да, вопрос — как это ценообразовать. Я скажу: при обсуждении потребительского ценообразования или по требованию, результатное ценообразование во многих случаях — разумное, но я не считаю, что оно станет доминирующим или применимо ко всему SaaS.

Потому что, когда вы общаетесь с клиентами, они очень не любят такие схемы, особенно с звездочками и условиями. Это — не связано с ценностью, которую они вкладывают. Например, я использую Splunk по модели «по объему логов»: если я увеличу объем логов вдвое, я заплачу больше. Я понимаю логику, но объем логов — это мой выбор. Я могу логировать больше или меньше, могу сказать команде: «Зачем так много логов? Это дорого, и вы действительно их используете?» — и контролировать расходы. Это — аналогия с хранением данных в S3 или других сервисах: я могу залить 1 ГБ или 2 ГБ, и это — управляемо.

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

Я могу получить 1 ГБ хранилища в AWS и развернуть его в Azure, и знаю, сколько за это заплачу, потому что цена за ГБ — фиксирована. Но когда у меня есть эти лимиты ИИ, я не знаю, такие ли они, как у других. Провайдер постоянно добавляет новые функции, мои пользователи используют их, расходуя лимит. Но я не знаю, что именно они делают.

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

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

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

Последний пример — результативное ценообразование: эти результаты — динамичны. Например, в службе поддержки я экономлю деньги: раньше тратила 20 долларов, теперь — 10. В первый год это — отличный аргумент. Но во второй год клиент скажет: я потратил 10, хочу 5, иначе — никакой ценности. А поставщик ответит: если я вас исключу, вы заплатите 20. Тогда клиент скажет: «Но я сейчас плачу 10». И так — способность экономить деньги каждый год — очень сложна для оценки, даже если я избавляю от рутинных задач.

Алекс: Я считаю, что с точки зрения продаж это тоже так. Я основал две платежные компании. Очень завидую Workday: я часто говорю своей команде, что они знают все о клиентах, и знают, сколько зарабатывают на GE. Они говорят: у GE — 330 тысяч сотрудников, и мы можем брать по 5 долларов за каждого в месяц. Это — очевидный источник дохода.

Если продавать софт таким образом, масштабировать продажи проще. Потому что ты знаешь, что эта компания заплатит 3 миллиона долларов. А когда мы только начинали, подписали 1800 компаний, и не знали, сколько заработаем. А реально запустил бизнес Casper — это производитель матрасов. Изначально было трудно предсказать, потому что казалось, что крупные клиенты — Walmart или другие, а в итоге — подписав Casper, бизнес взлетел.

У Workday есть такая двунаправленная предсказуемость: для инвесторов — предсказуемо, для руководства — тоже. Можно сосредоточиться на подписании крупных клиентов вроде GE, а не мелких. В интернете ситуация очень хаотична: Stripe может зарабатывать больше с 10-человечной компании, чем с GE. В такой модели — выше уровень предсказуемости.

Но ценообразование по результату или по расходам — это не всегда хорошо. Если нельзя понять, сколько зарабатывает аккаунт (seats), расширение продаж и маркетинга — становится очень сложным.

Эрик: Как предприниматель, я хочу вернуться к вопросу: что для вас самое важное в этом новом мире? Как это изменило ваш бизнес?

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

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

Именно поэтому мы создаем AI Gateway, командные карты и системы корпоративного соответствия и контроля. Их нужно отделять от функций, которые мы создаем для конкретных приложений. Где их размещать? Что именно они делают? Большая часть — в существующих рабочих потоках, чтобы помочь клиентам делать их быстрее, лучше, качественнее и эффективнее. Эти функции — очень простые, как анимация на 30 секунд, которая стала вирусной. Но для клиента это — очень важно, потому что он может сразу использовать, и его работа становится лучше. В мире ИИ это — довольно простое решение, и оно реально помогает.

Я часто говорю, что недостаточно просто привести пример в сервисе, нужно использовать их существующие процессы, объединять их с новыми приложениями или новыми рабочими потоками. Поэтому мы делаем все это. Например, в Jira — это типичный пример: в наших HR и IT-сервисах идет автоматизация заявок. Это — то, что мы можем делать лучше, чем раньше.

Внутри команды есть 4-5 человек, которые работают с одним заявлением, пытаются решить проблему. Когда подключается четвертый человек, уже много вложений и переписки. Обычно нужно 30 минут, чтобы прочитать все и понять, что произошло, и применить знания. Итог — не просто сводка, а контекст, который важен для модели. Это — не просто ввод текста и получение резюме. Контекст — очень важен, и он не меняется. Это — Алекс просит Эрика помочь с заявкой. Эрик должен загрузить всю релевантную информацию. Это — существующий рабочий поток, который мы можем улучшить с помощью LLM, и клиенты очень довольны. Но эти функции — без интеллекта.

Тогда мы можем сказать, что для этого рабочего потока нужны агенты на каждом этапе. Большинство людей работают с потоком, и часто сталкиваются с проблемой: этот шаг — очень долгий и сложный. Можем ли мы его ускорить? Это — то, что мы должны делать.

У нас есть отличный фреймворк для агентов, связанный с картой знаний и контекстом. Это — очень просто и недорого. Или можно