Phần mềm đang trở nên headless?

• Việc Salesforce ra mắt sản phẩm headless và đặt cược rằng lớp dữ liệu chứ không phải UI mới là trung tâm của giá trị đã làm dấy lên câu hỏi: trong kỷ nguyên agent, năng lực phòng thủ của SaaS còn nằm ở đâu
• Ở thời đại SaaS, hào lũy của các hệ thống lưu trữ hồ sơ (System of Record) là thói quen người dùng được hình thành qua UI, nhưng lợi thế này suy yếu trong cấu trúc nơi agent đọc và ghi trực tiếp vào DB
• Năng lực phòng thủ đang dịch chuyển xuống dưới về phía mô hình dữ liệu, quyền hạn, logic quy trình, tuân thủ, và lên trên về phía mạng lưới, tạo ra dữ liệu độc quyền, năng lực thực thi trong thế giới thực
• Thế hệ hệ thống lưu trữ hồ sơ AI-native tiếp theo cần những tiêu chuẩn mới như mô hình dữ liệu thân thiện với agent, quản lý quyền theo đơn vị agent, khép kín vòng lặp thực thi
• Mô hình kinh doanh thế hệ mới hứa hẹn nhất là dạng mở rộng vượt ra ngoài việc chỉ lưu trữ dữ liệu để bao trùm cả thực thi trong thế giới thực và điều phối nhiều bên

---

Câu hỏi được đặt ra từ thông báo headless của Salesforce

• Tháng trước, Salesforce công bố mở API và ra mắt sản phẩm headless, đặt cược rằng giá trị trong kỷ nguyên agent nằm ở lớp dữ liệu chứ không phải UI
  • Về mặt kỹ thuật, gần như không có gì mới — các API đang được tiếp thị như sản phẩm headless đã tồn tại từ nhiều năm trước, đây là một màn ra mắt kiểu marketing rất đặc trưng của Salesforce
  • Ý tưởng cốt lõi là agent truy cập trực tiếp vào dữ liệu của hệ thống lưu trữ hồ sơ mà không đi qua UI dành cho con người
• Khi bỏ UI đi và chỉ còn DB, câu hỏi bản chất được đặt ra là: nó khác gì so với Postgres + schema được thiết kế tốt + API
  • Cần xem xét liệu những yếu tố từng nâng đỡ các hệ thống lưu trữ hồ sơ hiện tại còn nguyên giá trị hay không, hay cần những tiêu chuẩn mới

Thời đại SaaS khi UI chính là sản phẩm

• Hệ thống lưu trữ hồ sơ (System of Record) là nguồn chân lý duy nhất có thẩm quyền cho một lĩnh vực cụ thể
  • CRM là hệ thống lưu trữ hồ sơ cho doanh thu, HRIS là hệ thống lưu trữ hồ sơ cho nhân sự, ERP là hệ thống lưu trữ hồ sơ cho dòng tiền
  • Sức mạnh thực sự không chỉ là một kho lưu trữ, mà là cung cấp thực tại được chia sẻ cho cả tổ chức
• Trong 20 năm qua, thứ Salesforce bán là cách các trưởng bộ phận kinh doanh vận hành đội ngũ
  • Dashboard, chế độ xem pipeline, công cụ dự báo, activity feed mới là thứ thực sự được bán ra, và mô hình kinh doanh dựa trên bán seat người dùng
  • DB bên dưới là cốt lõi, nhưng vẫn chỉ là yếu tố phụ trợ
• UI tạo ra độ bám dính (stickiness)
  • Nó ép buộc vệ sinh dữ liệu, tạo ra từ vựng chung (Lead, Opportunity, Account), và khiến nhân viên kinh doanh nhập vào những dữ liệu mà nếu không họ sẽ không nhập
  • Nhiều lãnh đạo kinh doanh mang Salesforce theo khi chuyển việc không phải vì UI đẹp, mà vì thói quen sử dụng đã ăn vào tay (muscle memory)
• Agent đang bắt đầu lật ngược mô hình này
  • Có thể read/write trực tiếp dữ liệu mà không đi qua UI
  • Quanh SAP cũng đang nhanh chóng hình thành một hệ sinh thái thân thiện với AI
  • Agent sử dụng máy tính, theo thời gian, làm suy yếu các yếu tố dựa trên con người như sở thích, đào tạo và ngữ cảnh không được tài liệu hóa

Tiêu chí đánh giá độ bám dính của hệ thống lưu trữ hồ sơ trong quá khứ

• Những yếu tố dựa trên cách con người tương tác với phần mềm và các sở thích của họ

• Được dùng thường xuyên đến mức nào

  • CRM được các đội GTM dùng hằng ngày → trở thành hạ tầng cốt lõi
  • Routine công việc, thao tác đã quen tay, nhịp quản lý được bồi đắp qua nhiều năm chồng lên trên đó là yếu tố khó di chuyển nhất
  • Trong nhiều trường hợp, nó thậm chí còn không được nhận thức như một thứ cần phải migration

• Là write-only hay read-write

  • Hệ thống lưu trữ hồ sơ có độ bám dính cao thường là dạng read-write
  • CRM được đọc liên tục — mọi ghi chú cuộc gọi, cập nhật giai đoạn, tạo tác vụ đều là luồng hai chiều
  • Vì phải xử lý dữ liệu vận hành trực tiếp nên không có thời điểm chuyển đổi nào thật sự an toàn → đã triển khai rồi thì rất khó rời đi
  • Ngược lại, ATS (hệ thống theo dõi ứng viên) gần với write-only hơn — sau khi tuyển xong hầu như không cần xem lại dữ liệu

• Có bao nhiêu SOP không được tài liệu hóa

  • Ngữ cảnh cốt lõi của doanh nghiệp được mã hóa trong các quy tắc workflow chứ không nằm trong wiki
  • Ví dụ trong sales: deal enterprise trên 100.000 USD cần VP phê duyệt, deal EMEA bắt buộc phải rà soát quyền riêng tư, giảm giá cho strategic logo chỉ có thể bỏ qua tài chính vào cuối quý
  • Ngữ cảnh kiểu này tạo ra khác biệt giữa xử lý đúng lúc và bỏ sót
  • Migration đồng nghĩa với việc reverse engineer toàn bộ automation, hoặc đánh mất hoàn toàn ký ức của tổ chức

• Quy mô phụ thuộc nội bộ và bên ngoài

  • Bao gồm các hệ thống nội bộ ở tầng dưới và nhu cầu truy cập trực tiếp từ kiểm toán viên, kế toán viên, cơ quan quản lý bên ngoài
  • Càng kết nối nhiều ở cả hai phía thì càng có nhiều nút thắt phải gỡ khi migration

• Mức độ quan trọng của tuân thủ

  • Dữ liệu payroll, ERP, HR đòi hỏi một nguồn chân lý duy nhất có thể bảo vệ về mặt pháp lý, kiểm soát truy cập quản trị nghiêm ngặt và sự can dự trực tiếp của kiểm toán viên/cơ quan quản lý
  • Độ bám dính rất cao
  • Dữ liệu sales, hay các công cụ hỗ trợ khách hàng như Zendesk, nằm ở đầu kia — tính liên tục và ngữ cảnh quan trọng nhưng không có mức phơi nhiễm pháp lý như vậy

• So sánh chi phí chuyển đổi giữa các hệ thống lưu trữ hồ sơ

  • ATS là công cụ workflow có ranh giới rõ ràng là tuyển dụng, tích hợp hẹp và ít người dùng
  • ERP thì hoàn toàn ngược lại — sổ cái chính là audit trail, còn kế toán viên, kiểm toán viên, cơ quan quản lý đều là các bên liên quan trực tiếp
  • Thay ATS thì đau nhưng vẫn chịu được, thay CRM là phẫu thuật tim hở, còn thay ERP là phẫu thuật tim hở cho một bệnh nhân đang chạy marathon

• Những yếu tố hào lũy vốn yếu theo truyền thống

  • Dữ liệu độc quyền — CRM có dữ liệu phong phú nhưng nỗ lực tạo insight liên khách hàng còn rất hạn chế (chỉ có vài thử nghiệm như Salesforce Einstein)
  • Hiệu ứng mạng lưới — từng được xem là chén thánh, nhưng trong các hệ thống lưu trữ hồ sơ thì về mặt lịch sử vẫn khá yếu

Khi UI biến mất và agent xuất hiện, điều gì còn lại

• Agent không cần trình duyệt — chỉ cần API, ngữ cảnh, chỉ thị và khả năng hành động

• Có hai thay đổi khiến điều này thành hiện thực

  • Khả năng suy luận của LLM được cải thiện: agent có thể đọc ngữ cảnh, lập kế hoạch, chọn công cụ, thực thi và rà soát kết quả mà không cần con người can thiệp
  • MCP chuẩn hóa việc truy cập công cụ: agent gọi các chức năng bên ngoài thông qua một giao diện chung
  • Agent sử dụng máy tính, nếu có đủ ngữ cảnh thích hợp, thậm chí có thể điều hướng giao diện phần mềm cũ mà không cần API

• Ba con đường dành cho người mua phần mềm

  • Hệ thống hiện có + agent: dùng CLI/API của các ông lớn SaaS hiện tại, dùng sản phẩm agent native (Salesforce Agentforce, SAP Joule) hoặc tự xây agent — nhưng điều này giả định API phải đầy đủ, dùng được và việc chuyển sang headless đủ đơn giản về vận hành
  • Tự xây hệ thống lưu trữ hồ sơ (DIY): tự xây mô hình dữ liệu, logic vận hành, quyền hạn/kiểm toán/tích hợp và agent của riêng mình ngay từ đầu (có thể tận dụng công cụ bên thứ ba)
  • Mua giải pháp thay thế AI-native: thế hệ phần mềm mới được xây từ đầu trên nền tảng máy có thể đọc được, orchestration agent là tính năng hạng nhất được tích hợp sẵn, có thể vận hành headless

• Những gì còn sống sót từ tiêu chí đánh giá cũ

  • Các yếu tố dựa trên hành vi con người (tần suất sử dụng, read vs read-write) → biến mất cùng với thói quen sử dụng
  • Agent giết chết hào lũy từ thói quen dùng, nhưng không giết được hào lũy từ logic vận hành và ngữ cảnh
  • Thậm chí, để agent có thể hành động an toàn thì quy tắc, quyền hạn và định nghĩa quy trình tường minh còn trở nên quan trọng hơn

• Trong ngắn hạn, SOP không được tài liệu hóa vẫn quan trọng

  • Logic tổ chức được mã hóa trong các quy tắc workflow là yếu tố cốt lõi để agent vận hành đúng
  • Không thể export gọn gàng ra được (đặc biệt khi con người vẫn còn ở trong một số quy trình)
  • Tuy vậy, khi việc nắm bắt ngữ cảnh trở nên dễ hơn và agent thay thế lao động nhiều hơn, yếu tố này sẽ dần bớt quan trọng

• Tính kết nối (connectivity) vẫn khó và còn mở rộng hơn

  • Trọng tâm không còn là đi theo con người, mà là duy trì kết nối giữa các chức năng và phần mềm phân mảnh
  • Agent CRM phải khâu nối dữ liệu và ngữ cảnh giữa sales, billing và customer success
  • Khi trở thành nút nơi agent của nhiều tổ chức bên ngoài giao dịch với nhau, mức độ phụ thuộc còn sâu hơn nữa
  • Cả mô hình ông lớn hiện tại + agent lẫn DIY DB + agent đều đều khó băng qua hàng loạt phần mềm tầng dưới khác nhau

• Dữ liệu tuân thủ vẫn quan trọng

  • Dữ liệu có rủi ro pháp lý và quản lý vẫn cần một nguồn dữ liệu tin cậy duy nhất
  • Khả năng tự xây và tự duy trì dữ liệu payroll hoặc kế toán là thấp
  • Bài toán khó chưa được giải quyết nhất của thế giới hoàn toàn agent là: agent nào, thay mặt ai, được cấp quyền làm gì và với mức độ kiểm toán nào
  • Hệ thống lưu trữ hồ sơ trở thành lớp nhận diện và phân quyền cho tương tác giữa các agent sẽ ép buộc một kiến trúc niềm tin, nên về cấu trúc rất khó bị thay thế

Những yếu tố phòng thủ mới của startup AI-native

• Mức độ khó tái tạo hệ thống lưu trữ hồ sơ

  • Trong ngắn hạn, điểm mấu chốt là mức độ dễ hay khó của việc trích xuất và tái tạo dữ liệu dựa trên hệ thống lưu trữ hồ sơ
  • Các ông lớn SaaS hiện tại khiến điều này khó bằng cách làm cho API trở nên đau đớn, có cổng chặn, không đầy đủ hoặc không kinh tế
  • Công cụ trích xuất, đặc biệt là agent sử dụng máy tính, đang phát triển và khiến việc này ngày càng dễ hơn
  • Đồng thời, các công ty mới đang xuất hiện để tái dựng dữ liệu phong phú hơn từ email, điện thoại, voice agent và tài liệu nội bộ
  • AI hạ chi phí tái tạo 80% đầu tiên của hệ thống lưu trữ hồ sơ, nhưng 20% còn lại (xử lý ngoại lệ, phê duyệt, tuân thủ, workflow tình huống biên) mới là nơi phân định giữa một giải pháp thay thế thực sự và một wedge

• Có sở hữu dữ liệu độc quyền có ý nghĩa hay không

  • Dữ liệu có thể phòng thủ không phải là dữ liệu được import vào, mà là dữ liệu do chính sản phẩm tạo ra một cách độc nhất
  • Dữ liệu kiểu walled garden — dữ liệu độc quyền, dữ liệu chịu quản lý, hoặc dữ liệu cần được cập nhật liên tục
  • Nhà cung cấp phần mềm đầu tư vào dữ liệu có thẩm quyền và đầy đủ sẽ có lợi thế hơn nhà cung cấp phổ dụng
  • Dữ liệu hành vi được tạo ra nội bộ: hành vi quan sát được, tỷ lệ phản hồi, mẫu hình thời điểm, kết quả quy trình, benchmark, mẫu ngoại lệ, theo dõi hiệu suất agent
  • Dữ liệu chính là ngữ cảnh (data is the context)

• Có sở hữu lớp hành động hay không

  • Trước đây, lưu trữ hồ sơ là đủ, nhưng trong thời đại mới, agent hành động
  • Năng lực phòng thủ dịch chuyển sang các sản phẩm có vòng lặp khép kín hành động → ghi nhận kết quả → phản hồi → cải thiện quyết định
  • Ví dụ với ERP: phê duyệt chi tiêu, kích hoạt payroll, đối soát hóa đơn, gửi thông báo
  • Sản phẩm khép kín vòng lặp nằm trong quá trình thực thi chứ không chỉ quan sát → tạo ra dữ liệu riêng, càng dùng càng tốt hơn và khó bị gỡ bỏ nếu không làm vỡ workflow

• Yếu tố thực thi trong thế giới thực

  • Mô hình kinh doanh có kết nối với các hoạt động ngoài đời thực sẽ không được tự động hóa hoàn toàn
  • Ví dụ về mạng lưới vận hành như DoorDash — về mặt lịch sử không phải hệ thống lưu trữ hồ sơ, nhưng mang lại nhiều gợi ý
  • Phần mềm khép kín vòng lặp bằng dịch vụ, fulfillment, logistics, vận hành tại hiện trường và thanh toán sở hữu một loại năng lực phòng thủ khác với SaaS thuần túy
  • Không chỉ lưu hồ sơ hay đưa khuyến nghị, mà còn điều người, vận chuyển hàng hóa và hoàn thành dịch vụ
  • Với người xây dựng sản phẩm, cơ hội nằm ở những thị trường mà phần mềm ngày càng ra quyết định và agent ngày càng điều phối nhưng last mile vẫn cần thực thi ngoài đời thực — ví dụ: phần mềm vertical kết hợp dịch vụ hiện trường

• Hiệu ứng mạng lưới

  • Trong các hệ thống lưu trữ hồ sơ trước đây, hiệu ứng này yếu vì phần mềm chủ yếu phục vụ nội bộ
  • Khi được nhúng vào workflow đa bên, hiệu ứng mạng lưới có thể trở nên quan trọng hơn nhiều
  • Khi phần mềm làm trung gian cho các tương tác lặp lại như người mua-người bán, nhà tuyển dụng-người lao động, công ty-kiểm toán viên, nhà cung cấp-khách hàng, payer-provider, số lượng bên tham gia tăng lên sẽ kéo theo giá trị mạng lưới tăng lên
  • Cách triển khai
    • Điều phối workflow dùng chung — trở thành nơi hai bên thực hiện giao dịch, trao đổi ngữ cảnh và giải quyết ngoại lệ
    • Benchmarking và intelligence — cung cấp chuẩn mực, điểm bất thường và khuyến nghị dựa trên các mẫu của mạng lưới
    • Niềm tin và chuẩn hóa — nếu trở thành đường ray chung cho phê duyệt, handoff, tuân thủ và thanh toán thì nó không còn chỉ là DB, mà trở thành một phần của hạ tầng điều phối thị trường

• Năng lực kỹ thuật của người mua

  • Dù trên lý thuyết ai cũng có thể làm agent, năng lực thực tế vẫn chênh lệch rất lớn
  • Các thị trường vertical end market và nhóm mua chức năng có nguồn lực kỹ sư nội bộ yếu khó có thể tự xây, duy trì và cải thiện DB, logic workflow, agent stack và governance của riêng mình
  • Chi phí cũng là yếu tố cốt lõi — DIY giảm phí license nhưng chuyển chi phí sang triển khai, bảo trì và độ phức tạp nội bộ
  • Cơ hội nằm ở các danh mục có vận hành phức tạp nhưng bị thiếu phục vụ về mặt công nghệ — sản xuất, back office xây dựng, workflow dịch vụ công nghiệp và hiện trường, kế toán

Những yếu tố thiết yếu khác (table stakes)

• Mô hình dữ liệu mới (ontology)

  • Cách nghĩ kiểu “DIY DB” có xu hướng đánh giá thấp giá trị của chính mô hình đối tượng
  • Phần mềm cũ được xây để phục vụ dashboard, báo cáo và ghi nhận workflow của con người → Opportunity, Ticket, Candidate...
  • Schema cho agent cần phải nắm bắt suy luận, hành động, theo dõi trạng thái, xử lý ngoại lệ, ủy quyền và điều phối giữa các hệ thống
  • Mô hình đối tượng native sẽ chuyển sang các dạng như task, intent, thread, policy, outcome

• Quản lý quyền của agent

  • Cần một hệ thống quyền không chỉ để quản trị con người mà còn để quản trị agent
  • Phải xác định ai, thông qua agent nào, dưới chính sách nào, với cơ chế phê duyệt/audit trail/rollback/xử lý ngoại lệ nào có thể làm gì

• Bối cảnh chi phí

  • Chi phí xây dựng và duy trì agent/DB, chi phí truy cập API, v.v.
  • Đây cũng là vấn đề gắn với độ khó tái tạo dữ liệu và số lượng phụ thuộc

Kết luận — hướng tiến hóa của hệ thống lưu trữ hồ sơ

• Việc các ông lớn SaaS hiện tại tiến tới headless là một sự đặt cược ngầm rằng lớp dữ liệu vẫn là nguồn gốc của giá trị
• Ở các danh mục gắn sâu với tuân thủ như dịch vụ tài chính, sự đặt cược này sẽ còn đúng trong một thời gian và việc chuyển sang headless cũng sẽ đến muộn hơn
• Với builder, cấu trúc cơ hội cạnh tranh với các ông lớn hiện tại đang chuyển sang headless đang thay đổi
• Hệ thống lưu trữ hồ sơ thế hệ mới không còn chỉ là kho ghi chép, mà là dạng thân thiện với agent, có khả năng nắm bắt ngữ cảnh, khởi tạo công việc và ghi lại data exhaust
• Những mô hình kinh doanh thú vị nhất là dạng mở rộng sang thực thi trong thế giới thực - điều phối nhân lực hiện trường, nhà cung cấp logistics, đội dịch vụ, tài sản vật lý hoặc đứng giữa nhiều bên
• Trộn lõi dữ liệu của mô hình kinh doanh thế giới cũ và hệ thống lưu trữ hồ sơ truyền thống, nhưng với cấu trúc mà dữ liệu lùi về phía nền