Tính thời gian giao hàng nghe có vẻ là một tính năng đơn giản: khách đặt hàng, hệ thống kiểm tra tồn kho, rồi trả về một ngày giao dự kiến. Phần lớn đội ngũ viết thẳng logic đó vào lớp script của ERP mà không dừng lại để hình dung quy trình trước. Vấn đề là "kiểm tra tồn kho rồi trả ngày giao" che giấu nhiều quyết định rất dễ sai một khi đơn hàng không thể lấy đủ từ một nơi duy nhất — và những sai sót đó thường chỉ lộ ra một lần, ngay khi hệ thống đã chạy thật, lúc khách hàng gọi điện hỏi tại sao ngày giao đã hứa lại sai.
Chỉ một nhánh được chọn — điểm rẽ XOR
Trước khi viết bất kỳ dòng code nào, quy trình bên dưới có thể được vẽ thành một EPK (Ereignisgesteuerte Prozesskette — chuỗi quy trình do sự kiện điều khiển): một dãy sự kiện và chức năng nối với nhau bằng các cổng rẽ nhánh tường minh. Cổng đầu tiên ở đây là một điểm rẽ XOR (exclusive-or — loại trừ lẫn nhau): với một đơn hàng bất kỳ, chỉ đúng một trong ba nhánh được chọn:
- Lấy đủ hàng từ một kho duy nhất.
- Phải chia (split) ra nhiều kho.
- Không có đủ hàng để giao.
Vẽ tường minh ba nhánh này ra, thay vì để ẩn trong một chuỗi if-else, buộc chúng tôi phải gọi tên đủ cả ba tình huống trước khi viết code cho bất kỳ nhánh nào.
Khi đơn hàng bị chia — điểm hợp UND
Nhánh bị chia ra nhiều kho chính là nơi độ phức tạp thật sự nằm ở đó. Một khi đơn hàng được chia cho nhiều kho, một điểm hợp AND (parallel AND — song song) sẽ áp dụng: mỗi kho liên quan chạy thời gian lấy hàng và thời gian vận chuyển của riêng mình, và các thời gian này chạy song song, không phải nối tiếp nhau. Việc mô hình hoá tường minh điều này quan trọng vì quy trình kho không phải một cuộc chạy tiếp sức — kho A không cần đợi kho B xong việc rồi mới bắt đầu.
Lỗi mà việc mô hình hoá bắt được: MAX, không phải SUM
Vì hai quy trình kho chạy song song, tổng thời gian giao hàng của một đơn bị chia là giá trị lớn nhất (MAX) trong các thời gian của từng kho — khách hàng chỉ nhận đủ đơn hàng khi lô hàng chậm nhất tới nơi — chứ không phải tổng (SUM) của tất cả. Một cách hiện thực hoá ngây thơ, chỉ đơn giản cộng dồn thời gian của từng kho, sẽ hệ thống hoá sai lệch và luôn báo thời gian giao dài hơn thực tế cho mọi đơn hàng bị chia. Đây chính là loại lỗi rất rẻ để bắt được trên giấy, ngay lúc vẽ cổng AND, nhưng rất đắt để phát hiện sau khi mô-đun đã chạy thật.
Vẫn chưa phải kết quả cuối: hiệu chỉnh theo lịch
Ngay cả sau khi tính xong thời gian thô theo MAX (hoặc theo kho đơn), đó vẫn chưa phải con số hiển thị cho khách hàng. Các hiệu chỉnh về ngày làm việc và giờ cắt (working-day/cut-off correction) vẫn cần được áp dụng — một đơn hàng đặt sau giờ cắt trong ngày sẽ được tính như bắt đầu từ ngày làm việc kế tiếp, và cuối tuần hay ngày nghỉ lễ sẽ đẩy con số này xa hơn nữa. Bỏ qua bước này, hoặc tính sai logic lịch, là một nguồn lỗi khác, không kém phổ biến, khiến ngày giao dự kiến bị sai.
Gộp lại, chỉ một mô-đun nhỏ này đã lộ ra ba lỗi cụ thể:
- Coi các kho song song như thể chúng chạy tuần tự.
- Dùng SUM thay vì MAX cho đơn hàng bị chia.
- Xử lý sai logic ngày làm việc/giờ cắt.
Không có lỗi nào trong số này lạ lùng cả — đó là loại sai sót mà bất kỳ lập trình viên nào cũng có thể mắc phải khi viết thẳng vào code. Bài học thực tế cho một xưởng sản xuất đang tự xây hoặc tự đặc tả logic ERP của mình rất đơn giản: với bất kỳ quy trình nào có nhiều hơn một nhánh khả dĩ, hãy phác thảo nó ra trước — dù chỉ sơ bộ, trên giấy, với các điểm rẽ và các bước song song được đánh dấu rõ — trước khi ai đó viết phép tính đó thành code. Việc này tốn một giờ, và rẻ hơn rất nhiều so với một ngày giao hàng sai trước mặt khách hàng.
Nguyễn Hải Minh
Tôi làm việc trong ngành CNTT tại Đức — trực tiếp viết phần mềm và xử lý dữ liệu hệ thống ERP (như INFOR) cho các nhà máy sản xuất của Đức. Về học vấn, tôi có bằng Cử nhân Kỹ thuật CNTT và bằng Kỹ thuật viên Điện tử Thông tin cấp nhà nước tại Đức. Tất cả những nền tảng đó giúp tôi rèn luyện một tư duy hệ thống vững vàng để làm tự động hóa và tối ưu vận hành chuẩn chỉ.
Tìm hiểu thêm về tác giả →