Dự án chuyển đổi số thất bại vì đâu? 4 bước dựng cầu nối

Dự án chuyển đổi số thất bại hiếm khi chết ở buổi ký hợp đồng. Nó chết ở buổi test thật, khi danh sách yêu cầu điều chỉnh bắt đầu đổ về và hai bên từng làm việc rất vui vẻ bắt đầu nhìn nhau như đối thủ. Nhưng tôi đã ngồi giữa đủ nhiều dự án như vậy để thấy một điều: không bên nào sai cả.

Câu trả lời ngắn cho câu hỏi vì sao: phần lớn dự án không hỏng vì đơn vị tư vấn yếu kỹ thuật, cũng không vì chủ doanh nghiệp thiếu tư duy hệ thống. Nó hỏng ở khoảng hở giữa yêu cầu kinh doanh và yêu cầu kỹ thuật. Không ai làm rõ yêu cầu đủ sâu trước khi code, nên mọi thay đổi dồn về giai đoạn đắt nhất.

Bài này mổ khoảng hở đó ra, rồi đưa 4 bước để lấp nó trước khi đội phát triển viết dòng code đầu tiên.

Hai thói quen đều đúng, đặt cạnh nhau thì va

Phần lớn doanh nghiệp SME Việt lớn lên mà không có hệ thống. Chủ doanh nghiệp điều hành bằng trực giác và kỹ năng, không có quy trình, không có job description rõ ràng. Mọi người phản ứng theo tình huống đang diễn ra.

Làm như vậy lâu năm, nó thành thói quen. Thói quen đó tên là linh hoạt: điều chỉnh khi cần, đổi hướng giữa chừng, chốt lại trong một buổi họp. Và phải nói thẳng, họ đã thắng nhờ nó. Linh hoạt để ứng phó khi thị trường đổi, linh hoạt để giành một deal khó, linh hoạt để thúc cả team đạt mục tiêu trong thời gian ngắn.

Đây không phải khuyết điểm. Đây là lý do doanh nghiệp còn sống tới hôm nay.

Rồi doanh nghiệp lớn lên. Việc không còn nằm gọn trong đầu vài người, và chủ doanh nghiệp bắt đầu thấy mình cần một hệ thống. Suy nghĩ phổ biến lúc này là: muốn có hệ thống thì đi làm chuyển đổi số.

Nhưng số hóa một quy trình nghĩa là viết ra một công thức mà 100, 200 người cùng dùng đều phải ra đúng một kết quả. Công thức đó cần ổn định, chính xác và đồng dạng. Đó là ba thuộc tính gần như ngược với sự linh hoạt.

	Bên vận hành (chủ doanh nghiệp)	Bên phát triển (đơn vị tư vấn)
Thói quen đã giúp họ thắng	Linh hoạt, điều chỉnh khi cần	Ổn định, chính xác, đồng dạng
Một lần "điều chỉnh" là	Sửa file Excel, một buổi họp, sửa slide	Sửa nhiều đoạn code liên kết, cấu trúc dữ liệu, hạ tầng
Cái giá của một lần sửa	Vài giờ, gần như bằng không	Tác động dây chuyền, phải kiểm tra lại cả chuỗi
Thứ họ phải cam kết	Kết quả kinh doanh tuần này	Sản phẩm đầu cuối chạy đúng cho mọi người dùng

Hai cột đều đúng. Vấn đề là không ai đặt hai cột này cạnh nhau ngay từ đầu dự án.

Vì sao dự án chuyển đổi số thất bại ở đúng buổi test thật?

Giai đoạn đầu, đơn vị tư vấn nào cũng muốn làm hài lòng khách hàng. Buổi làm rõ yêu cầu diễn ra trong không khí dễ chịu: chủ doanh nghiệp mô tả, bên tư vấn gật đầu, ai cũng thấy mình hiểu nhau.

Chính sự dễ chịu đó để lọt ba thứ:

• Vấn đề chưa được soi ở cấp độ chi tiết.
• Vấn đề chưa được soi từ nhiều khía cạnh, nhiều vai người dùng.
• Những tình huống có thể xảy ra, nhất là tình huống ngoại lệ, chưa ai hỏi tới.

Cho đến khi triển khai và test thật. Lúc này yêu cầu bắt đầu xuất hiện: chỉnh chỗ này, đổi chỗ kia, thêm một bước duyệt, bỏ một trường nhập. Với bên vận hành, chuyện đó rất bình thường, vì cả đời họ đã quen điều chỉnh. Với bên phát triển, mỗi yêu cầu là một quân domino. Họ không thể sửa một chỗ mà không chắc chắn nó không ảnh hưởng tới những chỗ khác, vì thứ họ cam kết là sản phẩm đầu cuối.

Đến đây hòa khí vỡ. Bên doanh nghiệp thấy đội dev chậm và khó tính. Đội dev thấy khách đổi ý liên tục. Và vòng này lặp đi lặp lại, vì nó sinh ra từ hai bản chất công việc khác nhau, không phải từ một người làm sai.

Số liệu nói cùng một điều. Báo cáo Pulse of the Profession của PMI năm 2014 ghi nhận 47% dự án không thành công không đạt mục tiêu vì quản lý yêu cầu thiếu chính xác. Ở tầm rộng hơn, BCG khảo sát 825 lãnh đạo năm 2020 và kết luận 70% chương trình chuyển đổi số không đạt mục tiêu đặt ra.

Còn cái giá của việc phát hiện muộn thì NASA đã đo. Nghiên cứu Error Cost Escalation Through the Project Life Cycle năm 2004 cho thấy một lỗi yêu cầu tốn 1 đơn vị để sửa ở giai đoạn làm rõ yêu cầu sẽ tốn 3 đến 8 đơn vị ở giai đoạn thiết kế, 21 đến 78 đơn vị ở giai đoạn tích hợp và kiểm thử, và từ 29 đến hơn 1.500 đơn vị khi hệ thống đã vận hành.

Con số đó đo trên dự án hàng không vũ trụ, nên đừng lấy nguyên hệ số áp cho phần mềm bán hàng của bạn. Nhưng hình dạng đường cong thì giống nhau. Mỗi câu hỏi "trường hợp này thì sao" bị bỏ qua ở tuần đầu sẽ quay lại ở buổi test, kèm hóa đơn đắt hơn nhiều lần.

Lỗi của tư vấn hay lỗi của chủ doanh nghiệp?

Khi một dự án phải đập đi làm lại, câu hỏi đầu tiên thường là tìm người chịu trách nhiệm. Đơn vị tư vấn làm không tốt, thiếu chuyên môn kỹ thuật? Hay chủ doanh nghiệp thiếu định hướng, thiếu phương pháp, thiếu tư duy hệ thống?

Không phải cả hai. Thứ đang thiếu là một cầu nối ở giữa.

Cầu nối đó làm một việc: làm rõ yêu cầu kinh doanh trước. Từ yêu cầu kinh doanh mới dựng ra yêu cầu kỹ thuật. Và chỉ khi có yêu cầu kỹ thuật, đơn vị tư vấn mới bắt đầu thực thi.

Tầng	Câu hỏi phải trả lời	Ai giữ quyền chốt
Yêu cầu kinh doanh	Vì sao làm, cho ai, đổi con số nào	Chủ doanh nghiệp
Yêu cầu kỹ thuật	Dữ liệu nào, luật nào, màn hình nào, ngoại lệ nào	Người đứng giữa cầu cùng trưởng kỹ thuật
Thực thi	Code, hạ tầng, kiểm thử	Đơn vị phát triển

Có một việc còn khó hơn nằm ngay trong tầng đầu tiên. Trong lúc làm rõ yêu cầu, nhiều khi phải cùng chủ doanh nghiệp dựng lại hệ thống vận hành trước, rồi mới số hóa. Tự động hóa không sửa quy trình sai. Nó chỉ làm quy trình sai chạy nhanh hơn.

Tôi đã viết kỹ về trình tự này trong bài hệ thống hóa doanh nghiệp bằng AI: cách vận hành đi trước, công cụ đi sau.

4 bước dựng cầu nối trước dòng code đầu tiên

Bốn bước dưới đây không thay được năng lực của người làm cầu nối. Nhưng nó cho bạn một thứ tự để không bỏ sót.

Bước 1: Chốt mục tiêu kinh doanh bằng con số, có người đứng tên

"Số hóa quy trình báo giá" không phải mục tiêu. "Rút thời gian báo giá từ hai ngày xuống bốn giờ" mới là mục tiêu. Mỗi mục tiêu cần một người đứng tên chốt nó, thường là chủ doanh nghiệp.

Thiếu con số thì không ai biết tính năng nào đáng làm trước. Thiếu người đứng tên thì yêu cầu nào cũng quan trọng như nhau.

Bước 2: Vẽ người dùng thật và soi tình huống ngoại lệ

Viết ra từng vai sẽ dùng hệ thống: họ nói gì, nghĩ gì, làm gì, lo gì. Rồi hỏi thẳng những câu mà buổi test sẽ hỏi hộ bạn: đơn bị hủy giữa chừng thì sao, khách đổi địa chỉ sau khi xuất kho thì sao, người duyệt vắng mặt ba ngày thì sao.

Tình huống ngoại lệ chính là chỗ sự linh hoạt cũ đang ẩn nấp. Trước đây một người giỏi xử lý nó bằng kinh nghiệm. Giờ hệ thống phải có luật cho nó, hoặc ghi rõ là để người xử lý.

Bước 3: Nối mỗi tính năng về một nhu cầu và một con số

Mỗi tính năng trong danh sách phải trả lời được hai câu: nó phục vụ nhu cầu của ai, và nó đẩy con số nào. Tính năng không nối được là scope creep. Gạch nó đi, hoặc để sang đợt sau.

Bước này cũng là cách viết một brief mà đội phát triển làm đúng ngay lần đầu. Tôi có một bài riêng về brief yêu cầu cho doanh nghiệp nếu bạn muốn đi sâu.

Bước 4: Viết luật cho thay đổi trước khi thay đổi đến

Thay đổi luôn có, và nó nên có. Cái cần thống nhất từ đầu là luật chơi. Mỗi yêu cầu đổi phải trả lời được bốn câu:

• Nó chạm vào những phần nào của hệ thống?
• Ai phải duyệt lại?
• Tốn thêm bao nhiêu thời gian và tiền?
• Nó vào đợt triển khai nào?

Có luật đó, chủ doanh nghiệp vẫn giữ được sự linh hoạt. Chỉ khác là mỗi lần linh hoạt đều hiện ra cái giá của nó, trước khi đội dev bắt tay sửa. Bài số hóa quy trình doanh nghiệp có phần bàn cách chuẩn bị ngân sách cho những vòng hiệu chỉnh này.

Người đứng giữa cầu phải cầm được cả hai phía

Bốn bước trên nghe đơn giản. Cái khó nằm ở người làm.

Người đứng giữa cầu phải ngồi được với chủ doanh nghiệp để nói chuyện biên lợi nhuận, dòng tiền, khách hàng khó tính. Rồi quay sang ngồi được với đội dev để nói chuyện cấu trúc dữ liệu, quyền truy cập, ngoại lệ. Không phải một BA chỉ viết tài liệu, cũng không phải một PM chỉ chạy tiến độ.

Coach lo People và Process. Dev lo Tool. Rất ít người cầm được cả phép nhân.

Và việc này phải làm sớm, trước khi ký phạm vi, bởi người có đủ năng lực và kinh nghiệm của cả bên kinh doanh lẫn bên hệ thống, công nghệ. Khi đó bước set up và planning ban đầu mới thật sự vững. Vấn đề phát sinh vẫn sẽ có, nhưng dự án chạy có nhịp hơn.

Một điều nữa cần giữ: quyền chốt yêu cầu kinh doanh ở lại với chủ doanh nghiệp. Người đứng giữa cầu giúp bạn diễn đạt, soi và nối. Họ không quyết thay bạn.

Product Master: cây cầu được viết thành phần mềm

Sau đủ nhiều dự án thấy cùng một khoảng hở, tôi dựng Product Master để giữ cây cầu đó khỏi sập giữa chừng. Việc khó nhất của một sản phẩm số không phải viết code. Việc khó nhất là trả lời được: khách hàng nào cần, cần điều gì, việc đó mang lại con số nào, và ai đã đồng ý.

Product Master làm bốn việc chính.

Nối từ mục tiêu xuống từng việc làm. Mỗi sản phẩm có một chuỗi truy vết: trụ tầm nhìn, KPI kinh doanh, KPI của sản phẩm, tính năng, user story, tiêu chí nghiệm thu, sprint, và cả lỗi. Song song là chuỗi phía khách hàng: chân dung người dùng, empathy map, nhu cầu, rồi tới tính năng giải nhu cầu đó. Mỗi tính năng bạn bỏ tiền ra làm đều truy ngược được về một mục tiêu kinh doanh.

Chỉ ra chỗ hở trước khi đội dev chạm vào. Hệ thống tự rà và đánh dấu đỏ, vàng: tính năng không đẩy KPI nào, nhu cầu chưa có tính năng nào phủ, KPI kinh doanh chưa có gì đỡ, story chưa có tiêu chí nghiệm thu. Đây chính là bước 2 và bước 3 ở trên, được máy nhắc thay vì trông vào trí nhớ.

Làm cho mỗi lần thay đổi hiện ra. Khi ai đó sửa một nhu cầu đã duyệt, nhu cầu đó chuyển về trạng thái cần duyệt lại. Tính năng phía trên bị đánh dấu vàng và không duyệt lại được cho tới khi nhu cầu được chốt xong. Mọi lần sửa đều lưu lịch sử: ai sửa, lúc nào, giá trị cũ, giá trị mới. Thay đổi vẫn diễn ra, nhưng không còn thay đổi nào lặng lẽ.

AI soạn nháp, người quyết. Claude kết nối qua MCP để soạn chân dung khách hàng, nhu cầu, tính năng, user story. Nhưng mọi thứ Claude tạo ra đều ở trạng thái nháp, và chỉ người giữ đúng vai mới duyệt được trên web.

Sáu vai phân quyền rõ: người bảo trợ chốt mục tiêu kinh doanh, chủ sản phẩm chốt khách hàng và tính năng, quản lý dự án xếp việc, trưởng kỹ thuật chốt công nghệ, lập trình viên cập nhật tiến độ, người kiểm thử báo lỗi và tick nghiệm thu. Từ những gì đã duyệt, hệ thống xuất ra PRD và tài liệu kỹ thuật.

Hai điểm thực tế cần biết. Product Master cài trên máy chủ riêng của bạn, nên dữ liệu sản phẩm nằm trong hạ tầng công ty. Và AI chạy bằng gói Claude của chính bạn, loại gói hỗ trợ kết nối connector, nên bạn không trả thêm phí AI nào cho Product Master.

Nói thẳng giới hạn của nó: công cụ giữ cầu, nó không xây cầu thay bạn. Nếu chưa ai ngồi với chủ doanh nghiệp để nói ra mục tiêu bằng con số, màn hình Product Master sẽ đỏ gần hết. Đó là đúng việc của nó: chỉ ra chỗ hở ở tuần đầu, lúc sửa còn rẻ.

Thay đổi không phải kẻ thù

Sự thay đổi sẽ luôn có, trong mọi dự án số hóa. Chủ doanh nghiệp không nên bỏ sự linh hoạt đã giúp mình thắng, và đội phát triển cũng không nên bỏ sự chặt chẽ đã giúp sản phẩm chạy đúng.

Bài học không phải là cấm khách đổi ý. Bài học là làm cho mỗi lần đổi ý hiện ra trước mắt cả hai bên, kèm cái giá của nó, trước khi nó thành một quân domino. Dự án không đổ vì thiếu thiện chí. Nó đổ vì thiếu một cây cầu.

Nếu bạn đang chuẩn bị một dự án số hóa, hoặc đang kẹt trong vòng sửa đi sửa lại với đội phát triển, hãy xem cách Product Master nối mục tiêu kinh doanh xuống từng tính năng. Muốn dựng thử chuỗi đó cho đúng dự án của bạn, đặt lịch 30 phút với tôi, mình mở màn hình làm luôn trong buổi.