Khi một nhà sản xuất triển khai hệ thống kiểm soát thay đổi đơn hàng, yêu cầu của khách hàng về việc tăng số lượng, đẩy nhanh giao hàng, hoặc sửa đổi thông số kỹ thuật không thể đơn giản ghi đè lên đơn bán hàng. Đội ngũ phải giữ lại cam kết trước đó, đánh giá tác động đến vật tư và sản xuất, phê duyệt đề xuất khả thi, xác nhận các điều khoản mới với khách hàng, và cập nhật ERP cũng như MES từ cùng một phiên bản hiệu lực. Hướng dẫn này bao gồm quy trình làm việc, mô hình dữ liệu, RFP, FAT và SAT cho một nhà máy tại Thái Lan.
Phạm vi: thay đổi sau khi đã thỏa thuận đơn hàng
Thay đổi đơn hàng là yêu cầu điều chỉnh số lượng đã thỏa thuận, ngày giao hàng hoặc địa điểm giao, chia lô giao hàng, thông số kỹ thuật sản phẩm, hoặc điều kiện đóng gói. Nó bắt đầu tại một thời điểm khác so với báo giá hoặc mua hàng ban đầu và có các chủ sở hữu quyết định khác nhau. Hướng dẫn quản lý đơn hàng và mua hàng của chúng tôi giải thích phạm vi rộng hơn của đơn hàng, mua hàng và MRP. Hướng dẫn loại bỏ nhập liệu trùng lặp trong nhà máy của chúng tôi đề cập đến các sự kiện MES, ERP và WMS. Ở đây, câu hỏi là điều khoản khách hàng sửa đổi nào sẽ có hiệu lực, và khi nào.
Một mã đơn hàng có thể có nhiều quyết định kinh doanh theo thời gian. Nếu bộ phận bán hàng chỉ thay đổi ngày trong ERP sau khi nhận email, hướng dẫn sản xuất và cam kết vật tư có thể vẫn phản ánh cam kết cũ. Nếu sản xuất chỉ thay đổi lịch trình của mình, nhà máy có thể hành động trước khi khách hàng chấp nhận đề nghị sửa đổi. Quy trình mục tiêu là tiếp nhận yêu cầu, đóng băng phiên bản trước, đánh giá hậu quả, phê duyệt đề xuất, ghi nhận phản hồi khách hàng, và chỉ phát hành phiên bản đã thỏa thuận xuống các bộ phận liên quan.
Xác định hồ sơ đơn hàng có thẩm quyền trước khi chọn phần mềm
Xác định một đơn hàng bằng khách hàng, số đơn hàng, dòng, mã hàng hoặc mã sản phẩm khách hàng, địa điểm giao hàng, dòng lịch giao hàng, và phiên bản. Việc tăng từ 100 lên 120 đơn vị có thể nghĩa là sửa đổi dòng gốc hoặc tạo đơn hàng riêng cho 20 đơn vị; lựa chọn này ảnh hưởng đến hóa đơn, giao hàng và truy xuất nguồn gốc. Giữ số thay đổi đơn hàng của khách hàng tách biệt với phiên bản đơn hàng nội bộ, có liên kết tham chiếu giữa chúng.
Ghi nhận một yêu cầu như một hồ sơ riêng thay vì chỉnh sửa trực tiếp đơn hàng đang hoạt động. Ghi lại mã hồ sơ, thời gian nhận và múi giờ, người yêu cầu, kênh tiếp nhận, tin nhắn gốc và tệp đính kèm, các dòng bị ảnh hưởng, thay đổi được yêu cầu, ngày hiệu lực mong muốn, hạn trả lời, và người phụ trách. Xác nhận lại yêu cầu đầu tiên nhận qua điện thoại với khách hàng, và phân biệt ghi chú chưa xác nhận với chỉ thị đã xác nhận. Chuẩn hóa các đầu vào email, EDI, và cổng thông tin thành cùng một mô hình hồ sơ, đồng thời giữ nguyên bằng chứng nguồn.
Định nghĩa ý nghĩa của các phiên bản trước, đề xuất, đã phê duyệt, và hiệu lực. Nếu V3 là đơn hàng đã được khách hàng xác nhận và V4 đang được đánh giá, xưởng sản xuất vẫn sử dụng V3. Việc phê duyệt nội bộ V4 không chứng minh rằng khách hàng đã chấp nhận nó. Nếu hợp đồng yêu cầu sự đồng ý rõ ràng từ khách hàng, hãy lưu lại bằng chứng đó trước khi cho V4 có hiệu lực. Số phiên bản thể hiện thứ tự; trạng thái thể hiện thẩm quyền kinh doanh. Đây là hai trường khác nhau.
Lưu trữ giá trị trước và sau, không chỉ danh sách tên trường đã chỉnh sửa. Chụp lại giá, tiền tệ, vận chuyển, thuế, và điều kiện thanh toán liên quan ngay cả khi chúng nằm ngoài yêu cầu tức thời. Đối với thay đổi thông số kỹ thuật, liên kết số và phiên bản bản vẽ, BOM hiệu lực, tiêu chí kiểm tra, và phê duyệt của khách hàng. “Tệp đính kèm mới nhất” không phải là tham chiếu sản xuất đầy đủ. Lưu lại mã tệp nhận được, mã băm nội dung khi khả thi, và vị trí lưu trữ thay vì chỉ dựa vào liên kết chia sẻ có thể thay đổi sau này.
Sử dụng một quy trình cho số lượng, ngày giao hàng và thông số kỹ thuật, với các bước kiểm tra khác nhau
Việc tăng số lượng có thể yêu cầu thêm nguyên vật liệu, năng lực sản xuất, thời gian kiểm tra và không gian vận chuyển. Việc giảm số lượng đặt ra các câu hỏi về linh kiện đã mua, bán thành phẩm, thành phẩm, quyền hủy đơn và ai sẽ chịu chi phí cho hàng tồn không sử dụng được. Trước khi cam kết một ngày giao hàng mới, hãy đánh giá tồn kho khả dụng sau khi đã phân bổ, nguồn cung sắp về, lô tối thiểu, tỷ lệ đạt và năng lực máy móc thực tế. Số lượng giảm không đồng nghĩa với việc thay đổi sẽ đơn giản hơn.
Giữ riêng biệt các trường: ngày giao hàng khách hàng yêu cầu, ngày khả thi đã tính toán, và ngày cam kết xác nhận. Tài liệu hướng dẫn cam kết đơn hàng của Microsoft mô tả ATP dựa trên nguồn cung khả dụng và CTP dựa trên vật tư và năng lực. Tài liệu này cũng minh họa rằng một cập nhật không nhất thiết phải tính lại cam kết nếu ngày hiện tại vẫn khả thi. Đây là mô tả cho một sản phẩm cụ thể, không phải hành vi chung của mọi hệ thống ERP. Hãy xác định rõ khi nào hệ thống của bạn phải tính lại cho cả yêu cầu sớm và muộn, và ai là người phê duyệt phản hồi.
Thay đổi thông số kỹ thuật cần thêm các bước kiểm soát. Xác định xem thay đổi liên quan đến bản vẽ, vật liệu, thiết lập quy trình, phương pháp kiểm tra hay nhãn mác. Quyết định thông số mới sẽ áp dụng hồi tố, từ ranh giới lô, hay chỉ từ một ngày trong tương lai sau khi đánh giá việc nhận diện hàng cũ và mới, tách biệt WIP, tái chế hoặc loại bỏ, và phê duyệt của khách hàng. Việc chỉ phát hành bản vẽ mới không hoàn tất thay đổi nếu vật liệu cũ hoặc đồ gá kiểm tra vẫn còn trên dây chuyền.
Giao hàng chia nhỏ cần nhiều hơn một trường số lượng và ngày trên dòng đơn hàng. Tài liệu lịch giao hàng của Microsoft mô tả việc nhập riêng số lượng và ngày cho nhiều lần giao. Yêu cầu cần phân biệt tổng số lượng đơn hàng, từng dòng giao hàng, số lượng đã giao, và số lượng còn lại có thể thay đổi. Việc hoán đổi lô giao hàng đầu tiên và thứ hai có thể làm thay đổi kế hoạch sản xuất dù tổng số lượng không đổi.
Đánh giá tác động phải thể hiện số liệu và bằng chứng
Đặt thỏa thuận trước đó, yêu cầu thay đổi và các phương án khả thi cạnh nhau. Với mỗi phương án, hãy thể hiện hạn trả lời của khách hàng, dự kiến ngày xuất hàng và đến nơi, thiếu hụt vật tư, tải thiết bị và nhân công, các bước gia công thuê ngoài, phê duyệt chất lượng, chi phí phát sinh, và điều kiện hợp đồng dựa trên dữ liệu tại một thời điểm xác định. Hỗ trợ các phương án có điều kiện như giao hàng chia nhỏ hoặc chuyển sang dây chuyền đã được phê duyệt khác; không trình bày chúng như cam kết trước khi có đủ phê duyệt về chất lượng, thương mại và khách hàng.
Tồn kho thực tế khác với tồn kho khả dụng cho đơn hàng này. Loại trừ hàng đã phân bổ, hàng bị giữ chất lượng, hàng chờ xuất hoặc hàng đang tranh chấp theo chính sách. Với vật tư mua ngoài, thể hiện hạn trả lời của nhà cung cấp, quyền hủy đơn và thời gian vận chuyển. Với năng lực sản xuất, bao gồm thời gian thiết lập, kiểm tra, đóng gói, bảo trì và lịch làm việc của nhà máy, không chỉ là thời gian máy rảnh. Đối với gia công thuê ngoài, trạng thái chờ phản hồi phải được thể hiện rõ ràng.
Tin nhắn hành động của Microsoft giải thích cách thay đổi nhu cầu bán hàng có thể dẫn đến đề xuất thay đổi các đơn cung ứng hiện có. Hướng dẫn lập kế hoạch sản xuất của Microsoft lưu ý rằng thay đổi thủ công đơn hàng dự kiến có thể yêu cầu chạy lại kế hoạch trước khi các yêu cầu vật tư liên quan được cập nhật. Hãy coi đây là gợi ý để kiểm tra triển khai thực tế của bạn: điều gì kích hoạt việc lập lại kế hoạch, khi nào kết quả được đọc, và màn hình ngăn trả lời dựa trên dữ liệu cũ như thế nào?
| Lĩnh vực | So sánh trước và sau | Người quyết định | Bằng chứng |
|---|---|---|---|
| Điều khoản khách hàng | Số lượng, ngày, thông số, chia lô, giá | Kinh doanh | Yêu cầu và phản hồi đề xuất |
| Vật tư | Tồn kho khả dụng, nhu cầu bổ sung, nhận hàng khả thi | Hoạch định và mua hàng | Phân bổ và phản hồi nhà cung cấp |
| Sản xuất | Năng lực, thiết lập, WIP, hoàn thành | Hoạch định và vận hành | Ảnh chụp kế hoạch |
| Chất lượng | Bản vẽ, kiểm tra, phê duyệt, tách biệt | Chất lượng và kỹ thuật | Tài liệu đã phê duyệt |
| Vận chuyển | Đã xuất, tồn, vận chuyển, điểm đến | Logistics | Kế hoạch giao hàng |
| Thương mại | Chi phí phát sinh, hủy đơn, hợp đồng | Kinh doanh và tài chính | Báo giá và phê duyệt |
Điều chỉnh các cột cho phù hợp với ngành và hợp đồng. Ngành thực phẩm và hóa chất có thể cần kiểm tra lô, hạn sử dụng hoặc công thức; gia công cơ khí có thể cần kiểm tra dụng cụ và sản phẩm mẫu đầu tiên; điện tử có thể cần phê duyệt linh kiện thay thế. Xem xét một mẫu nhỏ các trường hợp thay đổi gần đây để phát hiện các đánh giá bị bỏ sót và phê duyệt chậm trước khi sửa mẫu. Mười trường hợp là một điểm khởi đầu thực tế minh họa, không phải tiêu chuẩn chính thức.
Phân biệt quyền trả lời và quyền thực hiện
Chuyển hướng yêu cầu dựa trên mức độ ảnh hưởng. Một chỉnh sửa chính tả địa chỉ giao hàng trước khi sản xuất không nên đi cùng quy trình với thay đổi vật liệu sau khi đã bắt đầu sản xuất. Các điều kiện hữu ích gồm: ảnh hưởng đến thông số kỹ thuật, trạng thái sản xuất, yêu cầu phê duyệt của khách hàng, chi phí, tác động giao hàng, và xử lý hàng tồn cũ. Đặt ngưỡng giá trị theo chính sách công ty và hợp đồng, không dựa vào bài viết chung chung.
Phân biệt các bước: tiếp nhận, đánh giá, phê duyệt nội bộ, đề xuất cho khách hàng, khách hàng chấp nhận, kích hoạt, cập nhật xuống các bộ phận, và đóng hồ sơ. Một người có thể đảm nhiệm nhiều vai trò, nhưng mỗi quyết định cần có dấu thời gian và bằng chứng riêng. Việc trả lời miệng không chính thức có ràng buộc hay không phụ thuộc vào hợp đồng. Hệ thống nên phân biệt các trạng thái “đang thảo luận”, “đề xuất chính thức”, “chờ khách hàng”, “đã xác nhận” và “đã hủy”, đồng thời ngăn các điều khoản chưa xác nhận tự động chuyển xuống sản xuất.
Hiển thị các trường hợp quá hạn và ai là người chịu trách nhiệm trả lời tiếp theo. Một yêu cầu chờ mua hàng, chất lượng hoặc khách hàng cần theo dõi khác nhau. Đến hạn trả lời, người phụ trách có thể đề xuất phương án thay thế hoặc gửi phản hồi tạm thời. Việc tự động gia hạn ngày cam kết mà không có phê duyệt sẽ thay đổi cam kết thương mại; hãy ghi lại mọi gia hạn và người phê duyệt.
Phát hành bản sửa đổi đã xác nhận lên ERP và MES
Sau khi xác nhận, cập nhật dòng đơn hàng trên ERP, kiểm tra kết quả lập kế hoạch lại và điều chỉnh hướng dẫn sản xuất hoặc mua hàng khi cần thiết. MES cần thông tin về mã hàng, số lượng, tuyến sản xuất, bản vẽ và tiêu chuẩn công việc hiệu lực. Không được ghi đè lặng lẽ lên hướng dẫn đang thực hiện. Ghi nhận việc dừng hướng dẫn cũ, xử lý bán thành phẩm đang sản xuất (WIP), và phát hành hướng dẫn mới. Truy vấn WMS hoặc bộ phận vận chuyển để biết số lượng đã lấy, đã đóng gói và đã xuất kho trước khi thay đổi hướng dẫn logistics.
Tổng quan về ISA-95 của OPC Foundation mô tả mô hình thông tin giữa hoạch định doanh nghiệp và vận hành sản xuất. Tài liệu này không quy định quy trình thay đổi đơn hàng cụ thể như trên. Tuy nhiên, nó hữu ích khi xác định ranh giới hệ thống và các mã định danh: đơn hàng, dòng, phiên bản, lệnh sản xuất, lô hoặc số sê-ri, thời gian sự kiện và hệ thống nguồn. Gán cho mỗi thay đổi một khóa idempotency để việc thử lại không áp dụng thay đổi số lượng hai lần; lưu các thông báo thất bại vào hàng đợi ngoại lệ có thể phục hồi.
Xác định thứ tự cập nhật. Nếu ERP xác nhận V4 trong khi MES sau đó báo cáo thực hiện theo V3, “thông điệp cuối cùng thắng” là không an toàn. So sánh phiên bản trước dự kiến và phiên bản đến, chuyển các trường hợp không khớp cho người chịu trách nhiệm xử lý ngoại lệ. Ghi lại người thực hiện, lý do, sự kiện nguồn và kết quả của bất kỳ sửa chữa thủ công nào. Dịch văn bản trạng thái giao diện cho người dùng địa phương nhưng giữ mã sự kiện và định danh độc lập với ngôn ngữ.
Quản lý cam kết với khách hàng tách biệt với việc giao hàng kỹ thuật. Bộ phận kinh doanh có thể xác nhận ngày 20 tháng 10 trong khi cập nhật MES thất bại. Ngược lại, nhà máy không được chạy thông số kỹ thuật mới trước khi có sự đồng ý cần thiết từ khách hàng. Một cổng phát hành có thể kiểm tra sự đồng thuận của khách hàng, áp dụng ERP, nhận MES và dừng hướng dẫn lỗi thời. Sử dụng ma trận loại thay đổi để quyết định cổng nào áp dụng thay vì bắt buộc mọi chỉnh sửa nhỏ đều phải qua cả bốn bước.
Lưu giữ dấu vết kiểm toán có thể tái dựng
Danh sách chỉnh sửa có dấu thời gian là chưa đủ. Từ một trường hợp, cần truy xuất yêu cầu gốc, sự khác biệt giữa các phiên bản, độ tuổi của dữ liệu đầu vào lập kế hoạch, các đề xuất thay thế, quyết định phê duyệt, thông điệp gửi cho khách hàng, phản hồi của khách hàng, kết quả ERP và MES, và xử lý ngoại lệ. Thiết lập thời gian lưu trữ và quyền truy cập theo hợp đồng và ngành nghề. Nhật ký kiểm toán màn hình sẽ vô ích nếu bản vẽ khách hàng tham chiếu không còn truy xuất được.
Thông báo ISO 10013:2021 của ISO bàn về hướng dẫn quản lý thông tin tài liệu trong môi trường số. Tổng quan ISO 9001:2026 của ISO nhấn mạnh trọng tâm khách hàng, tiếp cận theo quy trình, tư duy dựa trên rủi ro và cải tiến. Không nguồn nào bắt buộc các màn hình cụ thể như mô tả ở đây. Đề xuất về trường sửa đổi, bằng chứng, phê duyệt và theo dõi là thiết kế triển khai để tái dựng quyết định.
Khi cần liên kết với sản phẩm vật lý, liên hệ lô hoặc số sê-ri đã xuất với phiên bản đơn hàng hiệu lực. GS1 EPCIS 2.0.1 định nghĩa TransactionEvent liên kết đối tượng vật lý hoặc số với giao dịch kinh doanh. Đây là một tiêu chuẩn tham khảo khả thi cho truy xuất nguồn gốc liên công ty, không phải yêu cầu bắt buộc mọi nhà máy đều phải triển khai EPCIS.
Những nội dung cần đưa vào RFP
“Có hỗ trợ thay đổi đơn hàng” là quá chung chung. Đưa ra các kịch bản cho tăng số lượng, giảm số lượng, đẩy nhanh ngày giao, tách giao hàng, thay đổi thông số kỹ thuật và hủy đơn. Với mỗi trường hợp, nêu rõ phiên bản khởi đầu, kênh nhập liệu, người phê duyệt, ràng buộc, phản hồi khách hàng dự kiến, kết quả ERP/MES/logistics và phương án phục hồi khi thất bại. Yêu cầu nhà cung cấp đánh dấu từng yêu cầu là cấu hình chuẩn, thiết lập, tùy chỉnh hay thay đổi hệ thống khác.
Nhóm các yêu cầu chức năng thành tiếp nhận và kiểm soát phiên bản; đánh giá vật tư, năng lực, WIP, chất lượng, chi phí và vận chuyển; phê duyệt và giao tiếp với khách hàng; và áp dụng ERP/MES cùng khả năng thử lại và xuất kiểm toán. Bao gồm bằng chứng gốc, so sánh trước/sau, yêu cầu cạnh tranh, độ mới của dữ liệu, ủy quyền phê duyệt, thời hạn, tài liệu phản hồi, sự đồng ý của khách hàng và xử lý ngoại lệ.
Yêu cầu phi chức năng nên bao gồm chỉnh sửa đồng thời, phân tách vai trò, nhật ký chống giả mạo, giới hạn tệp đính kèm, ngôn ngữ và múi giờ, sao lưu và phục hồi, thử lại API và di chuyển dữ liệu. Kiểm tra hai người mở hai phiên bản khác nhau của cùng một trường hợp và một người phê duyệt trước. Giữa nhà máy Thái Lan và trụ sở Nhật Bản, phân biệt thời gian hiển thị địa phương với thời gian UTC lưu trữ và ngày đến nơi với ngày xuất xưởng.
So sánh tổng chi phí triển khai, không chỉ chi phí bản quyền: sửa đổi ERP, ánh xạ MES, di chuyển dữ liệu lịch sử, biểu mẫu, đào tạo, bảo trì và thay đổi thông số kỹ thuật sau này. Không có con số chi phí chung nào từ các nguồn này. Cung cấp cho nhà cung cấp số lượng trường hợp, địa điểm, người phê duyệt, giao diện và yêu cầu lưu trữ, sau đó yêu cầu báo giá riêng cho chi phí ban đầu, thuê bao, phát triển và vận hành. Làm rõ ai chịu trách nhiệm hỗ trợ tùy chỉnh sau khi nâng cấp sản phẩm.
Khi so sánh các đề xuất, không sử dụng các mẫu đơn đặt hàng đẹp mắt do nhà cung cấp chuẩn bị sẵn, mà hãy cung cấp cho họ một trường hợp thực tế đã được ẩn danh từ công ty mình. Nếu khách hàng gửi yêu cầu thay đổi lần thứ hai khi việc đánh giá lần đầu chưa hoàn thành, hãy yêu cầu nhà cung cấp trình diễn cách xử lý: ưu tiên xử lý cái nào trước, và làm thế nào để vô hiệu hóa phương án cũ. Đối với các trường hợp chỉ thay đổi thời hạn giao hàng và các trường hợp thay đổi thông số kỹ thuật cần chờ phê duyệt của khách hàng, cả giao diện màn hình lẫn quy trình phê duyệt đều khác nhau. Những điểm được giải thích là “xử lý bằng vận hành thủ công” trong quá trình demo cần được ghi lại rõ: ai sẽ thực hiện thao tác gì, liệu có xử lý được khi số lượng đơn hàng tăng lên hay không. Ngay cả khi có vẻ là chức năng tiêu chuẩn, nếu chưa tính đến các thiết lập quyền hạn hoặc chuẩn bị master cần thiết, sẽ dẫn đến sai lệch khi so sánh chi phí và thời gian triển khai.
Không chỉ yêu cầu phương pháp nhập thay đổi đơn hàng, mà còn yêu cầu cả tài liệu trả lời gửi cho đối tác. Cần xác định rõ cách hiển thị số lượng, mặt hàng, phiên bản thông số kỹ thuật, ngày xuất hàng và ngày đến, thời điểm bắt đầu áp dụng, các mục chưa xác định trước và sau khi thay đổi trên phiếu trả lời. Nếu phải nhập tay các con số vào nội dung email, có nguy cơ gửi điều kiện khác với phiên bản đã được phê duyệt trên hệ thống. Nếu phiếu trả lời được tự động sinh ra, cần xác nhận rằng không trộn lẫn dữ liệu chưa được phê duyệt, khi tái phát hành phải tăng phiên bản, và không thể chỉnh sửa tài liệu đã gửi. Nếu khách hàng sử dụng mẫu đơn đặt hàng riêng, cần liên kết phiếu trả lời với số đơn thay đổi của khách hàng.
Ngoài ra, cần ghi rõ cách xử lý khi trường hợp thay đổi bị hủy bỏ. Việc hủy bỏ phương án chưa được phê duyệt khác với việc hủy bỏ sau khi đã trả lời xác nhận cho khách hàng. Trong trường hợp sau, không phải lúc nào cũng có thể đơn giản quay lại điều kiện ban đầu. Nếu nguyên vật liệu đã được đặt hàng, sản xuất đã bắt đầu, và đã đặt chỗ vận chuyển, cần đánh giá chi phí và biện pháp xử lý như một trường hợp thay đổi mới. Nếu nút “Hủy bỏ” chỉ xóa dòng lịch sử thì không thể kiểm toán được. Thiết kế phải lưu lại lý do hủy bỏ, người yêu cầu, người phê duyệt, cam kết ban đầu, các công việc đã thực hiện, và chỉ dừng các xử lý tiếp theo chưa thực hiện.
Xử lý các yêu cầu thay đổi đến cùng lúc
Có trường hợp bộ phận mua hàng của khách hàng gửi yêu cầu “tăng số lượng”, trong khi đang đánh giá thì một người khác lại gửi yêu cầu “muốn giao hàng sớm hơn”. Khi tạo phương án V4A từ phiên bản xác nhận V3 gốc, rồi tiếp tục tạo phương án V4B, thì A và B không chỉ đơn thuần là các phiên bản theo thứ tự thời gian mà là các lựa chọn khác nhau. Không được tự ý gộp lại thành một nếu chưa xác nhận với khách hàng rằng B có bao gồm việc tăng số lượng của A hay chỉ thay đổi thời hạn giao hàng. Trên màn hình quản lý đơn hàng, cần thể hiện rõ mỗi phương án dựa trên phiên bản xác nhận nào, đáp ứng yêu cầu nào của khách hàng, và có loại trừ lẫn nhau hay có thể sử dụng đồng thời với các phương án khác.
Nếu một nhân viên phê duyệt phương án A trong khi một người khác đang chỉnh sửa phương án B, có thể xảy ra trường hợp điều kiện đã được phê duyệt bị mất khi lưu màn hình sau. Khi lưu, cần so sánh “phiên bản mình đã tải” với “phiên bản mới nhất hiện tại”, nếu có sai lệch thì yêu cầu tải lại và đánh giá lại. Có trường hợp tồn kho dùng để đánh giá tác động của phương án A đã được phân bổ cho đơn hàng khác khi tạo phương án B. Kết quả đánh giá cần ghi lại thời điểm tính toán và phiên bản dữ liệu nhập, để không thể tạo trả lời xác nhận từ kết quả đã cũ. Cũng cần lưu lại lịch sử phát hiện xung đột, các phương án bị loại bỏ, lý do đánh giá lại để phục vụ kiểm toán.
Xác định ngoại lệ vượt qua ranh giới hiệu lực
“Bắt đầu sản xuất theo điều kiện mới từ khi nào” không chỉ quyết định dựa vào ngày đặt hàng. Ngay cả khi áp dụng thông số kỹ thuật mới cho các lô xuất hàng sau ngày 20/10, thì sản phẩm xuất ngày 20/10 có thể đã hoàn thành nhập nguyên vật liệu và kiểm tra trước đó. Ranh giới hiệu lực cần được xác định rõ theo đơn vị phù hợp với sản phẩm và quy trình như số lệnh sản xuất, lô, serial, thời điểm bắt đầu công đoạn, dòng xuất hàng, v.v. Cần quyết định có cho phép bắt đầu bằng phiên bản cũ và hoàn thành bằng phiên bản mới hay không, nếu cho phép thì ai sẽ phê duyệt kiểm tra bổ sung nào. Nếu phân loại toàn bộ bán thành phẩm nằm trên ranh giới vào “khác”, bộ phận chất lượng sẽ không thể theo dõi.
Ngày trả lời xác nhận cho khách hàng và ngày điều kiện mới có hiệu lực ở phía sản xuất có thể khác nhau. Trình tự an toàn là: đối với các thay đổi cần sự đồng ý của khách hàng, trước tiên lấy bằng chứng đồng ý, ghi lại phiên bản đã được phê duyệt nội bộ làm trả lời xác nhận, cập nhật đơn hàng và kế hoạch ERP liên kết với phiên bản đó, xác nhận việc nhận phiên bản mới và dừng chỉ thị cũ trên MES, cuối cùng cho phép hiệu lực tại ranh giới lô hoặc công đoạn đã thiết lập. Nếu vận hành song song trả lời và phản ánh do gấp, cần làm rõ các cổng chưa hoàn thành và tạm hoãn bắt đầu sản xuất. Nếu khi hệ thống gặp sự cố mà ERP đã ở V4 còn MES vẫn ở V3, không nên ép đơn hàng quay lại V3 mà cần đối chiếu trả lời khách hàng, công việc đã thực hiện, chỉ thị chưa thực hiện, và người chịu trách nhiệm phê duyệt phương án khôi phục.
Bộ dữ liệu kiểm thử đính kèm RFP
Dữ liệu kiểm thử cung cấp cho nhà cung cấp cần bao gồm: khách hàng và nơi giao hàng, số đơn hàng – chi tiết – điều kiện V3, nguyên văn yêu cầu thay đổi của khách hàng, các phương án V4A và V4B, tồn kho nguyên vật liệu và phân bổ, dự kiến nhập hàng, lịch năng lực, lệnh sản xuất đã phát hành, bán thành phẩm, phần đã xuất hàng, hàng giữ chất lượng, phiên bản bản vẽ. Có thể ẩn danh số tiền và tên khách hàng, nhưng phải nhất quán các khóa của đơn hàng, nguyên vật liệu, lệnh sản xuất. Cần ghép cặp dữ liệu đầu vào và đầu ra mong đợi, ví dụ: phương án A thì thiếu nguyên vật liệu, phương án B thì thiếu năng lực, kết hợp cả hai thì cần đề xuất lại thời hạn giao hàng, v.v. Đây là dữ liệu ví dụ giả định, không có nghĩa là tất cả các nhà máy đều gặp thiếu hụt như vậy.
Ngoài các trường hợp bình thường, cần đưa vào các trường hợp bất thường như: gửi cùng một sự kiện thay đổi hai lần, gửi thông điệp V3 sau khi đã xác nhận V4, hủy phê duyệt của khách hàng, yêu cầu giảm số lượng sau khi xuất hàng, chỉ thay thế file bản vẽ. Với mỗi trường hợp, cần liệt kê trạng thái màn hình mong đợi, phiên bản phiếu trả lời khách hàng, giá trị trên ERP và MES, hàng đợi ngoại lệ, log kiểm toán. Nếu lưu lại cấu hình và phiên bản dữ liệu đã dùng trong kiểm thử, có thể tái sử dụng cho so sánh nhà cung cấp hoặc kiểm thử hồi quy sau khi triển khai. Điều này giúp giảm thiểu trường hợp “chạy được trong demo” nhưng không tái hiện được khi vận hành thực tế.
FAT và SAT: kiểm tra thay đổi trong quá trình sản xuất
Đối với FAT, hãy ẩn danh các trường hợp thực tế và kiểm tra việc tạo V4 từ một V3 đã được xác nhận, tính toán tác động, phê duyệt, tạo phản hồi cho khách hàng và mô phỏng các thông điệp ERP/MES. Việc tăng số lượng nên làm lộ ra tình trạng thiếu nguyên vật liệu; việc đẩy nhanh ngày giao hàng nên làm lộ ra các giới hạn về năng lực sản xuất. Xác minh rằng một đề xuất chưa được phê duyệt không thể chuyển đến MES, người phê duyệt có thể đọc bằng chứng liên quan, và một bản sửa đổi bị từ chối sẽ không bao giờ có hiệu lực.
Đối với SAT, kết nối ERP, MES, logistics, và các luồng email hoặc EDI thực tế dưới quyền người dùng thực tế. Kiểm tra các trường hợp truyền thông bị gián đoạn và thử lại, sự kiện trùng lặp và không theo thứ tự, chỉnh sửa từ màn hình đã lỗi thời, thay đổi thông số kỹ thuật trước khi khách hàng đồng ý, và hủy bỏ sau khi sản xuất đã bắt đầu. Đảm bảo các đơn hàng kiểm thử và lệnh sản xuất kiểm thử không ảnh hưởng đến hoạt động thực tế của khách hàng. Khi chuyển đổi, hãy đếm số trường hợp chưa giải quyết và di chuyển chúng một cách rõ ràng.
Viết tiêu chí chấp nhận có thể quan sát được: các bản sửa đổi chưa được phê duyệt không bao giờ được gửi đến MES; một sự kiện thuộc bản sửa đổi cũ vẫn nằm trong hàng đợi ngoại lệ; việc phát lại một sự kiện chỉ thay đổi số lượng một lần; và phản hồi của khách hàng chỉ chứa số lượng và ngày đã được phê duyệt. Xác định ngưỡng thời gian phản hồi dựa trên tải hệ thống và số lượng trường hợp thực tế, thay vì một con số tùy ý trong bài viết.
Dữ liệu sử dụng cho thử nghiệm không chỉ đơn giản là “một đơn đặt hàng mới”, mà còn bao gồm các trường hợp như: yêu cầu thay đổi của khách hàng diễn ra hai lần liên tiếp, giao hàng từng phần mà chỉ chuyến đầu tiên đã xuất kho, tồn kho đang chờ kiểm tra chất lượng, linh kiện đã đặt hàng nhưng chưa nhập kho, và lệnh sản xuất đã bắt đầu thực hiện. Đối với từng trường hợp, cần ghi trước các thông tin như phiên bản mong đợi, trạng thái, người phê duyệt, tài liệu đầu ra, thông điệp liên kết, và điểm đến của các ngoại lệ. Nếu chỉ nhìn vào màn hình sau khi thực hiện để quyết định đạt hay không đạt, thì phán đoán có thể thay đổi về sau. Việc xác định trước giá trị kỳ vọng và lưu lại bằng chứng kiểm thử là rất quan trọng.
Quy trình chuyển đổi cũng cần được diễn tập như một phần của SAT. Cần xác định rõ tại thời điểm nào sẽ đóng băng yêu cầu thay đổi cuối cùng nhận được từ hệ thống cũ, ai sẽ đăng ký vào hệ thống mới, nếu trong quá trình chuyển đổi có liên hệ khẩn cấp từ khách hàng thì ai sẽ chịu trách nhiệm lưu trữ tạm thời, và nếu liên kết thất bại thì có thể quay lại phiên bản nào. Nếu chỉ ghi “cơ sở dữ liệu trước” là điểm quay lại thì sẽ không thể phục hồi các phản hồi đã xác nhận gửi cho khách hàng hoặc các công việc đã bắt đầu tại nhà máy. Cần tách biệt quy trình rollback kỹ thuật với quy trình phục hồi nghiệp vụ do bộ phận kinh doanh và sản xuất thực hiện.
Triển khai theo giai đoạn và đo lường
Bắt đầu với một nhóm sản phẩm mà liên kết từ đơn hàng đến sản xuất có thể truy vết và có đủ thay đổi để học hỏi. Trước khi triển khai, đo thời gian thực tế từ khi tiếp nhận đến khi phản hồi được xác nhận, số lần sửa đổi cần thiết sau phản hồi, sự không khớp giữa ERP/MES, các trường hợp quá hạn và thời gian dành cho việc thu thập bằng chứng kiểm toán. Sử dụng cùng một định nghĩa sau khi triển khai và ghi nhận các thay đổi về mùa vụ, khối lượng và cơ cấu khách hàng. Đánh giá lợi ích dựa trên số liệu thực tế, không dựa trên tỷ lệ giảm giả định.
Chỉ định đại diện từ bộ phận kinh doanh, lập kế hoạch, chất lượng và CNTT. Bộ phận kinh doanh cung cấp các yêu cầu thực tế từ khách hàng; lập kế hoạch xác định ranh giới với hướng dẫn đã phát hành; chất lượng đặt ra điều kiện thay đổi thông số kỹ thuật; CNTT chịu trách nhiệm về dữ liệu và các ngoại lệ tích hợp. Xem xét các trường hợp chưa trả lời, tồn đọng phê duyệt, thông điệp ngoại lệ và việc sử dụng các bản sửa đổi lỗi thời, không chỉ đánh giá giao diện màn hình. Đào tạo cả người phê duyệt, người xử lý ngoại lệ cũng như người nhập liệu.
Xem các yêu cầu thay đổi hệ thống sau này như các trường hợp kiểm soát. Định dạng phản hồi riêng cho từng khách hàng, tính toán lại sau khi thay đổi điểm đến, hoặc chỉ phê duyệt chất lượng cho thay đổi thông số kỹ thuật có thể là quy tắc chung, ngoại lệ theo hợp đồng hoặc quyết định riêng lẻ. Phân tách các trường hợp này trước khi mã hóa cứng. Kiểm toán viên cần có khả năng xem lý do tại sao một trường hợp cụ thể lại đi theo lộ trình khác.
Khi vận hành chính thức, xác định phiên bản có thẩm quyền của từng đơn hàng đang mở, liệt kê các yêu cầu khách hàng chưa giải quyết và di chuyển các trường hợp chưa xác nhận. Việc nhập toàn bộ email lịch sử không cho biết thông điệp nào cuối cùng đã được phê duyệt. Chọn một khoảng thời gian và người chịu trách nhiệm di chuyển, và tách biệt các điều khoản đã xác nhận khỏi các đề xuất đang chờ xử lý. Xem xét hàng đợi ngoại lệ hàng ngày ngay sau khi chuyển đổi, và xác nhận các bộ phận kinh doanh, lập kế hoạch, chất lượng và CNTT đang xem cùng một bản sửa đổi.
Tính toán lợi tức đầu tư như thế nào?
Thời gian nhập liệu chỉ là một thành phần. Sản xuất sai phiên bản, mua nguyên vật liệu dư thừa, vận chuyển gấp, kiểm tra lại, phản hồi khách hàng nhiều lần và tìm kiếm kiểm toán cũng có thể quan trọng. Phân biệt thời gian xử lý thông thường với tổn thất ngoại lệ; lưu lại số lượng sự kiện, tác động và bằng chứng chi phí. Ghi chú rõ mọi ước tính lợi ích là phép tính từ dữ liệu của chính bạn, không phải kết quả đạt được bởi công ty khác.
Chức năng thay đổi hiện tại của ERP có đủ không?
Nếu một ERP có thể tiếp nhận yêu cầu, so sánh các phiên bản, đánh giá nguyên vật liệu và năng lực, phê duyệt, ghi nhận sự đồng ý của khách hàng, cập nhật MES và lưu bằng chứng, thì có thể không cần thêm một sản phẩm độc lập. Một quy trình làm việc hoặc tích hợp có thể lấp đầy các khoảng trống nhỏ hơn. Tái hiện một trường hợp thực tế trong ERP hiện tại và kiểm tra xem bạn có thể xác định chính xác phiên bản nào đã được khách hàng chấp nhận và nhà máy sản xuất hay không. Một mục trong danh sách tính năng ghi “lịch sử thay đổi” không trả lời được câu hỏi đó.
Khi nào nên sửa đổi hướng dẫn sản xuất?
Áp dụng ngày hiệu lực hoặc ranh giới lô sau khi các quyết định nội bộ và khách hàng cần thiết, nhận diện vật tư cũ/mới và xử lý bán thành phẩm (WIP) đã rõ ràng. Dừng hướng dẫn lỗi thời và xác nhận đã nhận hướng dẫn thay thế ngay cả với trường hợp khẩn cấp. Việc trao đổi tài liệu giấy trong khi MES vẫn giữ phiên bản cũ sẽ tạo ra hai nguồn thẩm quyền. Nếu công việc đã bắt đầu, hãy sử dụng quy trình ngoại lệ để quyết định rõ ràng xử lý WIP như thế nào.
Kết luận
Một hệ thống kiểm soát thay đổi đơn hàng nên lưu giữ riêng yêu cầu của khách hàng so với đơn hàng đã được chấp nhận, so sánh các phiên bản trước và phiên bản đề xuất, đánh giá tác động về vật tư, năng lực, chất lượng và thương mại, lấy ý kiến phê duyệt, và chỉ phát hành phiên bản đã được khách hàng xác nhận cho ERP, MES và logistics. Lịch sử có thể tái dựng và các trường hợp FAT/SAT bao gồm thay đổi giữa quá trình và thất bại tích hợp giúp việc thực thi tại nhà máy luôn phù hợp với cam kết thương mại.
Nếu bạn đang xây dựng quy trình tiếp nhận, phê duyệt và áp dụng ERP/MES cho một nhà máy tại Việt Nam, liên hệ TOMAS TECH. Chúng tôi có thể cùng bạn rà soát một đơn hàng hiện tại và trường hợp thay đổi thực tế khi phạm vi vẫn đang được xác định.
Nguồn tham khảo
- Microsoft Learn: Cam kết đơn hàng
- Microsoft Learn: Thông điệp hành động
- Microsoft Learn: Lập kế hoạch sản xuất
- Microsoft Learn: Lịch giao hàng
- OPC Foundation: ISA-95
- ISO: ISO 9001:2026
- ISO: ISO 10013:2021
- GS1: EPCIS 2.0.1
Quy trình làm việc, RFP, thử nghiệm và khuyến nghị đo lường là hướng dẫn triển khai của TOMAS TECH. Tài liệu của nhà cung cấp mô tả các sản phẩm được trích dẫn; không được trình bày như một đặc tả phần mềm chung.
