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

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

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

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

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

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

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

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

ข้อกำหนด	ความหมาย	เหตุผลที่ผู้ตรวจประเมินสนใจ
จุดตัดสินใจของคนยังเป็นของคน	การทบทวนและอนุมัติเนื้อหาทำโดยคนที่มีชื่อระบุไว้ ไม่ใช่ระบบ	นี่คือข้อกำหนด ISO 9001 เอง ข้อกำหนด 7.5 ตั้งอยู่บนพื้นฐานการทบทวนโดยคนที่มีความสามารถ
ทุกการเขียนถูกบันทึก log แยกกัน	แต่ละช่องข้อมูลที่ระบบเขียน เลขแก้ไข วันที่ แถวในทะเบียน มีรายการของตัวเองในบันทึกกิจกรรม	ให้ผู้ตรวจประเมินตามรายการในทะเบียนกลับไปถึงเหตุการณ์ที่แน่นอนที่เป็นต้นเหตุ
การทำงานเป็น idempotent	การเล่นซ้ำหรือทริกเกอร์ซ้ำเหตุการณ์อนุมัติเดียวกันไม่สร้างรายการซ้ำ	ป้องกันไม่ให้ทะเบียนคลาดเคลื่อนจากสิ่งที่ได้รับอนุมัติจริงโดยไม่มีใครรู้ตัว
เอกสารต้นฉบับตรวจสอบได้ว่าไม่ถูกแตะต้อง	เอกสารต้นฉบับมี file ID ชื่อ รูปแบบ และเวลาแก้ไขล่าสุดเหมือนเดิมหลัง 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 เป็นระบบที่มีเอกสารและทดสอบได้ กับการสร้างเป็นสคริปต์ที่บังเอิญทำงานได้เกือบทุกครั้ง