Một khách hàng từng hỏi “làm phần mềm này mất bao lâu?” nay có thể hỏi “AI tự làm được rồi, vì sao tôi vẫn cần thuê bạn?”. Câu hỏi ấy chạm vào thay đổi quan trọng của ngành: khi tạo ra một tính năng trở nên dễ hơn, nhà cung cấp phải giải thích rõ hơn phần giá trị nằm ngoài việc viết mã.
AI đang tác động đồng thời đến cách phần mềm được xây dựng, cách khách hàng mua và cách nhà cung cấp kiếm tiền. Với doanh nghiệp phần mềm, điều cần theo dõi là công việc nào khách có thể tự làm, phần nào vẫn cần năng lực chuyên môn và kết quả nào đủ đáng tin để khách tiếp tục trả phí.
Bài viết đối chiếu các nghiên cứu, phân tích và khảo sát công khai của McKinsey, kết hợp với phân tích ứng dụng. Các tình huống và phép tính minh họa là ví dụ riêng, không phải case study hay kết luận của McKinsey. Hình được thiết kế mới; đồ họa số liệu ghi nguồn và thời điểm để người đọc kiểm tra.
Nên đọc nghiên cứu McKinsey nào về AI và ngành phần mềm?
Bài trọng tâm là The AI-centric imperative: Navigating the next software frontier (16/10/2025). Khung bảy hướng chuyển đổi được tóm lược trong sơ đồ dưới đây.
Để có thêm bối cảnh, bài Navigating the generative AI disruption in software (05/06/2024) dự báo AI có thể đẩy nhanh việc đổi nhà cung cấp và làm tăng xu hướng tự xây phần mềm. Đây là phân tích triển vọng tại thời điểm công bố, không phải số đo kết quả toàn thị trường năm 2026.
Khảo sát The state of AI in 2026: On the road to ROI (25/08/2026) ghi nhận 32% người trả lời báo cáo tổ chức đã bỏ ít nhất một quyết định mua sản phẩm hoặc tính năng vì có thể tự xây bằng công cụ lập trình AI. Phạm vi khảo sát ghi trong hình.
Năng suất tăng chưa tự động trở thành lợi nhuận
Các tỷ lệ trong hình đo những khía cạnh khác nhau: hành vi mua, năng suất cá nhân, EBIT và giới hạn chi phí. Chúng không tạo thành một phép đối chiếu lợi nhuận trực tiếp.
Có thể hình dung khoảng cách này qua một nhóm làm sản phẩm. Trước đây họ dành năm ngày viết một chức năng; nay bản nháp có sau hai ngày. Tuy nhiên, nếu yêu cầu vẫn thay đổi liên tục, dữ liệu kiểm thử chưa chuẩn và việc phê duyệt mất thêm một tuần, khách hàng chưa nhận được chức năng sớm hơn tương ứng. Năng suất ở một công đoạn chưa giải phóng nút thắt của toàn bộ công việc.
Tương tự, nhân viên có thể làm nhanh hơn nhưng công ty chưa bán được thêm, chưa giảm chi phí thực trả và chưa dùng thời gian trống vào việc có giá trị. Muốn chuyển năng suất thành hiệu quả, cần biết phần thời gian được giải phóng đi đâu. Nó giúp xử lý thêm khách hàng, giảm số lần sửa, rút ngắn thời gian chờ hay đơn giản chỉ tạo nhiều bản nháp hơn?
Vì vậy, một chỉ tiêu như “tỷ lệ mã do AI tạo” khó phản ánh đầy đủ thành công. Bộ chỉ tiêu phù hợp hơn có thể gồm thời gian từ yêu cầu đến nghiệm thu, tỷ lệ lỗi sau triển khai, số giờ bảo trì, chi phí trên một tác vụ hoàn tất và mức độ khách tiếp tục sử dụng. Các chỉ tiêu phải có cùng cách đo trước và sau thay đổi.
Khi khách hàng tự xây được: phần nào thực sự bị thay thế?
Hãy xét một doanh nghiệp phân phối có nhu cầu nhập danh sách đơn hàng và lọc đơn giao chậm. Trước đây họ có thể mua một ứng dụng nhỏ hoặc thuê viết một màn hình. Nay một người hiểu dữ liệu có thể dùng công cụ AI để dựng bản đầu tiên, nhập file và xuất danh sách cần xử lý. Với nhu cầu nội bộ đơn giản, cách tự làm có thể đủ tốt.
Đây là ví dụ minh họa về một phạm vi hẹp, không phải khẳng định mọi khách hàng đều làm được. Khi nhu cầu mở rộng sang nhiều kho, phân quyền nhân viên, đồng bộ vận đơn và lịch sử điều chỉnh, câu hỏi sẽ khác. Nếu tác vụ chạy sai lúc không có người theo dõi, ai phát hiện? Khi nhà vận chuyển đổi cấu trúc dữ liệu, ai cập nhật? Khi người tự xây nghỉ việc, ai tiếp tục vận hành?
Chi phí viết mã ban đầu chỉ là một phần tổng chi phí sở hữu. Cần tính cả thời gian hiểu yêu cầu, kiểm thử, triển khai, bảo mật, giám sát, sửa lỗi, sao lưu và bàn giao. AI có thể hỗ trợ nhiều phần trong đó, nhưng doanh nghiệp vẫn cần phân công trách nhiệm. “Tự xây” thực chất là nhận thêm một công việc vận hành, không chỉ sở hữu thêm một file mã nguồn.
| Phạm vi ví dụ | Cách làm có thể phù hợp | Điều phải kiểm tra |
|---|---|---|
| Công cụ cá nhân, dữ liệu không nhạy cảm | Tự làm bản nhỏ với AI | Đầu vào đúng, kết quả kiểm tra được, người dùng biết giới hạn. |
| Luồng nội bộ nhiều người dùng | Tự xây có người phụ trách hoặc thuê hỗ trợ | Phân quyền, lỗi, bảo trì và khả năng tiếp quản. |
| Hệ thống giao dịch quan trọng | Đánh giá kỹ mua, xây hoặc kết hợp | Tính nhất quán dữ liệu, khả năng phục hồi, trách nhiệm và chi phí vòng đời. |
Với nhà cung cấp, phản ứng hợp lý là xác định phần khách có thể tự làm và phần mình có thể làm tốt hơn một cách kiểm chứng được. Nếu một màn hình chỉ là lớp lọc dữ liệu đơn giản, rất khó bảo vệ giá chỉ bằng số ngày lập trình cũ. Ngược lại, khả năng đưa hệ thống vào vận hành ổn định, tích hợp đúng và xử lý ngoại lệ có thể là một phần đáng bán nếu khách thực sự có nhu cầu đó.
Giá trị phần mềm dịch chuyển về đâu?
Bài McKinsey năm 2025 mô tả agent hỗ trợ SaaS, kiến trúc lấy agent làm trung tâm và agent chuyên môn; đồng thời bàn về định giá theo sử dụng hoặc kết quả.
Để hiểu tác động trong một tình huống cụ thể, có thể tách sản phẩm thành ba phần: nơi lưu và xác nhận sự thật nghiệp vụ, nơi người dùng tương tác, và nơi công việc được điều phối. Đây là cách phân tích minh họa cho bài viết, không phải một khung được gán cho McKinsey.
Nơi lưu và xác nhận sự thật nghiệp vụ
Ví dụ, một đơn hàng đã được giao hay chưa, khách còn nợ bao nhiêu và tồn kho được phép bán là bao nhiêu. Những thông tin này cần quy tắc rõ và khả năng đối soát. Một câu trả lời nghe hợp lý không thay thế được trạng thái giao dịch đã xác nhận. Nếu dùng AI để hỏi tồn kho, hệ thống vẫn cần xác định dữ liệu nào có thẩm quyền và thời điểm số liệu có hiệu lực.
Nơi người dùng tương tác
Một số thao tác trước đây cần tìm menu, chọn bộ lọc và xuất file có thể được thực hiện bằng câu hỏi tự nhiên. Nhưng giao diện ngôn ngữ không phải lúc nào cũng tốt hơn. Nhập hàng loạt, so sánh nhiều dòng hoặc kiểm tra số chính xác có thể vẫn cần bảng và biểu mẫu. Thiết kế tốt là chọn cách tương tác phù hợp công việc, không buộc mọi tác vụ đi qua một ô chat.
Nơi điều phối công việc
Người quản lý hỏi “đơn nào cần ưu tiên hôm nay?” không chỉ muốn một danh sách. Họ có thể cần nhóm theo mức trễ, xác định người phụ trách, soạn việc cần làm và theo dõi xử lý. Phần điều phối nằm giữa nhiều hệ thống và nhiều người. Nó có giá trị nếu giảm được thời gian chờ hoặc bỏ sót, đồng thời giữ được quyền phê duyệt cho hành động có tác động lớn.
Trong ví dụ trên, có thể bán “một màn hình danh sách giao chậm”, hoặc cung cấp “quy trình phát hiện và giao xử lý đơn trễ, có đối soát và báo cáo ngoại lệ”. Hai phạm vi có trách nhiệm khác nhau. Phạm vi thứ hai chỉ đáng giá hơn khi khách cần nó, kết quả đo được và chi phí cung cấp còn hợp lý. Đổi tên dịch vụ thành AI Automation không tự tạo thêm giá trị.
Thu phí theo kết quả: hấp dẫn nhưng cần định nghĩa rất rõ
“Bán kết quả” dễ bị hiểu thành nhà cung cấp phải bảo đảm mọi chỉ tiêu kinh doanh. Thực tế, nhiều kết quả nằm ngoài quyền kiểm soát của phần mềm. Một hệ thống nhắc công nợ có thể gửi đúng hạn và giúp nhân viên ưu tiên, nhưng không tự quyết định khả năng thanh toán của khách. Cam kết tăng doanh thu mà không tách ảnh hưởng của giá, thị trường và đội bán hàng sẽ rất khó nghiệm thu.
Một cách bắt đầu là chọn đầu ra gần với khả năng kiểm soát: hồ sơ được đối chiếu theo tiêu chí, bản tin được kiểm tra, yêu cầu hỗ trợ được xử lý đúng phạm vi hoặc đơn hàng được phân loại với chất lượng đã thống nhất. Cần xác định cách tính khi tác vụ phải làm lại, khi người dùng không chấp nhận, và khi không có đủ dữ liệu. Số lượt gọi mô hình không nên tự động được coi là số việc hoàn tất.
| Mô hình thu phí | Phù hợp khi | Điểm cần làm rõ |
|---|---|---|
| Theo người dùng | Giá trị gắn với quyền truy cập và cộng tác | Vai trò agent, tài khoản kỹ thuật và người chỉ đọc. |
| Theo sử dụng | Chi phí và nhu cầu tăng theo khối lượng tác vụ | Đơn vị đo, giới hạn ngân sách, lượt lỗi và lượt chạy lại. |
| Theo đầu ra được chấp nhận | Có tiêu chuẩn nghiệm thu tương đối rõ | Ai chấp nhận, xử lý ngoại lệ, cơ chế đối soát. |
| Phí nền tảng kèm mức sử dụng | Cần duy trì hệ thống và có khối lượng biến động | Phần cố định bao gồm gì, vượt mức tính thế nào. |
Không có mô hình nào phù hợp cho mọi công ty. Nhà cung cấp nhỏ có thể dùng phí triển khai cho việc kết nối ban đầu, phí duy trì cho giám sát và bảo trì, kèm một mức tác vụ xác định. Đây là một lựa chọn thiết kế thương mại cần thử nghiệm với khách hàng, không phải mức giá chuẩn hay lời khuyên rằng phải bỏ hoàn toàn cách thu phí hiện tại.
Ví dụ kinh tế: tự động hóa có đáng bán và đáng mua không?
Giả sử một nhóm cần xử lý 1.000 hồ sơ mỗi tháng. Quy trình cũ mất trung bình 12 phút một hồ sơ, tổng cộng 200 giờ. Quy trình mới còn 4 phút kiểm tra thông thường cho mỗi hồ sơ, tức khoảng 66,7 giờ. Có 100 trường hợp cần thêm 10 phút xử lý ngoại lệ, tương đương 16,7 giờ. Tổng công còn khoảng 83,3 giờ, giải phóng khoảng 116,7 giờ. Đây hoàn toàn là số giả định để giải thích cách tính.
Nếu quy đổi năng lực ở mức giả định 150.000 đồng mỗi giờ, phần thời gian được giải phóng tương đương 17,5 triệu đồng. Giả sử tổng chi phí định kỳ của giải pháp là 8 triệu đồng, phần chênh lệch về giá trị năng lực là 9,5 triệu đồng mỗi tháng, trước chi phí thiết lập ban đầu và các khoản chưa tính. Không thể gọi toàn bộ số này là tiền tiết kiệm nếu chi phí nhân sự thực trả không giảm.
Hơn nữa, phép tính chỉ hợp lệ nếu chất lượng được giữ ở mức chấp nhận. Nếu hồ sơ bị phân loại sai, công sửa hoặc thiệt hại có thể xóa lợi ích thời gian. Nếu nhân viên không dùng giải pháp, mô hình chi phí trên giấy cũng không thành hiện thực. Cần đo trên một mẫu công việc đại diện, giữ cách đo nhất quán và tính cả công duyệt lẫn ngoại lệ.
Ở phía người bán, doanh thu 8 triệu không phải lợi nhuận 8 triệu. Cần trừ chi phí mô hình, hạ tầng, theo dõi, hỗ trợ, sửa lỗi và phần chi phí chung liên quan. Một thiết kế gọi mô hình nhiều lần cho mọi bước có thể làm biên lợi nhuận xấu đi khi khách dùng nhiều hơn. Giá bán và kiến trúc xử lý phải được xem cùng nhau.
Doanh nghiệp dịch vụ phần mềm cần thay đổi điều gì?
Trong Reimagining the value proposition of tech services for agentic AI (17/12/2025), McKinsey phân tích hai lực trái chiều: sức ép lên dịch vụ công nghệ truyền thống và cơ hội từ các công việc triển khai, vận hành mô hình người–agent. Khảo sát nền của bài gồm 200 lãnh đạo cấp cao tại doanh nghiệp có doanh thu trên 500 triệu USD; không nên coi là đại diện trực tiếp cho doanh nghiệp nhỏ Việt Nam.
Từ đó, cách áp dụng cần được kiểm tra với phân khúc cụ thể. Với một đơn vị làm phần mềm theo yêu cầu, năng lực viết nhanh giúp giảm chi phí nội bộ, nhưng câu chuyện bán hàng vẫn phải trả lời: khách đang kẹt ở đâu và vì sao chưa tự xử lý được? Có thể vướng dữ liệu rời rạc, thiếu người hiểu nghiệp vụ, không có người nhận trách nhiệm vận hành hoặc chưa tìm được cách nghiệm thu phù hợp.
Khách tự tuyển một kỹ sư nội bộ không đồng nghĩa họ không còn mua dịch vụ. Người nội bộ hiểu bối cảnh và theo sát công việc hằng ngày; bên ngoài có thể cung cấp chuyên môn hẹp, xử lý một giai đoạn khó hoặc hỗ trợ vận hành theo phạm vi rõ. Muốn hợp tác, nhà cung cấp cần bổ sung cho đội hiện có thay vì chỉ lặp lại một năng lực mà khách vừa tuyển được.
Một ví dụ là khách đã có người làm dashboard nhưng chưa có dữ liệu đối soát ổn định. Bán thêm một dashboard tương tự có thể không thuyết phục. Một gói chuẩn hóa chỉ tiêu, kiểm tra nguồn và bàn giao luồng dữ liệu có giám sát có thể giải quyết nút thắt gần hơn. Dù vậy, đây vẫn là giả thuyết sản phẩm phải xác nhận bằng nhu cầu và khả năng trả phí, không phải bảo đảm có thị trường.
Một lộ trình thử nghiệm có giới hạn cho công ty phần mềm
Bắt đầu bằng việc rà lại một nhóm khách hàng hoặc một loại dự án. Liệt kê các việc khách đang tự làm bằng AI, những lỗi họ gặp và phần công việc vẫn phải nhờ hỗ trợ. Tách lời khen về công nghệ khỏi bằng chứng sử dụng: khách có quay lại dùng không, có giao người chịu trách nhiệm không, có chấp nhận tiêu chí và chi phí duy trì không?
Sau đó chọn một công việc đủ hẹp để quan sát từ đầu đến cuối. Ví dụ đối soát một nguồn dữ liệu, tổng hợp một loại hồ sơ hoặc xử lý một nhóm yêu cầu hỗ trợ. Chốt đầu vào, đầu ra, giới hạn quyền và trường hợp chuyển người kiểm tra. Đừng hứa triển khai tự chủ toàn doanh nghiệp khi chưa biết cách xử lý một ngoại lệ lặp lại.
| Giai đoạn | Việc cần có | Bằng chứng để đi tiếp |
|---|---|---|
| Hiểu vấn đề | Quan sát luồng hiện tại, xác định người dùng và mốc ban đầu | Có công việc lặp lại, có người sở hữu và có cách đo. |
| Làm bản giới hạn | Kết nối dữ liệu tối thiểu, tạo đầu ra và kiểm tra ngoại lệ | Kết quả đối chiếu được trên mẫu đại diện. |
| Chạy song song | So với quy trình hiện tại, đo cả công sửa và chi phí | Chất lượng đạt tiêu chí, người dùng thực sự sử dụng. |
| Vận hành trả phí | Rõ trách nhiệm, giới hạn khối lượng và cách hỗ trợ | Hiệu quả cho khách và chi phí cung cấp đều phù hợp. |
Chỉ tăng phạm vi khi bước trước tạo đủ bằng chứng. Nếu thất bại vì dữ liệu chưa chuẩn, ưu tiên sửa dữ liệu. Nếu thất bại vì đầu ra không ai dùng, quay lại quyết định cần hỗ trợ. Nếu thất bại vì chi phí quá cao, xem lại kiến trúc và phạm vi trước khi tăng giá. Một thử nghiệm nhỏ có giới hạn giúp nhận diện sai lầm sớm hơn việc xây cả nền tảng rồi mới tìm lý do sử dụng.
Câu hỏi quan trọng hơn: khách hàng còn cần mình vì điều gì?
AI làm cho việc tạo phần mềm dễ tiếp cận hơn, nhưng nhu cầu của khách không dừng ở việc có thêm một ứng dụng. Họ cần công việc được giải quyết với mức chi phí, độ tin cậy và trách nhiệm phù hợp. Doanh nghiệp phần mềm cần hiểu phần nào của lời hứa hiện tại đã trở nên dễ thay thế, và phần nào có thể chứng minh bằng kết quả sử dụng.
Cách ứng phó thiết thực là dùng AI để nâng năng lực cung cấp, đồng thời làm rõ lý do khách trả tiền. Hãy chọn một nhóm công việc, đưa ra tiêu chí nghiệm thu, đo chi phí đầy đủ và chứng minh giá trị ở phạm vi nhỏ. Khi điều đó vận hành tốt, sản phẩm, dịch vụ và cách thu phí mới có cơ sở để mở rộng.
Bạn có thể đọc tiếp AI Automation trong phân tích dữ liệu: từ dữ liệu đến hành động để xem cách thiết kế một luồng có bằng chứng, kiểm chứng và trách nhiệm xử lý.
Nguồn nghiên cứu và ghi chú biên tập
- McKinsey — The AI-centric imperative: Navigating the next software frontier (16/10/2025).
- McKinsey — Navigating the generative AI disruption in software (05/06/2024).
- McKinsey — The state of AI in 2026: On the road to ROI (25/08/2026).
- McKinsey — Reimagining the value proposition of tech services for agentic AI (17/12/2025).
TechData.AI biên soạn độc lập từ nguồn công khai, kiểm tra ngày 14/11/2026. Đây là bài phân tích và bình luận, không phải bản dịch toàn văn hay nội dung do McKinsey tài trợ. Các ví dụ, bảng áp dụng và phép tính kinh tế là minh họa riêng; đồ họa thống kê giữ nguồn McKinsey, các ảnh bối cảnh được tạo mới. Không suy rộng kết quả khảo sát thành tác động chắc chắn cho từng doanh nghiệp.