Hệ thống sửa và phê duyệt sản lượng thực tế cho nhà máy tại Thái Lan

Triển khai hệ thống sửa và phê duyệt sản lượng thực tế không chỉ là thêm nút Chỉnh sửa. Khi thay đổi số lượng sản xuất, hàng đạt và lỗi, giờ công, thiết bị hoặc mã lô, nhà máy cần giải thích được báo cáo gốc, lý do thay đổi, người phê duyệt và tác động đến tồn kho, chi phí. Bài viết này dành cho nhóm sản xuất, chất lượng, kho và CNTT tại Thái Lan đang thiết kế lịch sử sửa, luồng phê duyệt, hủy và ghi nhận lại, đối soát ERP cùng thử nghiệm nghiệm thu.

Phạm vi là nhà máy đã ghi nhận sản lượng thực tế nhưng vẫn xử lý các trường hợp ngoại lệ qua email, giấy, bảng tính hoặc sửa trực tiếp trong ERP. Nếu cần thiết kế cách thu thập dữ liệu từ đầu, xem hướng dẫn thu thập sản lượng tại hiện trường. Giao dịch đưa thành phẩm vào kho được trình bày tại hướng dẫn hệ thống nhập kho thành phẩm. Ở đây chúng ta tập trung vào việc xử lý khi phát hiện giá trị đã báo cáo là sai, trước hoặc sau khi đã chuyển sang hệ thống khác.

Vì sao không nên ghi đè báo cáo sản xuất ban đầu

Một bản ghi sản xuất có thể gắn với lệnh sản xuất, công đoạn, mặt hàng, số lượng, phân loại đạt/lỗi, giờ công, máy, người vận hành, lô và thời điểm. Giả sử hiện trường báo 100 sản phẩm đạt nhưng sau đó kiểm đếm chỉ có 96. Hiển thị số 96 trên màn hình rất đơn giản; việc trả lời 100 được báo khi nào, vì sao giảm bốn, ERP đã nhập kho 100 hay chưa và hệ thống khác đã đọc số cũ chưa thì khó hơn. Điều tra nguyên nhân và đối soát cuối kỳ cần cả giá trị đang có hiệu lực lẫn quá trình dẫn tới nó.

Theo tài liệu Microsoft, báo hoàn thành lệnh sản xuất đưa thành phẩm vào tồn kho, có thể ghi nhận số lượng hoàn thành từng phần và số lượng lỗi kèm lý do. Tùy cấu hình, giao dịch này có thể liên quan đến tiêu hao vật tư và thời gian, công việc kho, lệnh kiểm tra chất lượng hoặc bút toán. Tài liệu về ghi sổ sản xuất cũng phân biệt vật tư, thời gian, thành phẩm, sản phẩm dở dang và tồn kho. Đây là mô tả của một sản phẩm ERP cụ thể, không phải khẳng định mọi nhà máy hoạt động giống nhau. Nó cho thấy cần khảo sát tác động phía sau trước khi thay một con số trên màn hình.

Cách thiết kế dễ kiểm toán là giữ sự kiện gốc và thêm sự kiện sửa hoặc đảo có liên kết. Ứng dụng tính phiên bản nào đang có hiệu lực cho báo cáo và tích hợp. Giữ dữ liệu sai mà vẫn cộng vào tổng sẽ đếm trùng; xóa dữ liệu gốc sẽ không giải thích được vì sao ERP từng ghi một giao dịch. Hệ thống cần giải quyết đồng thời hai vấn đề.

Tách ba loại thời điểm

Câu “hôm nay sửa sản lượng của hôm qua” bao gồm ít nhất ba mốc: lúc công việc thực tế diễn ra, lúc lưu báo cáo gốc, và lúc yêu cầu hoặc phê duyệt sửa. Ngày dùng để tính hiệu suất ca có thể khác ngày ghi sổ kế toán. Ca đêm, thiết bị gửi dữ liệu khi trở lại trực tuyến và giờ khóa sổ ERP làm khác biệt này quan trọng. Hãy quy định múi giờ và đồng bộ đồng hồ cho thiết bị, MES và ERP. Ngày hiệu lực của sản xuất có thể thuộc quá khứ nhưng hành vi phê duyệt phải mang thời điểm thật.

Thiết kế sự kiện sửa và tính giá trị có hiệu lực

Hai định danh tối thiểu là ID bản ghi thực tế gốc và ID yêu cầu sửa. Không xóa bản gốc. Yêu cầu phải liên kết tới ID gốc, giá trị trước và sau, đơn vị, lý do, người yêu cầu và thời điểm yêu cầu. Sau khi phê duyệt, ghi người và thời điểm phê duyệt rồi mới thay giá trị có hiệu lực theo quy tắc đã định. Nếu từ chối, giá trị cũ vẫn có hiệu lực nhưng nội dung yêu cầu và lý do từ chối được giữ lại. Yêu cầu đang chờ không được âm thầm thay tổng sản lượng.

Với trường hợp 100 thành 96 sản phẩm đạt, giữ bản ghi 100 và sự kiện 100→96 đã được duyệt. MES có thể hiển thị 96 như giá trị hiện tại hoặc tính 100 cộng điều chỉnh âm bốn. Cả hai cách đều dùng được nếu định danh tích hợp và thử lại nhất quán. Thay trực tiếp 100 bằng 96 làm giao dịch ERP 100 trước đó khó giải thích.

Không nên xử lý mọi trường giống nhau. Sửa lỗi chính tả ở ghi chú có thể chỉ nằm trong MES. Sửa mã lô ảnh hưởng truy xuất nguồn gốc; sửa máy ảnh hưởng chỉ số thiết bị; sửa giờ công có thể chạm đến tính giá thành hoặc hệ thống chấm công. Chuyển số lượng từ hàng đạt sang lỗi có thể thay cả hồ sơ chất lượng và tồn kho thành phẩm. Lập ma trận tác động theo từng trường trước khi quy định tuyến duyệt và thao tác ERP.

Trạng thái rõ ràng và phát hiện xung đột phiên bản

Mô hình trạng thái đơn giản gồm Bản nháp, Đã gửi, Đã duyệt, Từ chối, Chờ ERP, Đã ghi ERP, Đã đối soát và Lỗi. Phê duyệt khác với ghi thành công vào ERP. Khi mạng lỗi, yêu cầu có thể đã duyệt nhưng ERP chưa đổi; hàng chờ này phải được nhìn thấy. Việc hủy hay gửi lại nên là sự kiện liên kết chứ không xóa yêu cầu cũ.

Khi duyệt, so phiên bản mà người gửi đã xem với phiên bản hiện đang có hiệu lực. Nếu hai yêu cầu đều bắt đầu từ 100, một đề nghị 96 và một đề nghị 98, duyệt cả hai mà không kiểm tra sẽ khiến quyết định đầu biến mất. Hãy chặn việc duyệt trên phiên bản cũ và yêu cầu đánh giá lại. Nếu kiểm đếm thêm ra 95, tạo yêu cầu 96→95; đừng ghi đè lịch sử 100→96.

Luồng phê duyệt phải tương xứng với tác động

Mục tiêu phê duyệt là kiểm tra thay đổi có hệ quả, không phải gửi mọi lỗi chính tả tới giám đốc nhà máy. Sửa số lượng chưa gửi ERP, đổi hàng đạt thành hàng lỗi, đổi lô, giảm số lượng sau nhập kho và điều chỉnh sau khóa kỳ cần cách xem xét khác nhau. Ngưỡng số lượng hoặc tiền phải dựa trên giá trị hàng, yêu cầu chất lượng và ma trận trách nhiệm của nhà máy, không nên sao chép một ngưỡng chung.

Màn hình duyệt nên hiển thị cùng lúc giá trị gốc, giá trị đề nghị, chênh lệch, lý do, chứng cứ, hệ thống bị ảnh hưởng và trạng thái ERP. Nếu có ngoại lệ cho phép cùng một người gửi và duyệt, phải ghi ngoại lệ và căn cứ ủy quyền. Quy định người duyệt thay trong ca đêm hoặc khi vắng mặt, gồm người ủy quyền, thời hạn và lý do. Trọng tâm ở đây là truy nguyên được quyết định đối với từng yêu cầu sửa.

Mã lý do cần phản ánh nguyên nhân thực: nhập sai, ghi trùng, sai lệch bộ đếm máy, kết quả kiểm tra đến muộn, nhầm lô hoặc xử lý lại lỗi tích hợp ERP. Đừng bắt viết quá dài khiến nhân viên né hệ thống. Mã lý do, giải thích ngắn và tệp đính kèm khi cần thường dễ vận hành hơn. Nếu nguyên nhân chưa rõ, cho gửi dưới trạng thái “đang điều tra” và bổ sung chứng cứ trước khi duyệt.

Trình tự thông thường là gửi yêu cầu, kiểm tra tác động, phê duyệt, đổi giá trị hiệu lực của MES, rồi xử lý ERP. Biện pháp cách ly vì an toàn hay chất lượng có thể phải thực hiện trước; hãy ghi nó như hành động tạm thời tách khỏi việc sửa số lượng chính thức. Nếu gửi ERP trước khi duyệt, phải quy định cách đảo khi yêu cầu bị từ chối.

Quy định cách hủy, điều chỉnh và ghi lại trong ERP

Cơ chế sửa ERP tùy sản phẩm, cấu hình và trạng thái giao dịch. Gửi lại một giá trị MES mới có thể bị hiểu là giao dịch sản xuất bổ sung. Cần thống nhất ERP có thể hủy đúng giao dịch nguồn, chấp nhận chênh lệch hay phải hủy rồi ghi lại. Kiểm tra ảnh hưởng đến tồn kho, dở dang, chi phí, công việc kho và hồ sơ chất lượng.

Microsoft mô tả việc đảo trạng thái lệnh sản xuất sẽ đưa lệnh và công đoạn về bước trước trong vòng đời. Đảo từ Reported as finished có thể cần tính toán hay lập lịch lại; đảo từ Started về Released ảnh hưởng thành phẩm đã báo, thời gian và thông tin khác. Đảo toàn bộ trạng thái lệnh không đồng nghĩa sửa một bản ghi thực tế riêng lẻ. Không nên làm nút Undo chung khi chưa xác nhận hành vi ERP thực tế.

Tài liệu SAP về hủy xác nhận sản xuất yêu cầu xác định xác nhận cần hủy, đặc biệt khi một công đoạn có nhiều xác nhận. Một số chức năng được kích hoạt bởi xác nhận cũng có thể không tự đảo khi hủy. Vì vậy RFP nên yêu cầu giữ định danh xác nhận gốc, ghép cặp hủy và ghi lại, rồi kiểm tra riêng các tác động phía sau. Ví dụ của các nhà cung cấp không thay thế việc thử trên hệ thống và cấu hình thực tế.

ID yêu cầu ổn định và phản hồi không chắc chắn

Yêu cầu từ MES nên có nhà máy, lệnh, công đoạn, ID bản ghi gốc, ID sửa, loại thao tác và mã yêu cầu ổn định. Phân biệt Tạo mới, Hủy, Điều chỉnh và Ghi lại. Lần thử lại dùng cùng ID để ERP nhận biết yêu cầu trùng nếu hỗ trợ. Hết thời gian chờ không chứng minh ERP chưa ghi; hãy tra giao dịch đích trước khi gửi lại. Lưu số giao dịch, chứng từ ERP, thời gian và trạng thái cuối trong MES.

Nếu hủy thành công nhưng ghi lại thất bại, phải hiển thị trạng thái trung gian. Phát lại mù quáng cả hai bước có thể hủy hai lần. Đối soát phải so mặt hàng, lô, đơn vị và số lượng đã được ERP xác nhận, không chỉ kiểm tra thông báo API thành công. Nếu thành phẩm đã được phân bổ hoặc giao đi, điều chỉnh âm có thể bị từ chối; chuyển ngoại lệ cho người phụ trách kho hoặc tồn kho.

Với kỳ kế toán đã khóa, giữ ngày sản xuất thực tế nhưng thống nhất ngày hạch toán và cách xử lý chênh lệch với tài chính, kho và sản xuất. Sửa số MES của tháng trước không tự thay bút toán ERP tháng trước. Ghi phương án đã duyệt vào yêu cầu. Phần mềm thực thi quy định của doanh nghiệp chứ không tự đưa ra quyết định kế toán.

Đối soát MES và ERP đúng cấp độ

Hàng chờ ngoại lệ cần phân biệt Đã gửi yêu cầu, Đã duyệt chưa chuyển, Đã chuyển, ERP xử lý, Đã đối soát và Lỗi. Khoảng cách tăng giữa số MES đã duyệt và số ERP xác nhận làm số liệu sản xuất, tồn kho hoặc giá thành lệch nhau. Kiểm tra mỗi ngày thay vì chờ cuối ca hay cuối tháng.

Chỉ dùng mã lệnh sản xuất thường quá thô. Một lệnh có thể gồm nhiều công đoạn, ngày, lô và báo cáo. Hãy đối chiếu theo ID bản ghi gốc và ID sửa nếu có thể. Nếu ERP chỉ giữ tổng gộp, cần bảng ánh xạ giữa sự kiện chi tiết MES và giao dịch gộp ERP. Đừng gắn nhãn “đã đối soát” ở mức chi tiết mà hệ thống đích không thể xác minh.

Nhật ký kiểm toán cần ghi gì

Nhật ký nên sắp theo chuỗi: tạo bản gốc, gửi yêu cầu sửa, thêm chứng cứ, duyệt hoặc từ chối, gửi ERP, nhận phản hồi, thử lại thủ công và hoàn tất đối soát. Mỗi sự kiện ghi người thực hiện, thời gian, ID đối tượng, trước và sau, lý do và giao dịch ERP liên kết. Tác vụ tự động cần ID dịch vụ và ID công việc. Nếu quản trị viên sửa bản ghi và xóa nhật ký cùng lúc, chứng cứ yếu đi. Cân nhắc thời hạn lưu, quyền xuất, phát hiện thay đổi và sao lưu theo quy định doanh nghiệp.

Một ghi chú lý do không chứng minh quy trình duyệt đúng. Người kiểm toán có thể cần biết phiên bản quy tắc áp dụng lúc đó, người gửi và duyệt có độc lập không, người được ủy quyền đã làm theo căn cứ nào, chứng cứ còn không và đối soát ERP xong chưa. Giữ phiên bản quy tắc cũ thay vì áp quy tắc mới ngược lên sự kiện lịch sử. Tệp xuất nên có điều kiện chọn, thời điểm xuất, giá trị hiệu lực và toàn bộ chuỗi sự kiện liên kết.

Các yêu cầu nên viết trong RFP

Thay câu chung chung “có lịch sử sửa” bằng tình huống và tiêu chí nghiệm thu: nhập sai, đổi đạt sang lỗi, đổi lô, giảm số lượng sau báo hoàn thành, ERP hết thời gian chờ, người duyệt vắng mặt, hai yêu cầu đồng thời và sửa sau khóa kỳ. Với mỗi trường hợp, xác định ai được gửi, kiểm tra, duyệt; người duyệt thấy gì; ERP thực hiện giao dịch nào; và chứng minh hoàn tất ra sao.

Yêu cầu chức năng gồm liên kết ID gốc và sửa, hiển thị trước sau, lý do và tệp, tuyến duyệt, tách vai trò, phát hiện xung đột phiên bản, định danh hủy/điều chỉnh, tra phản hồi ERP, thử lại an toàn và xuất nhật ký. Yêu cầu phi chức năng gồm thứ tự thông điệp khi thiết bị ngoại tuyến, đồng bộ giờ, chống gửi trùng, rà soát quyền, lưu trữ và sao lưu, hướng dẫn phục hồi. Đặt mục tiêu hiệu năng theo khối lượng sửa thực tế và khả năng ERP thay vì một con số tùy ý.

Nếu ứng dụng workflow riêng chỉ giữ khâu duyệt, nó vẫn phải liên kết bền vững với giá trị hiệu lực MES và giao dịch ERP. Yêu cầu nhà cung cấp đưa mô hình sự kiện, định danh API, sơ đồ trạng thái lỗi và mẫu xuất kiểm toán bên cạnh bản demo màn hình. Trong báo giá, tách chức năng chuẩn, tùy chỉnh, cấu hình ERP, môi trường thử nghiệm và chuyển đổi dữ liệu. Với dữ liệu cũ không có lịch sử đáng tin, đánh dấu giá trị hiệu lực tại thời điểm chuyển đổi và nêu rõ lịch sử trước đó không có, thay vì tự dựng lại.

Triển khai theo giai đoạn

Một cách là chuẩn hóa yêu cầu sửa số lượng, phê duyệt và lịch sử trong MES trước; kết nối hủy hoặc điều chỉnh ERP sau; cuối cùng mở rộng sang ngoại lệ chất lượng, kho và chi phí. Tuy nhiên, nếu MES hiện đã tự chuyển sang ERP thì giai đoạn đầu vẫn phải phân biệt báo cáo chưa chuyển và đã chuyển. Vẽ luồng giao dịch hiện tại trước khi chọn thứ tự. Giữ ID ERP của các giao dịch cũ chưa hoàn tất đối soát khi chuyển đổi.

Kiểm tra nghiệm thu bằng PoC, FAT và SAT

Biểu mẫu chạy được chưa chứng minh một vụ sửa đã hoàn tất. Trong PoC, chọn một lệnh và công đoạn, đi từ báo sai qua yêu cầu, phê duyệt, đổi giá trị hiệu lực MES, hủy hoặc điều chỉnh ERP, ghi lại nếu cần rồi đối soát. FAT kiểm tra cấu hình và nhánh ngoại lệ ở môi trường nhà cung cấp. SAT lặp lại với thiết bị, mạng, ERP và ca vận hành thực. Lưu rõ mỗi môi trường đã chứng minh điều gì.

Thử trường hợp ERP đã ghi nhưng phản hồi bị mất. Xác nhận việc tra giao dịch trước khi thử lại, phát hiện trùng, hiển thị cho người vận hành và chuyển cấp xử lý. Cuối SAT, sản xuất, chất lượng, kho và tài chính phải theo được từ 100 gốc tới 96 có hiệu lực và các giao dịch ERP liên quan qua một mã vụ việc. Nếu còn đối soát thủ công, ghi người chịu trách nhiệm và bằng chứng đóng vụ.

Sau khi vận hành, đừng chỉ đếm số yêu cầu sửa. Theo dõi thời gian từ gửi tới duyệt, từ duyệt tới đối soát, vụ tồn lâu, số lần chặn trùng và mã lý do lặp lại. Số yêu cầu có thể tăng lúc đầu vì công việc trước đây không được ghi nay đi vào quy trình. Nếu cùng một máy hoặc ca cứ báo sai, kiểm tra đơn vị trên thiết bị, máy quét, bộ đếm, hướng dẫn làm việc hoặc kết quả kiểm tra đến muộn. Nếu duyệt chậm, xem lại lịch người duyệt; nếu ERP lỗi nhiều, kiểm tra dữ liệu chủ và quy tắc giao tiếp.

Câu hỏi thường gặp

Chỉ cần lịch sử thay đổi của một dòng dữ liệu có đủ không?

Thường là chưa. Cần nối lịch sử đó với yêu cầu, quyết định duyệt, hủy hoặc ghi lại trong ERP và đối soát. ID sửa là cầu nối bản ghi gốc với giao dịch ERP.

Mọi sửa đổi MES đều cần quản lý duyệt không?

Tuyến duyệt phụ thuộc trường dữ liệu, tác động tồn kho và chất lượng, và tình trạng khóa kỳ. Ngay cả sửa nhỏ được phép không qua phê duyệt vẫn cần ghi người thực hiện và lý do.

Có thể ghi đè sản lượng đã vào ERP không?

Tùy sản phẩm, cấu hình và trạng thái giao dịch. Tài liệu các nhà cung cấp mô tả hủy xác nhận hoặc đảo trạng thái lệnh với phạm vi và hậu quả khác nhau. Kiểm tra cơ chế trên hệ thống đang dùng và thử tác động tồn kho, giá thành.

Có audit log rồi còn cần đối soát không?

Vẫn cần. Nhật ký chứng minh MES đã yêu cầu, duyệt và gửi gì. Đối soát chứng minh ERP thực sự chấp nhận số lượng, lô, ngày hạch toán và số giao dịch nào. Hết thời gian chờ hay lỗi một phần không thể kết luận chỉ từ nhật ký gửi.

Kết luận

Hệ thống sửa và duyệt sản lượng thực tế nên theo dõi một vụ từ báo cáo gốc, yêu cầu, quyết định, thao tác ERP đến đối soát. Giữ số cũ, ghi trước sau, lý do và người duyệt; tách duyệt khỏi ghi sổ; thử gửi trùng, lỗi giữa chừng, kỳ khóa và yêu cầu xung đột. Như vậy thay đổi ngoại lệ có thể được giải thích với hiện trường và bộ phận chịu trách nhiệm tồn kho, chi phí.

Nếu nhà máy tại Thái Lan của bạn đang lập bản đồ cách sửa sản lượng đi qua biểu mẫu, con người, MES và ERP, hãy liên hệ TOMAS TECH. Bắt đầu bằng sơ đồ từ báo cáo gốc, phê duyệt đến ảnh hưởng tồn kho và chi phí sẽ giúp xác định phạm vi trước khi chọn giải pháp.

Nguồn tham khảo

• Microsoft Learn: Report production orders as finished
• Microsoft Learn: Reverse the production order status
• Microsoft Learn: Production posting
• Microsoft Learn: Production feedback
• Microsoft Learn: Configure the production floor execution interface
• SAP Help Portal: Canceling Confirmations