กลับไปยังบล็อก BIM และ IFC
การส่งมอบและ ISO 19650 · 2026-08-07 · 10 นาที
เกณฑ์การตรวจรับ IFC: วิธีรับหรือตีกลับโมเดลโดยไม่ต้องโต้เถียงกัน
“โมเดลนี้ใช้งานไม่ได้” กับ “โมเดลก็ปกติดี” เป็นข้อถกเถียงที่ไม่มีวันจบ ตารางเกณฑ์การตรวจรับหนึ่งหน้าที่ตกลงกันก่อนการส่งงานครั้งแรก จะเปลี่ยนเรื่องนี้ให้เป็นการตรวจ 5 นาทีที่มีผลลัพธ์บันทึกไว้เป็นหลักฐาน
เกณฑ์การตรวจรับ IFC: วิธีรับหรือตีกลับโมเดลโดยไม่ต้องโต้เถียงกัน — IFC Viewer Online article cover
ในทุกโครงการจะมีสักช่วงที่ผู้ประสานงานเปิดโมเดลที่ได้รับ ใช้เวลา 20 นาทีเพื่อพบว่ามันใช้งานไม่ได้ แล้วเขียนอีเมลที่ขึ้นต้นว่า “ต้องขออภัยที่ต้องแจ้งว่า...” สิ่งที่จะเกิดขึ้นต่อจากนั้นแทบจะขึ้นอยู่กับเรื่องเดียว คือมีใครเขียนไว้ล่วงหน้าหรือไม่ว่างานส่งมอบที่ยอมรับได้ต้องมีลักษณะอย่างไร
หากมีการเขียนไว้ อีเมลนั้นจะสั้น ตรงตามข้อเท็จจริง และไม่มีข้อโต้แย้ง หากไม่มี อีเมลนั้นจะเป็นการเปิดฉากการต่อรองว่าจะใช้มาตรฐานของใคร และเรื่องเดิมจะถูกยกขึ้นมาถกเถียงใหม่ทุกครั้งที่ถึงจุดตรวจของแต่ละระยะไปจนจบโครงการ
การตรวจรับคือเช็กลิสต์ ไม่ใช่ความเห็น
การเปลี่ยนมุมคิดนี้เป็นเรื่องเล็ก แต่เปลี่ยนทุกอย่าง การตรวจงานที่ส่งมาไม่ใช่การประเมินคุณภาพ แต่เป็นการนำเกณฑ์ที่ตกลงกันแล้วมาใช้กับไฟล์ ซึ่งส่งผล 3 ประการที่ควรพูดให้ชัด:
- ผู้ตรวจไม่ต้องมีอำนาจใดนอกเหนือจากตารางที่ตกลงกันไว้ และไม่ได้ตัดสินความสามารถของผู้สร้างโมเดล เพียงแต่รายงานผลลัพธ์
- ผู้สร้างโมเดลคาดการณ์ผลได้ก่อนส่งงาน อะไรที่คาดการณ์ได้ย่อมป้องกันได้ และนั่นคือหัวใจของเรื่องนี้ทั้งหมด
- เมื่อมีความเห็นไม่ตรงกัน ประเด็นจะอยู่ที่ตัวเกณฑ์ ซึ่งคุยกันอย่างใจเย็นเพียงครั้งเดียวได้ แทนที่จะต้องเถียงกันทุกเดือนกลางรอบการส่งงาน
คุณตีกลับงานเพราะไม่ผ่านมาตรฐานที่ผู้ส่งไม่เคยตกลงด้วยไม่ได้ คุณตีกลับได้เฉพาะเมื่องานไม่ผ่านมาตรฐานที่ทั้งสองฝ่ายตกลงร่วมกันแล้วเท่านั้น
ตารางเกณฑ์การตรวจรับ
นี่คือเอกสารที่ต้องมี 10 แถว 1 หน้า แนบท้ายแผนการดำเนินงาน BIM (BEP) หรือข้อกำหนดการแลกเปลี่ยนข้อมูล (EIR) คอลัมน์ที่สามเว้นว่างไว้โดยตั้งใจ โครงการจะเติมให้ครบก่อนการส่งงานครั้งแรก และการเติมคอลัมน์นั้นเองคือจุดที่เกิดการตกลงกันจริง
| เกณฑ์ | ตีกลับเมื่อ… | ข้อตกลงของโครงการ |
|---|
| ความสมบูรณ์เชิงโครงสร้างของไฟล์ | มีประเด็นที่พบด้านสคีมาหรือโครงสร้างเชิงพื้นที่ในระดับความรุนแรง “ข้อผิดพลาด” | ตีกลับ / รับพร้อมหมายเหตุ |
| Health Score (คะแนนคุณภาพโมเดล) | ต่ำกว่าเกณฑ์ที่ตกลงกัน | เกณฑ์: __ /100 |
| ความครอบคลุมการตรวจสอบ | มีการตรวจใดที่รายงานว่า “ไม่ได้รัน” หรือ “ล้มเหลว” | ตีกลับ / ต้องรันใหม่ |
| ความคงที่ของตัวระบุ | อัตราการเปลี่ยน GUID ระหว่างฉบับแก้ไขสูงกว่าเปอร์เซ็นต์ที่ตกลงกัน | อัตราการเปลี่ยนสูงสุด: __ % |
| การตั้งชื่อ | ชื่อไฟล์ไม่เป็นไปตามข้อกำหนดที่ตกลงกัน | ตีกลับ / เปลี่ยนชื่อและบันทึกไว้ |
| การอ้างอิงพิกัดทางภูมิศาสตร์ | โมเดลไม่ได้อยู่บนจุดอ้างอิงร่วมของโครงการ | ตีกลับ |
| หน่วย | หน่วยความยาวไม่ใช่ระบบเมตริก | ตีกลับ |
| การจำแนกประเภท | องค์ประกอบที่ไม่มีการอ้างอิงรหัสจำแนกประเภท | ใช้ตั้งแต่ระยะ: __ |
| ชุดคุณสมบัติ (property set) | ขาด Pset ที่จำเป็นตามระดับความต้องการสารสนเทศ (level of information need) ที่ประกาศไว้ | ตาราง Pset: __ |
| พื้นที่ (space) | พื้นที่ที่ไม่มีชื่อ ชื่อเต็ม (long name) หรือค่าพื้นที่ใช้สอย | ใช้ตั้งแต่ระยะ: __ |
จุดประสงค์ของตารางนี้ไม่ใช่ความเข้มงวด แต่คือการตัดสินใจไว้ล่วงหน้า ตารางแบบผ่อนปรนที่ทุกคนตกลงร่วมกัน ดีกว่าตารางเข้มงวดที่มาพร้อมอีเมลตีกลับงาน
สามแถวแรกคือแถวที่สำคัญที่สุด และก็เป็นแถวที่มักถูกละไว้บ่อยที่สุดเช่นกัน ข้อกำหนดที่ใช้บรรจุเกณฑ์เหล่านี้ลงใน BEP ตั้งแต่ต้นอธิบายไว้ในข้อกำหนดใน BEP ที่ป้องกันการส่งมอบ IFC คุณภาพต่ำได้จริง
แถวที่ 3 ควรมีหัวข้อของตัวเอง: ความครอบคลุมการตรวจสอบ
ตารางตรวจรับส่วนใหญ่ตรวจผลลัพธ์ของการตรวจสอบความถูกต้อง แต่แทบไม่มีตารางใดตรวจว่าการตรวจนั้นได้ทำจริงหรือไม่ และนั่นคือช่องโหว่ที่ใหญ่พอให้งานส่งมอบทั้งชุดหลุดรอดไปได้
การตรวจที่ไม่ได้รันดูเหมือนกับการตรวจที่ผ่านทุกประการ เพราะทั้งคู่ไม่มีประเด็นที่พบเลย ไฟล์ขนาดใหญ่หมดเวลา (timeout) โปรเซสเบื้องหลัง (worker) ล่ม การตรวจที่ต้องอาศัยเรขาคณิตยอมแพ้ไปเงียบ ๆ แล้วรายงานก็กลับมาสะอาดพร้อมคะแนนเต็ม งานส่งมอบจึงผ่านการตรวจรับ ทั้งที่ถูกตรวจเพียงในนามเท่านั้น
| สถานะความครอบคลุม | ความหมาย | การดำเนินการในการตรวจรับ |
|---|
| รันแล้ว | การตรวจทำงานจนเสร็จ ไม่มีประเด็นที่พบก็หมายความว่าไม่มีจริง | เชื่อถือผลลัพธ์ได้ |
| ไม่ได้รัน | มีการเริ่มตรวจแต่ไม่ได้ผลลัพธ์ มักเกิดจากหมดเวลาหรือการรันถูกยกเลิก | รันใหม่ก่อนตรวจรับ ห้ามถือว่าผ่านเด็ดขาด |
| ล้มเหลว | การตรวจเกิดข้อผิดพลาด | รายงานให้ทราบ คะแนนที่คำนวณจากการตรวจที่ล้มเหลวนำไปเทียบกับการรันที่สมบูรณ์ไม่ได้ |
ตรวจงานส่งมอบใน 5 นาที
- เปิดคอนเทนเนอร์สารสนเทศ (information container) แล้วรันชุดกฎของโครงการ โมเดลของแต่ละสาขางานส่วนใหญ่ใช้เวลาไม่ถึงหนึ่งนาที
- ดูความครอบคลุมก่อน แล้วจึงดูผลลัพธ์ หากมีรายการใดไม่ได้รัน ให้หยุด เพราะคุณยังไม่ได้ตรวจจริง
- อ่านคะแนนเทียบกับเกณฑ์ แล้วจึงดูประเด็นที่พบในระดับ “ข้อผิดพลาด” ที่เหลือทั้งหมดเป็นเพียงหมายเหตุ ไม่ใช่เงื่อนไขการผ่าน
- เปรียบเทียบกับฉบับแก้ไขก่อนหน้า ประเด็นที่พบใหม่คือเรื่องที่ต้องใส่ใจ ส่วนประเด็นที่แก้แล้วคือหลักฐานว่าผลการตรวจครั้งก่อนได้รับการดำเนินการ
- บันทึกผลไว้ในเอกสารนำส่ง (transmittal) หรือความคิดเห็นในสภาพแวดล้อมข้อมูลร่วม (CDE) ได้แก่ คะแนน ชุดกฎ ความครอบคลุม และประเด็นที่พบซึ่งยอมรับตามข้อตกลง
ขั้นตอนที่ 1 คือกิจวัตรเดียวกับที่ผู้ส่งควรทำก่อนส่งงาน บทความวิธีตรวจสอบโมเดล IFC ก่อนส่งมอบอธิบายขั้นตอนนี้จากฝั่งผู้ส่ง เมื่อทั้งสองฝ่ายรันการตรวจชุดเดียวกัน การตรวจรับจะไม่ใช่การตรวจจับผิดอีกต่อไป แต่กลายเป็นการยืนยันผล
วิธีเขียนข้อความตีกลับงาน
น้ำเสียงสำคัญพอ ๆ กับเนื้อหา เพราะผู้รับมักทำงานล่าช้ากว่ากำหนดอยู่แล้ว และแทบไม่เคยเป็นความผิดของเขาโดยตรง กฎ 3 ข้อ: ระบุเกณฑ์ ไม่ใช่ระบุตัวโมเดล บอกสาเหตุ ไม่ใช่แค่อาการ และบอกว่างานใดถูกระงับไว้และนานเท่าใด
Hi {name},
We've run the agreed pre-acceptance check on {filename} (rev {n}) and it
comes back at {score}/100, below the {threshold} we set in clause {x} of
the BEP.
The two findings driving that are:
- {rule id} — {plain description} ({n} elements)
- {rule id} — {plain description} ({n} elements)
Both look like export settings rather than modelling, so they should be
quick — the report is attached with the element references.
We'll hold coordination on this container until the next issue.
สังเกตสิ่งที่ไม่มีอยู่ในข้อความ คือไม่มีคำคุณศัพท์ใดบรรยายตัวโมเดล และไม่มีการคาดเดาว่าเหตุใดจึงเกิดขึ้น มีเพียงตัวเลขหนึ่งค่า รหัสกฎสองรายการ สาเหตุที่น่าจะเป็น และผลที่ตามมา นี่คือข้อความที่ไม่มีใครต้องออกมาแก้ตัว และนั่นคือเหตุผลที่มันได้รับการแก้ไข แทนที่จะถูกยกระดับเป็นข้อขัดแย้ง
เมื่อใดควรรับโมเดลที่ไม่ผ่าน
บางครั้งคำตอบที่ถูกต้องก็คือรับไว้อยู่ดี เช่น ข้อมูลที่ขาดไปอยู่นอกระดับความต้องการสารสนเทศของระยะนั้น ซัพพลายเออร์ยังไม่ได้ส่งข้อมูล หรือทางเลือกอื่นคือต้องหยุดโครงการ การรับงานส่งมอบที่ไม่ผ่านเป็นการตัดสินใจที่ชอบธรรม แต่การรับไว้เงียบ ๆ ไม่ใช่
ประเด็นที่พบซึ่งได้รับการยกเว้น (waiver) ต้องแนบ 3 อย่าง ได้แก่ เหตุผล ผู้ที่ให้ความเห็นชอบ และวันที่ นี่คือความแตกต่างทั้งหมดระหว่างประเด็นที่ยอมรับกับประเด็นที่ถูกเพิกเฉย และเป็นสิ่งที่ป้องกันไม่ให้ปัญหาเดิมถูกค้นพบใหม่ในฐานะวิกฤตเมื่อผ่านไปอีกสองระยะ
ข้อยกเว้นเหล่านั้นควรอยู่ในเอกสารนำส่ง ร่วมกับรายงานและทุกสิ่งที่ส่งไปพร้อมกับคอนเทนเนอร์ ดูสิ่งที่ต้องส่งมอบพร้อมโมเดล IFC
เกณฑ์การตรวจรับ IFC: วิธีรับหรือตีกลับโมเดลโดยไม่ต้องโต้เถียงกัน