Trong quá trình làm việc, tôi chứng kiến không ít doanh nghiệp gặp quả đắng khi thuê gia công phần mềm, dự án chết lâm sàng ngay khi vừa bàn giao… ngay cả khi bên gia công bàn giao đúng hạn, đúng tính năng. Trên giấy tờ nghiệm thu, mọi thứ đẹp đẽ: checklist xanh rì, chạy đúng tài liệu và khớp bản vẽ Figma. Bên thuê hân hoan cắt băng, bên gia công vui vẻ nhận tiền.
Nhưng bi kịch bắt đầu khi vào vận hành thực tế. Các vấn đề tồn tại ngay từ khi bắt đầu dự án, nay mới dần hiện ra và gây nên các thiệt hại nghiêm trọng cho doanh nghiệp. Hãy cùng bóc tách những nút thắt dẫn đến sự đứt gãy này dưới góc nhìn tâm lý và kinh tế học.
Thời thuộc địa Anh ở Ấn Độ, chính quyền đang đau đầu vì rắn hổ mang. Số người bị cắn tăng lên mỗi năm. Rắn xuất hiện khắp nơi, trong nhà, ngoài đường, trong chợ. Ai đó trong bộ máy chính quyền nghĩ ra một giải pháp trông có vẻ hoàn toàn logic: trả tiền thưởng cho mỗi con rắn hổ mang bị giết. Nộp xác rắn, nhận tiền. Đơn giản, hiệu quả, có KPI’s rõ ràng.
Ban đầu đúng là hiệu quả thật. Người dân đổ xô đi săn rắn. Số xác rắn nộp lên tăng vọt. Quan chức báo cáo tiến độ tốt. Mọi thứ trông đang đi đúng hướng.
Nếu là bác sống trong hoàn cảnh đó, bác sẽ bắt đầu nghĩ: tại sao phải đi bắt rắn ngoài tự nhiên, vừa mất công, vừa nguy hiểm; khi có thể nuôi rắn tại nhà chả phải ngon hơn không? Họ bắt đầu lập trại nuôi rắn hổ mang. Hàng chục con. Hàng trăm con. Rồi hàng nghìn con. Nuôi rắn, chờ rắn đẻ thêm, giết rắn, nộp xác, nhận tiền, một vòng lặp hoàn hảo. Số xác rắn nộp lên ngày càng tăng. Quan chức bắt đầu cảm thấy chính sách đưa ra là đúng đắn và rất hài lòng.
Đến khi chính quyền phát hiện ra trò này, họ lập tức hủy chương trình. Và đó là lúc mọi thứ thực sự vỡ ra. Hàng nghìn con rắn hổ mang đang được nuôi trong các trại, giờ trở thành vô giá trị. Những người nuôi rắn bắt đầu thả tất cả ra ngoài. Số rắn hổ mang ngoài đường tăng cao hơn cả trước đó. Giải pháp đã tạo ra chính xác vấn đề mà nó được thiết kế để giải quyết.
Bản chất của Hiệu ứng Cobra trong quản trị doanh nghiệp
Kinh tế học gọi đây là Cobra Effect, thuật ngữ do nhà kinh tế học người Đức Horst Siebert đặt ra để mô tả một hiện tượng đã được quan sát qua các sự kiện trong lịch sử: khi một hệ thống được thiết kế để đo và thưởng cho một thứ, người trong hệ thống sẽ tối ưu cho thứ được đo, không phải mục tiêu thực sự đằng sau nó. Không phải vì người dân khôn lỏi. Mà vì đó là hành vi tâm lý học của con người, luôn tìm cách tối ưu để đạt được mục tiêu một cách nhanh và hiệu quả nhất. Chính quyền thực dân Anh thì muốn triệt tiêu bớt rắn, nhưng người dân lại muốn kiếm tiền. Hai mục tiêu khác nhau nên cái tối ưu là khác nhau, nhiều khi còn xung đột với nhau.
Nếu bác đang thấy câu chuyện này nghe quen quen, thì đúng rồi. Nó đang xảy ra trong mọi lúc, mọi nơi trong cuộc sống và công việc. Ngành phần mềm, chuyển đổi số cũng không ngoại lệ. Chỉ là không có rắn, không có trại nuôi, và không ai gọi đặt tên nó.
Case study Lidl: Bốc hơi €500 triệu euro vì giữ quy trình cũ
Năm 2011, Lidl, chuỗi siêu thị giảm giá lớn nhất châu Âu với hơn 10,000 cửa hàng tại 30 quốc gia, quyết định làm điều mà họ gọi là sự chuyển đổi lớn nhất trong lịch sử công ty, với mục tiêu replace hệ thống quản lý kho nội bộ cũ bằng SAP để chuẩn hóa toàn bộ vận hành trên hơn 140 trung tâm logistics và hàng nghìn cửa hàng toàn cầu. Ngân sách ban đầu là €201 triệu và timeline là vài năm, nghe có vẻ hoàn toàn khả thi với quy mô của một tập đoàn như Lidl.
Năm 2015, họ go-live thí điểm tại Áo và có vẻ ổn nên tiếp tục, nhưng có một vấn đề không ai nhìn thấy hoặc không ai dám nói thẳng ngay từ ngày đầu tiên: Lidl từ trước đến nay luôn quản lý tồn kho dựa trên giá mua vào trong khi SAP được thiết kế để quản lý theo giá bán ra. Nghe có vẻ nhỏ nhưng đây là logic cốt lõi của toàn bộ hệ thống quản lý hàng hóa, thứ mà mọi nghiệp vụ khác đều xây trên đó, và thay vì thay đổi quy trình của mình để fit với SAP thì Lidl quyết định customize SAP để fit với quy trình cũ của họ.
Từ quyết định đó, mọi thứ bắt đầu chồng chất theo cách không ai kiểm soát được. Càng cố bend SAP theo quy trình cũ thì hệ thống càng trở nên phức tạp và bất ổn, customization chồng chất phá vỡ tính toàn vẹn của platform và technical debt tích lũy đến mức hệ thống gần như không thể scale, ngân sách €201 triệu bị vượt qua từ lâu mà không ai dám nói thật về con số thực, timeline vài năm kéo dài thành bảy năm trong khi nhân viên phải vừa xử lý vấn đề của hệ thống mới vừa duy trì hệ thống cũ và tinh thần xuống thấp dần. Không có sufficient internal oversight, không ai thực sự hiểu toàn bộ hệ thống, không có knowledge transfer thực chất xảy ra trong suốt quá trình đó.
Năm 2018, sau 7 năm và €500 triệu euro, CEO Jesper Hoyer gửi memo cho toàn bộ nhân viên với nội dung: “Các mục tiêu chiến lược như đã định nghĩa ban đầu không thể đạt được mà không phải chi thêm nhiều hơn mức chúng ta mong muốn.” Họ hủy toàn bộ và quay về hệ thống cũ, cái hệ thống nội bộ tự phát triển mà họ đã bỏ ra 7 năm và nửa tỷ euro để thay thế, trong khi CIO của Lidl rời công ty và toàn bộ chiến lược bị đảo ngược hoàn toàn.
Đây không phải câu chuyện về SAP tệ hay Lidl kém mà là Cobra Effect trong phần mềm đang vận hành đúng như cơ chế của nó: mỗi bên trong dự án, Lidl muốn giữ nguyên quy trình cũ, SAP muốn deliver đúng hợp đồng, consultant muốn bill thêm giờ, đều đang làm đúng theo những gì họ được đo và được thưởng, trong khi không ai trong số đó đang hỏi câu hỏi duy nhất thực sự quan trọng: “Sau tất cả những điều này, nhân viên kho có thực sự làm việc được không?”
Tại sao tiêu chuẩn nghiệm thu khiến nhiều dự án phần mềm, chuyển đổi số thất bại?
Bất cứ khi nào con người thiết kế một hệ thống đo lường, người trong hệ thống đó sẽ tối ưu cho chỉ số được đo chứ không phải mục tiêu thực sự đằng sau chỉ số đó. Goodhart’s Law, do nhà kinh tế học người Anh Charles Goodhart phát biểu từ những năm 1970, nói thẳng điều này: “Khi một chỉ số trở thành mục tiêu, nó ngừng là một chỉ số tốt.”
Trong dự án phần mềm, chỉ số đó là tính năng được deliver, deadline được giữ, QA pass. Không ai đo liệu nhân viên có thực sự dùng được không. Không ai đo liệu bài toán kinh doanh có được giải quyết không. Kết quả thì Standish Group đã đo suốt 30 năm trên hơn 50,000 dự án phần mềm toàn cầu: chỉ 29% dự án thực sự thành công, 52% gặp vấn đề nghiêm trọng, 19% thất bại hoàn toàn. Ở Việt Nam con số c
òn tệ hơn, 76% dự án digital transformation thất bại. Không phải vì doanh nghiệp Việt Nam kém hơn. Mà vì Cobra Effect không phân biệt quốc gia, nó chỉ đi theo cấu trúc của vấn đề.
Giải mã cấu trúc đứt gãy trong gia công phần mềm
Mọi dự án phần mềm đều bắt đầu theo một flow quen thuộc. Nhìn vào thì có vẻ rõ ràng và logic, mỗi bước có người chịu trách nhiệm, mỗi bước có deliverable cụ thể.
Vấn đề không nằm ở từng bước riêng lẻ mà nằm ở những gì xảy ra giữa các bước, khi thông tin đi từ người này sang người kia và mỗi lần handoff thì một phần context bị mất đi không thể lấy lại.
Sự lệch pha giữa người ra đề và người thực thi
Khách hàng mô tả bài toán theo ngôn ngữ của mình, BA nghe rồi diễn giải theo cách hiểu của BA, Design nhìn spec rồi hiểu theo góc nhìn của designer, Dev nhìn Figma rồi implement theo logic của dev, và qua mỗi lần chuyển giao như vậy thì một phần context của bài toán gốc bị mất đi mà không ai nhận ra vì không ai trong chuỗi đó có đủ shared context để biết mình đang mất gì.
Lidl có hệ thống SAP đầy đủ tính năng. Nhân viên kho có quy trình vận hành riêng đã tối ưu suốt nhiều năm. Hai thứ đó không bao giờ được đặt lên bàn cùng nhau trong suốt quá trình build, cho đến khi €500 triệu đã tiêu hết.
Khi mỗi mắt xích trong chuỗi tối ưu cho một đích riêng
Đây là Cobra Effect bên trong dự án phần mềm, không ai nuôi rắn có chủ ý nhưng cấu trúc của hệ thống khiến mỗi người tự nhiên tối ưu cho thứ được đo chứ không phải thứ cần đạt, và nhìn vào bảng dưới đây sẽ thấy rõ tại sao dự án có thể thành công theo nghĩa của từng người trong chuỗi mà vẫn thất bại hoàn toàn theo nghĩa của người trả tiền.
Không ai vô trách nhiệm vì họ đang làm đúng theo những gì hợp đồng yêu cầu, vấn đề là hợp đồng không yêu cầu đúng thứ.
Hợp đồng – Nơi “bẫy chỉ số” được hợp pháp hóa
Khi bác ký hợp đồng với công ty dev thì về bản chất bác đang ký một tài liệu mô tả tính năng, timeline và điều kiện nghiệm thu chứ không phải kết quả kinh doanh, và bên triển khai không có nghĩa vụ hợp đồng nào liên quan đến việc nhân viên của bác có dùng được phần mềm không vì họ chỉ cần deliver đúng tính năng đã ký, đúng deadline, pass nghiệm thu rồi hợp đồng kết thúc. Đây chính là lúc Cobra Effect vận hành hoàn hảo vì chỉ số được đo là tính năng và deadline nên bên triển khai tối ưu cho đúng hai thứ đó, dẫn đến kết quả là sản phẩm thành công về mặt hợp đồng nhưng thất bại về mặt thực tế. Standish Group chỉ ra rằng ba yếu tố quyết định thành công của một dự án phần mềm là sự tham gia của người dùng thực tế, sự hỗ trợ trực tiếp từ lãnh đạo và requirement được xác định rõ từ đầu, nhưng cả ba thứ đó đều không được viết vào hợp đồng thông thường.
Nghịch lý: Người nắm nhiều thông tin nhất lại đứng ngoài cuộc
Bác ký hợp đồng xong rồi nghĩ nhiệm vụ của mình đã hoàn thành và còn lại là việc của đội dev vì họ là chuyên gia, nhưng thực ra đội dev hiểu công nghệ mà không hiểu doanh nghiệp của bác, không hiểu quy trình thực tế, không hiểu người dùng cuối của bác là ai và đang gặp vấn đề gì hàng ngày, vì những thứ đó chỉ bác mới biết và người có nhiều thông tin nhất để làm dự án thành công lại là người ít tham gia nhất vào quá trình build. Đó là nghịch lý của gần như mọi dự án phần mềm và cũng chính xác là cách Lidl để €500 triệu euro bốc hơi mà không ai trong đội dev chịu trách nhiệm về kết quả cuối cùng vì về mặt hợp đồng họ đã làm đúng hết mọi thứ.
Bài học xương máu để phòng tránh rủi ro khi thuê Outsourcing
Không phải tìm công ty dev tốt hơn, không phải tăng ngân sách, không phải viết spec dài hơn mà phải thay đổi hai thứ theo đúng thứ tự này.
Thứ nhất là thay đổi cách definition of success phải được viết vào hợp đồng không phải dưới dạng tính năng mà là kết quả đo được, ví dụ như “80% nhân viên dùng hệ thống thành thạo sau 30 ngày go-live” thay vì “hệ thống có đủ các tính năng A, B, C”, và khi chỉ số thay đổi thì hành vi của tất cả mọi người trong chuỗi sẽ thay đổi theo, đó là cách phá vỡ Cobra Effect từ gốc rễ.
Thứ hai là thay đổi ai ngồi vào bàn từ đầu, vì người dùng thực tế phải có mặt trong quá trình build chứ không phải chỉ xuất hiện ở buổi kickoff và ngày nghiệm thu, và feedback loop từ người dùng thực phải là một phần của quy trình chứ không phải bonus nếu còn thời gian.
Chính quyền Anh ở Ấn Độ không thất bại vì thiếu tiền hay thiếu ý chí mà vì đang đo sai thứ và cả hệ thống tối ưu xung quanh cái chỉ số sai đó, Lidl không thất bại vì SAP tệ hay vì họ kém mà vì không ai trong suốt 7 năm dám hỏi thẳng “nhân viên kho có thực sự làm việc được với hệ thống này không”, và 76% dự án digital transformation ở Việt Nam không thất bại vì thiếu công nghệ mà vì Cobra Effect đang vận hành âm thầm trong từng hợp đồng, từng buổi họp, từng lần handoff mà không ai gọi tên nó.
Phần mềm thất bại không phải ở giai đoạn build mà thất bại ở giai đoạn trước khi build, khi không ai hỏi đúng câu hỏi và không ai đo đúng thứ cần đo.
Cảm ơn các bác đã dành thời gian ngồi lại đây để đi hết câu chuyện này cùng tôi. Những gì tôi chia sẻ ở trên hoàn toàn là đúc kết từ trải nghiệm thực tế trong quá trình làm nghề, nhưng mỗi cây mỗi hoa, mỗi doanh nghiệp sẽ lại có một bài toán chuyển đổi số hay thiết kế trải nghiệm rất khác nhau.
Ý kiến hoặc góc nhìn của các bác về vấn đề này thế nào? Đừng ngần ngại để lại một bình luận ngay bên dưới để anh em mình cùng ngồi xuống thảo luận và học hỏi lẫn nhau nhé.
Để lại một bình luận