เทียบผู้ให้บริการ ISO ก่อนเซ็นสัญญา: ต้องถามอะไรบ้าง

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

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

ทำไมการเทียบผู้ให้บริการ ISO ในไทยต้องดูมากกว่าสไลด์นำเสนอ

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

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

คำถาม แบ่งตามสิ่งที่มันปกป้อง

ขอบเขตและสิ่งที่ส่งมอบ

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

จุดตัดสินใจของมนุษย์

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

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

ความเป็นเจ้าของและการผูกติดผู้ขาย

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

การยอมรับและตรวจสอบ

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

โครงสร้างต้นทุน

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

ระยะเวลาและการสนับสนุนหลังขึ้นระบบจริง

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

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

ตารางเทียบสำหรับรายชื่อที่คัดไว้

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

แถวที่เต็มไปด้วยคำตอบคลุมเครือหรือหลบเลี่ยง ให้ข้อมูลมากกว่าคำตอบเดี่ยว ๆ ที่ดูดีข้อไหนก็ตาม

คำตอบจากผู้ที่ลงมือสร้างระบบควรฟังดูอย่างไร

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

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