Rất nhiều dự án phần mềm tùy chỉnh tại các nhà máy không chết vì lập trình, mà chết vì “yêu cầu không rõ ràng, phạm vi liên tục thay đổi, khi triển khai thì chẳng ai công nhận”. Phòng kinh doanh nói cần theo dõi tiến độ từng công đoạn, phân xưởng yêu cầu có thể điều chuyển, phòng kế toán đòi phải khớp với chi phí trên phiếu công việc, còn IT thì bảo danh sách giao diện vẫn chưa được chốt. Ba tháng sau hệ thống đã đi vào vận hành, nhưng tại hiện trường vẫn dùng WeChat để gửi ảnh và báo công bằng Excel. Điều thực sự thiếu không phải là danh sách chức năng, mà là một lộ trình thực thi xuyên suốt từ việc chốt phạm vi, thiết kế giải pháp, triển khai phát triển đến nghiệm thu, tạo thành chu trình khép kín.
Vấn đề nghiệp vụ: Tại sao “đã hoàn thành” rồi mà vẫn không dùng được?
Điểm đau thường gặp trong sản xuất rời rạc là: mở phiếu công việc rồi nhưng không nhìn thấy tiến độ từng công đoạn; tổ trưởng điều chuyển bằng miệng, hệ thống vẫn treo ở bước trước; kiểm tra chất lượng không đạt thì vòng tuần hoàn giấy tờ, còn hạch toán chi phí thì không khớp. Chủ doanh nghiệp mua phần mềm vì muốn nhìn thấy tình trạng WIP (công việc đang thực hiện) thật sự, nhưng nếu bên cung cấp báo giá theo “danh sách mô-đun”, họ sẽ gộp luôn bảng kanban, báo công, tồn kho, chi phí vào cùng một giai đoạn, khiến phạm vi phình to đến mức không thể nghiệm thu.
Một kiểu thất bại khác là coi biên bản phỏng vấn như đặc tả yêu cầu. Biên bản ghi “cần có thể xem tiến độ”, nhưng lại không nêu rõ tiến độ lấy theo phiếu công việc nào, xử lý tái công thế nào, hay ai có quyền điều chuyển giữa các tổ. Nhà phát triển chỉ làm theo nghĩa đen trang danh sách, nên khi đưa vào sử dụng ngay lập tức bị tắc nghẽn. Phần mềm có thể giải quyết những quy tắc này bằng cách biến chúng thành trạng thái máy hữu hiệu và phân quyền; còn nếu không thể giải quyết, thì chính là do trong tổ chức không ai chịu chốt các quy tắc đó. Còn một loại chi phí ẩn nữa là duy trì song song hai hệ thống quá lâu. Bảng Excel cũ vẫn dùng, hệ thống mới thì chưa đầy đủ; tại hiện trường chọn con đường dễ dàng, dữ liệu hệ thống ngày càng bẩn, cuối cùng bị đánh giá là “hệ thống khó dùng”. Có thể duy trì song song, nhưng phải ghi rõ ngày ngừng sử dụng bảng cũ và quy tắc đối chiếu, nếu không thì khi đưa vào vận hành chỉ thêm một bộ hiển thị nữa mà thôi.
Ngoài ra còn một chi phí tiềm ẩn khác: thời gian song hành kéo dài quá lâu. Bảng Excel cũ vẫn tiếp tục, hệ thống mới thì chưa hoàn thiện, tại hiện trường chọn lối đi dễ dàng, dữ liệu hệ thống ngày càng bẩn, cuối cùng bị kết luận là “hệ thống khó dùng”. Song hành thì được, nhưng phải ghi rõ ngày ngừng sử dụng bảng cũ và quy tắc đối chiếu, nếu không thì khi đưa vào vận hành chỉ thêm một bộ hiển thị nữa mà thôi.
- Phạm vi không rõ ràng: mục tiêu giai đoạn một bị trộn lẫn thành “toàn bộ số hóa”.
- Điểm đứt gãy trong thu thập dữ liệu: tiến độ vẫn phụ thuộc vào lời nói, hệ thống chỉ đóng vai trò hiển thị.
- Nghiệm thu sai lệch: kiểm tra theo menu chứ không nghiệm thu dựa trên kết quả nghiệp vụ.
- Song hành mất kiểm soát: bảng cũ vẫn hoạt động, dữ liệu mới không có chủ.
Cách chia tách nghiệp vụ: trước hết cần chốt kết quả có thể xác minh của giai đoạn một.
Đề nghị cố định giai đoạn một vào một kết quả có thể đo lường, ví dụ: “tiến độ báo công ở các công đoạn then chốt không chậm quá 30 phút, nhân viên lập kế hoạch có thể căn cứ phiếu công việc để kiểm tra đồng bộ và nguyên nhân tắc nghẽn”. Những hạng mục còn lại như tối ưu hóa sâu tồn kho, phân bổ chi phí, bảng điều khiển BI sẽ dời sang giai đoạn hai. Việc chia tách nghiệp vụ có thể dựa trên bốn chuỗi:
- Chuỗi phiếu công việc : lấy phiếu công việc và định nghĩa công đoạn từ ERP/MES, đồng thời xác định rõ người chịu trách nhiệm về dữ liệu chủ.
- Chuỗi báo công : ai, lúc nào quét mã/điểm chọn để báo hoàn thành, tái công, tạm dừng.
- Chuỗi bất thường : thiếu nguyên liệu, thiết bị ngừng hoạt động, chất lượng bị đóng băng—tắc nghẽn phía hạ lưu ra sao.
- Chuỗi đối chiếu : khi thanh toán hàng ngày, giải thích thế nào về sự chênh lệch giữa tiến độ hệ thống và kiểm kê thực tế.
Mỗi chuỗi cần ghi rõ sự kiện kích hoạt, vai trò trách nhiệm, quy trình nâng cấp khi vượt hạn. Nếu không thể viết ra, chứng tỏ nghiệp vụ chưa sẵn sàng lên hệ thống, nên trước hết cần làm nóng quy trình, chứ không nên vội vàng bắt tay vào phát triển. Cuộc họp chốt phạm vi phải hình thành văn bản ký kết: những tính năng nằm trong danh sách sẽ vào giai đoạn một, còn ngoài danh sách sẽ vào kho yêu cầu; mọi thay đổi đều phải thông qua phiếu thay đổi và đánh giá thời hạn.
Thiết kế ra sao: vai trò, quy trình, ranh giới dữ liệu.Trong giai đoạn thiết kế, cần đưa ra ba thứ, chứ không phải chỉ là vài bản wireframe: ma trận vai trò, máy trạng thái, hợp đồng giao diện. Bản wireframe có thể bổ sung sau, nhưng nếu ba nội dung đầu tiên thiếu thì bất kỳ giao diện nào cũng sẽ phải sửa lại.
Vai trò và quyền hạn.
Ít nhất cần phân biệt nhân viên lập kế hoạch, tổ trưởng, công nhân vận hành, kiểm tra chất lượng, quản lý kho, và ban lãnh đạo chỉ đọc. Việc điều chuyển và hủy bỏ phải ghi lại bằng hai chữ ký; công nhân chỉ báo công tại vị trí của mình; nhân viên lập kế hoạch xem xét hồ sơ tắc nghẽn. Quyền hạn gắn với “vị trí + dây chuyền sản xuất”, tránh tài khoản vạn năng cho một người. Tài khoản và việc nghỉ việc phải được cập nhật vào danh sách vận hành, nếu không nợ quyền hạn sẽ phản tác dụng, làm suy giảm độ tin cậy của dữ liệu.
Quy trình và trạng thái.
Gợi ý đơn giản hóa trạng thái của từng công đoạn: chờ khởi công, đang gia công, chờ kiểm tra, hoàn thành, tái công, đóng băng. Chuyển trạng thái chỉ được phép theo các bước hợp pháp; nếu nhảy qua bước không hợp lệ phải ghi rõ mã nguyên nhân. Kanban chỉ đọc kết quả máy trạng thái, nghiêm cấm bypass báo công để trực tiếp thay đổi trạng thái. Tái công phải xác định rõ trở lại công đoạn nào, có tạo phiếu công việc phụ hay không, tránh tình trạng “trông như hoàn thành, thực tế lại quay về”.
Dữ liệu và ranh giới giao diện.
Dữ liệu chủ (vật tư, quy trình, tổ nhóm) do hệ thống nguồn bảo trì; dữ liệu thực thi (báo công, bất thường) được tạo tại hệ thống hiện trường. Giao diện cắt giảm theo vị trí: công nhân hoàn tất báo công chỉ với ba phím, nhân viên lập kế hoạch xem tắc nghẽn và đồng bộ, ban lãnh đạo xem phân bố độ trễ. Không nên đưa toàn bộ trường của ERP lên máy tính bảng tại phân xưởng. Càng ít trường, thu thập càng chính xác.
Cách phát triển và triển khai: giao diện, thu thập, nghiệm thu.
Thứ tự phát triển khuyến nghị: đồng bộ dữ liệu chủ → thu thập báo công → xử lý tắc nghẽn bất thường → truy vấn khớp với phiếu công việc → báo cáo đối chiếu hàng ngày. Giao diện ưu tiên tính đồng nhất: thay đổi phiếu công việc dùng số phiên bản; báo công dùng khóa duy nhất của nghiệp vụ để chống trùng. Đầu thu thập phải thích ứng với mạng yếu: hàng đợi cục bộ, truyền hồi, cảnh báo xung đột. Quét mã thiết bị và điểm chọn thủ công có thể cùng tồn tại, nhưng cùng một công đoạn chỉ được phép có một “sự kiện hoàn thành chính thức”.
Khi thử nghiệm liên kết cần chuẩn bị “kịch bản dữ liệu bẩn”: quét mã lặp lại, gián đoạn mạng, thay đổi quy trình giữa chừng của phiếu công việc, điều chuyển giữa các tổ. Những tình huống này còn phơi bày lỗ hổng thiết kế mạnh hơn cả kịch bản hạnh phúc. Về hiệu suất, truy vấn kanban phân vùng theo dây chuyền sản xuất, tránh việc quét toàn bộ bảng theo thời gian thực trên toàn nhà máy.
Nghiệm thu không nên dựa trên “đánh dấu điểm chức năng”. Thay vào đó dùng kịch bản tình huống: mở một phiếu công việc thật, đi qua toàn bộ công đoạn báo công; tự tạo tình huống thiếu nguyên liệu để kiểm tra đóng băng phía dưới; sau khi điều chuyển giữa các tổ, kiểm tra xem kanban và phiếu công việc có đồng bộ không; lấy mẫu ba ngày báo công và kiểm kê thực tế, tỷ lệ chênh lệch phải thấp hơn ngưỡng thỏa thuận. Nếu không đạt, không ký nghiệm thu cuối cùng, chỉ ký cho phép vận hành có điều kiện.
Hồ sơ bàn giao cần bao gồm: biên bản chốt phạm vi, thuyết minh máy trạng thái, danh sách giao diện, ma trận quyền hạn, biên bản nghiệm thu theo tình huống, lịch trực vận hành và quy trình thay đổi. Thiếu những nội dung này, hậu mãi sẽ trở thành khảo cổ học bằng lời.
Kết thúc: coi việc bàn giao như “quy tắc có thể vận hành”.
Từ yêu cầu đến vận hành, cốt lõi không phải là chồng chất chức năng, mà là biến các quy tắc mặc định tại phân xưởng thành logic có thể thực thi, đồng thời dùng thu thập và nghiệm thu để chứng minh nó đang vận hành. Giai đoạn một chỉ cần đục một lỗ trên một chuỗi, còn hơn mười menu bán thành phẩm. Nếu nhà máy của bạn đang vướng mắc ở tiến độ công đoạn và không khớp với phiếu công việc, có thể áp dụng lộ trình trên để thu gọn phạm vi giai đoạn một rồi khởi động.
Shandong XYN Information Technology Co., Ltd. (XYN Tech) chuyên làm phần mềm tùy chỉnh cho nhiều ngành nghề, chia nhỏ phạm vi, thiết kế, phát triển và nghiệm thu thành các hạng mục có thể bàn giao. Để tìm hiểu thêm, vui lòng truy cập Về chúng tôi.