Редакційна примітка: Протягом останніх двох десятиліть бар’єри для входу в SaaS значною мірою ґрунтувалися на інтерфейсі. Панелі інструментів, поля, робочі процеси та користувацькі звички — це не просто інтерфейси взаємодії, а й фактори, що формують спосіб роботи організацій та порядок даних. Коли AI зможе безпосередньо читати дані, викликати інструменти та виконувати процеси, залежність від м’язової пам’яті людини почне зменшуватися, і інтерфейс більше не буде обов’язковою основою корпоративного програмного забезпечення.
Це не означає, що система запису втрачає цінність, а лише те, що її захист зміщується: від інтерфейсу та звичок використання до моделей даних, системи прав доступу, відповідальності за відповідність, бізнес-логіки, замкненого циклу виконання та мережі багатосторонньої співпраці. Майбутніми програмами з реальним бар’єром можуть стати не просто бази даних, що фіксують роботу людей, а дієві системи, здатні фіксувати контекст, запускати завдання, координувати агентів і постійно генерувати нові дані в процесі виконання.
Коли програмне забезпечення переходить до headless (позбавлення інтерфейсу), основна проблема корпоративного програмного забезпечення також змінюється: цінність більше не полягає лише в тому, хто володіє даними, а в тому, хто може організувати дії навколо даних.
Нижче наведено оригінал:
Минулого місяця Salesforce оголосила про відкриття API та запуск headless (безінтерфейсного) продукту. Сутність цього полягає в тому, що Salesforce робить ставку на те, що в епоху агентів її основна цінність більше не походить від інтерфейсу, а від шару даних. Це досить розумне переорієнтування.
Тим не менше, слід зазначити, що з технічної точки зору цей запуск, схоже, не приніс значних змін. API, які Salesforce зараз позиціонує як «головні продукти», насправді існують уже багато років. Іншими словами, це більше схоже на типове Salesforce-подібне маркетингове оголошення.
Основна ідея цього нового продукту полягає в тому, що агент може безпосередньо отримувати доступ до даних у системі реєстрації, не маючи потреби взаємодіяти через інтерфейс, розроблений для людей. Традиційний інтерфейс призначений для того, щоб допомогти користувачам-людям відстежувати процеси, керувати завданнями та просувати робочі процеси; однак після введення агента необхідність цього рівня інтерфейсу починає зменшуватися.
Справжнім предметом обговорення цього випуску є не те, які нові продукти представив Salesforce, а те, що він поставив більш фундаментальне питання: якщо відкинути інтерфейс і відкрити лише базу даних, що залишається в системі реєстрації? І наскільки вона відрізняється від бази даних Postgres, добре спроектованої схеми даних та набору API?
Більш того, чи залишаються в силі класичні фактори, які раніше забезпечували довгострокову захищеність системи реєстрації, чи з’явилися нові стандарти конкуренції?
У епоху SaaS бар’єри для входу існували через те, що користувачі довгий час працювали в інтерфейсі системи. Інтерфейс накопичував звички, організаційні процеси та дані, що створювало високі витрати на міграцію. Але в епоху агентів ця перевага зникає. Справжні бар’єри для входу зараз зсуваються: з одного боку — вниз до моделей даних, систем прав доступу, логіки робочих процесів та здатності до відповідності; з іншого — вгору до мережевих ефектів, здатності генерувати власні дані та виконання дій у реальному світі.
Коли програмне забезпечення переходить до headless, куди зміститься конкурентна перевага?
UI колись був самим продуктом
Система записів (System of Record, SoR) — це авторитетне джерело даних для певного типу бізнес-інформації. Це місце, де зберігається «офіційна версія» даних про клієнтів, працівників або фінансові транзакції, а також центральна система, з якої інші інструменти отримують дані та записують їх назад. CRM є системою записів для даних, пов’язаних із доходами, HRIS — для даних, пов’язаних із персоналом, а ERP — для даних, пов’язаних із коштами та фінансами.
Сила цих систем полягає не лише в тому, що вони зберігають дані, а в тому, що вони в кінцевому підсумку стають «єдиним джерелом істини», на яке спирається вся організація.
Протягом останніх двадцяти років Salesforce продавала клієнтам не саме програмне забезпечення, а набір інструментів для керівників продажів, які допомагають керувати командами. Реальними продуктами, які купуються, є інформаційні панелі, вигляди каналів продажів, інструменти прогнозування та динамічні стрічки новин. Бізнес-модель побудована на продажу місць користувачам, які надають доступ до цих функцій. Нижчий рівень бази даних, хоча й є ключовим, у досвіді користувача виглядає як прихована інфраструктура.
Тобто саме інтерфейс забезпечує лояльність користувачів.
Інтерфейс обмежував дані, сформував спільну мову: ліди, можливості, облікові записи клієнтів. Він дозволив тисячам продавців постійно вводити дані, які вони іншими були б не згодні вводити. Раніше інтерфейс був механізмом, що забезпечував консистентність і доступність даних. Salesforce має таку високу лояльність, що багато керівників з продажів залишають його в нових компаніях після зміни роботи — не тому, що його інтерфейс чудовий, а тому, що він став м’язовою пам’яттю.
Але агенти починають змінювати цю модель. Їм більше не потрібно взаємодіяти з програмним забезпеченням через інтерфейс — вони можуть безпосередньо читати та записувати дані нижчого рівня. Це також призвело до появи нового покоління інструментів та альтернатив, які обходять традиційні інтерфейси. Salesforce — не єдиний приклад: ми недавно обговорювали, як навколо SAP формується цілий екосистема, яка краще підходить для викликів штучного інтелекту.
Тим часом, агенти, які можуть керувати комп’ютером, зроблять традиційні людські фактори — такі як уподобання, навчання та недокументовані контексти — з часом все менш важливими. Іншими словами, умови, необхідні для створення сталого системи запису, змінюються.
Попередні критерії оцінки
Перш ніж обговорювати, що зміниться в епоху агентів, варто точніше повернутися до питання: що саме раніше робило системи запису в’язкими?
Перші кілька факторів стосуються переважно того, як люди використовують програмне забезпечення, а також їхніх власних уподобань. Програмне забезпечення важко замінити, оскільки воно в значній мірі залежить від інтерфейсу, звичок використання, робочих процесів людей та інституційних укладень, вбудованих у процеси організації.
Яка частота його відвідуваності?
CRM щодня використовується командою GTM та багатьма іншими відділами. Саме через таке часте використання він став критичною інфраструктурою. Але людський шар, побудований на ньому — наприклад, щоденні зустрічі команд, операційні звички, ритм управління та інші організаційні інercії, що сформувалися протягом років — часто є найскладнішою частиною для міграції. Причина в тому, що це навіть часто не визнається як «те, що треба перенести».
Друге, це лише запис, чи читання та запис одночасно?
Справжня в’язка системи запису зазвичай є двосторонньою системою читання та запису. Наприклад, CRM — це не лише система запису, призначена для архівування, а й система, яка постійно читається. Кожен запис дзвінка, кожне оновлення етапу, кожне створення завдання вводяться користувачем, який, як правило, також цікавиться тим, як ці дані будуть використовуватися пізніше.
Цей двосторонній потік означає, що будь-яка альтернатива повинна здатна приймати дані в реальному часі, а не лише експортувати історичні дані. Під час міграції майже немає абсолютно безпечного моменту для переключення. Тому, як тільки компанія завершує запуск, вона часто залишається у системі початкового постачальника на тривалий час.
Навпаки, системи відстеження кандидатів (ATS) зазвичай ближчі до систем «тільки для запису». Після того як кандидата було прийнято або відхилено, у компаній є відносно обмежені причини знову використовувати ці дані.
Третє, скільки не задокументованих SOP?
Справжні ключові бізнес-контексти часто не записані в жодному вікі, а накопичені у робочих процесах, створених адміністраторами та системними інтеграторами протягом років.
Наприклад, у системі продажів ці недокументовані контексти можуть включати: угоди на суму понад 100 000 доларів США потребують схвалення віце-президента; угоди в регіоні EMEA повинні пройти перевірку конфіденційності; знижки для стратегічних клієнтів можуть бути надані лише поза фінансовим схваленням наприкінці кварталу.
Ці контексти часто визначають, чи може бути вчасно розпочато чи завершено певне завдання без порушення ключових процесів. Міграція системи означає перезапис кожної автоматизованої правила; інакше компанія може втратити частину організаційної пам’яті.
Четверте, наскільки складними є внутрішні чи зовнішні залежності?
Основне питання полягає в тому, скільки внутрішніх систем, командних процесів чи зовнішніх зацікавлених сторін залежать від цієї системи реєстрації?
Внутрішня зв’язність — це кількість нижчестоячих програмних рішень або робочих процесів, які залежать від неї. Зовнішня зв’язність — це чи потребують зовнішні суб’єкти, такі як аудитори, бухгалтери, регулятори тощо, прямого доступу до даних у ній. ERP — це типовий приклад.
Чим вища зв’язність, незалежно від того, чи внутрішня, чи зовнішня, тим складнішими стають відносини, які потрібно розібрати та відновити під час міграції.
П’яте: як важливі дані з точки зору відповідності?
Проста суть проблеми: чи є ця система критичною з точки зору відповідності?
Такі критичні для відповідності системи, як системи оплати праці, ERP та дані з управління персоналом, повинні забезпечувати юридично обґрунтований джерело фактів та мати строгий контроль доступу адміністраторів. Будь-яке перенесення може вимагати безпосередньої участі аудиторів та регуляторних органів. Це робить їх значно більш прив’язаними.
Дані про продажі та інструменти підтримки клієнтів, такі як Zendesk, знаходяться на іншому кінці. Компанії, звичайно, цінують неперервність та контекст, але якщо дані мігрують або хтось отримує доступ до них, це зазвичай не викликає негайного регуляторного ризику.
Не всі системи запису мають однакові витрати на перехід. Порівняння CRM і ATS у одній групі вимірів виявляє очевидну різницю.
ATS — це інструмент робочого процесу, призначений для обмежених процесів, який зосереджений на рекрутації. Після того як кандидата прийнято або відхилено, відповідні записи більшістю стають даними з одноразовим записом. Його інтеграційний діапазон вужчий, а користувачі — менші та більш зосереджені.
ERP знаходиться на іншому полюсі. Генеральний журнал є саме аудиторським слідом, і бухгалтери, аудитори та регуляторні органи стануть безпосередніми зацікавленими сторонами в процесі міграції.
Заміна ATS — це болісно, але ще терпимо. Заміна CRM — як відкрита операція на грудях. А заміна ERP — це як робити відкриту операцію на грудях пацієнту, який біжить марафон.
Традиційно системи реєстрації не використовували справжніх джерел конкурентних переваг, таких як власні дані чи мережевий ефект; зазвичай сам процес роботи вже був достатнім бар’єром для входу. У певному сенсі, поєднання інструментів і мережі було більше характерним для споживчого бізнесу; історичні SoR не йшли цим шляхом.
Власні дані. Багато систем реєстрації, хоча й накопичили величезний обсяг даних клієнтів, не використовують їх глибоко, а в багатьох випадках умови договору не дозволяють цього робити. Тому, хоча CRM має багатий набір даних і теоретично може агрегувати дані різних клієнтів для отримання міжклієнтських інсайтів, вони ніколи не робили цього справді значущим чином. Звичайно, такі продукти, як Einstein від Salesforce, зробили деякі спроби.
Ефект мережі. Для системи записів ідеальним бар’єром для входу мав би бути ефект мережі: наприклад, CRM стає ціннішим, коли продавці програмного забезпечення можуть знаходити покупців усередині неї. Але, як і з даними, історично ефект мережі для систем записів був слабким, а можна сказати — майже відсутнім.
Якщо інтерфейс зникне, що залишиться в програмі після прибуття агента?
Агенту не потрібен браузер. Йому потрібні API, контекст, інструкції та здатність виконувати дії. Дві речі роблять можливим масштабування всього цього: по-перше, LLM вже мають достатньо сильні здібності до міркування, тому агенти зараз можуть читати контекст, розробляти плани, вибирати інструменти, виконувати дії та аналізувати результати, і більше не потрібно втручання людини у більшості завдань; по-друге, MCP стандартизував спосіб доступу до інструментів, надавши агентам загальний інтерфейс для виклику зовнішніх можливостей.
Агент з доступом до MCP може за мілісекунди масштабно виконувати дії, які раніше виконували людські користувачі на платформі, і не потребує браузера. За наявності достатнього контексту агент, здатний керувати комп’ютером, може безпосередньо використовувати існуючі інтерфейси програм, не обов’язково через API.
З точки зору простоти, у покупців програмного забезпечення зараз є три шляхи:
По-перше, продовжуйте використовувати існуючу систему та накладайте на неї Agent.
Використовуйте їх через CLI та API існуючих систем, щоб використовувати нативні продукти агентів виробників, такі як Agentforce від Salesforce або Joule від SAP, або створювати власні агенти на їх основі. Звичайно, тут припускається, що API є повним і доступним, а також ігнорується складність, яку може принести «головна» операція на практиці.
Друге, повністю власна система реєстрації.
Підприємства можуть створити власні моделі даних, логіку операцій, систему прав доступу, аудиторський слід, інтеграцію систем та власний стек Agent. Цей шлях, швидше за все, буде використовувати сторонні інструменти розробки Agent та баз даних.
Третє: купіть нативні альтернативи AI.
Компанії також можуть купувати нове покоління програмного забезпечення, спроектованого з самого початку для ери Agent. Такі продукти зосереджуються на машинній читабельності, вважаючи оркестрацію Agent первинною функцією, а не додаванням функції ШІ як патч до старих систем. Такі продукти також можуть бути headless.
Які елементи старої системи оцінювання будуть збережені?
Фактори, що визначаються людською поведінкою та уподобаннями, такі як частота відвідувань, двосторонні властивості читання-запису та інші показники, пов’язані з м’язовою пам’яттю людини, поступово зменшуватимуться. Агенти можуть зменшити цінність «м’язової пам’яті» як бар’єра, але не знищать бар’єри, пов’язані з операційною логікою та бізнес-контекстом. У певному сенсі, вони навпаки роблять цю логіку ще важливішою, оскільки для безпечного виконання завдань агенти повинні опиратися на чіткі правила, права та визначення процесів.
Недокументовані SOP залишаються важливими в короткостроковій перспективі.
Організаційна логіка, закладена в правилах робочих процесів, — це саме те, що потрібно Agent’у, щоб правильно виконувати завдання від вашого імені. Це також найскладніша частина для відтворення. Принаймні наразі її не можна чисто експортувати, особливо коли частина процесів все ще вимагає участі людини. Однак фіксація контексту стає все легшою; зі зростанням кількості завдань, які Agent замінює на людські, цей фактор поступово втрачатиме свою важливість.
Підключення все ще важко розібрати, і воно буде простиратися глибше.
Значення зв’язності змінюється. Вона більше не просто має допомагати людям у роботі, а й підтримувати зв’язок між функціями та програмним забезпеченням, які традиційно були розділені.
CRM-агент повинен поєднувати дані та контекст з різних етапів, таких як продажі, рахунки та успіх клієнта. Якщо ваша платформа також стає вузлом для транзакцій між кількома зовнішніми організаціями — наприклад, покупцями, продавцями та партнерами, які взаємодіють через неї — залежності ще більше ускладнюються.
При накладанні агентів від різних виробників може бути складно забезпечити плавну взаємодію між базовими об’єктами та логікою різних нижчих рівнів програмного забезпечення; компанії, які залежать лише від однієї власної бази даних та набору агентів, також стикаються з подібними проблемами.
Ключові дані щодо відповідності залишаються важливими.
Дані, що стосуються регуляторних органів, регуляторних ризиків або правових ризиків, все ще потребують єдиного надійного джерела даних. Якщо клієнти вже довіряють існуючим продуктам, вони менш схильні переключатися на інші системи.
Наприклад, з даними про заробітну плату та бухгалтерію, агент, можливо, дійсно потребує доступу до цих даних, але підприємства зазвичай не вибирають створення та довгострокове підтримання таких систем власними силами.
У світі, повністю орієнтованому на агентів, однією з найскладніших проблем є: яким агентам дозволено робити що? Від імені кого вони діють? Як можна аудитувати ці дії? Якщо система реєстрації зможе стати шаром ідентичності та прав доступу між агентами, вона отримає справжню, важко замінну структурну роль. Бар’єри тут — це не лише те, які дані вона зберігає, а те, яку архітектуру довіри вона реалізує.
Дивлячись вперед, для AI-ніжних стартапів набір нових факторів стане все більш важливим і вирішить, чи зможуть вони сформувати захист.
По-перше, наскільки складно відновити цю систему записів?
Дані стануть важливішими на кількох рівнях.
Спочатку, у короткостроковій перспективі, ключовим є ступінь складності витягування та відновлення даних нижчого рівня системи реєстрації. Штучний інтелект робить це простішим, і ряд інструментів допомагає користувачам виконувати такі міграції та відновлення.
У короткостроковій перспективі існуючі компанії можуть і, ймовірно, зроблять це складнішим: вони можуть зробити API незручним, обмеженим, неповним або економічно невигідним, або взагалі не надавати API. Але зі зростанням інstrumentів для вилучення даних, особливо з підвищенням здатності агентів, які можуть керувати комп’ютером, відновлення даних буде ставати все легшим.
Тим часом нова компанія також відновлює більш багатий набір даних з електронної пошти, телефонних дзвінків, голосових агентів та внутрішніх документів. Штучний інтелект знизив витрати на відновлення перших 80% системи реєстрації. Те, що розрізняє корисний підхід і справжню альтернативу, — це решта 20%: виняткові випадки, процеси схвалення, вимоги до відповідності та робочі процеси у крайніх сценаріях.
Друге, чи маєте ви справді значущі власні дані?
Друге, самі дані стануть більш цінними.
Справжніми захисними даними є не ті дані, які ви імпортуєте, а ті, які ваш продукт унікально сприяє створенню. Ми часто говоримо про «дані в замкненому саду»: ці дані є власними, підлягають регуляторним обмеженням або вимагають постійного оновлення. Програмний постачальник, який інвестує значні ресурси у збирання авторитетних та повних даних, має явну перевагу перед універсальними постачальниками або конкурентами, які не мають таких даних.
Дані також мають інший важливий напрямок: чи вони залежать від дій, що виникають всередині продукту.
Найкращі компанії не просто зберігають дані, введені ззовні. Вони створюють нові дані в процесі — наприклад, спостережені поведінкові шаблони, рівні відповідності, часові закономірності, результати процесів, галузеві показники, аномальні шаблони та траєкторії виконання агентів.
Суть у тому, що дані зараз — це контекст.
Третє, чи ви оволоділи рівнем дій?
У старому світі зберігання записів було достатнім. Але у новому світі агенти будуть діяти безпосередньо, і захисні механізми змістяться на продукти, які можуть створювати замкнений цикл: від дій до фіксації результатів і використання зворотного зв’язку для оптимізації майбутніх рішень.
Для ERP це може включати схвалення витрат, запуск виплати заробітної плати, перевірку рахунків, надсилання сповіщень тощо. Продукти, які забезпечують замкнений цикл, більш захищені, оскільки вони вбудовані в процес виконання, а не обмежуються лише спостереженням. Вони генерують унікальні дані, які покращуються з часом використання, і стають складнішими для заміни, оскільки їх видалення порушує робочий процес.
Звичайно, зі збільшенням обсягу контексту та кращою обробкою крайніх випадків цінність тут також зросте.
Четверте, чи містить він виконання у реальному світі?
Деякі бізнес-моделі пов’язані з операціями у реальному світі, які не можуть бути повністю автоматизовані. Найбільш очевидним прикладом є компанії, які володіють операційними мережами, наприклад DoorDash. Вони історично не належали до систем запису, але є дуже інформативними в цьому контексті.
У більш широкому сенсі будь-яка компанія, яка може розширити програмний цикл до сервісів, виконання замовлень, логістики, оперативної діяльності на місці або платежів, має захист, відмінний від чистого SaaS. Такі компанії не просто зберігають записи чи рекомендують дії; вони направляють персонал, переміщують вантажі або виконують конкретні сервіси.
Для підприємців це означає, що можливості можуть з’явитися на ринках, де програмне забезпечення все більше здатне приймати рішення, а агенти — координувати процеси, але останній кілометр все ще вимагає реального світового виконання. Наприклад, вертикальне програмне забезпечення, пов’язане з послугами на місці, є типовим напрямком.
П’яте: чи існує мережевий ефект?
Історично більшість систем реєстрації мали слабкий мережевий ефект, оскільки вони були переважно внутрішнім програмним забезпеченням. Але в епоху агентів, якщо система вбудована в багатосторонні робочі процеси, мережевий ефект може стати значно більш важливим.
Якщо система відповідає за посередництво у повторюваних взаємодіях між кількома сторонами, наприклад, покупцями та продавцями, роботодавцями та працівниками, компаніями та аудиторами, постачальниками та клієнтами, платниками та постачальниками послуг, то кожна додана сторона може зробити цю мережу більш цінною для наступної сторони.
Один із способів — це спільна робоча процедура: продукт стає місцем, де обидві сторони процесу здійснюють угоди, обмінюються контекстом та вирішують виняткові ситуації.
Іншим способом є базовий та інтелектуальний підхід: система може на основі шаблонів, спостережених у мережі, представляти галузеві норми, аномалії та рекомендації щодо дій, що посилює взаємодію зі згаданою раніше цінністю даних.
Третій спосіб — це довіра та стандартизація: коли контрагенти починають залежати від однієї й тієї ж системи для завершення схвалення, передачі, відповідності або платежів, цей продукт більше не є просто базою даних, а стає спільною інфраструктурою ринку, тому його складніше замінити.
Шосте, наскільки сильні технічні здібності покупця?
У світі, де теоретично будь-хто може створити власного агента, реальні здібності різних покупців до побудови все ще дуже відрізняються. Зокрема, у вертикальних галузях та серед функціональних покупців, які раніше не мали потужних внутрішніх інженерних ресурсів, ймовірність того, що вони самостійно створять, підтримуватимуть та постійно вдосконалюватимуть бази даних, логіку робочих процесів, стек агентів та рівень управління, залишається низькою.
Витрати тут також важливі. DIY теоретично може зменшити витрати на ліцензії на програмне забезпечення, але часто переносить витрати на реалізацію, підтримку та внутрішню складність.
Це означає, що в галузях із складними операціями, але недостатнім технічним забезпеченням, все ще існують реальні можливості. Наприклад, виробництво, бек-офіс будівельної галузі, промислові процеси, робочі процеси на місці та бухгалтерія.
Також важливими є й інші фактори, які поступово стануть базовим порогом для програмного забезпечення.
Наприклад, онтологія повинна змінитися. Багато ідей «власних баз даних» недооцінюють власну цінність, яку несе об’єктна модель. Існуючі програми створювалися для інформаційних панелей, звітів і людських користувачів, і вони фіксують об’єкти з робочих процесів, такі як можливості продажу, тікети, кандидати тощо.
Але схема ери Agent повинна відображати міркування, дії, відстеження стану, обробку винятків, делегування завдань та взаємодію між системами. Нативні об’єктні моделі можуть більше не бути продажами, тікетами та кандидатами, а замість цього — завданнями, намірами, потоками, стратегіями чи результатами.
Так само, система прав доступу також повинна бути оновлена. Вона більше не керує лише людськими користувачами, а має керувати агентами. Це включає: хто може що робити, через якого агента, за якою стратегією, які схвалення необхідні, який аудитний слід залишати, а також як виконувати відкати та обробляти виняткові ситуації.
Звичайно, все це безпосередньо пов’язано з витратами, наприклад, скільки коштує створення та підтримка агентів та баз даних, як високі витрати на доступ до API. Це знову повертає нас до кількох ключових питань: наскільки складно відновити дані, яка кількість залежностей і наскільки глибоко система вбудована.
Тоже саме, який висновок?
Зі зростанням головних виробників програмного забезпечення до headless-підходу, вони фактично роблять приховане припущення: шар даних залишиться основним джерелом вартості. У деяких категоріях, особливо в таких галузях, як фінансові послуги, які сильно регулюються, це припущення може залишатися дійсним ще деякий час, а процес переходу на headless-архітектуру може відбуватися повільніше.
Але для програмних підприємців, зі зростанням відмови від інтерфейсів існуючими виробниками, питання про те, як з ними конкурувати та як будувати програмне забезпечення з довгостроковою захисною здатністю, змінюються.
Наступне покоління систем запису вже починає набувати різних форм: вони більше не є просто сховищами даних про людську роботу, а набувають властивостей агентів — здатність відстежувати контекст, активно ініціювати роботу та записувати сліди даних, що виникають під час виконання.
Ще далі, найцікавіші компанії розширяться до реального світу: вони будуть координувати персонал на місці, логістичні сервіси, команди обслуговування та фізичні активи, або розташовуватимуться між кількома учасниками, стаючи посередником для багатосторонньої співпраці.
Ці компанії поєднають різні бізнес-моделі старого світу. А основа традиційних систем запису — дані — поступово відійде на тло, ставши фундаментом, що підтримує роботу всієї системи.
Натисніть, щоб дізнатися про вакансії BlockBeats
Вступайте до офіційного спільноти律动 BlockBeats:
Telegram-канал з підпискою: https://t.me/theblockbeats
Telegram-чат: https://t.me/BlockBeats_App
Офіційний аккаунт Twitter: https://twitter.com/BlockBeatsAsia