ทำไมเราสร้างระบบจาก SOP จริงของคุณ ไม่ใช่เทมเพลต

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

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

คำสัญญาของเทมเพลต และจุดที่มันพัง

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

ระบบควบคุมเอกสารจริงแตกต่างกันในแบบที่ส่งผลต่อการทำงานจริง ไม่ใช่แค่รูปลักษณ์ภายนอก

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

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

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

เราสร้าง ระบบ ISO อัตโนมัติ จริง ๆ อย่างไร

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

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

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

การสร้างจาก SOP จริงยังเป็นสิ่งที่เผยให้เห็นบั๊กที่เทมเพลตจะเมินไปเงียบ ๆ แบบฟอร์มกระดาษของผู้ผลิตปนปีปฏิทินพุทธศักราชกับคริสต์ศักราชไม่สม่ำเสมอ รายละเอียดที่เจ้าหน้าที่ควบคุมเอกสารคอยแก้ในหัวมาหลายปี โดยไม่มีใครเขียนเป็นกฎที่ชัดเจนไว้ เพราะเรากำลังทำแผนผังแบบฟอร์มจริงของพวกเขาทีละช่อง แทนที่จะใส่ช่องวันที่ทั่วไปเข้าไป ความไม่สอดคล้องนี้จึงโผล่ขึ้นมาระหว่างการสร้างระบบ ตอนนี้ระบบมาตรฐานทุกวันที่ให้เป็น dd/mm/yyyy ปิดช่องว่างที่กระบวนการกระดาษไม่เคยบังคับให้ใครต้องแก้

สิ่งที่ automation จาก SOP ยังไม่ทำ

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

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

ทำไมเรื่องนี้สำคัญตอนตรวจประเมิน

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

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