สร้าง ISO Automation ที่ผู้ตรวจประเมินยอมรับได้

ผู้ตรวจประเมินไม่ได้ปฏิเสธ ISO automation เพราะหลักการ แต่ปฏิเสธเมื่อมันแสดงไม่ได้ว่าใครตัดสินใจอะไร และเมื่อไร automation ที่ผู้ตรวจประเมินยอมรับ คือ automation ที่ทำให้เส้นทางการตัดสินใจมองเห็นได้ชัดกว่ากระบวนการแมนวลเดิม ไม่ใช่มองเห็นได้น้อยลง

นี่คือมาตรฐานการออกแบบ บทสนทนากับผู้ขายส่วนใหญ่มักข้ามไปที่ "เราจะทำให้การควบคุมเอกสารของคุณเป็นอัตโนมัติ" โดยไม่เคยพูดถึงสิ่งที่ผู้ตรวจประเมินจะตรวจสอบจริง ๆ นี่คือหน้าตาของการตรวจสอบนั้น และสิ่งที่ต้องมีเพื่อให้ผ่าน

ผู้ตรวจประเมินตรวจสอบอะไรจริง ๆ

ผู้ตรวจประเมิน ISO 9001 ที่สุ่มตรวจการควบคุมเอกสารของคุณ ไม่ได้ประเมินว่าคุณใช้ซอฟต์แวร์หรือไม่ พวกเขาประเมินว่าข้อกำหนด 7.5 ถูกปฏิบัติตามอย่างแสดงให้เห็นได้จริงหรือไม่ ว่าเอกสารถูกทบทวนและอนุมัติโดยผู้มีความสามารถก่อนปล่อยใช้งาน การเปลี่ยนแปลงตรวจสอบย้อนกลับได้ ฉบับปัจจุบันที่ได้รับอนุมัติคือฉบับที่หมุนเวียนอยู่จริง และบันทึกทั้งหมดนี้พร้อมให้ตรวจสอบและไม่ถูกเปลี่ยนแปลง

สเปรดชีตที่อัปเดตด้วยมือผ่านการตรวจนี้ได้ การเขียนข้อมูลแบบอัตโนมัติก็ผ่านได้เช่นกัน สิ่งที่ไม่ผ่านการตรวจ ไม่ว่าจะใช้เครื่องมือแบบไหน คือระบบที่ผู้ตรวจประเมินสร้างภาพเหตุการณ์ใหม่ไม่ได้ว่าใครอนุมัติอะไร เมื่อไร และเกิดอะไรขึ้นตามมา และการสร้างภาพนั้นต้องเชื่อกล่องดำแทนการอ่านบันทึกจริง

automation ยกระดับความเสี่ยงตรงนี้ ด้วยเหตุผลง่าย ๆ เมื่อเครื่องเป็นคนเขียนรายการในทะเบียนแทนคน คำถามของผู้ตรวจประเมินเปลี่ยนจาก "บันทึกนี้ถูกต้องหรือไม่" เป็น "ฉันเชื่อได้ไหมว่าบันทึกนี้ถูกเขียนถูกต้องทุกครั้ง และฉันจะรู้ได้ถ้ามันไม่ถูกต้อง" นี่เป็นคำถามที่ยากกว่า และงานที่ดีต้องตอบคำถามนี้ให้ชัดเจน

สี่ข้อที่ทำให้ ISO automation ผู้ตรวจประเมินยอมรับได้

พลาดข้อไหนข้อหนึ่งใน 4 ข้อนี้ คุณไม่ได้สร้าง ISO automation คุณสร้างวิธีที่เร็วขึ้นในการเจอข้อบกพร่องจากการตรวจประเมิน ทำถูกครบทั้ง 4 ข้อ บันทึกอัตโนมัติมักเป็น audit trail ที่แข็งแรงกว่าบันทึกที่ดูแลด้วยมือ เพราะตัดโอกาสที่รายการในทะเบียนจะไม่ตรงกับสิ่งที่ได้รับอนุมัติจริงออกไป

หน้าตาของสิ่งนี้ในงานสร้างระบบจริง

ระบบต้นแบบของเรา ระบบอัตโนมัติควบคุมเอกสารสำหรับผู้ผลิตไทยแห่งหนึ่ง ได้รับการรับรอง ISO 9001:2015 ทั้งสองไซต์ ถูกออกแบบตามมาตรฐานนี้เป๊ะ เพราะประเด็นสำคัญคือมันต้องผ่านการตรวจประเมินจริงได้ ไม่ใช่แค่ผ่านการเดโม

ระบบรักษาจุดตัดสินใจของคนทั้งสี่จุด ที่มาจาก SOP ของผู้ผลิตเอง ผู้ทบทวนทำเครื่องหมายบนแบบฟอร์มคำขอเปลี่ยนแปลงกระดาษ ผู้อนุมัติตรวจสอบความเหมาะสมของเนื้อหา และจุดรวมสุดท้ายที่ลงนามอนุมัติหลัก ครอบคลุมเอกสารภายนอกและเอกสารสนับสนุนด้วย automation จะทำงานก็ต่อเมื่อลำดับนั้นเสร็จสมบูรณ์แล้วเท่านั้น ณ จุดนั้นระบบเขียนช่องข้อมูลแปดช่องที่เจ้าหน้าที่ควบคุมเอกสารเคยพิมพ์ซ้ำด้วยมือ เลขแก้ไข วันมีผลบังคับใช้ รายการในประวัติการแก้ไข แถวในบัญชีรายชื่อเอกสารหลักครอบคลุมเมทริกซ์การแจกจ่ายสิบแผนก รายการในทะเบียนการเปลี่ยนแปลง เลขที่คำขออ้างอิงปี จำนวนหน้า และวันครบกำหนดเก็บรักษาและทำลายเอกสารที่คำนวณไว้แล้ว การเขียนข้อมูลทั้งแปดรายการถูกบันทึก log แยกกันทุกรายการ และ workflow ถูกออกแบบด้วย idempotency key ทำให้เหตุการณ์ที่เล่นซ้ำสร้างรายการซ้ำในทะเบียนไม่ได้

ระบบผ่านเกณฑ์การยอมรับ 19 จาก 19 ข้อ workflow เดิมทั้งหมด 51 รายการที่ไม่เกี่ยวข้องซึ่งทำงานอยู่บน tenant automation เดียวกันได้รับการยืนยันว่าไม่ได้รับผลกระทบใด ๆ หลังจากนั้น เอกสารต้นฉบับทั้งห้าฉบับก็ได้รับการยืนยันว่าไม่มีการเปลี่ยนแปลงเช่นกัน ทั้ง file ID ชื่อ รูปแบบ และเวลาแก้ไขล่าสุด ทั้งก่อนและหลัง ไม่มีข้อไหนเป็นแค่ของตกแต่ง แต่ละการตรวจสอบตอบคำถามเฉพาะที่ผู้ตรวจประเมินจะต้องถามด้วยตัวเองถ้าไม่มีสิ่งนี้

ข้อผิดพลาดที่พบบ่อยที่ทำให้ automation เสี่ยงตอนตรวจประเมิน

automation ส่วนใหญ่ที่ดึงความสนใจของผู้ตรวจประเมินด้วยเหตุผลที่ไม่ดี มักทำข้อผิดพลาดข้อใดข้อหนึ่งต่อไปนี้

• ระบบประเมินเนื้อหา ไม่ใช่แค่กระบวนการ อะไรก็ตามที่อ่านเนื้อหาเอกสารแล้วตัดสินว่า "ดีพอ" ที่จะข้ามขั้นตอนทบทวน คือการแทนที่วิจารณญาณของคนด้วยวิจารณญาณของซอฟต์แวร์ นั่นไม่สอดคล้องข้อกำหนด และมักเป็นสิ่งแรกที่ผู้ตรวจประเมินที่เฉียบคมจะตรวจสอบ
• การเขียนข้อมูลตรวจสอบย้อนกลับทีละรายการไม่ได้ ระบบที่อัปเดตทะเบียนเป็นชุดใหญ่ หรืออัปเดตโดยไม่มีใครรู้ ไม่มี log รายช่องข้อมูลผูกกับเหตุการณ์ต้นเหตุ ทำให้ผู้ตรวจประเมินไม่มีอะไรให้สุ่มตรวจสอบ
• การรันซ้ำไม่ใช่ idempotent ถ้า webhook ทำงานสองครั้ง หรือมีคนทริกเกอร์ workflow ซ้ำ แล้วทะเบียนได้แถวซ้ำ ทะเบียนก็ผิดแล้ว และผิดในแบบที่อาจไม่มีใครสังเกตเห็นจนกว่าตัวเลขจะไม่ลงตัว
• ไม่มีใครแสดงได้ว่าต้นฉบับไม่ถูกแตะต้อง ถ้า file ID ชื่อ หรือวันแก้ไขของเอกสารต้นฉบับเปลี่ยนไปด้วยเหตุผลที่ไม่มีใครอธิบายได้ นั่นคือข้อบกพร่องที่ชอบธรรม ไม่ว่าจะเป็นระบบอัตโนมัติหรือไม่ก็ตาม

ไม่มีข้อไหนเป็นปัญหาทางวิศวกรรมที่แปลกใหม่ ทั้งหมดคือความต่างระหว่างการสร้าง automation เป็นระบบที่มีเอกสารและทดสอบได้ กับการสร้างเป็นสคริปต์ที่บังเอิญทำงานได้เกือบทุกครั้ง