ERP cho một doanh nghiệp phân phối: từ Excel tới báo cáo thời gian thực

Đây là một hệ thống quản trị viết riêng cho một doanh nghiệp phân phối, hiện đang chạy hằng ngày. Ảnh chụp màn hình dashboard của hệ thống này nằm ở phần giải pháp trên trang chủ. Bài viết kể lại các quyết định thiết kế — phần thường không xuất hiện trong tài liệu giới thiệu nhưng lại là phần quyết định hệ thống dùng được hay không.

Hiện trạng trước khi làm

Toàn bộ vận hành chạy trên bảng tính và tin nhắn. Báo giá soạn trong Word, đơn hàng chốt qua nhóm chat, kho ghi sổ, công nợ nằm trong một file Excel do một người giữ. Mỗi mắt xích đều hoạt động; vấn đề là chúng không nối với nhau, nên không ai trả lời được nhanh ba câu hỏi:

• Báo giá tuần trước đã thành đơn hàng chưa, hay đang nằm im?
• Đơn này đã giao đủ chưa, đã xuất hoá đơn chưa, khách đã trả tiền chưa?
• Tháng này lãi thật bao nhiêu, sau khi trừ chiết khấu và hàng trả lại?

Quyết định 1: Làm cả chuỗi, không làm từng mảnh rời

Yêu cầu ban đầu là "làm phần mềm quản lý đơn hàng". Nhưng khảo sát cho thấy nếu chỉ làm đơn hàng thì kho vẫn ghi sổ, công nợ vẫn ở Excel, và người dùng vẫn phải nhập hai lần — tức là vẫn còn nguyên nguyên nhân gốc.

Nên phạm vi được mở rộng thành một chuỗi liền mạch: báo giá → xác nhận đơn → xuất kho → giao hàng → hoá đơn → công nợ. Mỗi bước tạo dữ liệu cho bước sau, không nhập lại lần nào. Đổi lại, chuỗi này được cắt thành các mốc hai tuần để doanh nghiệp có thứ dùng được sớm chứ không chờ tới cuối.

Quyết định 2: Trạng thái là xương sống

Phần lõi của hệ thống không phải màn hình mà là mô hình trạng thái của chứng từ. Một đơn hàng đi qua các trạng thái xác định, và mỗi bước chuyển đều có điều kiện:

Cột bên phải là chỗ hệ thống trả lại giá trị rõ nhất: không ai phải nhớ "xuất kho rồi thì nhớ ghi công nợ". Nó tự xảy ra, và vì thế nó không bị quên vào ngày bận.

Chỗ suýt hỏng: hàng giao thiếu

Bản thiết kế đầu tiên giả định hàng giao đúng bằng hàng xuất. Thực tế thì không: khách nhận thiếu vài thùng vì hàng lỗi, hoặc nhận đủ nhưng trả lại ngay tại điểm giao.

Nếu hệ thống chỉ cho ghi "đã giao" hoặc "chưa giao", nhân viên sẽ chọn "đã giao" rồi sửa tay ở đâu đó — và toàn bộ chuỗi tự động phía sau sai theo. Phần này được làm lại: cho phép ghi số lượng thực giao ngay tại điểm giao, phần chênh lệch tự tạo phiếu hoàn kho và điều chỉnh giá trị hoá đơn.

Dashboard: bốn ô đầu tiên

Màn hình tổng quan cố ý giữ gọn. Bốn chỉ số ở hàng đầu — doanh thu tháng, số đơn đang xử lý, số mặt hàng chạm ngưỡng cảnh báo tồn, và công nợ phải thu chưa thanh toán — cùng một khối "chờ phê duyệt" liệt kê các báo giá và hoá đơn cần người có quyền xem xét.

Khối "chờ phê duyệt" là phần được dùng nhiều nhất trong ngày, dù nó không phải phần trông ấn tượng nhất. Đó là ví dụ điển hình cho nguyên tắc ở bài Dashboard quản trị: thứ đáng đặt lên đầu là thứ dẫn tới hành động, không phải thứ đẹp nhất.

Chuyển dữ liệu và chạy song song

Danh mục hàng hoá cũ có nhiều dòng trùng do nhiều người cùng thêm qua các năm. Việc gộp mã và thống nhất đơn vị tính chiếm phần lớn thời gian của giai đoạn chuyển dữ liệu — nhiều hơn cả phần nạp số liệu.

Số dư đầu kỳ được lấy từ kiểm kê thực tế chứ không lấy từ file cũ; công nợ được đối chiếu với từng khách trước khi nạp. Hai hệ thống chạy song song vài tuần, đối chiếu cuối mỗi tuần, và chỉ dừng Excel khi số liệu khớp liên tục.

Điều rút ra

1. 1Phạm vi hẹp quá thì không giải quyết được nguyên nhân gốc; phạm vi rộng thì phải cắt thành mốc ngắn để không mất kiểm soát.
2. 2Thiết kế trạng thái quan trọng hơn thiết kế giao diện. Giao diện sửa được trong một ngày; mô hình trạng thái sai thì sửa mất vài tuần.
3. 3Trường hợp ngoại lệ phải được thiết kế ngay từ đầu, không để "xử lý sau" — vì nếu người dùng không ghi được sự thật vào hệ thống, họ sẽ ghi một thứ khác.