Một công ty gọi cho tôi sau khi đã chi gần một tỷ đồng cho một hệ thống quản lý kho. Hệ thống đang chạy. Đội kho không dùng. Họ vẫn dùng bảng tính Excel từ năm năm trước, song song với hệ thống mới — “để chắc ăn.”
Tôi hỏi người quản lý kho: “Anh có tham gia vào quá trình chọn hệ thống không?”
Ông nhìn tôi như tôi hỏi một câu ngớ ngẩn: “Có ai hỏi chúng tôi đâu.”
Cái mẫu hình tôi thấy lặp lại
Tôi không đếm được mình đã ngồi trong bao nhiêu cuộc họp kiểu này. Công ty khác nhau, ngành khác nhau, quy mô khác nhau. Nhưng câu chuyện gần như lúc nào cũng có cùng một bộ khung.
Ban lãnh đạo nhìn thấy vấn đề thật — quy trình chậm, dữ liệu phân tán, báo cáo mất nhiều ngày. Họ quyết định cần một hệ thống mới. Họ tìm nhà cung cấp, xem demo, chọn sản phẩm, ký hợp đồng. Dự án triển khai kéo dài, vượt timeline, vượt ngân sách. Cuối cùng hệ thống ra đời — và người dùng thực sự không dùng nó, hoặc dùng sai cách, hoặc dùng bên cạnh hàng loạt workaround tự chế.
Công thức đó lặp lại đủ nhiều lần để tôi nghi ngờ rằng đây không phải lỗi của nhà cung cấp, không phải lỗi của công nghệ, không phải lỗi của ngân sách. Đây là lỗi của một câu hỏi không được hỏi đúng lúc.
Câu hỏi không được hỏi
Câu hỏi đó là: người thực sự làm việc này mỗi ngày — họ đang làm gì, và tại sao họ làm vậy?
Nghe thì hiển nhiên. Nhưng trong thực tế, phần lớn quyết định mua phần mềm được đưa ra từ tầng quản lý — những người nhìn thấy vấn đề qua báo cáo, qua con số, qua cuộc họp. Họ không thấy cái anh nhân viên kho làm gì lúc 7 giờ sáng khi xe hàng đến sớm hơn dự kiến và hệ thống chưa mở ca. Họ không thấy cái bà kế toán tạo ra một file Excel riêng vì trường ngày tháng trong phần mềm không cho nhập theo định dạng của khách hàng Nhật.
Những workaround đó không phải dấu hiệu của nhân viên “không chịu thay đổi.” Chúng là bằng chứng của hệ thống không khớp với thực tế.
Phần mềm được thiết kế từ trên xuống luôn giải quyết vấn đề của người không dùng nó, bằng cách tạo ra vấn đề mới cho người dùng nó.
Cái tôi học được từ những dự án hiếm hoi đi đúng
Tôi đã thấy đủ thất bại để tò mò về những trường hợp ngược lại. Không nhiều — nhưng đủ để thấy điểm chung.
Những dự án triển khai tốt không bắt đầu bằng việc chọn phần mềm. Chúng bắt đầu bằng việc quan sát. Người ra quyết định ngồi cạnh người làm việc. Không phải phỏng vấn trong phòng họp. Ngồi cạnh. Xem. Hỏi “tại sao” không phải một lần mà năm lần, theo kiểu Năm Tại Sao. Và quan trọng hơn — lắng nghe câu trả lời thứ năm, vì đó mới là câu trả lời thật.
Họ cũng làm một điều mà hầu hết dự án bỏ qua: dành thời gian phân biệt giữa vấn đề thật và triệu chứng của vấn đề thật.
Ví dụ: “báo cáo chậm” thường không phải vấn đề thật. Nó là triệu chứng. Vấn đề thật có thể là dữ liệu nằm ở ba chỗ khác nhau và không ai chịu trách nhiệm đồng bộ. Hoặc vấn đề thật là hai phòng ban dùng định nghĩa khác nhau cho cùng một chỉ số. Mua phần mềm để giải quyết “báo cáo chậm” mà không giải quyết vấn đề thật — là mua thuốc hạ sốt cho người bị viêm phổi.
Điều khó nhất không phải là kỹ thuật
Tôi đã học được điều này muộn hơn tôi muốn thừa nhận: phần khó nhất của bất kỳ dự án phần mềm nào không phải là kỹ thuật. Kỹ thuật có thể học, có thể thuê, có thể giải quyết bằng tiền và thời gian.
Phần khó nhất là sự thành thật nội bộ — khả năng một tổ chức nhìn thẳng vào cách họ thực sự vận hành, không phải cách họ nghĩ họ vận hành, và nói thật về khoảng cách đó.
Khoảng cách đó tồn tại ở mọi tổ chức. Không có ngoại lệ. Câu hỏi không phải là “chúng ta có khoảng cách không” mà là “chúng ta có sẵn sàng nhìn vào nó không.”
Phần mềm tốt nhất, được cài vào tổ chức không sẵn sàng nhìn thật, sẽ chỉ làm tốt hơn việc che giấu khoảng cách đó. Và đó là một thứ đắt hơn nhiều so với chi phí dự án.
Trở lại câu chuyện đầu
Công ty đó cuối cùng không bỏ hệ thống mới. Nhưng họ mất thêm sáu tháng ngồi lại với đội kho — thật sự ngồi lại, không phải qua form khảo sát — để hiểu họ đang cần gì. Hệ thống sau đó được cấu hình lại một phần, quy trình được thiết kế lại một phần, và quan trọng hơn: đội kho được hỏi ý kiến trước khi bất kỳ thay đổi nào được áp xuống.
Bây giờ họ dùng hệ thống. Vẫn còn một số chỗ không hoàn hảo. Nhưng không còn file Excel song song.
Câu hỏi tôi muốn để lại: trong quy trình vận hành của bạn, ai là người biết nhiều nhất về cách công việc thực sự diễn ra mỗi ngày — và lần cuối cùng ai đó ngồi xuống hỏi họ là khi nào?