เทมเพลตไม่มีทางรู้ว่าโรงงานคุณมีสิบแผนกในเมทริกซ์การแจกจ่ายเอกสาร หรือสายอนุมัติของคุณมีจุดลงนามสี่จุดแยกกัน หรือแบบฟอร์มกระดาษของคุณปนปีพุทธศักราชกับคริสต์ศักราชมาอย่างเงียบ ๆ นานนับสิบปี เพราะเทมเพลตถูกเขียนขึ้นก่อนที่โรงงานคุณจะมีอยู่ด้วยซ้ำ นี่คือเหตุผลที่ ระบบ 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 กลับไปหาสมมติฐานของผู้ขาย คือความต่างที่ผู้ตรวจประเมินตรวจสอบได้จริง
คำถามที่พบบ่อย
สร้างจาก SOP ของเราใช้เวลานานกว่าติดตั้งเทมเพลตหรือไม่
ขั้นตอนสำรวจ การอ่าน SOP จริงของคุณและจับคู่จุดตัดสินใจ ช่องข้อมูล และทะเบียน เกิดขึ้นก่อน ก่อนที่จะเขียน logic ของ automation ใด ๆ เลย เป็นเวลาที่ใช้ครั้งเดียว และเป็นเหตุผลที่ระบบที่ได้ไม่ต้องมาตั้งค่าใหม่ทุกครั้งที่ SOP กับเครื่องมือไม่ตรงกัน
ถ้า SOP ของเรามีความไม่สอดคล้องที่เราไม่รู้ตัวล่ะ
การทำแผนผังทีละช่องจากเอกสารจริงของคุณมักเผยให้เห็นเรื่องแบบนี้พอดี เหมือนบั๊กระบบปฏิทินในระบบต้นแบบของเรา เราจะแจ้งสิ่งที่เจอ ส่วนคุณเป็นคนตัดสินใจว่าจะแก้อย่างไร เราไม่ปิดบังความไม่สอดคล้องอย่างเงียบ ๆ หรือเดาว่าคุณหมายถึงอะไร
คุณเคยแนะนำให้เปลี่ยน SOP แทนที่จะทำอัตโนมัติตามเดิมไหม
บางครั้งช่องว่างที่พบก็คุ้มค่าจะแจ้งก่อนที่เราจะสร้างระบบตามนั้น แต่ตัว automation เองถูกสร้างให้ตรงกับ SOP ตามที่เขียนและอนุมัติไว้ เราไม่ใส่การเปลี่ยนแปลง workflow ที่ยังไม่ผ่านกระบวนการเปลี่ยนแปลงเอกสารของคุณเองเข้าไป
เรื่องนี้แทนที่ซอฟต์แวร์ QMS ที่เรามีอยู่หรือไม่
ไม่จำเป็น automation ที่มาจาก SOP อยู่ควบคู่ไปกับแพลตฟอร์ม QMS หรือแทนที่ทะเบียนแบบสเปรดชีตก็ได้ ขึ้นอยู่กับว่าตอนนี้คุณควบคุมเอกสารอย่างไร
ระบบที่ได้ยังเป็นของเรา หรือเราถูกผูกติดกับแพลตฟอร์มของคุณ
คุณเป็นเจ้าของสิ่งที่ถูกสร้างขึ้นทั้งหมด ไม่มีการผูกติดกับผู้ให้บริการ ระบบถูกส่งมอบให้คุณ ทำงานอยู่บนโครงสร้างพื้นฐานที่คุณควบคุมเอง
ถ้าอยากเห็นว่า automation ที่มาจาก SOP หน้าตาเป็นอย่างไรจริง ๆ เทียบกับระบบที่ลงนามอนุมัติแล้ว ไม่ใช่แค่การนำเสนอขาย อ่านบันทึกการสร้างระบบต้นแบบของเราให้ผู้ผลิตไทยแห่งหนึ่ง 1% EVO สร้างระบบนั้นจาก SOP ที่ลูกค้าเขียนไว้เองและส่งมอบให้ ไม่มีเทมเพลต ไม่มีการผูกติดกับผู้ให้บริการ และไม่มีขั้นตอนไหนที่ขั้นตอนของลูกค้าถูกดัดแปลงให้เข้ากับซอฟต์แวร์ของคนอื่น