Hệ thống kiểm soát thay đổi lệnh sản xuất: RFP và nghiệm thu

Khi doanh nghiệp sản xuất triển khai hệ thống kiểm soát thay đổi lệnh sản xuất, câu hỏi khó không chỉ là “có sửa được một trường dữ liệu không”. Sau khi lệnh đã phát xuống xưởng, ai đánh giá tác động của việc đổi số lượng, hạn giao, BOM hay quy trình; phiên bản nào được phê duyệt; làm sao vô hiệu hướng dẫn cũ; và làm sao khớp sản phẩm dở dang, số liệu thực tế với ERP? Bài viết chuyển toàn bộ chuỗi đó thành yêu cầu mua sắm và tiêu chí kiểm thử. Khả năng sửa lệnh đã phát hành khác nhau theo phần mềm, vì vậy doanh nghiệp cần xác định quy tắc vận hành trước khi chọn giao diện.

Vì sao thay đổi sau phát hành khác sửa kế hoạch?

Ở giai đoạn lập kế hoạch, người lập lịch có thể sửa số lượng hoặc công đoạn rồi tính lại trước khi đưa xuống xưởng. Sau phát hành, công nhân có thể đã thấy lệnh, phiếu công việc đã in, vật tư đã đặt giữ hoặc xuất, và dữ liệu bắt đầu hay hoàn thành đã được ghi nhận. Tài liệu Microsoft mô tả Released là trạng thái lệnh có thể được thực hiện tại xưởng và trong quy trình kho.Microsoft: Release production orders Do đó, thay đổi lệnh phải xử lý cả chỉ dẫn đã truyền đi, vật tư đã di chuyển và lịch sử đã ghi.

Phạm vi ở đây là một lệnh sản xuất cụ thể sau khi phát hành. Quy trình duyệt thay đổi thiết kế và đồng bộ BOM gốc được bàn trong bài về tích hợp PLM và ERP. Việc xuất vật tư thực tế nằm ở bài về kiểm soát cấp phát vật tư. Mã thay đổi thiết kế trả lời “cần chế tạo cái gì”; mã thay đổi lệnh trả lời “từ điểm nào và theo cách nào lệnh đang chạy này sẽ được thực hiện”.

Xác định trạng thái nào được đổi nội dung nào

Phụ lục đầu tiên của RFP nên là bảng trạng thái lệnh, trường được sửa và biện pháp kiểm soát. Lệnh dự kiến, đã xếp lịch, đã phát hành, đã bắt đầu, hoàn thành một phần, hoàn thành và đã đóng có tác động khác nhau. Câu “cho sửa sau phát hành” không xác định liệu công đoạn đã chạy hay lô vật tư đã xuất có thể bị ghi đè hay không. Tính năng thay vật tư BOM sát giờ của Microsoft giới hạn lệnh áp dụng ở trạng thái Estimated hoặc Scheduled. Trong khi đó, tài liệu SAP Business ByDesign nêu một số thay đổi về lượng và ngày sau khi phát hành hoặc bắt đầu. Đây là hành vi theo từng sản phẩm, không phải quy tắc chung cho mọi MES/ERP.Microsoft: Last-minute changes SAP: Production Orders Quick Guide

Đây là chính sách mẫu cho bên mua, không khẳng định chức năng mặc định của mọi phần mềm. Nếu cho phép ngoại lệ, phải xác định người có quyền, căn cứ và phạm vi. Việc sửa số liệu thực tế đã ghi là quy trình riêng như trong bài về sửa và duyệt sản lượng thực tế. Không gộp thay phiên bản lệnh và sửa lịch sử sản xuất vào một thao tác.

Biến yêu cầu thay đổi thành dữ liệu có thể đánh giá

Yêu cầu cần có mã lệnh và phiên bản hiện tại, mã hàng, lô, dây chuyền, công đoạn, loại thay đổi, giá trị cũ/mới, điểm dự kiến có hiệu lực, lý do và tham chiếu yêu cầu khách hàng hoặc thay đổi thiết kế. Có thể giữ ô diễn giải tự do, nhưng thay đổi số lượng, hạn giao, vật tư/BOM và quy trình/thiết bị phải là trường có cấu trúc để hệ thống lựa chọn bước đánh giá và người duyệt. Gán mã thay đổi duy nhất, liên kết cả mã lệnh lẫn phiên bản. Chép một phê duyệt từ email vào hệ thống sau đó khó chứng minh người duyệt đã thấy chính xác các giá trị trước và sau nào.

Với số lượng, phân biệt tổng lượng lệnh, thành phẩm tốt đã hoàn thành, phế phẩm, WIP và lượng chưa bắt đầu. Giả sử lệnh 100 chiếc, 40 chiếc đã hoàn thành, 10 chiếc đang gia công và tổng mới là 80 chiếc. Chỉ đổi phần chưa hoàn thành từ 60 xuống 40 vẫn bỏ ngỏ cách xử lý 10 chiếc WIP. Các con số này là giả định minh họa, không phải quy tắc phân bổ tiêu chuẩn. Trước khi duyệt, xác định lô và công đoạn bị giảm, WIP sẽ hoàn thiện, cách ly hay loại bỏ.

Với ngày, tách cam kết khách hàng, ngày hoàn tất lệnh theo kế hoạch, thời gian từng công đoạn và ngày vật tư về. Sửa một ngày không tự làm khớp công suất và nguồn cung. Microsoft giải thích rằng thay đổi thủ công đối với planned order có thể chưa phản ánh vào phần còn lại của kế hoạch cho đến lần chạy hoạch định tiếp theo; chậm trễ vật tư cũng có thể lan qua các cấp BOM. RFP cần quy định khi nào tính lại và cách hiển thị kết quả.Microsoft: Production planning

Với vật tư, tách sửa phiên bản engineering BOM khỏi dùng vật tư thay thế cho riêng lệnh. Trường hợp đầu cần phê duyệt PLM/ERP ở thượng nguồn; trường hợp sau vẫn có thể cần QA và truy vết lô. Với quy trình, ghi rõ thứ tự, máy, đồ gá, điểm kiểm tra, thời gian chuẩn và hướng dẫn thao tác thay đổi ra sao. Phát một PDF mới trong khi màn hình vẫn buộc theo thứ tự cũ sẽ tạo hai chỉ dẫn mâu thuẫn.

Đánh giá tác động phải chỉ ra công việc cụ thể bị ảnh hưởng

Màn hình tác động cần nhiều hơn tín hiệu xanh/đỏ. Kế hoạch, mua hàng, kho, sản xuất, chất lượng, vận chuyển và tính giá phải xem hậu quả theo cùng một mã thay đổi. ISA-95 là khung mô tả trao đổi thông tin giữa hoạch định doanh nghiệp và quản lý vận hành sản xuất. Từ ranh giới đó, bài viết đề xuất lập ma trận nguồn dữ liệu chuẩn theo từng trường giữa ERP và MES; ISA-95 không bắt buộc một luồng phê duyệt cụ thể.ISA: ISA-95 Standard

Giữ ảnh chụp dữ liệu lúc đánh giá. Nếu tồn kho, WIP hoặc máy thay đổi giữa lúc nộp và duyệt, phải đánh giá lại. “Có vật tư khi nộp” không đồng nghĩa “có khi duyệt”. Ngưỡng chênh lệch lượng, tỷ lệ phần còn lại hoặc độ lệch thời gian phải dựa vào sản phẩm của nhà máy; bài viết không đưa một tỷ lệ chung thiếu căn cứ.

Kết hợp tuyến duyệt với điểm có hiệu lực ngoài xưởng

Chỉ dựa vào lý do thay đổi để chọn người duyệt là chưa đủ. Cần xét trường được sửa, trạng thái lệnh, tác động giá trị/số lượng, yêu cầu duyệt của khách, rủi ro chất lượng và truy vết lô. Một mô hình khả thi là kế hoạch kiểm ngày và công suất, kho kiểm vật tư, sản xuất kiểm áp dụng ngoài xưởng, QA kiểm thông số và phép thử, còn người phụ trách khách hàng xác nhận cam kết khi cần. Đây là ví dụ thiết kế vận hành, không phải sơ đồ thẩm quyền bắt buộc.

Màn hình duyệt phải cố định giá trị cũ/mới, lô và số lượng mục tiêu, cùng quy tắc có hiệu lực. Chọn mốc đối chiếu được với hiện vật: từ công đoạn chưa bắt đầu kế tiếp, từ số serial tiếp theo, từ lô chỉ định hoặc sau khi cách ly WIP hiện tại. Ghi thời điểm duyệt tách với thời điểm công nhân xác nhận đã nhận. Nếu thiết bị chưa đồng bộ, trạng thái phải là “đang áp dụng” dù đã duyệt, để tránh hai phiên bản cùng được dùng mà không ai thấy.

Vô hiệu chứ không xóa phiên bản cũ. Giữ mã phiên bản, người duyệt, thời gian, lý do, mốc có hiệu lực và thời điểm hết hiệu lực của bản cũ. Tài liệu Oracle cho biết audit trail khi được bật có thể ghi giá trị trước/sau, thời gian và người sửa. Cần kiểm tra trên sản phẩm được chọn xem những trường và sự kiện nào thực sự được ghi.Oracle: Using Manufacturing

Triển khai xuống xưởng phải vô hiệu mọi chỉ dẫn cũ

Hiển thị bản mới trên một máy tính bảng không loại bỏ phiếu in, bộ nhớ đệm ngoại tuyến, thiết lập đã gửi cho máy hoặc phiếu lấy vật tư ở kho. Với từng điểm nhận, RFP phải quy định dừng bản cũ, xác nhận bản mới, phát hiện máy chưa cập nhật và điều kiện chạy lại. Tài liệu SAP ME mô tả một luồng riêng của sản phẩm này: khi cập nhật shop order đã phát hành, hệ thống đặt shop order và các SFC đang hoạt động vào trạng thái hold rồi báo cho người vận hành. Đây là ví dụ hữu ích để thử cách khống chế công việc khi thay đổi, không phải bằng chứng mọi hệ thống đều hoạt động như vậy.SAP: Update of Released Production Order

Hiện khác biệt giữa hai phiên bản thật ngắn gọn cho công nhân và lưu xác nhận theo lệnh, lô, công đoạn. Màn hình mở từ trước khi cập nhật không được nhận số liệu sản xuất thực tế của bản cũ sau mốc có hiệu lực. Nếu còn giấy, chỉ định người thu phiếu cũ, cách cô lập nếu thất lạc và dấu hiệu nhận ra phiếu in lại. QR code nên kiểm tra phiên bản hiện hành trên máy chủ thay vì chỉ hiện nội dung cũ gắn sẵn trong mã.

Thay quy trình có thể tác động recipe của thiết bị hoặc kế hoạch kiểm. Việc ghi đè tham số máy từ xa cần đánh giá thiết bị và an toàn riêng. Có thể giao hệ thống thay đổi nhiệm vụ duyệt, phân phối và xác nhận, còn sửa tham số máy tự động qua quy trình được kiểm soát khác. Với WIP thực tế, phải xác định vị trí của sản phẩm trước khi coi cập nhật dữ liệu là hoàn tất.

Đối soát ERP, MES và số liệu sản xuất thực tế theo phiên bản

Một cách phân quyền là ERP làm nguồn chuẩn cho thông tin đầu lệnh và lượng kế hoạch, MES làm nguồn chuẩn cho thực hiện công đoạn và số liệu sản xuất thực tế. Kiến trúc hiện có có thể khác. Lập bảng trách nhiệm theo từng trường. Đưa mã lệnh, phiên bản và mã thay đổi vào thông điệp tích hợp để bên nhận phân biệt bản đã áp dụng, bản cũ và bản trung gian bị thiếu. Nhận lại cùng mã thay đổi không được áp dụng lần hai; lỗi phải có nguyên nhân và cách gửi lại có kiểm soát. ISA-95 Part 5 đề cập giao dịch giữa hệ thống kinh doanh và sản xuất; khóa chống áp dụng trùng và quy tắc gửi lại ở đây là yêu cầu triển khai được đề xuất tại ranh giới đó.ISA: Part 5

Gắn số liệu sản xuất thực tế trước và sau thay đổi với đúng phiên bản. Không trình bày sản phẩm bản cũ như thể đã dùng BOM mới. Sau khi đổi số lượng, đối chiếu tổng lượng, hàng tốt, hàng lỗi, WIP và phần chưa bắt đầu. Với vật tư, giữ sự kiện đặt giữ, xuất, trả và tiêu hao; đưa chênh lệch cho người phụ trách thay vì âm thầm bù trừ. Bước chuyển sang thành phẩm được trình bày trong bài về hệ thống nhập kho thành phẩm.

Xưởng có thể đang dùng bản mới còn ERP vẫn là bản cũ, hoặc ngược lại. Hãy hiển thị riêng “đã duyệt”, “đã gửi MES”, “thiết bị đã xác nhận”, “ERP đã cập nhật” và “đã đối soát”, thay vì gộp thành một trạng thái cuối. Tác vụ đối soát cần liệt kê chênh lệch, xác định có được gửi lại không và lưu lý do sửa thủ công. Có dừng sản xuất hay không tùy rủi ro vật tư, quy trình và chất lượng.

Thu thập ca thay đổi thực tế và định nghĩa dữ liệu trước khi mua

Trước khi viết đặc tả, chọn vài ca thay đổi gần đây rồi dựng lại dòng thời gian từ lúc yêu cầu đến lúc áp dụng ngoài xưởng. Ghi phiên bản lệnh người yêu cầu thấy, ca nào nhận chỉ dẫn miệng, lô vật tư thực dùng, lúc thu phiếu in, người sửa ERP và lúc khóa số liệu sản xuất thực tế. Qua đó phân biệt chậm do duyệt hay do phân phối sau duyệt. Nên có ca sau khi xuất vật tư, ca đêm, sau hoàn thành một phần và khi mất mạng. Đối chiếu phiếu thật với bản ghi hệ thống quan trọng hơn thu thật nhiều ví dụ nông.

“Số lượng” có thể là lượng đơn bán, lượng lệnh sản xuất, lượng đưa vào công đoạn, sản lượng tốt hoặc lượng nhập kho; mỗi giá trị có chủ sở hữu khác. Từ điển trường dữ liệu cần tên, đơn vị, hệ thống chuẩn, người sửa, trạng thái lệnh được sửa, tham chiếu, thời hạn lưu và nơi nhận. Tương tự, phân biệt engineering BOM, manufacturing BOM và dòng cấu phần đã triển khai vào một lệnh. Nếu hệ thống dùng mã phiên bản khác nhau, lập bảng ánh xạ phiên bản lệnh với phiên bản BOM thay vì ép thành một chuỗi. Nếu không, phê duyệt có thể nhắm lệnh bản A nhưng máy tính bảng chỉ nhận BOM bản B.

Sự kiện tích hợp tối thiểu cần mã lệnh, phiên bản lệnh, mã thay đổi, công đoạn hoặc lô bị tác động, quy tắc hiệu lực, thời gian và hệ thống gửi. Dự kiến thiết bị gửi lại hoặc ERP truyền lại để bên nhận nhận ra bản trùng. Tách thời gian hiển thị cho con người khỏi thời gian lưu để tích hợp. Nhà máy Thái Lan nối với ERP của trụ sở ở nước ngoài có thể đọc sai thứ tự duyệt và áp dụng nếu chỉ nhìn giờ hiển thị. Không dựa riêng vào thời gian để xếp thứ tự; dùng cả phiên bản và ID sự kiện.

Kiểm tra dữ liệu lịch sử bị thiếu từ đầu. Phiếu cũ không có phiên bản, số lô viết tay hoặc số liệu sản xuất thực tế nhập cuối ngày không thể được phần mềm mới tái dựng hoàn hảo. Xác định ranh giới bằng chứng trước/sau chuyển đổi, rồi thống nhất phiên bản gắn với WIP tại thời điểm chuyển đổi cùng sản xuất, QA và tài chính. Mức chứng cứ cần thiết phụ thuộc yêu cầu chất lượng và hợp đồng.

Đầu ra khảo sát hữu ích gồm sổ các ca thay đổi, từ điển trường, ma trận chủ sở hữu dữ liệu giữa hệ thống và danh sách ngoại lệ. Dùng ca thay đổi cho FAT, từ điển để soát API, ma trận để xử lý sự cố và ngoại lệ cho SAT. Đánh dấu quyết định còn mở ngay trong RFP thay vì để mỗi nhà cung cấp báo giá trên một giả định ngầm khác nhau.

Quản lý thay đổi khẩn cấp và hủy trong cùng quy trình kiểm soát

Máy hỏng hoặc nghi ngờ lọt sản phẩm lỗi có thể đòi hỏi hành động trước khi phê duyệt thông thường hoàn tất. Điều đó không có nghĩa “ai cũng được ghi đè ngay”. Hãy xác định người có quyền dừng, người ghi biện pháp tạm, thời hạn duyệt bổ sung, nhu cầu báo khách và người cho phép chạy lại. Cách hai bước khả thi là dừng và cách ly nhanh, sau đó rà tác động rồi phê duyệt thay đổi dài hạn thành phiên bản mới. Duyệt bổ sung hoàn thiện hồ sơ, không biến một thay đổi chưa duyệt thành thay đổi được duyệt từ trước.

Hủy sau phê duyệt cũng không đơn thuần là bật lại màn hình phiên bản cũ. Có thể đã sản xuất lô và xuất vật tư theo bản mới. Ghi yêu cầu hủy với mã thay đổi mới, kiểm tra WIP, thành phẩm, vật tư và kết quả kiểm tra hiện tại, rồi phát hành một phiên bản hiệu lực tiếp theo. Thử hủy trước khi phân phối, khi mới vài thiết bị nhận, và khi một số lô đã làm theo chỉ dẫn mới. Ở mỗi giai đoạn phải rõ cần dừng gì, giữ lịch sử nào và duyệt lại việc gì. Điều tra chất lượng sau này cần truy được chỉ dẫn nào áp dụng từ lô nào.

Viết RFP thành câu có thể kiểm chứng

Yêu cầu “có quản lý thay đổi” có thể được đáp ứng bằng một nút bấm. Hãy mô tả điều kiện nghiệp vụ, kết quả mong đợi, bằng chứng và cách xử lý lỗi. Những dòng dưới đây là mẫu yêu cầu của bên mua, cần điều chỉnh theo sản phẩm, dây chuyền và ma trận thẩm quyền.

Yêu cầu nhà cung cấp phân loại từng dòng: chức năng chuẩn, cấu hình, phát triển thêm, bên thứ ba hoặc không hỗ trợ. Khả năng trên màn hình và qua API có thể khác nhau. Nêu rõ giả định giá về giấy phép, thời gian lưu log, ứng dụng di động ngoại tuyến và chỉnh ERP. So sánh phương pháp triển khai và phạm vi phải dừng dây chuyền cùng với giá.

FAT: kiểm thử cả luồng lỗi

Trong Factory Acceptance Test, kết hợp trạng thái lệnh và loại thay đổi ở môi trường có đường truyền thiết bị, kho và ERP gần với thực tế. Có thể dùng mã hàng và lô giả, nhưng phải lưu bằng chứng ở log, số dư, thông điệp tích hợp và việc hệ thống từ chối bản cũ.

1. Tăng lượng trước khi bắt đầu: tính lại vật tư và công suất; trước duyệt xưởng vẫn thấy bản cũ; sau duyệt chuyển bản mới.
2. Giảm lượng khi đang chạy: tách lượng hoàn thành, WIP, lượng chưa làm và xác định lô chịu tác động.
3. Đẩy hạn giao sớm: cảnh báo máy hoặc vật tư thiếu, hiện phương án và phản hồi cho khách.
4. Thay vật tư: không trộn vật tư cũ đã xuất với vật tư mới; truy được lô thực sự tiêu thụ.
5. Thay quy trình: không ghi đè lịch sử công đoạn đã chạy; áp dụng bản mới từ mốc quy định.
6. Hai yêu cầu đồng thời: phát hiện xung đột trên cùng lệnh và phiên bản, buộc đánh giá lại yêu cầu đến sau.
7. Mất kết nối và gửi lại: không chấp nhận chỉ dẫn lỗi thời; sau phục hồi chỉ áp dụng một lần.
8. Quyền và hủy: người thiếu quyền không duyệt được; hủy sau duyệt thành sự kiện lịch sử riêng.

Đặt ngưỡng số theo khối lượng và mạng của nhà máy. Thay vì tự tạo mục tiêu “mọi thiết bị nhận trong X giây”, hãy ghi số điểm nhận, thời gian mất mạng cho phép và công đoạn phải dừng rồi đo. Tài liệu hướng dẫn kiểm toán ISO/TC 176 nói về rà soát và kiểm soát thay đổi trong cung cấp sản phẩm, dịch vụ; tài liệu không quy định màn hình hay thời gian phản hồi.ISO/TC 176 Auditing Practices Group

SAT phải thử điều kiện thực của nhà máy

Trong Site Acceptance Test, lặp lại kịch bản chính với thiết bị, máy tính bảng, quyền người dùng và đường truyền thực. Quan sát việc thu hồi, vô hiệu phiếu giấy. Kiểm tra quyền nhân viên mới và quản lý, bàn giao ca, khôi phục sau mất mạng. Ở xưởng nhiều ngôn ngữ, công nhân cần xác nhận lý do thay đổi, trạng thái duyệt và điểm hiệu lực trên giao diện dịch được hiểu đồng nhất.

Bằng chứng nghiệm thu phải truy được số liệu sản xuất thực tế, xuất, trả vật tư và nhập thành phẩm sau thay đổi thuộc phiên bản nào. Nếu trường hợp lỗi làm hệ thống dừng, nhân viên cần quy trình chờ an toàn và biết ai có quyền mở. Không nên đóng mọi ngoại lệ với câu “xử lý bằng quy trình” mà thiếu thủ tục tạm, người phụ trách, hạn khắc phục và điều kiện thử lại.

Trình tự triển khai và yếu tố chi phí

Đầu tiên tập hợp phiếu thay đổi và log gần đây, phân loại theo dạng thay đổi, trạng thái lệnh, bộ phận chịu tác động, thời gian chờ và việc làm lại. Tạo mô hình tối thiểu cho năm phần: nguồn dữ liệu chuẩn, phiên bản, phê duyệt, triển khai xưởng và đối soát. Thử một sản phẩm và một dây chuyền rồi mở rộng sang thay quy trình, vật tư thay thế, công đoạn thuê ngoài theo rủi ro quan sát được. Đây là cách triển khai theo giai đoạn để tham khảo; sản phẩm rủi ro cao có thể cần kiểm soát rộng từ đầu.

Chi phí không chỉ là màn hình yêu cầu và duyệt. Kiểm tra khác biệt trường ERP/MES, cách dùng phiếu giấy, thiết bị ngoại tuyến, truy lô, lưu audit và tích hợp máy hoặc hệ thống kiểm. API không mang phiên bản hay mã thay đổi vẫn có thể cần phát triển thêm. Nếu ERP giới hạn sửa sau phát hành, tách lệnh hoặc tạo lệnh cho phần còn lại có thể phù hợp hơn ép ghi đè. So sánh tần suất/rủi ro thay đổi, phạm vi sửa hệ thống, thời gian dừng cho phép và công sức nghiệm thu cùng nhau. Bài viết không đưa chi phí hay tỷ lệ tiết kiệm chung thiếu căn cứ.

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

Chỉ triển khai hệ thống kiểm soát thay đổi lệnh sản xuất trong MES được không?

MES có thể chủ trì luồng duyệt, nhưng nếu ERP là nguồn chuẩn của lượng, ngày, nhu cầu vật tư, tồn kho hoặc giá thành thì phải thiết kế tích hợp. Xác định chủ sở hữu dữ liệu và quyền sửa từng trường trước, rồi chỉ rõ nơi nhận kết quả duyệt, số liệu sản xuất thực tế và chênh lệch. ISA-95 giúp gọi tên ranh giới; cách kết nối cụ thể phụ thuộc hệ thống hiện có.

BOM kỹ thuật thay đổi thì lệnh đã phát hành tự cập nhật không?

Không nên giả định như vậy. Một số phần mềm sao chép production BOM và route vào lệnh khi tạo và giới hạn chỉnh sửa theo trạng thái. Microsoft mô tả việc sao chép và khả năng chỉnh trước khi lệnh bắt đầu.Microsoft: Production order lifecycle Kiểm tra phiên bản BOM của lệnh mục tiêu, vật tư đã xuất và trạng thái bắt đầu, rồi ghi rõ những lệnh nằm trong phạm vi.

Ai duyệt thay đổi số lượng và hạn giao?

Chọn theo trách nhiệm bị ảnh hưởng thay vì một chức danh cố định. Ngay cả đổi lượng hay ngày cũng có thể tác động vật tư, máy, cam kết khách và chất lượng. Xác định tuyến duyệt theo trạng thái và kết quả đánh giá, bao gồm ủy quyền và hồ sơ khẩn cấp. Nếu cần khách hàng đồng ý, duyệt nội bộ chưa phải kết thúc.

FAT và SAT có cần lặp lại cùng kịch bản không?

Giữ bộ kịch bản cốt lõi chung. FAT kiểm chức năng, tích hợp và lỗi; SAT kiểm thiết bị, giấy, quyền, mạng và WIP thực. Thao tác màn hình qua FAT không chứng minh phiếu cũ hoặc cache đã biến mất ở xưởng. Thống nhất bằng chứng và điều kiện thử lại trước khi chạy.

Kết luận

Hãy coi thay đổi sau phát hành là một chuỗi kiểm soát thống nhất: yêu cầu, đánh giá tác động, phê duyệt, triển khai xuống xưởng, vô hiệu phiên bản cũ, và đối soát số liệu sản xuất thực tế với ERP. Ghi trong RFP trạng thái được sửa, điểm hiệu lực ngoài thực tế, xác nhận của công nhân, lịch sử theo phiên bản và cách khôi phục khi tích hợp lỗi. Chứng minh luồng đúng lẫn luồng lỗi bằng FAT và SAT theo sản phẩm, vật tư và quy tắc chất lượng của chính nhà máy.

Ngay cả khi phiếu thay đổi và luồng ERP/MES hiện tại chưa được hệ thống hóa, những trường hợp gần đây của một dây chuyền đã đủ để bắt đầu xác định câu hỏi cho RFP. Liên hệ TOMAS TECH.

Tài liệu gốc

• ISA: ISA-95 Standard
• ISA: ISA-95 Part 5
• Microsoft: Release production orders
• Microsoft: React to last-minute changes
• Microsoft: Production planning
• SAP: Production Orders Quick Guide
• SAP: Update of Released Production Order
• Oracle: Using Manufacturing
• ISO/TC 176: Auditing Practices Group