a16z：Коли UI більше не є продуктом, що залишається від конкурентної переваги програмного забезпечення?

Від редактора: За останні двадцять років, захисний вал SaaS значною мірою базувався на UI. Панелі інструментів, поля, процеси затвердження та звички користувачів — це не лише інтерфейс для операцій, а й формують спосіб роботи організацій та порядок даних. Коли AI може безпосередньо зчитувати дані, викликати інструменти та виконувати процеси, залежність від людської пам’яті стає менш важливою, і UI більше не є обов’язковим ядром корпоративного програмного забезпечення.

Це не означає, що системи запису втратили цінність, а швидше, що їх захисний механізм переміщується: від UI та звичок використання — до моделей даних, систем доступу, відповідальності за відповідність, бізнес-логіки, циклу виконання та мережі багатосторонньої співпраці. У майбутньому справжні бар’єри у програмному забезпеченні можуть більше не базуватися на базі даних для запису людської роботи, а на системах дій, здатних захоплювати контекст, ініціювати завдання, координувати інтелектуальні агенти та постійно генерувати нові дані під час виконання.

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

Нижче наведено оригінальний текст:

Минулого місяця Salesforce оголосила про відкриття API та запуск безінтерфейсного (headless) продукту. По суті, це означає, що Salesforce робить ставку: у епоху агентів їхня основна цінність більше не з UI, а з рівня даних. Це досить розумна переорієнтація.

Однак також потрібно зазначити, що з технічної точки зору цей реліз, здається, не приніс значних змін. API, яке Salesforce зараз перепакувала під назвою «headless продукт», багато років існувало і раніше. Іншими словами, це більше схоже на типовий маркетинговий реліз Salesforce.

Основна ідея нового продукту полягає в тому, що агент може безпосередньо отримувати доступ до даних системи запису, не використовуючи інтерфейс, орієнтований на людину. Традиційний UI допомагав користувачам слідкувати за процесами, керувати завданнями та просувати робочі потоки; але після появи агентів ця необхідність у такому рівні інтерфейсу починає зменшуватися.

Дійсно важливе питання, яке варто обговорити, полягає не лише у тому, що Salesforce випустила новий продукт, а й у тому, що вона підняла більш глибоку проблему: якщо зняти UI і відкрити лише базу даних, що тоді залишається у системі запису? Чи залишаються між цим і базою даних Postgres, добре спроектованою схемою даних та набором API суттєкі відмінності?

Більше того, чи залишилися чинники, що забезпечували довгострокову захищеність системи запису? Чи з’явилися нові стандарти конкуренції?

У епоху SaaS системи запису мають захисний вал, тому що людські користувачі довго працювали у їхньому інтерфейсі. Інтерфейс формував звички, організаційні процеси та накопичення даних, що створювало високі витрати при міграції. Але в епоху агентів ця перевага починає слабшати. Справжні рівні захисту переміщуються: з одного боку — у моделі даних, системи доступу, логіку робочих процесів і відповідальність за відповідність; з іншого — у мережеві ефекти, унікальні здатності генерувати дані та здатність виконувати дії у реальному світі.

Коли програмне забезпечення стає безінтерфейсним, куди саме переміститься захисний вал?

UI колись був самим продуктом

Так звані системи запису (System of Record, SoR) — це авторитетне джерело фактів щодо певних бізнес-даних. Це місце, де зберігаються офіційні версії клієнтських відносин, записів співробітників або фінансових транзакцій, і це ядро систем, з яких інші інструменти зчитують і записують дані. CRM — це система запису даних про доходи, HRIS — про персонал, ERP — про фінанси та бухгалтерію.

Міцність цих систем полягає не лише у тому, що вони зберігають дані, а у тому, що вони в кінцевому підсумку стають «реальністю», на якій базується вся організація.

За останні двадцять років Salesforce пропонувала клієнтам спосіб керувати командами продажів. Панелі інструментів, воронки продажів, інструменти прогнозування, динамічні потоки інформації — це справжній продукт, який купують. Її бізнес-модель базується на продажу ліцензій, які надають доступ до функцій. Базова база даних — важлива, але у досвіді користувача вона швидше є прихованою інфраструктурою.

Отже, справжнім драйвером залученості користувачів є UI.

UI обмежує стандарти даних, формує спільну мову: ліди, можливості, клієнтські рахунки. Він дозволяє тисячам продавців постійно вводити дані, які вони не завжди хотіли б вводити. Раніше UI був механізмом підтримки цілісності та доступності даних. Salesforce має таку сильну залученість, що багато керівників продажів після переходу до нової компанії продовжують використовувати Salesforce, і це не через його чудовий інтерфейс, а через те, що він став для них «м’язовою пам’яттю».

Але агенти починають руйнувати цю модель. Вони більше не потребують взаємодії через UI, вони можуть безпосередньо зчитувати і записувати дані у базу. Це сприяє появі нових інструментів і альтернатив, що обходять традиційний інтерфейс. Salesforce — не єдиний приклад: недавно ми обговорювали, що навколо SAP зростає ціла екосистема, більш пристосована для викликів AI.

Тим часом, агенти, що можуть керувати комп’ютером, зменшують значущість людських факторів — переваг, навчання, не задокументованого контексту. Іншими словами, умови для довгострокової захищеності системи запису змінюються.

Попередні критерії оцінки

Перед тим, як говорити про зміни у епоху агентів, потрібно точніше повернутися до питання: що саме раніше робило систему запису стійкою?

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

Перший — наскільки часто її використовують?

CRM щодня використовують відділи продажів і інші підрозділи. Саме ця висока частота використання робить її критичною інфраструктурою. Але саме організаційна інерція — наприклад, регулярні наради, звички роботи, управлінські ритми — є найскладнішою для перенесення, і часто її навіть не усвідомлюють як щось, що потрібно переносити.

Другий — чи система лише записує, чи ще й читає?

Дійсно стійка система запису — це система з двонапрямним потоком даних. Візьмемо CRM: вона не лише зберігає дані, а й постійно їх використовує. Кожен дзвінок, оновлення статусу, створення завдання — все це вводиться користувачем, і користувач зацікавлений у тому, як ці дані будуть використовуватися далі.

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

На відміну від цього, системи відстеження кандидатів (ATS) зазвичай ближчі до систем «тільки для запису». Після прийняття або відмови кандидатів, ці дані мають менше значення для подальшого використання.

Третій — скільки не задокументованих SOP?

Ключовий бізнес-контекст часто не записаний у wiki, а закладений у правила робочих процесів, створені адміністраторами та системними інтеграторами роками.

Наприклад, у системі продажів: це може бути необхідність схвалення VP для угод понад 100 тисяч доларів; перевірка приватності для транзакцій у регіоні EMEA; знижки для стратегічних клієнтів, які можна отримати лише наприкінці кварталу.

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

Четвертий — наскільки складні внутрішні або зовнішні залежності?

Головне питання: скільки внутрішніх систем, командних процесів або зовнішніх сторін залежить від цієї системи запису?

Внутрішня зв’язність — скільки downstream-систем або робочих процесів залежить від неї?
Зовнішня — чи потрібно аудиторам, бухгалтерам, регуляторам безпосередньо доступ до даних? ERP — класичний приклад.

Чим вища зв’язність, тим складніше при міграції розбирати та відновлювати ці зв’язки.

П’ятий — наскільки важливі дані з точки зору відповідності?

Головне питання тут — чи є ця система критичною для відповідності?

Наприклад, системи зарплат, ERP, HR — це системи, що мають юридичну вагу і вимагають строгого контролю доступу. Міграція таких систем може залучати аудиторів і регуляторів, що підсилює їхню захищеність.

З іншого боку, системи для обліку продажів або підтримки клієнтів (Zendesk) — це важливі, але менш критичні системи. Вони забезпечують контекст і безперервність, але при міграції даних або зміні доступу ризики для регуляторів зазвичай мінімальні.

Не всі системи запису мають однакову ступінь витрат при переході. Порівняння CRM і ATS у цій площині показує значну різницю.

ATS — це workflow-система для рекрутингу. Після прийняття або відмови кандидатів, дані стають одноразовими записями. Її інтеграція вузька, користувачів менше і вона більш сфокусована.

ERP — це зовсім інший рівень. Головна книга — це аудитний слід, і аудитори, регулятори — безпосередні зацікавлені особи у процесі міграції.

Заміна ATS — болюча, але можлива. Заміна CRM — це як операція на відкритому серці. Заміна ERP — це як робити відкриту операцію під час марафону.

Традиційно системи запису не використовували переваги власних даних або мережевих ефектів; зазвичай, робочі процеси самі по собі створювали бар’єри. В деякому сенсі, поєднання інструментів і мереж — це більше споживчий рівень; історичні системи SoR не йшли цим шляхом.

Власні дані. Багато систем запису накопичили великі обсяги клієнтських даних, але не використовували їх глибоко, і в багатьох випадках контрактні умови забороняли це робити. Тому, хоча CRM має багатий набір даних і теоретично може аналізувати їх для отримання міжклієнтських інсайтів, на практиці цього ніколи не робили у справді значущому масштабі. Salesforce Einstein — один із таких експериментів.

Мережеві ефекти. Для систем запису ідеальним захисним валом був би мережевий ефект: наприклад, CRM стає ціннішою, коли продавці можуть знайти покупців у системі. Але, як і з даними, мережеві ефекти у систем запису історично були слабкими або майже відсутні.

Якщо UI зникне, і з’являться агенти, що залишиться у програмному забезпеченні?

Агенти не потребують браузера. Їм потрібні API, контекст, команди та здатність виконувати дії. Є дві ключові речі, що дозволяють масштабувати цей процес: по-перше, LLM вже має достатню здатність до логіки, тому агент може зчитувати контекст, планувати, обирати інструменти, виконувати дії та аналізувати результати — і в більшості випадків вже не потрібно людське втручання; по-друге, стандарт MCP уніфікує спосіб доступу до інструментів, надаючи універсальний інтерфейс для виклику зовнішніх можливостей.

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

Загалом, у покупця програмного забезпечення є три шляхи:

Перший — продовжувати використовувати існуючі системи і накладати агентів.
Через CLI та API існуючих систем можна використовувати їхні власні агенти, наприклад Salesforce Agentforce, SAP Joule, або створювати власних агентів. Тут припускається, що API є повними і доступними, і ігнорується складність headless у реальній експлуатації.

Другий — повністю самостійно створити систему запису.
Компанія може з нуля розробити свою модель даних, логіку роботи, системи доступу, аудиту та Agent-стек, можливо, з використанням сторонніх інструментів для розробки агентів і баз даних.

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

Отже, які критерії з попередніх стандартів залишаться?

Фактори, що залежать від людської поведінки та звичок, з часом зменшаться, наприклад, частота використання, двонапрямний характер запису.
Агенти, можливо, зменшать цінність «м’язової пам’яті» як бар’єра, але не знищать захисний механізм бізнес-логіки та контексту. Навпаки, вони зроблять ці логіки ще важливішими, оскільки для безпечного виконання завдань агенти повинні орієнтуватися на чіткі правила, системи доступу та процеси.

Не задокументовані SOP залишаться важливими у короткостроковій перспективі.
Організаційна пам’ять у правилах робочих процесів — це те, що потрібно агентам для правильного виконання завдань. Це також найскладніша частина для відтворення, і наразі її важко повністю експортувати, особливо коли частина процесів залишається людською. Однак, захоплення контексту стає все простішим; з поширенням агентів, що замінюють людську працю, ця важливість зменшуватиметься.

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

CRM-агент має з’єднати дані та контекст продажів, виставлення рахунків, підтримки клієнтів.
Якщо ваша платформа стане вузлом для транзакцій між кількома зовнішніми організаціями — покупцями, продавцями, партнерами — залежність посилюється.

Коли існуючі постачальники додають агентів, може бути важко забезпечити плавну взаємодію між об’єктами та логікою різних систем; якщо компанія використовує лише власну базу даних і набір агентів, проблеми аналогічні.

Ключові дані для відповідності все ще важливі.
Дані, що стосуються регуляторів, ризиків або юридичних аспектів, мають бути у єдиному, надійному джерелі фактів. Якщо клієнти довіряють існуючим продуктам, перехід на нову систему малоймовірний.

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

У світі, де все автоматизовано агентами, одне з найскладніших питань — хто і що має право робити? Хто від їхнього імені діє? Як це контролювати і аудіювати? Якщо система запису стане ідентифікатором і рівнем доступу для агентів, вона отримає справжню, важко замінну структурну роль. Бар’єр тут — не лише у тому, які дані вона має, а у тому, яку довіру вона забезпечує.

Загалом, для AI-стартапів важливими стануть нові фактори, що визначатимуть їхню здатність створювати захист.

Перший — наскільки складно відновити цю систему запису?

Дані стануть ще важливішими на кількох рівнях.

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

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

Одночасно, нові компанії вже відновлюють дані з пошти, телефонів, голосових агентів і внутрішніх документів. AI знижує вартість відновлення 80% системи запису. Важливіше — залишкові 20%: виняткові ситуації, процеси затвердження, вимоги до відповідності та крайні випадки.

По-друге, чи є у вас справді унікальні, цінні дані?

Дані стають ще ціннішими, якщо вони унікальні і створюються саме вашою компанією. Це так званий «захищений даний сад» — дані, що є власністю, під регуляторним контролем або потребують постійного оновлення. Компанія, яка інвестує у збір авторитетних і повних даних, має явну перевагу над конкурентами, що використовують загальні або менш повні набори.

Ще один аспект — чи залежить дані від внутрішніх дій продукту?

Найкращі компанії не просто зберігають дані, а й постійно генерують нові сліди даних у процесі роботи: поведінку, відповіді, часові моделі, результати процесів, галузеві бенчмарки, аномалії та траєкторії агентів.

Ключове — дані сьогодні є контекстом.

По-третє, чи маєте ви рівень дій?

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

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

З часом, із накопиченням контексту і обробкою крайніх випадків, їхня цінність зростатиме.

Четвертий — чи включає система елементи реального світу?

Деякі бізнес-моделі тісно пов’язані з операціями у реальному світі, і ці процеси не можна повністю автоматизувати. Яскравий приклад — компанії з мережею операцій, наприклад DoorDash. Вони не є системами запису, але мають важливе значення.

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

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

П’ятий — чи є мережеві ефекти?

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

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

Можливі підходи: спільна робота у процесі, обмін контекстом, обробка винятків; або ж — створення галузевих стандартів і рекомендацій, що підсилюють довіру і знижують бар’єри для участі.

Третій — чи маєте ви достатньо технічних ресурсів?

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

Вартість також важлива. Самостійне створення може зменшити ліцензійні витрати, але збільшує витрати на впровадження, підтримку і складність.

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

Додатково, важливі й інші фактори, що з часом стануть базовими вимогами:

Наприклад, онтологія має змінитися. Багато ідей щодо «самостійного створення баз даних» недооцінюють цінність об’єктної моделі. Традиційне програмне забезпечення орієнтоване на інтерфейси для панелей і звітів, воно фіксує об’єкти робочих процесів — можливості, заявки, кандидатів.

У епоху агентів схема має охоплювати логіку логіки, дії, відстеження стану, обробку винятків, делегування завдань і міжсистемну координацію. Об’єктна модель може змінитися: замість можливостей, заявок і кандидатів — задачі, наміри, потоки, стратегії або результати.

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

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

Отже, яка ж висновок?

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

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

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

Ще цікавіше, що найперспективніші компанії будуть виходити на рівень реального світу: координувати польових працівників, логістичні служби, сервісні команди або фізичні активи, або виступати посередниками між кількома учасниками.

Ці компанії поєднуватимуть старі бізнес-моделі з новими. А ядро традиційних систем запису — дані — поступово відійде на задній план, ставши базою для функціонування всієї системи.

[Посилання на оригінал]

Клікніть, щоб дізнатися про вакансії в BlockBeats

Запрошуємо приєднатися до офіційної спільноти BlockBeats:

Telegram підписка: https://t.me/theblockbeats

Telegram група: https://t.me/BlockBeats_App

Офіційний акаунт у Twitter: https://twitter.com/BlockBeatsAsia