Có một ảo tưởng khá phổ biến trong công nghệ: một công ty càng lớn, càng nhiều kỹ sư, càng nhiều tiền và càng làm nhiều dự án thì càng có khả năng nhận ra một công nghệ có giá trị.
Thực tế không hẳn vậy.
Một tổ chức có thể rất giỏi trong thế giới mà nó đang sống, nhưng lại gần như không có hệ quy chiếu để định giá một thứ thuộc tầng phía trên.
Vấn đề không phải họ không nhìn thấy.
Họ nhìn thấy, nhưng nhìn nó bằng hệ quy chiếu của một tầng giá trị thấp hơn.
Và khi đó, một cơ hội có thể nằm ngay trên bàn vẫn bị đọc thành một thứ rất bình thường.
Từ Project đến Standard
Trong bài trước về 4 tầng kiếm tiền, tôi chia quá trình tạo giá trị theo một logic khá đơn giản: bán sức, bán kỹ năng, bán sản phẩm và cuối cùng là bán quy tắc.
Với doanh nghiệp công nghệ, có thể chuyển nó thành một trục khác:
Project → Product → Platform → Standard.
Bốn tầng này nhìn bên ngoài đều có thể là phần mềm. Nhưng cách tạo ra giá trị hoàn toàn khác nhau.
Ở tầng Project, doanh nghiệp bán năng lực triển khai.
Khách hàng có một bài toán. Một đội kỹ sư được đưa vào khảo sát, thiết kế, phát triển, tích hợp rồi vận hành. Làm xong dự án này thì sang dự án khác.
Muốn tăng doanh thu thường phải tăng khách hàng, tăng hợp đồng, tăng đội ngũ hoặc tăng đơn giá nhân sự.
Một kỹ sư vẫn chỉ có một lượng thời gian hữu hạn. Một tổ chức có 30.000 kỹ sư chẳng qua đã nhân khả năng bán thời gian từ 1 người lên 30.000 người.
Quy mô rất lớn. Nhưng vẫn là quy mô của năng lực triển khai.
Sang tầng Product, cấu trúc bắt đầu thay đổi.
Một lõi phần mềm được làm một lần rồi bán cho 100, 1.000 hay 10.000 khách hàng. Việc triển khai riêng cho từng khách hàng vẫn có thể tồn tại, nhưng phần giá trị cốt lõi không phải được viết lại từ đầu mỗi lần.
Đến đây phần mềm bắt đầu trở thành tài sản.
Nó không còn chỉ là sản phẩm phụ của một hợp đồng đã hoàn thành. Nó tồn tại độc lập với từng khách hàng, có lộ trình phát triển riêng, tích lũy năng lực qua thời gian và có thể tạo thêm doanh thu mà không phải tăng nhân lực theo tỷ lệ tương ứng.
Tầng Platform đi thêm một bước.
Lúc này người khác bắt đầu xây trên thứ của bạn.
Platform không nhất thiết giải quyết trọn vẹn một bài toán cuối cùng cho khách hàng. Nó cung cấp một lớp năng lực chung để nhiều hệ thống, dịch vụ và sản phẩm khác sử dụng.
Giá trị của Platform vì thế không chỉ nằm ở số người mua nó.
Giá trị nằm ở số thứ khác phụ thuộc vào nó.
Và trên Platform còn một tầng nữa: Standard.
Ở đây, thứ bạn tạo ra bắt đầu định hình cách những hệ thống khác phải giao tiếp, phải tương thích hoặc phải vận hành.
Một đặc tả hay tiêu chuẩn đủ mạnh có thể khiến hàng nghìn sản phẩm của hàng nghìn công ty cùng tuân theo một cách chơi.
Đó là lúc công nghệ tiến gần tới tầng “viết luật chơi”.
Khác tầng thì khác cách nhìn giá trị
Bốn tầng này không chỉ khác nhau về mô hình kinh doanh.
Chúng tạo ra bốn hệ quy chiếu giá trị khác nhau.
Người sống lâu trong Project thường hỏi:
Khách hàng là ai?
Yêu cầu cụ thể là gì?
Hợp đồng bao nhiêu?
Cần bao nhiêu người?
Bao lâu nghiệm thu?
Biên lợi nhuận dự án thế nào?
Đó đều là câu hỏi đúng ở tầng Project.
Người làm Product lại hỏi:
Bao nhiêu khách hàng có thể dùng chung một lõi?
Bao nhiêu phần trăm phải tùy biến?
Doanh thu lặp lại thế nào?
Doanh thu có thể tăng nhanh hơn số nhân sự không?
Khách hàng thứ 1.000 có còn tốn gần bằng khách hàng đầu tiên hay không?
Lên Platform, câu hỏi đổi tiếp:
Có bao nhiêu hệ thống đang xây trên năng lực này?
Bao nhiêu thứ sẽ phụ thuộc vào nó?
Nếu bỏ nó ra, phần còn lại phải xây lại bao nhiêu?
Một năng lực mới được thêm vào Platform sẽ tự động lan xuống bao nhiêu hệ thống bên dưới?
Còn ở Standard:
Ai phải tương thích với mình?
Có bao nhiêu hệ thống độc lập cùng thực thi đặc tả này?
Nếu mình không còn trực tiếp tham gia từng dự án, tiêu chuẩn đó vẫn tiếp tục lan rộng không?
Một tổ chức có thể đọc được chữ của cả bốn tầng.
Nhưng điều đó không có nghĩa họ định giá được cả bốn.
FPT và cái bẫy của một mô hình quá thành công
FPT là một trường hợp rất đáng quan sát.
Gần ba thập kỷ qua, FPT xây được một cỗ máy dịch vụ phần mềm rất lớn. Quy mô nhân lực, khách hàng quốc tế, khả năng triển khai và độ phủ doanh nghiệp của FPT là những thứ ít công ty công nghệ Việt Nam có thể so sánh.
Nhưng quy mô không tự động làm thay đổi tầng.
Báo cáo thường niên của FPT nêu rõ định hướng chuyển dịch từ dịch vụ sang làm chủ các nền tảng và giải pháp công nghệ có giá trị cao.
Trên thực tế, hệ sinh thái Made-by-FPT năm 2024 đạt 2.267 tỷ đồng doanh thu, tăng 31%, trong khi khối dịch vụ vẫn chiếm tỷ trọng áp đảo trong toàn bộ hoạt động công nghệ.
Con số này không phủ nhận nỗ lực chuyển dịch.
Nó chỉ cho thấy quán tính của mô hình Project vẫn rất lớn.
FPT có một danh mục dài những thứ được gọi là sản phẩm, giải pháp và nền tảng. Nhưng tên gọi không quyết định tầng.
Một phần mềm được đặt tên, làm trang giới thiệu riêng và bán cho nhiều khách hàng chưa chắc đã trở thành Product theo nghĩa kinh tế. Nếu mỗi hợp đồng vẫn kéo theo khảo sát riêng, tích hợp riêng, tùy biến lớn và một đội triển khai đáng kể, thì nó vẫn có thể chỉ là một Project được đóng gói lại.
Điều này khác khá xa với một công ty sinh ra bằng product-based.
Base.vn là ví dụ rõ.
Trước khi FPT mua cổ phần đa số, Base.vn đã vận hành như một sản phẩm phần mềm dùng chung cho hàng nghìn doanh nghiệp. Lõi sản phẩm, cách phát triển và cách mở rộng khách hàng đã tồn tại trước khi FPT bước vào.
Vì vậy việc FPT sở hữu Base.vn không thể tự động được dùng làm bằng chứng rằng tổ chức cốt lõi của FPT đã chuyển sang product-based.
FPT sở hữu một công ty product-based không đủ sức mạnh để nói FPT trở thành (hoặc là) một công ty product-based.
Nhìn sang Infosys sẽ thấy sự khác biệt
So sánh với Infosys càng làm ranh giới này rõ hơn.
Infosys cũng đi lên từ dịch vụ phần mềm và gia công.
Nhưng họ không dừng lại ở việc làm Project ngày càng lớn. Finacle trở thành một sản phẩm core banking độc lập, được triển khai cho nhiều ngân hàng ở nhiều quốc gia và tiếp tục tồn tại như một tài sản sản phẩm riêng bên cạnh mảng dịch vụ.
Infosys vì vậy ngày nay có thể được nhìn như một công ty lai (hybrid): dịch vụ vẫn rất lớn, nhưng Product và Platform đã trở thành những lớp giá trị thực sự.
FPT thì chưa có một bằng chứng nội sinh tương đương như vậy.
Khoảng cách nằm ở đó.
Khi một lựa chọn đi trước bốn năm được đưa vào một cỗ máy Project
Câu chuyện trở nên thú vị hơn khi một lựa chọn công nghệ được thực hiện để đi trước bốn năm trước với mục tiêu rất khác.
Nó không được đặt ra như một phần mềm để bán cho một vài ngân hàng.
Không được định vị như một Project.
Thậm chí không dừng ở một Product.
Lựa chọn đó được xây theo hướng tạo ra một tài sản trí tuệ có khả năng tiến từ kiến trúc, sang Platform, rồi nếu được chấp nhận đủ rộng, có tiềm năng trở thành một tiêu chuẩn trong thời kỳ hậu AI.
Một bản tóm tắt điều hành về hướng đi này từng được chuyển tới lãnh đạo cấp cao nhất của tập đoàn thông qua một kênh cá nhân tin cậy.
Khoảng 30 phút sau, tài liệu được chuyển xuống đơn vị có mảng kinh doanh phù hợp để đánh giá.
Một ngày sau, phản hồi từ lãnh đạo đơn vị, về bản chất, là:
đơn vị đang tập trung làm giải pháp cho một số khách hàng hiện tại và chưa có định hướng phát triển theo hướng Product.
Timeline này đáng chú ý không phải vì FPT phản ứng chậm.
Ngược lại.
FPT phản ứng rất nhanh và rất chuẩn xác theo cơ chế vận hành hiện tại.
Tài liệu được chuyển ngay tới đúng đơn vị có vẻ liên quan nhất về mặt công nghệ lẫn phạm vi kinh doanh. Đơn vị xử lý thông tin, đối chiếu với nhu cầu hiện tại rồi đưa ra quyết định rất nhanh.
Không có dấu hiệu trì trệ.
Không có dấu hiệu quan liêu.
Không có dấu hiệu “không biết chuyển cho ai”.
Hệ thống vận hành tốt.
Chỉ có một vấn đề:
nó vận hành rất đúng theo hệ quy chiếu Project.
Một tài sản được thiết kế cho câu hỏi:
“Làm thế nào để đi tới Standard?”
được đưa vào một hệ thống đang quen hỏi:
“Hiện tại có Project nào cho nó không?”
Khi đó kết quả lệch tầng gần như là tất yếu.
Điều đáng phân tích vì thế không phải FPT có xử lý sai cơ hội hay không.
Điều đáng phân tích là một tổ chức có thể phản ứng rất nhanh, rất chuyên nghiệp và hoàn toàn hợp lý trong hệ quy chiếu của mình, nhưng vẫn định giá sai một tài sản nằm ở tầng khác.
Đây chính là loại điểm mù khó nhận ra nhất.
Bởi mọi quy trình bên trong đều đang chạy đúng.
VIEApps NGX: khi một Platform bị nhìn như một bộ công cụ
VIEApps NGX là một ví dụ kỹ thuật rất rõ cho sự lệch tầng này.
Nếu nhìn nó bằng hệ quy chiếu Project, người ta sẽ rất dễ hỏi:
Dùng bộ trung gian truyền thông nào?
Dùng cân bằng tải nào?
Dùng cổng giao tiếp nào?
Dùng cơ chế gọi dịch vụ nào?
Dùng công cụ điều phối nào?
Sau đó đem từng mảnh đi so với các công cụ phổ biến của cloud-native mainstream.
Nhưng VIEApps NGX không được thiết kế như một tập hợp công cụ.
Nó là một communication runtime platform cho hệ thống phân tán (distributed systems).
VIEApps NGX tách logic nghiệp vụ khỏi việc truyền thông, định tuyến và điều phối thực thi. Các dịch vụ nghiệp vụ có thể được phát triển độc lập; lớp runtime bên dưới chịu trách nhiệm truyền thông, định tuyến lời gọi và phân phối thực thi giữa các node.
Điểm khác biệt nằm ở đây.
Trong một Project thông thường, mỗi lần cần thêm một khả năng mới, đội dự án phải ghép thêm công cụ, thêm mã tích hợp, thêm lớp giao tiếp rồi nối nó vào hệ thống.
Ở Product, những phần đó có thể được đóng gói để dùng lại.
Nhưng ở Platform, năng lực nằm ngay trong lớp nền mà mọi dịch vụ bên trên cùng sử dụng.
Vì vậy một thay đổi ở Platform có thể lập tức trở thành năng lực của toàn bộ hệ sinh thái.
VIEApps NGX cho thấy điều này rất rõ khi MCP (Model Context Protocol) xuất hiện.
Thay vì sửa từng dịch vụ nghiệp vụ để biến nó thành một công cụ cho AI, lớp runtime có thể ánh xạ trực tiếp các RPC (Remote Procedure Call) đã tồn tại sang MCP tools và resources.
Tài liệu kỹ thuật của VIEApps NGX mô tả điều này bằng một câu rất ngắn:
“Every existing RPC instantly becomes an AI tool.”
Nói đầy đủ hơn về mặt kiến trúc:
Every existing RPC can be exposed as an AI tool without rewriting its business execution path.
Câu này chính là chỗ có thể nhìn thấy ranh giới giữa Project, Product và Platform.
Nếu đang ở tầng Project, khi AI xuất hiện, bạn mở một dự án mới.
Bạn khảo sát những dịch vụ nào cần cho AI truy cập, viết thêm lớp trung gian, tạo công cụ riêng, xử lý xác thực, điều phối, giới hạn tải rồi tích hợp từng dịch vụ.
Mỗi hệ thống lại làm một lần.
Nếu đang ở tầng Product, bạn có thể xây một AI module rồi đưa nó vào sản phẩm.
Nhưng khi đã ở tầng Platform, bài toán thay đổi hẳn.
Không cần đi sửa lại đường thực thi nghiệp vụ của từng dịch vụ.
Chỉ cần Platform hiểu một giao thức mới, toàn bộ RPC đang tồn tại phía trên lập tức có khả năng được đưa ra cho AI sử dụng qua cùng một cơ chế thực thi.
Đó là sức bật của Platform.
Một thay đổi ở lớp nền tạo ra năng lực mới cho cả hệ thống.
Đây cũng là lý do so VIEApps NGX với từng cổng giao tiếp, middleware truyền thông, message broker, service mesh hay framework riêng lẻ thường dẫn đến sai câu hỏi.
Từng chức năng riêng biệt có thể không mới.
Cái cần đánh giá là:
Khi chúng được đặt chung vào một runtime, ranh giới của hệ thống thay đổi thế nào?
Cùng một runtime chịu trách nhiệm truyền thông, định tuyến, phân phối thực thi, kiểm soát tải và điều phối các dịch vụ. HTTP chỉ còn là lớp thích nghi bên ngoài; MCP cũng trở thành một lớp thích nghi khác đi vào cùng đường thực thi bên trong.
Như vậy trình duyệt, ứng dụng, API hay AI không cần tạo ra bốn con đường nghiệp vụ khác nhau.
Chúng đi vào cùng một đường thực thi.
Đó không còn là câu chuyện thêm một tính năng.
Đó là câu chuyện kiến trúc đã tạo sẵn một đòn bẩy mà khi thế giới thay đổi, toàn bộ hệ thống có thể hấp thụ thay đổi đó tại một điểm.
Project không có đặc tính này.
Product có một phần.
Platform được xây chính để tạo ra nó.
Từ Platform đến Standard còn một bước khác
Nhưng Platform vẫn chưa phải Standard.
Một Platform có thể rất tốt mà chỉ có một tổ chức sử dụng.
Muốn đi lên Standard, nó phải vượt khỏi chính implementation của mình.
Cách giao tiếp, cách mô tả năng lực, cách các thành phần kết nối và các hợp đồng kỹ thuật phải đủ rõ để những hệ thống độc lập khác có thể cùng thực thi.
Từ đó mới xuất hiện một khả năng lớn hơn:
người khác không cần dùng chính phần mềm của bạn, nhưng vẫn phải tương thích với cách mà bạn đã góp phần định nghĩa.
Đó mới là quyền lực của Standard.
Và đó cũng là lý do một lựa chọn công nghệ đi trước bốn năm, nếu thực sự có khả năng đi theo con đường này, không thể được định giá bằng câu hỏi:
“Hiện tại có bao nhiêu ngân hàng mua nó?”
Câu hỏi đó đúng với Project.
Nhưng sai tầng với một tài sản đang nhắm tới Standard.
Khi tài sản trí tuệ bị nhìn thành giải pháp
Ở đây xuất hiện một cơ chế rất dễ xảy ra.
Một tổ chức project-based gặp một tài sản trí tuệ.
Vì trong hệ quy chiếu của nó không có ô tương ứng, tài sản đó sẽ được dịch về thứ gần nhất mà tổ chức đã quen:
giải pháp.
Sau khi đã bị dịch thành giải pháp, chuỗi câu hỏi quen thuộc xuất hiện:
Khách hàng nào cần?
Có Project nào không?
Ai sẽ mua?
Doanh thu năm đầu bao nhiêu?
Nếu câu trả lời chưa hấp dẫn, cơ hội được loại bỏ.
Không có gì sai trong quá trình đó.
Chỉ có một vấn đề:
câu hỏi đã được đặt sai tầng.
Với một tài sản có khả năng tiến tới Standard, câu hỏi đầu tiên không phải “ai đang mua nó?”.
Câu hỏi đáng quan tâm hơn là:
Nếu cách này trở thành chuẩn, bao nhiêu hệ thống sẽ phải tương thích với nó?
Một bên nhìn doanh thu của từng hợp đồng.
Bên kia nhìn khả năng hình thành sự phụ thuộc của cả hệ sinh thái.
Hai cách định giá đó rất khó gặp nhau.
Thành công cũng có thể tạo ra điểm mù
Đây là phần nghịch lý nhất.
Một tổ chức không nhất thiết mắc kẹt vì thất bại.
Nó có thể mắc kẹt chính vì mô hình hiện tại đã thành công quá lâu.
Project-based đã giúp FPT xây hàng chục nghìn nhân sự, phục vụ khách hàng toàn cầu và trở thành một trong những doanh nghiệp công nghệ lớn nhất Việt Nam.
Mỗi năm thành công lại thêm một lần xác nhận rằng:
cách nhìn hiện tại là đúng.
Từ tuyển dụng, bán hàng, quản lý khách hàng, triển khai, tài chính đến chỉ tiêu vận hành đều dần tối ưu quanh cùng một logic:
Khách hàng.
Project.
Nhân lực.
Công suất triển khai.
Doanh thu.
Biên lợi nhuận.
Sau gần ba mươi năm, đó không còn đơn giản là mô hình kinh doanh.
Nó trở thành phản xạ tổ chức.
Một tài sản xuất hiện mà chưa có khách hàng cụ thể sẽ bị coi là quá sớm.
Một Platform chưa có doanh thu trực tiếp sẽ khó định giá.
Một đặc tả chưa biết “ai mua” có thể nhìn giống như một điều nhảm nhí vô nghĩa.
Trong khi một số tài sản công nghệ có giá trị nhất lại không bắt đầu bằng câu hỏi “bán cho ai”.
Chúng bắt đầu bằng một câu hỏi khác:
Nếu cách này đúng, liệu sau này người khác có phải làm theo không?
Cơ hội bị bỏ lỡ không nhất thiết chỉ vì không nhìn thấy
Người ta thường kể chuyện doanh nghiệp bỏ lỡ công nghệ mới như thể vấn đề nằm ở sự bảo thủ.
Tôi nghĩ có một cơ chế đơn giản hơn.
Con người và tổ chức định giá thứ mới bằng kinh nghiệm kinh tế mà họ đã có.
Nếu cả đời kiếm tiền từ Project, một công nghệ mới sẽ được hỏi xem nó tạo Project gì.
Nếu đã sống bằng Product, người ta sẽ nhìn khả năng nhân bản.
Nếu đã xây Platform, người ta sẽ nhìn mức độ phụ thuộc của hệ sinh thái.
Nếu từng tạo Standard, người ta sẽ nhìn khả năng được chấp nhận và quyền định hình luật chơi.
Vì vậy đôi khi một công ty nhỏ có thể nhìn thấy giá trị mà một tập đoàn hàng chục nghìn người không thấy.
Không phải vì công ty nhỏ thông minh hơn.
Mà vì hai bên đang đứng ở hai hệ quy chiếu khác nhau.
Đó cũng là lý do một lựa chọn công nghệ đi trước bốn năm, có tiềm năng tiến tới tiêu chuẩn của thời kỳ hậu AI, có thể nằm trên bàn một doanh nghiệp công nghệ rất lớn mà cuối cùng vẫn được đọc thành:
“một giải pháp cho vài ngân hàng.”
Hệ thống đã tiếp nhận nó rất nhanh. Đã chuyển nó rất đúng người. Đã phản hồi rất đúng với logic hiện tại.
Nó đã được nhìn thấy.
Chỉ là bị nhìn từ sai tầng.
Cơ hội lớn đôi khi bị bỏ lỡ không chỉ vì người ta không nhìn thấy nó. Nó bị bỏ lỡ vì người ta định giá nó bằng OKR của Project — bằng hệ quy chiếu của tầng phía dưới.
