กลับไปยังบล็อก BIM และ IFC
การส่งมอบและ ISO 19650 · 2026-08-07 · 9 นาที
ข้อกำหนดใน BEP ที่ป้องกันการส่งมอบไฟล์ IFC คุณภาพต่ำได้จริง
BEP ส่วนใหญ่เขียนไว้เพียงว่าโมเดลต้อง “มีคุณภาพที่เหมาะสม” และไม่มีอะไรมากกว่านั้น การถกเถียงเรื่องคุณภาพจึงไม่มีวันจบ บทความนี้เสนอข้อกำหนดสั้น ๆ สี่ข้อที่เขียนไว้ให้คัดลอกไปใช้ได้ทันที เพื่อเปลี่ยนความเห็นส่วนตัวให้เป็นเงื่อนไขที่ทดสอบได้
ข้อกำหนดใน BEP ที่ป้องกันการส่งมอบไฟล์ IFC คุณภาพต่ำได้จริง — IFC Viewer Online article cover
ลองเปิดแผนการดำเนินงาน BIM (BEP) ฉบับใดก็ได้ไปที่หมวดการส่งมอบสารสนเทศ คุณจะพบประโยคทำนองนี้: “โมเดลทั้งหมดต้องส่งมอบในรูปแบบที่เหมาะสม และมีคุณภาพเหมาะสมกับวัตถุประสงค์การใช้งาน” ทุกคนลงนาม ไม่มีใครทำผิดข้อนี้ได้ และก็ไม่มีใครบังคับใช้ได้เช่นกัน
ประโยคนี้คือเหตุผลที่การถกเถียงเรื่องคุณภาพ IFC ในโครงการดุเดือดนัก เพราะไม่มีอะไรให้ชี้ได้เลย เมื่อผู้ประสานงานบอกว่าโมเดลใช้ไม่ได้ แต่ผู้สร้างโมเดลบอกว่าไม่มีปัญหา ทั้งสองฝ่ายต่างก็แค่ให้ความเห็น เพราะสัญญาไม่เคยแปลง “คุณภาพ” ให้เป็นเงื่อนไขที่ใครก็ทดสอบได้
ข้อกำหนดด้านคุณภาพที่ไม่มีวันไม่ผ่าน ไม่ใช่ข้อกำหนด แต่เป็นความหวังที่มีเลขข้อกำกับไว้
อะไรทำให้ข้อกำหนดบังคับใช้ได้จริง
มีคุณสมบัติสามประการ และควรนำไปเทียบกับทุกข้อที่มีอยู่แล้วใน BEP ของคุณ ดังนี้
- ระบุการทดสอบ ไม่ใช่ “คุณภาพดี” แต่เป็นการตรวจสอบที่เจาะจง ดำเนินการด้วยวิธีที่เจาะจง และให้ผลลัพธ์ที่เจาะจง
- ระบุเกณฑ์ เป็นตัวเลข จำนวนนับ หรือเงื่อนไขแบบใช่/ไม่ใช่ ที่ผู้ตรวจทานนำไปเทียบได้โดยไม่ต้องใช้ดุลยพินิจ
- ระบุว่าจะเกิดอะไรขึ้นเมื่อไม่ถึงเกณฑ์ ข้อกำหนดที่ไม่มีผลตามมาเป็นแค่เอกสารประกอบ ไม่ใช่ข้อบังคับ
ข้อกำหนดทั้งสี่ข้อด้านล่างมีครบทั้งสามประการ และตั้งใจเขียนให้สั้น เพราะข้อกำหนดด้านคุณภาพที่ไม่มีใครอ่านย่อมไม่มีผล ส่วนข้อกำหนดที่ยาวไม่เกินครึ่งหน้าจะถูกยกขึ้นมาอ้างกับผู้เกี่ยวข้องได้จริง ซึ่งนั่นคือจุดประสงค์ทั้งหมด
ข้อกำหนดที่ 1: ตรวจสอบอัตโนมัติก่อนออกเอกสาร
Every IFC container issued to the CDE at status S2 (Shared) or above shall
have been checked with the project's agreed rule set within the 24 hours
preceding issue. The check report shall be issued alongside the container.
Containers issued without a check report may be rejected without review.
ประโยคสุดท้ายคือส่วนที่ทำงานจริง หากไม่มีประโยคนี้ ข้อกำหนดจะสร้างข้อผูกพันที่ข้ามไปได้โดยไม่มีต้นทุนใด ๆ และจะถูกข้ามในสัปดาห์ที่กำหนดการตึงมือ ซึ่งก็คือสัปดาห์ที่การตรวจสอบสำคัญที่สุดพอดี
สังเกตจุดที่วางไว้: ที่สถานะ S2 ไม่ใช่ตอนเผยแพร่ (publication) เมื่อถึงตอนที่งานถูกเผยแพร่ สามสาขางานได้ประสานงานโดยอิงงานนั้นไปแล้ว ความผิดพลาดเชิงโครงสร้างจึงหมายถึงการต้องทำงานของพวกเขาใหม่ ไม่ใช่แค่งานของคุณ ความคุ้มค่าทั้งหมดของการตรวจสอบก่อนส่งมอบขึ้นอยู่กับการจับปัญหาให้ได้ที่รอยต่อระหว่างสถานะ Work in progress → Shared
หากยังไม่ได้เลือกชุดกฎ ให้เริ่มจากการตรวจสอบมาตรฐานที่เครื่องมือตรวจสอบทุกตัวใช้ ข้อผิดพลาดในการตรวจสอบ IFC ที่พบบ่อยที่สุด ครอบคลุมการตีกลับงานจริงส่วนใหญ่ และเป็นแบบเดียวกันทุกที่ เพราะมีสาเหตุมาจากการตั้งค่าการส่งออก ไม่ใช่จากสไตล์การสร้างโมเดล
ข้อกำหนดที่ 2: เกณฑ์คุณภาพขั้นต่ำ
IFC containers shall achieve a Health Score of at least 80/100 under the
project rule set. Containers scoring below the threshold may be issued only
with the prior written agreement of the Information Manager, recording the
findings concerned and the reason.
มีการตัดสินใจเชิงออกแบบสองข้อที่ควรนำไปใช้ ข้อแรก ทางออกฉุกเฉินถูกเขียนไว้อย่างชัดเจน เพราะบางครั้งโมเดลที่ต่ำกว่าเกณฑ์ก็จำเป็นต้องแชร์จริง ๆ และกฎที่ไม่มีข้อยกเว้นที่ชอบธรรมมักถูกเพิกเฉยแทนที่จะถูกปฏิบัติตาม ข้อสอง ข้อยกเว้นต้องบันทึกเป็นลายลักษณ์อักษร ซึ่งเปลี่ยน “เราตกลงกันว่าปล่อยผ่าน” ให้กลายเป็นบันทึกที่มีวันที่และชื่อผู้บันทึก
เลือกเกณฑ์อย่างรอบคอบ คะแนนคือการบีบรายงานทั้งฉบับให้เหลือตัวเลขเดียว โดยถ่วงน้ำหนักตามหมวดหมู่และความรุนแรง จึงควรทำความเข้าใจก่อนนำไปเขียนเป็นข้อสัญญา คู่มือ IFC Health Score (คะแนนคุณภาพโมเดล) อธิบายว่าอะไรทำให้คะแนนเปลี่ยน และเปลี่ยนมากน้อยเพียงใด
ข้อกำหนดที่ 3: ความคงที่ของรหัสระบุ (identifier)
IFC GlobalIds shall be persistent for the life of the project: the identifier
of an element shall not change between revisions unless the element itself is
deleted and replaced. Task teams shall configure authoring and export tools
accordingly, and shall report any event that invalidates identifiers (model
recreation, round-trip import, template migration) at the time it occurs.
หากจะเพิ่มข้อกำหนดจากบทความนี้เพียงข้อเดียว ให้เพิ่มข้อนี้ ข้อกำหนดเรื่องเกณฑ์ช่วยยกระดับคุณภาพการส่งมอบโดยเฉลี่ย ส่วนข้อกำหนดเรื่องรหัสระบุป้องกันความเสียหายประเภทที่ซ่อมภายหลังไม่ได้
เมื่อ GlobalId เปลี่ยนทุกครั้งที่ส่งออก จะมีสามสิ่งพังลงพร้อมกันโดยไม่มีสัญญาณเตือน ได้แก่ ประเด็นปัญหาหลุดออกจากองค์ประกอบที่ถูกระบุไว้ การเปรียบเทียบฉบับแก้ไขกลายเป็นเรื่องแต่งเพราะทุกองค์ประกอบดูเหมือนใหม่หมด และข้อมูลทรัพย์สินกระทบยอดกับโมเดลต้นทางไม่ได้ ไม่มีข้อใดทำให้เกิดข้อความแจ้งข้อผิดพลาด แต่ทำให้เกิดโครงการที่ไม่มีใครเชื่อถือประวัติการประสานงานได้เต็มที่ และไม่มีใครบอกได้ว่าเพราะอะไร
ข้อผูกพันเรื่องการรายงานในประโยคสุดท้ายสำคัญกว่าที่เห็น การที่ GUID เปลี่ยนไปมักเกิดจากเหตุการณ์ในกระบวนการที่มีคนรู้อยู่แล้ว เช่น โมเดลถูกสร้างใหม่ หรือไฟล์ถูกส่งผ่านเครื่องมืออื่นแล้วนำกลับมา การรู้ว่าเกิดขึ้นเมื่อใดคือความต่างระหว่างการจดบันทึกหนึ่งบรรทัดกับการต้องไล่สืบสวนหาสาเหตุ ดูสาเหตุเฉพาะได้ในทำไม GUID ของ IFC จึงเปลี่ยนทุกครั้งที่ส่งออก และดูปัญหาที่เกี่ยวข้องซึ่งองค์ประกอบสองชิ้นใช้รหัสระบุเดียวกันได้ในGUID ซ้ำในไฟล์ IFC
ข้อกำหนดที่ 4: พิกัดและหน่วยที่ใช้ร่วมกัน
All task teams shall use the project shared reference point and rotation
defined in {document}, and shall deliver in metric SI length units. Storey
names and elevations shall follow the agreed level schedule without local
variation.
ข้อนี้ให้ผลเฉพาะเมื่อรวมโมเดลเท่านั้น โมเดลของแต่ละสาขางานอาจสมบูรณ์แบบในตัวเอง แต่โมเดลรวม (federated model) ก็ยังใช้งานไม่ได้ เพราะมีความผิดพลาดสามรูปแบบที่มองไม่เห็นจนกว่าโมเดลจะมาเจอกัน ได้แก่ โมเดลที่อ้างอิงจุดกำเนิดต่างกัน ไฟล์หนึ่งที่ใช้หน่วยอิมพีเรียล และตารางระดับชั้น (Level) ของแต่ละสาขางานที่ต้องอาศัยตารางแปลงซึ่งมีคนคอยดูแลด้วยมือ
ส่วนของการอ้างอิงพิกัดทางภูมิศาสตร์ (georeferencing) คือส่วนที่ทำให้เกิดความผิดพลาดแบบน่าตกใจ เช่น อาคารไปอยู่ห่างจากไซต์หลายร้อยกิโลเมตร หรือถูกหมุนผิดทิศ กลไกของเรื่องนี้อธิบายไว้ในพิกัดและการอ้างอิงพิกัดทางภูมิศาสตร์ใน IFC
ข้อกำหนดเหล่านี้ควรอยู่ในเอกสารใด
| เอกสาร | สิ่งที่ควรอยู่ในเอกสารนั้น |
|---|
| EIR (ฝั่งผู้ว่าจ้าง) | สิ่งที่ผู้ว่าจ้างต้องการ: วัตถุประสงค์ของการส่งมอบแต่ละครั้ง ระบบการจำแนกประเภท และข้อมูลทรัพย์สินที่คาดหวังเมื่อส่งมอบ |
| BEP (ทีมส่งมอบงาน) | วิธีที่จะทำให้ได้ตามนั้น: ข้อกำหนดทั้งสี่ข้อนี้ ชุดกฎที่ระบุชื่อ การอ้างอิงถึงค่าการตั้งค่าการส่งออก และตารางความรับผิดชอบ (responsibility matrix) |
| ภาคผนวกของ BEP | ตารางเกณฑ์การตรวจรับ หนึ่งแถวต่อหนึ่งเกณฑ์ โดยกรอกจุดยืนของโครงการไว้ก่อนการส่งมอบครั้งแรก |
| ใบนำส่ง (transmittal) | คำแถลงประจำการส่งมอบแต่ละครั้ง: ฉบับแก้ไข สถานะความเหมาะสม (suitability) คะแนน ชุดกฎ และประเด็นที่พบซึ่งยอมรับตามข้อตกลง |
ข้อกำหนดเพียงลำพังมีคุณค่าไม่มากนัก ต้องมีที่ที่ฝ่ายผู้รับนำไปใช้จริง ซึ่งก็คือตารางเกณฑ์การตรวจรับตารางนี้คือหัวข้อของบทความถัดไป: เกณฑ์การตรวจรับ IFC: วิธีรับหรือปฏิเสธโมเดลโดยไม่ต้องถกเถียง และเมื่อคอนเทนเนอร์ผ่านการตรวจแล้ว คำถามถัดไปคือต้องส่งอะไรไปพร้อมกับโมเดล ซึ่งอธิบายไว้ในสิ่งที่ต้องส่งมอบพร้อมโมเดล IFC
ฉบับย่อในย่อหน้าเดียว
หาก BEP ของคุณเขียนเสร็จแล้วและการเปิดแก้ใหม่มีต้นทุนทางการเมืองสูง ให้เพิ่มย่อหน้าเดียวนี้ในหมวดการส่งมอบสารสนเทศ แล้วคุณจะได้คุณค่าส่วนใหญ่มาแล้ว
IFC containers issued at S2 or above shall be checked with the project rule
set immediately before issue, shall reach a Health Score of at least 80/100,
and shall carry persistent GlobalIds between revisions. The check report
shall accompany the container; exceptions require the written agreement of
the Information Manager.
หากต้องการเห็นว่าข้อกำหนดเหล่านั้นเป็นอย่างไรในทางปฏิบัติก่อนผูกมัดตัวเอง ให้ลองตรวจสอบโมเดลที่คุณส่งมอบไปแล้ว ขั้นตอนการตรวจสอบโมเดลก่อนส่งมอบ ใช้เวลาประมาณหนึ่งนาทีต่อไฟล์ และผลลัพธ์จะบอกคุณว่าเกณฑ์ 80 ถือว่าผ่อนปรนหรือท้าทายสำหรับโครงการของคุณ
ข้อกำหนดใน BEP ที่ป้องกันการส่งมอบไฟล์ IFC คุณภาพต่ำได้จริง