Cách các tư vấn viên AI xác định phạm vi dự án thay thế SaaS nội bộ

Bất kỳ chuyên gia tư vấn đáng tiền nào cũng xác định phạm vi thay thế SaaS bằng giải pháp nội bộ theo cùng một cách: chia mỗi công cụ thành những phần bạn có thể nhìn thấy và những phần buộc phải chính xác mỗi lần thực hiện. SaaS (phần mềm bạn thuê theo tháng) phần lớn là các màn hình, quy trình công việc và báo cáo nằm trên một lõi lưu trữ dữ liệu nhỏ hơn. AI đã giúp việc tái xây dựng một nửa đầu tiên trở nên vô cùng rẻ. Nửa còn lại mới là nơi các dự án thay thế thường thất bại, và một kế hoạch phạm vi tốt tồn tại là để đo lường xem bao nhiêu phần trong hóa đơn đăng ký định kỳ của bạn thực sự nằm ở đó.

Dưới đây là cách từng bước xây dựng phạm vi dự án thay thế SaaS nội bộ và câu hỏi duy nhất quyết định phần lớn quá trình này. (Tên nhà cung cấp và số liệu khảo sát bên dưới chính xác tại thời điểm xuất bản; hãy coi các thông tin cụ thể này là bức ảnh chụp tại một thời điểm.)

Phạm vi thay thế SaaS thực sự bao gồm những gì?

Một danh mục các nhiệm vụ, chứ không phải danh sách tính năng. Chuyên gia tư vấn sẽ liệt kê mọi nhiệm vụ mà công cụ đảm nhận, ai tương tác với từng nhiệm vụ và điều gì sẽ xảy ra nếu kết quả đầu ra bị sai. Các chuỗi phê duyệt, bảng điều khiển (dashboard) và biểu mẫu được xếp vào một cột. Dòng tiền chuyển động, số lượng tồn kho, thuế và hồ sơ nhân viên được xếp vào cột khác. Sản phẩm bàn giao là sơ đồ đó, mức độ rủi ro cho mỗi nhiệm vụ và danh sách mọi hệ thống mà công cụ đang âm thầm kết nối.

Câu hỏi để đánh giá rủi ro chính là mấu chốt của vấn đề: nếu kết quả đầu ra này bị sai, bạn sẽ phát hiện ra bằng cách nào và chi phí phải trả là bao nhiêu? Một bảng điều khiển không cập nhật dữ liệu có thể nhận ra ngay lập tức và không tốn chi phí. Nhưng một tổng số tiền chi trả bị sai chỉ được phát hiện vào kỳ quyết toán thuế và sẽ tiêu tốn tiền thật.

Tại sao lại chia sản phẩm thành hai lớp?

Bởi vì AI đã kéo giảm chi phí của một lớp xuống mức tối thiểu nhưng lại không thể tác động đến lớp còn lại. Lớp giao diện (biểu mẫu, bảng điều khiển, công cụ nội bộ, quy trình phê duyệt) giờ đây có thể tái xây dựng rất nhanh; các mô hình hiện tại có thể tạo ra các ứng dụng web hoạt động được chỉ trong vài giờ, đây chính xác là những gì chúng tôi tìm ra khi đặt câu hỏi liệu GPT-5.6 có thể xây dựng một hệ thống POS hoạt động được hay không. Lớp hạ tầng lại hoàn toàn khác: xử lý thanh toán, tuân thủ PCI (các quy định bảo mật thẻ mà các đơn vị xử lý thanh toán bắt buộc), quản lý tồn kho theo thời gian thực (hai máy thu ngân cùng bán sản phẩm cuối cùng), và các báo cáo đối soát (tổng số tiền khớp với khoản tiền gửi ngân hàng của bạn). Lớp đó khó không phải vì mã nguồn dài, mà vì sự 'gần đúng' ở đó chẳng có giá trị gì, và chi phí để chứng minh tính chính xác còn đắt hơn chi phí tạo ra mã nguồn.

Ngay cả các mô hình tốt hơn cũng không loại bỏ được rào cản đó. Điểm nghẽn nằm ở khâu kiểm thử tính chính xác và trách nhiệm pháp lý, chứ không phải ở việc tạo mã nguồn, vì vậy một bản phạm vi dự án thực tế sẽ định giá cho việc xác minh. Tạo mã chỉ là bản demo. Xác minh mới chính là hóa đơn thanh toán.

Dự án thay thế SaaS của Klarna thực sự đã chứng minh điều gì?

Rầm rộ nhất với câu chuyện "chúng tôi đã thay thế SaaS bằng AI" thực ra lại là một bài học về xác định phạm vi dự án. Vào cuối năm 2024, CEO của Klarna thông báo công ty sẽ ngừng sử dụng Salesforce và Workday như một phần của kế hoạch cải tổ bằng AI, và các tiêu đề báo chí đồng loạt đưa tin AI đang thay thế hoàn toàn SaaS. Các báo cáo sau đó ghi nhận thông tin chính xác hơn: Klarna đã chuyển nhân sự (HR) sang một nhà cung cấp khác và giải quyết nhu cầu CRM bằng sự kết hợp giữa các công cụ thay thế và các mã nối tự phát triển, với AI được tích hợp ở lớp trên cùng¹. Một ngân hàng được cấp phép đang vận hành một trong những chương trình AI quyết liệt nhất trong ngành fintech vẫn giữ hệ thống lưu trữ dữ liệu chính thức (copy gốc duy nhất và chuẩn xác về dữ liệu kinh doanh của bạn) trên các nền tảng đã được kiểm chứng và chỉ tái xây dựng ở phần rìa.

Đó không phải là sự thiếu quyết đoán. Đó là kết quả của việc xác định phạm vi dự án hoạt động đúng hướng.

Những con số nào chứng minh một dự án thay thế là hợp lý?

Cắt giảm lãng phí trước, xây dựng sau. Chỉ số Quản lý SaaS 2026 của Zylo, được trích xuất từ hơn 40 triệu giấy phép đang quản lý, chỉ ra rằng chi phí SaaS trung bình là 9.455 USD cho mỗi nhân viên mỗi năm, tìm thấy trung bình 36% giấy phép không được sử dụng, và cho thấy các đơn vị kinh doanh kiểm soát 81% chi phí SaaS trong khi bộ phận IT chỉ trực tiếp quản lý 15%². Một chuyên gia tư vấn sẽ đánh giá tập hợp công cụ của bạn so với các con số này trước khi đề xuất bất kỳ điều gì: hủy các tài khoản không dùng đến, hợp nhất các công cụ chồng chéo, và chỉ sau đó mới lập danh sách rút gọn các ứng dụng cần xây dựng lại.

Các công cụ nằm trong danh sách rút gọn có chung đặc điểm: chi phí định kỳ cao, các nhiệm vụ phần lớn nằm ở lớp giao diện, và mức độ ảnh hưởng nhỏ khi xảy ra sự cố. Dự án sẽ được phê duyệt khi chi phí đăng ký định kỳ tăng nhanh hơn chi phí xây dựng và bảo trì, đồng thời mọi nhiệm vụ đòi hỏi tính chính xác tuyệt đối đều có thể giữ lại trên hạ tầng do đơn vị khác vận hành.

Hệ thống POS nằm ở đâu trong khung xác định phạm vi này?

Nằm ở góc khắt khe nhất của biểu đồ. Một hệ thống POS có vẻ giống như một dự án giao diện, một lưới các nút bấm và giỏ hàng, vì vậy các chủ doanh nghiệp cho rằng phạm vi của nó tương tự như một bảng điều khiển. Nhưng tỷ lệ thực tế lại ngược lại. Màn hình thanh toán chỉ là một phần nhỏ của sản phẩm; phần còn lại là thanh toán, thiết bị đầu đọc thẻ đã được chứng nhận, tồn kho chịu được việc hai máy thu ngân bán cùng lúc, các quy tắc thuế và các báo cáo đối soát cuối ngày. Khi POS xảy ra lỗi, nó làm sai lệch tiền bạc, xảy ra hàng ngày.

Vì vậy, các tư vấn viên xác định phạm vi tái xây dựng POS theo cách Klarna xử lý sổ cái của mình: giao diện tùy chỉnh, hạ tầng đã được kiểm chứng. Việc phân tách này từng đòi hỏi một đội ngũ lập trình viên. Nhưng giờ đây nó đã trở thành một danh mục sản phẩm: Build của Final biến câu lệnh ngôn ngữ tự nhiên thành một quy trình thanh toán bạn có thể xem trước và triển khai, và bạn có thể kết nối AI của riêng mình qua MCP để xây dựng trên cùng một hạ tầng thương mại đó. Thanh toán, tồn kho, báo cáo và phần cứng đều được giữ lại trên lớp hạ tầng đã được xác minh tính chính xác.

Vậy bạn nên xác định phạm vi thay thế SaaS nội bộ như thế nào?

Tách mọi công cụ thành hai lớp, đánh giá từng nhiệm vụ theo chi phí nếu kết quả đầu ra sai mà không được phát hiện, và định giá cho việc xác minh hơn là việc viết mã. Tùy ý tái xây dựng giao diện và quy trình làm việc; hãy để các hệ thống lưu trữ dữ liệu chính thức trên hạ tầng mà người khác đảm bảo tính chính xác. Trước khi tái xây dựng bất kỳ công cụ nào trong nội bộ, hãy tự hỏi: nếu kết quả đầu ra của nó bị sai, bao lâu thì tôi sẽ phát hiện ra? Nếu câu trả lời là "không nhanh", nhiệm vụ đó nên được giữ lại trên các nền tảng đã được kiểm chứng.

Và nếu phần thương mại trong hệ thống của bạn là phần bạn muốn xây dựng lại, hãy bắt đầu bằng một cái nhìn thực tế về những gì các mô hình ngày nay có thể và không thể tự xây dựng: Claude vs ChatGPT vs Gemini trong việc xây dựng POS thực tế, hoặc hai hướng đi no-code trong cách sử dụng Gemini 3.6 Flash để xây dựng POS tùy chỉnh.