- Mô hình SaaS từng thuyết phục ngành IT bằng lời hứa “chỉ trả cho những gì cần dùng và tập trung vào kinh doanh thay vì công nghệ”, nhưng trên thực tế đã biến chất thành một cấu trúc khóa chặt (lock-in) khách hàng
- Các nhà cung cấp lớn tập trung vào duy trì thanh toán liên tục và thu thập dữ liệu hơn là sự hài lòng của khách hàng, và ngay cả “quản lý thành công khách hàng” cũng chỉ là vai trò để ngăn rời bỏ
- Toàn ngành né tránh thay đổi và đổi mới dưới danh nghĩa “thực tiễn tốt nhất (best practice)”, và kết quả là sản sinh ra một hệ sinh thái phần mềm đồng dạng và tầm thường
- Thị trường SaaS đã trở nên giống trung tâm thương mại Mỹ thập niên 1980: bị kiểm soát quá mức và dễ đoán, nơi các nền tảng lớn đồng thời đóng vai chủ cho thuê và cửa hàng
- Giải pháp thực sự không phải là dùng cùng một hệ thống như mọi người, mà là xây dựng hệ thống thông tin phù hợp với tổ chức, điều này có thể đạt được bằng các cách tiếp cận thay thế như tự lưu trữ
Lời hứa và thực tế của mô hình SaaS
- Ban đầu, SaaS đưa ra lý tưởng “trả theo mức dùng (pay as you go)” và “tập trung vào kinh doanh thay vì công nghệ”, hứa hẹn tối ưu hóa hiệu quả vận hành IT
- Người dùng được thuyết phục bằng thông điệp rằng họ có thể tiết kiệm vốn và thời gian và giảm gánh nặng quản lý kỹ thuật
- Nhưng trên thực tế, các nhà cung cấp lớn như Microsoft, Google, Intuit đã phát triển theo hướng ưu tiên sự lệ thuộc của khách hàng hơn là lấy khách hàng làm trung tâm
- Họ thực hiện khảo sát mức độ hài lòng sau mọi tương tác với khách hàng, nhưng đó chỉ là một phương tiện khác để thu thập dữ liệu lớn
- Kết quả khảo sát chỉ là thứ yếu; điều họ thực sự mong muốn là khách hàng ở lại và tiếp tục trả tiền
- Dữ liệu thu thập được chỉ được dùng cho những cải tiến gia tăng ở vùng rìa
Nghịch lý của quản lý thành công khách hàng
- Gần như mọi công ty SaaS đều tạo ra vai trò Quản lý thành công khách hàng (Customer Success Manager)
- Những người này được gán cho từng tài khoản để hỗ trợ onboarding và ngăn khách hàng rời bỏ
- “Thành công” ở đây không phải là thành công thực sự của tổ chức, mà chỉ là khiến họ sử dụng sản phẩm đủ nhiều
- Việc tạo ra một sản phẩm mà khách hàng thấy hữu ích tự nó không xấu, nhưng mô hình kinh doanh SaaS theo thời gian đã biến chất thành một cấu trúc dựa trên sự phục tùng (submission) và quán tính (inertia) chứ không phải thành công của khách hàng
- Đến một thời điểm nào đó, tệp khách hàng và sản phẩm trở nên quá lớn nên không thể thay đổi
Safety in Numbers - Ảo giác an toàn của số đông
- Nhiều doanh nghiệp chọn SaaS vì tâm lý “ai cũng làm vậy” và vì hiệu ứng mạng lưới
- Nếu mọi người đều đang làm, thì đó trở thành con đường ít kháng cự nhất, hoặc ít nhất là đủ tốt
- Hiệu ứng mạng lưới có giá trị, nhưng số đông chỉ an toàn đến một mức nào đó
- Số đông che giấu những rủi ro vô hình, đặc biệt là rủi ro kiểu thiên nga đen (black swan)
- Những rủi ro hiếm nhưng mang tính thảm họa quá hiếm gặp và có thể quá nghiêm trọng nên không ai thực sự nghĩ đến
- Hệ thống sao lưu, khôi phục thảm họa và duy trì liên tục kinh doanh có thể bảo vệ khỏi lỗi của một hệ thống đơn lẻ, nhưng không thể bảo vệ khỏi sự mất mát ngữ cảnh và bí quyết
- Vấn đề thật sự không phải là mất mát mà là sự tích tụ
- Quá nhiều chương trình, API, tích hợp và độ phức tạp quá mức được ngụy trang thành các hệ thống tinh vi
- Không tồn tại hệ thống khôi phục ngữ cảnh, nhưng các tổ chức thành công lại phụ thuộc vào ngữ cảnh chứ không phải dữ liệu
- Hàng terabyte dữ liệu là vô nghĩa nếu không biết vì sao mình giữ dữ liệu đó, nó có ý nghĩa gì và phải dùng nó như thế nào
Cái bẫy của dư thừa thông tin và ra quyết định
- Thông tin và nội dung là vô hạn và mang tính xác suất, không nhất thiết có thể dự đoán
- Nhiều thông tin hơn không dẫn đến quyết định tốt hơn, mà chỉ dẫn đến nhiều dữ liệu hơn
- Điều này nuôi lớn nỗi sợ và rủi ro trước những gì ta không biết
- Không thể biết hết mọi thông tin trước khi ra quyết định, nhưng khi đối mặt với điều chưa biết và bất định, việc áp dụng “best practice” mang lại một tấm chăn an toàn dễ chịu
Undifferentiated Best Practices — Thực tiễn tốt nhất không tạo khác biệt
- Toàn ngành tồn tại một niềm tin gần như mù quáng vào các mẫu “best practice”
- Vấn đề của best practice là nó giả định rằng thế giới đã ngừng thay đổi
- Trong thực tế, thế giới không tĩnh tại; nó liên tục thay đổi và đòi hỏi cải tiến và tiến hóa liên tục
- Việc mù quáng áp dụng các best practice được đóng khuôn không phải là con đường để trở thành tốt nhất, mà là con đường dẫn đến mức trung bình tầm thường
- Lập luận “đừng phát minh lại bánh xe” bị lạm dụng
- Theo đó, không cần tốn thời gian và công sức để giải quyết những vấn đề đã được giải quyết
- Nhưng trên thực tế, cách làm này chỉ giỏi đạt được trạng thái ngang bằng (parity) với đối thủ
- Cách tiếp cận đó tạo ra sự tầm thường nhạt nhòa (bland mediocrity) và vận hành như một cấu trúc ngăn cản khác biệt thực sự hay tiến bộ thật sự
Bland and Generic Applications — Hệ sinh thái phần mềm bị đồng dạng hóa
- Nhìn vào môi trường phần mềm thương mại, có hàng nghìn ứng dụng trong hàng nghìn danh mục, nhưng rốt cuộc chúng vẫn chỉ là các biến thể khác nhau của ứng dụng ghi chú hay lịch
- Một số chương trình có thể đẹp hơn hoặc trực quan hơn, nhưng định nghĩa vấn đề và cách tiếp cận thì tương tự nhau
- Lý do phần mềm cứ lặp đi lặp lại việc giải quyết cùng một loại vấn đề có thể giải được là vì những bài toán còn lại thực sự rất khó để giải bằng công nghệ
- Giao tiếp và cộng tác chứa đầy sắc thái và độ tinh tế kháng cự việc số hóa
- Điều này không chỉ giới hạn ở các công ty SaaS; phần lớn công ty phần mềm cũng gia nhập đoàn tàu SaaS để tiếp thị và bán sản phẩm
- Cung cấp phiên bản miễn phí với vừa đủ tính năng để lôi kéo người dùng vào gói thành viên trả phí
- Sau đó là ba lựa chọn đăng ký tiêu chuẩn kiểu good, better, best
- Thêm công cụ giao tiếp không khiến chất lượng giao tiếp tăng lên, mà chỉ làm lượng giao tiếp tăng mạnh, kéo theo nhiễu và mệt mỏi
Let’s Go to the Mall — SaaS và sự tương đồng với trung tâm thương mại thập niên 1980
- SaaS đã trở thành thứ công nghệ giống như trung tâm thương mại Mỹ thập niên 1980
- Đắt đỏ quá mức, dễ đoán, và ở trung tâm nào thì hàng hóa cũng gần như giống hệt nhau
- Đây không phải là một thị trường năng động mà là một thị trường bị kiểm soát rất chặt
- landlord thiết lập nền tảng, còn các nhà bán lẻ đổ về vị trí đắc địa này để hưởng lợi nhuận lớn và lợi thế quy mô
- Những nhà bán lẻ có thể chịu nổi tiền thuê trong trung tâm thương mại sẽ cung cấp một trải nghiệm bị kiểm soát rất chặt
- Trung tâm thương mại thập niên 1980 không phải nơi dành cho thử nghiệm táo bạo hay chấp nhận rủi ro; rủi ro nằm ở việc ký hợp đồng thuê
- Google và Microsoft vừa là cửa hàng trong trung tâm thương mại, vừa đồng thời là landlord kiểm soát trải nghiệm của cả trung tâm
- Apple vận hành trung tâm thương mại của riêng mình và hào nhoáng hơn nhưng không khác biệt
- Ngày nay, nhiều trung tâm thương mại vật lý sẽ thành phố ma nếu không có Apple Store kéo lưu lượng khách đến
- Đến một lúc nào đó, văn hóa đã mệt mỏi với trải nghiệm trung tâm thương mại, và khắp nước Mỹ đầy rẫy những trung tâm thương mại bị bỏ hoang
- Mô hình này có hiệu quả đến một ngưỡng nhất định, nhưng xu hướng thì thay đổi
- Những cửa hàng nhỏ với các sản phẩm được tuyển chọn cẩn thận bắt đầu xuất hiện và thu hút đám đông
- Tương lai của công nghệ thông tin cũng rất giống như vậy
- Điều quan trọng không phải là có cùng một hệ thống như tất cả mọi người khác
- Điều quan trọng là có một hệ thống thông tin phù hợp với chính mình
1 bình luận
Ý kiến Hacker News
Bàn về hiện tượng người tiêu dùng không muốn trả "giá thật" cho phần mềm, cũng giống như họ không muốn trả giá thật cho đồ ăn hay quần áo
Trước đây có thể mua một lần các công cụ như Postman với giá $40, nhưng giờ lại phải trả $30/tháng theo mô hình thuê bao
SaaS có ưu điểm là luôn giữ được phiên bản mới nhất
Nhưng phát triển phần mềm về bản chất là một công việc tốn kém về kinh tế, và giá trị đó đang bị đánh giá thấp nhờ lao động không công của các cộng tác viên mã nguồn mở
Trong 20 năm qua đã có lượng phần mềm khổng lồ được tạo ra, nhưng cảm giác là hầu như không có bước đột phá đổi mới nào đáng kể
Hiệu năng máy tính đã tốt hơn gấp 10~20 lần, nhưng ngược lại phần mềm lại chậm hơn và phức tạp hơn
Phần mềm ngày nay thường bị ép đưa tới tay người tiêu dùng, đồng thời bị chỉ trích là đóng vai trò con ngựa thành Troy để thu thập dữ liệu và giám sát
Người tiêu dùng sẵn sàng trả tiền cho thực phẩm, nước và chỗ ở, nhưng lại không muốn trả tiền cho phần mềm
Nếu quy mô đầu tư và đội ngũ hợp lý hơn, thì một GUI cho curl đơn thuần đã không cần thu mức phí ngang Adobe
Đồng thời chỉ ra rằng SaaS cũng không hề mang lại nhiều phần thưởng hơn cho các cộng tác viên mã nguồn mở
Công ty đã chuyển qua nhiều client khác nhau, và Postman cuối cùng cũng đang đi đúng con đường đó
Mong những bài viết giật gân kiểu "AWS sập rồi" biến mất để quay lại với thảo luận bình thường
Hồi trước chỉ với máy chủ on-premise cũng có thể vận hành rất ổn, thậm chí còn hiệu quả hơn bây giờ
Giờ đây lập trình viên cũng phải hiểu AWS, lại còn phải lo rủi ro bảo mật và việc rò rỉ tri thức qua LLM
Có cảm giác tiến bộ công nghệ ngược lại đã tạo ra một môi trường phát triển mang màu sắc phản địa đàng, khiến người ta nhớ về UX đơn giản và trực quan
Cho rằng với đa số doanh nghiệp, việc dùng các dịch vụ "SaaS đủ tốt" cho email, lịch, VPN, CRM... là lựa chọn hợp lý
Các công cụ như Google Workspace, HubSpot hay Power BI được cảm nhận là tốt hơn rất nhiều so với sản phẩm offline trước đây
Dù hiểu rằng rất khó nhồi nhiều thông tin vào màn hình nhỏ, nhưng vẫn thấy khá gượng gạo
Chỉ trích cấu trúc bán tính năng bảo mật theo từng tầng như bắt làm con tin của SaaS
Việc bị phishing là vấn đề của công ty chứ không phải trách nhiệm của nhà cung cấp
Nêu ra vấn đề "sao chép lậu (piracy)" vốn không thể thiếu trong các cuộc thảo luận về SaaS
Việc không cần cài đặt đã khiến quá trình áp dụng trở nên dễ dàng hơn
Đồng thời nói thêm rằng việc đánh cắp tài sản trí tuệ rất phổ biến, nhưng dữ liệu rốt cuộc vẫn có bản tính muốn được tự do
Giải thích rằng bản thân SaaS không phải là khái niệm xấu, và dưới góc nhìn chỉ trả tiền đúng theo mức cần dùng thì đó là mô hình hợp lý
Vấn đề là mô hình thuê bao đã bị đẩy đi quá xa, và vì vendor lock-in nên việc di chuyển dữ liệu trở nên bất khả thi
Giống như chiến lược "moat" của AWS, người dùng bị mắc kẹt vì chính những phụ thuộc do họ tự tạo ra
Vì vậy có lời khuyên rằng không nên phụ thuộc vào SaaS cho các chức năng cốt lõi
Chỉ ra rằng việc chỉ nhấn mạnh mặt tiêu cực của SaaS là thiếu cân bằng
B2B SaaS có thể mang lại lợi ích lớn cho khách hàng miễn là cạnh tranh vẫn được duy trì
Nhà cung cấp có động lực liên tục cải tiến sản phẩm và cung cấp tính năng mới miễn phí để ngăn churn
Trong khi đó, phần mềm on-premise đời cũ được nhớ lại là có hợp đồng bảo trì đắt đỏ và chất lượng thấp
Cuối cùng, người mua vẫn phải chọn điểm thỏa hiệp
Nói rằng các sản phẩm như Photoshop hay AutoCAD sẽ hữu ích cho freelancer hơn nếu có tùy chọn thuê bao ngắn hạn
Nhưng trên thực tế, việc bật tắt thuê bao một cách tự do là rất khó
Nhấn mạnh rằng chỉ cần mua một lần là đủ
Phân tích rằng lock-in cốt lõi của SaaS đến từ sự kết hợp của hai yếu tố
Cho rằng cần tách rời (unbundle) hai yếu tố này, và giải thích rằng yếu tố thứ nhất có thể đã có Nix giải quyết được
Nhiệm vụ còn lại là tạo ra mô hình kinh doanh hỗ trợ dựa trên self-hosting
Tin rằng điều này có thể giải quyết được về mặt kỹ thuật, chỉ là tới nay vẫn chưa được hiện thực hóa