Có một tình huống lặp lại đủ nhiều để đáng gọi tên. Một công ty chi ngân sách lớn cho hệ thống mới, dự án chạy đủ mười tám tháng, phần mềm được bàn giao đúng đặc tả. Sáu tháng sau, nhân viên vẫn xuất dữ liệu ra Excel để làm nốt phần việc thật.
Không ai làm sai. Lập trình viên xây đúng thứ được yêu cầu. Người viết đặc tả mô tả đúng quy trình trong quy định. Vấn đề nằm ở chỗ quy trình trong quy định không phải quy trình đang chạy.
Khoảng cách giữa quy trình viết ra và quy trình chạy thật
Hãy lấy một ví dụ cụ thể: duyệt đề nghị mua hàng.
Quy định ghi ba bước. Người đề nghị điền phiếu, trưởng bộ phận duyệt, phòng mua hàng thực hiện. Rõ ràng, gọn gàng, và là thứ được đưa cho đội phát triển.
Thực tế thì khác. Người đề nghị gọi điện hỏi phòng mua hàng xem món đó còn hàng không trước khi điền phiếu, vì điền xong mới biết hết hàng thì mất một tuần. Trưởng bộ phận duyệt nhưng nhắn riêng cho kế toán xem còn ngân sách không. Kế toán trả lời bằng tin nhắn. Nếu vượt một mức tiền nào đó thì có thêm một chữ ký nữa mà quy định không ghi, vì mức đó được thống nhất trong một cuộc họp hai năm trước.
Bảy bước thật, ba bước trên giấy. Số hoá ba bước trên giấy thì bốn bước còn lại vẫn chạy bằng điện thoại và tin nhắn — và giờ chúng chạy song song với một hệ thống mới mà không ai cập nhật.
Đây là lý do dự án hỏng, và nó không phải vấn đề kỹ thuật.
Dấu hiệu thứ nhất: không ai ngồi cạnh người đang làm việc đó
Giai đoạn phân tích thường diễn ra trong phòng họp, với trưởng phòng và giám đốc. Đó là những người mô tả quy trình như nó nên chạy — họ biết quy định, và họ ở xa thao tác hàng ngày.
Người biết quy trình thật là người ngồi làm nó tám tiếng mỗi ngày. Họ biết chỗ nào tắc, biết phải gọi ai để đẩy nhanh, và họ đã tự nghĩ ra cách lách từ lâu.
Những cách lách đó là dữ liệu quý nhất trong cả giai đoạn phân tích. Mỗi cách lách chỉ ra một chỗ mà thiết kế chính thức không khớp với công việc thật. Một người dùng tự tạo file Excel song song để theo dõi đơn hàng đang chờ — nghĩa là hệ thống chính không cho họ thấy thứ họ cần thấy. Đó là một yêu cầu, chỉ là nó chưa bao giờ được viết ra dưới dạng yêu cầu.
Kiểm tra: trong biên bản phân tích, có bao nhiêu buổi ngồi cùng người trực tiếp làm việc, và bao nhiêu buổi chỉ có quản lý? Nếu tỉ lệ nghiêng hẳn về phía thứ hai, đặc tả đang mô tả một công ty không tồn tại.
Dấu hiệu thứ hai: kế hoạch có một ngày go-live duy nhất ở rất xa
Một kế hoạch ba năm với một lần chuyển đổi ở cuối là kế hoạch đặt cược toàn bộ vào việc các giả định ban đầu vẫn đúng sau ba năm.
Chúng sẽ không đúng. Thị trường đổi. Người viết đặc tả nghỉ việc. Đối thủ ra sản phẩm mới làm thay đổi thứ tự ưu tiên. Và quan trọng nhất: không ai biết mình sai ở đâu cho tới khi có người thật dùng thứ mình xây.
Cách ít rủi ro hơn là chia thành các giai đoạn mà mỗi giai đoạn tự nó đã có giá trị, kể cả khi giai đoạn sau không bao giờ được làm. Ràng buộc này nghe có vẻ khắt khe nhưng nó có tác dụng phụ rất tốt: nó buộc phải xếp thứ tự ưu tiên thật. Khi mọi giai đoạn đều phải tự đứng được, không thể để dồn phần khó xuống cuối.
Nó cũng có ích trong nội bộ. Một dự án cho thấy kết quả sau bốn tháng sẽ được bảo vệ khi ngân sách bị soát lại. Một dự án hứa kết quả sau ba năm thì không — nó chỉ là một dòng chi phí chưa mang lại gì.
Dấu hiệu thứ ba: chưa ai trả lời được ba câu hỏi về dữ liệu
Ba câu này nghe đơn giản tới mức dễ bị bỏ qua, và bỏ qua chúng thì hậu quả xuất hiện sau vài năm, khi đã quá muộn để sửa rẻ.
Dữ liệu gốc nằm ở đâu? Với mỗi loại dữ liệu — khách hàng, đơn hàng, tồn kho — phải có đúng một hệ thống được coi là nguồn sự thật. Không phải hai.
Ai được sửa? Nếu ba hệ thống cùng ghi được vào dữ liệu khách hàng thì sớm muộn chúng sẽ ghi đè lẫn nhau.
Khi hai hệ thống bất đồng thì tin cái nào? Câu này sẽ xảy ra. Trả lời trước thì có quy tắc; trả lời sau thì có một cuộc họp giữa hai phòng ban, mỗi bên cầm một con số khác nhau.
Không trả lời rõ ba câu này, sau vài năm công ty sẽ ở trong tình trạng quen thuộc: mỗi phòng báo cáo một con số doanh thu khác nhau, và không ai chứng minh được ai đúng.
Vậy nên làm gì
Bắt đầu bằng việc vẽ lại quy trình đang chạy, đúng như nó chạy, có mặt người trực tiếp làm.
Tìm những chỗ lách. Với mỗi chỗ lách, hỏi vì sao nó tồn tại. Phần lớn sẽ chỉ ra một bước thừa cần bỏ, hoặc một thông tin cần hiện ra sớm hơn.
Bỏ bước thừa trước khi số hoá. Đây là phần khó nhất vì nó động tới người và quyền, không phải động tới phần mềm — nhưng nó cũng là phần tạo ra phần lớn giá trị. Số hoá một quy trình bảy bước trong đó bốn bước vô nghĩa thì kết quả là bốn bước vô nghĩa chạy nhanh hơn.
Rồi mới chọn công nghệ. Đến lúc đó, câu hỏi công nghệ thường đã trở nên dễ, vì bài toán đã rõ.
Nice Solutions tư vấn chuyển đổi số cho doanh nghiệp vừa và lớn, đã làm việc với Gree Việt Nam, diaB và Galaxy Holdings. Nếu bạn đang ở giai đoạn đầu của một dự án như thế này và muốn trao đổi, liên hệ với chúng tôi.