รับประกันไม่แตะต้นฉบับ: สร้างระบบบนไฟล์สำเนาเท่านั้น

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

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

ทำไม "ไม่แตะ" ต้องมีความหมายที่ชัดเจนสำหรับระบบ ISO อัตโนมัติ

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

การเปรียบเทียบนั้นมีสี่ส่วน และต้องผ่านครบทั้งสี่

1. File ID รหัสอ้างอิงของเอกสารในระบบจัดเก็บไม่เปลี่ยน ไม่ได้ถูกลบแล้วสร้างใหม่ภายใต้ชื่อเดิม
2. ชื่อไฟล์ ไม่มีการเปลี่ยนชื่อเงียบ ๆ ไม่มีการต่อท้ายชื่อ ไม่มีร่องรอยของการทำเวอร์ชันที่ automation ทิ้งไว้
3. รูปแบบไฟล์ ไฟล์ .docx ยังคงเป็น .docx ไม่มีการแปลงไฟล์ ไม่มีการบีบอัด หรือบันทึกซ้ำผ่านเครื่องมือกลางที่เปลี่ยนโครงสร้างไฟล์
4. เวลาที่แก้ไขล่าสุด timestamp สะท้อนครั้งล่าสุดที่คนแก้ไขเอกสารจริง ไม่ใช่ครั้งล่าสุดที่ workflow ทำงานใกล้ ๆ ไฟล์นั้น

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

สร้างระบบบนไฟล์สำเนา ไม่ใช่บนต้นฉบับ อย่างไร

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

พูดให้เป็นรูปธรรม หน้าที่ของ workflow engine คือตอบสนองต่อการตัดสินใจของคน เครื่องหมายของผู้ทวนสอบ ลายเซ็นอนุมัติของผู้อนุมัติ แล้วแปลงการตัดสินใจนั้นเป็นรายการในระบบที่ automation เป็นเจ้าของ เช่น ทะเบียนใน Google Sheets, activity log, การย้ายโฟลเดอร์ที่สะท้อนสถานะวงจรชีวิตเอกสาร ไม่ใช่เครื่องมือที่ไปแก้ไข แปลงไฟล์ หรือบันทึกซ้ำเอกสารควบคุมเอง ถ้าเอกสารต้องมีฉบับแก้ไขใหม่ คนจะเป็นผู้สร้างฉบับนั้นตามที่ SOP กำหนดไว้อยู่แล้ว หน้าที่ของ automation เริ่มหลังจากไฟล์นั้นมีอยู่แล้ว ไม่ใช่ก่อนหน้านั้น

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

"ตรวจสอบแล้วว่าไม่เปลี่ยนแปลง" หน้าตาเป็นอย่างไรจริง ๆ

นี่คือสิ่งที่ข้อรับประกันนี้เป็นจริงเมื่อเราทดสอบ ไม่ใช่แค่บรรยาย บนระบบต้นแบบที่เราสร้างให้โรงงานไทยแห่งหนึ่ง ได้รับการรับรอง ISO 9001:2015 ทั้งสองโรงงาน

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

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

อะไรเปลี่ยน อะไรไม่เปลี่ยนเลย

ชั้นงาน	สิ่งที่ automation แตะ	สิ่งที่ตรวจสอบหลังสร้างระบบ
เอกสารต้นฉบับ	ไม่เปิด ไม่แก้ไข ไม่เปลี่ยนชื่อ ไม่บันทึกซ้ำเลย	file ID ชื่อ รูปแบบ เวลาแก้ไขล่าสุด ไม่เปลี่ยน
ทะเบียน / master list	เขียนหลังจากคนอนุมัติแล้วเท่านั้น	เพิ่มแถวใหม่ ไม่ใช่แก้ไฟล์ต้นฉบับ
Activity log	เขียนทุกครั้งที่ automation ทำงาน	บันทึกทีละรายการ พร้อม timestamp
สถานะโฟลเดอร์ Drive	สะท้อนวงจรชีวิตเมื่อคนย้ายไฟล์	automation ตอบสนอง ไม่ใช่ผู้เริ่มย้ายเอง
workflow อื่นบน tenant	ไม่ถูกแตะต้องจากระบบนี้เลย	ตรวจ 51 workflow เดิมที่ไม่เกี่ยวข้อง พบว่าไม่เปลี่ยนแปลง

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

สิ่งนี้ปกป้องคุณจากอะไร

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

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